Re: [RFC V2] cfg80211: introduce critical protocol indication from user-space

[Ben Greear <greearb@candelatech.com>]

On 03/28/2013 04:01 PM, Dan Williams wrote:
> On Thu, 2013-03-28 at 23:44 +0100, Johannes Berg wrote:
>> On Thu, 2013-03-28 at 17:42 -0500, Dan Williams wrote:
>>
>>>> Well, you can do DHCP a second or so, I'd think? And EAPOL much quicker,
>>>> of course. I don't really see any reasonable minimum time? We might want
>>>> to enforce a max though, maybe.
>>>
>>> Not quite.  A lot is dependent on the server itself, and I've had users
>>> on university and corporate networks report it sometimes takes 30 to 60
>>> seconds for the whole DHCP transaction to complete (DISCOVER, REQUEST,
>>> OFFER, ACK).  Sometimes there's a NAK in there if the server doesn't
>>> like your lease, which means you need another round-trip.  So in many
>>> cases, it's a couple round-trips and each of these packets may or may
>>> not get lost in noisy environments.
>>
>> Oh, yes, of course. However, we're talking about optimising the good
>> cases, not the bad ones. Think of it this way: if it goes fast, we
>> shouldn't make it slow by putting things like powersave or similar in
>> the way. If it's slow, then it'll still work, just slower. But when
>> "slower" only means a few hundred milliseconds, it doesn't matter if
>> everything takes forever (30-60 secs)
>
> True, but at least 4 or 5 seconds is the minimum time I'd recommend here
> for DHCP.

Couldn't dhcp just turn off the critical protection as soon as it is done?

Then, you only need to worry about the max time allowed.

Also, you would probably need to enforce in the kernel that only
x out of y time in any given period can be locked, otherwise lots
of different dhclient processes (perhaps erroneously spawned..or
running on lots of different VIFs) could basically disable scanning
or channel changes...

Thanks,
Ben

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