From owner-freebsd-current@FreeBSD.ORG Fri Sep 9 09:24:00 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 C503316A41F for ; Fri, 9 Sep 2005 09:24:00 +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 ECBAD43D45 for ; Fri, 9 Sep 2005 09:23:59 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 45471 invoked by uid 1000); 9 Sep 2005 09:23:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Sep 2005 09:23:53 -0000 Date: Fri, 9 Sep 2005 11:23:53 +0200 (CEST) From: Lars Erik Gullerud To: Jon Dama In-Reply-To: Message-ID: <20050909111927.I31154@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> <20050908220217.X64137@electra.nolink.net> 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: Fri, 09 Sep 2005 09:24:00 -0000 On Thu, 8 Sep 2005, Jon Dama wrote: > >> 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). > > Yes but surely you'd recognize a difference between a link state change > and issuing ifconfig ... down > > In the latter case, I expect state to be flushed. In the former, I expect > everything to resume when the link is restored. Imagine having to > manually reinit your interfaces just because some joker temporary > unplugged your ethernet cable! No, quite the opposite - a link state change is is when you REALLY want state (particularly ARP) to be flushed. If someone unplugs your ethernet cable, and the link subsequently returns, you have no way of knowing you are on the _same network segment_. You may plug out your cable and plug it into a different network, in which case you do NOT want old ARP entries to remain. I.e. the new network may use the same IP addressing, but obviously ARP will point to different macs - in which case you will get no traffic because your host will not re-ARP IP-addresses for which it already has a cache entry. ARP cache should _always_ flush on link state change. /leg