Sat Jul 3 11:09:00 UTC 2010
(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
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
----- 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
> 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
> From the sounds of your bug report, the default route is coming from another
> source than DHCP.
More information about the pkg-dhcp-devel