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

https://printserver.ink/blog/blame-wifi-drivers-for-printer-discovery-issues/

by ValdikSS • 9 months ago

30 6 9 months ago

Since modern DHCP servers ping check an ip before they assign it, I usually static assign the printer it's DHCP assigned IP allowing the mdns cache - which I haven't check but appears to be persistent between reboots- to work assuming you print regularly.

ValdikSS• 9 months ago

Well I guess that could help, but only on Windows, since it's the only OS which follows printer "installation" flow for driverless printers.

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.

gerdesj• 9 months ago

"Since modern DHCP servers ping check an ip before they assign it,"

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.

AceJohnny2• 9 months ago

Very tangential, but I want to put what I learned down somewhere:

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

EvanAnderson• 9 months ago

Reading over that made me realize I've run into the Ubiquiti hostapd bug but didn't know what it was. I had problems with DHCP and ARP in a couple different Customer environments. The symptoms in the linked Reddit thread[0] match up with what I was seeing. Wild.

[0] https://old.reddit.com/r/Ubiquiti/comments/mlit54/problems_w...

donmcronald• 9 months ago

I have a Brother printer that doesn’t work when it connects to a U7 Pro. It works ok with other UniFi APs. It’s not too surprising though. The U7 Pro is a lemon.

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

Related Stories