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

Avery Pennarun apenwarr at gmail.com
Sun May 11 21:56:04 PDT 2014

On Mon, May 12, 2014 at 12:05 AM, Ben Greear <greearb at candelatech.com> wrote:
> On 05/11/2014 08:54 PM, Avery Pennarun wrote:
>> On Sun, May 11, 2014 at 11:09 PM, Ben Greear <greearb at candelatech.com>
>> wrote:
>>> Also, have you tried sniffing with a third device to see if
>>> the AP actually puts the ICMP responses on the air?
>> I did try that.  As far as I can tell, the ICMP responses are simply
>> not being sent at all.

I was incorrect about this because I was looking at the wrong data.  I
tested again with a more obvious method, running "ping -i0.01" where 107 is the address of my macbook.  With 100
packets per second, they overwhelm the rest of the traffic so it's
easy to see whether they're coming through.

The AP definitely *is* transmitting the packets on the air.  Even my
macbook can see them in the radiotap tcpdump mode, but it doesn't see
them at the IP layer.  So they are either being encrypted wrong or my
macbook is decrypting them wrong, I guess.

I think I'll try using wireshark and see what it thinks...

> I haven't dug into many of the stats yet, but it's possible the
> ath10k debugfs file would show some types of transmit errors in this case?

Possibly.  Can you give me a hint of where to look?  I don't really
know what these files do.

> Might be interesting to see how long it takes the AP to generate
> the tx status response for the transmitted ICMP packets.  My firmware
> has some extended tx status, but I'm not sure it has anything overly
> useful for your case...I was mostly concerned with the tx rate reporting
> when writing it.

I can try it with your firmware if you think there is useful data to
gather, although since it turned out my earlier statement wasn't true
maybe this is less important :)



More information about the ath10k mailing list