Desperate need for use of secondary port for M5's

First, let me thank you for the great work you guys have done with the software. so far with what we have changed over we are impressed with how well the UBNT hardware finally works when it is elevated... no more VoIP problems or throughput issues with more than 25 on an AP...  Thank you guys. Keep up the good work.

We are planning on elevating over 1500 clients and over 1200 of them are NSM5's that we have plugged into the secondary port. Here are some reasons we are using the secondary ports and not the primary.

1. If there is any water in the connectors or line when the radio gets rebooted it will enter TFTP mode and wipe the config. we have had some bad cable but we also have customers getting the POE wet from snowy boots or spilling stuff on it. this would cause a truck roll. Putting it in the secondary port avoided this problem. 

2. reset buttons on the POE that some people liked pushing and rebooting... the unit would go into TFTP mode and reset the config. This would cause a truck roll. Putting it in the secondary port avoided this problem.

 3. POE pass through did not always work from the primary to the secondary. However, It would always work going from the secondary to the primary as it would force the relay to always be on.

With this, we have made our standard installation for NSM5's to use the secondary port. It saved a lot of problems but now is hindering Elevating.

We do not need to use both LAN0 and LAN1 we just need a way to choose one or the other. Having to truck roll to a customers house just to swap the port from secondary to main would be a major inconvenience.

Is there anything we can do?

Hmm... so no one else needs this feature?

I have a handful of clients using it but it is non-standard for us and they know we may not continue to support it.

It would be nice but not gamechanging.

Same here. We rarely used the 2nd port except for adding cameras to a CPE. (Still a viable answer for that, hopefully further epmp radios will still have a 2nd port). But its definitely not a deal breaker for us either. Majority of cpes don’t have a 2nd port and I’ve made it our policy to not to be dependent on that. I’ve heard a few people claim they’ve been able to use the 2nd port on xw models, try one on the bench and see if it does for you too. If not, just flash it back to ubnt software for now. Cambium is always improving the products so I wouldn’t be surprised if that lands on the roadmap.

As Chris said, the second port should work on XW devices. Its the XMs that are tempermental and we are challenged with making it work reliably. But work continues and we hope to have it working. This is just the bridging part. For PoE passthrough, its a bigger challenge as we have to get into the GPIO of these devices and therefore can't commit to it right now. 

NGL_ConnectionWe are not considering using the aux port as a standard deployment.  And even after Elevate, once you start swapping out with ePMP SMs, you won't have the second port available with the Force 180 and 200. At the end of the day, we released Elevate as a migration path and not as a long term solution for your Ubiquiti network. Also, regarding your #1 and #2 concerns, once you Elevate your devices, this will no longer be a problem as we have disabled (in the Elevate software) the TFTP mode factory default via reset button on the PoE. We did this exactly because of the unreliability of the GPIO on the Ubiquiti hardware.

Thanks,

Sriram

1 Like

Thank you very much for the information.

Yes it looks like XW hardware works in both bridge and NAT mode with the secondary port. It looks odd because it says down but shows green when the secondary port is used. I tried with the XM hardware initially and it does not work with the secondary port at all.

This will help much in our network. I have noticed that the XM hardware requires quite a bit better signal  then XW hardware to stay connected reliably. -64 or greater. They may need swapped out sooner then later.

It seems ver. 3.2.2 fixed most of the XM hardware from disconnecting. Great work guys!

2 Likes