You are here

Ubiquiti airOS 5.6.2 ALERT

21 posts / 0 new
Last post
K5DLQ
K5DLQ's picture
Ubiquiti airOS 5.6.2 ALERT

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.

VA2MVC
From the openwrt wiki (http:/

From the openwrt wiki (http://wiki.openwrt.org/toh/ubiquiti/airmaxm):

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.

DB1OFH
Possible to Repair?

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?

DB1OFH
Background why I'm bricked my NSM 5

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

 

AE6XE
AE6XE's picture
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

 

Image Attachments: 
DB1OFH
Hi Joe,

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

 

AE6XE
AE6XE's picture
Peter,  we're looking at the

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  

 

DB1OFH
Hi Joe,

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

DB1OFH
I've extract the latest beta

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
 

 

 

 

DB1OFH
@Joe:

@Joe:

I backup the ART-Partition from another NSM5 and manipulate the system-init in original firmware to restore it automaticly.

Tx

Peter

AE6XE
AE6XE's picture
Peter,  Did the restore of

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.   

KG6JEI
Of even more important note

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)

DB1OFH
Hello Joe,

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.

 

DB1OFH
With this firmware my

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

w7rej
RE: Ubiquiti airOS 5.6 ALERT

When purchasing a device is it possible to specify one that is a version older than airOS 5.6?

KG6JEI
That will depend on your

That will depend on your vendor, the version of the OS is (or at least was when I last ordered ) stamped on the outside of the box.

So far I've yet to hear of any off the shelf coming with this version, it's so far only been persons whom have manually chosen to upgrade their devices but it wouldn't hurt to spec before ordering.

Most important thing is that if you do receive one that is running newer AirOS is not to flash and just give some breathing room to sort it all out. what effect the change has, we need the time to make sure we fully analyze it and don't rush to any conclusions and evaluate it correctly.

K5DLQ
K5DLQ's picture
AREDN U-Boot Test Program

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.

K5DLQ
K5DLQ's picture
AREDN U-Boot Test Program UPDATE

We have added a backup feature to the AREDN U-Boot Test program to backup your critical partitions.

Download here: AREDN U-Boot Test

KI6FJA
What to buy then?

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?

K5DLQ
K5DLQ's picture
All of the supported 5Ghz

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.

K5DLQ
K5DLQ's picture
We are still researching

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

#: name size offset mask_flags
0: u-boot 0x00040000 0x00000000 0
1: u-boot-env 0x00010000 0x00040000 0
2: kernel 0x00100000 0x00050000 0
3: rootfs 0x00660000 0x00150000 0
4: cfg 0x00040000 0x007b0000 0
5: EEPROM 0x00010000 0x007f0000 0

U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50) -- THIS IS THE PROBLEMATIC VERSION

#: name size offset mask_flags
0: u-boot 0x00040000 0x00000000 0
1: u-boot-env 0x00010000 0x00040000 0
2: kernel 0x00100000 0x00050000 0
3: rootfs 0x005a0000 0x00150000 0
4: cfg 0x00040000 0x006f0000 0
5: EEPROM 0x00010000 0x00730000 0

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer