#6823 NORM Never A: Active antenna mesh parameters cannot be changed

[Zarro Boogs per Child]

#6823: Active antenna mesh parameters cannot be changed
--------------------------+-------------------------------------------------
  Reporter:  carrano      |       Owner:  wad           
      Type:  enhancement  |      Status:  new           
  Priority:  normal       |   Milestone:  Never Assigned
 Component:  wireless     |     Version:                
Resolution:               |    Keywords:                
  Verified:  0            |    Blocking:                
 Blockedby:               |  
--------------------------+-------------------------------------------------
Changes (by bcavagnolo):

  * owner:  dwmw2 => wad


Comment:

 I implemented iwprivs to access the new extensions to the CMD_MESH_CONFIG
 firmware command.  The patch is posted here:
 http://lists.laptop.org/pipermail/devel/2008-May/014199.html

 The iwprivs are documented here:
 http://www.laptop.org/teamwiki/index.php/Tech:Wireless

 I tested the new functionality using the tests implemented in the attached
 activeant.sh script.  Note that it only tests the iwprivs against the
 firmware 5.126.0.p5.  I also did some casual testing against other
 firmware versions.  I've reassigned to John Watlington for acceptance.
 The following details may be interesting to future driver maintainers and
 firmware maintainers:

 -- To enable the mesh, the driver formerly sent a string representing the
 mesh SSID to the firmware.  Now, in place of this string, it sends a
 custom Marvell mesh information element.  This change is inspired by the
 0002-Flash_Mesh_Parameters.patch from Shailendra.  I would have expected
 this change to break the mesh start/stop functionality in older versions
 of the firmware.  Specifically, I would have expected this to cause the
 older firmware to put a garbled Marvell mesh IE in the mesh beacon frames.
 However, I did not observe this.  Instead, beacons from versions
 5.110.22.p9 and 5.110.22.p14 appear correct and identical.  I cannot
 explain this.

 -- I expected the new extended CMD_MESH_CONFIG actions to fail on hardware
 that does not implement the persistent defaults.  This is the behavior
 with the 5.126.0.p5 firmware.  However, with the 5.110.22.pX firmware,
 they new actions succeed but return all 0s.  I would consider this a bug
 that should be addressed in the 5.110.22.pX firmware.  I would recommend
 fixing the 5.110.22.pX to properly set/get the persistent settings IF it
 is running on hardware that supports those settings (i.e., an active
 antenna).  This would eliminate the need for the special  5.126.0.p5
 firmware.

 -- The mesh functionality in the 5.126.0.p5 firmware appears to be broken.
 In particular, when I set up a mesh network on two XOs using this firmware
 and the following commands:

 $ ifconfig eth1 down
 $ iwconfig eth1 channel 1
 $ iwconfig msh0 essid foobar
 $ ifconfig msh0 192.168.4.X

 They cannot ping each other and a sniffer reveals that no traffic is
 transmitted from either node.  This may or may not be a bug.

 -- After much time staring at 0002-Flash_Mesh_Parameters.patch, I realized
 that the CMD_MESH_CONFIG is extensible using two parameters: type and
 action.  For the mesh start and mesh stop commands, the type comes from
 the IEEE802.11 proprietary TLV space and the action is either start or
 stop.  For the new getters and setters, the action is either get or set
 and the type represents the parameter to be getted or setted.  OPINION:
 This is confusing.  The types should all come from one space, and the
 actions should all come from another.  I wouldn't call this a bug per se,
 but it is confusing and messier to maintain, especially if the
 CMD_MESH_CONFIG command is to be extended further.

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