wake-on-lan

wake-on-lan

[Joseph Dunn]

I'm trying to get wake-on-lan working for my media box.  However, I'm
running into a problem.  When I halt the machine (shutdown -h) I cannot
wake it.  However, if the machine is unplugged, then plugged back in,
*then* I can wake it.  The lights on the ethernet card will only glow
when the machine is off (i.e. card can wake the machine) when I unplug
the power and plug it back in.  I did find that however software
suspend 2 shuts down the machine does leave it in a wakable state.

So, one option is to hibernate the machine instead of shutting down,
but thats not a great solution.  Also, I have a desktop machine that
has a similar problem.  The wake on alarm in the BIOS cannot wake the
machine if linux performed the last shutdown.  It looks to me like
linux leaves the machine in a deeper sleep state than even plugging it
in for the first time.

I tried to go into the code where the sleep state is hard coded and
mess with it. I edited poweroff.c and changed the two hardcoded lines
referring to S5 to S4.  No affect.  Just to make sure that I was really
calling that code during shutdown I changed it to S0, and the machine
remained on (in S0 state I believe).  By the way, I also tried S3 there
and found that I couldn't wake using the network card in any case.

The machines in question are running Fedora Core 4, but with my own
custom kernels.  The kernels are vanilla for the most part, but are
patched with software suspend and a couple drivers.  I'm sure this is
probably something simple, but it doesnt look like I'm going to trip
over the solution, so does anyone have any suggestions?

-Joe Dunn

RE: wake-on-lan

[Brown, Len]

>When I halt the machine (shutdown -h) I cannot
>wake it.  However, if the machine is unplugged, then plugged back in,
>*then* I can wake it. 

WOL can be done a couple of ways.

