From owner-freebsd-pf@FreeBSD.ORG Mon Dec 2 16:39:31 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC3B32A6 for ; Mon, 2 Dec 2013 16:39:30 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6081C1273 for ; Mon, 2 Dec 2013 16:39:29 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rB2GdR0x055279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Dec 2013 20:39:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB2GdR8V055278; Mon, 2 Dec 2013 20:39:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 2 Dec 2013 20:39:27 +0400 From: Gleb Smirnoff To: Kajetan Staszkiewicz Subject: Re: [patch] Source entries removing is awfully slow. Message-ID: <20131202163927.GM48919@glebius.int.ru> References: <201303081419.17743.vegeta@tuxpowered.net> <201312012005.54919.vegeta@tuxpowered.net> <20131202153638.GL48919@glebius.int.ru> <201312021728.58010.vegeta@tuxpowered.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201312021728.58010.vegeta@tuxpowered.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-pf@freebsd.org" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:39:31 -0000 Kajetan, On Mon, Dec 02, 2013 at 05:28:57PM +0100, Kajetan Staszkiewicz wrote: K> > On Sun, Dec 01, 2013 at 08:05:54PM +0100, Kajetan Staszkiewicz wrote: K> > K> > Ok. Let's summurize what we need to: K> > K> > K> > K> > 1) Switch kill|reset, that affects both -K and -k. K> > K> > 2) Add option to -K that would kill states. K> > K> > 3) Add option to -K and -k to specify that argument is a table. K> > K> > 4) Try not to add new global option keys. K> > K> > K> > K> > What we got: K> > K> > K> > K> > 1) -k supports specifying that argument is label or id. This is done K> > via K> > multiple -k specifiers: K> > K> > K> > K> > pfctl -k id -k 4823e84500000003 K> > K> > K> > K> > 2) -K and -k can be specified twice, meaning -k source -K destination. K> > K> > K> > K> > So, 1) and 2) make order of multiple arguments important. K> > K> > K> > K> > The main problem is that we need to keep working current syntax, which K> > I K> > find ugly. The biggest problem is that order of arguments matters. K> > This is K> > really a bad habbit. K> > K> > K> > K> > What about if we come with something order-agnostic as alternative to K> > K> > current syntax? And put all enhanced state/srcnode killing/resetting K> > into K> > this new syntax, w/o touching current syntax. The current syntax K> > will be K> > mark as obsoleted in manual page. We might even want to K> > implement all K> > these new features in a new utility. Not sure there is K> > a reason to do, so K> > but is possible. K> > K> K> > K> I believe it is possible to extend the current syntax without breaking K> > K> compatibility. Have a look: K> > K> - A list of -K string1 -K string2... is provided. K> > K> - Magic keywords are: label, id, table, rdrhost, kill ("states", K> > K> "rststates"). K> > K> - If there is a magic keyword at any position, the next position is a K> > value for K> the keyword. K> > K> - If there is a string, which is not a magic keyword, at any position, K> > it is K> src host or dst host, depending on position (first is src, next K> > is dst). K> - Of course not all keywords apply both to -K and -k (e.g K> > state's rdrhost is K> src_node's dst). K> > K> K> > K> This is: K> > K> - Compatible with the current syntax. K> > K> - Extends the syntax to my needs. K> > K> - By coincidence extedns the syntax for matching by multiple keywords + K> > src/dst K> at once. Kernel should already handle that, pfctl.c needs to K> > be changed. K> K> > K> It can be extended with more magic keywords: srchost, dsthost. This K> > would make K> order of tuples (-K keyword -K value) fully obsolete. K> > K> K> > K> How do you find the idea? K> > K> > Well, that would work. I just dislike the current syntax order dependant: K> > K> > '-K foo -K bar' isn't equal to '-K bar -K foo' K> > K> > But compatibility issue can overweight saneness. K> K> Do we have an agreement then? Shall I start developing this? I won't object on any interface that is consistent and resides in the '-K' and '-k' namespace. As said before, I am against utilizing new letters for options to avoid clashing with pfctl syntax in OpenBSD. Thank you. -- Totus tuus, Glebius.