#12483 NORM 13.1.0: mwifiex communication problems related to A-MSDU aggregation (was: XO-4 C1 problem executing yum/curl Python code)

[Zarro Boogs per Child]

#12483: mwifiex communication problems related to A-MSDU aggregation
------------------------------------+---------------------------------------
           Reporter:  dsd           |       Owner:  dsd          
               Type:  defect        |      Status:  closed       
           Priority:  normal        |   Milestone:  13.1.0       
          Component:  not assigned  |     Version:  not specified
         Resolution:  fixed         |    Keywords:               
        Next_action:  diagnose      |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------
Changes (by dsd):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 We tried to monitor the buggy AP to see whats going on, but now the
 problem can't be reproduced. Maybe a change in the AP settings has caused
 a behaviour change; mwifiex now no longer attempts A-MSDU aggregation
 here, and yum works OK. Going back to the old AP settings (security etc)
 doesn't re-introduce the issue either.

 The (incomplete) dumps we managed to capture show that there is now some
 evidence of a block ack agreement, which might explain why mwifiex would
 not go for the A-MSDU option any more.

 So I think we just have to close the bug now with the following findings:
  * Manuel's AP is likely buggy, not accepting A-MSDUs, in violation of the
 802.11n spec
  * We don't fully understand mwifiex's logic of when to choose between
 A-MSDU and otherwise
  * We have fixed a real bug relating to mwifiex's formation of A-MSDUs for
 when that does happen, and I've tested resultant A-MSDUs against a linksys
 802.11n AP.

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