#10207 NORM 10.1.2: wake-on-WLAN regression on XO-1

[Zarro Boogs per Child]

#10207: wake-on-WLAN regression on XO-1
----------------------------------------------+-----------------------------
           Reporter:  dsd                     |       Owner:  pgf          
               Type:  defect                  |      Status:  new          
           Priority:  normal                  |   Milestone:  10.1.2       
          Component:  power manager (powerd)  |     Version:  not specified
         Resolution:                          |    Keywords:               
        Next_action:  test in build           |    Verified:  0            
Deployment_affected:                          |   Blockedby:               
           Blocking:                          |  
----------------------------------------------+-----------------------------

Comment(by sascha_silbe):

 Replying to [comment:8 pgf]:

 > also like XO-1.5, we don't wake on multicast.  currently we only wake on
 unicast on both laptops.  we can add multicast or broadcast (search for
 "ethtool" in /usr/sbin/powerd for where to do that), but i'm worried it
 will cause too many wakeups, since we can't limit by multicast group.
 perhaps we can do so only if we determine that certain protocols are
 active?  certain activities active?  maybe we can set up an iptables
 filter to see if we've recently sent certain kinds of multicast, so we
 know whether to wake-on-multicast?  (i'm just brainstorming.  none of this
 might work.)

 Waking on multicast is required for IPv6 to work transparently (the IPv6
 equivalent of ARP, called neighbour discovery, uses multicast instead of
 broadcast). I have enabled it on all my XOs.

 I found two major sources of (too) frequent wake-ups: CUPS and a multicast
 router. avahi-daemon might be troublesome as well; I had all instances of
 it shut down while testing automatic suspend.

 With an AP that has multicast routing support it will wake up the XO about
 every 1-2 minutes. This particular model doesn't have any way to
 deactivate multicast routing or tweak the timers which makes it
 particularly troublesome. Being consumer hardware, the chance that many
 APs behave the same and are unfixable is rather high unfortunately.

 In general my reading of [http://tools.ietf.org/html/rfc3376 RFC 3376]
 (IGMP v3) suggests that it's sufficiently tweakable to allow both long
 periods of sleep and acceptable traffic overhead. Of particular interest
 is the Query Interval (the major source of wake-ups in the absence of
 traffic) and the Last Member Query Interval resp. Last Member Query Count
 (the product is called Last Member Query Time and should be high enough
 for an XO to wake up and respond). IGMP v2 added explicit leaving of
 groups ("low leave latency") so a high Query Interval shouldn't increase
 overhead (unless IGMP v1 hosts are subscribed to the same group).
 AFAICT multicast routing is done in user space, so how to set these
 variables is software specific.

-- 
Ticket URL: <http://dev.laptop.org/ticket/10207#comment:9>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system