Release 14.1.2 is a maintenance release and supports PMP/PTP 450, PMP/PTP 450i and PMP 430 SM (Interoperability mode ONLY) radios.
Software packages and documentation is now available for download.
1 Like
PMP 450i power on reset (now Hardware Watchdog Reset in 14.1.2 build 19) has been resolved?
14.1.2 build 19 still has this problem...
@Telemar wrote:
PMP 450i power on reset (now Hardware Watchdog Reset in 14.1.2 build 19) has been resolved?
14.1.2 build 19 still has this problem...
Hi Telemar,
The occurance rate has been reduced through defensive code but not eliminated. We continue to root cause it to eliminate it in the next release.
Thanks,
Sriram
"CPY-10327
When SM Network Accessibility is set to Local, the proxy link to the AP does not function Network accessibility determines whether or not a proxy connection from the SM to the AP may be established.
When the SM network accessibility is set to local, SM-to-AP proxy is now disabled."
Can this be clarified? We rely on AP to SM proxy to manage SM's and typically leave access to local as it has been the "out of box" configuration. Perhaps this change should be a third option (Local - no Proxy access), not a complete change to existing functionality. Always on SM-to-AP proxy is the expected behaviour after operating canopy for 10 years.
Perhaps I misunderstand what's changed here?
This is SM to AP proxy , when SM is set to Local it can’t reach AP.
No changes to AP to SM Proxy, it works as earlier.
Aha, I had no idea there was such a thing. Sitting on this side of all the connections, I've never looked either.
Looking at my old FSK network where I currently still have a couple directly accessible SM's, I don't see anywhere there would be an "SM to AP" proxy. Was this a new feature? What is the use case for SM-to-AP proxy? Primarily a PTP feature?
I have 14.1.2 official loaded on a couple sites (including the SMs). I was hoping and praying that this problem was related to the AP FPGA memory controller issue. Welp, it's not.
Bridge mode SM. Static management IP. Monitoring reports it down. Yup, can't ping it. No GUI access. Ping from AP to RF private IP also no-go. AP>SM proxy doesn't work. It's definitely still in session. Customer can still pass traffic... for a while, then that quits too.
The fix: drop that SM's session from the AP using the "local" option. Something with the session just goes screwy.
Hi George,
Could you lets us know what kidn of traffic was passing thru on this particular SM? How long it took for problem to show up? Does all of your SM behave like this?
After SM comes back by dropping , do you see something strange in Event Log.?
-Chitrang
@George Skorup wrote:I have 14.1.2 official loaded on a couple sites (including the SMs). I was hoping and praying that this problem was related to the AP FPGA memory controller issue. Welp, it's not.
Bridge mode SM. Static management IP. Monitoring reports it down. Yup, can't ping it. No GUI access. Ping from AP to RF private IP also no-go. AP>SM proxy doesn't work. It's definitely still in session. Customer can still pass traffic... for a while, then that quits too.
The fix: drop that SM's session from the AP using the "local" option. Something with the session just goes screwy.
Hi,
This feature was present since long.Use could be you are at customer location and wanted to access AP(in case you dont remember IP or its dynamic). One can use this proxy to access AP page.
@Steven wrote:Aha, I had no idea there was such a thing. Sitting on this side of all the connections, I've never looked either.
Looking at my old FSK network where I currently still have a couple directly accessible SM's, I don't see anywhere there would be an "SM to AP" proxy. Was this a new feature? What is the use case for SM-to-AP proxy? Primarily a PTP feature?
Similar stupid things are still happening on 14.1.2 official when a radar detection occurs. Almost still as crazy as 13.2.1.
Just had it happen again. Somewhat similar to this: http://community.cambiumnetworks.com/t5/PMP-Beta/Beta-Software-14-1-2-Build-17-for-PMP-PTP-450-and-PMP-PTP-450i/m-p/55665#M624
This time, all HP VCs were stuck at 1X/1X. Some SMs would not stay registered for more than a few seconds. I dropped all sessions (local) and removed all idle SMs. Things somewhat cleared up, but a couple SMs kept going in and out of session every few seconds. Some have HP enabled, others not. So that doesn't seem to be related.
The only way to fix this is to reboot the AP. Someone please tell me I'm not alone with this issue. :(
@Chitrang wrote:Hi George,
Could you lets us know what kidn of traffic was passing thru on this particular SM? How long it took for problem to show up? Does all of your SM behave like this?
After SM comes back by dropping , do you see something strange in Event Log.?
-Chitrang
@George Skorup wrote:I have 14.1.2 official loaded on a couple sites (including the SMs). I was hoping and praying that this problem was related to the AP FPGA memory controller issue. Welp, it's not.
Bridge mode SM. Static management IP. Monitoring reports it down. Yup, can't ping it. No GUI access. Ping from AP to RF private IP also no-go. AP>SM proxy doesn't work. It's definitely still in session. Customer can still pass traffic... for a while, then that quits too.
The fix: drop that SM's session from the AP using the "local" option. Something with the session just goes screwy.
The SM that was affected did not have HP enabled. But they are running VoIP. We turned off HP several weeks ago (while still on some of the early 14.1.2 builds) to troubleshoot some voice quality issues. HP on vs off didn't seem to make any difference, so we left it off. Other than that, normal internet stuff.
That customer also has all of their network equipment on a UPS, so it's not power related.
Over the last two years, I have not been able to determinte what sets off this condition.
Hi George,
As for this SM unaccessible issue, could you check bridging table on AP when its works and when it didn't.
This is a legacy issue which never got root caused and I remember it happened on 13.2 as well.