The fundamental issue here is DHCP is designed for a single network
interface per system and at one time.
Well, that's just not reality.
Folks running multiple interfaces can't effectively use DHCP without
'hacking' it as I had to.
The reason for this is there is no per-port control of what information
DHCP retrieves, and no useful interface for network management tools to
control DHCP clients.
While it may be possible to 'force' DHCP to use multiple configuration
files (-cf option), this isn't integrated in to the standard Debian
networking setup (or any other that I'm aware of).
What I've proposed is one possible solution, so that the network manager
app can properly configure a multi-interface DHCP client system.
I'd be just as happy with any other solution that allows control over
what information DHCP uses when setting up the system. The point here
is there needs to be additional control on a per port basis so you
don't get into the case of ports fighting each other over the
network settings (router) vs the link settings (IP address).
>From my point of view another good solution, and my original idea
(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 <apoll...@debian.org>
> To: eclectic 923 <eclectic...@yahoo.com>; 563...@bugs.debian.org
> Cc: sub...@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.
>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
