4 ms·

Oh, this is long-awaited, if it works. For context: Mikrotik uses some (semi-)proprietary, but pretty nifty protocols to manage their gear. One of these protoc

by mdb31 5y ago

Oh, this is long-awaited, if it works. For context: Mikrotik uses some (semi-)proprietary, but pretty nifty protocols to manage their gear. One of these protocols, MAC-telnet, has been reverse-engineered pretty extensively previously. But, due to a (not unreasonable) security-related upgrade, the login phase was changed, and 3rd-party implementations stopped working. Mikrotik has refused repeated requests to document this protocol. The linked repository looks like it may re-enable MAC-telnet logins, which would be great for 3rd-party scripts and management solutions. (Why? Because it allows you to connect to, and properly provision, any Mikrotik gear using your own scripts, just based on Layer-2 presence. This is very cool for many use cases...)

stingraycharles 5y ago
So you can still connect to a device if it doesn’t have an IP? That’s pretty cool. Then out of curiosity, do I understand correctly that these types of packets are bridged, not routed, and as such doesn’t work if you’re not in the same subnet?
- w7 5y ago
  Correct. You can't use these protocols outside of the same broadcast segment[0]. That segment can be stretched though with some frame encapsulation protocol like VXLAN or VPNs with bridged TAP devices. [0] Broadcast segment would be the more accurate term here, given that subnet generally refers to layer 3 addressing mechanics. Technically a broadcast segment can contain more than one operational IP subnet, but this is uncommon on most user networks.
  - swinglock 5y ago
    The accurate term is "broadcast domain" or "Ethernet segment".
    - w7 5y ago
      Haha, whoops I mashed the two together. Similar to one of those moments when one speaks and swaps the first letters of two words.
- mdb31 5y ago
  Yes, Mikrotik MAC-telnet works regardless of the IP configuration: it's technically broadcast UDPv4 to port 20561, but the address information in the protocol data is the only thing that's required for it to work. So the IP addresses can be something invalid like 0.0.0.0, in which case you both need to be on the same L2 segment (bridged). But, it's also entirely possible to use valid IP source/destination addresses (which don't need to be exactly your addresses, just a combination that works in both directions across any routers involved, so Ethernet packets end up on the right segment -- this requires some NAT tricks, but in the end it does work...) for the same protocol to work in a L3 environment. Also, on an all-Mikrotik network, there's https://help.mikrotik.com/docs/display/ROS/RoMON https://help.mikrotik.com/docs/display/ROS/RoMON, which, once you set it up, allows for even more interesting traffic flows. My use case for MAC-telnet is "remote hands" provisioning of new/replacement routers and switches. The only thing the local IT resource needs to be able to do, is connect the equipment to a correct uplink port, after which things will usually work (if not, a factory defaults reset may be required). At the moment, some minor manual configuration work using another Mikrotik box is still required to enable IPv6 and configure the correct VLAN, after which my scripts take over. If MAC-telnet authentication can now be automated as well (and testing that is next on my to-do list...), provisioning could be fully automated in most cases.
deleted 5y ago
[deleted]

by mdb31 5y ago

stingraycharles 5y ago

So you can still connect to a device if it doesn’t have an IP? That’s pretty cool. Then out of curiosity, do I understand correctly that these types of packets are bridged, not routed, and as such doesn’t work if you’re not in the same subnet?

w7 5y ago
Correct. You can't use these protocols outside of the same broadcast segment[0]. That segment can be stretched though with some frame encapsulation protocol like VXLAN or VPNs with bridged TAP devices. [0] Broadcast segment would be the more accurate term here, given that subnet generally refers to layer 3 addressing mechanics. Technically a broadcast segment can contain more than one operational IP subnet, but this is uncommon on most user networks.
- swinglock 5y ago
  The accurate term is "broadcast domain" or "Ethernet segment".
  - w7 5y ago
    Haha, whoops I mashed the two together. Similar to one of those moments when one speaks and swaps the first letters of two words.
mdb31 5y ago
Yes, Mikrotik MAC-telnet works regardless of the IP configuration: it's technically broadcast UDPv4 to port 20561, but the address information in the protocol data is the only thing that's required for it to work. So the IP addresses can be something invalid like 0.0.0.0, in which case you both need to be on the same L2 segment (bridged). But, it's also entirely possible to use valid IP source/destination addresses (which don't need to be exactly your addresses, just a combination that works in both directions across any routers involved, so Ethernet packets end up on the right segment -- this requires some NAT tricks, but in the end it does work...) for the same protocol to work in a L3 environment. Also, on an all-Mikrotik network, there's https://help.mikrotik.com/docs/display/ROS/RoMON https://help.mikrotik.com/docs/display/ROS/RoMON, which, once you set it up, allows for even more interesting traffic flows. My use case for MAC-telnet is "remote hands" provisioning of new/replacement routers and switches. The only thing the local IT resource needs to be able to do, is connect the equipment to a correct uplink port, after which things will usually work (if not, a factory defaults reset may be required). At the moment, some minor manual configuration work using another Mikrotik box is still required to enable IPv6 and configure the correct VLAN, after which my scripts take over. If MAC-telnet authentication can now be automated as well (and testing that is next on my to-do list...), provisioning could be fully automated in most cases.

deleted 5y ago

[deleted]