From owner-freebsd-pf@freebsd.org Sun Feb 17 21:01:32 2019 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CD7914DF5FF for ; Sun, 17 Feb 2019 21:01:32 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7D189182 for ; Sun, 17 Feb 2019 21:01:32 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CF25914DF5F6; Sun, 17 Feb 2019 21:01:31 +0000 (UTC) Delivered-To: pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDB9914DF5F5 for ; Sun, 17 Feb 2019 21:01:31 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D76F689172 for ; Sun, 17 Feb 2019 21:01:30 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E85D5A821 for ; Sun, 17 Feb 2019 21:01:29 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x1HL1T6f095075 for ; Sun, 17 Feb 2019 21:01:29 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x1HL1Tg2095071 for pf@FreeBSD.org; Sun, 17 Feb 2019 21:01:29 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201902172101.x1HL1Tg2095071@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: pf@FreeBSD.org Subject: Problem reports for pf@FreeBSD.org that need special attention Date: Sun, 17 Feb 2019 21:01:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Sun, 17 Feb 2019 21:01:32 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 203735 | Transparent interception of ipv6 with squid and p 1 problems total for which you should take action. From owner-freebsd-pf@freebsd.org Mon Feb 18 17:30:44 2019 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD9B614E54A6 for ; Mon, 18 Feb 2019 17:30:44 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB9E67453A; Mon, 18 Feb 2019 17:30:43 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id E752527D73; Mon, 18 Feb 2019 18:30:33 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id nYiE4_q7ypRT; Mon, 18 Feb 2019 18:30:33 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 2450828198; Mon, 18 Feb 2019 18:30:33 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id EDDAA190; Mon, 18 Feb 2019 18:30:32 +0100 (CET) Message-ID: <5C6AEBB8.2030305@incore.de> Date: Mon, 18 Feb 2019 18:30:32 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Konstantin Belousov CC: freebsd-pf@freebsd.org, Gleb Smirnoff , Kristof Provost Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections References: <5BD45882.1000207@incore.de> <5BEB3B9A.9080402@incore.de> <20181113222533.GJ9744@FreeBSD.org> <5C49ECAA.7060505@incore.de> <20190124203802.GU24863@kib.kiev.ua> <5C4A37A1.80206@incore.de> <20190125131409.GZ24863@kib.kiev.ua> <5C557065.10600@incore.de> <20190202184208.GG24863@kib.kiev.ua> In-Reply-To: <20190202184208.GG24863@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CB9E67453A X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of longwitz@incore.de designates 195.145.1.138 as permitted sender) smtp.mailfrom=longwitz@incore.de X-Spamd-Result: default: False [-1.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.83)[-0.832,0]; RCVD_COUNT_FIVE(0.00)[5]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[incore.de]; NEURAL_SPAM_SHORT(0.62)[0.617,0]; NEURAL_HAM_LONG(-0.97)[-0.972,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[dss.incore.de]; RCVD_IN_DNSWL_NONE(0.00)[138.1.145.195.list.dnswl.org : 127.0.10.0]; IP_SCORE(0.04)[asn: 3320(0.21), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:195.145.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 17:30:45 -0000 Hello, > Ok, thanks, I will commit the patch shortly. I do not see a point in waiting > for two more weeks, sure report me if anything goes wrong. your patch for counter(9) on i386 definitely solves my problem discussed in this thread. Because fetching a counter is a rather expansive function we should use counter_u64_fetch() in pf_state_expires() only when necessary. A "rdr pass" rule should not cause more effort than separate "rdr" and "pass" rules. For rules with adaptive timeout values the call of counter_u64_fetch() should be accepted, but otherwise not. For a small gain in performance especially for "rdr pass" rules I suggest something like --- pf.c.orig 2019-02-18 17:49:22.944751000 +0100 +++ pf.c 2019-02-18 17:55:07.396163000 +0100 @@ -1558,7 +1558,7 @@ if (!timeout) timeout = V_pf_default_rule.timeout[state->timeout]; start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; - if (start) { + if (start && state->rule.ptr != &V_pf_default_rule) { end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; states = counter_u64_fetch(state->rule.ptr->states_cur); } else { -- Andreas From owner-freebsd-pf@freebsd.org Mon Feb 18 18:07:37 2019 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2364814E64A1 for ; Mon, 18 Feb 2019 18:07:37 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [198.45.61.253]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 777CC759A5; Mon, 18 Feb 2019 18:07:36 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id x1II7T4c076215 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 18 Feb 2019 10:07:29 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id x1II7T3f076214; Mon, 18 Feb 2019 10:07:29 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 18 Feb 2019 10:07:29 -0800 From: Gleb Smirnoff To: Andreas Longwitz Cc: Konstantin Belousov , freebsd-pf@freebsd.org, Kristof Provost Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections Message-ID: <20190218180729.GP83215@FreeBSD.org> References: <5BEB3B9A.9080402@incore.de> <20181113222533.GJ9744@FreeBSD.org> <5C49ECAA.7060505@incore.de> <20190124203802.GU24863@kib.kiev.ua> <5C4A37A1.80206@incore.de> <20190125131409.GZ24863@kib.kiev.ua> <5C557065.10600@incore.de> <20190202184208.GG24863@kib.kiev.ua> <5C6AEBB8.2030305@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C6AEBB8.2030305@incore.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 777CC759A5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; ASN(0.00)[asn:2906, ipnet:198.45.48.0/20, country:US] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 18:07:37 -0000 Thanks, Andreas! Kristof, will you handle that? If you are busy, I can try to refresh my memory. On Mon, Feb 18, 2019 at 06:30:32PM +0100, Andreas Longwitz wrote: A> Hello, A> A> > Ok, thanks, I will commit the patch shortly. I do not see a point in waiting A> > for two more weeks, sure report me if anything goes wrong. A> A> your patch for counter(9) on i386 definitely solves my problem discussed A> in this thread. A> A> Because fetching a counter is a rather expansive function we should use A> counter_u64_fetch() in pf_state_expires() only when necessary. A "rdr A> pass" rule should not cause more effort than separate "rdr" and "pass" A> rules. For rules with adaptive timeout values the call of A> counter_u64_fetch() should be accepted, but otherwise not. A> A> For a small gain in performance especially for "rdr pass" rules I A> suggest something like A> A> --- pf.c.orig 2019-02-18 17:49:22.944751000 +0100 A> +++ pf.c 2019-02-18 17:55:07.396163000 +0100 A> @@ -1558,7 +1558,7 @@ A> if (!timeout) A> timeout = V_pf_default_rule.timeout[state->timeout]; A> start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; A> - if (start) { A> + if (start && state->rule.ptr != &V_pf_default_rule) { A> end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; A> states = counter_u64_fetch(state->rule.ptr->states_cur); A> } else { A> A> -- A> Andreas A> -- Gleb Smirnoff From owner-freebsd-pf@freebsd.org Mon Feb 18 20:17:26 2019 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55D9614EA620 for ; Mon, 18 Feb 2019 20:17:26 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9698841BC; Mon, 18 Feb 2019 20:17:25 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 77F84FC5F; Mon, 18 Feb 2019 20:17:25 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [192.168.228.1] (ptr-8rh08jz61yyfq8za5mu.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:240e:402:4884:154c:fc4:be06]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id A92EE2C799; Mon, 18 Feb 2019 21:17:22 +0100 (CET) From: "Kristof Provost" To: "Andreas Longwitz" Cc: "Konstantin Belousov" , freebsd-pf@freebsd.org, "Gleb Smirnoff" Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections Date: Mon, 18 Feb 2019 21:17:21 +0100 X-Mailer: MailMate (2.0BETAr6135) Message-ID: <222311AF-CA32-4C78-8550-215D9B4360AC@FreeBSD.org> In-Reply-To: <5C6AEBB8.2030305@incore.de> References: <5BD45882.1000207@incore.de> <5BEB3B9A.9080402@incore.de> <20181113222533.GJ9744@FreeBSD.org> <5C49ECAA.7060505@incore.de> <20190124203802.GU24863@kib.kiev.ua> <5C4A37A1.80206@incore.de> <20190125131409.GZ24863@kib.kiev.ua> <5C557065.10600@incore.de> <20190202184208.GG24863@kib.kiev.ua> <5C6AEBB8.2030305@incore.de> MIME-Version: 1.0 X-Rspamd-Queue-Id: B9698841BC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 20:17:26 -0000 On 18 Feb 2019, at 18:30, Andreas Longwitz wrote: >> Ok, thanks, I will commit the patch shortly. I do not see a point in >> waiting >> for two more weeks, sure report me if anything goes wrong. > > your patch for counter(9) on i386 definitely solves my problem > discussed > in this thread. > > Because fetching a counter is a rather expansive function we should > use > counter_u64_fetch() in pf_state_expires() only when necessary. A "rdr > pass" rule should not cause more effort than separate "rdr" and "pass" > rules. For rules with adaptive timeout values the call of > counter_u64_fetch() should be accepted, but otherwise not. > > For a small gain in performance especially for "rdr pass" rules I > suggest something like > > --- pf.c.orig 2019-02-18 17:49:22.944751000 +0100 > +++ pf.c 2019-02-18 17:55:07.396163000 +0100 > @@ -1558,7 +1558,7 @@ > if (!timeout) > timeout = V_pf_default_rule.timeout[state->timeout]; > start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; > - if (start) { > + if (start && state->rule.ptr != &V_pf_default_rule) { > end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; > states = > counter_u64_fetch(state->rule.ptr->states_cur); > } else { > I think that looks correct. Do you have any performance measurements on this? Although presumably it only really matters in cases where there’s no explicit catch-all rule, so I do wonder if it’s worth it. Regards, Kristof From owner-freebsd-pf@freebsd.org Tue Feb 19 21:53:16 2019 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D159214DAFA8 for ; Tue, 19 Feb 2019 21:53:16 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 673D376004; Tue, 19 Feb 2019 21:53:15 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 54CE227DC5; Tue, 19 Feb 2019 22:53:07 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id wLMHAAo4O-S3; Tue, 19 Feb 2019 22:53:06 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 374D727DAD; Tue, 19 Feb 2019 22:53:06 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id DF8ED1D2; Tue, 19 Feb 2019 22:53:05 +0100 (CET) Message-ID: <5C6C7AC1.4080201@incore.de> Date: Tue, 19 Feb 2019 22:53:05 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Kristof Provost CC: Konstantin Belousov , freebsd-pf@freebsd.org, Gleb Smirnoff Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections References: <5BD45882.1000207@incore.de> <5BEB3B9A.9080402@incore.de> <20181113222533.GJ9744@FreeBSD.org> <5C49ECAA.7060505@incore.de> <20190124203802.GU24863@kib.kiev.ua> <5C4A37A1.80206@incore.de> <20190125131409.GZ24863@kib.kiev.ua> <5C557065.10600@incore.de> <20190202184208.GG24863@kib.kiev.ua> <5C6AEBB8.2030305@incore.de> <222311AF-CA32-4C78-8550-215D9B4360AC@FreeBSD.org> In-Reply-To: <222311AF-CA32-4C78-8550-215D9B4360AC@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 673D376004 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of longwitz@incore.de designates 195.145.1.138 as permitted sender) smtp.mailfrom=longwitz@incore.de X-Spamd-Result: default: False [-2.26 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.907,0]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[incore.de]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.975,0]; IP_SCORE(0.04)[asn: 3320(0.21), country: DE(-0.01)]; MX_GOOD(-0.01)[dss.incore.de]; NEURAL_HAM_SHORT(-0.11)[-0.106,0]; RCVD_IN_DNSWL_NONE(0.00)[138.1.145.195.list.dnswl.org : 127.0.10.0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:195.145.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 19 Feb 2019 21:53:17 -0000 Kristof Provost wrote: > > Because fetching a counter is a rather expansive function we should use > counter_u64_fetch() in pf_state_expires() only when necessary. A "rdr > pass" rule should not cause more effort than separate "rdr" and "pass" > rules. For rules with adaptive timeout values the call of > counter_u64_fetch() should be accepted, but otherwise not. > > For a small gain in performance especially for "rdr pass" rules I > suggest something like > > --- pf.c.orig 2019-02-18 17:49:22.944751000 +0100 > +++ pf.c 2019-02-18 17:55:07.396163000 +0100 > @@ -1558,7 +1558,7 @@ > if (!timeout) > timeout = V_pf_default_rule.timeout[state->timeout]; > start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; > - if (start) { > + if (start && state->rule.ptr != &V_pf_default_rule) { > end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; > states = counter_u64_fetch(state->rule.ptr->states_cur); > } else { > > I think that looks correct. Do you have any performance measurements on > this? No > Although presumably it only really matters in cases where there’s no > explicit catch-all rule, so I do wonder if it’s worth it. Sorry, but I do not understand this argument. >From manpage: The adaptive timeout values can be defined both globally and for each rule. When used on a per-rule basis, the values relate to the number of states created by the rule, otherwise to the total number of states. This handling of adaptive timeouts is done in pf_state_expires(): start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; if (start) { end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; states = counter_u64_fetch(state->rule.ptr->states_cur); } else { start = V_pf_default_rule.timeout[PFTM_ADAPTIVE_START]; end = V_pf_default_rule.timeout[PFTM_ADAPTIVE_END]; states = V_pf_status.states; } The following calculation needs three values: start, end and states. 1. Normal rules "pass .." without adaptive setting meaning "start = 0" runs in the else-section of the code snippet and therefore takes "start" and "end" from the global default settings and sets "states" to pf_status.states (= total number of states). 2. Special rules like "pass .. keep state (adaptive.start 500 adaptive.end 1000)" have start != 0, run in the if-section of the code snippet and take "start" and "end" from the rule and set "states" to the number of states created by their rule using counter_u64_fetch(). Thats all ok, but there is a third case without special handling in the above code snippet: 3. All "rdr/nat pass .." statements use together the pf_default_rule. Therefore we have "start != 0" in this case and we run the if-section of the code snippet but we better should run the else-section in this case and do not fetch the counter of the pf_default_rule but take the total number of states. Thats what the patch does. Regards Andreas From owner-freebsd-pf@freebsd.org Sat Feb 23 15:48:19 2019 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFD341519F6B for ; Sat, 23 Feb 2019 15:48:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 322168FB90; Sat, 23 Feb 2019 15:48:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 5822B1F3F4; Sat, 23 Feb 2019 15:48:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.193] (ptr-8rh08jyuvq568vpw6ub.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:240e:402:341b:360f:e5dc:7fa3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 3053A372AB; Sat, 23 Feb 2019 16:48:15 +0100 (CET) From: "Kristof Provost" To: "Andreas Longwitz" Cc: "Konstantin Belousov" , freebsd-pf@freebsd.org, "Gleb Smirnoff" Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections Date: Sat, 23 Feb 2019 16:48:12 +0100 X-Mailer: MailMate (2.0BETAr6135) Message-ID: <051F7C53-CDC6-4A8E-87E5-EB4D22431EAC@FreeBSD.org> In-Reply-To: <5C6C7AC1.4080201@incore.de> References: <5BD45882.1000207@incore.de> <5BEB3B9A.9080402@incore.de> <20181113222533.GJ9744@FreeBSD.org> <5C49ECAA.7060505@incore.de> <20190124203802.GU24863@kib.kiev.ua> <5C4A37A1.80206@incore.de> <20190125131409.GZ24863@kib.kiev.ua> <5C557065.10600@incore.de> <20190202184208.GG24863@kib.kiev.ua> <5C6AEBB8.2030305@incore.de> <222311AF-CA32-4C78-8550-215D9B4360AC@FreeBSD.org> <5C6C7AC1.4080201@incore.de> MIME-Version: 1.0 X-Rspamd-Queue-Id: 322168FB90 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Sat, 23 Feb 2019 15:48:19 -0000 On 19 Feb 2019, at 22:53, Andreas Longwitz wrote: > Kristof Provost wrote: >> >> Because fetching a counter is a rather expansive function we >> should use >> counter_u64_fetch() in pf_state_expires() only when necessary. A >> "rdr >> pass" rule should not cause more effort than separate "rdr" and >> "pass" >> rules. For rules with adaptive timeout values the call of >> counter_u64_fetch() should be accepted, but otherwise not. >> >> For a small gain in performance especially for "rdr pass" rules I >> suggest something like >> >> --- pf.c.orig 2019-02-18 17:49:22.944751000 +0100 >> +++ pf.c 2019-02-18 17:55:07.396163000 +0100 >> @@ -1558,7 +1558,7 @@ >> if (!timeout) >> timeout = V_pf_default_rule.timeout[state->timeout]; >> start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; >> - if (start) { >> + if (start && state->rule.ptr != &V_pf_default_rule) { >> end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; >> states = counter_u64_fetch(state->rule.ptr->states_cur); >> } else { >> >> I think that looks correct. Do you have any performance measurements >> on >> this? > > No > >> Although presumably it only really matters in cases where there’s >> no >> explicit catch-all rule, so I do wonder if it’s worth it. > > Sorry, but I do not understand this argument. > >> From manpage: > The adaptive timeout values can be defined both globally and for > each rule. When used on a per-rule basis, the values relate to the > number of states created by the rule, otherwise to the total number > of states. > > This handling of adaptive timeouts is done in pf_state_expires(): > > start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; > if (start) { > end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; > states = counter_u64_fetch(state->rule.ptr->states_cur); > } else { > start = V_pf_default_rule.timeout[PFTM_ADAPTIVE_START]; > end = V_pf_default_rule.timeout[PFTM_ADAPTIVE_END]; > states = V_pf_status.states; > } > > The following calculation needs three values: start, end and states. > > 1. Normal rules "pass .." without adaptive setting meaning "start = 0" > runs in the else-section of the code snippet and therefore takes > "start" and "end" from the global default settings and sets > "states" > to pf_status.states (= total number of states). > > 2. Special rules like > "pass .. keep state (adaptive.start 500 adaptive.end 1000)" > have start != 0, run in the if-section of the code snippet and take > "start" and "end" from the rule and set "states" to the number of > states created by their rule using counter_u64_fetch(). > > Thats all ok, but there is a third case without special handling in > the > above code snippet: > > 3. All "rdr/nat pass .." statements use together the pf_default_rule. > Therefore we have "start != 0" in this case and we run the > if-section of the code snippet but we better should run the > else-section in this case and do not fetch the counter of the > pf_default_rule but take the total number of states. > > Thats what the patch does. > Thank you, that makes sense. I’d missed the third case. The patch is in my queue and should get committed soon. Your explanation makes a great commit message. Regards, Kristof