Date: Thu, 24 May 2007 01:36:49 +0200 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@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: <4654D011.5040309@freebsd.org> In-Reply-To: <20070521073544.GP89017@FreeBSD.org> References: <200705182113.l4ILD2qb044650@repoman.freebsd.org> <20070521073544.GP89017@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4654D011.5040309>