From owner-freebsd-net Fri Apr 5 15:45:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id D1C2737B41A; Fri, 5 Apr 2002 15:45:24 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 3349A4CE17; Fri, 5 Apr 2002 18:45:24 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA22711; Fri, 5 Apr 2002 18:45:23 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA21989; Fri, 5 Apr 2002 15:45:23 -0800 (PST) Message-Id: <200204052345.PAA21989@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bmah@FreeBSD.ORG Subject: Re: IP fragmentation (was Re: Fatal trap 12: page fault while in kernel mode) Cc: net@FreeBSD.ORG References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org> <15533.46222.49598.958821@grasshopper.cs.duke.edu> <3CADE0E7.ED472650@mindspring.com> <15533.57961.725030.692387@grasshopper.cs.duke.edu> <200204052120.g35LKW00034174@intruder.bmah.org> Date: Fri, 5 Apr 2002 15:45:22 -0800 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >The only difference I can see is that in ip_input(), if nipq > maxnipq, >all of the fragments for some other packet in the current hash bucket >get dropped (with the wonderfully descriptive comment "gak"). The best thing to do is to drop the oldest frag queue; that's obviously non-trivial with the current data structures. The problem with the ip_nfragments code is that if space becomes available in the middle of reception of an entire packet, a queue will be created to reassemble a packet that will never completely arrive (since we dropped some of the beginning of it due to no space). I guess the nipq code has a similar problem: it will gladly free a queue that contains fragments that go with the next fragment that arrives. In fact, if datagrams that hash to the same bucket arrive with interleaved fragments, the nipq code could thrash between the two packets, creating and deleting a frag queue for each fragment arrival, dropping both datagrams. To address this kind of problem, it might be worth creating a "drop" frag queue entry, which is a way to remember that we dropped fragments from a given datagram so we should drop all the other fragments too. (I'd also go for modifying the data structures to make it easy to drop the oldest frag queue.) Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message