search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.76k stars 495 forks source link

DietPi-Software | "Remote Wake/Sleep-on-LAN Server" (RWSOLS) #2596

Open MichaIng opened 5 years ago

MichaIng commented 5 years ago

Ref: https://dietpi.com/forum/t/wol-server-setup-on-dietpi-build/2979 RWSOLS: https://github.com/sciguy14/Remote-Wake-Sleep-On-LAN-Server

Jurgiebaby commented 5 years ago

Thanks for setting this up @MichaIng and any help from anyone would be greatly appreciated

tindecken commented 5 years ago

look like an useful feature, thanks for great works 👍

Jurgiebaby commented 5 years ago

look like an useful feature, thanks for great works 👍

Can you let me know if you get this working on a dietpi build please as mine will no longer work since i moved over to dietpi @tindecken

MirisWisdom commented 5 years ago

The method I've used for a long time is using etherwake, with a rudimentary function in ~/.bashrc (or ~/.bash_profile) as a shortcut:

# ~/.bashrc

# Sends WOL packet to the designated MAC address on the LAN.
function wol-pc                              
{                                            
  sudo etherwake -i enp0s25 $*
  # $* = MAC address
  # e.g. 8C:CC:3A:D4:44:27
}

Last time I tried it on an RPi w/ DietPi, it worked without any issues. Of course, the RPi & PC would need to be connected to each other over the wire using a LAN switch.

I wonder if this would serve as a workaround for the posted issue: access the RPi over SSH, and invoke the etherwake command to your target PC. 🤔

MichaIng commented 5 years ago

I updated the header since this is about a particular WOL server.

So it seems to be essentiell that the wakeonlan command works and the www-data user has execute permissions to it.

MichaIng commented 5 years ago

@Jurgiebaby Could you try to use the bare wakeonlan command from terminal: wakeonlan mac:address:of:the:sleeping:device

Jurgiebaby commented 5 years ago

@MichaIng What would be the command line entry for this test?

wakeonlan 68:05:CA:2F:9E:73

or is there more to it than that?

MichaIng commented 5 years ago

@Jurgiebaby That should be it.

Jurgiebaby commented 5 years ago

@MichaIng it didn't work to the 2x pc's I tried as you can see below

root@DietPi:/# wakeonlan 68:05:CA:2F:9E:73 Use of uninitialized value in subroutine entry at /usr/bin/wakeonlan line 118. Use of uninitialized value $proto in socket at /usr/bin/wakeonlan line 121. Use of uninitialized value $port in concatenation (.) or string at /usr/bin/wakeonlan line 124. Sending magic packet to 255.255.255.255: with 68:05:CA:2F:9E:73 send : Invalid argument at /usr/bin/wakeonlan line 126. root@DietPi:/# wakeonlan 00:FD:45:FD:BC:60 Use of uninitialized value in subroutine entry at /usr/bin/wakeonlan line 118. Use of uninitialized value $proto in socket at /usr/bin/wakeonlan line 121. Use of uninitialized value $port in concatenation (.) or string at /usr/bin/wakeonlan line 124. Sending magic packet to 255.255.255.255: with 00:FD:45:FD:BC:60 send : Invalid argument at /usr/bin/wakeonlan line 126. root@DietPi:/#

I am guessing but is it something to do with the subnet being 255.255.255.255? as opposed to 255.255.255.0?

MichaIng commented 5 years ago

@Jurgiebaby The subnet/mask is correct. You want to send the wake magic packet to this MAC address regardless of the IP => default broadcast IP 255.255.255.255, so all IPs are listening to this, but only matching MAC address will react.

Here is the failing code part of the perl script (which wakeonlan is):

