From owner-freebsd-bugs Thu Jul 6 00:28:40 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA08763 for bugs-outgoing; Thu, 6 Jul 1995 00:28:40 -0700 Received: from mpp.com (mpp.Minn.Net [204.157.201.242]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA08756 for ; Thu, 6 Jul 1995 00:28:38 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id CAA03114; Thu, 6 Jul 1995 02:28:31 -0500 From: Mike Pritchard Message-Id: <199507060728.CAA03114@mpp.com> Subject: Re: ipfw 'reject' panics the system To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 6 Jul 1995 02:28:30 -0500 (CDT) Cc: bugs@freebsd.org In-Reply-To: <95Jul5.224325pdt.49860@crevenia.parc.xerox.com> from "Bill Fenner" at Jul 5, 95 10:43:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1747 Sender: bugs-owner@freebsd.org Precedence: bulk > I took a glance at the firewall stuff when Michael Butler posted his most > recent message saying that using the firewall reject code will panic the > machine when a rejected packet comes in. It turns out that the firewall > code uses dtom(ip) on a rejected packet, but it's entirely possible that > the packet is in a cluster mbuf, on which dtom() doesn't work. I fixed > the code to pass the original mbuf along with the ip pointer, and Michael > said his panics went away. > > Can someone (review and) commit these diffs? > > Thanks, > > Bill > >...patches deleted... >From my 5 minute look at this, this is a non-problem, but feel free to tell me otherwise! I suspect that the orginal poster got an intermediate copy that was still causing problem. His test case was somewhat simple, and with the -current version, my kernel has no problems with rejected packets, even with his test case, and a few of my own. I could always be wrong, too :-(. I build a -current kernel daily, and just rebooted it about 4 hours ago specificaly to test to ipfw code, so I'm reasonably sure that it is working. After a quick look, it seems like dtom() should do the right thing, since the ipfw code is passed a pointer from mtod(), which should be the reverse of dtom(). If it isn't, then we probably have bigger things to worry about. If we have problems with freeing individual mbufs that are part of mbuf clusters, then I would expect to see out of memory problems/many more problems. Again, this may be the case, but on my setup is isn't. Unfortunately, my networking setup isn't the best. Just a PPP link to the outside world. -- Mike Pritchard mpp@legarto.minn.net "Go that way. Really fast. If something gets in your way, turn"