/tool wol - target IP address?

libove · Sun Apr 14, 2024 10:58 am

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.

Kanzler · Sun Apr 14, 2024 11:04 am

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

libove · Sun Apr 14, 2024 11:07 am

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

?

jaclaz · Sun Apr 14, 2024 3:02 pm

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

See here:
viewtopic.php?t=172386
viewtopic.php?t=100434
viewtopic.php?t=100434#p585755

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.

libove · Sun Apr 14, 2024 3:37 pm

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).

almdandi · Mon Apr 15, 2024 11:06 pm

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.

Amm0 · Tue Apr 16, 2024 1:15 am

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.

mkx · Tue Apr 16, 2024 5:47 pm

Theoretically WOL could be on a BMC with an IP address ...

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.

Amm0 · Tue Apr 16, 2024 6:22 pm

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.

mkx · Tue Apr 16, 2024 7:30 pm

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.

Amm0 · Tue Apr 16, 2024 11:18 pm

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.

With NirSoft's WakeMeOnLAN tool, I can successfully wake-on-lan an MSI Cubi2 system on my LAN.

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.

libove · Wed Apr 17, 2024 9:20 pm

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.

libove · Sun Apr 28, 2024 8:24 pm

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?

jaclaz · Sun Apr 28, 2024 9:10 pm

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:
viewtopic.php?t=186010

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/16156 ... an-working
on how to filter in Wireshark:

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

libove · Sun Apr 28, 2024 11:20 pm

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,

fragtion · Mon Apr 29, 2024 3:33 am

Please share the script

Amm0 · Mon Apr 29, 2024 5:03 am

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.

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).

libove · Mon Apr 29, 2024 10:23 am

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

jaclaz · Mon Apr 29, 2024 10:32 am

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

libove · Mon Apr 29, 2024 12:01 pm

@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.

jaclaz · Mon Apr 29, 2024 12:18 pm

I am editing/adding info in my previous posts.

The source/destination ports seem not to be plainly encoded?

e6c69c40
should mean:
e6c6 -> 59078
9c40 -> 40000
the second is fine, the first ?

The only difficulties in creating a new packet seem to me, once the last fields (ports) are clear, calculating the two checksums and length fields.
The repetitions are 16, to which you add the ffffffffffff, they are (16+1)=17x6=102

From what I understand (not necessarily right, mind you) the wake on lan packet is "detected" because of the leading ffffffffffff, so that cannot be changed to other MAC address.

mkx · Mon Apr 29, 2024 9:02 pm

The WoL magic is all inside the packet payload, meaning ffffffffffff plus the destination MAC address repeated N times.

Ethernet headers are only of interest of L2 devices on the way (switches) ... if these (still) have dst-mac in their FDB tables, then they will pass frame on (hopefully) correct egress port, otherwise they will flood it out through all (except ingress) ports - the later is exactly the same as if it was initially sent to broadcast MAC address.
So apart from sending frame out through a few more ports nothing changes. Further more, using unicast dst MAC address can miss the correct egress port if FDB is not correct for some reason (e.g. if NIC, after going into WoL sleep state, was re-connected to different switch port ... as long as device is inactive, switch can not update FDB).

IP and UDP headers are even less interesting, target NIC doesn't have IP stack alive (and hence doesn't even know own IP address). The only entity, interested in IP headers, is a potential router on the packet's path.
UDP is usually used as L4 protocol because it allows to send out a packet with some payload without target ever replying (e.g. TCP requires some handshake before first payload can be sent out). Other protocols (e.g. ICMP), which might allow sending required payload in initial frame, are sometimes more restricted for use by non-privileged processes.

To return to initial request: adding possibility to send WoL packet to certain IP address is aide to user who then doesn't need to know device's MAC address. But then device offering such service would have to collect MAC/IP mappings in a pseudo-permanent manner. Which ROS currently doesn't do as it doesn't have any other use case for such table (yet).

libove · Tue Apr 30, 2024 12:17 am

