5

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 ? 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. 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? 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? 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. Commented May 5, 2021 at 12:33

1 Answer 1

6

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.

3
  • 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/… Commented May 5, 2021 at 14:02
  • I have the same issue but I don't run network-manager service Commented Oct 11, 2022 at 11:31
  • As of 2024.01 the answer for Ubuntu is sudo systemctl restart NetworkManager Commented Jan 28 at 13:50

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.