From owner-freebsd-hackers Tue May 6 19:50:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA25822 for hackers-outgoing; Tue, 6 May 1997 19:50:04 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA25781 for ; Tue, 6 May 1997 19:49:56 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.7.3) id MAA28012; Wed, 7 May 1997 12:53:20 +1000 (EST) Date: Wed, 7 May 1997 12:53:19 +1000 (EST) From: "Daniel O'Callaghan" To: Darren Reed cc: freebsd-hackers@FreeBSD.ORG Subject: Re: divert still broken? In-Reply-To: <199705070243.MAA27969@panda.hilink.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 7 May 1997, Darren Reed wrote: > In some mail from Archie Cobbs, sie said: > > > > Ah, now I see.. remembering that FO is stored in bytes/8 (as you pointed > > out), it's not possible for a UDP header to be split across fragments > > in any way (since it's only 8 bytes long)... correct? > > Tell me, what does ipfw do with a packet that says "more fragments" but > the packet has no data (i.e. _no_ header at all), and is UDP ? Nothing, AFAIK. > Best thing, I think for ipfw to do, is drop any packets where the header(s) > are split across multiple packets (i.e. aren't all in the one you have). With the TCP flags problem you could send complete headers in the first packet, and overwrite the flags in the second. A UDP packet which has no data at all, is an interesting thought, but what use would it be? A follow-up fragment would have to have FO=0, which indicates a new packet. > I don't recall ipfw doing any ICMP filtering to worry about that. Can you elaborate on the dangers a bit, please. I guess it might be a way of tying up kernel resources, by sending lots of fragments which say "more fragments coming", and never send them. Danny