HowToFixMe
Hardware Failure

MikroTik wAP ax stack member missing: 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.

A MikroTik platform behaving badly is usually one of three things: a thermal/PSU issue caught by `/system health print`, a transceiver problem caught by `/interface ethernet print stats ether1`, or a boot-loader hang you only see on the console. RouterOS surfaces all three differently from competitors, so the diagnostic order matters.

I will be honest, on the wAP ax family I have seen at least one false-positive from the on-box monitoring per quarter. Always cross-check what `/system resource print` and `/system health print` reports against the physical front-panel and a smell test of the chassis.

If this is your first MikroTik hardware issue, the good news is that MikroTik Support is competent and the part-replacement RMA cycle is usually under a week for a covered unit.

What this guide covers

Diagnose and recover from stack member missing on a MikroTik wAP ax.

Step-by-step

  1. Run the stack / chassis status command to see member states.
  2. Inspect the stack cables. re-seat both ends.
  3. Try replacing one stack cable at a time to identify a bad cable.
  4. Power-cycle the affected member if cables are good.
  5. If the member still doesn't rejoin, RMA it.

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.

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:

Quick verification

Before you walk away from a MikroTik device fix, run through:

1. Reproduce the original trigger. does the issue reappear? 2. Check the device's status / health screen for any new alerts. 3. Confirm paired devices (app, hub, controller) reconnected. 4. Save / commit any configuration changes per the device's normal workflow. 5. Note the change in your maintenance log with date + firmware version.

Escalation guide

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

More frequently asked questions

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.

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.

Will the procedure work on the international variant?

Some features and firmware paths are region-locked. Check the model spec sheet to confirm your variant supports the menu option referenced. If you're outside the US/EU, look for the regional support portal.

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.

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.