If it is implemented using ACPI GPE's, then
you need to find a string (unfortunately, they're arbitrary)
in /proc/acpi/wakeup that looks like your device and echo that
string into the file to toggle between enabled and disabled.

Only Power/Sleep/LID buttons are enabled for wakeup by default.

Note that this I/F is temporary -- the ability of
a device to wake the system should really be a property
of that device in the /sys tree.

cheers,
-Len

Re: wake-on-lan

[Karol Kozimor]

Thus wrote Brown, Len:
> >When I halt the machine (shutdown -h) I cannot
> >wake it.  However, if the machine is unplugged, then plugged back in,
> >*then* I can wake it. 
> 
> WOL can be done a couple of ways.
> 
> If it is implemented using ACPI GPE's, then
> you need to find a string (unfortunately, they're arbitrary)
> in /proc/acpi/wakeup that looks like your device and echo that
> string into the file to toggle between enabled and disabled.
> 
> Only Power/Sleep/LID buttons are enabled for wakeup by default.
> 
> Note that this I/F is temporary -- the ability of
> a device to wake the system should really be a property
> of that device in the /sys tree.

Note also that there are very few explicit calls to pci_enable_wake() in
the whole tree. Linux doesn't set the PME-Enable bit properly, which
apparently results in WOL either working or not working. My understanding
is that the final outcome depends on what BIOS does to the card during
POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird 
example.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: wake-on-lan

[Adam Belay]

On Fri, Jan 20, 2006 at 06:16:35AM +0100, Karol Kozimor wrote:
> Thus wrote Brown, Len:
> > >When I halt the machine (shutdown -h) I cannot
> > >wake it.  However, if the machine is unplugged, then plugged back in,
> > >*then* I can wake it. 
> > 
> > WOL can be done a couple of ways.
> > 
> > If it is implemented using ACPI GPE's, then
> > you need to find a string (unfortunately, they're arbitrary)
> > in /proc/acpi/wakeup that looks like your device and echo that
> > string into the file to toggle between enabled and disabled.
> > 
> > Only Power/Sleep/LID buttons are enabled for wakeup by default.
> > 
> > Note that this I/F is temporary -- the ability of
> > a device to wake the system should really be a property
> > of that device in the /sys tree.
> 
> Note also that there are very few explicit calls to pci_enable_wake() in
> the whole tree. Linux doesn't set the PME-Enable bit properly, which
> apparently results in WOL either working or not working. My understanding
> is that the final outcome depends on what BIOS does to the card during
> POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird 
> example.

I'm in the process of overhauling the PCI layer's power management event
support.  Basically, I'd like to catch ACPI GPE events and then walk the
device tree in thier corresponding location to see if PME is set.  If so
a function like ->wake() will be called for the device driver that owns
the triggered device.  This should allow for even runtime PME usage.  I'm
expecting to have a patch available for the PCI end of these changes soon.

Thanks,
Adam

Re: wake-on-lan

[Karol Kozimor]

Thus wrote Adam Belay:
> > Note also that there are very few explicit calls to pci_enable_wake() in
> > the whole tree. Linux doesn't set the PME-Enable bit properly, which
> > apparently results in WOL either working or not working. My understanding
> > is that the final outcome depends on what BIOS does to the card during
> > POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird 
> > example.
> I'm in the process of overhauling the PCI layer's power management event
> support.  Basically, I'd like to catch ACPI GPE events and then walk the
> device tree in thier corresponding location to see if PME is set.  If so

Ouch. Registering a notify handler against the device's node is not enough?
AFAIR, the spec requires devices that triggered wake-up to be notified and
most DSDTs I've seen do it in one way or another (usually through _WAK).

> a function like ->wake() will be called for the device driver that owns
> the triggered device.  This should allow for even runtime PME usage.  I'm
> expecting to have a patch available for the PCI end of these changes soon.

What point is calling this when we're already up?

Obviously, I haven't seen the whole picture, but from what I know we
already have a .enable_wake callback that is ignored by both the core code
and the drivers. Perhaps extending this callback with platform hooks to
enable the corresponding GPE (die, /proc/acpi/wakeup, die!) and making sure
it actually is called would suffice?

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: wake-on-lan

[Satoru Takeuchi]

Hi, Joseph

At Sun, 8 Jan 2006 10:45:13 -0700,
Joseph Dunn wrote:
> 
> I'm trying to get wake-on-lan working for my media box.  However, I'm
> running into a problem.  When I halt the machine (shutdown -h) I cannot
> wake it.  However, if the machine is unplugged, then plugged back in,
> *then* I can wake it.  The lights on the ethernet card will only glow
> when the machine is off (i.e. card can wake the machine) when I unplug
> the power and plug it back in.  I did find that however software
> suspend 2 shuts down the machine does leave it in a wakable state.

How about this patch?

Thanks,

Satoru Takeuchi

To enable wakeup GPEs, acpi_enable_wakeup_device() has to be called.
But current ACPI subssytem doesn't call this function at the shutdown
time.
This patch fixes it.

Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>

 drivers/acpi/sleep/poweroff.c |    1 +
 drivers/acpi/sleep/wakeup.c   |    2 ++
 2 files changed, 3 insertions(+)

Index: linux-2.6.16-rc1/drivers/acpi/sleep/poweroff.c
===================================================================
--- linux-2.6.16-rc1.orig/drivers/acpi/sleep/poweroff.c	2006-01-03 12:21:10.000000000 +0900
+++ linux-2.6.16-rc1/drivers/acpi/sleep/poweroff.c	2006-01-20 09:47:42.000000000 +0900
@@ -47,6 +47,7 @@
 	/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
 	printk("%s called\n", __FUNCTION__);
 	local_irq_disable();
+	acpi_enable_wakeup_device(ACPI_STATE_S5);
 	/* Some SMP machines only can poweroff in boot CPU */
 	acpi_enter_sleep_state(ACPI_STATE_S5);
 }
Index: linux-2.6.16-rc1/drivers/acpi/sleep/wakeup.c
===================================================================
--- linux-2.6.16-rc1.orig/drivers/acpi/sleep/wakeup.c	2006-01-20 12:04:41.000000000 +0900
+++ linux-2.6.16-rc1/drivers/acpi/sleep/wakeup.c	2006-01-20 12:05:40.000000000 +0900
@@ -48,6 +48,7 @@
 	}
 	spin_unlock(&acpi_device_lock);
 }
