I was working on a PMP450m on the workbench today, and had connected the radio via the fibre SFP, to a switch. To do this, I obviously had to set the “Ethernet Port Selection” to “SFP port” inside the Medusa.
Everything tested fine with zero issues, but I had a thought that begged to be tested. In the unlikely event that there is a fibre cut, or an SFP failure in the 450m Radio, can I simply connect a copper Ethernet Patch cable from the LAN side of the PoE power supply, and just bypass the broken fibre without changing the setting in the Radio? Will the PMP450m always respond on the Main port? Will it fail over in the event of a loss of link on the Fibre?
To test this theory, I simply unplugged the fibre between the switch and the medusa, and plugged in a cat-6 patch cable from the power supply to my PC. I hadn’t made any settings changes, so the radio was still set to use the SFP port… I then factory defaulted the PMP450m using the plug-in for 10 seconds, unplug for 2, and then power back up method. Low and behold, I couldn’t get a ping response from the default IP. I tried this several more times to remove the chance to human error, and still could not make it respond via the Main Ethernet Port.
So I reconnected the Fibre from Switch to Radio, and then plugged my PC back into the switch. I proceeded to factory default the radio again, and started getting pings back over the SFP interface, and saw that the radio had indeed booted into recovery mode.
So, after some experimentation, I feel comfortable confirming that if you loose a fibre up to your radio, the radio does not fail over to the Main port.
The radio will only respond to the default IP, on the interface it was last set to, even if you boot the radio into recovery mode.
So I’d like to clarify with anyone from Cambium that I’m correct in my experiment. If I’ve done something wrong, or overlooked some setting, please feel free to correct me.
Otherwise, I’m wondering if this is something that can be remedied with a firmware update, I have little doubt that it can’t.
We’ve been discussing this internally… one of the engineers will post the current state of things. Then we can discuss any future changes to make things better.
Can you specify which software version you were running? There was a known issue in 16.1.5, also present in early builds of 20.0 where the SFP or copper or both were inaccessible in default boot mode. This was fixed in 20.0 Official release. For reasons I won’t get into here, 16.2.2 was also working correctly, despite 16.1.5 not working, so if you are reporting this from 16.1.5 and don’t want to upgrade to 20.0, you can try 16.2.2 and see if it works as expected.
Long story short, the expected behavior for 450m is that if you do a short power cycle and boot to recovery, Canopy will utilize whichever interface, SFP or Main Eth / Copper that is first to show connectivity. You can then reconfigure the radio to the port you’d like to use, reboot, and upon reboot have access in normal boot mode.
Just to be clear, this hybrid main/SFP operation is only active in recovery, because it treats the 2 physical interfaces as a single logical interface, and would result in incorrect stats, among other things. It’s a bit of a shortcut to make sure recovery works in various scenarios, but is not ready for “prime time” as a normal feature.
In terms of it’s expected behavior, I can confirm that when performing the factory default process, the Ethernet would have been the only available connectivity for the radio to see. So if it’s expected to utilize whichever interface fist sees connectivity, Ethernet should have been it’s only option.
Hmm, thanks Neil. Someone from our test team sent you a PM to follow up about your specific hardware. Please get back to him and I’ll update here with any findings that come out of that. Thanks!
So in addition to the 20.2 Cambium testing that Al C had mentioned a couple of weeks ago, we did some retesting on 20.2.1 software this week on the recovery scenario Neil described. We again failed to find any problems. You should not need the fiber connection for recovery mode. It doesn’t mean you have not found an issue, just that there must some variation with your field scenario vs what we are testing that we need to understand. If any additional reproductions of the problem are seen, drop me a note directly or in this forum chain and we’ll try to think through what the difference could be that’s causing the issue you are seeing