From owner-freebsd-net@freebsd.org Sun Jul 7 17:43:58 2019 Return-Path: Delivered-To: freebsd-net@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 2FF9D15E9937 for ; Sun, 7 Jul 2019 17:43:58 +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 DEE2569B81 for ; Sun, 7 Jul 2019 17:43:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9A72315E9931; Sun, 7 Jul 2019 17:43:57 +0000 (UTC) Delivered-To: net@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 8915115E9930 for ; Sun, 7 Jul 2019 17:43:57 +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 22B5569B7D for ; Sun, 7 Jul 2019 17:43:57 +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 66710426 for ; Sun, 7 Jul 2019 17:43:56 +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 x67HhugQ073607 for ; Sun, 7 Jul 2019 17:43:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x67HhujH073606 for net@FreeBSD.org; Sun, 7 Jul 2019 17:43:56 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: net@FreeBSD.org Subject: [Bug 238789] panic: mutex so_rcv not owned at /usr/src/sys/kern/uipc_socket.c:2359 Date: Sun, 07 Jul 2019 17:43:56 +0000 X-Bugzilla-Reason: CC 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: needs-qa, panic X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: markj@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 17:43:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238789 --- Comment #9 from commit-hook@freebsd.org --- A commit references this bug: Author: markj Date: Sun Jul 7 17:43:15 UTC 2019 New revision: 349810 URL: https://svnweb.freebsd.org/changeset/base/349810 Log: MFC r349599: Fix handling of errors from sblock() in soreceive_stream(). PR: 238789 Changes: _U stable/12/ stable/12/sys/kern/uipc_socket.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jul 7 17:44:00 2019 Return-Path: Delivered-To: freebsd-net@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 AC10C15E994D for ; Sun, 7 Jul 2019 17:44:00 +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 412F169B94 for ; Sun, 7 Jul 2019 17:44:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0530515E9946; Sun, 7 Jul 2019 17:44:00 +0000 (UTC) Delivered-To: net@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 E68E915E9944 for ; Sun, 7 Jul 2019 17:43:59 +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 8190B69B90 for ; Sun, 7 Jul 2019 17:43:59 +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 C038342B for ; Sun, 7 Jul 2019 17:43:58 +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 x67HhwUH073634 for ; Sun, 7 Jul 2019 17:43:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x67Hhw7U073633 for net@FreeBSD.org; Sun, 7 Jul 2019 17:43:58 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: net@FreeBSD.org Subject: [Bug 238789] panic: mutex so_rcv not owned at /usr/src/sys/kern/uipc_socket.c:2359 Date: Sun, 07 Jul 2019 17:43:58 +0000 X-Bugzilla-Reason: CC 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: needs-qa, panic X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: markj@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 17:44:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238789 --- Comment #10 from commit-hook@freebsd.org --- A commit references this bug: Author: markj Date: Sun Jul 7 17:43:45 UTC 2019 New revision: 349811 URL: https://svnweb.freebsd.org/changeset/base/349811 Log: MFC r349599: Fix handling of errors from sblock() in soreceive_stream(). PR: 238789 Changes: _U stable/11/ stable/11/sys/kern/uipc_socket.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jul 7 17:44:15 2019 Return-Path: Delivered-To: freebsd-net@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 DD09C15E9985 for ; Sun, 7 Jul 2019 17:44:15 +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 840C069C06 for ; Sun, 7 Jul 2019 17:44:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 486AF15E9981; Sun, 7 Jul 2019 17:44:15 +0000 (UTC) Delivered-To: net@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 35A7D15E997F for ; Sun, 7 Jul 2019 17:44: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 C225A69BF4 for ; Sun, 7 Jul 2019 17:44: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 1675842F for ; Sun, 7 Jul 2019 17:44: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 x67HiDr2073979 for ; Sun, 7 Jul 2019 17:44:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x67HiDRj073978 for net@FreeBSD.org; Sun, 7 Jul 2019 17:44:13 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: net@FreeBSD.org Subject: [Bug 238789] panic: mutex so_rcv not owned at /usr/src/sys/kern/uipc_socket.c:2359 Date: Sun, 07 Jul 2019 17:44:14 +0000 X-Bugzilla-Reason: CC 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: needs-qa, panic X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: markj@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 17:44:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238789 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Open |Closed --- Comment #11 from Mark Johnston --- Thanks for the report. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Jul 7 21:01:14 2019 Return-Path: Delivered-To: freebsd-net@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 5C16615C9DFA for ; Sun, 7 Jul 2019 21:01:14 +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 15B2D74FD9 for ; Sun, 7 Jul 2019 21:01:14 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id CD9F615C9DF6; Sun, 7 Jul 2019 21:01:13 +0000 (UTC) Delivered-To: net@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 A8A8F15C9DF2 for ; Sun, 7 Jul 2019 21:01:13 +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 24D2F74FBF for ; Sun, 7 Jul 2019 21:01:13 +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 08B6A2095 for ; Sun, 7 Jul 2019 21:01:12 +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 x67L1BtY047075 for ; Sun, 7 Jul 2019 21:01:11 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x67L1BQo047066 for net@FreeBSD.org; Sun, 7 Jul 2019 21:01:11 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201907072101.x67L1BQo047066@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: net@FreeBSD.org Subject: Problem reports for net@FreeBSD.org that need special attention Date: Sun, 7 Jul 2019 21:01:11 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 21:01:14 -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 ------------+-----------+--------------------------------------------------- In Progress | 221146 | [ixgbe] Problem with second laggport In Progress | 235700 | oce(4) driver causes fatal trap 12 on boot with e New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 213410 | [carp] service netif restart causes hang only whe Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 200319 | Bridge+CARP crashes/freezes Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 222273 | igb(4): Kernel panic (fatal trap 12) due to netwo Open | 225438 | panic in6_unlink_ifa() due to race Open | 227720 | Kernel panic in ppp server Open | 233952 | jme NICs non functional after 11.2 to 12.0 upgrad Open | 236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open | 236983 | bnxt(4) VLAN not operational unless explicit "ifc Open | 237072 | netgraph(4): performance issue [on HardenedBSD]? Open | 237391 | route get returns no result for network addresses Open | 237840 | Removed dummynet dependency on ipfw 18 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Jul 7 21:21:34 2019 Return-Path: Delivered-To: freebsd-net@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 0753315CB1A2 for ; Sun, 7 Jul 2019 21:21: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 9665176181 for ; Sun, 7 Jul 2019 21:21:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5141215CB1A1; Sun, 7 Jul 2019 21:21:33 +0000 (UTC) Delivered-To: net@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 3FAC915CB1A0 for ; Sun, 7 Jul 2019 21:21:33 +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 D38D07617C for ; Sun, 7 Jul 2019 21:21:32 +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 35B1F24C7 for ; Sun, 7 Jul 2019 21:21:32 +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 x67LLWve040750 for ; Sun, 7 Jul 2019 21:21:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x67LLWpM040739 for net@FreeBSD.org; Sun, 7 Jul 2019 21:21:32 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: net@FreeBSD.org Subject: [Bug 238839] ipfilter: kernel panic in function ipf_check_wrapper Date: Sun, 07 Jul 2019 21:21:32 +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: panic X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 21:21:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238839 Cy Schubert changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|net@FreeBSD.org |cy@FreeBSD.org --- Comment #2 from Cy Schubert --- > The IP Filter module is custom built that been applied patches from bug #= 238796 > and https://sourceforge.net/p/hacking-freebsd/freebsd-patches/ci/m= aster > /tree/10.3/ipfilter-local-output-tcp-checksum.diff Please try this without your custom patches. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jul 8 10:38:02 2019 Return-Path: Delivered-To: freebsd-net@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 E675615DAC32 for ; Mon, 8 Jul 2019 10:38:01 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40DB096DEE for ; Mon, 8 Jul 2019 10:38:00 +0000 (UTC) (envelope-from devgs@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id:Cc:To :Subject:From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=h18U2K79tsFA52TfwAIX83Z2HrSK+7wn9MaSl+27u6U=; b=q xbG3Pa12V44ohQTt8wLXaO3cWoCzZgkOyEHkC3bFOFXoiYpg7EKDFBBEN+m6o94LoQw8APOKjyYJB X1+BzQjyb+IfBt49kKLdjJblGPa+PjYO/S6ntCgNUFfE17Go3DUN9OpfIpeCIdT65u/lmoooaghVv 7pxdJ+use2FMJNwo=; Received: from [10.10.10.39] (helo=frv39.fwdcdn.com) by frv196.fwdcdn.com with smtp ID 1hkR1q-000Ane-Uj for freebsd-net@freebsd.org; Mon, 08 Jul 2019 13:37:50 +0300 Date: Mon, 08 Jul 2019 13:37:50 +0300 From: Paul Subject: Issues with TCP Timestamps allocation To: Michael Tuexen , freebsd-net@freebsd.org Received: from devgs@ukr.net by frv39.fwdcdn.com; Mon, 08 Jul 2019 13:37:50 +0300 Message-Id: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 40DB096DEE X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=q xbG3Pa; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of devgs@ukr.net designates 212.42.77.196 as permitted sender) smtp.mailfrom=devgs@ukr.net X-Spamd-Result: default: False [-5.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24]; FREEMAIL_FROM(0.00)[ukr.net]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.63)[ipnet: 212.42.77.0/24(-4.55), asn: 8856(-3.69), country: UA(0.08)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_SPAM_SHORT(0.11)[0.112,0]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; MX_GOOD(-0.01)[mxs.ukr.net]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 10:38:02 -0000 Hi team, Recently we had an upgrade to 12 Stable. Immediately after, we have started seeing some strange connection establishment timeouts to some fixed number of external (world) hosts. The issue was persistent and easy to reproduce. Thanks to a patience and dedication of our system engineer we have tracked this issue down to a specific commit: https://svnweb.freebsd.org/base?view=revision&revision=338053 This patch was also back-ported into 11 Stable: https://svnweb.freebsd.org/base?view=revision&revision=348435 Among other things this patch changes the timestamp allocation strategy, by introducing a deterministic randomness via a hash function that takes into account a random key as well as source address, source port, dest address and dest port. As the result, timestamp offsets of different tuples (SA,SP,DA,DP) will be wildly different and will jump from small to large numbers and back, as long as something in the tuple changes. After performing various tests of hosts that produce the above mentioned issue we came to conclusion that there are some interesting implementations that drop SYN packets with timestamps smaller than the largest timestamp value from streams of all recent or current connections from a specific address. This looks as some kind of SYN flood protection. To ensure that each external host is not going to see a wild jumps of timestamp values I propose a patch that removes ports from the equation all together, when calculating the timestamp offset: Index: sys/netinet/tcp_subr.c =================================================================== --- sys/netinet/tcp_subr.c (revision 348435) +++ sys/netinet/tcp_subr.c (working copy) @@ -2224,7 +2224,22 @@ uint32_t tcp_new_ts_offset(struct in_conninfo *inc) { - return (tcp_keyed_hash(inc, V_ts_offset_secret)); + /* + * Some implementations show a strange behaviour when a wildly random + * timestamps allocated for different streams. It seems that only the + * SYN packets are affected. Observed implementations drop SYN packets + * with timestamps smaller than the largest timestamp value of all + * recent or current connections from specific a address. To mitigate + * this we are going to ensure that each host will always observe + * timestamps as increasing no matter the stream: by dropping ports + * from the equation. + */ + struct in_conninfo inc_copy = *inc; + + inc_copy.inc_fport = 0; + inc_copy.inc_lport = 0; + + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret)); } /* In any case, the solution of the uptime leak, implemented in rev338053 is not going to suffer, because a supposed attacker is currently able to use any fixed values of SP and DP, albeit not 0, anyway, to remove them out of the equation. There is the list of example hosts that we were able to reproduce the issue with: curl -v http://88.99.60.171:80 curl -v http://163.172.71.252:80 curl -v http://5.9.242.150:80 curl -v https://185.134.205.105:443 curl -v https://136.243.1.231:443 curl -v https://144.76.196.4:443 curl -v http://94.127.191.194:80 To reproduce, call curl repeatedly with a same URL some number of times. You are going to see some of the requests stuck in `* Trying XXX.XXX.XXX.XXX...` For some reason, the easiest way to reproduce the issue is with nc: $ echo "foooooo" | nc -v 88.99.60.171 80 Only a few such calls are required until one of them is stuck on connect(): issuing SYN packets with an exponential backoff. From owner-freebsd-net@freebsd.org Mon Jul 8 12:26:43 2019 Return-Path: Delivered-To: freebsd-net@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 D350215DD6B7 for ; Mon, 8 Jul 2019 12:26:42 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward103j.mail.yandex.net (forward103j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::106]) (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 3CEBC6BEF5 for ; Mon, 8 Jul 2019 12:26:41 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback17j.mail.yandex.net (mxback17j.mail.yandex.net [IPv6:2a02:6b8:0:1619::93]) by forward103j.mail.yandex.net (Yandex) with ESMTP id EF69667400B2; Mon, 8 Jul 2019 15:26:30 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback17j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 0MpV5cm7RA-QUsKRB0Z; Mon, 08 Jul 2019 15:26:30 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1562588790; bh=0T3kcUvnTEZpKsOjaQme9ONvpRKXrxqW+bDPbSCglcE=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=Yj69O0+xcgM5ErHZefz+RxjvkIl1sESXDY+sCfl0EiyRZ6og3dZMBUyuLF8FMx1rt VARaz7xWMn37Q3z/CKGWJjt228Q8Ec4+q9xAUZ1hqUQOK3emGCnSSuySUEFmPajStG SpNmKB8uJdJ87z6dtnrP3INTtqH+++Qxh1vPQcec= Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id yBOE7anyex-QU4eFOjJ; Mon, 08 Jul 2019 15:26:30 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: How to set up ipfw(8) NAT between an alias and the main IP address, when the alias is in another network? To: Yuri , "freebsd-net@freebsd.org" References: <8e388abc-f2ac-b070-cf86-a4d3971ac095@rawbw.com> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= mQENBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAG0JUFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT6JATgEEwECACIFAkwB F1kCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAHF6gQQyKF6qmYIAI6ekfm1VA4T vqankI1ISE6ku4jV7UlpIQlEbE7/8n3Zd6teJ+pGOQhN5qk8QE7utdPdbktAzi+x7LIJVzUw 4TywZLXGrkP7VKYkfg6oyCGyzITghefQeJtr2TN4hYCkzPWpylkue8MtmqfZv/6royqwTbN+ +E09FQNvTgRUYJYTeQ1qOsxNRycwvw3dr2rOfuxShbzaHBB1pBIjGrMg8fC5pd65ACH5zuFV A0CoTNGMDrEZSfBkTW604UUHFFXeCoC3dwDZRKOWJ3GmMXns65Ai5YkA63BSHEE1Qle3VBhd cG1w0CB5FBV3pB27UVnf0jEbysrDqW4qN7XMRFSWNAy5AQ0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAYkBHwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <8c0f4366-f3e3-dbd6-c8e3-6644951c40d7@yandex.ru> Date: Mon, 8 Jul 2019 15:23:43 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8e388abc-f2ac-b070-cf86-a4d3971ac095@rawbw.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pVX86c9KJZ2d6995nUtQOJyUTxraDAORf" X-Rspamd-Queue-Id: 3CEBC6BEF5 X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=Yj69O0+x; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 2a02:6b8:0:801:2::106 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-9.69 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0::/52]; FREEMAIL_FROM(0.00)[yandex.ru]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[yandex.ru:+]; MX_GOOD(-0.01)[mx.yandex.ru,mx.yandex.ru,mx.yandex.ru,mx.yandex.ru,mx.yandex.ru]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; SIGNED_PGP(-2.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[6.0.1.0.0.0.0.0.0.0.0.0.2.0.0.0.1.0.8.0.0.0.0.0.8.b.6.0.2.0.a.2.list.dnswl.org : 127.0.5.1]; MIME_TRACE(0.00)[0:+,1:+,2:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_LOW(-1.00)[yandex.ru.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.51)[ip: (-9.15), ipnet: 2a02:6b8::/32(-4.65), asn: 13238(-3.73), country: RU(0.01)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 12:26:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pVX86c9KJZ2d6995nUtQOJyUTxraDAORf Content-Type: multipart/mixed; boundary="U0yERktjwO716mcUZzWzmKt44OwVdEngr"; protected-headers="v1" From: "Andrey V. Elsukov" To: Yuri , "freebsd-net@freebsd.org" Message-ID: <8c0f4366-f3e3-dbd6-c8e3-6644951c40d7@yandex.ru> Subject: Re: How to set up ipfw(8) NAT between an alias and the main IP address, when the alias is in another network? References: <8e388abc-f2ac-b070-cf86-a4d3971ac095@rawbw.com> In-Reply-To: <8e388abc-f2ac-b070-cf86-a4d3971ac095@rawbw.com> --U0yERktjwO716mcUZzWzmKt44OwVdEngr Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06.07.2019 11:01, Yuri wrote: > My network interface looks like this: > $fw nat 1 config redirect_addr 192.168.100.2 192.168.1.2 redirect_addr > 192.168.1.2 192.168.100.2 if sk0 unreg_only reset >=20 > $fw add 1001 nat 1 tcp from 192.168.100.2/32 to any via sk0 keep-state >=20 > $fw add 1002 check-state >=20 >=20 > The rule 1001 has keep-state, therefore it should process both outgoing= > tcp and incoming response packets. But the outbound packets are NATted,= > but the inbound ones are not. >=20 > What is wrong, and how to fix this script? 'keep-state' creates state for TCP connection that is not yet translated, thus it won't handle the reply packet, that has translated address/port. --=20 WBR, Andrey V. Elsukov --U0yERktjwO716mcUZzWzmKt44OwVdEngr-- --pVX86c9KJZ2d6995nUtQOJyUTxraDAORf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl0jNdAACgkQAcXqBBDI oXqSiQf9HgbJEsSBjVUXhGLwDkUEiJvFZbZ/hA6MMxEq2s7xxy+L9RvJ9XWEsu82 r8FRwpFk2RNtGFyUoYUk9hUCSLx8Ukt3RMoaUb8un3XEYZIzzlraa+z0il59UCm0 pxr4KVM3I/1fFpn6TrlwV0OL/ZvzI3DzQoMqZvUvAUydYChPDSVbtOc02GL2zFNx UACQCRwU5yohxFmKmU6F2T6lzmrGn4kGz1DvdSFZGp2GdQEAKJFSPeLH0apopyMW aM7DzteMgQcfthq8fb2/KKSdA3XD6v1ZHHFVlY1nVXBpIwGqzk5V8hdt9O1jGk6V oLQ500Ldj9oPFovfpU0Jw16qxDUkdg== =wl+Y -----END PGP SIGNATURE----- --pVX86c9KJZ2d6995nUtQOJyUTxraDAORf-- From owner-freebsd-net@freebsd.org Mon Jul 8 12:53:17 2019 Return-Path: Delivered-To: freebsd-net@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 0CC6715DDFE1 for ; Mon, 8 Jul 2019 12:53:17 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 840356CF5A for ; Mon, 8 Jul 2019 12:53:16 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2a02:c6a0:4015:12:f4a0:506f:aa54:cf8] (unknown [IPv6:2a02:c6a0:4015:12:f4a0:506f:aa54:cf8]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id DD372721E281A; Mon, 8 Jul 2019 14:53:11 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Issues with TCP Timestamps allocation From: Michael Tuexen In-Reply-To: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> Date: Mon, 8 Jul 2019 14:53:11 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <32FD061B-245C-41D2-81DE-1B4756A7173D@freebsd.org> References: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> To: Paul X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Status: No, score=-1.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 12:53:17 -0000 > On 8. Jul 2019, at 12:37, Paul wrote: >=20 > Hi team, >=20 > Recently we had an upgrade to 12 Stable. Immediately after, we have = started=20 > seeing some strange connection establishment timeouts to some fixed = number > of external (world) hosts. The issue was persistent and easy to = reproduce. > Thanks to a patience and dedication of our system engineer we have = tracked =20 > this issue down to a specific commit: >=20 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D338053 >=20 > This patch was also back-ported into 11 Stable: >=20 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D348435 >=20 > Among other things this patch changes the timestamp allocation = strategy, > by introducing a deterministic randomness via a hash function that = takes > into account a random key as well as source address, source port, dest > address and dest port. As the result, timestamp offsets of different > tuples (SA,SP,DA,DP) will be wildly different and will jump from small=20= > to large numbers and back, as long as something in the tuple changes. Hi Paul, this is correct. Please note that the same happens with the old method, if two hosts with different uptimes are bind a consumer grade NAT. >=20 > After performing various tests of hosts that produce the above = mentioned=20 > issue we came to conclusion that there are some interesting = implementations=20 > that drop SYN packets with timestamps smaller than the largest = timestamp=20 > value from streams of all recent or current connections from a = specific=20 > address. This looks as some kind of SYN flood protection. This also breaks multiple hosts with different uptimes behind a consumer level NAT talking to such a server. >=20 > To ensure that each external host is not going to see a wild jumps of=20= > timestamp values I propose a patch that removes ports from the = equation > all together, when calculating the timestamp offset: >=20 > Index: sys/netinet/tcp_subr.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/netinet/tcp_subr.c (revision 348435) > +++ sys/netinet/tcp_subr.c (working copy) > @@ -2224,7 +2224,22 @@ > uint32_t > tcp_new_ts_offset(struct in_conninfo *inc) > { > - return (tcp_keyed_hash(inc, V_ts_offset_secret)); > + /*=20 > + * Some implementations show a strange behaviour when a = wildly random=20 > + * timestamps allocated for different streams. It seems that = only the > + * SYN packets are affected. Observed implementations drop = SYN packets > + * with timestamps smaller than the largest timestamp value = of all=20 > + * recent or current connections from specific a address. To = mitigate=20 > + * this we are going to ensure that each host will always = observe=20 > + * timestamps as increasing no matter the stream: by dropping = ports > + * from the equation. > + */=20 > + struct in_conninfo inc_copy =3D *inc; > + > + inc_copy.inc_fport =3D 0; > + inc_copy.inc_lport =3D 0; > + > + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret)); > } >=20 > /* >=20 > In any case, the solution of the uptime leak, implemented in rev338053 = is=20 > not going to suffer, because a supposed attacker is currently able to = use=20 > any fixed values of SP and DP, albeit not 0, anyway, to remove them = out=20 > of the equation. Can you describe how a peer can compute the uptime from two observed = timestamps? I don't see how you can do that... >=20 > There is the list of example hosts that we were able to reproduce the=20= > issue with: >=20 > curl -v http://88.99.60.171:80 > curl -v http://163.172.71.252:80 > curl -v http://5.9.242.150:80 > curl -v https://185.134.205.105:443 > curl -v https://136.243.1.231:443 > curl -v https://144.76.196.4:443 > curl -v http://94.127.191.194:80 >=20 > To reproduce, call curl repeatedly with a same URL some number of = times.=20 > You are going to see some of the requests stuck in=20 > `* Trying XXX.XXX.XXX.XXX...` >=20 > For some reason, the easiest way to reproduce the issue is with nc: >=20 > $ echo "foooooo" | nc -v 88.99.60.171 80 >=20 > Only a few such calls are required until one of them is stuck on = connect(): > issuing SYN packets with an exponential backoff. Thanks for providing an end-point to test with. I'll take a look. Just to be clear: You are running a FreeBSD client against one of the = above servers and experience the problem with the new timestamp computations. You are not running arbitrary clients against a FreeBSD server... Best regards Michael From owner-freebsd-net@freebsd.org Mon Jul 8 13:24:32 2019 Return-Path: Delivered-To: freebsd-net@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 1730615DEBE3 for ; Mon, 8 Jul 2019 13:24:32 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from frv197.fwdcdn.com (frv197.fwdcdn.com [212.42.77.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A206B6EA98 for ; Mon, 8 Jul 2019 13:24:31 +0000 (UTC) (envelope-from devgs@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VMd+HYnoIukSLUvZ4GXKpjI9metc2Ka/Hnqa6yJdrYQ=; b=pvFC2ZGvh/RkQzn1J8Tbky7DyF WyZVxHwKEBy/RazQwKwmALXm1v3TNM6KWEGsmR16jhmMqlhDCpWZDIQdkyDVXxwWGRIds3oER1xmc EJGckx60Ba537o3ZCIT1DlcrgYnqMZcNO9oKFxAUHClJp+SyyudlitKiB22ulOJuwJsw=; Received: from [10.10.10.39] (helo=frv39.fwdcdn.com) by frv197.fwdcdn.com with smtp ID 1hkTd0-000PQD-Rg for freebsd-net@freebsd.org; Mon, 08 Jul 2019 16:24:22 +0300 Date: Mon, 08 Jul 2019 16:24:22 +0300 From: Paul Subject: Re[2]: Issues with TCP Timestamps allocation To: Michael Tuexen Cc: freebsd-net@freebsd.org Received: from devgs@ukr.net by frv39.fwdcdn.com; Mon, 08 Jul 2019 16:24:22 +0300 In-Reply-To: <32FD061B-245C-41D2-81DE-1B4756A7173D@freebsd.org> References: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> <32FD061B-245C-41D2-81DE-1B4756A7173D@freebsd.org> X-Reply-Action: reply Message-Id: <1562591379.369129000.gpmxvurq@frv39.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: A206B6EA98 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 13:24:32 -0000 Hi Michael, 8 July 2019, 15:53:15, by "Michael Tuexen" : > > On 8. Jul 2019, at 12:37, Paul wrote: > > > > Hi team, > > > > Recently we had an upgrade to 12 Stable. Immediately after, we have started > > seeing some strange connection establishment timeouts to some fixed number > > of external (world) hosts. The issue was persistent and easy to reproduce. > > Thanks to a patience and dedication of our system engineer we have tracked > > this issue down to a specific commit: > > > > https://svnweb.freebsd.org/base?view=revision&revision=338053 > > > > This patch was also back-ported into 11 Stable: > > > > https://svnweb.freebsd.org/base?view=revision&revision=348435 > > > > Among other things this patch changes the timestamp allocation strategy, > > by introducing a deterministic randomness via a hash function that takes > > into account a random key as well as source address, source port, dest > > address and dest port. As the result, timestamp offsets of different > > tuples (SA,SP,DA,DP) will be wildly different and will jump from small > > to large numbers and back, as long as something in the tuple changes. > Hi Paul, > > this is correct. > > Please note that the same happens with the old method, if two hosts with > different uptimes are bind a consumer grade NAT. If NAT does not replace timestamps then yes, it should be the case. > > > > After performing various tests of hosts that produce the above mentioned > > issue we came to conclusion that there are some interesting implementations > > that drop SYN packets with timestamps smaller than the largest timestamp > > value from streams of all recent or current connections from a specific > > address. This looks as some kind of SYN flood protection. > This also breaks multiple hosts with different uptimes behind a consumer > level NAT talking to such a server. > > > > To ensure that each external host is not going to see a wild jumps of > > timestamp values I propose a patch that removes ports from the equation > > all together, when calculating the timestamp offset: > > > > Index: sys/netinet/tcp_subr.c > > =================================================================== > > --- sys/netinet/tcp_subr.c (revision 348435) > > +++ sys/netinet/tcp_subr.c (working copy) > > @@ -2224,7 +2224,22 @@ > > uint32_t > > tcp_new_ts_offset(struct in_conninfo *inc) > > { > > - return (tcp_keyed_hash(inc, V_ts_offset_secret)); > > + /* > > + * Some implementations show a strange behaviour when a wildly random > > + * timestamps allocated for different streams. It seems that only the > > + * SYN packets are affected. Observed implementations drop SYN packets > > + * with timestamps smaller than the largest timestamp value of all > > + * recent or current connections from specific a address. To mitigate > > + * this we are going to ensure that each host will always observe > > + * timestamps as increasing no matter the stream: by dropping ports > > + * from the equation. > > + */ > > + struct in_conninfo inc_copy = *inc; > > + > > + inc_copy.inc_fport = 0; > > + inc_copy.inc_lport = 0; > > + > > + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret)); > > } > > > > /* > > > > In any case, the solution of the uptime leak, implemented in rev338053 is > > not going to suffer, because a supposed attacker is currently able to use > > any fixed values of SP and DP, albeit not 0, anyway, to remove them out > > of the equation. > Can you describe how a peer can compute the uptime from two observed timestamps? > I don't see how you can do that... Supposed attacker could run a script that continuously monitors timestamps, for example via a periodic TCP connection from a fixed local port (eg 12345) and a fixed local address to the fixed victim's address and port (eg 80). Whenever large discrepancy is observed, attacker can assume that reboot has happened (due to V_ts_offset_secret re-generation), hence the received timestamp is considered an approximate point of reboot from which the uptime can be calculated, until the next reboot and so on. > > > > There is the list of example hosts that we were able to reproduce the > > issue with: > > > > curl -v http://88.99.60.171:80 > > curl -v http://163.172.71.252:80 > > curl -v http://5.9.242.150:80 > > curl -v https://185.134.205.105:443 > > curl -v https://136.243.1.231:443 > > curl -v https://144.76.196.4:443 > > curl -v http://94.127.191.194:80 > > > > To reproduce, call curl repeatedly with a same URL some number of times. > > You are going to see some of the requests stuck in > > `* Trying XXX.XXX.XXX.XXX...` > > > > For some reason, the easiest way to reproduce the issue is with nc: > > > > $ echo "foooooo" | nc -v 88.99.60.171 80 > > > > Only a few such calls are required until one of them is stuck on connect(): > > issuing SYN packets with an exponential backoff. > Thanks for providing an end-point to test with. I'll take a look. > Just to be clear: You are running a FreeBSD client against one of the above > servers and experience the problem with the new timestamp computations. > > You are not running arbitrary clients against a FreeBSD server... We are talking about FreeBSD being the client. Peers that yield this unwanted behaviour are unknown. Little bit of tinkering showed that some of them run Debian: telnet 88.99.60.171 22 Trying 88.99.60.171... Connected to 88.99.60.171. Escape character is '^]'. SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 > > Best regards > Michael > > From owner-freebsd-net@freebsd.org Mon Jul 8 14:12:27 2019 Return-Path: Delivered-To: freebsd-net@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 69F0A15DF99F for ; Mon, 8 Jul 2019 14:12:27 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1940702AD for ; Mon, 8 Jul 2019 14:12:26 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2003:cd:6f26:600:6826:686e:91bf:a40d] (p200300CD6F2606006826686E91BFA40D.dip0.t-ipconnect.de [IPv6:2003:cd:6f26:600:6826:686e:91bf:a40d]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 4DBD1721E281A; Mon, 8 Jul 2019 16:12:17 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Issues with TCP Timestamps allocation From: Michael Tuexen In-Reply-To: <1562591379.369129000.gpmxvurq@frv39.fwdcdn.com> Date: Mon, 8 Jul 2019 16:12:16 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> <32FD061B-245C-41D2-81DE-1B4756A7173D@freebsd.org> <1562591379.369129000.gpmxvurq@frv39.fwdcdn.com> To: Paul X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Status: No, score=-1.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: C1940702AD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 14:12:27 -0000 > On 8. Jul 2019, at 15:24, Paul wrote: >=20 > Hi Michael, >=20 > 8 July 2019, 15:53:15, by "Michael Tuexen" : >=20 >>> On 8. Jul 2019, at 12:37, Paul wrote: >>>=20 >>> Hi team, >>>=20 >>> Recently we had an upgrade to 12 Stable. Immediately after, we have = started=20 >>> seeing some strange connection establishment timeouts to some fixed = number >>> of external (world) hosts. The issue was persistent and easy to = reproduce. >>> Thanks to a patience and dedication of our system engineer we have = tracked =20 >>> this issue down to a specific commit: >>>=20 >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D338053 >>>=20 >>> This patch was also back-ported into 11 Stable: >>>=20 >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D348435 >>>=20 >>> Among other things this patch changes the timestamp allocation = strategy, >>> by introducing a deterministic randomness via a hash function that = takes >>> into account a random key as well as source address, source port, = dest >>> address and dest port. As the result, timestamp offsets of different >>> tuples (SA,SP,DA,DP) will be wildly different and will jump from = small=20 >>> to large numbers and back, as long as something in the tuple = changes. >> Hi Paul, >>=20 >> this is correct. >>=20 >> Please note that the same happens with the old method, if two hosts = with >> different uptimes are bind a consumer grade NAT. >=20 > If NAT does not replace timestamps then yes, it should be the case. >=20 >>>=20 >>> After performing various tests of hosts that produce the above = mentioned=20 >>> issue we came to conclusion that there are some interesting = implementations=20 >>> that drop SYN packets with timestamps smaller than the largest = timestamp=20 >>> value from streams of all recent or current connections from a = specific=20 >>> address. This looks as some kind of SYN flood protection. >> This also breaks multiple hosts with different uptimes behind a = consumer >> level NAT talking to such a server. >>>=20 >>> To ensure that each external host is not going to see a wild jumps = of=20 >>> timestamp values I propose a patch that removes ports from the = equation >>> all together, when calculating the timestamp offset: >>>=20 >>> Index: sys/netinet/tcp_subr.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/netinet/tcp_subr.c (revision 348435) >>> +++ sys/netinet/tcp_subr.c (working copy) >>> @@ -2224,7 +2224,22 @@ >>> uint32_t >>> tcp_new_ts_offset(struct in_conninfo *inc) >>> { >>> - return (tcp_keyed_hash(inc, V_ts_offset_secret)); >>> + /*=20 >>> + * Some implementations show a strange behaviour when a = wildly random=20 >>> + * timestamps allocated for different streams. It seems = that only the >>> + * SYN packets are affected. Observed implementations drop = SYN packets >>> + * with timestamps smaller than the largest timestamp value = of all=20 >>> + * recent or current connections from specific a address. = To mitigate=20 >>> + * this we are going to ensure that each host will always = observe=20 >>> + * timestamps as increasing no matter the stream: by = dropping ports >>> + * from the equation. >>> + */=20 >>> + struct in_conninfo inc_copy =3D *inc; >>> + >>> + inc_copy.inc_fport =3D 0; >>> + inc_copy.inc_lport =3D 0; >>> + >>> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret)); >>> } >>>=20 >>> /* >>>=20 >>> In any case, the solution of the uptime leak, implemented in = rev338053 is=20 >>> not going to suffer, because a supposed attacker is currently able = to use=20 >>> any fixed values of SP and DP, albeit not 0, anyway, to remove them = out=20 >>> of the equation. >> Can you describe how a peer can compute the uptime from two observed = timestamps? >> I don't see how you can do that... >=20 > Supposed attacker could run a script that continuously monitors = timestamps, > for example via a periodic TCP connection from a fixed local port (eg = 12345)=20 > and a fixed local address to the fixed victim's address and port (eg = 80). > Whenever large discrepancy is observed, attacker can assume that = reboot has=20 > happened (due to V_ts_offset_secret re-generation), hence the received=20= > timestamp is considered an approximate point of reboot from which the = uptime > can be calculated, until the next reboot and so on. Ahh, I see. The patch we are talking about is not intended to protect = against continuous monitoring, which is something you can always do. You could = even watch for service availability and detect reboots. A change of the local = key would also look similar to a reboot without a temporary loss of = connectivity. Thanks for the clarification. >=20 >>>=20 >>> There is the list of example hosts that we were able to reproduce = the=20 >>> issue with: >>>=20 >>> curl -v http://88.99.60.171:80 >>> curl -v http://163.172.71.252:80 >>> curl -v http://5.9.242.150:80 >>> curl -v https://185.134.205.105:443 >>> curl -v https://136.243.1.231:443 >>> curl -v https://144.76.196.4:443 >>> curl -v http://94.127.191.194:80 >>>=20 >>> To reproduce, call curl repeatedly with a same URL some number of = times.=20 >>> You are going to see some of the requests stuck in=20 >>> `* Trying XXX.XXX.XXX.XXX...` >>>=20 >>> For some reason, the easiest way to reproduce the issue is with nc: >>>=20 >>> $ echo "foooooo" | nc -v 88.99.60.171 80 >>>=20 >>> Only a few such calls are required until one of them is stuck on = connect(): >>> issuing SYN packets with an exponential backoff. >> Thanks for providing an end-point to test with. I'll take a look. >> Just to be clear: You are running a FreeBSD client against one of the = above >> servers and experience the problem with the new timestamp = computations. >>=20 >> You are not running arbitrary clients against a FreeBSD server... >=20 > We are talking about FreeBSD being the client. Peers that yield this = unwanted > behaviour are unknown. Little bit of tinkering showed that some of = them run=20 > Debian: >=20 > telnet 88.99.60.171 22 > Trying 88.99.60.171... > Connected to 88.99.60.171. > Escape character is '^]'. > SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 Also some are hosted by Hetzner, but not all. I'll will look into this tomorrow, since I'm on a deadline today (well it is 2am tomorrow morning, to be precise)... Best regards Michael=20 >=20 >=20 >>=20 >> Best regards >> Michael >>=20 >>=20 From owner-freebsd-net@freebsd.org Mon Jul 8 15:22:43 2019 Return-Path: Delivered-To: freebsd-net@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 DE1D715E14E5 for ; Mon, 8 Jul 2019 15:22:42 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from frv196.fwdcdn.com (frv196.fwdcdn.com [212.42.77.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D14E573629 for ; Mon, 8 Jul 2019 15:22:41 +0000 (UTC) (envelope-from devgs@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=9dvi4ZtW9kSLFJrtLyS7tEGPO/k5vmcMAbwvDMBhl/M=; b=m0GOmK4uoHVPIODMMGQ71waKuM v6d30CFeJ0nbdB5g3M4e1syVgeYD4aaRyizUSqei6SKyvVHwvcHWZGYYkJ2SLPTVj1L8BuULG3jGa cA28Aj9mrQT57xdMXXdSUyW8gX3LBM7klpFkU3ddpjel84G8b3hqqa7NTXS5NJw3Chok=; Received: from [10.10.10.39] (helo=frv39.fwdcdn.com) by frv196.fwdcdn.com with smtp ID 1hkVTS-000PyN-Qa for freebsd-net@freebsd.org; Mon, 08 Jul 2019 18:22:38 +0300 Date: Mon, 08 Jul 2019 18:22:38 +0300 From: Paul Subject: Re[2]: Issues with TCP Timestamps allocation To: Michael Tuexen Cc: freebsd-net@freebsd.org Received: from devgs@ukr.net by frv39.fwdcdn.com; Mon, 08 Jul 2019 18:22:38 +0300 In-Reply-To: References: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> <32FD061B-245C-41D2-81DE-1B4756A7173D@freebsd.org> <1562591379.369129000.gpmxvurq@frv39.fwdcdn.com> X-Reply-Action: reply Message-Id: <1562599181.734953000.1l9a1d23@frv39.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: D14E573629 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ukr.net header.s=ffe header.b=m0GOmK4u; dmarc=pass (policy=none) header.from=ukr.net; spf=pass (mx1.freebsd.org: domain of devgs@ukr.net designates 212.42.77.196 as permitted sender) smtp.mailfrom=devgs@ukr.net X-Spamd-Result: default: False [-6.51 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ukr.net:s=ffe]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.42.77.0/24]; FREEMAIL_FROM(0.00)[ukr.net]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-1.65)[ipnet: 212.42.77.0/24(-4.61), asn: 8856(-3.73), country: UA(0.08)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DWL_DNSWL_LOW(-1.00)[ukr.net.dwl.dnswl.org : 127.0.5.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ukr.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[ukr.net,none]; MX_GOOD(-0.01)[cached: mxs.ukr.net]; NEURAL_HAM_SHORT(-0.85)[-0.852,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[ukr.net]; ASN(0.00)[asn:8856, ipnet:212.42.77.0/24, country:UA]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 15:22:43 -0000 8 July 2019, 17:12:21, by "Michael Tuexen" : > > On 8. Jul 2019, at 15:24, Paul wrote: > > > > Hi Michael, > > > > 8 July 2019, 15:53:15, by "Michael Tuexen" : > > > >>> On 8. Jul 2019, at 12:37, Paul wrote: > >>> > >>> Hi team, > >>> > >>> Recently we had an upgrade to 12 Stable. Immediately after, we have started > >>> seeing some strange connection establishment timeouts to some fixed number > >>> of external (world) hosts. The issue was persistent and easy to reproduce. > >>> Thanks to a patience and dedication of our system engineer we have tracked > >>> this issue down to a specific commit: > >>> > >>> https://svnweb.freebsd.org/base?view=revision&revision=338053 > >>> > >>> This patch was also back-ported into 11 Stable: > >>> > >>> https://svnweb.freebsd.org/base?view=revision&revision=348435 > >>> > >>> Among other things this patch changes the timestamp allocation strategy, > >>> by introducing a deterministic randomness via a hash function that takes > >>> into account a random key as well as source address, source port, dest > >>> address and dest port. As the result, timestamp offsets of different > >>> tuples (SA,SP,DA,DP) will be wildly different and will jump from small > >>> to large numbers and back, as long as something in the tuple changes. > >> Hi Paul, > >> > >> this is correct. > >> > >> Please note that the same happens with the old method, if two hosts with > >> different uptimes are bind a consumer grade NAT. > > > > If NAT does not replace timestamps then yes, it should be the case. > > > >>> > >>> After performing various tests of hosts that produce the above mentioned > >>> issue we came to conclusion that there are some interesting implementations > >>> that drop SYN packets with timestamps smaller than the largest timestamp > >>> value from streams of all recent or current connections from a specific > >>> address. This looks as some kind of SYN flood protection. > >> This also breaks multiple hosts with different uptimes behind a consumer > >> level NAT talking to such a server. > >>> > >>> To ensure that each external host is not going to see a wild jumps of > >>> timestamp values I propose a patch that removes ports from the equation > >>> all together, when calculating the timestamp offset: > >>> > >>> Index: sys/netinet/tcp_subr.c > >>> =================================================================== > >>> --- sys/netinet/tcp_subr.c (revision 348435) > >>> +++ sys/netinet/tcp_subr.c (working copy) > >>> @@ -2224,7 +2224,22 @@ > >>> uint32_t > >>> tcp_new_ts_offset(struct in_conninfo *inc) > >>> { > >>> - return (tcp_keyed_hash(inc, V_ts_offset_secret)); > >>> + /* > >>> + * Some implementations show a strange behaviour when a wildly random > >>> + * timestamps allocated for different streams. It seems that only the > >>> + * SYN packets are affected. Observed implementations drop SYN packets > >>> + * with timestamps smaller than the largest timestamp value of all > >>> + * recent or current connections from specific a address. To mitigate > >>> + * this we are going to ensure that each host will always observe > >>> + * timestamps as increasing no matter the stream: by dropping ports > >>> + * from the equation. > >>> + */ > >>> + struct in_conninfo inc_copy = *inc; > >>> + > >>> + inc_copy.inc_fport = 0; > >>> + inc_copy.inc_lport = 0; > >>> + > >>> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret)); > >>> } > >>> > >>> /* > >>> > >>> In any case, the solution of the uptime leak, implemented in rev338053 is > >>> not going to suffer, because a supposed attacker is currently able to use > >>> any fixed values of SP and DP, albeit not 0, anyway, to remove them out > >>> of the equation. > >> Can you describe how a peer can compute the uptime from two observed timestamps? > >> I don't see how you can do that... > > > > Supposed attacker could run a script that continuously monitors timestamps, > > for example via a periodic TCP connection from a fixed local port (eg 12345) > > and a fixed local address to the fixed victim's address and port (eg 80). > > Whenever large discrepancy is observed, attacker can assume that reboot has > > happened (due to V_ts_offset_secret re-generation), hence the received > > timestamp is considered an approximate point of reboot from which the uptime > > can be calculated, until the next reboot and so on. > Ahh, I see. The patch we are talking about is not intended to protect against > continuous monitoring, which is something you can always do. You could even > watch for service availability and detect reboots. A change of the local key > would also look similar to a reboot without a temporary loss of connectivity. > > Thanks for the clarification. > > > >>> > >>> There is the list of example hosts that we were able to reproduce the > >>> issue with: > >>> > >>> curl -v http://88.99.60.171:80 > >>> curl -v http://163.172.71.252:80 > >>> curl -v http://5.9.242.150:80 > >>> curl -v https://185.134.205.105:443 > >>> curl -v https://136.243.1.231:443 > >>> curl -v https://144.76.196.4:443 > >>> curl -v http://94.127.191.194:80 > >>> > >>> To reproduce, call curl repeatedly with a same URL some number of times. > >>> You are going to see some of the requests stuck in > >>> `* Trying XXX.XXX.XXX.XXX...` > >>> > >>> For some reason, the easiest way to reproduce the issue is with nc: > >>> > >>> $ echo "foooooo" | nc -v 88.99.60.171 80 > >>> > >>> Only a few such calls are required until one of them is stuck on connect(): > >>> issuing SYN packets with an exponential backoff. > >> Thanks for providing an end-point to test with. I'll take a look. > >> Just to be clear: You are running a FreeBSD client against one of the above > >> servers and experience the problem with the new timestamp computations. > >> > >> You are not running arbitrary clients against a FreeBSD server... > > > > We are talking about FreeBSD being the client. Peers that yield this unwanted > > behaviour are unknown. Little bit of tinkering showed that some of them run > > Debian: > > > > telnet 88.99.60.171 22 > > Trying 88.99.60.171... > > Connected to 88.99.60.171. > > Escape character is '^]'. > > SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 > Also some are hosted by Hetzner, but not all. I'll will look into > this tomorrow, since I'm on a deadline today (well it is 2am tomorrow > morning, to be precise)... Thanks a lot, I would appreciate that. > > Best regards > Michael > > > > > >> > >> Best regards > >> Michael > >> > >> > > From owner-freebsd-net@freebsd.org Mon Jul 8 16:13:22 2019 Return-Path: Delivered-To: freebsd-net@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 A5FA015E2764 for ; Mon, 8 Jul 2019 16:13:22 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF2EB75D02 for ; Mon, 8 Jul 2019 16:13:21 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: by mail-vs1-xe33.google.com with SMTP id 2so8572414vso.8 for ; Mon, 08 Jul 2019 09:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=C37V9XSmwpLFh6haTgya9EVq4SnZISvA8nVNVPDQtu8=; b=iRvWRmhO3jZn+rfeuts05kHpJOl+u/WabH9GYyeF12iAWAcQGHKblsZXLqEsGBKIUK isFFlMi6k1k3jGnc/5CkJT+1xA/Piqhy2fq7kEn6HLehWbhSB4Bs+19RuYl9jJhSHhYB pKBZxnoDg+QoLoYvxiX+MZhNUTxBfh6GTpXJ92cvdI4bYDvjNTIziSmumzyjMOPpgGpE r7lKvieFeJk0kr4ifICceskTXsg0iGfr+OnACUsplFJST1tfOLhUtFi+nM7NNd8wraDY fp5P1hIsvJGyrh6Q+rsQOlE6nh2mIOWG1jBGcmlM9EePJt1RGejEgIY9QI8aiW4B7Tto JMqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=C37V9XSmwpLFh6haTgya9EVq4SnZISvA8nVNVPDQtu8=; b=p559XINzVJbReuicgbxzCplJNRzFaJFSoZmmYwmoK2KKB07fREGKVu13bhg0iWyXkU LttWV9RTZ09YQ/h95cEaa8aIsQOL42RgS1IIUPvMZLifBzQRPWb3dqPjwokTEF2wl93E sppvg9whl7tV0JY/AYKy2x1nKX95CA0WoaJlf8bc6WWiarmCP3JB4eh6wMYtxJXiB+Of suZc1Zwp3sRIoFAPmiEGta/RWjmqW//z4Rze+kCifrIcOfteI7ofownN0PKnr4EIdI6E 43peQMbw5Dzb9m1ZVx9YAert5uGJbn1aN18OCNKQgA6dPeb5VV4dNRTwDJUcLUHed7So l4dw== X-Gm-Message-State: APjAAAXiEPTg3XbLSY5egYH10tWpxn9YB+BAUqoUJM7lTBhhSNUvpcsZ j8Jw90kLQ6+49x6K9QP6KlfA5+FLiTI5uUaXxIT+Kffn X-Google-Smtp-Source: APXvYqxmts149iTbZ3icfJkfooPMHvS4E8bc6a20Znaz6bWHEoPKOKBKACFt0OUiNkVx/JvQb5yVcT+bFs/OdJ9FIkI= X-Received: by 2002:a67:ead3:: with SMTP id s19mr975489vso.147.1562602400541; Mon, 08 Jul 2019 09:13:20 -0700 (PDT) MIME-Version: 1.0 From: Dan Lists Date: Mon, 8 Jul 2019 11:13:09 -0500 Message-ID: Subject: Bridge Not Forwarding ARP To: freebsd-net@freebsd.org X-Rspamd-Queue-Id: CF2EB75D02 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=iRvWRmhO; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of listsdan@gmail.com designates 2607:f8b0:4864:20::e33 as permitted sender) smtp.mailfrom=listsdan@gmail.com X-Spamd-Result: default: False [-6.65 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.59)[-0.592,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.05)[ip: (-9.62), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.40), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[3.3.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 16:13:23 -0000 I have a server running FreeBSD 11.2 that I am wanting to use as a bridged firewall. I have it set up and it mostly works. The problem is that ARP replies are not being forwarded from the outside interface to the inside interface. It appears to be working in the other direction. I see the ARP request go out on the outside interface and the reply arrives back at the outside interface. The ARP reply is never getting to the bridge or to the inside interface. The firewall server and the device behind it are in ESX. I think I've worked all the ESX issues out. When I manually add an ARP entry everything works. I've done this before with a physical server running FreeBSD 8.4 and it works as expected. The differences are physical vs virtual, and 8.4 vs 11.2. I'm at a loss as to why it is not working. I've searched the web and found noting. If anyone could offer suggestions on how to fix this or begin to debug it I would greatly appreciate it. Thanks, Dan From owner-freebsd-net@freebsd.org Mon Jul 8 16:54:01 2019 Return-Path: Delivered-To: freebsd-net@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 203E315E3121 for ; Mon, 8 Jul 2019 16:54:01 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0CDD7766A for ; Mon, 8 Jul 2019 16:53:59 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qt1-x841.google.com with SMTP id w17so15573567qto.10 for ; Mon, 08 Jul 2019 09:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eWzYER4zli1SpKsEaz5y/mHd7HnzsuTvhlWz+dJsm5M=; b=W3coe0hab+ThloYgnEKnUj6PgGwdw1ZL/Yfq4lp+qBkHm1QfVmuAp46cLdsa3yuBxw Qap5EoEJuOxaPi7ETfKd5IxEr2WYKCc84p8lr+XbJkPj6AtZvJmUeKnDUmKLBm7hbX4t LmYSK3G3ZmVw1iLSlj/6Ba0ARBs47yozAG8ikoYfoVib9wPkaZqkMLOMu4F7TAx17db8 uzBLddh4Peg2+QjLs9sF9vm7aNvPHsqFCL5d/GAR8mMyDMi/CG5ixxVHv4Tb5SaeQlum wE/b180sYnqzH3rV218kPq0y3IN40IlMcPKJ8PebItOovu7F5E5a6jodkQ8oq1LAsWSs g8Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eWzYER4zli1SpKsEaz5y/mHd7HnzsuTvhlWz+dJsm5M=; b=Or0LowH/9SyJT0RgQQYv5Wln1gBUAGRIuxYmVl3RAxQB6hvtzDCMEpAx7Ry21QEgRM q/bxFkW/AJOtI9COuYYFB6YgsESFrHCtsVqLa4IqLOBgaBzj9yCMfClJIZ9grE9/Wdcg e6Ql32SkCCZ4IYLaLQF1Ym+xJisVZ7Gnso30K0FQTbo94MxU1tj8QgowLYhmb9blnFZd r5+yrg/hi5HRcd34A+LCnBRiQ4/WUDgc7jH9H6jAiCyScbti02wpUKRU92MiK0BKCaSb n2h5i0HTLtBCWldk/9Sv1HgpGU62wpgLQiB+m/hobwIH1x9veRsVoew/RRzUUOPwjCHb 74+Q== X-Gm-Message-State: APjAAAVXAWAwPIrkDZn+B7XExS43/UOmkkyNKJGPX55jIg226DqKPCNV ejAep9QyMbjSiXF2N4oKHzJ7bSHnSQ9PQqO+xbw5cuQKyZ8= X-Google-Smtp-Source: APXvYqy0Vc5sY/dXjOUlUaj/XpDdTIvHaUGZSPtFx/5yzxgS5rCKwSa44HkPhyqhK008xrmyp0712Cy6A+tLuEUoUnQ= X-Received: by 2002:aed:2241:: with SMTP id o1mr15091155qtc.233.1562604838697; Mon, 08 Jul 2019 09:53:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Sierchio Date: Mon, 8 Jul 2019 09:53:22 -0700 Message-ID: Subject: Re: Bridge Not Forwarding ARP To: "freebsd-net@freebsd.org" X-Rspamd-Queue-Id: C0CDD7766A X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tenebras-com.20150623.gappssmtp.com header.s=20150623 header.b=W3coe0ha X-Spamd-Result: default: False [-3.64 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986,0]; R_DKIM_ALLOW(-0.20)[tenebras-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[tenebras.com]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.72)[ip: (2.02), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.40), country: US(-0.06)]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; DKIM_TRACE(0.00)[tenebras-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.63)[-0.625,0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 16:54:01 -0000 What's your firewall ruleset look like? (show, don't tell) What does sysctl report on the interfaces and on arp? On Mon, Jul 8, 2019 at 9:15 AM Dan Lists wrote: > I have a server running FreeBSD 11.2 that I am wanting to use as a bridge= d > firewall. I have it set up and it mostly works. The problem is that AR= P > replies are not being forwarded from the outside interface to the inside > interface. It appears to be working in the other direction. I see the > ARP request go out on the outside interface and the reply arrives back at > the outside interface. The ARP reply is never getting to the bridge or = to > the inside interface. > > The firewall server and the device behind it are in ESX. I think I've > worked all the ESX issues out. When I manually add an ARP entry everythi= ng > works. I've done this before with a physical server running FreeBSD 8.4 > and it works as expected. The differences are physical vs virtual, and > 8.4 vs 11.2. > > I'm at a loss as to why it is not working. I've searched the web and > found noting. If anyone could offer suggestions on how to fix this or > begin to debug it I would greatly appreciate it. > > Thanks, > > Dan > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata From owner-freebsd-net@freebsd.org Mon Jul 8 17:17:57 2019 Return-Path: Delivered-To: freebsd-net@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 74B9215E3F3A for ; Mon, 8 Jul 2019 17:17:57 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CFFE808AD for ; Mon, 8 Jul 2019 17:17:56 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qk1-x72f.google.com with SMTP id 201so11755319qkm.9 for ; Mon, 08 Jul 2019 10:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2JZhuUPBKCxsnqF7GlNHjbtRZrgDX/IeAOx7MWIawVQ=; b=Ml6O/xUYhC0OHhCcVfdIPV9WXgEEJ/UFkYl8GRCFEoTmM0GpZRNHAk9fFi4r1lZiAz ioKAYmUQPC8Qo8U8wvOFC1mi2fgj/UF7gzCv0gJkGkFKEYzCvlJ64PBLazawIj6MtMOA rvdaM94FUtPVV4KnkC/YMaDf5ne1qj7er1EzboDiwIvzwnz+uBUyQxDVS3bOAZfn94Op 5lZ4+QalMThn++za4EvQB0WG9kK9d4wOmkc3o1y0uvaakI2o1EM5log93AYYBhZR+iRT uT8oM/SQstFT4NJNt7vHwV2J6joEFh6UWP/JKi9dbQkGWT7FelkdVMQIsuw9ZTh8I2JJ Sq9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2JZhuUPBKCxsnqF7GlNHjbtRZrgDX/IeAOx7MWIawVQ=; b=Slz3R1I/eQb0lgw13jpdUSWXk0KbDm4OP1QIyk2AxJ3GB5YJjobbppTVV8iB4+GGkm K8qQzzia69rP1LJ/YGlDSp3KIwtHQ6T49G4ZR3i0ip5UHPOb09PqLab5ujbHrD5i4C4i UUw6CWoLGizd/yRFv0pxwg+YcgIl43bOkVafO7jELWU4Q3zHdfWkleYYiPrGRNEYpWTz vFne/uLO9Aq6N4ELpXnOC9VdB670GZjNyMrG/N/iXS8uAwT8MOUJxJJBVdbTB/U33bP/ XYNEzB4fTun0Lq/BA1LM1qaTCaUW67u7FJwqHYnBHL98qJaltXxt7CykaP9vcjcne5lV yCew== X-Gm-Message-State: APjAAAXtWzFFV56GlEQZVAzDbw/ZnXB6YWbcD7Iyk9rqg/QDb1Tr4aGE gSgFu+BM/ryLbuIxozy6TWk1t61QZG3vhDw43dZesdbPRkj1cA== X-Google-Smtp-Source: APXvYqy4vptQxggfRzGiQF2phFjV/9zdsariEuojDUZT6aHMqOg+Zy2uEem2wowKtSjIL6HsO3cAPuIz/VmLYc0Ktn8= X-Received: by 2002:a37:6085:: with SMTP id u127mr15492041qkb.25.1562606275388; Mon, 08 Jul 2019 10:17:55 -0700 (PDT) MIME-Version: 1.0 References: <8e388abc-f2ac-b070-cf86-a4d3971ac095@rawbw.com> In-Reply-To: <8e388abc-f2ac-b070-cf86-a4d3971ac095@rawbw.com> From: Michael Sierchio Date: Mon, 8 Jul 2019 10:17:19 -0700 Message-ID: Subject: Re: How to set up ipfw(8) NAT between an alias and the main IP address, when the alias is in another network? To: "freebsd-net@freebsd.org" X-Rspamd-Queue-Id: 7CFFE808AD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tenebras-com.20150623.gappssmtp.com header.s=20150623 header.b=Ml6O/xUY X-Spamd-Result: default: False [-3.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; R_DKIM_ALLOW(-0.20)[tenebras-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[tenebras.com]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[tenebras-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[f.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; HTTP_TO_IP(1.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; NEURAL_HAM_SHORT(-0.85)[-0.852,0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-3.03)[ip: (-9.51), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.40), country: US(-0.06)] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:17:57 -0000 NAT is already maintaining state =E2=80=93 it is possible to combine statef= ul rules and NAT, but don't. ;-) Are you really proposing to NAT twice, or is 192.168.1.2 a phony address for the purposes of discussion here? In any case, consider something like the following: #!/bin/sh fw=3D"/sbin/ipfw -q" sysctl net.inet.ip.fw.one_pass=3D0 IP_JAIL=3D"192.168.100.2" IP_EXIF=3D"192.168.1.2" OIF=3D"sk0" ###########################################################################= ##### # If 192.168.1.2 is really your interface address, you'll be nat'ing twice # on the way to the internet, which is ugly. You don't need the *unreg_only= * # directive if you only have RFC1918 addresses anyway. You should clarify # if this is the case. *reset* kills all active nat sessions if you run thi= s # script again. $fw flush $fw nat 1 config \ redirect_addr ${IP_EXIF} ${IP_JAIL} \ redirect_addr ${IP_JAIL} ${IP_EXIF} \ if ${OIF} unreg_only reset ###########################################################################= ##### # separate in and out as a matter of habit - don't mention protocol in nat # statement, do this in subsequent rules $fw add 01000 nat 1 ip from any to any in recv ${OIF} # check-state isn't needed, really, since it gets performed at the next # rule that mentions state #$#$#$#$# $fw add 01500 check-state # these will match traffic to/from external IP and not jail $fw add 02000 allow tcp from ${IP_EXIF} to any out setup keep-state $fw add 02010 allow udp from ${IP_EXIF} to any out keep-state $fw add 02020 allow icmp from ${IP_EXIF} to any out keep-state ###########################################################################= ##### # Why is this safe? because it will only match NAT return packets. # It only permits traffic to your jail in this case. Also, for TCP to # function properly, to need to accept ICMP error messages, esp. need-frag $fw add 02000 allow ip from any to ${IP_JAIL} ###########################################################################= ##### # outbound packets pass through nat $fw add 03000 nat 1 ip from any to any out xmit ${OIF} ###########################################################################= ##### # if your default rule (65535) is DENY, you need something like this. This will # match only NAT'd traffic $fw add 50000 allow ip from any to any out xmit ${OIF} On Sat, Jul 6, 2019 at 1:03 AM Yuri wrote: > My network interface looks like this: > > sk0: flags=3D8843 metric 0 mtu 15= 00 > options=3D80009 > ether 01:3c:47:8a:17:12 > inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 > inet 192.168.100.2 netmask 0xffffffff broadcast 192.168.100.2 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > > The second IP address is an alias that is used for jail. > > I would like to set up NAT so that this jail would access the internet > through the same interface. > > > I tried this script: > > > fw=3D"/sbin/ipfw -q" > > $fw nat 1 config redirect_addr 192.168.100.2 192.168.1.2 redirect_addr > 192.168.1.2 192.168.100.2 if sk0 unreg_only reset > > $fw add 1001 nat 1 tcp from 192.168.100.2/32 to any via sk0 keep-state > > $fw add 1002 check-state > > > The rule 1001 has keep-state, therefore it should process both outgoing > tcp and incoming response packets. But the outbound packets are NATted, > but the inbound ones are not. > > What is wrong, and how to fix this script? > > > Thank you, > > Yuri > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata From owner-freebsd-net@freebsd.org Mon Jul 8 17:19:58 2019 Return-Path: Delivered-To: freebsd-net@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 2C4EC15E3FE0 for ; Mon, 8 Jul 2019 17:19:58 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50688809BB for ; Mon, 8 Jul 2019 17:19:57 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: by mail-ua1-x934.google.com with SMTP id j21so5257577uap.2 for ; Mon, 08 Jul 2019 10:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G6OHOLygpWNvYwtxFeZv/Ep/ES+T/OptUKARjr/4TR0=; b=Q5U7ho80gMWXQ5+RyzdHGoI5vVsS1T6VVM+DV8RT0GxRtO6VnTNCG3tB1Qajv5nax2 WmG4BhM9mu95XqF5nvkvmYmXSv3M0sm5a8m0a+fEKtpihHgx2o8PEQOMy8V8cRvYLgwH WLRwFXys/NE4fPcItIliYYLb031jDpczHGItBEwN02cAX0q28ykE9ydYi7lBTtndl/mc sT6BIq6wjHYWOgtOSviD9EAKm4FzZrDrMhcM2MhckNPdThmNGDyjRMl8khzS2NzZ5+Hw r2A54JdjOyC7glTvPWDNkECJVj0HAKyprVdhQSnshjIP5egNUqTm+ZibEE2cqyzt/pJU yZqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G6OHOLygpWNvYwtxFeZv/Ep/ES+T/OptUKARjr/4TR0=; b=nmnEE2waQytj9O4ntdmMRE8AV+bnvftEngHNs3UVkaZ7HXY1x9V9pVOkAFmWuyB5IW j8N5+tqashVLquOOjpYo+3QPaNYW2fjHBFX1m5B9jB4Tc+o39tSMPqwwosla35gKuY71 5aCaHMlu//5MLNPGS10/pco68ttenOoCyQ61Sk3TjY8rj3ai4gGXg4HIThv5cpp/vbVJ b53+9A6EypMZJ4DywpvKS9aSvo4x0Dq59Hw0Czza71SVjA2N25ARcCfEKOUM7nIGcXGu xdx12ygfUXMBnH3jRoPXO2Z1nCIGDnKmU6Egx9XFpp+hZo/WLvmlN1w9YOrUl7+xszUG FOWw== X-Gm-Message-State: APjAAAXVBSjn8TMwpRyYRPZ7LCbPHPeYB+bba1l+NV6hnjT3/Rcdw7cn BLCoYvt7ssGTLeYPdphn8DUZE05JGb5IYcXxtsJQ5EaU X-Google-Smtp-Source: APXvYqxASoKBiBavoPtAJuYqEjoy7XfXZuV4hCnJVgPhyJCiMtGlhKu4eWHXTALr1g0aNnPlkQKTTmRSD0QpB8kT3LE= X-Received: by 2002:ab0:23ce:: with SMTP id c14mr9941106uan.77.1562606396559; Mon, 08 Jul 2019 10:19:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Lists Date: Mon, 8 Jul 2019 12:19:45 -0500 Message-ID: Subject: Re: Bridge Not Forwarding ARP To: Michael Sierchio Cc: "freebsd-net@freebsd.org" X-Rspamd-Queue-Id: 50688809BB X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Q5U7ho80; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of listsdan@gmail.com designates 2607:f8b0:4864:20::934 as permitted sender) smtp.mailfrom=listsdan@gmail.com X-Spamd-Result: default: False [-7.02 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.979,0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-3.03)[ip: (-9.53), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.40), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:19:58 -0000 On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio wrote= : > What's your firewall ruleset look like? (show, don't tell) > The firewall is off for testing (the machine is only on a private network). # ipfw list 65535 allow ip from any to any > What does sysctl report on the interfaces and on arp? > > I have not changed any settings. net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.garp_rexmit_count: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 1 hw.em.eee_setting: 1 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 1024 hw.em.rxd: 1024 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 hw.em.disable_crc_stripping: 0 dev.em.2.wake: 0 dev.em.2.mac_stats.tso_ctx_fail: 0 dev.em.2.mac_stats.tso_txd: 0 dev.em.2.mac_stats.tx_frames_1024_1522: 3 dev.em.2.mac_stats.tx_frames_512_1023: 2 dev.em.2.mac_stats.tx_frames_256_511: 5675 dev.em.2.mac_stats.tx_frames_128_255: 4255 dev.em.2.mac_stats.tx_frames_65_127: 35563 dev.em.2.mac_stats.tx_frames_64: 918055 dev.em.2.mac_stats.mcast_pkts_txd: 0 dev.em.2.mac_stats.bcast_pkts_txd: 0 dev.em.2.mac_stats.good_pkts_txd: 963553 dev.em.2.mac_stats.total_pkts_txd: 963553 dev.em.2.mac_stats.good_octets_txd: 60423175 dev.em.2.mac_stats.good_octets_recvd: 16906 dev.em.2.mac_stats.rx_frames_1024_1522: 1 dev.em.2.mac_stats.rx_frames_512_1023: 0 dev.em.2.mac_stats.rx_frames_256_511: 0 dev.em.2.mac_stats.rx_frames_128_255: 0 dev.em.2.mac_stats.rx_frames_65_127: 235 dev.em.2.mac_stats.rx_frames_64: 0 dev.em.2.mac_stats.mcast_pkts_recvd: 0 dev.em.2.mac_stats.bcast_pkts_recvd: 0 dev.em.2.mac_stats.good_pkts_recvd: 236 dev.em.2.mac_stats.total_pkts_recvd: 236 dev.em.2.mac_stats.xoff_txd: 0 dev.em.2.mac_stats.xoff_recvd: 0 dev.em.2.mac_stats.xon_txd: 0 dev.em.2.mac_stats.xon_recvd: 0 dev.em.2.mac_stats.coll_ext_errs: 0 dev.em.2.mac_stats.alignment_errs: 0 dev.em.2.mac_stats.crc_errs: 0 dev.em.2.mac_stats.recv_errs: 0 dev.em.2.mac_stats.recv_jabber: 0 dev.em.2.mac_stats.recv_oversize: 0 dev.em.2.mac_stats.recv_fragmented: 0 dev.em.2.mac_stats.recv_undersize: 0 dev.em.2.mac_stats.recv_no_buff: 0 dev.em.2.mac_stats.missed_packets: 0 dev.em.2.mac_stats.defer_count: 0 dev.em.2.mac_stats.sequence_errors: 0 dev.em.2.mac_stats.symbol_errors: 0 dev.em.2.mac_stats.collision_count: 0 dev.em.2.mac_stats.late_coll: 0 dev.em.2.mac_stats.multiple_coll: 0 dev.em.2.mac_stats.single_coll: 0 dev.em.2.mac_stats.excess_coll: 0 dev.em.2.rxd_tail: 235 dev.em.2.rxd_head: 236 dev.em.2.txd_tail: 127 dev.em.2.txd_head: 127 dev.em.2.fifo_reset: 0 dev.em.2.fifo_workaround: 0 dev.em.2.fc_low_water: 45604 dev.em.2.fc_high_water: 47104 dev.em.2.rx_control: 32794 dev.em.2.device_control: 1086325321 dev.em.2.watchdog_timeouts: 0 dev.em.2.rx_overruns: 0 dev.em.2.tx_desc_fail2: 0 dev.em.2.tx_desc_fail1: 0 dev.em.2.tx_dma_fail: 0 dev.em.2.dropped: 0 dev.em.2.mbuf_defrag_fail: 0 dev.em.2.cluster_alloc_fail: 0 dev.em.2.flow_control: 3 dev.em.2.rx_processing_limit: 100 dev.em.2.itr: 488 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_int_delay: 66 dev.em.2.rx_int_delay: 0 dev.em.2.nvm: -1 dev.em.2.%parent: pci2 dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x100f subvendor=3D0x15ad subdevice=3D0x0750 class=3D0x020000 dev.em.2.%location: slot=3D3 function=3D0 dbsf=3Dpci0:2:3:0 handle=3D\_SB_.PCI0.P2P0.S4F0 dev.em.2.%driver: em dev.em.2.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.1.0 dev.em.1.wake: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tx_frames_1024_1522: 1 dev.em.1.mac_stats.tx_frames_512_1023: 0 dev.em.1.mac_stats.tx_frames_256_511: 0 dev.em.1.mac_stats.tx_frames_128_255: 0 dev.em.1.mac_stats.tx_frames_65_127: 13 dev.em.1.mac_stats.tx_frames_64: 222 dev.em.1.mac_stats.mcast_pkts_txd: 0 dev.em.1.mac_stats.bcast_pkts_txd: 0 dev.em.1.mac_stats.good_pkts_txd: 236 dev.em.1.mac_stats.total_pkts_txd: 236 dev.em.1.mac_stats.good_octets_txd: 15962 dev.em.1.mac_stats.good_octets_recvd: 5286574431 dev.em.1.mac_stats.rx_frames_1024_1522: 2876152 dev.em.1.mac_stats.rx_frames_512_1023: 269810 dev.em.1.mac_stats.rx_frames_256_511: 605978 dev.em.1.mac_stats.rx_frames_128_255: 1879331 dev.em.1.mac_stats.rx_frames_65_127: 3179015 dev.em.1.mac_stats.rx_frames_64: 6 dev.em.1.mac_stats.mcast_pkts_recvd: 0 dev.em.1.mac_stats.bcast_pkts_recvd: 0 dev.em.1.mac_stats.good_pkts_recvd: 8809664 dev.em.1.mac_stats.total_pkts_recvd: 8816562 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_no_buff: 0 dev.em.1.mac_stats.missed_packets: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.rxd_tail: 167 dev.em.1.rxd_head: 168 dev.em.1.txd_tail: 236 dev.em.1.txd_head: 236 dev.em.1.fifo_reset: 0 dev.em.1.fifo_workaround: 0 dev.em.1.fc_low_water: 45604 dev.em.1.fc_high_water: 47104 dev.em.1.rx_control: 32794 dev.em.1.device_control: 1086325321 dev.em.1.watchdog_timeouts: 0 dev.em.1.rx_overruns: 0 dev.em.1.tx_desc_fail2: 0 dev.em.1.tx_desc_fail1: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.dropped: 0 dev.em.1.mbuf_defrag_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.flow_control: 3 dev.em.1.rx_processing_limit: 100 dev.em.1.itr: 488 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_int_delay: 66 dev.em.1.rx_int_delay: 0 dev.em.1.nvm: -1 dev.em.1.%parent: pci2 dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x100f subvendor=3D0x15ad subdevice=3D0x0750 class=3D0x020000 dev.em.1.%location: slot=3D2 function=3D0 dbsf=3Dpci0:2:2:0 handle=3D\_SB_.PCI0.P2P0.S3F0 dev.em.1.%driver: em dev.em.1.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.1.0 > > On Mon, Jul 8, 2019 at 9:15 AM Dan Lists wrote: > > > I have a server running FreeBSD 11.2 that I am wanting to use as a > bridged > > firewall. I have it set up and it mostly works. The problem is that > ARP > > replies are not being forwarded from the outside interface to the insid= e > > interface. It appears to be working in the other direction. I see th= e > > ARP request go out on the outside interface and the reply arrives back = at > > the outside interface. The ARP reply is never getting to the bridge o= r > to > > the inside interface. > > > > The firewall server and the device behind it are in ESX. I think I've > > worked all the ESX issues out. When I manually add an ARP entry > everything > > works. I've done this before with a physical server running FreeBSD 8= .4 > > and it works as expected. The differences are physical vs virtual, an= d > > 8.4 vs 11.2. > > > > I'm at a loss as to why it is not working. I've searched the web and > > found noting. If anyone could offer suggestions on how to fix this or > > begin to debug it I would greatly appreciate it. > > > > Thanks, > > > > Dan > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > > -- > > "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool i= s no > wiser, but an intelligent person requires only two thousand five hundred.= " > > - The Mah=C4=81bh=C4=81rata > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Mon Jul 8 17:33:52 2019 Return-Path: Delivered-To: freebsd-net@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 5980D15E46E1 for ; Mon, 8 Jul 2019 17:33:52 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B986816D3 for ; Mon, 8 Jul 2019 17:33:41 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x68HXYiO042205 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jul 2019 17:33:36 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: lists.dan@gmail.com Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x68HXTHF022289 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jul 2019 00:33:29 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Bridge Not Forwarding ARP To: Dan Lists , Michael Sierchio References: Cc: "freebsd-net@freebsd.org" From: Eugene Grosbein Message-ID: <9e33c592-bd64-277e-6c21-fdeba7e44a94@grosbein.net> Date: Tue, 9 Jul 2019 00:33:28 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4B986816D3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.66 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MX_INVALID(0.50)[greylisted]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.32)[-0.316,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; IP_SCORE(-0.75)[ipnet: 2a01:4f8::/29(-1.95), asn: 24940(-1.79), country: DE(-0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:33:52 -0000 09.07.2019 0:19, Dan Lists wrote: > On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio wrote: > >> What's your firewall ruleset look like? (show, don't tell) > The firewall is off for testing (the machine is only on a private network). > # ipfw list > 65535 allow ip from any to any >> What does sysctl report on the interfaces and on arp? > I have not changed any settings. Show output of ifconfig for the bridge and for its members, too. I suppose some misconfiguration like IP address assigned to member interfaces that is wrong. All IP addresses need to be moved to the bridge interface itself. From owner-freebsd-net@freebsd.org Mon Jul 8 17:43:57 2019 Return-Path: Delivered-To: freebsd-net@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 55E7A15E4AD1 for ; Mon, 8 Jul 2019 17:43:57 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71B0281E93 for ; Mon, 8 Jul 2019 17:43:56 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qk1-x72b.google.com with SMTP id d79so9677549qke.11 for ; Mon, 08 Jul 2019 10:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=drqNQ7Ux8SUYUH2YSc/LpYmeAxnt8NN7k+iHLxhj/Jo=; b=1W70xCFHLmpPh/EKqyjLPrcY9Z+8hsPZtBQ9OGeKs07xyoofekdO7Z4iURvDAQ3Vwo FnEL2qwTt3DJm6E1tKLVHCfXYvjIdOOF2BCx+958wzIezgiZ+qg7T+HcTYJQRaC4AsiN aTBkc84VxVJRUwud9lC6dCt2RfpDpfT2BW+1ug1gvSFxmlLdk3e4HwUvjLHrVjY5oBnH SwsUZ3CbeVV8Mq9NJPs3nyHPfTgfqd0T87vT+iXKbwFyku8vgqrW+9EALia3LIrc1J/x +bfpFCmsFCaXS+z9PPn4sbSw+FEpVGXe6n+dDskOYK/1zQJhBGR7ZyE1CGpZMnTYP+PQ oyOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=drqNQ7Ux8SUYUH2YSc/LpYmeAxnt8NN7k+iHLxhj/Jo=; b=HL7B0XxTuO6qoVUXgKpbBxB20nTrt3rmepKX6rP3F3RHRPYzHb3PO8SQXxhvGuRwCa JAgRNPHbcWKkb1ExCQrP84JWggnVLbSRJbS5rbdPrDgwPa+gr//1sfkJ3QeOPgjr/yo+ eBShoZszog17IAPlaYS8P2MTaTlGvm9NrnS3R/adWIQC17x6iNRnZ2n+pfsNcQcfEocP Pl/IASIuEotu+ASff3eSU96a/s0m4Q6QfPJS9sB/wgyoCv4B1MCocT168lkzhe9G05XT SMlSOm+K1fL/9HP3E19hTiGCmG/9qHuinWHCwmf37UnpYsuEYhAoZ1QqjJZlqGdzgohx lr+w== X-Gm-Message-State: APjAAAUih/59YZ/RbT/nET+u+R5oMPC9nqU0HYFIhHCXZOhR6L5tFTpv YgDI4CkS1A1BySh/MvloL2+iP+0m3QJWyNh/wR05kA== X-Google-Smtp-Source: APXvYqxnUe2PotaH/amzOmSPJYGqxjo8Xa7x9l6e2DlxJOAvSnXGdlMoN9h3L4R94PYjRXgVJL88ucb8fNQ84FKN+Xc= X-Received: by 2002:a37:6085:: with SMTP id u127mr15569227qkb.25.1562607835897; Mon, 08 Jul 2019 10:43:55 -0700 (PDT) MIME-Version: 1.0 References: <9e33c592-bd64-277e-6c21-fdeba7e44a94@grosbein.net> In-Reply-To: <9e33c592-bd64-277e-6c21-fdeba7e44a94@grosbein.net> From: Michael Sierchio Date: Mon, 8 Jul 2019 10:43:20 -0700 Message-ID: Subject: Re: Bridge Not Forwarding ARP To: Eugene Grosbein Cc: Dan Lists , "freebsd-net@freebsd.org" X-Rspamd-Queue-Id: 71B0281E93 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tenebras-com.20150623.gappssmtp.com header.s=20150623 header.b=1W70xCFH X-Spamd-Result: default: False [-5.81 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[tenebras-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[tenebras.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tenebras-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[b.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.48)[-0.477,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_CC(0.00)[gmail.com]; IP_SCORE(-3.03)[ip: (-9.51), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.40), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:43:57 -0000 On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein wrote: 09.07.2019 0:19, Dan Lists wrote: > > > On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio > wrote: > > > >> What's your firewall ruleset look like? (show, don't tell) > > The firewall is off for testing (the machine is only on a private > network). > > # ipfw list > > 65535 allow ip from any to any > >> What does sysctl report on the interfaces and on arp? > > I have not changed any settings. > > Show output of ifconfig for the bridge and for its members, too. > I suppose some misconfiguration like IP address assigned to member > interfaces that is wrong. > All IP addresses need to be moved to the bridge interface itself. > > Does 'ip' in ipfw match arp packets? --=20 "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata From owner-freebsd-net@freebsd.org Mon Jul 8 17:55:36 2019 Return-Path: Delivered-To: freebsd-net@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 F278415E4EB3 for ; Mon, 8 Jul 2019 17:55:35 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CCAB827C7 for ; Mon, 8 Jul 2019 17:55:34 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: by mail-vs1-xe2a.google.com with SMTP id j26so8809961vsn.10 for ; Mon, 08 Jul 2019 10:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7RO9VFB3iapjUY+A7+/xBWwcZ04GAMo+VurZmXeG8lY=; b=qrY3yF1w2w522NCU+NL4+inP70LmMWTN+pymPrpQc0ieEIQLz7pdXGKBQzoPIkFMEc bZiuUuIVQYRlMIUE6Bd+yMLpInJuGsZc/TG7M28QinwYTAAK2mNScfjF/5DfPpJ8aLL5 2uL1sB3qAr+AOQzli0hTHscgVRQA0bY37bSGpQmZbHd1IkTFHhDe5Ud9YGBTBIEdsSS7 9CvSRBAJcKv5se84af3lmWwQkk+MEX1XFPhhZO7VDp4HepQ3wmOockILz0o8vYK9PlEU ukNeXoRU7TKQ49RbvmJDmc0W3gblUwz7pIwOdKyekyihrk4hy18fBMvgg41MkhX8WBOp L+oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7RO9VFB3iapjUY+A7+/xBWwcZ04GAMo+VurZmXeG8lY=; b=nRBEMDoxrRJrqOCQK7yrsspu5irkt7J05uX0av+Bh/g/iAmaj29+OqIgh8AmsiCV5e 7w2v9/8H81a4KMadF9ZwqvLM6n5CKJzlwJB/3jl0eIcte3n8xKSW+CalfnFwVgj9Ku1Y OKlLNOx1wW9iL/tHeRXBEPcYPSzAs0q8t35CKSbgWNpAfQg73zic+lEk7hCLFXK6vXYU u0pxwKQnkjOUakMTQvIFqbpng2NXHD+xVUd7HIhYTpPa9CAVuTIvfLxFV2mJX+CMZB9S lAwUFKbPIgO56oSylHerW+rIaVI0DhQjL/7eXt49zrzpAM01oOxfIUQ7fPyCRXC7pvcJ wnZA== X-Gm-Message-State: APjAAAWY5Ffg6XkKFthoCz6VoUOo7EkAn0ljZDOugsZ02cheaLN3w250 sa+cdiJMZArflRAgrCSO3Hj1d5+Y2savM1sLGFw= X-Google-Smtp-Source: APXvYqxX077RsV3lIEdPrfWg6rV+q0c1122FVYrWCsqhfOdo1s/viSTX29R962M7G2a0k/cmUUaolo2g2xtFJNb38yE= X-Received: by 2002:a67:1a81:: with SMTP id a123mr10947864vsa.162.1562608533644; Mon, 08 Jul 2019 10:55:33 -0700 (PDT) MIME-Version: 1.0 References: <9e33c592-bd64-277e-6c21-fdeba7e44a94@grosbein.net> In-Reply-To: From: Dan Lists Date: Mon, 8 Jul 2019 12:55:22 -0500 Message-ID: Subject: Re: Bridge Not Forwarding ARP To: Michael Sierchio Cc: Eugene Grosbein , "freebsd-net@freebsd.org" X-Rspamd-Queue-Id: 3CCAB827C7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=qrY3yF1w; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of listsdan@gmail.com designates 2607:f8b0:4864:20::e2a as permitted sender) smtp.mailfrom=listsdan@gmail.com X-Spamd-Result: default: False [-6.71 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.62)[-0.622,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[a.2.e.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-3.08)[ip: (-9.76), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.40), country: US(-0.06)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 17:55:36 -0000 On Mon, Jul 8, 2019 at 12:43 PM Michael Sierchio wrote= : > > On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein > wrote: > > 09.07.2019 0:19, Dan Lists wrote: >> >> > On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio >> wrote: >> > >> >> What's your firewall ruleset look like? (show, don't tell) >> > The firewall is off for testing (the machine is only on a private >> network). >> > # ipfw list >> > 65535 allow ip from any to any >> >> What does sysctl report on the interfaces and on arp? >> > I have not changed any settings. >> >> Show output of ifconfig for the bridge and for its members, too. >> I suppose some misconfiguration like IP address assigned to member >> interfaces that is wrong. >> All IP addresses need to be moved to the bridge interface itself. >> >> > Does 'ip' in ipfw match arp packets? > It is my understanding that ARP packets are not filtered. That behavior can be changed by setting net.link.bridge.ipfw_arp=3D1. ARP packets are supposed to be forwarded by default. That worked with FreeBSD 8.4. --=20 > > "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool i= s no > wiser, but an intelligent person requires only two thousand five hundred.= " > > - The Mah=C4=81bh=C4=81rata > From owner-freebsd-net@freebsd.org Mon Jul 8 18:22:24 2019 Return-Path: Delivered-To: freebsd-net@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 C462E15E5BE3 for ; Mon, 8 Jul 2019 18:22:24 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 02D4883E28 for ; Mon, 8 Jul 2019 18:22:23 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x68IMHHv042428 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jul 2019 18:22:18 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kudzu@tenebras.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x68IMDEp009662 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jul 2019 01:22:13 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Bridge Not Forwarding ARP To: Michael Sierchio References: <9e33c592-bd64-277e-6c21-fdeba7e44a94@grosbein.net> Cc: "freebsd-net@freebsd.org" , Dan Lists From: Eugene Grosbein Message-ID: Date: Tue, 9 Jul 2019 01:22:07 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 02D4883E28 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.68 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; MX_INVALID(0.50)[cached]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; NEURAL_HAM_SHORT(-0.33)[-0.332,0]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; IP_SCORE(-0.75)[ipnet: 2a01:4f8::/29(-1.95), asn: 24940(-1.79), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 18:22:25 -0000 09.07.2019 0:43, Michael Sierchio wrote: > On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein wrote: > > 09.07.2019 0:19, Dan Lists wrote: >> >>> On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio >> wrote: >>> >>>> What's your firewall ruleset look like? (show, don't tell) >>> The firewall is off for testing (the machine is only on a private >> network). >>> # ipfw list >>> 65535 allow ip from any to any >>>> What does sysctl report on the interfaces and on arp? >>> I have not changed any settings. >> >> Show output of ifconfig for the bridge and for its members, too. >> I suppose some misconfiguration like IP address assigned to member >> interfaces that is wrong. >> All IP addresses need to be moved to the bridge interface itself. >> >> > Does 'ip' in ipfw match arp packets? We have net.link.bridge.ipfw_arp that defaults to 0 (false): $ sysctl -d net.link.bridge.ipfw_arp net.link.bridge.ipfw_arp: Filter ARP packets through IPFW layer2 If one changes it to 1 so ipfw would get bridged ARP frames, then answer to your question should depend on value of net.link.ether.ipfw (0 by default) as ARP packets have no IP header. So if you change so many sysctls, you will be able to filter ARP frames with "ip" keyword as "ip" equals to "all" in ipfw. From owner-freebsd-net@freebsd.org Mon Jul 8 19:42:41 2019 Return-Path: Delivered-To: freebsd-net@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 BFECB15E815C for ; Mon, 8 Jul 2019 19:42:41 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B4F91889C4 for ; Mon, 8 Jul 2019 19:42:40 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-qt1-x829.google.com with SMTP id d17so17846996qtj.8 for ; Mon, 08 Jul 2019 12:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8aeIJ7hFmoZusnwc/gB7qoX64Q9o2NFZkxvzB1wttfQ=; b=rdYskcT6lew7dJpv6IOBCUYWljCZhMVutBn1ixoFaxfFkgdNiRjMeTYKond2c92bP+ LiC+A2e4irj4+O2YNlv/RLtoUOUvuztbhSdJfdpwtgRZmUygQt061SLFcVX9XxAlBlnA EHFoOWTPyHqozuOETi1oU6fW8owaoYaS2UUl/sH1IjveohBNwRfShEEWv9qa30P0hkOY In+WgXVKKn0/iu372IOJIWJlwuThJVEpTkeSTLmVBc9jhnq3k5o5vfZXiLLuYGiuVthA +uyxkKz0pT9Lu152DbjwYxFNX4CTlbCmdIPoyADFo8cxxiCLTzh/A1AELBNQSgF7qtH+ SmNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8aeIJ7hFmoZusnwc/gB7qoX64Q9o2NFZkxvzB1wttfQ=; b=SUlM4Nz7M0rbCEkK34ShDfTNQxsApTO45JIL2Ma9xybz6PBEtQ8hHLPoZ3BaVaI4TJ P4u6cc4qwj3HhrJBWQHvhvs26WLVyy4aFMyvvBq+kQFT6iVDnvsgN9ali3K3ZbIKjKlB WUeOHPbpHf2WEnqRZ8VOOsZRG/Zb+Y68aoqRg60Rh4lEwS/bbMjYqeWw2yvJgHmZumMr DBWLScm/ONEZGNJIS9TvpIOyyPk05U8OtmwSljj3lx2075svsgvHt7DEZftXrXHj1DxY z21ID9BCmVotbI3Nfnt3gc+WXIfff2xDhikeCc/bOlT2ipfBqWkeC8KyOQ7Ie7ay+16n DiRw== X-Gm-Message-State: APjAAAVIqUVxxYiJcCBTCLLyGGuus6vvpN3JDwbqqLWRZj2DNlwzXpYT z6/uQziqIxxSaO/vArlyuvOHlR2cjcSa2pO5z8y5XQ== X-Google-Smtp-Source: APXvYqxGArriVxVw2GEMuDCMUKX/AO7SGCe9YQuc/5uCQkGmkhH+kroYPETsAjwmzA4XknRlI2OhgpTCvUKogNsoNYo= X-Received: by 2002:ac8:27d4:: with SMTP id x20mr15064631qtx.138.1562614959847; Mon, 08 Jul 2019 12:42:39 -0700 (PDT) MIME-Version: 1.0 References: <9e33c592-bd64-277e-6c21-fdeba7e44a94@grosbein.net> In-Reply-To: From: Michael Sierchio Date: Mon, 8 Jul 2019 12:42:04 -0700 Message-ID: Subject: Re: Bridge Not Forwarding ARP To: Eugene Grosbein Cc: "freebsd-net@freebsd.org" , Dan Lists X-Rspamd-Queue-Id: B4F91889C4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tenebras-com.20150623.gappssmtp.com header.s=20150623 header.b=rdYskcT6 X-Spamd-Result: default: False [-6.18 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[tenebras-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[tenebras.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; DKIM_TRACE(0.00)[tenebras-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[9.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.86)[-0.864,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-3.01)[ip: (-9.41), ipnet: 2607:f8b0::/32(-3.16), asn: 15169(-2.41), country: US(-0.06)] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 19:42:42 -0000 On Mon, Jul 8, 2019 at 11:22 AM Eugene Grosbein wrote: > 09.07.2019 0:43, Michael Sierchio wrote: > > > On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein > wrote: > > > > 09.07.2019 0:19, Dan Lists wrote: > >> > >>> On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio > >> wrote: > >>> > >>>> What's your firewall ruleset look like? (show, don't tell) > >>> The firewall is off for testing (the machine is only on a private > >> network). > >>> # ipfw list > >>> 65535 allow ip from any to any > >>>> What does sysctl report on the interfaces and on arp? > >>> I have not changed any settings. > >> > >> Show output of ifconfig for the bridge and for its members, too. > >> I suppose some misconfiguration like IP address assigned to member > >> interfaces that is wrong. > >> All IP addresses need to be moved to the bridge interface itself. > >> > >> > > Does 'ip' in ipfw match arp packets? > > We have net.link.bridge.ipfw_arp that defaults to 0 (false): > > $ sysctl -d net.link.bridge.ipfw_arp > net.link.bridge.ipfw_arp: Filter ARP packets through IPFW layer2 > > If one changes it to 1 so ipfw would get bridged ARP frames, > then answer to your question should depend on value of net.link.ether.ipf= w > (0 by default) > as ARP packets have no IP header. So if you change so many sysctls, you > will be able > to filter ARP frames with "ip" keyword as "ip" equals to "all" in ipfw. > > Right, thanks, and Dan's sysctl output has net.link.bridge.ipfw_arp: 0 --=20 "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata From owner-freebsd-net@freebsd.org Tue Jul 9 00:52:49 2019 Return-Path: Delivered-To: freebsd-net@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 2CB3A15C0CCF for ; Tue, 9 Jul 2019 00:52:49 +0000 (UTC) (envelope-from jbwlists@hilltopgroup.com) Received: from equinox.hilltopgroup.com (equinox.hilltopgroup.com [204.109.63.175]) by mx1.freebsd.org (Postfix) with ESMTP id C9C946DD2E for ; Tue, 9 Jul 2019 00:52:44 +0000 (UTC) (envelope-from jbwlists@hilltopgroup.com) Received: from mail.relativity.hilltopgroup.com (unknown [104.185.205.155]) by equinox.hilltopgroup.com (Postfix) with ESMTP id 43F0037BD9F for ; Mon, 8 Jul 2019 20:54:49 -0400 (EDT) Received: from [192.168.8.200] (unknown [104.185.205.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jbwlists@hilltopgroup.com) by mail.relativity.hilltopgroup.com (Postfix) with ESMTPSA id D5F3E2EE0C for ; Mon, 8 Jul 2019 20:52:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hilltopgroup.com; s=mail; t=1562633558; bh=PaA4PYXJvEG3yru2puC2WvJy62yPV0yNnwDvtcuAivc=; h=Subject:To:References:From:Date:In-Reply-To; b=OgFhRyfdj/sga0YiKTPYJYnxpf9gN7R+FxqAnqV7/zVnVOtzjK1bIrx7OVcujmJHB b+Fy9dEz75COAzPPt+QTCuBlGvgtIkUGqSgjrChizuHbLJMuhmOx0epFLX0u3rI+DI q4CIt0Y9Wwbox5Nt4dkZ25iZl5w1ltG29dasqSwY= Subject: Re: Bridge Not Forwarding ARP To: freebsd-net@freebsd.org References: From: Joseph Ward Message-ID: Date: Mon, 8 Jul 2019 20:52:36 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: C9C946DD2E X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hilltopgroup.com header.s=mail header.b=OgFhRyfd; spf=pass (mx1.freebsd.org: domain of jbwlists@hilltopgroup.com designates 204.109.63.175 as permitted sender) smtp.mailfrom=jbwlists@hilltopgroup.com X-Spamd-Result: default: False [-4.46 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[hilltopgroup.com:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[hilltopgroup.com]; DKIM_TRACE(0.00)[hilltopgroup.com:+]; MX_GOOD(-0.01)[equinox.hilltopgroup.com,mail2.hilltopgroup.com,mail.hilltopgroup.com]; NEURAL_HAM_SHORT(-0.83)[-0.834,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.21)[ipnet: 204.109.60.0/22(-2.13), asn: 36236(-3.88), country: US(-0.06)]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 00:52:49 -0000 I had this exact issue while virtualbox had a guest network adapter bridged to the external interface that the FreeBDS bridge0 interface was bridged to.  If I shutdown the VMs, ARP magically started working bidirectionally, and after restarting the VMs it failed again. My fix was eventually to just have 2 external NICs; one exclusively for the virtualbox systems.  I have no idea if you have a virtualbox guest present, but if so that was my fix.  The issue occurred on both igb and re NICs. -Joseph On 2019-07-08 12:13, Dan Lists wrote: > I have a server running FreeBSD 11.2 that I am wanting to use as a bridged > firewall. I have it set up and it mostly works. The problem is that ARP > replies are not being forwarded from the outside interface to the inside > interface. It appears to be working in the other direction. I see the > ARP request go out on the outside interface and the reply arrives back at > the outside interface. The ARP reply is never getting to the bridge or to > the inside interface. > > The firewall server and the device behind it are in ESX. I think I've > worked all the ESX issues out. When I manually add an ARP entry everything > works. I've done this before with a physical server running FreeBSD 8.4 > and it works as expected. The differences are physical vs virtual, and > 8.4 vs 11.2. > > I'm at a loss as to why it is not working. I've searched the web and > found noting. If anyone could offer suggestions on how to fix this or > begin to debug it I would greatly appreciate it. > > Thanks, > > Dan > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Tue Jul 9 02:42:02 2019 Return-Path: Delivered-To: freebsd-net@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 0C9D015CBF20 for ; Tue, 9 Jul 2019 02:42:02 +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 965B7713EB for ; Tue, 9 Jul 2019 02:42:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5439815CBF1F; Tue, 9 Jul 2019 02:42:01 +0000 (UTC) Delivered-To: net@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 4149D15CBF1D for ; Tue, 9 Jul 2019 02:42:01 +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 C8AF5713E7 for ; Tue, 9 Jul 2019 02:42:00 +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 CAB9A12344 for ; Tue, 9 Jul 2019 02:41:59 +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 x692fxBu055432 for ; Tue, 9 Jul 2019 02:41:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x692fxMx055431 for net@FreeBSD.org; Tue, 9 Jul 2019 02:41:59 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: net@FreeBSD.org Subject: [Bug 238789] panic: mutex so_rcv not owned at /usr/src/sys/kern/uipc_socket.c:2359 Date: Tue, 09 Jul 2019 02:41:59 +0000 X-Bugzilla-Reason: CC 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: panic X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: markj@FreeBSD.org X-Bugzilla-Flags: mfc-stable11+ mfc-stable12+ X-Bugzilla-Changed-Fields: flagtypes.name keywords 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 02:42:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238789 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable11?, |mfc-stable11+, |mfc-stable12? |mfc-stable12+ Keywords|needs-qa | --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 02:54:27 2019 Return-Path: Delivered-To: freebsd-net@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 1C50615CC31D for ; Tue, 9 Jul 2019 02:54:27 +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 A5C5771A96 for ; Tue, 9 Jul 2019 02:54:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 63C2B15CC31B; Tue, 9 Jul 2019 02:54:26 +0000 (UTC) Delivered-To: net@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 51E9915CC31A for ; Tue, 9 Jul 2019 02:54:26 +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 DE9C071A92 for ; Tue, 9 Jul 2019 02:54:25 +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 0D275124D2 for ; Tue, 9 Jul 2019 02:54:25 +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 x692sOCe079974 for ; Tue, 9 Jul 2019 02:54:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x692sOa2079970 for net@FreeBSD.org; Tue, 9 Jul 2019 02:54:24 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: net@FreeBSD.org Subject: [Bug 238642] netmap: fix kernel pointer printing in netmap_generic.c Date: Tue, 09 Jul 2019 02:54:24 +0000 X-Bugzilla-Reason: CC 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: patch, security X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vmaffione@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: flagtypes.name bug_severity resolution cc assigned_to bug_status keywords 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 02:54:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238642 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |mfc-stable11?, | |mfc-stable12? Severity|Affects Only Me |Affects Some People Resolution|FIXED |--- CC| |net@FreeBSD.org Assignee|net@FreeBSD.org |vmaffione@FreeBSD.org Status|Closed |In Progress Keywords| |security --- Comment #2 from Kubilay Kocak --- Re-open pending MFC --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 02:55:17 2019 Return-Path: Delivered-To: freebsd-net@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 D232915CC394 for ; Tue, 9 Jul 2019 02:55: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 688F771B63 for ; Tue, 9 Jul 2019 02:55:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2C48015CC390; Tue, 9 Jul 2019 02:55:16 +0000 (UTC) Delivered-To: net@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 1961815CC38C for ; Tue, 9 Jul 2019 02:55: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 A686971B60 for ; Tue, 9 Jul 2019 02:55:15 +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 E01B8124D8 for ; Tue, 9 Jul 2019 02:55: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 x692tEfo081081 for ; Tue, 9 Jul 2019 02:55:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x692tEo8081080 for net@FreeBSD.org; Tue, 9 Jul 2019 02:55: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: net@FreeBSD.org Subject: [Bug 238641] netmap: Remove pointer printing in netmap_mem2.c Date: Tue, 09 Jul 2019 02:55: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: CURRENT X-Bugzilla-Keywords: patch, security X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vmaffione@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? X-Bugzilla-Changed-Fields: keywords resolution bug_severity bug_status assigned_to flagtypes.name 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 02:55:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238641 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |security Resolution|FIXED |--- Severity|Affects Only Me |Affects Some People Status|Closed |In Progress Assignee|net@FreeBSD.org |vmaffione@FreeBSD.org Flags| |mfc-stable11?, | |mfc-stable12? --- Comment #3 from Kubilay Kocak --- Reopen pending MFC --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 02:57:03 2019 Return-Path: Delivered-To: freebsd-net@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 0113715CC493 for ; Tue, 9 Jul 2019 02:57:03 +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 8289971C1A for ; Tue, 9 Jul 2019 02:57:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3DC7715CC491; Tue, 9 Jul 2019 02:57:02 +0000 (UTC) Delivered-To: net@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 2C4E815CC490 for ; Tue, 9 Jul 2019 02:57:02 +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 A01C971C15 for ; Tue, 9 Jul 2019 02:57:01 +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 9F6D1124DB for ; Tue, 9 Jul 2019 02:56:59 +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 x692uxBT082912 for ; Tue, 9 Jul 2019 02:56:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x692uxBf082911 for net@FreeBSD.org; Tue, 9 Jul 2019 02:56:59 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: net@FreeBSD.org Subject: [Bug 238324] Add XG-C100C/AQtion AQC107 10GbE NIC driver Date: Tue, 09 Jul 2019 02:56:59 +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: feature, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity cc bug_status keywords 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 02:57:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238324 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Many People |Affects Some People CC| |koobs@FreeBSD.org Status|New |Open Keywords| |feature --- Comment #4 from Kubilay Kocak --- I have a port WIP for this, which may be the best place for the network dri= ver in the first instance. At last test it was failing to build on one supported base branch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 04:14:26 2019 Return-Path: Delivered-To: freebsd-net@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 8877115CE088 for ; Tue, 9 Jul 2019 04:14:26 +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 1E3CC74D72 for ; Tue, 9 Jul 2019 04:14:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D5DFC15CE087; Tue, 9 Jul 2019 04:14:25 +0000 (UTC) Delivered-To: net@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 C2E6015CE085 for ; Tue, 9 Jul 2019 04:14:25 +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 5DE5A74D6C for ; Tue, 9 Jul 2019 04:14:25 +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 7C7A513087 for ; Tue, 9 Jul 2019 04:14:24 +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 x694EOTZ033387 for ; Tue, 9 Jul 2019 04:14:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x694EOMj033386 for net@FreeBSD.org; Tue, 9 Jul 2019 04:14:24 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Tue, 09 Jul 2019 04:14:24 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: msl0000023508@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 04:14:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 WHR changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|Not A Bug |--- Status|Closed |Open --- Comment #7 from WHR --- (In reply to Cy Schubert from comment #5) I has successfully reproduced this bug in kernel version 13.0-CURRENT r3497= 53. I don't known how does you believe this bug could disappear without actual = code change. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 04:15:23 2019 Return-Path: Delivered-To: freebsd-net@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 E1D5115CE0FB for ; Tue, 9 Jul 2019 04:15:22 +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 7919574E07 for ; Tue, 9 Jul 2019 04:15:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3C3F615CE0FA; Tue, 9 Jul 2019 04:15:22 +0000 (UTC) Delivered-To: net@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 2AA1715CE0F8 for ; Tue, 9 Jul 2019 04:15:22 +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 B7F7474E03 for ; Tue, 9 Jul 2019 04:15:21 +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 F1AF51308C for ; Tue, 9 Jul 2019 04:15:20 +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 x694FKmk034842 for ; Tue, 9 Jul 2019 04:15:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x694FKKG034841 for net@FreeBSD.org; Tue, 9 Jul 2019 04:15:20 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Tue, 09 Jul 2019 04:15:21 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: msl0000023508@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 04:15:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #8 from WHR --- (In reply to Cy Schubert from comment #5) > there is no need for this patch. It already works. Why? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 05:13:29 2019 Return-Path: Delivered-To: freebsd-net@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 223B815CF548 for ; Tue, 9 Jul 2019 05:13: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 B11D276E7E for ; Tue, 9 Jul 2019 05:13:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 71BE815CF547; Tue, 9 Jul 2019 05:13:28 +0000 (UTC) Delivered-To: net@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 5D18515CF546 for ; Tue, 9 Jul 2019 05:13: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.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 EBE1476E7B for ; Tue, 9 Jul 2019 05:13: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 4EBDB1390D for ; Tue, 9 Jul 2019 05:13: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 x695DRDh060799 for ; Tue, 9 Jul 2019 05:13:27 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x695DRx8060798 for net@FreeBSD.org; Tue, 9 Jul 2019 05:13: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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Tue, 09 Jul 2019 05:13:27 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: msl0000023508@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 05:13:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 WHR changed: What |Removed |Added ---------------------------------------------------------------------------- Version|12.0-STABLE |CURRENT --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 05:38:55 2019 Return-Path: Delivered-To: freebsd-net@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 997B515CFE22 for ; Tue, 9 Jul 2019 05:38:55 +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 3383577AE3 for ; Tue, 9 Jul 2019 05:38:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E72B115CFE21; Tue, 9 Jul 2019 05:38:54 +0000 (UTC) Delivered-To: net@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 D25F615CFE20 for ; Tue, 9 Jul 2019 05:38:54 +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 5F73F77AE2 for ; Tue, 9 Jul 2019 05:38:54 +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 A03F013BF5 for ; Tue, 9 Jul 2019 05:38:53 +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 x695crei009132 for ; Tue, 9 Jul 2019 05:38:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x695crVW009131 for net@FreeBSD.org; Tue, 9 Jul 2019 05:38:53 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Tue, 09 Jul 2019 05:38:53 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 05:38:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 Cy Schubert changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Not A Bug Status|Open |Closed --- Comment #9 from Cy Schubert --- cwfw# echo "pass in quick on fxp0 to sk0:10.1.1.1 inet proto tcp from 192.168.0.0/24 port =3D 22 to any" | ipf -f - cwfw# ipfstat -ion | grep 'pass in quick on fxp0 to sk0:10.1.1.1 inet' @212 pass in quick on fxp0 to sk0:10.1.1.1 inet proto tcp from 192.168.0.0/= 24 port =3D ssh to any cwfw# echo "pass in quick on fxp0 to sk0:10.1.1.1 inet proto tcp from 192.168.0.0/24 port =3D 22 to any" | ipf -r -f - cwfw# ipfstat -ion | grep 'pass in quick on fxp0 to sk0:10.1.1.1 inet'=20= =20=20=20=20=20=20=20=20 cwfw#=20 cwfw# uname -a FreeBSD cwfw 13.0-CURRENT FreeBSD 13.0-CURRENT #407 r349853M: Mon Jul 8 18:28:18 PDT 2019=20=20=20=20 root@cwfw:/export/obj/opt/src/svn-current/amd64.amd64/sys/PROD2 amd64 cwfw#=20 I am unable to reproduce this on my production firewall. It is likely your problem is due to one of your custom patches. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 07:22:20 2019 Return-Path: Delivered-To: freebsd-net@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 7356E15D2297 for ; Tue, 9 Jul 2019 07:22:20 +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 0E85D83BCB for ; Tue, 9 Jul 2019 07:22:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C2B6115D2296; Tue, 9 Jul 2019 07:22:19 +0000 (UTC) Delivered-To: net@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 AFC8D15D2295 for ; Tue, 9 Jul 2019 07:22: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 4923183BC6 for ; Tue, 9 Jul 2019 07:22:19 +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 8950114B63 for ; Tue, 9 Jul 2019 07:22: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 x697MIf1093386 for ; Tue, 9 Jul 2019 07:22:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x697MI2b093385 for net@FreeBSD.org; Tue, 9 Jul 2019 07:22:18 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Tue, 09 Jul 2019 07:22:18 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: msl0000023508@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 07:22:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 WHR changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Closed |Open Resolution|Not A Bug |--- --- Comment #10 from WHR --- (In reply to Cy Schubert from comment #9) I never said I has used any custom patch when discovering this bug, the only patch 'attachment 205322' is used to FIX the bug. In fact the 2 kernel imag= es and associated 'ipl.ko' KLD module are downloaded directly from FreeBSD download site, with version 12.0-STABLE r349024 and 13.0-CURRENT r349753. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 11:44:38 2019 Return-Path: Delivered-To: freebsd-net@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 080A915D8120 for ; Tue, 9 Jul 2019 11:44:38 +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 955DB8D27D for ; Tue, 9 Jul 2019 11:44:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 58F8015D811F; Tue, 9 Jul 2019 11:44:37 +0000 (UTC) Delivered-To: net@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 45E7615D811E for ; Tue, 9 Jul 2019 11:44:37 +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 CD45C8D27A for ; Tue, 9 Jul 2019 11:44:36 +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 0A557170A8 for ; Tue, 9 Jul 2019 11:44:36 +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 x69BiZQs080075 for ; Tue, 9 Jul 2019 11:44:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x69BiZS9080074 for net@FreeBSD.org; Tue, 9 Jul 2019 11:44:35 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Tue, 09 Jul 2019 11:44:35 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 11:44:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #11 from Cy Schubert --- Unfortunately I cannot accept a patch for something I cannot reproduce. AFA= IAC your patch does not fix any bug. Help me reproduce it here then. A patch for something I cannot verify or reproduce is not enough. If this i= s a bug, what do I do to expose it? I need your help then. Help me verify that = this is indeed a bug. Help me out here. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 12:34:31 2019 Return-Path: Delivered-To: freebsd-net@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 DC4FB15D9945 for ; Tue, 9 Jul 2019 12:34:30 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62B738F039 for ; Tue, 9 Jul 2019 12:34:30 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2a02:8109:1140:c3d:1c7:520c:e8a0:1e52] (unknown [IPv6:2a02:8109:1140:c3d:1c7:520c:e8a0:1e52]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6847D71E3F933; Tue, 9 Jul 2019 14:34:25 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Issues with TCP Timestamps allocation From: Michael Tuexen In-Reply-To: <1562599181.734953000.1l9a1d23@frv39.fwdcdn.com> Date: Tue, 9 Jul 2019 14:34:24 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0C475A01-9BCD-4E4A-9731-09AB919CA9BE@freebsd.org> References: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> <32FD061B-245C-41D2-81DE-1B4756A7173D@freebsd.org> <1562591379.369129000.gpmxvurq@frv39.fwdcdn.com> <1562599181.734953000.1l9a1d23@frv39.fwdcdn.com> To: Paul X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Status: No, score=-1.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 12:34:31 -0000 > On 8. Jul 2019, at 17:22, Paul wrote: >=20 >=20 >=20 > 8 July 2019, 17:12:21, by "Michael Tuexen" : >=20 >>> On 8. Jul 2019, at 15:24, Paul wrote: >>>=20 >>> Hi Michael, >>>=20 >>> 8 July 2019, 15:53:15, by "Michael Tuexen" : >>>=20 >>>>> On 8. Jul 2019, at 12:37, Paul wrote: >>>>>=20 >>>>> Hi team, >>>>>=20 >>>>> Recently we had an upgrade to 12 Stable. Immediately after, we = have started=20 >>>>> seeing some strange connection establishment timeouts to some = fixed number >>>>> of external (world) hosts. The issue was persistent and easy to = reproduce. >>>>> Thanks to a patience and dedication of our system engineer we have = tracked =20 >>>>> this issue down to a specific commit: >>>>>=20 >>>>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D338053 >>>>>=20 >>>>> This patch was also back-ported into 11 Stable: >>>>>=20 >>>>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D348435 >>>>>=20 >>>>> Among other things this patch changes the timestamp allocation = strategy, >>>>> by introducing a deterministic randomness via a hash function that = takes >>>>> into account a random key as well as source address, source port, = dest >>>>> address and dest port. As the result, timestamp offsets of = different >>>>> tuples (SA,SP,DA,DP) will be wildly different and will jump from = small=20 >>>>> to large numbers and back, as long as something in the tuple = changes. >>>> Hi Paul, >>>>=20 >>>> this is correct. >>>>=20 >>>> Please note that the same happens with the old method, if two hosts = with >>>> different uptimes are bind a consumer grade NAT. >>>=20 >>> If NAT does not replace timestamps then yes, it should be the case. >>>=20 >>>>>=20 >>>>> After performing various tests of hosts that produce the above = mentioned=20 >>>>> issue we came to conclusion that there are some interesting = implementations=20 >>>>> that drop SYN packets with timestamps smaller than the largest = timestamp=20 >>>>> value from streams of all recent or current connections from a = specific=20 >>>>> address. This looks as some kind of SYN flood protection. >>>> This also breaks multiple hosts with different uptimes behind a = consumer >>>> level NAT talking to such a server. >>>>>=20 >>>>> To ensure that each external host is not going to see a wild jumps = of=20 >>>>> timestamp values I propose a patch that removes ports from the = equation >>>>> all together, when calculating the timestamp offset: >>>>>=20 >>>>> Index: sys/netinet/tcp_subr.c >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- sys/netinet/tcp_subr.c (revision 348435) >>>>> +++ sys/netinet/tcp_subr.c (working copy) >>>>> @@ -2224,7 +2224,22 @@ >>>>> uint32_t >>>>> tcp_new_ts_offset(struct in_conninfo *inc) >>>>> { >>>>> - return (tcp_keyed_hash(inc, V_ts_offset_secret)); >>>>> + /*=20 >>>>> + * Some implementations show a strange behaviour when a = wildly random=20 >>>>> + * timestamps allocated for different streams. It seems = that only the >>>>> + * SYN packets are affected. Observed implementations = drop SYN packets >>>>> + * with timestamps smaller than the largest timestamp = value of all=20 >>>>> + * recent or current connections from specific a address. = To mitigate=20 >>>>> + * this we are going to ensure that each host will always = observe=20 >>>>> + * timestamps as increasing no matter the stream: by = dropping ports >>>>> + * from the equation. >>>>> + */=20 >>>>> + struct in_conninfo inc_copy =3D *inc; >>>>> + >>>>> + inc_copy.inc_fport =3D 0; >>>>> + inc_copy.inc_lport =3D 0; >>>>> + >>>>> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret)); >>>>> } >>>>>=20 >>>>> /* >>>>>=20 >>>>> In any case, the solution of the uptime leak, implemented in = rev338053 is=20 >>>>> not going to suffer, because a supposed attacker is currently able = to use=20 >>>>> any fixed values of SP and DP, albeit not 0, anyway, to remove = them out=20 >>>>> of the equation. >>>> Can you describe how a peer can compute the uptime from two = observed timestamps? >>>> I don't see how you can do that... >>>=20 >>> Supposed attacker could run a script that continuously monitors = timestamps, >>> for example via a periodic TCP connection from a fixed local port = (eg 12345)=20 >>> and a fixed local address to the fixed victim's address and port (eg = 80). >>> Whenever large discrepancy is observed, attacker can assume that = reboot has=20 >>> happened (due to V_ts_offset_secret re-generation), hence the = received=20 >>> timestamp is considered an approximate point of reboot from which = the uptime >>> can be calculated, until the next reboot and so on. >> Ahh, I see. The patch we are talking about is not intended to protect = against >> continuous monitoring, which is something you can always do. You = could even >> watch for service availability and detect reboots. A change of the = local key >> would also look similar to a reboot without a temporary loss of = connectivity. >>=20 >> Thanks for the clarification. >>>=20 >>>>>=20 >>>>> There is the list of example hosts that we were able to reproduce = the=20 >>>>> issue with: >>>>>=20 >>>>> curl -v http://88.99.60.171:80 >>>>> curl -v http://163.172.71.252:80 >>>>> curl -v http://5.9.242.150:80 >>>>> curl -v https://185.134.205.105:443 >>>>> curl -v https://136.243.1.231:443 >>>>> curl -v https://144.76.196.4:443 >>>>> curl -v http://94.127.191.194:80 >>>>>=20 >>>>> To reproduce, call curl repeatedly with a same URL some number of = times.=20 >>>>> You are going to see some of the requests stuck in=20 >>>>> `* Trying XXX.XXX.XXX.XXX...` >>>>>=20 >>>>> For some reason, the easiest way to reproduce the issue is with = nc: >>>>>=20 >>>>> $ echo "foooooo" | nc -v 88.99.60.171 80 >>>>>=20 >>>>> Only a few such calls are required until one of them is stuck on = connect(): >>>>> issuing SYN packets with an exponential backoff. >>>> Thanks for providing an end-point to test with. I'll take a look. >>>> Just to be clear: You are running a FreeBSD client against one of = the above >>>> servers and experience the problem with the new timestamp = computations. >>>>=20 >>>> You are not running arbitrary clients against a FreeBSD server... >>>=20 >>> We are talking about FreeBSD being the client. Peers that yield this = unwanted >>> behaviour are unknown. Little bit of tinkering showed that some of = them run=20 >>> Debian: >>>=20 >>> telnet 88.99.60.171 22 >>> Trying 88.99.60.171... >>> Connected to 88.99.60.171. >>> Escape character is '^]'. >>> SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 >> Also some are hosted by Hetzner, but not all. I'll will look into >> this tomorrow, since I'm on a deadline today (well it is 2am tomorrow >> morning, to be precise)... >=20 > Thanks a lot, I would appreciate that. Hi Paul, I have looked into this. * The FreeBSD behaviour is the one which is specified in the last bullet = item in https://tools.ietf.org/html/rfc7323#section-5.4 It is also the one, which is RECOMMENDED in https://tools.ietf.org/html/rfc7323#section-7.1=20 * My NAT box (a popular one in Germany) does NOT rewrite TCP timestamps. This means that the host you are referring to have some sort of = protection, which makes incorrect assumptions. It will also break multiple hosts = behind a NAT. I can run curl -v http://88.99.60.171:80 in a loop without any problems from a FreeBSD head system. I tested 1000 iterations or so. The TS.val is jumping up and down as expected. I'm wondering why you are observing errors in this case, too. However, doing something like echo "foooooo" | nc -v 88.99.60.171 80 triggers the problem. So I think there is some functionality (in a middlebox or running on the = host), which incorrectly assume monotonic timestamps between multiple TCP = connections coming from the same IP address, but only in case of errors at the = application layer. Do you have any insights whether the hosts you are listed share = something in common. Some of them are hosted by Hetzner, but not all. I think in general, it is the correct thing to include the port numbers = in the offset computation. We might add a sysctl variable to control the = inclusion. This would allow interworking with broken middleboxes. Please note, this does not fix the case of multiple clients behind a = NAT. I'm also trying to figure out how and why Linux and Windows are handling = this. Best regards Michael >=20 >>=20 >> Best regards >> Michael=20 >>>=20 >>>=20 >>>>=20 >>>> Best regards >>>> Michael >>>>=20 >>>>=20 >>=20 >>=20 From owner-freebsd-net@freebsd.org Tue Jul 9 12:59:03 2019 Return-Path: Delivered-To: freebsd-net@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 A8E1515D9FF2 for ; Tue, 9 Jul 2019 12:59:03 +0000 (UTC) (envelope-from devgs@ukr.net) Received: from frv198.fwdcdn.com (frv198.fwdcdn.com [212.42.77.198]) (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 "*.ukr.net", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 392918FBC6 for ; Tue, 9 Jul 2019 12:59:03 +0000 (UTC) (envelope-from devgs@ukr.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-Id: References:In-Reply-To:Cc:To:Subject:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=20mxaSdIjlz3sc0lHcaH1DKfhhw9kFhA2WQWWqD40Jg=; b=hk5dpbfMvocKTsBVcZuHEh9Jui 5NX2/0XRuecYQTxUg73wzoTO6GtdvSS0koGYmvzRB4E/DSkIx+UcpG2lIVUk7AT4grKFKRca4WqOq sflyLEIy09T13EjUUrcYzV01EJVC5qX/zTkgFzUlZfoPRr/vo/t9giXuqo5Ay8Nu087E=; Received: from [10.10.10.39] (helo=frv39.fwdcdn.com) by frv198.fwdcdn.com with smtp ID 1hkphu-000EAo-KG for freebsd-net@freebsd.org; Tue, 09 Jul 2019 15:58:54 +0300 Date: Tue, 09 Jul 2019 15:58:54 +0300 From: Paul Subject: Re[2]: Issues with TCP Timestamps allocation To: Michael Tuexen Cc: freebsd-net@freebsd.org Received: from devgs@ukr.net by frv39.fwdcdn.com; Tue, 09 Jul 2019 15:58:54 +0300 In-Reply-To: <0C475A01-9BCD-4E4A-9731-09AB919CA9BE@freebsd.org> References: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> <32FD061B-245C-41D2-81DE-1B4756A7173D@freebsd.org> <1562591379.369129000.gpmxvurq@frv39.fwdcdn.com> <1562599181.734953000.1l9a1d23@frv39.fwdcdn.com> <0C475A01-9BCD-4E4A-9731-09AB919CA9BE@freebsd.org> X-Reply-Action: reply Message-Id: <1562676414.933145000.z3zteyqp@frv39.fwdcdn.com> X-Mailer: mail.ukr.net 5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary X-Rspamd-Queue-Id: 392918FBC6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 12:59:03 -0000 Hi Michael, 9 July 2019, 15:34:29, by "Michael Tuexen" : > > > > On 8. Jul 2019, at 17:22, Paul wrote: > > > > > > > > 8 July 2019, 17:12:21, by "Michael Tuexen" : > > > >>> On 8. Jul 2019, at 15:24, Paul wrote: > >>> > >>> Hi Michael, > >>> > >>> 8 July 2019, 15:53:15, by "Michael Tuexen" : > >>> > >>>>> On 8. Jul 2019, at 12:37, Paul wrote: > >>>>> > >>>>> Hi team, > >>>>> > >>>>> Recently we had an upgrade to 12 Stable. Immediately after, we have started > >>>>> seeing some strange connection establishment timeouts to some fixed number > >>>>> of external (world) hosts. The issue was persistent and easy to reproduce. > >>>>> Thanks to a patience and dedication of our system engineer we have tracked > >>>>> this issue down to a specific commit: > >>>>> > >>>>> https://svnweb.freebsd.org/base?view=revision&revision=338053 > >>>>> > >>>>> This patch was also back-ported into 11 Stable: > >>>>> > >>>>> https://svnweb.freebsd.org/base?view=revision&revision=348435 > >>>>> > >>>>> Among other things this patch changes the timestamp allocation strategy, > >>>>> by introducing a deterministic randomness via a hash function that takes > >>>>> into account a random key as well as source address, source port, dest > >>>>> address and dest port. As the result, timestamp offsets of different > >>>>> tuples (SA,SP,DA,DP) will be wildly different and will jump from small > >>>>> to large numbers and back, as long as something in the tuple changes. > >>>> Hi Paul, > >>>> > >>>> this is correct. > >>>> > >>>> Please note that the same happens with the old method, if two hosts with > >>>> different uptimes are bind a consumer grade NAT. > >>> > >>> If NAT does not replace timestamps then yes, it should be the case. > >>> > >>>>> > >>>>> After performing various tests of hosts that produce the above mentioned > >>>>> issue we came to conclusion that there are some interesting implementations > >>>>> that drop SYN packets with timestamps smaller than the largest timestamp > >>>>> value from streams of all recent or current connections from a specific > >>>>> address. This looks as some kind of SYN flood protection. > >>>> This also breaks multiple hosts with different uptimes behind a consumer > >>>> level NAT talking to such a server. > >>>>> > >>>>> To ensure that each external host is not going to see a wild jumps of > >>>>> timestamp values I propose a patch that removes ports from the equation > >>>>> all together, when calculating the timestamp offset: > >>>>> > >>>>> Index: sys/netinet/tcp_subr.c > >>>>> =================================================================== > >>>>> --- sys/netinet/tcp_subr.c (revision 348435) > >>>>> +++ sys/netinet/tcp_subr.c (working copy) > >>>>> @@ -2224,7 +2224,22 @@ > >>>>> uint32_t > >>>>> tcp_new_ts_offset(struct in_conninfo *inc) > >>>>> { > >>>>> - return (tcp_keyed_hash(inc, V_ts_offset_secret)); > >>>>> + /* > >>>>> + * Some implementations show a strange behaviour when a wildly random > >>>>> + * timestamps allocated for different streams. It seems that only the > >>>>> + * SYN packets are affected. Observed implementations drop SYN packets > >>>>> + * with timestamps smaller than the largest timestamp value of all > >>>>> + * recent or current connections from specific a address. To mitigate > >>>>> + * this we are going to ensure that each host will always observe > >>>>> + * timestamps as increasing no matter the stream: by dropping ports > >>>>> + * from the equation. > >>>>> + */ > >>>>> + struct in_conninfo inc_copy = *inc; > >>>>> + > >>>>> + inc_copy.inc_fport = 0; > >>>>> + inc_copy.inc_lport = 0; > >>>>> + > >>>>> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret)); > >>>>> } > >>>>> > >>>>> /* > >>>>> > >>>>> In any case, the solution of the uptime leak, implemented in rev338053 is > >>>>> not going to suffer, because a supposed attacker is currently able to use > >>>>> any fixed values of SP and DP, albeit not 0, anyway, to remove them out > >>>>> of the equation. > >>>> Can you describe how a peer can compute the uptime from two observed timestamps? > >>>> I don't see how you can do that... > >>> > >>> Supposed attacker could run a script that continuously monitors timestamps, > >>> for example via a periodic TCP connection from a fixed local port (eg 12345) > >>> and a fixed local address to the fixed victim's address and port (eg 80). > >>> Whenever large discrepancy is observed, attacker can assume that reboot has > >>> happened (due to V_ts_offset_secret re-generation), hence the received > >>> timestamp is considered an approximate point of reboot from which the uptime > >>> can be calculated, until the next reboot and so on. > >> Ahh, I see. The patch we are talking about is not intended to protect against > >> continuous monitoring, which is something you can always do. You could even > >> watch for service availability and detect reboots. A change of the local key > >> would also look similar to a reboot without a temporary loss of connectivity. > >> > >> Thanks for the clarification. > >>> > >>>>> > >>>>> There is the list of example hosts that we were able to reproduce the > >>>>> issue with: > >>>>> > >>>>> curl -v http://88.99.60.171:80 > >>>>> curl -v http://163.172.71.252:80 > >>>>> curl -v http://5.9.242.150:80 > >>>>> curl -v https://185.134.205.105:443 > >>>>> curl -v https://136.243.1.231:443 > >>>>> curl -v https://144.76.196.4:443 > >>>>> curl -v http://94.127.191.194:80 > >>>>> > >>>>> To reproduce, call curl repeatedly with a same URL some number of times. > >>>>> You are going to see some of the requests stuck in > >>>>> `* Trying XXX.XXX.XXX.XXX...` > >>>>> > >>>>> For some reason, the easiest way to reproduce the issue is with nc: > >>>>> > >>>>> $ echo "foooooo" | nc -v 88.99.60.171 80 > >>>>> > >>>>> Only a few such calls are required until one of them is stuck on connect(): > >>>>> issuing SYN packets with an exponential backoff. > >>>> Thanks for providing an end-point to test with. I'll take a look. > >>>> Just to be clear: You are running a FreeBSD client against one of the above > >>>> servers and experience the problem with the new timestamp computations. > >>>> > >>>> You are not running arbitrary clients against a FreeBSD server... > >>> > >>> We are talking about FreeBSD being the client. Peers that yield this unwanted > >>> behaviour are unknown. Little bit of tinkering showed that some of them run > >>> Debian: > >>> > >>> telnet 88.99.60.171 22 > >>> Trying 88.99.60.171... > >>> Connected to 88.99.60.171. > >>> Escape character is '^]'. > >>> SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 > >> Also some are hosted by Hetzner, but not all. I'll will look into > >> this tomorrow, since I'm on a deadline today (well it is 2am tomorrow > >> morning, to be precise)... > > > > Thanks a lot, I would appreciate that. > Hi Paul, > > I have looked into this. > > * The FreeBSD behaviour is the one which is specified in the last bullet item > in https://tools.ietf.org/html/rfc7323#section-5.4 > It is also the one, which is RECOMMENDED in > https://tools.ietf.org/html/rfc7323#section-7.1 > > * My NAT box (a popular one in Germany) does NOT rewrite TCP timestamps. > > This means that the host you are referring to have some sort of protection, > which makes incorrect assumptions. It will also break multiple hosts behind > a NAT. > > I can run > curl -v http://88.99.60.171:80 > in a loop without any problems from a FreeBSD head system. I tested 1000 > iterations or so. The TS.val is jumping up and down as expected. > I'm wondering why you are observing errors in this case, too. > > However, doing something like > echo "foooooo" | nc -v 88.99.60.171 80 > triggers the problem. > > So I think there is some functionality (in a middlebox or running on the host), > which incorrectly assume monotonic timestamps between multiple TCP connections > coming from the same IP address, but only in case of errors at the application layer. Yeah, exactly, some hosts seem to enable this only in case of an error in HTTP communication (some smart proxy?). However, there are some that behave this way regardless of errors, for example these: curl -v https://185.134.205.105:443 curl -v https://136.243.1.231:443 > > Do you have any insights whether the hosts you are listed share something in > common. Some of them are hosted by Hetzner, but not all. Nope. A whole set of endpoints that we have detected so far is pretty diverse, containing a lot of different locations geographically, as well as different hosters. > > I think in general, it is the correct thing to include the port numbers in > the offset computation. We might add a sysctl variable to control the inclusion. > This would allow interworking with broken middleboxes. Yeah, I completely agree that these rare cases should not dictate the implementation. But an ability to enable a work-around via sysctl would be greatly appreciated. Currently we are unable to roll-out the upgrade across all servers because of this issue: even though it happens not so often, a lot of requests from our users get stuck or fail all together. For example, a host 185.134.205.105 is a kind of social network that our proxy servers connect to so securely access to content, such as images, on behalf of our users. > > Please note, this does not fix the case of multiple clients behind a NAT. Yeah, that's true. Fortunately we don't use NAT. > > I'm also trying to figure out how and why Linux and Windows are handling this. Thanks for bothering! > > Best regards > Michael > > > > >> > >> Best regards > >> Michael > >>> > >>> > >>>> > >>>> Best regards > >>>> Michael > >>>> > >>>> > >> > >> > > From owner-freebsd-net@freebsd.org Tue Jul 9 14:27:07 2019 Return-Path: Delivered-To: freebsd-net@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 80E2E15DBED9 for ; Tue, 9 Jul 2019 14:27:07 +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 1A4276C66E for ; Tue, 9 Jul 2019 14:27:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D06C615DBED7; Tue, 9 Jul 2019 14:27:06 +0000 (UTC) Delivered-To: net@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 BE37315DBED6 for ; Tue, 9 Jul 2019 14:27:06 +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 5B6856C66A for ; Tue, 9 Jul 2019 14:27:06 +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 A32A218740 for ; Tue, 9 Jul 2019 14:27:05 +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 x69ER57t070453 for ; Tue, 9 Jul 2019 14:27:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x69ER5oa070452 for net@FreeBSD.org; Tue, 9 Jul 2019 14:27:05 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Tue, 09 Jul 2019 14:27:05 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: msl0000023508@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 14:27:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #12 from WHR --- (In reply to Cy Schubert from comment #11) Although this bug is always reproduce on that particular machine, with both 12.0-STABLE and 13.0-CURRENT kernels, I failed to reproduce it on a testing= VM. I plan to install another test VM with FreeBSD 13.0-CURRENT, tomorrow. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 15:30:05 2019 Return-Path: Delivered-To: freebsd-net@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 4C75415DD02D for ; Tue, 9 Jul 2019 15:30:05 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CABEE6E6E0 for ; Tue, 9 Jul 2019 15:30:04 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2a02:8109:1140:c3d:1c7:520c:e8a0:1e52] (unknown [IPv6:2a02:8109:1140:c3d:1c7:520c:e8a0:1e52]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id DF85C71E3F456; Tue, 9 Jul 2019 17:29:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Issues with TCP Timestamps allocation From: Michael Tuexen In-Reply-To: <1562676414.933145000.z3zteyqp@frv39.fwdcdn.com> Date: Tue, 9 Jul 2019 17:29:57 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1E9F3F99-C3E9-44DD-AA70-9B11E19D4769@freebsd.org> References: <1562579483.67527000.24rw4xi5@frv39.fwdcdn.com> <32FD061B-245C-41D2-81DE-1B4756A7173D@freebsd.org> <1562591379.369129000.gpmxvurq@frv39.fwdcdn.com> <1562599181.734953000.1l9a1d23@frv39.fwdcdn.com> <0C475A01-9BCD-4E4A-9731-09AB919CA9BE@freebsd.org> <1562676414.933145000.z3zteyqp@frv39.fwdcdn.com> To: Paul X-Mailer: Apple Mail (2.3445.104.11) X-Spam-Status: No, score=-1.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 15:30:05 -0000 > On 9. Jul 2019, at 14:58, Paul wrote: >=20 > Hi Michael, >=20 > 9 July 2019, 15:34:29, by "Michael Tuexen" : >=20 >>=20 >>=20 >>> On 8. Jul 2019, at 17:22, Paul wrote: >>>=20 >>>=20 >>>=20 >>> 8 July 2019, 17:12:21, by "Michael Tuexen" : >>>=20 >>>>> On 8. Jul 2019, at 15:24, Paul wrote: >>>>>=20 >>>>> Hi Michael, >>>>>=20 >>>>> 8 July 2019, 15:53:15, by "Michael Tuexen" : >>>>>=20 >>>>>>> On 8. Jul 2019, at 12:37, Paul wrote: >>>>>>>=20 >>>>>>> Hi team, >>>>>>>=20 >>>>>>> Recently we had an upgrade to 12 Stable. Immediately after, we = have started=20 >>>>>>> seeing some strange connection establishment timeouts to some = fixed number >>>>>>> of external (world) hosts. The issue was persistent and easy to = reproduce. >>>>>>> Thanks to a patience and dedication of our system engineer we = have tracked =20 >>>>>>> this issue down to a specific commit: >>>>>>>=20 >>>>>>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D338053 >>>>>>>=20 >>>>>>> This patch was also back-ported into 11 Stable: >>>>>>>=20 >>>>>>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D348435 >>>>>>>=20 >>>>>>> Among other things this patch changes the timestamp allocation = strategy, >>>>>>> by introducing a deterministic randomness via a hash function = that takes >>>>>>> into account a random key as well as source address, source = port, dest >>>>>>> address and dest port. As the result, timestamp offsets of = different >>>>>>> tuples (SA,SP,DA,DP) will be wildly different and will jump from = small=20 >>>>>>> to large numbers and back, as long as something in the tuple = changes. >>>>>> Hi Paul, >>>>>>=20 >>>>>> this is correct. >>>>>>=20 >>>>>> Please note that the same happens with the old method, if two = hosts with >>>>>> different uptimes are bind a consumer grade NAT. >>>>>=20 >>>>> If NAT does not replace timestamps then yes, it should be the = case. >>>>>=20 >>>>>>>=20 >>>>>>> After performing various tests of hosts that produce the above = mentioned=20 >>>>>>> issue we came to conclusion that there are some interesting = implementations=20 >>>>>>> that drop SYN packets with timestamps smaller than the largest = timestamp=20 >>>>>>> value from streams of all recent or current connections from a = specific=20 >>>>>>> address. This looks as some kind of SYN flood protection. >>>>>> This also breaks multiple hosts with different uptimes behind a = consumer >>>>>> level NAT talking to such a server. >>>>>>>=20 >>>>>>> To ensure that each external host is not going to see a wild = jumps of=20 >>>>>>> timestamp values I propose a patch that removes ports from the = equation >>>>>>> all together, when calculating the timestamp offset: >>>>>>>=20 >>>>>>> Index: sys/netinet/tcp_subr.c >>>>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> --- sys/netinet/tcp_subr.c (revision 348435) >>>>>>> +++ sys/netinet/tcp_subr.c (working copy) >>>>>>> @@ -2224,7 +2224,22 @@ >>>>>>> uint32_t >>>>>>> tcp_new_ts_offset(struct in_conninfo *inc) >>>>>>> { >>>>>>> - return (tcp_keyed_hash(inc, V_ts_offset_secret)); >>>>>>> + /*=20 >>>>>>> + * Some implementations show a strange behaviour when a = wildly random=20 >>>>>>> + * timestamps allocated for different streams. It seems = that only the >>>>>>> + * SYN packets are affected. Observed implementations = drop SYN packets >>>>>>> + * with timestamps smaller than the largest timestamp = value of all=20 >>>>>>> + * recent or current connections from specific a = address. To mitigate=20 >>>>>>> + * this we are going to ensure that each host will = always observe=20 >>>>>>> + * timestamps as increasing no matter the stream: by = dropping ports >>>>>>> + * from the equation. >>>>>>> + */=20 >>>>>>> + struct in_conninfo inc_copy =3D *inc; >>>>>>> + >>>>>>> + inc_copy.inc_fport =3D 0; >>>>>>> + inc_copy.inc_lport =3D 0; >>>>>>> + >>>>>>> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret)); >>>>>>> } >>>>>>>=20 >>>>>>> /* >>>>>>>=20 >>>>>>> In any case, the solution of the uptime leak, implemented in = rev338053 is=20 >>>>>>> not going to suffer, because a supposed attacker is currently = able to use=20 >>>>>>> any fixed values of SP and DP, albeit not 0, anyway, to remove = them out=20 >>>>>>> of the equation. >>>>>> Can you describe how a peer can compute the uptime from two = observed timestamps? >>>>>> I don't see how you can do that... >>>>>=20 >>>>> Supposed attacker could run a script that continuously monitors = timestamps, >>>>> for example via a periodic TCP connection from a fixed local port = (eg 12345)=20 >>>>> and a fixed local address to the fixed victim's address and port = (eg 80). >>>>> Whenever large discrepancy is observed, attacker can assume that = reboot has=20 >>>>> happened (due to V_ts_offset_secret re-generation), hence the = received=20 >>>>> timestamp is considered an approximate point of reboot from which = the uptime >>>>> can be calculated, until the next reboot and so on. >>>> Ahh, I see. The patch we are talking about is not intended to = protect against >>>> continuous monitoring, which is something you can always do. You = could even >>>> watch for service availability and detect reboots. A change of the = local key >>>> would also look similar to a reboot without a temporary loss of = connectivity. >>>>=20 >>>> Thanks for the clarification. >>>>>=20 >>>>>>>=20 >>>>>>> There is the list of example hosts that we were able to = reproduce the=20 >>>>>>> issue with: >>>>>>>=20 >>>>>>> curl -v http://88.99.60.171:80 >>>>>>> curl -v http://163.172.71.252:80 >>>>>>> curl -v http://5.9.242.150:80 >>>>>>> curl -v https://185.134.205.105:443 >>>>>>> curl -v https://136.243.1.231:443 >>>>>>> curl -v https://144.76.196.4:443 >>>>>>> curl -v http://94.127.191.194:80 >>>>>>>=20 >>>>>>> To reproduce, call curl repeatedly with a same URL some number = of times.=20 >>>>>>> You are going to see some of the requests stuck in=20 >>>>>>> `* Trying XXX.XXX.XXX.XXX...` >>>>>>>=20 >>>>>>> For some reason, the easiest way to reproduce the issue is with = nc: >>>>>>>=20 >>>>>>> $ echo "foooooo" | nc -v 88.99.60.171 80 >>>>>>>=20 >>>>>>> Only a few such calls are required until one of them is stuck on = connect(): >>>>>>> issuing SYN packets with an exponential backoff. >>>>>> Thanks for providing an end-point to test with. I'll take a look. >>>>>> Just to be clear: You are running a FreeBSD client against one of = the above >>>>>> servers and experience the problem with the new timestamp = computations. >>>>>>=20 >>>>>> You are not running arbitrary clients against a FreeBSD server... >>>>>=20 >>>>> We are talking about FreeBSD being the client. Peers that yield = this unwanted >>>>> behaviour are unknown. Little bit of tinkering showed that some of = them run=20 >>>>> Debian: >>>>>=20 >>>>> telnet 88.99.60.171 22 >>>>> Trying 88.99.60.171... >>>>> Connected to 88.99.60.171. >>>>> Escape character is '^]'. >>>>> SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 >>>> Also some are hosted by Hetzner, but not all. I'll will look into >>>> this tomorrow, since I'm on a deadline today (well it is 2am = tomorrow >>>> morning, to be precise)... >>>=20 >>> Thanks a lot, I would appreciate that. >> Hi Paul, >>=20 >> I have looked into this. >>=20 >> * The FreeBSD behaviour is the one which is specified in the last = bullet item >> in https://tools.ietf.org/html/rfc7323#section-5.4 >> It is also the one, which is RECOMMENDED in >> https://tools.ietf.org/html/rfc7323#section-7.1=20 >>=20 >> * My NAT box (a popular one in Germany) does NOT rewrite TCP = timestamps. >>=20 >> This means that the host you are referring to have some sort of = protection, >> which makes incorrect assumptions. It will also break multiple hosts = behind >> a NAT. >>=20 >> I can run >> curl -v http://88.99.60.171:80 >> in a loop without any problems from a FreeBSD head system. I tested = 1000 >> iterations or so. The TS.val is jumping up and down as expected. >> I'm wondering why you are observing errors in this case, too. >>=20 >> However, doing something like >> echo "foooooo" | nc -v 88.99.60.171 80 >> triggers the problem. >>=20 >> So I think there is some functionality (in a middlebox or running on = the host), >> which incorrectly assume monotonic timestamps between multiple TCP = connections >> coming from the same IP address, but only in case of errors at the = application layer. >=20 > Yeah, exactly, some hosts seem to enable this only in case of an error = in HTTP > communication (some smart proxy?). However, there are some that behave = this way > regardless of errors, for example these: >=20 > curl -v https://185.134.205.105:443 > curl -v https://136.243.1.231:443 Wireshark sees an Encrypted Alert in both cases. So I guess this is = another indication of "error at the application layer". >=20 >>=20 >> Do you have any insights whether the hosts you are listed share = something in >> common. Some of them are hosted by Hetzner, but not all. >=20 > Nope. A whole set of endpoints that we have detected so far is pretty = diverse, > containing a lot of different locations geographically, as well as = different > hosters. OK. Thanks for the clarification. >=20 >>=20 >> I think in general, it is the correct thing to include the port = numbers in >> the offset computation. We might add a sysctl variable to control the = inclusion. >> This would allow interworking with broken middleboxes. >=20 > Yeah, I completely agree that these rare cases should not dictate the = implementation. > But an ability to enable a work-around via sysctl would be greatly = appreciated. > Currently we are unable to roll-out the upgrade across all servers = because of this > issue: even though it happens not so often, a lot of requests from our = users=20 > get stuck or fail all together. For example, a host 185.134.205.105 is = a kind of > social network that our proxy servers connect to so securely access to = content, > such as images, on behalf of our users. >=20 >>=20 >> Please note, this does not fix the case of multiple clients behind a = NAT. >=20 > Yeah, that's true. Fortunately we don't use NAT. >=20 >>=20 >> I'm also trying to figure out how and why Linux and Windows are = handling this. >=20 > Thanks for bothering! Will let you know what I figure out. Best regards Michael >=20 >>=20 >> Best regards >> Michael >>=20 >>>=20 >>>>=20 >>>> Best regards >>>> Michael=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 From owner-freebsd-net@freebsd.org Tue Jul 9 18:27:37 2019 Return-Path: Delivered-To: freebsd-net@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 1F8C415E14FF for ; Tue, 9 Jul 2019 18:27:37 +0000 (UTC) (envelope-from Alexander@leidinger.net) 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 71FBB76B72 for ; Tue, 9 Jul 2019 18:27:36 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 2DD4015E14F9; Tue, 9 Jul 2019 18:27:36 +0000 (UTC) Delivered-To: net@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 0A68B15E14F6; Tue, 9 Jul 2019 18:27:36 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D98B776B68; Tue, 9 Jul 2019 18:27:29 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5B1651BC.dip0.t-ipconnect.de [91.22.81.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 8F05828B55; Tue, 9 Jul 2019 20:27:17 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 8659A306D; Tue, 9 Jul 2019 20:26:42 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.15.2/8.14.4/Submit) id x69IQeoh017613; Tue, 9 Jul 2019 20:26:40 +0200 (CEST) (envelope-from Alexander@leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@leidinger.net using -f Received: from IO.Leidinger.net (IO.Leidinger.net [192.168.1.11]) by webmail.leidinger.net (Horde Framework) with HTTPS; Tue, 09 Jul 2019 20:26:40 +0200 Date: Tue, 09 Jul 2019 20:26:40 +0200 Message-ID: <20190709202640.Horde.NiJw42D0neU2FjppH2RxdYB@webmail.leidinger.net> From: Alexander Leidinger To: current@freebsd.org, net@freebsd.org, jail@freebsd.org Subject: panic on epair destroy in current as of r349853, jail related User-Agent: Horde Application Framework 5 Accept-Language: de,en Content-Type: multipart/signed; boundary="=_zTkON1xidMr3iv3yK_ktBod"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1562696838; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=nqpdNGUD5IByBOwj92gzZa16x66pflXuqzAsDGVOyqE=; b=cTImwBl0HAr+HqrDVsXl+gmVpY5lZZ9GtesHP2uNG7WSjQNwQqaGn9RmqSLwXas37f/J6D 8+ixOGI2nOcCNJl3OWSCqFU7i7LTlaGU/i9kdiMK5go1SUGLZU0ZV70PInz81jFnkCx9aX feBkKCu9KiHHwSQUNBX4TPJnNKohpID9svVUlsBBsWp5oermV9oE0ccl6G7Gv5t5eISzzo vcjCUTIYYSzffSIZ2JopzCnQcWSsATHcCN4eAKOvy+sHNqDb5haAG4sgIaDZFvf/UVPd0I t4COdLNDk+b9l9ORAmXtqJ+cMP1y/d1YZehANnM0Gmd8g0IrX4mJMF+0jJ7Wtg== ARC-Seal: i=1; s=outgoing-alex; d=leidinger.net; t=1562696838; a=rsa-sha256; cv=none; b=eFf/DjyQsovLLtmpkejNk3ohqgqrk6bhMAJq5CPbxE4uWBMFy7CvIEFnenng3vAjQLE/1x CsK5j3Cr53woOw5shymjagjOlWCUBNPuFRXFk1LtfDVdUVO6WtjOFG3GLxXuk58pQia9IU cIDm5rLM/x7ROWJ0Pk5kqVyGne4sZM5v2spRqOV1EiCCt4u2OX2bUe2Ao/KEk6xapVzDqs Sl6oqYVsfrAtVwRVYb9/EyOIqUy1D5Rlboy70g4JDXr3/rDuFwxbBl+Fn0ct248yFkZnRt b32MtxJqhoWJuB+hPGxEiztGnFBVMGTxpexqlfej2huoFrP19M2/dGbHxFLBhw== ARC-Authentication-Results: i=1; mailgate.Leidinger.net; auth=pass smtp.auth=netchild@leidinger.net smtp.mailfrom=Alexander@leidinger.net X-Rspamd-Queue-Id: D98B776B68 X-Spamd-Bar: --------- X-Spamd-Result: default: False [-9.77 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; XAW_SERVICE_ACCT(1.00)[]; IP_SCORE(-3.71)[ip: (-9.79), ipnet: 2a00:1828::/32(-4.88), asn: 34240(-3.87), country: DE(-0.01)]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MX_GOOD(-0.01)[mailgate.leidinger.net]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.949,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; ARC_ALLOW(-1.00)[i=1]; RECEIVED_SPAMHAUS_PBL(0.00)[188.81.22.91.zen.spamhaus.org : 127.0.0.10] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 18:27:37 -0000 This message is in MIME format and has been PGP signed. --=_zTkON1xidMr3iv3yK_ktBod Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I updated from r347365 to r349853. Now I get a panic on epair destroy=20=20 (one=20end needs to be in a jail, and inside the jail an IP address=20=20 needs=20to be assigned to the epair. If no ifconfig is used inside the=20= =20 jail,=20there is no panic. Another user reported something similar (but for him it was enough to=20=20 list=20the interfaces inside the jail with ifconfig) in PR 234985: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234985 Backtrace (here I also renamed the interface before attaching it to=20=20 the=20jail, as I detected the issue with interfaces which are renamed): Fatal trap 9: general protection fault while in kernel mode cpuid =3D 13; apic id =3D 33 instruction pointer =3D 0x20:0xffffffff805f2045 stack pointer =3D 0x28:0xfffffe0159822880 frame pointer =3D 0x28:0xfffffe0159822880 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 43334 (ifconfig) trap number =3D 9 panic: general protection fault cpuid =3D 13 time =3D 1562695289 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0159822= 590 vpanic() at vpanic+0x19d/frame 0xfffffe01598225e0 panic() at panic+0x43/frame 0xfffffe0159822640 trap_fatal() at trap_fatal+0x39c/frame 0xfffffe01598226a0 trap() at trap+0x6c/frame 0xfffffe01598227b0 calltrap() at calltrap+0x8/frame 0xfffffe01598227b0 --- trap 0x9, rip =3D 0xffffffff805f2045, rsp =3D 0xfffffe0159822880, rbp= =20=20 =3D 0xfffffe0159822880 --- strncmp() at strncmp+0x15/frame 0xfffffe0159822880 ifunit_ref() at ifunit_ref+0x51/frame 0xfffffe01598228c0 ifioctl() at ifioctl+0x508/frame 0xfffffe0159822990 kern_ioctl() at kern_ioctl+0x26d/frame 0xfffffe0159822a00 sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe0159822ad0 amd64_syscall() at amd64_syscall+0x23a/frame 0xfffffe0159822bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0159822bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x8004690da, rsp =3D=20= =20 0x7fffffffe448,=20rbp =3D 0x7fffffffe4b0 --- Uptime: 3h34m59s Dumping 5294 out of 61352 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..= 91% __curthread () at /space/system/usr_src/sys/amd64/include/pcpu.h:246 246 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n"=20=20 (OFFSETOF_CURTHREAD)); (kgdb)=20#0 __curthread () at=20=20 /space/system/usr_src/sys/amd64/include/pcpu.h:246 #1=20 doadump (textdump=3D1) at /space/system/usr_src/sys/kern/kern_shutdow= n.c:392 #2 0xffffffff8050cf70 in kern_reboot (howto=3D260) at /space/system/usr_src/sys/kern/kern_shutdown.c:479 #3 0xffffffff8050d3e9 in vpanic (fmt=3D, ap=3D) at /space/system/usr_src/sys/kern/kern_shutdown.c:905 #4 0xffffffff8050d123 in panic (fmt=3D) at /space/system/usr_src/sys/kern/kern_shutdown.c:832 #5 0xffffffff807e758c in trap_fatal (frame=3D0xfffffe01598227c0, eva=3D0) at /space/system/usr_src/sys/amd64/amd64/trap.c:943 #6 0xffffffff807e698c in trap (frame=3D0xfffffe01598227c0) at /space/system/usr_src/sys/amd64/amd64/trap.c:221 #7 #8 0xffffffff805f2045 in strncmp (s1=3D, s2=3D, n=3D) at /space/system/usr_src/sys/libkern/strncmp.c:44 #9 0xffffffff80605d31 in ifunit_ref (name=3D0xfffffe0159822a20 "panic_test= 1b") at /space/system/usr_src/sys/net/if.c:2434 #10 0xffffffff80607ef8 in ifioctl (so=3D0xfffff809a1afd368, cmd=3D322334953= 6, data=3D0xfffffe0159822a20 "panic_test1b", td=3D0xfffff8014c83e5a0) at /space/system/usr_src/sys/net/if.c:3093 #11 0xffffffff8057658d in fo_ioctl (fp=3D, com=3D3223349536, data=3D0xfffff800020e2180, active_cred=3D0x0, td=3D0xfffff8014c83e5a0) at /space/system/usr_src/sys/sys/file.h:333 #12 kern_ioctl (td=3D0xfffff8014c83e5a0, fd=3D3, com=3D3223349536, data=3D0xfffff800020e2180 "") at /space/system/usr_src/sys/kern/sys_generic.c:800 #13 0xffffffff805762ad in sys_ioctl (td=3D0xfffff8014c83e5a0, uap=3D0xfffff8014c83e968) at=20=20 /space/system/usr_src/sys/kern/sys_generic.c:712 #14=200xffffffff807e801a in syscallenter (td=3D0xfffff8014c83e5a0) at /space/system/usr_src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #15 amd64_syscall (td=3D0xfffff8014c83e5a0, traced=3D0) at /space/system/usr_src/sys/amd64/amd64/trap.c:1181 #16 #17 0x00000008004690da in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffe448 Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_zTkON1xidMr3iv3yK_ktBod Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJdJNxgAAoJEBINsJsD+NiGMS8P/2GFWrYagdCX594w6jgqVm6j En+B0rT9UYT6c1sQqaA+QoDciGr0PdYEQEYuyNK51/zqfCA2ycT+9EZnIzXyRwtz wr7wbFUpe8owBrX+oUKe2h4c3WkBDJje01GtsAU1ZjUF7+i3Bm37+2VEozzs99wd JHR9rErFD5Jngki0pOrnMAnlXjMHkAp0d/Gtrh95ulfXzKSB+LSq0+wAJw0zGFrg 19thf+QiF9a2YEQiHJe2NlqTO/cXIwVyFKnivh14lCEtFAXpn8THl4ZGY/D4C0Fw A1jc0Edyqp3E31YlWhOMorA4BacAxQCPdSRDQigniEDEdZK9UUWI6XrKZmp9aXcK kiRseKpKVRey5XhUhABx7LiefkbEVTPNdgefq5EBSGEwHuT9mUzWTlIjm+RpPTsI SA00GAL5joQjEjHybF3zb4wl61g9pbNp2D63i8Ed5zWLMR6bNYBHG3276bqrRXRV 591IxrdGlF2xciKIyJLRd27Sw308SNX3EWZSLs0GO7hX821mzkP/+93XOtjcAPkx AU7E3TaaVSq6RvBRYayH7s57SOgH4/Xq5EjhRJQIhiSU6+gZ3xoZueRhMQ+6wV29 1IZf1RpvhwjkW8vsa3hNRfflwxwN7XZXiGqhM8ZB4pmdF/wGqbL5Jttuhc/R6KHQ zq2Q1GQ6c8lW1+wVQEV8 =C1e5 -----END PGP SIGNATURE----- --=_zTkON1xidMr3iv3yK_ktBod-- From owner-freebsd-net@freebsd.org Tue Jul 9 19:18:03 2019 Return-Path: Delivered-To: freebsd-net@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 F192D15E2E31 for ; Tue, 9 Jul 2019 19:18:02 +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 8B4AC8144D for ; Tue, 9 Jul 2019 19:18:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4D07F15E2E2F; Tue, 9 Jul 2019 19:18:02 +0000 (UTC) Delivered-To: net@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 3B1F815E2E2D for ; Tue, 9 Jul 2019 19:18:02 +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 CB4E28144A for ; Tue, 9 Jul 2019 19:18:01 +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 0FC1A1B082 for ; Tue, 9 Jul 2019 19:18:01 +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 x69JI0VB062051 for ; Tue, 9 Jul 2019 19:18:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x69JI0kX062050 for net@FreeBSD.org; Tue, 9 Jul 2019 19:18:00 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Tue, 09 Jul 2019 19:18:00 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 19:18:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #13 from Cy Schubert --- Unfortunately I cannot accept patches until I can reproduce the problem her= e. I have tested the rule in a VM with INVARIANTS and on my production firewall without INVARIANTS. I am unable to verify that this is a bug. Or, what makes your one machine different from all the others needs to be discovered. Then= I can reproduce it here. If you can provide me with something I can reproduce= the scenario here I will be open to committing an updated version of your patch. Otherwise I am not able to justify an unverified patch. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Tue Jul 9 21:45:12 2019 Return-Path: Delivered-To: freebsd-net@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 40B2515E6CD1 for ; Tue, 9 Jul 2019 21:45:12 +0000 (UTC) (envelope-from srick@gefjun.hzn.srick.org) Received: from gefjun.hzn.srick.org (jail1.hzn.srick.org [188.40.60.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gefjun.srick.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E169788561 for ; Tue, 9 Jul 2019 21:45:09 +0000 (UTC) (envelope-from srick@gefjun.hzn.srick.org) Received: from gefjun.hzn.srick.org (localhost [127.0.0.1]) by gefjun.hzn.srick.org (8.15.2/8.15.2) with ESMTPS id x69LhkWV043329 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 9 Jul 2019 22:43:46 +0100 (BST) (envelope-from srick@gefjun.hzn.srick.org) Received: (from srick@localhost) by gefjun.hzn.srick.org (8.15.2/8.15.2/Submit) id x69LhkZ5043328 for freebsd-net@freebsd.org; Tue, 9 Jul 2019 22:43:46 +0100 (BST) (envelope-from srick) Date: Tue, 9 Jul 2019 22:43:46 +0100 From: Steffen Rick To: freebsd-net@freebsd.org Subject: Re: ipfilter not creating entries in the state table Message-ID: <20190709214346.GA42407@gefjun.hzn.srick.org> References: <20190703164229.GA5930@gefjun.hzn.srick.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190703164229.GA5930@gefjun.hzn.srick.org> User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: E169788561 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [4.32 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.17)[-0.170,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.15)[0.146,0]; MX_GOOD(-0.01)[gefjun.hzn.srick.org]; MX_MISSING(3.50)[requested record is not found]; DMARC_NA(0.00)[srick.org]; NEURAL_SPAM_MEDIUM(0.42)[0.419,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[steffen.rick@srick.org,srick@gefjun.hzn.srick.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:188.40.0.0/16, country:DE]; FROM_NEQ_ENVFROM(0.00)[steffen.rick@srick.org,srick@gefjun.hzn.srick.org]; IP_SCORE(-0.76)[ipnet: 188.40.0.0/16(-2.02), asn: 24940(-1.79), country: DE(-0.01)] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 21:45:12 -0000 Any chance someone with a better understanding of how stateful firewall rules work able to take a look at this with me? I'm trying to make my firewall ruleset rock solid in the long run and this is one of the occasions where Ihaven't been able to do so yet. Any comment appreciated! Steffen On Wed, Jul 03, 2019 at 05:42:29PM +0100, Steffen Rick wrote: > Hi, > > hoping you guys can help me with this. I'm somehow unable to create an > ipfilter configuration that will use stateful filtering on IPv6. What > I have is a very simple ipf.rules file: > > ipf.rules: > pass in quick on lo0 all > pass out quick on lo0 all > > pass out quick on re0 all keep state > > pass in quick on re0 proto tcp from any to any port = 22 > > block in log quick on re0 all > > default kernel wise is to accept traffic > (I do this to not log myself out when working remotely) > > When I lookup www.google.com over IPv4 I get an entry in the state table > > dig -A www.google.com @8.8.8.8 > ipfstat -t > Src: 0.0.0.0, Dest: 0.0.0.0, Proto: any, Sorted by: # bytes > > Source IP Destination IP ST PR #pkts #bytes ttl > 188.40.60.69,22 80.79.143.188,47160 4/4 tcp 75 14048 119:59:59 > 188.40.60.96,51126 8.8.8.8,53 0/0 udp 1 83 0:03 > > When I try to lookup the A record on the IPv6 server I get no state table entry > > dig -A www.google.com @2001:4860:4860::8888 > no state table entry and no response from the server > > tcpdump -nnn host 2001:4860:4860::8888 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes > 16:48:48.588867 IP6 2a01:4f8:221:181::2.62706 > 2001:4860:4860::8888.53: 15010+ [1au] A? www.google.com. (55) > 16:48:48.602580 IP6 2001:4860:4860::8888.53 > 2a01:4f8:221:181::2.62706: 15010 1/0/1 A 216.58.206.4 (59) > 16:48:53.663637 IP6 2a01:4f8:221:181::2.62706 > 2001:4860:4860::8888.53: 15010+ [1au] A? www.google.com. (55) > 16:48:53.668845 IP6 2001:4860:4860::8888.53 > 2a01:4f8:221:181::2.62706: 15010 1/0/1 A 216.58.206.4 (59) > 16:48:58.744154 IP6 2a01:4f8:221:181::2.62706 > 2001:4860:4860::8888.53: 15010+ [1au] A? www.google.com. (55) > 16:48:58.764794 IP6 2001:4860:4860::8888.53 > 2a01:4f8:221:181::2.62706: 15010 1/0/1 A 216.58.206.4 (59) > ^C > > The request seems to have gone through just fine but my dig client times out. > > I change the ruleset to include > > pass in quick on re0 inet6 proto tcp from any port = 53 > pass in quick on re0 inet6 proto udp from any port = 53 > > and then I'm obviously able to get a response from the server. > > tcpdump -nnn host 2001:4860:4860::8888 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes > 16:47:36.738177 IP6 2a01:4f8:221:181::2.40852 > 2001:4860:4860::8888.53: 54683+ [1au] A? www.google.com. (55) > 16:47:36.751447 IP6 2001:4860:4860::8888.53 > 2a01:4f8:221:181::2.40852: 54683 1/0/1 A 172.217.18.164 (59) > ^C > > That obiously ignores the statefulness of the firewall. Is this a > known issue? Has anyone ipfilter working with stateful rules correctly > being created when making outbound requests? > > Any help appreciated! > > Thanks, > Steffen > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Wed Jul 10 03:40:24 2019 Return-Path: Delivered-To: freebsd-net@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 B111315ED14C for ; Wed, 10 Jul 2019 03:40:24 +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 38E226DB43 for ; Wed, 10 Jul 2019 03:40:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id F044815ED14B; Wed, 10 Jul 2019 03:40:23 +0000 (UTC) Delivered-To: net@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 DEAA415ED14A for ; Wed, 10 Jul 2019 03:40:23 +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 70AB26DB3F for ; Wed, 10 Jul 2019 03:40:23 +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 ADCB71F85C for ; Wed, 10 Jul 2019 03:40:22 +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 x6A3eMBR015745 for ; Wed, 10 Jul 2019 03:40:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6A3eMVU015744 for net@FreeBSD.org; Wed, 10 Jul 2019 03:40:22 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Wed, 10 Jul 2019 03:40:22 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: msl0000023508@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 03:40:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #14 from WHR --- Good news. I has reproduced this bug in a FreeBSD 13.0-CURRENT r349753 test= ing VM. The steps are: kldload ipl.ko ifconfig tun0 plumb ifconfig tun1 plumb echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - echo "pass in quick reply-to tun1:10.1.2.1 on tun1 proto tcp from any to 10.1.2.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - ipfstat -Rion echo "pass in quick route-to tun1:10.1.2.1 on em0 proto tcp from 10.0.3.63 = to any" | ipf -f - echo "pass in quick route-to tun0:10.1.1.1 on em0 proto tcp from 10.0.3.64 = to any port =3D 23" | ipf -f - echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - ipfstat -Ri ipfstat -Ri | ipf -f - Please tell if you want the VM configuration or the disk image. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Jul 10 06:04:55 2019 Return-Path: Delivered-To: freebsd-net@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 17EAD15CB627 for ; Wed, 10 Jul 2019 06:04:55 +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 A188F7220C for ; Wed, 10 Jul 2019 06:04:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6126415CB626; Wed, 10 Jul 2019 06:04:54 +0000 (UTC) Delivered-To: net@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 4E49515CB624 for ; Wed, 10 Jul 2019 06:04:54 +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 DD27F72208 for ; Wed, 10 Jul 2019 06:04:53 +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 25E4AE05 for ; Wed, 10 Jul 2019 06:04:53 +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 x6A64qJf055789 for ; Wed, 10 Jul 2019 06:04:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6A64qkx055777 for net@FreeBSD.org; Wed, 10 Jul 2019 06:04:52 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Wed, 10 Jul 2019 06:04:53 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 06:04:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #15 from Cy Schubert --- That's perfect, thank you. I'll do some testing here. I suspect the cause is similar to a panic I am working on. Use your patch or the improved patch I posted here while I dig into the root cause. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Wed Jul 10 17:53:40 2019 Return-Path: Delivered-To: freebsd-net@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 60D9E15DE7B8 for ; Wed, 10 Jul 2019 17:53:40 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2BE56829E for ; Wed, 10 Jul 2019 17:53:37 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: by mail-vk1-xa29.google.com with SMTP id w186so641392vkd.11 for ; Wed, 10 Jul 2019 10:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sflvwY1MuuMpFQB1bMAol+c3hn3+9kMzul9bAPKcGx8=; b=iR67GM4k8LubWSzVR3uLwAG4dxqq5Fr6WLpJZMGElIvikcAuj+vRhkgXuG0f+7yPPQ s7MZAqtNNIxItwXJadfhWMhiXVx2nQOM29RTZKhtugoMwGLm9rlH2x5/rcHWSb3T7awE lfb8vqDEcoWhEvgAIKdiu4chhWZTL55KFwEPSP2CJNzTEBPjODt94EbDF0Pvh+UWqU0u YK0QojBHzXqLv9Qr7UoMsMWI7fAl5Vk4pigJjqShWuvUOrsJGDh8gSvb2U5qrKepG6mt bRxZ9O7KIdj6ddVDFUMg0L3LZgmmfOg5HOy/HwMtdmBJIE9ccFoRZVoBM+ZndgEQImpr YM/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sflvwY1MuuMpFQB1bMAol+c3hn3+9kMzul9bAPKcGx8=; b=nRdiJ2y+WpQC/Mq7MpGUAULecrj3IAxJJmIHU7NbpHaLTec5T84fyIhpvTE92eddgs yGGoQsbeiLqCTLO8QCsAcLt0aRe71Uvb9IWAFxMctHkPiouuyUwIpYccaJm4Vzhj0BSt JLuFfFTJBerhp1br9K+KRPHqGtsY/B03TW3wFVDoCivRQPdUchJOLRlTREElVPZrjePZ c7GmxpzMNB200u6PHOQG/iovlE+K9kh/OCOe5MxhfSxi1Nlk+PPvX/hqJ9cjX0lI+4ar mgO5+nTGgGWcJ4EPXjwy2dzfYtw8Hyt2u2dc6QMo6fPKtsG+PJwLxbgaC1gTKGQ7k4hU 31AQ== X-Gm-Message-State: APjAAAVsxOqD2DF94ljNGcF17KhUmXfftJYugCO8H9hJvwxsOhWNt4kJ agca116P4OIy0VqpWYr42dbayi+JLrD2THfxdQMGlA== X-Google-Smtp-Source: APXvYqzdYSDxHPzDGXu1MS2maG5QyBr4fta4ZAVxg+1Y9OsM2uym0Vo1CtYuMm43DUITnHMVZA1kq+ZMJnnTcLmywq4= X-Received: by 2002:a1f:84d5:: with SMTP id g204mr11108597vkd.44.1562781217028; Wed, 10 Jul 2019 10:53:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dan Lists Date: Wed, 10 Jul 2019 12:53:25 -0500 Message-ID: Subject: Re: Bridge Not Forwarding ARP To: freebsd-net@freebsd.org X-Rspamd-Queue-Id: D2BE56829E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=iR67GM4k; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of listsdan@gmail.com designates 2607:f8b0:4864:20::a29 as permitted sender) smtp.mailfrom=listsdan@gmail.com X-Spamd-Result: default: False [-6.99 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.94)[-0.938,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.04)[ip: (-9.54), ipnet: 2607:f8b0::/32(-3.18), asn: 15169(-2.43), country: US(-0.06)]; RCVD_IN_DNSWL_NONE(0.00)[9.2.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 17:53:40 -0000 I am not running virtualbox. I am still searching for clues to fix this problem. On Mon, Jul 8, 2019 at 7:54 PM Joseph Ward wrote: > I had this exact issue while virtualbox had a guest network adapter > bridged to the external interface that the FreeBDS bridge0 interface was > bridged to. If I shutdown the VMs, ARP magically started working > bidirectionally, and after restarting the VMs it failed again. > > My fix was eventually to just have 2 external NICs; one exclusively for > the virtualbox systems. I have no idea if you have a virtualbox guest > present, but if so that was my fix. > > The issue occurred on both igb and re NICs. > > -Joseph > > On 2019-07-08 12:13, Dan Lists wrote: > > I have a server running FreeBSD 11.2 that I am wanting to use as a > bridged > > firewall. I have it set up and it mostly works. The problem is that > ARP > > replies are not being forwarded from the outside interface to the inside > > interface. It appears to be working in the other direction. I see the > > ARP request go out on the outside interface and the reply arrives back at > > the outside interface. The ARP reply is never getting to the bridge or > to > > the inside interface. > > > > The firewall server and the device behind it are in ESX. I think I've > > worked all the ESX issues out. When I manually add an ARP entry > everything > > works. I've done this before with a physical server running FreeBSD 8.4 > > and it works as expected. The differences are physical vs virtual, and > > 8.4 vs 11.2. > > > > I'm at a loss as to why it is not working. I've searched the web and > > found noting. If anyone could offer suggestions on how to fix this or > > begin to debug it I would greatly appreciate it. > > > > Thanks, > > > > Dan > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Thu Jul 11 07:38:21 2019 Return-Path: Delivered-To: freebsd-net@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 88E0115EEA32 for ; Thu, 11 Jul 2019 07:38: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 23ED16A345 for ; Thu, 11 Jul 2019 07:38:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D8B3F15EEA30; Thu, 11 Jul 2019 07:38:20 +0000 (UTC) Delivered-To: net@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 C5E8515EEA2E for ; Thu, 11 Jul 2019 07:38: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 61B8E6A341 for ; Thu, 11 Jul 2019 07:38: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 8783FEBF1 for ; Thu, 11 Jul 2019 07:38: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 x6B7cJ5L080896 for ; Thu, 11 Jul 2019 07:38:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6B7cJHe080895 for net@FreeBSD.org; Thu, 11 Jul 2019 07:38: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: net@FreeBSD.org Subject: [Bug 239112] [LACP] Latency problem when reconfiguring LACP links Date: Thu, 11 Jul 2019 07:38:19 +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.2-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:38:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239112 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Jul 11 20:14:54 2019 Return-Path: Delivered-To: freebsd-net@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 7B61215DCE6F for ; Thu, 11 Jul 2019 20:14:54 +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 11D408FB85 for ; Thu, 11 Jul 2019 20:14:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C9D4B15DCE6D; Thu, 11 Jul 2019 20:14:53 +0000 (UTC) Delivered-To: net@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 B860B15DCE6C for ; Thu, 11 Jul 2019 20:14:53 +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 577718FB7E for ; Thu, 11 Jul 2019 20:14:53 +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 87D801581C for ; Thu, 11 Jul 2019 20:14:52 +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 x6BKEq5w073099 for ; Thu, 11 Jul 2019 20:14:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6BKEqUL073097 for net@FreeBSD.org; Thu, 11 Jul 2019 20:14:52 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: net@FreeBSD.org Subject: [Bug 238642] netmap: fix kernel pointer printing in netmap_generic.c Date: Thu, 11 Jul 2019 20:14:52 +0000 X-Bugzilla-Reason: CC 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: patch, security X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vmaffione@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 20:14:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238642 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: vmaffione Date: Thu Jul 11 20:13:52 UTC 2019 New revision: 349920 URL: https://svnweb.freebsd.org/changeset/base/349920 Log: MFC r349752 netmap: fix kernel pointer printing in netmap_generic.c Print the adapter name rather than the address of the adapter to avoid kernel address leakage. PR: Bug 238642 Submitted by: Fuqian Huang Reviewed by: vmaffione Changes: _U stable/12/ stable/12/sys/dev/netmap/netmap_generic.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Jul 11 20:30:11 2019 Return-Path: Delivered-To: freebsd-net@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 2C95E15DD2AA for ; Thu, 11 Jul 2019 20:30: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 B5E2368674 for ; Thu, 11 Jul 2019 20:30:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7467815DD2A9; Thu, 11 Jul 2019 20:30:10 +0000 (UTC) Delivered-To: net@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 6191015DD2A7 for ; Thu, 11 Jul 2019 20:30: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 EF1BC6866D for ; Thu, 11 Jul 2019 20:30: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 2D4641598F for ; Thu, 11 Jul 2019 20:30: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 x6BKU97C098682 for ; Thu, 11 Jul 2019 20:30:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6BKU9YZ098679 for net@FreeBSD.org; Thu, 11 Jul 2019 20:30:09 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: net@FreeBSD.org Subject: [Bug 238642] netmap: fix kernel pointer printing in netmap_generic.c Date: Thu, 11 Jul 2019 20:30:09 +0000 X-Bugzilla-Reason: CC 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: patch, security X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vmaffione@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 20:30:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238642 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: vmaffione Date: Thu Jul 11 20:29:51 UTC 2019 New revision: 349922 URL: https://svnweb.freebsd.org/changeset/base/349922 Log: MFC r349752 netmap: fix kernel pointer printing in netmap_generic.c Print the adapter name rather than the address of the adapter to avoid kernel address leakage. PR: Bug 238642 Submitted by: Fuqian Huang Reviewed by: vmaffione Changes: _U stable/11/ stable/11/sys/dev/netmap/netmap_generic.c --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Jul 12 10:14:17 2019 Return-Path: Delivered-To: freebsd-net@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 3358715EBC9D for ; Fri, 12 Jul 2019 10:14:17 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::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.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4344681EF; Fri, 12 Jul 2019 10:14:16 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mxrelay.nyi.freebsd.org (Postfix) with ESMTP id CFC4DCF84; Fri, 12 Jul 2019 10:14:15 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id CEF1B1962B5; Fri, 12 Jul 2019 10:14:15 +0000 (UTC) Date: Fri, 12 Jul 2019 10:14:15 +0000 To: Phabricator From: "aleksandr.fedorov_itglobal.com (Aleksandr Fedorov)" Cc: freebsd-net@freebsd.org Reply-to: "aleksandr.fedorov_itglobal.com (Aleksandr Fedorov)" Subject: [Differential] D19422: if_vxlan(4) Allow set MTU more than 1500 bytes. Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , X-Herald-Rules: <81>, <110> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk Thread-Topic: PHID-DREV-bvtxxu4jwhzdkwqxxgd7 X-Phabricator-Mail-ID: 1536126 X-Phabricator-Send-Attempt: ogdesf5qn4kcvajm In-Reply-To: References: Thread-Index: MzYyMWIxNGMwOTE4YmQzMWVhNTU2NTFhMGQ2IF0oXXc= X-Phabricator-Stamps: actor(@aleksandr.fedorov_itglobal.com) application(Differential) author(@aleksandr.fedorov_itglobal.com) herald(H81) herald(H110) monogram(D19422) object-type(DREV) phid(PHID-DREV-bvtxxu4jwhzdkwqxxgd7) reviewer(#network) reviewer(@bryanv) reviewer(@hrs) reviewer(@jhb) reviewer(@krion) reviewer(@rgrimes) revision-status(needs-review) subscriber(@ae) subscriber(@evgueni.gavrilov_itglobal.com) subscriber(@freebsd-net-list) subscriber(@olevole_olevole.ru) via(web) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_cdb82613d6eb3422df5b497157282e14" X-Rspamd-Queue-Id: C4344681EF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.94)[-0.940,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 10:14:17 -0000 --b1_cdb82613d6eb3422df5b497157282e14 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 YWxla3NhbmRyLmZlZG9yb3ZfaXRnbG9iYWwuY29tIHVwZGF0ZWQgdGhpcyByZXZpc2lvbiB0byBE aWZmIDU5Njg0LgphbGVrc2FuZHIuZmVkb3Jvdl9pdGdsb2JhbC5jb20gZWRpdGVkIHRoZSB0ZXN0 IHBsYW4gZm9yIHRoaXMgcmV2aXNpb24uCmFsZWtzYW5kci5mZWRvcm92X2l0Z2xvYmFsLmNvbSBh ZGRlZCByZXZpZXdlcnM6IGtyaW9uLCBqaGIuCmFsZWtzYW5kci5mZWRvcm92X2l0Z2xvYmFsLmNv bSBhZGRlZCBhIGNvbW1lbnQuClRoaXMgcmV2aXNpb24gbm93IHJlcXVpcmVzIHJldmlldyB0byBw cm9jZWVkLgoKCiAgSSB0aGluayB0aGF0IG10dSBoYW5kbGluZyBpbiBldGhlcl9pb2N0bCAoKSBy ZXF1aXJlcyBtb3JlIHdvcmsgYW5kIG11c3QgYmUgZG9uZSB2ZXJ5IGNhcmVmdWxseSwgYmVjYXVz ZSBpdCBpcyB1c2VkIGJ5IG1hbnkgb3RoZXIgZHJpdmVycy4gU29tZSBkcml2ZXJzIHNldCB0aGUg SUZDQVBfSlVNQk9fTVRVIGZsYWcsIGJ1dCBsaW1pdCB0aGUgbWF4aW11bSBNVFUgc2l6ZSB0byBs ZXNzIHRoYW4gOTAwMCBieXRlcy4gVGhlcmVmb3JlLCBpdCBpcyBub3Qgc28gZWFzeSB0byBoYW5k bGUgdGhlIHZhcmlvdXMgcmVxdWlyZW1lbnRzIGZvciBkcml2ZXJzIGluIGV0aGVyX2lvY3RsICgp LCBhbmQgZmFpbGJhY2sgdG8gdGhlIHN0YW5kYXJkIE1UVSAoMTUwMCkgc2l6ZSBtYXkgYmUgcmVh c29uYWJsZS4KICAKICBSZXZpc2lvbiBjaGFuZ2VzOgogIAogIC0gSW5jcmVhc2UgbWF4aW11bSBh bGxvd2VkIE1UVSB0byA2NUsgLSAxMDAgYnl0ZXMKCkNIQU5HRVMgU0lOQ0UgTEFTVCBVUERBVEUK ICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvRDE5NDIyP3ZzPTU0NTg1JmlkPTU5Njg0CgpD SEFOR0VTIFNJTkNFIExBU1QgQUNUSU9OCiAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVic2Qub3JnL0Qx OTQyMi9uZXcvCgpSRVZJU0lPTiBERVRBSUwKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcv RDE5NDIyCgpBRkZFQ1RFRCBGSUxFUwogIHN5cy9uZXQvaWZfdnhsYW4uYwoKRU1BSUwgUFJFRkVS RU5DRVMKICBodHRwczovL3Jldmlld3MuZnJlZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxw cmVmZXJlbmNlcy8KClRvOiBhbGVrc2FuZHIuZmVkb3Jvdl9pdGdsb2JhbC5jb20sIGJyeWFudiwg aHJzLCAjbmV0d29yaywgcmdyaW1lcywga3Jpb24sIGpoYgpDYzogZXZndWVuaS5nYXZyaWxvdl9p dGdsb2JhbC5jb20sIG9sZXZvbGVfb2xldm9sZS5ydSwgYWUsIGZyZWVic2QtbmV0LWxpc3QsIGty enlzenRvZi5nYWxhemthX2ludGVsLmNvbQo= --b1_cdb82613d6eb3422df5b497157282e14 Content-Type: text/x-patch; charset=utf-8; name="D19422.59684.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D19422.59684.patch" ZGlmZiAtLWdpdCBhL3N5cy9uZXQvaWZfdnhsYW4uYyBiL3N5cy9uZXQvaWZfdnhsYW4uYwotLS0g YS9zeXMvbmV0L2lmX3Z4bGFuLmMKKysrIGIvc3lzL25ldC9pZl92eGxhbi5jCkBAIC04NCw2ICs4 NCwxMSBAQAogCWludAkJCQkgdnhsc29tY191c2VyczsKIH07CiAKKy8qCisgKiBUaGUgbWF4aW11 bSBzdXBwb3J0ZWQgRXRoZXJuZXQgbGVuZ3RoIGFuZCBzb21lIHNwYWNlIGZvciBlbmNhcHN1bGF0 aW9uLgorICovCisjZGVmaW5lIFZYTEFOX01BWF9NVFUJNjU0MzUKKwogI2RlZmluZSBWWExBTl9T T19NQ19NQVhfR1JPVVBTCQkzMgogCiAjZGVmaW5lIFZYTEFOX1NPX1ZOSV9IQVNIX1NISUZUCQk2 CkBAIC0yMjQ3LDEwICsyMjUyLDExIEBACiAJaWZyID0gKHN0cnVjdCBpZnJlcSAqKSBkYXRhOwog CWlmZCA9IChzdHJ1Y3QgaWZkcnYgKikgZGF0YTsKIAorCWVycm9yID0gMDsKKwogCXN3aXRjaCAo Y21kKSB7CiAJY2FzZSBTSU9DQURETVVMVEk6CiAJY2FzZSBTSU9DREVMTVVMVEk6Ci0JCWVycm9y ID0gMDsKIAkJYnJlYWs7CiAKIAljYXNlIFNJT0NHRFJWU1BFQzoKQEAgLTIyNjcsNiArMjI3Mywx MyBAQAogCQllcnJvciA9IGlmbWVkaWFfaW9jdGwoaWZwLCBpZnIsICZzYy0+dnhsX21lZGlhLCBj bWQpOwogCQlicmVhazsKIAorCWNhc2UgU0lPQ1NJRk1UVToKKwkJaWYgKGlmci0+aWZyX210dSA8 IEVUSEVSTUlOIHx8IGlmci0+aWZyX210dSA+IFZYTEFOX01BWF9NVFUpCisJCQllcnJvciA9IEVJ TlZBTDsKKwkJZWxzZQorCQkJaWZwLT5pZl9tdHUgPSBpZnItPmlmcl9tdHU7CisJCWJyZWFrOwor CiAJZGVmYXVsdDoKIAkJZXJyb3IgPSBldGhlcl9pb2N0bChpZnAsIGNtZCwgZGF0YSk7CiAJCWJy ZWFrOwpAQCAtMjc0Nyw4ICsyNzYwLDggQEAKIAlpZnAtPmlmX2lvY3RsID0gdnhsYW5faW9jdGw7 CiAJaWZwLT5pZl90cmFuc21pdCA9IHZ4bGFuX3RyYW5zbWl0OwogCWlmcC0+aWZfcWZsdXNoID0g dnhsYW5fcWZsdXNoOwotCWlmcC0+aWZfY2FwYWJpbGl0aWVzIHw9IElGQ0FQX0xJTktTVEFURTsK LQlpZnAtPmlmX2NhcGVuYWJsZSB8PSBJRkNBUF9MSU5LU1RBVEU7CisJaWZwLT5pZl9jYXBhYmls aXRpZXMgfD0gSUZDQVBfTElOS1NUQVRFIHwgSUZDQVBfSlVNQk9fTVRVOworCWlmcC0+aWZfY2Fw ZW5hYmxlIHw9IElGQ0FQX0xJTktTVEFURSB8IElGQ0FQX0pVTUJPX01UVTsKIAogCWlmbWVkaWFf aW5pdCgmc2MtPnZ4bF9tZWRpYSwgMCwgdnhsYW5fbWVkaWFfY2hhbmdlLCB2eGxhbl9tZWRpYV9z dGF0dXMpOwogCWlmbWVkaWFfYWRkKCZzYy0+dnhsX21lZGlhLCBJRk1fRVRIRVIgfCBJRk1fQVVU TywgMCwgTlVMTCk7Cgo= --b1_cdb82613d6eb3422df5b497157282e14-- From owner-freebsd-net@freebsd.org Fri Jul 12 10:21:39 2019 Return-Path: Delivered-To: freebsd-net@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 9869315EBFB8 for ; Fri, 12 Jul 2019 10:21:39 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::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.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14EC1684BF; Fri, 12 Jul 2019 10:21:39 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mxrelay.nyi.freebsd.org (Postfix) with ESMTP id BA668D004; Fri, 12 Jul 2019 10:21:38 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id B984D1970F1; Fri, 12 Jul 2019 10:21:38 +0000 (UTC) Date: Fri, 12 Jul 2019 10:21:38 +0000 To: Phabricator From: "aleksandr.fedorov_itglobal.com (Aleksandr Fedorov)" Cc: freebsd-net@freebsd.org Reply-to: "aleksandr.fedorov_itglobal.com (Aleksandr Fedorov)" Subject: [Differential] D19422: if_vxlan(4) Allow set MTU more than 1500 bytes. Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: X-Herald-Rules: <81>, <110> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk Thread-Topic: PHID-DREV-bvtxxu4jwhzdkwqxxgd7 X-Phabricator-Mail-ID: 1536169 X-Phabricator-Send-Attempt: yngeqamlav2nckts In-Reply-To: References: Thread-Index: MzYyMWIxNGMwOTE4YmQzMWVhNTU2NTFhMGQ2IF0oXzI= X-Phabricator-Stamps: actor(@aleksandr.fedorov_itglobal.com) application(Differential) author(@aleksandr.fedorov_itglobal.com) herald(H81) herald(H110) monogram(D19422) object-type(DREV) phid(PHID-DREV-bvtxxu4jwhzdkwqxxgd7) reviewer(#network) reviewer(@bryanv) reviewer(@hrs) reviewer(@jhb) reviewer(@krion) reviewer(@rgrimes) revision-status(needs-review) subscriber(@ae) subscriber(@evgueni.gavrilov_itglobal.com) subscriber(@freebsd-net-list) subscriber(@olevole_olevole.ru) via(web) MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-Rspamd-Queue-Id: 14EC1684BF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.93 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.93)[-0.934,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 10:21:39 -0000 YWxla3NhbmRyLmZlZG9yb3ZfaXRnbG9iYWwuY29tIG1hcmtlZCBhbiBpbmxpbmUgY29tbWVudCBh cyBkb25lLgoKQ0hBTkdFUyBTSU5DRSBMQVNUIEFDVElPTgogIGh0dHBzOi8vcmV2aWV3cy5mcmVl YnNkLm9yZy9EMTk0MjIvbmV3LwoKUkVWSVNJT04gREVUQUlMCiAgaHR0cHM6Ly9yZXZpZXdzLmZy ZWVic2Qub3JnL0QxOTQyMgoKRU1BSUwgUFJFRkVSRU5DRVMKICBodHRwczovL3Jldmlld3MuZnJl ZWJzZC5vcmcvc2V0dGluZ3MvcGFuZWwvZW1haWxwcmVmZXJlbmNlcy8KClRvOiBhbGVrc2FuZHIu ZmVkb3Jvdl9pdGdsb2JhbC5jb20sIGJyeWFudiwgaHJzLCAjbmV0d29yaywgcmdyaW1lcywga3Jp b24sIGpoYgpDYzogZXZndWVuaS5nYXZyaWxvdl9pdGdsb2JhbC5jb20sIG9sZXZvbGVfb2xldm9s ZS5ydSwgYWUsIGZyZWVic2QtbmV0LWxpc3QsIGtyenlzenRvZi5nYWxhemthX2ludGVsLmNvbQo= From owner-freebsd-net@freebsd.org Fri Jul 12 13:51:40 2019 Return-Path: Delivered-To: freebsd-net@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 D0F2D15CB229 for ; Fri, 12 Jul 2019 13: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 614AB71434 for ; Fri, 12 Jul 2019 13:51:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2242515CB228; Fri, 12 Jul 2019 13:51:39 +0000 (UTC) Delivered-To: net@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 DBC5215CB225 for ; Fri, 12 Jul 2019 13: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 785027142F for ; Fri, 12 Jul 2019 13:51: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 A73F81EE90 for ; Fri, 12 Jul 2019 13: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 x6CDpb2Z035842 for ; Fri, 12 Jul 2019 13: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 x6CDpb6f035840 for net@FreeBSD.org; Fri, 12 Jul 2019 13: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: net@FreeBSD.org Subject: [Bug 238642] netmap: fix kernel pointer printing in netmap_generic.c Date: Fri, 12 Jul 2019 13:51:37 +0000 X-Bugzilla-Reason: CC 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: patch, security X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: aleksandr.fedorov@itglobal.com X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vmaffione@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 13:51:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238642 Aleksandr Fedorov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aleksandr.fedorov@itglobal. | |com --- Comment #5 from Aleksandr Fedorov --- It seems something goes wrong. With with changes i saw a panic on CURRENT: root@current:~ # ifconfig vlan0 create up=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 root@current:~ # vale-ctl -a vale0:vlan0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 Fatal trap 12: page fault while in kernel mode=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 cpuid =3D 2; apic id =3D 02=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 fault virtual address =3D 0x2a0=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 fault code =3D supervisor read data, page not present=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 instruction pointer =3D 0x20:0xffffffff80cb96cf=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 stack pointer =3D 0x28:0xfffffe008fa48da0 frame pointer =3D 0x28:0xfffffe008fa48da0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 665 (vale-ctl) trap number =3D 12 panic: page fault=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 cpuid =3D 2=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 time =3D 1562949961=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 KDB: stack backtrace:=20=20 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe008fa48= a60 vpanic() at vpanic+0x19d/frame 0xfffffe008fa48ab0 panic() at panic+0x43/frame 0xfffffe008fa48b10 trap_fatal() at trap_fatal+0x39c/frame 0xfffffe008fa48b70 trap_pfault() at trap_pfault+0x62/frame 0xfffffe008fa48bc0 trap() at trap+0x2b4/frame 0xfffffe008fa48cd0 calltrap() at calltrap+0x8/frame 0xfffffe008fa48cd0 --- trap 0xc, rip =3D 0xffffffff80cb96cf, rsp =3D 0xfffffe008fa48da0, rbp = =3D 0xfffffe008fa48da0 --- strlen() at strlen+0x1f/frame 0xfffffe008fa48da0 kvprintf() at kvprintf+0xf79/frame 0xfffffe008fa48ec0 vprintf() at vprintf+0x81/frame 0xfffffe008fa48f90 printf() at printf+0x43/frame 0xfffffe008fa48ff0 generic_netmap_attach() at generic_netmap_attach+0x309/frame 0xfffffe008fa4= 9040 netmap_get_hw_na() at netmap_get_hw_na+0x81/frame 0xfffffe008fa49070 netmap_get_bdg_na() at netmap_get_bdg_na+0x213/frame 0xfffffe008fa49100 netmap_vale_attach() at netmap_vale_attach+0xe0/frame 0xfffffe008fa49140 netmap_ioctl() at netmap_ioctl+0x8a9/frame 0xfffffe008fa49200 netmap_ioctl_legacy() at netmap_ioctl_legacy+0x4fd/frame 0xfffffe008fa495b0 netmap_ioctl() at netmap_ioctl+0x16b/frame 0xfffffe008fa49670 freebsd_netmap_ioctl() at freebsd_netmap_ioctl+0x88/frame 0xfffffe008fa496b0 devfs_ioctl() at devfs_ioctl+0xca/frame 0xfffffe008fa49700 VOP_IOCTL_APV() at VOP_IOCTL_APV+0x63/frame 0xfffffe008fa49720 vn_ioctl() at vn_ioctl+0x13d/frame 0xfffffe008fa49830 devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfffffe008fa49850 kern_ioctl() at kern_ioctl+0x28a/frame 0xfffffe008fa498c0 sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe008fa49990 amd64_syscall() at amd64_syscall+0x276/frame 0xfffffe008fa49ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe008fa49ab0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x80041631a, rsp =3D 0x7fffffffeab8, rbp =3D 0x7fffffffeb50 --- KDB: enter: panic [ thread pid 665 tid 100131 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why db>=20 This happens due the fact that gna->prev equal zero. For example old output without this patch: root@current:~ # vale-ctl -a vale0:vlan0 792.670615 [1130] generic_netmap_attach Emulated adapter for vlan0 crea= ted (prev was 0) =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 ^^^^^^^!!!!! I don't know why, but this if evaluated as false: 1121 if (NM_NA_VALID(ifp)) { 1122 gna->prev =3D NA(ifp); /* save old na */ 1123 netmap_adapter_get(gna->prev); 1124 } And then: 1129 nm_prinf("Emulated adapter for %s created (prev was %s)", na->name, gna->prev->name); =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 ^^^^!!!! Null pointer dereference. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Jul 12 17:33:29 2019 Return-Path: Delivered-To: freebsd-net@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 F168B15D10C4 for ; Fri, 12 Jul 2019 17:33:28 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::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.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CE21833A5; Fri, 12 Jul 2019 17:33:28 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mxrelay.nyi.freebsd.org (Postfix) with ESMTP id 200EB19BC8; Fri, 12 Jul 2019 17:33:28 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 1F0A7AD86B; Fri, 12 Jul 2019 17:33:28 +0000 (UTC) Date: Fri, 12 Jul 2019 17:33:28 +0000 To: Phabricator From: "jhb (John Baldwin)" Cc: freebsd-net@freebsd.org Reply-to: "jhb (John Baldwin)" Subject: [Differential] D19422: if_vxlan(4) Allow set MTU more than 1500 bytes. Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: X-Herald-Rules: <81>, <110> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: Precedence: bulk Thread-Topic: PHID-DREV-bvtxxu4jwhzdkwqxxgd7 X-Phabricator-Mail-ID: 1536901 X-Phabricator-Send-Attempt: af4jlcgac6pnh2wp In-Reply-To: References: Thread-Index: MzYyMWIxNGMwOTE4YmQzMWVhNTU2NTFhMGQ2IF0oxGg= X-Phabricator-Stamps: actor(@jhb) application(Differential) author(@aleksandr.fedorov_itglobal.com) herald(H81) herald(H110) monogram(D19422) object-type(DREV) phid(PHID-DREV-bvtxxu4jwhzdkwqxxgd7) reviewer(#network) reviewer(@bryanv) reviewer(@hrs) reviewer(@jhb) reviewer(@krion) reviewer(@rgrimes) revision-status(needs-review) subscriber(@ae) subscriber(@evgueni.gavrilov_itglobal.com) subscriber(@freebsd-net-list) subscriber(@olevole_olevole.ru) via(web) MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" X-Rspamd-Queue-Id: 8CE21833A5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.94)[-0.940,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 17:33:29 -0000 amhiIGFkZGVkIGEgY29tbWVudC4KCgogIEkgYWdyZWUgdGhhdCB3ZSBjYW4ndCBoYW5kbGUgdGhp cyBpbiBldGhlcl9pb2N0bCBhcyBpdCB2YXJpZXMgdG9vIG11Y2ggYnkgcmVhbCBoYXJkd2FyZS4K CklOTElORSBDT01NRU5UUwoKPiBpZl92eGxhbi5jOjkwCj4gKyAqLwo+ICsjZGVmaW5lIFZYTEFO X01BWF9NVFUJNjU0MzUKPiArCgpJZiBpdCB3YXMgcG9zc2libGUgdG8gbWFrZSB0aGlzIGRlcml2 ZWQgZnJvbSBvdGhlciBjb25zdGFudHMgdGhhdCB3b3VsZCBiZSBpZGVhbC4gIDxuZXQvZXRoZXJu ZXQuaD4gaGFzIEVUSEVSX01BWF9MRU5fSlVNQk8gb2Ygb25seSA5MDE4LCBidXQgaXQgc2VlbXMg c29tZSBvdGhlciBkcml2ZXJzIGhhdmUgaGlnaGVyIG1heGltdW1zICg5NjAwIGZvciBjeGdiZSBh bmQgOTcyOCBmb3IgaXhsKDQpKS4gIFNvIHNhZGx5IHRoZXJlIGlzIG5vIGdvb2QgY29uc3RhbnQg Zm9yIHRoZSA2NGsgbWF4LiAgIElzIHRoZXJlIGFuIGV4cHJlc3Npb24gdGhhdCB3b3VsZCBnaXZl IHlvdSB0aGUgbWF4IG92ZXJoZWFkPyAgSWYgc28geW91IGNvdWxkIHVzZSBzb21ldGhpbmcgbGlr ZToKCiAgJyg2NTUzNSAtIHNpemVvZihzdHJ1Y3QgdnhsYW5faGVhZGVyKSAtIEVUSEVSX0hEUl9M RU4gLSBFVEhFUl9DUkNfTEVOIC0gRVRIRVJfVkxBTl9WQ0FQX0xFTikKCmlmX2l4bC5jIGhhcyBz b21ldGhpbmcgbGlrZSB0aGF0IGZvciBzZXR0aW5nIHRoZSBNVFUuICBXaGF0IEkgZG9uJ3Qga25v dyBpcyB3aGF0IHRoZSBwb3NzaWJsZSBlbmNhcHN1bGF0aW9uIG92ZXJoZWFkIGlzIGZvciB0aGlz IGludGVyZmFjZS4KCkNIQU5HRVMgU0lOQ0UgTEFTVCBBQ1RJT04KICBodHRwczovL3Jldmlld3Mu ZnJlZWJzZC5vcmcvRDE5NDIyL25ldy8KClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3 cy5mcmVlYnNkLm9yZy9EMTk0MjIKCkVNQUlMIFBSRUZFUkVOQ0VTCiAgaHR0cHM6Ly9yZXZpZXdz LmZyZWVic2Qub3JnL3NldHRpbmdzL3BhbmVsL2VtYWlscHJlZmVyZW5jZXMvCgpUbzogYWxla3Nh bmRyLmZlZG9yb3ZfaXRnbG9iYWwuY29tLCBicnlhbnYsIGhycywgI25ldHdvcmssIHJncmltZXMs IGtyaW9uLCBqaGIKQ2M6IGV2Z3VlbmkuZ2F2cmlsb3ZfaXRnbG9iYWwuY29tLCBvbGV2b2xlX29s ZXZvbGUucnUsIGFlLCBmcmVlYnNkLW5ldC1saXN0LCBrcnp5c3p0b2YuZ2FsYXprYV9pbnRlbC5j b20K From owner-freebsd-net@freebsd.org Sat Jul 13 04:49:07 2019 Return-Path: Delivered-To: freebsd-net@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 B7C7015DF967 for ; Sat, 13 Jul 2019 04:49:07 +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 4C37E6D34E for ; Sat, 13 Jul 2019 04:49:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0A30715DF966; Sat, 13 Jul 2019 04:49:07 +0000 (UTC) Delivered-To: net@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 E8E1415DF965 for ; Sat, 13 Jul 2019 04:49:06 +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 712066D34D for ; Sat, 13 Jul 2019 04:49:06 +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 869D96F50 for ; Sat, 13 Jul 2019 04:49:05 +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 x6D4n59u009861 for ; Sat, 13 Jul 2019 04:49:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6D4n5Tm009860 for net@FreeBSD.org; Sat, 13 Jul 2019 04:49:05 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Sat, 13 Jul 2019 04:49:05 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 04:49:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #16 from Cy Schubert --- This was broken by ipfilter commit c8beabe in 2009. fr_cksum was moved from= the end of frentry_t to before fr_func. It's a wonder any rule compares work. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Jul 13 05:11:51 2019 Return-Path: Delivered-To: freebsd-net@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 6A9A115E0263 for ; Sat, 13 Jul 2019 05:11:51 +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 051306E00F for ; Sat, 13 Jul 2019 05:11:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B848C15E0261; Sat, 13 Jul 2019 05:11:50 +0000 (UTC) Delivered-To: net@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 A5CA815E0260 for ; Sat, 13 Jul 2019 05:11:50 +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 3F8226E00D for ; Sat, 13 Jul 2019 05:11:50 +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 4DD8C7356 for ; Sat, 13 Jul 2019 05:11:49 +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 x6D5BnQQ061356 for ; Sat, 13 Jul 2019 05:11:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6D5Bn61061354 for net@FreeBSD.org; Sat, 13 Jul 2019 05:11:49 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Sat, 13 Jul 2019 05:11:48 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 05:11:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #17 from Cy Schubert --- To be more precise (since I converted Darren's CVS tree to GIT), the CVS rev number reported by cvs blame for ip_fil.h. 1.31 (darren_r 01-Mar-09) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Jul 13 05:45:47 2019 Return-Path: Delivered-To: freebsd-net@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 329E015E0864 for ; Sat, 13 Jul 2019 05:45: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 BC3466EDE0 for ; Sat, 13 Jul 2019 05:45:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 7B62515E0863; Sat, 13 Jul 2019 05:45:46 +0000 (UTC) Delivered-To: net@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 66E8515E0862 for ; Sat, 13 Jul 2019 05:45: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 E09A76EDDC for ; Sat, 13 Jul 2019 05:45: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 1E27B7796 for ; Sat, 13 Jul 2019 05:45: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 x6D5jiJJ033167 for ; Sat, 13 Jul 2019 05:45:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6D5jiSR033166 for net@FreeBSD.org; Sat, 13 Jul 2019 05:45: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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Sat, 13 Jul 2019 05:45:44 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 05:45:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 Cy Schubert changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #205322|0 |1 is obsolete| | Attachment #205341|0 |1 is obsolete| | --- Comment #18 from Cy Schubert --- Created attachment 205744 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D205744&action= =3Dedit Revert part of ip_fil.h cvs rev r1.31 This patch reverts part of ip_fil.h r1.31 (March 1, 2009) about 4 years bef= ore 5.1.2 was imported into FreeBSD. This resolves the issue on my main firewal= l. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Jul 13 06:26:52 2019 Return-Path: Delivered-To: freebsd-net@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 05A8315E12E7 for ; Sat, 13 Jul 2019 06:26: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 94DFD704BA for ; Sat, 13 Jul 2019 06:26:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 55A1415E12E6; Sat, 13 Jul 2019 06:26:51 +0000 (UTC) Delivered-To: net@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 4272515E12E4 for ; Sat, 13 Jul 2019 06:26:51 +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 C7746704B6 for ; Sat, 13 Jul 2019 06:26:50 +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 EE2AF7D04 for ; Sat, 13 Jul 2019 06:26:49 +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 x6D6QnLd096548 for ; Sat, 13 Jul 2019 06:26:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6D6Qncx096537 for net@FreeBSD.org; Sat, 13 Jul 2019 06:26:49 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: net@FreeBSD.org Subject: [Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison Date: Sat, 13 Jul 2019 06:26:49 +0000 X-Bugzilla-Reason: CC 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: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cy@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: cy@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 06:26:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #19 from Cy Schubert --- I will produce an improved patch. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Jul 13 07:26:29 2019 Return-Path: Delivered-To: freebsd-net@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 40E6D15E230B for ; Sat, 13 Jul 2019 07:26: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 CB3F2720E4 for ; Sat, 13 Jul 2019 07:26:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 821AB15E2307; Sat, 13 Jul 2019 07:26:28 +0000 (UTC) Delivered-To: net@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 7090115E2305 for ; Sat, 13 Jul 2019 07:26: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.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 9915A720E2 for ; Sat, 13 Jul 2019 07:26: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 9A1C8852E for ; Sat, 13 Jul 2019 07:26: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 x6D7QQOr013653 for ; Sat, 13 Jul 2019 07:26:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6D7QQsP013652 for net@FreeBSD.org; Sat, 13 Jul 2019 07:26: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: net@FreeBSD.org Subject: [Bug 238642] netmap: fix kernel pointer printing in netmap_generic.c Date: Sat, 13 Jul 2019 07:26:26 +0000 X-Bugzilla-Reason: CC 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: patch, security X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: vmaffione@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: vmaffione@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 07:26:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238642 --- Comment #6 from Vincenzo Maffione --- Yes, indeed. For some reason when I did not catch this when running the tes= ts. I'll fix it now. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Jul 13 13:50:39 2019 Return-Path: Delivered-To: freebsd-net@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 8642415E9A6E for ; Sat, 13 Jul 2019 13:50: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 215EC87050 for ; Sat, 13 Jul 2019 13:50:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id D45DF15E9A5D; Sat, 13 Jul 2019 13:50:38 +0000 (UTC) Delivered-To: net@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 C30BA15E9A58 for ; Sat, 13 Jul 2019 13:50: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 6273F8704D for ; Sat, 13 Jul 2019 13:50: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 7B538B84C for ; Sat, 13 Jul 2019 13:50: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 x6DDobBq030085 for ; Sat, 13 Jul 2019 13:50:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6DDob5Z030083 for net@FreeBSD.org; Sat, 13 Jul 2019 13:50: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: net@FreeBSD.org Subject: [Bug 237441] Virtio net consistently truncates last byte of a fetch xfer with > 8956 bytes of payload Date: Sat, 13 Jul 2019 13:50:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: freebsd-bugs@cklie.de X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 13:50:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237441 --- Comment #6 from Christoph Kliemann --- I think this is not a FreeBSD issue. Can't reproduce immediately after a host reboot. The issue occurs after the first sleep/wake cycle of the host and persists until reboot. This seems to be a macOS and/or qemu issue. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Jul 13 15:05:59 2019 Return-Path: Delivered-To: freebsd-net@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 832B815EAE6C for ; Sat, 13 Jul 2019 15:05:59 +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 1757089735 for ; Sat, 13 Jul 2019 15:05:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C8CE415EAE6B; Sat, 13 Jul 2019 15:05:58 +0000 (UTC) Delivered-To: net@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 B62C715EAE6A for ; Sat, 13 Jul 2019 15:05:58 +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 47A4889730 for ; Sat, 13 Jul 2019 15:05:58 +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 8475FC4E9 for ; Sat, 13 Jul 2019 15:05:57 +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 x6DF5vUo054452 for ; Sat, 13 Jul 2019 15:05:57 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6DF5vk8054443 for net@FreeBSD.org; Sat, 13 Jul 2019 15:05:57 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: net@FreeBSD.org Subject: [Bug 237441] Virtio net consistently truncates last byte of a fetch xfer with > 8956 bytes of payload Date: Sat, 13 Jul 2019 15:05:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: freebsd-bugs@cklie.de X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 15:05:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237441 --- Comment #7 from Christoph Kliemann --- (In reply to Christoph Kliemann from comment #6) Please disregard. Managed to reproduce after a reboot. Sorry for the noise. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sat Jul 13 19:53:43 2019 Return-Path: Delivered-To: freebsd-net@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 4D73615EFB8A for ; Sat, 13 Jul 2019 19:53:43 +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 DB8F56BC8C for ; Sat, 13 Jul 2019 19:53:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 955A215EFB89; Sat, 13 Jul 2019 19:53:42 +0000 (UTC) Delivered-To: net@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 8400115EFB88 for ; Sat, 13 Jul 2019 19:53:42 +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 224A76BC89 for ; Sat, 13 Jul 2019 19:53: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 64205EB95 for ; Sat, 13 Jul 2019 19:53:41 +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 x6DJrfRS033129 for ; Sat, 13 Jul 2019 19:53:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6DJrf1u033128 for net@FreeBSD.org; Sat, 13 Jul 2019 19:53:41 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: net@FreeBSD.org Subject: [Bug 219428] em network driver broken in current Date: Sat, 13 Jul 2019 19:53:35 +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: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: arkadiusz.majewski@iptrace.pl X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@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-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 19:53:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219428 --- Comment #23 from IPTRACE --- Is there any workaround instead of restart a system? I was trying below without progress as well. # ifconfig igb0 down # ifconfig igb0 up I think the problem is when the network card loses ethernet link and then errors occurs with non-working interface. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Jul 13 20:28:44 2019 Return-Path: Delivered-To: freebsd-net@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 E132D15CA246 for ; Sat, 13 Jul 2019 20:28:43 +0000 (UTC) (envelope-from kob6558@gmail.com) 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 2BD7A6CA44 for ; Sat, 13 Jul 2019 20:28:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DCAFD15CA245; Sat, 13 Jul 2019 20:28:42 +0000 (UTC) Delivered-To: net@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 B518415CA244 for ; Sat, 13 Jul 2019 20:28:42 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43CD26CA41; Sat, 13 Jul 2019 20:28:42 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ot1-x331.google.com with SMTP id r6so12904909oti.3; Sat, 13 Jul 2019 13:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UdhRU7PJNd4yIVL5eWhCIwomrTc4xmIX7PbzLBlkR7M=; b=rBbJcjzdNYGoCwO3cz3qtYj90ZZJrmEG+TRkJ3UPdxX+QxRan3TOYzDV9NYWjFcJo+ mX0PRI1kk9qEauly/vHTdOUk8O8pLreJDfdLbtdHJktjJw1vrsbgrJSaqJqNG8UBSYoG o9oGhWBT/3YmBh7GpOt8GOTFR/pGZn2pl0Y9dmmVHFOGfPKvVUBQZNcEcPNdxOVtjo/8 3JrlJOoumjCZrvTTnLU0PfOiX1FiUjy/NngZ9AL+QY8VaHFSVjjxx+zST8tCE07dee8a ILMCZqZpYmEK8WAyaqrK+Irdu7eoCsyiyUem4mlhC4i7STdsCZPZQGIsS/lW4WLcAqvL /Z6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UdhRU7PJNd4yIVL5eWhCIwomrTc4xmIX7PbzLBlkR7M=; b=odu2C0mgwxnX7T/MBkUvJloTDSl1GwCWg7DtHLRDq9MUezaNwC2ELSSlUVJZ+Rez/C cX36CouwbR/BoIc97DfMUD0hqg0Y0Vrbt3nYfPFTxVKsChelw57xgZEcPHptX1rGAAiw ZZld0VNNiE2oCk00foDGgrWnRVBY41A0tVVcUSox7eJpb/EfqW3RRg3PSi1AcysrtUAE 5iu3cefl0WU8ukU8KwAIAxg7KpsY+8LRw5C5ScHkb5ylWct4JD6h7PhIiyuiXk2YHD1r xA9sIe5/MxhLjWVj+I+tf79UqueR2e7eV4rrRw1IRp8WbTUafxqe+ml4DkSGHwiZWAQI eQHQ== X-Gm-Message-State: APjAAAUQnt2c+vPBQ7j/OSLPYpthK440WeUJaGv7q144bVLHpQJpzWTH MMxgDED7b9HiIFD6/alsoXWCHXYwB+CdXYZHgz1betacLTM= X-Google-Smtp-Source: APXvYqwhZjL7j1wDQLnfzmOA1P4DUFkpSKGjnJOf+Gqzt2RhvucQUqO1f7NrRpVyb5YGffOUe7bdzomm6TjVdEysB28= X-Received: by 2002:a9d:4809:: with SMTP id c9mr13702117otf.199.1563049720973; Sat, 13 Jul 2019 13:28:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kevin Oberman Date: Sat, 13 Jul 2019 13:28:24 -0700 Message-ID: Subject: Re: [Bug 219428] em network driver broken in current To: bugzilla-noreply@freebsd.org Cc: FreeBSD Net X-Rspamd-Queue-Id: 43CD26CA41 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.84 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.84)[-0.838,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 20:28:44 -0000 On Sat, Jul 13, 2019 at 12:54 PM wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219428 > > --- Comment #23 from IPTRACE --- > Is there any workaround instead of restart a system? > I was trying below without progress as well. > > # ifconfig igb0 down > # ifconfig igb0 up > > I think the problem is when the network card loses ethernet link and then > errors occurs with non-working interface. > No idea whether it will do the trick, but you might try "service netif restart ibg0". It does a lot more than just down-up of the interface. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683