Question on beacon-miss offloading.

Ben Greear greearb at
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
>> wrong.
> 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...
> Thanks,
> Ben

Ben Greear <greearb at>
Candela Technologies Inc

More information about the ath10k mailing list