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

[Johannes Berg <johannes@sipsolutions.net>]

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 ;-)

johannes