Hi Guys,
I'm trying to do a TFTP downgrade on a PowerBeam-M5-400 running XW.v6.1.2, but it fails due to timeout.
I've tried it both via CMD and TFTP2 as per:
https://help.ubnt.com/hc/en-us/articles/204911324-airMAX-How-to-reset-your-device-with-TFTP-firmware-recovery
I have a copy of http://dl.ubnt.com/firmwares/XW-fw/v5.5.10/XW.v5.5.10-u2.28005.150723.1358.bin in my c:\firmware as suggested.
I have no problem pinging it or connecting to AirOS.
Any ideas what I may have wrong?
You are here
TFTP connect request failed
Fri, 03/16/2018 - 17:41
#1
N1TEW
TFTP connect request failed
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Thanks for your quick response!
I was not correctly in the bootloader, but I am now. I have the alternating LEDs.
I've tried your suggestions, but now I'm receiving an error "Firmware Check Failed" when I use CMD command line. When I use TFTP2 it gets farther than before as the progress bar for "Upgrading Flash" goes all the way across, but "Erasing Flash" shows no progress. It fails with the error "No response from server". The LEDs stop alternating when trying both methods.
Do I need a password?
Any other thoughts?
-neal
Now I'm getting "firmware check failed" as discussed in my other reply.
"I'm trying to do a TFTP downgrade on a PowerBeam-M5-400 running XW.v6.1.2"
It would be most efficient to directly tftp AREDN nightly build to this device "as is". Only the nightly build (or 3.17.1.0RC1) works on this device. The other option is to tftp an older AirOS version that can then upload AREDN using the AirOS UI (an older version that doesn't expect signed firmware). It's a longer path to get from A to B. Downgrading to AirOS v5.5.x is only necessary for 3.16.1.1 and older (which does not work on this device).
Be sure to tftp load the AREDN nightly build rocket-m-xw factory version to the PBE-M5-400/620. The PBE-M5-300 uses the loco-m-xw flavor.
Joe AE6XE
That's exactly what I needed. This shortcut isn't apparent in the documentation. Is it because it's a nightly build and not ready for primetime?
-neal
Joe AE6XE
I have a bricked NanoBridge M2. It had BBHN software installed - wrong file. Support from them is now non-existant, so decided now is the time to switch to AREDN. I am attempting to tftp either an older version of airOS or the AREDN firmware. both efforts result in the same result. The node appears to receive the tftp file then goes into a blinking mode (I thought indicating that actual installation) but that blinking mode never seems to stop. After an hour or more I have had to reset the node and start all over. The original (flawed) BBHN firmware is unchanged. I get the node on my browser but cannot save setup information.
Thoughts?
I assume your flashing with the latest AREDN Nightly build or a recent AirOS.
I suspect your device had a version of AirOs on it newer than 5.5.10 as well prior to flashing.
If all of the above is true I suspect your likely in the situation we saw where for some reason the bootloader gets buggy on flashing devices after having been load with a version of BBHN/AREDN that doesn't support the newest versions of AirOs' bootloader (known as uboot). Latest nightly builds when flashed by TFTP have no known issues loading to devices with latest AirOs versions on them that have not gotten to this corrupted state.
I'm not sure any of our newest fixes have made it possible to recover from this corrupted state without going in via the serial console so you very likely will have to follow the procedure documented here http://bloodhound.aredn.org/products/AREDN/wiki/HowTo/Unbrick to bring the device back to a working state.
Unfortunately the NaonBridge is pretty much a sealed case, as far as I can tell the cap is glued on, the unit I took apart required a Dremel to open it. With that in mind its probably worth trying if you haven't the latest AREDN Development (Nightly) build via TFTP to use that file before you crack it open.
As Conrad said:
http://bloodhound.aredn.org/products/AREDN/wiki/HowTo/Unbrick%C2%A0
or
You can try to load the AREDN nightly build to see if it will "recover" it properly (buy that is untested).
You didn't indicate which version of AirOS that you started with and which version of AREDN you attempted to load. Do you have those details?
P.S. The newer AirOS versions (5.6+) have a newer bootloader that does not unlock the memory chip on some devices, thus, users see a "read-only memory error" on the device when installing a firmware that is not aware of it (ie. BBHN, current AREDN production releases). This has been corrected in the AREDN nightlies.
Since I was able to partially flash this thing, I'm going to keep it cool and make another attempt (New use for a refrigerator.) based on the assumption that it failed when heated up.
What the heck! Who knows?
1) you can power up the device, then able to access the bbhn basic setup screen with a browser? But when you click 'save' it reboots and comes back up as if it was first booted everytime? A screen shot of what you are seeing would be helpful. To get to this state (assuming you've had this device for a long time and older AirOS was originally installed) you would have had to install AirOS via tftp, then upload a newer AirOS version in the UI to get the bootloader upgraded to a version that has this flash write behavior. (the bootloader is only updated when uploading AirOS from within the AirOS UI.)
2) you have tried to tftp the nightly AREDN build, but still same state as #1? You are attempting the tftp upload of this firmware?:
https://downloads.aredn.org/snapshots/trunk/ar71xx/generic/AREDN-develop...
Joe AE6XE
If the device was running AirOs newer than 5.5.10 (which I suspect it was based on the symtoms your telling us) than the bootloader (which starts before AREDN or BBHN or AirOS) puts all the FLASH MEMORY chips in a WRITE PROTECT mode where you can not write to the chip. New AirOS put in the feature to unlock the chip when they put the feature to lock the chip so they had already unlocked the chip when you had flashed BBHN on it. At that point BBHN does NOT know how to unlock the flash chip and thats why you can not save the configuration file because the flash chip is saying "I am write protected you need to move me to read write mode first" (think of the older floppy disks that had a Write Protect switch, its the same thing the switch is in the write protect position on the flash chip). Now this puts you in an interesting position, the boot loader locks the chip and BBHN can not unlock it without changes to its software, to change the software to unlock the chip you need to have already unlocked the flash memory.
The bootloader (uboot) knows how to unlock the chip to flash a new version of the operating system, but this is where we get into the 2nd issue I mentioned where the bootlaoder and its flashing software (a propritary program written by Ubiquiti) have been seen to get into a confused state and has trouble flashing from the old faulty BBHN version to a new working version of AREDN or AirOs. This is why the serial console recovery is required.
If you get a working copy of AREDN on there (via the link we have linked to you to do a SERIAL CONSOLE recovery [not an ssh or telnet session it has to be a LVTTL serial connection]) than yes the device will work perfectly from a software standpoint however as noted the NanoBeam being a sealed device its basically impossible to open and put it back in active service in the same state that you bought it.
Well, keeping it cold didn't make any difference. I blew this one from the very start. I should have:
1. written down the airOS versions before doing anything else (I didn't.)
2. Double-checked the software I was flashing (I didn't.)
3. Made the move to AREDN before even attempting to flash it (I didn't.)
I purchased the unit used. Looks like it had been in service for several years, so I suspect the airOS is older.
So now, it allows me to enter setup information, but when I "save" it there is an error response (Error - unable to save) or some such. If I reboot, the node comes up as before without the setup changes. I can load BBHN or AREDN system upgrades - including the Nightly builds - but when the system reboots, I get the same old BBHN startup screen.
When I attempt to tftp, the led blinks are appropriate, the firmware appears to load (sometimes quickly and sometimes very slowly). The LEDs then go back to a ready to receive tftp input signal and that is where it remains. The longest I have watched this is 4 hours. In any event, when I reboot, I come up with the BBHN input setup screen.
Nothing changes.
Probably will open it up next... Unless someone has a flash of insight...
Thanks for the suggestions. It has been an educational experience - and - isn't that what it is about (Well partly, I guess)?
-Les
1) the exact error message - take a screen shot
2) from the linux command line on the device (access with ssh or telnet): type the command "dmesg" and copy-n-paste the output and upload here.
3) from the linux command line on the device: type the command "cat /dev/mtd0 | grep -i u-boot" and copy-n-paste the output and upload here.
Joe AE6XE
https://www.aredn.org/content/bad-rocket-m5
https://www.aredn.org/content/ubiquity-error-saving-setup
(we called this a bad NAND but latter inside a conference call started going with the belief that this was likely our first exposure to a new AirOs versions as several months later we started declaring not to upgrade to new AirOs versions.)
Remember that node-setup returns an error if it can’t copy/move files to /etc/config which in the case of AREDN/BBHN before we got the flash unlock commit into the Repo would be read only /rom space because jffs2 couldn’t format the flash because it was read only. The response of node-setup is passed by save_setup() and checked in the setup Perl code.
Reference this change to make flash writable on winbond chips:
Change-Id: Ia40783fdfb720901a5981e9d372772739db3caa7 In such cases, the file overlay gets created in RAM and all the remaining AREDN code works correctly. Save in setup works, but reboot looses all the changes since they are not on the flash. The references provided and I believe this issue is due to a miss-match of the flash layout definition between the firmware and the (newer version of the) bootloader. Ends up with no space vs not writable.The commands I gave can confirm the version of the bootloader. I have seen NSM2's recovered, I think was from this state, with the current tftp of the nightly build. Just wanted to confirm this option before cracking open the case. Joe AE6XE MODERATOR: edited formatting - DLQ