* Re: Ath10k probe response error related to mac80211 commit. [not found] ` <1472756034.9608.15.camel@sipsolutions.net> @ 2016-09-01 20:52 ` Ben Greear 2016-09-02 12:09 ` Michal Kazior 0 siblings, 1 reply; 3+ messages in thread From: Ben Greear @ 2016-09-01 20:52 UTC (permalink / raw) To: Johannes Berg, linux-wireless@vger.kernel.org, ath10k 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@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Ath10k probe response error related to mac80211 commit. 2016-09-01 20:52 ` Ath10k probe response error related to mac80211 commit Ben Greear @ 2016-09-02 12:09 ` Michal Kazior 2016-09-02 13:30 ` Ben Greear 0 siblings, 1 reply; 3+ messages in thread From: Michal Kazior @ 2016-09-02 12:09 UTC (permalink / raw) To: Ben Greear; +Cc: Johannes Berg, linux-wireless@vger.kernel.org, ath10k On 1 September 2016 at 22:52, Ben Greear <greearb@candelatech.com> wrote: > 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. Sounds like 802.11 header vs 802.3 header length problem (24 - 14 = 10). You can hit this if you start playing around tx encap mode as well. You could try fooling firmware into thinking the frame has a different length either in htt TX_FRM or tx fragment list (or both) but since this seems to be related to RA/DA peer state at xmit time it's probably not going to be reliable unless you introduce extra tx flushing barriers in the driver. Michał _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Ath10k probe response error related to mac80211 commit. 2016-09-02 12:09 ` Michal Kazior @ 2016-09-02 13:30 ` Ben Greear 0 siblings, 0 replies; 3+ messages in thread From: Ben Greear @ 2016-09-02 13:30 UTC (permalink / raw) To: Michal Kazior; +Cc: Johannes Berg, linux-wireless@vger.kernel.org, ath10k On 09/02/2016 05:09 AM, Michal Kazior wrote: > On 1 September 2016 at 22:52, Ben Greear <greearb@candelatech.com> wrote: >> 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. > > Sounds like 802.11 header vs 802.3 header length problem (24 - 14 = > 10). You can hit this if you start playing around tx encap mode as > well. > > You could try fooling firmware into thinking the frame has a different > length either in htt TX_FRM or tx fragment list (or both) but since > this seems to be related to RA/DA peer state at xmit time it's > probably not going to be reliable unless you introduce extra tx > flushing barriers in the driver. The problem is that the OS sent the packet on the mgt-tid, but the firmware over-rode this and put it on non-qos TID instead. mgt and non-pause TIDs are 'raw', and do not need that -10 adjustment, and my logic to handle mgt frames on the normal htt path depends on that distinction. Probably I could fix up htt tx path to do that -10 stuff depending on eventual TID instead of making assumptions, but if I do this, it will probably be in 10.4 as I am hoping to keep 10.1 mostly just stable fixes and the htt tx path is one tricky beast. Search firmware for "The tidno that DE finds needs to be overridden for non-QOS" and you can see where this happens. I just fixed that firmware code to not override TID if it were already >= non-qos-tid. Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-09-02 13:31 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <cf9852df-6d14-baf6-af0a-9cc78c448fde@candelatech.com>
[not found] ` <1472752911.9608.11.camel@sipsolutions.net>
[not found] ` <c7eb32b4-84c5-41ae-1fe6-89df7cbbe7d4@candelatech.com>
[not found] ` <1472756034.9608.15.camel@sipsolutions.net>
2016-09-01 20:52 ` Ath10k probe response error related to mac80211 commit Ben Greear
2016-09-02 12:09 ` Michal Kazior
2016-09-02 13:30 ` Ben Greear
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox