On 09/01/2016 11:53 AM, Johannes Berg wrote:
On Thu, 2016-09-01 at 11:23 -0700, Ben Greear wrote:
Could easily be that others are corrupted too, but since probe resp
is bad, the association will not proceed.
makes sense.
Heh, I spent 4 days tracking this down, so I wanted to be precise in
my bug report :)
Ahrg, ouch. Sorry about that. I really didn't think the flag would
cause any issues for anyone.
The result I see is that there is an extra 10 bytes at the end of the
frame on air. But, it looks like the exact same pkt is sent to the
firmware both with and without this patch. Maybe the firmware is
using the wrong tid or something like that due to how the station is
created differently with this patch.
That makes no sense though, unless this only happens on say the second
station that connects? Until the first station sends an authentication
frame, that patch really should have no impact whatsoever.
Ok, I found the problem.
In the 10.1 firmware (at least), it will force the TID to be NON-QOS-TID
if the peer object does not have the qos_enabled flag set. This is probably
a work-around for some other thing lost in antiquity.
When using my firmware that puts mgt frames over HTT, the TID for mgt
frames was being over-ridden and set to non-qos TID. Due to other
hackery and work-arounds, mgt frames cannot be sent on the non-qos
TID because they will be put on-air 10 bytes too long. They must be
sent on the mgt-tid or non-pause tid.
I am guessing that somehow this mac80211 change creates a peer early
that does not have the qos logic enabled, and so that is why I suddenly
started hitting this bug.
Probably stock firmware is OK since it uses a second tx path for management,
and I guess that by whatever time it starts sending non-mgt frames the
qos-enabled logic is set properly.
I can fix this in my firmware by making it not over-ride the TID in
this case.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
