ethertype 9abe?

RouterOS General
1

I have been seeing some of my Mikrotik AP broadcasting packets with ethernet protocol 9abe to ff:ff:ff:ff:ff:ff. I have searched and cannot find what this protocol is supposed to be, I assume it is a Mikrotik specific ethertype, as I have only seen it come from Routerboards running ROS. At first I thought it might be neighbor discovery, but I am not seeing these packets from all of the Mikrotik that have neighbor discovery enabled.

Does anyone know what ethertype 9abe is?

9abe protocol
2

We are also just now seeing the same ethertype packets flooding about 0.4% of our network and they are also only coming from MikroTik access points (Metal 2SHPn).
I am also just as stumped on what they are - they are exactly 32 bytes in size and data is the same for every broadcast from the same device.

Qiet72

3

Here is a temporary fix/workaround until the source problem is fixed:

/interface bridge filter
add action=drop chain=input mac-protocol=0x9ABE
add action=drop chain=forward mac-protocol=0x9ABE

Regards,
Qiet72

4

Hello everyone,

while working on a custom protocol analyzer, I encountered some mysterious Ethernet frames with EtherType 0x9abe being broadcasted by Mikrotik access points on the LAN. At first, I suspected this might be a new feature — perhaps related to WiFi roaming or AP coordination — but after some digging, I discovered this forum thread (dated back to 2016-) discussing these packets. Clearly, this protocol has been around for quite a while, though it seems to me it remains largely undocumented.

What Is the Structure of These 0x9abe Frames?

Based on traffic captures and analysis, the protocol structure for the payload of these frames appears to be pretty simple:

EtherType (0x9abe) - Protocol Structure Hypothesis (Frame Payload)
-------------------------------------------------------------------------------
Field 1 (6 bytes): Proto-specific destination/identifier ? (not a MAC address)
Field 2 (6 bytes): Connected client device MAC (e.g., phone)
Field 3 (6 bytes): AP device interface MAC (e.g., AP/BSSID)
Field 4 (rest)   : Padding, reserved, or additional protocol fields

So, in every broadcasted frame you might see:

  • Field 1: A 6-byte value acting as an internal identifier or proto dest (not a std MAC address)
  • Field 2: The MAC address of a connected wireless client device
  • Field 3: The MAC address of the AP interface (BSSID?)
  • Field 4: Remaining bytes: padding most likely, reserved or for future protocol extensions

The most plausible explanation is internal AP coordination: these frames allow Mikrotik access points on the same LAN to share information about which clients are currently associated. This could facilitate features like seamless roaming, or other features. Such internal signaling is common in enterprise WiFi solutions—each vendor simply uses their own proprietary format.
One interesting detail: when a device connects to a Mikrotik AP, the AP broadcasts this information three times, spaced about 0.5 seconds apart. I guess this redundancy likely helps ensure all listening APs on the LAN receive the update.

Some users have expressed concern and even blocked these broadcasts with firewall rules. In my assessment, the frames are harmless: they only expose some information about connected devices, and are probably meant purely for Mikrotik’s internal network coordination.

If you’re analyzing your own network, stumbling across unknown or custom Ethernet protocols can be confusing or even alarming. Hopefully, this brief analysis clarifies that these 0x9abe frames are a long-standing Mikrotik mechanism for AP coordination, not a sign of anything malicious or new.

If anyone from Mikrotik wants to chime in with some tech official details, that would be much appreciated!
Maybe this info is already documented somewhere and well-known to others, but it wasn't known to me until I started digging into these frames myself.

Hope this helps the next person who falls down the packet analysis rabbit hole :wink:
bye..

5

Only thinking aloud or very, very wild guess, but could it be related to (the proprietary) wi-fi bridging?

We know that when a client (station) Mikrotik device is set as station-bridge:

it enables bridging over wi-fi, as long as the AP has the bridge-mode enabled

but this bridge-mode is enabled by default, so in practice, the only change made in configurations is setting the client device as station-bridge.

It should be easy to check, if you disable bridge-mode on the AP, something should change.

There is another (related to bridging) setting,

which is edge, which by default is auto, that senses if a wireless interface is an edge port checnking the setting of bridge-mode.

Or maybe this is all unrelated to these 0x9abe packets ...

1 Like
6

Thanks for the ideas! Observations so far:

  • 0x9abe frames show up with a plain AP + normal client (e.g. phone; no station-bridge).

  • They only appear at (re)association; I’m logging longer term to confirm no others. Bridging doesn’t look like the trigger. Still curious about that first 6‑byte field — maybe CAPsMAN-related? If anyone has captures from CAPsMAN or other modes, would love to compare. Cheers!

bye..