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.
Recently, I had a look at a number of frameworks to push notification messages to my mobile device based on trigger events of my cloud at home. Think of getting a notification when a service starts misbehaving or crashing, disk drives about to become full, backups finished, etc. So far I’ve used emails and XMPP messages for the purpose. While that works great it doesn’t really fit the purpose. So I was looking for something else and discovered Gotify, ‘a simple server for sending and receiving messages’.
Installation is super easy and I was up and running in just a few minutes. Also, pushing messages from the shell or in programs written in Python and other languages just requires a single line of code. On the wire, HTTP push and Websockets are used and TLS encryption with Letsencrypt certificates are thrown in for good measure. Nice! When I had a look at the traffic to and from my mobile device to the Gotify app, however, I was a bit surprised, to say the least.
For today, I have a screenshot of two bandwidth graphs of a recent working day at home which shows the different applications I use Internet connectivity for. As in the previous blog entries on the topic both graphs show the same timeframe. While the bottom graph shows the complete downlink channel bandwidth of 100 Mbit/s in the downlink direction and 36 Mbit/s in the uplink direction, the upper graph is capped at 10 Mbit/s to show things in more detail.
Like so many other events recently, the Vintage Computing Festival Berlin (VCFB) will hold its annual event in the virtual domain this year. Other retro computing events have already taken place online in 2020 and I very much enjoyed to join events I could not have gone in person. However, all of them have focused on talks while the exhibition of retro computing equipment was unfortunately ditched. At the online VCFB this year, we attempt to do things a bit differently.
After the introduction of my network statistics data collection system in the previous post I can now analyze my line usage over time in detail. Here’s a screenshot that shows a number of overlapping data flows.