systemd-networkd does not configure DHCPv4

[Benjamin Drung]

I have an up-to-date Ubuntu 18.04 (bionic) server installation (with systemd 237-3ubuntu10) which has following netplan configuration:

```
root@ubuntu:~# cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    all:
      match: {}
      dhcp4: yes
root@ubuntu:~# cat /run/systemd/network/10-netplan-all.network
[Match]

[Network]
DHCP=ipv4

[DHCP]
UseMTU=true
RouteMetric=100
```

Despite having DHCPv4 configured, no IPv4 address is configured on the ethernet device:

```
root@ubuntu:~# ip a show ens6
2: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 64000 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:01:71:8f:cc:72 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::1:71ff:fe8f:cc72/64 scope link
       valid_lft forever preferred_lft forever
```

The kernel dmesg has no related messages and the journal log also looks normal:

```
root@ubuntu:~# journalctl -u systemd-networkd
Jul 02 16:36:51 ubuntu systemd[1]: Starting Network Service...
Jul 02 16:36:51 ubuntu systemd-networkd[1790]: ens6: Gained IPv6LL
Jul 02 16:36:51 ubuntu systemd-networkd[1790]: Enumeration completed
Jul 02 16:36:51 ubuntu systemd[1]: Started Network Service.
Jul 02 16:36:51 ubuntu systemd-networkd[1790]: lo: Link is not managed by us
Jul 02 16:36:51 ubuntu systemd-networkd[1790]: lo: Configured
```

Calling dhclient sets up the device correctly:

```
root@ubuntu:~# dhclient ens6
root@ubuntu:~# cat /var/lib/dhcp/dhclient.leases
lease {
  interface "ens6";
  fixed-address 87.106.172.36;
  option subnet-mask 255.255.255.255;
  option dhcp-lease-time 600;
  option routers 87.106.172.1;
  option dhcp-message-type 5;
  option domain-name-servers 46.16.74.70,46.16.72.37;
  option dhcp-server-identifier 87.106.172.1;
  option interface-mtu 64000;
  option host-name "ubuntu-18_04-fkb-2018-07-02";
  renew 1 2018/07/02 16:46:51;
  rebind 1 2018/07/02 16:51:31;
  expire 1 2018/07/02 16:52:46;
}
root@ubuntu:~# ip a show ens6
2: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 64000 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:01:71:8f:cc:72 brd ff:ff:ff:ff:ff:ff
    inet 87.106.172.36/32 brd 87.106.172.36 scope global ens6
       valid_lft forever preferred_lft forever
    inet6 fe80::1:71ff:fe8f:cc72/64 scope link
       valid_lft forever preferred_lft forever
```

[Benjamin Drung (bdrung)]

You can also reproduce this issue with the official cloud image. See https://askubuntu.com/questions/1030081/ubuntu-18-04-cloud-image-does-not-get-dhcp-ipv4-address

[Dimitri John Ledkov (xnox)]

An empty match, does not match any interfaces hence none are configured....

What's the output of $ networkctl ? i suspect no interfaces are maganaged, right?

Note the config mentioned in this bug report looks buggy, and different from the askubuntu reference - which does appear to have a valid config.

[Benjamin Drung (bdrung)]

My interpretation of the documentation was that an empty match entry matches everything. I changed the configuration to enforce the matching and it still fails:

```
root@ubuntu:~# cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    all:
      match:
        name: ens*
      dhcp4: yes
root@ubuntu:~# networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  2 ens6 ether degraded configuring

2 links listed.
root@ubuntu:~# networkctl status ens6
* 2: ens6
       Link File: /lib/systemd/network/99-default.link
    Network File: /run/systemd/network/10-netplan-all.network
            Type: ether
           State: degraded (configuring)
            Path: pci-0000:00:06.0
          Driver: virtio_net
          Vendor: Red Hat, Inc.
           Model: Virtio network device
      HW Address: 02:01:71:8f:cc:72
         Address: fe80::1:71ff:fe8f:cc72
root@ubuntu:~# cat /run/systemd/network/10-netplan-all.network
[Match]
Name=ens*

[Network]
DHCP=ipv4

[DHCP]
UseMTU=true
RouteMetric=100
root@ubuntu:~# journalctl -u systemd-networkd
Jul 03 08:52:33 ubuntu systemd[1]: Starting Network Service...
Jul 03 08:52:33 ubuntu systemd-networkd[447]: Enumeration completed
Jul 03 08:52:33 ubuntu systemd[1]: Started Network Service.
Jul 03 08:52:33 ubuntu systemd-networkd[447]: lo: Link is not managed by us
Jul 03 08:52:33 ubuntu systemd-networkd[447]: ens6: IPv6 successfully enabled
Jul 03 08:52:33 ubuntu systemd-networkd[447]: ens6: Gained carrier
Jul 03 08:52:35 ubuntu systemd-networkd[447]: ens6: Gained IPv6LL
```

[Benjamin Drung (bdrung)]

Just checked the initial configuration:

```
root@ubuntu:~# cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    all:
      match: {}
      dhcp4: yes
root@ubuntu:~# networkctl
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier configured
  2 ens6 ether degraded configuring

2 links listed.
```

