DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9658E2154B
Subject: Re: How many null-data probes on connection loss?
To:     Johannes Berg <johannes@sipsolutions.net>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
References: <9a1447d9-9a61-dc2d-0101-33c6bdeb946f@candelatech.com>
 <1537951137.28767.5.camel@sipsolutions.net>
 <fc564b2e-b6f2-75db-a2d9-99ea55a63c4a@candelatech.com>
 <1537986415.28767.17.camel@sipsolutions.net>
 <7ed031b0-19d9-46db-33d9-082999e5ed22@candelatech.com>
 <1537987703.28767.22.camel@sipsolutions.net>
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
Message-ID: <e3c18a8d-9a58-54c5-9aaa-b778299f527b@candelatech.com>
Date:   Wed, 26 Sep 2018 15:21:23 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <1537987703.28767.22.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 09/26/2018 11:48 AM, Johannes Berg wrote:
> On Wed, 2018-09-26 at 11:47 -0700, Ben Greear wrote:
>
>>>> I think I'll start by making sure the firmware does not do software retransmits
>>>> for frames from the driver (self-gen frames are OK to be retransmitted I guess).
>>>
>>> You do want it to be doing retries for frames from the driver, since you
>>> want it to recover from temporary collisions with a microwave and
>>> whatnot ... just not *that many*, I guess.
>>
>>  From what I can tell so far, my firmware has this sort of logic:
>>
>> frame from stack to the driver
>>    -> send to firmware
>>    -> in firmware, hardware will do up to X retries (maybe 16 or so, need to check)
>>    -> On failure, the firmware may re-queue the packet (firmware-software retry)
>>    -> back to hardware retries (~32 frames on air at this point)
>>    ...
>>    Eventually tx-fail notification is sent back to the driver one way or another.
>>
>> I am thinking it would be best to have the software retry in the firmware
>> disabled.
>>
>> Then, when mac80211 sends a null-data frame, you would see at most about
>> 16 of them on air, every 500ms or so until it recovers or considers the
>> connection lost.
>
> Yes, that seems reasonable. In fact, I'd argue that such software-retry
> should just be disabled completely - it's better to lose the occasional
> frame than to keep using airtime for it forever ...
>
> Toke is probably getting nightmares reading this - sweet dreams ;-)

I fixed the firmware....

Now only 4 retries per frame, but it seems mac80211 is all 5 of its
null-data probes within a few miliseconds.  Is that expected, or should
there be a bit more pause between each of the probe requests to better
weather periodic network glitches?

Thanks,
Ben

>
> johannes
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com