From owner-freebsd-current@FreeBSD.ORG Thu Sep 8 20:09:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C319716A41F for ; Thu, 8 Sep 2005 20:09:54 +0000 (GMT) (envelope-from lerik@nolink.net) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0D2A43D4C for ; Thu, 8 Sep 2005 20:09:53 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 66346 invoked by uid 1000); 8 Sep 2005 20:09:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Sep 2005 20:09:50 -0000 Date: Thu, 8 Sep 2005 22:09:50 +0200 (CEST) From: Lars Erik Gullerud To: Brooks Davis In-Reply-To: <20050907194130.GA2436@odin.ac.hmc.edu> Message-ID: <20050908220217.X64137@electra.nolink.net> References: <20050901225346.0923E16A41F@hub.freebsd.org> <200509021003.39863.incmc@gmx.de> <20050902164957.GA22097@odin.ac.hmc.edu> <200509072128.04819.incmc@gmx.de> <20050907194130.GA2436@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2005 20:09:54 -0000 On Wed, 7 Sep 2005, Brooks Davis wrote: > I think I see what's going on. Your arp cache is posioning your routing > table. Try doing an "arp -a -d" after flushing the routes and before > inserting the nic. It looks like we should add support to the arp(8) > command so -i can be used with -d and consider flushing cache entries > realted to an interface when it goes down. Uhm, so are you saying ARP cache entries for a given interface is NOT flushed today when an interface goes down? If that is the case, then it should definitely be more than "considered". If an interface goes down then up the old ARP cache entries should _never_ "reappear" - how do you even know you are still on the same physical network you were before you brought the interface down? Bringing an interface down then back up is usually one of the "try this first" operations when troubleshooting all platforms I normally work on, exactly because it _does_ (normally) clear a lot of state info that you don't want around to confuse you (like the ARP cache and routing table entries). /leg