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

[Avery Pennarun]

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?

Thanks,

Avery