All computers in our company with Intel WiFi chips are seeing dns-sd/mdns issues after network changes.
This is very easy to reproduce. Start with having Wireshark capturing on the WiFi. Filter on mdns to see what is received for the destination address 126.96.36.199. Normally one will see some answers to standard queries coming in. Then set the Wifi in flight mode, out of flight mode, and connect to the WiFi again. Check wireshark again. Suddenly will you only see mdns packages from you own computer. Using wireshark on another computer for same wifi network can show queries from my computer, as well as many answers from all network systems. On my own computer are only the sent queries seen.
The only way to resolve this is by disable and enable the network interface. That's not an OK solution since it requires elevation.
Windows 10 is up to date, my chip is AC 8260 with Intels latest driver 188.8.131.52. I'm attaching result from running SSU.exe, but want to emphasize that this same issue is seen on all computers with Intel WiFi we tested with. Same problem also seen when e.g. getting out of and back into wifi range.
We know that we can get e.g. Google Chrome MDNS Broswer App to work during these circumstances, but that is because they use a non standard source port for their queries, resulting in the answers being returned with Unicast instead of Multicast, and that works. It's also not only 184.108.40.206 which is blocked. also did tests with multicast senders/receivers and verified that at least 220.127.116.11 also stops working. So I guess all (most) incoming multicast is blocked.
Using another source port for dns-sd/mdns isn't a viable solution either since it will be blocked by corporate routers if not using standard ports...
When testing with computers with wifi from other manufacturers, then these problems aren't seen.
This issue is causing major problems for many of our customers. Please fix.
Thank you for posting on the Intel* Community Forums.
Please provide me with the following information:
- How many units have been affected by this behavior? Please, provide the specific model of the units or wireless cards
I can notice with the report you sent, using the Intel* NUC6i7KYB, that you are not using the latest recommended drivers for the NUC nor the Latest BIOS.
Please follow the next steps:
According to the report you are using the BIOS version 0034, the latest version available on our website is the 0067.
- Go to the following link to find the version 0067. https://downloadcenter.intel.com/download/29503/BIOS-Update-KYSKLi70-86A-?product=89187
- We recommend downloading the bio version.
- You can find all the steps to follow on the Release Notes, in the document "read me"
I recommend you using the Intel® DSA tool, The Intel® Driver & Support Assistant keeps your system up-to-date by providing tailored support and hassle-free updates for most of your Intel hardware.
- Download the Intel® DSA tool.
- Scan your system to find the most updated drivers.
- Perform the necessary updates, but we do not recommend to use this tool to perform the BIOS update.
Once you have the system up to date, try to replicate the behavior again and let me know the outcome.
If the issue persisted once you finish the steps and the updates, provide me with a new report using the Intel® System Support Utility report in .txt format (once the scan is done, click the menu where it says Summary View to change to Detailed View, click Next and click Save.
Intel Customer Support Technician
Thanks for the Skype meeting, but I did some more thinking and testing. Your suggestion to detect network changes in the software and "re-register" multicast addresses will not work. It doesn't help to restart our program, or MCastTest.exe. It will still fail until you reset the network interface itself (tcp stack?). I don't know of any other way to "re-register" than create and bind new sockets.
I also verified that this issue of blocking multicast occurs if you just disconnect from the SSID and then connect back to the same SSID again. Most likely also if you loose connection by getting out of range and then back into range again.
Those cases don't sound like they can be explained in exactly the same way as when toggling flight mode (os not providing list of multicast addresses when enabling again)? Or is it equivalent?
Win10 Version: 10.0.19042 Build 19042
Intel Model: AX200 || Driver version: 18.104.22.168
After "disabling" then re-enabling WiFi from the Windows taskbar (which just puts it into sleep mode and doesn't disable the interface itself) no mDNS responses are seen. The workaround suggested in this thread (disabling then re-enabling the interface from Device Manager) resolves the issue.
I believe that once the NIC/Windows is in this deprecated state the issue lies with the NIC/Windows not properly using IGMP to indicate the client is interested in receiving traffic from the mDNS multicast groups.
IGMP is used by networking hardware (APs/Switches) to figure out which clients are interested in the multicast traffic being broadcasted.
If the AP that sits between the clients does not see the IGMP join message coming from the client it won't forward multicast traffic for that IGMP group to that client, since it doesn't know that the client is "interested" in receiving that multicast traffic.
If a switch that sites between two APs never receives an IGMP join message on the switchport the AP with the windows client is connected to, it will not forward multicast traffic from other clients out of that switchport.
This is assuming that IGMP snooping is enabled, which it generally is by default on modern networking hardware. The alternative is flooding multicast out of all ports, which should be avoided if possible.
Working State Example - Same AP: My windows client wants to cast to a Google cast device. Both are connected to the same AP. Both send an IGMP Join message to the AP informing it that both are interested in the mDNS multicast traffic group (224.0. 0.251). The AP then forwards the mDNS multicast traffic between the two clients.
Non-working State Example - Same AP: My windows client wants to cast to a Google cast device. Both are connected to the same AP but only my Google cast device send an IGMP join message for the multicast group. If this occurs then the AP will only forward the windows client multicast mDNS traffic to the Google cast device. The AP will not forward the google cast device mDNS traffic to the windows client as no IGMP join message was sent from the windows client, so the AP doesn't think the windows client is interested in receiving the google cast mDNS traffic.
Non-working State Example - Different APs with wired uplinks on same switch:: The same issue will be seen if you have multiple APs connected through switches that are performing IGMP snooping.
If only my windows client is connected to AP A through switchport 1 and my google cast device is connected to AP B through switchport 2. The switch will not forward mDNS traffic for the mDNS multicast group from switchport 2 to switchport 1 as it never received an IGMP Join message on switchport 1 indicating there was a client interested in receiving mDNS multicast traffic.
If you take a packet capture on switchport 1 you will only see mDNS multicast traffic coming from the windows client. If you take a packet capture on switchport 2 you will see mDNS multicast traffic from both the windows client and the google cast device.
I can back this up with packet captures taken on APs and switchports along with Intel System scans (I'd prefer not to post them publicly)
Did some more digging into this.
So the NIC/Windows does actually send IGMP join messages after WiFi is toggled from the Windows taskbar.
The biggest difference between toggling it from the taskbar and disabling/re-enabling from device manager is that the IGMP version reverts to v2.
- When WiFi is toggled off/on from the windows taskbar the client sends out IGMP joins using IGMPv2.
- No mDNS responses from other clients are seen. Possibly a bug with my networking hardware regarding IGMP snooping IGMPv2 packets.
- When the WiFi interface is disabled/re-enabled from device manager, the client sends out IGMP joins using IGMPv3
- mDNS responses are seen from other clients
My biggest question right now is, Why does toggling WiFi off then on from the Windows taskbar cause the NIC/Windows to send out IGMP packets using IGMPv2 instead of IGMPv3?
I'm not sure the IGMP version even matters. Though it might be worth looking into internally as to why this changes.
I took monitor mode captures from a separate laptop on a new unencrypted SSID. I can see the AP sending the mDNS traffic to my Windows PC/Intel NIC but I never see the mDNS traffic in the client-side packet capture. Even if I completely disable the windows firewall
Once the Windows/Intel client is in the deprecated state, mDNS traffic is being dropped somewhere between the Intel NIC and Windows itself. I can't say where exactly but I can definitely verify mDNS responses from other clients are seen in the wireless spectrum heading from my AP to the MAC address of my intel NIC. Where this mDNS traffic goes after the Intel NIC receives it, I have no clue.
I'll await your email so I can provide more data.
Is there any update for this issue. I come across the same issue on Wireless-AC8265.
Just like @GRolf descibed, after switching the airport mode or reconnect the ap, the wireless card cannot receive the IGMP query sent by my router. The IGMP query can be captured by Wireshark from another PC. This issue can be recovered by disable and enable the WiFi interface.
Wireless-AC8265, Firmware: 22.214.171.124
OS: Windows 1909