Reviving the Ubiquiti loco M5
I’ve had a pair of Ubiquiti NanoStation loco M5 devices operating continually for around 5 years. They were finally decommissioned in 2020, but recently were revived for a project at work temporarily bridging two buildings while I transferred premesis equipment. I suppose it goes without saying that of course I was pressed for time and of course this would be a simple in-and-out. It also goes without saying that of course things didn’t work out as intended and of course these device decided that their previous life of working 24/7 was over and retirement was in full swing.
Hours went by, and every time I actually got the devices to boot and grab an IP they would mysteriously disappear on the network after any configuration changes. A seemingly endless cycle of reboots, resets, and re-applicaiton of configs and I felt like Jerry Seinfeld in the lobby of The Chinese Restaurant. After wishing, begging the Silicon Gods for mercy, they miraculously held a config. They booted back up and linked. Not wont for disrupting the delicate balance I just afforded myself, I tiptoed out convincing myself “Sure, they had been working for years with not even a peep - nothing to worry about”. Not two hours later, they were down. Not three and an ethernet cable was run. My hours of hair-pulling were enshrined in two white plastic figurines and a long blue stretch of Cat6.
All said and done, I got them home and now neither were grabbing IPs, regardless of how many times I power cycled. There wasn’t a hint of network traffic. No worries - I’ll take any excuse to break out the serial cable and start poking around.
Opening the case we find an unpopulated header, J5. Heading over to the OpenWRT Table of Hardware shows us the pinout.
I’m going to use Minicom pointed at ttyUSB0, baud 115200, 8N1. Don’t forget to disable hardware flow control and enable software flow control under cOnfigure Minicom -> Serial port setup.
$ minicom -D /dev/ttyUSB0
Adding a header, powering up the device, the hardware appears to initialize and we get…
U-Boot 1.1.4-gb02ecccc (Feb 14 2020 - 10:53:11)
DRAM: 64 MB
Flash: 8 MB (0xc2, 0x20, 0x17)
Net: AR8032 Detected
eth0, eth1
Board: Ubiquiti Networks AR9342 board (e845-32564.1122.0030)
Radio: 0777:e845
Reset: Normal
Hit any key to stop autoboot: 0
## Booting image at 9f050000 ...
Image Name: MIPS Ubiquiti Linux-2.6.32.71
Created: 2020-07-15 13:28:25 UTC
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 979899 Bytes = 956.9 kB
Load Address: 80002000
Entry Point: 80002000
Verifying Checksum at 0x9f050040 ...OK
Uncompressing Kernel Image ... OK
Starting kernel ...
Booting Atheros AR934x
…nowhere. It sits mocking me with it’s single blinking eye LED, going no
further.
Well, it may be a hardware issue. There’s no damage visible on the PCB or evidence of water intrusion. If a fault exists, it might be a component. This project might be hitting a dead end. No sense in wasting time, however; let’s head back to OpenWRT and grab the latest bin for this device (19.07.7 at the time of writing). My particular units are the “newer” XW model, not the XM. The XW models use the Atheros AR9342 chips which can be seen in the initial serial output. I have attempted to upload an XM image to the XW model and the firmware check appropriately rejects it.
With the device powered off, hold the reset button, and power back on. Hold the reset button until you get alternating flashing lights on the device indicating the TFTP mode is initializing. On the serial output, you’ll see:
BOOTP broadcast 1
Sending discovery response
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 28
DHCP client bound to address 192.168.1.108
Starting TFTP server...
Using eth0 (192.168.1.108), address: 0x81000000
Will reset device configuration (Reset button active after 10 seconds).
Erasing sector 123..126
First 0x7b last 0x7e sector size 0x10000
.... done
Waiting for connection: Sending discovery response
If momentarily paused at “Starting TFTP server…”, continue holding the reset button until the configuration is erased. At that point it will be ready for a TFTP connection. Hop over to the tftp utility or your equivalent. Be sure to put your client in binary mode and enable tracing for some additional feedback.
$ tftp 192.168.1.108
tftp> binary
tftp> trace
Packet tracing on.
When ready, upload the image and the M5 takes care of the rest.
tftp> put openwrt-19.07.7-ar71xx-generic-ubnt-loco-m-xw-squashfs-factory.bin
On the other end, you’ll see the M5 receiving the data, writing the flash sectors, and confirmation when the update is complete.
Received 4194716 bytes
Firmware Version: XW.ar934x.v6.0.4-42.OpenWrt-r11306-c4a6851c72
Setting U-Boot environment variables
Un-Protected 1 sectors
Erasing Flash.... done
Erased 1 sectors
Writing to Flash... write addr: 9f040000
done
Protected 1 sectors
Copying partition 'kernel' to flash memory:
First 0x5 last 0x14 sector size 0x10000
................ done
write addr: 9f050000
Copying partition 'rootfs' to flash memory:
First 0x15 last 0x7a sector size 0x10000
................ done
write addr: 9f150000
Firmware update complete.
Resetting...
Okay, so the moment of truth. Are we going to get off, scot-free? Is it possible it’s just going to work?
U-Boot 1.1.4-gb02ecccc (Feb 14 2020 - 10:53:11)
DRAM: 64 MB
Flash: 8 MB (0xc2, 0x20, 0x17)
Net: AR8032 Detected
eth0, eth1
Board: Ubiquiti Networks AR9342 board (e845-32564.1122.0030)
Radio: 0777:e845
Reset: Normal
Hit any key to stop autoboot: 0
## Booting image at 9f050000 ...
Image Name: MIPS OpenWrt Linux-4.14.221
Created: 2021-02-15 15:22:37 UTC
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 1589435 Bytes = 1.5 MB
Load Address: 80060000
Entry Point: 80060000
Verifying Checksum at 0x9f050040 ...OK
Uncompressing Kernel Image ... OK
Starting kernel ...
[ 0.000000] Linux version 4.14.221 (builder@buildhost) (gcc version 7.5.0 (1
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 0001974c (MIPS 74Kc)
[ 0.000000] SoC: Atheros AR9342 rev 2
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 04000000 @ 00000000 (usable)
...
Turns out, yeah! It boots up and provides a serial terminal. We use UCI to set DHCP on the ethernet port to connect and configure, and to stop the DHCP server from attempting to hand out leases. Restart the network service and we’ve got a fully functioning device with OpenWRT.
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 19.07.7, r11306-c4a6851c72
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:/# uci set network.lan.proto=dhcp
root@OpenWrt:/# uci commit && service network restart
Whaddya know? The devices appear to be stable and I haven’t run in to any issues yet, though they certainly won’t be seeing a production environment and can rest easy in retirement. Perhaps we’ll see them again in a future project, but until then, thanks for stopping by and see you around!