Ticket #10207 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

wake-on-WLAN regression on XO-1

Reported by: dsd Owned by: pgf
Priority: normal Milestone: 10.1.2
Component: power manager (powerd) Version: not specified
Keywords: Cc: sascha_silbe
Action Needed: diagnose Verified: no
Deployments affected: Blocked By:
Blocking:

Description

According to Hal Murray, on 10.1.2 build 300 for XO-1, wake on WLAN has stopped working.

Change History

  Changed 4 years ago by pgf

  • owner changed from dsaxena to pgf
  • next_action changed from never set to code
  • component changed from kernel to power manager (powerd)

i tested this last week, so i knew it used to work. turns out that when i did the powerd mods for XO-1, i remembered that XO-1 can wake on arp, and added 'a' to its ethtool wol command:

ethtool -s eth0 wol ua

but i was forgetting that the ethtool support code in the current driver doesn't support that. so powerd's ethtool command is failing, and no wakeup options are being set. changing the command to:

ethtool -s eth0 wol u

(which matches XO-1.5 command) fixes this.

i'll change it in powerd for the next release, but only after investigating why we can't do wake-on-arp.

  Changed 4 years ago by pgf

sanity check: am i right that XO-1 can wake on ARP in the 802 builds? i thought i'd seen that in the older driver, but i'm not finding it right now.

  Changed 4 years ago by pgf

  • cc sascha_silbe added

well, i still haven't actually tested wake-on-arp on XO-1 build 802, but http://lists.laptop.org/pipermail/devel/2010-March/027775.html strongly suggests it doesn't work.

the mechanisms to make it work are described in #6993, and reasons why those mechanisms might be broken are described in #3732. i can't actually tell from the last several comments in #3732 whether the logical filters are expected to work or not. in any case, i don't believe we've ever implemented the code necessary to use the filters to cause wake-on-arp to work.

i'm also sure that the code that manages those filters, from the old wext.c and ioctl.c of the libertas driver on the olpc-2.6 "testing" branch, is not present at all in the 2.6.31 branch. whether because it wasn't upstreamed, or simply not ported forward, or maybe was deprecated, i'm not sure.

nutshell: no wake-on-arp on 2.6.31.

  Changed 4 years ago by dsd

I agree, doesn't look like this ever worked. Let's get a new powerd release to fix the regression and leave wake-on-ARP for another day...

  Changed 4 years ago by dsd

  • next_action changed from code to test in build

fixed in powerd-25, scheduled for next build

  Changed 4 years ago by Quozl

  • milestone changed from 1.0-software-update to 10.1.2

  Changed 4 years ago by Quozl

Need a clearer test case. I gather from comments that wake-on-WLAN isn't going to work until wake-on-ARP works. I tested os301 and verified that a shared Chat via mesh does not wake the idle suspended participant. However, a ping with ARP cached does wake the target laptop.

follow-up: ↓ 9   Changed 4 years ago by pgf

like XO-1.5, wake-on-arp isn't implemented, so the arp cache on the pinging host needs to be valid.

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.)

in reply to: ↑ 8   Changed 4 years ago by sascha_silbe

Replying to 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 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.

  Changed 4 years ago by pgf

while all this may be true, IPv6 is not a targetted application of the XO, currently. multicast is important for our collaboration protocols, however, and that's where i found the wakeups to be excessive.

  Changed 4 years ago by dsd

what happened on 8.2? multicast wakeups or no multicast wakeups?

  Changed 4 years ago by Quozl

  • next_action changed from test in build to diagnose

No multicast wakeups, apparently.

Test: XO-1 8.2.1 os802 with Chat-48. Two laptops associated with an access point. Shared chat established. One laptop configured to idle suspend. Other laptop configured to tcpdump transmitted traffic. Waiting for idle suspend. Attempted chat transmission.

Result: tcpdump showed Chat used a multicast UDP packet, to 239.255.71.211:27560. Laptop that had suspended did not resume as a result of the packet. Upon resuming the laptop with touchpad, the missing chat traffic was displayed. tcpdump showed other laptop retransmitted upon request.

  Changed 4 years ago by dsd

OK. I think we can close this ticket then- we now match behaviour of 8.2.1.

  Changed 4 years ago by cjb

  • status changed from new to closed
  • resolution set to fixed

Okay, closing.

Note: See TracTickets for help on using tickets.