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

[Dave Taht]

On Wed, May 14, 2014 at 11:12 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
> On Wed, May 14, 2014 at 3:26 PM, Dave Taht <dave.taht at gmail.com> wrote:
>> On Wed, May 14, 2014 at 12:07 PM, Avery Pennarun <apenwarr at gmail.com> wrote:
>>> 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.
>
> Yup, replaced this function with 'return 0' and my problems are gone.
> (Well okay, this problem is gone, and you're probably not interested
> in my personal problems. :))

The wifi alliance won't certify something that doesn't do 802.11e
"correctly". Not that I care.

A side effect of ripping this out is that some prioritized traffic, notably
multicast & dhcp (marked with CS6) now gets head of line blocked
in the BE queue until it can be delivered.

A possible problem with this "fix" is that the underlying hw queues are
still having some sort of problem in the driver, and doing a
multicast flood (say, mdns-scan or uftp) while doing other traffic might
trigger it again.

The linux 4 exposed queue problem should long ago have been
bumped to directly include a 5th queue observable and manageable
for multicast events.

> Obviously just completely disabling QoS multiple queues is not the
> right long term fix, but as Dave pointed out, it wasn't clear the code
> there was exactly what we want anyway, so I won't feel too guilty
> about it.

Well, after spending 4+ months trying to get to the bottom of this
myself...

... I just also ripped 802.11e out of cerowrt in this same file for more
testing.

802.11e in a packet aggregated world is both conceptually and
operationally broken, when the real resource limit is txops,
and cramming as many packets (sanely) into a txop is more the
right thing.

I've been showing that 4 hardware queues induces more latency
than 1 for a long time now, I am inspired (before I commit to
ripping out 802.11e entirely) to produce some graphs showing how
horrible flooding those queues is, compared to having one queue.

Now, getting away from doing QoS at this level opens up an opportunity
in that there are still 4 independently programmable tx queues (from
hostapd) and they could be used instead as a poor mans "mu-mimo" to
drive multiple stations more sanely.

> Meanwhile, hopefully someone with deeper knowledge than me
> can figure out what's with the IVs.

+10

> Thanks!
>
> Avery



-- 
Dave Täht

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