/tool wol - target IP address?

RouterOS General
1

With NirSoft’s WakeMeOnLAN tool, I can successfully wake-on-lan an MSI Cubi2 system on my LAN.
It requires setting the option to send the WOL packet directly to the device’s IP address, not to the IP broadcast.

In RouterOS, I don’t see a way to do that in the /tool wol
Is it possible, in RouterOS (v6.longterm current on an RB951), to send a WOL packet to a specific IP address?

Apart from that, the /tool wol has an option “as-value” which isn’t documented in the help for /tool wol, and where I do find the text “as-value” mentioned elsewhere, I don’t understand how it would relate to /tool wol
Could someone please explain what “as-value” does as an option on the /tool wol command?

thanks.

2

tool wol mac=FF:FF:FF:FF:FF

The WOL tool will send a UDP MagicPacket to the Broadcast address with the MAC address embedded in it.

By default, the magic packet will be sent as an IP broadcast out the default gateway interface, but if you want, you can tell the command to use a specific interface

tool wol interface=ether1 mac=FF:FF:FF:FF:FF:FF

3

It is necessary, for this and some other WOL targets, that the destination IP address embedded in the WOL packet be a specific IP address e.g. 192.168.255.42, not a broadcast IP address e.g. 192.168.255.255 or 255.255.255.255.
Selecting an interace on which to send the packet does not provide RouterOS with sufficient information to know the specific IP unicast address to embed in the packet, so it is not enough.

Is there a way on RouterOS to specify, e.g.

/tool wol mac=AA:BB:CC:DD:EE:FF target-ip-address=192.168.255.42

?

4

Maybe you need a port forward and a static DHCP/ARP setting for the target.

See here:
http://forum.mikrotik.com/t/how-to-allow-remote-wake-on-lan-through-firewall-without-completely-compromising-security/146723/1
http://forum.mikrotik.com/t/wol-from-wan/91333/1
http://forum.mikrotik.com/t/wol-from-wan/91333/1

AFAIK the magic packet cannot be changed and does not contain any IP information (it will always start with 255.255.255.255.255.255 or ff:ff:ff:ff:ff:ff , the broadcast address at Layer2) but it can be redirected.

5

Hm, yeah, I suppose it might be possible to mangle the packet; it would be nice if MikroTik would implement a full WOL capability. (I’ll submit that as a support/feedback request to MikroTik).

6

I don’t know why the ip address should be necessary. The computer is shutdown or standby. The network card i only powered by the 5V standby power from the PSU. The NIC only do pattern matching to find a packet with the magic packet format and his own mac address.

I checked the NirSoft’s WakeMeOnLAN tool with “IP Address of the device” and indeed, it sends the UDP packets to the ip address of the computer. Is also send an arp reqeust before to get the mac address of the remote computer. As i wrote above, it makes no sense to me because there is no ip stack available in this state. I have two computer with a MSI mainboards and both boot normally with the magic packet send to the broadcast ip.

A packet capture from the remote computer would be nice for further debugging. To check if the broadcast packet is even arriving on the other side.

If your really need such a magic packet you could try to use the traffic-generator tool (/tool/traffic-generator) with inject or inject-pcap.

7

Theoretically WOL could be on a BMC with an IP address, and the WOL turns out rest of system. It does not seem like a bad option to have, although perhaps confusing since IP isn’t going to help in most cases. Kinda niche, but Mikrotik has the feature request category at help.mikrotik.com.

8

In this case BMC is fully up & running, accepting HTTP / API / whatever conbections and one can use appropriate command to power on the whole system.

WOL stands for Wake On LAN, meaning that host’s NIC is half alive and ready to receive the magic ethernet frame (so nothing to do with BMC). And as others already mentioned, NIC doesn’t know about IP address, so it won’t reply to ARP whohas requests (hence using device’s last known IP address is futile) . If some gadget can take IP address of device which needs to be woken up, then that device likely holds an ARP table … and those entries don’t expire (like normal ARP entries do), they just get replaced (if some IP address changes MAC).

I’m not saying that MT shouldn’t implement such feature. But I do believe it can’t be implemented trivially.

9

It may flow via L2 MAC, but it’s still formatted as UDP packet AFAIK.

Could be wrong… but I think it’s just specific IP address, instead of broadcast 255.255.255.255, in the UDP part of the packet.

