RouterBOARD

Summary

RouterBOARD represents MikroTik’s line of router hardware designed specifically for running RouterOS, featuring an embedded bootloader called RouterBOOT that manages the initial boot process and provides hardware configuration options. Understanding RouterBOARD management enables administrators to monitor device information, upgrade firmware, configure boot behavior, and secure their hardware against unauthorized access. The RouterBOOT loader undergoes separate versioning from RouterOS, receiving periodic updates that improve hardware compatibility, boot reliability, and security features. Modern RouterBOARD devices support advanced features including protected bootloader mode, preboot Etherboot for remote reinstallation, and configurable mode and reset buttons that trigger custom scripts when pressed.

The /system routerboard menu in RouterOS provides access to all RouterBOARD-specific functionality, dividing commands into display commands for viewing device information and configuration commands for modifying boot settings. The RouterBOOT settings persist across RouterOS installations and operate independently of the operating system, making them fundamental to device management regardless of which RouterOS version is installed. Physical access to the device through serial console or direct button manipulation remains the primary method for recovering from severe configuration errors or performing emergency reinstallations when RouterOS becomes inaccessible.

Device Properties

Viewing RouterBOARD Information

The RouterBOARD menu displays critical hardware information that identifies your specific device model, serial number, and firmware versions. Access this information through the print command at the /system routerboard menu level:

[admin@MikroTik] /system routerboard> print
       routerboard: yes
             model: 1200
   serial-number: 3B5E02741BF0
     firmware-type: amcc460
  factory-firmware: 2.38
  current-firmware: 7.1beta3
  upgrade-firmware: 7.2

This output reveals essential device characteristics that help identify specific hardware capabilities and current firmware status. The model field indicates the RouterBOARD designation, while the serial-number provides unique device identification for warranty claims and inventory management. The firmware-type identifies the processor architecture that determines which RouterOS builds are compatible with your device.

Property Reference

The following table describes all read-only properties available through the RouterBOARD information display, helping administrators understand their device’s current state and upgrade requirements:

Property	Type	Description
routerboard	yes/no	Confirms whether the device is a MikroTik RouterBOARD product
model	string	Hardware model identifier specific to this RouterBOARD series
serial-number	string	Unique factory-assigned serial number for device identification
firmware-type	string	Processor architecture identifier determining RouterOS compatibility
factory-firmware	string	Original RouterBOOT version installed at manufacturing time
current-firmware	string	RouterBOOT version currently installed and in active use
upgrade-firmware	string	Available RouterBOOT upgrade version ready for installation

Understanding the distinction between current-firmware and upgrade-firmware enables administrators to track when RouterBOOT updates become available. The upgrade-firmware value updates when RouterOS packages containing newer RouterBOOT versions are installed, but the actual upgrade requires manual execution through the RouterBOARD upgrade command.

Upgrading RouterBOOT

Upgrade Process

RouterBOOT upgrades contain improvements to boot reliability, hardware compatibility, and security features that benefit all RouterBOARD installations. When the upgrade-firmware value exceeds current-firmware, administrators should perform the upgrade before rebooting to ensure the latest bootloader features are active. The upgrade process modifies the RouterBOOT flash memory and requires confirmation before execution:

[admin@MikroTik] /system routerboard> upgrade
Do you really want to upgrade firmware? [y/n]
y
echo: system,info,critical Firmware upgraded successfully, please reboot for changes to take effect!

After accepting the upgrade, the new RouterBOOT version becomes active only after the next system reboot. The current-firmware value updates during the upgrade, while upgrade-firmware clears until another RouterOS package containing a newer RouterBOOT version is installed. For devices with critical network responsibilities, schedule RouterBOOT upgrades during maintenance windows that accommodate the required reboot.

RouterBOOT versioning follows a separate track from RouterOS versioning, meaning that RouterOS upgrades do not automatically update RouterBOOT and vice versa. Some RouterOS versions require minimum RouterBOOT versions for full functionality, making periodic RouterBOOT upgrades necessary even when RouterOS remains unchanged. Review the RouterOS release notes to identify version-specific RouterBOOT requirements for your device model.

Verification and Rollback

After rebooting following a RouterBOOT upgrade, verify the installation by checking that current-firmware matches the previously indicated upgrade-firmware value:

[admin@MikroTik] /system routerboard> print
       routerboard: yes
             model: 1200
   serial-number: 3B5E02741BF0
     firmware-type: amcc460
  factory-firmware: 2.38
  current-firmware: 7.2
  upgrade-firmware: 7.2

