From owner-freebsd-stable Fri Nov 14 17:42:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20400 for stable-outgoing; Fri, 14 Nov 1997 17:42:08 -0800 (PST) (envelope-from owner-freebsd-stable) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20393 for ; Fri, 14 Nov 1997 17:42:06 -0800 (PST) (envelope-from nash@Jupiter.Mcs.Net) Received: from Jupiter.Mcs.Net (nash@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id TAA04359; Fri, 14 Nov 1997 19:42:02 -0600 (CST) Received: from localhost (nash@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) with SMTP id TAA28584; Fri, 14 Nov 1997 19:42:01 -0600 (CST) Date: Fri, 14 Nov 1997 19:42:01 -0600 (CST) From: Alex Nash Reply-To: Alex Nash To: Studded cc: FreeBSD Stable List Subject: Re: Serious problem with ipfw in 11/10 Snap In-Reply-To: <199711150021.QAA02869@mail.san.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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