Date: Wed, 07 Feb 2001 10:36:56 -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, phk@FreeBSD.ORG, dwmalone@FreeBSD.ORG Subject: Re: Solved: Bridging and dummynet seems to destroy dmesg output Message-ID: <3A814168.533ADAFC@jonny.eng.br> References: <200101312212.f0VMCHj08290@iguana.aciri.org> <3A79B707.3DF0B6D@jonny.eng.br> <20010207142853.A30058@outblaze.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Yusuf,
As described by cvsweb, the patches to IPFW did not change the behavior
with log messages. To be more exactly, either netinet/ip_fw.c either
kern/subr_prf.c should be changed to match each other. In my local setup I
use a patch script after cvsup to fix ip_fw.c, removing all instances of
"LOG_SECURITY |".
Luigi/Poul, have you at least decided where the changes should be made?
There's no log(9) man page to decide which one is the correct syntax. IMHO,
-stable is not stable while this bug persists.
Yusuf Goolamabbas wrote:
>
> Hi, I cvsupped today and got all of Luigi's commit [the one where he
> does 1.16.2.13 of bridge.c alongwith a few others], I also have David
> Malone's fix to syslogd.c [1.59.2.5]
>
> If I don't have the following sysctl
>
> net.inet.ip.fw.verbose_limit=10
>
> then dmesg gets busted as mentioned earlier and if I do a sync;reboot
> then I get a huge amount of ipfw messages scrolling on the console [It's
> as if they were backlogged in some buffer somewhere] and after a few
> seconds the syncing disk messages comes along
>
> I have the following in my kernel config
>
> options IPFIREWALL
> options IPFIREWALL_DEFAULT_TO_ACCEPT
> options BRIDGE
> options DUMMYNET
>
> my /etc/sysctl.conf is as follows
>
> net.link.ether.bridge_ipfw=1
> net.link.ether.bridge=1
> net.inet.ip.fw.verbose=1
> net.inet.ip.fw.verbose_limit=10
>
> > Luigi Rizzo wrote:
> > >
> > > > I tried only removing DUMMYNET from config, and the bug continues. Should
> > > > I try the changes below?
> > >
> > > no-they only affect dummynet. But this seems to suggest that
> > > the problem is unrelated to my changes...
> > >
> > > cheers
> > > luigi
> >
> > Hi,
> >
> > I found the problem!
> >
> > I started searching for the point where ipfw writes to the msgbuf, and
> > like all other kernel modules, it uses the log(9) function. But differently
> > from the other modules, ip_fw.c uses a LOG_SECURITY argument. I removed it,
> > recompiled, reboot, and BINGO! Probably the log(9) function does not expect a
> > facility parameter, as it is assumed to be LOG_KERNEL.
> >
> > Searching the cvsweb tree, I assume the changes that made it fail were
> > made to kern/subr_prf.c, and not directly to netinet/ip_fw.c. Probably a
> > longer search should be made to detect if any other call to log(9) uses this
> > approach. (CC: to phk, who made the change to kern/subr_prf.c, 1.61.2.1, at
> > 2000.01.16)
> >
> > Hoping this is the final solution and waiting for the cvs commit, thanks
> > to everybody,
> >
> > Jonny
> >
> > --
> > João Carlos Mendes Luís jonny@embratel.net.br
> > Networking Engineer jonny@jonny.eng.br
> > Internet via Embratel jcml@ieee.org
>
> --
> Yusuf Goolamabbas
> yusufg@outblaze.com
--
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-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A814168.533ADAFC>