From owner-freebsd-pf@freebsd.org Sun Oct 21 00:39:29 2018 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 2F619FFBF94 for ; Sun, 21 Oct 2018 00:39:29 +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 C06C771F3B for ; Sun, 21 Oct 2018 00:39:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 850FFFFBF93; Sun, 21 Oct 2018 00:39:28 +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 73CC9FFBF92 for ; Sun, 21 Oct 2018 00:39:28 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F243371F38 for ; Sun, 21 Oct 2018 00:39: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 497EF1DC26 for ; Sun, 21 Oct 2018 00:39:27 +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 w9L0dRIB014813 for ; Sun, 21 Oct 2018 00:39:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9L0dRIl014812 for pf@FreeBSD.org; Sun, 21 Oct 2018 00:39:27 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 201695] [PATCH] pf.conf syntax (interface:0) incorrectly results in IPv6 link-local address Date: Sun, 21 Oct 2018 00:39:27 +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.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many 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: cc 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: Sun, 21 Oct 2018 00:39:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D201695 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kp@freebsd.org --- Comment #1 from Kristof Provost --- Reviews: https://reviews.freebsd.org/D17633 https://reviews.freebsd.org/D17634 I think this makes sense, but it's a behaviour change, so I'd like to think about this a bit more before I commit it. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Sun Oct 21 21:00:34 2018 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 DAC161008867 for ; Sun, 21 Oct 2018 21:00:34 +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 7995777947 for ; Sun, 21 Oct 2018 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3CA721008866; Sun, 21 Oct 2018 21:00:34 +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 2B0861008864 for ; Sun, 21 Oct 2018 21:00:34 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2B5377941 for ; Sun, 21 Oct 2018 21:00:33 +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 0045948B for ; Sun, 21 Oct 2018 21:00:33 +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 w9LL0WHU077027 for ; Sun, 21 Oct 2018 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9LL0Wex077019 for pf@FreeBSD.org; Sun, 21 Oct 2018 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201810212100.w9LL0Wex077019@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, 21 Oct 2018 21:00:32 +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, 21 Oct 2018 21:00:35 -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 Sun Oct 21 21:18:44 2018 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 08F781036BB8 for ; Sun, 21 Oct 2018 21:18:44 +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 BB3FE791F3 for ; Sun, 21 Oct 2018 21:18:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7B08C1036BB2; Sun, 21 Oct 2018 21:18:43 +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 694F21036BB1 for ; Sun, 21 Oct 2018 21:18:43 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9F05791ED for ; Sun, 21 Oct 2018 21:18:42 +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 083BE83D for ; Sun, 21 Oct 2018 21:18:42 +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 w9LLIfmY075546 for ; Sun, 21 Oct 2018 21:18:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9LLIfo6075540 for pf@FreeBSD.org; Sun, 21 Oct 2018 21:18:41 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 122773] [pf] pf doesn't log uid or pid when configured to Date: Sun, 21 Oct 2018 21:18:42 +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: 7.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal 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: Sun, 21 Oct 2018 21:18:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D122773 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Sun Oct 21 21:17:43 UTC 2018 New revision: 339557 URL: https://svnweb.freebsd.org/changeset/base/339557 Log: tcpdump: Log uid on pflog interfaces If pf logs the user id ('pass out log (user)') have tcpdump also print this. Example output: 00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 57539, offset 0, flags [none], proto UDP (17), length 55) 172.16.2.2.18337 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x16e4!] 40222+ A? google.be. (27) PR: 122773 Differential Revision: https://reviews.freebsd.org/D17625 Changes: head/contrib/tcpdump/print-pflog.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Mon Oct 22 04:13:52 2018 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 C4EF9FE83A3 for ; Mon, 22 Oct 2018 04:13:52 +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 5DD2D86E8D for ; Mon, 22 Oct 2018 04:13:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 23427FE83A2; Mon, 22 Oct 2018 04:13:52 +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 12011FE83A0 for ; Mon, 22 Oct 2018 04:13:52 +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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1B6286E8B for ; Mon, 22 Oct 2018 04:13:51 +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 EF07744E4 for ; Mon, 22 Oct 2018 04:13:50 +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 w9M4DoX8018440 for ; Mon, 22 Oct 2018 04:13:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9M4DosC018439 for pf@FreeBSD.org; Mon, 22 Oct 2018 04:13:50 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 201520] Wrong Error Line Number Given by PF syntax checker Date: Mon, 22 Oct 2018 04:13:51 +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: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many 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: Mon, 22 Oct 2018 04:13:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D201520 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Mon Oct 22 04:12:51 UTC 2018 New revision: 339578 URL: https://svnweb.freebsd.org/changeset/base/339578 Log: pfctl: Fix line numbers when \ is used inside "" PR: 201520 Obtained from: OpenBSD MFC after: 2 weeks Changes: head/sbin/pfctl/parse.y --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Wed Oct 24 13:12:21 2018 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 3702B107AF3C for ; Wed, 24 Oct 2018 13:12:21 +0000 (UTC) (envelope-from donotreplytothismail@gmx.com) Received: from SUNSTUDIO (unknown [128.199.213.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E4668968F for ; Wed, 24 Oct 2018 13:12:19 +0000 (UTC) (envelope-from donotreplytothismail@gmx.com) Message-ID: From: "Mark Chen" (Mark Chen) To: freebsd-pf@freebsd.org Subject: RE: Satellite Broadband Internet Modem IP freebsd-pf@freebsd.org Date: 24 Oct 2018 20:08:15 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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: Wed, 24 Oct 2018 13:12:21 -0000 From owner-freebsd-pf@freebsd.org Sat Oct 27 12:22:39 2018 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 B74FE10ED8FD for ; Sat, 27 Oct 2018 12:22:39 +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 293168FA63 for ; Sat, 27 Oct 2018 12:22:38 +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 69C93139A5; Sat, 27 Oct 2018 14:22:28 +0200 (CEST) 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 PrdFTlJ0Xk4E; Sat, 27 Oct 2018 14:22:26 +0200 (CEST) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id D0F0B139A0; Sat, 27 Oct 2018 14:22:26 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id 974AC1B0; Sat, 27 Oct 2018 14:22:26 +0200 (CEST) Message-ID: <5BD45882.1000207@incore.de> Date: Sat, 27 Oct 2018 14:22:26 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Kristof Provost CC: 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 12:22:39 -0000 Thanks very much for answer especially for the hint to openbsd. > I wonder if there’s an integer overflow in the of_state_expires() > calculation. > The OpenBSD people have a cast to u_int64_t in their version: > > |timeout = (u_int64_t)timeout * (end - states) / (end - start); > | > > Perhaps this would fix your problem? (Untested, not even compiled) > > | if (end && states > start && start < end) { > if (states < end) { > timeout = (uint64_t)timeout * (end - states) / (end - start); > return (state->expire + timeout; > } > else > return (time_uptime); > } > return (state->expire + timeout); I can confirm the patch of the openbsd people adding the uint64_t cast makes sense. If timeout * (end - states) becomes bigger than UINT32_MAX (I am on i386) the cast prevents the overflow of this product and the result of the adaptive calculation will always be correct. Example: start=6000, end=12000, timeout=86400 * 5 (5 days), states=100 result 140972, result with cast patch 856800. In the problem I have reported for states of "rdr pass" rules I see start=6000, end=12000, timeout=86400 and (obviously erroneous, probably negative) states=0xffffffd0. Therefore the condition "states < end" is false and instead of doing the adaptive calculation the function pf_states_expires() returns time_update. In the code snippet start = state->rule.ptr->timeout[PFTM_ADAPTIVE_START]; if (start) { end = state->rule.ptr->timeout[PFTM_ADAPTIVE_END]; states = counter_u64_fetch(state->rule.ptr->states_cur); } else { start = V_pf_default_rule.timeout[PFTM_ADAPTIVE_START]; end = V_pf_default_rule.timeout[PFTM_ADAPTIVE_END]; states = V_pf_status.states; } I see start=6000, so the variable states with value 0xffffffd0 is hold in a counter variable. Based on these facts there are two questions (please notice I have not any adaptive statements in my pf.conf): 1. Why I see start=6000 for states of "rdr pass" rules ? For all states of filter rules I see always start=0 and therefore a counter variable is never used. 2, The counter variable states_cur is changed exclusiv by the macros STATE_INC/DEC_COUNTERS, why one of them can be negative ? The answer of question 1 I can give myself: All states of filter rules include a pointer to the underlying rule which includes counter variables too. A state of a "rdr pass" rule does not have such an underlying rule, so the global pf_default_rule is used. That means in the first line of the code snippet above we have state->rule.ptr == pf_default_rule and the value of timeout[PFTM_ADAPTIVE_END] indeed is initialized with 6000. Further the counter variable for states_cur of pf_default_rule is used für all "rdr/nat/binat pass" rules together. This was a little bit suprising for me, but I think this is intended behaviour. Correct ? I still don't have an answer for question 2. My problem is best described in the log of commit 263029: Once pf became not covered by a single mutex, many counters in it became race prone. Some just gather statistics, but some are later used in different calculations. A real problem was the race provoked underflow of the states_cur counter on a rule. Once it goes below zero, it wraps to UINT32_MAX. Later this value is used in pf_state_expires() and any state created by this rule is immediately expired. Thus, make fields states_cur, states_tot and src_nodes of struct pf_rule be counter(9)s. I run FreeBSD 10 r338093 and of course have this and the following commits included. Are there any hints why the counter pf_default_rule->states_cur could get a negative value ? --- Andreas Longwitz From owner-freebsd-pf@freebsd.org Sat Oct 27 17:44:40 2018 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 88D4E10CDC62 for ; Sat, 27 Oct 2018 17:44:40 +0000 (UTC) (envelope-from srs0=g08q=nh=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 200717424F for ; Sat, 27 Oct 2018 17:44:40 +0000 (UTC) (envelope-from srs0=g08q=nh=sigsegv.be=kristof@codepro.be) Received: from [192.168.12.245] (96-68-179-129-static.hfc.comcastbusiness.net [96.68.179.129]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id BEC1220969; Sat, 27 Oct 2018 19:44:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1540662277; bh=lMwauA84OSqJT5+q97dKwYhnKExgZszfX9fLDgo56z8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=RKiNxk9fZV5OBl/a3nwVjM3r2M/FxV3zPKU6l6aFe/uY2m+pAjwOPcnQS5d5zcIgc ZFnjyRLvPGi2swc8IVrDFdLWfYQMSKT80rP5aDNI1D1zKmoE7VsXtvN0oE33Q7DELY Tw+72XLfxI5pCEjCi0bRwPF1WsLYwSi0+QMcaBLE= From: "Kristof Provost" To: "Andreas Longwitz" Cc: freebsd-pf@freebsd.org Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections Date: Sat, 27 Oct 2018 10:44:31 -0700 X-Mailer: MailMate (2.0BETAr6123) Message-ID: In-Reply-To: <5BD45882.1000207@incore.de> References: <5BC51424.5000309@incore.de> <5BD45882.1000207@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 17:44:40 -0000 On 27 Oct 2018, at 5:22, Andreas Longwitz wrote: > Thanks very much for answer especially for the hint to openbsd. > >> I wonder if there’s an integer overflow in the of_state_expires() >> calculation. >> The OpenBSD people have a cast to u_int64_t in their version: >> >> |timeout = (u_int64_t)timeout * (end - states) / (end - start); >> | >> >> Perhaps this would fix your problem? (Untested, not even compiled) >> >> | if (end && states > start && start < end) { >> if (states < end) { >> timeout = (uint64_t)timeout * (end - states) / >> (end - start); >> return (state->expire + timeout; >> } >> else >> return (time_uptime); >> } >> return (state->expire + timeout); > > I can confirm the patch of the openbsd people adding the uint64_t cast > makes sense. If > timeout * (end - states) > becomes bigger than UINT32_MAX (I am on i386) the cast prevents the > overflow of this product and the result of the adaptive calculation > will > always be correct. > > Example: start=6000, end=12000, timeout=86400 * 5 (5 days), states=100 > result 140972, result with cast patch 856800. > > In the problem I have reported for states of "rdr pass" rules I see > start=6000, end=12000, timeout=86400 and (obviously erroneous, > probably > negative) states=0xffffffd0. > I have no idea how that can happen. Just to make sure I understand: you know that states is negative here because of a printf() or SDT addition in pf_expire_states(), right? > Further the counter variable for states_cur of pf_default_rule is > used für all "rdr/nat/binat pass" rules together. This was a little > bit > suprising for me, but I think this is intended behaviour. Correct ? > Yes. > Are there any hints why the counter pf_default_rule->states_cur > could get a negative value ? > I’m afraid I have no idea right now. Best regards, Kristof From owner-freebsd-pf@freebsd.org Sat Oct 27 21:48:38 2018 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 2A71210D5129 for ; Sat, 27 Oct 2018 21:48:38 +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 921A77D0C7 for ; Sat, 27 Oct 2018 21:48:37 +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 46B1D139AC; Sat, 27 Oct 2018 23:48:35 +0200 (CEST) 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 hkzOknWXRACS; Sat, 27 Oct 2018 23:48:34 +0200 (CEST) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 15DF7139A5; Sat, 27 Oct 2018 23:48:34 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id E8C40117; Sat, 27 Oct 2018 23:48:33 +0200 (CEST) Message-ID: <5BD4DD31.409@incore.de> Date: Sat, 27 Oct 2018 23:48:33 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Kristof Provost CC: 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 21:48:38 -0000 > In the problem I have reported for states of "rdr pass" rules I see > start=6000, end=12000, timeout=86400 and (obviously erroneous, probably > negative) states=0xffffffd0. > > I have no idea how that can happen. Just to make sure I understand: you > know that states is negative here because of a printf() or SDT addition > in pf_expire_states(), right? I did not change the kernel, I use DTrace on my firewall server fwextern. In pf.conf I have changed all productive "rdr pass" rules to a rdr rule and an extra filter rule. Now only one "rdr pass" rule is left for test: rdr pass on $if_internet proto tcp from 31.17.172.227 to $ip_internet port 8022 -> 10.0.0.254 Now I start the following DTrace script pfcounter.d, which will be active when a SYN on port 8022 arrives: #!/usr/sbin/dtrace -s fbt::pf_normalize_tcp:entry /((*(args[2]->m_hdr.mh_data + 33)) & 0x02) == 0x02 && htons(*(short *)(args[2]->m_hdr.mh_data + 22)) == 8022/ /* SYN + port 8022 */ { self->flag1 = 1; } fbt::pf_test:return /self->flag1/ { self->flag1 = 0; } fbt::pfioctl:entry /args[1] == 3221767193 && ((struct pfioc_states *)args[2])->ps_len != 0/ /* DIOCGETSTATES && len != 0 */ { self->flag2 = 1; } fbt::counter_u64_fetch:entry /self->flag2/ { } fbt::counter_u64_fetch:return /self->flag2/ { printf(" returncode (states_cur)=%d / 0x%x", args[1], args[1]); } fbt::pfioctl:return /self->flag2/ { self->flag2 = 0; } Now I run on my remote test client (IP 31.17.172.227) the command ssh -p 8022 fwextern sleep 20 This creates on fwextern a state for the "rdr pass" rule with expire time zero. I must be quick to run "pfctl -vss" on fwextern to see this state and the output of the DTrace script shows me the "negative" value of the counter: === root@fwextern (pts/0) -> ./pfcounter.d dtrace: script './pfcounter.d' matched 6 probes CPU ID FUNCTION:NAME 3 17624 counter_u64_fetch:entry 3 17625 counter_u64_fetch:return returncode (states_cur)=4294967248 / 0xffffffd0 If I run on the test client the ssh command twice, then the counter is one less negative than before: === root@fwextern (pts/0) -> ./pfcounter.d dtrace: script './pfcounter.d' matched 6 probes CPU ID FUNCTION:NAME 3 17624 counter_u64_fetch:entry 3 17625 counter_u64_fetch:return returncode (states_cur)=4294967249 / 0xffffffd1 3 17624 counter_u64_fetch:entry 3 17625 counter_u64_fetch:return returncode (states_cur)=4294967249 / 0xffffffd1 Because of "sleep 20" the ssh command does not return and must be killed. I have observed the problem on two of my firewall servers, the pf rules never were reloaded since boot. I think there must be an unknown event in the past, that triggered the negative counter value. I will try to add a statement to the kernel that recognizes the problem and go back to the "rdr pass" rules, so next time the problem occurres we have more information than now. Kindly regards, Andreas