Impacts of disabling Automatic Power Management

[John Gilmore]

> waking up on all multicast frames, apparently even ones that wouldn't
> normally be sent from the hardware to the driver

There's a flag for that, "ifconfig wlan0 allmulti", which should NOT
be set.  That configuration tells the hardware that we want to receive
all multicasts, not just the ones we have software listening for.  (It
shows up in capital letters, in the flags line of "ifconfig wlan0" if
set.)

If that's off, waking on all multicasts is pretty unlikely.  Multicast
reception hardware (for every Ethernet as well as every WiFi) is
designed so that it doesn't see packets unless they match the address
filter, which the Linux drivers already know how to set.  This is easy
to test.  Run "ip maddr", it will tell you all the addresses that the
driver is listening for, on each interface.  It lists link-level (MAC)
address, IPv4 addresses, and IPv6 addresses.

To test it, let the laptop auto-suspend.  Then from another node on
the same network (AP or adhoc or ethernet), ping a multicast address
that the node should NOT wake up for, e.g. the "all routers on this
link" address in IPv6 (ff02::2):

  ping6 -I wlan0 ff02::2

This should NOT wake up the autosuspended laptop.  You can try pinging
various other multicast addresses, e.g. ff02::f, or ipv4's 224.1.2.3.

After confirming that, try sending a multicast that SHOULD wake up the
laptop.  You have a list of them from the "ip maddr" output.  An easy
one that's always there is the "all nodes on this link" multicast
address in IPv6 (ff02::1):

  ping6 -I wlan0 ff02::1

This should wake up the laptop (and get you a ping response sent back
to the second node).  However, old bugs like
http://dev.laptop.org/ticket/6528 may prevent the ping response
(packets that wake the laptop from suspend are often lost).

If we're still dropping some packets that wake the laptop from suspend,
then that could be one of the problems with collaboration.  Four years
ago, I commented:

  http://dev.laptop.org/ticket/6818#comment:18

  Yes, the real test will be how it integrates in the whole system:
  With the presence service running, with "ethtool -s msh0 wol uma",
  and with auto-suspend: Will we drop the unicast or multicast packet
  that wakes us up (#6528), or will it actually reach the application
  that's awaiting it?

  And, secondarily, can we stay suspended long enough to save power?
  Or will the application level multicast traffic be so constant that
  we always wake a few seconds after we suspend (in which case we need
  to fix the applications so they aren't so chatty)?

	John