OpenWRT Notes

We are transitioning our equipment to OpenWRT

Docs: http://wiki.openwrt.org/doc/start

OpenWRT installs on recent Ubiquiti products

Ubiquiti AirOS radios, are embedded devices that often use the U-Boot boot loader. This loader allows for different sized partitions on the internal flash chip of the device. If the start or size of the flash partitions doesn't match with the uploaded firmware, then it often gives you a checksum error when you try to tftp it to the device. This can also happen if you try to flash the wrong architecture. Whats worse is, it might actually flash, but just behave erratically. Eg. resetting back to factory defaults, or not correctly mounting root with the mount_root command in recovery mode. When in doubt test that it will save configs and keep them over a reboot, and that you can go into the OpenWRT recovery mode and access the old config.

Most of these devices have a serial port header that you can put a USB TTL serial dongle on to interact with the boot process or change partition sizes etc... Be sure to use a good quality dongle that works at 3.3v or you might see garbled text. Though the characters you type are received, and mostly echoed correctly. Also when you re-flash to OpenWRT it may clear up when OpenWRT starts booting.

There are a couple of ways to change the layouts to match. You can re compile openWRT to match the U-Boot partitions, you can use a long reset to access the tftp firmware upload feature, and upload an older Ubiquiti image that matches, or you can edit the device's layout over the serial console in U-boot. More recently Ubiquiti has started cryptographically signing their images which can cause the "Firmware check failed" error for non-signed images. Though there are several ways of uploading firmware and you may find one that dosn't check. The known ways are:

• Via the factory firmware web UI, which does check.
• Via ssh and a shell command, whcih may check
• The long reset tftp server, which does check.
• The urescue console command without the -f -e.
• urescue with the -f -e.
• The tftpboot console command.
• Via first uploading, and running a special initramfs version of OpenWRT that can then save a normal version to EPROM.
• mm - memory modify, (requires a send expect script)

If you are already using an older non-signed image, try any v5.5.X version, like XW.v5.5.10 or XM.v5.5.10. Flash this image from the recovery mode or by using the serial port and the command:

urescue -f -e

It's flash layout will match OpenWRT's, and then you should be able to flash OpenWRT normally. Here are some older XM and XW series AirOS firmware, a good starting point for flashing OpenWRT.

• XM.v5.5.8.bin
• XM.v5.5.10.bin
• XW.v5.5.9.bin
• XW.v5.5.10.bin

Also note that newer versions of U-boot may not have all the commands you're used to, so if you have an older trusted version for that architecture, you may be able to upload and re-flash that partition with it. Be very sure you have a compatible version of U-boot because you could easily brick your device!

Mount_Root Problems

If mount_root seems to be broken, you can mount the configs manually like so:

mount -t jffs2 /dev/mtdblock? /mnt

Where the '?' is a digit. You can then compare what you get for differences.

Accessing via the Web UI, or SSH CLI

First you need to verify the IP address of your device. Newer devices will try to get a DHCP lease over the Ethernet or an open WiFi AP. Also sometimes ping responses are turned off. So if it's not the default IP of 192.168.1.20, a good way to find your device is:

nmap -sn '192.168.1.*'

