Unicast packets stop being transmitted to a particular station, under load, when WPA2 is enabled

[Dave Taht]

On Wed, May 14, 2014 at 12:07 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
> On Mon, May 12, 2014 at 4:21 AM, Avery Pennarun <apenwarr at gmail.com> wrote:
>> Nevertheless, I can certainly see things being ACKed in my wifi
>> traces.  I think maybe some incorrect Add Block Ack Request packets
>> may be triggering a bug in the wifi driver on my macbook?
>>
>> IEEE 802.11 wireless LAN management frame
>>     Fixed parameters
>>         Category code: Block Ack (3)
>>         Action code: Add Block Ack Request (0x00)
>>         Dialog token: 0x01
>>         Block Ack Parameters: 0x1017, A-MSDUs, Block Ack Policy
>>             .... .... .... ...1 = A-MSDUs: Permitted in QoS Data MPDUs
>>             .... .... .... ..1. = Block Ack Policy: Immediate Block Ack
>>             .... .... ..01 01.. = Traffic Identifier: 0x0005
>>             0001 0000 00.. .... = Number of Buffers (1 Buffer = 2304 Bytes): 64
>>         Block Ack Timeout: 0x0000
>>         Block Ack Starting Sequence Control (SSC): 0x0000
>>             .... .... .... 0000 = Fragment: 0
>>             0000 0000 0000 .... = Starting Sequence Number: 0
>
> Replicated this a few more times.  Still on a Macbook, but a different
> one (latest MacOS version this time) on a different setting.
>
> Once again, the problem kicked in immediately following an ADDBA
> request like the above.  The TID was this time equal to 3 (which I
> think is the problematic one last time too; I accidentally pasted the
> ADDBA for TID=5 but in my earlier email I called out TID=3 as the one
> that triggered the problem).
>
> In this new test case, interestingly, unicast continued to work as
> long as I was sending packets off-LAN (ie. through a gateway to
> somewhere on the Internet); packets could be exchanged in both
> directions.  But I couldn't ping the gateway or any other
> LAN-connected device.  This is fishy since I might have blamed a lack
> of multicast/broadcast and thus a failure of ARP (unicast was
> obviously working) but my ARP table definitely contained the IP of the
> gateway.
>
> Anyway, one new clue: the ADDBA was triggered by a TCP ACK packet
> being sent by the SPDY port on a server somewhere with a particular
> packet priority: diffserv field = 0x60 (class selector 3, no ECN).
>
> I don't know why this would scramble my Macbook's wifi, since the
> packets themselves looked fine, but it did.  This was definitely the
> first SPDY packet on the session and it triggered the ADDBA and died
> instantly.
>
> I really should take Dave Taht's advice and get that netperf thing
> going and test all the QoS queues... but meanwhile, I think I'm in a
> big hurry so I probably want to just rip out all support for mapping
> diffserv to QoS on the ath10k transmit side.  Does anyone have any
> suggestions on where to look for my hack-and-slash operation?

Tis easy to hack and slash it out of cfg80211_classify8021d in
net/wireless/util.c

Recently someone added a direct mapping from vlan priorities to wifi
queues here - which is stupid, as the VO queue does not behave
anything like the equivalent vlan priority queue does. I'd like to see
that removed or mapped properly, also.

Or you can try telling hostapd to never negotiate wmm/802.11e.

Last night I got it to blow up the vi, vo, and bk queues on the ath9k
in about 4 hours, and I just successfully in under 20 minutes got the
BK queue to misbehave, driven by an iwl driver on linux, on both ipv6
and ipv4. It is probable this is elsewhere in the stack than the
drivers themselves. (although things are so intertwined down here that
it's hard to tell). Perhaps running on a noisier network triggers it
faster.

I logged last nights progress on http://www.bufferbloat.net/issues/442
- with pictures and logs - there are packet captures on that bug now,
but not on the monitoring interface. Adding that now.

What I just saw looks like this.

Command: /usr/local/bin/netperf -P 0 -v 0 -D -0.2 -6 -Y CS1,CS1 -H
fdfe:7b16:f8e2::1 -t TCP_STREAM -l 300 -f m
Program output:
  netperf: send_omni: connect_data_socket failed: Connection timed out

Warning: Command produced no valid data.
Data series: Ping (ms) UDP BK
Runner: NetperfDemoRunner
Command: /usr/local/bin/netperf -P 0 -v 0 -D -0.2 -6 -Y CS1,CS1 -H
fdfe:7b16:f8e2::1 -t UDP_RR -l 310 -- -e 2
Standard error output:

+ :
+ expr 3 + 1
+ i=4
+ netperf-wrapper -l 300 -H 172.21.18.1 -t default-4 -o default-4.svg
-p all_scaled rrul
Warning: Program exited non-zero (1).
Command: /usr/local/bin/netperf -P 0 -v 0 -D -0.2 -4 -Y CS1,CS1 -H
172.21.18.1 -t TCP_MAERTS -l 300 -f m
Program output:
  netperf: send_omni: connect_data_socket failed: Connection timed out

Warning: Program exited non-zero (1).
Command: /usr/local/bin/netperf -P 0 -v 0 -D -0.2 -4 -Y CS1,CS1 -H
172.21.18.1 -t TCP_STREAM -l 300 -f m
Program output:
  netperf: send_omni: connect_data_socket failed: Connection timed out

The bk, be, and vi queues are currently still operational.
>
> Thanks,
>
> Avery
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article