MAC layer transports

MAC-layer transports

Three transports reach the router over the MAC layer (UDP 20561) instead of IP: MAC-Telnet, WinBox CLI over MAC and WinBox native over MAC. They need no IP route to the router — not even an IP address on it — only that you share an Ethernet segment. Use them to recover or bootstrap a router, or to manage one on an isolated management VLAN. This page covers what the three share.

using tik4net;
using tik4net.MacTelnet;

var setup = new TikConnectionSetup(TikRouterAddress.FromMac("AA:BB:CC:DD:EE:FF"), "admin", "");

using (ITikMacCliConnection connection = setup.CreateMacTelnetConnection())
{
    Console.WriteLine(connection.CreateCommand("/system/identity/print").ExecuteScalar());
}

Transport	On top of the MAC layer	Router service	Page
MacTelnet	a plain console (login encrypted, session not)	/tool mac-server	MAC-Telnet connection
WinboxCliMac	an encrypted console	/tool mac-server mac-winbox	WinBox CLI over MAC
WinboxNativeMac	encrypted structured WinBox calls (experimental)	/tool mac-server mac-winbox	WinBox native over MAC

/tool mac-server set allowed-interface-list=all
/tool mac-server mac-winbox set allowed-interface-list=all

The two services are independent — enable the one your transport uses.

Addressing the router

You know	Address	What happens
its MAC only	TikRouterAddress.FromMac(mac) (or the MAC as a plain string)	each local network adapter is tried until the router answers
its IP only	"192.168.88.1"	the MAC is found by MNDP — up to 5 s per open
both	TikRouterAddress.FromHostAndMac(ip, mac)	fastest: the IP picks the local adapter, nothing is discovered

• RouterMac on the setup, or the routerMac: argument of the factory, also skips discovery:

using ITikMacCliConnection connection = new TikConnectionSetup("192.168.88.1", "admin", "")
    .CreateMacTelnetConnection(routerMac: "AA:BB:CC:DD:EE:FF");

• On a machine with many adapters (VPN, Hyper-V, WSL), allow for the trying in ConnectTimeout.
• An IP transport given a MAC-only address throws at Create, naming the missing host.

Behaviour to know

• Idle sessions are dropped by the router after about 30 seconds, without a word. tik4net reopens the session and resends the command once, so the first command after a pause takes a few seconds longer. Do not add a keepalive of your own — it shortens the session instead.
  • The resend happens only when the router provably never received the command, so nothing runs twice.
  • WinBox native over MAC resends reads only; a write on a dropped session throws TikConnectionSessionClosedException, which means the write did not run.
  • Inside Safe Mode nothing is resent — losing the session is what rolls your changes back — and you get TikConnectionSessionClosedException.
• Login refusals are retried, as on every WinBox transport — see The WinBox channel. A router that never answers the handshake ends in TikConnectionLoginNoAnswerException.
• Slower than TCP. Every packet is acknowledged and one lost packet holds up everything behind it. Prefer an IP transport for high-rate monitoring when there is a route.

Large reads

The two console transports read tables in windows of 100 rows (CliReadPageSize). A single big read over the MAC layer can lose rows silently when the router falls behind; windows prevent it, and a table that fits in one window still costs one request.

var setup = new TikConnectionSetup(HOST, USER, PASS) { CliReadPageSize = 50 };   // 0 = one command per read

• Filters go into the window, so a LoadByName is one request whatever the table size.
• A windowed read is not a snapshot: a row added or removed meanwhile can be missed or seen twice. For a table that changes while you read it, prefer an IP transport.
• Every read is checked against the router's own row count; a short read throws TikConnectionResponseIncompleteException instead of returning fewer rows.

Troubleshooting

MAC transports time out while every IP transport works. The router still appears in MNDP, so it looks reachable — but MNDP is the router broadcasting to you, while a MAC session starts with you broadcasting to it. The usual cause is your host sending broadcasts out of the wrong adapter, typically a disconnected adapter that still holds an address in the router's subnet. The exception names the local interface it used.

On Windows:

# Broadcast and unicast must leave through the SAME, live adapter:
Find-NetRoute -RemoteIPAddress <subnet>.255
Find-NetRoute -RemoteIPAddress <router-ip>

# A stale address on a disconnected adapter, or a dead adapter with a better metric?
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, AddressState
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric |
    Select-Object InterfaceAlias, ConnectionState, InterfaceMetric

Fix it by releasing the stale address (ipconfig /release on that adapter) or giving the unused adapter a worse metric (Set-NetIPInterface -InterfaceIndex <n> -InterfaceMetric 100).

Also check:

• the router side — /tool mac-server print and /tool mac-server mac-winbox print allow the interface you come through;
• another program holding UDP 5678 (an MNDP viewer) stops discovery — give the MAC to skip it;
• a wire trace that shows only outgoing packets means they never left your host.

See also

• MNDP — finding routers and their MACs on the segment
• CLI transports — what MacTelnet and WinboxCliMac share with the other consoles
• RoMON connection — reaching routers beyond the one you are next to
• Connecting to a router