Ticket #4616 (new defect)
Mesh doesn't resume from suspend on reciept of multicast packets
|Reported by:||gnu||Owned by:||cjb|
|Priority:||normal||Milestone:||8.2.0 (was Update.2)|
|Component:||power manager (OHM)||Version:||Development build as of this date|
|Keywords:||Cc:||jg, mbletsas, dwmw2, Collabora|
|Deployments affected:||Blocked By:||#6993|
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.