The WinBox Bug That Silently Breaks Apple Wi-Fi

In part two of Episode 4, Tyler Casey of DMTech walks Marc through a discovery that has been quietly wrecking Wi-Fi for MikroTik operators — and doing it in a way that’s almost impossible to catch unless you know exactly where to look.

The short version: if you edit a Wi-Fi configuration in WinBox v3 on a router running RouterOS 7.22 or newer, WinBox injects a broken value into the config. You won’t see it in WinBox. You won’t see it in WebFig. And on the other end of it, every Apple device on that network stops being able to connect.

The demo

Tyler recreated it live on a router running 7.22.

He started clean — a /interface/wifi/configuration print from the CLI showed exactly what you’d expect. Nothing out of place.

Then he opened the Wi-Fi configuration in WinBox v3 and clicked OK without changing anything. Still clean. So the mere act of opening a window isn’t the trigger.

Then he added a single character to the end of the configuration name and printed again.

There it was. A realms-raw entry, sitting under interworking, that he never asked for and never typed. He repeated it on the 5 GHz config and got the same result. One trivial edit — a name change, nothing to do with radios, security, or channels — and the config was contaminated.

Marc’s reaction is the right one: that is crazy broken.

Why you can’t see it

This is what makes the bug genuinely dangerous rather than merely annoying.

The injected value is invisible from the GUI. Tyler went hunting for it — found the Interworking tab, found the Realms RAW field, and it was blank. Empty. Nothing to clear, nothing to fix, no indication anything was wrong.

He then closed WinBox v3, reconnected with WinBox v4, and checked again. Still not visible. Even the current-generation client won’t render it.

The only place the injected line exists in a form a human can see is the CLI.

Why only Apple devices

In DMTech’s testing the impact was strikingly selective. Android phones, laptops, desktops, smart TVs, IoT gear — all of it connected without complaint. Apple devices, across the board, would not connect at all.

And the failure mode gives you nothing to work with. You tap the SSID, you’re prompted for the password, you hit Join — and the phone just stops. No error, no spinner that means anything, no “incorrect password.” It hangs, and eventually gives up without ever telling you why. On the router side, there’s often no meaningful log of an attempt.

The why turns out to be a reasonable guess once you know what the field is. MikroTik’s documentation describes realms-raw as a list of hex strings, each specifying the contents of an NAI Realm Tuple — in other words, it’s part of the ANQP element set used for Hotspot 2.0 / Passpoint. Apple devices lean much harder on ANQP queries during association than most other clients do. Feed them a malformed realm advertisement and they choke, while everything else on the network shrugs and ignores it.

The fix

Here’s the genuinely good news: remediation is trivial once you know the bug exists.

Option 1 — re-edit in WinBox v4. Tyler simply changed the configuration names back using WinBox v4, printed again, and the injected realms-raw entry was gone. The act of writing the config with v4 cleans it.

Option 2 — clear it from the CLI. You can unset the field directly:

/interface/wifi/configuration print
/interface/wifi/unset <config-name> interworking.realms-raw

Run the print first on anything that’s been touched by WinBox v3 recently. If realms-raw appears where you didn’t put it, you’ve found your Apple problem.

The part that stings

Tyler pulled up the version check inside WinBox v3. He was on 3.43 — the latest v3 build there is. And one of the line items in that release is update support for new field types used by future ROS versions.

You’d assume that means the new Wi-Fi field types. The ones like realms-raw that didn’t exist in the old wireless stack. That’s the reasonable read.

Except 3.43 is the newest v3 there will ever be, it’s specifically supposed to handle those new fields, and it still breaks anything running 7.22 or later.

To be fair to MikroTik, they haven’t been quiet about the direction: WinBox v3 is formally end of life, and v4 is where development is. They’ve technically covered themselves. But there’s a wide gap between “this version is EOL” and “this version will silently corrupt your Wi-Fi config in a way no GUI will show you.”

It’s also worth noting that MikroTik’s own 7.22.x changelog includes a fix for empty Realm Raw value processing and inheritance from configuration templates — with the explicit caveat that it requires WinBox 4. So the fix exists. It just isn’t available to anyone still on the v3 client.

This isn’t the first one

This lands right on the heels of the WebFig bug the guys covered previously, where making changes through WebFig on newer 7.x builds breaks things badly.

Put the two together and the operational guidance gets uncomfortably narrow:

• WebFig — don’t use it for configuration changes on modern 7.x.
• WinBox v3 — don’t use it for Wi-Fi changes on 7.22+. Other changes appear safe, but that’s a footgun waiting for the one time somebody forgets which tab they’re in.
• WinBox v4 or CLI — this is where you should be.

As Tyler put it, the honest answer is WinBox v4 only, or CLI. The catch, and every MSP owner reading this already knows it, is that “just use the CLI” assumes a team that can drive the CLI.

There’s a reasonable chance you’ve never hit either bug. If you’re running MikroTik for infrastructure and dynamic routing and you’re not doing in-home or customer-premises Wi-Fi, none of this ever touches you. But if you are putting MikroTik APs in customer homes, this is the difference between a working network and a support queue full of “my iPhone won’t connect and I don’t know why.”

The community response

After Tyler posted the finding to WISP Talk and the MikroTik Facebook groups, the replies came fast — operators running the config print, finding the injected line, and realizing they’d been affected without knowing it.

One of them reached out directly to say the post had saved a customer relationship. They’d had a client whose Apple devices couldn’t connect, they’d been unable to diagnose it, and they found the answer in Tyler’s write-up.

That’s the whole reason this show exists.

What to do this week

1. Inventory anything running RouterOS 7.22 or newer that’s serving Wi-Fi.
2. Run /interface/wifi/configuration print from the CLI on each one — do not trust the GUI for this check.
3. Look for realms-raw under interworking that you didn’t configure.
4. Clean it with WinBox v4 or the CLI unset command above.
5. Pull WinBox v3 off your technicians’ machines.

One more thing

Tyler closed part two by mentioning a third discovery, uncovered the day before recording — and his word for it was “gutted.”

That one’s coming. Subscribe to our YouTube Channel so you don’t miss it.

---

Bridge Mode is hosted by Marc (MikroTik Marc) and Tyler Casey of DMTech.