From owner-freebsd-net@FreeBSD.ORG Thu May 29 13:49:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1EEBF7E for ; Thu, 29 May 2014 13:49:02 +0000 (UTC) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 818812B88 for ; Thu, 29 May 2014 13:49:02 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id uo5so405629pbc.28 for ; Thu, 29 May 2014 06:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=qmSP4djW9CqpcTBxJDSvJB3VJNCcmzU7rfS9A2ebyFE=; b=VBhOUpkFhDojckNbyq0W/K1czIDnQUo0A742Y+zrKjDRE1O/DNv57jMmLM7ey3DeOf 5xyya+t/9Q7pxO3azNj1YfyUzlCVBrvdbfq40rjxoxVCzkqF3d+qqdfUwVb8L6bsB6EW ZM32y/rgqAEUH5L+At5Vwp9JDpod96dqNv6IPM3fqk2yEd+7j+dTvximWS56QO4Ef6bH fihV3PI8Z0l8mgBDSaMM3/ZEjcpOtEGqixfipm/JuGOA9OLG89m7yjO7HVc0UNo7d0gK 0UhrmiVQHb+ddDzKf+j0qxlQMBTxwGV8wZ7tVXH1Q/KTIeLSa7oWsb8a3WqdfNN+AyZB L5uA== X-Received: by 10.66.120.201 with SMTP id le9mr9030702pab.98.1401371341999; Thu, 29 May 2014 06:49:01 -0700 (PDT) Received: from billwin7 (amx-tls2.starhub.net.sg. [203.116.164.12]) by mx.google.com with ESMTPSA id jt7sm1388966pbc.46.2014.05.29.06.48.58 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 May 2014 06:49:01 -0700 (PDT) From: "bycn82" To: "'Luigi Rizzo'" References: <001b01cf7b3b$dfd1cfb0$9f756f10$@gmail.com> <20140529131015.GA72798@onelab2.iet.unipi.it> In-Reply-To: <20140529131015.GA72798@onelab2.iet.unipi.it> Subject: RE: propose a new generic purpose rule option for ipfw Date: Thu, 29 May 2014 21:48:58 +0800 Message-ID: <003201cf7b44$bfd6ed40$3f84c7c0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGHvkjU79R1H+5sSqlQcstB+XJ0CwD6Vot3AjU0ir0BPakgnpvDnOTQ Content-Language: en-us Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: 'FreeBSD Net' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:49:02 -0000 =20 -----Original Message----- From: 'Luigi Rizzo' [mailto:rizzo@iet.unipi.it]=20 Sent: 29 May, 2014 21:10 To: bycn82 Cc: 'FreeBSD Net' Subject: Re: propose a new generic purpose rule option for ipfw =20 On Thu, May 29, 2014 at 08:45:26PM +0800, bycn82 wrote: ... >=20 > Sure, that is the reason why developers are providing more and more = rule options. But the my question is do we have enough options to match = all the fixed position values? =20 we do not have an option for fixed position matching. =20 Can I say that =E2=80=9CIt will be useful when a user come up with a = special requirement which cannot be fulfilled by any existing rule = option.=E2=80=9D Since there are so many rule options already. So I = don=E2=80=99t know when that special requirement will appear. L that is = what you said =E2=80=9Cuseless=E2=80=9D, I accept that . =20 As i said, feel free to submit one and i will be happy to import it if = the code is clean (btw i am still waiting for fixes to the other 'rate = limiting' option you sent), but keep in mind that 'fixed position' is = mostly useless. Which `rate limiting`, the `Packet per second`?=20 http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/189720 =20 =20 More useful options would be one where you express the position as =20 '{MAC|VLAN|IP|UDP|TCP|...|PAYLOAD}+offset' =20 It is possible, =20 match the can be a pattern , then that means it can match multiple = value at the same time. =20 so at least you can adapt to variant headers, or one where you can look = for a pattern in the entire packet or in a portion of it. =20 cheers luigi