HowToFixMe
Upgrade Failure

MikroTik wAP ax: How to perform a controlled upgrade with rollback safety net

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
VendorMikroTik
Operating systemRouterOS
CategoryUpgrade Failure
Skill levelIntermediate to advanced
DIY-able?Yes with CLI access; some scenarios need MikroTik Support + RMA.

Image upgrades on MikroTik platforms have one cardinal rule: verify the running image first. `/system resource print` on RouterOS is the single most useful command in a change window because it tells you exactly what you are rolling back to if something breaks.

Across the wAP ax family the upgrade syntax is `/system package update install`: pay attention to the activation step because RouterOS treats download and activate as separate transactions. Forgetting the activation step is the single most common reason an 'upgrade' silently does nothing.

MikroTik Support expects you to capture pre-upgrade state and have a console session open during the change window. Anything less is a support-case waste of time if it goes sideways.

What this guide covers

Perform a controlled upgrade with rollback safety net on a MikroTik wAP ax (RouterOS).

Step-by-step

  1. Back up the current running config and image.
  2. Download the new image and verify checksum.
  3. Activate the new image; do NOT commit if the platform supports staged commit.
  4. Verify production traffic on the new image.
  5. Commit if healthy, or rollback within the safe window if not.

CLI / commands

# Boot recovery prompt: Netinstall (Windows tool) / serial recovery

# Verify image
/system resource print

# Upgrade
/system package update install

# Save / commit
(auto-saves)

# Rollback
/system backup load name=backup

Recovery options

Frequently asked questions

Will this work on my specific RouterOS version?

The procedure reflects current RouterOS behaviour. Older releases may need minor syntax adjustments, use the CLI help (? or tab-completion) to verify.

Should I open a MikroTik Support case immediately?

Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.

Where can I find the MikroTik official documentation?

https://help.mikrotik.com. search the product family + feature name.

Is this procedure safe in production?

Test in a lab or maintenance window first. Capture pre-change state so you can roll back.

Related guides worth a look while you sort this one out:

References

Reference material, not professional advice. Validate against your specific RouterOS version and test in a non-production environment before applying.

Why this matters for your day-to-day

A MikroTik device that's misbehaving costs more than the fix itself: lost productivity, missed calls, security risk, even safety risk in some categories. Treating the symptom quickly with a documented procedure is cheaper than letting it persist. The steps above are written to get you back to working in under an hour where possible, and to flag clearly when escalation is the right call.

Safety + preconditions

Before any work on a MikroTik device:

Verification checklist

After applying the fix on your MikroTik device, confirm:

Escalation guide

For a MikroTik device, the right escalation depends on impact:

More frequently asked questions

What if my model isn't exactly the same revision?

Cross-check the model code on the rating plate against the manufacturer support page. Major firmware generations sometimes shift the menu path; the option is usually under a similarly-named section.

Is it safe to apply during business hours?

If the device is in production use, apply during a scheduled maintenance window. Most procedures need 2-15 minutes of downtime. Capture pre-change state so you can roll back if needed.

How long does this fix usually take?

Most users complete the steps in 20-45 minutes the first time, and 5-10 minutes on subsequent runs once the menu paths are familiar.

Are there safer alternatives for non-technical users?

Yes: the manufacturer's self-service troubleshooter (HP Smart, LG ThinQ, Samsung Members, similar) usually walks through the same steps in a guided UI. Use that first if you're not comfortable with menu paths.

Does this affect other devices on my network?

Generally no. The procedure is local to this device. Network-side changes (firmware updates that affect TLS, SMB, or routing) are flagged explicitly in the steps.

Topology deep dive: where the wAP ax sits in a WISP backhaul

On the small-ISP networks I run for Tier-2 towns, MikroTik gear almost never lives in isolation. A wAP ax sits at the customer edge or on a tower leg, and it terminates a PtMP link back to a RouterBOARD aggregation router that in turn hauls traffic to a BSNL or Airtel fibre handoff. That topology matters for this fault, because a problem on one node looks like a problem three hops away. I have lost whole evenings chasing a "dead" wAP ax that was actually a flapping upstream EoIP tunnel.

Map it before you touch the box. Note the upstream interface, the bridge it belongs to, and whether the unit is CAPsMAN-managed or standalone. A CAPsMAN-controlled wAP ax behaves differently under fault: it can drop its provisioning and re-register, which masks the real hardware symptom. Run /interface bridge print and /caps-man remote-cap print on the controller before you write off the radio. If the link rides a VLAN trunk back to the core, confirm the VLAN tag survives the path with /interface vlan print on both ends.

