On Thu, 2020-07-16 at 18:09 +0200, Heiner Kallweit wrote: > 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. >
I already suspected this. It's a work in progress. Programming the network nodes from a laptop in Paris will have to wait :) > > > _any_ packet with the "magic" pattern > > > Michal Cheerz, Mischa.