The matching values confirm successful installation. If problems occur after a RouterBOOT upgrade, MikroTik service personnel may request the factory-firmware value to understand the device’s original configuration. RouterBOOT upgrades do not affect RouterOS configuration or files, providing a safe modification path that rarely requires rollback procedures.

Boot Settings

Settings Overview

The RouterBOARD settings menu (/system routerboard settings) controls fundamental boot behavior, serial console configuration, and hardware initialization parameters. These settings persist in RouterBOOT flash memory independent of RouterOS, surviving reinstallation and operating system upgrades. Default values accommodate most deployment scenarios, but specific requirements may necessitate configuration changes before deploying devices in production environments.

[admin@MikroTik] /system/routerboard/settings> print
              auto-upgrade: no
                 baud-rate: 115200
                boot-delay: 2s
            enter-setup-on: any-key
               boot-device: nand-if-fail-then-ethernet
         preboot-etherboot: disabled
             cpu-frequency: 1200MHz
          memory-frequency: 1066DDR
             boot-protocol: bootp
       enable-jumper-reset: yes
       force-backup-booter: no
               silent-boot: yes
      protected-routerboot: disabled
       reformat-hold-button: 20s
   reformat-hold-button-max: 10m

Boot Device Configuration

The boot-device property determines how RouterBOOT selects the operating system to load, with options accommodating standard NAND boot, Etherboot mode for network installation, and failover behaviors when primary boot sources fail. Selecting the appropriate boot device ensures reliable startup while maintaining recovery options for emergency situations.

Boot Device Options:

Value	Description
nand-if-fail-then-ethernet	Primary boot from NAND flash; fallback to Etherboot if NAND boot fails (default)
nand-only	Boot exclusively from NAND flash with no Etherboot fallback
ethernet	Boot in Etherboot mode for network installation via Netinstall
flash-boot	Enable Flashfig mode for mass configuration deployment
flash-boot-once-then-nand	Single-use Flashfig mode then revert to nand-if-fail-then-ethernet
try-ethernet-once-then-nand	Attempt Etherboot once; boot from NAND if server unavailable

The nand-if-fail-then-ethernet default provides reliability through automatic failover while maintaining Etherboot accessibility for recovery. Deployments requiring strict security may prefer nand-only to prevent accidental or unauthorized network boot attempts. Etherboot mode remains accessible through the reset button regardless of boot-device setting, providing a physical recovery path even when boot-device excludes Ethernet boot.

Serial Console Configuration

Serial console access through RS232 connections provides direct device management when network connectivity is unavailable or during recovery scenarios. The baud-rate setting controls communication speed, while enter-setup-on determines which key triggers the RouterBOOT configuration menu during boot delay:

/system/routerboard/settings set baud-rate=115200 enter-setup-on=any-key

Set baud-rate to “off” to disable the serial interface entirely when serial console access is not required, preventing potential unauthorized access through exposed serial ports. The default 115200 baud rate matches standard terminal program configurations, but older serial equipment may require 9600 or 38400 baud settings.

Boot Protocol Selection

The boot-protocol property specifies how RouterBOOT obtains network configuration when booting in Etherboot mode:

/system/routerboard/settings set boot-protocol=bootp

The BOOTP protocol represents the traditional default appropriate for most Netinstall scenarios. DHCP protocol support accommodates OpenWRT and alternative operating systems that use DHCP for network boot configuration. This setting only affects Etherboot mode behavior; NAND boot configurations using RouterOS do not utilize boot-protocol settings.

Silent Boot Configuration

The silent-boot setting suppresses RouterBOOT audio beeps during the boot process, useful in noise-sensitive environments or when beeps indicate boot completion that should remain unobtrusive:

/system/routerboard/settings set silent-boot=yes

Silent boot disables RouterBOoot-generated beeps only; the RouterOS beep command remains functional for user-defined audio notifications. This distinction allows continued use of audio alerts within RouterOS while eliminating startup sounds.

Auto Upgrade Setting

The auto-upgrade setting triggers automatic RouterBOOT firmware installation whenever RouterOS upgrades include newer RouterBOOT versions:

/system/routerboard/settings set auto-upgrade=yes

Enabling auto-upgrade ensures RouterBOOT remains current without manual intervention, applying upgrades automatically during the first reboot following RouterOS package installation. Consider security implications before enabling auto-upgrade in high-security environments where change control procedures require manual approval for firmware modifications.

