No subject

(before I realized deep diving into DHCP was more than I wanted to do)
was to have dhclient *automatically* use per port dhclient-eth0.conf,
dhclient-eth1.conf... configurations when present, otherwise use
the default configuration. This implies that if the information isn't
explicitly asked for, but sent anyway that the dhclient-script wouldn't be
passed the excluded values. This would preserve the default behavior, and
provide the configuration flexibility needed to deal with multi-interface
systems.

If necessary it would be easy to dynamically generate these DHCP client
configurations from the network manager to meet a wide variety of needs,
in much the same fashion that my patch configured DHCP to do what I needed.

Let's find a solution, any solution, rather than leaving this problem
to continue.







----- Original Message ----
> From: Andrew Pollock <apollock at debian.org>
> To: eclectic 923 <eclectic923 at yahoo.com>; 563677 at bugs.debian.org
> Cc: submit at bugs.debian.org
> Sent: Sun, July 11, 2010 8:10:57 PM
> Subject: Re: Bug#563677: dhcp3-client: dhclient should not override default 
>routing
> 
> On Mon, Jan 04, 2010 at 06:51:31AM -0800, eclectic 923 wrote:
> > Package:  dhcp3-client
> > Version: 3.1.1-6+lenny3
> > Severity: important
> > 
> > *** Please type your report below this line ***
> > 
> > As I  watched the various wireless security protocols get cracked,
> > I decided  to give up on wireless security, there's a better and
> > simpler solution,  openvpn. It takes a whole lot less work to set up
> >  openvpn-client/openvpn-server than a supplicant/radius-hostap (which I
> >  used to use with TKIP/AES settings). Not to mention, remote access and
> >  wireless access management is consolidated into one place
> >  (openvpn-server) vs the radius and openvpn-servers.
> > 
> > When my  system connects to a wireless router, it runs a dhclient to set
> > up the  wireless interface wlan0.  Openvpn supplies my real connection thru
> >  the tap0 virtual network device. The firewall is set up to only allow  dhcp
> > traffic and openvpn traffic on the wireless link (wlan0). This also  has the
> > added virtue of allowing me to use any of several wireless  routers, yet
> > always have the same network IP address as the wired  network connection,
> > thereby eliminating the need for a dynamic dns  server.
> > 
> > When using this set up, after initial connection, the  default route is
> > switched to the openvpn tap0 device (aka default route  moves from wlan0
> > to tap0).
> > 
> > The problem is that  /sbin/dhclient-script has some 'naughty' code in it.
> > 
> >  Specifically, under BOUND|RENEW|REBIND|REBOOT) and TIMEOUT) one finds:
> > 
> >         for router in $new_routers;  do
> >                 route add  default dev $interface gw $router $metric_arg
> >          done
> > 
> > The problem with this, is that the default route is  *unconditionally*
> > set. Which is why the system gets two default routes  in the routing table,
> > and stops working.
> > 
> > There needs to  be a check added to make sure that the default route isn't
> > already set.  If the default route is set, then the naughty code should
> > NOT be run.  Something along the lines of:
> 
> I've been giving this some more  thought.
> 
> Wouldn't your problem be just as easily addressed by not  requesting the
> default route (i.e. removing routers from the request  directive in
> dhclient.conf)?
> 
> From the sounds of your bug report, the  default route is coming from another
> source than DHCP.
>