Routeros Mac Telnet

---
name: routeros-mac-telnet
description: "MAC-Telnet protocol (MikroTik Layer-2 terminal/exec over UDP 20561) wire format, session handshake, and MD5 + MTWEI (EC-SRP) authentication. Use when: implementing or debugging a MAC-Telnet client/server, reaching a RouterOS device by MAC address without IP, parsing MAC-Telnet packets, understanding the WinBox-style L2 terminal, deciding between classic MD5 and modern MTWEI auth, or when the user mentions MAC-Telnet, mactelnet, mactelnetd, port 20561, or MTWEI/EC-SRP RouterOS login."
---

# MAC-Telnet — MikroTik Layer-2 Terminal Protocol

MAC-Telnet lets you open an interactive RouterOS terminal (or run commands)
addressing a device by its **MAC address** — you do not need to know or route to
the target's IP. It works across a Layer-2 broadcast domain even when the target
has no IP, a wrong IP, or an IP you cannot route to, which is why WISPs and
provisioning tools rely on it. WinBox's "MAC Telnet" and the `tools/mac-telnet`
CLI use this protocol family.

## Why This Matters for Agents

- It is the only way to get a shell on a freshly-unboxed or misconfigured
  RouterOS device that has no reachable IP.
- The protocol carries its **own 6+6-byte source/destination MAC addressing
  inside every packet**, independent of the outer UDP/L2 delivery. This trips up
  implementers who assume normal UDP semantics.
- Authentication has **two incompatible modes** — classic **MD5** and modern
  **MTWEI (EC-SRP over Curve25519)**. Current RouterOS 7.x defaults to MTWEI;
  getting the mode-detection wrong is the single most common failure.
- It is simple enough to implement from scratch for the MD5 path; MTWEI needs an
  elliptic-curve library.

## Protocol Basics

| Property | Value |
|----------|-------|
| Transport | UDP |
| Port | **20561** (server listens; client may use an ephemeral or matching source port) |
| Addressing | In-packet 6-byte src + 6-byte dst MAC (the real addressing); outer UDP/IP is just transport |
| Delivery | Layer-2 — broadcast or unicast Ethernet frame to the target MAC; does not cross routers |
| Reliability | Application-level: byte-counter ACKs + timed retransmission (UDP gives none) |
| Session | Stateful handshake → authenticated → raw terminal stream → teardown |
| Auth | MD5 (legacy) **or** MTWEI / EC-SRP (current RouterOS 7.x default) |
| Max packet | 1500 bytes (`MT_PACKET_LEN`) |

MAC-Telnet (UDP 20561) is a **sibling of MNDP** (UDP 5678) from the same
MikroTik L2 toolset: MNDP discovers the device and its MAC; MAC-Telnet then
connects to that MAC. See the `routeros-mndp` skill for discovery. They are
otherwise independent wire formats — MNDP is a one-shot TLV announcement with no
session, auth, control-block magic, or `00 15` client-type.

## Packet Header (22 bytes)

Every SESSIONSTART / DATA / ACK / END session packet starts with a fixed
22-byte header. **The session-key and client-type fields swap position by
direction** — this is the #1 footgun. (PING/PONG belong to the MAC-Ping tool and
use an 18-byte variant; see *Packet Types*.)

Client → server layout:

```text
Offset  Len  Field
0       1    version  = 0x01 (always 1)
1       1    packet type (see table below)
2       6    source MAC (the client's in-protocol address)
8       6    destination MAC (the target device)
14      2    session key   (uint16, BIG-endian)      ← client direction
16      2    client type   = 00 15                    ← client direction
18      4    counter       (uint32, BIG-endian)
```

Server → client layout is identical **except** the two middle fields swap:

```text
14      2    client type   = 00 15                    ← server direction
16      2    session key   (uint16, BIG-endian)       ← server direction
```

So a parser must know the direction (or which MAC is "ours") to read the session
key from the right offset. Reference: `init_packet()` in MAC-Telnet `protocol.c`
keys both fields on `mt_direction_fromserver`.

- **Version** is always `1`. Reject other values as not-this-protocol.
- **Client type `00 15`** is a fixed constant identifying a MAC-Telnet/WinBox
  client. Treat it as a magic constant; its internal meaning is not
  documented by MikroTik.
- **Counter** is **cumulative payload bytes**, not a packet index — see below.

## Packet Types (`enum mt_ptype`)

