I have an SM periodically disassociating with this log entry:
Sep 9 18:50:38 ePMP-SM kernel: SM disassociated from AP[00:04:56:c8:c4:1d] F=5240 11naht20. Reason: 32 (NO ALLOCATION ON AP)
This is on an SM running v2.5 firmware connecting to a 5GHz connectorized non-sync AP in flexible frame mode.
What does "Reason: 32 (NO ALLOCATION ON AP)" mean?
Thanks, Chris
Hello uberdome,
That issue is related to internal AP transmission scheduling.
That issue will be fixed in next release.
Sorry for inconveniences.
Thank you.
Seen this message in 2.6.1, like several times an hour. The client disconnects.
Is it normal?
No, it is not normal.
Is SM disconnecting with that reason or you see that reason when it try to register back?
Thank you.
I am seeing this issue with 3.1 firmware on an ePMP2000. Do you know what might be causing it? Most of my subscibers are dropping off then reconnecting.
Are you using 2.5 ms frame?
Thank you.
Yes
Sorry for inconveniences.
It is known issue in 3.1 and we are working on fix now.
Please use 5ms frame as workaround.
Thank you.
It does it on 3.1 with 5.0ms also. Had one today do this.
Was on heer to find the reason why, guess I know now it is a issue.
4.4.2 Since then and...
Reason: 32 (NO ALLOCATION ON AP)
Any suggestions?
Hi,
Do you have pure .11n network?
Is the issue introduced with 2.5ms frame size?
Thank you.
What you mean by 802.11n?
We have epmp2000s on APs and mix of ubnt and force 180-190s.
The one with problem is actually Force 190.
Sep 2 01:02:38 ePMP1000_6421e0 kernel: [90163.190000] SM associated with AP[00:04:56:d3:7d:48] Sep 2 01:02:49 ePMP1000_6421e0 kernel: [90174.030000] SM disassociated from AP[00:04:56:d3:7d:48] F=5705 11naht20. Reason: 32 (NO ALLOCATION ON AP) Sep 2 01:04:30 ePMP1000_6421e0 kernel: [90274.970000] SM associated with AP[00:04:56:d3:7d:48] Sep 2 01:06:22 ePMP1000_6421e0 DEVICE-AGENT[3414]: [src/epmp.c:183 json_config_show] request failed, ret = 2 (Param not found) Sep 2 01:07:20 ePMP1000_6421e0 kernel: [90445.720000] SM disassociated from AP[00:04:56:d3:7d:48] F=5705 11naht20. Reason: 48 (COMMUNICATION LOST) Sep 2 01:08:34 ePMP1000_6421e0 kernel: [90519.630000] SM associated with AP[00:04:56:d3:7d:48] Sep 2 01:08:39 ePMP1000_6421e0 kernel: [90524.550000] SM disassociated from AP[00:04:56:d3:7d:48] F=5705 11naht20. Reason: 49 (INVALID SECURITY KEY) Sep 2 01:09:49 ePMP1000_6421e0 kernel: [90594.760000] SM associated with AP[00:04:56:d3:7d:48]
This is another log after changing to 5ms frame (Was 2.5ms before).
Station's RSSI is -58
SNR: 39dB
There were jumps on uplink MCS from 10 to 14 mostly, so i have fixed it on 10 with same luck
MCS 10 - QPSK 3/4 432 441 (86%)MCS 9 - QPSK 1/2
51 317 (10.2%)
Hi Beeonline,
While community forum is great for discussions and sharing and it is not as great as straight tech support. To figure out what is the exact reason of the issue you are having I would strongly recommend to open a support ticket, share tech support logs and work with the team. It is available as a free service for all Cambium customers.
Dmitry
PS My feeling that the reason is an interference on the client side. But as you can imagine it is just a guess.
i also have this issue on 26/06/2021 AP3000 version 4.6.0.1
whats should i do?
If it was me, I would upgrade to 4.6.1-RC27, which is a mature Release Candidate and as far as I know, it addresses all known/reported problems. We are running it on a bunch of ePMP APs and SMs, and it’s working well for us.
No Allocation on AP can mean one of two things: 1) the AP is full as either you have max number of SMs for that AP or you have an AP-Lite; OR 2) your SM has been banned from that AP by the MAC filter.
I would start like Ninedd said and upgrade to 4.6.1-RC27 on both that AP and SM, while your in there make sure your max subscriber count in the config is larger than the number of SMs on the sector. Also, check the MAC filter and make sure that SM isnt in the list and boot SMs off that sector is they arent supposed to be on that one, the mac filter list is a good way to prevent SMs from migrating where they are not supposed to.