4

I see this problem on my laptop: when I docker run a Docker container, then after a few seconds my WiFi internet stops working. I don't have an Ethernet connection to test that side of things.

I don't know how to troubleshoot this, I see I have 2 network interfaces relevant to this issue:

  • the wifi interface wlp2s0
  • the docker interface docker0

As soon as the network I/O starts on the network interface docker0, then it stops on the network interface wlp2s0. I can check this with a web browser because when a Docker container is running, then I am not able to reach any web page via the browser.

I see this networking configuration in Docker:

docker network list
NETWORK ID     NAME      DRIVER    SCOPE
5d408693425d   bridge    bridge    local
2eba59b04a5f   host      host      local
f22b30d7782a   none      null      local

When using ifconfig I see this:

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:e5ff:fe8a:b85c  prefixlen 64  scopeid 0x20<link>
        ether 02:42:e5:8a:b8:5c  txqueuelen 0  (Ethernet)
        RX packets 9034  bytes 1228570 (1.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9945  bytes 94278580 (94.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

...

wlp2s0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500
        inet 192.168.1.54  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2001:b07:6477:ebfa:e46f:631e:206c:8a9e  prefixlen 64  scopeid 0x0<global>
        ether 04:d3:b0:ee:2f:b9  txqueuelen 1000  (Ethernet)
        RX packets 3771571  bytes 3664198427 (3.6 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2460874  bytes 1439515295 (1.4 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I don't need to do sudo ifconfig wlp2s0 up or anything after I stop the running docker containers. Internet just starts working again.

In /etc/docker I only see a file named key.json which doesn't look like it's related to networking settings (like e.g. /etc/docker/daemon.json for DNS entries, which is not there).

In this file ~/.docker/config.json I only see some authorizations to some private Docker registry, nothing related to networking. There are some other tocken related files which I believe are not relevant:

$ ls -a ~/.docker/
.  ..  .buildNodeID  config.json  .token_seed  .token_seed.lock

If I restart NetworkManager with sudo systemctl restart network-manager.service after running the docker container, then I still cannot reach the internet with either my browser or e.g. ping 8.8.8.8 (but ping localhost keeps working regardless the fact that I am running or not a Docker container).

I've also tried to change the NetworkManager configuration (see here) at /etc/NetworkManager/NetworkManager.conf by adding:

[keyfile]
unmanaged-devices=interface-name:docker0

Then restarting the service with sudo systemctl restart network-manager.service. But the effect is the same: after a few seconds from when the Docker container starts, then the internet is not on reach via WiFi.

However this might be related to a bug or mis-configuration with Network Manager because when I check the logs of the service with service network-manager status then I see this:

May 05 08:49:05 my-host NetworkManager[1269565]: <info>  [1620200945.9900] dhcp6 (wlp2s0): option dhcp6_name_servers   => '2001:b07:6477:ebfa:aa2b>
May 05 08:49:05 my-host NetworkManager[1269565]: <info>  [1620200945.9900] dhcp6 (wlp2s0): state changed unknown -> bound
May 05 08:49:06 my-host NetworkManager[1269565]: <info>  [1620200946.2184] manager: startup complete
May 05 08:53:43 my-host NetworkManager[1269565]: <info>  [1620201223.6347] manager: (veth90dd212): new Veth device (/org/freedesktop/NetworkManage>
May 05 08:53:43 my-host NetworkManager[1269565]: <info>  [1620201223.6358] manager: (veth9cfce50): new Veth device (/org/freedesktop/NetworkManage>
May 05 08:53:43 my-host NetworkManager[1269565]: <info>  [1620201223.6374] device (veth90dd212): carrier: link connected
May 05 08:53:43 my-host NetworkManager[1269565]: <info>  [1620201223.6389] device (veth9cfce50): carrier: link connected
May 05 08:53:43 my-host NetworkManager[1269565]: <info>  [1620201223.6394] device (docker0): carrier: link connected
May 05 08:55:29 my-host NetworkManager[1269565]: <info>  [1620201329.0433] manager: (veth90dd212): new Veth device (/org/freedesktop/NetworkManage>
May 05 08:55:29 my-host NetworkManager[1269565]: <info>  [1620201329.0777] device (veth9cfce50): released from master device docker0
  1. until 08:53 all good: the WiFi works and no Docker containers run
  2. at 08:53:43 I start a Docker container and Network Manager links to both docker0 and some other transient network interfaces that appear because I run a new Docker container. The internet is not on reach.
  3. at 08:55:29 I stop the Docker container, then Network Manager releases resources from docker0. The internet is back to normal: I can see web pages again.

This issue happens to me with a variety of Linux Ubuntu/Debian versions and Docker versions, anyway my current setup is:

Ubuntu:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:        20.04
Codename:       focal

Docker:

$ docker --version
Docker version 20.10.6, build 370c289

Network Manager:

$ /usr/sbin/NetworkManager --version
1.22.10
$ nmcli --version
nmcli tool, version 1.22.10

I read this page a few times https://docs.docker.com/network/bridge/ and I think my Docker Bridge is working, because when I run these Docker containers on my laptop they are able to reach the Internet. However that documentation on the Docker website is a bit dry and I am not sure how to deeply troubleshoot these networking issues.

  • What's wrong with the docker configuration?
  • Is there any mis-configuration with Network Manager?
  • What do I have to do to make the 2 network interfaces to work together simultaneously?

EDIT:

Before running Docker containers:

$ ip route get 1.1.1.1
1.1.1.1 via 192.168.1.254 dev wlp2s0 src 192.168.1.54 uid 1000 
    cache 

After running the Docker container:

$ ip route get 1.1.1.1
1.1.1.1 dev vethf6c1790 src 169.254.198.92 uid 1000 
    cache
$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 169.254.198.92 icmp_seq=1 Destination Host Unreachable
^C 

That vethf6c1790 always appears as a new network interface when I run a new Docker container.

7
  • Did you try reaching Internet with an IP, like pinging a "famous" IP like 1.1.1.1 or 8.8.8.8, to check it's not just name resolution. Can you also give the result before failure and during failure of ip route get 1.1.1.1 ?
    – A.B
    Commented May 5, 2021 at 12:05
  • Among other things, it appears the bridge port interface is configured with an IP address, maybe by a DHCP client (which fails and uses IPv4LL): that's should not be done.
    – A.B
    Commented May 5, 2021 at 12:14
  • docker0 has always had an IP address e.g. 172.17.0.1 (I checked with ifconfig), that's the way I can find where containers listen to e.g. HTTP ports. I am not sure I get the context here, I am not familiar with bridge networks from a practical point of view. Where should I look, what commands or concepts should I research?
    – TPPZ
    Commented May 5, 2021 at 12:18
  • 1
    docker0 is the bridge interface. vethf6c1790 is the bridge port interface. Don't confuse them. Or maybe it's not in your setup. Check: ip link show type bridge_slave . Does vethf6c1790 appear?
    – A.B
    Commented May 5, 2021 at 12:18
  • Yes it appears as a bridge slave. I found out 169.254.0.0/16 means IPv4LL (link-local) and yes vethf6c1790 appears to have 169.254.198.92 which gets in the middle when a Docker container is running. My wlp2s0 network interface (WiFi) gets assigned a local IP via DHCP by my router - if that's what you mean? My router is somehow assigning a LL IP to the bridge port as well? I struggle to follow - however, my docker installation is the usual one, no custom changes or extra configuration.
    – TPPZ
    Commented May 5, 2021 at 12:33

1 Answer 1

5

It turns out NetworkManager tries to manage and assign an IP address to the veth* network bridge port (I am assuming this is related to the docker0 network bridge).

All these veth* appear in the ifconfig list after I invoke docker run to start a Docker container. They have a different suffix label that is dynamic, but their prefix is always veth*.

So the solution is to demand Network Manager to ignore these bridge ports.

I added to /etc/NetworkManager/NetworkManager.conf this configuration with a wildcard on the name veth*:

[keyfile]
unmanaged-devices=interface-name:veth*

Then I restarted the NetworkManager service with: sudo systemctl restart network-manager.service

After doing that I was able to navigate the internet while having Docker containers running and listening on these bridge ports like vethf6c1790.

2
  • 1
    If you're interested in bridges on Linux, check this answer of mine where I put references to blog series about bridges: unix.stackexchange.com/questions/546136/…
    – A.B
    Commented May 5, 2021 at 14:02
  • I have the same issue but I don't run network-manager service
    – fccoelho
    Commented Oct 11, 2022 at 11:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .