Question on beacon-miss offloading.
greearb at candelatech.com
Tue Jun 16 16:06:35 PDT 2015
On 06/16/2015 02:55 PM, Ben Greear wrote:
> On 06/15/2015 10:29 PM, Michal Kazior wrote:
>>> This patch below (with firmware fix to make it actually pay attention
>>> to this special TID in station mode), fixes the null-func to be non-qos
>>> frames and get immediate ack. This in turn seems to fix the disconnect
>>> issue I was facing, though I need to test some more to be sure.
>>> This seem reasonable, maybe even for upstream?
>>> [greearb at ben-dt2 ath10k]$ git diff
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>> index 6ca48e3..610447e 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -2213,6 +2213,9 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)
>>> if (ieee80211_is_mgmt(hdr->frame_control))
>>> return HTT_DATA_TX_EXT_TID_MGMT;
>>> + if (ieee80211_is_nullfunc(hdr->frame_control))
>>> + return HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;
>> That's weird.. QoS NullFunc frames are already converted to non-QoS
>> frames, see ath10k_tx_h_nwifi():
> True, but the 4.0.4 kernel sends down non-qos null-func frames as far
> as I can tell, at least when doing connection probing.
> In my case, my kernel was sending non-qos nullfunc frame to firmware, but then
> firmware stuck it on BE queue and made it QoS.
Stock 4.0.4 and stock firmware-2.bin have the same 'nullfunc sent as qos and no immediate ack' bug,
so it must be something that was fixed or changed between 4.0.4 and the 4.1.x ath tree.
>> /* Some firmware revisions don't handle sending QoS NullFunc well.
>> * These frames are mainly used for CQM purposes so it doesn't really
>> * matter whether QoS NullFunc or NullFunc are sent.
>> hdr = (void *)skb->data;
>> if (ieee80211_is_qos_nullfunc(hdr->frame_control))
>> cb->htt.tid = HTT_DATA_TX_EXT_TID_NON_QOS_MCAST_BCAST;
>> Or is it that ath10k_tx_h_get_tid() has a bug that ends up assigning
>> an invalid tid for non-QoS NullFunc frames? If so I guess your patch
>> would be okay with some comments/commit-log explaining why/what was
> I tried very recent upstream ath kernel, and stock firmware-2.bin, and it
> seems to generate null-func frames fine. I'll go back at look at my
> recent FW and kernel changes in more detail now that I understand the problem
> better and see if I can figure out what is going on...
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc http://www.candelatech.com
More information about the ath10k