118 $them = pack_sockaddr_in($port, $raddr);
119 $proto = getprotobyname('udp');
120
121 socket(S, AF_INET, SOCK_DGRAM, $proto) or die "socket : $!";
122 setsockopt(S, SOL_SOCKET, SO_BROADCAST, 1) or die "setsockopt : $!";
123
124 print "Sending magic packet to $ipaddr:$port with $hwaddr\n";
125
126 send(S, $pkt, 0, $them) or die "send : $!";

So perl fails to derive default UDP info in your case, although no idea why this is the case.

EDIT: I think I found the reason. Please try: G_AGI netbase && wakeonlan 68:05:CA:2F:9E:73

Jurgiebaby commented 5 years ago

@MichaIng I have tried both ways now using the new and old wakeonlan command to 2x PC.s and both have not worked in sending the magic packet to wake them up but I do get fewer errors this time as you can see below

root@DietPi:~# G_AGI netbase && wakeonlan 68:05:CA:2F:9E:73
[  OK  ] Root access verified.
[  OK  ] APT installation for: netbase, please wait...
Selecting previously unselected package netbase.
(Reading database ... 59162 files and directories currently installed.)
Preparing to unpack .../archives/netbase_5.4_all.deb ...
Unpacking netbase (5.4) ...
Setting up netbase (5.4) ...

[  OK  ] G_AGI: netbase
Sending magic packet to 255.255.255.255:9 with 68:05:CA:2F:9E:73
root@DietPi:~# G_AGI netbase && wakeonlan 00:FD:45:FD:BC:60
[  OK  ] APT installation for: netbase, please wait...

[  OK  ] G_AGI: netbase
Sending magic packet to 255.255.255.255:9 with 00:FD:45:FD:BC:60
root@DietPi:~# wakeonlan 00:FD:45:FD:BC:60
Sending magic packet to 255.255.255.255:9 with 00:FD:45:FD:BC:60
root@DietPi:~# 68:05:CA:2F:9E:73
-bash: 68:05:CA:2F:9E:73: command not found
root@DietPi:~# ^C
root@DietPi:~# wakeonlan 68:05:CA:2F:9E:73
Sending magic packet to 255.255.255.255:9 with 68:05:CA:2F:9E:73
root@DietPi:~#
MichaIng commented 5 years ago

@Jurgiebaby Ah sorry G_AGI netbase was only meant once to install the package. G_AGI is our wrapper for apt-get install.

So now only wakeonlan 68:05:CA:2F:9E:73 is the command to test. Since the script does not show errors anymore but instead a correct port number (255.255.255.255:9 => port is 9 which is the correct recommended UDP discard port for this feature), the netbase package indeed was the source.

But you say now the remote PCs are still not reacting to it? Can you verify that otherwise those are reachable (when awake) e.g. via ping 192.168.178.21 (using the correct IP instead)?

And perhaps try it as well with etherwake, as my strike through above:

G_AGI etherwake # (only once ;) )
etherwake 68:05:CA:2F:9E:73
Jurgiebaby commented 5 years ago

@MichaIng hi there so when i got home i tried the wakeonlan command to my 2x server boxes and got the following 

root@DietPi:~# wakeonlan 00:FD:45:FD:BC:60
Sending magic packet to 255.255.255.255:9 with 00:FD:45:FD:BC:60
root@DietPi:~# wakeonlan 68:05:CA:2F:9E:73
Sending magic packet to 255.255.255.255:9 with 68:05:CA:2F:9E:73

If I manually boot these 2x machines up I can ping them both from Raspberry Pi Terminal window as follows

root@DietPi:~# ping 192.168.0.29
PING 192.168.0.29 (192.168.0.29) 56(84) bytes of data.
64 bytes from 192.168.0.29: icmp_seq=1 ttl=128 time=28.5 ms
64 bytes from 192.168.0.29: icmp_seq=2 ttl=128 time=29.2 ms
64 bytes from 192.168.0.29: icmp_seq=3 ttl=128 time=25.1 ms

And

