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:
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.
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?
Don’t think I’ve tried those particular settings yet. Those are on the network card?
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.
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?
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.
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...
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.
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.)
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)
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.
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.
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?