Problem with security log

[Jeremy Chadwick]

On Wed, Oct 13, 2010 at 11:03:36AM +0200, Marcin wrote:
> 2010/10/13 Jeremy Chadwick <freebsd at jdc.parodius.com>:
> > On Tue, Oct 12, 2010 at 10:50:28PM +0200, Marcin wrote:
> >> Hi folks,
> >>
> >> For some time in the file / var / log / security appear illegible entries:
> >> kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0
> >> .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0
> >>
> >> How to get rid of it? Please help...
> >
> > There isn't a 100% reliable way to get rid of this problem.  I've been
> > harping about this for years (sorry to sound like a jerk, but this
> > really is a major problem that keeps coming up and annoys users/admins
> > to no end.  There are solutions -- Linux solved it by implementing a
> > lockless circular ring buffer[1] used by kmsg).
> >
> > The """workaround""" -- which again, does not solve the problem, only
> > decreases the regularity of it happening (and when it does happen, can
> > sometimes decrease how much interspersed output there is) -- is to add
> > the following line to your kernel config and rebuild/reinstall your
> > kernel:
> >
> > options         PRINTF_BUFR_SIZE=128    # Prevent printf output being interspersed.
> >
> > This option became part of the GENERIC kernel configuration file at the
> > following times:
> >
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/GENERIC#rev1.529
> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC#rev1.517
> >
> > Depending on what release/tag you follow, you may or may not find the
> > above commit/change in your GENERIC file.  I can't be bothered to track
> > down what time the CVS tagging was done, for multiple architectures,
> > etc...
> >
> > [1]: http://www.mjmwired.net/kernel/Documentation/trace/ring-buffer-design.txt
> 
> Hi Jeremy,
> I have compiled kernel with this option and unfortunately problem still exist...
> Do you have another idea how can i improve my log file? :)

I was incorrect in my understanding/prognosis, so as Andriy pointed out,
the option won't solve your problem.

It sounds like the only way to solve this issue is to improve/fix the
msgbuf code.  Alternatively, you could consider moving from ipfw to
pf(4) and use pflog(4) / pflogd(8).

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |