I have just noticed this issue more and more as I have either added more SMs to AP running 5.11 or higher (including 5.12) or have updated APs from 5.10 to 5.11 or 5.12RC33.
At random times the AP will drop random amounts of SMs from the AP. Every time the issue is for the same reason
SM log
2026.07.07 11:22:29 -05:00 G3-Glendenning kernel: [952984.070509] SM associated with AP[bc:e6:7c:f0:3b:ee]
2026.07.07 11:21:52 -05:00 G3-Glendenning kernel: [952946.981919] SM disassociated from AP[bc:e6:7c:f0:3b:ee] F=6700 11axahe80. Reason: 32 (NO ALLOCATION ON AP)
I already have a ticket open, but has anyone else seen this issue? I first saw it when I took an AP from 5.10.1 to 5.11RC46 and the only fix was to roll back to 5.10.1. I waited for the 5.12 beta FW to see if this was fixed and it is not and started right back up again.
I then started checking closer other 5.11 and 5.12RC33 APs and found a several doing this now.
It also seems more prone to happen on APs that have are a synced pair on a tower doing back-to-back frequency reuse. However, since almost all of my APs except a few are all doing reuse, it could just be a coincidence.
But whatever is the cause does not happen on 5.10FW.
Also will mention it does not matter the SM FW version. I can have SMs running 5.10, 5.11 or 5.12 and they are fine as long as AP is on 5.10. It is when the AP is on 5.11 or higher that this issue appears.
I have an open ticket for my 4500 dropping all 20 sm’s several times a day, sometimes crashing. Different lengths of time. All were with 5.10 fw. I was told to upgrade to ePMP-AX-v5.12.0-RC35.img
I come here and see all the trouble with RC33 and I can’t even find RC35. I have upgraded all the sm’s to 5.11fw, but was waiting until the middle of the night to upgrade the 4500, hoping it would stop dropping and not wanting to cause it to purposely. The sm’s are a mix of 4525’s and 300-25’s. Now I’m afraid to upgrade the a/p to 5.11fw. Advice please?
Based on your description, this appears to be different from the original issue discussed in this thread. It is related to the UL MIR profile and falls into one of two known cases:
UL MIR limit below 5 Mbps - If your UL MIR limit is configured to less than 5 Mbps, please increase it to 5 Mbps or higher and monitor the link. This should resolve the issue. We are also planning to introduce a restriction in a future release that will prevent configuring the UL MIR limit below 5 Mbps, as lower values can lead to this behavior.
UL MIR limit of 5 Mbps or higher - If your UL MIR limit is already set to 5 Mbps or higher, this is a different issue that has been addressed in the latest 5.12.0 Release Candidates.
If your case matches the second scenario, please let me know and I can provide you with 5.12.0 RC35. Alternatively, if you already have a support ticket open, simply share the ticket ID with me and I will attach the firmware there.
In this case, the latest 5.12.0 Release Candidate should resolve the issue. We have already received positive feedback from customers who tested 5.12, confirming that the MIR-related issue has been resolved.
Alternatively, you can wait for the next stable firmware release.
If you prefer not to upgrade to a Release Candidate, the only available workaround at this time is to disable the MIR profile.
we have a potential fix for your type of issue. It is under testing now.
We will provide a build to try as soon as it ready.
It is not related to the original topic.
Thank you!
That is good news and hopefully it fixes the No allocation on AP issue as it is pretty bad on several of my AP that have moved from 5.10 to 5.11 or higher.
I hope this gets fixed, but at this point who knows.
Does anyone else see this issue on 5.11+FW if doing same tower frequency reuses on front to back 4600 APs?
You would have to look for SMs whose uptime is greater than their connection time and check the SM logs to look for Reason 32 disconnects. I would not really notice it if I did not see the AP charts for Registered SMs in cnMaestro showing the disconnections at random times.
To me it seems like some fundamental flaw with the 5.11+ branch when doing frequency reuse on the same tower as every single AP that I upgrade from 5.10 to 5.11 or higher starts having the Reason 32 issues.
Only APs on 5.12 that do not have this issue are ones running GPS sync but not sharing frequencies with other APs on the same tower.
Am I just odd with the 4600 APs and are most people instead using Flexible TDD and not reusing frequencies, because with how widespread it is in my network I would think anyone doing same tower reuse should be seeing this issue.