Send dhcp-users mailing list submissions to
        dhcp-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
        dhcp-users-requ...@lists.isc.org

You can reach the person managing the list at
        dhcp-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."


Today's Topics:

   1. Re: dhcpd does not answer DHCPDISCOVER from systemd-networkd
      (Simon Hobson)


----------------------------------------------------------------------

Message: 1
Date: Tue, 25 Feb 2020 20:31:19 +0000
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dhcpd does not answer DHCPDISCOVER from systemd-networkd
Message-ID: <36c7b50b-32d1-4434-a480-fce49a37b...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii

Frederik Himpe <frede...@frehi.be> wrote:

> I have a Debian Buster server running dhcpd version 4.4.1-2 an a client
> with Ubuntu 18.04. When I use systemd-netword to get an IP using DHCP,
> the server does not answer the DHCPDISCOVER. However, when I run
> dhclient instead, dhcpd does answer the DHCPDISCOVER. Also PXE booting
> works.
> 
> The server logs this when using systemd-networkd:
> dhcpd[1227]: DHCPDISCOVER from 04:0e:3c:a3:b2:79 via eth0: network AI: no 
> free leases
> 
> With dhclient it says:
> dhcpd[1227]: DHCPDISCOVER from 04:0e:3c:a3:b2:79 (aiexp1) via eth0
> dhcpd[1227]: DHCPOFFER on 192.168.0.20 to 04:0e:3c:a3:b2:79 (aiexp1) via eth0
> dhcpd[1227]: DHCPREQUEST for 192.168.0.20 (192.168.0.1) from 
> 04:0e:3c:a3:b2:79 (aiexp1) via eth0
> dhcpd[1227]: DHCPACK on 192.168.0.120 to 04:0e:3c:a3:b2:79 (aiexp1) via eth0
> 
> dhcpd.conf roughly looks like this:
> 
> shared-network "AI" {
>       subnet 192.168.0.0 netmask 255.255.255.0 {
>               authoritative;
>                option subnet-mask 255.255.255.0;
>                option broadcast-address 192.168.0.255;
>                option routers 192.168.0.1;
>               pool {
>                       allow members of "AI";
>                       range 192.168.0.10 192.168.0.50;
>               }
>               pool {
>                       allow members of "BI";
>                       range 192.168.0.100 192.168.0.150
>               }
>       }
>       subnet 192.168.1.0 netmask 255.255.255.0 {
>               [...]
>       }
> 
>       group {
>               allow bootp;
>                next-server 192.168.0.2;
>                if option arch = 00:07 {
>                        filename "fai/efi/x86_64-efi/core.efi";
>                } else {
>                        filename "fai/pxelinux.0";
>                }
>                host aiexp1 {
>                        hardware ethernet 04:0E:3C:A3:B2:79;
>                }
>        }
> }
> 
> subclass "AI" 1:04:0e:3c:a3:b2:79;

So where is group AI defined ? How is it defined ?

Also, while not linked to your problem, you should move your group out of the 
shared-network declaration. Not sure about the rest of it, but host statements 
are global in scope and defining them within a subnet (or shared network) can 
create some "interesting" inheritance issues.

> tcpdump on the server while using systemd-networkd as client:
> 15:43:51.989154 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP 
> (17), length 316)
>    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request 
> from 04:0e:3c:a3:b2:79 (oui Unknown), length 288, xid 0x488b21d8, secs 1, 
> Flags [none] (0x0000)
>         Client-Ethernet-Address 04:0e:3c:a3:b2:79 (oui Unknown)
>         Vendor-rfc1048 Extensions
>           Magic Cookie 0x63825363
>           DHCP-Message Option 53, length 1: Discover
>           Client-ID Option 61, length 19: hardware-type 255, 
> b6:22:0f:eb:00:02:00:00:ab:11:f0:a4:5a:73:5e:e8:d2:07
>           Parameter-Request Option 55, length 9: 
>             Subnet-Mask, Default-Gateway, Hostname, Domain-Name
>             Domain-Name-Server, MTU, Static-Route, Classless-Static-Route
>             NTP
>           MSZ Option 57, length 2: 576
>           Hostname Option 12, length 6: "aiexp1"
>           END Option 255, length 0
> 
> While using dhclient:
> 15:56:27.094705 IP (tos 0x0, ttl 128, id 0, offset 0, flags [none], proto UDP 
> (17), length 328)
>    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request 
> from 04:0e:3c:a3:b2:79 (oui Unknown), length 300, xid 0xdce3353c, secs 8, 
> Flags [none] (0x0000)
>         Client-Ethernet-Address 04:0e:3c:a3:b2:79 (oui Unknown)
>         Vendor-rfc1048 Extensions
>           Magic Cookie 0x63825363
>           DHCP-Message Option 53, length 1: Discover
>           Hostname Option 12, length 6: "aiexp1"
>           Parameter-Request Option 55, length 13: 
>             Subnet-Mask, BR, Time-Zone, Default-Gateway
>             Domain-Name, Domain-Name-Server, Option 119, Hostname
>             Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
>             NTP
>           END Option 255, length 0
>           PAD Option 0, length 0, occurs 33

One really obvious difference there is that dhclient is not sending Option 61, 
while systemd-networkd is sending a 19 byte Option 61.

Dhclient is also asking for additional options: BR, Time-Zone, Option 119, 
Netbios-Name-Server, Netbios-Scope
While systemd-networkd is asking for : Static-Route

My guess is that with systemd-networkd, the request isn't matching your class 
definition, so is not permitted to use the pool, and hence there are "no free 
leases" to be able to offer one to the client.
The other thing to check is that there is in fact a spare lease in the pool. 
Bear in mind that these are DIFFERENT clients as far as the server is concerned 
due to one offering Option 61 and the other not.

Simon



------------------------------

Subject: Digest Footer

_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users


------------------------------

End of dhcp-users Digest, Vol 136, Issue 11
*******************************************

Reply via email to