networkd - DHCP error: could not get routes: No data available

[ghost]

systemd version the issue has been seen with

238 (in the LXC container)

Used distribution

host ubuntu 4.15.0-23 (being a VPS on a KVM hypervisor with virtio driver)
container archlinux
lxc 3.0.1
dnsmasq 2.79 (on host)

Unexpected behaviour you saw

DHCP error: could not get routes: No data available

Steps to reproduce the problem
(re)starting networkd

---

Having looked into #1147 I thought that been patched. Is it a regression thus?

log from the container (eth0 being a veth passed though from the host)

systemd-networkd[161]: eth0: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST
systemd-networkd[161]: eth0: Link 13 added
systemd-networkd[161]: eth0: Link state is up-to-date
systemd-networkd[161]: eth0: found matching network ‘/etc/systemd/network/eth.network’
systemd-networkd[161]: eth0: Started LLDP.
systemd-networkd[161]: eth0: Acquiring DHCPv4 lease
systemd-networkd[161]: eth0: Saved original MTU: 1500
systemd-networkd[161]: eth0: Adding address: 172.25.120.2/24 (valid for 57min 46s)
systemd-networkd[161]: eth0: DHCPv4 address 172.25.120.2/24 via 172.25.120.1
systemd-networkd[161]: eth0: Updating address: 172.25.120.2/24 (valid for 1h)
systemd-networkd[161]: eth0: DHCP error: could not get routes: No data available

log from host

dnsmasq-dhcp[9782]: 1042366568 available DHCP range: 172.25.120.2 – 172.25.120.254
dnsmasq-dhcp[9782]: 1042366568 client provides name: ovpn
dnsmasq-dhcp[9782]: 1042366568 DHCPREQUEST(br3) 172.25.120.2 72:62:1f:ac:a2:dd
dnsmasq-dhcp[9782]: 1042366568 tags: known, br3
dnsmasq-dhcp[9782]: 1042366568 DHCPACK(br3) 172.25.120.2 72:62:1f:ac:a2:dd ovpn
dnsmasq-dhcp[9782]: 1042366568 requested options: 1:netmask, 3:router, 12:hostname, 15:domain-name,
dnsmasq-dhcp[9782]: 1042366568 requested options: 6:dns-server, 33:static-route, 121:classless-static-route,
dnsmasq-dhcp[9782]: 1042366568 requested options: 42:ntp-server
dnsmasq-dhcp[9782]: 1042366568 next server: 172.25.120.1
dnsmasq-dhcp[9782]: 1042366568 sent size: 1 option: 53 message-type 5
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 54 server-identifier 172.25.120.1
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 51 lease-time 1h
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 58 T1 30m
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 59 T2 52m30s
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 1 netmask 255.255.255.0
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 28 broadcast 172.25.120.255
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 3 router 172.25.120.1
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 6 dns-server 172.25.120.1
dnsmasq-dhcp[9782]: 1042366568 sent size: 4 option: 12 hostname ovpn

[yuwata]

It seems that the dhcp server provides no routes, right?

[ghost]

Been searching for the meaning of

DHCP error : could not get routes: No data available

but came up short. If it referes to 33:static-route a/o 121:classless-static-route then yes, such is not presented by dnsmasq as no such routes are (currently) specified.

So then it may just be my confusion over error vs. No data available. The latter is clear in case there is no static route table present(ed) by the DHCP server but why such necessarily constitues/warrants an error classification is rather not so clear to me.

My conecpetion of error in this context would rather be a malfunction in the communction between DHCP client and server.

If this being my misconception over semantics and not represnting an actual bug than please feel at liberty to close this issue.

[yuwata]

Fix is waiting in #9406.

[rgov]

@yuwata Could you please summarize what the root cause was here? Would this bug manifest as systemd-networkd toggling the link down/up again if DHCP "fails" due to this error?

Your changes in #9406 did not make it into Ubuntu 18.04 and I'm facing the same error, and trying to determine if there is a specific DHCP option I can set on dnsmasq that would work around the issue, without having to patch / upgrade systemd.

I'm not sure how the patch addresses this, since the line with the error message is not modified by the change. I think it's an innocuous message anyway, because no error gets returned to the caller, but I'm not sure.

Thank you.