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

[Dan Williams <dcbw redhat com>]

On Tue, 2008-08-05 at 19:52 +0100, Sjoerd Simons wrote:
> On Tue, Aug 05, 2008 at 02:05:51PM -0400, Dan Williams wrote:
> > On Tue, 2008-08-05 at 18:10 +0100, Sjoerd Simons wrote: 
> > > > 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.
> 
> Well hopefully the mesh code will become less OLPC specific soon. As
> mesh-support is now in the mainline linux kernel and should work with all
> mac80211s devices. But indeed this change is indeed a tad specific to the OLPC
> usecase.
> 
> > 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.
> 
> Just because you can set the property in the D-Bus interface doesn't mean you
> have to :) But yeah, i'll rewrite this to not expose the dhcp timeout setting
> in the general ip4 config properties.
> 
> What are your feelings about the anycast property, as it's probably even more
> specific to OLPC?

My feeling is that anycast should stay specific to the OLPC case, since
it's an OLPC implementation detail.  We can put some stuff internally to
make anycast and the 'initial-interval' stuff easier for the OLPC mesh
device, but I don't think we need to expose it.

Maybe the better approach here is to create an "olpc-mesh" setting type
which would be used in the NMSettingConnection's ->type field.  This
type would only be valid when used with the OLPC mesh device class and
when NM saw this connection type in a connection, it would know to
activate the mesh device if needed.

Thus, you could add some OLPC specific stuff like anycast address, and
whether to start MPP on that particular connection or not to the
setting.  I'm not sure what the implications of having two separate
connections here are (one for the 802.11 wifi device and one for the
mesh device) and how they'd interact, but this approach might work.

The real logic in the OLPC NM builds was to do the handoffs between the
WiFi and mesh interfaces, but they each had their own individual
configuration in the end.  Since each NMConnection provides individual
configuration that might be a way to go with this.

So what actual mesh-specific tunables (besides anycast address) would
you anticipate needing?

Dan