I tried to install 3.15.1 on a factory Nanostation. It seemed to be going
fine but then never came back at the end. It may have been running
Airos 5.6. Not sure. I cannot run the test program as I have XP. I have
tried all the tactics listed here and elsewhere. Nothing works. The leftmost
two lights are always on solid green and no other lights show anything. I
cannot ping it. Help!
Bob W8ERD
fine but then never came back at the end. It may have been running
Airos 5.6. Not sure. I cannot run the test program as I have XP. I have
tried all the tactics listed here and elsewhere. Nothing works. The leftmost
two lights are always on solid green and no other lights show anything. I
cannot ping it. Help!
Bob W8ERD
Bob, 5Ghz, 3Ghz, or 2Ghz? Some guessing may be involved... XM or XW? 5.5 or 5.6? Any manufacture date anywhere to help bias the guess? There will be a way to gain access in the end, but the risk is the unique calibration data for the device is lost (already or in the guessing).
If you don't see the right most light blinking green after powering on (with AREDN or OpenWRT images), and you just loaded one of these images, then the firmware is not loading and symptoms of a corrupted partitioning->leans towards it was a 5.6 shipped device. But maybe AREDN didn't load and AirOS is still there, just not getting access to it for some reason. Power it on, record the exact light sequence to a steady state--what's happening?
Maybe the firmware upload was interrupted in the middle lost power -> tftp the right image? But what is the right image?
Joe
S/N 1538K68725138BB1
When powered up, the leftmost green light turns on steady.
Lights 2 and 3 flash green briefly.
Light 5 flashes orange briefly.
Light 6 flashes green very briefly.
Thanks for your help!
Bob W8ERD
Ok, this rules out the XW version--it has to be an XM. Now we're trying to figure out if it came with AirOS 5.6 or 5.5. Here's what I'd suggest as next step:
- using 'tftp' method, install the AREDN nano 'factory' 3.15.1.0 image (XM). For this to work, it would have had AirOS 5.5 when received and the prior load of AREDN didn't complete for some reason, e.g. the power was pulled early. In the worse case, If it came with AirOS 5.6, then the assumption is that loading AREDN on the 2nd attempt will do no more harm than what has already occurred from the first attempt.
When holding the hardware reset button down, and powering on, be sure to keep holding the button until the nano starts to blink orange and red lights--may take up to 30 seconds.
... and triple check:
1) nano has had a ~min to boot up:
2) hold hardware reset for 15 seconds, ish.
That:
1) the node is not "ping"able from your laptop with a static IP (on laptop) of something like 192.168.1.21 and you ping 192.168.1.20 (the default UBNT address).
2) laptop is set to DHCP and after pulling cat5 cable from the laptop, waiting 15 sec, then reattaching, look to see if the laptop receives an IP Address 10.x.x.x or 192.168.1.x
If ether of these succeeds, then there may be command line access to check out the node before trying to load any firmware image.
Joe AE6XE
Ping gives nothing.
3.5.1 is on my desktop.
Set directory to desktop. Static address 192.169.1.21
Started up with reset pushed for 30 seconds.
Red and Orange lights are flashing.
tftp -i w8erdpclaptop put aredn-3.15.1.0-ubnt-nano-m-squashfs-factory.bin 192.169.1.20
says "timeout occurred"
Bob W8ERD
192.168 not 192.169.
Sorry.
The 169 address is not from dhcp...that's Windows doing an autoconfig.
1. Manually config your workstation's lan ip address to 192.168.1.2 with a 255.255.255.0 mask, no gateway address, don't worry about name servers.
2. Now try to ping the node. It will either be on 192.168.1.20 (airos running) or 192.168.1.1 (unlikely) You have to be able to ping it first before trying to load it or access it.
If it responds on .20, hit it via a web browser.
If it doesn't respond at all, put it back in tftp mode by unplugging it, hold in the reset button, then plug it back in, release the button AFTER it starts doing the blink sequence. Then try to ping it on 192.168.1.20. If that works either send an airos or an aredn package to it with the windows tftp command.
Let us know how this turns out and if you need more detailed instructions. Good luck!
tftp -i 192.168.1.20 put aredn-3.15.1.0-ubnt-nano-m-squashfs-factory.bin
But you HAVE to be able to ping 192.168.1.20 before you'll be able to do the tftp.
Using the corrected tftp syntax you provided, it says "firmware check failed".
Happy New Year!
Bob W8ERD
download from: http://dl.ubnt.com/firmwares/XN-fw/v5.5.11/XM.v5.5.11.28002.150723.1344.bin
from same directory:
tftp -i 192.168.1.20 put v5.5.11/XM.v5.5.11.28002.150723.1344.bin
Joe AE6XE
Bob W8ERD
Tried tftp again. This time the tftp command seems to be running forever. Over 5 mins now with no completion.
I am letting it run. After 30-60 minutes it stopped with "Error on Server: Firmware Check Failed".
While running, light 5 was solid orange. After stopping, it went back to the flashing state.
Bob W8ERD
Bob,
Just in case, make sure the device is getting sufficient voltage (not on battery with a 100' cable) at least 12v, but no more than 24v, technically ubnt supports these down to 10.8v. Use all short cat5 cables and the stock power brick. The cat5 cable should be plugged into the primary port.
Capture the LED sequence through the full process. There's a different pattern at each step:
1) booting to tftp mode <- we know this is occurring and a ping to 192.168.1.20 confirms connectivity
2) tftp transfer of data <- might be occurring, is transfer time about right? LAN1 LED blinking for the duration of the tftp transfer?
3) flashing
4) rebooting
working down to the remaining options. Could try XM5.6 AirOS, but should see same tftp result. Next option is a bit more invasive, opening it up to get access to the serial port. (or return to vendor, it might be a hardware problem.)
Joe AE6XE
For an XM NS M5, this is especially puzzling. The newer NS M5's are being shipped with XW hardware and not compatible yet with AREDN firmware--could your device be an XW? In my tests in upgrading the older XM NS device to AirOS5.6.x, I was unable to reproduce a change in the flash layout reported to cause this problem. What is the history of your device? Was it received and you confirmed in the AirOS status page it was version XMv5.6.x? Did you upgrade to latest AirOS recently (and is was originally XMv5.5.x?) If you upgraded, via tftp or from the AirOS UI (it makes a difference)?
To get an idea of the last resort recovery process, do some searches with key word "redboot" "nanostation" "ubiquiti" "firmware recovery". There are some videos of how to pull the cover off a NS. There are OpenWRT (older device) documented notes on the serial port layout. There's a youtube on a Bullet redboot serial console access to recover.
Joe AE6XE
We're in need to document the process to access the serial port console and do this last resort recovery process. If you're willing to ship the device to me, I'm willing to attempt the recovery and capture video and document the process. My address is on QRZ, just an hour North in OC. The good news is a hacksaw is not required ;) , however this does involve peeling off the label to access the screws and remove the housing.
Best guess is that AirOS XM5.6 upload changed the flash layout and relocated the device specific data into a location which was subsequently over-written with the AREDN upload. The device specific information includes unique calibration data of the radio function that can not be re-created, unless we have access to very expensive test equipment and inside knowledge to do so. There's also data for proper function of the tftp server in the flash, which if lost will break this function. We have to copy this data from another like device to get it working in the ball park, but with risk it might have some undesirable behavior--spurs, etc. Can only speculate how big or small this risk is...
Joe AE6XE
Watch your mailbox.
Thanks!
Bob W8ERD
5.6 and the aredn were both originally done via web browser. I've only been using tftp for recovery. Sure I'll send it out sometime this week thanks for the help. I've already ripped off the label and opened it.
For everyone else's benefit, this is why the warning is posted on our Software Download page against loading AREDN firmware onto a device running AirOS 5.6.x.
We have developed the AREDN U-Boot Test Setup Program to check the device, confirm the boot loader's compatibility, and provide a means of backing-up critical node data should something go wrong in the load. Do not put your device at risk by deviating from this process. If the AREDN U-Boot Test Setup Program returns anything but a GOOD GOOD indication, then backup the data and downgrade the AirOS to 5.5.x before going any further.
I'm sorry this program is only available for Windows-based PCs. If you are an Apple developer and want to contribute a MAC version, please get a hold of me @arrl.net.
Andre, K6AH
Bob W8ERD
Hi Bob,
For the benefit of others reading this thread, I just wanted to use the opportunity to re-enforce the need to check nodes to be sure they are not running AirOS 5.6.x without confirming the AirOS boot loader's compatibility. Not everyone reads the warning we've posted (now highlighted in red): http://www.aredn.org/content/software
Andre
Joe AE6XE
A process to recover bricked devices due to the uboot AirOS v5.6.x issue has succeeded. Thanks to Bob, W8ERD, for volunteering his node to the scalpel. I'm working on a full write up, but to summarize the very high level process, here it is:
1) Gain access to the motherboard and attach a console to the serial port.
2) On power up, hit a key to stop the boot process and enter the command "urescue -f -e" (runs the internal tftp server and enables the downgrade of uboot)
3) Now "tftp" on the main ethernet port to upload the AirOS v5.5.x firmware (correct uboot version now restored)
4) Repeat step 2 and 3 with out the options, "urescue" only. With correct uboot version, flash layout, etc. is returned to normal.
5) Reassemble case and power cycle, booting to AirOS (if encountering any issues, without using the serial console access, do the normal tftp upload of AirOS v5.5.x a final time)
This process has worked on a NSM2 and a Bullet so far.
Joe AE6XE
Joe's Firmware Development and Device Restoration Emporium
"You brick 'em and We fix 'em"
YES!!!!
Bob W8ERD
Hi Joe,
I've been looking all over for the write up on how to get my Bullet back up and running. Did you post a more detailed write up yet? If not I'll just keep checking back. Thanks for effort on finding a solution.
Greg K6GHL
It has a start, but the end document will evolve here: http://bloodhound.aredn.org/products/AREDN/wiki/HowTo/Unbrick
Joe AE6XE
I fixed an Airrouter-hp that I bricked, and a Bullet, for someone else.
Airrouter pins 3 9 11 (tx rx gnd) and the bullet uses pin 2,3 for tx/rx and the pin closest to the antenna for GND.
Here is the Airrouter that I fixed. https://www.youtube.com/watch?v=NSyBoudyc8g
73
Jim AG6IF
http://www.aredn.org/comment/1568#comment-1568
Just wondering if you are modifying new NSM2 that have been bricked?
Just got it today, ran test program. Tried to downgrade it to 5.5.x
I did back up with ARDEN U-Boot tester, but I don’t see how to restore from the .backup files.
I really want to modify to run the ARDEN firmware.
Thanks
Lou
NO2C
The symptoms described by trying to 'tftp' the v5.6.x AirOS to the node and it doesn't recover--needs a special option that can only be given from a serial console. I started a write up of doing the serial console method, should be linked to earlier in this forum thread. Do you have an rs232 to tty converter or rasPi to directly connect to the serial console? Is this something you are familiar with? I've got to finish up my write up with all the pics to document this process...
Joe AE6XE
close your browser.
disconnect your CAT5 cable from your PC.
re-attach your CAT5
open the browser to http://192.168.1.20
Thanks
It works great.
Joe AE6XE
load AirOS 5.6.x
then use the GUI to downgrade to AirOS 5.5.x
then use the GUI to upgrade to AREDN (factory)
Thanks
I just Bricked my first Nanostation XW Device. It was running 3.15.1.0 Nanostation XW production and I accidentally (successfully) installed the XM Firmware update to 3.16B01 without any warnings. Now I can't get an IP address off of either port.
Reinforcing the need to have the firmware check for the proper model AND XM/XW before allowing upgrade. Unlike putting the wrong model within the same board version, this seems to render the Ethernet port(s) to be unavailable.
Will attempt TFTP through the serial interface later this afternoon and I'll report back.
Otherwise, TFTP (hold reset for 30 secs while powering on) should help.
Pages