Wake On LAN works but CRON command fails

mowest

Running Pfsense Community Edition 2.7

I can wake my homelab server with "Services / Wake-on-LAN" as one would expect it to work.

I wanted to automate the waking of the homelab server, and in this forum I discovered this command to use with the CRON package.

55	20	*	*	*	root	/usr/local/bin/wol -i 192.168.1.5 11:22:33:44:55:66

Where the ip address is the actual ip address reserved for the homelab server in Pfsense, and the MAC address is the actual MAC address that is shown in "Services / Wake-on-LAN" that does wake the server when used.

I would expect the above entry in the CRON package would turn on the server every night at 8:55pm, but it doesn't turn the homelab server on. The current date and time in Pfsense is also displayed correctly in the overview page.

Any ideas of what I might be missing?

viragomann

@mowest
I used the wol command successfully in the past from the console, but with the broadcast address instead of the IP.

So my command looked like this:

wol -i <Broadcast_address> <MAC_address>

Gertjan

@mowest

Execute it manually

/usr/local/bin/wol  -i 192.168.1.8 90:02:a9:85:48:f9

where 192.168.1.8 isn't fully used - but needed because wol can determine what network (== what interface) should be selected to broadcast on.

Btw : its good behaviour to specify the full command path when cron is used

Have a packet capture running at that moment will show the wake up packet at that interface :

igc0 is my LAN (192.168.1.0/24 interface)
By default, port 40000 is used.

So, the packet is on the wire.

If the device didn't receive it (because of a switch not relaying ?) isn't pfSense fault.
If the device did receive the packet on it's interface but wasn't powered on, so it could actually receive it, not a pfSense issue neither.
The device doesn't support wol ? Not an issue neither.
Etc.

Btw : the payload - the data section in the packet is tree times the device's MAC address.

mowest

Okay, I ran some more tests with "packet capture".

I set up my packet capture as suggested by @Gertjan. Here were the settings shown in "packet capture":

Running packet capture:
/usr/sbin/tcpdump -ni igb1 -c 1000 -U -w - '((port 40000)) and ((not vlan))'

igb1 is my LAN interface.
After "Starting" packet capture. I copied the exact command that I put into the CRON package into the "Diagnostics / Command Prompt", and I got back the curious message (not every time I click "execute" but sometimes, other times it would just say "Waking up bc:ee:7b:db:fc:f4..."):

Shell Output - /usr/local/bin/wol -i 192.168.2.4 bc:ee:7b:db:fc:f4

/usr/local/bin/wol: Cannot send magic packet for 'bc:ee:7b:db:fc:f4' to 192.168.2.4:40000: Host is down

When I used the "Diagnostics / Command Prompt" nothing came through on the "packet capture"

When I used Pfsense's "Services / Wake-on-LAN" set to the LAN Interface with the same MAC address, I got the following in the "packet capture" window:

11:38:04.865781 IP 192.168.2.1.13624 > 192.168.2.255.40000: UDP, length 102
11:38:04.865793 IP 192.168.2.1.13624 > 192.168.2.255.40000: UDP, length 102

(these below came into the packet capture after I had used "Services / Wake-on-LAN", the first two entries, when I used the command in the  "Diagnostics / Command Prompt".)
11:39:12.421630 IP 192.168.2.1.8198 > 192.168.2.4.40000: UDP, length 102
11:39:12.421632 IP 192.168.2.1.53999 > 192.168.2.4.40000: UDP, length 102
11:39:12.421636 IP 192.168.2.1.29442 > 192.168.2.4.40000: UDP, length 102
11:39:12.421637 IP 192.168.2.1.56567 > 192.168.2.4.40000: UDP, length 102
11:48:00.781726 IP 192.168.2.1.23044 > 192.168.2.4.40000: UDP, length 102

As expected my homelab server did wake up. So for some reason, the "Services / Wake-on-LAN" is sending the magic packet out the correct interface the LAN interface, but when I run the command as formatted above in the "Diagnostics / Command Prompt" it doesn't seem to be sending anything through the LAN interface of Pfsense, even through it should since 192.168.2.4 is on the LAN with Pfsense which is 192.168.2.1. I don't have any managed switches. I know the WOL works on the homelab server because Pfsense can wake it with "Services / Wake-on-LAN" so the issue must be in Pfsense somewhere because it works but not in when I have the command in the CRON package.

Gertjan

@mowest said in Wake On LAN works but CRON command fails:

... "Diagnostics / Command Prompt" ...

My advise : you can 'look' GUI at that page.
Any serious work to do ? Open the console, or even better, use SSH.

What the GUI ( ServicesWake-on-LAN ) does : this :

"/usr/local/bin/wol -i {$bcip} {$mac}"

where $(bcip) is the broadcast address of the select interface, probably something like 192.168.1.255 for LAN)
($mac) is the MAC of the device to wake up.
The GUI runs as 'root".

Look familiar ... ;)

When I do this :

I see this :

So the command executed in the GUI works just fine.

When I set up a CRON like this :

and I went away, it was supper time.

When I came back :

So : Am I safe to say that : cron works ?

mowest

@Gertjan

Thanks for all of your help with this issue. I'm unsure why yours is working when you use the actual ip address of your server in CRON, but mine is not.

Because of what I saw in the packet capture, I decided to imitate what the GUI is doing. I changed the command in CRON to:

/usr/local/bin/wol -i 192.168.2.255 bc:ee:7b:db:fc:f4

The above command works in CRON to wake up my server. From what you said, I'm guessing this is because "192.168.2.255" is the "broadcast address" of the LAN interface of the $(bcip) as described in your post.

/usr/local/bin/wol -i 192.168.2.4 bc:ee:7b:db:fc:f4

The original command above did nothing and didn't even show up in "packet capture" until after the server was already up and running, then I would get something similar to what you got in your packet capture in your screenshot above, as you can see from my previous post. However, the command with the actual ip address reserved for my server in Pfsense fails to wake-on-lan my server, but 192.168.2.255 does work.

Thanks for all of your advice and help which resulted in changing "4" to "255" and now it works.