From owner-cvs-all@FreeBSD.ORG Wed May 24 16:47:01 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFBFF16A42A; Wed, 24 May 2006 16:47:01 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from camay.yandex.ru (camay.yandex.ru [213.180.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9F3B43D4C; Wed, 24 May 2006 16:47:00 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (camay.yandex.ru) by mail.yandex.ru id ; Wed, 24 May 2006 20:46:48 +0400 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Wed, 24 May 2006 20:46:48 +0400 (MSD) Date: Wed, 24 May 2006 20:46:48 +0400 (MSD) From: "Andrey V. Elsukov" Sender: bu7cher@yandex.ru Message-Id: <44748DF8.000002.11682@camay.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: bu7cher@yandex.ru To: andre@freebsd.org In-Reply-To: <44747A4C.9090800@freebsd.org> References: <200605241309.k4OD9tex003002@repoman.freebsd.org> <44747A4C.9090800@freebsd.org> X-Source-Ip: 82.211.152.12 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, oleg@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_fw.h ip_fw2.c src/sbin/ipfw ipfw.8 ipfw2.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bu7cher@yandex.ru List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 16:47:02 -0000 >Does this accept the packet and untag it at the same time? Wouldn't >it make more sense to have [tag|untag] as its own operators like >[allow|deny]? Yes, it does (but example is impractical - we don't need tagging or untagging when packet is finally denied). We thought about making [tag|untag] as its own actions like [allow|deny], but decided to implement it as modifiers instead, for two primary reasons: 1) Speed. It is faster to match packet with body of only one rule than to do it once more for the same packet in the next rule, only to take action on it. 2) Flexibility. We can use modifiers tag/untag with any possible actions, e.g. allow, netgraph, skipto, pipe, ... - not only [allow|deny]. Imagine you have to insert additional tagging rule for any such action looking absolutely the same? And then consider speed of matching. Thus, it is even *looks* more beautiful to write: ipfw add 100 netgraph 300 tag 200 ip from host1 to host2 for tagging packet with tag 200 and then sending it to netgraph, than to write something like: ipfw add 100 tag 200 ip from host1 to host2 ipfw add 101 netgraph 300 ip from host1 to host2 tagged 200 -- WBR, Andrey V. Elsukov