CPU and Memory Configuration

RouterBOARD devices support CPU frequency and memory timing adjustments that trade performance for power consumption or thermal output:

/system/routerboard/settings set cpu-frequency=1200MHz

Available frequency options vary by device model, with newer RouterOS versions displaying available choices when pressing ? or F1 at the configuration prompt. The power-save cpu-mode option reduces power consumption during CPU idle periods, beneficial for battery-powered or thermally-constrained deployments. The regular mode maintains higher temperatures that help prevent condensation issues in humid environments.

Performance Considerations:

Overclocking or memory frequency adjustments beyond manufacturer specifications may improve throughput in specific workloads but void warranty coverage and risk hardware damage. When troubleshooting performance issues, return CPU and memory settings to default values before contacting MikroTik support.

Jumper Reset Control

The enable-jumper-reset setting controls whether the onboard jumper header can reset RouterBOOT settings:

/system/routerboard/settings set enable-jumper-reset=yes

Disabling jumper reset prevents physical manipulation of RouterBOOT settings through header connections, adding security against unauthorized configuration changes via physical access. This setting complements protected-routerboot functionality for deployments requiring comprehensive hardware security.

Backup Booter Selection

The force-backup-booter setting configures RouterBOOT to use the backup bootloader instead of the primary bootloader on every boot:

/system/routerboard/settings set force-backup-booter=yes

The backup bootloader provides recovery capability when the primary bootloader becomes corrupted, typically through failed firmware updates or flash memory errors. Enabling force-backup-booter sacrifices primary bootloader features but ensures recovery accessibility without physical button manipulation during every boot cycle.

Preboot Etherboot

Overview

Preboot Etherboot extends the standard Etherboot functionality by adding a configurable timeout period during which RouterBOOT waits for Netinstall server responses before proceeding with normal boot. This feature enables remote reinstallation scenarios where devices can be reimaged without physical access or button manipulation. When preboot-etherboot activates, RouterBOOT sends BOOTP requests on all enabled network interfaces, awaiting IP address assignment from a configured Netinstall server.

The preboot-etherboot-server property restricts which Netinstall server the device accepts addresses from, preventing unauthorized reinstallation attempts from rogue DHCP servers on the network:

/system/routerboard/settings set preboot-etherboot=9s preboot-etherboot-server=10.155.115.199

This configuration instructs RouterBOOT to wait 9 seconds for DHCP responses from the specified server at 10.155.115.199 before proceeding with normal boot. The device accepts addresses only from this server, blocking reinstallation attempts from other network DHCP servers.

Remote Reinstallation Procedure

With preboot-etherboot configured, remote reinstallation follows a predictable sequence that requires only power cycling the target device:

Configure preboot-etherboot and preboot-etherboot-server on the target device while RouterOS is accessible
Prepare the Netinstall server with the desired RouterOS image
Power cycle the device through PoE switch control or remote power controller
RouterBOOT enters Etherboot mode and requests addresses from the configured server
Netinstall reinstalls RouterOS onto the device
After installation, disable the Netinstall server or remove preboot-etherboot configuration
Power cycle the device again to complete normal boot

This procedure eliminates the need for physical access during reinstallation, valuable for remote tower deployments or devices in secure locations. The preboot-etherboot configuration persists across RouterOS installations, so remember to disable it after completing reinstallation to prevent unintended Etherboot behavior.

Server Configuration Notes

When preboot-etherboot-server is not specified, the device accepts addresses from any BOOTP/DHCP server presenting as a Netinstall source. This behavior enables flexible reinstallation scenarios but creates security implications on shared networks where unauthorized DHCP servers could trigger Etherboot mode. Always specify preboot-etherboot-server in production environments to restrict reinstallation capability to authorized Netinstall servers.

Protected Bootloader

Security Overview

Protected RouterBOOT prevents unauthorized access to RouterBOOT settings and blocks etherboot mode activation, requiring RouterOS administrator authentication for any boot configuration changes. When enabled, the reset button and reset pin-hole become non-functional for boot mode changes, and RouterBOOT configuration menu access through serial console is disabled entirely. This protection secures devices against physical attacks where someone with device access might attempt configuration reset or reinstallation through etherboot.

/system/routerboard/settings set protected-routerboot=enabled

Protected RouterBOOT displays a confirmation prompt requiring button press within 60 seconds:

