#3732 HIGH First D: arp and NDP timeouts on Linux are bizzarely short.

[Zarro Boogs per Child]

#3732: arp and NDP timeouts on Linux are bizzarely short.
---------------------+------------------------------------------------------
  Reporter:  wad     |       Owner:  cjb                   
      Type:  defect  |      Status:  new                   
  Priority:  high    |   Milestone:  First Deployment, V1.0
 Component:  distro  |     Version:                        
Resolution:          |    Keywords:                        
  Verified:  0       |  
---------------------+------------------------------------------------------

Comment(by gnu):

 Jim, your assertion is incorrect that ipv6 Neighbor Discovery Protocol
 (NDP) is like ARP.  NDP and router advertisements use *multicast* packets,
 not broadcasts.  They are carefully tuned so that they should only wake up
 the nodes which they are addressed to.  (The IPv6 designers learned from
 the mistakes of IPv4.)

 See [http://www.ietf.org/rfc/rfc4861.txt NDP RFC 4861]'s use of the
 "solicited-node multicast address", section 7.2.2 (page 60).  This address
 is computed from the target IPv6 address via the algorithm in
 [http://www.ietf.org/rfc/rfc4291.txt IPv6 Address Architecture RFC 4291],
 page 15-16.  It uses a link-local multicast IPv6 address whose low 24 bits
 match the destination IPv6 address.  This is translated to a multicast
 Ethernet MAC address 0x3333nnnnnnnn whose low 32 bits match the multicast
 IPv6 address (see [http://www.ietf.org/rfc/rfc2464.txt IPv6-on-Ethernet
 RFC 2464], page 4.  As long as the chip implements any kind of half-assed
 or better multicast address matching, the only node that will see this
 multicast is the node the NDP packet is looking for.

 Therefore, the wireless chip *should* be set up to wake-on-multicast.  It
 should have its multicast address table or hashtable preloaded with the
 subset of multicasts of interest to this node.  All existing Ethernet
 drivers already preload these addresses, on every Ethernet chip that
 supports multicast.

 This would allow IPv6 Neighbor Discovery to wake the laptop when
 suspended, fixing this bug for IPv6.

 [As for IPv4:  I think that, though it's a layer violation, OLPC/Cozybit
 should implement a wake-on-wlan hack that passes the node's IPv4 address
 to the chip, and asks it to wake-on-arp-for-that-address.  It could be
 made arbitrarily simple:  pass a byte value and an offset within the
 packet, and only wake on broadcasts where that byte matches.  Pointing it
 at the low byte of the IP address in an ARP packet would only wake you for
 1/256th of random broadcast packets; and in real life they are seldom
 random, so you win bigger.  This would eliminate the need for unusual "arp
 and NDP timeouts" in every host or gateway that wants to initiate a
 connection to an OLPC laptop.]

-- 
Ticket URL: <https://dev.laptop.org/ticket/3732#comment:13>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system