Bug 826652

Summary: Wake-on-LAN settings are ignored when using NetworkManager
Product: [Fedora] Fedora Reporter: Rui Prior <rprior>
Component: NetworkManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 23CC: bruno, christian, cristian.ciupitu, danw, dcbw, emmanuel.touzery, fschwarz, iarlyy, igeorgex, jklimes, jonathan, jorti, kdudka, lnykryn, mfuruta, momcilo, myroslav, plautrba, rvokal, shawn.starr, thomas, vgulch
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1049868 (view as bug list) Environment:
Last Closed: 2015-08-18 15:12:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1049868    

Description Rui Prior 2012-05-30 17:14:21 UTC
Description of problem:
ETHTOOL_OPTS are ignored for interfaces managed by NetworkManager.


Version-Release number of selected component (if applicable):


How reproducible:
Always
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
  
Actual results:


Expected results:


Additional info:
If you change NM_CONTROLLED to "no", the option works as expected

Comment 1 Lukáš Nykrýn 2012-05-31 09:09:11 UTC
NetworkManager should handle this option so reassigning.

Comment 2 Dan Winship 2012-06-25 17:37:45 UTC
/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...

Comment 3 Jirka Klimes 2012-09-06 14:49:34 UTC
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.

Comment 4 Fedora End Of Life 2013-07-03 22:00:21 UTC
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.

Comment 5 Shawn Starr 2013-11-09 21:10:40 UTC
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

Comment 6 Emmanuel Touzery 2013-11-09 21:31:51 UTC
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.

Comment 7 Shawn Starr 2013-11-10 04:50:33 UTC
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.

Comment 8 Bruno A. Crespo 2013-11-10 18:24:15 UTC
One workarount is to put an script in the path

/etc/NetworkManager/dispatcher.d

my script is:

#!/bin/bash

if [ "$2" = "up" -a "$1" = "eth0" ]; then
        /sbin/ethtool -s eth0 wol g
fi


This script is executed everytime a new ethernet card is initialized....

Comment 9 Jan Kurik 2015-07-15 15:08:03 UTC
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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 10 Fedora Admin XMLRPC Client 2015-08-18 15:00:41 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Dan Winship 2015-08-18 15:12:58 UTC
This is fixed upstream, and will eventually be in NetworkManager 1.2, which will probably be in Fedora 24