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

Reply via email to