Re: Intel WiFi chips are blocking multicast after resuming from airplane mode etc.

GRolf · ‎05-20-2020

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 224.0.0.251. 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 20.70.16.4. 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 224.0.0.251 which is blocked. also did tests with multicast senders/receivers and verified that at least 224.0.0.3 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.

Maria_R_Intel · ‎05-22-2020

Hello GRolf,

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:

-BIOS:

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"

-DRIVERS:

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.

Best regards,

Maria R.

Intel Customer Support Technician

GRolf · ‎05-25-2020

Hi again, I have now tried updating to latest bios and latest driver of everything (except the graphics driver version x.x.x.7985 which says it installs correctly but after every reboot, Intel DSA tool says it wants to be installed again...). The multicast problem remains and I have uploaded two WireShark captures to Dropbox. One when it works, and the other when it fails after toggling flight mode on/off. I will continue and test with debug driver and come back with the result of that. Will also try to get a list of all types of hardware where we have seen the same issue. Best regards Göran Rolfsson, PIXY AB Den 2020-05-23 kl. 05:42, skrev Intel Customer Support:

GRolf · ‎05-25-2020

Hi, I have now collected logs and uploaded to dropbox, when using the debug WiFi drivers. Hope that helps you out. Should also be easy to reproduce the problem yourself by just toggling flight mode, and using a multicast test program, e.g. MCastTest.exe. I am trying to collect info about some of the machine types we have seen the issue on, but at least got confirmed that it's visible also with the AC8625 chip. /Göran Den 2020-05-25 kl. 08:45, skrev Göran Rolfsson:

GRolf · ‎05-27-2020

Sure, my company name is PIXY AB, but more interesting is probably my customer which I'm consulting for. It's a much bigger company called Laerdal Medical AS, producing medical simulators among other things (and have delivered thousands of computers with these Intel chips in them to their customers). Regarding the test, yes step 3 is enter flight mode, exit flight mode and connect to the WiFi again. Alternative test is to switch between different wifi networks. In my case I can switch between the 2.4GHz and 5GHz net provided by my AP. Traffic will stop once you have switched network. At step 4 I guess you can also try to stop/start the receiver to really make sure it's not receiving anything Another test would be if you check dns-sd traffic, but then you have to have some software looking for devices. E.g. a Chromecast configured or scanning for printers or similar. Happy bug hunting :-) Best regards Göran Rolfsson Den 2020-05-27 kl. 05:05, skrev Intel Customer Support:

GRolf · ‎06-02-2020

Hi, any progress with this issue? Have you been able to reproduce the problem? /Göran Den 2020-05-27 kl. 05:05, skrev Intel Customer Support:

GRolf · ‎06-17-2020

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?

LynnT_Intel · ‎06-20-2020

Hi Göran,

Thanks for the verification and the info. I'll notify you when I receive the update from the developer team

Best Regards,

Lynn

RLudwig · ‎01-23-2021

@Maria_R_Intel @LynnT_Intel - Resurrecting this thread here as I'm seeing the same issue on Intel's latest driver. Was this ever fixed?

Win10 Version: 10.0.19042 Build 19042

Intel Model: AX200 || Driver version: 22.20.0.6

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)

RLudwig · ‎01-24-2021

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?

LynnT_Intel · ‎01-25-2021

Hi RLudwig,

Thank you for reaching out to us.

We'll send you an email requesting private information and start internal support.

Best Regards,

Lynn

RLudwig · ‎01-25-2021

Thanks Lynn,

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.

Thanks!

Ryan

weyou · ‎06-20-2021

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: 20.70.19.1

OS: Windows 1909