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@NAS1: Debian 11
OS lan-basics@NAS2: Debian 12
lan-basics@NAS1 is configured to use bridge br0 which enslaved the
physical interface enp1s0.
lan-basics@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@NAS1, I
made the following attempts:
1. I copied lan-basics@NAS2 to lan-basics2@NAS1. As NAS1 only has one
interface I added lan-basics2 to the same br0 as lan-basics@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@NAS2 to use
this bridge interface. Still the same symptoms.
3. I copied lan-basics@NAS1 to lan-basics1@NAS2. There I first tried
using the same initial config as lan-basics@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.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
