Blame Wi-Fi drivers for printer (mDNS) discovery issues
Have you ever heard how unreliable printer connection over Wi-Fi is, or maybe faced the issue yourself? The printer works most of the time, but when you need it most, it stops?..
Or maybe your phone could not find a Chromecast on your network even if it was working 10 minutes ago?
I spent some time debugging mysterious issues with auto-discovery protocols over Wi-Fi last year.
Different setups, different Wi-Fi routers, different software, but the same core issue: on a scale, everything which uses auto-discovery doesn't seem to be reliable enough and breaks at random times.
mDNS (and DNS-SD)
Many modern hardware incorporates one of network zero-configuration protocols, which simplifies discovery process and decrease first installation burden.
Nowadays most widely used protocol is mDNS (a.k.a Bonjour), which was initially created by Apple and used by printers, Apple AirPlay/HomeKit, Google Chromecast, Sonos speakers, Home Assistant and IoT hardware.
mDNS (Multicast DNS) is very similar to the regular DNS protocol. It transmits basically the same data using the same packet types, and doesn't even bring any new features compared to DNS.
However, it's also very different:
- Uses Multicast UDP network packets with hard-coded destination (group)
224.0.0.251/ff02::fband port5353 - Does not require any central entity or centralized domain management
- Usually handles only
*.localdomain queries - Resolves name conflicts by automatically renaming the device/host is another one with the same name already presents in the network
Similar to DNS, mDNS publishes and resolves hostnames to IP addresses, which allows one to connect to the device using its user-friendly hostname instead of IP address.
But how does my PC knows the type of the device, that the printer is indeed the printer? That's where DNS-SD comes into play.
DNS-SD (DNS Service Discovery) is an mDNS extension, which defines common service types to well-known DNS record names.
For example, for Internet Printing Protocol (IPP) printers it's _ipp._tcp.local:
On Linux, avahi-browse allows to query mDNS/DNS-SD records:
$ avahi-browse -t _ipp._tcp
+ enp86s0 IPv6 Canon1120 @ uowprint _ipp._tcp local
+ enp86s0 IPv6 hp1000 @ uowprint _ipp._tcp local
+ enp86s0 IPv4 Canon1120 @ uowprint _ipp._tcp local
+ enp86s0 IPv4 hp1000 @ uowprint _ipp._tcp local
It works, great!
Let's take a look at cases when it does not.
Bug #1: Intel Wi-Fi cards
Popular Intel AX201, AX210, AX211 and older cards like AC8260 are affected by Windows driver bug which prevents mDNS from working after PC suspend-resume cycle.
It's known since at least 2020, and is not fixed as of October 2025.
How to reproduce:
- Ensure you have mDNS device on the network, and it's responding correctly:
runResolve-DnsName name-of-that-devicein PowerShell and verify that it resolves - Put the laptop to sleep
- Wake it up
- Repeat step 2
If mDNS continues to work—you're lucky, but the issue could also be triggered by switching the adapter off and on again:
- Ensure you have mDNS device on the network, and it's responding correctly:
runResolve-DnsName name-of-that-devicein PowerShell and verify that it resolves - Turn off Wi-Fi using the "Wi-Fi" button in Windows (don't disconnect from your current network, but turn off the adapter itself)
- Put the laptop to sleep
- Wake it up
- Turn on Wi-Fi and connect to the network
- Repeat step 2
Result
After the sleep-wake cycle, no mDNS queries work.
Relevant topics on Intel community forum:
- Intel WiFi chips are blocking multicast after resuming from airplane mode etc.
- Multicast messages not always received over Wifi with AC8260
- mDNS packets not received on Intel Wi-Fi chips
Tested with Intel AX211 (23.110.0.5 driver, 22.240.0.6 driver), AX201 (22.40.0.7 driver).
Bug #2: Qualcomm Wi-Fi cards
Qualcomm QCA6174 card found in Microsoft Surface Go (gen. 1) tablet exhibit similar bug as Intel, with similar symptoms, but it could not be easily reproduced (not by suspend-resume cycle).
Unfortunately, this card is not supported directly by Qualcomm, and Microsoft no longer supports Surface Go tablet, that's why most probably it won't be ever fixed.
Affected driver version: 12.0.0.1159.
Bug #3: Mediatek MT6572M
This is a very old (circa 2009) smartphone system-on-chip with 2-core ARMv7, which back in the day was used in countless smartphones, as well as in Orange Pi 3G-IoT-A single-board computer.
I used Orange Pi as a print server with CUPS software, which shares the USB-connected printer over AirPrint/Mopria. This feature requires mDNS and DNS-SD support.
As it turned out, the Wi-Fi chip integrated into SoC incorrectly handles "full" (not mixed) WPA2 encryption which uses AES (CCMP) cipher for multicast packets.
Switching the network to "mixed mode" (WPA/WPA2) fixed the issue: this mode uses TKIP cipher for multicast packets, which apparently doesn't trigger the bug.
Bug #4: Ubiquiti Access Points
Reddit user known as sharhalakis spent 1.5 years debugging Multicast issues on Ubiquiti APs
Problems with broadcast/multicast traffic on UAP [Reproduced and Solved]
The problem that Ubiquiti APs have is that they occasionally use the wrong key index number. E.g:
- A station connects and receives the GTK with index number 1 from the AP
- The AP then sends broadcast frames using index number 2
This happens in a number of ways:
- It can happen from the first moment, when a station joins
- It can start happening after a rekeying event
- It can start happening to existing stations even if there wasn't a rekeying event
The author proposed several workarounds for the issue, and the bug was finally fixed in 5.43.34.12682 firmware update.
Why mDNS issues are so common for wireless networks
Auto-discovery protocols (mDNS/DNS-SD) are using multicast traffic type, which require special handling by itself, and additional special care to work over Wi-Fi.
Group Temporal Key
Wi-Fi uses two types of keys for different type of situations:
- Pairwise Temporal Key (PTK) is a unique client key, used for regular Unicast, and for Broadcast and Multicast from Wi-Fi client to AP (or wired LAN host)
- Group Temporal Key (GTK) is a shared key used for Broadcast and Multicast from AP (or wired LAN host) to Wi-Fi client
See the issue already?
Classic internet protocols usually use broadcast and multicast only to announce client themselves to the server, which in Wi-Fi case uses PTK, not GTK.
Take DHCP for example:
- Broadcast is used for DHCP Discover: (Client (PTK) → AP)
- AP replies with DHCP Offer unicast packet: (AP (PTK) → Client)
- DHCP Request and DHCP Ack packets are unicast and use PTK
However mDNS replies with multicast packets, contrary to classic DNS, for everyone on the network to learn the IP address of the device, even if they did not ask for it.
- Multicast is used for mDNS Standard Query: (Client (PTK) → AP)
- Multicast is used for mDNS Query Response: (AP (GTK) → Client) ← the bug is here!
As most protocols use Multicast only from Client to AP (which uses PTK) but not vice versa, GTK issues are not trivial to spot and debug. Everything mostly still just works, but not mDNS!
GTK is also frequently rotated (re-keyed), usually each hour, 6 hours, 24 hours, or other "round" time.
I recommend reading SuperUser answer by Spiff if you want to learn more.
Group join
To receive multicast traffic, the application should join the "multicast group" first by using Internet Group Management Protocol (IGMP)
protocol. In case of mDNS, this group is a well-known 224.0.0.251 IP address.
However, multicast-over-Wi-Fi is a special case here as well. Since AP → Client multicast is essentially a broadcast directed to every client of the AP, it's technically not required to join the group to receive the data. Despite that, the client's Wi-Fi driver itself usually drops multicast packets received from non-joined groups, mostly for power-saving reasons.
The "group join" packet has its timeout, after which it should be sent again to rejoin the group.
This is also the case which I've seen to be handled incorrectly in the Wi-Fi driver.
VPN / Multiple interfaces (multihoming)
Badly written applications could send mDNS packets only to the main network interface ("default route" interface), which would break LAN discovery if VPN with default route is connected.
Unfortunately, this is a very common bug in both client applications (one example is KDE Connect), and VPN applications, which don't apply workarounds to prevent LAN Multicast/Broadcast to be routed to the tunnel.
Possible solutions
In short, if your printer, Chromecast or other mDNS device is connected to the network all the time (and you can see its IP address in the router's web interface, it could be pinged), but could be discovered on the network only for precisely 1 hour or 1 day or other round time, this is most likely a multicast issue.
Try:
- Checking your router for multicast filtering option (disable it), as well as IGMP Snooping (disabling it will forward all multicast traffic without need for the device to join the multicast group first)
- Switching your Wi-Fi security mode to "WPA-PSK/WPA2-PSK Mixed"—that will force using TKIP encryption for Group Key (GTK), which is more compatible with some devices (as seen in Bug #3)
- Disabling GTK (Group Key) rekeying completely (multicast and broadcast data will be encrypted with a static key, less secure)
- Creating dedicated (but not isolated) Wi-Fi network for printer only