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