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

Wed Jan 23 15:45:00 EST 2013

#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):

 By running a fake DNS server on another system on the same network, we can
 see that the DNS query packets never make it to their destination.

 Looking at the mwifiex level, in the failing case, the two DNS query
 packets (one ipv4 query followed by one ipv6) are being aggregated
 (A-MSDU) by the driver and then transmitted in just one frame. In the
 success case (with the print statement added), the frames are not
 aggregated - presumably due to a slight change in timing.

 In the aggregation case, the first ethernet frame is:
 {{{
 d4 d1 84 a7 07 f4 20 16 d8 1e 88 ab 08 00 45 00 00 47 d8 53 40 00 40 11 de
 de c0 a8 01 22 c0 a8 01 01 85 29 00 35 00 33 42 7c 61 a9 01 00 00 01 00 00
 00 00 00 00 07 6d 69 72 72 6f 72 73 0d 66 65 64 6f 72 61 70 72 6f 6a 65 63
 74 03 6f 72 67 00 00 01 00 01
 }}}

 The second frame is:
 {{{
 d4 d1 84 a7 07 f4 20 16 d8 1e 88 ab 08 00 45 00 00 47 d8 54 40 00 40 11 de
 dd c0 a8 01 22 c0 a8 01 01 85 29 00 35 00 33 e4 d7 a4 4d 01 00 00 01 00 00
 00 00 00 00 07 6d 69 72 72 6f 72 73 0d 66 65 64 6f 72 61 70 72 6f 6a 65 63
 74 03 6f 72 67 00 00 1c 00 01
 }}}

 And these are aggregated in this form to be sent to the hardware:
 {{{
 d1 00 00 00 00 00 bd 00 10 00 e6 00 00 00 00 00 00 00 00 00 d4 d1 84 a7 07
 f4 20 16 d8 1e 88 ab 00 4f aa aa 03 00 00 00 08 00 45 00 00 47 d8 54 40 00
 40 11 de dd c0 a8 01 22 c0 a8 01 01 85 29 00 35 00 33 e4 d7 a4 4d 01 00 00
 01 00 00 00 00 00 00 07 6d 69 72 72 6f 72 73 0d 66 65 64 6f 72 61 70 72 6f
 6a 65 63 74 03 6f 72 67 00 00 1c 00 01 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00
 }}}

 That aggregation is obviously bad, only the 2nd frame is present. Fixed by
 {{{
 commit d92a680359ff3230bd1e68ac8f3ac827639f494e
 Author: Yogesh Ashok Powar <yogeshp at marvell.com>
 Date:   Fri Aug 3 18:05:59 2012 -0700

     mwifiex: copy MSDU subframes correctly
 }}}

 now in arm-3.5, as well as 2 related fixes.

 This doesn't solve the yum case though. Repeating the test:

 First frame:
 {{{
 d4 d1 84 a7 07 f4 20 16 d8 1e 88 ab 08 00 45 00 00 47 bb 22 40 00 40 11 fc
 0f c0 a8 01 22 c0 a8 01 01 ec 66 00 35 00 33 c7 64 75 83 01 00 00 01 00 00
 00 00 00 00 07 6d 69 72 72 6f 72 73 0d 66 65 64 6f 72 61 70 72 6f 6a 65 63
 74 03 6f 72 67 00 00 01 00 01
 }}}

 Second frame:
 {{{
 d4 d1 84 a7 07 f4 20 16 d8 1e 88 ab 08 00 45 00 00 47 bb 23 40 00 40 11 fc
 0e c0 a8 01 22 c0 a8 01 01 ec 66 00 35 00 33 4c e4 d5 03 01 00 00 01 00 00
 00 00 00 00 07 6d 69 72 72 6f 72 73 0d 66 65 64 6f 72 61 70 72 6f 6a 65 63
 74 03 6f 72 67 00 00 1c 00 01
 }}}

 Aggregated to:
 {{{
 d1 00 00 00 00 00 bd 00 10 00 e6 00 00 00 00 00 00 00 00 00 d4 d1 84 a7 07
 f4 20 16 d8 1e 88 ab 00 4f aa aa 03 00 00 00 08 00 45 00 00 47 bb 22 40 00
 40 11 fc 0f c0 a8 01 22 c0 a8 01 01 ec 66 00 35 00 33 c7 64 75 83 01 00 00
 01 00 00 00 00 00 00 07 6d 69 72 72 6f 72 73 0d 66 65 64 6f 72 61 70 72 6f
 6a 65 63 74 03 6f 72 67 00 00 01 00 01 00 00 00 d4 d1 84 a7 07 f4 20 16 d8
 1e 88 ab 00 4f aa aa 03 00 00 00 08 00 45 00 00 47 bb 23 40 00 40 11 fc 0e
 c0 a8 01 22 c0 a8 01 01 ec 66 00 35 00 33 4c e4 d5 03 01 00 00 01 00 00 00
 00 00 00 07 6d 69 72 72 6f 72 73 0d 66 65 64 6f 72 61 70 72 6f 6a 65 63 74
 03 6f 72 67 00 00 1c 00 01
 }}}

 Analysing the aggregation:
 {{{
 Marvell SDIO header: d1 00 00 00

 Marvell TX descriptor: 00 00 bd 00 10 00 e6 00 00 00 00 00 00 00 00 00
 e6 indicates AMSDU (good)

 A-MSDU subframe 1:
 DA: d4 d1 84 a7 07 f4
 SA: 20 16 d8 1e 88 ab
 Length: 00 4f

 MSDU:
 LLC header: aa aa 03 00 00 00 08 00
 Data: 45 00 00 47 bb 22 40 00 40 11 fc 0f c0 a8 01 22 c0 a8 01 01 ec 66 00
 35 00 33 c7 64 75 83 01 00 00 01 00 00 00 00 00 00 07 6d 69 72 72 6f 72 73
 0d 66 65 64 6f 72 61 70 72 6f 6a 65 63 74 03 6f 72 67 00 00 01 00 01
 Padding: 00 00 00

 A-MSDU subframe 2:
 DA: d4 d1 84 a7 07 f4
 SA: 20 16 d8 1e 88 ab
 Length: 00 4f

 MSDU:
 LLC: aa aa 03 00 00 00 08 00
 Data: 45 00 00 47 bb 23 40 00 40 11 fc 0e c0 a8 01 22 c0 a8 01 01 ec 66 00
 35 00 33 4c e4 d5 03 01 00 00 01 00 00 00 00 00 00 07 6d 69 72 72 6f 72 73
 0d 66 65 64 6f 72 61 70 72 6f 6a 65 63 74 03 6f 72 67 00 00 1c 00 01
 }}}

 Looks fine, but still no response to the DNS query.

 We'll test tomorrow with a different 802.11n AP.

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