11

I am fighting with the WOL settings of my Ubuntu box at the moment. The idea is to have an HTTP/SVN server to sleep while it's unused and wake up when it's accessed. So far, wake-on-LAN works and is activated on startup:

Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: pg
        Wake-on: pg
        Current message level: 0x0000003f (63)
        Link detected: yes

As you can see, I also set the wol p flag ('wake on physical activity'). My assumption was that I could convince the device to wake up not only on magic packets, but on any network access. This, however, seems to be wrong.

What does this flag mean then, and: (How) can I misuse this for my evil plans?

1
  • It could be a pretty thing to be able to wake up just when you receive an order. But the problem is that the request, even if waking up the machine, will not be handled. So you have to make the request again. A normal wol is also equivalent. Feb 25, 2015 at 19:47

2 Answers 2

10
+50

Note: the question is a 4+ year old cross post from here. Not sure why it gets a bounty after more than 4 years, but probably it received a wol package ;-)

The ethtool manual says:

wol p|u|m|b|a|g|s|d...
          Set Wake-on-LAN options.  Not all  devices  support  this.   The
          argument  to  this  option  is a string of characters specifying
          which options to enable.
          p  Wake on phy activity
          u  Wake on unicast messages
          m  Wake on multicast messages
          b  Wake on broadcast messages
          a  Wake on ARP
          g  Wake on MagicPacket(tm)
          s  Enable SecureOn(tm) password for MagicPacket(tm)
          d  Disable (wake on nothing).  This option clears  all  previous
             options.

The PHY activity refers to the PHY chip, that handles communication on the physical layer of the OSI model. In layman's terms: any package directly send to this networking device should wake the machine up.

The following conditions should be met before wake on PHY works:

  • your networking device supports this and your networking driver supports this. I'm not sure if ethtool is checking this extensively before setting the parameter. Check your manual/spec's to see if this specific feature is supported.
  • your ethernet card is still on after shutdown (led lights should be on). If this isn't the case, make sure that your OS isn't shutting down the card (in most Linux distro's put NETDOWN=no in /etc/default/halt).
  • wol settings are preserved after sleep/shutdown.
  • wol is enabled in your BIOS settings.

Also note that the default ARP timeout is 30 seconds (also see this SU post). After that, the IP address of your target machine will be forgotten by the machine from where you are sending any physical package. Make sure you set a static ARP address on the machine from where you are sending the package.

Now any directed request (ping, http, ssh, a wol package, ...) should bring your machine up.

2

I think your assumption is correct. There are many different events you can configure your device to wake up from. The documentation on ethtool isn't very clear on the p flag unfortunately.

A few questions that could help to analyze the problem: When your machine is shutdown, can you confirm that the network card is still running (LEDs blink) ? Are you trying to wake up your machine from within the same subnet or over a router ? How are you trying to wake it up? Can you use a network sniffer (wireshark) on the same network to confirm that data is actually sent on the subnet?

3
  • Thanks for your answer so far! At the moment, I'm trying to wake up the server from the local subnet; the network card is awake in S3 state and WOL by Magic Packet already works. (In fact, due to a bit of packet redirection it also works through the router.) I have not tested what happens to normal packets when the server is asleep though. --- I wonder if what I meant is actually "pattern match", which I would assume is "unicast" in ethtool, and not supported by my network card. Still the question remains what that 'physical activity' is then. It's not plugging the cable in and out.
    – sunside
    Nov 2, 2010 at 1:39
  • I haven't found anything else about the p flag. It's also strange that in your output it says PHYAD:0. In all other examples I saw this was different from 0. I would first really try to constantly ping the server and see if it wakes up. Check the LEDs to see if the server actually receives the packages. If not, you first have to make sure the packages actually reach it.
    – pgruetter
    Nov 2, 2010 at 6:29
  • 1
    I can confirm that the packets reach the server; It's blinking like a christmas tree.
    – sunside
    Nov 2, 2010 at 14:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .