DHCP proxy service does not relinquish lease on container teardown

[pcguy85]

Hi.

Sending a DHCP RELEASE message on container teardown could help with DDNS setups where containers use fixed hostnames or in cases where the pool of available addresses is small and lease time is long. Most dhcp clients I know of relinquish leases when stopped or can be configured to do so.

But sending DHCP RELEASE is not mandated per dhcp spec so this is not a bug report. More like a feature request.

[Rishikpulhani]

I would like to take this up @Luap99

[Rishikpulhani]

/assign

[Rishikpulhani]

@Luap99
i am facing a probelm with the testing of this code patch in my pr #1305 because of my development environment in wsl fedora

Background

My change sends out a dhcprelease message on container teardown to free up the IP address at the DHCP server. To verify this, I need to run containers with DHCP-assigned addresses and observe both the DHCPDISCOVER and DHCPRELEASE packets.

However, WSL’s networking model is making this tricky:

• WSL doesn’t expose a real physical NIC directly.
• The Windows Hyper-V virtual switch drops certain packets (notably raw L2 traffic from macvlan/ipvlan).
• As a result, DHCP traffic from containers never reaches the DHCP server if I try to attach to a real interface.

First attempt

I initially tried creating a macvlan network attached to the WSL-visible interface (eth0) and pointing it at my LAN’s DHCP server.

# List interfaces
ip a

# Create macvlan network
sudo podman network create \
  --driver macvlan \
  --ipam-driver dhcp \
  --opt parent=eth0 \
  dhcp-test-net

# Run test container
sudo podman run -d --rm --name dhcp-test-container --network dhcp-test-net alpine sleep 60

in the other terminal I used the tcpdump tool in order to listen for DHCP traffic on your main network interface.

sudo tcpdump -i eth0 -n 'port 67 or port 68' -v

shortly after creating the container it did emit 2 packets as seen in the output on the other terminal but request timed out with this error message from netavark - Error: netavark: unable to obtain lease: get DHCP lease: Timeout: Timeout

dropped privs to tcpdump
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
16:06:22.001186 IP (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 362)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0a:cb:56:55:f8:81, length 334, xid 0x8cefe82, Flags [none]
          Client-Ethernet-Address 0a:cb:56:55:f8:81
          sname "d0728b93848b"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            Parameter-Request (55), length 7:
              Hostname (12), Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6)
              Domain-Name (15), MTU (26), NTP (42)
            Client-ID (61), length 65: "d0728b93848b8bc156959772e2867009d5f4644d12137614a68c38fd849b4b7f"
            Hostname (12), length 12: "d0728b93848b"
16:06:25.002152 IP (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 362)
    0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0a:cb:56:55:f8:81, length 334, xid 0x8cefe82, Flags [none]
          Client-Ethernet-Address 0a:cb:56:55:f8:81
          sname "d0728b93848b"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            Hostname (12), length 12: "d0728b93848b"
            Client-ID (61), length 65: "d0728b93848b8bc156959772e2867009d5f4644d12137614a68c38fd849b4b7f"
            Parameter-Request (55), length 7:
              Hostname (12), Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6)
              Domain-Name (15), MTU (26), NTP (42)

Second approach - tried running everything locally inside wsl

I ran the following commands - The idea was to avoid the physical NIC entirely by running a DHCP server locally inside WSL and connecting containers directly to it.

# Create dummy interface
sudo ip link add dummy0 type dummy
sudo ip addr add 192.168.100.1/24 dev dummy0
sudo ip link set dummy0 up

# Configure dnsmasq
sudo tee /etc/dnsmasq.d/test-dhcp.conf > /dev/null <<'EOF'
interface=dummy0
bind-interfaces
dhcp-range=192.168.100.50,192.168.100.100,12h
log-dhcp
EOF

# Stop any existing dnsmasq
sudo systemctl stop dnsmasq

# Run dnsmasq manually
sudo dnsmasq --no-daemon --conf-file=/etc/dnsmasq.d/test-dhcp.conf --port=0

Then I tried creating the Podman network:

sudo podman network create \
  --driver macvlan \
  --opt parent=dummy0 \
  --ipam-driver dhcp \
  test-dhcp-net

sudo podman run -it --rm --network test-dhcp-net alpine sh

I got the same error from netavark - Error: netavark: unable to obtain lease: get DHCP lease: Timeout: Timeout

I don't know of any other ways to test this in wsl
I would appreciate some guidance on how to reliably test this in a WSL Fedora environment. My goal is simply to verify that the dhcprelease packet is sent on teardown and reaches the DHCP server. Any pointers on a workable setup for this in WSL would be very helpful.

[Luap99]

I don't use WSL or windows, from experience the WSl networking stuff is quite different from a regular linux system so I don't know how this would affect things. Also macvlan requires a real interface top send data, I don't think it works on top of the virtual interfaces. Then you cannot use the same interface for the parent and dhcp server because the braodcast package is not seen on the same interface where it is sent from.

You should be able to run tests in test-dhcp as that uses namespaces to set stuff up

There you can read the dnsmasq log, i.e.

netavark/test-dhcp/002-setup.bats

Lines 29 to 30 in 6b44b7e

	# Check that there was a hostname in the DHCP requests
	assert `grep -c "client provides name: foobar" "$TMP_TESTDIR/dnsmasq.log"` == 3

We already have a teardown test where you can add the log check
https://github.com/containers/netavark/blob/main/test-dhcp/003-teardown.bats

[Rishikpulhani]

@Luap99, following up on your suggestion, I've added a test to 003-teardown.bats.

But instead of checking the dnsmasq logs, I'm verifying the netavark-dhcp-proxy logs to see the release message being sent. The reason for this workaround is detailed in PR #1305.

I'd appreciate it if you could take a look and provide your feedback. I'm mainly hoping you can review if this testing strategy is valid, as the proxy log confirms the DHCPRELEASE packet is indeed being sent.

[Rishikpulhani]

@Luap99 I’ve made the changes you requested in the PR. However, I still have a doubt regarding the testing, which I’ve mentioned in a comment on this PR (#1305). Could you please take a look when you get a chance?
#1305 (comment)