Open MichaIng opened 5 years ago
Thanks for setting this up @MichaIng and any help from anyone would be greatly appreciated
look like an useful feature, thanks for great works 👍
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
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. 🤔
I updated the header since this is about a particular WOL server.
wakeonlan
: https://github.com/sciguy14/Remote-Wake-Sleep-On-LAN-Server/blob/master/index.php#L181So it seems to be essentiell that the wakeonlan
command works and the www-data
user has execute permissions to it.
@Jurgiebaby
Could you try to use the bare wakeonlan
command from terminal:
wakeonlan mac:address:of:the:sleeping:device
@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?
@Jurgiebaby That should be it.
@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?
@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 : $!";
$port
is given, the default "discard" port for UDP is used:
15 my $DEFAULT_PORT = getservbyname('discard', 'udp');
255.255.255.255:
), this seems to fail.$proto
as well tries to derive it from UDP:
119 $proto = getprotobyname('udp')
So perl
fails to derive default UDP info in your case, although no idea why this is the case.
G_AGI netbase && wakeonlan 68:05:CA:2F:9E:73
netbase
provides e.g. /etc/protocols
which contains information that the perl
functions seem to use. So in the APT repo netbase
needs to be added to the dependency list of wakeonlan
. I will send in a bug report (if the above verifies the assumption).
I just found that etherwake
actually is the simpler command (smaller package) while wakeonlan
is the more featured one which allows to read inputs from file as well etc.
Could you try:
G_AGI etherwake && etherwake 68:05:CA:2F:9E:73
@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:~#
@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
@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 :)
@Jurgiebaby I ran some tests on my VMs and most strange:
etherwake
magic packets do not arrivewakeonlan
magic packets do arriveI 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
wakeonlan <mac:address>
on one VM, I can see the packets sent on both iptraf monitors.etherwake <mac:address>
on one VM, I cannot see any packets on any of the two iptraf montors...Could you check this as well?
@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!
@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.
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
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.
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.
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.
@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.
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
@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 😉.
@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:
@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.
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.
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.
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.
(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?
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.
@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. 😛
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.
-b
option does not take any argument.wakeonlan
using port 7 and iptraf
shows it successfully, so the port is not the issue./etc/ethers
, install net-tools
and add MAC IP to the ether file. Then etherwake allows the IP as argument and debug output shows successful IP to MAC resolution from the /etc/ethers entry. But I still don't see any outgoing nor incoming packets even that etherwake debug output always shows Sendto worked ! 116
.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.
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
a station address, 00:11:22:33:44:55, or
a hostname with a known 'ethers' entry.
The -b option does not take any argument.
There is no way to specify the port that etherwake uses. Although it should not play any role besides there are local firewall rules active.
I tested with wakeonlan using port 7 and iptraf shows it successfully, so the port is not the issue.
I also tried to add legacy /etc/ethers, install net-tools and add MAC IP to the ether file. Then etherwake allows the IP as argument and debug output shows successful IP to MAC resolution from the /etc/ethers entry. But I still don't see any outgoing nor incoming packets even that etherwake debug output always shows Sendto worked ! 116.
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.
@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.
@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
:
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! |
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
@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:
/DietPi/dietpi/.dietpi-banner
and change the line aCOLOUR[0]='\e[38;5;154m'
to e.g. aCOLOUR[0]='\e[92m'
which is another code for bright green. The part between \e[
and m
is the actual code here.@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:
Luckily the DP colours are rendered without a problem on other terminals. 😛
@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) :).
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.
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
@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.
Ref: https://dietpi.com/forum/t/wol-server-setup-on-dietpi-build/2979 RWSOLS: https://github.com/sciguy14/Remote-Wake-Sleep-On-LAN-Server