10

According to wikipedia article, the WoL magic frame is basically broadcast on ethernet layer, but as payload it does contain MAC address of device which is supposed to wake-up. Then there are extensions which make WoL packets routable (using destination IP address), but need support from “victim’s router” to eventually use broadcast MAC address for final delivery.

All in all it still means that destination NIC doesn’t respond to IP operations, so either WoL packet sender or final relay needs to know destination’s MAC address.

Read the linked article, it’s interesting.

11

Fair enough, it is even more confusing. I thought it’s just UDP with different ether type. That it might not be UDP was a suprise.


A sniffer trace of what WOL packet gets generated with your tool when using IP might be useful. @mkx points out there are quite a few flavors in WOL… I was thinking it’s just the “inner” UDP have a specific dst-address, but that may not might right.

12

I agree that the NirSoft WOL tool sending the ARP request for an IP address which shouldn’t be on and answering is a bit odd, but, also, the NirSoft WOL tool does keep a cache of MAC addresses, so it isn’t necessary for the ARP request to get an answer in order for the NirSoft WOL tool to know to what MAC address to direct the magic packet.

I’m away for the next week and a half, but when I get back I’ll do a packet capture on both the sending system and the target system (which will be awake, of course) to see exactly what the NirSoft tool does send, and I’ll post that back here.

I also received a reply from MikroTik support that they have registered the IP unicast feature request for the built-in WOL tool in RouterOS.

13

So. Packet captures.

On the sending host (running NirSoft WakeMeOnLAN):

0000   4c cc 6a d6 39 c7 d8 9e f3 42 de b4 08 00 45 00   L.j.9....B....E.
0010   00 82 b9 e7 00 00 80 11 00 e2 c0 a8 ff 25 c0 a8   .............%..
0020   ff 2a e6 c6 9c 40 00 6e e5 c9 ff ff ff ff ff ff   .*...@.n........
0030   4c cc 6a d6 39 c7 4c cc 6a d6 39 c7 4c cc 6a d6   L.j.9.L.j.9.L.j.
0040   39 c7 4c cc 6a d6 39 c7 4c cc 6a d6 39 c7 4c cc   9.L.j.9.L.j.9.L.
0050   6a d6 39 c7 4c cc 6a d6 39 c7 4c cc 6a d6 39 c7   j.9.L.j.9.L.j.9.
0060   4c cc 6a d6 39 c7 4c cc 6a d6 39 c7 4c cc 6a d6   L.j.9.L.j.9.L.j.
0070   39 c7 4c cc 6a d6 39 c7 4c cc 6a d6 39 c7 4c cc   9.L.j.9.L.j.9.L.
0080   6a d6 39 c7 4c cc 6a d6 39 c7 4c cc 6a d6 39 c7   j.9.L.j.9.L.j.9.

Frame 5: 144 bytes on wire (1152 bits), 144 bytes captured (1152 bits) on interface \Device\NPF_{32469523-BD20-4A8A-9A64-AFEF34EAA3F1}, id 0
    Section number: 1
    Encapsulation type: Ethernet (1)
    Frame Number: 5
    Frame Length: 144 bytes (1152 bits)
    Capture Length: 144 bytes (1152 bits)
    [Protocols in frame: eth:ethertype:ip:udp:wol]
Ethernet II, Src: Dell_42:de:b4 (d8:9e:f3:42:de:b4), Dst: Micro-St_d6:39:c7 (4c:cc:6a:d6:39:c7)
    Destination: Micro-St_d6:39:c7 (4c:cc:6a:d6:39:c7)
    Source: Dell_42:de:b4 (d8:9e:f3:42:de:b4)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.255.37, Dst: 192.168.255.42
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 130
    Identification: 0xb9e7 (47591)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 128
    Protocol: UDP (17)
    Header Checksum: 0x00e2 [validation disabled]
    Source Address: 192.168.255.37
    Destination Address: 192.168.255.42
User Datagram Protocol, Src Port: 59078, Dst Port: 40000
    Source Port: 59078
    Destination Port: 40000
    Length: 110
    Checksum: 0xe5c9 [unverified]
    UDP payload (102 bytes)