| Value | Name | Direction | Purpose |
|-------|------|-----------|---------|
| 0 | SESSIONSTART | client → server | Open a session (header only, no payload) |
| 1 | DATA | both | Carries control blocks and/or terminal bytes; must be ACKed |
| 2 | ACK | both | Acknowledges received bytes (header only; counter = bytes seen) |
| 4 | PING | either | **MAC-Ping** liveness/latency probe — *not* the session keepalive (see below) |
| 5 | PONG | either | Reply to PING, echoing the PING's payload |
| 255 | END | either | Tear down the session |

Note the gap: there is **no type 3**; PING/PONG are 4/5.

**PING/PONG are the separate MAC-Ping tool, not session keepalive.** In the
canonical implementation a PING packet is **18 bytes**, not 22: it is built like
a normal header but bytes 14–17 (the swapped session-key/client-type fields) are
zeroed and the 4-byte counter field at 18–21 is omitted (`init_pingpacket`). The
responder echoes the payload back in a PONG. Do not use PING/PONG to keep a
terminal session alive — that is done with empty ACKs (see *Session Lifecycle*
and *Reliability*).

## The Counter (ACK accounting — footgun)

The 32-bit `counter` is a **running total of payload bytes**, per direction —
not a sequence/packet number.

- SESSIONSTART and the first DATA use counter `0`.
- Each side advances its outbound counter by the number of **payload bytes it
  sent** (control-block bytes *including* their 9-byte headers, plus raw
  terminal bytes).
- An **ACK's counter = the received packet's counter + the length of that
  packet's payload** (i.e. "I have now received this many bytes"). A peer keeps
  retransmitting a DATA packet until it sees an ACK whose counter reaches the
  end of that payload.
- A DATA packet whose counter does **not advance** past what you've already
  processed is a retransmission: still ACK it (so the peer stops resending) but
  do not re-deliver its payload.

Getting this wrong produces a session that authenticates but then hangs on
endless retransmits, or one that double-prints terminal output.

## Control Blocks (the DATA payload format)

A DATA payload is zero or more **control blocks**, optionally followed/mixed with
raw terminal data. Each control block:

```text
Offset  Len  Field
0       4    magic  = 56 34 12 FF
4       1    control type (see table)
5       4    length (uint32, BIG-endian) — byte count of value
9       N    value
```

- The 9-byte control header is `MT_CPHEADER_LEN`. The magic is
  `56 34 12 ff` (`mt_mactelnet_cpmagic`).
- **Length is big-endian** (`htonl` in the reference, even though it carries a
  16-bit value).
- **PLAINDATA**: any bytes in the payload that do **not** begin with the 4-byte
  magic are raw terminal data with no header. A parser reads blocks until the
  next 4 bytes aren't the magic, then treats the remainder as one PLAINDATA run.
  This is how keystrokes (client→server) and screen output (server→client) ride
  inside DATA packets. PLAINDATA is `cptype -1` internally — never on the wire.
  Note there is **no escaping**: terminal bytes that happen to begin with
  `56 34 12 ff` at a parse boundary would be misread as a control block. This is
  vanishingly rare for text terminals but matters for robust codec tests — the
  reference parser distinguishes PLAINDATA only by the *absence* of the magic at
  the current offset.

### Control Types (`enum mt_cptype`)

| Value | Name | Direction | Value payload |
|-------|------|-----------|---------------|
| 0 | BEGINAUTH | client → server | empty (length 0) — starts auth |
| 1 | PASSSALT | **both (overloaded)** | server→client: salt (MD5) or pubkey+salt (MTWEI). client→server (MTWEI only): `username\0` + client pubkey |
| 2 | PASSWORD | client → server | MD5: 17 bytes. MTWEI: 32-byte EC-SRP proof |
| 3 | USERNAME | client → server | login name (byte string; commonly ASCII/UTF-8, no encoding is specified) |
| 4 | TERM_TYPE | client → server | `$TERM` (byte string, e.g. `vt102`, `xterm`) |
| 5 | TERM_WIDTH | client → server | uint16 **little-endian** columns |
| 6 | TERM_HEIGHT | client → server | uint16 **little-endian** rows |
| 7 | PACKET_ERROR | server → client | error string (byte string; auth failure, etc.) |
| 9 | END_AUTH | server → client | empty — auth done, terminal mode begins |

Note the gap: there is **no control type 8**; END_AUTH is 9.

