Wake on Lan works sometimes

Hi all,

I've set up a fileserver at home and I don't usually need it running through the night so I figured I should be able to turn it on and off in an automation. I wanted to use WOL and got the node. I have a Firewalla Blue Plus with NodeRED running in docker.

Everything looked good at first, couldn't bring it up from shutdown, but could bring it up from hibernate or suspend; either would be fine for me. I turned it off from the command line in these scenarios. Started on the shutdown (hibernate) part and got that working through the execute node from a NodeRED instance running on the server itself (using MQTT to talk between the 2 NodeRED instances).

Then I tried it together. Could not consistently bring the server back up when I had hibernated or suspended it using NodeRED, nor when I manually do it directly on the server. Double checked that the ethernet port was still in 'g' mode after a reboot, it was. Tried a windows tool, Aquila's WakeOnLan, which confirmed that packets were coming in when I was trying to wake my (running) laptop from the wake on lan node. Tried a phone app, which succeeded to wake my server each and every time. I tried UDP port 7, that worked once, no luck afterwards.

I'm running out of ideas on how to debug this. I am not intimately familiar with Linux: I could not find an equivalent of the tool I used to confirm the packets were being received on my laptop. It consistently working from the phone app seems to suggest everything is ok on the server's side. Anybody any ideas?

Thanks!

p.s. as alternatives I could look into waking the machine on power and putting a NodeRED controlled power switch between it and its socket, or, because it's in a streacom case I could try to find a Flirc-SE and control it from my Logitech Harmony, either seems less ideal than just using WOL, though if I had a spare of either I might just set that up.

You haven't explained clearly enough for me to understand what machines you have in the network and which one is being awoken (or not). Also what OSs are you running on them and how are they interconnected?

Sure, devices (among others I expect would not expect to be relevant, think various IoT devices, printer, my HTPC, etc.):

  • Firewalla Blue Plus: Linux based device, mostly acts as a firewall, but has the ability to add functionality through docker. I have loaded the latest NodeRED in docker on this device. This device will be always on.

  • Ubuntu 20.04.2 LTS fileserver (+ some other functionalities) on Asus f2a85-m motherboard and AMD A10-5700 CPU. Currently always on and runs my home automation in NodeRED docker and a local NodeRED to allow me to use the execute node for certain functionalities (like the hibernate or suspend). I would like to move the home automation to the Firewalla as it will use a lot less power and needs to always be on anyway (this is why the home automation was already delegated to docker, making it more like the to be situation). This is the device I want to be able to turn off and on.

  • Windows 10 laptop (not really part of the concern, but the machine I use to SSH to the others from).

  • Xiaomi Mi9SE phone with the Wake On Lan app (also not really part of the concern, but used for testing WOL).

The Firewalla and Ubuntu server are hardwired, laptop and phone use wireless to get on the same network through my linksys MR8300 router (possibly through a switch). The Firewalla creates a virtual network in the 192.168.99.x range for which it handles DHCP and does monitoring, all the devices in question are on this virtual network.

My reasoning is that as the phone can successfully do the WOL consistently the network setup is suitable.

Does 'this' apply to the Firewalla in the sentence before, or the Ubuntu machine bullet point that the statement is under?

What node?

"this" applies to the entire bullet: the Ubuntu machine.

node-red-node-wol

Does WOL work from a full power down?
Have you checked the BIOS/UEFI for a setting to enable WOL?

What does this give running on the Ubuntu machine
sudo ethtool <interface>
<interface> is the interface the WOL should be coming in on. for example eth0 or enp0s31f6. If you don't know what the i/f is called then sudo ip link show will tell you what they are. It should also show you the mac address that you need to use with the WOL, but presumably you have already checked that.

Full power down: no, it seems only hibernate and suspend work
BIOS/UEFI: considering it seemed to work from the mobile app I didn't check

I am guessing that as it won't wake from shutdown checking the bios is next? Will be a bit slower with responses as I'll get a monitor hooked up.

Other answers:

Ethtool:
Settings for enp3s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes

ip link show: 2:
enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 50:46:5d:8b:98:71 brd ff:ff:ff:ff:ff:ff

If it doesn't work from a full power down then it isn't working properly. Check the BIOS. I think almost always there will be a setting and the default is usually off.

That is good. It is enabled in the interface. That is different to the BIOS however.
I would get it working with a full power down first before worrying about hibernate/suspend.

Found some BIOS settings, power on after shutdown from app works, first try from NodeRED does too. I'll try it a few more times to see if it keeps working.

Getting hybrid-suspend working would be best, but I can live with having to wait for it to boot from time to time (or more likely: making sure it's turned on before I need it).

You might find that it now works reliably from hibernate/suspend too.

Unfortunately it stopped waking from NodeRED again after working the one time. I've tried both waiting 5 minutes as well as sending WOL messages every second just in case it worked the one time because the LAN was not completely shut down yet. No difference: have lost the ability to turn it on through NodeRED again.

Phone app keeps working just fine.

I shut it down through 'sudo systemctl poweroff -f' if that would make any difference.

How have you configured the WOL node?

You could run tcpdump on the server (with it running obviously) and see what the difference is between seniding the packet from the phone app and from node-red. There must be a difference.

Did I see node-red was running on docker mentioned somewhere in this thread?

I think wol magic packet might not work as expected due to bridged port or non privileged port.

Should be fine from a regular node-red installation.

You can probably mess about with networking and get it going but I am not a docker expert.


I have also tried empty Target Address and 192.168.99.255 as recommended in various places.

Looking at tcpdump, but getting a lot of info from it.

@Steve-Mcl Indeed it runs in docker, on the device I want to use for it running in docker is the only option.

tcpdump:

sudo tcpdump -i enp3s0 '(udp and port 7) or (udp and port 9)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:13:54.998211 IP xiaomi.mi.9.se.lan.49101 > 192.168.99.255.discard: UDP, length 102
18:13:54.998295 IP xiaomi.mi.9.se.lan.44183 > server.lan.discard: UDP, length 102
18:13:54.998564 IP xiaomi.mi.9.se.lan.49778 > 192.168.99.255.discard: UDP, length 102
18:13:54.998815 IP xiaomi.mi.9.se.lan.38540 > server.lan.discard: UDP, length 102
18:13:54.998951 IP xiaomi.mi.9.se.lan.39497 > 192.168.99.255.discard: UDP, length 102
18:13:54.999084 IP xiaomi.mi.9.se.lan.38550 > server.lan.discard: UDP, length 102
18:14:09.341295 IP _gateway.48334 > server.lan.discard: UDP, length 102
18:14:09.439899 IP _gateway.48334 > server.lan.discard: UDP, length 102
18:14:09.540586 IP _gateway.48334 > server.lan.discard: UDP, length 102

Definitely something different coming out, though unsure how to read this. (Initial 6 are the phone).

Anybody any thoughts on the difference I get between the phone WOL and NodeRED WOL?

No, sorry, I am off the end of my knowledge base.

Thanks for trying in any case, hopefully someone else has an idea.