[admin@450] > /system/routerboard/settings/set protected-routerboot=enabled
[admin@450] > /system/routerboard/settings/print
                           ;;; press button within 60 seconds to confirm
                               protected routerboot enable
              auto-upgrade: no
                 baud-rate: 115200
                boot-delay: 2s
            enter-setup-on: any-key
               boot-device: nand-if-fail-then-ethernet
             cpu-frequency: auto
             boot-protocol: bootp
       enable-jumper-reset: yes
       force-backup-booter: no
               silent-boot: yes
       protected-routerboot: enabled
        reformat-hold-button: 20s
    reformat-hold-button-max: 10m

Pressing the reset button within 60 seconds confirms the protected RouterBOOT enablement. The confirmation requirement prevents accidental activation through configuration scripts and ensures intentional administrative action.

Security Implications

CRITICAL WARNING: Devices with protected RouterBOOT enabled require RouterOS administrator credentials for all access. If the RouterOS password is lost or forgotten, the device cannot be recovered through any means including Netinstall, serial console, or MikroTik support intervention. Protected RouterBOOT provides security through this irreversibility; there is no backdoor or recovery procedure.

Protected RouterBOOT affects device behavior in the following ways:

Access Method	Behavior with Protected RouterBOOT
RouterOS login	Functions normally with valid credentials
Serial console	Ignores all input; no RouterBOOT menu access
Reset button	No effect on boot mode
Reset pin-hole	No effect on boot mode
Etherboot	Disabled; Netinstall requires password
Netinstall	Requires RouterOS admin password

When protected RouterBOOT is active, devices display blinking LED patterns (alternating on/off each second) to visually indicate the security state. This indicator helps administrators quickly verify protected status without logging into RouterOS.

Reformat Hold Button Configuration

Protected RouterBOOT includes a reformat-hold-button feature providing emergency device erasure when held during power-on:

/system/routerboard/settings set reformat-hold-button=20s reformat-hold-button-max=10m

Holding the reset button for reformat-hold-button duration (but less than reformat-hold-button-max) triggers complete NAND erasure, removing all RouterOS installation and configuration. This feature serves as a last-resort recovery option when all other access methods fail. After reformat completes, the device enters etherboot mode automatically, requiring Netinstall to reinstall RouterOS.

The reformat-hold-button-max property adds security by requiring button release within a specific time window:

/system/routerboard/settings set reformat-hold-button=60s reformat-hold-button-max=65s

This configuration requires holding the button 60 to 65 seconds exactly, preventing guessing attempts and adding protection against accidental activation. Reformat procedures may exceed 5 minutes on some devices; the device remains in reformat state until completion.

Legacy Hardware Support

Older RouterBOARD devices with factory-firmware versions below 7.19.3 require bootloader upgrades before protected RouterBOOT becomes available. Devices displaying the message “The ‘protected RouterBOOT’ feature requires a backup-routerboot upgrade” must follow a specific upgrade sequence:

Install RouterOS 7.19.3 specifically (not newer or older versions)
Execute /system routerboard upgrade and reboot
Verify current-firmware matches 7.19.3
Upload the RouterOS v7 universal package to the device
Reboot to complete factory-firmware upgrade to 7.19.3
Enable protected RouterBOOT
Upgrade to desired RouterOS version

RouterOS v6 devices requiring protected RouterBOOT follow the same procedure using version 6.49.7 as the intermediate upgrade target.

Mode and Reset Buttons

Button Functionality Overview

Many RouterBOARD devices feature physical buttons that trigger custom scripts when pressed, enabling automation of administrative tasks through physical interaction. The mode button provides general-purpose programmable functionality, while the reset button supports both normal reset functions and script-triggering capabilities. These buttons appear in the RouterBOARD menu hierarchy and require explicit configuration to associate scripts with button press events.

Supported Devices Include:

Device Series	Examples
Indoor access points	cAP, cAP ac, wsAP ac lite, cAP ax
Desktop routers	hEX, hEX S, hEX PoE, hAP ac^2, hAP ax^3, Chateau, Chateau ax, Chateau PRO ax
Outdoor devices	LtAP mini, LHG LTE/4G, SXT LTE/4G
Rack-mount switches	CRS328-4C-20S-4S+RM, CRS328-24P-4S+RM
Core routers	CCR1016-12G, CCR1016-12S-1S+, CCR1036-12G-4S, CCR1036-8G-2S+, CCR2116-12G-4S+
Other	CloudRouterSwitch, CloudSmartSwitch, various custom configurations

