You are here

Ubiquiti NanoBridge Won't Flash

5 posts / 0 new
Last post
NA7RF
Ubiquiti NanoBridge Won't Flash
I seem to get the problem nodes to work on in my local area.  I have a NanoBridge that is giving me troubles.  I don't know the history behind the node or if it is an XM or XW.  It does have writing on it suggesting that it was flashed at one time.  I don't even know for sure if it is a NanoBridge and pretty sure it is for 2Ghz.  I wish Ubiquiti put better marking on these devices.
I can get the device into flash mode.  When I put it into flash mode, it has some strange lights getting there.  When the button is pushed and power applied, the power LED lights up, the network activity LED lights up,  as well as 2 other LEDs, right next to each other but with a blank LED between the network LED and the 2 LEDs.  After a few seconds, the 2 LEDs go out and then the bar graph starts to fill (I can't remember which why it fills) until all the LEDs are on.  A couple of seconds later, I get the 2 alternating LEDs signifying it is in flash mode.
One problem I am having is that when I tftp any file, the transfer is really slow.  I have put wireshark on and will attach a picture.  In wireshark, I can see the data being sent several times before the node acknowledges the data.  I think this is slowing the process down but don't understand what is causing it.  Every once is a great while, the transfer will transfer correctly but it fails.  I suspect the firmware failure is caused by a checksum lock (or signing) as the device rejects the firmware.  While the transfer is happening, the dual alternating LEDs are stuck in one position and only the network LED blinks.
If I don't ad a static arp entry, my computer will abort the process stating the device is no longer reachable.  This could be due to the slow response from TFTP.  

Has anyone seen slow transfers similar to what I am describing?  If so, what did you do to fix it?
What is the best way to identify the device?
Any other suggestions?

73,
Matt
NA7RF
File Attachment: 
nc8q
nc8q's picture
What is the best way to identify the device?
Hi, Matt:

That was a lot of backstory that I cannot assist your with, but
"What is the best way to identify the device?"
I may be able to offer suggestions.
Assuming that the device had/has Ubiquiti OS, BBHS, HSMM, or AREDN firmware on it,
it may respond to a DHCP server and ask for an IP address.
Does it do this?
Else, if DHCP client service is disabled, if you DtD connect it to another node
does it link?

73, Chuck

 
NA7RF
Chuck,

Chuck,
Thanks for the reply.  Sadly, I don't think any firmware is in the device.  I am now starting to think the CPU has been damaged or has a heat problem.  Playing around with it, I can see that it will respond/work better if it is cold.  While it is cold outside (highs in the low 40F), I just can't get it to respond any better.  I have been trying to get any firmware on it but either tftp times out or the device rejects the firmware.

When I let the device boot normally, it makes no attempt to do anything on the network.  I don't see any DHCP requests or any announcements.

I am going to make one last effor to utilize the cold weather we have right now.  Maybe I can get it to respond better outside when it is in the 20Fs.

Again, thanks for the reply.

Edit: if the device is having a CPU heat problem, then my feeling it should never be part of the mesh network because it will likely fail soon.
 

nc8q
nc8q's picture
DtD test omitted?
Hi, Matt:
Did you omit the DtD test?
The device could still be functioning but its DHCP client could be disabled.
73, Chuck

 
NA7RF
Chuck,
Chuck,

No, I did a DtD test.  It never showed up.  I think I am declaring this node a loss.

Thanks for your suggestions.

73,
Matt, NA7RF

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer