From owner-cvs-src@FreeBSD.ORG Wed May 23 23:36:46 2007 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 975C616A468 for ; Wed, 23 May 2007 23:36:46 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7B213C43E for ; Wed, 23 May 2007 23:36:45 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 55263 invoked from network); 23 May 2007 22:53:58 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 May 2007 22:53:58 -0000 Message-ID: <4654D011.5040309@freebsd.org> Date: Thu, 24 May 2007 01:36:49 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gleb Smirnoff References: <200705182113.l4ILD2qb044650@repoman.freebsd.org> <20070521073544.GP89017@FreeBSD.org> In-Reply-To: <20070521073544.GP89017@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2007 23:36:46 -0000 Gleb Smirnoff wrote: > On Fri, May 18, 2007 at 09:13:01PM +0000, Andre Oppermann wrote: > A> andre 2007-05-18 21:13:01 UTC > A> > A> FreeBSD src repository > A> > A> Modified files: > A> sys/netinet tcp_syncache.c > A> Log: > A> o Add syslog logging under LOG_DEBUG to various failures caused by > A> bogus segments > > Can these events be triggered remotely? Of course, we do not log the > debug level to the file, but just passing the message from the kernel > to syslogd daemon will cause an additional load, that can be provoked > remotely. Yes, these logs can be triggered remotely. Broken packets and spoofed packets may cause them. We're interested in the former. I'll do some benchmarks on the impact of the logging and then decide whether to put it under a sysctl. The reason it is unconditionally enabled is to see if non-compliant TCP stacks are out there that fail the very strong (but fully RFC and TCP-secure conform) checks. W/o logging we have no way of really knowing. Before we were possibly accepting stuff we shouldn't have (spoofing and attacks). Now we may drop stuff we perhaps should accept anyway. W/o logging diagnosing a TCP problem was very difficult and would need a lot cooperation with the PR submitter, if it was submitted at all. We normally only got a report of TCP 'not working'. Figuring out what went wrong was pretty much doing iterative shots into the dark and see if something squeaks. With logging I want to make things much more obvious and simpler to diagnose. Plus we get information in cases (from admins reading the logs) that were totally lost in the noise or not even attempted to be debugged. For our TCP maintainers (mostly I at the moment) and also 3rd parties this makes TCP trouble diagnosis much more accessible. Based on a log report and the OS name/version of the remote end we can pretty much tell right away what went wrong. This saves an order of a magnitude in debugging and fault analysis time. From many hours and email round trips to mere minutes and one or two information requests. -- Andre