DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC94820685
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>
 <e3c18a8d-9a58-54c5-9aaa-b778299f527b@candelatech.com>
 <1538032363.14416.2.camel@sipsolutions.net>
 <a409f0b7-5a91-1add-484d-588a554f0cd4@candelatech.com>
 <1538119161.14416.57.camel@sipsolutions.net>
From:   Ben Greear <greearb@candelatech.com>
Message-ID: <da09e014-3335-dc46-0e94-ee7ce3f318e7@candelatech.com>
Date:   Fri, 28 Sep 2018 08:14:45 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1538119161.14416.57.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/28/2018 12:19 AM, Johannes Berg wrote:
> On Thu, 2018-09-27 at 08:32 -0700, Ben Greear wrote:
>
>>> It seems though that if there's some noise or so on the channel you
>>> wouldn't be transmitting, so what kind of "network glitches" might
>>> affect this? AP going away unexpectedly for some time?
>>
>> I am thinking that if the 'timeout' is 500ms, and the number of probes is 2
>> (the default values), then it should probe at 0ms, and at 250ms, and then finally
>> fail at 500ms if nothing was received.  In otherwords, X probes, x/timeout apart.
>
> That seems reasonable I guess. Although I'm not sure - perhaps once we
> know it failed we *do* want to try a bit quicker again? Otherwise we
> have a totally dead period there in the meantime, no?

I don't think the tx path stops just because the mlme decides probes
are timing out, so if AP is really functional, you won't have a dead period.

If it is dead, then the sooner you probe and discover timeout and disconnect,
the sooner you can re-connect to some better AP (assuming one exists).  A
false disconnect due to missing a few probes would be disruptive though, and
probing very often in idle situations would use more airtime, so
of course there is a trade-off.

While watching the sniffer, it seems the initial mlme probe happens about
3 seconds after I admin down the AP, and then disconnect is about 1s after
that (I have my timeout set to 1000ms instead of default 500ms, and I have retry
count set to 5 instead of 2.

Did you see that patch I posted?  It looks good in the sniffer and logs,
as far as I can tell....

Thanks,
Ben

>
> johannes
>

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