450b dropping off Medusa AP

Products PMP
1

Hi

We have an issue with a 450b that registers to a Medusa AP (takes a while to register) but shortly after will drop off.

It then attempts to register again but takes a long time.

We see the following in the AP session log:

Session Dump for LUID 94

02/15/2018 : 11:44:09 UTC : Event: SES_MSG, MsgType: PAREQ, NewState: IN SESSION, Flag 0

repeated 3 times

02/15/2018 : 11:47:47 UTC : Event: OOS, MsgType: VCERR, NewState: IDLE, Flag 1101

02/15/2018 : 11:51:41 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0

02/15/2018 : 11:52:06 UTC : Event: OOS, MsgType: TIME OUT, NewState: IDLE, Flag 0

02/15/2018 : 11:53:48 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0

02/15/2018 : 11:54:16 UTC : Event: OOS, MsgType: TIME OUT, NewState: IDLE, Flag 0

02/15/2018 : 11:55:58 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0

02/15/2018 : 11:56:26 UTC : Event: OOS, MsgType: TIME OUT, NewState: IDLE, Flag 0

02/15/2018 : 11:58:15 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0

02/15/2018 : 11:58:36 UTC : Event: OOS, MsgType: TIME OUT, NewState: IDLE, Flag 0

02/15/2018 : 12:00:20 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0

02/15/2018 : 12:00:20 UTC : Event: SEND_AUTHEN_MSG, NewState: REGISTERING, Flag 0

02/15/2018 : 12:00:20 UTC : Event: AUTHEN_SUC, NewState: IN SESSION, Flag 0

02/15/2018 : 12:00:21 UTC : Event: SEND_AUTHOR_MSG, NewState: IN SESSION, Flag 0

02/15/2018 : 12:00:21 UTC : Event: SES_MSG, MsgType: ESNQUERY, NewState: IN SESSION, Flag 0

02/15/2018 : 12:00:48 UTC : Event: OOS, MsgType: VCERR, NewState: IDLE, Flag 1101

And the Authentication State Machine Log:

Authentication State Machine Dump for LUID 94


02/15/2018 : 11:31:06 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

02/15/2018 : 11:32:56 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0

02/15/2018 : 11:33:26 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

02/15/2018 : 11:36:52 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0

02/15/2018 : 11:37:16 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

02/15/2018 : 11:39:09 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0

02/15/2018 : 11:39:09 UTC : Event: AUTHEN_SUC, NewState: AUTHENTICATED, Flag 0

02/15/2018 : 11:47:47 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

02/15/2018 : 11:51:41 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0

02/15/2018 : 11:52:06 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

02/15/2018 : 11:53:48 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0

02/15/2018 : 11:54:16 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

02/15/2018 : 11:55:58 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0

02/15/2018 : 11:56:26 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

02/15/2018 : 11:58:15 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0

02/15/2018 : 11:58:36 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

02/15/2018 : 12:00:20 UTC : Event: AUTHEN_REQ, NewState: AUTHENTICATING, Flag 0

02/15/2018 : 12:00:20 UTC : Event: AUTHEN_SUC, NewState: AUTHENTICATED, Flag 0

02/15/2018 : 12:00:48 UTC : Event: AUTHEN_RESET, NewState: IDLE, Flag 0

What could be causing the authentication to reset?

RSSI is -54, signal quality when connected is excellent.

2

Are you using 15.1.3 on both the 450m and 450b?

3

Hi Eric

Yes, 15.1.3 on both radios.

Colin

4

Colin,

I have a setup in the Cambium Lab where I can attempt to duplicate what you're encountering.

If you can post your radio configuration information:
Frequency Band
Frequency Carrier
Channel Bandwidth
Frame Period
Max Range
Downlink Data
Contention Slots

...I'll see what results here.

5

Does this happen with only one 450b?  Do you have other 450b units that are working well?  Other connected SMs that are working?

Trying to determine if it's only this SM causing problems, or a system thing...

6

Just the one SM - we tried a new one and connected up ok.

I'm waiting to get the SM back on my desk.

Is there documentation that describes the auth process and what the various messages mean?

Some of them are a bit obtuse.

7

It looks like a VC Error (a Virtual Circuit Error) knocked the SM off... this kind of thing can be caused by many different issues, from hardware problems to rf conditions (interference).  Since a different module seems to work, this could be a problem with that particular SM.

Regarding the message list, I will ask, but I don't think we have a complete list of the codes and their meaning anywhere.

8

Hi Matt, Can I echo Colins request for some documentation on what various error messages mean? I presume the reason the messages are cryptic is to save space rather than to be obtuse. A lot of google searches could be saved if we know what the error might actually be…

9

Hello Matt,

Nice to see there´s someone with the same log, in my case it happens in PTP BH 450i:

BH SESSION LOG

Session Dump for LUID 2

09/12/2018 : 17:30:45 COT : Event: SES_MSG, MsgType: KAREQ, NewState: IN SESSION, Flag 0
repeated 18 times

Please let me now If you have something about this.

10

rconstante,

Yes, I know our error codes aren't very helpful and some maybe shouldn't even be exposed. Some are just a generic message as well.

For example a "VC error" could mean any of the few things: Rebooted radio, unplugged radio, interference, low receive power, softare issue, other side detected radar, etc. We are looking to improve a few of the "VC errors" messages to in 16.1.

The KAREQ is Keep Alive Request that is PTP spcecific and it is not indictative of any problem. In PTP mode a Keep Alive Request/Response is normal.

In 14.1.2 we have moved this to it's own log on the BHS:

KeepAlive.PNG
KeepAlive.PNG1202×180 33.6 KB

I hope that answers your question.

Charlie

1 Like