From owner-freebsd-stable Sat Nov 15 14:35:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA17452 for stable-outgoing; Sat, 15 Nov 1997 14:35:37 -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 OAA17406 for ; Sat, 15 Nov 1997 14:35:32 -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 QAA17159; Sat, 15 Nov 1997 16:35:31 -0600 (CST) Received: from localhost (nash@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) with SMTP id QAA13642; Sat, 15 Nov 1997 16:35:30 -0600 (CST) Date: Sat, 15 Nov 1997 16:35:30 -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: <199711152131.NAA01650@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 Sat, 15 Nov 1997, Studded wrote: > >If > >not, it may indicate that ipfw's rules were damaged by a memory overwrite. > > I'm not sure what that means. Basically, some piece of ipfw or other kernel code unknowingly stomped on the two bytes of RAM which contained the rule number. The rule should have contained 65535 (as a short), or 0xFFFF, but instead had 0x0000. Another mystery is why a flush would not have eliminated this rule. The flush code removes everything but rule #65535. Do you still have the problem SNAP kernel? If it's configured with 2940 or 53c810 support I'd like to give it a try here. Alex