dhcpd does not do option 54 (Server Identifier) in certain situations
To Reproduce Steps to reproduce the behavior:
- Run dhcpd with the following config 'interface devnet;' where devnet is a VLAN. Upon starting dhcpd no physical Ethernet interface is connected yet (e.g. un-docked notebook). Albeit this being logged as 'dhcpd: devnet missing an interface address' dhcpd does successfully start.
- Notebook gets connected to an Ethernet where Embedded Linux boards are connected via a switched VLAN.
- A client (e.g. connman running on one of them Embedded Linux targets) does send a DHCP Discover packet
- The server then responds with a DHCP Offer packet missing option 54 (Server Identifier). Unsure whether or not this may even be illegal according to spec.
- Unfortunately, connman seems to crash (this is a separate issue to be reported at resp. upstream project).
Expected behavior The dhcpd should never send DHCP Offer packets missing option 54 (Server Identifier).
- ISC DHCP version: isc-dhcpd-4.4.1 (dhcp-server-4.4.1-19.fc31.x86_64).
- OS: Fedora 31 x64
- Which features were compiled in http://rpmfind.net/linux/RPM/fedora/updates/31/x86_64/Packages/d/dhcp-server-4.4.1-19.fc31.x86_64.html
Additional Information A colleague of mine once already enquired about this (see below original message) but never got any response. -------- Original Message -------- Subject: dhcpd does not option 54 (Server Identifier) in certain situations Date: 2018-05-09 17:42 From: Stefan Agner firstname.lastname@example.org To: email@example.com
When I am using dhcpd 4.4.1 on Linux on a VLAN network interface I can successfully start the server. When I then connect the Ethernet cable, dhcpd sends DHCPOFFERs to DHCPDISCOVERs, however they miss option 54.
A quick debug session showed that get_server_source_address gets called from ack_lease and does not get an address since packet->interface->address_count is 0.
During startup the DHCP server actually reports the missing interface address.
Mai 09 17:16:49 trochilidae systemd: Starting IPv4 DHCP server... Mai 09 17:16:49 trochilidae dhcpd: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config Mai 09 17:16:49 trochilidae dhcpd: Internet Systems Consortium DHCP Server 4.4.1 Mai 09 17:16:49 trochilidae dhcpd: Copyright 2004-2018 Internet Systems Consortium. Mai 09 17:16:49 trochilidae dhcpd: All rights reserved. Mai 09 17:16:49 trochilidae dhcpd: For info, please visit https://www.isc.org/software/dhcp/ Mai 09 17:16:49 trochilidae dhcpd: Source compiled to use binary-leases Mai 09 17:16:49 trochilidae dhcpd: Wrote 0 deleted host decls to leases file. Mai 09 17:16:49 trochilidae dhcpd: Wrote 0 new dynamic host decls to leases file. Mai 09 17:16:49 trochilidae dhcpd: Wrote 155 leases to leases file. Mai 09 17:16:49 trochilidae dhcpd: vlaneth0 missing an interface address Mai 09 17:16:49 trochilidae dhcpd: Server starting service. Mai 09 17:16:49 trochilidae systemd: Started IPv4 DHCP server. Mai 09 17:17:03 trochilidae dhcpd: DHCPDISCOVER from 00:14:2d:2d:e4:c9 via vlaneth0 Mai 09 17:17:04 trochilidae dhcpd: DHCPOFFER on 192.168.10.168 to 00:14:2d:2d:e4:c9 (hostname) via vlaneth0
As far as I can tell DHCP mandates option 54. It seems to me that the behavior currently is not ideal. The DHCP server should either deny sending DHCPOFFERs or not start in first place...?
Some initial questions
- Are you sure your feature is not already implemented in the latest ISC DHCP version? No, but at least I could not spot anything relevant in the history since.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time to consider migration? Good question. Kea is news to me but I will give it a try and update this ticket should our use case work there.
- Are you sure what you would like to do is not possible using some other mechanisms? Well, one could keep manually re-starting dhcpd over and over again...
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? Yes, I'm coming from their suggestion to log this as a bug.