I want wake over lan (WOL)for my Dietpi PC. in past that pc windows was installed & i was able to wake up that computer from android APP while it was sleeping. last week i have format that pc & install dietpi. my android phone app now not able to wake that pc. In mother board/Bios side i have not change anything so that pc is wol compatible as it was working in past. please guide me what change i have to made in pc so that it can wake up via WOL through android mobile app. what packages are missing which not allow dietpi X86 pc not to wake up from sleep mode.
maybe you can have a look into this article WakeOnLan - Debian Wiki
I guess you need to add
ethernet-wol g into
/etc/network/interfaces as we use
Thanks, my system start using WOL, the command i gave as
sudo nano /etc/network/interfaces.d/eth0
save these words in eth0 file
iface eth0 inet dhcp
& reboot system & system boot with WOL commands, thanks @Joulinar
Awesome, I didn’t know that one, and so easy. I’ll put it on the list for
dietpi-network to be available as GUI option when I find time to finish it.
Docs: WakeOnLan - Debian Wiki
ethtool package, but it’s pre-installed on DietPi for link speed and debugging already.
@MichaIng but there would need to be a check, to verify if the feature is supported by the system.
ethtool output contains this info.
Is any thing change with this configuration. my working WOL system stop since last week. i have not changed anything. in past WOL working fine. i just gave “apt-get update” “apt-get upgrade” commands also installed & uninstall docker cli & docker-compose via dietpi-software. this setup working fine before but now with this computer is not wakeup via WOL. my system is working headless so no change in BIOS etc.
I guess the updated packages broke something. What did you update?
only update system via standard commands “apt-get update” “apt-get upgrade” & i have install docker & docker compose & then uninstall it. is any linux command verify the WOL system or needed packages working /available or not?
these commands gives following results
root@DietPi:/etc/network# networkctl list
WARNING: systemd-networkd is not running, output will be incomplete.
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback n/a unmanaged
2 eth0 ether n/a unmanaged
3 wlan0 wlan n/a unmanaged
root@DietPi:/etc/network# ifquery eth0
ethtool: bad command line argument(s)
For more information run ethtool -h
You could have a look to official docs WakeOnLan - Debian Wiki
Dietpi is using
root@DietPi:~# sudo ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
master-slave cfg: preferred slave
master-slave status: slave
Port: Twisted Pair
Supports Wake-on: pumbg
Link detected: yes
Did you tried and ran
ethtool -h to see more info?
yes it is giving hundreds line
root@DietPi:~# ethtool -h
ethtool version 5.9
ethtool [ --debug MASK ][ --json ] DEVNAME Display standard information about device
ethtool [ --debug MASK ][ --json ] -s|--change DEVNAME Change generic options
[ speed %d ]
[ duplex half|full ]
[ port tp|aui|bnc|mii|fibre|da ]
[ mdix auto|on|off ]
[ autoneg on|off ]
[ advertise %x[/%x] | mode on|off ... [--] ]
[ phyad %d ]
Can you provide:
ethtool -i eth0 ?
And what happens when you do:
sudo ethtool -s eth0 wol g
root@DietPi:~# ethtool -i eth0
firmware-version: rtl8411-1_0.0.3 06/18/12
root@DietPi:~# sudo ethtool -s eth0 wol g
Ok no output at all, I would take this as “it worked”?!
This command basically activated WOL mode g on eth0, like it was already before. I just wanted to get sure…
You can reboot the machine and try if it works no, but I think not since we didn’t change anything.
Hm this looks all fine, my only idea left is to check the LAN cable / physical connections.