Back in August, we finally relented to the pandemic reality and started to organize the 2020 edition of the Vintage Computing Festival Berlin in the virtual domain. Things have progressed nicely since then and we are ready to open the doors this this weekend!
I use the XMPP messenger “Conversations” quite a lot these days for end-to-end encrypted voice calls over my own infrastructure and I am quite amazed at how background noise is handled in WebRTC based voice channels on Android devices. When I’m in a ‘normal’ voice call, noise cancellation usually works pretty well until I switch to my Bose headset. Once the headset it plugged in, noise cancellation in the phone is disabled and people find it difficult to understand me due to the background noise in busy places or in the car. Not so with WebRTC!
Over the years, setting up a Linux notebook to access Eduroam Wifi networks around the world has become quite easy. While there is a generic installer script that institutions can customize to help their users to set up their Linux notebook, it has become easy enough in the meantime to just set it up with the standard network manager dialog when connecting to ‘Eduroam’ for the first time. As I recently migrated from Ubuntu 16.04 to 20.04, I had a look if anything had changed in the setup.
I am one of the few people who have the luxury, the time and the knowledge to run most of his cloud based services for family and friends at home. While this is the most private setup for personal data and communication, not everyone who wants his private data not to be in the hands of globally dominating surveillance capitalism companies does have this luxury. But there are many options for privacy focused people even if they can’t run cloud services on their own. As I keep being asked what I’d recommend, I thought I’d put together a post on how to have as much control over your privacy and your data as possible while not hosting the required servers (‘the cloud’) at home.
This is a follow-up to my previous post on IPv6-only connectivity in combination with DNS64 and NAT64 on Bouygues’s mobile network. One would assume that in an ideal world, the Android operating system would only query the IPv6 address of a domain name. In practice, however, this is not quite the case and different apps are behaving quite differently.
Quite a number of mobile network operators around the world these days support IPv4 / IPv6 dual stack operation. That’s nice but the real goal of the exercise is to eventually end up in an IPv6-only world without any IPv4 traffic in the network. Recently, I noticed that French mobile network operator Bouygues has also switched to IPv6-only operation for mobile Internet access.
I first noticed what Bouygues was doing when I had a look at the APN settings that were automatically configured when I inserted a Bouygues SIM in a device. As can be seen in the first screenshot in this post, the ‘APN protocol’ field is set to “IPv6” rather than “IPv4” or “IPv4v6”. When in the home network in France, the device only requests IPv6 connectivity in the LTE ‘PDN Connectivity Request’ and ‘ESM Information Request’ messages. As a result the device only gets the IPv6 addresses of DNS servers and an IPv6 interface identifier in the LTE ‘Activate Default EPS Bearer Conext Request’ message. Together with the IPv6 prefix received on the user plane in an IPv6 ‘Router Advertisement’ message, the device then generates its IPv6 address.
Now that Conversations supports end-to-end encrypted voice calls I have come to use it on a daily basis. While for text and image messaging I don’t mind a delay of a few seconds it is crucial that the setup of a voice call happens as quickly as possible. It turns out that in practice quite a number of things can delay message exchange and things can be optimized. In a previous post I went into the details of configuring TCP timeout of the XMPP server to counter carrier NAT gateways that have a very low NAT timeout value and cut connections before the default TCP or application keep alive mechanism sends an IP packet to keep the connection open. Once that was fixed, call establishment worked fine while the device in question was using the cellular mobile network. However, I still suffer some delay or even call setup failures when devices are connected to a particular Wifi network so I had a look at that scenario as well.
A quick blog post today about a super useful feature that must have been in the Linux ‘tail’ command for ages of which I only recently became aware: The upper case -F option.
For many years now I’m operating a Prosody XMPP server at home for private messaging between family members and friends. Together with Conversations on Android devices and the Dino App for Linux it’s the perfect solution. There is one client device, however, to which messages sometimes take a couple of minutes to be delivered. Also I noticed that it frequently reconnects to the XMPP server. That client device is usually connected to a French mobile network so I assumed that they probably have a very short NAT timeout on their gateway that kills the TCP session to the server before either the client or the server sends some sort of keep-alive message. Not a big deal so far but since Conversations has been extended with voice and video calls, call establishment fails to the device every now and then. Time for having a closer look.
Sometimes when I get visitors I am politely asked for the Wi-Fi password of my network. No problem with that but as my password even for the guest Wi-Fi is a bit complicated it’s a pain to type it in. A nice solution: My Wi-Fi router can display a 2D bar code in the Web-UI which most mobile devices can read today either in the camera app or with a separate bar code app and detect that it contains Wi-Fi configuration information.
While this works very nicely with my router at home, I do have some Wi-Fi access points that don’t have this function, so I was wondering how I could generate such a bar code myself.