Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 May 2007 13:26:44 +0400
From:      Gleb Smirnoff <glebius@FreeBSD.org>
To:        Andre Oppermann <andre@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/netinet tcp_syncache.c
Message-ID:  <20070524092643.GC89017@FreeBSD.org>
In-Reply-To: <4654D011.5040309@freebsd.org>
References:  <200705182113.l4ILD2qb044650@repoman.freebsd.org> <20070521073544.GP89017@FreeBSD.org> <4654D011.5040309@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 24, 2007 at 01:36:49AM +0200, Andre Oppermann wrote:
A>  Yes, these logs can be triggered remotely.  Broken packets and spoofed
A>  packets may cause them.  We're interested in the former.
A> 
A>  I'll do some benchmarks on the impact of the logging and then decide
A>  whether to put it under a sysctl.
A> 
A>  The reason it is unconditionally enabled is to see if non-compliant
A>  TCP stacks are out there that fail the very strong (but fully RFC and
A>  TCP-secure conform) checks.
A> 
A>  W/o logging we have no way of really knowing.  Before we were possibly
A>  accepting stuff we shouldn't have (spoofing and attacks).  Now we may
A>  drop stuff we perhaps should accept anyway.  W/o logging diagnosing a
A>  TCP problem was very difficult and would need a lot cooperation with
A>  the PR submitter, if it was submitted at all.  We normally only got a
A>  report of TCP 'not working'.  Figuring out what went wrong was pretty
A>  much doing iterative shots into the dark and see if something squeaks.
A> 
A>  With logging I want to make things much more obvious and simpler to
A>  diagnose.  Plus we get information in cases (from admins reading the
A>  logs) that were totally lost in the noise or not even attempted to
A>  be debugged.
A> 
A>  For our TCP maintainers (mostly I at the moment) and also 3rd parties
A>  this makes TCP trouble diagnosis much more accessible.  Based on a
A>  log report and the OS name/version of the remote end we can pretty
A>  much tell right away what went wrong.  This saves an order of a
A>  magnitude in debugging and fault analysis time.  From many hours and
A>  email round trips to mere minutes and one or two information requests.

I completely understand that this logging is very important in the
process of refactoring the TCP code. I just think that the performance
impact should be measured before merging this logging to RELENG_6.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070524092643.GC89017>