Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 01 Feb 2001 10:28:16 -0200
From:      Joao Carlos Mendes Luis <jonny@jonny.eng.br>
To:        Yusuf Goolamabbas <yusufg@outblaze.com>
Cc:        Luigi Rizzo <rizzo@aciri.org>, freebsd-net@FreeBSD.ORG, freebsd-stable@freebsd.org
Subject:   Re: Bridging and dummynet seems to destroy dmesg output
Message-ID:  <3A795660.687791E6@jonny.eng.br>
References:  <3A787124.B307EC20@jonny.eng.br> <200101312012.f0VKCGB07532@iguana.aciri.org> <20010201135551.A13446@outblaze.com>

next in thread | previous in thread | raw e-mail | index | archive | help
CC: -stable, this seens not to be a -net related problem.

Yusuf Goolamabbas wrote:
> > > Hi,
> > >
> > >     I sent these files in private.  But I remembered that I have another
> > > unusual config in this machine: is is multiprocessed, and has 10 SCSI disks
> > > and lots of SYSV shared memory.
> >
> > i think SMP might have something to do with it. Yusuf, are you also
> > using an SMP box ?
> 
> No, I am using a "book-PC" type machine [small Celeron] dmesg attached
> 
> I reinstalled my shaper box with 4.2 release today and cvsuped to
> 4.2-stable.
> 
> The strange thing is that if I turn on verbose logging (via sysctl) but
> don't turn on verbose_limit, dmesg seems to get corrupted. If I have
> verbose_limit set to say 10, dmesg works and does not get overridden
> with log messages from ipfw [which goes to /var/log/security]
> 
> This is what I have in my /etc/sysctl.conf
> 
> net.link.ether.bridge_ipfw=1
> net.link.ether.bridge=1
> net.inet.ip.fw.verbose=1
> net.inet.ip.fw.verbose_limit=10
> 
> So, it seems some combination of verbose logging and non setting of
> verbose limit [or the default setting of verbose limit] is causing this
> problem

    Indeed, the problem does not start at the very first message.  It takes
some time, after I start the nmap attack, to corrupt the buffer.  You
observation may just mean that the number of messages needed to corrupt the
buffer is greater than 10.  Maybe even this is the reason Luigi does not see
any problem with picobsd.

    The fact that GENERIC also shows this problem is banging on my head.  Why
nobody else has seen this?  What kind of kernel messages create this problem? 
IIRC IPFW does not use any kind of printf, just log(9).  What other kernels
modules use this function?  How could we generate such messages to test?

    Just in case nobody has yet noticed, this is for sure a case of lost
pointer.  And if the kernel is not yet crashing is just mere luck!  Time to
audit changes since -release?

    I'd love to help more, but I've been far from FreeBSD cvs lists for a long
time now.

                                        Jonny

-- 
João Carlos Mendes Luís                 jonny@embratel.net.br
  Networking Engineer                   jonny@jonny.eng.br
 Internet via Embratel			jcml@ieee.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A795660.687791E6>