This note is based on the official OpenWrt installation instructions for the MX60:
https://openwrt.org/toh/meraki/mx60
but expands on some tricky points.
Cisco sold Meraki MX60 as a “cloud-managed security appliance”. It comes in two flavors; MX60 proper has one WAN port and four LAN ports (all ports are Gigabit), and MX60W is basically MX60 plus wireless networking powered by Qualcomm Atheros AR93xx adapter. The MX60 has passed end of sales in October 2015 and is nearing its end of support slated for October 2022 (translation: look for those things on eBay; they ought to come cheap).
The MX60 is implemented in a desktop form factor and has a good-looking (nay, MacMini-level gorgeous) all-metal case, silver top and black bottom. Power requirements (in case your unit didn’t come with a power supply) are 12 V / 2.5 A over a 5.5 mm barrel plug.
The unit we had on hand was a MX60W sporting a PowerPC CPU (OpenWrt identifies it as APM821xx), 512 MB of RAM, and 1 GB of onboard Flash storage. Purchase price (eBay) was a little over USD 30 including shipping. No power supply, but we generally keep on hand a few 12 V / 3 A units, which can be had, courtesy of eBay, for under USD 10.
We have a gradation of difficulty when it comes to OpenWrt installs. Grade One (the simplest) is when you just upload OpenWrt using stock firmware and a Web browser. Grade Two (slightly more complicated) is when you have to involve the console. This install is Grade Three; we’ll have to use both the console and a TFTP server. Also, we’ll need to open the case and use a UART cable in order to get to the console. And, before you ask, yes, there are still-higher grades, but today is not that day... :)
To restate the above, for this install, we will need, in addition to an operational MX60:
Start by setting up a TFTP server. Incidentally, TFTP stands for Trivial File Transfer Protocol. It is a simple, no-frills (and no-security) way for one machine to share files with another. A typical use case for TFTP is network boot, often used by thin clients and, occasionally, by fat servers. We'll use TFTP to boot out router into OpenWrt.
On most Linux flavors, spinning up a TFTP server involves a one-line command to the package manager and a glance at the newly created configuration file. Our designated TFTP server was an Ubuntu Server 22.04, so we elevated ourselves to root and went to town:
apt install tftpd-hpa
When installation is complete, you can check how your new TFTP server is doing:
systemctl status tftpd-hpa
Next, take a look at your TFTP configuration file. Use your favorite text editor to open it; the example below uses nano
:
nano /etc/default/tftpd-hpa
Find the line that starts with TFTP_DIRECTORY
; this is where you will need to put files that you want to be accessible via TFTP. In our case, it was /srv/tftp
. Write it down for future reference.
Next, change to the directory you just identified
cd /srv/tftp
and download the initial boot file for the MX60:
wget https://downloads.openwrt.org/releases/22.03.0/targets/apm821xx/nand/openwrt-22.03.0-apm821xx-nand-meraki_mx60-initramfs-kernel.bin
When download is complete. rename the downloaded file to buck.bin and assign its ownership to user tftp. If you don't have this user on your system, go back to the TFTP configuration file and see what is says under TFTP_USERNAME
; this would be the name under which TFTP runs.
Next, change your network settings so that your Ethernet port has a fixed IP address, 192.168.1.101. The MX60 will look for files to use at boot at this IP address. In our case, this was accomplished by editing the Netplan configuration file, which resides at:
/etc/netplan/00-installer-config.yaml
In your case... check your OS documentation.
Ideally, you'd want to verify that your TFTP server works. We kinda half-assed it by verifying that (a) TFTP server is up and running according to the local systemctl
(see above), and (b) the machine responds to pings sent to 192.168.1.101 from another machine on the same LAN. It's not ideal, but in our case, it turned out to be sufficient. If things didn't work as intended in the later stages, we would know to start debugging by properly testing the TFTP server...
When all this is done, shut the machine off for the time being; we have other things to do now.
Now we need a way to access MX60 using the console. Most business-class routers have a port for that; it may look like a COM port, or like an RJ-45 port, or even like a mini-USB port. Not so with MX60; its console port is hidden inside the case and takes the form of four pins sticking out of one corner of the motherboard.
Be sure that the MX60 is turned off and disconnected from the power supply unit. If your router is a MX60W, it might help if you removed the Wi-Fi antennas, although you don't have to.
Open the MX60's case by removing four screws on the sides of the case, two on the left, two on the right. On our unit, those were hexalobe screws, so we needed a hexalobe screwdriver to remove them. After that, the top should come off with some gentle prodding, revealing the motherboard. One corner of the motherboard will look like this:
Note that the thing under the metal shield on the bottom of the picture is the Wi-Fi card, so the metal shield and the Wi-Fi card won't be there if your unit doesn't have wireless networking and the board will look slightly different because of that.
There are four pins on this connector; they are VCC (power), RX (receive), TX (transmit), and GND (ground).
Now break out your UART cable and study the piece of paper that came with it. Your cable should have the four single-pin connectors with the same labels, VCC (power), RX (receive), TX (transmit), and GND (ground), each with a different color wire leading to it.
For this job, we will not need the VCC pin at all, so leave the VCC connector dangling. Connect the GND connector to the GND pin. Now,
WARNING! THIS IS ABOUT TO GET CONFUSING!!!
Historically, the TX connector would be connected to the RX pin and the RX connector, to the TX pin. The logic was, what one device in a connected pair transmits, the other receives, and vice versa. These days, some manufacturers buck this convention and make cables in which the TX connector must connect to the TX pin and the RX connector, to the RX pin. Our UART cable came from one of those manufacturers, so on the first try, we got garbled output on the console. But when we swapped TX and RX connectors, it fixed things instantaneously. So try it one way, and if it doesn't work, try it the other way. Just remember: (1) do not connect anything to the VCC pin!!!, and (2) GND connects to GND regardless. With these two things tied down, you have only two possible permutations for connecting things.
At this point, the MX60 and the TFTP server are powered off, and your other computer is probably on (if not, turn it on). Now, make sure you have the following in place:
There are many programs that can receive and transmit data over a UART cable. We used a command-line Linux utility called screen
, but many people successfully use Putty, which is available for both Linux and Windows. If you end up using Putty, be sure to instruct it to use the following connection settings:
With all this in place, turn on the TFTP server and give it some time to boot. When it has booted, start the console session on your other computer. Using screen
for that purpose, we executed:
sudo screen /dev/ttyUSB0 115200
This tells the computer to open a connection via the UART cable at 115200 bits per second. When screen
first starts, the terminal window goes blank. When that happens, do two things at once, (1) hold down the space bar on your computer, and (2) plug in the power on your MX60. When you plug in the MX60, it will start the normal boot process with stock firmware, but if it receives a "key pressed" signal from the console first thing, it will abort the normal boot, and you will see some initial output and then, a command prompt that looks like this:
=>
If all you see on the console screen is garbage, you need to turn off the MX60, abort the screen session (press Ctrl-a, then k, then y), swap the TX and RX connectors as discussed above, and try again.
Now that you gained command-line access on the console, run the following commands ONE BY ONE (console connections sometimes do funny things if you try to paste several commands into the terminal at once):
setenv owrt_load1 ubi read \${meraki_loadaddr} kernel
setenv owrt_load2 ubi read \${meraki_loadaddr} recovery
setenv lede_bootkernel bootm \${meraki_loadaddr_kernel} - \${meraki_loadaddr_fdt}
setenv owrt_bootkernel bootm \${meraki_loadaddr}
setenv owrt_bootargs setenv bootargs console=ttyS0,\${baudrate} rootfstype=squashfs mtdoops.mtddev=oops
setenv owrt_boot run meraki_ubi owrt_bootargs\; run owrt_load1 meraki_checkpart lede_bootkernel\; run owrt_load2 owrt_bootkernel
setenv owrt510_boot run meraki_ubi owrt_bootargs\; run owrt_load1 owrt_bootkernel\; run owrt_load2 owrt_bootkernel
setenv bootcmd run owrt510_boot
saveenv
The commands above will prepare the MX60 for booting OpenWrt from the TFTP server. Now we should go ahead and boot it, Run (again, ONE BY ONE):
setenv ipaddr 192.168.1.1
setenv bootargs console=ttyS0,$baudrate mtdoops.mtddev=oops;
tftpboot $meraki_loadaddr buck.bin;
bootm $fileaddr
This should start the OpenWrt boot process. If it doesn't, we need to verify whether the TFTP server is working right. In our case, everything went well. OpenWrt booted and along the way flashed a message asking to press Enter to gain access to the console. We did as requested and were rewarded with the OpenWrt ASCII logo.
Now that OpenWrt is up and running, we can reclaim some storage space (remembering, of course, to run commands ONE BY ONE):
ubirmvol /dev/ubi0 -N part1
ubirmvol /dev/ubi0 -N part2
ubirmvol /dev/ubi0 -N storage
Now OpenWrt is up and running, but it resides only in RAM. To settle it permanently, we need to perform a system upgrade. We also may want to create a recovery partition.
Right now, the Internet port of the MX 60 is still connected to the TFTP server, but it should be able to connect to the Internet, if the upstream device can provide DHCP service. So unplug the CAT cable from the TFTP server, plug it into the upstream device, give it a moment to negotiate the connection, and see if the MX60 can dial out. Try something like this:
ping -c 3 google.com
If you have a connection to the outside, you can download everything you need directly to the MX60 (this is what we will assume for the rest of this note). If not, you may need to download files to another computer first, then connect that computer to one of the LAN ports on the MX60, and use SCP to transfer the necessary files to the MX60.
So let's do the recovery partition first. Start by listing the contents of the /dev directory:
ls /dev
In the listing, there should be a directory called ubi0. There may or may not be directories called ubi0_0, ubi0_1, etc. If there are, write down their names.
Next, create the recovery partition:
ubimkvol /dev/ubi0 -s 10MiB -N recovery
Once that is done, run ls /dev
again and see if there is a new directory called ubi0_X, where X is a number. In our case, the new directory was ubi0_0, so this is what we are going to use a little later.
Now download the recovery firmware to the /tmp directory:
cd /tmp
wget https://downloads.openwrt.org/releases/22.03.0/targets/apm821xx/nand/openwrt-22.03.0-apm821xx-nand-meraki_mx60-initramfs-kernel.bin
And populate the recovery partition (remember to use the appropriate directory name, which may or may not be /dev/ubi0_0):
ubiupdatevol /dev/ubi0_0 /tmp/openwrt-22.03.0-apm821xx-nand-meraki_mx60-initramfs-kernel.bin
Finally, we can perform system upgrade over the Internet:
sysupgrade https://downloads.openwrt.org/releases/22.03.0/targets/apm821xx/nand/openwrt-22.03.0-apm821xx-nand-meraki_mx60-squashfs-sysupgrade.bin
If all of the above worked, congratulations! You have successfully installed OpenWrt on your MX60. Close screen
if it's still open (Ctrl-a, then k, then y), connect a client device to your MX60 and set it up to your liking using SSH or LuCI. At some point, you may want to put the top of the case back on, too...