dhcpd does not answer DHCPDISCOVER from systemd-networkd

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

dhcpd does not answer DHCPDISCOVER from systemd-networkd

Frederik Himpe
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;


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
15:56:28.096165 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 329)
    dhcp.example.com.bootps > ai20.example.com.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 301, xid 0xdce3353c, secs 8, Flags [none] (0x0000)
          Your-IP ai20.example.com
          Server-IP ai02.example.com
          Client-Ethernet-Address 04:0e:3c:a3:b2:79 (oui Unknown)
          file "fai/pxelinux.0"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: dhcp.example.com
            Lease-Time Option 51, length 4: 2941
            Subnet-Mask Option 1, length 4: 255.255.255.0
            BR Option 28, length 4: 192.168.0.255
            Default-Gateway Option 3, length 4: 192.168.0.1
            Domain-Name Option 15, length 9: "example.com"
            Domain-Name-Server Option 6, length 8: ns1.example.com,ns2.example.com
            Netbios-Name-Server Option 44, length 4: file.example.com
            END Option 255, length 0



How can I make dhcpd answer the systemd-networkd DHCPDISCOVER request too?

--
Frederik Himpe <[hidden email]>

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: dhcpd does not answer DHCPDISCOVER from systemd-networkd

Simon Hobson
Frederik Himpe <[hidden email]> 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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: dhcpd does not answer DHCPDISCOVER from systemd-networkd

Frederik Himpe
On Tue, 2020-02-25 at 20:31 +0000, Simon Hobson wrote:

> Frederik Himpe <[hidden email]> 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.
> >
> >
>
> > subclass "AI" 1:04:0e:3c:a3:b2:79;
>
> So where is group AI defined ? How is it defined ?

Right, I had forgotten about that. It's defined like this, at the top
level in the hierarchy in dhcpd.conf:

class "AI" {
        match pick-first-value (option dhcp-client-identifier, hardware);
}

And there we have the problem...

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

So this option 61 is the dhcp-client-identifier I'm using in the class
definition. Thanks for the pointing me in the right direction! With
just match hardware it's now working as I want.

Regards,

--
Frederik Himpe <[hidden email]>

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: dhcpd does not answer DHCPDISCOVER from systemd-networkd

glenn.satchell
On 2020-02-26 23:54, Frederik Himpe wrote:

> On Tue, 2020-02-25 at 20:31 +0000, Simon Hobson wrote:
>> Frederik Himpe <[hidden email]> 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.
>> >
>> >
>>
>> > subclass "AI" 1:04:0e:3c:a3:b2:79;
>>
>> So where is group AI defined ? How is it defined ?
>
> Right, I had forgotten about that. It's defined like this, at the top
> level in the hierarchy in dhcpd.conf:
>
> class "AI" {
>         match pick-first-value (option dhcp-client-identifier,
> hardware);
> }
>
> And there we have the problem...
>
>> One really obvious difference there is that dhclient is not sending
>> Option 61, while systemd-networkd is sending a 19 byte Option 61.
>
> So this option 61 is the dhcp-client-identifier I'm using in the class
> definition. Thanks for the pointing me in the right direction! With
> just match hardware it's now working as I want.
>
> Regards,

Hi Frederik

The value of the dhcp-client-identifier, as shown in the packet dump, is
b6:22:0f:eb:00:02:00:00:ab:11:f0:a4:5a:73:5e:e8:d2:07

and that doesn't match the sub-class value, so you can see why the
client doesn't match class AI, and hence "no free leases" :)

Potentially you could have added another value to the sub-class with
that identifier.

subclass "AI" b6:22:0f:eb:00:02:00:00:ab:11:f0:a4:5a:73:5e:e8:d2:07;

The other points are valid though, the whole group statement should be
moved outside the shared-network block.

regards,
-glenn
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: dhcpd does not answer DHCPDISCOVER from systemd-networkd

Pavel Zhukov
[hidden email] writes:

> On 2020-02-26 23:54, Frederik Himpe wrote:
[ ... ]
>>
>> class "AI" {
>>         match pick-first-value (option dhcp-client-identifier,
>> hardware);
>> }
>>
>> And there we have the problem...
>>
[ ... ]

> Potentially you could have added another value to the sub-class with
> that identifier.
Or change pick-first-value order to match hardware first?

>
> subclass "AI" b6:22:0f:eb:00:02:00:00:ab:11:f0:a4:5a:73:5e:e8:d2:07;
>
> The other points are valid though, the whole group statement should be
> moved outside the shared-network block.
>
> regards,
> -glenn
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

--
PAVEL ZHUKOV

 

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: dhcpd does not answer DHCPDISCOVER from systemd-networkd

Simon Hobson
Pavel Zhukov <[hidden email]> wrote:

>Or change pick-first-value order to match hardware first?

That would make pick-first-value a null operation. Hardware is always present.

Simon
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: dhcpd does not answer DHCPDISCOVER from systemd-networkd

Bill Shirley-2
Hardware is always present

Except for IPv6.  This is a real irritation to me about IPv6 along with the fact that
most devices (except Windows) do not send their hostname (or FQDN).  The
whole "I want to hide on your LAN and use your internet service" idea is crazy.

Bill

On 2/26/2020 10:57 AM, Simon Hobson wrote:

> Pavel Zhukov <[hidden email]> wrote:
>
>> Or change pick-first-value order to match hardware first?
> That would make pick-first-value a null operation. Hardware is always present.
>
> Simon
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users