From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 18:06:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1AB416A419 for ; Thu, 24 Jan 2008 18:06:51 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 0FDBA13C45D for ; Thu, 24 Jan 2008 18:06:50 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 31838 invoked from network); 24 Jan 2008 13:01:04 -0500 Received: from pknat1.passkey.com (HELO ?192.168.16.168?) (68.162.198.134) by coruscant.far-far-away.us with SMTP; 24 Jan 2008 13:01:04 -0500 From: Yousif Hassan To: Brooks Davis In-Reply-To: <20080124163634.GA25331@lor.one-eyed-alien.net> References: <1201125022.2106.67.camel@localhost> <20080123222047.GA14264@lor.one-eyed-alien.net> <1201190313.2591.7.camel@localhost> <20080124163634.GA25331@lor.one-eyed-alien.net> Content-Type: text/plain Date: Thu, 24 Jan 2008 13:07:22 -0500 Message-Id: <1201198042.19736.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: network interface monitoring? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2008 18:06:51 -0000 On Thu, 2008-01-24 at 10:36 -0600, Brooks Davis wrote: > On Thu, Jan 24, 2008 at 10:58:33AM -0500, Yousif Hassan wrote: > > Thank you to all who responded. > > > > The suggestion was made to use devd or ifstated. Both sound like > > excellent tools, but I'm currently being tripped up by a core problem - > > both tools rely on the kernel to notify userland of link state changes > > (which makes complete sense!). This is all well and good - but the > > current issue I'm seeing is that the link state doesn't get updated > > without running "ifconfig" again - is this by design? A known "issue?" > > > > An example: > > 1. Unplug network cable from bfe0 > > 2. I run ifconfig > > 3. I see that interface bfe0's status is "no carrier". Good. > > 4. I plug the cable into bfe0 > > 5. Wait... wait... look in /var/log/messages... wait more.. NO STATE > > CHANGE - the longest I've waited was 2 minutes, which is already too > > long > > 6. run "ifconfig" again > > 7. Link state immediately changes, logs to /var/log/messages, devd > > scripts run > > > > Is this a known behavior? It seems like the link state changes should > > happen automatically, without something to "trigger" them. Isn't there > > some kind of poll or interrupt sequence? I'm on 6.3 RC2 (will upgrade > > to 6.3-RELEASE imminently) but can't imagine this code changed? Does > > this work differently/better in 7.0? > > It's known but not well understood and is a driver bug. I was afraid you'd say that. Thanks for the info. I found PR kern/109733: [bge] bge link state issues (regression) which, while referring to a different driver, has some of the same symptoms. In the meantime, I scripted something that calls ifconfig every 30 seconds or so, redirected its output to null, and put it in the background and nice'd it; this seems to do the trick, albeit via a horrid hack. Due to the bug you mentioned, sometimes link state events queue up, too, and get passed to userland at once, which is no kind of fun, but the script still works. Yousif