From owner-freebsd-pf@freebsd.org Sun Jan 20 21:00:50 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 741C314A64CE for ; Sun, 20 Jan 2019 21:00:50 +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 10F2E823AB for ; Sun, 20 Jan 2019 21:00:50 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id C989714A64CD; Sun, 20 Jan 2019 21:00:49 +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 B7ED014A64CB for ; Sun, 20 Jan 2019 21:00:49 +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 595F0823A5 for ; Sun, 20 Jan 2019 21:00:49 +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 A2B501EB3A for ; Sun, 20 Jan 2019 21:00:48 +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 x0KL0mrp064147 for ; Sun, 20 Jan 2019 21:00:48 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0KL0m0D064136 for pf@FreeBSD.org; Sun, 20 Jan 2019 21:00:48 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201901202100.x0KL0m0D064136@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, 20 Jan 2019 21:00:48 +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, 20 Jan 2019 21:00:50 -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 Jan 21 18:51:39 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 2BD3A14B36D6 for ; Mon, 21 Jan 2019 18:51:39 +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 A219871941 for ; Mon, 21 Jan 2019 18:51:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 658D014B36D3; Mon, 21 Jan 2019 18:51:38 +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 540EB14B36D1 for ; Mon, 21 Jan 2019 18:51:38 +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 E034871937 for ; Mon, 21 Jan 2019 18:51:37 +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 2DDEFB034 for ; Mon, 21 Jan 2019 18:51:37 +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 x0LIpbub039381 for ; Mon, 21 Jan 2019 18:51:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0LIpbwY039374 for pf@FreeBSD.org; Mon, 21 Jan 2019 18:51:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize Date: Mon, 21 Jan 2019 18:51:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: gonzo@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 21 Jan 2019 18:51:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209475 Oleksandr Tymoshenko changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |gonzo@FreeBSD.org Resolution|--- |FIXED --- Comment #35 from Oleksandr Tymoshenko --- There is a commit referencing this PR, but it's still not closed and has be= en inactive for some time. Closing the PR as fixed but feel free to re-open it= if the issue hasn't been completely resolved. Thanks --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Mon Jan 21 19:17:28 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 9FFB714B46F2 for ; Mon, 21 Jan 2019 19:17:28 +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 3C58572F45 for ; Mon, 21 Jan 2019 19:17:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id F05FB14B46F1; Mon, 21 Jan 2019 19:17:27 +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 DEC9E14B46F0 for ; Mon, 21 Jan 2019 19:17:27 +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 7D64A72F40 for ; Mon, 21 Jan 2019 19:17:27 +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 A25F0B3A7 for ; Mon, 21 Jan 2019 19:17:26 +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 x0LJHQOH024244 for ; Mon, 21 Jan 2019 19:17:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0LJHQRO024243 for pf@FreeBSD.org; Mon, 21 Jan 2019 19:17:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 211796] missing htonl calls in pf range check Date: Mon, 21 Jan 2019 19:17:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gonzo@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 21 Jan 2019 19:17:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211796 Oleksandr Tymoshenko changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |gonzo@FreeBSD.org Resolution|--- |FIXED --- Comment #6 from Oleksandr Tymoshenko --- There is a commit referencing this PR, but it's still not closed and has be= en inactive for some time. Closing the PR as fixed but feel free to re-open it= if the issue hasn't been completely resolved. Thanks --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Mon Jan 21 19:17:39 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 5A27B14B4718 for ; Mon, 21 Jan 2019 19:17:39 +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 DFE0E72F66 for ; Mon, 21 Jan 2019 19:17:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9DC9B14B4716; Mon, 21 Jan 2019 19:17:38 +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 8C55514B4714 for ; Mon, 21 Jan 2019 19:17:38 +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 2C3BF72F64 for ; Mon, 21 Jan 2019 19:17:38 +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 59EA1B3B1 for ; Mon, 21 Jan 2019 19:17:37 +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 x0LJHbRE024501 for ; Mon, 21 Jan 2019 19:17:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0LJHbxv024500 for pf@FreeBSD.org; Mon, 21 Jan 2019 19:17:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 211796] missing htonl calls in pf range check Date: Mon, 21 Jan 2019 19:17:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gonzo@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 21 Jan 2019 19:17:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211796 --- Comment #7 from Oleksandr Tymoshenko --- There is a commit referencing this PR, but it's still not closed and has be= en inactive for some time. Closing the PR as fixed but feel free to re-open it= if the issue hasn't been completely resolved. Thanks --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Tue Jan 22 01:07:47 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 52140149105B for ; Tue, 22 Jan 2019 01:07:47 +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 E00638B61C for ; Tue, 22 Jan 2019 01:07:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A39A81491055; Tue, 22 Jan 2019 01:07:46 +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 9241F1491054 for ; Tue, 22 Jan 2019 01:07:46 +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 2DAE78B618 for ; Tue, 22 Jan 2019 01:07:46 +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 4E851E8FB for ; Tue, 22 Jan 2019 01:07:45 +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 x0M17jjG089501 for ; Tue, 22 Jan 2019 01:07:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0M17jEE089500 for pf@FreeBSD.org; Tue, 22 Jan 2019 01:07:45 GMT (envelope-from bugzilla-noreply@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: [Bug 234874] pf: pfr_update_stats: assertion failed. Date: Tue, 22 Jan 2019 01:07:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 22 Jan 2019 01:07:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234874 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Tue Jan 22 01:07:19 UTC 2019 New revision: 343289 URL: https://svnweb.freebsd.org/changeset/base/343289 Log: MFC r343041 pf: silence a runtime warning Sometimes, for negated tables, pf can log 'pfr_update_stats: assertion failed'. This warning does not clarify anything for users, so silence it, just as OpenBSD has. PR: 234874 Changes: _U stable/12/ stable/12/sys/netpfil/pf/pf_table.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Tue Jan 22 01:07:49 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 904231491076 for ; Tue, 22 Jan 2019 01:07:49 +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 24D518B62E for ; Tue, 22 Jan 2019 01:07:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id DC9481491062; Tue, 22 Jan 2019 01:07:48 +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 C9CFF1491061 for ; Tue, 22 Jan 2019 01:07:48 +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 5E9CD8B62A for ; Tue, 22 Jan 2019 01:07:48 +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 AD6AFE900 for ; Tue, 22 Jan 2019 01:07:47 +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 x0M17lTj089610 for ; Tue, 22 Jan 2019 01:07:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0M17lB7089609 for pf@FreeBSD.org; Tue, 22 Jan 2019 01:07:47 GMT (envelope-from bugzilla-noreply@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: [Bug 234874] pf: pfr_update_stats: assertion failed. Date: Tue, 22 Jan 2019 01:07:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 22 Jan 2019 01:07:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234874 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Tue Jan 22 01:07:20 UTC 2019 New revision: 343290 URL: https://svnweb.freebsd.org/changeset/base/343290 Log: MFC r343041 pf: silence a runtime warning Sometimes, for negated tables, pf can log 'pfr_update_stats: assertion failed'. This warning does not clarify anything for users, so silence it, just as OpenBSD has. PR: 234874 Changes: _U stable/11/ stable/11/sys/netpfil/pf/pf_table.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Tue Jan 22 01:08:46 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 97ED8149111D for ; Tue, 22 Jan 2019 01:08:46 +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 542C08B6AF for ; Tue, 22 Jan 2019 01:08:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 147071491118; Tue, 22 Jan 2019 01:08:46 +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 02D471491116 for ; Tue, 22 Jan 2019 01:08:46 +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 472C28B6A7 for ; Tue, 22 Jan 2019 01:08:45 +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 8F057E901 for ; Tue, 22 Jan 2019 01:08:44 +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 x0M18iQ1090499 for ; Tue, 22 Jan 2019 01:08:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0M18i9E090498 for pf@FreeBSD.org; Tue, 22 Jan 2019 01:08:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 234874] pf: pfr_update_stats: assertion failed. Date: Tue, 22 Jan 2019 01:08:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 22 Jan 2019 01:08:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234874 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Tue Jan 22 22:56:17 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 7487314B2769 for ; Tue, 22 Jan 2019 22:56:17 +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 ECEF5750C6 for ; Tue, 22 Jan 2019 22:56:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B0B4F14B2768; Tue, 22 Jan 2019 22:56:16 +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 9F14714B2767 for ; Tue, 22 Jan 2019 22:56:16 +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 3F021750C3 for ; Tue, 22 Jan 2019 22:56:16 +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 9130F1A907 for ; Tue, 22 Jan 2019 22:56:15 +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 x0MMuFcV069530 for ; Tue, 22 Jan 2019 22:56:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0MMuFXE069529 for pf@FreeBSD.org; Tue, 22 Jan 2019 22:56:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface Date: Tue, 22 Jan 2019 22:56:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vegeta@tuxpowered.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete cc attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 22 Jan 2019 22:56:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229092 Kajetan Staszkiewicz changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194342|0 |1 is obsolete| | CC| |vegeta@tuxpowered.net --- Comment #11 from Kajetan Staszkiewicz --- Created attachment 201346 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D201346&action= =3Dedit Reconstruct interface route by standard fib lookup I found another issue. Even if we can somehow reconstruct route interface, there is still a requirement for having identical ruleset on both routers because it is rule->rt which makes Route-to, Duplicate-to and Reply-to targ= ets work. This information is never kept in state. Attached patch solves this issue by copying rule->rt to state->rt (new fiel= d). Pfsync struct got this field too. Route interface is reconstructed by normal lookup in routing table in fib 0. Warning: for "no state" rules stil rule->rt must be used and I have coded it but not tested. For stateful ruleset all seems fine for route-to target. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Tue Jan 22 23:16:36 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 283A814B2CAF for ; Tue, 22 Jan 2019 23:16:36 +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 B297B7596E for ; Tue, 22 Jan 2019 23:16:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 76B9C14B2CAA; Tue, 22 Jan 2019 23:16:35 +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 6541714B2CA9 for ; Tue, 22 Jan 2019 23:16:35 +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 04AB57596D for ; Tue, 22 Jan 2019 23:16:35 +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 549871ABF9 for ; Tue, 22 Jan 2019 23:16:34 +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 x0MNGYjW043092 for ; Tue, 22 Jan 2019 23:16:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0MNGY4i043091 for pf@FreeBSD.org; Tue, 22 Jan 2019 23:16:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface Date: Tue, 22 Jan 2019 23:16:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 22 Jan 2019 23:16:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229092 --- Comment #12 from Kristof Provost --- (In reply to Kajetan Staszkiewicz from comment #11) Wouldn't the pfcksum protect us from having different rules in the first pl= ace? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Wed Jan 23 08:11: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 7305414BECE4 for ; Wed, 23 Jan 2019 08:11:16 +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 085198F757 for ; Wed, 23 Jan 2019 08:11:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id BD53114BECE3; Wed, 23 Jan 2019 08:11:15 +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 A8AED14BECE2 for ; Wed, 23 Jan 2019 08:11:15 +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 E6D818F751 for ; Wed, 23 Jan 2019 08:11:14 +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 3C3241FA4C for ; Wed, 23 Jan 2019 08:11:14 +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 x0N8BE1A075816 for ; Wed, 23 Jan 2019 08:11:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0N8BEPe075815 for pf@FreeBSD.org; Wed, 23 Jan 2019 08:11:14 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface Date: Wed, 23 Jan 2019 08:11:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vegeta@tuxpowered.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 23 Jan 2019 08:11:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229092 --- Comment #13 from Kajetan Staszkiewicz --- (In reply to Kristof Provost from comment #12) pfcksum only checks if loaded rules are the same, it does not ensure rules = are the same on 2 routers. There are a few ways to have different rulesets, let= me give you a little list I came across while trying to make pfsync work: - Any rule using interface IP addresses in unnamed table {} will end up bei= ng different on 2 routers unless named {} is used. - Same thing for SNAT rules, although I'm unsure if those are included in pfchecksum. - If ruleset is dynamically generated by a script, data structure might not have explicit ordering and produce different result on each run: for me it = was Python and its dictionaries and sets. - In a dynamical environment it might happen that the ruleset is different = for short periods of time when new configuration is applied as it will never be applied at exactly the same time on both routers. For me on some loadbalanc= ers new configuration is applied tens of times a day. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Wed Jan 23 21:52:18 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 DC25314B3B51 for ; Wed, 23 Jan 2019 21:52:18 +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 742F28CFD7 for ; Wed, 23 Jan 2019 21:52:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 31C4F14B3B48; Wed, 23 Jan 2019 21:52:18 +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 203CA14B3B47 for ; Wed, 23 Jan 2019 21:52:18 +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 B15238CFCF for ; Wed, 23 Jan 2019 21:52:17 +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 E8FD074FB for ; Wed, 23 Jan 2019 21:52:16 +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 x0NLqGN6057414 for ; Wed, 23 Jan 2019 21:52:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0NLqGW0057413 for pf@FreeBSD.org; Wed, 23 Jan 2019 21:52:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface Date: Wed, 23 Jan 2019 21:52:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vegeta@tuxpowered.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 23 Jan 2019 21:52:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229092 --- Comment #14 from Kajetan Staszkiewicz --- To sum it up: I don't think it is feasible to have any functionality depend= ing on ruleset being identical. It is really hard to achieve it and it might n= ot be worth the effort. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Wed Jan 23 22:47:45 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 7F11F14B4A5C for ; Wed, 23 Jan 2019 22:47:45 +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 130268ECF9 for ; Wed, 23 Jan 2019 22:47:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C4B3814B4A5B; Wed, 23 Jan 2019 22:47:44 +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 B2ECB14B4A59 for ; Wed, 23 Jan 2019 22:47:44 +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 4AE538ECF8 for ; Wed, 23 Jan 2019 22:47:44 +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 987917C6C for ; Wed, 23 Jan 2019 22:47:43 +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 x0NMlhna097444 for ; Wed, 23 Jan 2019 22:47:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0NMlhog097443 for pf@FreeBSD.org; Wed, 23 Jan 2019 22:47:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface Date: Wed, 23 Jan 2019 22:47:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 23 Jan 2019 22:47:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229092 --- Comment #15 from Kristof Provost --- (In reply to Kajetan Staszkiewicz from comment #13) > - Any rule using interface IP addresses in unnamed table {} will end up b= eing different on 2 routers unless named
{} is used. Ah, because pf generates a random id for the table? I'd argue that that's something the rules sync script (if there is one) should account for, but I= 'd be happy to take patches to make that 'random id' predictable (and consiste= nt across hosts). > - Same thing for SNAT rules, although I'm unsure if those are included in= pfchecksum. I'm not sure what you mean by SNAT rules. The pf_setup_pfsync_matching() function checksums all rules, other than the scrub rules. > - If ruleset is dynamically generated by a script, data structure might n= ot have explicit ordering and produce different result on each run: for me = it was Python and its dictionaries and sets. I don't understand this one. It shouldn't matter how rules are generated, t= he kernel will calculate a checksum. Or do you mean to say pf should compensate for bugs in synchronisation scripts?=20 I don't really see a way around the requirement for the ruleset to be ident= ical on all pfsync synced hosts. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Thu Jan 24 01:11:21 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 8B24414B89E0 for ; Thu, 24 Jan 2019 01:11:21 +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 46D966E9A9 for ; Thu, 24 Jan 2019 01:11:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0A88714B89DC; Thu, 24 Jan 2019 01:11:21 +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 DC52B14B89DA for ; Thu, 24 Jan 2019 01:11:20 +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 98C136E9A1 for ; Thu, 24 Jan 2019 01:11:20 +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 D80259220 for ; Thu, 24 Jan 2019 01:11:19 +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 x0O1BJJB065073 for ; Thu, 24 Jan 2019 01:11:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0O1BJA5065072 for pf@FreeBSD.org; Thu, 24 Jan 2019 01:11:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface Date: Thu, 24 Jan 2019 01:11:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vegeta@tuxpowered.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 24 Jan 2019 01:11:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229092 --- Comment #16 from Kajetan Staszkiewicz --- (In reply to Kristof Provost from comment #15) > (In reply to Kajetan Staszkiewicz from comment #13) > >> - Any rule using interface IP addresses in unnamed table {} will end up= =20 >> being different on 2 routers unless named
{} is used. > > Ah, because pf generates a random id for the table? I think so. > I'd argue that that's > something the rules sync script (if there is one) I don't "sync" rules. I "generate" on central database and upload to loadbalancers. Generated files look identical, line by line. (+/- Python issue, I will comment on it later). > should account for, but I'd Taking that into account is exactly what was needed in my case. Consider such two rules: 1. allow in on $IFACE from { $HOST1 $HOST2 } Table used here is unnamed, anonymous, dynamic or however it is called in the world of pf. There is no guarantee of its name and thus even if configuration is generated centrally, it will result in ruleset having different checksum on each loadbalancer. But is there even any real table used at all? I remember something about dynamically generated table names but what I see is expansion of ruleset during loading into separate rules. e.g. rule: rdr on $if_public inet6 proto ipv6-icmp from any to $if_public -> got expanded to 2 rules: rdr on public inet6 proto ipv6-icmp from any tofe80::6a05:caff:fe0b:dd02 -> round-robin rdr on public inet6 proto ipv6-icmp from any to 2a00:XXXXXX -> round-robin (BTW, expansion to link-local addresses seems a bug to me, I will report it separately). 2. table
{ $HOST1 $HOST2 } pass in on $IFACE from
Here table is named. Ruleset is now consitent between loadbalancers no matter the contents of table. > be happy to take patches to make that 'random id' predictable (and consis= tent > across hosts). Maybe one day but for now I already forced usage of named tables everywhere. >> - Same thing for SNAT rules, although I'm unsure if those are included i= n pfchecksum. > > I'm not sure what you mean by SNAT rules. Sorry, of course I meant NAT rules in pf. I very much prefer nftables terminology of SNAT and DNAT, they just make way more sense. > The pf_setup_pfsync_matching() > function checksums all rules, other than the scrub rules. That just adds one more type of rules that can screw up checksum, as I expected. >> - If ruleset is dynamically generated by a script, data structure might = not=20 >> have explicit ordering and produce different result on each run: for me = it >> was Python and its dictionaries and sets. > > I don't understand this one.=20 Data structures like sets and hashes have no explicit ordering, at least in Python. I think I was getting consistent results with Python 2.7 but totally random when moved to 3.5 Things put to them will be retrieved in some random order. One database of rules will produce functionally identical (at least as long as they are "quick" rules) firewall but with rules in different order. Of course pf can't do anything about it and this is expeced, see next paragraph. > It shouldn't matter how rules are generated, the > kernel will calculate a checksum. Or do you mean to say pf should compens= ate > for bugs=20 That is not a bug. > in synchronisation scripts? No, it definitely should not. All I'm saying that it is another trap I've encountered while fighting with this topic and that it is very hard to make the ruleset identical from point of view of pf and we should not expect identical rulesets. > I don't really see a way around the requirement for the ruleset to be ide= ntical > on all pfsync synced hosts. But is there really such requirement with current status of pf? I think the whole discussion wandered away from the main topic. Let's get back on track. Current situation: 1. Identical pf.conf will result in different checksum in many cases due to interface addresses, dynamic table names and/or rule expansion from unnamed tables. 2. pfsync of normal firewall states which only pass or nat traffic don't need identical ruleset at all. 3. pfsync of states from route/dup/reply-to rules is *fully broken*. Let me repeat once again: none of *working* functionalities of pf seems to require identical ruleset. Maaaaybeee label counters? I want to focus on fixing issue 3. There are multiple aproaches: 1. Old patch which depends on ruleset being identical and reconstructing missing information from rules. 2. New patch which sends part of missing information (state->rt) over pfsync and discovers interface to use from normal route lookup. 3. Modify pfsync structure to io include both state->rt and state->rt_kif. I would *love* to have 3. implemmented but for now I work with 2. because 1. was way too unrealiable. How should we progress? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Thu Jan 24 01:26:11 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 09D1314B9C67 for ; Thu, 24 Jan 2019 01:26:11 +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 94ADB6F897 for ; Thu, 24 Jan 2019 01:26:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5858114B9C61; Thu, 24 Jan 2019 01:26:10 +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 46FB114B9C5F for ; Thu, 24 Jan 2019 01:26:10 +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 DA2A56F895 for ; Thu, 24 Jan 2019 01:26:09 +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 34C8193DB for ; Thu, 24 Jan 2019 01:26:09 +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 x0O1Q9X6095530 for ; Thu, 24 Jan 2019 01:26:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0O1Q9n3095529 for pf@FreeBSD.org; Thu, 24 Jan 2019 01:26:09 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface Date: Thu, 24 Jan 2019 01:26:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 24 Jan 2019 01:26:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229092 --- Comment #17 from Kristof Provost --- Right, for 3. we come back to the compatibility issue. pfsync has to remain able to run with different versions, so while we could potentially extend t= he protocol to include this information we *have* to make sure doing so won't break a host that doesn't understand the new fields. And vice versa: a host which doesn't include the information must be able to send state to a host which expects the extra information. That's probably possible, but it'll need some special care. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Thu Jan 24 13:59: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 DF82E14B0DE7 for ; Thu, 24 Jan 2019 13:59:19 +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 7AA286C736 for ; Thu, 24 Jan 2019 13:59:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3E8B014B0DDC; Thu, 24 Jan 2019 13:59:19 +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 2CEB414B0DDA for ; Thu, 24 Jan 2019 13:59:19 +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 B75676C733 for ; Thu, 24 Jan 2019 13:59:18 +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 16A6910323 for ; Thu, 24 Jan 2019 13:59:18 +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 x0ODxHMx022098 for ; Thu, 24 Jan 2019 13:59:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x0ODxHgL022097 for pf@FreeBSD.org; Thu, 24 Jan 2019 13:59:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: pf@FreeBSD.org Subject: [Bug 229092] [pf] [pfsync] States created by route-to rules pfsynced without interface Date: Thu, 24 Jan 2019 13:59:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vegeta@tuxpowered.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Thu, 24 Jan 2019 13:59:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229092 --- Comment #18 from Kajetan Staszkiewicz --- My 2nd patch stores missing state->rt information in currently unused part = of struct pfsync_state. That should make it compatible. A router running non-patched kernel will simply not transmit any data there when sending sta= tes and ignore all data when receiving them from a patched router. So that part should be safe. What looks potentially unsafe is guessing of target interface. Although it = is already badly broken, as packets are leaving router via route matching destination on unpatched kerel. Is guessing of target interface done correctly? Can I use fib lookup functi= ons just like this? No locking needed? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Thu Jan 24 16:49:58 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 A8A5514B53C9 for ; Thu, 24 Jan 2019 16:49:58 +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 54D08725CB; Thu, 24 Jan 2019 16:49:57 +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 141F9280C1; Thu, 24 Jan 2019 17:49:48 +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 yMbDs99f8zXa; Thu, 24 Jan 2019 17:49:47 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id DBE89280BF; Thu, 24 Jan 2019 17:49:46 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id 8FF66B0; Thu, 24 Jan 2019 17:49:46 +0100 (CET) Message-ID: <5C49ECAA.7060505@incore.de> Date: Thu, 24 Jan 2019 17:49:46 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections References: <5BC51424.5000309@incore.de> <5BD45882.1000207@incore.de> <5BEB3B9A.9080402@incore.de> <20181113222533.GJ9744@FreeBSD.org> In-Reply-To: <20181113222533.GJ9744@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 54D08725CB 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.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.53)[-0.528,0]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-0.96)[-0.961,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[incore.de]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.06)[0.057,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.23), 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: Thu, 24 Jan 2019 16:49:58 -0000 after some more long term research I have an educated guess whats going on in this problem. The problem only occurs on i386. If I replace the counter_u64_fetch() call in pf_state_expires() by the value of V_pf_status.states, then pf works without problems, the expire time zero problem is gone: --- pf.c.1st 2018-08-14 10:17:41.000000000 +0200 +++ pf.c 2019-01-19 17:49:18.000000000 +0100 @@ -1542,7 +1542,7 @@ 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); + states = V_pf_status.states; } else { start = V_pf_default_rule.timeout[PFTM_ADAPTIVE_START]; end = V_pf_default_rule.timeout[PFTM_ADAPTIVE_END]; The use of counter_u64_fetch() looks a little bit at random for me. For all states not associated with the pf_default_rule the value of pf_status.states is used and for me this value is ok for all rules. Further the counter(9) framework was created for quick and lockless write of counters, but fetching is more expansive. So I suggest to let pf_state_expires() work without a counter fetch. Further I can confirm that the counter states_cur of the pf_default_rule remains correct, when the patch given above is active. Without the patch the counter on my main firewall machine gets slowly negative. I have verified this with a lot of live DTrace and kgdb script debugging. >> OK, in the meantime I did some more research and I am now quite sure the >> problem with the bogus pf_default_rule->states_cur counter is not a >> problem in pf. I am convinced it is a problem in counter(9) on i386 >> server. The critical code is the machine instruction cmpxchg8b used in >> /sys/i386/include/counter.h. >> >> From intel instruction set reference manual: >> Zhis instruction can be used with a LOCK prefix allow the instruction to >> be executed atomically. >> >> We have two other sources in kernel using cmpxchg8b: >> /sys/i386/include/atomic.h and >> /sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S > > A single CPU instruction is atomic by definition, with regards to the CPU. > A preemption can not happen in a middle of instruction. What the "lock" > prefix does is memory locking to avoid unlocked parallel access to the > same address by different CPUs. > > What is special about counter(9) is that %fs:%esi always points to a > per-CPU address, because %fs is unique for every CPU and is constant, > so no other CPU may write to this address, so lock prefix isn't needed. > > Of course a true SMP i386 isn't a well tested arch, so I won't assert > that counter(9) doesn't have bugs on this arch. However, I don't see > lock prefix necessary here. I think the problem is the cmpxchg8b instruction used in counter_u64_fetch(), because this machine instruction always writes to memory, also when we only want to read and have (EDX:EAX) = (ECX:EBX): TEMP64 <- DEST IF (EDX:EAX = TEMP64) THEN ZF <- 1 DEST <- ECX:EBX ELSE ZF <- 0 EDX:EAX <- TEMP64 DEST <- TEMP64 FI If one CPU increments the counter in pf_create_state() and another does the fetch, then both CPU's may run the xmpxschg8b at once with the chance that both read the same memory value in TEMP64 and the fetching CPU is the second CPU that writes and so the increment is lossed. Thats what I see without the above patch two or three times a week. Andreas From owner-freebsd-pf@freebsd.org Thu Jan 24 20:37:12 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 2F66214BDAE9 for ; Thu, 24 Jan 2019 20:37:12 +0000 (UTC) (envelope-from byrnejb@harte-lyne.ca) Received: from mx32.harte-lyne.ca (mx32.harte-lyne.ca [216.185.71.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx32.harte-lyne.ca", Issuer "CA_HLL_ISSUER_2016" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1550085EC2 for ; Thu, 24 Jan 2019 20:37:10 +0000 (UTC) (envelope-from byrnejb@harte-lyne.ca) Received: from mx32.harte-lyne.ca (unknown [127.0.32.1]) by mx32.harte-lyne.ca (Postfix) with ESMTP id C3BD53FB3 for ; Thu, 24 Jan 2019 15:37:04 -0500 (EST) X-Virus-Scanned: amavisd-new at harte-lyne.ca Received: from mx32.harte-lyne.ca ([127.0.32.1]) by mx32.harte-lyne.ca (mx32.harte-lyne.ca [127.0.32.1]) (amavisd-new, port 10024) with ESMTP id TUQ5PxR7x_W2 for ; Thu, 24 Jan 2019 15:37:03 -0500 (EST) Received: from webmail.harte-lyne.ca (mx32.harte-lyne.ca [216.185.71.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx32.harte-lyne.ca (Postfix) with ESMTPSA id B789D3FAA for ; Thu, 24 Jan 2019 15:37:02 -0500 (EST) Received: from 216.185.71.44 (SquirrelMail authenticated user byrnejb_hll) by webmail.harte-lyne.ca with HTTP; Thu, 24 Jan 2019 15:37:02 -0500 Message-ID: Date: Thu, 24 Jan 2019 15:37:02 -0500 Subject: routing LAN traffic through/around a pf gateway From: "James B. Byrne" To: freebsd-pf@freebsd.org Reply-To: byrnejb@harte-lyne.ca User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Rspamd-Queue-Id: 1550085EC2 X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.45 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[byrnejb@harte-lyne.ca]; RBL_COMPOSITE_RCVD_IN_DNSWL_MED_DWL_DNSWL_LOW(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.185.71.0/26]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; MX_GOOD(-0.01)[cached: mx31.harte-lyne.ca]; DKIM_TRACE(0.00)[harte-lyne.ca:+]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[32.71.185.216.list.dnswl.org : 127.0.4.2]; DMARC_POLICY_ALLOW(-0.50)[harte-lyne.ca,quarantine]; NEURAL_HAM_SHORT(-0.96)[-0.960,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:12021, ipnet:216.185.64.0/20, country:CA]; IP_SCORE(-3.78)[ip: (-9.91), ipnet: 216.185.64.0/20(-4.95), asn: 12021(-3.96), country: CA(-0.09)]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[harte-lyne.ca:s=dkim_hll]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(0.00)[harte-lyne.ca.dwl.dnswl.org : 127.0.4.1] 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: Thu, 24 Jan 2019 20:37:12 -0000 I have limited knowledge of PF being in the process of transitioning from 20+ years of RHEL/CentOS to FreeBSD. Neither do I possess a great fund of knowledge respecting IP routing. That said this is my problem: On a small test LAN I have three hosts, W44, W4 and G5: network layout, gateway address 216.185.71.5 W44 G5 w4 216.185.71.44 ----> 216.185.71.5 216.185.71.4 int_if IP 192.168.150.44 192.168.150.5 ----> 192.168.150.4 int_if IP alias Using ssh and with PF running on the gateway, when I connect from 216.185.71.44 to 216.185.71.4 then the ssh session operates normally. However, if instead I connect from 216.185.71.44 to 192.168.150.4 then the initial connection is made but the ssh session remains responsive for a brief time before it becomes non-responsive. If I terminate the PF running on the gateway the ssh session again becomes responsive. If I do not terminate PF then eventually the ssh session client disconnects with a timeout error. Besides macros the entire active contents of pf.conf on G5 are: scrub in all no-df max-mss 1440 fragment reassemble block return out log all block drop in log all pass log on $int_if pass inet proto icmp all \ icmp-type $icmp_types keep state pass out quick on $ext_if inet proto udp \ from any \ to any port 33433 >< 33626 keep state Which results in these rules when PF is running: @0 scrub in all no-df max-mss 1440 fragment reassemble @1 block return out log all @2 block drop in log all @3 pass log on em0 all flags S/SA keep state @4 pass inet proto icmp all icmp-type echoreq keep state @5 pass inet proto icmp all icmp-type unreach keep state @6 pass out quick on em1 inet proto udp from any to any port 33433 >< 33626 keep state When the ssh session is non-responsive PF records like this are logged: rule 1/0(match): block in on em0: 216.185.71.44.63394 > 192.168.150.4.22: Flags [P.], seq 2664:2952, ack 6041, win 1030, options [nop,nop,TS val 263607703 ecr 653371936], length 288 My question is: What filter rules will permit the ssh session established as above to remain responsive with PF running on the gateway while maintaining the default block directive for everything else? I am looking for the general case where hosts on the LAN that have multiple IP addresses can communicate with each other using any assigned IP without having PF involved at all, but which are filtered when passing through the gateway or natted to the WAN. Thanks, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 From owner-freebsd-pf@freebsd.org Thu Jan 24 20:38:10 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 C930B14BDB89 for ; Thu, 24 Jan 2019 20:38:10 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 54F6985F52; Thu, 24 Jan 2019 20:38:10 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x0OKc20N003875 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Jan 2019 22:38:05 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x0OKc20N003875 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x0OKc2wj003874; Thu, 24 Jan 2019 22:38:02 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Thu, 24 Jan 2019 22:38:02 +0200 From: Konstantin Belousov To: Andreas Longwitz 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 Message-ID: <20190124203802.GU24863@kib.kiev.ua> References: <5BC51424.5000309@incore.de> <5BD45882.1000207@incore.de> <5BEB3B9A.9080402@incore.de> <20181113222533.GJ9744@FreeBSD.org> <5C49ECAA.7060505@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C49ECAA.7060505@incore.de> User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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: Thu, 24 Jan 2019 20:38:11 -0000 [Keep me in Cc:] On Thu, Jan 24, 2019 at 05:49:46PM +0100, Andreas Longwitz wrote: > after some more long term research I have an educated guess whats going > on in this problem. > > The problem only occurs on i386. > > If I replace the counter_u64_fetch() call in pf_state_expires() by > the value of V_pf_status.states, then pf works without problems, the > expire time zero problem is gone: > > > --- pf.c.1st 2018-08-14 10:17:41.000000000 +0200 > +++ pf.c 2019-01-19 17:49:18.000000000 +0100 > @@ -1542,7 +1542,7 @@ > 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); > + states = V_pf_status.states; > } else { > start = V_pf_default_rule.timeout[PFTM_ADAPTIVE_START]; > end = V_pf_default_rule.timeout[PFTM_ADAPTIVE_END]; > > The use of counter_u64_fetch() looks a little bit at random for me. For > all states not associated with the pf_default_rule the value of > pf_status.states is used and for me this value is ok for all rules. > > Further the counter(9) framework was created for quick and lockless > write of counters, but fetching is more expansive. So I suggest to let > pf_state_expires() work without a counter fetch. > > Further I can confirm that the counter states_cur of the pf_default_rule > remains correct, when the patch given above is active. Without the patch > the counter on my main firewall machine gets slowly negative. I have > verified this with a lot of live DTrace and kgdb script debugging. > > >> OK, in the meantime I did some more research and I am now quite sure the > >> problem with the bogus pf_default_rule->states_cur counter is not a > >> problem in pf. I am convinced it is a problem in counter(9) on i386 > >> server. The critical code is the machine instruction cmpxchg8b used in > >> /sys/i386/include/counter.h. > >> > >> From intel instruction set reference manual: > >> Zhis instruction can be used with a LOCK prefix allow the instruction to > >> be executed atomically. > >> > >> We have two other sources in kernel using cmpxchg8b: > >> /sys/i386/include/atomic.h and > >> /sys/cddl/contrib/opensolaris/common/atomic/i386/opensolaris_atomic.S > > > > A single CPU instruction is atomic by definition, with regards to the CPU. > > A preemption can not happen in a middle of instruction. What the "lock" > > prefix does is memory locking to avoid unlocked parallel access to the > > same address by different CPUs. > > > > What is special about counter(9) is that %fs:%esi always points to a > > per-CPU address, because %fs is unique for every CPU and is constant, > > so no other CPU may write to this address, so lock prefix isn't needed. > > > > Of course a true SMP i386 isn't a well tested arch, so I won't assert > > that counter(9) doesn't have bugs on this arch. However, I don't see > > lock prefix necessary here. > > I think the problem is the cmpxchg8b instruction used in > counter_u64_fetch(), because this machine instruction always writes to > memory, also when we only want to read and have (EDX:EAX) = (ECX:EBX): > > TEMP64 <- DEST > IF (EDX:EAX = TEMP64) > THEN > ZF <- 1 > DEST <- ECX:EBX > ELSE > ZF <- 0 > EDX:EAX <- TEMP64 > DEST <- TEMP64 > FI > > If one CPU increments the counter in pf_create_state() and another does > the fetch, then both CPU's may run the xmpxschg8b at once with the > chance that both read the same memory value in TEMP64 and the fetching > CPU is the second CPU that writes and so the increment is lossed. Thats > what I see without the above patch two or three times a week. Please try the following patch. The idea is to make the value to compare with unlikely to be equal to the memory content, for fetch_one(). Also it fixes a silly bug in zero_one(). diff --git a/sys/i386/include/counter.h b/sys/i386/include/counter.h index 7fd26d2a960..aa20831ba18 100644 --- a/sys/i386/include/counter.h +++ b/sys/i386/include/counter.h @@ -78,6 +78,9 @@ counter_u64_read_one_8b(uint64_t *p) uint32_t res_lo, res_high; __asm __volatile( + "movl (%0),%%eax\n\t" + "movl 4(%0),%%edx\n\t" + "addl $0x10000000,%%edx\n\t" /* avoid write */ "movl %%eax,%%ebx\n\t" "movl %%edx,%%ecx\n\t" "cmpxchg8b (%2)" @@ -120,11 +123,11 @@ counter_u64_zero_one_8b(uint64_t *p) { __asm __volatile( +"\n1:\n\t" "movl (%0),%%eax\n\t" - "movl 4(%0),%%edx\n" + "movl 4(%0),%%edx\n\t" "xorl %%ebx,%%ebx\n\t" "xorl %%ecx,%%ecx\n\t" -"1:\n\t" "cmpxchg8b (%0)\n\t" "jnz 1b" : From owner-freebsd-pf@freebsd.org Thu Jan 24 22:09:41 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 4356114C0745 for ; Thu, 24 Jan 2019 22:09:41 +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 8F21389A66; Thu, 24 Jan 2019 22:09:40 +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 B51CD27D1B; Thu, 24 Jan 2019 23:09:38 +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 bEk9WwUNdRcB; Thu, 24 Jan 2019 23:09:37 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id BCEC327D0B; Thu, 24 Jan 2019 23:09:37 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id 8A6A0196; Thu, 24 Jan 2019 23:09:37 +0100 (CET) Message-ID: <5C4A37A1.80206@incore.de> Date: Thu, 24 Jan 2019 23:09:37 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-pf@freebsd.org CC: Konstantin Belousov , Gleb Smirnoff , Kristof Provost Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections References: <5BC51424.5000309@incore.de> <5BD45882.1000207@incore.de> <5BEB3B9A.9080402@incore.de> <20181113222533.GJ9744@FreeBSD.org> <5C49ECAA.7060505@incore.de> <20190124203802.GU24863@kib.kiev.ua> In-Reply-To: <20190124203802.GU24863@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8F21389A66 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.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: Thu, 24 Jan 2019 22:09:41 -0000 >> I think the problem is the cmpxchg8b instruction used in >> counter_u64_fetch(), because this machine instruction always writes to >> memory, also when we only want to read and have (EDX:EAX) = (ECX:EBX): >> >> TEMP64 <- DEST >> IF (EDX:EAX = TEMP64) >> THEN >> ZF <- 1 >> DEST <- ECX:EBX >> ELSE >> ZF <- 0 >> EDX:EAX <- TEMP64 >> DEST <- TEMP64 >> FI >> >> If one CPU increments the counter in pf_create_state() and another does >> the fetch, then both CPU's may run the xmpxschg8b at once with the >> chance that both read the same memory value in TEMP64 and the fetching >> CPU is the second CPU that writes and so the increment is lossed. Thats >> what I see without the above patch two or three times a week. > > Please try the following patch. The idea is to make the value to compare > with unlikely to be equal to the memory content, for fetch_one(). During my research I first had the same idea, but it did not work. In the actual coding eax/edx is not well defined before cmpxchg8b is executed, but it does not help for the problem to do so. > Also it fixes a silly bug in zero_one(). > > diff --git a/sys/i386/include/counter.h b/sys/i386/include/counter.h > index 7fd26d2a960..aa20831ba18 100644 > --- a/sys/i386/include/counter.h > +++ b/sys/i386/include/counter.h > @@ -78,6 +78,9 @@ counter_u64_read_one_8b(uint64_t *p) > uint32_t res_lo, res_high; > > __asm __volatile( > + "movl (%0),%%eax\n\t" > + "movl 4(%0),%%edx\n\t" > + "addl $0x10000000,%%edx\n\t" /* avoid write */ > "movl %%eax,%%ebx\n\t" > "movl %%edx,%%ecx\n\t" > "cmpxchg8b (%2)" We can not avoid the write done by cmpxchg8b as can be seen from the microcode given above, we always end up with "DEST <- TEMP". From the Intel instruction reference manual: The destination operand is written back if the comparision fails. (The processor never produces a locked read without also producing a locked write). Maybe it is enough to prefix the cmpxchg8b with LOCK only in function counter_u64_read_one_8b(). > @@ -120,11 +123,11 @@ counter_u64_zero_one_8b(uint64_t *p) > { > __asm __volatile( > +"\n1:\n\t" > "movl (%0),%%eax\n\t" > - "movl 4(%0),%%edx\n" > + "movl 4(%0),%%edx\n\t" > "xorl %%ebx,%%ebx\n\t" > "xorl %%ecx,%%ecx\n\t" > -"1:\n\t" > "cmpxchg8b (%0)\n\t" > "jnz 1b" > : If jnz jumps back the instruction cmpxchg8b has load registers eax/edx with (%0), therefor I do not understand the silly bug. Andreas From owner-freebsd-pf@freebsd.org Fri Jan 25 00:32:02 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 5D34F14C49B8 for ; Fri, 25 Jan 2019 00:32:02 +0000 (UTC) (envelope-from srs0=upjq=qb=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 "smtp.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 214A98F2E1 for ; Fri, 25 Jan 2019 00:32:00 +0000 (UTC) (envelope-from srs0=upjq=qb=sigsegv.be=kristof@codepro.be) Received: from [10.193.4.91] (unknown [202.36.179.100]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id C857D8660; Fri, 25 Jan 2019 01:31:50 +0100 (CET) From: "Kristof Provost" To: byrnejb@harte-lyne.ca Cc: freebsd-pf@freebsd.org Subject: Re: routing LAN traffic through/around a pf gateway Date: Fri, 25 Jan 2019 13:31:46 +1300 X-Mailer: MailMate (2.0BETAr6135) Message-ID: <77538042-3448-4C7F-8499-F492A06E52E9@sigsegv.be> In-Reply-To: References: MIME-Version: 1.0 X-Rspamd-Queue-Id: 214A98F2E1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dmarc=fail reason="" header.from=sigsegv.be (policy=none); spf=pass (mx1.freebsd.org: domain of srs0=upjq=qb=sigsegv.be=kristof@codepro.be designates 5.9.86.228 as permitted sender) smtp.mailfrom=srs0=upjq=qb=sigsegv.be=kristof@codepro.be X-Spamd-Result: default: False [-3.67 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[sigsegv.be : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:5.9.86.228]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.74)[-0.742,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[228.86.9.5.list.dnswl.org : 127.0.9.2]; RCPT_COUNT_TWO(0.00)[2]; MX_GOOD(-0.01)[mx2.codepro.be,mx1.codepro.be]; IP_SCORE(-0.82)[ipnet: 5.9.0.0/16(-1.77), asn: 24940(-2.33), country: DE(-0.01)]; FORGED_SENDER(0.30)[kristof@sigsegv.be,srs0=upjq=qb=sigsegv.be=kristof@codepro.be]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:24940, ipnet:5.9.0.0/16, country:DE]; FROM_NEQ_ENVFROM(0.00)[kristof@sigsegv.be,srs0=upjq=qb=sigsegv.be=kristof@codepro.be]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Fri, 25 Jan 2019 00:32:02 -0000 On 25 Jan 2019, at 9:37, James B. Byrne via freebsd-pf wrote: > I have limited knowledge of PF being in the process of transitioning > from 20+ years of RHEL/CentOS to FreeBSD. Neither do I possess a > great fund of knowledge respecting IP routing. That said this is my > problem: > > On a small test LAN I have three hosts, W44, W4 and G5: > > network layout, gateway address 216.185.71.5 > > W44 G5 w4 > 216.185.71.44 ----> 216.185.71.5 216.185.71.4 int_if IP > 192.168.150.44 192.168.150.5 ----> 192.168.150.4 int_if IP alias > > Using ssh and with PF running on the gateway, when I connect from > 216.185.71.44 to 216.185.71.4 then the ssh session operates normally. > However, if instead I connect from 216.185.71.44 to 192.168.150.4 then > the initial connection is made but the ssh session remains responsive > for a brief time before it becomes non-responsive. If I terminate the > PF running on the gateway the ssh session again becomes responsive. > If I do not terminate PF then eventually the ssh session client > disconnects with a timeout error. > > Besides macros the entire active contents of pf.conf on G5 are: > > scrub in all no-df max-mss 1440 fragment reassemble > > block return out log all > > block drop in log all > > pass log on $int_if > > pass inet proto icmp all \ > icmp-type $icmp_types keep state > > pass out quick on $ext_if inet proto udp \ > from any \ > to any port 33433 >< 33626 keep state > > Which results in these rules when PF is running: > > @0 scrub in all no-df max-mss 1440 fragment reassemble > @1 block return out log all > @2 block drop in log all > @3 pass log on em0 all flags S/SA keep state > @4 pass inet proto icmp all icmp-type echoreq keep state > @5 pass inet proto icmp all icmp-type unreach keep state > @6 pass out quick on em1 inet proto udp from any to any port 33433 >< > 33626 keep state > You don’t appear to have a rule permitting the SSH traffic to pass through your router. I’m a more than little surprised you manage to establish a connection in the first place. Unless the connection existed before you started pf, of course. Try adding something like: pass inet porto tcp port 22 Regards, Kristof From owner-freebsd-pf@freebsd.org Fri Jan 25 13:14:18 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 2D6F114B561D for ; Fri, 25 Jan 2019 13:14:18 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 A9D9282F04; Fri, 25 Jan 2019 13:14:17 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x0PDEApu032336 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Jan 2019 15:14:13 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x0PDEApu032336 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x0PDE9Z2032335; Fri, 25 Jan 2019 15:14:09 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Fri, 25 Jan 2019 15:14:09 +0200 From: Konstantin Belousov To: Andreas Longwitz 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 Message-ID: <20190125131409.GZ24863@kib.kiev.ua> References: <5BC51424.5000309@incore.de> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C4A37A1.80206@incore.de> User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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: Fri, 25 Jan 2019 13:14:18 -0000 On Thu, Jan 24, 2019 at 11:09:37PM +0100, Andreas Longwitz wrote: > >> I think the problem is the cmpxchg8b instruction used in > >> counter_u64_fetch(), because this machine instruction always writes to > >> memory, also when we only want to read and have (EDX:EAX) = (ECX:EBX): > >> > >> TEMP64 <- DEST > >> IF (EDX:EAX = TEMP64) > >> THEN > >> ZF <- 1 > >> DEST <- ECX:EBX > >> ELSE > >> ZF <- 0 > >> EDX:EAX <- TEMP64 > >> DEST <- TEMP64 > >> FI > >> > >> If one CPU increments the counter in pf_create_state() and another does > >> the fetch, then both CPU's may run the xmpxschg8b at once with the > >> chance that both read the same memory value in TEMP64 and the fetching > >> CPU is the second CPU that writes and so the increment is lossed. Thats > >> what I see without the above patch two or three times a week. > > > > Please try the following patch. The idea is to make the value to compare > > with unlikely to be equal to the memory content, for fetch_one(). > > During my research I first had the same idea, but it did not work. In > the actual coding eax/edx is not well defined before cmpxchg8b is > executed, but it does not help for the problem to do so. > > > Also it fixes a silly bug in zero_one(). > > > > diff --git a/sys/i386/include/counter.h b/sys/i386/include/counter.h > > index 7fd26d2a960..aa20831ba18 100644 > > --- a/sys/i386/include/counter.h > > +++ b/sys/i386/include/counter.h > > @@ -78,6 +78,9 @@ counter_u64_read_one_8b(uint64_t *p) > > uint32_t res_lo, res_high; > > > > __asm __volatile( > > + "movl (%0),%%eax\n\t" > > + "movl 4(%0),%%edx\n\t" > > + "addl $0x10000000,%%edx\n\t" /* avoid write */ > > "movl %%eax,%%ebx\n\t" > > "movl %%edx,%%ecx\n\t" > > "cmpxchg8b (%2)" > > We can not avoid the write done by cmpxchg8b as can be seen from the > microcode given above, we always end up with "DEST <- TEMP". From the > Intel instruction reference manual: > > The destination operand is written back if the comparision fails. (The > processor never produces a locked read without also producing a locked > write). I see, AMD APM is more clear there, stating that the instruction always do rmw regardless of lock prefix. > > Maybe it is enough to prefix the cmpxchg8b with LOCK only in function > counter_u64_read_one_8b(). I am not sure. Lets switch to IPI method for fetch, similar to clear. I do not think that the cost of fetch is too important comparing with the race. > > > > @@ -120,11 +123,11 @@ counter_u64_zero_one_8b(uint64_t *p) > > { > > __asm __volatile( > > +"\n1:\n\t" > > "movl (%0),%%eax\n\t" > > - "movl 4(%0),%%edx\n" > > + "movl 4(%0),%%edx\n\t" > > "xorl %%ebx,%%ebx\n\t" > > "xorl %%ecx,%%ecx\n\t" > > -"1:\n\t" > > "cmpxchg8b (%0)\n\t" > > "jnz 1b" > > : > > If jnz jumps back the instruction cmpxchg8b has load registers eax/edx > with (%0), therefor I do not understand the silly bug. Ignore me. diff --git a/sys/i386/include/counter.h b/sys/i386/include/counter.h index 7fd26d2a960..278f89123a4 100644 --- a/sys/i386/include/counter.h +++ b/sys/i386/include/counter.h @@ -72,7 +72,12 @@ counter_64_inc_8b(uint64_t *p, int64_t inc) } #ifdef IN_SUBR_COUNTER_C -static inline uint64_t +struct counter_u64_fetch_cx8_arg { + uint64_t res; + uint64_t *p; +}; + +static uint64_t counter_u64_read_one_8b(uint64_t *p) { uint32_t res_lo, res_high; @@ -87,9 +92,22 @@ counter_u64_read_one_8b(uint64_t *p) return (res_lo + ((uint64_t)res_high << 32)); } +static void +counter_u64_fetch_cx8_one(void *arg1) +{ + struct counter_u64_fetch_cx8_arg *arg; + uint64_t val; + + arg = arg1; + val = counter_u64_read_one_8b((uint64_t *)((char *)arg->p + + UMA_PCPU_ALLOC_SIZE * PCPU_GET(cpuid))); + atomic_add_64(&arg->res, val); +} + static inline uint64_t counter_u64_fetch_inline(uint64_t *p) { + struct counter_u64_fetch_cx8_arg arg; uint64_t res; int i; @@ -108,9 +126,10 @@ counter_u64_fetch_inline(uint64_t *p) } critical_exit(); } else { - CPU_FOREACH(i) - res += counter_u64_read_one_8b((uint64_t *)((char *)p + - UMA_PCPU_ALLOC_SIZE * i)); + arg.p = p; + arg.res = 0; + smp_rendezvous(NULL, counter_u64_fetch_cx8_one, NULL, &arg); + res = arg.res; } return (res); } From owner-freebsd-pf@freebsd.org Fri Jan 25 14:17:40 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 0C89114B72C1 for ; Fri, 25 Jan 2019 14:17:40 +0000 (UTC) (envelope-from byrnejb@harte-lyne.ca) Received: from mx32.harte-lyne.ca (mx32.harte-lyne.ca [216.185.71.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx32.harte-lyne.ca", Issuer "CA_HLL_ISSUER_2016" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6307F85B47 for ; Fri, 25 Jan 2019 14:17:29 +0000 (UTC) (envelope-from byrnejb@harte-lyne.ca) Received: from mx32.harte-lyne.ca (unknown [127.0.32.1]) by mx32.harte-lyne.ca (Postfix) with ESMTP id D625144FB; Fri, 25 Jan 2019 09:17:27 -0500 (EST) X-Virus-Scanned: amavisd-new at harte-lyne.ca Received: from mx32.harte-lyne.ca ([127.0.32.1]) by mx32.harte-lyne.ca (mx32.harte-lyne.ca [127.0.32.1]) (amavisd-new, port 10024) with ESMTP id qa2BMkP1sQYa; Fri, 25 Jan 2019 09:17:19 -0500 (EST) Received: from webmail.harte-lyne.ca (mx32.harte-lyne.ca [216.185.71.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx32.harte-lyne.ca (Postfix) with ESMTPSA id 59E1344F0; Fri, 25 Jan 2019 09:17:18 -0500 (EST) Received: from 216.185.71.44 (SquirrelMail authenticated user byrnejb_hll) by webmail.harte-lyne.ca with HTTP; Fri, 25 Jan 2019 09:17:19 -0500 Message-ID: In-Reply-To: <77538042-3448-4C7F-8499-F492A06E52E9@sigsegv.be> References: <77538042-3448-4C7F-8499-F492A06E52E9@sigsegv.be> Date: Fri, 25 Jan 2019 09:17:19 -0500 Subject: Re: routing LAN traffic through/around a pf gateway From: "James B. Byrne" To: "Kristof Provost" Cc: byrnejb@harte-lyne.ca, freebsd-pf@freebsd.org Reply-To: byrnejb@harte-lyne.ca User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Rspamd-Queue-Id: 6307F85B47 X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[byrnejb@harte-lyne.ca]; RBL_COMPOSITE_RCVD_IN_DNSWL_MED_DWL_DNSWL_LOW(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.185.71.0/26]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[harte-lyne.ca:+]; RCVD_IN_DNSWL_MED(-0.20)[32.71.185.216.list.dnswl.org : 127.0.4.2]; HAS_X_PRIO_THREE(0.00)[3]; MX_GOOD(-0.01)[mx32.harte-lyne.ca,mx31.harte-lyne.ca,mx132.harte-lyne.ca]; DMARC_POLICY_ALLOW(-0.50)[harte-lyne.ca,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:12021, ipnet:216.185.64.0/20, country:CA]; IP_SCORE(-3.78)[ip: (-9.91), ipnet: 216.185.64.0/20(-4.95), asn: 12021(-3.96), country: CA(-0.09)]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[harte-lyne.ca:s=dkim_hll]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(0.00)[harte-lyne.ca.dwl.dnswl.org : 127.0.4.1]; TO_MATCH_ENVRCPT_SOME(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: Fri, 25 Jan 2019 14:17:40 -0000 On Thu, January 24, 2019 19:31, Kristof Provost wrote: > > > On 25 Jan 2019, at 9:37, James B. Byrne via freebsd-pf wrote: > >> I have limited knowledge of PF being in the process of transitioning >> from 20+ years of RHEL/CentOS to FreeBSD. Neither do I possess a >> great fund of knowledge respecting IP routing. That said this is my >> problem: >> >> On a small test LAN I have three hosts, W44, W4 and G5: >> >> network layout, gateway address 216.185.71.5 >> >> W44 G5 w4 >> 216.185.71.44 ----> 216.185.71.5 216.185.71.4 int_if IP >> 192.168.150.44 192.168.150.5 ----> 192.168.150.4 int_if IP >> alias >> >> Using ssh and with PF running on the gateway, when I connect from >> 216.185.71.44 to 216.185.71.4 then the ssh session operates >> normally. >> However, if instead I connect from 216.185.71.44 to 192.168.150.4 >> then >> the initial connection is made but the ssh session remains >> responsive >> for a brief time before it becomes non-responsive. If I terminate >> the >> PF running on the gateway the ssh session again becomes responsive. >> If I do not terminate PF then eventually the ssh session client >> disconnects with a timeout error. >> >> Besides macros the entire active contents of pf.conf on G5 are: >> >> scrub in all no-df max-mss 1440 fragment reassemble >> >> block return out log all >> >> block drop in log all >> >> pass log on $int_if >> >> pass inet proto icmp all \ >> icmp-type $icmp_types keep state >> >> pass out quick on $ext_if inet proto udp \ >> from any \ >> to any port 33433 >< 33626 keep state >> >> Which results in these rules when PF is running: >> >> @0 scrub in all no-df max-mss 1440 fragment reassemble >> @1 block return out log all >> @2 block drop in log all >> @3 pass log on em0 all flags S/SA keep state >> @4 pass inet proto icmp all icmp-type echoreq keep state >> @5 pass inet proto icmp all icmp-type unreach keep state >> @6 pass out quick on em1 inet proto udp from any to any port 33433 >> >< >> 33626 keep state >> > You don’t appear to have a rule permitting the SSH traffic to pass > through your router. > I’m a more than little surprised you manage to establish a > connection > in the first place. > Unless the connection existed before you started pf, of course. > > Try adding something like: > pass inet porto tcp port 22 > > Regards, > Kristof -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3