We’ve been battling with this issue for a while, and we had made some progress by splitting up the heavily loaded AP into two APs, configured slightly differently, but it is now raising its ugly head again. We’ve brought this issue to Cambium’s attention, and they have been very responsive and have done their best to be helpful, but we really haven’t been able to resolve the problem.
We have multiple sectors on a tower, and the issue is that certain CPEs, which had been working normally, will suddenly decide to refuse to connect to the appropriate AP. In most cases, we lock the CPE to the BSID table, so they simply won’t connect to anything. If we unlock the BSID selection, then the CPE may connect to an AP which is clearly not the optimal one.
For instance, here is the (edited) channel table from one of these CPEs:
---------------------------
2
36xxxxx 5 MHz -76.17 29.25 Enable
BSID:xx:xx:02:00:00:00 Preamble Index:0
8
36xxxxx 10 MHz -90.34 15.97 Enable
BSID:xx:xy:00:00:00:00 Preamble Index:0
10
36xxxxx 10 MHz -75.39 30.84 Enable
BSID:xx:xx:00:00:00:00 Preamble Index:0
The CPE was working on channel 2 just fine for weeks, until this morning. Now, it will not connect to channel 2 (channel 10 is pointed correctly, but is out of range, since we had disabled Extended Range mode on it), and it chooses to only connect to channel 8.
I checked frame utilization on the AP I want to connect to, since high utilization has correlated with the problem before, but the usage is good (over the course of several minutes, neither ul or dl slots exceeded 40% usage). I tried to play with the BSID table, moving entries around, locking and unlocking, which has often resulted in success in the past on other CPEs. Nothing works - it connects to channel 8 or it will not connect at all - and it ignores the fundamental issue: why does this happen?
I can have the CPE replaced, but that’s just a band-aid, and does nothing to prevent it from happening to other locations, or even the replacement AP, for that matter.
Has anyone got any insight to share about this problem? Please?
So you have tried deleting the unused/unwanted frequencies from the CPEs?
Peachy wrote: So you have tried deleting the unused/unwanted frequencies from the CPEs?
My fear (which has successfully prevented me from trying that) is that doing so will not cause the CPE to register to the correct AP, but it will then still not connect, and I'll have to try to talk the customer through adding the frequency back into the channel table if we want to get it up at all.
Have you found success doing exactly that?
Just as an added point of reference, if I watch the Radio Info data on the AP when the CPE has been rebooted, I can see the CPE's MAC address trying to register, and the two uplink RSSI and CINR values cycle between -100/-100 and -4 (i.e. not communicating) and -69/-92 and 29 (i.e. normal), but the downlink RSSI stays horribly low and it just refuses to register. I found that if I have the correct AP at the top of the list, it will try once and fail to register to it, but it won't behave as expected and just move on to the next AP in the list until I Deregister the CPE in the Connected CPEs screen, at which point it immediately locks onto the wrong AP.
We currently have multiple CPEs with only the one frequency…we actually delete any others to prevent them from jumping from AP to AP. With those RF lvls mentioned however, your problems are coming from there. We tend not to install below a steady RSSI -85 CINR 20. The CPE in your case just appears to be trying to survive. Assuming you’re using integrated SMs, have you tried connectorized?
Peachy wrote: We currently have multiple CPEs with only the one frequency...we actually delete any others to prevent them from jumping from AP to AP. With those RF lvls mentioned however, your problems are coming from there. We tend not to install below a steady RSSI -85 CINR 20. The CPE in your case just appears to be trying to survive. Assuming you're using integrated SMs, have you tried connectorized?
This radio was connecting just fine to the same AP it should be connecting to before - exactly one month ago, it was working great at RSSI: -75.69 dBm CINR: 30.39 dB. It now will only connect to the wrong AP at RSSI: -89.12 dBm CINR: 16.82 dB.
The channel table shows (RSSI and CINR) -77.11 and 29.59 for the good one and -85.72 and 17.06 for the bad one. That's the whole point of why I'm trying to find a solution - the CPE should not be preferring the AP it is, let alone refusing to connect to the one with a CINR that's almost twice as strong.
did you make sure extended range mode was off before upgrading this basestation???
we had this problem on a basestation i neglected to turn it off, after a few days of irritation i realized my mistake and downgraded to 2.2, factory defaulted, cleared all QOS assignments and profiles, upgraded to 2.3, re programmed QOS and re enabled extended range mode and problem solved.
mgthump wrote: did you make sure extended range mode was off before upgrading this basestation???
we had this problem on a basestation i neglected to turn it off, after a few days of irritation i realized my mistake and downgraded to 2.2, factory defaulted, cleared all QOS assignments and profiles, upgraded to 2.3, re programmed QOS and re enabled extended range mode and problem solved.
We read the release notes on the firmware release which had the bug that caused the spontaneous reboot if the basestation was upgraded without disabling Extended Range mode, so we did follow correct procedure for that upgrade. I think we had one AP on that tower which I upgraded without the correct steps, so I had to disable ER, downgrade, and re-input all the QOS profiles before I could apply the upgrade. As far as I can see, the problem I'm dealing with shows up with CPEs trying and failing to communicate with the APs that did have ER disabled before the upgrade and the one which didn't.
Do you use a syslog server for the AP?
Ive found that with certain problems(for me it was a missed setting in QoS)with SM’s not connecting properly or at all that the info found from the syslog usually gives a pretty good answer of why its happening.