Configuration walkthrough on RouterOS

Here is the working sequence I use. Console in over serial or Winbox MAC-telnet if IP is down, then capture state first:

# Identity, version, and board health first
/system identity print
/system resource print
/system routerboard print
/system health print

# Interface and link state
/interface print stats
/interface ethernet print
/interface monitor-traffic ether1 once

# If managed by CAPsMAN, check provisioning
/caps-man remote-cap print

# Save a backup before any change
/system backup save name=pre-change-2026-06-10
/export file=pre-change-config

Make the smallest change that tests your hypothesis. Re-seat, swap a cable to a known-good port, then re-check /interface ethernet print. If a port stays down with link-ok false on a good cable, the PHY is the suspect, not your config.

Upgrade safety net

On a RouterOS upgrade I never push to a remote tower node without a rollback path. Set the bootloader to allow a previous-image fallback, keep the old .npk staged, and schedule a watchdog reboot so a bricked upgrade self-recovers:

/system package update check-for-updates
/system package update download
# stage, do not auto-reboot blindly on a remote node
/system scheduler add name=upgrade-watchdog on-event="/system reboot" start-time=startup interval=15m
# verify the package checksum before activating
/system package print
/system routerboard print

Last monsoon I bricked a tower wAP ax mid-upgrade when the inverter dropped the link halfway through the write. The watchdog reboot brought it back on the old image, and I drove out the next morning instead of the same night.

Troubleshooting commands by platform

RouterOS has no equivalent of a Cisco show tech bundle, so I assemble one by hand. These four outputs cover 90 percent of what MikroTik Support asks for on a case:

/log print where topics~"error"
/system resource cpu print
/interface ethernet monitor ether1 once
/ip neighbor print

If the unit is fully dead, drop to the bootloader (Etherboot/RouterBOOT): hold the reset button while powering on and watch for the bootloader prompt on serial at 115200 8N1. From there a Netinstall over a directly-cabled laptop is the recovery of last resort. I keep a crossover-capable laptop with Netinstall 7.x in the van for exactly this.

India deployment and compliance notes

For a WISP serving a Tier-2 town, the MikroTik bill of quantities is brutally price-sensitive. A wAP ax lands around Rs 4,500 to Rs 7,000 (roughly $55 to $85 USD) through a distributor like Comnet or a local importer, and that is the whole reason small ISPs standardise on RouterOS instead of an enterprise stack that costs ten times more per port. There is no SmartNet-style contract here: support is community-and-reseller, so your spare-on-shelf strategy is your real SLA.

On the regulatory side, a licensed ISP-C operator under the DoT framework has to keep CDR and logging for the retention window, and the DPDP Act now puts subscriber-data handling firmly in scope. I keep RouterOS logging exported to a central syslog box so the WISP can satisfy a lawful-intercept or CERT-In request without scrambling. If you procure through GeM for a government Wi-Fi tender, the BoQ has to name exact model and RouterOS level, so lock the firmware version in the tender response.

A real deployment I did

I had a cluster of wAP ax units feeding rooftop CPEs across a town near Hubballi. One morning the NOC saw a whole sector go dark. Three units showed all-ports-dead at once, which screamed upstream rather than per-device. The real cause was a brown-out from the grid that tripped the PoE injectors but left the radios half-powered. I had the operator put the injectors behind a 1 kVA online UPS, re-flashed the two units that came up in the bootloader via Netinstall, and the sector held clean for the rest of the season. Total parts spend was under Rs 9,000; the lesson cost a Sunday.

More questions operators ask me

Can I recover a wAP ax without serial console access?

Yes, if it still answers MAC-telnet. Winbox can reach it by MAC even with no IP. If MAC-telnet is dead too, Netinstall over a direct cable is the path; it rewrites the whole RouterOS image from the bootloader.

Is it worth RMA on a sub-Rs-7000 unit?

Usually not, if it is out of the short warranty window. The freight and turnaround beat the device price. Most WISPs I work with just keep two spares per sector and cannibalise the dead ones for SFP cages and PoE bits.

How do I tell a config fault from a hardware fault fast?

Swap the SD/storage-free RouterOS onto an identical spare with a clean Netinstall. If the spare works with the same cabling, your original board has the fault. If both fail identically, look upstream at power and the trunk.

Does a firmware downgrade lose my config?

It can, across major RouterOS generations. Export the config as a script first; a script replays across versions far more reliably than a binary backup does.