Red Hat Bugzilla – Bug 826652
Wake-on-LAN settings are ignored when using NetworkManager
Last modified: 2015-12-19 10:16:42 EST
Description of problem:
ETHTOOL_OPTS are ignored for interfaces managed by NetworkManager.
Version-Release number of selected component (if applicable):
Add «ETHTOOL_OPTS="wol g"» to the configuration of an interface that also has «NM_CONTROLLED="yes"». Use ifdown then ifup on that interface, then use ethtool and see "Wake-on: d" on the output, indicating it has
Steps to Reproduce:
1. Add «ETHTOOL_OPTS="wol g"» to the configuration of an interface that also has «NM_CONTROLLED="yes"»
2. Use ifdown then ifup on that interface
3. Use ethtool on that interface and see "Wake-on: d" on the output, indicating wake-on-lan is disabled
If you change NM_CONTROLLED to "no", the option works as expected
NetworkManager should handle this option so reassigning.
/usr/share/doc/initscripts-*/sysconfig.txt lists ETHTOOL_OPTS as "deprecated, but supported", and notes that "Long term, this should be done by sysadmin-written udev rules."
Having NM run ethtool on an interface with random admin-provided options seems a little dubious (since it could modify the device in arbitrarily-confusing ways). Supporting just the "ethtool -s $DEVNAME ..." form is maybe a little bit more plausible.
Probably NM should just grow explicit support for configuring WoL...
Yeah, NM's ifcfg-rh plugin doesn't parse ETHTOOL_OPTS, so neither wake-on-lan nor any other Layer2 parameters are set up.
We should probably introduce a new means of configuring this, because passing options of others tools is not nice/easily-parsable/secure.
And, we should introduce some "Layer 2" configuration inside NM, the same way we have "Layer 3" org.freedesktop.NetworkManager.IP[4/6]Config.
Say org.freedesktop.NetworkManager.Layer2Config, that would contain parameters like wake-on-lan, speed, duplex, etc.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
I confirm this an issue in Fedora 19/20+
Please look into this or I have to use an rc.local systemd method for now
Shawn Starr: If there is a workaround could please explain it because I don't know how to achieve the goal at all with recent Fedora versions personally? I would really appreciate it.
I'm just using /etc/rc.d/rc.local workaround create it and make executable then add the ethtool command to set the WOL flag on network interface.
One workarount is to put an script in the path
my script is:
if [ "$2" = "up" -a "$1" = "eth0" ]; then
/sbin/ethtool -s eth0 wol g
This script is executed everytime a new ethernet card is initialized....
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.
(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)
More information and reason for this action is here:
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is fixed upstream, and will eventually be in NetworkManager 1.2, which will probably be in Fedora 24