Yeah, I can't get a handle on it either. When I was contacted by Cambium and asked to use 13.4 when it was in beta, it did help. Before 13.4, some of my links were unusable. I have no idea what they changed with 13.4, but whatever it was, it prompted them to contact me and tell me that it addressed disconnects.
Before 13.4, I was trying to establish a PTP450 link that was about 7 miles from a water tower to a silo. There was line of site, but just barely above the tree tops. The PTP450 would run stable so long as there was no traffic on the link. As soon as I bridged across it, it would disconnect repeatedly, even though the PTP230 that we were replacing ran perfectly without disconnects. I tried a 5Ghz PTP450 and a 3Ghz PTP450 and experienced the exact same problem. That link was replaced with a PTP650 and I never went back to test 13.4.
Traffic definelty has a part in this, but I suspect that it is triggering a fault that has to do with MIMO. a PTP230 is pretty much the same as a PTP450, minus the MIMO. Afterall, the 450 line comes from the 430 line, which is what the PTP230 is (a PMP430 SM). My water tower to silo link was the worst I have ever seeen and it would make sense that MIMO would have issues on that kind of link. There would be Fresnel obstructions and multipath off the surfaces of both sites. Whatever this problem is, it should be fixable, because my PTP650 link runs fine and it is MIMO.
I should also comment now that I run a lot of PMP450. I've noticed that clients routinely disconnect when they are in NLOS conditions. My own home connection is a 3Ghz PMP450. I am aiming it through about 100 yards of sparse forest. I have a -65dBm signal now that the leaves are off, but it disconnects randomely and takes about 1 minute to reconnect. It's connection is timing out and it has to reconnect. Pretty much the same problem as the PTP450 I think.
One of the huge downfalls of adopting the PMP450 line has been its terrible NLOS performance. If they could fix that, it would be a great product. I don't need to run -85dBm links. But I should be able to run a -65dBm link stable.
Perhaps their engineers haven't figured out MIMO yet. Perhaps I'm seeing the exact same issues across all of my 450 radios and the trigger is a combination of traffic load and non-ideal MIMO conditions. Is there a way to simply turn MIMO off to test?
Well, I had a disconnect again with auth disabled, so that didn't help. These log entries are my only clue so far. Though they tell me the times of the disconnects, they do not tell me why.
Slave:
11/18/2015 : 01:35:27 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0 11/18/2015 : 01:35:47 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0 11/18/2015 : 01:35:47 UTC : Event: AUTHEN_FAIL, NewState: IDLE, Flag 0 11/18/2015 : 01:35:51 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0 11/18/2015 : 01:35:51 UTC : Event: AUTHEN_SUC, NewState: AUTHENTICATED, Flag 0
Master:
BH Authorization:
11/18/2015 : 01:35:27 UTC : Event: AUTHOR_RESET, NewState: IDLE, Flag 0 11/18/2015 : 01:35:51 UTC : Event: AUTHOR_REQ, NewState: AUTHORIZING, Flag 0 11/18/2015 : 01:35:51 UTC : Event: SET_PARAMS, NewState: AUTHORIZING, Flag 0 11/18/2015 : 01:35:51 UTC : Event: SEND_PARAMS, NewState: AUTHORIZING, Flag 0
BH Authentication:
11/18/2015 : 01:35:27 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0
BH Session:
11/18/2015 : 16:49:16 UTC : Event: SES_MSG, MsgType: KAREQ, NewState: IN SESSION, Flag 0 repeated 18 times
Cambium, I have to keep asking for attention. Are you at least aware of this issue? I have many PTP450 links. I've RMA'd them, I bought new ones. There is something wrong.
This is my best explanation: The session locks up on the AP when a certain amount/type of traffic is passing across a MIMO link. The SM times out and reconnects to the AP.
Because of this, an increase in packets/traffic increases to odds the error will occur.
Likewise, an increase in fresnel obstruction increases the odds the error will occur.
The combination of the two is causing the issue.
Please provide me a way to turn off one phase. I can then verify if the problem goes away.