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

Avery Pennarun apenwarr at gmail.com
Sun May 11 19:29:06 PDT 2014


On Sun, May 11, 2014 at 10:07 PM, Dave Taht <dave.taht at gmail.com> wrote:
> 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 think my problem may be something else.  In particular, it seems to
affect each station separately, and doesn't seem to happen if I
disable encryption.  (Does your ath9k problem trigger if encryption is
turned off?)  I also have an ath9k device in the same AP on 2.4 GHz,
and it doesn't trigger there either.  I haven't attempted to see if
your bug triggers on that one though :)

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

I just checked, and my bug seems to trigger more often when I'm at a
longer distance (my macbook says about -60 RSSI) and less often at a
closer distance (currently macbook reports RSSI of -41).  Not sure if
this is related to increased retransmits or decreased speed or
something else.

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

That's not a bad idea... I really need to get netperf-wrappers going
for some stress testing :)

Have fun,

Avery



More information about the ath10k mailing list