I really like traving by train. You can sit in a comfy seat and if you are so inclined, you can even get a bit of work in. That is, if you are not too dependent on the internet because for some obscure reason, german trains still have rather shitty internet.
Okay, to be fair it has gotten better and it is maybe expected to be somewhat spotty on a route that involves tunnelling through a Mittelgebirge.
Except, for me, it wasn’t working at all. I couldn’t even get to the captive portal after connecting to the Wifi.
Trying my usual debugging for network connections, I tried to ping the gateway which worked. Okay, so how about name resolution, after all, it is, as we all know, always DNS, right?
Okay, weird, the DNS server rejects my connections on port 53.
Aha!
I must admit, at this point, I did a bit of web searching on my phone (I’m trying to get into the habit of not calling it googling anymore, which it actually isn’t, so there) and someone in an obscure forum suggested that there could be issues when using Docker.
Which lead to a couple of challenges. For basically all of my life, either ipconfig or ifconfig, depending on using a Windows or a Linux system, would give you a list of network interfaces.
This is no longer true for Linux, at least not generally.
On my machine, on Ubuntu, the correct incantation to see both the IPv6 and the IPv4 addresses is ip address. Now I know and now you know.
Private IP ranges, a primer
Now to explain what’s happening we need to understand the concept of private IP blocks. You have encountered these before. If you look at your local IP address at your home network, chances are, it looks a bit like 192.168.0.200 or so. Or maybe, depending on your provider, even something like 10.10.1.200.
Just to be absolutely sure, let’s quickly make sure we are all on the same page regarding IP addresses. They are distinct addresses of nodes in a network. For example, if you ask the DNS to tell you the address of the webserver of this page, it will tell you, after a bit of indirection, that it is 138.201.249.230. This is a public IP address that is “owned” by my provider, Hetzner.
These IP addresses are somewhat rare, given that they are only 32 bit numbers (The dot notation we usually use for IP addresses is just a representation of a 32 bit number that is a bit easier to understand and reason about, because it allows us to segment the numbers into blocks) and so for example your internet provider (usually) doesn’t actually give you a public IP address for each of the devices you connect to your home network, instead they use a thing called NAT (If you are a network professional, please ignore my inaccuracies, I’m trying to keep this brief) which allows you to use the before mentioned private IPs inside the network.
There are three distinct blocks of private IP ranges. The first one is the 10.x block. It allows you to run one single network that can have up to 16,777,216 distinct addresses. In most organisations, you will probably split this up into multiple sub networks, but technically, you could use it as one block.
The second one we all know is the 192.168.x block. Usually, when used in a home network, you will only use a single sub block of this network, allowing you to use 256 distinct addresses. This is probably enough for a while for home networks, even with the internet of shit.
But if you’re trying to provide Wifi for a whole ICE train, 256 is definitely not enough. And while you technically could use the full block of 65536 distict addresses, that’s not usually how this network is used.
So the engineers designing the network for Deutsche Bahn decided to use the third network block, the slightly weirdly shaped 172.x block. Which is inaccurate, because the actual range is from 172.16.0.0 to 172.31.255.255.
This is slightly inconvenient to read in the usual dot notation because the available address space is 20 bits. But it isn’t so bad, because this is usually split up into 16 segments (= four bits) of 16 bits, so that we end up with the last two segments as the usable address space for a network.
This is where Docker comes back in
Now for some reason, the 172.x IP block is rarely used for NAT. I don’t really know why, but I must admit that before I encountered this particular issue I didn’t even know about this block.
Which is probably why Docker engineers decided to treat it as their private address space.
And io and behold, when looking at the output of ip address, one of the docker networks had an IP of 172.18.0.1 which is also the standard address of the ICE Wifi gateway, at least for my train.
So instead of asking the gateway for DNS responses, I actually asked a non running docker container’s IP address.
Okay, let’s fix this
The fix to this is twofold. You can probably, if it is a development thing on your machine, delete the particular docker network that’s clogging that particular address using docker network rm.
But also, it is a good idea to instruct docker to never use that particular network range ever again by creating (or modifying) /etc/docker/daemon.json.
Mine looks like this now:
{
"bip": "172.29.0.1/24",
"default-address-pools": [
{
"base": "172.30.0.0/16",
"size": 24
},
{
"base": "172.31.0.0/16",
"size": 24
}
]
}
The first one defines the base IP of the docker daemon, and the pools are just network segments the docker daemon is free to use. Your mileage may vary.
After restarting the docker daemon (And probably rebooting for good measure because that always seems to help), my Computer happily connected to the network and I was able to push out some code one of my clients was waiting for.
But then there was this tunnel and … well, nevermind.
