I am going to upgrade production AP to MR 26.6.1 stable release. Are there any known bugs that I should know about?
Solved! Go to Solution.
Contrary to the reports of others:
26.6.1 still has an MR32 bug in it that prevents us from upgrading. It's completely unstable/unusable for us.
We weren't given a number but were told that it's a known issue.
The network is unusable when connected to an MR32. A continuous ping of the local gateway from a device associated to an affected AP shows a pattern of: no responses and high 20 second response times that get shorter and then stop. Rinse. Repeat.
@randhall That's worrying. I was all set to upgrade our estate this coming week, starting with a small group of AP's, but will hold off until I hear the outcome of your problem. I'll do some testing in our lab setup on a MR32 here to see if I can replicate the issue.
Please keep us updated
Is this the only device connected to the AP? Is the device connecting via 2.4 or 5? There are quite a few of other factors that could be contributing to performance like this. Did this behavior start occurring on the 26.6.1 release?
Have you reached out to support on this as well?
I'll try the ping test in one of ours, we don't appear to have that sort of issue and out of the 20 we have, two of them consistently have 15+ clients connected. One of those is in an employee lounge where there is a huge transient population and the other has about 7 continuosly connected static iPads that run an app used to monitor activity. If it was experiencing that sort of drop out for TCP traffic we'd definitely know!
We weren't given a bug number by support but they said it was a known issue. It extends a couple of revs back. Only on MR32s (150) out of our 750+ total.
Excellent idea with the lab ..
I always do/recommend this in larger environment (pre-prod setup).
I don't have the MR32, so I did not get any indications of instability ..
Worrying indeed, could You post your responses from the Support case, when things turn brigther ?
In any case: Good luck tracking down the issue ..
With highest regards
When I upgraded to it, my nest cameras started dropping on/off the wifi. Few times a day. After 4 days of this I reverted back to the latest 25.13 and nest cams have been solid. Tried going back to 26.6.1 again and they dropped off/on again. Went back to 25.13 - solid nest cams. ¯\_(ツ)_/¯
@randhallI have finally tested one of our MR32s on 26.6.1 and I get no packet loss so there must be something else that is different between our networks that causes the issue you see. Our MR32s are plugged into Cisco 3850 switches and us them as the default gateway.
I have a customer with a bunch of MR32 that is experiencing wifi drops since the upgrade to 26.6.1 and some clients no longer able to communicate over a mesh link with MR32's.
I haven't had a chance to look deep though but since it's really since the auto upgrade to 26.6.1 we have to think it's a likely issue with the firmware.
I have some MR33 and a lot of MR42 running the 26.6.1 and they are behaving nicely as of now ..
(but then again, seen in the current light of activity during lockdowns it might not be the correct picture)
I have a physical intervention tomorrow where MR32's are potentially misbehaving after this update.
I'll do a few packet captures while trying to replicate the issue.
One of the things was that the closest AP was not accepting 5GHz connections while sending the SSID but after a reboot it did again. So the clients were all connected to 2.4GHz on another AP nearby but way lower RSSI.
Also some disconnect issues. So I hope I can replicate those.
Alright, I'm onsite now and I'm finding this issue:
The site has a bunch of AP's: MR32, MR33, MR72, MR74.
The issue is that on a few of the MR32's since the update the 5 GHz radio suddenly stops working.
After rebooting the AP the 5 GHz once again sends out RF energy and beacons. But after a few days (6 to 7), it stops again.
Other AP's who aren't used that much also have the issue but on another time.
I'm testing this with the Ekahau sidekick.
Time to give Support a call.
I'll follow closely .. Thanx for posting live ..
Crossing my fingers so You will get an answer, that clears up mysteries and uncertainty !!
I spent quite a while at the phone with the support agent. As usual they really want as detailed information as possible. And when I got disconnected from the phone due to an area at the customer with bad reception they called me back but the audio was choppy.
Anyway now the observed behavior:
- Some MR32's just stop transmitting anything on the 5 GHz band after 6 to 7 days of operation.
- I did notice a possible frame from an AP but it didn't contain any L2 info only L1 and it had to come from that AP since the channel and RSSI matched. But those frames are far apart.
- There were no special events in the eventlog. You could only notice 802.11 association frames on channels 1 or 6 or 11 from a certain point on.
- During the talk with support we changed RF profiles on two of the not working AP's: one of these remained silent on 5GHz, the other started transmitting again.
- After changing it a few times on the AP that kept not working I manually changed the channel and only then the radio came back.
- So even when measuring on channel 40 and not finding any noise/interference I decided to put the AP back on channel 40 where it supposed to have been while it didn't transmit. But then it just moved to ch 40 and transmitted just fine. That coupled with this behavior since software update, I'm quite sure this is a software issue on the MR32 since 26.6.1.
This sounds similar to something we've seen on MR16s & MR18s. It has some correlation with channel changes. Take a look at the RF tab on the AP. You'll likely see a normal traffic pattern followed by an AutoRF/DFS channel change followed by a flatline during which no connections will be made. There's definitely some sort of problem handling channel changes gracefully.
I haven't noticed that particular circumstance.
Around the timestamps I noticed when no more clients were associating to the AP on 5 GHz channels no DFS/channel chg events happened.
The only channel changes I did notice were on the 2.4 GHz band but not at the time of the last association and disconnect.
One of the AP's showed that when the last client on 5 GHz connected, it was deauth'd after a few minutes and that client reconnected on 2.4GHz on the same AP. So the bandsteering wasn't enforcing it either.
I only had some issues with 2,4 clients like wireless printers and Apple Watch which ask me about the password few times. But after few days ago now its working fine. Maybe beacause i have many networks around my location, so its interferences in 2,4 GHz. On 5 GHz i didn't notice any issues.
I'm following closely!
We see these gaps also (mainly reported because video streaming is popular at the moment) but Wifi coverage is very flexible at this customer, so no business affected ..
Will love to hear what engineering has to say (and how they will discover what's wrong) ..