From owner-freebsd-net@FreeBSD.ORG Fri May 12 15:19:51 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2913416A71D; Fri, 12 May 2006 15:19:51 +0000 (UTC) (envelope-from vadimnuclight@tpu.ru) Received: from relay1.tpu.ru (relay1.tpu.ru [213.183.112.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27FCD43D49; Fri, 12 May 2006 15:19:49 +0000 (GMT) (envelope-from vadimnuclight@tpu.ru) Received: by relay1.tpu.ru (Postfix, from userid 501) id 006CF10C47F; Fri, 12 May 2006 22:19:46 +0700 (NOVST) Received: from mail.main.tpu.ru (mail.main.tpu.ru [10.0.0.3]) by relay1.tpu.ru (Postfix) with ESMTP id D971410C47C; Fri, 12 May 2006 22:19:46 +0700 (NOVST) Received: from mail.tpu.ru ([213.183.112.105]) by mail.main.tpu.ru with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 22:19:46 +0700 Received: from nuclight.avtf.net ([82.117.64.107]) by mail.tpu.ru over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 22:19:46 +0700 To: "Luigi Rizzo" References: <44648E66.6010800@freebsdbrasil.com.br> <20060512065327.B16302@xorpc.icir.org> Message-ID: Date: Fri, 12 May 2006 22:18:43 +0700 From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20060512065327.B16302@xorpc.icir.org> User-Agent: Opera M2/7.54 (Win32, build 3865) X-OriginalArrivalTime: 12 May 2006 15:19:46.0499 (UTC) FILETIME=[80BDF930:01C675D7] Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [patch] ipfw packet tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 15:19:52 -0000 12.05.06 × 20:53 Luigi Rizzo wrote: >> > I've tried Andrey Elsukov's ipfw "tag/tagged" patches from: >> > http://butcher.heavennet.ru/patches/kernel/ipfw_tags/ >> > >> > Tested on 5.5-PRERELEASE production server with moderate >> > load - rock stable [I've also looked through the code - patch >> > is small, so it simply can't be any bugs there ;)]. >> > >> > Personally I very like the idea from original Andrey's letter >> >> I have tested on 6.1 and works fine too. >> >> Hope it gets commited. Very useful for altq/dummynet flexibility too. > > i would, however, like to have a bit more documentation in the patch, > in particular: > > - a manpage patch describing how to use the thing, and also the > behaviour in in odd situations (e.g. what happens when we try to tag > a packet multiple times ? does the tag survive between the 'input' > and 'output' path of ipfw for routed packets, etc ?). > I can look this up in the code, but the average user cannot, I think it will always survive, but not sure, may be it is better for your to review the code and correct description. > and the patch does not contain a single line of comment, > plus we generally want to have some textual description of the > behaviour (so we can RTFM), not just an implementation > without comments. OK, Andrey currently comments the code and implements untag action, and here is my patch for manpage describing all this stuff: --- ipfw.8.orig Fri May 12 21:09:14 2006 +++ ipfw.8 Fri May 12 22:08:42 2006 @@ -563,6 +563,30 @@ Note: logging is done after all other packet matching conditions have been successfully verified, and before performing the final action (accept, deny, etc.) on the packet. +.It Cm tag Ar number +When a packet matches a rule with the +.Cm tag +keyword, the numeric tag for the given +.Ar number +in the range 0..65535 will be attached to the packet. +The tag acts as an internal marker (it is not sent out over +the wire) that can be used to identify these packets later on. +This can be used, for example, to provide trust between interfaces +and to start doing policy-based filtering. +A packet can have mutiple tags at the same time. +Tags are "sticky", meaning once a tag is applied to a packet by a +matching rule it exists everywhere while packet is still in kernel +until explicit removal or sending packet out to the network. +To check for previously applied tags, use the +.Cm tagged +rule option. +.It Cm untag Ar number +When a packet matches a rule with the +.Cm untag +keyword, the tag with the number +.Ar number +is searched in the set of tags attached to +this packet and, if found, removed from this set. .It Cm altq Ar queue When a packet matches a rule with the .Cm altq @@ -1257,6 +1281,15 @@ .It Cm src-port Ar ports Matches IP packets whose source port is one of the port(s) specified as argument. +.It Cm tagged Ar number +Match if packet has a tag with number +.Ar number . +Tags can be applied to the packet using +.Cm tag +rule action parameter or set somewhere in another part of the kernel +network subsytem using +.Xr mbuf_tags 9 +facility. .It Cm tcpack Ar ack TCP packets only. Match if the TCP header acknowledgment number field is set to -- WBR, Vadim Goncharov