From 6b0c9026c6322f63603f8716a3da2bcf9ca230b6 Mon Sep 17 00:00:00 2001 From: cjc Date: Wed, 1 May 2002 06:29:16 +0000 Subject: Enlighten those who read the FINE POINTS of the documentation a bit more on how ipfw(8) deals with tiny fragments. While we're at it, add a quick log message to even let people know we dropped a packet. (Note that the second FINE POINT is somewhat redundant given the first, but since the code is there, leave the docs for it.) MFC after: 1 day --- sbin/ipfw/ipfw.8 | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) (limited to 'sbin') diff --git a/sbin/ipfw/ipfw.8 b/sbin/ipfw/ipfw.8 index 6966a74..aaaf9dc 100644 --- a/sbin/ipfw/ipfw.8 +++ b/sbin/ipfw/ipfw.8 @@ -1052,9 +1052,20 @@ Don't forget the loopback interface. .Sh FINE POINTS .Bl -bullet .It -There is one kind of packet that the firewall will always -discard, that is a TCP packet's fragment with a fragment offset of -one. +There are circumstances where fragmented datagrams are unconditionally +dropped. +TCP packets are dropped if they do not contain at least 20 bytes of +TCP header, UDP packets are dropped if they do not contain a full 8 +byte UDP header, and ICMP packets are dropped if they do not contain +4 bytes of ICMP header, enough to specify the ICMP type, code, and +checksum. +These packets are simply logged as +.Dq pullup failed +since there may not be enough good data in the packet to produce a +meaningful log entry. +.It +Another type of packet is unconditionally dropped, a TCP packet with a +fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls. When logging is enabled, these packets are -- cgit v1.1