**Endianness trap:** the control-block *length* is big-endian, but the terminal
*width/height values* are little-endian uint16. Everything else multi-byte in
the header (session key, counter) is big-endian.

## Session Lifecycle

A successful client session, in order:

```text
1. client → SESSIONSTART                     (counter 0, header only)
2. server → ACK
3. client → DATA: BEGINAUTH [+ MTWEI login block]   (see auth below)
4. server → DATA: PASSSALT  (16 bytes → MD5 mode; 49 bytes → MTWEI mode)
   client → ACK (always ACK inbound DATA)
5. client → DATA: PASSWORD + USERNAME + TERM_TYPE + TERM_WIDTH + TERM_HEIGHT
6. server → DATA: END_AUTH                    → terminal mode
7. ── interactive: server PLAINDATA (screen) / client PLAINDATA (keystrokes),
      each DATA ACKed; empty-ACK keepalive on idle (see below) ──
8. either → END                               → both close
```

Every inbound DATA is answered with an ACK (step counter = received counter +
payload length). **Keepalive** is an **empty ACK** sent on idle: the reference
client sends one after ~10 seconds of inactivity, and the server drops a session
after ~15 seconds without traffic (`MT_CONNECTION_TIMEOUT`). END should be
echoed/acknowledged, then the socket closed. (PING/PONG, despite the name, are
the MAC-Ping tool — not part of this keepalive.)

## Authentication

The server announces the mode by the **length of the PASSSALT it sends**:

| Server PASSSALT length | Mode | Meaning of bytes |
|------------------------|------|------------------|
| **16** | MD5 (legacy) | 16-byte random salt |
| **49** | MTWEI / EC-SRP | 33-byte server public key ‖ 16-byte salt |

Any other length is invalid — abort. This single check is the correct, robust
way to detect the mode (do not rely on RouterOS version strings).

### Classic MD5

Simple and library-free:

```text
PASSWORD value = 0x00 ‖ MD5( 0x00 ‖ password ‖ salt )      // 17 bytes total
```

- Leading `0x00`, then the 16-byte MD5 digest of (`0x00` + password bytes +
  16-byte salt). The client sends only `BEGINAUTH` in step 3 and waits for the
  server's 16-byte salt.