root@DietPi:~# ping 192.168.0.30
PING 192.168.0.30 (192.168.0.30) 56(84) bytes of data.
64 bytes from 192.168.0.30: icmp_seq=1 ttl=128 time=28.5 ms
64 bytes from 192.168.0.30: icmp_seq=2 ttl=128 time=29.2 ms
64 bytes from 192.168.0.30: icmp_seq=3 ttl=128 time=25.1 ms

I then installed the Etherwake application and running the following command I can wake both the above PC's up with no issue.

root@DietPi:~# etherwake 68:05:CA:2F:9E:73
root@DietPi:~# etherwake 00:FD:45:FD:BC:60

So now I still have no idea why the Jeremy Blum one no longer sends the WOL Packet but ONLY on DietPi Installation as it has worked perfectly well on all other builds of the Pi :(

I love the DietPi Build but really would love to get this RWOL thing back up and running again as it's great and password protected etc so I can wake remotely, so once again if you can figure anything else out that would be greatly appreciated as ever @MichaIng

Many thanks

Jurgen :)

MichaIng commented 5 years ago

@Jurgiebaby I ran some tests on my VMs and most strange:

I tried to debug both scripts but didn't found any issue anymore nor any possible missing dependencies (like netbase).

I used iptraf to check incoming and outgoing packets:

G_AGI iptraf-ng
iptraf-ng
# IP traffic monitor
# eth0

Could you check this as well?

MirisWisdom commented 5 years ago

@MichaIng

For etherwake, mind specifying the interface of your VM's NIC? Example:

etherwake -i <interface> <mac:address>
# etherwake -i enp0s25 8C:CC:3A:D4:44:27

I always had to explicitly pass the interface as a parameter for the packets to be sent successfully. Not sure if this would resolve it, but it might be worth a shot!

MichaIng commented 5 years ago

@yumiris Thanks for the suggestion. However I already tried it an it has no effect, especially since my VMs only have one network interface. I also tried to set/change all other options but etherwake simply does not attempt to send any request out to any interface (which I can monitor) and while doing nothing also does not throw any error message or error code. Veery strange 🤔. Also it is the same on Stretch and Buster, so at least no issue with one particular system but either with the package/binary on Debian amd64 and/or VM systems in particular.

I will test the same on my notebook with WiFi.

MirisWisdom commented 5 years ago

That is certainly very strange. I've never had issues wither WOL in a DietPi VM when using etherwake. I'll spin up a VM soon and try to test it out from scratch -- this really got me curious. :P

MichaIng commented 5 years ago

Just the same on notebook, wakeonlan works fine, reaching the VMs and the other way round while etherwake does not send anything. etherwake by default tries eth0 (at least if it is available at all), so to use it via WiFi I needed to add -i wlan0. But it throws an error about that as well, so nothing one can miss. But giving the correct interface still does not send anything out.

EDIT

Jep indeed strange, especially since for @Jurgiebaby it is exactly the other way round. etherwake working while wakeonlan not, which is what he needs for the web UI wrapper 😕. But to track this down the package monitor result would be indeed interesting.

MirisWisdom commented 5 years ago

WOL can only be done through Ethernet (in most practical scenarios) -- have you tried connecting your notebook to the other PC with a cable (either directly or using a LAN switch)?

As for the VM, which hypervisor are you using? I'll try to test out DietPi later today with a setup similar to yours and see if I can reproduce the issue.

MichaIng commented 5 years ago

@yumiris

WOL can only be done through Ethernet (in most practical scenarios)

However wakeonlan works perfectly fine here over WiFi. I just switched to Ethernet, but no change, wakeonlan still works while etherwake does not.

Even sending magic packets to the very own MAC via eth0 or lo (loopback interface) shows no outgoing or incoming package. etherwake really seems to fail deep in its core, perhaps using wrong network core features or something (on my x86_64 systems).

As for the VM, which hypervisor are you using?

