From owner-freebsd-hackers Mon Oct 27 11:15:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16040 for hackers-outgoing; Mon, 27 Oct 1997 11:15:12 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from verdi.nethelp.no (verdi.nethelp.no [195.1.171.130]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA16031 for ; Mon, 27 Oct 1997 11:15:05 -0800 (PST) (envelope-from sthaug@nethelp.no) From: sthaug@nethelp.no Received: (qmail 6843 invoked by uid 1001); 27 Oct 1997 19:15:00 +0000 (GMT) To: tom@sdf.com Cc: henrich@crh.cl.msu.edu, Don.Lewis@tsc.tdk.com, matt@3am-software.com, mrcpu@cdsnet.net, freebsd-hackers@FreeBSD.ORG Subject: Re: de0 errors In-Reply-To: Your message of "Mon, 27 Oct 1997 09:42:52 -0800 (PST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 27 Oct 1997 20:15:00 +0100 Message-ID: <6841.877979700@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > server. I wish FreeBSD had a top or systat function that showed network > > traffic in K/Sec. > > It does: netstat -I de0 -w Unfortunately, the byte count and the packet count are inconsistent if the interface is in promiscuous mode - in this case it looks like the byte count represents the "normal" traffic adressed directly to the machine, while the packet count represents *all* the traffic that is seen on the interface, whether it is for this machine or not. Here is a snapshot of netstat on a Fast Ethernet interface running nnstat: input (de6) output packets errs bytes packets errs bytes colls 20310 0 93115 0 0 0 0 21645 0 94452 0 0 0 0 21904 0 93558 0 0 0 0 18802 0 93293 0 0 0 0 18643 0 94048 0 0 0 0 18732 0 93220 0 0 0 0 The effect is easily reproducible. Start tcpdump (or similar) to force the interface into promiscuous mode, start netstat -w. Observe the byte and packet counts. Start ttcp between two other machines on the same segment, and watch how the packet count climbs to reflect the heavy ttcp traffic between the other machines, while the byte count doesn't. Steinar Haug, Nethelp consulting, sthaug@nethelp.no