So, it's looking like my MR34s are doing a really poor job of bandwidth steering. Devices that should be connecting to the 5ghz band are sitting on the 2.4ghz band, even if I'm right under an AP. This is not good because the 2.4ghz band on these MR34s can be worse than a dial-up modem for speed.
Anybody else having this issue with the bandwidth steering? I feel that it started around the same time the Meraki added the Radio setting/RF profiles to the dashboard. I've tried removing the defaults and setting up my own specific rules, but that hasn't helped.
This is more a reflection of the device listening to the beacons, then the AP.
I tend to disable the 2.4Ghz band where I can.
Too many devices (like 3-4 year old Dell Laptops) were shipped with 2.4Ghz only wi-fi cards so I cannot turn off 2.4Ghz.
But now I've got an even worse problem.
Even on the 5Ghz band, the MR34 is junk. Like really bad test results for bandwidth speed in comparison to an MR52. They never used to have this issue, so I think the latest firmware, as per usual with Meraki, broke something. The MR34 would not broadcast at 80Mhz. It routinely fails to reach or maintain 75+Mbps speed between laptop and MR34. It routinely fails to even break 50Mbps in an online speed test. (Don't even get me started on the 30Mbps it can barely hit in 2.4Ghz mode).
The MR52 hit 240Mbps at 80Mhz broadcast. It consistently hit 150+Mbps at the 40Mhz rate. I used the exact same single network cable in the same room and position for testing.
How far can I step the firmware back?
You can roll the firmware back under Organization/Firmware Upgrades (as long as it was not too long ago). There is a curly arrow on the right you can click on.
Personally - I've given up trying to use 80Mhz wide channels - on both Cisco Meraki and Cisco Enterprise. Trying to get such a large block with no RF issues can be challenging. I just use "Auto" now, and the system allocates as much bandwidth as it thinks it can get to work.
You mention old clients - you only need just one client to try and connect using 802.11b and the through for everyone sinks. Typically I made the minimum connect rate 12Mb/s to forcibly prevent these clients (I would rather have better performance).
25.11 is a solid firmware version. I don't remember the stats for this version any more, but globally is by far the most used version of code for the access points.
I should also point out that the MR5x series is a 4x4 MIMO radio. Simply put, it is a higher spec radio.
ps. There is no MR34. Perhaps you have an MR33?
@PhilipDAth I beg to differ, and the 138 MR34s that are in place across my sites would like to have a word with you about saying they don't exist.
Maybe that's the issue? They're having an existential crisis?
Trust me. These MR34s have a MAJOR issue, and it wasn't the case a few months back. Yes, I know the MR52s are 4x4, but the MR34s are 3x3 and should clearly be able to consistently handle 100Mbps speeds, especially with almost zero load on the network (summer break). The fact that they can barely even reach 75Mbps in the local page when running device to WAP testing is an absolute travesty.
My testing yesterday had the minimum bitrate floor at 18, so zero chance for any 802.11b traffic, but again the campus is empty. Later today I'm going to test one of the MR42s that I have for comparison as well. Those are 3x3, so at least it'll be closer to apple-to-apple. I'll also take an MR34 and test at the campus that the MR42s are at, and do a same line test.
I have a few hundred MR34's in production (generally in networks with MR32's) and do not see this issue on earlier 25.X firmware. Perhaps the 34's never made it down to NZ @PhilipDAth? We're running 25.3 today as 25.9 (and later) has a blocking bug for us with Windows clients randomly being disconnected from the network.
The only thing I will note is that we generally use a significantly higher minimum bitrate (because we go for high density with an AP in every room) and auto channel width for 5GHz. You should easily be able to hit 300Mb+ on an unloaded MR34 with a client that can handle that type of throughput (2016/2017 MacBook Pro's are great for testing VHT WiFi).