Wölfisch

Wake on LAN doesn't

woelfisch

4/8/09 02:39 pm

One difference between openSUSE 11.0 and 11.1 really bugged me: even though I enabled Wake on LAN (WOL) on eth0, the driver would switch off the transceiver on suspend to RAM. After some investigation I found that the atl1e driver has the "wakeup" flag for power management set to "disabled", regardless what I set with ethtool. After enabling it with "echo enabled >/sys/class/net/eth0/device/power/wakeup", WOL works again. As a quick workaround I created a file /etc/udev/rules.d/78-enablewol.rules with the following udev rules:

SUBSYSTEM=="net", ENV{INTERFACE}!="eth*", GOTO="skip_wol"
SUBSYSTEM=="net", ACTION=="add", RUN+="/bin/sh -c 'echo enabled >/sys/class/net/$env{INTERFACE}/device/power/wakeup' "
LABEL="skip_wol"

Edit: Forgot that redirections aren't implemented in udev. Sigh.

NB: Of course you also need to actually turn on WOL. Either by setting "ETHTOOL_OPTIONS='wol g' " in /etc/sysconfig/network/ifcfg-eth0.cfg if you are using "traditional" network setup with ifup/ifdown, or by adding

SUBSYSTEM=="net", ACTION=="add", RUN+="/sbin/ethtool -s $env{INTERFACE} wol g"

to above udev rules.

Tags: bnc#493214, opensuse, planetsuse, udev

• Current Location: Nürnberg, Germany
• Current Mood: busy

• 2 comments
• Leave a comment

• tchk

  4/8/09 08:06 pm (UTC)

  

  Aww, what happened to linux being simple where I could just edit the startup shell scripts to execute commands?
  
  I'm sorry to say, but I miss my old slackware. I knew how everything worked on that system, ten years ago. Everything was commands in bash scripts and simple config files with man pages.
  
  Now you have to know a million special subsystems, and very soon, like under solaris, all configuration is going to be moved into one big in-memory database with an ebXML rules engine that only uses up 7.4 GB RAM and 3 processor cores all the time. And runs in tomcat.
  
  *sigh*
  
  This is no better than the §$(/& registry.
  

  • Reply
  • Thread

  • woelfisch

    4/8/09 08:54 pm (UTC)

    

    I also miss the old simple solutions, but those only worked for static setups. The udev / dbus / hal approach, as confusing as the sparse documentation may be, is currently the best general approach for hotplugging scenarios. Especially when desktop support gets into the picture. The problem is that a newcomer to a modern Linux system will need many weeks to understand how it all works. And everyone else at least a couple of days.
    
    Even worse when Network Manager is involved, which is a black box which IMHO interacts poorly with the rest of the system, violates the Unix philosophy, isn't documented very well and gives only sparse debug information. Oh, and it keeps its own cryptic gconf-style registry. Granted, all text files, but as many undocumented incomprehensible XML files scattered over a weird directory structure.

    • Reply
    • Parent
    • Thread