From owner-freebsd-pf@FreeBSD.ORG Mon Dec 2 19:56:27 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 CD180C23; Mon, 2 Dec 2013 19:56:27 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 97D2A1098; Mon, 2 Dec 2013 19:56:27 +0000 (UTC) Received: by mail-pb0-f41.google.com with SMTP id jt11so19842234pbb.28 for ; Mon, 02 Dec 2013 11:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5zjLVYTYumu8xYFVMZvGJ/2ebJslvj3on+hm4syZfM8=; b=NGsKav3LNN8UR6RgWi2KQ00WsLq/z7tZlAHmgf/5mbVm+HLifZ065ysken0RdxXitg 2QJUhVcQv4x7ezsWylasDrVO6n8evf/Y5kB07IjKI0eAPyyWhB+kGwrJS9h4tC3N89Xn zlG4kPXS65yEbiSXcnoksLmSqjljrSpUf8ZthvwwIIWlXA2qOf4lcHRr86+S4+B2xJ69 BThqyhtnzR0VS/5kLH9kCqAhLa4/1IOKfDfbKz15GHSjdm9FKiTtWKbNXABRq1YxqvAF 2RF2nql+Y7eoChH7xPddberIUKfMa03yeZiDea+Mt71t4kWvRcbJafJ8BgrN3eVqVSPL Zm3A== MIME-Version: 1.0 X-Received: by 10.66.188.203 with SMTP id gc11mr68460902pac.63.1386014187043; Mon, 02 Dec 2013 11:56:27 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.4.163 with HTTP; Mon, 2 Dec 2013 11:56:26 -0800 (PST) In-Reply-To: <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> <20131202163927.GM48919@glebius.int.ru> Date: Mon, 2 Dec 2013 20:56:26 +0100 X-Google-Sender-Auth: KEMwuotli0-SdXziKL0KAMSsqlk Message-ID: Subject: Re: [patch] Source entries removing is awfully slow. From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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 19:56:28 -0000 Hello, can you specify what does not fit on the current interface from pfctl? -k and -K have different scopes. You already can specify src/dst today through them. The only not possible thing is specifying ports/id for protocols that support them tcp/udp/icmp, mostly because the switch/parsing of arguments does not allow that. Furthermore pfctl is not really a well built utility per se, it does not provide any interface/library so external tools can use easily. That would be an improvement to it so extra features you need can be built easily and do not need to go into this utility per se. Though going back to your request, can you specify your requirments since i did not understand from the mail fwd here. On Mon, Dec 2, 2013 at 5:39 PM, Gleb Smirnoff wrote: > 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. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > -- Ermal