Windows 10 with Intel WLAN not joining multicast groups after wakeup, printers unusable

Hi !

I've been troubleshooting some printer discovery issues, for WSD devices (printers) discovered through DNS-SD on WLAN :

• some clients fail to discover the printer, it can be fixed by rebooting the machine, or by disabling/enabling the WLAN adapter
  
• the problem appears frequently, it looks like it can be caused by toggling airplane mode, suspending, and roaming through base stations for the same SSID
  
• it only happens on machines with Windows 10 and an Intel WLAN adapter
• even if the printer is already discovered, if the client has not joined the multicast group, it's unable to print (I suppose this is because Windows attempts to locate to device to determine if its address changed).
• Linux/Apple and non-Intel Windows clients have no problem at all discovering and using the printer
• printers are on a specific VLAN, clients are organized in specific VLANs, mDNS traffic is relayed by avahi-daemon

It looks like this problem is known :

The engineering team has investigated this multicast issue with Microsoft. Microsoft is aware there's an issue with the multicast address managed by the OS. The issue has been introduced together with Windows 10 (WDI arch for WiFi Drivers.) Any scenarios of WLAN reconnected (i.e. Airplane mode, roaming out and back into RF range, or disconnect and reconnect to the same SSID) and then the multicast packets might be affected by this issue. Currently this issue is expected to be fixed for Windows 10 Version 21H1.

However, upgrading to Windows 10 Version 21H1 did not fix the problem, so I'm asking here if anyone experienced the same problem and/or has found a nice workaround to make the clients able to discover the printers.

So far, I've thought of :

• hardcoding the SRV/TXT records of these printers in our DNS resolver (not ideal because the printers change often (yes..))
• writing my own mDNS proxy (currently the mDNS data is proxied through subnets by avahi-daemon), that would only reply in unicast (i'm not sure if Windows would accept these replies)
• writing a script to disable/enable the WLAN driver on each BSSID change and on wakeup, and deploy it to all the potentially affected clients
• sharing the printer on all VLANs through SMB (this is not ideal because some proprietary functions of the printer don't work when the printer is shared through SMB)

I'm a bit stuck, because this location hosts a "coworking" setup, where users come and go (often with multiple devices), there is no AD and so deploying scripts to all machines would be a lot of repetitive work. It looks like the best solution is to stick to hardcoded SRV/TXT records in our resolver, and update them whenever the printers change, but I wanted to ask if anyone sees a better solution, or if anyone knows of an upcoming fix for this problem.

Thanks a lot !