On 16.07.2020 09:28, Michael J. Baars wrote: > On Wed, 2020-07-15 at 15:39 +0200, Michal Kubecek wrote: >> On Wed, Jul 15, 2020 at 11:27:20AM +0200, Michael J. Baars wrote: >>> Hi Michal, >>> >>> This is my network card: >>> >>> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. >>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) >>> Subsystem: Realtek Semiconductor Co., Ltd. Device 0123 >>> Kernel driver in use: r8169 >>> >>> On the Realtek website >>> ( >>> https://www.realtek.com/en/products/communications-network-ics/item/rtl8168e >>> ) >>> it says that both wake-on-lan and remote wake-on-lan are supported. >>> I >>> got the wake-on-lan from my local network working, but I have >>> problems >>> getting the remote wake-on-lan to work. >>> >>> When I set 'Wake-on' to 'g' and suspend my system, everything works >>> fine (the router does lose the ip address assigned to the mac >>> address >>> of the system). I figured the SecureOn password is meant to forward >>> magic packets to the correct machine when the router does not have >>> an >>> ip address assigned to a mac address, i.e. port-forwarding does not >>> work. >>> >>> Ethtool 'Supports Wake-on' gives 'pumbg', and when I try to set >>> 'Wake-on' to 's' I get: >>> >>> netlink error: cannot enable unsupported WoL mode (offset 36) >>> netlink error: Invalid argument >>> >>> Does this mean that remote wake-on-lan is not supported (according >>> to >>> ethtool)? >> >> "MagicPacket" ('g') means that the NIC would wake on reception of >> packet >> containing specific pattern described e.g. here: >> >> https://en.wikipedia.org/wiki/Wake-on-LAN#Magic_packet >> >> This is the most frequently used wake on LAN mode and, in my >> experience, >> what most people mean when they say "enable wake on LAN". >> > > Yes, about that. I've tried the 'system suspend' with 'ethtool -s > enp1s0' wol g' several times this morning. It isn't working as fine as > I thought it was. The results are in the attachment, five columns for > five reboots, ten rows for ten trials. As you can see, the wake-on-lan > isn't working the first time after reboot. You can try for yourself, I > run kernel 5.7.8. > >> The "SecureOn(tm) mode" ('s') is an extension of this which seems to >> be >> supported only by a handful of drivers; it involves a "password" (48- >> bit >> value set by sopass parameter of ethtool) which is appended to the >> MagicPacket. >> > > Funny, it looks more like a mac address to me than like a password :) > >> I'm not sure how is the remote wake-on-lan supposed to work but >> technically you need to get _any_ packet with the "magic" pattern to >> the >> NIC. > >>> I figured the SecureOn password is meant to forward magic packets >>> to the correct machine when the router does not have an ip address >>> assigned to a mac address, i.e. port-forwarding does not work. > > Like this? We put it on the broadcast address? > >> >>> I also tried to set 'Wake-on' to 'b' and 'bg' but then the systems >>> turns back on almost immediately for both settings. >> >> This is not surprising as enabling "b" should wake the system upon >> reception of any broadcast which means e.g. any ARP request. Enabling >> multiple modes wakes the system on a packet matching any of them. >> > > I think the "bg" was supposed to wake the system on a packet matching > both of them. We want to wake up on a packet with the magic packet > signature on the broadcast address, > This needs to be supported by the hardware. And also r8168 vendor driver doesn't support the signature mode, you can check the r8168 sources.
>> _any_ packet with the "magic" pattern > >> Michal > >
