#4616 NORM Never A: Mesh doesn't resume from suspend on reciept of multicast packets

Zarro Boogs per Child bugtracker at laptop.org
Fri Nov 2 16:28:15 EDT 2007


#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



More information about the Bugs mailing list