[Dimitri John Ledkov (xnox)]

Ok, i must be mistaken about empty match stuff then.

This does look odd.

systemd-networkd should have forked, to run its own dhcp client implementation. And there should be state data in /run/systemd/netif/ e.g. /leases/ folder should have a lease.

[Benjamin Drung (bdrung)]

/run/systemd/netif/leases is empty

[Dimitri John Ledkov (xnox)]

The dhclient lease looks ok. It has a largish MTU, but that should be fine.

Does the dhcp server in question require MAC based client identifiers?

Could you please try:

network:
  version: 2
  renderer: networkd
  ethernets:
    all:
      match:
        name: ens*
      dhcp4: yes
      dhcp-identifier: mac

Note the additional 'dhcp-identifier: mac' key.

Failing that, a package capture using wireshark inside the guest would be needed; under systemd-networkd, and again under dhclient. Packet capture should reveal what sort of things systemd-networkd is doing different to dhclient.

[Benjamin Drung (bdrung)]

Setting 'dhcp-identifier: mac' (translates to networkd 'ClientIdentifier=mac' option) makes no difference. One specialty is that the subnet-mask is 255.255.255.255 (i.e. /32).

[Benjamin Drung (bdrung)]

$ sudo env SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
[...]
DHCP CLIENT (0x...): received lease lacks address, server address or lease lifetime, ignoring

[Benjamin Drung (bdrung)]

Full log output:

root@ubuntu:~# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
Failed to read $container of PID 1, ignoring: Permission denied
Found container virtualization none.
Bus n/a: changing state UNSET → OPENING
Bus n/a: changing state OPENING → AUTHENTICATING
Failed to open configuration file '/etc/systemd/networkd.conf': No such file or directory
timestamp of '/etc/systemd/network' changed
timestamp of '/run/systemd/network' changed
Ignoring /run/systemd/network/10-netplan-all.network, because it's not a regular file with suffix .netdev.
Ignoring /lib/systemd/network/80-container-vz.network, because it's not a regular file with suffix .netdev.
Ignoring /lib/systemd/network/80-container-ve.network, because it's not a regular file with suffix .netdev.
Ignoring /lib/systemd/network/80-container-host0.network, because it's not a regular file with suffix .netdev.
Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .netdev.
Ignoring /lib/systemd/network/99-default.link, because it's not a regular file with suffix .network.
ens6: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST
ens6: Link 2 added
ens6: udev initialized link
ens6: Saved original MTU: 64000
lo: Flags change: +LOOPBACK +UP +LOWER_UP +RUNNING
lo: Link 1 added
lo: udev initialized link
lo: Saved original MTU: 0
ens6: Adding address: fe80::1:71ff:fe8f:cc72/64 (valid forever)
ens6: Gained IPv6LL
lo: Adding address: ::1/128 (valid forever)
lo: Adding address: 127.0.0.1/8 (valid forever)
rtnl: received address with invalid family 129, ignoring
Enumeration completed
Bus n/a: changing state AUTHENTICATING → HELLO
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=2 reply_cookie=0 signature=su error-name=n/a error-message=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=3 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=4 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_31 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=5 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=6 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/network1 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7 reply_cookie=0 signature=s...

[Benjamin Drung (bdrung)]

Attached dhclient.pcap file generated with:
# tshark -i ens6 -w /tmp/dhclient.pcap

[Felix Geyer (debfx)]

This is not really a bug in systemd-networkd. It just adheres more strictly to the standard.

In this case the DHCP server doesn't send the Option 51 "IP Address Lease Time" in the DHCPOFFER. RFC2131 declares this a MUST (see Table 3: Fields and options used by DHCP servers).

I encountered a similar problem where a DHCP server doesn't send the "Server identifier" option.

[Andrew Jones (andrew.jones)]

This bug in systemd-networkd is affecting our environment also.

We have an RFC-compliant DHCP server that does not reply with Option 54 "Server Identifier". We have made the point to other vendors that this is indeed compliant with the RFC because there is no routable address to the DHCP server so it is not possible to send this option and also stay in line with the RFC.

For context, the reason there is no routable address as this server works in a cloud environment where it impersonates a server in multiple VLANs that belong to customers. It cannot use addresses in those subnets.

`To accommodate potentially incomplete network connectivity, a server MUST choose an address as a 'server identifier' that, to the best of the server's knowledge, is reachable from the client.`
This is the reason why its not possible to send the option in the DHCPOFFER as there is no such address.

There is good support for this implementation from other software such as the ISC dhclient and from Windows.

[Eric Teeter (teetere)]

I don’t know if this should be a different bug or a note added here.

I have tried to setup Ubuntu 18.04 (bionic) server as a router. I was trying to set it up with both IPv4 & IPv6 but the installation (dynamic) would not allow me to get IP from my ISP after setup was complete. When starting setting up it would pull a IPv4 address, but when I set IPv6 to dhcp the ISP would not give any address.

When I would try to use static the setup would not allow me to put in both DNS IP address, which ever was last was the DNS IP address. In other words I could only put in two DNS IP address not four as would be needed for Ipv4 & IPv6 together.

[Dan Streetman (ddstreet)]

please reopen if this is still an issue