Mode Button Configuration

The mode button appears at /system routerboard mode-button and supports configuration of on-event script execution when pressed:

/system script add name=test-mode-button source={:log info message=("mode button pressed");}
/system/routerboard/mode-button/set on-event=test-mode-button enabled=yes

The enabled property activates or deactivates button functionality without removing the configuration. The on-event property specifies the script name to execute, which must exist in the /system scripts menu before button configuration.

Hold Time Configuration

RouterOS 6.47 and later support hold-time specifications that restrict script execution to button presses within defined duration ranges:

/system script add name=test-mode-button source={:log info message=("mode button pressed");}
/system/routerboard/mode-button/set on-event=test-mode-button hold-time=3..5 enabled=yes

The hold-time property accepts minimum and maximum values defining the valid press duration. Presses shorter than the minimum or longer than the maximum do not trigger the associated script. This filtering prevents accidental triggers from brief accidental touches while enabling deliberate press recognition.

Reset Button Scripting

The reset button supports identical scripting capabilities through a separate menu path:

/system script add name=test-reset-button source={:log info message=("reset button pressed");}
/system/routerboard/reset-button/set on-event=test-reset-button hold-time=0..10 enabled=yes

Reset button scripting supplements rather than replaces the button’s hardware reset function. Holding the reset button for extended periods still triggers hardware reset behavior independent of scripting configuration.

Practical Examples

LED Dark Mode Toggle:

/system script add name=dark-mode source={
   :if ([system leds settings get all-leds-off] = "never") do={
       /system leds settings set all-leds-off=immediate
   } else={
       /system leds settings set all-leds-off=never
   }
}
/system/routerboard/mode-button/set enabled=yes on-event=dark-mode

This configuration toggles all device LEDs off when the mode button is pressed, useful in bedroom or noise-sensitive environments where router indicator lights create disturbance.

WiFi WPS Push Button:

/system script add name=wps-accept source={
   :foreach iface in=[/interface/wifi find where (configuration.mode="ap" && disabled=no)] do={
       /interface/wifi wps-push-button $iface
   }
}

/system/routerboard/wps-button/set enabled=yes on-event=wps-accept
/system/routerboard/mode-button/set enabled=yes on-event=wps-accept

The WPS button (available on D53, C53, S53, and H53 series) and mode button can both trigger WiFi WPS registration, simplifying client device connectivity without accessing RouterOS configuration.

Configuration Persistence

Button configurations persist across RouterOS reboots and survive RouterOS upgrades. Script associations remain active unless deliberately removed, providing persistent automation capabilities requiring no ongoing configuration management. When troubleshooting unexpected behavior, review button configurations as potential triggers for unexplained state changes.

Device Mode Configuration

Overview

Starting from RouterOS version 7.17, device-mode restricts SwOS/RouterOS transitions for dual-boot devices on CRS3xx series switches. This feature prevents accidental switching between operating systems that might disrupt network availability:

/system/device-mode/update routerboard=yes

Enabling device-mode update through routerboard allows RouterOS to manage device-mode transitions. This setting prevents unauthorized or accidental OS switches that might occur through physical button manipulation on supported hardware.

RouterBOOT - Detailed RouterBOOT loader documentation and configuration
Netinstall - Network installation procedures for RouterOS recovery
Reset Button - Hardware reset functionality and recovery options
First Time Configuration - Initial RouterOS setup procedures
Securing Your Router - Security best practices for RouterOS deployments

RouterBOARD

RouterBOARD

Summary

Device Properties

Viewing RouterBOARD Information

Property Reference

Upgrading RouterBOOT

Upgrade Process

Verification and Rollback

Boot Settings

Settings Overview

Boot Device Configuration

Serial Console Configuration

Boot Protocol Selection

Silent Boot Configuration

Auto Upgrade Setting

CPU and Memory Configuration

Jumper Reset Control

Backup Booter Selection

Preboot Etherboot

Overview

Remote Reinstallation Procedure

Server Configuration Notes

Protected Bootloader

Security Overview

Security Implications

Reformat Hold Button Configuration

Legacy Hardware Support

Mode and Reset Buttons

Button Functionality Overview

Mode Button Configuration

Hold Time Configuration

Reset Button Scripting

Practical Examples

Configuration Persistence

Device Mode Configuration

Overview

Related Resources