Re: Default route doesn't change to wireless device (ath0)

From: Jon Dama (jd_at_ugcs.caltech.edu)
Date: 09/09/05

  • Next message: Kris Kennaway: "Re: [Panic] 6b3 + mdconfig -t malloc + unionfs + screeen" 
    Date: Thu, 8 Sep 2005 15:13:07 -0700 (PDT)
To: Brooks Davis <brooks@one-eyed-alien.net>

    > > > > And whenever there is a wireless network available (where the system can log
    > > > > in an get a network connection) the default route should be switched to that
    > > > > wireless nic. Or even better, if both connections work, automatically choose
    > > > > the faster one :-).
    > > >
    > > > That's the goal we're headed towards. Unfortunatly, it's not an instant
    > > > 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. :(

    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.

    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.

    Some discussion of this on the dragonfly lists a while back. I don't know
    if anything became of it:

    http://leaf.dragonflybsd.org/mailarchive/kernel/2003-10/msg00079.html

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Kris Kennaway: "Re: [Panic] 6b3 + mdconfig -t malloc + unionfs + screeen"

    Relevant Pages

    • Re: DECWindows SET/DISPLAY & CREATE/TERM/DETACH problem on Alphaserver DS10L
      ... So we have a default route. ... Maybe what is happening is that because of the way routing is setup the ... DHCP client failed to configure interface WE1 ... INTERnet ACP Created INTERnet interface: ...
      (comp.os.vms)
    • Re: tun0 not responding to ping
      ... IP as the address of its public interface (192.168.0.2 in this ... This causes FreeBSD to have routing problems, ... default route. ... vpnc does seem to be establishing the VPN ...
      (freebsd-net)
    • Re: Generate traffic with only one machine - whats wrong with this routing?
      ... external interface even if the IP address is assigned to interface ... ip route del local 10.0.1.11 table local ... seems like an sytax error in the routing tables. ... the packets are sent out on the other interface eth2 as the "From ...
      (comp.os.linux.networking)
    • Re: tun0 not responding to ping
      ... IP as the address of its public interface (192.168.0.2 in this ... This causes FreeBSD to have routing problems, ... default route. ... vpnc does seem to be establishing the VPN ...
      (freebsd-net)
    • RE: More help needed please
      ... Each interface is isolated from the other for security reasons. ... If so the use a client machine and set it's route to the f/w ... > routing table leading me to claim that it may be a bug. ... Both nics are set to come up at ...
      (RedHat)