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

[Dave Taht]

On Sun, May 11, 2014 at 6:57 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
> Version: 3.15-rc1 and ath10k-stable-3.11-8 (both via backports to kernel 3.2.26)
> Firmware: 10.1.467.2-1
>
> Steps:
> - Configure ath10k as AP on channel 149, width 80 MHz, WPA2 encryption
> - Connect my 2009 macbook
> - Start a ping of 8.8.8.8 in the background from my macbook
> - Generate some traffic.  The trigger varies, but running uTorrent or
> quickly opening a lot of background tabs in Chrome usually seems to
> set it off within a couple of minutes.  iperf and isoping don't seem
> to cause any trouble.
>
> Expected:
> - ping keeps pinging
>
> Actual:
> - tcpdump on the ath10k host shows ICMP requests coming in, and
> responses going out.
> - tcpdump on the macbook shows ICMP requests going out, but no
> responses coming back.
> - tcpdump -I (radiotap mode) on the macbook is a little hard to
> understand since it's encrypted, but it shows some packets coming out
> of the ath10k (broadcasts, I think) but no unicast packets to the
> macbook.
> - tcpdump on the macbook *does* show broadcast packets arriving.  For
> example, ARP requests and "ping -b 192.168.1.255" (my local subnet IP
> address) get through.
> - Disconnecting and then reconnecting the wifi on my macbook fixes the
> problem until it next triggers.
> - Other STAs connected to the AP are not affected when the one STA
> isn't able to communicate (although each one has the potential to
> trigger the problem)
>
> Disabling encryption makes the problem go away permanently.
>
> This is pretty quick for me to reproduce, but unfortunately I don't
> have any steps to trigger it instantly, nor any command line tools
> that seem to make it happen.  (For example I tried multiple parallel
> 'curl' processes in a loop, and no lock.)
>
> Nothing interesting appears in the dmesg or hostapd logs at the time
> of the problem.
>
> This sounds like it could be a problem with crypto session keys, but I
> don't understand why it would only be wrong in a single direction.  I
> also don't think my keys are rotating this quickly, so this shouldn't
> be a key rotation problem (though I don't understand very well how
> that works).

I have been failing to find and fix a very similar problem on the
ath9k for many months now. What I see happening there is that one or
more of the
hardware queues locks up, and stops transmitting traffic. So, for
example I might get traffic destined for the BK (background queue,
traffic marked CS1) hung,
but BE remains fine. Most recently I was able to lock up the VO, VI
AND BK queues by exercising it overnight with multiple copies of the
rrul test.

I don't know much about how the hardware queues are configured on
ath10k, but you can land stuff in each queue by marking with CS0, CS1,
CS5, and CS7 (BE,BK,VI,VO) on mac80211 based devices.

I can make it happen more often, faster, if the associated station has
considerable distance and less signal strength than nearby.

My bug in the bug tracker is here:

http://www.bufferbloat.net/issues/442

> It might be my imagination, but it's possible that this triggers more
> quickly if my macbook has been connected for a longer period of time
> before generating the traffic burst.

>
> Anything I can check to help narrow this down?

Move it farther away.

Blow it up with netperf-wrappers -H someserver rrul...

> 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