Today I want to share a different type of story. When I travel in Germany, I usually always take the train. If some of you ever travelled from Berlin westbound will probably know, that as soon as you leave Berlin, the internet connection gets really bad, no matter if you use the wifi on board an ICE or your mobile as a hotspot. But those of you using Linux and being developer might not even be able to connect to the internet using the wifi at all.

WIFIonICE

When you take an ICE high speed train, even in the 2nd class you will be able to use free wifi. It’s decent enough for most things, even streaming and video calls, if you really need to do them. But please not in a quite zone! For streaming, at iceportal.de you will even find some movies and series to watch, just like in a plane.

That sound nice, right? But you might not be able to use it at all. Usually, you would connect to either WIFIonICE or WIFI@DB and your browser will pop up to ask you to accept the terms. If that’s not happening, open a browser and navigate to LogIn.WIFIonICE.de to see that page. You did that and nothing happens? Then the FAQ section on the DB website might help you. But you wouldn’t be here it that worked, right?

OK, let me take a guess: you might be using a Linux laptop, but you are definitely using for local development you are using Docker. Got it? Then welcome to my uncommon blog post to a strange topic ?

Docker networks and WIFIonICE

The issue is one, you will unfortunately not find on the DB website. And it’s also one I ran into and couldn’t find out, why I was not able to see the page to accept the terms. Any request to any page just failed. Nothing happened in the browser. The reason for that is the following: the ICE on board network uses the 172.17.0.0/16 IP range. And not take a guess what Docker is using as the default IP range for its networks! You are a clever one ?

Solving the issue

In order to be able to connect, you have to remove the network attached to the IP address 172.17.0.1 from your Docker networks. This could be done with the OS tools (like ip link delete) or using the docker network rm command. This would fix it, but it might break things within Docker, as the network you have just deleted is probably needed. Usually its the primary bridge network. And when you board an ICE in some months time, the IP address might again be taken by another Docker network. So I needed a more robust solution.

Change the IP range

After some research, I’ve found the documentation of an optional configuration file you can have on your system to set some variables for the Docker daemon. This page also contains a full example for a Linux configuration. From this, we would only need a small part. First, you open up the configuration file (or create it):

sudo vim /etc/docker/daemon.json

Now you add (at least) the following lines and save the file:

{
  "default-address-pools": [
    {
      "base": "172.30.0.0/16",
      "size": 24
    },
    {
      "base": "172.31.0.0/16",
      "size": 24
    }
  ]
}

I have defined two alternative IP ranges. One would probably have been enough. After changes on this file, you have to restart the Docker daemon. For me, this command did it (on Manjaro Linux):

systemctl restart docker

Now you should be able to open up the page to accept the terms and finally start some productive coding session on the train … or enjoy a movie from the onboard media library ?

Conclusion

Network issues and issues with (public) hotspots is probably something we all can tell many stories about. But I’d never imagined that using Docker would cause an issue, not even DB is aware of. Or at least they don’t have anything in their FAQ about this specific issue, which probably not only I had more than once now. So is this blog post helped you to get online, why not leave a little comment? ☺️