Date: Fri, 14 Nov 1997 19:42:01 -0600 (CST) From: Alex Nash <nash@Mcs.Net> To: Studded <Studded@dal.net> Cc: FreeBSD Stable List <FreeBSD-Stable@FreeBSD.ORG> Subject: Re: Serious problem with ipfw in 11/10 Snap Message-ID: <Pine.BSF.3.95.971114190153.27651A-100000@Jupiter.Mcs.Net> In-Reply-To: <199711150021.QAA02869@mail.san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Nov 1997, Studded wrote:
> >This code hasn't changed on the 2.2 branch since August 23. The same
> >code that's in 2.2.5 is in the 11/10 snap (that you claim is broken) and
> >the 11/11 snap (that you claim is fixed).
>
> Ok, I'll take your word for that,
It's simple to check for yourself by typing:
ident /usr/src/sys/netinet/ip_fw.[ch] /usr/src/sbin/ipfw/ipfw.c
I get this (2.2.5-stable, last cvs update on November 4th):
$Id: ip_fw.c,v 1.51.2.5 1997/08/23 14:31:52 alex Exp $
$Id: ip_fw.h,v 1.23.2.3 1997/08/21 01:30:23 alex Exp $
$Id: ipfw.c,v 1.34.2.7 1997/08/21 01:30:21 alex Exp $
Alternatively, you can check with cvsweb:
http://www.freebsd.org/cgi-bin/cvsweb
> but I'm still at a loss as to
> how the problem could have occurred. FWIW, I rm -r /usr/obj/* and
> /usr/src/* before I make the world, then ftp the ...-SNAP/src/* tree to
> make sure I've got everything fresh. If you're telling me the code hasn't
> changed, then something else has either changed, or is vulnerable to
> change, since I used the same procedures I always do.
If you have a copy of the CVS tree handy, look at CVSROOT/commitlogs/sys.
I looked for changes on the 2.2 branch between 11/10 and 11/11, and saw:
- APM & BT848 changes (I assume neither apply to your server)
- ep driver fixes (merged from -current)
I'm currently running ipfw with the ep driver before the above fixes, and
everything works fine. Therefore I think we can rule out the ep driver
as fixing whatever problem you saw (assuming you use the ep driver, of
course).
> More detail on the problem in case it's useful.
>
> 1. The rule appeared as 00000 deny ip from any to any
> 2. That rule, and only that rule persisted after a flush.
> 3. IPFW was able to load my usual (well-tested) rc.firewall script just
> fine, but none of the rules in it mattered because the 00000 rule was
> always parsed first.
It shouldn't be possible to generate a rule with #0 since that has a
special meaning to the kernel -- that is, insert this rule after the
highest numbered rule. I looked at the code, but can't see any way that
this could happen.
Just out of curiosity, did you also see the 65535 deny all rule? If
not, it may indicate that ipfw's rules were damaged by a memory overwrite.
This rule's number is set at boot time in the kernel by:
deny.fw_number = (u_short)-1;
Furthermore it is (theoretically) impossible to delete this entry.
If you didn't see this rule, then something very unexpected has happened.
> Please understand, I'm not trying to point the finger of blame at
> anyone. I simply would like to be sure that this problem can't take
> anyone else by surprise.
Fair enough, but please use the resources above and exercise
restraint before saying things like:
"it was definitely a problem with the code"
"This is twice now that we've been bitten in the ass by foolish
mistakes in ipfw"
"if this happens again, he's going to put up a note on the server
for the 40,000 users we get every day apologizing for
the outage, and explaining that they can blame it on FreeBSD."
We're here to help -- but not if you turn 40,000 people against us :)
Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971114190153.27651A-100000>