Blame Wi-Fi drivers for printer (mDNS) discovery issues

There is a subset of the DHCP Protocol which is the DHCPINFORM packet. This is where the client informs the server of the IP it already has, and gets network information (router, DNS...) back from the DHCP server. Search for "DHCPINFORM" in RFC2131 [1].

This protocol is used on Macs when you configure their interface with "Using DHCP with Manual Address".

Now the fun thing is when you have a misconfigured firewall that's also serving as a DHCP relay, which is how I fell down this rabbit hole. The standard DHCP request package (DHCPREQUEST) by nature will be sent as a broadcast packet, as will the DHCPACK response because of course the client does not have an IP address yet. But a DHCPACK in response to a DHCPINFORM will be a unicast packet, because in this case the client does have an IP address. So if your firewall acts as a DHCP relay but otherwise blocks ports 67 & 68, then the usual DHCP stuff will work (broaecast, handled by the relay), but the "DHCP with Manual Address" (DHCPINFORM) will fail, because the unicast DHCPACK will get blocked.

Anyways, I brought this up in relation to your comment because, for DHCPINFORM, the RFC says this:

> The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.

[1] https://datatracker.ietf.org/doc/html/rfc2131

A quick icmp check before allocation seems like a logical idea until you really think about it.

A DHCP server on the same subnet as the allocation could try ARP first and then resort to ICMP. If the request is relayed then it can't use ARP and can only rely on something like ping.

However, all that takes time. DHCP was invented in a time when a local switched LAN should have a maximum RTT of around 20 to 100ms across itself. Nowadays I expect a RTT to Google public DNS of around 30ms from my laptop over wifi.

How long are you prepared to wait for the test before allocation? That test takes time. Do you send one ping and wait for a second? That's an additional second on roaming and when you open the lid on your laptop and so on. Do you actually wait three seconds - to be really sure, which is even worse. You also have the overhead of DHCP itself and the various reconfiguration systems doing their stuff.

Windows DHCP, Novell's (back in the day), Kea, dhcpd and the rest can all do an ICMP check but I don't recommend it. If you are doing DHCP and you own your network then use DHCP snooping on your switches to keep it regular.

Other OS just discover printer all the time, and for that they need DNS-SD as well, which could not be fixed by static IP assignment.