+#endif
 
 /**
  * acpi_enable_wakeup_device - enable wakeup devices
@@ -100,6 +101,7 @@
 	spin_unlock(&acpi_device_lock);
 }
 
+#ifdef CONFIG_ACPI_SLEEP
 /**
  * acpi_disable_wakeup_device - disable devices' wakeup capability
  *	@sleep_state:	ACPI state

Re: wake-on-lan

[Adam Belay]

On Fri, Jan 20, 2006 at 07:50:45AM +0100, Karol Kozimor wrote:
> Thus wrote Adam Belay:
> > > Note also that there are very few explicit calls to pci_enable_wake() in
> > > the whole tree. Linux doesn't set the PME-Enable bit properly, which
> > > apparently results in WOL either working or not working. My understanding
> > > is that the final outcome depends on what BIOS does to the card during
> > > POST. Please see http://bugme.osdl.org/show_bug.cgi?id=3801 for a weird 
> > > example.
> > I'm in the process of overhauling the PCI layer's power management event
> > support.  Basically, I'd like to catch ACPI GPE events and then walk the
> > device tree in thier corresponding location to see if PME is set.  If so
> 
> Ouch. Registering a notify handler against the device's node is not enough?
> AFAIR, the spec requires devices that triggered wake-up to be notified and
> most DSDTs I've seen do it in one way or another (usually through _WAK).

Sure, there are a lot of requirements on the ACPI end.  We also need to call
_DSW or _PSW (if it's available) when preparing a PCI device for wakeup.
> 
> > a function like ->wake() will be called for the device driver that owns
> > the triggered device.  This should allow for even runtime PME usage.  I'm
> > expecting to have a patch available for the PCI end of these changes soon.
> 
> What point is calling this when we're already up?

I think you're defining a scope that is too narrow for wake events.
Remember that they can be enabled during S0 (and there are many good
reasons to do so).  In this case, a device is not going to turn on by
itself as ->resume will never be called.  Rather, the driver will need
to evaluate the wake event and determine the proper course of action.  

> 
> Obviously, I haven't seen the whole picture, but from what I know we
> already have a .enable_wake callback that is ignored by both the core code
> and the drivers. Perhaps extending this callback with platform hooks to
> enable the corresponding GPE (die, /proc/acpi/wakeup, die!) and making sure
> it actually is called would suffice?

Yes, I'd like to use platform hooks.  The API on the PCI end might look
like this: (in psuedo-code)

pci_arm_wakeup(struct pci_dev *dev,
	       struct power_state *lowest_state_we_might_enter,
	       struct system_state *target_system_suspend_state)
{
	pci_enable_pme();
	enable_platform_wakeup();
}

pci_disarm_wakeup(struct pci_dev *dev)
{
	disable_platform_wakeup();
	pci_disable_pme();
}

pci_enable_wake() would be deprecated.

Regards,
Adam

wake-on-lan

[Michael J. Baars]

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)?

---

I also tried to set 'Wake-on' to 'b' and 'bg' but then the systems turns back on almost immediately for both settings.

---

Hope you can help getting the remote wake-on-lan to work,

Best regards,
Mischa.

Re: wake-on-lan

[Heiner Kallweit]

On 15.07.2020 11:27, 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)?
> 
> ---
> 
> I also tried to set 'Wake-on' to 'b' and 'bg' but then the systems turns back on almost immediately for both settings.
> 
> ---
> 
> Hope you can help getting the remote wake-on-lan to work,
> 
> Best regards,
> Mischa.
> 
> 
> 
> 
This isn't really a question to Michal. r8169 supports pumbg as mentioned by you.
On DASH-capable systems with Windows more may be supported by the vendor driver.
But Realtek doesn't release any public datasheets, therefore there's no DASH support under Linux.

Re: wake-on-lan

[Michal Kubecek]

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".

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.

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 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.

Michal

Re: wake-on-lan

[Heiner Kallweit]

On 15.07.2020 15:39, 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".
> 
> 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.
> 
> 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.
> 
WoL is MAC-based and works on layer 2 only. WoW (Wake-on-WAN) requires
routing and therefore a running IP stack. In sleep mode the BIOS has
to provide this. One approach was DASH: https://www.dmtf.org/standards/dash

Realtek provides a DASH Windows client, however it's limited to specific
network chip set versions and systems (as it requires BIOS support).

>> 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.
> 
> Michal
> 

Re: wake-on-lan

[Michael J. Baars]

On Wed, 2020-07-15 at 15:17 +0200, Heiner Kallweit wrote:
> On 15.07.2020 11:27, 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)?
> > 
> > ---
> > 
> > I also tried to set 'Wake-on' to 'b' and 'bg' but then the systems
> > turns back on almost immediately for both settings.
> > 
> > ---
> > 
> > Hope you can help getting the remote wake-on-lan to work,
> > 
> > Best regards,
> > Mischa.
> > 
> > 
> > 
> > 
> This isn't really a question to Michal. r8169 supports pumbg as
> mentioned by you.
> On DASH-capable systems with Windows more may be supported by the
> vendor driver.
> But Realtek doesn't release any public datasheets, therefore there's
> no DASH support under Linux.

They do provide open-source drivers :)

Re: wake-on-lan

[Michael J. Baars]

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

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,

> _any_ packet with the "magic" pattern

> Michal



[-- Attachment #2: wake-on-lan.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 8691 bytes --]

Re: wake-on-lan

[Heiner Kallweit]

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
> 
> 

Re: wake-on-lan

[Michael J. Baars]

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.