VirtualBox attached to local network via bridged network through... ah... again WiFi on the host system. One last thing to be really sure is to attach the host system via Ethernet as well, although the DietPi test notebook also is not able to send etherwake packets to itself.

EDIT: No change as well, WiFi and Ethernet behave exactly the same.

MirisWisdom commented 5 years ago

However wakeonlan works perfectly fine here over WiFi.

Is the target PC connected over cable? 🤔 A device cannot receive incoming WOL packets unless they're connected through Ethernet, because WICs are not powered on when the computer is off.

Stupid question, but can you confirm that eth0 is your actual interface? Nowadays, eth0 is rarely used on latest Linux distributions, which is why I would be surprised if you're using eth0. 😛

Hmmm... this is from my Ubuntu 18.04 host when sending a WOL command to my PC. 

# PC IS OFF

miris@gensokyo:~$ ping 192.168.0.25                                         
PING 192.168.0.25 (192.168.0.25) 56(84) bytes of data.                      
From 192.168.0.10 icmp_seq=1 Destination Host Unreachable                   
From 192.168.0.10 icmp_seq=2 Destination Host Unreachable                   
From 192.168.0.10 icmp_seq=3 Destination Host Unreachable                   
^C                                                                          
--- 192.168.0.25 ping statistics ---                                        
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3077ms 
pipe 4                                                                      

# WOL COMMAND SENT HERE
miris@gensokyo:~$ sudo etherwake -i enp0s25 4C:CC:6A:D8:88:47               

# PC STARTS UP

miris@gensokyo:~$ ping 192.168.0.25                                         
PING 192.168.0.25 (192.168.0.25) 56(84) bytes of data.                      
From 192.168.0.10 icmp_seq=1 Destination Host Unreachable                   
From 192.168.0.10 icmp_seq=2 Destination Host Unreachable                   
From 192.168.0.10 icmp_seq=3 Destination Host Unreachable                   
64 bytes from 192.168.0.25: icmp_seq=5 ttl=128 time=19.2 ms                 
64 bytes from 192.168.0.25: icmp_seq=6 ttl=128 time=0.172 ms                
64 bytes from 192.168.0.25: icmp_seq=7 ttl=128 time=0.195 ms                
64 bytes from 192.168.0.25: icmp_seq=8 ttl=128 time=0.161 ms                
^C
MichaIng commented 5 years ago

@yumiris

Is the target PC connected over cable? 🤔 A device cannot receive incoming WOL packets unless they're connected through Ethernet, because WICs are not powered on when the computer is off.

Jep the last tests included several source + destination on Ethernet connections. However in my test case it didn't matter, because I did not try to actually wake up anything but just monitored the outgoing + incoming magic packets while every device was up. WOL implementations just send six times 000000FF + sixteen times the destination MAC address as a packet to either a specific IP or as broadcast (default). Network adapters that support WOL just scan incoming packets for this "magic" pattern an in case react. So to sort out any WOL compatibility of network adapters I just checked if this packet is sent, which does not require any special hardware support.

Stupid question, but can you confirm that eth0 is your actual interface? Nowadays, eth0 is rarely used on latest Linux distributions, which is why I would be surprised if you're using eth0. 😛

Jep it's either eth0 (VMs) and/or wlan0 (DietPi notebook). Indeed on modern systemd-based OS's the network interfaces are mostly named like enp0s0 which includes the physical position of the network adapter and is thus more reliable than the old eth0/wlan0 naming scheme, where the integers can change when you plug in/off other network devices. A bid comparable to why you should use UUIDs to mount drives instead of their /dev/sdX names, which can as well change when plugging in/off other drives. However DietPi currently still uses the old naming scheme by overriding the related udev-rule via ln -s /dev/null /etc/systemd/network/99-default.link. This is actually something I want to change, generally making DietPi more flexible for different interface names. But low priority 😉.

MirisWisdom commented 5 years ago

@MichaIng

