Salix Forums

Linux for the Lazy Slacker
https://forum.salixos.org/

ethtool and rc.d scripts

https://forum.salixos.org/viewtopic.php?t=7672

Page 1 of 1

ethtool and rc.d scripts

Posted: 26. Jul 2018, 21:53
by mobius
Hello world, this is basically a question about startup/shutdown scripts, couched in wake on lan question ;) .

WOL works once, but after startup ethtool eth0 shows Wake-on: d (disabled.) If I use sudo ethtool -s eth0 wol g, it will again work once, but is then disabled. From my searching, the answer appears to be to place the above enabling command in a startup or shutdown script, so that it will be enabled each time, and ready for the next wakeup.

So, I tried putting ethtool -s eth0 wol g in rc.local_shutdown, thinking it better to have it run at shutdown rather than startup, so that even if it became disabled during a session, it would be re-enabled at shutdown. That didn't work, and I'm not sure why not.

Do I need to use sudo in the script? (I thought perhaps the startup/shutdown scripts would run with system privileges.)

Or, does it need to go in some other script (rc.local?) With or without sudo?

Thanks for any help.

Re: ethtool and rc.d scripts

Posted: 28. Jul 2018, 07:24
by galmei
Hello,

did you allow wake-on in the BIOS setup? Do you use a network manager and if so, is the correct WOL source selected in the configuration settings?

mobius wrote: ↑26. Jul 2018, 21:53So, I tried putting ethtool -s eth0 wol g in rc.local_shutdown, thinking it better to have it run at shutdown rather than startup, so that even if it became disabled during a session, it would be re-enabled at shutdown. That didn't work, and I'm not sure why not.
If the interface is shut down in the shutdown process, then the WOL request can not be stored anywhere. So rc.local_shutdown is the wrong place. If you have no network manager in use and if the desired WOL mode is not already activated by default, this can be activated via rc.local.

In the mentioned scripts in rc.d the called programs run with root rights.

If a network manager is used, such as NetworkManager or Wicd, then it is their task to consider the WOL behavior. Automatically handled by NetworkManager and Wicd.

But if you really need to enforce wake-on behavior in an unconventional way and you want to do it better than with rc.local, then for NetworkManager, use a dispatcher script in directory /etc/NetworkManager/dispatcher.d to launch the ethtool program. For Wicd, the script belongs in the directory /etc/wicd/up.

The scripts are executed when the Ethernet interface is up. This guarantees that the parameters from the ethtool call will not be overwritten by NetworkManager or Wicd. As already written, NetworkManager and Wicd can run the WOL parameterization on their own.

Finally, you should have given the full output to the manual calls to ethtool:

Code: Select all

sudo ethtool eth0
and

Code: Select all

sudo ethtool -s eth0 wol g
It may then be possible to deduce more from the program outputs. For these calls you have to use sudo, if you do not want to have a real superuser.

Re: ethtool and rc.d scripts

Posted: 28. Jul 2018, 19:04
by mobius
galmei, thank you for a very complete answer.
galmei wrote: ↑28. Jul 2018, 07:24 Hello,

