networkd regression: "DHCP error: could not get routes: No data available"

[martinpitt]

In current trunk, our "networkd" integration tests started failing. I have a simple *.network file like this:

# cat /run/systemd/network/test_eth42.network
[Match]
Name=test_eth42
[Network]
DHCP=yes

which is a veth (the other end is called router_eth42, and runs dnsmasq). With systemd 225 this still works fine, but in current trunk this now gets stuck in "degraded/configuring", although it got all the data:

# networkctl status test_eth42
● 16: test_eth42
       Link File: /lib/systemd/network/99-default.link
    Network File: /run/systemd/network/test_eth42.network
            Type: ether
           State: degraded (configuring)
          Driver: veth
      HW Address: 96:fb:e4:d2:fc:de
             MTU: 1500
         Address: 192.168.5.180
                  fe80::94fb:e4ff:fed2:fcde
         Gateway: 192.168.5.1

Corresponding journal log:

Sep 04 19:30:44 debian systemd[1]: Started Network Service.
Sep 04 19:30:44 debian systemd-networkd[11717]: test_eth42: Gained carrier
Sep 04 19:30:44 debian systemd-networkd[11717]: router_eth42: Gained carrier
Sep 04 19:30:47 debian systemd-networkd[11717]: test_eth42: DHCPv4 address 192.168.5.180/24 via 192.168.5.1
Sep 04 19:30:47 debian systemd-networkd[11717]: test_eth42: DHCP error: could not get routes: No data available
Sep 04 19:30:47 debian systemd-networkd[11717]: test_eth42: Configured

This "could not get routes: No data available" seems to be the culprit? The device itself is configured fine:

# ip a show dev test_eth42
16: test_eth42@router_eth42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 96:fb:e4:d2:fc:de brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.180/24 brd 192.168.5.255 scope global dynamic test_eth42
       valid_lft 3018sec preferred_lft 3018sec
    inet6 fe80::94fb:e4ff:fed2:fcde/64 scope link 
       valid_lft forever preferred_lft forever

# ip route
default via 10.0.2.2 dev eth0 
default via 192.168.5.1 dev test_eth42  proto dhcp  src 192.168.5.180  metric 1024 
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15 
192.168.5.0/24 dev router_eth42  proto kernel  scope link  src 192.168.5.1 
192.168.5.0/24 dev test_eth42  proto kernel  scope link  src 192.168.5.180 
192.168.5.1 dev test_eth42  proto dhcp  scope link  src 192.168.5.180  metric 1

(eth0 is the "real" network card).

[martinpitt]

Bisected to 0339cd770

[martinpitt]

Confirmed in a VM with a real ethernet device, and no veth. So this isn't just an artifact of the test, but an actual issue. This looks quite serious, so I'm taking the liberty to set the release-critical flag.

[mbiebl]

should we create a v226 milestone and assign this issue there?

[poettering]

#1149 is merged now. Closing

(Martin, BTW, you can add "Fixes: #1147" to your commits and that issue will then be closed automatically when I merge the PR)

[martinpitt]

Martin, BTW, you can add "Fixes: #1147"

Ah thanks for pointing out. I'll do that from now on instead of putting a link to the issue in the changelog.

[hwinkel]

@poettering just want to share our experiences with this approach of closing issues or referencing other things via some flavored magic in commit messages like "fixes #1174" if the system referenced here is foreseeable stable like hopefully the github systemd project in the systemd organization this seems fine. Once you will move a repo with such messages you will have broken references without any meaning or pointing to the wrong issue as the namespace is not "globally" unique. And you may decide to rewrite commit history...

just my 2ct as learned in the past ;-)

[filbranden]

Does the "Fixes: #1147" need to be in the commit description? Or can it be in the PR text? I think having it in the PR is better than in the commits themselves...

[hwinkel]

@filbranden good point, at least it stays GH local this way. Never tried but would be good.
and sorry for highjacking the task for unrelated questions.

[poettering]

@filbranden yes you may:

https://github.com/blog/1506-closing-issues-via-pull-requests