- Modern RouterOS no longer accepts MD5 in practice. Verified on stock CHR 7.23:
  the device offers a **16-byte salt to a classic client** (one that sends only
  `BEGINAUTH`, with no MTWEI offer) but then **rejects the MD5 proof even for
  credentials it accepts over REST/native-API** ("login failure … via
  mac-telnet" in the device log). So a 16-byte salt does **not** mean MD5 will be
  honored — you must drive MTWEI to log in. MD5 stays useful only for genuinely
  legacy/downgraded gear.

### MTWEI (EC-SRP over Curve25519) — current default

A zero-knowledge password proof: the password never crosses the wire and the
exchange proves the client knows it without revealing it. It requires an
elliptic-curve implementation. (Note: MTWEI authenticates the login but does
**not** encrypt the subsequent terminal stream — MAC-Telnet has no transport
cipher. Treat it as management-plane traffic on a trusted L2 segment.)

Wire-level flow (what differs from MD5):

1. Client generates a keypair → **33-byte client public key**. This is **not**
   the standard 32-byte X25519 wire format: MTWEI runs EC-SRP on a custom
   Curve25519-in-Weierstrass form and serializes the public point as a 32-byte
   big-endian X coordinate plus a 1-byte Y-parity flag (literal `0`/`1`, not a
   SEC1 `0x02`/`0x03` compressed-point tag). Use the reference MTWEI math, not
   an off-the-shelf X25519 API.
2. In step 3 the client sends, alongside `BEGINAUTH`, a **PASSSALT (type 1)
   block carrying `username` + `0x00` + the 33-byte client public key**. (Yes —
   control type 1 is overloaded: server→client it is the salt; client→server in
   MTWEI it is the login+pubkey.)
3. Server replies with a 49-byte PASSSALT = **33-byte server public key ‖
   16-byte salt**.
4. Client derives the SRP identity in **two SHA-256 stages**:
   `v1 = SHA256(username ‖ ":" ‖ password)`, then
   `id = SHA256(salt ‖ v1)` (16-byte salt). It runs the EC-SRP exchange over
   both public keys using `id` to produce a **32-byte PASSWORD proof**, sent with
   USERNAME + terminal blocks as in MD5.
5. Server verifies; on success sends END_AUTH.

Username caveat: the C reference strips any `+...` console-parameter suffix from
the login name **only for the MTWEI identity hash** (`strsep(..., "+")` before
`mtwei_id()`), while still sending the original login string in the USERNAME
control block. Implement this if you support RouterOS console parameters in the
login field.

The cryptographic core (point arithmetic, Weierstrass↔Montgomery conversion,
proof derivation) is non-trivial — implement against a reference rather than
from this summary:

- C: `mtwei.c` / `mtwei.h` in `haakonnessjoen/MAC-Telnet` (OpenSSL EC;
  EC-SRP per the IEEE P1363.2 draft, derived from Margin Research's PoC).
- .NET: `EcsrpEngine.cs` / `EcsrpMath.cs` in `KCTech-Lab/KC.MacTelnet`.
- m2ir: `profiles/winbox-ipc/ec-srp5-handshake.yaml` captures the related
  WinBox EC-SRP5 point encoding and is useful corroboration for the 32-byte-X +
  parity shape. Do **not** copy WinBox's later AES-128-CBC transport encryption
  into MAC-Telnet; MAC-Telnet's terminal stream is not encrypted.

Constants worth pinning in tests: client/server public key = **33 bytes**
(`MTWEI_PUBKEY_LEN`), validator/proof = **32 bytes** (`MTWEI_VALIDATOR_LEN`).

### Auth-mode pragmatics

To log into current RouterOS you must implement **MTWEI** — an MD5-only client
gets a 16-byte salt but its proof is refused (see *Classic MD5* above). A robust
client offers MTWEI in `BEGINAUTH` by default and falls back to MD5 only when the
device returns a 16-byte salt (legacy gear). `tikoci/centrs` does this — it
implements **both** MD5 and MTWEI (`src/protocols/mtwei.ts`, a dependency-free
BigInt port of `mtwei.c`) and is validated over real L2 against stock CHR 7.23.

**`END_AUTH` does not mean the login succeeded.** A *failed* login also sends
`END_AUTH`, immediately followed by a `PLAINDATA` "Login failed, incorrect
username or password" message and `END`. Confirm success only when real terminal
output (a prompt/banner) arrives; treat `END_AUTH` → "Login failed" → `END` (or
an `END` right after `END_AUTH` with no prompt) as auth failure. Grounded on CHR
7.23 via `centrs`.

## After Login: The Interactive Console

`END_AUTH` drops you into RouterOS's normal readline console — the same shell you
get over SSH/serial. These facts are grounded on stock CHR 7.23.1 (via
`tikoci/centrs`'s console reader) and matter whenever you scrape command output
over MAC-Telnet rather than just relaying to a human's terminal:

- **Terminal-size probe.** On connect the console runs a multi-step ANSI cursor
  probe to learn the terminal size: `ESC[9999B` / `ESC[9999C` (move the cursor far
  down / right), `ESC[H` (home), `ESC D`, `ESC Z` (DECID), mode sets
  (`ESC[4l ESC[20l ESC[?7h ESC[?5l ESC[?25h`), and repeated **`ESC[6n` (DSR
  cursor-position report)**. Answer each `ESC[6n` with `ESC[<row>;<col>R`.
  Reporting a wide column makes the console use that width; **ignore the probe and
  it falls back to 80 columns and wraps the echo**, which breaks naive output
  scraping. The TERM_WIDTH/TERM_HEIGHT control blocks appear advisory — the ANSI
  probe wins.
- **~10s negotiation stall.** The MOTD/prompt does not appear until ~10 seconds
  after login, on *every* login. Answering the DSR sets the width but does **not**
  remove the stall — the probe seems to expect a real terminal's clamped cursor
  tracking across the down/up/right/home sequence, so a fixed DSR answer leaves it
  unsatisfied and the console waits out a timeout. A cursor-tracking emulator
  (track row/col in a rows×cols grid, answer each DSR with the real clamped
  position) is the way to avoid it. A human with a real terminal does not see this.
- **First-login license gate.** A factory-fresh device prints the banner and
  `Do you want to see the software license? [Y/n]:` and blocks until answered —
  exactly the fresh/unconfigured gear MAC-Telnet exists for, so a robust client
  must detect and answer it (`n`). Later logins skip it.
- **Prompt, echo, and output shape.** The prompt has two forms: `[user@identity] >` (root) and
  `[user@identity] /path>` (submenu), each with a trailing space; it is redrawn with CR + space-padding + CR (not
  ANSI erase). Keystrokes are echoed and the input line is redrawn. Command
  responses contain **no ANSI** — only CR, LF, spaces, and text — so a simple CR/LF
  terminal emulation (CR → column 0 with overwrite, LF → new line) reconstructs the
  screen. A response is: the echoed `[prompt] > <command>` line, then the output
  lines, then the trailing prompt; strip the first and last to get clean output. A
  **successful write prints nothing** (e.g. `/ip/address/add …` returns straight to
  the prompt — there is no `.id` on the console, unlike REST/the binary API).
- **Validate without running:** `:put [:parse "<command>"]` over the console prints
  `(evl …)` for a good parse, `syntax error (line N column M)` for malformed CLI,
  and `bad parameter <name> (line …)` for an unknown attribute — so one console
  `:parse` checks both syntax and parameter validity. (Over REST the same string
  rides an HTTP-200 `ret`; over the binary API `:put [:parse]` returns an opaque
  object handle and reveals nothing.)

## Reliability & Retransmission

UDP provides nothing, so the protocol layers on:

- **ACK-by-byte-counter** (above) — a sender retransmits an unacknowledged DATA.
- **Timed retransmission** schedule from the reference client, in milliseconds:
  `{15, 20, 30, 50, 90, 170, 330, 660, 1000}` (`retransmit_intervals`), i.e. a
  rough exponential backoff, up to 9 tries before giving up.
- **Empty-ACK keepalive** so idle authenticated sessions are not dropped: the
  client sends an empty ACK after ~10s idle; the server times out a session
  after ~15s of silence. (PING/PONG is the MAC-Ping tool, not this keepalive.)

## Transport & Socket Notes

- **Server**: UDP **20561**. To receive frames addressed to a device that has no
  IP, real clients often send to the **broadcast** address (or a raw Ethernet
  frame to the unicast target MAC) and rely on the in-packet destination MAC to
  let the right device claim the session. The device replies to the client MAC.
- Because addressing is in-band, you generally do **not** need the target's IP —
  only its MAC (discovered via MNDP, ARP, or printed on the label).
- A shared L2 segment means **other devices' MAC-Telnet traffic can hit your
  socket**. Filter rigorously: accept a packet only when version = 1, the
  session key matches, and the in-packet src/dst MACs mirror your own (their src
  = your dst, their dst = your src). Drop everything else.
- **Self-echo**: broadcasting can loop your own packet back; ignore packets whose
  in-packet source MAC is yours.
- **Privilege**: sending raw Ethernet frames (the most robust delivery) needs
  root / `CAP_NET_RAW`. A pure UDP-broadcast approach avoids that but is less
  universal.
- **Testing without a router**: the codec and state machine are pure functions
  of bytes — drive them with a scripted in-memory peer (no L2 fabric needed), as
  `centrs`' unit tests do. Full end-to-end testing needs a real L2 segment
  (CHR-on-a-bridge or hardware), since broadcast/raw-frame delivery is the part a
  CI runner usually can't provide.

## Security Considerations

- **MD5 auth is weak** — salted MD5 of the password, no forward secrecy, and the
  17-byte proof is replayable within a salt. Prefer MTWEI; disable legacy MD5
  login on RouterOS unless required for old gear.
- **MTWEI** does not transmit the password, but MAC-Telnet does not use MTWEI as
  a transport cipher for the terminal stream — treat it as a management-plane
  protocol for trusted L2 segments.
- **No transport authentication of the peer** beyond the auth exchange; any
  device on the segment can attempt sessions. Restrict MAC-Telnet on RouterOS
  (`/tool mac-server`) to trusted interfaces.
- Exposure: a reachable L2 segment + a weak password = shell. Lock down the
  MAC-server interface list the same way you would Telnet/SSH.

## RouterOS-Side Surface

```routeros
# Which interfaces accept incoming MAC-Telnet (server side)
/tool/mac-server/print
/tool/mac-server/set allowed-interface-list=LAN

# MAC WinBox (related L2 service) is configured separately
/tool/mac-server/mac-winbox/print

# From one RouterOS device to another, by MAC:
/tool/mac-telnet 64:D1:54:XX:XX:XX
```

Restricting `allowed-interface-list` to a trusted list is the primary hardening
control; the default may allow all interfaces.

## Reference Implementations

| Lang | Source | Notes |
|------|--------|-------|
| C | `haakonnessjoen/MAC-Telnet` (`protocol.c/.h`, `mactelnet.c`, `mactelnetd.c`, `mtwei.c/.h`) | **Canonical ground truth.** Header offsets, control magic, MD5 + MTWEI. MTWEI added 2022. |
| .NET 10 | `KCTech-Lab/KC.MacTelnet` (`MacTelnetDriver/Proto/*`, `Proto/Auth/Ecsrp*`) | Modern client; implements **MTWEI** against current RouterOS 7.x; pluggable terminal engine. |
| TypeScript | `tikoci/centrs` (`src/protocols/mac-telnet.ts`, `src/protocols/mtwei.ts`, `src/protocols/mac-telnet-console.ts`) | Pure codec + injectable-sink session state machine with byte-counter retransmit + empty-ACK keepalive (a `tick(now)` driven by the console reader); **MD5 + MTWEI** (dependency-free BigInt EC-SRP port of `mtwei.c`); interactive-**console reader** (terminal-probe answering, license clear, prompt sync, CR/LF screen emulation, `:parse` gate) wired into an `execute` adapter; scripted-peer + real-byte unit tests and real-L2 CHR-7.23.1 integration (login, run, write, validate) via quickchr `socket-connect`. |

**Verified:** the header layout (22 bytes, direction-swapped session-key/client-
type), control-block magic `56 34 12 ff`, big-endian length, little-endian
terminal dimensions, packet/control type enums, the 17-byte MD5 proof, the
16-vs-49-byte PASSSALT mode detection, the MTWEI identity hash, and the 33-byte
public-point encoding in this skill were cross-checked against `MAC-Telnet`'s
`protocol.c` / `mactelnet.c` / `mtwei.c`, the `centrs` codec + tests, and
`m2ir`'s related EC-SRP5 profile.

## Provenance & Unknowns

Captured deliberately, with confidence noted:

- **High confidence (source-grounded):** port 20561, the 22-byte header and its
  direction swap, control magic, packet/control type numbers, byte-counter ACK
  semantics, the empty-ACK keepalive (~10s client / ~15s server timeout), MD5
  proof formula, the two-stage MTWEI identity hash, the 16-vs-49 PASSSALT
  detection, the MTWEI public-key (33) / proof (32) sizes, and the 32-byte-X +
  parity point encoding — all read directly from `protocol.c`, `mactelnet.c`,
  `mactelnetd.c`, and `mtwei.c`, with key codec behavior cross-checked against
  `centrs` and the point encoding corroborated by `m2ir`'s WinBox EC-SRP5
  profile.
- **C-reference-specific behavior:** MTWEI strips a `+...` console-parameter
  suffix from the login name before hashing the SRP identity, but still sends
  the original login string in USERNAME. This is grounded in `mactelnet.c`;
  verify against your target implementation if you depend on console
  parameters.
- **Meaning of `client type 00 15`:** treated as an opaque constant. MikroTik
  publishes no spec; do not attribute semantics to it.
- **MTWEI math details** (curve constants, Weierstrass↔Montgomery conversion,
  proof derivation): not reproduced here on purpose — they are easy to get
  subtly wrong, and the 33-byte public key is *not* standard X25519. Implement
  against `mtwei.c` or `EcsrpEngine.cs` and pin the byte-length constants plus
  the 32-byte-X + parity encoding in tests.
- **PING/PONG (MAC-Ping):** present in the enum (4/5) and used by the MAC-Ping
  latency tool with 18-byte packets; the exact MAC-Ping payload semantics are
  out of scope here and only sketched.
- **Exact UDP delivery (broadcast vs. raw unicast Ethernet, source port choice):**
  varies by implementation and platform; the in-packet MAC addressing is the
  invariant. Verify delivery empirically on your target segment.
- **There is no official MikroTik protocol specification.** All of the above is
  reverse-engineered and corroborated across the reference implementations cited.

## Related Skills

- `routeros-mndp` — discover the device and MAC to connect to (UDP 5678).
- `routeros-fundamentals` — RouterOS CLI/REST basics for what you do once
  connected.
- `routeros-qemu-chr` — boot CHR (e.g. bridged onto an L2 segment) to test
  MAC-Telnet without hardware.
- `routeros-sniffer` — capture and inspect MAC-Telnet packets on the wire.