#12483 NORM 13.1.0: XO-4 C1 problem executing yum/curl Python code

[Zarro Boogs per Child]

#12483: XO-4 C1 problem executing yum/curl Python code
------------------------------------+---------------------------------------
           Reporter:  dsd           |       Owner:  dsd          
               Type:  defect        |      Status:  new          
           Priority:  normal        |   Milestone:  13.1.0       
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  diagnose      |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by dsd):

 Section 9.11 of the 802.11-2012 spec makes it clear that 802.11n APs must
 be able to accept A-MSDUs:

   A STA that has a value of false for dot11HighthroughputOptionImplemented
 shall not transmit an A-MSDU.

   A STA shall not transmit an A-MSDU to a STA from which it has not
 received a frame containing an HT Capabilities element.

   Support for the reception of an A-MSDU, where the A-MSDU is carried in a
 QoS data MPDU with Ack Policy equal to Normal Ack and the A-MSDU is not
 aggregated within an A-MPDU, is mandatory for an HT STA.

 mwifiex prefers A-MPDU, because it is believed that A-MPDU is generally
 more efficient, however A-MPDU depends on block acks which are still
 optional even in 802.11n (I think).

 Even though it looks like manuq's AP is buggy, the question remains of why
 the driver falls back to A-MSDU here, instead of using A-MPDU.

 The scan results do talk about A-MPDU availability, even though block acks
 are missing from the capability bits:

 {{{
 BSS d4:d1:84:a7:07:f5 (on wlan0) -- associated
         TSF: 1096428441987 usec (12d, 16:33:48)
         freq: 2437
         beacon interval: 100
         capability: ESS Privacy ShortSlotTime (0x0411)
         signal: -35.00 dBm
         last seen: 450 ms ago
         Information elements from Probe Response frame:
         SSID: gatobus
         Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0
         DS Parameter set: channel 6
         ERP: Barker_Preamble_Mode
         Extended supported rates: 6.0 9.0 12.0 48.0
         HT capabilities:
                 Capabilities: 0x18fe
                         HT20/HT40
                         SM Power Save disabled
                         RX Greenfield
                         RX HT20 SGI
                         RX HT40 SGI
                         TX STBC
                         No RX STBC
                         Max AMSDU length: 7935 bytes
                         DSSS/CCK HT40
                 Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                 Minimum RX AMPDU time spacing: 8 usec (0x06)
                 HT RX MCS rate indexes supported: 0-15, 32
                 HT TX MCS rate indexes are undefined
         HT operation:
                  * primary channel: 6
                  * secondary channel offset: above
                  * STA channel width: any
                  * RIFS: 0
                  * HT protection: non-HT mixed
                  * non-GF present: 0
                  * OBSS non-GF present: 1
                  * dual beacon: 0
                  * dual CTS protection: 0
                  * STBC beacon: 0
                  * L-SIG TXOP Prot: 0
                  * PCO active: 0
                  * PCO phase: 0
         WPA:     * Version: 1
                  * Group cipher: TKIP
                  * Pairwise ciphers: TKIP
                  * Authentication suites: PSK
                  * Capabilities: 16-PTKSA-RC (0x000c)
         WMM:     * Parameter version 1
                  * u-APSD
                  * BE: CW 15-1023, AIFSN 3
                  * BK: CW 15-1023, AIFSN 7
                  * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
                  * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
 }}}

 What's strange is that on my local linksys AP, where mwifiex does not try
 to use A-MSDU, the block ack bits are also missing from capabilities, both
 for the mwifiex STA and the linksys AP. Yet as the attached traffic dump
 shows, the AP opens up a block ack agreement immediately after the STA
 associates, and the STA accepts.

 Will try to get a traffic dump from manuq's buggy AP to see if there is an
 obvious explanation for the behaviour difference there.

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