#4616: Mesh doesn't resume from suspend on reciept of multicast packets
--------------------+-------------------------------------------------------
Reporter: gnu | Owner: dilinger
Type: defect | Status: new
Priority: normal | Milestone: Never Assigned
Component: kernel | Version: Development build as of this date
Keywords: | Verified: 0
--------------------+-------------------------------------------------------
B4, Q2D03, build 616.
Set up two XO's next to each other. On one of them, run:
ping6 -I msh0 ff02::1
This pings the IPv6 link-local "all nodes" multicast address.
This will print two lines (packets) per second, one for its own node, and
one from the other XO. (If there are more XO's nearby, they will also
show up as additional lines.)
Now suspend the target XO with the power button. It stops responding to
the pings. When you resume it by pressing a key on the keyboard, it
shortly starts responding to pings again.
Since ieee802 multicast packets are used for IPv6 neighbor discovery (the
ARP equivalent), this also prevents ordinary unicast pings or unicast TCP
connections from reaching a suspended machine. You can demonstrate this
by reading off the source address of the pings that did come back, and
sending a ping6 directly to that address. It works while not suspended,
but not after suspending.
I believe that this "bug" results from some of the massive confusion about
suspending -- is the power-button suspend a "mac-style" or "pc-style"
suspend that requires manual action to resume from? Or is it an automatic
"olpc-style" suspend that is just a power saving measure and requires no
manual action? As we further debug and evolve the suspend architecture,
we'll resolve this question and can then either fix (or not) this possible
bug.
An automatic suspend should be awakened by these packets.
A manual suspend should not be awakened by these packets.
--
Ticket URL: <http://dev.laptop.org/ticket/4616>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system