Ubuntu
powernap package

powerwake enhancement, monitor ARP requests for sleeping machines and send magic packets

Bug #737479 reported by heckheck
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
powernap
Fix Released
Undecided
Andres Rodriguez
powernap (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: powernap

Here is a suggestion for an enhancement that could be made to the powerwake utility. I am posting this suggestion as an enhancement bug here since it seems very in line with the functionality of powernap/powerwake, and I thought you might find the approach interesting. Feel free to use this idea (and code) or not as you see fit.

I have written a short Python script that can be run as a daemon that leverages the scapy package to monitor ARP traffic for a list of targeted IP addresses on the local network. When an ARP is sent for one of the monitored addresses, the script will compose a magic packet for that IP and send it out on the local network.

The scapy association is not strictly needed, but it made implementation very simple. The reason I wrote this tool is that the Intel E1000 nic driver in Linux does not support wake on ARP (even though the card supports filters and the kernel driver could be extended to cover that feature as the related Windows driver for the same card does). In fact few cards in Linux seem to support wake on ARP.

This is very annoying, since there is no easy way to wake a sleeping computer by simply attempting to access it over the network, since ARP entries age out throughout the network and you end up with no way to recover the MAC address via ARP (the computer continues to sleep). The drivers almost universally support wake on magic packet, so the natural solution seemed to be to have a computer that is awake on the network sniff for ARP requests to the sleeping computer and emit the Magic Packet on behalf of that request.

On to the code. The Python script sets up a scapy filtered sniff for ARP traffic that uses very little system resources. On receiving an ARP it checks to see if it matches the list of IPs being monitored and if so, constructs the appropriate Magic Packet and sends it.

Best Regards,

-Jim Heck

Revision history for this message
heckheck (jinfo) wrote :

Could I please bother you to block out the MAC addresses in the script I just posted, or to delete the attachment and let me upload it again.

Best Regards,

-Jim Heck

Revision history for this message
heckheck (jinfo) wrote :

I am uploading a version of the script with MACs removed.

Best Regards,

-Jim Heck

Revision history for this message
Andres Rodriguez (andreserl) wrote :

Hi Jim,

Thank your for taking the time to file this bug and sending this script. It is indeed very very interesting and I definitely gonna consider it for the next release of PowerNap (3.x).

Now, I just want to get something straight:

When target/monitored machines are sleeping (suspended, hibernated, etc), and an ARP packet for any of those machines is heard over the network, then your script sends a WoL packet to the machine from which an ARP was sent to?

So for example, if I have ServerA (192.168.1.100) suspended, and some router/switch tries to discover if ServerA is in the local network, by sending broadcasting ARP messages for 192.168.1.100 to discover its MAC address, then your script will sniff that ARP packet and send a WoL to 192.168.1.100?

Now, the way I think I can integrate your script with powerwake, is that for the next Ubuntu release, I'd like to have a powerwaked daemon that keeps track of all the machine on the local network that are using PowerNap. This way we have some kind of client/'server approach to administer PowerNap clients from the server (such as schedule wakeups, poweroffs, and things like that), and I believe your script fits here perfectly.

Finally, I'm marking this bug as invalid for Ubuntu, but open it in the project's bug tracking system as this is a feature request and should be handled there.

Thanks a lot!! This is indeed awesome!

Changed in powernap (Ubuntu):
status: New → Invalid
Changed in powernap:
status: New → Confirmed
Revision history for this message
heckheck (jinfo) wrote :

Andres,

Yes your understanding of my script is correct and your example is spot on.

Explained another way, there are three computers involved in the process. There is the requester who is ARPing for the sleeping machine, there is the sleeping machine, which will not wake to ARP requests, and there is the sniffer, which is a third machine on the network that is awake and listening for ARP traffic on behalf sleeper and will send the magic packet (which will wake the sleeper) when it promiscuously hears the ARP request go out from the requester.

-Jim

Revision history for this message
Andres Rodriguez (andreserl) wrote :

Awesome.

Will definitely like to include it into powerwaked once I start working on it, to be a feature of "Automatic Wake up on Network traffic" or something like that!

Thanks again!

Andres Rodriguez (andreserl)
Changed in powernap:
status: Confirmed → In Progress
assignee: nobody → Andres Rodriguez (andreserl)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package powernap - 2.12-0ubuntu1

---------------
powernap (2.12-0ubuntu1) oneiric; urgency=low

  [ Andres Rodriguez ]
  * Add Initial PowerNap (powerwaked) Server Capabilities:
    - powerwake/*: Add module and Initial ARPMonitor (LP: #737479).
    - powerwaked.conf: Add config file.
    - powerwaked: Add daemon.
    - powerwake-monitor: Add tool to add, delete, list, etc.
  * Package powernap-server:
    - debian/control: Add powerwaked, powerwake-common, powernap-server
    - debian/{powerwaked,powerwake-common}.install: Add
    - debian/powerwaked.upstart: Add upstart job.

  [ Dustin Kirkland ]
  * bin/powerwake:
    - only seed the arp cache if the argument is not already a mac address
 -- Andres Rodriguez <email address hidden> Fri, 01 Jul 2011 16:06:51 -0400

Changed in powernap (Ubuntu):
status: Invalid → Fix Released
Dustin Kirkland  (kirkland)
Changed in powernap:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.