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.
> 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)?
Sjoerd
--
It's very inconvenient to be mortal -- you never know when everything may
suddenly stop happening.