From owner-freebsd-doc@FreeBSD.ORG Sun Nov 30 05:50:23 2003 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE7AE16A4CE for ; Sun, 30 Nov 2003 05:50:22 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C75C243FE3 for ; Sun, 30 Nov 2003 05:50:20 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAUDoKFY065392 for ; Sun, 30 Nov 2003 05:50:20 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAUDoKB2065391; Sun, 30 Nov 2003 05:50:20 -0800 (PST) (envelope-from gnats) Resent-Date: Sun, 30 Nov 2003 05:50:20 -0800 (PST) Resent-Message-Id: <200311301350.hAUDoKB2065391@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Eugene Grosbein Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4E2116A4CE for ; Sun, 30 Nov 2003 05:42:20 -0800 (PST) Received: from grosbein.pp.ru (dadv.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92E0543F75 for ; Sun, 30 Nov 2003 05:42:18 -0800 (PST) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.9p2/8.12.9) with ESMTP id hARFFe78005406 for ; Thu, 27 Nov 2003 22:15:41 +0700 (KRAT) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.9p2/8.12.9/Submit) id hARFFe2J005405; Thu, 27 Nov 2003 22:15:40 +0700 (KRAT) (envelope-from eugen) Message-Id: <200311271515.hARFFe2J005405@grosbein.pp.ru> Date: Thu, 27 Nov 2003 22:15:40 +0700 (KRAT) From: Eugene Grosbein To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: docs/59835: ipfw(8) man page does not warn about accepted but meaningless rules X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Eugene Grosbein List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 13:50:23 -0000 >Number: 59835 >Category: docs >Synopsis: ipfw(8) man page does not warn about accepted but meaningless rules >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 30 05:50:20 PST 2003 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release: FreeBSD 4.9-STABLE i386 >Organization: Svyaz Service JSC >Environment: System: FreeBSD grosbein.pp.ru 4.9-STABLE FreeBSD 4.9-STABLE #2: Tue Nov 25 23:13:47 KRAT 2003 eu@grosbein.pp.ru:/usr/local/obj/usr/local/src/sys/DADV i386 IPFW2 >Description: ipfw2 accepts rules like this: divert 10000 ip from any to any via fxp0 MAC 00:90:27:a7:5c:72 any But this rules will never match a packet. And ipfw(8) man page mentiones this nowhere. Yes, it says something: /* quote start */ Note that as packets flow through the stack, headers can be stripped or added to it, and so they may or may not be available for inspection. E.g., incoming packets will include the MAC header when ipfw is invoked from ether_demux(), but the same packets will have the MAC header stripped off when ipfw is invoked from ip_input(). Also note that each packet is always checked against the complete rule- set, irrespective of the place where the check occurs, or the source of the packet. If a rule contains some match patterns or actions which are not valid for the place of invocation (e.g. trying to match a MAC header within ip_input() ), the match pattern will not match, but a not operator in front of such patterns will cause the pattern to always match on those packets. /* quote stop */ However, man page does not say that divertion will occur when ipfw is invoked from ip_input(). >How-To-Repeat: See description. I needed to count and divert unicast-only packets to an application, tried to use mentioned rule and failed. I'm forced to rewrite it as a set of three rules (count, skip broadcast and divert) but it took some time to understand what's going wrong. >Fix: Correct ipfw(8) man page. It should clearly state that divert can never be used with layer2 packets. Eugene Grosbein >Release-Note: >Audit-Trail: >Unformatted: