[Dnsmasq-discuss] DHCP packet received on enp6s0 which has no address

[Masin Wiedner]

I finally found some time for further investigations. Here are my 
observations.

NAS1: old NAS with systemd-nspawn lan-basics
NAS2: new NAS with systemd-nspawn lan-basics
lan-basics1: NAS1's lan-basics on NAS2
lan-basics2: NAS2's lan-basics on NAS1

OS NAS1: Debian 11
OS NAS2: Debian 12
OS lan-basics at NAS1: Debian 11
OS lan-basics at NAS2: Debian 12

lan-basics at NAS1 is configured to use bridge br0 which enslaved the 
physical interface enp1s0.

lan-basics at NAS2 started with 1 of 4 interfaces moved into the 
systemd-nspawn, enp6s0. I removed any additional interfaces of my prior 
setup as I wanted to reduce the moving parts.

Leaving aside dnsmasq's configuration that worked on lan-basics at NAS1, I 
made the following attempts:

1. I copied lan-basics at NAS2 to lan-basics2 at NAS1. As NAS1 only has one 
interface I added lan-basics2 to the same br0 as lan-basics at NAS1. The 
result was the same as on NAS2: "DHCP packet received on host0 which has 
no address" (the veth interface in this configuration is named host0 in 
the container).

2. I replicated the network configuration from NAS1: I created a bridge 
interface br0, enslaved enp6s0 and configured lan-basics at NAS2 to use 
this bridge interface. Still the same symptoms.

3. I copied lan-basics at NAS1 to lan-basics1 at NAS2. There I first tried 
using the same initial config as lan-basics at NAS2 with enp6s0, but 
lan-basics1 now oddly showed the same symptoms.

4. I reconfigured the network to enslave enp6s0 under br0 and 
lan-basics1 to use this bridge interface. It works.

For the moment I stick to setup 4 but there's apparently something wrong 
with how dnsmasq treats namespaced interfaces. I can switch around 
setups 3 and 4, always with the same result of dnsmasq complaining about 
receiving DHCP packets on the interface where it doesn't know its 
address. Yes, I made sure that dnsmasq is started after the interface 
got its configuration (stopping dnsmasq, checking the address of the 
interface, starting dnsmasq).

I haven't tried yet the other network options of systemd-nspawn, e.g. 
IPVLAN, MACVLAN, VETH with port forwarding etc. Giving a systemd-nspawn 
container a network interface with exclusive access should be the gold 
standard of all possible network configurations.

FWIW, the versions of the involved dnsmasq binaries are 2.85 for Debian 
11 and 2.89 for Debian 12.

I believe this to be a bug in dnsmasq. I'd gladly help to debug it but I 
can't do it myself. AFAICT the problem seems to be in iface_check in 
network.c but I don't know where it goes wrong.