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

[Zarro Boogs per Child]

#4616: Mesh doesn't resume from suspend on reciept of multicast packets
----------------------------------+-----------------------------------------
  Reporter:  gnu                  |       Owner:  cjb                              
      Type:  defect               |      Status:  new                              
  Priority:  normal               |   Milestone:  Update.1                         
 Component:  power manager (OHM)  |     Version:  Development build as of this date
Resolution:                       |    Keywords:                                   
  Verified:  0                    |  
----------------------------------+-----------------------------------------

Comment(by gnu):

 This is what I mean about massive confusion about suspends.

 The use scenario is that we've done an automatic suspend to save power,
 and somebody opens a TCP connection to the laptop, using IPv6.  IPv6 does
 its "ARP" equivalent using multicast packets, to avoid waking up every
 node on the network like ARP (broadcasts) do.  Pings will produce the same
 IPv6 neighbor discovery multicast.

 In general, the chip should have three bits that say:

   *  wake us on unicast
   *  wake us on multicast
   *  wake us on broadcast

 and for efficiency in supporting IPv4 ARP, it should have a fourth:

   *  wake us on broadcast, if and only if the bcast packet has byte value
 X in byte position Y.

 Then the host can turn these four bits on and off (and set the two bytes
 used by the arp kludge) as it desires, depending on why it suspended in
 the first place.

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