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

[Chase Phillips]

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.  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
  * 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)

Can these be provided?

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.

> chase you wrote dhcpselect, would you be able to take a look at this?
> also, to get around this issue at tdv we need to use the wedge file.
> the wedge file is going to be used to set up a gateway node that has
> no dhcpd on the ethernet line.  chase i was hoping you could send me
> the syntax of that file?

As Bill mentions, the tests are only for the existence of the files.
(Lines 746, 773)

Chase