Date: Thu, 8 Sep 2005 15:22:32 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: Jon Dama <jd@ugcs.caltech.edu> Cc: Jochen Gensch <incmc@gmx.de>, freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) Message-ID: <20050908222232.GA12398@odin.ac.hmc.edu> In-Reply-To: <Pine.LNX.4.53.0509081509110.18161@ngwee.ugcs.caltech.edu> References: <20050901225346.0923E16A41F@hub.freebsd.org> <200509072128.04819.incmc@gmx.de> <20050907194130.GA2436@odin.ac.hmc.edu> <200509072223.20560.incmc@gmx.de> <20050907211811.GA19570@odin.ac.hmc.edu> <Pine.LNX.4.53.0509081426360.18161@ngwee.ugcs.caltech.edu> <20050908214834.GA8000@odin.ac.hmc.edu> <Pine.LNX.4.53.0509081509110.18161@ngwee.ugcs.caltech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 08, 2005 at 03:13:07PM -0700, Jon Dama wrote: >=20 >=20 > > > > > And whenever there is a wireless network available (where the sys= tem can log > > > > > in an get a network connection) the default route should be switc= hed to that > > > > > wireless nic. Or even better, if both connections work, automatic= ally choose > > > > > the faster one :-). > > > > > > > > That's the goal we're headed towards. Unfortunatly, it's not an in= stant > > > > thing, particularly when people trying things like what you're doing > > > > that don't map well into the old world view of static devices that = don't > > > > change networks. The old model is wrong and has been so for quite = some > > > > time, but that doesn't mean there aren't assumptions related to it = all > > > > over the place. > > > > > > Again, the problem is with the routing code. You should NOT need to = be > > > deleting default routes simply because one link goes down and another > > > comes up on a different interface. > > > > > > Deleting the route simply because the interface went down is a hack. > > > > Got a new routing implemention handy? Until then, well have to live > > with hacks. :( >=20 > True enough. I think the general idea is that you need a two layer > routing table. One that keeps tract of what is possible, and one that > keeps track of what is happening w.r.t existing flows. Once an interface > link goes down, the route in the second table invaliadates and you go back > to the first to find a new route. >=20 > afaik, this is what is done in SunOS, on cisco hardware... MS might do it > too, certainly their handling of default routes meshes well with the > wireless world. I believe andre implied that we would be close to the desired state after his current round of work. If so, that will be great because all sorts of problems just go away if we can have multiple routes to the same network(s) and select the right one via appropriate metrics. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDILmnXY6L6fI4GtQRAkB6AJ9hYcZ77vCeIMZCadpPYEdoWxeSswCePKOc 6BL53IElNme3hILoK11utSo= =iEu5 -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050908222232.GA12398>