[CUWiN-Dev] extra dhcpselect 'state' and wedge file format...

[David Young]

On Mon, Aug 07, 2006 at 12:26:14PM -0700, Chase Phillips wrote:
> On 8/1/06, dan blah <dan.blah at gmail.com> wrote:
> >hey all (chase),
> >working at tdv we ran into a issue with the node being plugged into a
> >consumer router running dhcpd by default.  with dhcpselect running as
> >it should, the node set the proper settings to be a gateway node
> >creating a "black hole" (a dy coined phrase) in the network.  with
> >cuwin getting ready to move into non technocrat households this poses
> >a big problem.  dave and i were talking about making a third state for
> >dhcpselect in which the node receives a dhcp lease from a dhcpd but
> >does not immediately set the route as a permanent default.  the node
> >would run a test to ensure the route is good.  if the route does not
> >allow the node to get to the internet dhcpselect would would route
> >packets back through the cuwin network.
> 
> When I wrote dhcpselect, this scenario was originally treated by "not
> doing that."  A quick review of the code agrees it could be solved as
> you and Dave state.  I recall discussion of solving this problem at
> HSLS's layer, too.  It's likely I'm recalling a different problem
> though.. that of advertising Internet-connected-ness to others,
> instead of first knowing one's own Internet-connected-ness via some
> other ISP service.
> 
> I'd be interested in extending dhcpselect to handle these cases, but
> only if my work doesn't walk over Dave's and his work doesn't walk
> over mine.

Mike Earnhart is working on gateway advertisement/selection for Google
SoC, but it should not interfere with your work, which is Internet
gateway discovery.

> The last time dhcpselect went through this sort of change
> it was destabilized for a time.  I'd need a couple of things:
> 
>  * testers to ensure things are working properly

We can arrange that.

>  * a good branch point to work on the code in isolation (perhaps from
> a revision after the
>    last dhcpselect change near a known-stable release)

I think rc3 is on its way.  Branch there, see how it goes.

> How do you suggest we test for Internet-connected-ness?  Ping?  Which
> hosts?  Or check that packets to an address in the public Internet
> address space are routed on our behalf somewhere, not caring about the
> ping results?  I suppose solving this for the 80%-90% case would be a
> massive improvement over the current condition, and ping google.com
> would do enough there.  But any thought you've put toward this problem
> would help, too.

Pinging google.com is fine.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933