OpenWrt Forum Archive

Topic: Nanostation M5 poe passthrough

The content of this topic has been archived on 12 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I'm testing Ubiquiti Nanostation 5M for using them in our OLSR-under-openwrt-based mesh network. I've compiled and uploaded the latest trunk 19374 and everything worked fine, even OLSR. Congratulations to all developers for such a universal and updated firmware which is openwrt.
However, it would very interesting (and help saving a lot of CAT5 cable) to enable the PoE passthrough feature included in this piece of hardware. Any success on this issue?

Looking at AirOS software, I think that gpio pin 8 must be set to enable the poe passthrough. I compiled gpioctrl with the openwrt but when I try:

gpioctrl dirout 8

I get the following error:

Error whilst opening /dev/gpio

It seems that is not recognising the gpio devices... Any ideas on this?

Thanks

xavier_martinez

EDIT: I've changed the code listed below to what I found to work for Nanostation M5 on OpenWRT Backfire.

https://lists.openwrt.org/pipermail/ope … 07746.html

To switch the poe pass trough on use this ...

echo 8 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio8/direction
echo 1 > /sys/class/gpio/gpio8/value

You can put this in /etc/rc.local

(Last edited by westbywest on 1 Mar 2011, 21:47)

Hi,

i tried to build a chain of Nanostations M5 running 10.03.1-rc6 like this:

                 [M5]                         [M5]
POE===Main   Secondary===Main   Secondary

it worked fine after i enabled passtrogh on the first M5
using your code

echo 8 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio8/direction
echo 1 > /sys/class/gpio/gpio8/value

when i enabled POE passtrough on the second M5 i seem to hear a gentle click sound - of death.

Now the second M5 is not working anymore. If we connect Power only the Power Led is on -
no activity of the others. Main and Secondary LAN ports get no link anymore, serial console stays dark.

We tried to reproduce this error by successfuly bricking another M5.

Manufacturing Date of our M5 is 08 Nov. 2011



Kind Regards

fire

(Last edited by f1r3 on 21 Nov 2011, 10:44)

f1r3 wrote:

We tried to reproduce this error by successfuly bricking another M5.

Manufacturing Date of our M5 is 08 Nov. 2011

This report of yours is quite troubling.  The commands to toggle the GPIOs shouldn't be capable of causing physical damage; they're only setting a couple register bits (i.e. direction, and output value).

My first question is what sort of POE injector you were using?  The failure described for your 2nd NSM5 sounds like under-voltage.  I have only been able to get reliable results powering devices off the NSM5 secondary LAN using Ubiquiti's POE-24-1 injector, 24VDC @ 1amp.  Anything with less voltage or amperage has proven insufficient.

Beside that, UBNT did vaguely admit to a BOM error (Bill of Materials error, aka manufacturing error) on NSM5 units manufactured up until sometime in late spring 2011.  I can not find this particular thread on the ubnt.com forum at present.  The error amounted to a FET with too low of current tolerance supplying POE pass-thru to the secondary LAN port.

For me, this BOM problem always manifested itself as the POE pass-thru to the secondary LAN port eventually getting stuck-on after a few weeks of operation.  Such that I would lose the ability to remotely power-cycle the 2nd LAN port, w/o simply power-cycling the primary NSM5.  Inspecting the circuit board inside some of these units revealed visible (albeit tiny) burn marks on the FET affected.  Also on some units, setting the GPIO bits after the stuck-on occurred would trigger a spontaneous reboot.

(Last edited by westbywest on 2 Jan 2012, 02:10)

I observed a problem on a recent generation 00:27:... Nanostation M5 (mfg date ~August 2011) bricking itself upon enabling the POE passthrough feature (via firmware) shortly after boot.

The unit did not become bricked simply from flashing it, but rather failed upon the passthrough enable.  Also, nothing was connected to its secondary LAN port at the time; it was sitting on the bench.

I have not experienced this failure upon enabling the POE passthru feature, with stock firmware and otherwise, on older NSM5 units. Maybe there was a BOM change.

I found recent reports of other UBNT users experiencing the same failure enabling the POE passthrough feature on Nanostation M2 and M5s, when using stock firmware too:
https://forum.ubnt.com/showthread.php?p=270549

The suggested work-around, which I have so far tested successfully, is to NOT enable POE passthrough, presumably with any firmware.  Rather, swap the Main and Secondary LAN ports, i.e. so that whatever secondary POE device is connected to Main.  This will have the effect of the 2nd POE device being always on.

This work-around comes with caveat of possibly reduced power noise filtering, since the unit will not be receiving its power from the Main port.

Also, do please note UBNT's warranty policy of not supporting 3rd party firmware, even despite their wiki providing instructions for flashing OpenWRT onto their products:
http://www.ubnt.com/support/warranty

(So, recommendation is to prove out all units with UBNT stock firmware first, especially POE passthru, to screen for any problems.)

You *SHOULD NOT* use POE passtrough with stock power adapter, that is the reason you brick devices, you need a more powerful supply.

Use at least 20W power supply, stock supply is only 12W (24*0,5).

(Last edited by valentt on 27 Jun 2014, 22:37)

The observed self-bricking problem occured *despite* using the appropriate 24V / 1Amp POE injector.  Please read the forum post I linked to at ubnt.com.  There was a BOM error on some Nanostation M5's manufactured around August 2011, causing the POE passthru function to brick the device if enabled.

The particular radio of mine that suffered this problem was returned to UBNT for an exchange at no cost.

I've not observed any problems on POE passthru on Nanostations manufactured since then.

The discussion might have continued from here.