DHCP for physical network adapter

Incus
1

Completely new to Incus, I am trying to create a container with a physical adapter attached to it.

The host and the container (named LAN2) both run Debian 12. Before being managed by Incus, the adapter gets an IP address from the DHCP server running on the router (10.169.1.1/24).

After I run

incus network create LAN-USB3 --type=physical parent=enx000acd30c4bb
incus network set LAN-USB3 ipv4.gateway 10.169.1.1/24
incus network attach LAN-USB3 LAN2 eth1

The interface eth1 shows up in the container but has no IP address. I then run
ip addr add 10.169.1.100/24 dev eth1
and networking runs fine.

But I don’t know how to make it permanent and I don’t know how to obtain the IP address from the DHCP server.

I have searched using DuckDuckGo but most of the links point to the official doc where I cannot find what I am looking for.

$ incus profile show default
config: {}
description: Default Incus profile
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: lxcbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: default
used_by:
- /1.0/instances/postgres
- /1.0/instances/LAN2
- /1.0/instances/LAN4
project: default

$ incus network show LAN-USB3
config:
  ipv4.gateway: 10.169.1.1/24
  parent: enx000acd30c4bb
  volatile.last_state.created: "false"
description: ""
name: LAN-USB3
type: physical
used_by:
- /1.0/instances/LAN2
managed: true
status: Created
locations:
- none
project: default
``
2

When you use type=physical, the device is gone from the host and appears in the container.
When it appears in the container, it has lost any configuration that it had from the host.
Once in the container, it has to request configuration anew, for example, with DHCP.
If the container is in a VM, then it might struggle to receive the DHCP response. You can use all those networking tools like tshark to figure out if a request is sent, and if the reply is received.

3

Hi Simos,

it took me a while to figure out what the problem was in the container.

  1. I had to understand that the network interfaces were managed by systemd-networkd.service and not by networking.service like I was used to under Debian until now.
  2. I tried hard to configure eth0 properly using /etc/systemd/network/eth0.network, to no avail. While invoking dhclient -r or ip addr add would work, systemctl restart systemd-networkd` would leave the interface in a broken state.
  3. I finally figured out using journalctl -b 0 that there were plenty of error messages related to udevadm:
root@LAN2:~# journalctl -b 1 | grep udev | grep eth
Jul 01 22:28:11 LAN2 udevadm[125]: cdc_ether: Failed to write 'add' to '/sys/bus/usb/drivers/cdc_ether/uevent': Permission denied
Jul 01 22:28:11 LAN2 udevadm[125]: cdc_ether: Failed to write 'add' to '/sys/module/cdc_ether/uevent': Permission denied
Jul 01 22:28:11 LAN2 udevadm[125]: veth: Failed to write 'add' to '/sys/module/veth/uevent': Permission denied
Jul 01 22:28:12 LAN2 udevadm[132]: eth1: Failed to write 'add' to '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.1/2-2.1:1.0/net/eth1/uevent': Permission denied
  1. Searching on the internet, I realised that this was probably due to the unpriviledged nature of the container. Indeed, after changing it to priviledged, the messages disappeared and the interface got its configuration from /etc/systemd/network/eth0.network.

So now my question is : is running a priviledged container the only way to use an adapter of type physical in combination with systemd-networkd ?

Kind regards.

4

There shouldn’t be a difference between the two.

This is a USB 4G dongle, right? Does it initially appears as a CDROM device and then has to switch (through usbmodeswitch / udevadm) into a network device?

5

I don’t think so. Back to the host (Debian 12 too) :

ballama@dellxps:~$ lsusb
Bus 002 Device 007: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
Bus 002 Device 006: ID 2109:8110 VIA Labs, Inc. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0cf3:e300 Qualcomm Atheros Communications QCA61x4 Bluetooth 4.0
Bus 001 Device 011: ID 2109:2811 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

It is a USB 3 network adapter that shows up as device 007.

As a side note, when running the container as unprivileged, I get many more udevadm related messages. I filtered them to show only a few in my previous message.

If I am not mistaken, systemd tries to set read access on device files in order to be able to get notified of changes. In an unprivileged container, this boot-time operation fails. Here is an excerpt of the journal :

Jul 07 12:48:44 LAN2 udevadm[129]: acpi: Failed to write 'add' to '/sys/bus/acpi/uevent': Permission denied
Jul 07 12:48:44 LAN2 udevadm[129]: ac: Failed to write 'add' to '/sys/bus/acpi/drivers/ac/uevent': Permission denied
Jul 07 12:48:44 LAN2 udevadm[129]: battery: Failed to write 'add' to '/sys/bus/acpi/drivers/battery/uevent': Permission denied
Jul 07 12:48:44 LAN2 udevadm[129]: button: Failed to write 'add' to '/sys/bus/acpi/drivers/button/uevent': Permission denied
Jul 07 12:48:44 LAN2 udevadm[129]: ec: Failed to write 'add' to '/sys/bus/acpi/drivers/ec/uevent': Permission denied

On the host (root id = 0) :

ballama@dellxps:~$ ls -l /sys/bus/acpi/
total 0
drwxr-xr-x  2 root root    0  7 jui 13:22 devices
drwxr-xr-x 13 root root    0  7 jui 13:16 drivers
-rw-r--r--  1 root root 4096  7 jui 13:22 drivers_autoprobe
--w-------  1 root root 4096  7 jui 13:22 drivers_probe
--w-------  1 root root 4096  7 jui 13:22 uevent

In the container (here in unprivileged mode) :

root@LAN2:~# ls -l /sys/bus/acpi
total 0
drwxr-xr-x  2 nobody nogroup    0 Jul  7 13:13 devices
drwxr-xr-x 13 nobody nogroup    0 Jul  7 13:13 drivers
-rw-r--r--  1 nobody nogroup 4096 Jul  7 13:21 drivers_autoprobe
--w-------  1 nobody nogroup 4096 Jul  7 13:21 drivers_probe
--w-------  1 nobody nogroup 4096 Jul  7 13:13 uevent
6

I found this issue on GitHub/systemd that describes the problem.

It dates back to September 2023 and there does not seem to be a fix for the moment.

If nobody knows a workaround for unprivileged container, I will investigate other network managers to see if they are affected as well.

7

I finally created a service that invokes dhclient.

$ sudo vi /etc/systemd/system/eth0.service

[Service]
Type=oneshot
ExecStart=/bin/bash -c "dhclient -i eth0"

[Install]
WantedBy=systemd-networkd.service

$ sudo systemctl enable /etc/systemd/system/eth0.service
$ sudo systemctl restart systemd-networkd
1 Like