This is certainly getting interesting 🤔 -- how did you analyse the packets in iptraf-ng?

Based on this documentation, etherwake sends the magic packets on port 7:

-P -UDP port on the target mac_address within the broadcast address specified. The default is 7. UDP Port 9 is also commonly used.

I've looked at the list of open ports in iptraf-ng, and port 7 never popped up. The target PC successfully woke up, so the magic packets are indeed being sent. I can try analysing the packets in a different way using iptraf-ng, if you have any suggestions.

Screenshot below shoes the open ports iptraf-ng picked up:

image

MichaIng commented 5 years ago

@yumiris

This is certainly getting interesting 🤔 -- how did you analyse the packets in iptraf-ng?

Installing the package, running iptraf-ng and selecting traffic monitor (first menu option) on the desired interface or all. However tcpdump or any other traffic monitoring tool should work as well.

Based on this documentation, etherwake sends the magic packets on port 7:

Good to know. However should not play a role in my case, since all hosts were on local network without any firewall in place and also on source host I could not see any sent package 🤔.

I cannot see the UDP port 7 package on your iptraf screen, did you take this directly after sending an etherwake packet (simply when destination is awake)?

And it would be interesting if from one of your DietPi systems sending out etherwake and/or wakeonlan magic packets works as well or not, if you find time to test. Actually I am not sure if it might be related to the router/DHCP server, if and how it handles broadcasted packets (IP 255.255.255.255), if it can interfere and block it being received by the destination host. However in case of OT the network seems to generally allow it since etherwake works and on other disto (Raspbian Lite) it works as well. And actually etherwake and wakeonlan "should" do exactly the same, besides using another default port. However I will play around again to assure both attempting to really do exactly the same here.

