#6818 NORM Never A: Driver does not set link level multicast addresses into firmware when ip address assigned to mesh interface

[Zarro Boogs per Child]

#6818: Driver does not set link level multicast addresses into firmware when ip
address assigned to mesh interface
-----------------------+----------------------------------------------------
  Reporter:  shailen   |       Owner:  dwmw2         
      Type:  defect    |      Status:  new           
  Priority:  normal    |   Milestone:  Never Assigned
 Component:  wireless  |     Version:                
Resolution:            |    Keywords:                
  Verified:  0         |    Blocking:                
 Blockedby:            |  
-----------------------+----------------------------------------------------

Comment(by carrano):

 It seems we finished the first part of the story: Making the multicast
 filter not break anything. But it seems we still have work to do on the
 second: make the multicast filter actually work on a suspended XO.

 I just did the following test (on a 703 build, with firmware 22.p10 and a
 kernel patched as above (mesh_mcast_v2.patch):

 Supended a node and tested resume for the following events (all of than
 should bring the node back, I believe)

 1 - ping multicast address 224.0.0.1 => OK (the node resumed)

 2 - shared an activity in another node (this causes multicast frames to be
 sent to 01:00:5e:00:00:fb) => FAIL (the suspended node ignored). Expected:
 the activity would show up on the mesh view (as it did in the control
 group) - it did not.

 3 - added another node to the mesh (this also causes multicast frames to
 be sent to 01:00:5e:00:00:fb) => FAIL (the suspended node ignored).
 Expected: the new XO would show up on the mesh view (as it did in the
 control group) - it did not.

 I would like to stress that:

 A - the ip maddr output is not providing us with the information we need
 (it always report the expected bindings, for example to
 01:00:5e:00:00:fb). I would say it does not report actual multicast
 addresses informed to the firmware.

 B - Once again the 224.0.0.1 address (bound to 01:00:5e:00:00:01) works
 while another multicast addresses fail. (please refer to
 http://dev.laptop.org/ticket/6854#comment:8). My guess is that
 understanding this will provide us with an insight.

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