We have replaced our MR32 for a mix of MR42/MR52 and since this change, we can see that performance (bandwidth) slowly getting lower and lower and almost tend to less than 1 Mbps. Only a reboot of the device permit to have good performance back for some time.
We are observing this behavior in environment where there is multiple other SSIDs broadcasted by other third parties in the buildings next to us.
We are in 5GHz only, 40 Mhz width channel. The 5 Ghz Channels used are not overloaded in utilization by other third parties.
If i put a MR32 at the same place, same channels, i don't have the issue.
It's like MR42/MR52 have an issue when the environment is used a lot even if it is not on the channels we are using. And, a reboot solve the issue for some hours (and we keep the same channels, so it's not a question of channels overloaded).
We have open ticket to support but upgrading to last firmware does not help.
Thanks in advance.
Try setting the minimum connect speed to 12Mb/s (unless you are using something higher already). Perhaps legacy protocols are consuming a lot of airtime, or devices are holding onto APs some distance away.
Also note it takes 24 hours before the final channel plan and power levels gets put into affect. The APs slowly drift towards their final values.
If you do a speedtest between the AP and the user (using my.meraki.com) is the result also poor?
Are you using the 26.x firmware?
Thanks for your answer.
I am already with minimum connect speed 12 Mb/s.
When the problem occurs, the speedtest using my.meraki.com show a result between 0 and 1 Mbps. So users can't do anything in Wifi.
We are using the 26.6.1 firmware, we had the same issue in 25.13.
This behavior is seen only on MR42/MR52 access point. I don't have this issue with MR32 access point. Seems something related to MR42/MR52 model
My only way to solve it temporarily is to reboot the access point.
Also enable DFS channels unless you are near a radar user. Without DFS in Europe there are only two 5GHz channels, so the interference can slow them right down.
Thanks for your answers guys !
Regarding the channel utilization, it is always pretty fine on the channels used by the access points (40 Mhz), so it's seems not to be related to a high utilization of the channels currently in use by the access point itself.And if i replace the MR42 or MR52 with a MR32 with the same channels, i don't have the issue.
So it's seems related only to these 802.11ac wave 2 models and not especially if the channels used are highly used but also if all the channels around are high used (even if not overlapping with the channels currently in use).
I was not able to test many things since lockdown but i have seen that in the release notes of the 26.8 firmware, an issue fixed can correspond to my problems:
-> MR would get into a state where it would cease being able to TX frames reliably in environments with sustained high channel utilization (802.11ac Wave 2 MRs)
This corresponds to the fact that my issues are only seen on these MR42 and MR52 (802.11ac wave 2) and not on old MR32.
I will upgrade and check how it goes.
Did you ever make any headway with this issue?
We have a lot of MR42's and are now also seeing very poor performance with them until they are rebooted.
We have checked out the switching environment, check our WAN usage, and have gone over our RF profiles and cannot see the cause of the issues.
Like yourself, rebooting the AP returns it back to good performance, but with 180 across our site, doing this regularly with what is supposed to be enterprise hardware is not ideal!
We are running the latest firmware as well.
Hi @TASIS_IT , when you say the latest, can you be more specific, there is 27.6 (which I guess you mean), but others out there as well?
Yes, we are running 27.6, across all of our MR42's
Nothing else is currently available on the Merkai Portal.
Ok I have read through all the posts. Quick question What type of power are you hitting the APs with? If they are getting 802.3af power they will work but become way more persnickety and your dedicated scanning radio goes away and they become quite sticky from a channel standpoint. Also, the MR 32 is only capable of running the 26 family of FW.
Models with a dedicated scanning radio, such as the MR18/32/34/42/52/53/84, don't generate channel_scan events. They rely on the scanning radio to get the neighbor and channel utilization report on an ongoing basis.
In comparison, models without the dedicated scanning radio, such as the MR12/16/20/24/70, scan the whole spectrum every 2 hours when there are no clients associated. When low power mode is enabled the scanning radio function becomes disabled. Thus, not only are there no channel_scan events but AutoRF channel assignment can be negatively impacted.
We have had a very similar issue. Running approximately 60 MR52s across the enterprise. Tuning has been done manually for channels and power as found we could get a much better result than allowing the APs to manually complete this. Everything worked perfectly. my.meraki gave high download speeds consistently.
However after a few weeks to a month the usual report is poor performance and running a my.meraki speedtest which only tests bandwidth between the device and the AP shows a maximum speed of 20Mbs. We have tried to change the channels in use, power settings, channel width all to no avail. In some cases I have seen 0-1Mbs on the my.meraki test.
We have tried all the different Meraki firmware available and custom firmware, still to no avail. A ticket has been open with Meraki for months and still its in their "research and development section" with no solid answer forth coming.
I feel Meraki have really dropped the ball on this and they have had countless options to resolve it. I used to really believe in Meraki hardware, and while all devices have issues, the real key to customer service is how you deal with the problem. There is no way a retail shop would have got away with this fiasco.
We feel the Meraki devices have a hardware issue as I never saw these issues on MR33s or lower spec devices in the past. The symptom is a memory leak.
We also have a few MR56s we have installed and touch wood after weeks and weeks we have no issues at all so far.
These are affecting not only one office but multiple offices around as well, so it is not an environmental issue either as all offices are different types, some very isolated to the outside world so no chance of interference.
I have spent hours and hours with Meraki on this one and sent countless packet capture logs we had to acquire an Apple MAC so we could obtain the details they required.
However as of today I have just had to reboot 6 APs to resolve issues for clients and suspect I will need to do more.
I have even raised to Meraki they need to own this issue and arrange a scheduled staggered reboot to provide a stop gap for us. However that was met with a solid no. Also there is no uptime in the dashboard which would help predict the issue and be proactive. Meraki have uptime on their dashboard but customers dont...go figure...
We have also been told we are the only ones experiencing this issue, which I know is not the case, however this is the most recent post I have seen concerning these devices.
All I can suggest is push Meraki hard. There are issues as we are experiencing them as well.
After weeks of sending screenshots and packet captures, I received this response from Meraki.
I have managed to find the issue that is causing the slow speed problem over time and after a reboot, the issue just goes.
Thanks to the packet capture taken from the working and AP and broken AP we identified that the issue was being caused because the client was sending aggregated frames and the AP wasn't.
Initially, both the AP and the client decide to send aggregate frames then all of a sudden after a while the AP doesn't send aggregate frames. Hence when you restart the AP it's all fresh and negotiates with the client again to send aggregate frames and the problem disappears.
We are currently working, on fixing this issue on a feature firmware release with our internal team, however, at this point, the problem is still premature and we are looking more into why the AP goes into stops sending aggregate frames. We know that the issue came around firmware version 27.x. Our internal team has asked me to ask you if you would be willing to test our beta MR 28.1 to see if the problem also persists on this firmware.
If you are willing to upgrade a couple of APs to MR28.1 to test let me know and I can arrange a session to ping the firmware on the APs you want to test on without having to upgrade the whole network to MR28.1
I am just waiting for our summer holidays to start and then I will be in a position to test MR28.1 on a few of the AP's.
I was pleased to see that they had identified a possible source of the issue since we have been chasing this for weeks and questioning ourselves whether it was something that we had done or something we were missing with the configuration of our network.
Hopefully, the issue is resolved in the next firmware update, but ill update you all again once i have tested further.
We are running 28.1 on most of our 100+ APs and at least 30 of those are MR42/52 models.
It has been stable so far, I'll let you know if we see any problems.
If that is the case, that sort of pokes a hole in the 'this issue was introduced with the 27.x train' comment
Yes exactly, my thoughts as well. We tried that in Feb. We have had our case open since last year.
Pretty poor to release a product with such a major bug. Ive had more luck out of a dlink AP.
How long have you been on 28.2? We moved to 28.1 and then 28.2
However I have just had exactly the same issue out of firmware version 28.1 . Slow speed between AP and client verifying with my.meraki.com and doing the speed test.
It was upgraded June 22nd, and today well its July 15th.
For an expensive AP it lasts less time than some cheap AP.
Also I have noticed on the latest MR56 after a few months its dumping clients off trying to connect it. There seems to be no light at the end of the tunnel at all with these APs.
Meraki, you really need to sort this out.