Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
systemd-networkd never leaves "routable (configuring)" state when no IPv4 gateway is sent #2496
Container Linux Version
When eno1 gets a DHCP address with no gateway, state transitions to
When eno1 gets a DHCP address with no gateway, state remains
# Don't fork, and log to stderr no-daemon log-facility=- # Never listen on eno2 except-interface=eno2 # Use LANL's resolvers no-resolv server=18.104.22.168 server=22.214.171.124 # Hand out IPv6 Router Advertisements enable-ra # As a router, we are valid for 0 seconds (so, like, don't use us) ra-param=eno1,0,0 # Don't hand out a gateway #dhcp-option=option:router,10.0.0.0 dhcp-option=option:router # Hand out DHCP dhcp-range=::1,constructor:eno1,72h dhcp-range=10.28.0.100,10.28.0.254,72h #dhcp-hostsfile=/etc/dhcp.hosts dhcp-authoritative # We have our own domain here local=/mgmt/ domain=mgmt # Add some custom hosts no-hosts #addn-hosts=/etc/hosts.dnsmasq # Read MAC to hostname table read-ethers # Be a TFTP server #enable-tftp #tftp-root=/var/lib/tftpboot # Legacy PXE dhcp-match=set:bios,option:client-arch,0 dhcp-boot=tag:bios,undionly.kpxe # UEFI dhcp-match=set:efi32,option:client-arch,6 dhcp-boot=tag:efi32,ipxe.efi dhcp-match=set:efibc,option:client-arch,7 dhcp-boot=tag:efibc,ipxe.efi dhcp-match=set:efi64,option:client-arch,9 dhcp-boot=tag:efi64,ipxe.efi # iPXE - chainload to matchbox ipxe boot script dhcp-userclass=set:ipxe,iPXE dhcp-boot=tag:ipxe,http://10.28.0.1:2880/boot.ipxe # verbose #log-queries log-dhcp
Thanks for the report. Can you please put networkd in debugging mode and attach logs from a fresh boot (without any pre-existing lease)? A brief tcpdump of the DHCP transaction may also be helpful.
Moreover, I am a bit confused about which CL release you are using, as the os-release and your later explanation don't match.
Sorry for the confusion: I'm using CoreOS beta to run the dhcp server, and stable to run the client. I can't imagine the version of the OS interacts with how dnsmasq hands out responses, but included it for completeness. I don't have the ability to twiddle the DHCP server operating system, so I can't test it out on stable, unfortunately.
If it matters, this behavior is also present in 1632.3.0. It's been around for a while.
I'll inline everything for easier reading, and also attach as a zip file.
I see that a line here is being ignored. This bug is still present without any