Re: [PATCH] Add dhcp timeout and anycast config options

[Dan Williams <dcbw redhat com>]

On Tue, 2008-08-05 at 18:10 +0100, Sjoerd Simons wrote: 
> On Mon, Aug 04, 2008 at 06:30:35PM -0400, Dan Williams wrote:
> > On Mon, 2008-08-04 at 12:28 +0100, Sjoerd Simons wrote:
> > > Add configuration options for apply a dhcp timeout and using DHCP using
> > > anycast instead of broadcast.
> > 
> > So; does the DHCP timeout change for the mesh devices at all in the new
> > scheme?  At what points might the DHCP timeout be something other than
> > the max or the min? 
> 
> I'm not sure what you mean with max and min here. But the olpc connection
> algorithm is afaik to basically try out the three ``standard'' mesh frequencies
> one by one using dhcp to see if there is a school server around. In this case
> the 45 second timeout is a bit long. Which is why the possibility to set a
> smaller timeout is desirable.

Right; I had hardcoded it to 20s on the nm-0-6-olpc branch.  Since that
value doesn't really need to be changed by the user on per-connection
basis, it doesn't need to be part of the IP4 setting at all.  I was
referring to the bits in the patch that modify nm-setting-ip4-config.c
in verify() and also the GObject property.

> > I'd rather not have configurable DHCP timeouts in this manner because for
> > non-mesh cases, the DHCP timeout never needs to change.  If we can set the
> > DHCP timeout for mesh operations in the activation request like the old code
> > did, that would be preferable.
> 
> I guess i could do that. But that would mean mixing device configuration and ip
> configuration for mesh devices, which doesn't seem the right way to me. I don't
> really see any harm in exposing this functionality for all devices (although
> maybe we should clamp it to a certain min and max value)?

Well, the mesh code is specific for OLPC, and the DHCP timeouts there
were tuned to the specific mesh cases and behavior that we had with
OLPC.

Furthermore, DHCP timeouts shouldn't need to be changed in general
anyway.  People always try to get the DHCP timeout raised for wireless
stuff, but the fact is that if you're not connected in 45 seconds, the
driver has a bug, your key is wrong, or you're waaay out of range.
There is no good reason to allow user-configurable DHCP timeouts at this
point.

Just because the option can be tweaked doesn't mean it should in 99% of
cases.

Dan