Once you have the IP, then you can either connect to it in a browser, (Unifi devices don't have web access), or you can ssh in like so:

ssh ubnt@192.168.1.20

Password 'ubnt'.

There are a couple of different ways to flash new firmware from the CLI. First you use scp from the device CLI, to copy the new image into tmp. Rename the image to fwupdate.bin, and or use something like this to reflash it:

mv /tmp/openwrt-ar71xx-generic-ubnt-unifi-squashfs-factory.bin /tmp/fwupdate.bin
cd /tmp
nohup syswrapper.sh upgrade2

or,

fwupdate.real -m openwrt-ar71xx-generic-ubnt-unifi-squashfs-factory.bin -d

Often at the CLI prompt, the flash partitions will be referred to as mmc devices eg. /dev/mmcblk0??, or /sys/block/mmcblk0/mmcblk0??. In some hardware versions, they may be write protected or locked. For some unifi devices there is a magic command to unlock them:

# #Unlock mtd partitions with some magic:
# echo "5edfacbf" > /proc/ubnthal/.uf

Then you can sometimes write the new images to these partitions directly from the CLI using dd.

Initramfs images

An initramfs is basically used for testing purposes and is loaded in RAM only to boot the system without the need to replace your original software. However, once you have that image running correctly, you can use the builtin sysupgrade procedure to write a recent version of OpenWRT to the flash.

Typically you tftp the image to ram with a command simular to:

ar7240> tftpboot 0x80000000 openwrt-19.07.2-ar71xx-generic-ubnt-unifi-initramfs-kernel.bin

Installation on Ubiquiti Bullet

Same as for a NanoStation below, though the serial header pins are not labeled So counting from the antenna end the pins are:

1. pin = GND
2. pin = Tx
3. pin = Rx
4. pin = 3.3v

There is usually no reason to connect pin 4.

Installation on Ubiquiti NanoStation2 Loco

OpenWRT wiki page: http://wiki.openwrt.org/toh/ubiquiti/nanostation

• Downloaded backfire 10.03 for ubiquity (openwrt-atheros-ubnt2-squashfs.bin)
  • * Now using AA image (openwrt-ar71xx-generic-ubnt-bullet-m-squashfs-factoryAA.bin) --JamieC
• Load OpenWRT image using the AirOS upgrade feature.
• Or, reset NanoStation2 if the web interface is not accessible. Hold down reset and connect power, wait for signal strength leds to flash and then stop. The default ip under stock AirOS will be 192.168.1.20
  *** Note: Hold the reset button until you see the red LED flash, it should flash several LEDs including the red one 3 times, then go into a cycling pattern with red and green LEDs cycling back and forth. Its not ready until it goes into the cycling pattern with red and other LEDs. --JamieC
• Device IP will be 192.168.1.1 after reboot.

If you are configuring OpenWRT for bridging, you must select "custom" for the bridging interface and enter a list of interfaces to bridge. Interfaces are not configured to be members of a bridge as in linux, the LAN interface is configured to create a bridge and include itself and other interfaces.

-- IanBaber - 21 Jun 2010

Apparently Backfire was a little too green at that time to have all the cool packages in it just yet. You can downgrade by sshing into the the unit and doing something like this:

wget http://downloads.openwrt.org/kamikaze/8.09.2/atheros/openwrt-atheros-combined.squashfs.img
sysupgrade openwrt-atheros-combined.squashfs.img

Though I'm not sure if we lose any customizations for the NS2 by doing this. To get the X-WRT gui add a package source line for the X-WRT repository:

src/gz snapshots http://downloads.openwrt.org/kamikaze/8.09.2/atheros/packages
src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/8.09/brcm-2.4/packages

Installation on Ubiquiti NanoStation M5

Install Directions

https://wiki.openwrt.org/toh/ubiquiti/nanostationm5

Notes about Ubiquiti AirmaxM: https://openwrt.org/toh/ubiquiti/airmaxm

Notes on downgrading to v5.5.X:

Often it's necessary to downgrade the factory version for a couple of reasons. One; they changed the flash partition layout, and it's not compatible with the OpenWRT image you're using. Two; They implemented a firmware check in later versions, and OpenWRT won't pass the check. The factory firmware downgrade / sidegrade process can correctly move the radio calibration data to a new location if necessary. I don't know much about this, but if you lose this data the unit is useless. For this reason you must be careful not to overwrite the EEPROM partition. if you change partition layout how does the firmware know where the EEPROM area is?

Airos v6.X.X v6.06-beta -> v6.0.4 -> 5.5.X.

Downloads

Typically it will be XW version, but log into the web interface with the default firmware first to confirm.

• XM Version: https://wiki.openwrt.org/toh/hwdata/ubiquiti/ubiquiti_nanostationm5
  • https://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/openwrt-15.05.1-ar71xx-generic-ubnt-nano-m-squashfs-factory.bin
• XW Version: https://wiki.openwrt.org/toh/hwdata/ubiquiti/ubiquiti_nanostationm5xw
  • https://downloads.openwrt.org/chaos_calmer/15.05.1/ar71xx/generic/openwrt-15.05.1-ar71xx-generic-ubnt-nano-m-xw-squashfs-factory.bin

It seems that the internal flash card partition layout is different between the Ubiquiti firmware and OpenWRT. I've found that you can change the flash layout if you access the internal serial port by taking the device out of it's plastic shell.

Required Tools

• Small (00) Phillips Screwdriver
• Knife
• Razor blade/boxcutter blade (optional, knife can work)
• USB to 4-pin Serial cable
• Laptop with ethernet, USB, and minicom (or software of choice) installed, and firmware image.
• POE injector

Initial Laptop Setup

1. Plug in serial cable
2. Launch terminal, check which device the serial cable is (try ls /dev/tty.* or ls /dev/ttyUSB* to see. Likely /dev/ttyUSB0 )
   1. Cable may need to be connected to show up
3. launch minicom config ( minicom -s)
4. Scroll down, select "Serial port setup" (3rd option)
5. Press "A" to edit Serial Device, enter device you identified in step 1 (e.g. /dev/ttyUSB0)
6. Doublecheck other settings (Bps/Par/Bits should be 115200 8N1)
7. Escape to return to main menu, then "Save setup as dfl" to make settings persistent,
8. exit settings to return to minicom (or launch minicom)
9. Launch a second terminal window, navigate to directory with firmware image (or use terminal tabs, but side-by-side windows is useful)
10. Copy filename of firmware image to clipboard for easy pasting.
11. Plug Ethernet into LAN port on POE (>>NOT THE POE SIDE<<)
12. Configure ethernet to 192.168.1.X/24, recommend 192.168.1.2 (sudo ifconfig [ethconnection] 192.168.1.2)

Installation

On the Access Point

1. Using the razor blade or knife, lift the sticker to expose small screw
2. Using phillips screwdriver, remove and secure screw
3. Pop end cap to reveal the port housing
4. Use knife to gently lift the port housing away from the shell (two small plastic pins will release)
5. Gently tug (may require fairly firm yank if shell is tight) circuit board out of the shell
6. Ensure shell pieces stay together (place end cap inside shell body), place shell to one side

On the Board

1. Attach Serial cable to pins on top left of board (ports are "down"). Pins are a bit smaller than normal so connections may be loose and require careful placement of the serial cable to establish a good connection, especially the Green/SIn
   1. Black Serial to Ground (top right of 8 pins)
   2. White to SOut (next pin down on right)
   3. Green to SIn (3rd pin down on right)
   4. NO RED -- leave unattached
2. Plug POE into Main port, watch for lights

In Terminal

1. Ping AP to confirm connection at default IP (ping 192.168.1.20)

In MiniCom

1. Very shortly after boot/reboot, there will be a prompt to "press any key to stop autoboot" -- you have 1 second to hit any key, or simply reboot the AP until you get to the prompt (should read e.g. ar7240> ). If you are getting weird text, check connection on green wire.
2. At prompt, type 'urescu -f -e' -- AP lights will change and eventually it will say "waiting for connection"

In Terminal

1. tftp to device (tftp 192.168.1.20)
2. At tftp prompt
   1. type 'bin'
   2. type 'tra'
   3. type 'put ' (with the space) then paste the firmware image filename
3. Watch the put run, it should complete without errors in 4.7-5 seconds

In MiniCom

1. Watch the write.
2. Watch the boot process, there will be a short pause after "done loading kernel modules", but will continue, will finish with a line that says something about "upper fs does not support..." at which point press enter to continue.
3. Check welcome banner for "v22.03.5"
4. There will be a welcome message encouraging you to set the root password (passwd, then type low security password twice to confirm)
5. type 'reboot' to reboot device, watch entire startup again.
6. When startup completes, press enter, then check the welcome message -- it should not prompt you to set the root password. If there is a prompt, the partition layout may not be correct, causing it to lose configuration across boots.

In Terminal

1. Ping to confirm the AP is now at the new IP (ping 192.168.1.1)
2. SSH to the AP to confirm connectivity and root password (ssh root@192.168.1.1)
   1. This may require updating known hosts depending on settings since the fingerprint will change for every AP

Notes

• On version 22.03.0 (XM) eth0 and eth1 are switched so you can't just copy an XW config to a XM config. Also that version does not know the specific switch config and shows you more ports than actually exist.
• The XM radios also have different radios and the first stanza of the wireless file is different, so you can't copy an XW wireless file to an XM without preserving the first radio0 stanza.
• in the NSM5 switch, vlan 1 misbehaves possibly due to hard-coded exceptions. One symptom is arp does not work across ports. Change all vlan 1 instances to something like vlan 10. You could also change the vid or index from 1 to 10, but not sure that is necessary.
  • If you use Luci (the GUI) it may not change all references, you should check the resulting network config file to make sure.
  • The NSM? switch can not have both untagged and tagged traffic, eg it can not have a PVID due to hardware limitations. So you need to have just one untagged stream or all tagged with this device. See this link: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  • Though I have seen it do this briefly after configuring it in a specific order until it was rebooted. So it might actually be a driver issue.
  • Other Ubiquity devices / switches such as the ToughSwitch don't have this hardware limitation.

Other Notes

• This should go somewhere else, but you can edit parms with the UCI command line interface and then have it update the config files; network, wireless, system, etc....
• The long term Asymetric routing issues were caused by TCP initiation checks and a lack of proper state recording. As explained in this link:
  • https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html
• You can add just one floating rule, selecting all of the internal ports, and an alias for all our subnets, looking at both directions to solve the problem.
  • You may want to make it a fast rule, and / or combine it with the internal queue. You may want to do this on all the routers.
• You can flash openwrt on the ToughSwitch, but the management port, and all LEDs will not work, and to get PoE, you need to echo 1 to some /sys/path/name.
  • The flash is very small so you can't add much in the way of packages. However, there are other switches that can run openWRT.

Installation on Ubiquiti UniFi AP

There are two HW versions and some folks find it impossitble to install on the v2 version. Here are some links:

• https://openwrt.org/toh/ubiquiti/unifi_ap
• https://forum.openwrt.org/t/flashing-the-ubiquiti-unifi-uap-v2/91857/

I've done these before and made a complete set of backups but didn't seem to take a lot of notes. I just did another one of these and all I had to do was tftp flash it with the factory bin, and that was it.

Installation on Ubiquiti UniFi AC Lite AP

These instructions based on: https://openwrt.org/toh/ubiquiti/unifiac

There is a way to do this without connecting to the serial port, though I like to at least backup the installed version of U-boot so I have the possibility of restoring it later. Most often I backup all the important partitions, though that is overkill because you can re-install any factory image just using U-boot.

Open the device, and connect the serial cable. Perhaps follow the backup instructions: Ways of saving a copy of U-boot and other flash images, below. Then:

tftpboot 0x80000000 openwrt-ar71xx-generic-ubnt-unifiac-squashfs-sysupgrade.bin
erase 0x9f070000 +0x790000
cp.b 0x80000000 0x9f070000 0x
bootm 0x9f070000

Note that the last value in the cp.b command is the length to write, and must come from the output of the tftpboot command.

Configuration of internal switch

The M5 and other products have an internal 3-port switch.

• One port is for the incoming data feed and PoE power. It is labeled "MAIN" on the device, "LAN" in the GUI switch configuration, and "5" in the CLI.
• One port is internal to the device itself. It's labeled "CPU (eth0)" in the GUI and "0" in the CLI.
• One port is connected to the outgoing port. It is labeled "SECONDARY" on the device itself, "WAN" in the GUI and "1" in the CLI.

Default VLAN 1 is known to misbehave when used in a trunking environment and is best avoided. Use VLAN 10 for management.

All VLANs should be tagged on the CPU (eth0) internal port.

The outgoing port can optionally supply 24 volt passive power to a downstream device. It's configured in /etc/config/system

OpenWRT installs on TP-Link Products

Installation on AC1750 (EAP245)

These install notes based on:

• https://www.tp-link.com/us/support/faq/2165/
• https://www.tp-link.com/us/support/download/eap245/#Firmware

The OpenWRT images:

• https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_eap245-v3-squashfs-factory.bin
• https://downloads.openwrt.org/releases/21.02.0/targets/ath79/generic/openwrt-21.02.0-ath79-generic-tplink_eap245-v3-squashfs-sysupgrade.bin

Get latest TP-link EAP245 V3 firmware from above, and unzip on a desktop.

Boot new device, find and connect to it's open wifi, and goto: http://tplinkeap.net

Log in with admin admin or the account you last set. Do a minimal setup. Find IP address on status page. Now you can get to it from the desktop with the image on it. Make sure the FW virsion is at least 2.3.0 or higher, or just upgrade anyway.

System --> Firmware Update

Log back in, and do minimul setup again.

Goto Management --> SSH

Turn on SSH by cecking the boxes.

Find the IP address again. Now ssh in from the desktop and enter this command:

cliclientd stopcs

Go back to the web page and:
System --> Firmware Update
Find the OpenWRT factory.bin image and upgrade.
change your ip to 192.168.1.2 and ssh into 192.168.1.1

vi /etc/config/network

Change OpenWRT to your network and add option gateway.

vi /etc/resolv.conf

Add our router as a DNS server

Since this is probably a snapshot version it dosn't have Luci installed. Install it now:

opkg update
opkg install luci-ssl

Follow insturctions on camas wiki to force https.
Now login via Luci. Go to package page and install rsync and rsyncd.

Look at the recent config you want to copy and port it over.
Note Network --> Switch settings and add vlans, or they will be blocked.
Maybe add vlan 11 instead of 1, this would take some work.
Maybe update Mac addresses so they are uninque.

Notes:

Info on TP-link TFTP: https://www.tp-link.com/us/support/faq/3186/

Recovering a broken config

• http://wiki.openwrt.org/doc/howto/generic.failsafe

Example:

Set your ip to 192.168.1.2, and start a ping to 192.168.1.1, then rapidly click the reset button After you apply power. When it responds, you can SSH to it (because telnet is disabled, remember?) and mount the JFFS2 (writable) flash fs like so:

mount_root

Then cd /etc/config, and inspect, or edit the broken config files by hand. After you're done, reboot:

reboot -f

Unbricking a Ubiquiti node

Short version:

• http://www.ubnt.com/wiki/index.php?title=Firmware_Recovery
• For RS: http://www.ubnt.com/downloads/RS/RS-r1665-BETA/RS-Recovery.txt
• http://www.ubnt.com/support/downloads

Other links:

• http://www.ubnt.com/forum/archive/index.php/t-6245.html
• http://ubnt.com/forum/viewtopic.php?t=2184
• https://community.ubnt.com/t5/airOS-SDK-Custom-Development/AirMAX-Device-Firmware-Recovery-Procedure/m-p/1499583#M2499

Example:

Begin by depressing the reset button. Keep holding, then power the unit on. Wait 8 seconds then release the button (if you want to reset the unit to factory defaults, wait at least 15 seconds). Signal LEDs will be shift left and right indicating that the device is ready for recovery. Note you might have to do a killall NetworkManager to keep your ipaddress.

killall NetworkManager
ifconfig eth0 192.168.1.2
Press reset then apply power
Wait for flashing LEDs
ping 192.168.1.20
tftp 192.168.1.20
 tftp> bin
 tftp> trace
 tftp> put PicoStation2HP-4.0.1.buildxxxx.bin
Sent 1965199 bytes in 35.2 seconds 
 tftp> quit

Note: You can go from a "Bricked" device directly to any firmware that will run on it by doing a tftp put with the firmware.bin file.

Config:

After the signal strength lights stop blinking, you can telnet to 192.168.1.1. Then set a root password, exit and ssh back in. You should then be able to access the web GUI.

Notes on U-boot

U-Boot is a handy boot loader for embedded systems. It seems pretty popular. Sometimes you need various commands handy to unbrick your system.

• https://www.denx.de/wiki/DULG/Manual
  • https://www.denx.de/wiki/view/DULG/UBootCmdGroupFlash#Section_5.9.3.5.
• U-boot trick: http://www.linuxjournal.com/content/handy-u-boot-trick
• http://www.karo-electronics.com/484.html
• https://community.ubnt.com/t5/airOS-SDK-Custom-Development/5-6-2-TFTP-ERROR/td-p/1307614

In more recent versions of Ubiquiti products, the flash layout is different than OpenWRT expects. Also the later versions of U-boot used by Ubiquiti are missing some important commands. Some will not even erase or write to flash. Soooooo, a way to fix these problems is to downgrade the firmware version to something like v5.5.9 or .10, which have earlier, and more enabled versions of U-boot.Sometimes, the current firmware is so locked down that tftp will give you an error when you try to downgrade the firmware, but the Ubiquiti web GUI will work just fine. So try that if you have problems. You could save one of these older U-boot versions, and reflash just that portion, because the running code is relocated to ram first. Some of the older firmware versions are attached here.

Ways of saving a copy of U-boot and other flash images

It's always nice to be able to get back to the factory firmware. So it's a good idea to make backups before you start overwriting it! Luckily we only really need the U-boot code and a few important bits of data like the MAC address etc... If your device has a working U-boot then you can reload the rest. Though if you don't have a working U-boot then you will probably need a JTAG header, (You may have to solder one on yourself), and a JTAG dongle to talk to it with. I haven't yet tried this but I hear it's possible.

If you have a copy of U-boot with the tftpput command then it's easy enough to upload flash images for backup. Though Ubiquity doesn't compile that in by default, Darn... Otherwise here is another way to save partition images. Based on notes from here: https://stackoverflow.com/questions/22271699/upload-firmware-from-flash-using-u-boot

Ssh into a machine that has a serial port into the device, and you can run minicom or the like on, and attach your serial TTL dongle to the header. Set your baud to 115200 8N1, Then pull up the U-boot console.First lets gather some info about the device in case we need it later. Start file capture on your terminal program and set the file name to something like UniFi-UAP-U-boot.cap. Then type reset to capture the banner and every thing up to "Booting... "

reset

Power cycle it again and this time hit enter when it says "Hit any key to stop autoboot:". Then we use the info commands below to get more useful data to help us when the day comes that we want to restore the images. Note that on some products Ubiquity removes some commands like urescue and bdinfo. If bdinfo is missing, note the line from when it starts booting that says something like "Booting image at 9f050000". Compare this with the output of mtdparts, and you will probably find that the kernel image starts at offset 50000. This tells you that the flash starts at 0x9f000000.

version
bdinfo
mtdparts
printenv
flinfo
imls

*** EEPROM Data ***

MAC address: 68:72:51:81:db:5d

md.b 9F7f0000 40
md.b 9F7f0000 40

Note that at least for the UAP, the MAC address(s) are the stored at the start of the EEPROM partition in groups of eight bytes, first one at address 0, second one at 8, etc... You can get the EEPROM starting address from the bdinfo and mtdparts commands. Because we used to think the EEPROM area was so short, we just included it in this meta-data file. Now we know that there is also per device calibration data in that area, and if it gets wiped, there seems to be no way to recover. So we now backup that whole partition except the last section of FF's. You should double check the MAC address on the label(s) with the arp cache "arp -n", and the EEPROM data, sometimes they are different!

After you run these commands, close the capture file, and lightly edit it to clean up some of the formatting. It might be good to also add some comments, like what the actual MAC address is. Rename the file:

mv UniFi-UAP-U-boot.cap UniFi-UAP-U-boot.txt

Next lets save the U-boot partition. This is a bit Kludgey because we don't have any upload commands (You checked right?) on the factory version of U-boot. So we save it twice and check that the files are the same to help protect against dropped characters etc... For each partition you want to save, find the start address and length from the mtdparts command and add the start to the flash start address from the bdinfo command. Typically the U-boot partition is first. Get ready to start another capture file, call it something like: U-boot.hex.cap

md.b 9F000000 40000 (start file capture before hitting enter)

Here are some sample commands for a typical flash layout:

ar7240> mtdparts
device nor0 <ar7240-nor0>, # parts = 6
 #: 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

>md.b 9f000000 40000 (u-boot)
>md.b 9f040000 10000 (u-boot-env)
>md.b 9f050000 100000 (kernel)
>md.b 9f150000 660000 (rootfs)
>md.b 9f7f0000 40     (EEPROM)

Stop the capture, and start a new one with the same command to another file like: U-boot2.hex.cap. Check that they are the same, or keep trying till they are. Then rename them:

diff U-boot.hex.cap U-boot2.hex.cap
mv U-boot.hex.cap U-boot.hex
mv U-boot2.hex.cap U-boot2.hex

Rsync all these files to your workstation:

rsync -Pavc U-boot* clif@192.168.4.1:/home/clif/src

Using your preferred editor, find the end of the U-boot image by searching for something like "ff ff ff ff ff ff ff ", and remove everything after that to save space. Diff the new files again to check that they are still the same. Note that there are sometimes odd repeated one line patterns in the erased areas that you can safely ignore.

vi U-boot.hex
:%s/.*ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................\n//gc
:.,$s/.*ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................\n//gc
vi U-boot2.hex
:%s/.*ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................\n//gc
:.,$s/.*ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................\n//gc
diff U-boot.hex U-boot2.hex

Now check that the cut command is showing us the data portion of each line correctly:

cut -b 10-60 U-boot.hex | head

You should not see any of the addresses on the left, or ASCII characters on the right. Extra white space is fine. Make adjustments to the range "10-60" if not. Then Generate two binary copies of the U-boot partition and compare them like so:

cut -b 10-60 U-boot.hex | xxd -r -p >! U-boot.bin
cut -b 10-60 U-boot2.hex | xxd -r -p >! U-boot2.bin
cmp U-boot.bin U-boot2.bin

Cmp should output nothing if they are identical. You can even convert the bin files back into hex and compare them to the source hex files like so:

xxd -g1 U-boot.bin | cut -b 10-58 >! U-boot.out
cut -b 10-60 U-boot.hex >! U-boot.tmp
diff -w U-boot.out U-boot.tmp
rm -f *.out *.tmp

Next we need the U-boot environment. Recall we captured the text printout above in our meta data file, so now we get the actual image. Again we use the bdinfo and mtdparts command to add the offset of the u-boot-env partition to the start of the flash. The environment is not that long so lets just dump the first 1k or so, and see if we got it all:

md.b 9F040000 400
md.b 9F040000 400

Start the capture and save two copies like we did for the U-boot image above. Transfer it over to the workstation and make binary images. Lastly we need the EEPROM data. Put all these files in a folder called something like: UniFi -UAP, and add some checksums.

md5sum *.{txt,hex,bin} readme > ! md5sums.sum
md5sum -c md5sums.sum
sha512sum *.{txt,hex,bin} readme > ! sha512sums.sum
sha512sum -c sha512sums.sum

You might also want to make a README file like this:

These are backup images and meta data for a Ubiquiti UniFi UAP or just AP for short. The MAC address is stored in the EEPROM.

File                    Description

readme                  This file
U-boot.hex              U-boot image hex file
U-boot.bin              U-boot image
U-boot-env.hex          Environment hex file
U-boot-env.bin          Environment image
U-boot-kernel.hex       Kernel hex file
U-boot-kernel.bin       Kernel image
U-boot-rootfs.hex       Rootfs hex file
U-boot-rootfs.bin       Rootfs image
U-boot-EEPROM.hex       EEPROM hex file
U-boot-EEPROM.bin       EEPROM image
UniFi-UAP-U-boot.txt    Example U-boot text and command outputs.
md5sums.sum             Checksums
sha512sums.sum          Checksums

Note that the last trailing section of ff ff ff.... was trimmed off of most of these hex files.

Then tar it up for safekeeping:

ls UniFi-UAP
readme  U-boot.bin  U-boot-env.bin  U-boot-env.hex  U-boot.hex  UniFi-UAP-U-boot.txt
tar cJf UniFi-UAP.txz UniFi-UAP
tar dJf UniFi-UAP.txz

rm -rf UniFi-UAP

Ways of Restoring a copy of U-boot flash images

If you need to restore a previously saved image, you can follow this procedure. As mentioned above, if your U-Boot code has had important commands removed, then you may have to downgrade the firmware to an earlier version that is more enabled. However, this could lead to a catch-22. I would try never to have a lobotomized version of U-boot running, but perhaps you can use the power on reset tftp mode to get it re-flashed. Here are some previously saved pristine images, which also include an early good version of U-boot:

• Ubnt-NSM5.txz: Saved virgin image from an NSM5 for version v5.6.11 XW
• Ubnt-Rocket.txz: Saved virgin image from a Rocket M2 for version v5.6.11 XM
• Ubnt-BulletM2.txz: Saved virgin image from a BulletM2 for version XM.v5.5.6
• Ubnt-PicoM2.txz: Saved virgin image from a PicoStation for version XM.v6.1.9
• Ubnt-UAP.txz: Saved virgin image from a UAP, didn't record version.
• UAP-AC-lite.txz: Saved virgin image from a UAP AC Lite, didn't record version.
• UAP-AC-LR.txz: Saved virgin image from a UAP AC LR, didn't record version.

Note that you will need a U-Boot version for the target architecture. Also you can often enable the serial console using the appropriate kernel arguments in the bootargs environment variable.

mtdparts default
saveenv

Type tftp and get the IP of the node and the IP it wants for the server. Then CTRL-C out of it.

 *tftp* ...
Using eth0 device
TFTP from server 192.168.1.254; our IP address is 192.168.1.2

Set up a writable tftp server on some machine that you can put on the 192.168.1.254 IP.

apt-get install tftpd-hpa tftp-hpa

adduser --system --home /srv/tftp --no-create-home --uid 113 --group tftp
chown tftp.tftp /srv/tftp
chmod 755 /srv/tftp

Then edit /etc/default/tftpd-hpa:

vi /etc/default/tftpd-hpa
OPTIONS="-4 -p -c -u tftp -U 002 -l -s"

ifconfig eth0 192.168.1.254 netmask 255.255.255.0

killall in.tftpd
/etc/init.d/tftpd-hpa start

Untar your saved image files from above, and copy the images to the tftp directory, then flash each section one at a time:

<b>protect off all
erase 0x9f040000 +0x10000
tftp 81000000 U-boot-env.bin
cp.b 0x81000000 0x9f040000 0x10000
cmp.b 0x81000000 0x9f040000 0x10000

erase 0x9f050000 +0x100000
tftp 81000000 U-boot-kernel.bin
cp.b 0x81000000 0x9f050000 0x100000
cmp.b 0x81000000 0x9f050000 0x100000

erase 0x9f150000 +0x660000
tftp 81000000 U-boot-rootfs.bin
cp.b 0x81000000 0x9f150000 0x660000
cmp.b 0x81000000 0x9f150000 0x660000

Now reboot:

reset

Notes on JTAG

At some point we may need to reflash the U-boot code if it accidentally gets erased.

• http://www.pawelwozniak.info/index.php/embedded-linux/iconnect-nas/119-flashing-u-boot-with-jtag
• Search terms
  • jtag site:ubnt.com

There sometimes is a problem with a garbled serial port under U-boot. You could search for a solution:

• Search terms:
  • ubiquiti NSM5 serial port garbled
  • u-boot serial port garbled
  • uboot change baud rate.

Try setting a slower baud rate.

Example Multiple SSID setup

Network

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config interface 'lan'
    option ifname 'eth0'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.0.0'
    option gateway '10.10.255.254'
    option ipaddr '10.10.255.253'
    option dns '10.254.0.5'

config interface 'FAM'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.0.0'
    option gateway '10.7.255.253'
    option ipaddr '10.7.255.201'
    option ifname 'eth0.7'

config interface 'VEN'
    option proto 'static'
    option type 'bridge'
    option ifname 'eth0.6'
    option netmask '255.255.0.0'
    option gateway '10.6.255.253'
    option ipaddr '10.6.255.201'

config interface 'STAFF'
    option proto 'static'
    option ifname 'eth0.2'
    option type 'bridge'
    option ipaddr '10.2.255.201'
    option netmask '255.255.0.0'
    option gateway '10.2.255.253'
  

Note: The default configuration has several sections referencing switch configurations and VLANs. Delete these in their entirety before saving and reloading the network. Otherwise you'll be locked out and will need to follow the procedure for recovering a broken configuration.

If you want to reload the network settings do this:

/etc/init.d/network reload

Wireless

config wifi-device 'radio0'
   option type 'mac80211'
   option channel '36'
   option hwmode '11a'
   option path 'platform/ar934x_wmac'
   option htmode 'HT20'
   option txpower '9'
   option country 'US'

config wifi-iface
   option device 'radio0'
   option network 'WIFI'
   option mode 'ap'
   option encryption 'none'
   option ssid 'OCFnetL4'

config wifi-iface
   option device 'radio0'
   option mode 'ap'
   option macaddr 'F0:9F:C2:5E:45:38'
   option ssid 'OCFnet_FamilyL4'
   option network 'FAM'
   option key 'Secret11'
   option encryption 'psk2'

config wifi-iface
   option device 'radio0'
   option mode 'ap'
   option macaddr 'F0:9F:C2:5E:45:39'
   option ssid 'OCFnet_StaffL4'
   option network 'STAFF'
   option encryption 'psk2'
   option key 'Secret22'

config wifi-iface
   option device 'radio0'
   option mode 'ap'
   option macaddr 'F0:9F:C2:5E:45:3A'
   option ssid 'OCFnet_VendorsL4'
   option network 'VEN'
   option key 'Secret33'
   option encryption 'psk2'
   

If you want to reload the wifi settings, do this:

wifi

Other common changes:

Force https:

1. Update the AP's package manager with the following:
   • opkg update
     • The update may have errors when downloading the package updates due to packet loss or other disturbances. If more than 3 errors occurred, it would be best to run it again until less than 3 of the downloaded packages are failing.
2. Install the SSL version of luci on the AP:
   • opkg install luci-ssl
3. Set things so it redirects http requests to https:
   • uci set uhttpd.main.redirect_https='1'
   • uci commit
4. (Re)start the webserver on the AP:
   • /etc/init.d/uhttpd restart

Add crontab to change power settings etc:

You can add scripts to change power or bring interfaces up and down, though different drivers use different utilities to make changes. Follow this link for an overview:

https://openwrt.org/docs/guide-user/network/wifi/wireless-tool/wireless.utilities

cd /root
cat <<EOF > wifidown.sh
#/bin/sh

lowpower=1

# The old way that rewrites the config on the flash card each time
# /sbin/uci set wireless.radio0.txpower="$lowpower"
# /sbin/uci set wireless.radio1.txpower="$lowpower"
# /sbin/uci commit wireless
# /sbin/wifi reload

# The new way, that just changes the driver parameter
iw phy phy0 set txpower limit "${lowpower%%.*}00"
iw phy phy1 set txpower limit "${lowpower%%.*}00"
EOF

cat <<EOF > wifiup.sh
#/bin/sh

hipower=15

# The old way that rewrites the config on the flash card each time
# /sbin/uci set wireless.radio0.txpower="$hipower"
# /sbin/uci set wireless.radio1.txpower="$hipower"
# /sbin/uci commit wireless
# /sbin/wifi reload

# The new way, that just changes the driver parameter
iw phy phy0 set txpower limit "${hipower%%.*}00"
iw phy phy1 set txpower limit "${hipower%%.*}00"
EOF

Now goto System --> Scheduled Tasks, and add:

# (Cron version -- )
# m h dom mon dow    command

# Turn WiFi power down at night.
30 7 * * * /root/wifiup.sh
0 23 * * * /root/wifidown.sh

Note that some wifi devices also have limits on how low they can go, eg 5 rather than 0 or 1. To see the current txpower do:

iwinfo | egrep "Tx-Power:"

Add SNMPd to OpenWRT Devices:

For our Network Monitoring System to monitor the performance of OpenWRT devices, you need to:

1. Make sure the networking is set up properly and the radio can ping something like www.google.com
2. Add the SNMPd package
   1. "opkg update"
   2. "opkg install snmpd"
3. You will need to untar the librenms_openwrt.tar.gz file over to the radio you just provisioned.
   
   1. scp username@currant://var/www/html/librenms_openwrt.tar.gz /tmp
   2. cd /etc
   3. tar -xvpzf /tmp/librenms_openwrt.tar.gz
4. Edit the various files to apply the config to this particular radio
   1. In /etc/snmp/snmpd.conf and /etc/config/snmpd - change the lines sysLocation and sysName
5. Restart the SNMPd daemon:
   1. service snmpd restart
6. Add device to LibreNMS

Notes:

Here is a discussion on usable 5.8 GHz channels; you may not be able to use the DFS portion.

https://supportforums.cisco.com/discussion/12060681/non-overlapping-channels-80211an-need-clarification

Here are some notes about a routed wifi node: https://wiki.openwrt.org/doc/recipes/routedap

One common failure mode for some Ubiquiti gear is for the Ethernet port to go dead, apparently. You might notice this when it stops responding to pings, and if you check with arp -n, you will see that there is no MAC address for it's address.

Actually a lot of the time it just stops working at 100Mbs but when in tftp mode (which forces it to 10Mbs), it will still work. 10Mbs is fast enough for a lot of use cases so you don't have to recycle it quite yet. You just have to get the other end to force 10Mbs. I'm not sure if there is a way to do it in the AirOS config file. Here is a way to do it in linux:

ethtool -s eth0 speed 10 duplex full autoneg off

-- ClifCox - 21 Jun 2010