NirSoft WakeMeOnLAN also needs to manually keep the IP-to-MAC mapping, and while it might be nice for RouterOS to implement this database of once-known ARP mappings, really the /tool WOL doesn't *require* such a database to be created - just to have the necessary options e.g.:

/tool wol interface={whatever} dst-mac=AA:BB:CC:DD:EE:FF dst-ip=192.168.255.42

And, maybe also,

... route-via={intermediate-router's-IP-address}

, which, yes, would require the administrator/script to embed even more static knowledge about the network layout, but it would still be useful for most small(er) networks.

To return to initial request: adding possibility to send WoL packet to certain IP address is aide to user who then doesn't need to know device's MAC address. But then device offering such service would have to collect MAC/IP mappings in a pseudo-permanent manner. Which ROS currently doesn't do as it doesn't have any other use case for such table (yet).

libove · Tue Apr 30, 2024 12:19 am

I can't answer for why the source port seems to be wrong - could even be just an editing error on my part when I posted earlier.
But I don't think it matters, since as @mkx points out, the target station doesn't look at the IP/UDP parts of the packet, and doesn't check checksums, anyway.

The source/destination ports seem not to be plainly encoded?

e6c69c40
should mean:
e6c6 -> 59078
9c40 -> 40000
the second is fine, the first ?

jaclaz · Tue Apr 30, 2024 12:52 am

In theory, all this stuff Is not needed (the encapsulation of the 0x0800 ethertype and the UDP packet), this much simpler 0x0842 packet should have the same effect:

4ccc6ad639c7d89ef342deb40842ffffffffffff4ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c7

or at least it is seemingly parsed correctly on:
https://hpd.gasmi.net/

libove · Tue Apr 30, 2024 8:32 pm

I tested this. As expected, yes, it does work.
Not sure whether it's specifically better to use the simpler (non-routable) packet vs. a (routable, slightly more complex) UDP packet, but anyway yes it does work.
-Jay

In theory, all this stuff Is not needed (the encapsulation of the 0x0800 ethertype and the UDP packet), this much simpler 0x0842 packet should have the same effect:
4ccc6ad639c7d89ef342deb40842ffffffffffff4ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c74ccc6ad639c7
or at least it is seemingly parsed correctly on:
https://hpd.gasmi.net/

jaclaz · Tue Apr 30, 2024 9:12 pm

Well, this is much easier to script, no lengths, no checksums to be calculated, and will work for most people in a simple LAN.

I am not even convinced that the encapsulated UDP packet may work (the fact that is routable does not mean that it will be actually routed correctly) on many setups where routing between subnets or wan is involved (without some persistent IP/ARP mapping or some other "magic" trick).

TP-LINK has a detailed page:
https://www.tp-link.com/us/support/faq/2156/
on how to configure the router to do WOW (Wake on Wan

)

On Mikrotik, likely you need something *like* this workaround

:
https://www.reddit.com/r/mikrotik/comme ... _solution/
(for "normal" broadcast/multicast)

mkx · Wed May 01, 2024 11:51 am

I am not even convinced that the encapsulated UDP packet may work ...

It won't work without the "last mile router" collecting IP/MAC mappings. Without support on router it'll try to deliver UDP packet just like it was ordinary packet ... and will try to do ARP whohas inquiry which will obviously fail (because NIC in WoL sleep state doesn't run IP stack) and router will thus drop the packet because it won't be able to find the final recipient.

With workaround mentioned it will work ... because you as administrator will do the static IP/MAC table collection.

libove · Wed May 01, 2024 11:55 am

All of this is great discussion. In the end, in case anyone from MikroTik is reading, at a minimum just please implement the (already submitted) feature request to do unicast instead of only broadcast. Anything else would be gravy.
thanks

mkx · Wed May 01, 2024 12:02 pm

... at a minimum just please implement the (already submitted) feature request to do unicast instead of only broadcast.

Please elaborate on the following two questions: What would be the benefit of using unicast ethernet frames instead of broadcasts? What would be benefit of using unicast IP address instead of broadcast? I'm truly interested.

libove · Wed May 01, 2024 1:43 pm

It's what I said when I first started this thread -- some WOL-capable adapters, inexplicably?, REQUIRE the unicast - my MSI Cubi2 for example. It ignores broadcast WOL packets.
-Jay

... at a minimum just please implement the (already submitted) feature request to do unicast instead of only broadcast.

Please elaborate on the following two questions: What would be the benefit of using unicast ethernet frames instead of broadcasts? What would be benefit of using unicast IP address instead of broadcast? I'm truly interested.

jaclaz · Wed May 01, 2024 3:06 pm

I am not convinced that the 0x0800 and UDP encapsulating serves any purpose besides making the packet routable (given that some other trick actually allows it to be routed).
The "plain" 0x0842 is delivered because of the first 6 bytes are the specific MAC address of the device to be woken (since there is no IP address anywhere in the packet, it must work at L2 level).
The encapsulated packet is as well IMHO delivered because of the first 6 bytes are the specific MAC address of the device to be woken (since there is no real IP assigned to the device which is off and waiting for the WOL packet, I don't understand how an IP may be involved).
In other words, I believe that one could make an encapsulated packet with *any* destination IP (as long as it belongs to the same subnet) but that only allows for the packet to *somehow* go to the right interface of the router, the destination device is still represented by the first 6 bytes.

I.e. since we are talking freely and inventing commands

, the (completely hypothetical) command:

/tool wol interface={whatever} dst-mac=AA:BB:CC:DD:EE:FF dst-ip=192.168.255.42

could probably be the same as:

/tool wol interface={whatever} dst-mac=AA:BB:CC:DD:EE:FF dst-subnet=192.168.255.0/24

(the command would create the encapsulated WOL packet with the broadcast address 192.168.255.255 as destination IP)

mkx · Wed May 01, 2024 5:14 pm

@libove is stating an almost sensible reason. I don't know why exactly would MSI break standard behaviour (could be they are trying to "enhance security" by ignoring broadcast frames ... or they are trying to skip processing usual broadcast packets, such as DHCP handshake and what not while in sleep mode). Since this kind of functionality still wouldn't depend on gathering IP/MAC pairs, it could be done (MAC address is already passed as property to ROS command).

But any dependence on actual IP address is insanity. Using actual IP address doesn't matter (NIC waiting for WoL frame doesn't run IP stack; router without support for "WoW" likely wouldn't be able to pass frame to correct LAN device due to missing IP stack on target NIC).

Using broadcast IP address with UDP payload might allow WoW ... if "last mile router" allows routing traffic towards broadcast address (personally I'd consider this a serious security flaw).

libove · Wed May 01, 2024 6:07 pm

Whatever we may think of it, it's a thing.

Lookup man ethtool, https://man7.org/linux/man-pages/man8/ethtool.8.html
See the section on WOL option:

wol p|u|m|b|a|g|s|f|d...
                  Sets Wake-on-LAN options.  Not all devices support
                  this.  The argument to this option is a string of
                  characters specifying which options to enable.
                  p   Wake on PHY activity
                  u   Wake on unicast messages
                  m   Wake on multicast messages
                  b   Wake on broadcast messages
                  a   Wake on ARP
                  g   Wake on MagicPacket™
                  s   Enable SecureOn™ password for MagicPacket™
                  f   Wake on filter(s)
                  d   Disable (wake on nothing).  This option
                      clears all previous options.

The fact that ethtool supports enabling an option to instruct an interface to accept WOL as a unicast message means that some interfaces do support (or, as apparently in the case of my MSI Cubi2, require) this.

ManageEngine's documentation also notes that this exists: https://www.manageengine.com/products/o ... 20directly.

Since it is a needed use case, it would be a useful feature for MikroTik to add.

jaclaz · Wed May 01, 2024 7:41 pm

For what is worth, a (rigorously half-@§§ed and not fully tested) WOL generator in a spreadsheet.
Should be enough to play a little bit with various values.

libove · Wed May 01, 2024 9:52 pm

For what is worth, a (rigorously half-@§§ed and not fully tested) WOL generator in a spreadsheet.
Should be enough to play a little bit with various values.

/tool wol - target IP address?

/tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?

Re: /tool wol - target IP address?