Do not flash a Ubiquiti device that is running, or has been running, airOS version 5.6 or higher with AREDN firmware. We have become aware of a change that may be incompatible with current firmware images. We are looking into the concerns raised and will post more details as they are determined.
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
From the openwrt wiki (http://wiki.openwrt.org/toh/ubiquiti/airmaxm):
I've bricked my NSM5 with openwrt firmware. I can upload firmware XW.v5.6.2.27929.150716.1149.bin via tft (i've also a beta v5.6.3....) , but the device don't answer after reboot. Is there a way to repair it?
I've tested several Firmware for the NSM5, because the XW based Devices from ubnt makes heavy pulsed noise on 145 Mhz and disturb our 2m Relais DB0NHM.
(Sorry only in German: http://www.darc.de/h18 )
The problem is, 4 of this devices hang in an high of 35 metres, without a chance to climb on to the mast in the next time. We has bring them up in the last August week.
'73 Peter
Peter,
Can you clarify the scenario? Did you:
A) buy and receive a device with airOS5.6.x and attempted to install AREDN?
B) have an existing AREDN/BBHN/Other OpenWRT based device and attempted to install airOS5.6.x?
We have been speculating on the issues, but need to do further investigation to fully understand. Assuming your scenario is option 'B'...
According to OpenWRT Ubiquiti has changed the usage of flash in airOS5.6.x. To compare old and new, we can see the difference in the attached picture. AirOS5.6.x has a smaller rootfs (the linux file system of the node) and left 768k of flash memory unallocated at the end for some yet-to-be-discovered reason.
Note that the "EEPROM" data is the ART (Atheros Radio Test) or Calibration data that is unique to a given device and created at manufacture time with high cost equipment. If this data is lost, per OpenWRT, "If this is wiped / corrupted ath radios will not come up anymore." http://wiki.openwrt.org/doc/howto/restore_art_partition
Have you attempted to reload the AREDN 'factory' image via tftp for the device? Possibly the EEPROM (ART) data is still the last 64kb in flash and unaffected for AREDN to still function, but AirOS5.6.x can't find any of this device specific information to function with a different (smaller) partition map.
Joe AE6XE
Hi Joe,
a) it is brandnew NSM 5 (July 2015). It comes with Firmware 5.5.10. I've testing serveral Firmware (aredn,openwrt, bb-mesh, hamnet Projekt from DARC district passau, a mixed self made Firmware (Hamnet Passau, with ath-modules from aredn). All of this works fine. Then i get a Beta Firmware from ubnt, which should be reduce the interferences to 145Mhz. I upload this firmware, but it does not help, but the firmware work.
Then i test openwrt daily build. Openwrt start, telnet to 192.168.1.1 works. Luci don't work (cgi-bin missing)
ok. i reload 5.6.2. tftp works. The LEDs shows same behavior as before. But the device don't show a frontend any more (no ping, no ssh, no http)
Now i test to tftp aredn, openwrt, and so one. tftp quits with an Error with questionmarks (???????). If i tftp 5.6.2, the firmware load nice an then same behavior. no ping, no ssh, no http.
Tftp works. I can load all firmware from ubnt higher then 5.6.x
Greetings
Peter
Peter, we're looking at the issues and will take a period of time to fully understand. I can only speculate that the EEPROM or ART device specific data has become corrupt.
For others reading this thread, in this 'test', upgrading an XM5.5.x node to XM5.6.x node converts the flash partition map as if you received a new ubnt device with XM5.6.x pre-loaded. It is reported to work. However, there is no current path to revert back to any OpenWRT based image and attempts to do so, per the OpenWRT post will brick the device, which appears to mean corrupting the ART partition.
Peter, it would be best to find some way to inspect the state of the flash before proceeding any further. Best guess is that you'd need to follow the OpenWRT ART recovery steps (to the new flash layout addresses in 5.6.x) and only load XM5.6.x on the node until patches are released for OpenWRT based images.
Joe AE6XE
Hi Joe,
In the ddr-wrt forum i've read that ubnt lock something in the flash
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=285332&sid=ce56dc7c91f96c5b72e9acf18edff293
this firmware is possible to load via tftp. I can ping 192.168.1.1 (!!). http://192.168.1.1 show one moment the luci configuration site but can not load http://192.168.1.1/cgi-bin/luci
the link to dd-wrt firmware:
http://dd-wrt.com/site/support/other-downloads?path=others%2Feko%2FBrainSlayer-V24-preSP2%2F
Peter DB1OFH
I've extract the latest beta firmware from ubnt.
Here some infos about it:
Scan Time: 2015-09-25 12:13:22
Signatures: 193
Target File: /daten02/pub/afu/ubiquiti/ubnt/ubiquiti/XW.v5.6.3-beta3.28377.150922.1830.bin
MD5 Checksum: c7227eeeb31a1c5a8fbcbfc7f70587f0
DECIMAL HEX DESCRIPTION
-------------------------------------------------------------------------------------------------------
228912 0x37E30 uImage header, header size: 64 bytes, header CRC: 0x4A2F55E8, created: Tue Sep 22 17:31:31 2015, image size: 952264 bytes, Data Address: 0x80002000, Entry Point: 0x80002000, data CRC: 0x533245A9, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Ubiquiti Linux-2.6.32.67"
228976 0x37E70 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2783164 bytes
1181304 0x120678 Squashfs filesystem, little endian, version 4.0, compression: lzma, size: 5877613 bytes, 1185 inodes, blocksize: 131072 bytes, created: Tue Sep 22 17:31:33 2015
7210680 0x6E06B8 gzip compressed data, from Unix, last modified: Tue Sep 22 17:30:15 2015
FW_SIZE='7238281'
HEADER_TYPE=''
HEADER_SIZE=''
HEADER_IMAGE_SIZE='1181304'
HEADER_IMAGE_OFFSET='0'
FOOTER_SIZE='2768'
FOOTER_OFFSET='7235513'
FS_TYPE='squashfs'
FS_OFFSET='1181304'
FS_COMPRESSION='lzma'
FS_BLOCKSIZE='131072'
ENDIANESS='-le'
MKFS="./src/others/squashfs-4.2-official/mksquashfs"
From interesting is the init file in the root patch with the mount options :
#!/bin/sh
#
# crucial mountpoints
mount -t proc none /proc
mount -t sysfs none /sys
mount -n tmpfs /var -t tmpfs -o size=9437184
tar cf /tmp/devtmp.tar /dev
mount dev /dev -t tmpfs
@Joe:
I backup the ART-Partition from another NSM5 and manipulate the system-init in original firmware to restore it automaticly.
Tx
Peter
Peter, Did the restore of EEPROM (ART) data make the node functional again? on XM5.6.x at this point? Did it work?
Also, note that AREDN and BBHN firmware derives the IP addresses from the MAC addresses, which are part of the EEPROM (device specific) data. If you copied this data over from another node, and at some point install AREDN on both nodes, there will be an IP conflict.
Of even more important note is that each device is individually calibrated on the assembly line via automated tools, even if the unit does boot up, is RF characteristics may no longer match specs meaning anything from shorter range to 100% non decodable packets even when one is in the same room (or somewhere in-between or some combination of scenarios)
Hello Joe,
i have build an firmware based on 5.6.2. But i can not upload it via tftp. Now i open a thread in ubnt beta-Forum.
With this firmware my Nanostation XW boot again:
ftp://ftp.dd-wrt.com/betas/2015/10-09-2015-r27944/ubnt_NanoStation_M5-XW/
'73 Peter
When purchasing a device is it possible to specify one that is a version older than airOS 5.6?
We have developed the following utility to help determine if your device is compatible. Download the AREDN U-Boot Test Setup Program. Requires Windows 7 or higher and Microsoft .NET Framework 4.5.
We have added a backup feature to the AREDN U-Boot Test program to backup your critical partitions.
Download here: AREDN U-Boot Test
I have been unable to find any version 5.5 world Ubiquiti devices in 5Ghz. I am finding the 5.6 version world devices are even backordered for 2 months. If anyone has found a source let us all know. Will the version 5.5 devices use the new 5Ghz frequencies around 5.9Ghz?
All of the supported 5Ghz devices support the new expanded channels (5.9Ghz). (It does not require a "world" edition.)
Also, some of the 5.6.2 versions are still ok. It depends on the version of the embedded U-Boot (think of it as the bootloader).
We have released a tool for you to check the U-Boot version and is found on the software page.
We are still researching impacts, but, here is more detail from the OpenWRT site.
-----
*Special Firmware Note: AirOS XM.v5.5.X images used U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07). The OpenWRT image can be successfully flashed onto these versions of firmware. However, in July 2015 Ubiquiti released a new version of firmware XM.v5.6.X. With this firmware a new U-Boot version was released, U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50). The newer U-Boot version changes the memory size and starting address for rootfs, cfg, and EEPROM. LOADING AN OPENWRT IMAGE ON A U-Boot 1.1.4.2-s956 WILL CAUSE THE DEVICE TO BE BRICKED!!!
If the device has XM.v5.6.X an older version of XM firmware can be loaded from the AirOS webgui (for example XM.v5.5.10) and U-Boot will be overwritten with the older version. OpenWRT can then be loaded onto the device successfully.
U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07) -- THIS IS THE GOOD, AREDN SUPPORTED VERSION
U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50) -- THIS IS THE PROBLEMATIC VERSION