If I update the AP first, none of the subscriber units will register. They show up in the session status as idle. I reversed the order on a smaller site and if I do the SM first, then the AP last, it works OK. The only difference I can see is the 14.2 does not have encryption. Where DES or AES is shown with the release, the word "None" is in its place.
Typically you should always do the SM's first and then the AP when making such a large jump between releases. I would have also done a bench test first between migrating such a large jump.
All PMP450 radios support either no encryption, DES, or AES. The encryption is specified on the Security tab on the AP. Nothing needs to be set on the SM.
1 Like
I just updated a 14.1.2 AP to 14.2 for testing and it defaults to none rather than defautling to DES as it did migrating from 13.2 - 14.1.2.
Presumably just setting it to DES will solve your issue.
That is however on the highly annoying side to have to replace settings when upgrading. I haven't tried this on a configured AP yet, this was a factory defaulted one. I really hope it's not doing something like wiping out all the security page settings like the saved auth key.
I went back down to 14.1.2 on that AP just now, set the standard authentication server settings I use, saved it. Updated again and it held the DES pull down, and all security settings including the preshared key on update. Perhaps this only happens if you're using factory defaults on the security page?
I'm not even finished rolling out a 14.1.2 migration so that's a worry for another day I guess.
I'm pretty sure AP's out of the box have their encryption set to none. We've done many many incremental steps between releases and it's always retained the encryption setting.
The factory defaults on 14.1.2 and lower at least for all the APs we have use DES in the pulldown not "none".
I'm just taking a stab in the dark that the OP uses the default security page settings and his APs and SM's are defaulting to none with this behavior.
Try setting factory defaults on 14.1.2 and then on 14.2, you'll see the new default for the pulldown is none instead of DES.
The *AP* default has always been 'none' for encryption. SMs have always been DES.
If the AP is set to none, the SMs will register fine. Doesn't matter if they have DES or AES selected.
If the AP is set to DES and the SMs are set to AES, then yeah, it won't work.
We make things easy and just use DES on the AP, since that's the default on SMs. Makes new out of box SMs register via ICC without issue.
Not on any of the APs I have. Do you want screenshots? The default is DES on 14.1.2 and lower.
I don't know about the APs themselves. But the 230 backhauls had a different version for the United States than other regions. It's entirely possible there could be different equipment in the US region with different default settings that I'm unaware of, but I can assure you the default is DES on all of the 450s we have. Prior to 14.2 that is.
Errors I am getting after updating to 14.2. This was a working AP until upgrading the AP.
This one was registered then dropped
Session Dump for LUID 3
08/19/2016 : 22:48:20 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0
08/19/2016 : 22:48:20 UTC : Event: SEND_AUTHEN_MSG, NewState: REGISTERING, Flag 0
08/19/2016 : 22:48:20 UTC : Event: AUTHEN_SUC, NewState: IN SESSION, Flag 0
08/19/2016 : 22:48:20 UTC : Event: SEND_AUTHOR_MSG, NewState: IN SESSION, Flag 0
08/19/2016 : 22:48:20 UTC : Event: SES_MSG, MsgType: ESNQUERY, NewState: IN SESSION, Flag 0
08/19/2016 : 22:50:20 UTC : Event: SES_MSG, MsgType: PAREQ, NewState: IN SESSION, Flag 0
repeated 1 times
08/19/2016 : 22:53:14 UTC : Event: OOS, MsgType: VCERR, NewState: IDLE, Flag 190
This one never registered.
Session Dump for LUID 5
08/19/2016 : 22:48:50 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0
08/19/2016 : 22:48:54 UTC : Event: REGREREQ, NewState: REGISTERING, Flag 0
repeated 1 times
08/19/2016 : 22:49:24 UTC : Event: OOS, MsgType: TIME OUT, NewState: IDLE, Flag 0
08/19/2016 : 22:51:33 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0
08/19/2016 : 22:51:37 UTC : Event: REGREREQ, NewState: REGISTERING, Flag 0
08/19/2016 : 22:52:04 UTC : Event: OOS, MsgType: TIME OUT, NewState: IDLE, Flag 0
08/19/2016 : 22:52:27 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0
08/19/2016 : 22:52:27 UTC : Event: SEND_AUTHEN_MSG, NewState: REGISTERING, Flag 0
08/19/2016 : 22:52:27 UTC : Event: AUTHEN_SUC, NewState: IN SESSION, Flag 0
08/19/2016 : 22:52:28 UTC : Event: OOS, MsgType: VCERR, NewState: IDLE, Flag 311
08/19/2016 : 22:55:16 UTC : Event: REGREQ, NewState: REGISTERING, Flag 0
08/19/2016 : 22:55:18 UTC : Event: REGREREQ, NewState: REGISTERING, Flag 0
08/19/2016 : 22:55:18 UTC : Event: SEND_AUTHEN_MSG, NewState: REGISTERING, Flag 0
08/19/2016 : 22:55:18 UTC : Event: AUTHEN_SUC, NewState: IN SESSION, Flag 0
08/19/2016 : 22:55:19 UTC : Event: OOS, MsgType: VCERR, NewState: IDLE, Flag 311
Replying to my own post...
Looks like there is not other way to upgrade except for doing a SM at a time and have those users down until all SMs are upgraded, then do the AP. This is the only way I have been able to get modules to all talk to the AP.
Dan
Have you tried doing it in smaller jumps? Say to 13.4, then to 14.1 or to 14.2?
Yes. If the AP is at 14.x.x, it will not see any of the 13.1.3. If I leave the AP at 13.1.3, I can updaate the SMs, but they will no longer register until the AP is moved to 14.1.x
14.1.2 connects just fine to devices on 13.2 for what it's worth. I have about 25 % of that upgrade completed and it's going quite smoothly.
As for the FSKs 13.1.3 FSKs connect just fine to 13.4.1 APs as well for me.