You are here

Nanostation XM Unbricking Help/Pointers Please

6 posts / 0 new
Last post
Nanostation XM Unbricking Help/Pointers Please


I have been given and have been tasked with unbricking a nanostation.   

I'm looking for some suggested pointers links videos etc however I want to determine that the device is truly bricked before
I attempt "unbricking".

I'm also concerned from what I have read that radio calibration data could have been lost in some circumstances and I don't 
want to overwrite that in an unbricking attempt unless I absolutely have to.  
This is particularly where I could use some help or benefit from your experience.

I've asked for some preliminary information on the device from the owner and the owner gave me a best effort.  
I'll also describe and attempt to detail what states I am testing the device in and what I have observed so far.  
Sorry It's a bit lengthy but really simple as all I have really done so far is try different reset button press timings
during powerup after powerup etc and describe the LED changes.
Detailed below are all of my initial tests before I go and get a serial terminal hooked up to it. 
There's some kind of life here but no network connectivity of any sorts. 

I'm really curious what these LED flash "modes" might be and if you might be familiar with any of them.  
Serial port looksee is next.  

This is freaking lengthy TL*don't*Read.
If you require a video to help me out let me know. 

Device: Nanostation 2.4Ghz only label seems to be a #+mac "*1628K6872615A37D0 "
Internal sticker on board has same number.  *1628K6872615A37D0
Another sticker on board has : 
NSM20000T00 LF

Printed on the main board are: 

HannStar J  MV-4  94V-0 E89382 1617  
And finally "Ubiquity Networks 2012 

* owner says it came with  v6.1.3 firmware on it.   
And bricked when they tried to TFTP Flash AirOS 5.6.15 onto it.  

Now the board is in my hands and here is what I am observing:   
LED Number and color I will be discussing and describing  what is going on are as follows left to right
From left to right

1- Green Power LED
2- Green LAN1 LED 
3- Green LAN2 LED  

6- Green SIG3 LED 
7- Green SIG4 LED  

Using Ubiquity power injector.  
Test PC is on and hooked to LAN port of injector, power injector is known good and working.  
Attempting continuous ping from PC to device (ping -t to see if it responds.... ever.  

Tests and results:  

"Normal Powerup" (simply plugging ethernet with POE into main LAN port)

Three leftmost LEDs (1,2 and 4 ) come on simultaneously for 1.5 seconds the leftmost (LED1) stays lit green... forever no changes. 
Device is not pingable at nor does it respond to ARP requests.

Let's call this "test state 1"   
In test state 1 nothing ever changes.  

Next test (test 2)  is momentary press of reset button in test state 1
This test cause no noticeable change LED remains lit solid no response from network. 

Next test (test 3) LONG 30 second press of reset button (while in test state 1)  
​If this is done within about 45 seconds after powerup nothing ever happens or changes. 

If I wait two full minutes and then press and hold the reset button for 30 seconds it does something and appears to go into a different mode.   
This starts by a sequence of LED flashes as follows.  
LED1 remains solid lit
LEDs 1,2,3 and 4 simultaneous flash THREE times and then go out.   
If I let off the reset switch during this flashing event noting further happens afterward and the device goes back to just the solid power LED1. 

If I do not let up on the reset button and continue to hold it during this initial LED flash sequence more happens. 
After the 3 flashes of 4 LEDs mention just above 2 LEDs (LED5 and LED6) *SIG2 and SIG3* come on together and stay lit for 3 seconds then go off for 5 seconds.  
Then the 4 *SIG* LEDS (4,5,6,7) go into an alternating flash pattern where (SIG1 and SIG3) light up together for 1 second then go out
and then (SIG2 and SIG4) pair are lit together and it alternates forever.
Hitting the reset button or holding it for a long time does not change it it keeps alternating the pattern until you power it off.   

During all of these test it is never pingable at nor does it respond to ARP.  

Another test and slightly different results:  

If I power it up with the reset button held LAN1+LAN2 (LED2 and 3) light up for 5 seconds and go out.  
If I let off of the reset button either while they are lit or just after they go out it just goes back to the green power LED only 
and never pingable at or any ARP response. 

If I try this again but hold the reset button in and don't let off in about 20 seconds this does the same all 4 SIG LEDS flash 3 times mentioned way above
But this time I don't get the intermediate single flash of the wto SIG2+SIG4 LEDs before it goes into the same alternating pattern.   

During ALL my tests detailed here the device is never reachable at in any way possible.  



Sometimes I can be the
Sometimes I can be the biggest derp in the world.  
​The PC was plugged into a different network and I was "certain" I had it plugged in.   
​Ah H*ll  I wanted to get myself a TTL serial adaptor going anyway for like 10 years to play around and never really needed it.  
Same goes for JTAG.  
Want to try that too sometime.  

​The alternating LEDs pattern is when it is in TFTP server mode ready to accept a firmware image.  

​Pretty sure his PDA (802.11 radio alignment/calibration data) will be just fine :)   

Wrong Firmware; Any Hope for NanoStation XW?

We originally loaded up nightly build firmware 536-7486a17 to my NanoStation XW and it performed properly. I wanted to upgrade it before it gets mounted in the field so I used the AREDN GUI to upgrade it, however I was tired and accidently used:  aredn- !  I should have used:  aredn- !  I have since tried to load the proper firmware using TFTP however I cannot get a connect between my raspberry pi LAN port and the NanoStation LAN port; the NS LAN port is not talking.  I also tried Mac and windows but no joy.

Is there any hope to unbrick it?.

AE6XE's picture
KD6UVT,    It would be worth

KD6UVT,    It would be worth another look at putting the device in tftp mode and attempt to upload the nano-m-xw-factory image or see if it is still booting AREDN.   The sysupgrade process through the AREDN UI shouldn't have a path to attempt to load the "nano-m" image on this "nano-m-xw" device.  sysupgrade detects this miss-match and would error out.    

By chance did you recall if there was a pop-up, something like "expecting the nano-m-xw image, are you sure you want to proceed?".   (Even if you had clicked 'ok', it still should have errored out and not loaded anything.)    Exhaustively testing every possible combination isn't always feasible, so just in case, if a warning window didn't pop up, we'd like to capture that and correct.

Joe AE6XE 

I spent hours attempting to
I spent hours attempting to TFTP to the NanoStation but I cannot get a connect with it on eth0. It apears that it cannot communicate and at as a DHCP server I believe.
My first initial upgrade was using the AREDN GUI method. When it stopped working I believe I attempted to do the update with the XM version for TFTP. I am now planning to use TTY access to stop the autoboot process and then use tftp to load the correct verions. May have to reinstall the original firmware and then upgrade to AREDN.

I don't recall it showing a warning and attribute the problem to being tired and not reading all the equipment type and software version info.

It have tried all kinds of ways to find a ip address for the device but my pi reports eth0 link is down.

AE6XE's picture
I always use and recommend a
I always use and recommend a dumb switch between the tftp client device and the node. This makes the link down issue something between the RasPi and the switch.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer