Re: How many null-data probes on connection loss?

From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: How many null-data probes on connection loss?
Date: Wed, 26 Sep 2018 11:47:03 -0700	[thread overview]
Message-ID: <7ed031b0-19d9-46db-33d9-082999e5ed22@candelatech.com> (raw)
In-Reply-To: <1537986415.28767.17.camel@sipsolutions.net>

On 09/26/2018 11:26 AM, Johannes Berg wrote:
> On Wed, 2018-09-26 at 11:04 -0700, Ben Greear wrote:
>
>> I have been running with mac80211/mlme.c's max_nullfunc_tries set to 5 for many years.
>> Long ago it helped with connectivity issues with lots of vdevs and and/orloaded APs
>> if I recall correctly.
>
> That's different, that's the number of distinct frames mac80211 will
> send.
>
> I thought you were asking about *retries*.

Well, it retries the probe action 5 times in my case.

I am also asking about total amount of retried frames on the air.

>> In fact, I see 62 frames captured on air all with the same sequence number
>> in the test I just did, and subsequent frames with the next seq-no are sent
>> immediately after the first one.  The frames are all right after each other, so
>> I guess this is probably firmware doing lots of HW retransmits and then *also*
>> doing software retransmits in the firmware (my reading of mlme.c indicates it should
>> only probe every 500ms).
>
> Yes.
>
>> 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.

Thanks,
Ben

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