I am as well thinking which IP etherwake uses by default. It has a separate option to use the broadcast IP (https://manpages.debian.org/stretch/etherwake/etherwake.8.en.html) but no option to define any specific IP. During my test this option didn't have any effect, but if it is not default, which IP does it use by default or does it attempt to derive the destination host IP by the MAC address? But this would require additional software, AFAIK, especially since etherwake is a very small binary, that most likely does not include that feature.

EDIT

It generates the standard AMD Magic Packet format, optionally with a password included. The single required parameter is a station (MAC) address or a host ID that can be translated to a MAC address by an ethers(5) database specified in nsswitch.conf(5)

So the IP can be given instead of the MAC, but then indeed an external "ethers database" is required to allow it deriving the MAC, which is only required to create the magic packet string. So I assume that when given a MAC as argument, it uses the broadcast IP by default and if given an IP as argument it derives the MAC and sends the packet to the given IP only, as long as you do not use the -b option.

EDIT 2

https://www.mkssoftware.com/docs/man1/etherwake.1.asp

etherwake -b 192.168.1.255 00:21:70:c2:c1:88

So you can give both? Hmm this cannot be derived from the man page, however I will try that later, using the local network specific broadcast address, 255.255.255.255 and the desired destination IP in particular.

EDIT 3

https://en.wikipedia.org/wiki/Broadcast_address

A special definition exists for the IP address 255.255.255.255. It is the broadcast address of the zero network or 0.0.0.0, which in Internet Protocol standards stands for this network, i.e. the local network. Transmission to this address is limited by definition, in that it is never forwarded by the routers connecting the local network to other networks.

Just to verify that 255.255.255.255 matches/results in the same than using 192.168.1.255 as above.

MirisWisdom commented 5 years ago

(previous reply didn't format + I didn't see your latest edits until now)

Installing the package, running iptraf-ng and selecting traffic monitor on the desired interface or all. However tcpdump or any other traffic monitoring tool should work as well.

Heh, that's what I've originally tried, but there is too much data to look through.

I cannot see the UDP port 7 package on you iptraf screen, did you take this directly after sending an etherwake packet?

Yup, that was the point of the screenshot: port 7 is not shown, even if the WOL packet was successfully sent. I started iptraf before invoking etherwake, and took the screenshot after sending the successful WOL packet.

And it would be interesting if from one of your DietPi systems sending out etherwake and/or wakeonlan magic packets works as well or not, if you find time to test. Actually I am not sure if it might be related to the router/DHCP server, if and how it handles broadcasted packets (IP 255.255.255.255), if it can interfere and block it being received by the destination host. However in case of OT the network seems to generally allow it since etherwake works and on other disto (Raspbian Lite) it works as well. And actually etherwake and wakeonlan "should" do exactly the same, besides using another default port. However I will play around again to assure both attempting to really do exactly the same here.

I can certainly try the proposed tests on DieTpi. Would you like it to be done from an RPi, or a VM?

MichaIng commented 5 years ago

I can certainly try the proposed tests on DieTpi. Would you like it to be done from an RPi, or a VM?

At best from RPi to match TOs case and void possible VM host-network interferences.

Yup, that was the point of the screenshot: port 7 is not shown, even if the WOL packet was successfully sent. I started iptraf before invoking etherwake, and took the screenshot after sending the successful WOL packet.

Hmm, indeed strange, I am thinking if there might be a reason why the packets are not show by iptraf but ARE actually successfully send, as of your tests the target system successfully woke up? Need to play around with port+IP the next hours.

MirisWisdom commented 5 years ago

@MichaIng

I'll test it out on the RPi this upcoming weekend -- I think it will take longer to find the RPi itself rather than the results of the test. 😛

MichaIng commented 5 years ago

I played around again with etherwake:

root@VM-Stretch:~# etherwake -b 192.168.178.255 08:00:27:9e:d0:6f
etherwake: The Magic Packet host address must be specified as
  - a station address, 00:11:22:33:44:55, or
  - a hostname with a known 'ethers' entry.

However if you say etherwake successfully wakes remote machines even that neither on the source nor destination machine iptraf-ng (or any other monitoring tool) shows any outgoing/incoming packets, then not sure why but perhaps it's somehow hidden only.

The issue stays why wakeonlan does not work for TO, which is what he needs for the web UI. All this ARP/ether IP to MAC does not play a role, since the web UI wakes via exec ('wakeonlan ' . $COMPUTER_MAC[$selectedComputer]); so uses the MAC address anyway.

MirisWisdom commented 5 years ago

Would the Web UI work if you symlink etherwake to wakeonlan?

On 20/03/2019 1:47 am, MichaIng wrote:

I played around again with etherwake:

root@VM-Stretch:~# etherwake -b 192.168.178.255 08:00:27:9e:d0:6f etherwake: The Magic Packet host address must be specified as

However if you say etherwake successfully wakes remote machines even that neither on the source nor destination machine iptraf-ng (or any other monitoring tool) shows any outgoing/incoming packets, then not sure why but perhaps it's somehow hidden only.

The issue stays why wakeonlan does not work for TO, which is what he needs for the web UI. All this ARP/ether IP to MAC does not play a role, since the web UI wakes via exec ('wakeonlan ' . $COMPUTER_MAC[$selectedComputer]); so uses the MAC address anyway.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/MichaIng/DietPi/issues/2596#issuecomment-474492363, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJxFmmtyryuaXcjsnLEKyVO1TyHGjT0Kks5vYSKvgaJpZM4bUhwm.

MichaIng commented 5 years ago

@yumiris

Would the Web UI work if you symlink etherwake to wakeonlan?

Indeed a good idea since both commands take the same argument. Only issue: etherwake requires root permissions to be executed, AFAIK?

@Jurgiebaby So in your case I would at least try the following: ln -s $(which etherwake) /usr/local/bin/wakeonlan

Since it is placed on the local bin path with higher priority, running wakeonlan command would then execute the symlinked etherwake binary. But possible that the web UI cannot run it because it requires root permissions 🤔. Jep indeed:

root@VM-Stretch:~# sudo -u www-data etherwake 08:00:27:9e:d0:6f
etherwake: This program must be run as root.

Okay other last resort solution is replacing the command with a shell script that runs etherwake as sudo and give www-data sudo permissions:

echo -e '#!bin/sh\nsudo etherwake $@' > /usr/local/bin/wakeonlan
chmod +x /usr/local/bin/wakeonlan
echo 'www-data ALL=NOPASSWD: ALL' > /etc/sudoers.d/www-data

Not sure if a reboot might be required to have running commands use the new $PATH variable, but the above should allow your web UI to wake other devices then.

MirisWisdom commented 5 years ago

@MichaIng - I've gotten around to setting up a fresh install on RPi3, and I'm getting the exact same issues on wakeonlan, and absolutely no issues on sudo etherwake:

image

Steps tried:

command pass notes
wakeonlan <mac address> ❌ Use of uninitialized value [...]
sudo wakeonlan <mac address> ❌ Use of uninitialized value [...]
etherwake <mac address> ❌ This program must be run as root.
sudo <mac address> ✔️ PC successfully started!
MirisWisdom commented 5 years ago

I also invoked a WOL command when connected to Wi-Fi, and that didn't work at all. For WOL to work, both the PC & RPi must be connected to each other using Ethernet.

rpi <- ethernet -> gateway <- ethernet -> pc => works!

rpi <- ethernet -> gateway <-   wifi   -> pc => does NOT work

rpi <-   wifi   -> gateway <- ethernet -> pc => does NOT work

rpi <-   wifi   -> gateway <-   wifi   -> pc => does NOT work
MichaIng commented 5 years ago

@yumiris

I've gotten around to setting up a fresh install on RPi3, and I'm getting the exact same issues on wakeonlan

The wakeonlan error is still due to missing netbase package. I will add this to the Debian bug tracker now.

So according to your tests only the RPi needs to be attached via Ethernet, while for the PC to waken it doesn't matter? Did you define the correct WiFi interface manually, since as we found out above etherwake always uses eth0 by default?

Little off-topic as I see your screen:

MirisWisdom commented 5 years ago

@MichaIng

Should I try installing netbase manually and see if it works? 🤔

Blah, I should've copied and pasted better. WOL only works on Ethernet in both the RPi and PC. Any Wi-Fi connection breaks the WOL. My apologies for the mistake -- fixed it now.

It's likely caused by the theme I've set up. Initially I tested directly from the RPi, but for the sake of screenshotting, I SSH'd from the the terminal. I think the custom theme might be affecting the colours a little, as seen here:

image

Luckily the DP colours are rendered without a problem on other terminals. 😛

MichaIng commented 5 years ago

@yumiris Yes you need to install netbase manually. Makes sense that it requires Ethernet on the client to wake since it's the Ethernet cards that can offer the feature to listen to music packets even in low power states. But I thought for the sending WOL server it would not matter.

Perhaps you find a colour code for the banner entries that works on all your terminals. With v6.23 we aim to make custom colour codes system wide (for DietPi scripts/output) :).

MichaIng commented 5 years ago

So finally bug reported: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928314

"Waiting for user reply" = Waiting for bug report reaction 😉.

Furthermore since WOL generally works, I changed this into a software request for some WOL server implementation, e.g. the OP mentioned RWSOLS web UI.

UNiXMIT commented 4 years ago

I wondered why wakeonlan wasn't working for me when it did previously on a previous DietPi image. Installed netbase and it works again. Thanks

MichaIng commented 4 years ago

@UNiXMIT I just bumped the bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928314) and opened a PR at Debian Git repo: https://salsa.debian.org/debian/wakeonlan/-/merge_requests/1 Lets see if we get some more attention now. It is a tiny issue, but most users will not know how to debug/solve, especially since perl does not print any error about/why the two functions fail.