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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
