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

[Chase Phillips]

Unless there's a reason to want dhcpselect to *wait* before it tries
testing for a net connection once the dhclient-bound interface becomes
available, this could be a relatively simple addition.

We could, upon receiving the bound notification from dhclient, test
the bound interface for a net connection.  If ping exits successfully,
only then net-connect the interface.  (Rather than net-connecting it
no matter what when we receive the bound notification.)

Was there a reason you and Dave wanted a third state beyond dhcpd and
dhclient, or more specifically, a reason the third state needs to be
explicitly called out in the code, rather than just an abstraction of
a corner case?  If there's not a good reason to make a third state,
I'd rather not, as that's the kind of change to dhcpselect that can
cause disruptions.

Chase

On 8/7/06, dan blah <dan.blah at gmail.com> wrote:
> On 8/7/06, Chase Phillips <ch at se.tl> 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.  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?
> >
>
> i can do testing for you here on a local test bed as well as set you
> up with access to the test bed if you wish.  if we are wanting to
> include the new dhcpselect functionality in 0.7.0 the latest know
> stable revision is 4074 (0.7.0-RC1).
>
> > 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)
>
> great, thanks bill and chase.
>
> >
> > Chase
> >
>
>
> --
> Daniel
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
>