Can someone please check if /tool wol is working correctly on their devices?
Especially when using interface= parameter
In my case, sometime after upgrading to 7.x Wake on LAN packets are no longer being sent from hAP ac3.
I'm currently using latest RouterOS version 7.20.2 on hAP ac3 (main router) and ac2 (AP)
On ac3 I cannot see that it is sending WOL packet on UDP port 9 at all, regardless if I call "/tool wol" with or without interface parameter on any available interface.
/tool wol mac=aa:bb:cc:dd:ee:ff #does not work
/tool wol mac=aa:bb:cc:dd:ee:ff interface=bridge1 #does not work
/tool wol mac=aa:bb:cc:dd:ee:ff interface=ether5 #does not work
On ac2 which has a much simpler configuration and only has one brigde interface, WOL packet is only being sent when interface is not specified
/tool wol mac=aa:bb:cc:dd:ee:ff #WORKS!
/tool wol mac=aa:bb:cc:dd:ee:ff interface=bridge1 #does not work
/tool wol mac=aa:bb:cc:dd:ee:ff interface=ether5 #does not work
When ac2 does sent WOL package (without interface=) it does it on all interfaces which are up (bridge, ether5 and wlan1 - for example)
I'm using
/tool sniffer set filter-dst-port=discard filter-ip-protocol=udp
to check if WOL packet is being sent (as well as monitoring on LAN using wireshark...)
Something is off here, I'm sure it was working on ROS v6.x
What I would expect to see when calling /tool wol is that it either sends WOL packet on all interfaces without interface= parameter or to send only on a single specified interface. But that is not what I see here.
Sending WOL packets is still not working as expected...
/tool wol mac=aa:bb:aa:bb:aa:bb # sends packet on ether1 interface (Internet)
/tool wol mac=aa:bb:aa:bb:aa:bb interface=ether1 # no packet sent
/tool wol mac=aa:bb:aa:bb:aa:bb interface=ether5 # no packet sent
/tool wol mac=aa:bb:aa:bb:aa:bb interface=bridge # no packet sent
/tool wol mac=aa:bb:aa:bb:aa:bb interface=wlan1 # no packet sent
As always with Mikrotik Routers do you first have the default config from the RouterOS version.
So if you want to file a bug, you have to reset the device to the default config and then test the thing that doesn't work.
Like if you have design vlans and so on that not get it correct.
Thanks @patrikg, I'll try this as well.
In the meantime can you please test it on your end and see if you get results that make sense (i.e wol tool respecting interface= parameter)?
Did you filed the bug report? i have the same problem here, wol is being sent on default interface(another subnet) and i cant wake up my pc on lan with mikrotik, when i use interface=bridge1 none package at sniffer is shown, when not using interface parameter, it is sent to a diferent subnet…
Yes, I reported this on MikroTik support portal, but didn't hear back from them yet.
Feel free to report it as well, maybe they'll acknowledge the problem sooner.
This is exactly the issue I'm seeing, it's not possible to send WOL to any LAN based host since WOL packet is going out only on default Internet facing interface.
Well, I also thought that WoL is not working. But after little investigation I discovered that these packets weren’t UDP. This is what I get:
/tool/wol mac=00:1e:4f:52:7e:6e interface=some_vlan
In fact 0x0842 is standardized as ethertype for WoL. UDP is sometimes used by user-level tools that do not want to demand root privileges, but it should not matter because WoL does not look at the headers at all but merely checks if the own MAC address appears in the packet 16 times.
That it doesn’t work, well, that is a common occurrence with WoL. There are a lot of things that have to fall into place for this to work.
Correct filter to capture WOL packets should then be:
ether proto 0x0842 or udp port 9
Looks like Mikrotik does send both packet types, UDP and protocol 0x0842, probably depending on some additional logic (could depend on which interface= parameter to /tool/wol is specified, if any...)
It would be great if this was explained in more detail in Mikrotik documentation.
Current documentation is only mentioning UDP Magic Packet and does not mention Ethernet Type Wake On LAN (0x0842) or when which one is sent.
Indeed the documentation is wrong because what is sent is not (always) a UDP packet.
However, before complaining to MikroTik the OP should first test with a known-good WoL tool from another computer on the local network, because WoL often fails to work especially on modern machines.
It will at least require BIOS settings to be changed, and with Windows also “network interface adapter setting” changes and possibly sleep state settings. E.g. when the sleep state S5 is configured, it usually will not work and that has to be changed.
Well the issue I had was that I didn't see the expected WOL traffic as UDP from Mikrotik in certain cases.
But now we know that Mikrotik is not consistently sending same packet types but sometimes sends IP/UDP packets and sometimes sends WOL type packets (ethernet type 0x0842) and there has to be some logic as to which is sent at what time, since it is consistent when you try to send across different interfaces or VLANs.
Thanks @pe1chl for pointing in the right direction, at least the mystery of Mikrotik not sending packets at all from /tool/wol is now a bit clearer
But how did you get here? I presume you were trying to wake some system and it did not work? Or is it something else?
Because while the sent WoL packet is not the UDP packet you tried to catch, the packet that is sent should still work as WoL. That is, when WoL does work at all.
How I got here is that I was verifying my setup after migration from ROS 6.x to ROS 7.x and implementing VLANs during that time.
I wanted to check if WOL scripts I was using are still able to send WOL packets to wake certain hosts on my LAN now that VLANs were configured (interface= parameters needed to be changed due to VLAN).
So what better way to do that than to fire up tcpdump/wireshark and watch for packets on UDP port 9, right?
If you see a packet on the wire then it should work same as it was working before - much easier than shutting down all relevant hosts and trying to wake them up using new Mikrotik configuration.
And since I didn't see the UDP packets I was trying to capture I assumed that Mikrotik is not sending any WOL packets
I'll make sure to verify WOL behaviour when relevant hosts are down, but that test will be postponed for another time.
Ok I understand… so probably there is nothing wrong at all.
In the past I had working WoL on our office network and I used it to wake up all PCs e.g. on sunday to install updates, but while that initially worked, it has had issues several times and in the end (due to configuring port authentication on switches, buying new PCs, etc) I have just given up and have configured a wake-up time in the BIOS. Of course it is a different purpose than you may have.
