From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 18 09:17:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E69716A4B3 for ; Thu, 18 Sep 2003 09:17:40 -0700 (PDT) Received: from safety.net (ns3.safety.net [216.40.201.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3AF743FBF for ; Thu, 18 Sep 2003 09:17:39 -0700 (PDT) (envelope-from les@ns3.safety.net) Received: from ns3.safety.net (localhost [127.0.0.1]) by localhost (8.12.9/8.12.9) with ESMTP id h8IGHYFI013884; Thu, 18 Sep 2003 09:17:34 -0700 Received: (from les@localhost) by ns3.safety.net (8.12.9/8.12.9/Submit) id h8IGHYYa013870; Thu, 18 Sep 2003 09:17:34 -0700 From: Les Biffle Message-Id: <200309181617.h8IGHYYa013870@ns3.safety.net> In-Reply-To: <20030918150311.GG51544@dan.emsphone.com> To: Dan Nelson Date: Thu, 18 Sep 2003 09:17:34 -0700 (MST) X-Mailer: ELM [version 2.4ME+ PL94 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: "freebsd-hackers@FreeBSD. ORG" Subject: Re: TCP information X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2003 16:17:40 -0000 > In the last episode (Sep 18), Terry Lambert said: **snip** > tcpcb is currently 236 bytes though, and I don't imagine adding another > 8 bytes for an unsigned long "dropped packets" counter is going to kill > him. > > Deepak: if you really want stats, try adding a struct tcpstat to tcpcb > and hack all the netinet/tcp* code to update those whenever the global > tcpstat gets updated. We spent a lot of effort doing this for our 3.5-based NAT/firewall products, putting the SEQ/ACK numbers and related re-transission counts in the struct we used for transient connection objects, and logged them when the connection closed. With 10K simultaneous connections active, it added less than 640K of malloc'd memory, so it's not a big hit. We didn't find the statistics we gathered to be meaningful, BTW. Transient errors (congestion and routing loops) were infrequent, and most of what looked like errors turned out to be generated by the stack at the other end (gratuitous back-to-back ACKs and packet retransmission before any possible timeout could occur). For us, a waste of time. If you have more interesting results, please let me know. I figured it would be a great tool. -Les -- Les Biffle CISSP Information Systems Security Consultant (480) 585-4099 les@safety.net http://www.les.biffle.org/ Network Safety, PO Box 14461, Scottsdale, AZ 85267