Date: Tue, 17 Mar 2009 15:39:45 -0700 From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov <dima_bsd@inbox.lv>, Alex Dupre <ale@FreeBSD.org> Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? Message-ID: <49C026B1.8010108@elischer.org> In-Reply-To: <20090317223511.GB95451@onelab2.iet.unipi.it> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote: >> Luigi Rizzo wrote: >>> Thinking more about it, i believe that calling reass as an explicit >>> firewall action is useless, because if ip_reass fails due to lack of >>> all fragments you are back to square one: >>> what do I do with this fragment ? >>> >> AFAIK ip_reass() never fails: if it's the last fragment it reassembles >> the packet and return it, else it queues the fragment for later >> reassembly. > > Ok then we may have a plan: > > you could do is implement REASS as an action (not as a microinstruction), > with the following behaviour: > > - if the packet is a complete one, the rule behaves as a "count" > (i.e. the firewall continues with the next rule); > > - if the packet is a fragment and can be reassembled, the rule > behaves as a "count" and the mbuf is replaced with the full packet; > > - if the packet is a fragment and cannot be reassembled, the > rule behaves as a "drop" (i.e. processing stops) > and the packet is swallowed by ipfw. > > This seems a useful behaviour, but it must be documented very > clearly because it is not completely intuitive. Perhaps we should > find a more descriptive name. So what is the behaviour when you reassemble a 5K packet, and then it has to be forwarded out another interface with 1500 MTU. > > Good progress! > > cheers > luigi > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49C026B1.8010108>