HowToFixMe
Hardware Failure

MikroTik wAP ax partial boot then reload loop: Diagnose & Fix

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

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

Across years of operating MikroTik gear I have watched the same hardware-failure pattern repeat: a unit ships fine, runs for two years, then trips on a power-event or a thermal excursion. On RouterOS the recovery path is the same whether the affected unit is from the wAP ax family or something newer.

Before you touch anything, capture state. `/system resource print` and `/system health print` dumped to a file is worth more than a screen-cap because MikroTik Support will ask for the exact output when you open the case. Keep the artifact even if the box recovers on its own.

Below I walk through the on-box steps first, then the MikroTik Support escalation path. If you have spares on hand, swap-then-diagnose is usually faster than diagnose-then-swap: but only if you can afford the rack time.

What this guide covers

Diagnose and recover from partial boot then reload loop on a MikroTik wAP ax.

Step-by-step

  1. Capture the boot console output to a file, this is the single most useful diagnostic.
  2. Verify image integrity (md5sum or vendor checksum).
  3. If the image is corrupt, re-download from the vendor site and copy back.
  4. If the boot output references a hardware error (memory test fail, FPGA fail), open an RMA.
  5. Try booting an older known-good image stored on flash.

CLI / commands

# Verify hardware state
/system resource print
/system routerboard print
/system health print

# Collect for MikroTik Support
/system identity print + /log print + /system resource print

When to RMA

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.

What changed recently?

Fault diagnosis on a MikroTik device goes faster when you map the symptom to a recent change:

The answer narrows the root cause to a manageable subset.

Safety + preconditions

Before any work on a MikroTik device:

Verification checklist

After applying the fix on your MikroTik device, confirm:

When to call MikroTik support instead

Escalate if:

More frequently asked questions

How often should I run preventive checks?

Quarterly for most consumer devices; monthly for production / commercial devices. Set a calendar reminder so the device stays healthy between issues.

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.

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.

What if the fix returns after a reboot?

Persistent fault returns mean either: a hardware fault (escalate), a configuration that's being overwritten by a sync source (check cloud profiles), or a regression in a recent firmware update (rollback).

Can I roll this back if something breaks?

Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.

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.

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.

Field checklist I run before leaving site

On a WISP rollout the worst outcome is a second truck-roll, so I never close a wAP ax job without walking this list. It has saved me more night drives than any single config trick.

I treat the spares shelf as the real SLA. Two units per sector, cannibalise the dead ones for SFP cages and PoE bits, and the WISP keeps uptime that a paid contract would never beat at this price point.