cvs commit: src/sys/netinet tcp_syncache.c

[Gleb Smirnoff]

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