Hey gang,
I can not get the firmware to take!
Ubiquiti Bullet M2
Firmware airOS5 for XM board firmware v5.6.15
I have backdated the fw to this but unable to got farther as the GUI says the 5.5.x isn't genuine (read that is no longer required?) .
U-BOOT is a fail/pass. Updating with tfpd64. When loading the firmware it keeps giving "firmware check failed".
Can someone point me in the right direction? I have searched the forum and can't find an answer.
Jason G.
KG4FJC
I can not get the firmware to take!
Ubiquiti Bullet M2
Firmware airOS5 for XM board firmware v5.6.15
I have backdated the fw to this but unable to got farther as the GUI says the 5.5.x isn't genuine (read that is no longer required?) .
U-BOOT is a fail/pass. Updating with tfpd64. When loading the firmware it keeps giving "firmware check failed".
Can someone point me in the right direction? I have searched the forum and can't find an answer.
Jason G.
KG4FJC
Special thanks to Chad Smith on the Facebook group. He suggested I check out there hardware UART inside the bullet. Turns out that booting the device up and running TFTP mode from the command line overrides whatever we were dealing with before. The TFTPD64 program downloaded the firmware same as before, but this time the device accepted it! She came right up like she's supposed to. So here's what I did.
1. disconnected the ethernet cable and antenna from the device
2. removed the large round nut from the base of the antenna connector
3. slid the entire PCB out of the enclosure.
4. located the 4-pin header on the board.
5. pulled an FTDI USB-to-UART adapter out of my desk drawer and made SURE that it was running 3.3vdc
6. used jumper wires to wire the adapter to the 4 pin header
7. Opened up a serial terminal at 115200 to monitor the com port
8. plugged the poe cable back into the Bullet M2
Immediately, I found text appearing in the serial terminal...
U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50)
DRAM: 32 MB
Flash: 8 MB
PCIe WLAN Module found (#1).
Net: eth0,eth1
Board: Ubiquiti Networks XM board (rev 1.0 e202)
Hit any key to stop autoboot:
Right there (very quickly) I hit a key, and the device gave me a command prompt.
9. typed "urecover" and hit enter.
10. Set my computer's network adapter to a static IP of 192.168.1.100
11. connected the LAN side of the PoE adapter directly to the PC
12. Sent the normal firmware bin file using tftpd64 software on Windows.
It accepted the download perfectly. I did the same thing with the second device and it worked correctly, too.
Oh joy of keeping up with Ubiquiti stealthiness to meet the FCC part 15 certification requirements. The newer AC devices require a bit more hand springs and flips to get images installed -- we have to hex patch the AirOS firmware load program, to hack around the checks that prevent our images from loading :) .
Joe AE6XE
1) the current version of AirOS installed -- screen capture from this AirOS page would be ideal.
2) the version of uboot installed in flash (and is often NOT the version packaged in the image of a given version of AirOS).
Example way to capture the uboot version:
root@AE6XE-PleasantsPk-RM2:~# cat /dev/mtd0 | grep -i u-boot
U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07)
Lots of detail that may shed light on the issues, if interested:
Note 1: the OpenWrt community continues to have documentation that says AirOS needs to be rolled back -- we have proven this to not be correct, at points in time. There's always the possibility the latest AirOS or uboot releases will break something.
Note 2: The OpenWrt instructions talk about "tftp recovery" as the process -- this requires a serial cable to the mother board, and to type special uboot options that forces things to happen. The tftp process from holding the reset button does not do a "tftp recovery" .
Note 3: When instructions say to roll back AirOS, this is a misleading instruction. What must be rolled back is the version of the uboot loader installed in a special flash partition. We need to install in flash a version of uboot that is compatible with the image we want to load. When it is said to roll back to, e.g. AirOSv5.x.y.z, this really means, we need the uboot version installed in flash of the device, that is packaged in the image of this version of AirOS.
Note 4: the prescribed way to roll back the version of uboot is to load the AirOS image version that contains the desired uboot version AND to load this image within a booted live AirOS node from the UI prompt. The tftp process does not update uboot on flash, and it continues to stay the same version. (If you connected via serial cable to the mother board and gave a uboot command line option, you could put tftp in recovery mode and update the uboot version.)
Example: the version of uboot 1.1.4.2-gd9d730c7 packaged with in the current Bullet XM image v6.3.6.33330.2108.2001:
joe@JoeMain:/mnt/c/Users/joe.000/Downloads$ binwalk XM.v6.3.6.33330.210818.2001.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Ubiquiti firmware header, header size: 264 bytes, ~CRC32: 0x3E8F8937, version: "XM.ar7240.v6.3.6.33330.210818.2001"
268 0x10C Ubiquiti partition header, header size: 56 bytes, name: "PARTu-boot", base address: 0x9F000000, data size: 230544 bytes
149396 0x24794 U-Boot version string, "U-Boot 1.1.4.2-gd9d730c7 (Feb 14 2020 - 10:52:59)"
149716 0x248D4 CRC32 polynomial table, big endian
171396 0x29D84 Ubiquiti firmware header, header size: 264 bytes, ~CRC32: 0x65746831, version: " APP Magic mismatch, addr=%x, magic=%x "
223368 0x36888 CRC32 polynomial table, big endian
230876 0x385DC Ubiquiti partition header, header size: 56 bytes, name: "PARTkernel", base address: 0x9F050000, data size: 1034800 bytes
230932 0x38614 uImage header, header size: 64 bytes, header CRC: 0xDEB033C0, created: 2021-08-18 17:02:22, image size: 1034736 bytes, Data Address: 0x80002000, Entry Point: 0x80002000, data CRC: 0xA2D819CC, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Ubiquiti Linux-2.6.32.71"
230996 0x38654 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2935428 bytes
1265740 0x13504C Ubiquiti partition header, header size: 56 bytes, name: "PARTrootfs", base address: 0x9F150000, data size: 6291456 bytes
1265796 0x135084 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 6095940 bytes, 1397 inodes, blocksize: 131072 bytes, created: 2021-08-18 17:02:24
7557316 0x7350C4 gzip compressed data, from Unix, last modified: 2021-08-18 17:01:26
7599576 0x73F5D8 gzip compressed data, from Unix, last modified: 2017-05-22 12:00:25
7599873 0x73F701 Ubiquiti end header, header size: 12 bytes, cumulative ~CRC32: 0xAA1FC336
Joe AE6XE
U-Boot 1.1.4.2-s445 (Sep 6 2010 - 14:46:33) AirGrid-M5-25 Works KE8MVM
U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07) bullet-m2-xm Works nc8q
U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07) NanoBridge-M9 Works nc8q
U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07) Nanostation-M3-xm Works nc8q
U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07) Nanostation-M3-xm Works nc8q
U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07) Nanostation-M5-xm Works KE8MVM
U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07) Nanostation-M9 Works nc8q
U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50) ? Fails nr0x ?
U-Boot 1.1.4-s776 (Nov 27 2013 - 15:58:45) PBE-M5-400-xw Works nc8q
U-Boot 1.1.4-s958 (Jun 10 2015 - 10:56:20) Loco-M2-xw Works nc8q
U-Boot 1.1.4-s958 (Jun 10 2015 - 10:56:20) Loco-M2-xw Works nc8q
All recent AREDN firmware images form ~2016 are fixed with correct partition definitions
and no longer soft-brick the device, regardless of which uboot version.
I'm doing everything I can to build up the AREDN network in my area, Knoxville, TN, but everywhere I look, there's a road block. I am not a computer scientist, and this tech is outside of my current abilities. Is there anyone who can help me out? I'll put in the effort, but it's overwhelming building this by myself.
Thomas KM4TBQ
You did not say what model of Ubiquiti radios you have, or any indication of what is failing, and what you have tried. If you want our help, you need to be out eyes and fingers.
Yeah, my apologies. upon further review, my inquiry was extremely vague, I was at witts end when I wrote it.I know NOTHING about computers, and every step of the way is a monumental pain. I was also pulling all-nighters for 5 out of 7 days for several weeks. It's not very healthy, and I DO NOT recommend doing that. Being ignorant is rough, boy, lemme tell ya. hopefully I clarified the issue above.
Thank you,
Thomas, KM4TBQ
Thanks again
73, Chuck
Thanks a lot for telling me that. I was trying to play it safe because I'm very invested now and can't jeopardize losing contact with you experts here. I started an account after meeting Andre a few years back, but I just recently got into AREDN seriously, so I'm a noob.....noob at AREDN, computers and forums.
Thanks again, I'm very relieved. Unless you have a reason not to, I would like to try re-posting the post that has caused all this hassle?
Thomas
Hi, Thomas:
73, Chuck
Hello again, Chuck, always very helpful,
1. Flashing: Bullet M2 XM, NanoStation Loco M2 XM, TWO Rocket M2s XM & NanoBeam M2 XM.
2. Firmware: I always and ONLY run the supported FW, (dark green), and always check the forums for a particular node before doing so, to triple check.
3. Instructions: I screen-shotted, formed a PDF and printed a hard copy of the instructions + checklist right off the AREDN Instructions page.
4. Failure: The failure is at the very end when the FW should be loading onto the device.
- I've used the three recommended TFTP programs recommended here, (different settings, block sizes, etc).
- I've successfully flashed over two dozen nodes using this same method, (an absolute miracle),
- Error messages include: "Error on server", "Firmware check failed", "timeout occurred", "Error #2", (others I didn't write down, but similar).
I read everything I could find here regarding this issue, but nothing seems to work. One bad radio is one thing, but five is a hard pill to swallow. I know that being older XMs with low memory has got to play a role, but numerous people have flashed them, so I know it can be done.
Well recently, I decided to fully commit to setting up a network, even if I have to do it single-handedly. I make more money now than back then, and REALLY want to see AREDN succeed in my area, (everywhere). I've aqcuired dozens of radios and antennas, (yes, my kitchen looks like the swapmeet at Hamvention), I'm working on/have already acquired tower and node-site MOUs, recruiting the local guys who also gave up when we all were left holding our, , and gathering new guys to participate.( Sorry, I felt inclined to give you some context). All that to say, AREDN WILL be up and running in east Tennessee or I will die in the process.
(change gears again)
It seems like back in 2020 I vaguely remember loading older factory FW before flashing the AREDN FW, but after reading here, it appears that's no longer necessary? The two Rocket M2s have a USB port, but won't flash the USB FW, but will (act like) it flashes the plain/non-USB M2 FW. It says it's successful, but goes back into tftp mode right after the (fake) flash.
I have some other details I can touch on if you need, but I'm pretty sure this novel I wrote is enough to digest this go-around. Thanks a million for even responding. I can't tell you how crummy it is being cut off from the forums. There is no other place to get answers, and you guys are truly priceless. Which reminds me, I am prepared to hire one of you guys to pick apart my final draft of this network plan once I get there. It's all hodge-podge at the moment, because i'm still learning the fundamentals. Basically, I don't know what I don' t know, but can say I'm roughly 70% there.
Again, thank you,
Thomas, KM4TBQ
Oh wow, I just noticed that these questions are different from the previous ones that I answered but got removed...so I'm NOT losing my mind, they DID disappear. OK, this is going to take some time to get that info to you. I hate that you had to type all over again. You are a gentleman and a scholar. I'll get working on it ASAP.
Thanks a million,
73, Thomas
Here you go, Chuck:
1. Please post the model of Bullet M2. I want to know if it is a XM, or XW.
Both XM
2. Please post the version of firmware that is on the Bullet M2.
6 devices, 2 bullets: v6.1.9 / v6.2.0 / 5.6.11
3. Please post the filename of firmware that you are flashing onto the Bullet M2.
aredn-3.22.8.0-ar71xx-generic-ubnt-bullet-m-squashfs-factory.bin
4. Please post your computer's Operating System and version.
Windows 7 Home Premium, 64 bit and Windows 10
5. Please post the version of TFTP software you are using to flash the Bullet M2.
TFTP64, PumpKIN and native terminal
6. Please post the URL of the instructions you are following
https://arednmesh.readthedocs.io/en/latest/arednGettingStarted/installing_firmware.html
7. Please post the exact error message.
Server stops the transfer.Error#2: Firmware check failed
8. Please post the command immediately before the error.
I click PUT FILE in the UI for the 2 programs and for terminal: tftp.exe –I
* I have successfully flashed numerous devices with these same exact methods.
Thanks for your time, Thomas, KM4TBQ
I appreciate all your help, and I will update you with any progress here for some closure, (whether I get them running or turn them into rifle targets).
I sincerely appreciate your time and expertise,
Thomas, KM4TBQ
As NR0X described above, the serial connection menu comes up very quickly, and I had to hit return within a few seconds to prevent the Bullet M5 from continuing the boot process. Then, I typed 'urescue' at the serial prompt in the PuTTY window. All options on the Bullet serial communications menu can be seen with use of the 'help' command. From there, the Bullet was in tftp mode and the standard tftp procedure as outlined in the Ubiquiti First Install docs ( https://arednmesh.readthedocs.io/en/latest/arednGettingStarted/installin... ) worked flawlessly. I, then, was able to setup the device normally.
Generally, I have been having more issues flashing older devices such as Nanostation M2 XM, Bullet M2/M5 XM, and Nanostation Loco M2 XM but was glad that this rescue procedure worked. I only keep these devices around because a number of folks I support have them but almost never deploy them in the field in any fashion. These might have a use case in local WiFi mode, perhaps. It is also better to have them and not need them than need them and not have them. My longer term plan is to eventually sunset all devices which have the XM model and especially the Bullets and Locos. I hope these additional comments can help the next amateur encountering this particular issue. My thanks to NR0X for the excellent notes that got me started on the fix.
Thank you. This is way beyond my ability, but I guess I have no choice at this point. If it was one old device I would just walk away, but FIVE? Yeah, I guess i'll have to have a go at it. I copied your instructions and just ordered that adapter. Thanks again for your time.
Update 11/30/22:
-I finally received this cord you recommended, printed off instructions/screenshots from the forum and assembled a makeshift instruction sheet and printed it. I will attempt to flash these five Ubiquiti XMs ASAP. Thanks for all the info so far, hopefully I can salvage these nodes.
from: firmware release version
to: firmware bin file.
Does
https://www.arednmesh.org/homepage?page=1
"The AREDN simplified firmware filename standard has been changed to the default OpenWRT convention to leverage data files created at build time for future automation of firmware selection."
apply?
73, Chuck
Since these are older XM devices, some but not all are experiencing flashing issues BUT not to this extent. This time some surgery was needed in order to resurrect the device when upgrading from 3.22.6.0 => 3.22.8.0. I'm not sure whether this is a firmware issue or just a peculiarity with these devices using the latest firmware. Prior versions to 3.22.x.x generally wouldn't take due to out of memory issues and in some cases took a number of retries and at other times a factory reflash. Also, I have seen the need to de-power and re-power the node after the 3.22.8.0 is installed - sometimes. It is not consistent. Maybe a timing issue specific to the device, perhaps. I hope that helps...
Can someone explain why my follow up post is not here? I spent over an hour typing it out, and two members were trying to help me solve a problem, it contained info that would help them help me. Also, the two peoples' posts are also gone. Do posts just arbitrarily get removed? Is the website just buggy? Because there is no way any guidelines were violated in either of our three posts that are now missing. I really hope i'm just overlooking something, because that's ridiculous if you just take posts down for no reason. I'm spearheading a major project that greatly promotes AREDN, and would be greatly disappointed if this is what's happened...especially after I JUST donated money. Lastly, If it was removed, I was given no explanation of why, which deters me from ever posting again. I just dropped a few thousand dollars on equipment and have dedicated hundreds of hours already to pushing this service along into my area. PLEASE tell me that's not what has happened. Can somebody please clear this up for me? Thank you.
Maybe, try a different browser or computer?
Have a great evening....I sure will now.