Check out our Monthly Survey Page to see what our users are running.
Docker bridge causing wifi havoc?
Guppy 8 Sep
Just had a visit from a very upset network technician, apparently the bridge that docker creates (docker0) announced it self as the default gateway on the interoffice wifi network ( I only use it for printing ).

While I eventually figured out how to force it away from 172.17.0.1 - I do wonder why the default setting is to announce it to other wifi clients?

It's possible that he has been drinking from the chamber pot - but I'd appreciate some feedback.



 
$ docker network inspect c0bf044950bc
[
    {
        "Name": "bridge",
        "Id": "c0bf044950bc5cc555e3418a3f50815e493df863bee03a91c29a29bbc416a3ef",
        "Created": "2022-09-08T13:26:18.318941442+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.15.0.0/16",
                    "Gateway": "172.15.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]


It says 'Scope: local' so I don't see how it could interfere - but the I'm oblivious to the finer points of docker configuration - I just run containers :P

The only change I've ever made to docker apart from installing it just a few minuts ago adding the file

 
$ cat /etc/docker/daemon.json 
{
  "bip": "172.15.0.1/16"
}
Huh?

Are you sure it was docker doing this to their network? Based on your config I can't see a reason why docker would do that.

If it really did that (tbh I doubt it, I could be wrong though!) then changing the IP address alone will not be enough to stop it announcing itself as the default gateway (It'll still try to do it, just under a different IP).

Also, those bridge configurations usually only work within the host machine. That is, pinging 172.15.0.1 in this case from another device on the network almost certainly won't work (at least, not to your docker container, it might ping another device which is assigned that IP, but not your docker).

That's why in most cases there are (automated) forwarding rules in place for a docker container within the host that says in simple terms, incoming data from public ip X forward to internal ip 172.15.0.X that belongs to container X for example.

So I think it's very unlikely that your docker container was announcing itself over the network unless there is something very, very wrong with your config. In most instances if a docker containers network is not setup correctly you'll end up knocking yourself off the network before you knock others off.

Try it again, see if it happens again (probably best with networks permission). If it does, ask to see their network logs just to verify it really is coming from your device.

Lastly, why doesn't their corporate router stop that from happening in the first place?

Is the corporate network even using that IP range? Run "ip addr" check your local ip on the wlan0 interface.

With that said, for further reading this may be of help:
https://docs.docker.com/network/bridge/
Linas 8 Sep
What is your actual network IP range? If it is in the same range as Docker, they will conflict and bad and weird things will happen. Make sure those networks never overlap. Docker likes to pretend that everything is isolated and abstracted, and sort of ignores the fact that it is still part of the host system. Including all those networks it is creating, those are still just networks on your host machine.

If you can, I suggest checking out Podman, and run it rootless mode. Might take a bit more setup, and it is somewhat less mature than Docker, but it was built from the ground up to run without root privileges, and not messing with your networks/firewalls/mountpoints/etc.
Guppy 8 Sep
Quoting: BlackBloodRum[...]
Lastly, why doesn't their corporate router stop that from happening in the first place?

Is the corporate network even using that IP range? Run "ip addr" check your local ip on the wlan0 interface.

[...]

That was my first question "why aren't wifi clients isolated?" - that did not go over well

Relevant lines:
3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 14:5a:fc:2b:5f:db brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.187/24 brd 172.17.0.255 scope global dynamic noprefixroute wlp4s0
       valid_lft 824sec preferred_lft 824sec
    inet6 fe80::6d59:256d:e4b1:3fb/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:45:4f:bb:46 brd ff:ff:ff:ff:ff:ff
    inet 172.15.0.1/16 brd 172.15.255.255 scope global docker0
       valid_lft forever preferred_lft forever


anyway I think I will just turn off wifi around the office unless I need to print :P
Yeah.. there was definitely an IP conflict of some sort going on then.

Just avoid using 172.17.* for anything local, and you should be good.

It's the first time I've seen it happen with docker though! I've only ever seen that happen when someone tries to setup a dhcpd server on their machine for one network interface and it gets set to the wrong (or all) interfaces and it tries grabbing clients.

Though to be fair, I very rarely use docker since I prefer manual setups
Guppy 8 Sep
Quoting: BlackBloodRumThough to be fair, I very rarely use docker since I prefer manual setups

I usually prefer using vagrant, but for plesk development that wasn't my choice ;)
TodC 10 Sep
Quoting: BlackBloodRumHuh?
Are you sure it was docker doing this to their network? Based on your config I can't see a reason why docker would do that.

Quoting: BlackBloodRumIt's the first time I've seen it happen with docker though! I've only ever seen that happen when someone tries to setup a dhcpd server on their machine for one network interface and it gets set to the wrong (or all) interfaces and it tries grabbing clients.

That's it! We use Docker extensively at work and I've never seen or heard of this. That's because as far as I know Docker networks aren't capable of announcing themselves as a gateway. They're just network connections.

I think it is your image that you're running that has a DHCP server or something that is announcing itself as a gateway.

If you can't control that, I think either scope, driver or some of the other settings, or perhaps port mappings on the docker-compose or your command-line equivalent can be changed to prevent what gateway is running from accessing the outside. What does your docker-compose look like? And what is the default network driver? (There can be big differences in how they act, especially with older versions of Docker.)
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.