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

[Chase Phillips]

Dan,

The best way to handle static routes on any interface (wired or not)
would be to wedge the interface into a manual mode in dhcpselect and
give it the ifconfig and route commands to run on your behalf (perhaps
by reading the commands from the wedge file).  Once the interface is
raised, dhcpselect could check for a Net connection on that interface
using the same code I wish to add and configure routing appropriately.

I will presume a third state for dhclient-based interfaces is not
necessary atm and that I can check for a gateway the instant the
interface is bound.  Unless there are objections, I will land my patch
on the trunk.  If it tests fine there, I'll land it on the 0.7.0
branch.

Chase

On 8/8/06, dan blah <dan.blah at gmail.com> wrote:
> we have two networks now that are going to require the gateways have
> static network information on the wired interface to get out to the
> internet (nodes being plugged into border routers and other such
> situations).  i am assuming as cuwin networks become more popular we
> will see more situations like this.
>
> i am not for sure the best solution for this problem except maybe
> turning dhcpselect off on boot?
>
> On 8/8/06, Chase Phillips <ch at se.tl> wrote:
> > 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
> > >
> >
>
>
> --
> Daniel
>