Wake On LAN, MAC: Micro-St_d6:39:c7 (4c:cc:6a:d6:39:c7)
    Sync stream: ffffffffffff
    MAC: Micro-St_d6:39:c7 (4c:cc:6a:d6:39:c7)

On the receiving end:

0000   4c cc 6a d6 39 c7 d8 9e f3 42 de b4 08 00 45 00   L.j.9....B....E.
0010   00 82 b9 5e 00 00 80 11 01 6b c0 a8 ff 25 c0 a8   ...^.....k...%..
0020   ff 2a f0 c1 9c 40 00 6e db ce ff ff ff ff ff ff   .*...@.n........
0030   4c cc 6a d6 39 c7 4c cc 6a d6 39 c7 4c cc 6a d6   L.j.9.L.j.9.L.j.
0040   39 c7 4c cc 6a d6 39 c7 4c cc 6a d6 39 c7 4c cc   9.L.j.9.L.j.9.L.
0050   6a d6 39 c7 4c cc 6a d6 39 c7 4c cc 6a d6 39 c7   j.9.L.j.9.L.j.9.
0060   4c cc 6a d6 39 c7 4c cc 6a d6 39 c7 4c cc 6a d6   L.j.9.L.j.9.L.j.
0070   39 c7 4c cc 6a d6 39 c7 4c cc 6a d6 39 c7 4c cc   9.L.j.9.L.j.9.L.
0080   6a d6 39 c7 4c cc 6a d6 39 c7 4c cc 6a d6 39 c7   j.9.L.j.9.L.j.9.

Frame 69: 144 bytes on wire (1152 bits), 144 bytes captured (1152 bits) on interface \Device\NPF_{9F0D01C4-3179-4B28-9AA5-6DA0D69468CF}, id 0
    Section number: 1
    Encapsulation type: Ethernet (1)
    Frame Number: 69
    Frame Length: 144 bytes (1152 bits)
    Capture Length: 144 bytes (1152 bits)
    [Protocols in frame: eth:ethertype:ip:udp:wol]
Ethernet II, Src: Dell_42:de:b4 (d8:9e:f3:42:de:b4), Dst: Micro-St_d6:39:c7 (4c:cc:6a:d6:39:c7)
    Destination: Micro-St_d6:39:c7 (4c:cc:6a:d6:39:c7)
    Source: Dell_42:de:b4 (d8:9e:f3:42:de:b4)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.255.37, Dst: 192.168.255.42
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 130
    Identification: 0xb95e (47454)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 128
    Protocol: UDP (17)
    Header Checksum: 0x016b [validation disabled]
    Source Address: 192.168.255.37
    Destination Address: 192.168.255.42
User Datagram Protocol, Src Port: 61633, Dst Port: 40000
    Source Port: 61633
    Destination Port: 40000
    Length: 110
    Checksum: 0xdbce [unverified]
    UDP payload (102 bytes)
Wake On LAN, MAC: Micro-St_d6:39:c7 (4c:cc:6a:d6:39:c7)
    Sync stream: ffffffffffff
    MAC: Micro-St_d6:39:c7 (4c:cc:6a:d6:39:c7)

So, it was definitely unicast.

I produced the above two captures by capturing with no capture filter, and then by one-by-one filtering out everything that wasn’t Wake-on-LAN. I found exactly one WOL packet per each time I clicked the Wake Up Selected Computers button in NirSoft Wake Me On LAN.

I remind that, with this particular target host (an MSI Cubi2), if I DON’T use the NirSoft Wake-Me-On-LAN option to unicast, then the target host does NOT wake up.

So, does this tell us anything?

14

If I were you I would try sending that packet to the intended destination device via the traffic generator tool, this seemingly unrelated thread may give you some ideas:
http://forum.mikrotik.com/t/my-gratuitous-arp-script/158056/1

The Wake on Lan packet should be easy to create, it should consist of 6 FF’s followed by 16 repetitions of the destination MAC address, so it should be 17x6=102 bytes.

Here:
https://serverfault.com/questions/161560/how-to-get-wake-on-lan-working
on how to filter in Wireshark:

ether dst FF:FF:FF:FF:FF:FF and ether proto 0x0842

15

Thanks - I now have a couple of rather brute force but functional scripts, one way to send a host-appropriate magic packet, to two different of my local LAN hosts. It works.

