In this article, I’m going to describe architecture enhancements for the control system of the WebRTC-controlled telepresence robot I built a few months ago, presented in a previous article.
Since I did not manage to have a satisfying WebRTC support directly in a native Android app, I previously settled for a hack where the smartphone of the Telebot uses two different connections to the signaling channel: one to receive user control in the Android app, and one to handle the WebRTC session in the browser.
This was bad for two reasons:
The robot can enter an incoherent state if one connection is closed and not the other.
User control commands do not benefit from WebRTC, instead they travel through the server, adding latency and jitter.
The Google Chromecast is an impressive little device. If you haven’t encountered one already, it’s a small HDMI dongle which, when connected to a TV screen, allows to play audio, video, or visual content of a compatible webapp from a computer or mobile device.
However, it is primarily designed to only stream content from the Web, and not from your computer itself, which follows the current trend that everything should be “in the cloud” and is infuriatingly limiting. As you can guess, that dubious ideology is not my cup of tea.
Luckily, the excellent library PyChromecast allows to control the device from a Python program. Yet the issue is that it only works for codecs the Chromecast is able to decode natively, i.e., H.264 and VP8. Besides, the Chromecast is only able to handle a few containers like MP4 and WebM. What if you want to stream other video formats ? Besides, what if you want to stream dynamically-generated content, for instance your screen or a live video from a camera ?
Building a specific Android application to handle a WebRTC session on the smartphone and relay commands to the controller via Bluetooth
Setting up a node.js server to serve an HTML5 control page over HTTPS allowing visioconference and remote control
You are without doubt already familiar with the Tor project. The Tor browser is already a very handy tool to surf anonymously, but what if we had an entire network’s traffic forwarded through Tor via a special gateway? Let’s transform a tiny router in a transparent Tor proxy, a portable wifi access point redirecting all traffic to the Tor network!
Let’s begin with a short presentation of one of my favorite hackable network devices: the TL-MR3020.
My network setup at home is surprisingly pretty common: a DSL modem (VDSL2 actually) followed by a router featuring an ethernet switch and an 802.11n wifi access point, configured as a NAT gateway.
Let’s imagine I’m in a country that doesn’t care about the right to private life of its citizens and performs automated mass surveillance, on the pretext of fighting against terrorism or copyright infringement. A gloomy perspective for sure, but let’s keep that as our work hypothesis.
Of course, I could just set up on every computer a VPN whose gateway happens to be in a foreign and more respectful country. However, multiple VPNs on multiple computers are a highly impractical setup for various reasons:
VPN configuration has to be done multiple times, and I’m allergic to repetitive tasks
The maximum number of concurrent connections is restricted by VPN service providers
Access to resources on a local network at the same time is a hassle and need specific configuration, like DNS settings
So, why not install the VPN once and for all in a privacy-enhancing gateway? We will implement it in a clean, IPv6-compatible manner so we even have public addresses working on the hosts.
Our goal is to get a smart gateway behaving as follows:
Outgoing connections are routed through the VPN. We have to use Network Address Translation since the VPN provider only attributed us one IPv4 address and one IPv6 address.
Incoming connections are routed normally to the LAN, so we get IPv4 port forwarding and working IPv6 public addresses.