docker interface eth0 has no ip when run with --privilege flag #76
Comments
|
I actually wound up investigating this very same issue today and found myself here. I see the same issue when running a rootfs container with either # run with default entrypoint
➜ ~ CONTAINER=$(docker run --rm -it -d --privileged openwrtorg/rootfs:x86-64-openwrt-21.02)
# address is initially configured
➜ ~ docker exec $CONTAINER ip addr list dev eth0
147: eth0@if148: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fd00::242:ac11:2/80 scope global flags 02
valid_lft forever preferred_lft forever
inet6 fe80::42:acff:fe11:2/64 scope link
valid_lft forever preferred_lft forever
# sleep for a little bit to allow init process to finish
➜ ~ sleep 5
# address on eth0 is gone
➜ ~ docker exec $CONTAINER ip addr list dev eth0
149: eth0@if150: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet6 fe80::42:acff:fe11:2/64 scope link
valid_lft forever preferred_lft foreverUsing the ➜ ~ CONTAINER=$(docker run --rm -it -d --privileged --entrypoint /bin/ash openwrtorg/rootfs:x86-64-openwrt-21.02)
➜ ~ docker exec $CONTAINER ip addr list dev eth0
147: eth0@if148: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fd00::242:ac11:2/80 scope global flags 02
valid_lft forever preferred_lft forever
inet6 fe80::42:acff:fe11:2/64 scope link
valid_lft forever preferred_lft foreverTherefore I assume that by giving the container extra privileges, something that runs during the normal init process ends up wiping the address from Is there a simple way to prevent the address on |
|
Yep, good find 🕵️ The issue is that OpenWrt tries to takeover control of the interface and apply it's default configuration (dhcp) rather than using the setup interface provided by Docker. This happens pretty much here. Running Question is for what do we want to use the OpenWrt containers. I'm happy to change them so that only |
|
@aparcar I don't know where it comes from or what other (possibly negative) consequences this might have, but setting network.lan.device in /tmp/board.json to an empty string seems to stop the address from being flushed. Is this a really bad idea? If no, would it be possible to build the roots images with this change? Personally, I like that /sbin/init is run and that all the services one would expect are brought up. I'd think making the user need to know exactly which services should be started would be a bit of a pain, as that would be dependent on what packages are installed and how they are configured, presumably. |
|
All right, i that case we should make the init system "container aware" like we did some time ago with procd. I'll think about it but feel free to join in |
|
@aparcar Is there a simpler way (perhaps by overriding some files via https://github.com/openwrt/docker/tree/master/rootfs) to just tell OpenWrt to not touch eth0? The rootfs images already contain slight modifications so that they run better in Docker, the current situation is just unfortunate in that giving the contain more privileges actually makes it function worse. |
|
@nwidger I figured out a way to tape that @aparcar I found an old discussion where you suggested a similar solution. but is there a better way without disabling network service? so that I would like to manage other interface other than eth0. surprisingly other interfaces(eg. eth3, eth4) aren't getting flushed by starting network service. my network config and netifd logs showing undesired manipulation of eth0 without explicit configuration. |
Aw that is cool find. @nwidger led me to this (partial) solution. netifd on x86_64: netifd log on armvirt64 Edit: it seems to disable the eth0 flushing if there is only one interface even on arm64. maybe I'm missing something 🤔 |
|
It is looking like as long as there is some network in /etc/config/network mentions interface that actually exists in the host, netifd auto-magically flushes eth0 as well when it sets up those configured networks. Sigh 😞 it seems like a dead-end on both sides k8snetworkplumbingwg/multus-cni#256 😟 |
|
I have compiled the rootfs for OpenWrt myself and it works properly. Basically, I use the Mavlan network for Podman. |
When I execute docker run command, it has below impacts
Without privileged flag -- ($ docker run -itd openwrtorg/rootfs:x86-64)
Internet is accessible on container
Ip was assigned to docker eth0 interface
With privileged flag -- ($ docker run -itd --privileged openwrtorg/rootfs:x86-64)
Internet not accessible on container
no IP attached to docker eth0 interface, but IP is visible in inspect command output
With --privileged flag we have root privileges but in our case IP is not attached to eth0 primary docker interface.
I just wanna confirm why this strange behavior is being observed.
Thanks
keshav
The text was updated successfully, but these errors were encountered: