ePMP 4k - 5.11+ FW Randomly drops SMs

Products ePMP
1

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)

AP Log

2026.07.07 11:22:38 -05:00 Herr-ePMP-6N kernel: [1077650.506488] SM[bc:e6:7c:93:49:17] aid=1 peer=19 associated with AP
2026.07.07 11:22:29 -05:00 Herr-ePMP-6N kernel: [1077640.992224] SM[bc:e6:7c:93:4a:b5] aid=5 peer=18 associated with AP
2026.07.07 11:22:26 -05:00 Herr-ePMP-6N kernel: [1077638.082365] SM[bc:e6:7c:93:4a:dd] aid=4 peer=17 associated with AP
2026.07.07 11:21:59 -05:00 Herr-ePMP-6N kernel: [1077611.412435] SM[bc:e6:7c:93:46:f3] aid=2 peer=16 associated with AP
2026.07.07 11:21:53 -05:00 Herr-ePMP-6N kernel: [1077604.924677] SM[bc:e6:7c:93:4a:dd] aid=4 peer=7 disassociated. Reason: 48 (COMMUNICATION LOST)
2026.07.07 11:21:53 -05:00 Herr-ePMP-6N kernel: [1077604.919664] SM[bc:e6:7c:93:49:17] aid=1 peer=2 disassociated. Reason: 48 (COMMUNICATION LOST)
2026.07.07 11:21:51 -05:00 Herr-ePMP-6N kernel: [1077603.710427] SM[bc:e6:7c:93:4a:b5] aid=5 peer=11 disassociated. Reason: 48 (COMMUNICATION LOST)
2026.07.07 11:21:51 -05:00 Herr-ePMP-6N kernel: [1077603.709620] SM[bc:e6:7c:93:46:f3] aid=2 peer=3 disassociated. Reason: 48 (COMMUNICATION LOST)

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.

2

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.

3

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?

4

What is the reason listed in the AP or SM logs for your disconnects? Mine are specifically Reason 32 No allocation on AP.

5 
I'm getting reason 48 and no allocation during 400 TDD frames.

2026.07.19 09:28:31 kernel: [104108.577067] SM[bc:e6:7c:90:6d:a1] aid=10 peer=223 disassociated. Reason: 48 (COMMUNICATION LOST)
2026.07.19 09:28:31 kernel: [104108.576114] ERROR: STA aid=10 peer=223 disassociated from AP. [bc:e6:7c:90:6d:a1] had no allocation during 400 TDD frames
6

Hi @NU2theGame,

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:

  1. 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.
  2. 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.

7

The mir limits are set to a minimum of 50 Mbps

8

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.

9

@Vladyslav_Sapeha I know I got a ticket open on the Reason 32. Any progress on that front? Ticket 487199

10

Hello @terintamel,

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!

11

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.