It would still be nice to see a user-friendly addition to the existing RouterOS WOL tool to specify that the magic packet must be unicast.

warm regards,

16

Please share the script :grin:

17

Not sure how wide-spread the problem, but given @fragtion is also interested. You should file as a feature request at help.mikrotik.com.

From the wireshark, it’s appears it just uses the IP of the host in the UDP packet… So I doubt it be hard to just have an extra attribute like ip-address= (that defaulted to broadcast 255.255.255.255).

18

I truly brute forced this, so there’s not much “script”; anyway, I’d already made the feature request last week.
Here’s what little I have:

##
##   Send unicast WOL packet to host AVClientXB1's Ethernet interface MAC address 4C-CC-6A-D6-39-C7
##


########## Set variables

## Notification e-mail
:local email "inserthere@your.org"

## Interface out through which to send it - we use our group master LAN port
## This may vary on your RouterOS device
:local outintf "ether2-master-local"

## Destination MAC address - NOT BEING CONFIGURABLE LIKE THIS, YET
##:global dstmac "4CCC6AD639C7"

## The actual whole magic packet for that specific MAC
:local magicpkt "4ccc6ad639c7d89ef342deb4080045000082b9e70000801100e2c0a8ff25c0a8ff2ae6c69c40006ee5c9ffffffffffff4ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c7"

########## Construct the WOL magic packet
## Well, maybe later. For now, it's all in the static blob above, which is a single packet capture by Wireshark, taken on the sender

########## Do it
:log info ("WOL-AVClientXB1: Sending magic packet") 

/tool traffic-generator inject $outintf data=$magicpkt
19

It has to be understood what the beginning of the packet means.
The actual WOL packet is the part that starts with fffffff, before that:
Nothing ← No preamble?
4ccc6ad639c7 ← this is the destination MAC:
d89ef342deb4 ← this is the source MAC
0800 ← this is the packet/frame type (IP protocol) should be 0x0842 in theory
4 ← version
5 ← length of header, 5 x 32 bits= 160 bits → 20 bytes
00 ← DSCP/ECN always 0
0082 ← total length of packet 0x82=130
b9e7<-identification field
0000 ← flags/fragmentation (none set)
80 ← TTL or Time To leave
11 ← protocol 0x11=17=UDP
00e2 <-IP checksum, formula here: https://en.wikipedia.org/wiki/Internet_checksum
c0a8ff25 ← source IP → 192.168.255.37
c0a8ff2a ← destination IP → → 192.168.255.42
e6c6 → Source port 59078
9c40 → Destination port 40000
006e ← length 0x006E=110
e5c9 ← UDP checksum, formula here:https://en.wikipedia.org/wiki/User_Datagram_Protocol Can probably be omitted (setting it to 0000)
The WOL packet:

ffffffffffff
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7
4ccc6ad639c7

20

@jaclaz asked about this part of the WOL packet:

d89ef342deb4080045000082b9e70000801100e2c0a8ff25c0a8ff2ae6c69c40006ee5c9

Apologies, I might have shown the Wireshark interpretation from one WOL packet sent, but WOL packet data from a second occurrence:

d8:9e:f3:42:-de:b4

is the MAC address of the machine from which I sent the WOL packet.

Then,

08:00

specifies IPv4

The next block:

45000082b9e70000801100e2c0a8ff25c0a8ff2a

.. wireshark explains as:

  • protocol definition (UDP)


  • total packet length (130)


  • checksum (two hex bytes), and


  • source and destination IP addresses (192.168.255.37, 192.168.255.42)

The final block before the ffffffffffff lead-in to the actual magic packet contents:

e6c69c40006ee5c9

.. wireshark describes as the UDP content:

  • source port: 61634


  • dest port: 40000
    (information that I find about WOL magic packets suggest that the dest port is irrelevant to the receiving host, and of course the source port is just whatever was available to the sendering host at the moment, and also has no importance to the success or failure of the WOL attempt), and


  • length: 110


  • checksum: (two hex bytes)

.. and finally the UDP 102 bytes payload which is the ffffffffffff followed by a bunch of repetitions (17 in this case, I think I counted?) of that target MAC address.

So, in an updated RouterOS tool /wol, probably little (futher) ‘magic’ (heh) is needed around this particular block of bytes, just that a target unicast IP instead of broadcast would be built in.