From owner-freebsd-pf@FreeBSD.ORG Mon Dec 2 11:06:51 2013 Return-Path: Delivered-To: freebsd-pf@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 670BCB7E for ; Mon, 2 Dec 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 51B591956 for ; Mon, 2 Dec 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rB2B6pZX007816 for ; Mon, 2 Dec 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rB2B6oRe007814 for freebsd-pf@FreeBSD.org; Mon, 2 Dec 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Dec 2013 11:06:50 GMT Message-Id: <201312021106.rB2B6oRe007814@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Subject: Current problem reports assigned to 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 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/182401 pf [pf] pf state for some IPs reaches 4294967295 suspicou o kern/182350 pf [pf] core dump with packet filter -- pf_overlad_task o kern/179392 pf [pf] [ip6] Incorrect TCP checksums in rdr return packe o kern/177810 pf [pf] traffic dropped by accepting rules is not counted o kern/177808 pf [pf] [patch] route-to rule forwarding traffic inspite o kern/176268 pf [pf] [patch] synproxy not working with route-to o kern/173659 pf [pf] PF fatal trap on 9.1 (taskq fatal trap on pf_test o bin/172888 pf [patch] authpf(8) feature enhancement o kern/172648 pf [pf] [ip6]: 'scrub reassemble tcp' breaks IPv6 packet o kern/171733 pf [pf] PF problem with modulate state in [regression] o kern/169630 pf [pf] [patch] pf fragment reassembly of padded (undersi o kern/168952 pf [pf] direction scrub rules don't work o kern/168190 pf [pf] panic when using pf and route-to (maybe: bad frag o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/87074 pf [pf] pf does not log dropped packets when max-* statef a kern/86752 pf [pf] pf does not use default timeouts when reloading c o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 56 problems total. 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. From owner-freebsd-pf@FreeBSD.ORG Mon Dec 2 17:24:51 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 D5237A97 for ; Mon, 2 Dec 2013 17:24:51 +0000 (UTC) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 634EB163D for ; Mon, 2 Dec 2013 17:24:51 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id v10so5431416bkz.7 for ; Mon, 02 Dec 2013 09:24:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=EUqlgtzhFn60AF5ayDagW9l8A8OnILieys9we2ALFYY=; b=QFL//eHcK0uu92KE/Eba6QrCQdT8KGnoW/dFQPRWhoP+BTmRY5Cq23LJ8U7VyPm6CO +KRS0qIM5boYud4dkil8sup6HN1LbDFwkXyUkt6jLTjWN88zE2zEwg1HtDEC05CpB3bw ctKXQLzpWutw6B9VdYsObyJa/ARXJZ8d809DD9yH6yEo2nBnUdsyRHvRyRfEiPGVMVJQ 0e+5oXU8byOpEOQpyS4XSJ23eHzjN6pJ/A9W31KuiFcL7cpZfQyGTYXfbr/1WTNJPLb1 EI5XPi5IjQst9On9Bevmqdk0od6L2JJwN2J9aMcMpOPjsVmNKkAs5uccr1coVicHLzD7 n/4Q== X-Gm-Message-State: ALoCoQlBHmb75WdrTsUB1k75UDhirTvFY4y3zkjHgunf3ovQ0CUjIe32bc2ecf5Ow2dYKLmbNmt0 X-Received: by 10.204.68.199 with SMTP id w7mr53972bki.160.1386001739457; Mon, 02 Dec 2013 08:28:59 -0800 (PST) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPSA id it12sm8713715bkb.12.2013.12.02.08.28.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2013 08:28:58 -0800 (PST) From: Kajetan Staszkiewicz To: Gleb Smirnoff Subject: Re: [patch] Source entries removing is awfully slow. Date: Mon, 2 Dec 2013 17:28:57 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.1; KDE/4.8.4; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201312012005.54919.vegeta@tuxpowered.net> <20131202153638.GL48919@glebius.int.ru> In-Reply-To: <20131202153638.GL48919@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201312021728.58010.vegeta@tuxpowered.net> 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 17:24:51 -0000 Dnia poniedzia=C5=82ek, 2 grudnia 2013 o 16:36:38 Gleb Smirnoff napisa=C5= =82(a): > Kajetan, >=20 > On Sun, Dec 01, 2013 at 08:05:54PM +0100, Kajetan Staszkiewicz wrote: > K> > Ok. Let's summurize what we need to: > K> > > K> > 1) Switch kill|reset, that affects both -K and -k. > K> > 2) Add option to -K that would kill states. > K> > 3) Add option to -K and -k to specify that argument is a table. > K> > 4) Try not to add new global option keys. > K> > > K> > What we got: > K> > > K> > 1) -k supports specifying that argument is label or id. This is done > via K> > multiple -k specifiers: > K> > > K> > pfctl -k id -k 4823e84500000003 > K> > > K> > 2) -K and -k can be specified twice, meaning -k source -K destinatio= n. > K> > > K> > So, 1) and 2) make order of multiple arguments important. > K> > > K> > The main problem is that we need to keep working current syntax, whi= ch > I K> > find ugly. The biggest problem is that order of arguments matters. > This is K> > really a bad habbit. > K> > > K> > What about if we come with something order-agnostic as alternative to > K> > current syntax? And put all enhanced state/srcnode killing/resetting > into K> > this new syntax, w/o touching current syntax. The current syntax > will be K> > mark as obsoleted in manual page. We might even want to > implement all K> > these new features in a new utility. Not sure there is > a reason to do, so K> > but is possible. > K> > K> I believe it is possible to extend the current syntax without breaking > K> compatibility. Have a look: > K> - A list of -K string1 -K string2... is provided. > K> - Magic keywords are: label, id, table, rdrhost, kill ("states", > K> "rststates"). > K> - If there is a magic keyword at any position, the next position is a > value for K> the keyword. > K> - If there is a string, which is not a magic keyword, at any position, > it is K> src host or dst host, depending on position (first is src, next > is dst). K> - Of course not all keywords apply both to -K and -k (e.g > state's rdrhost is K> src_node's dst). > K> > K> This is: > K> - Compatible with the current syntax. > K> - Extends the syntax to my needs. > K> - By coincidence extedns the syntax for matching by multiple keywords + > src/dst K> at once. Kernel should already handle that, pfctl.c needs to > be changed. K> > K> It can be extended with more magic keywords: srchost, dsthost. This > would make K> order of tuples (-K keyword -K value) fully obsolete. > K> > K> How do you find the idea? >=20 > Well, that would work. I just dislike the current syntax order dependant: >=20 > '-K foo -K bar' isn't equal to '-K bar -K foo' >=20 > But compatibility issue can overweight saneness. Do we have an agreement then? Shall I start developing this? > Hmm, may be it is worth make our discussion public? The freebsd-pf@ > or freebsd-net@ would be okay. I think it's a bit late, but I somehow forgot about this in the first email= =2E=20 Added pf@ now. =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' 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 From owner-freebsd-pf@FreeBSD.ORG Wed Dec 4 13:34:13 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 0B7F64F5; Wed, 4 Dec 2013 13:34:13 +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 EFFE21116; Wed, 4 Dec 2013 13:34:11 +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 rB4DY21x070777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Dec 2013 17:34:02 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB4DY2jM070776; Wed, 4 Dec 2013 17:34:02 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 4 Dec 2013 17:34:02 +0400 From: Gleb Smirnoff To: Ian FREISLICH Subject: Re: icmp-type echoreq not matching resulting ttl exceeded Message-ID: <20131204133402.GL48919@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: bapt@FreeBSD.org, 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: Wed, 04 Dec 2013 13:34:13 -0000 Ian, On Fri, Nov 29, 2013 at 02:28:27PM +0200, Ian FREISLICH wrote: I> At some point this stopped working. I was able to use traceroute -I I> This rule let the echo request out and the resulting TTL exceeded I> was matched and allowed back in. I> I> pass out inet proto icmp from to any icmp-type echoreq I> I> I've had to change the rule to the following to keep traceroute going: I> I> pass out inet proto icmp from to any This is probably related to r257223. Baptiste, any ideas? Ian, is it possible to reproduce this on a single host? What pf.conf and traceroute command are required? -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Wed Dec 4 14:29:31 2013 Return-Path: Delivered-To: freebsd-pf@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 56048EBF for ; Wed, 4 Dec 2013 14:29:31 +0000 (UTC) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D5621144E for ; Wed, 4 Dec 2013 14:29:30 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id r15so10642968ead.24 for ; Wed, 04 Dec 2013 06:29:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=GXxk248+D7yEtRtwG0QMtDIl1Ric8xnvYd3vNMOy59w=; b=dmdBpYKZNbZ75nqLatjKrSTC5mvmQgsU356rmIkhjwCqiY1ZSQK/9nNvHcl0a7tYvu QvzucN+CKNeShKOU33/v7p444sWZMFhqHW8cGL7elTf16YNZy7zIY+1vPQlnmn2uNaeG a50+8MNVmwwVHV1/Vn6kydZR6Xinq9Ou20XRrzQ/QuZMwgJ3GQt2dgkpdHd3KErab5e0 0EXWJYMxmUQ7L+Qb32BnJaoSfh3wRGlMgJoMK0VOkx0PDWaT+4tAjBFOxoxDFUwHgMKe gvQiVXhJERR/H153vcAEuxQqstO8aD0aKWKAmrYAC+S+i6zREBgrj764mI33Y0FTQQOI EV/g== X-Gm-Message-State: ALoCoQlvpc/vQDfiJQt5BCIoZ+RkW5gCoGCU0asI/uiJ/PEAW8UIWq/IMDVNzyXKVSndVi7Se1Z5 X-Received: by 10.14.182.199 with SMTP id o47mr75925317eem.7.1386167363099; Wed, 04 Dec 2013 06:29:23 -0800 (PST) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPSA id g47sm95065582eeo.19.2013.12.04.06.29.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Dec 2013 06:29:22 -0800 (PST) From: Kajetan Staszkiewicz To: Gleb Smirnoff Subject: Re: [patch] Source entries removing is awfully slow. Date: Wed, 4 Dec 2013 15:29:21 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.1; KDE/4.8.4; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201312021728.58010.vegeta@tuxpowered.net> <20131202163927.GM48919@glebius.int.ru> In-Reply-To: <20131202163927.GM48919@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201312041529.21788.vegeta@tuxpowered.net> 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: Wed, 04 Dec 2013 14:29:31 -0000 Dnia poniedzia=C5=82ek, 2 grudnia 2013 o 17:39:27 Gleb Smirnoff napisa=C5= =82(a): > 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. I have a nice commandline parser working, but I got blocked by one problem.= As=20 the parser is quite big and most options are common for -K and -k, the pars= er=20 is just one function for both operation modes (and a similar thing for the= =20 loops going over IP addresses found by given host names). Unfortunately=20 DIOCKILLSTATES and DIOCKILLSRCNODES are using separate structures. Whatever the parser reads, it puts the result in the following structure=20 (defined only inside pfctl, not kernel): struct pfioc_universal_kill { sa_family_t puk_af; int puk_proto; struct pf_rule_addr puk_src; struct pf_rule_addr puk_dst; struct pf_rule_addr puk_rdr; struct pf_state_cmp puk_pfcmp; char puk_ifname[IFNAMSIZ]; char puk_label[PF_RULE_LABEL_SIZE]; char puk_table[PF_TABLE_NAME_SIZE]; u_int puk_killed_states; u_int puk_killed_src_nodes; }; Which later gets translated for every ioctl to pfioc_src_node_kill or=20 pfioc_state_kill. To have the most clean and simple code it would make the most sense to use = the=20 aforementioned pfioc_universal_kill for both DIOCKILLSTATES and=20 DIOCKILLSRCNODES. But that would be a change of kernel api which I assume c= an=20 not take place inside major release, so translation of structures is curren= tly=20 the way to go. Please correct me if I am wrong. =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' From owner-freebsd-pf@FreeBSD.ORG Thu Dec 5 08:19:07 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 E30F0365 for ; Thu, 5 Dec 2013 08:19:07 +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 4E01116C0 for ; Thu, 5 Dec 2013 08:19:06 +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 rB58In97075607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2013 12:18:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB58Imtx075606; Thu, 5 Dec 2013 12:18:48 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 5 Dec 2013 12:18:48 +0400 From: Gleb Smirnoff To: Kajetan Staszkiewicz Subject: Re: [patch] Source entries removing is awfully slow. Message-ID: <20131205081848.GQ48919@glebius.int.ru> References: <201303081419.17743.vegeta@tuxpowered.net> <201312021728.58010.vegeta@tuxpowered.net> <20131202163927.GM48919@glebius.int.ru> <201312041529.21788.vegeta@tuxpowered.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <201312041529.21788.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: Thu, 05 Dec 2013 08:19:07 -0000 Kajetan, On Wed, Dec 04, 2013 at 03:29:21PM +0100, Kajetan Staszkiewicz wrote: K> Dnia poniedziałek, 2 grudnia 2013 o 17:39:27 Gleb Smirnoff napisał(a): K> K> > I won't object on any interface that is consistent and resides in the K> > '-K' and '-k' namespace. As said before, I am against utilizing new K> > letters for options to avoid clashing with pfctl syntax in OpenBSD. K> K> I have a nice commandline parser working, but I got blocked by one problem. As K> the parser is quite big and most options are common for -K and -k, the parser K> is just one function for both operation modes (and a similar thing for the K> loops going over IP addresses found by given host names). Unfortunately K> DIOCKILLSTATES and DIOCKILLSRCNODES are using separate structures. K> K> Whatever the parser reads, it puts the result in the following structure K> (defined only inside pfctl, not kernel): K> K> struct pfioc_universal_kill { K> sa_family_t puk_af; K> int puk_proto; K> struct pf_rule_addr puk_src; K> struct pf_rule_addr puk_dst; K> struct pf_rule_addr puk_rdr; K> struct pf_state_cmp puk_pfcmp; K> char puk_ifname[IFNAMSIZ]; K> char puk_label[PF_RULE_LABEL_SIZE]; K> char puk_table[PF_TABLE_NAME_SIZE]; K> u_int puk_killed_states; K> u_int puk_killed_src_nodes; K> }; K> K> Which later gets translated for every ioctl to pfioc_src_node_kill or K> pfioc_state_kill. K> K> To have the most clean and simple code it would make the most sense to use the K> aforementioned pfioc_universal_kill for both DIOCKILLSTATES and K> DIOCKILLSRCNODES. But that would be a change of kernel api which I assume can K> not take place inside major release, so translation of structures is currently K> the way to go. Please correct me if I am wrong. It is okay to add new API. So in head we will add new API/ABI, then remove obsoleted one. We will merge only addition to stable/10, not removal. The ABI constraints for stable branches are the following. Newer kernel must work with older utilities. So, 10.1 kernel will work with pfctl from 10.0, since old ioctls are still supported. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Thu Dec 5 10:07:54 2013 Return-Path: Delivered-To: freebsd-pf@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 49B79245 for ; Thu, 5 Dec 2013 10:07:54 +0000 (UTC) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCD281EEB for ; Thu, 5 Dec 2013 10:07:53 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id k10so11428657eaj.1 for ; Thu, 05 Dec 2013 02:07:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=SYI3dfiizs8SDkuec6Q7JaJMpc2fytsWfyuCg8S1J+M=; b=dbl2U73oH7aLYCBe+753QSFTYKls4MdbZsc1HfaZnZc+OiFlRF0IVAfy9UGv95Gjig DpIG7r++MJpC9VSsndkVDjTdWFWvKJb2w0qsTpmMd8N66sDhbe9sBvQK9dvBoyq5SO47 BXMy/tZ9MXj7a66zI5Mb5JhQpwJyiAIrL3mA1BzIgkakX3WQotDgoXwVnGL5otdC/AzC WqEG+naQrBtn7azWSB3s2e8eGNCMxNI80maYSRZIrtrsC5jk12ZtU73L/OIjTDOmoV99 m/yvjzLgByWjinw5YX3a1gGgQseIRAPqLNcPVf1POZkQfCQqRtTIGWdabpA7nPmBuEau Jv5A== X-Gm-Message-State: ALoCoQnw9/hyBn/MgfQXtr9PsS45jXQjZKZBw5ufuxeg335v5Ba0Bt4PCcWxuByuyR1DqUi+uLdU X-Received: by 10.15.56.7 with SMTP id x7mr15224255eew.43.1386238066184; Thu, 05 Dec 2013 02:07:46 -0800 (PST) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPSA id e3sm67106346eeg.11.2013.12.05.02.07.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2013 02:07:45 -0800 (PST) From: Kajetan Staszkiewicz To: Gleb Smirnoff Subject: Re: [patch] Source entries removing is awfully slow. Date: Thu, 5 Dec 2013 11:07:39 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.1; KDE/4.8.4; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201312041529.21788.vegeta@tuxpowered.net> <20131205081848.GQ48919@glebius.int.ru> In-Reply-To: <20131205081848.GQ48919@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201312051107.39932.vegeta@tuxpowered.net> 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: Thu, 05 Dec 2013 10:07:54 -0000 Dnia czwartek, 5 grudnia 2013 o 09:18:48 Gleb Smirnoff napisa=C5=82(a): > K> To have the most clean and simple code it would make the most sense to > use the K> aforementioned pfioc_universal_kill for both DIOCKILLSTATES and > K> DIOCKILLSRCNODES. But that would be a change of kernel api which I > assume can K> not take place inside major release, so translation of > structures is currently K> the way to go. Please correct me if I am wrong. >=20 > It is okay to add new API. I was rather thinking about leaving DIOCKILLSTATES and DIOCKILLSRCNODES ioc= tls=20 in place but change the structure passed to them to pfioc_universal_killer.= So=20 changint the existing API. > So in head we will add new API/ABI, then remove obsoleted one. We will > merge only addition to stable/10, not removal. >=20 > The ABI constraints for stable branches are the following. Newer kernel > must work with older utilxities. So, 10.1 kernel will work with pfctl from > 10.0, since old ioctls are still supported. Is recompiling older utilities allowed? Please note that I need to add=20 ps(n?)k_table to (pfioc_src_nod|stat)e_kill and psnk_killed_states to=20 psnk_src_node_kill anyway. If not, then we must consider that this patch co= uld=20 get only into head, and only with struct pfioc_universal_kill. I see no rea= son=20 to clean up the old parser without adding the new syntax with new parameter= s. =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' From owner-freebsd-pf@FreeBSD.ORG Thu Dec 5 10:47:43 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 4C899A08 for ; Thu, 5 Dec 2013 10:47:43 +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 AD3B010F8 for ; Thu, 5 Dec 2013 10:47:41 +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 rB5AlQGR076627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Dec 2013 14:47:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rB5AlQs6076626; Thu, 5 Dec 2013 14:47:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 5 Dec 2013 14:47:26 +0400 From: Gleb Smirnoff To: Kajetan Staszkiewicz Subject: Re: [patch] Source entries removing is awfully slow. Message-ID: <20131205104725.GT48919@glebius.int.ru> References: <201303081419.17743.vegeta@tuxpowered.net> <201312041529.21788.vegeta@tuxpowered.net> <20131205081848.GQ48919@glebius.int.ru> <201312051107.39932.vegeta@tuxpowered.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201312051107.39932.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: Thu, 05 Dec 2013 10:47:43 -0000 Kajetan, On Thu, Dec 05, 2013 at 11:07:39AM +0100, Kajetan Staszkiewicz wrote: K> > K> To have the most clean and simple code it would make the most sense to K> > use the K> aforementioned pfioc_universal_kill for both DIOCKILLSTATES and K> > K> DIOCKILLSRCNODES. But that would be a change of kernel api which I K> > assume can K> not take place inside major release, so translation of K> > structures is currently K> the way to go. Please correct me if I am wrong. K> > K> > It is okay to add new API. K> K> I was rather thinking about leaving DIOCKILLSTATES and DIOCKILLSRCNODES ioctls K> in place but change the structure passed to them to pfioc_universal_killer. So K> changint the existing API. That can't be merged. K> > So in head we will add new API/ABI, then remove obsoleted one. We will K> > merge only addition to stable/10, not removal. K> > K> > The ABI constraints for stable branches are the following. Newer kernel K> > must work with older utilxities. So, 10.1 kernel will work with pfctl from K> > 10.0, since old ioctls are still supported. K> K> Is recompiling older utilities allowed? Please note that I need to add K> ps(n?)k_table to (pfioc_src_nod|stat)e_kill and psnk_killed_states to K> psnk_src_node_kill anyway. If not, then we must consider that this patch could K> get only into head, and only with struct pfioc_universal_kill. I see no reason K> to clean up the old parser without adding the new syntax with new parameters. Recompiling old utilites is allowed. So, the plan, that would work sounds like that: 1) Add new ioctl number and new structure. Rewrite pfctl to handle it. 2) Remove old ioctls and structures. 3) Merge 1). What we achieve: 10.1 kernel understands 10.1 pfctl ans has new functionality. 10.1 kernel understands 10.0 pfctl. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Thu Dec 5 12:26:16 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 391FCCD0 for ; Thu, 5 Dec 2013 12:26:16 +0000 (UTC) Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C119D17FB for ; Thu, 5 Dec 2013 12:26:15 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id f15so11164608eak.25 for ; Thu, 05 Dec 2013 04:26:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=F4vfGwG0JdoNat2IRsfP/JVx51JSzOXnv/8gn7yzlWc=; b=AX2Qa2N4sxluruK7fs3BUwhkiciG9DI/AAGUm62TxQW5W4qioSPtmoWcQ+xLRMahot td2CLRhO7kuHm1j7v7ptiFGiMgFS1Sbce8gKv+kONPYB3DOP8C35sXZjJpD61GjmewSZ zFY8cj6NuRuV72wvSxS4B96muJS4dKxrq/ijub+4wl7HADmA4aC9O0JF4ENUAWo0GNum Uiw8Fl/ZUnA3Vw+lsU71L8+rlGfporOFLZHORLEgnyQV9YrBuqIktMD9On+ZvaWizRwp /7690CsNwh0PRvcA/YF7d2QBmjPTeMpFH8Se4cI2j5v0ysJFQRXLo+9Hkgb0Ipwn+GFP 8nHQ== X-Gm-Message-State: ALoCoQnsWCIVVdGQvXX+5nuUMmxYSrmRqUsOasK4rpORK/5DDcvGnsrQyPJ+/Ipl6kat7ubA9is2 X-Received: by 10.14.87.2 with SMTP id x2mr102087eee.79.1386246030570; Thu, 05 Dec 2013 04:20:30 -0800 (PST) Received: from zvezda.localnet ([212.48.107.10]) by mx.google.com with ESMTPSA id j46sm105475085eew.18.2013.12.05.04.20.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2013 04:20:30 -0800 (PST) From: Kajetan Staszkiewicz To: Gleb Smirnoff Subject: Re: [patch] Source entries removing is awfully slow. Date: Thu, 5 Dec 2013 13:20:24 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.1; KDE/4.8.4; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201312051107.39932.vegeta@tuxpowered.net> <20131205104725.GT48919@glebius.int.ru> In-Reply-To: <20131205104725.GT48919@glebius.int.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201312051320.24373.vegeta@tuxpowered.net> 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: Thu, 05 Dec 2013 12:26:16 -0000 Dnia czwartek, 5 grudnia 2013 o 11:47:26 Gleb Smirnoff napisa=C5=82(a): > Recompiling old utilites is allowed. >=20 > So, the plan, that would work sounds like that: >=20 > 1) Add new ioctl number and new structure. Rewrite pfctl to handle it. > 2) Remove old ioctls and structures. > 3) Merge 1). >=20 > What we achieve: >=20 > 10.1 kernel understands 10.1 pfctl ans has new functionality. > 10.1 kernel understands 10.0 pfctl. OK, now I get it. I'll keep you informed in a few days when I have a workin= g=20 patch. =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------'