did you allow wake-on in the BIOS setup?
WOL is enabled in the BIOS. (Actually, I couldn't find any setting specifically targeting WOL or the network interface, but do have enabled Wake-on-PCI and Wake-on-PCIE, the only settings that seem remotely related.) However, the BIOS is obviously correctly configured, since WOL does work, but then seems to become disabled under Linux. Before installing Salix, this computer had Windows installed, and WOL always worked without issue.
Do you use a network manager and if so, is the correct WOL source selected in the configuration settings?
No network manager in use, as far as I know (see more below.)
If the interface is shut down in the shutdown process, then the WOL request can not be stored anywhere. So rc.local_shutdown is the wrong place. If you have no network manager in use and if the desired WOL mode is not already activated by default, this can be activated via rc.local.
I have no idea where WOL is becoming disabled. But, I have already moved the enabling command to rc.local. So far, this seems to be working. :D
In the mentioned scripts in rc.d the called programs run with root rights.
Thank you. That's what I expected, but it's good to have it confirmed.
Finally, you should have given the full output to the manual calls to ethtool:

Code: Select all

sudo ethtool eth0
and

Code: Select all

sudo ethtool -s eth0 wol g
It may then be possible to deduce more from the program outputs. For these calls you have to use sudo, if you do not want to have a real superuser.
Sorry for the lack of information.

It does appear to be working now, so if it continues, I will leave the command in rc.local.

A bit of background: I began with my own home-built microcomputer using just a 2kB ROM monitor program, and graduated to all kinds of OS's, including FLEX and OS-9 (both 6800/68000 based), CP/M (8080/Z80), and MS-DOS among others, so I am no stranger to the command-line. However, I have been using Windows for more years than I care to think about.

During those years, I have from time to time made an attempt become familiar with (or even convert to :o ) Linux, but without success. I believe that is because I always concentrated too much on the GUI/Window-manager. This time, I am attempting to learn Linux from the ground up, using only the command-line (no GUI.)

With that in mind, and since this topic is about startup/shutdown scripts, how would I configure Salix to boot into multiuser command-line mode (run level 3,) rather than the current windowed default of run level 4?

In /etc/inittab, I see the lines:

Code: Select all

# Default runlevel.  (Do not set to 0 or 6)
id:4:initdefault:
which I presume I would change to:

Code: Select all

# Default runlevel.  (Do not set to 0 or 6)
id:3:initdefault:
But are there any other changes required?

Re: ethtool and rc.d scripts

Posted: 29. Jul 2018, 09:01
by gapan
mobius wrote: ↑28. Jul 2018, 19:04 In /etc/inittab, I see the lines:

Code: Select all

# Default runlevel.  (Do not set to 0 or 6)
id:4:initdefault:
which I presume I would change to:

Code: Select all

# Default runlevel.  (Do not set to 0 or 6)
id:3:initdefault:
But are there any other changes required?
No, that's all it takes.

Re: ethtool and rc.d scripts

Posted: 29. Jul 2018, 19:25
by mobius
gapan wrote: ↑29. Jul 2018, 09:01No, that's all it takes.
Thank you!

Re: ethtool and rc.d scripts

Posted: 30. Jul 2018, 01:34
by galmei
[...] but do have enabled Wake-on-PCI and Wake-on-PCIE, the only settings that seem remotely related.
These are the right settings. The terms for this are very different on the various computers. On the machine I'm using right now, the property is called Power-on Source and can be set to BIOS Controlled or ACPI Controlled. It's not possible to switch off. In some other BIOS, you can only choose between On and Off.
Before installing Salix, this computer had Windows installed, and WOL always worked without issue.
On the topic Wake on LAN you will find in Wikipedia, among others, the following text:
(Quote)

Respond to the Magic Packet and restore full power
Most WoL hardware functionally is typically blocked by default and needs to be enabled in using the system BIOS. Further configuration from the OS is required in some cases, for example, via Device Manager network card properties on Windows Operating systems. More below.

(Omission)

Linux
Wake-on-LAN support may be changed using a subfunction of the ethtool command.

(Quote end) Source https://en.wikipedia.org/wiki/Wake_on_LAN

From the omission can also be seen why it works with Windows automatically.
No network manager in use, as far as I know (see more below.)
Well that can be checked. If

Code: Select all

ps ax | grep -i networkmanager | grep -v grep
ps ax | grep -i nm | grep -v grep
ps ax | grep -i wicd | grep -v grep
shows no output, then none of the named network managers will run either.
id:3:initdefault:
That's okay.
But are there any other changes required?
Everything is done.

Runlevel 3 can also be approached differently. Runlevel 4 in inittab is left.
For permanent use, a three is written to the append line in lilo.conf.
e.g.

Code: Select all

append="3 quiet vt.default_utf8=1 ..."
For other bootloaders or bootmanagers, this is done in an equivalent way but with the associated notation method.
For temporary use, "Salix 3" is written to the kernel command line and also reaches runlevel 3.
In SalixLive, the kernel label might be different than Salix - I do not know.

Change: The shown usage of "sudo /usr/bin/echo -n LAN > /proc/acpi/wakeup" does not work with sudo. Rather, the user must be really supersuer. Because this example is not suitable for anyone interested, it has been removed.

Re: ethtool and rc.d scripts

Posted: 30. Jul 2018, 21:17
by mobius
galmei wrote: ↑30. Jul 2018, 01:34(Quote end) Source https://en.wikipedia.org/wiki/Wake_on_LAN

From the omission can also be seen why it works with Windows automatically.
What seems puzzling, is that with Linux (some/all distributions?,) one can turn on WoL, but it will once again become disabled after reboot. After much googling, it seems that the solution is simply to re-enable in a startup/shutdown script after each boot. This now appears to be working fine for me, so as to why it happens, I leave it to those far more knowledgeable than myself. ;)
No network manager in use, as far as I know (see more below.)
Well that can be checked. If

Code: Select all

ps ax | grep -i networkmanager | grep -v grep
ps ax | grep -i nm | grep -v grep
ps ax | grep -i wicd | grep -v grep
shows no output, then none of the named network managers will run either.
There is a process running: /usr/sbin/NetworkManager, but neither of the other two.
Runlevel 3 can also be approached differently. Runlevel 4 in inittab is left.
For permanent use, a three is written to the append line in lilo.conf.
To this point, I haven't yet looked at lilo at all, though I have tinkered a bit with grub.
Here's something to play or tinker:
The wake-on functionality can be switched on and off in /proc instead of using ethtool. For this one must apply for the preparation once:

Code: Select all

lspci
The relevant excerpt from the output on my computer looks like this:

Code: Select all

00:14.0 Bridge: NVIDIA Corporation MCP51 Ethernet Controller (rev a3)
On the far left is the mandatory part of the slot specification. This consists of bus:device.function. Before that, there may be an optional 'domain:' term. Then one uses also once for preparation:
That's an interesting command. In my case, the relevant line is:

Code: Select all

02:00.0 Ethernet controller: Qualcomm Atheros AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)

Code: Select all

cat /proc/acpi/wakeup
In the output, look for the line in which the slot information can be found. On my computer the relevant excerpt is, shown along with the column headings:

Code: Select all

Device	S-state	  Status   Sysfs node
LAN       S4    *disabled  pci:0000:00:14.0
The Device column contains the device name. This name will be used later. The device names come from the BIOS's Differentiated System Description Table (DSDT) and can be arbitrarily assigned by the manufacturers. They therefore often differ completely from manufacturer to manufacturer. The next column shows from which S-state the LAN adapter can revive the computer. Here it is S4. The status is displayed as disabled.
Here, my list shows 22 entries, but none have "02:00.0" (none have "02:" at all.) They all have S-state S4. The only ones (several of them) which show "enabled," all have names containing "USB," with the exception of this line:

Code: Select all

PS2K      S4    *enabled   pnp:00:07
This is strange, since 'sudo ethtool eth0' shows "Wake-on: g."
All times are UTC
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited