This page describes common procedures across MikroTik RouterBoard routers. If you edit / add information about a specific model, please consider linking to this page to avoid repeating common instructions.
RouterBoards can netboot OpenWrt initramfs .elf (.bin in some instances) images via TFTP. This RAM-based initramfs OpenWrt image is first used to validate the desired OpenWrt version operates properly without overwriting any existing image in the NAND or NOR flash of the RouterBoard.
Once you have verified OpenWrt is working on your MikroTik hardware, use the LuCI web interface to permanently flash the appropriate sysupgrade .bin image into the flash of the RouterBoard. In this way, an initial installation is treated exactly the same as a subsequent OpenWrt upgrade. Prior versions of OpenWrt required a subsequent upgrade to once again boot OpenWrt using initramfs: with the current version of OpenWrt that now uses Unsorted Block images (UBI), the initial flash and subsequent upgrades can be performed directly in-place from the LuCI web interface.
After OpenWrt is installed to Flash, depending on the model, some platform configuration may be needed. This is explained in the model specific wiki pages.
Before you start installing OpenWrt, save your RouterOS License .key file. This will allow you to use Mikrotik's NetInstall to re-install RouterOS.
Save your license by using Mikrotik WinBox: it's under System→License→Export Key. The Mikrotik WebFig web interface does not export license files, you must use WinBox.
See below for other methods to export your license file.
The first supported version of OpenWrt for a particular model should be listed on the OpenWrt Table of Hardware
If the OpenWrt table of hardware says 'trunk', the model specific page should explain if 'trunk' already contains the necessary patches for your model or if you need to compile and patch OpenWrt yourself. Compilation / patching is explained further down in this document. If the documentation is old, then the model may work already in a newer release.
If your RouterBoard is not supported in the latest release, consider compiling the required patches to make your RouterBoard work with the latest release and install that (as described below).
Since an initramfs image is just a temporary image (only loaded into RAM), it is safe to test a particular version of OpenWrt by netbooting (using DHCP/BOOTP/TFTP) and downloading the initramfs image.
When you power down your RouterBoard after loading an initramfs file, OpenWrt will simply vanish: a power down and reboot of the RouterBoard will revert to the prior version of firmware that is still in flash of the RouterBoard.
If the RAM-based initramfs version you have selected works for you, feel free to try other versions of OpenWrt, such as Latest release or snapshot.
Once you are happy with the RAM-based operation of OpenWrt, proceed to the step of flashing OpenWrt in order to permanently write OpenWrt into your RouterBoard.
Images for the latest OpenWrt image can be downloaded from https://downloads.openwrt.org/
Most OpenWrt supported Routerboards are Atheros-based hardware: in that case, after selecting a release, go to the targets/ar71xx/mikrotik folder to see a list of all files available for that release.
For example, to download the 18.06.1 OpenWrt images for the (Atheros-based) RB450G, download from https://downloads.openwrt.org/releases/18.06.1/targets/ar71xx/mikrotik/
After the commit of Introduce sysupgrade + 64MB/Large NAND sysupgrade images, there is no longer a tar.gz image, but instead there are multiple sysupgrade .bin images, only one of which will be used for any particular RouterBoard model.
This wiki has been updated to reflect this simplifying change used in OpenWrt Version 18 for the Mikrotik RouterBoards.
Please refer to older versions of this wiki for instructions on using older releases of OpenWrt such as Chaos Calmer, Barrier Breaker, Attitude Adjustment, etc.
There will be just two images needed to install OpenWrt for any particular Mikrotik RouterBoard hardware platform:
To determine the precise file names needed for your specific RouterBoard model, please refer to:
The following table explains the general convention of initramfs and sysupgrade file names, but does have exceptions. For example, for the nand-large images, it is quite model-specific whether you use the initramfs.elf or initramfs-lzma.elf image.
The above link Table of Hardware - Firmware Downloads, or the wiki for your specific RouterBoard, are the most accurate resources for the correct file names.
|Flash Size||sysupgrade .bin File Naming Convention||File Names to Download from OpenWrt.org (Please Verify At This Link)||RouterBoard Type|
|Image Name Prefix⇒||AC Wifi?⇒||Image Name Suffix⇒||sysupgrade .bin File Name||initramfs File Name|
|16 MB NOR||rb-nor-flash-16M||-ac-||squashfs-sysupgrade.bin||rb-nor-flash-16M-ac-squashfs-sysupgrade.bin||rb-nor-flash-16M-ac-initramfs-kernel.bin||RouterBoard with 16 MB NOR (includes AC WiFi)|
|-||rb-nor-flash-16M-squashfs-sysupgrade.bin||rb-nor-flash-16M-initramfs-kernel.bin||RouterBoard with 16 MB NOR (includes a/b/g/n WiFi)|
|64 MB NAND||nand-64m||-||nand-64m-squashfs-sysupgrade.bin||vmlinux-initramfs.elf||RouterBoard with 64 MB NAND (includes a/b/g/n WiFi)|
|128 MB NAND (or larger)||nand-large||-ac-||nand-large-ac-squashfs-sysupgrade.bin||vmlinux-initramfs.elf||RouterBoard with 128 MB NAND (or larger) (includes AC WiFi)|
|-||nand-large-squashfs-sysupgrade.bin||vmlinux-initramfs.elf or vmlinux-initramfs-lzma.elf (model-dependent)||RouterBoard with 128 MB NAND (or larger) (includes a/b/g/n WiFi)|
Refer to the OpenWrt Table Of Hardware-Ideal to determine the type and size of flash for your particular RouterBoard. The type of WiFi may depend on optional WiFi cards you may have installed in your RouterBoard.
If you add packages to your installed version of OpenWrt (via opkg or LuCI), be careful to use the packages that are compiled specifically for the version of sysupgrade .bin you have running on your RouterBoard. For example, if you decide to run nightly snapshots, be aware you'll want to also install and run the packages from that specific snapshot - each time you update the snapshot, you'll want to update both the sysupgrade .bin AND the packages you are using.
If you are using a snapshot (e.g. for the RB750Gr3), there is no LuCI contained. The flashing can still be done using SSH as outlined in https://openwrt.org/docs/guide-user/installation/sysupgrade.cli .
scp openwrt-*mikrotik*-squashfs-sysupgrade.bin email@example.com:/tmp/
sysupgrade -n /tmp/openwrt-*-mikrotik*-squashfs-sysupgrade.bin
Installing and upgrading OpenWrt on a RouterBoard is basically just a couple steps:
Note the wget2nand utility has been deprecated in this latest release of OpenWrt since the UBI changes to the code now allow direct flashing of the NAND or NOR from the LuCI web interface.
The detailed 12 step process below is updated to reflect the new 'UBI' style firmware images of version 18 OpenWrt that now make it very easy to flash the RouterBoard directly from the LuCI web interface. Many of the board-specific wiki's here in OpenWrt have yet to be updated to reflect this new, simpler process. Use this description of the Step-By-Step Installation Process to get an idea how relatively simple it is to install and upgrade OpenWrt - and feel free to give it a try since the initramfs version of OpenWrt is just a RAM image that will not affect your RouterOS if you decide NOT to flash the permanent sysupgrade.bin file into your RouterBoard. If you do flash OpenWrt into your RouterBoard, you can revert back to RouterOS at a later time using Mikrotik's NetInstall utility - as long as you saved your RouterOS license file (export your .key license file) before you permanently install (flash) OpenWrt.
To install OpenWrt (works on all OpenWrt supported RouterBoards, using V18 or later OpenWrt):
Linuxor other unix-like OS: install tftp server, usually
in.tftpd. On normal case the client of SSH already installed in the system.
Once you have OpenWrt running, you'll probably want to reset your PC's Ethernet back to DHCP instead of the 'forced' static IP addresses you used during the install of OpenWrt.
Routerboards contain the Mikrotik RouterBoot netboot bootloader that will boot over the network and run an OpenWrt initramfs file. The initramfs file is a single file with the whole OpenWrt package: kernel plus filesystem. A RouterBoard has at least three flash partitions: bootloader, kernel and ubi. The MikroTik bootloader is preserved even after OpenWrt is installed into NAND or NOR flash.
The RouterBoard RouterBoot supports two different boot protocols when netbooting a RouterBoard:
Select any of the following choices to set up a RouterBoard compatible netboot DHCP/BOOTP/TFTP server, then proceed to the next step.
If using Choice 2 or 3, you will need a local copy of the 'openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf' on your Linux system. For example, to create that file in Linux using the 18.06.1 release (latest as of 11/2018) for an RB450G:
wget -c https://downloads.openwrt.org/releases/18.06.1/targets/ar71xx/mikrotik/openwrt-18.06.1-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf ln -s openwrt-18.06.1-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf
Choice 1 assumes you are running from a Windows PC and have already downloaded the initramfs file from the OpenWrt downloads website to your Windows PC.
Choice 2 and 3 assume you are running from Linux. The Linux choices expect the initramfs file to use the above specific name 'openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf'. This is why the above explanation creates a symbolic link to associate the longer release-specific name to the shorter 'generic' name.
The freeware Tiny PXE software is a (free) example of a DHCP/BOOTP/TFTP server that implements the rfc951 BOOTP capability. To enable Tiny PXE's rfc951 BOOTP capabilities, rfc951=1 must be set in the [dhcp] section of the Tiny PXE config.ini file.
Select the initramfs file as the Boot file Filename, un-check the gPXE or iPXE Filename option, select the Option 54 IP address for the ethernet cable you have connected to the RouterBoard, and put Tiny PXE Online.
if you have problems running Tiny PXE, you may need to turn off your firewall, run Tiny PXE as administrator, or disable all other ethernet/bluetooth/wifi in Network Connections.
It is especially important to ensure only one DHCP/BOOTP/TFTP server is running on your network while attempting a netboot since BOOTP has no support for Proxy DHCP or authoritative DHCP - so be sure to disconnect from any other routers before running Tiny PXE.
Copy openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf to your TFTP server location. Set up your DHCP server to point to your TFTP server as the next-server and to that file as the bootfile.
To use dnsmasq:
#/bin/bash ifconfig eth0 192.168.1.10 up sudo dnsmasq -i eth0 --dhcp-range=192.168.1.100,192.168.1.200 \ --dhcp-boot=openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf \ --enable-tftp --tftp-root=~/mikrotik/trunk/bin/ar71xx/ -d -u $USER -p0 -K --log-dhcp --bootp-dynamic
If your shell don't set the environment variable $USER, please replace it with your user name. Run script loader.sh
Connect the ethernet 1 port of your routerboard (typically the WAN port) to a network configured to reach the DHCP/BOOTP/TFTP server that you have set up.
The RouterBoard default boot protocol is BOOTP. You can change the RouterBoot boot protocol from BOOTP to DHCP by using the COM port, RouterOS, or rbcfg from OpenWrt as documented in this list of netboot methods.
The instructions in this wiki tend to assume you have changed the netboot protocol to DHCP since DHCP netboot is readily supported by dnsmasq (the most common DHCP/BOOTP/TFTP server in Linux distributions).
However, if you have chosen to use a DHCP/BOOTP/TFTP netboot server that supports rfc951 BOOTP (such as Tiny PXE, with rfc951=1 set in the [dhcp] section of the config.ini), any of these netboot methods will work fine without any changes to the Routerboot boot protocol.
When a boot protocol is set in RouterBoot, it is remembered: any of the methods here that force a netboot will then use the BOOTP or DHCP boot protocol previously selected in RouterBoot.
This method will work on all RouterBoards, including RouterBoards without a serial port. It is certainly the simplest approach to perform a netboot if using an rfc951 BOOTP-capable DHCP/BOOTP/TFTP server.
Most RouterBoard models generate a short beep when an image begins to netboot or load from flash (unless the RouterBoard has been put in 'silent mode' from the RouterBoot menu). So if you are running without a connection to the serial console COM port to view boot activity from a terminal window, you can use the beep to know when RouterBoot has successfully started to load an image (either a netboot image or the existing flash image).
If you are using Tiny PXE as your netboot PXE DHCP/BOOTP/TFTP server, you can watch its information/log window to see exactly when Tiny PXE begins uploading the initramfs file to the RouterBoard (TFTPd:DoReadFile shows up in the information/log window): this will be the same time the RouterBoard beeps.
To enable a netboot using the Reset button:
If your RouterBoard model has a serial COM port, you can connect to it as a console terminal to netboot the routerboard via TFTP.
If your RouterBoard does NOT have a serial COM port, it may still have a COM port on the motherboard: if you try soldering a cable, the RouterBoot bootloader may or may not support that serial port.
If you cannot use your serial COM port for any reason, a simple alternative is to use a DHCP/BOOTP/TFTP server that supports rfc951 BOOTP (rather than DHCP) netboot and use the Reset button to force a netboot (see Method 1 above).
To enable a netboot using the serial COM port:
If you have not yet installed OpenWrt onto Flash, you should reboot the routerboard via TFTP from the RouterOS web configuration interface.
Connect a PC to a LAN port (port 2…). Log into the web interface of RouterOS and set router to boot from ethernet once with DHCP:
Reboot routerboard (on some devices “System –> Reboot” does not perform a correct TFTP boot; you must use instead “System –> Shutdown” and unplug/replug the router). This will boot OpenWrt from TFTP once. The boot protocol setting will stay persistent across reboots, but the next reboot will be again from NAND (the bootloader resets this parameter after booting from TFTP once). Once you have installed OpenWrt, RouterOS will have been deleted, so you will need to use one of the following other methods listed here to netboot from TFTP.
The OpenWrt rbcfg utility permits to configure parameters of the routerboard bootloader. Note that this program may not work on all routerboards.
opkg update opkg install rbcfg rbcfg set boot_device ethnand rbcfg set boot_protocol dhcp rbcfg apply
After the DHCP/BOOTP/TFTP netboot of the initramfs image, connect your PC to one of the LAN ports of your RouterBoard.
You cannot connect to the RouterBoard via WiFi with the TFTP netbooted image of OpenWrt because the initramfs version of OpenWrt has WiFi disabled.
After the RAM-based intiramfs version of OpenWrt has netbooted, you should be able to ping your RouterBoard LAN ports at IP address 192.168.1.1
If you have trouble accessing 192.168.1.1 on your RouterBoard LAN port when it is running OpenWrt, try any of the following:
After successfully using a web browser to connect to the OpenWrt LuCI web interface at 192.168.1.1:
Congratulations: you have now successfully flashed OpenWrt into your RouterBoard!
These instructions are deprecated since wget2nand is no longer used, but left here for reference. Note “rootfs” has become “ubi” in the current OpenWrt release.
If wget2nand encounters problems, perform its steps manually from shell.
cat /proc/mtd dev: size erasesize name mtd0: 00040000 00020000 "booter" mtd1: 003c0000 00020000 "kernel" mtd2: 07c00000 00020000 "rootfs"
The following instructions assume that as shown above, kernel is /dev/mtd1 and rootfs /dev/mtd2. If these numbers are different on your model, appropriately change the following commands.
mtd erase /dev/mtd1 mtd erase /dev/mtd2 mkdir /mnt/kernel mkdir /mnt/rootfs mount /dev/mtdblock1 /mnt/kernel mount /dev/mtdblock2 /mnt/rootfs
Copy kernel & rootfs to routerboard:
scp bin/ar71xx/openwrt-ar71xx-mikrotik-vmlinux-lzma.elf firstname.lastname@example.org:/tmp scp bin/ar71xx/openwrt-ar71xx-mikrotik-DefaultNoWifi-rootfs.tar.gz email@example.com:/tmp
Flash kernel & rootfs
mv /tmp/openwrt-ar71xx-nand-vmlinux-lzma.elf /mnt/kernel/kernel chmod +x /mnt/kernel/kernel umount /mnt/kernel cd /mnt/rootfs tar -xvzf /tmp/openwrt-ar71xx-mikrotik-DefaultNoWifi-rootfs.tar.gz cd / umount /mnt/rootfs sync
Check if the LEDs light up according to their desired functions (eg: under RouterOS). LED configuration is found in /etc/config/system. Depending on model, OpenWrt may have initialized the LEDs correctly. If not, the model specific wiki page should explain how to configure LEDs in /etc/config/system.
By default, OpenWrt tries to set up wired/wireless interfaces so that there is one routed WAN interface which is typically the first wired ethernet port and the remaining wired ethernet port and wireless interfaces are bridged into a LAN. This setup is partially done under the hood and partially it shows up in /etc/config/network and can be seen via linux CLI commands, for example 'ifconfig -a':
br-lan this is the linux software bridge interface representing the 'lan'. It should by default have IP address 192.168.1.1. It is created by the 'config interface lan' section in /etc/config/network. The 'option ifname' lists one or more wired interfaces that are included in the bridge. The wireless interface(s) seem to be added to the bridge under the hood. Use 'brctl show' to list all interfaces bound to br-lan.
eth0, eth1,… are ethernet interfaces. They may each be attached directly to an ethernet port or to a switch. Use 'swconfig show' to see which ethernet is connected to a switch.
ethN.M is a VLAN on a switched ethernet.
If you solder the UART pins on the board, you can enable the serial console, adding this line to /etc/inittab:
You are done now with common OpenWrt procedures for routerboards. Refer to more specific instructions for your individual routerboard, then proceed to first steps with OpenWrt if you do not know them yet:
If your model is not yet supported by trunk, you need to download compile and patch OpenWrt sources. Always check if the model specific wiki instructions could already be obsolete and the necessary patches have already been integrated before embarking into compilation.
Full instructions are at buildroot.exigence The following is a mostly a cheat sheet specifically for routerboards.
OpenWrt sources are available via two release management systems, svn and git. If the model specific instructions specified one, use that, otherwise use git (faster).
# Find/make some directory: mkdir mikrotik cd mikrotik # Get Barrier Breaker (14.07) git clone git://git.openwrt.org/14.07/openwrt.git # Alternatively, get trunk (latest build) git clone git://git.openwrt.org/openwrt.git # git created openwrt directory. All further compile commands # have to be entered from that directory cd openwrt # Patch the kernel as needed wget ... -O patchfile patch -u -p0 < patchfile # Set up compilation to build AR71XX images for routerboards as well as initramfs echo CONFIG_TARGET_ar71xx=y > .config echo CONFIG_TARGET_ar71xx_mikrotik=y >> .config echo CONFIG_TARGET_ROOTFS_INITRAMFS=y >> .config echo CONFIG_TARGET_INITRAMFS_COMPRESSION_NONE=y >> .config # make defconfig creates the rest of the config file. make defconfig # -j parallel compilation may cause problems, but usually it does not. # choose the number according to the number of your CPU cores make -j 6
Instead of creating .config manually (most easy), you can use the curses CLI (after patching)
make kernel_menuconfig -> Target = AR7XXX -> Subtarget = Mikrotik device with NAND flash -> Target Images = ramdisk'' -> save, exit # Normally you do not need this, but if there are specific kernel options required: make kernel_menuconfig # compile normally make -j 6
It can be advantageous to explicitly use the kernel configuration used to build the images on openwrt.org:
Example with 14.07:
git clone git://git.openwrt.org/14.07/openwrt.git cd openwrt # Optional, this is the commit from which stock kernels where built for 14.07. # there should be a better label for this in 14.07, but there is none. git reset --hard 14cb884013ff7034c7bdd19ba704b252095039ad # Use exactly the config as stock image: wget https://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/mikrotik/config.ar71xx_mikrotik mv config.ar71xx_mikrotik .config # Patch as needed now .. # Compile make -j 6
After compilation, the images are in bin/ar71xx. Copy them to your tftp and http server location (including renaming) accordingly to tftp-boot/install them as explained before.
Warning: once you run “make”, it will copy files from the 'target' directory over to 'build_dir' directory including downloading additional software/patches. If you modify/patch files in 'target' after a 'make', those changes will not propagate into 'build_dir'. To experiment with different patches, you either need to modify files in build_dir directly, or run 'make clean' before every make run.
It's a good idea to save your RouterOS license .key file (export your license) before starting an install of OpenWrt.
A simple method is to use the Mikrotik WinBox Windows application, as discussed at the top of this wiki. See http://wiki.mikrotik.com/wiki/Manual:License.
Otherwise, boot RouterOS and export the key to a file:
/system license output
Then list the files on your device to see which file the .key file was saved:
On a fresh install, the key file should be #1 (or #0 on a RB433UAH).
Copy contents, alternative 1: to open the editor with file #1, type:
/file edit 1 value-name=contents
Then copy-paste the text in a file on your computer. (this alternative only support text files)
Copy contents, alternative 2: later v5 versions of RouterOS supports uploading files via the fetch command. Example:
fetch address=192.168.0.200 src-path=RJ15-ERX5.key user=ftp mode=ftp password=ftp dst-path=/pub/write/RJ15-ERX5.key upload=yes
Copy contents, alternative 3: download files from web interface. Example
The differences between the obtained key file and a key exported with Winbox are that the SoftwareID line is not present in the latter, and there are no empty lines, so you should probably delete all the empty lines in your file prior to import it for a new installation; the SoftwareID line should not bother the installer (untested).
From TFTP booted OpenWrt:
cat /proc/mtd # the following expects that kernel is mtd1 and rootfs is mtd2 mkdir /mnt/kernel /mnt/rootfs mount -o ro /dev/mtdblock1 /mnt/kernel mount -o ro /dev/mtdblock2 /mnt/rootfs cd /mnt/kernel tar czf /tmp/mikrotik-kernel.tar.gz . cd /mnt/rootfs tar czf /tmp/mikrotik-rootfs.tar.gz . cd /tmp scp mikrotik* username@your-server:tmp
If you skipped this step but find you need to restore your prior version of RouterOS, you can use the Mikrotik NetInstall utility to re-install a fresh copy of RouterOS. Mikrotik does provide copies of RouterOS .npk files on their website, however you need to be sure to have saved your license key in order to use NetInstall (if NetInstall does not recognize your existing license).
Be sure to use Mikrotik WinBox to export your license key before installing OpenWrt.
Router model specific pages may refer to http://patchwork.openwrt.org/patch/4773/raw/ URLs. That patchwork server was decommissioned in 2014. See https://dev.openwrt.org/ticket/17785 and https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/029786.html.
The new patch server is https://patchwork.ozlabs.org. Patch numbers for the old server seemingly can not be translated to the new patchwork server so they are not accessible anymore. In general, all patches from the old patchserver should have already been integrated into trunk.
Some wiki pages claim that parallel compilation with -j N mail fail OpenWrt build. This seems not to be a problem for >= 14.07 and AR71XX builds as for RouterBoards, parallel compile seems to work fine.
Some wiki pages claim that you need to put paths into the OpenWrt build tree into your .bashrc so that compilation works correctly. This does not seem to be the case anymore. No problems encountered.
A Detailed Example of Installing OpenWrt on a Mikrotik RB493G (V18 Style) Written by the author of many of the V18 upgrades to this wiki. Procedure should work on most RouterBoards with only a change to the selected initramfs and sysupgrade.bin file names.
Using Mikrotik NetInstall to Install RouterOS Covers the process of re-installing RouterOS after you have previously installed OpenWrt. You may need to have a copy of your RouterOS license .key file to do this (if NetInstall does not recognize your prior license)