Date: Wed, 7 May 1997 12:53:19 +1000 (EST) From: "Daniel O'Callaghan" <danny@panda.hilink.com.au> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: divert still broken? Message-ID: <Pine.BSF.3.91.970507124619.4479y-100000@panda.hilink.com.au> In-Reply-To: <199705070243.MAA27969@panda.hilink.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970507124619.4479y-100000>