Intermittent issue between Meraki AP's (MR52/53s) and Intel Dual Band wireless cards

[londoner2019]

Hello all,

Hoping and desperate for help!

We have a Meraki estate with a number of WAPs deployed which are a mix of Mr52/53s.

We have recently been alerted to an issue impacting some Windows 10 machines with Intel Dual Band network adaptors. These users will be working and then intermittently throughout the day, their connection will change to "Limited, no internet". the only remedy is to disconnect and reconnect.

The interesting thing here is the Windows event log becomes flooded with network card errors:

Intel(R) Dual Band Wireless-AC 8275 : Has determined that the network adapter is not functioning properly.

We have tried a host of different things:

• Updating network card drivers to latest
• Rolling back network cards to older version
• Changing preferred band to 5ghz
• Setting up new SSID which is purely 5ghz and lowest bitrate

None of these things have fixed the issue. The other interesting point is I have had the issue myself whilst on our corporate network, however I have not noticed the issue on any other network (e.g. home) - so we know this only happens for Intel dual band cards and whilst on a Meraki AP. Other clients on other types of wireless cards (example: Killer Wireless on a Dell XPS) have not reported the same issue.

Appreciate ANY thoughts/suggestions here - reaching a dead end with Meraki and Intel support and now considering replacing the network cards entirely. 

[PhilipDAth]

Have you tried uninstalling the driver and using the generic Windows driver? 

I doubt it will help but you are you using a recent MR firmware image? 

[londoner2019]

Yep have tried the generic Intel driver if that’s what you mean?

Using latest stable MR firmware.

[ww]

any other settings you tryed?

802.11r and w disabled? wpa2-only?

[londoner2019]

Don’t think I’ve tried those particular settings yet. Those are on the network card? 

[ww]

on the ap. wireless》 access control

[londoner2019]

I can try this on the new SSID we setup. Could there be rationale for why only certain cards are affected in relation to these settings?

[Uberseehandel]

Has the MSS value been changed? (inadvertently).

You need to check it from client device, through all the network devices to the modem. Under certain circumstances, when an MSS value has been set too high, it effectively kills browsing, so it looks like no internet access.

[londoner2019]

Where is this setting changed pls? Apologies, not from a heavy networking background myself!

[BlakeRichardson]

@londoner2019 

What does the event log in your dashboard report?

What sort of authentication method are you using?

Have you tried rebooting the AP to see if the problem goes away?

Are the affected devices in the same area or spread out?

[londoner2019]

Hello.

meraki dashboard shows client left for unspecified reason..

authentication is WPA2-PSK

Affected devices can be anywhere within the building and on multiple APs. The only common denominator is the Intel card!  

Will try a reboot tonight to rule out although I read typically there’s rarely a need to manually reboot them. 

Thank you.

[jdsilva]

That wifi chipset sure sounds familiar... At my last job we had dell laptops with an intel AC-8something chipset in it, and it was utter garbage. The only way we could get rid of problems with it randomly disconnecting from the wifi (and then refusing to show the SSID for minutes after). 

Deskside never was able to solve the problem, but a few folks who had admin rights on their machines were able to install the official Intel drivers using some Intel hardware manager and that dramatically helped things. Since it wasn't a Dell sanctioned driver deskside refused to deploy it widely. 

I'm probably remembering some of this wrong...

[AjitKumar]

Hi 

I am not sure why but I will try the following scenarios.

1. Create a Test1 SSID. Keep it open (no password) and in Bridge Mode.

2. Create a Test2 SSID. Keep it open (no password) NAT Mode.

Could you please try latching to above SSIDs? and share your observations.

[cta102]

From previous strangeness with some Intel drivers I would ask if the issues are on APs which are using DFS channels.

I found that if you have certain Intel drivers, 5GHz DFS channels and hidden SSIDs the clients will never connect (the driver refuses to send probes on DFS channels.)

If you have visible SSIDs we got clients disconnecting, we found that the devices sometimes lost the ability to see the SSID broadcasts too.

So it may be an idea to disable the DFS channels and do a couple of tests as it's an easy test.

In the end Intel were pulled into the conference calls and they recommended a particular driver that improved the situation when the SSID was visible (however this was for one very specific handheld device.)

Side note:

In the past the EU introduced Listen Before Talk (LBT) rules for a lot of radio equipment which led to some issues about 3 years ago and I suspect the refusal to send probes to look for hidden SSIDs stems from that (and I suspect strange behaviour in their driver code date from that change)

[Uberseehandel]

The regulations with respect to the use of the 5 GHz spectrum and Dynamic Frequency Selection are clearly set out.

However, it is not unknown for WiFi systems which are conforming with the regulations with respect to DFS, TPC and CAC.

The end result is that, if using a DFS channel, then should a weather radar be detected, then the Wi-Fi devices concerned cease transmitting, switch to another channel, and listen without transmitting for up to 4 hours.

To most observers this looks like a "broken" WiFi.

The future can only get worse as the regulations envisage WiFi systems interacting with each other to optimise overall network utilisation and throughput.

[TechNicholas]

We have similar issues with these model access points. These are very unstable. We have the same setup in other buildings but with the 802.11ac models. We thought going to 802.11ax and disabling it would be good at first. Huge mistake 400 users always complaining of random issues is not a good thing. Cisco meraki should not of released these access points not having stable code. 

[DevinM]

We were having very similar issues with our AC8265 equipped laptops. I opened a ticket with Intel and they said that a release (around February) should help with this issue. We would have all of our laptops associated to the same APs drop off the network and require a reboot (as disabling and re-enabling the device requires admin privileges). Before we could start testing the new driver properly, though, we started our WFH efforts. 

Have you found any more stability in the later releases of the driver?

[colby_oc]

I worked with Dell as originally the issue presented the most for our XPS Dell laptops with different versions of that Killer Wifi card they have been using.  From my research this is an Intel based chip.  This is supported by my case with Dell and them providing me directly an intel driver.  Originally the drivers via the dell support page and such all showed as signed by Rivet or something like that, once I got this driver it shows as signed by Intel.  An Intel driver is what Windows 10 will install by default, but not what seemed to come with the Dell image.  That being said I did see improvements as that was the first angle of attack, but I firmly believe that the resolution I had was to alter the power settings for the radios and the channel width as the network I inherited had too many AP's too close together as it was very old Apple Base Stations that were replaced with these first gen Wifi6 devices.  I believe that a newer driver than what Dell provided me has been released as I just noticed when I went to look at the version on my machine that the driver version is now 21.110.1.1 (7/1/2020); I did not specifically install this and have Dell update utilities turned off so this likely came via Windows Update.  My Card is Killer Wifi 6 AX1650s.  I hope this is helpful.  Best of luck to you.

[redsector]

Maybe the same issue as described here:

https://community.meraki.com/t5/Wireless-LAN/poor-WLAN-quality-with-MR45/m-p/100512#M14855