From owner-freebsd-net@FreeBSD.ORG Sun Oct 19 21:00:26 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CD63864 for ; Sun, 19 Oct 2014 21:00:26 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 42B3781B for ; Sun, 19 Oct 2014 21:00:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9JL0Q0g010615 for ; Sun, 19 Oct 2014 21:00:26 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201410192100.s9JL0Q0g010615@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 19 Oct 2014 21:00:26 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 19 Oct 2014 21:00:26 -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 ----------------+-----------+------------------------------------------------- Needs MFC | 183659 | [tcp] TCP stack lock contention with short-live 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:38:51 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B88E7772 for ; Mon, 20 Oct 2014 01:38:51 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 9FC6C2E5 for ; Mon, 20 Oct 2014 01:38:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1cpDI080915 for ; Mon, 20 Oct 2014 01:38:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second Date: Mon, 20 Oct 2014 01:38:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 20 Oct 2014 01:38:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:46:26 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A7869EA for ; Mon, 20 Oct 2014 01:46:26 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 718D23B3 for ; Mon, 20 Oct 2014 01:46:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1kQn4089198 for ; Mon, 20 Oct 2014 01:46:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194238] [tcp] Ping attempted with MTU 9000 transmits fragmented packets of size 1500 Date: Mon, 20 Oct 2014 01:46:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 20 Oct 2014 01:46:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194238 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Summary|Ping attempted with MTU |[tcp] Ping attempted with |9000 transmits fragmented |MTU 9000 transmits |packets of size 1500 |fragmented packets of size | |1500 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:46:52 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F589AC6 for ; Mon, 20 Oct 2014 01:46:52 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 5A9513C9 for ; Mon, 20 Oct 2014 01:46:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1kq0w089331 for ; Mon, 20 Oct 2014 01:46:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27 Date: Mon, 20 Oct 2014 01:46:52 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 20 Oct 2014 01:46:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #3 from Mark Linimon --- Over to maintainers. -- 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 Mon Oct 20 01:47:39 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EA22BB6 for ; Mon, 20 Oct 2014 01:47:39 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 151FE3E6 for ; Mon, 20 Oct 2014 01:47:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1lcXT089546 for ; Mon, 20 Oct 2014 01:47:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194197] [igb] [patch] IGB cards need a kernel option to enable legacy mode (to support ALTQ) Date: Mon, 20 Oct 2014 01:47:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-BETA3 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 20 Oct 2014 01:47:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194197 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Summary|IGB cards need a kernel |[igb] [patch] IGB cards |option to enable legacy |need a kernel option to |mode (to support ALTQ) |enable legacy mode (to | |support ALTQ) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:47:55 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F25A7C88 for ; Mon, 20 Oct 2014 01:47:55 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id D9BF83F2 for ; Mon, 20 Oct 2014 01:47:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1ltou089628 for ; Mon, 20 Oct 2014 01:47:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193986] [lor][network] multicast related Date: Mon, 20 Oct 2014 01:47:56 +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.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 20 Oct 2014 01:47:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193986 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:48:17 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D55D7D62 for ; Mon, 20 Oct 2014 01:48:17 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id BC190403 for ; Mon, 20 Oct 2014 01:48:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1mHQX089732 for ; Mon, 20 Oct 2014 01:48:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193724] [panic] [tcp] in tcp_discardcb (/usr/src/sys/netinet/tcp_subr.c:929) Date: Mon, 20 Oct 2014 01:48:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 20 Oct 2014 01:48:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193724 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Summary|[panic] in tcp_discardcb |[panic] [tcp] in |(/usr/src/sys/netinet/tcp_s |tcp_discardcb |ubr.c:929) |(/usr/src/sys/netinet/tcp_s | |ubr.c:929) -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:48:33 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F051AE36 for ; Mon, 20 Oct 2014 01:48:33 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id D708B5EB for ; Mon, 20 Oct 2014 01:48:33 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1mX2K089819 for ; Mon, 20 Oct 2014 01:48:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193673] [ixgbe] flowid / rss field should only be set if the packettype field says it has a flowid Date: Mon, 20 Oct 2014 01:48:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 20 Oct 2014 01:48:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193673 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:49:09 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A44B8F17 for ; Mon, 20 Oct 2014 01:49:09 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 89B14600 for ; Mon, 20 Oct 2014 01:49:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1n9pt090092 for ; Mon, 20 Oct 2014 01:49:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193579] [axge] axge driver issue with tcp checksum offload with pf nat Date: Mon, 20 Oct 2014 01:49:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 20 Oct 2014 01:49:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193579 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:49:25 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AE1DFEE for ; Mon, 20 Oct 2014 01:49:25 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 8225260E for ; Mon, 20 Oct 2014 01:49:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1nPgO090193 for ; Mon, 20 Oct 2014 01:49:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193488] [re] RTL8168F ignores incoming multicast packets Date: Mon, 20 Oct 2014 01:49:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 20 Oct 2014 01:49:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193488 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #1 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 01:50:04 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DCA8155 for ; Mon, 20 Oct 2014 01:50:04 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 64DBB625 for ; Mon, 20 Oct 2014 01:50:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K1o4l2090486 for ; Mon, 20 Oct 2014 01:50:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194344] [regression] Wake on LAN no longer works on em(4) Date: Mon, 20 Oct 2014 01:50:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 20 Oct 2014 01:50:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194344 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #2 from Mark Linimon --- Over to maintainers. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 04:19:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 836A24EF for ; Mon, 20 Oct 2014 04:19:21 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63BA4388 for ; Mon, 20 Oct 2014 04:19:20 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9K4Ir0l088123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Oct 2014 13:19:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9K4IpuJ063541; Mon, 20 Oct 2014 13:18:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 20 Oct 2014 13:18:39 +0900 (JST) Message-Id: <20141020.131839.1886955791866316016.hrs@allbsd.org> To: prabhakar.lakhera@gmail.com Subject: Re: IPv6 stacks responds to all node link local multicast NS From: Hiroki Sato In-Reply-To: References: <20141018.143919.1930138986692891609.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Mon_Oct_20_13_18_39_2014_811)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Mon, 20 Oct 2014 13:19:14 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 04:19:21 -0000 ----Security_Multipart0(Mon_Oct_20_13_18_39_2014_811)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Oct_20_13_18_39_2014_886)--" Content-Transfer-Encoding: 7bit ----Next_Part(Mon_Oct_20_13_18_39_2014_886)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit prabhakar lakhera wrote in : pr> Like I said before, it is not per RFC. It is trivial to derive solicited pr> node multicast address from the target IP, so If someone were to launch a pr> flood attack to poison cache entry for X host by sending Address resolution pr> request for all other local hosts in the network, with NS's source IP=X's pr> IP and with source link layer info=attacker's MAC, computing sol node pr> multicast for each target will make it only slightly costly, so I am not pr> sure if security could be of concern here. pr> pr> The other concern is if it can be a compliance issue given the NS packet pr> format described by the RFC. pr> pr> Also the comment in the code suggests what RFC says but the check is more pr> liberal. Also why it is different for DAD NS vs Neighbor resolution NS. In my understanding, RFC does not allow sending NS messages to all-node multicast address but says nothing about accepting side. An NS message to all-node multicast address is broken, but at least FreeBSD never sends an NS message to all-node multicast address. There is no problem with RFC conformance in this regard. The check itself is easy and I think the attached patch is enough. I am still wondering what kind of trouble we have if we do not do this check. I do not think the security concern is severe because NS flooding from neighbors is still easy even if narrowing down the destination address check upon its acceptance. One possible countermeasure would be rate-limiting of NS/NA. -- Hiroki ----Next_Part(Mon_Oct_20_13_18_39_2014_886)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nd6_nbr_smaddrcheck_20141020-1.diff" Index: sys/netinet6/nd6_nbr.c =================================================================== --- sys/netinet6/nd6_nbr.c (revision 273157) +++ sys/netinet6/nd6_nbr.c (working copy) @@ -116,6 +116,7 @@ int lladdrlen = 0; int anycast = 0, proxy = 0, tentative = 0; int tlladdr; + int dsmaddr; int rflag; union nd_opts ndopts; struct sockaddr_dl proxydl; @@ -147,15 +148,33 @@ goto bad; } - if (IN6_IS_ADDR_UNSPECIFIED(&saddr6)) { - /* dst has to be a solicited node multicast address. */ - if (daddr6.s6_addr16[0] == IPV6_ADDR_INT16_MLL && + /* + * Attaching target link-layer address to the NA? + * (RFC 2461 7.2.4) + * + * NS IP dst is unicast/anycast MUST NOT add + * NS IP dst is solicited-node multicast MUST add + * + * In implementation, we add target link-layer address by default. + * We do not add one in MUST NOT cases. + */ + if (!IN6_IS_ADDR_MULTICAST(&daddr6)) + tlladdr = dsmaddr = 0; + else if (daddr6.s6_addr16[0] == IPV6_ADDR_INT16_MLL && /* don't check ifindex portion */ daddr6.s6_addr32[1] == 0 && daddr6.s6_addr32[2] == IPV6_ADDR_INT32_ONE && - daddr6.s6_addr8[12] == 0xff) { - ; /* good */ - } else { + daddr6.s6_addr8[12] == 0xff) + tlladdr = dsmaddr = 1; + else { + nd6log((LOG_INFO, "nd6_ns_input: multicast NS not to " + "solicited-node multicast address.\n")); + goto bad; + } + + if (IN6_IS_ADDR_UNSPECIFIED(&saddr6)) { + /* dst has to be a solicited node multicast address. */ + if (dsmaddr == 0) { nd6log((LOG_INFO, "nd6_ns_input: bad DAD packet " "(wrong ip6 dst)\n")); goto bad; @@ -206,21 +225,6 @@ } /* - * Attaching target link-layer address to the NA? - * (RFC 2461 7.2.4) - * - * NS IP dst is unicast/anycast MUST NOT add - * NS IP dst is solicited-node multicast MUST add - * - * In implementation, we add target link-layer address by default. - * We do not add one in MUST NOT cases. - */ - if (!IN6_IS_ADDR_MULTICAST(&daddr6)) - tlladdr = 0; - else - tlladdr = 1; - - /* * Target address (taddr6) must be either: * (1) Valid unicast/anycast address for my receiving interface, * (2) Unicast address for which I'm offering proxy service, or ----Next_Part(Mon_Oct_20_13_18_39_2014_886)---- ----Security_Multipart0(Mon_Oct_20_13_18_39_2014_811)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlREjR8ACgkQTyzT2CeTzy0ntgCfSOXEMF0lgBP6J9S73ozSELy+ XA0AoKiyoBDnZSC260gCNmFvRFHAO9+u =Ib4O -----END PGP SIGNATURE----- ----Security_Multipart0(Mon_Oct_20_13_18_39_2014_811)---- From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 06:19:51 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69CD294B for ; Mon, 20 Oct 2014 06:19:51 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 511B1F02 for ; Mon, 20 Oct 2014 06:19:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K6JpZo047555 for ; Mon, 20 Oct 2014 06:19:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193488] [re] RTL8168F ignores incoming multicast packets Date: Mon, 20 Oct 2014 06:19:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yongari@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: yongari@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 20 Oct 2014 06:19:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193488 Pyun YongHyeon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion CC| |yongari@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |yongari@FreeBSD.org --- Comment #2 from Pyun YongHyeon --- Could you show me the output dmesg(re(4) only)? I guess the specific controller has a silicon bug such that driver needs a workaround to accept multicast packets. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 08:00:11 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 425D945E for ; Mon, 20 Oct 2014 08:00:11 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 16D5FB0F for ; Mon, 20 Oct 2014 08:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9K80A24038776 for ; Mon, 20 Oct 2014 08:00:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201410200800.s9K80A24038776@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [FreeBSD Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 20 Oct 2014 08:00:10 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 08:00:11 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (1 bugs) Bug 183659: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-net@FreeBSD.org Status: Needs MFC Resolution: Summary: [tcp] TCP stack lock contention with short-lived connections From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 12:44:27 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 005ED522 for ; Mon, 20 Oct 2014 12:44:26 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id DBD98EEF for ; Mon, 20 Oct 2014 12:44:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9KCiQSd055215 for ; Mon, 20 Oct 2014 12:44:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194238] [tcp] Ping attempted with MTU 9000 transmits fragmented packets of size 1500 Date: Mon, 20 Oct 2014 12:44:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: melifaro@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 20 Oct 2014 12:44:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194238 Alexander V. Chernikov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |melifaro@FreeBSD.org --- Comment #1 from Alexander V. Chernikov --- can you show 'route -n get
' on both machines? This is the typical problem which can happen when you first configure addreses (so on-interface routes with default MTU gets installed) and then you configure MTU. In that case interface MTU will be 9k, but interface routes MTU will be still 1500. You can either manuall fix this by issuing route modify -mtu 9000 or to configure MTU at startup along with interface addresses. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 15:41:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57CC23A7 for ; Mon, 20 Oct 2014 15:41:00 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 24EBAD25 for ; Mon, 20 Oct 2014 15:41:00 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id va2so4056823obc.16 for ; Mon, 20 Oct 2014 08:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=YlfRhxjR1t8dgYX+s8EV0vRb05pj+7qmvNzLm+4pK0I=; b=qwGlqkq4lXgp6Je5QpbbaUPCIFMBCuo1t7Sc5E31pp6QBiqXE16OWr9MEiNo/5Pydx p4MOqveOAKKuL3CdhCO6LExiaumSpuyKQL+Gu/5TX5Nh4pFLQHYSbJ3Ev1twPaga3cDm 8eA1Hm+sW99MUQydLBwQvrUuMtsyk+vfzoi0MtQ8ypVFf6mRGSDYnEDpP3G6Sx2RkKuL x4xd8+1ejIv1FhsIyJAmlU9gORvjbBMMgHkBs6l1hbs4eCrRkWjjoUwU1xw31v7Mb/iz JU3SoOiDyEE0gDmjkHhqpO9NBiBThiY/6/JbUdZlG9r4MmY7dewKwnrJI/xRcCWkSdFo lKPQ== MIME-Version: 1.0 X-Received: by 10.202.186.136 with SMTP id k130mr1593120oif.94.1413819659459; Mon, 20 Oct 2014 08:40:59 -0700 (PDT) Sender: jim.harris@gmail.com Received: by 10.202.178.8 with HTTP; Mon, 20 Oct 2014 08:40:59 -0700 (PDT) Date: Mon, 20 Oct 2014 08:40:59 -0700 X-Google-Sender-Auth: qxha1WKrkuB4qokBeIg7Hl2L7o4 Message-ID: Subject: Intel DPDK added to FreeBSD ports collection From: Jim Harris To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 15:41:00 -0000 Just wanted to send a heads-up that Intel's Data Plane Development Kit (DPDK) for high speed packet processing was added to the FreeBSD ports collection last week under net/dpdk. Intel added support for FreeBSD earlier this year, but until now required downloading from Intel's website or dpdk.org. Thanks to Bruce Richardson from the Intel DPDK team and vanilla@ and gnn@ for getting it checked into ports. For any questions, please check out dpdk.org and the developer mailing list (dev@dpdk.org). Regards, -Jim From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 15:45:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8121626; Mon, 20 Oct 2014 15:45:40 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E0EAE36; Mon, 20 Oct 2014 15:45:40 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id n3so7538607wiv.5 for ; Mon, 20 Oct 2014 08:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s9xYFK+313KzwPgz9W1d9ADLWdurznGF2uGJaCq0vgo=; b=b7U/GSkJlIutW8S9JI3Ib8B8IrKGN6poWaa6a9GVumXUs76xEsIP36E0LhRdReVt9w 3LGVVqOJriuAj6Vl6sE0UHZShjpJs7mUW9/HDwTxUDxvSIIZSROW6OnJyq43IoAkYQys dEDq7Fijd6ykNOmHW8MGNTY/ZUE2SDbwaEkVyPWmB5izz80yO+8BX+LcN1kLyJoprFvJ RnYBopiOl5g9mS2av0ZaTfFy+uAmE7P43dHzYHlNO2KXu/0KCIiSZ/ktDHsJtjE4Ky0K nHz8mecmNjog0QYUMUv/fURd1JaepIWwovCzl96HZ82eYvy3eXeXJP+uLO36WkrVgT9w l/+Q== MIME-Version: 1.0 X-Received: by 10.194.2.168 with SMTP id 8mr35751603wjv.78.1413819938372; Mon, 20 Oct 2014 08:45:38 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.194.19.9 with HTTP; Mon, 20 Oct 2014 08:45:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 08:45:38 -0700 X-Google-Sender-Auth: hMrKOJRZhMtq4kCMCmOpattikzY Message-ID: Subject: Re: Intel DPDK added to FreeBSD ports collection From: Luigi Rizzo To: Jim Harris Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 15:45:40 -0000 very cool! cheers luigi On Mon, Oct 20, 2014 at 8:40 AM, Jim Harris wrote: > Just wanted to send a heads-up that Intel's Data Plane Development Kit > (DPDK) for high speed packet processing was added to the FreeBSD ports > collection last week under net/dpdk. Intel added support for FreeBSD > earlier this year, but until now required downloading from Intel's website > or dpdk.org. Thanks to Bruce Richardson from the Intel DPDK team and > vanilla@ and gnn@ for getting it checked into ports. > > For any questions, please check out dpdk.org and the developer mailing > list > (dev@dpdk.org). > > Regards, > > -Jim > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 16:18:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0454FD65 for ; Mon, 20 Oct 2014 16:18:24 +0000 (UTC) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B0B783B2 for ; Mon, 20 Oct 2014 16:18:23 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id s9KGHG9V026323 for ; Mon, 20 Oct 2014 11:17:16 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (rrcs-50-84-127-134.sw.biz.rr.com [50.84.127.134]) by mail.shrew.net (Postfix) with ESMTPSA id 667BC18A7D7 for ; Mon, 20 Oct 2014 11:17:11 -0500 (CDT) Message-ID: <544535C2.9020301@shrew.net> Date: Mon, 20 Oct 2014 11:18:10 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Broken IPsec + enc +pf/ipfw Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Mon, 20 Oct 2014 11:17:16 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 16:18:24 -0000 All, There appears to be an issue with FreeBSD 10.x when using enc device to filter inbound traffic on the receive path. After searching the mailing lists, I see two different people reporting the issue ... https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076900.html https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037951.html The second report had tracked it down to a specific commit ... http://svnweb.freebsd.org/base?view=revision&revision=254519 There appears to be quite a bit of info in both email threads, but I'll do my best to sum it up again. When an ESP packet arrives at a host for processing, the packet is seen on the enc0 interface but isn't seen by the pf firewall. This prevents the firewall from creating a state entry so returned packets get blocked by the firewall. IMO, this degrades the security of IPsec as makes it pretty much impossible to have a stateful firewall protect inbound traffic that arrives from an IPsec peer unless you are willing to write rules that let private network traffic inbound via your public interface after disabling enc ... # enc0 device options net.enc.in.ipsec_bpf_mask=2 net.enc.in.ipsec_filter_mask=2 net.enc.out.ipsec_bpf_mask=1 net.enc.out.ipsec_filter_mask=1 NOTE: These are the recommended settings from the ENC(4) man page. It should cause the inbound and outbound packets to be visible on the enc device without the outer header. [root@fw1 ~]# tcpdump -nei enc0 src or dst x.x.x.x tcpdump: WARNING: enc0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 65535 bytes capability mode sandbox enabled 11:06:42.256172 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 0, length 64 11:06:43.257731 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 1, length 64 11:06:44.260129 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 2, length 64 11:06:45.263452 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 3, length 64 11:06:46.264225 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 4, length 64 11:06:47.258684 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 5, length 64 [root@fw1 ~]# tcpdump -nei pflog0 src or dst x.x.x.x tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes capability mode sandbox enabled 11:06:42.257911 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 0, length 64 11:06:43.258224 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 1, length 64 11:06:44.260459 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 2, length 64 11:06:45.263674 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 3, length 64 11:06:46.264364 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 4, length 64 11:06:47.259121 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 5, length 64 I can confirm this is a regression between 9.x to 10.x as I upgraded a set of firewalls last night from 9.2 to 10.0. They use exactly the same configuration with the exception of some tweaks to the carp interface config ( changed significantly between 9.x and 10.x ). I also have two other sets of firewalls that run the exact same type of configuration on 9.x that are working exactly as expected. Lastly, I tried to locate a relevant PR but didn't find anything concrete. Is this related to the issue? And if so, can it be MFCd? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110959 Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 18:13:38 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1AC21E4 for ; Mon, 20 Oct 2014 18:13:38 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 9881133C for ; Mon, 20 Oct 2014 18:13:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9KIDcj0017956 for ; Mon, 20 Oct 2014 18:13:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN Date: Mon, 20 Oct 2014 18:13:38 +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.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 20 Oct 2014 18:13:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #12 from Eric Joyner --- (In reply to Garrett Cooper from comment #10) > (In reply to Eric Joyner from comment #8) > > So it sounds like we may just need to change IXGBE_RX_COPY_LEN from a fixed > > value of 160 to something that's calculated based on the length of struct > > m_hdr and struct m_pkthdr combined. > > > > I think they got 160 by adding together the size of the two header structs > > (88 in FreeBSD amd64), adding some number (8) to make that size divisible by > > 32 (96 % 32 == 0), and then subtracted that from MSIZE (256) to get > > IXGBE_RX_COPY_LEN (160), while keeping the padding added as > > IXGBE_RX_COPY_ALIGN. > > A couple questions then: > > - What architectures is this driver supported on? > - Is this optimization only valid for amd64? > - Why 32? - At least i386 and amd64, but it should theoretically work on anything with a PCI-E slot - This optimization specifically was contributed by scottl/luigi, looking at the commit logs. You should ask either of those two for details. - Doesn't the comment in the code you posted answer that? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 19:26:46 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3A1BADC for ; Mon, 20 Oct 2014 19:26:45 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id DAD4FD6D for ; Mon, 20 Oct 2014 19:26:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9KJQjxv041154 for ; Mon, 20 Oct 2014 19:26:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194344] [regression] Wake on LAN no longer works on em(4) Date: Mon, 20 Oct 2014 19:26:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: wblock@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 20 Oct 2014 19:26:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194344 --- Comment #3 from Warren Block --- Testing again with no changes, WoL worked. It seems intermittent. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 19:44:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D7FDF4 for ; Mon, 20 Oct 2014 19:44:35 +0000 (UTC) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (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 20278F32 for ; Mon, 20 Oct 2014 19:44:34 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by gateway2.nyi.internal (Postfix) with ESMTP id E333C3F8A for ; Mon, 20 Oct 2014 15:44:33 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Mon, 20 Oct 2014 15:44:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:in-reply-to :references:subject:date; s=smtpout; bh=rBUsUuJC9MW24k5fgNnIhklq cg4=; b=ZbLXy0mXpi4zi1lA/vNzsrsr5IUhp8Z2dayYOwZAAeq097z3MbMWFuVW ZKvucg3s3p7+gfxW0lRD+HVMht9Hi7FgU5dEJbaVtNYTAQ5KcHQOKJzC8RD8Y9LY dC3vFQ8+iSpkel4smjbeOm9RtgDviEvY8qiUpPikAVsjD2oRSY4= Received: by web3.nyi.internal (Postfix, from userid 99) id 9CAC011790A; Mon, 20 Oct 2014 15:44:33 -0400 (EDT) Message-Id: <1413834273.2953625.181228801.6E462532@webmail.messagingengine.com> X-Sasl-Enc: G5d2CR3qiHzE9FPR0gBfxEp8F2RVGR5rmNxKI4Pt3p/T 1413834273 From: Mark Felder To: Matthew Grooms , freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-e69fc525 In-Reply-To: <544535C2.9020301@shrew.net> References: <544535C2.9020301@shrew.net> Subject: Re: Broken IPsec + enc +pf/ipfw Date: Mon, 20 Oct 2014 14:44:33 -0500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 19:44:35 -0000 On Mon, Oct 20, 2014, at 11:18, Matthew Grooms wrote: > All, > > There appears to be an issue with FreeBSD 10.x when using enc device to > filter inbound traffic on the receive path. After searching the mailing > lists, I see two different people reporting the issue ... > Your subject mentions ipfw, but I don't see any mention of it in the body of your email or the bug report. Is this problem strictly related to pf? Is ipfw unaffected? From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 19:49:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E61B3F9 for ; Mon, 20 Oct 2014 19:49:34 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 653E8475C; Mon, 20 Oct 2014 19:49:33 +0000 (UTC) Message-ID: <544566D2.40303@FreeBSD.org> Date: Mon, 20 Oct 2014 23:47:30 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Matthew Grooms , freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> In-Reply-To: <544535C2.9020301@shrew.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 19:49:34 -0000 On 20.10.2014 20:18, Matthew Grooms wrote: > Lastly, I tried to locate a relevant PR but didn't find anything > concrete. Is this related to the issue? And if so, can it be MFCd? > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110959 Did you try the patch from last PR? It is small and should be applicable to stable/10. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 20:00:28 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DF4467B for ; Mon, 20 Oct 2014 20:00:28 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F93E101 for ; Mon, 20 Oct 2014 20:00:27 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id s9KJxM0R068771 for ; Mon, 20 Oct 2014 14:59:22 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (rrcs-50-84-127-134.sw.biz.rr.com [50.84.127.134]) by mail.shrew.net (Postfix) with ESMTPSA id F0D6E18A8BD for ; Mon, 20 Oct 2014 14:59:10 -0500 (CDT) Message-ID: <544569CF.2060905@shrew.net> Date: Mon, 20 Oct 2014 15:00:15 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> In-Reply-To: <544566D2.40303@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Mon, 20 Oct 2014 14:59:22 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 20:00:28 -0000 On 10/20/2014 2:47 PM, Andrey V. Elsukov wrote: > On 20.10.2014 20:18, Matthew Grooms wrote: >> Lastly, I tried to locate a relevant PR but didn't find anything >> concrete. Is this related to the issue? And if so, can it be MFCd? >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110959 > > Did you try the patch from last PR? It is small and should be applicable > to stable/10. > As I mentioned, it's not clear to me if the patch was intended to fix the issue that I am describing. Is that the case? If so, I would be happy to apply it and report back. These are production firewalls, so I'd prefer to have some feedback before calculating that risk. Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 20:03:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F9DB71D for ; Mon, 20 Oct 2014 20:03:24 +0000 (UTC) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D47B71A7 for ; Mon, 20 Oct 2014 20:03:23 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id s9KK2Ina027608 for ; Mon, 20 Oct 2014 15:02:18 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (rrcs-50-84-127-134.sw.biz.rr.com [50.84.127.134]) by mail.shrew.net (Postfix) with ESMTPSA id C983D18ADFE for ; Mon, 20 Oct 2014 15:02:12 -0500 (CDT) Message-ID: <54456A85.9010409@shrew.net> Date: Mon, 20 Oct 2014 15:03:17 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <1413834273.2953625.181228801.6E462532@webmail.messagingengine.com> In-Reply-To: <1413834273.2953625.181228801.6E462532@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Mon, 20 Oct 2014 15:02:18 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 20:03:24 -0000 On 10/20/2014 2:44 PM, Mark Felder wrote: > > On Mon, Oct 20, 2014, at 11:18, Matthew Grooms wrote: >> All, >> >> There appears to be an issue with FreeBSD 10.x when using enc device to >> filter inbound traffic on the receive path. After searching the mailing >> lists, I see two different people reporting the issue ... >> > > Your subject mentions ipfw, but I don't see any mention of it in the > body of your email or the bug report. Is this problem strictly related > to pf? Is ipfw unaffected? The link to the last email thread that I included made mention of ipfw. I am only testing the interaction with pf. I assume all the firewalls hook into pfil in more or less the same fashion, so it doesn't surprise me that both would experience the same dysfunction given the nature of the issue. -Matthew From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 20:52:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6F34921 for ; Mon, 20 Oct 2014 20:52:51 +0000 (UTC) Received: from forward3l.mail.yandex.net (forward3l.mail.yandex.net [84.201.143.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ABE0949 for ; Mon, 20 Oct 2014 20:52:51 +0000 (UTC) Received: from smtp3m.mail.yandex.net (smtp3m.mail.yandex.net [77.88.61.130]) by forward3l.mail.yandex.net (Yandex) with ESMTP id 587A3150056A; Tue, 21 Oct 2014 00:52:41 +0400 (MSK) Received: from smtp3m.mail.yandex.net (localhost [127.0.0.1]) by smtp3m.mail.yandex.net (Yandex) with ESMTP id E40CA27A00D3; Tue, 21 Oct 2014 00:52:40 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:c33::9a]) by smtp3m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id dmbAME88HL-qee0T4Vk; Tue, 21 Oct 2014 00:52:40 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: e0d4e6e6-22a7-4dbb-ba75-3f7abaf2e793 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1413838360; bh=YmkB+cke3vvhVA0Fugd2bZz8s96OsnSkqapmHPo45Mo=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=fEDLSzncQw2HCHLmuuZLSc6j9ksO7pgj2aoQqJK6qWDfAyZ/1V3o443vnDFdBsRgM bAh4O6byQmca22TVBvVD25HF8aH1stILZbYnBOpQhpgzxTCDy2+5Qu13XQcLZ9F1kM PVw28dLjp/0Q67WE+QEmZ2/m3gAxJWhHL6C1C8Vk= Authentication-Results: smtp3m.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54457599.4060102@yandex.ru> Date: Tue, 21 Oct 2014 00:50:33 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Matthew Grooms , freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> In-Reply-To: <544569CF.2060905@shrew.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="694oOeL46xM7CU5VUMT1pFRaGVQNR1QmV" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 20:52:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --694oOeL46xM7CU5VUMT1pFRaGVQNR1QmV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 21.10.2014 00:00, Matthew Grooms wrote: > On 10/20/2014 2:47 PM, Andrey V. Elsukov wrote: >> On 20.10.2014 20:18, Matthew Grooms wrote: >>> Lastly, I tried to locate a relevant PR but didn't find anything >>> concrete. Is this related to the issue? And if so, can it be MFCd? >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D110959 >> >> Did you try the patch from last PR? It is small and should be applicab= le >> to stable/10. >> >=20 > As I mentioned, it's not clear to me if the patch was intended to fix > the issue that I am describing. Is that the case? If so, I would be > happy to apply it and report back. These are production firewalls, so > I'd prefer to have some feedback before calculating that risk. This commit fixes similar problem with ipfw in 11.0-CURRENT. But I think it won't help you with pf in 10. I guess r266800 is what you need. --=20 WBR, Andrey V. Elsukov --694oOeL46xM7CU5VUMT1pFRaGVQNR1QmV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJURXWeAAoJEAHF6gQQyKF6OvwH/1t3Y2wuJ7n6Mi4v2/xonGih 9ktSG5l3Cqc14x908xOXwMrmoOZllyved6iCFa1DazNa3NbK6VD//I89yi0/kW1O WEtIv5DGWb2jHn2io38Yj9Yn6I8r8K6qPuvx3j4moc0F9ZZrqGAG69wWvxkECHIL 8mHUzvzs4zw6wFufnjIs0i7p0Sf9Pz0LZdnPXMGZ+GM+7rfHXGkfAULkFqbQC8DR K6+jYkooZZHYndmf0RsBEaTL28nsaJZzaM6pgtEkz3H27/Z+B6oE1KYn4/ZjF9Xl EL7a6Q0NI35puPYJ15D5C/taMTHypBNpZ5prJC6k0RvjJw6UD9KUBuAUJPo29Ek= =40W2 -----END PGP SIGNATURE----- --694oOeL46xM7CU5VUMT1pFRaGVQNR1QmV-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 20:54:20 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1AAF9CE for ; Mon, 20 Oct 2014 20:54:20 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id B881D960 for ; Mon, 20 Oct 2014 20:54:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9KKsKhi014722 for ; Mon, 20 Oct 2014 20:54:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second Date: Mon, 20 Oct 2014 20:54:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 20 Oct 2014 20:54:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Hiren Panchasara changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Triage |In Discussion CC| |hiren@FreeBSD.org --- Comment #2 from Hiren Panchasara --- (In reply to boba from comment #0) > It's impossible to create "pipe" with bandwidth higher than 2Gbits per > second. Possible due to "signed" type of variable. > > # ipfw pipe 1 config bw 2700mbit/s > ipfw: bandwidth too large I think you are right that its overflowing because of "signed" type. A simple change like this may fix the problem: Index: dummynet.c =================================================================== --- dummynet.c (revision 270969) +++ dummynet.c (working copy) @@ -546,7 +546,7 @@ if_name[namelen] = '\0'; *bandwidth = 0; } else { /* read bandwidth value */ - int bw; + uint32_t bw; char *end = NULL; bw = strtoul(arg, &end, 0); -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 21:35:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75F08238 for ; Mon, 20 Oct 2014 21:35:05 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CAB1DC9 for ; Mon, 20 Oct 2014 21:35:04 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id s9KLY4WH068974; Mon, 20 Oct 2014 16:34:04 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (rrcs-50-84-127-134.sw.biz.rr.com [50.84.127.134]) by mail.shrew.net (Postfix) with ESMTPSA id 0D98218B182; Mon, 20 Oct 2014 16:33:53 -0500 (CDT) Message-ID: <54458001.6000507@shrew.net> Date: Mon, 20 Oct 2014 16:34:57 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> In-Reply-To: <54457599.4060102@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Mon, 20 Oct 2014 16:34:04 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 21:35:05 -0000 On 10/20/2014 3:50 PM, Andrey V. Elsukov wrote: > On 21.10.2014 00:00, Matthew Grooms wrote: >> On 10/20/2014 2:47 PM, Andrey V. Elsukov wrote: >>> On 20.10.2014 20:18, Matthew Grooms wrote: >>>> Lastly, I tried to locate a relevant PR but didn't find anything >>>> concrete. Is this related to the issue? And if so, can it be MFCd? >>>> >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110959 >>> >>> Did you try the patch from last PR? It is small and should be applicable >>> to stable/10. >>> >> >> As I mentioned, it's not clear to me if the patch was intended to fix >> the issue that I am describing. Is that the case? If so, I would be >> happy to apply it and report back. These are production firewalls, so >> I'd prefer to have some feedback before calculating that risk. > > This commit fixes similar problem with ipfw in 11.0-CURRENT. But I think > it won't help you with pf in 10. I guess r266800 is what you need. > From the commit message, it would appear that r266800 is intended to correct issues related to IPv4-in-IPv6 or IPv6-in-IPv4 configurations. I'm using the more traditional IPv4-in-IPv4 tunnel mode configuration. Would a change to if_enc.c only effect the operation of ipfw? Unless I'm misreading the man page, it only deals with traffic associated with the IPSec processing path. In theory, I don't see why it would have an effect on one pfil consumer and not the other. It looks like the last commit to 10.0-RELEASE is r255926, which is the last real code change ( r257176 is just a header file include ) before your commit of 272695 in CURRENT. So besides r272695, the driver in both 10.x and CURRENT are essentially the same, are they not? Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 21:39:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 606182F7; Mon, 20 Oct 2014 21:39:24 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01DB0DFA; Mon, 20 Oct 2014 21:39:23 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so4045621qae.13 for ; Mon, 20 Oct 2014 14:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=amGfAgjxylqmxqFrf3Z1uGJmMfHRb+obfHKF6+o0XXQ=; b=cXrhuemPhxqMeER1Drzl7HLpJKw6uoJWWBWfjqxsqSpKnDOUa3Dm2hsulzVc3gvHVV ZI9S2TsRpNlXvdDU0WNnlZFraltnC/MVXbuIk5DTGtiax6wZfXv9DBZaEIMZukNyYjG9 Dsrv3OIxmRh8ZCby5Z80p+hO9RIw5ByFUnndYlVBNS4GFs+mdyb8SbwvJ59rmxkh7VE6 KK6XY6HO/ODfwC0+3S3Px9QTEf2gb1iP7HCrvPovr8yLcOIz4YA3zxuiSCWMMKzwwS99 0Jb/eRzZHgnMXrEJCOuaCI3kzzHcE6jgk9sFMXi7+WiqR4HJEhJtey+BMR5kqNqEJGkH 7inQ== MIME-Version: 1.0 X-Received: by 10.140.40.99 with SMTP id w90mr37299779qgw.18.1413841162659; Mon, 20 Oct 2014 14:39:22 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.205.201 with HTTP; Mon, 20 Oct 2014 14:39:22 -0700 (PDT) In-Reply-To: <20141020082345.GA2040@unixarea.DDR.dd> References: <20141020072528.GA1748@unixarea.DDR.dd> <20141020082345.GA2040@unixarea.DDR.dd> Date: Mon, 20 Oct 2014 14:39:22 -0700 X-Google-Sender-Auth: klpICHOJH4G9ynp4r40J5YgH5Xc Message-ID: Subject: Re: FreeBSD && TCP stealth From: hiren panchasara To: Matthias Apitz , freebsd-current , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 21:39:24 -0000 I am not aware of any work but adding -net to get more "networking" eyeball= s. On Mon, Oct 20, 2014 at 1:23 AM, Matthias Apitz wrote: > El d=C3=ADa Monday, October 20, 2014 a las 09:25:28AM +0200, Matthias Api= tz escribi=C3=B3: > >> >> Hello, >> >> Is there any work started or in progress to implement TCP stealth in our >> kernel as proposed to IETF in >> >> https://datatracker.ietf.org/doc/draft-kirsch-ietf-tcp-stealth/ >> >> The idea is that the client put some magic value in the ISN of the first >> SYN pkg which is derived from a secret the client and the server share. >> The server can check the ISN and decide if it will answer the SYN pkg or >> do a RST, for example. > > For Linux wip see also: https://gnunet.org/knock > > matthias > -- > Matthias Apitz | /"\ ASCII Ribbon Campaign: > E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail > WWW: http://www.unixarea.de/ | X - No proprietary attachments > phone: +49-170-4527211 | / \ - Respect for open standards > | en.wikipedia.org/wiki/ASCII_Ribbon_Campaig= n > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-net@FreeBSD.ORG Mon Oct 20 23:54:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16BD3A4F for ; Mon, 20 Oct 2014 23:54:13 +0000 (UTC) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5B2FDB3 for ; Mon, 20 Oct 2014 23:54:12 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id w10so122240pde.0 for ; Mon, 20 Oct 2014 16:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=JQjX45HhogBGFHdCuuOvVw3wonDuK6uAXTZwmRudblI=; b=Ndp2ctCu9HjDkoYL7bj3GHWi7fv5J2fxo1a611XUjrrnmTqzXiAR0BRxiYT7CziHFA 3Q0TR8RadWd/l6cMSLMN1saqg6BfdVzuUiW0e4Q32BZZMvmlv1RPgepghPJLdYlrLa4q ud358GaStQuzfkEBa8Po0jFZgP7lOAiyBVWXdBlFySjnkJRpVEz7hDZMN8GKSELN2css Ftv6UyKZpxwQmkw9xoVQXRhMRz/4tVYUr6umZ6lBqziKBO9HSrrSNcmcOXvXvquZmRNJ Ld/zOnWLOIr+PIYAE/3FbU1RK3k/EP2MC2kacmUG/JkmnEWsgeAoHs+jKvD8o0XLbdSV h1/Q== X-Received: by 10.70.48.202 with SMTP id o10mr31066859pdn.63.1413849252481; Mon, 20 Oct 2014 16:54:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.113.195 with HTTP; Mon, 20 Oct 2014 16:53:32 -0700 (PDT) From: Eric Joyner Date: Mon, 20 Oct 2014 16:53:32 -0700 Message-ID: Subject: Media types in ifconfig To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 20 Oct 2014 23:54:13 -0000 So, what are the two fields on the media line for? AFAICT, it looks like the first field is the media the user wants to use (so the driver typically sets it to Ethernet autoselect by default?), and the second field is for the media that's active in the interface. --- - Eric Joyner From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 00:14:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E597212B for ; Tue, 21 Oct 2014 00:14:05 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7AB4F59 for ; Tue, 21 Oct 2014 00:14:05 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so82498qae.41 for ; Mon, 20 Oct 2014 17:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EPyZk/GT/mOY1FlqMfuSg+jpkJpcIwBIAnE2SzxLeVg=; b=gNaTJuaEr9htOfA+DbX84kcrUgZXbi5RYBeUXvtDN+lVuP6s+0YyyFW8ThSpfidRxF B/SST7s7+Qh79cjINq2vPhMF1gzxcL1g2KGqlWUSOrLRdUlbIO4RdKyswzj/TQWAQ8Qc sACAeG4NY6aQFw+mk6pcEOxbBOTxKTnOtTM7OoP5qx7hR4cbLnMGFLMTlhn5c4BFgwH+ 9hlm1B4l1s+ruszdR153vxfHEeEdLDMq/us0VMTrme5WEUeHsUbUfxWDDLIlaz9O5EAa PSfHgclNohuHL9fW4gk1bpxy32tGyzetvLTqeuOy5hpuJQDs5BUzxGRRNPVI6SYLbJyg l2BQ== MIME-Version: 1.0 X-Received: by 10.140.91.73 with SMTP id y67mr38314321qgd.52.1413850444868; Mon, 20 Oct 2014 17:14:04 -0700 (PDT) Sender: hiren.panchasara@gmail.com Received: by 10.96.205.201 with HTTP; Mon, 20 Oct 2014 17:14:04 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 17:14:04 -0700 X-Google-Sender-Auth: t37B3nVhmhbicIcaw-gquixcX0Q Message-ID: Subject: Re: Media types in ifconfig From: hiren panchasara To: Eric Joyner Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Oct 2014 00:14:06 -0000 On Mon, Oct 20, 2014 at 4:53 PM, Eric Joyner wrote: > So, what are the two fields on the media line for? > > AFAICT, it looks like the first field is the media the user wants to use > (so the driver typically sets it to Ethernet autoselect by default?), and > the > second field is for the media that's active in the interface. Aren't those "type" and "subtype"? sys/net/if_media.h has more info. cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 00:59:31 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D85276DF for ; Tue, 21 Oct 2014 00:59:31 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id BF4F63B7 for ; Tue, 21 Oct 2014 00:59:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9L0xVkR068944 for ; Tue, 21 Oct 2014 00:59:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second Date: Tue, 21 Oct 2014 00:59: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: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: boba@boba.name X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 21 Oct 2014 00:59:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #3 from boba@boba.name --- How can we be sure this change to "unsigned" type does not brake anything else ? There might be some other places in dummynet code where this variable may be used as "signed". Unfortunately my C skills are not good enough to check this myself. Anyway. Even with this patch applied, this is not full solution to the problem, this just extends limits to 4Gbits per second. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 06:08:54 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 619F5B1 for ; Tue, 21 Oct 2014 06:08:54 +0000 (UTC) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (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 2435A75B for ; Tue, 21 Oct 2014 06:08:54 +0000 (UTC) Received: from [89.182.173.25] (helo=localhost) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1XgScm-0004gW-3b for freebsd-net@FreeBSD.org; Tue, 21 Oct 2014 08:08:52 +0200 Date: Tue, 21 Oct 2014 08:08:51 +0200 From: Marcus von Appen To: freebsd-net@FreeBSD.org Subject: Convert your bugs from Needs MFC Message-ID: <20141021060851.GZ1065@medusa.sysfault.org> Reply-To: Marcus von Appen MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8hIAwjNL+G6Jxmsm" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Df-Sender: MTEyNTc0Mg== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Oct 2014 06:08:54 -0000 --8hIAwjNL+G6Jxmsm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear freebsd-net@FreeBSD.org, the "Needs MFC" status is subject to be removed in a few weeks and will be replaced by the newly added flags "mfc-stable8", "mfc-stable9" and "mfc-stable10". We would like you to convert the bugs with the status "Needs MFC", that are currently assigned to you, to those new flags and to set the bug to "In Discussion". Please set only those flags to "?", for which a MFC is still required. If a MFC already took place for a stable branch, set the flag to "+". If a MFC will not be done for a stable branch, set the flag to "-". All bugs, which are not converted within the next 14 days (until the 5th of November), will be converted by bugmeister, requesting a MFC for all branches, unknowingly, if that may be correct or not. Thanks for your help Marcus on behalf of bugmeister --8hIAwjNL+G6Jxmsm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRF+HMACgkQi68/ErJnpkdRgQCdH3sIKoKTYGcJzYOBLKgbu3rs K2wAn3hC6PixYmHs1XCDYlyx1hU8lHG5 =M9nb -----END PGP SIGNATURE----- --8hIAwjNL+G6Jxmsm-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 07:59:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CD6699A for ; Tue, 21 Oct 2014 07:59:53 +0000 (UTC) Received: from forward10l.mail.yandex.net (forward10l.mail.yandex.net [IPv6:2a02:6b8:0:1819::a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FBC41CE for ; Tue, 21 Oct 2014 07:59:52 +0000 (UTC) Received: from smtp4m.mail.yandex.net (smtp4m.mail.yandex.net [77.88.61.131]) by forward10l.mail.yandex.net (Yandex) with ESMTP id 0105ABA114B; Tue, 21 Oct 2014 11:59:48 +0400 (MSK) Received: from smtp4m.mail.yandex.net (localhost [127.0.0.1]) by smtp4m.mail.yandex.net (Yandex) with ESMTP id 702C2BE00D3; Tue, 21 Oct 2014 11:59:48 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:c33::9a]) by smtp4m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id EjGtaz42MR-xlPeJaC0; Tue, 21 Oct 2014 11:59:47 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: dd649f31-5dba-4c23-a26b-10aceb8dcc05 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1413878387; bh=4kaHig99OTv44+2v+tQoBvwDyucScUCo61P/STj8bTU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ciMrSNCvDd2sbecTd7R7QRjrgwzbCXlNuX6ir9HXDlzyY5IPMetNJISkbAMo8wsGp J7ARXRZrDZfrXJw3W2CyP9ba2NaU3CF5PsSlGnpqDU2InUMpOrBUFSlmcGPIEj3Bvy lm93BFvyqW05UpVqTmOnrk0ltx+NsU5zQiVGJJv4= Authentication-Results: smtp4m.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <544611F8.9070403@yandex.ru> Date: Tue, 21 Oct 2014 11:57:44 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Matthew Grooms , freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> <54458001.6000507@shrew.net> In-Reply-To: <54458001.6000507@shrew.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Oct 2014 07:59:53 -0000 On 21.10.2014 01:34, Matthew Grooms wrote: >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110959 >>>> >>>> Did you try the patch from last PR? It is small and should be >>>> applicable >>>> to stable/10. >>>> >>> >>> As I mentioned, it's not clear to me if the patch was intended to fix >>> the issue that I am describing. Is that the case? If so, I would be >>> happy to apply it and report back. These are production firewalls, so >>> I'd prefer to have some feedback before calculating that risk. >> >> This commit fixes similar problem with ipfw in 11.0-CURRENT. But I think >> it won't help you with pf in 10. I guess r266800 is what you need. >> > > From the commit message, it would appear that r266800 is intended to > correct issues related to IPv4-in-IPv6 or IPv6-in-IPv4 configurations. > I'm using the more traditional IPv4-in-IPv4 tunnel mode configuration. It also changes places from where pfil consumers are called. You may use dtrace script to see where is the problem. Try this: > kldload dtraceall > cat > ~/ipsec.d #!/usr/sbin/dtrace -s fbt::ipsec_filter:entry { m = *(struct mbuf **)arg0; ip = (struct ip *)m->m_hdr.mh_data; printf("%s: %s: %s->%s proto %d", (arg1 & 1) ? "in": "out", (arg2 & 1) ? "before": "after", inet_ntoa(&ip->ip_src.s_addr), inet_ntoa(&ip->ip_dst.s_addr), ip->ip_p); } ^D > chmod +x ~/ipsec.d > ~/ipsec.d This script will print messages when ipsec_filter function will be invoked. Can you show what it will print for your case? > Would a change to if_enc.c only effect the operation of ipfw? Unless I'm > misreading the man page, it only deals with traffic associated with the > IPSec processing path. In theory, I don't see why it would have an > effect on one pfil consumer and not the other. pf and ipfw deal differently when they want to determine incoming interface. > It looks like the last commit to 10.0-RELEASE is r255926, which is the > last real code change ( r257176 is just a header file include ) before > your commit of 272695 in CURRENT. So besides r272695, the driver in both > 10.x and CURRENT are essentially the same, are they not? No, they are not the same. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 16:06:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E9888A8 for ; Tue, 21 Oct 2014 16:06:49 +0000 (UTC) Received: from mail.1970jan1-epo.ch (mail.1970jan1-epo.ch [IPv6:2a02:2770:13::1a24:0:11]) (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 2A4CB140 for ; Tue, 21 Oct 2014 16:06:48 +0000 (UTC) Received: from 1970jan1-epo.ch (c-174-57-248-44.hsd1.pa.comcast.net [174.57.248.44]) by mail.1970jan1-epo.ch (Postfix) with ESMTPSA id 8710B52D; Tue, 21 Oct 2014 16:06:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=1970jan1-epo.ch; s=1970; t=1413907605; bh=vQBbNTTwC9zUthgeKI6I/kp4wpvJq6APEK2rnSquDZQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=udFRh/AB8HAZDSGbKO+eoM6bgEUAByt2aFCItpPl5vkLXyaMmWwo5lrPyV9nWhDJ1 VZrvUUWLgykbKf63V7+UWHTO6LX4CuQMvWTYeO6J/Yqm/STpd6n7HUynBoujE9fHpr gVMcGxBawEn8EOjxw0DfI3eej0FVnQor6tEYvtaE= Date: Tue, 21 Oct 2014 12:06:43 -0400 From: Kyle Williams To: "Andrey V. Elsukov" Subject: Re: Broken IPsec + enc +pf/ipfw Message-ID: <20141021160643.GB2787@1970jan1-epo.ch> References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> <54458001.6000507@shrew.net> <544611F8.9070403@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544611F8.9070403@yandex.ru> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, Matthew Grooms X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Oct 2014 16:06:49 -0000 Hello, I'm currently using 10.0, IPSEC, racoon, enc, and pf between two remote hosts without NATT. The gif tunnel is ipv4 only, host A is ipv4 only, host B is ipv4/ipv6. I use IPSEC to route traffic between jails on both hosts, with the jails using cloned lo1 and 10.0.0.0/8 addresses. I'm testing the posted patches on host A with the following pf.conf: block all pass all I'm using the recommended sysctl's: net.enc.in.ipsec_bpf_mask=2 net.enc.in.ipsec_filter_mask=2 net.enc.out.ipsec_bpf_mask=1 net.enc.out.ipsec_filter_mask=1 On Tue Oct 21 00:50:33 2014, Andrey V. Elsukov wrote: > On 20.10.2014 20:18, Matthew Grooms wrote: >> Lastly, I tried to locate a relevant PR but didn't find anything >> concrete. Is this related to the issue? And if so, can it be MFCd? >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110959 > > Did you try the patch from last PR? It is small and should be applicable > to stable/10. On 10/20/2014 3:50 PM, Andrey V. Elsukov wrote: >This commit fixes similar problem with ipfw in 11.0-CURRENT. But I think >it won't help you with pf in 10. I guess r266800 is what you need. On Tue Oct 21 11:57:44 2014, Andrey V. Elsukov wrote: >It also changes places from where pfil consumers are called. You may use >dtrace script to see where is the problem. Try this: > >> kldload dtraceall >> cat > ~/ipsec.d >#!/usr/sbin/dtrace -s > >fbt::ipsec_filter:entry >{ > m = *(struct mbuf **)arg0; > ip = (struct ip *)m->m_hdr.mh_data; > printf("%s: %s: %s->%s proto %d", > (arg1 & 1) ? "in": "out", > (arg2 & 1) ? "before": "after", > inet_ntoa(&ip->ip_src.s_addr), > inet_ntoa(&ip->ip_dst.s_addr), > ip->ip_p); >} >^D >> chmod +x ~/ipsec.d >> ~/ipsec.d > >This script will print messages when ipsec_filter function will be >invoked. Can you show what it will print for your case? IPSEC traffic is still blocked after applying r272695. Here is the output of the above script during an incoming wget: 2 26761 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 2 26761 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 2 26761 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 ... With pf.conf only containing `pass all', traffic is passed (IP's munged): 2 26761 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 2 26761 ipsec_filter:entry out: after: 1.1.1.1->2.2.2.2 proto 4 1 26761 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 1 26761 ipsec_filter:entry out: after: 1.1.1.1->2.2.2.2 proto 4 1 26761 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 1 26761 ipsec_filter:entry out: after: 1.1.1.1->2.2.2.2 proto 4 2 26761 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 2 26761 ipsec_filter:entry out: after: 1.1.1.1->2.2.2.2 proto 4 1 26761 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 1 26761 ipsec_filter:entry out: after: 1.1.1.1->2.2.2.2 proto 4 ... Applying r266800 failed on sys/netipsec/ipsec_output.c on the last chunk, so I copied ipsec_output.c from head. r272695 is included as well. Traffic is still blocked with `block all' and `pass all' in pf.conf. Here is the dtrace output: 0 26759 ipsec_filter:entry in: after: 10.0.4.2->10.0.5.10 proto 6 3 26759 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 0 26759 ipsec_filter:entry in: after: 10.0.4.2->10.0.5.10 proto 6 3 26759 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 0 26759 ipsec_filter:entry in: after: 10.0.4.2->10.0.5.10 proto 6 3 26759 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 0 26759 ipsec_filter:entry in: after: 10.0.4.2->10.0.5.10 proto 6 ... And finally with only `pass all', traffic is passed: 0 26759 ipsec_filter:entry in: after: 10.0.4.2->10.0.5.10 proto 6 3 26759 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 3 26759 ipsec_filter:entry out: after: 1.1.1.1->2.2.2.2 proto 4 0 26759 ipsec_filter:entry in: after: 10.0.4.2->10.0.5.10 proto 6 3 26759 ipsec_filter:entry in: after: 10.0.4.2->10.0.5.10 proto 6 3 26759 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 3 26759 ipsec_filter:entry out: after: 1.1.1.1->2.2.2.2 proto 4 0 26759 ipsec_filter:entry in: after: 10.0.4.2->10.0.5.10 proto 6 0 26759 ipsec_filter:entry out: before: 10.0.5.10->10.0.4.2 proto 6 0 26759 ipsec_filter:entry out: after: 1.1.1.1->2.2.2.2 proto 4 ... I'm willing to test more kernel patches, but I can't install head. -- Kyle Williams (541) 250 0314 Kyle@1970Jan1-epo.ch PGP key: 0xD1E5BADF From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 16:35:28 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C297A1A2 for ; Tue, 21 Oct 2014 16:35:28 +0000 (UTC) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 918FB654 for ; Tue, 21 Oct 2014 16:35:27 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id s9LGYG1W043768 for ; Tue, 21 Oct 2014 11:34:16 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id 3395718B1E2 for ; Tue, 21 Oct 2014 11:34:11 -0500 (CDT) Message-ID: <54468B43.40602@shrew.net> Date: Tue, 21 Oct 2014 11:35:15 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> <54458001.6000507@shrew.net> <544611F8.9070403@yandex.ru> <20141021160643.GB2787@1970jan1-epo.ch> In-Reply-To: <20141021160643.GB2787@1970jan1-epo.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Tue, 21 Oct 2014 11:34:16 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Oct 2014 16:35:28 -0000 On 10/21/2014 11:06 AM, Kyle Williams wrote: > Hello, > > I'm currently using 10.0, IPSEC, racoon, enc, and pf between two remote > hosts without NATT. The gif tunnel is ipv4 only, host A is ipv4 only, > host B is ipv4/ipv6. I use IPSEC to route traffic between jails on both > hosts, with the jails using cloned lo1 and 10.0.0.0/8 addresses. > > I'm testing the posted patches on host A with the following pf.conf: > block all > pass all > > I'm using the recommended sysctl's: > net.enc.in.ipsec_bpf_mask=2 > net.enc.in.ipsec_filter_mask=2 > net.enc.out.ipsec_bpf_mask=1 > net.enc.out.ipsec_filter_mask=1 > [...] > > I'm willing to test more kernel patches, but I can't install head. > Hey Kyle, Thanks for lending a hand. I tested a few myself last night but had no luck. This morning I received an email off list that pointed to a patch that was merged to 10 stable. It sounds promising ... Log: Merge r263091: fix mbuf flags clash that lead to failure of operation of IPSEC and packet filters. https://lists.freebsd.org/pipermail/svn-src-stable-10/2014-March/001111.html I won't have a chance to try it until after business hours tonight, but will report back to the list with my results. Alternately, I assume you also could upgrade to 10.1-RC2 as the MFC for this patch happened back in March. I may go this route myself and then bump up to RELEASE in a few weeks when it happens. Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Oct 21 18:39:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1795EE1 for ; Tue, 21 Oct 2014 18:39:24 +0000 (UTC) Received: from mail.1970jan1-epo.ch (mail.1970jan1-epo.ch [IPv6:2a02:2770:13::1a24:0:11]) (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 9098465E for ; Tue, 21 Oct 2014 18:39:24 +0000 (UTC) Received: from 1970jan1-epo.ch (c-174-57-248-44.hsd1.pa.comcast.net [174.57.248.44]) by mail.1970jan1-epo.ch (Postfix) with ESMTPSA id B89D054C for ; Tue, 21 Oct 2014 18:39:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=1970jan1-epo.ch; s=1970; t=1413916761; bh=4ISzKqMbJqTi3TgfNx+Pq9BWhQIHLJbBVlJxI6VtZ3g=; h=Date:From:To:Subject:References:In-Reply-To; b=TfFP8zwNz0z5HIvjt4W6buADbe6dpdn5ampMA3otvBLVnhUPIm6pVrgwcPsHG7PNu ZxKbKc4zQ8dwlPkG8EgbbbAvHWmlb2sBk9J8GNJmNhE66DFN+EbyqdKnFrTE4RZtQO EkRXywYX/WiphbWlaUWB/JiEcUcuJ/nagrmBL2+U= Date: Tue, 21 Oct 2014 14:39:19 -0400 From: Kyle Williams To: freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw Message-ID: <20141021183919.GD2787@1970jan1-epo.ch> References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> <54458001.6000507@shrew.net> <544611F8.9070403@yandex.ru> <20141021160643.GB2787@1970jan1-epo.ch> <54468B43.40602@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54468B43.40602@shrew.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 21 Oct 2014 18:39:24 -0000 On Tue Oct 21 11:35:15 2014, Matthew Grooms wrote: >Hey Kyle, > >Thanks for lending a hand. I tested a few myself last night but had no >luck. This morning I received an email off list that pointed to a patch >that was merged to 10 stable. It sounds promising ... > >Log: > Merge r263091: fix mbuf flags clash that lead to failure of operation > of IPSEC and packet filters. > >https://lists.freebsd.org/pipermail/svn-src-stable-10/2014-March/001111.html > >I won't have a chance to try it until after business hours tonight, but >will report back to the list with my results. Alternately, I assume you >also could upgrade to 10.1-RC2 as the MFC for this patch happened back >in March. I may go this route myself and then bump up to RELEASE in a >few weeks when it happens. r263091, r266800, and r272695 together on 10.0-RELENG works for me. I didn't test r263091 by itself. Thanks! -- Kyle Williams (541) 250 0314 Kyle@1970Jan1-epo.ch PGP key: 0xD1E5BADF From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 10:45:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 850053E9 for ; Wed, 22 Oct 2014 10:45:34 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48E37D65 for ; Wed, 22 Oct 2014 10:45:34 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XgpQ3-000KsT-GS; Wed, 22 Oct 2014 10:29:15 +0400 Message-ID: <54478A59.10804@FreeBSD.org> Date: Wed, 22 Oct 2014 14:43:37 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: eric Joyner Subject: ixgbe ifmedia handling Content-Type: multipart/mixed; boundary="------------010003070702060804070603" Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 10:45:34 -0000 This is a multi-part message in MIME format. --------------010003070702060804070603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit There is a problem with correct media reporting in ixgbe: ixgbe_setup_optics() is called only at ixgbe_attach(). This means that: 1) if SFP slot was empty at the attach() time, "media" part will be set to adapter->optics = IFM_ETHER | IFM_AUTO; e.g. after attaching SFP status will look like media: Ethernet autoselect (autoselect ) status: active 2) If SFP slot was not empty, ifmedia will not be updated. The former case may trigger problems in other places inside kernel relying for ifmedia to be set correctly. For example, ifmedia_baudrate() will return 0 for given active interface (and this breaks best LACP aggregator selection making lagg interface attach impossible until module unload or reboot. Attached patch seems to work for 82599 NIC, but I'm pretty sure that it needs more checks. (And I wonder if we have the same problems with if_ixl). While investigating this case/performing tests I've noticed the following: * code inside ixgbe_local_timer() probing SFP seems to be dead /* Check for pluggable optics */ if (adapter->sfp_probe) was always false (due to failure to detect/set IXGBE_ERR_SFP_NOT_PRESENT status?) * ixgbe_handle_mod() was triggered in 1/4 of cases: e.g. if you detach SFP witin 2-3 seconds after attach it will not trigger. Even if detaching SFP which was inserted half an hour ago (and link was UP) this interrupt does not always trigger. --------------010003070702060804070603 Content-Type: text/x-patch; name="ixgbe_media.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ixgbe_media.diff" Index: ixgbe.c =================================================================== --- ixgbe.c (revision 273327) +++ ixgbe.c (working copy) @@ -5341,7 +5341,17 @@ struct ixgbe_hw *hw = &adapter->hw; u32 autoneg; bool negotiate; + int err; + err = hw->phy.ops.identify_sfp(hw); + if (err == IXGBE_ERR_SFP_NOT_PRESENT) { + device_printf(adapter->dev, + "SFP+ module was detached.\n"); + } else { + ixgbe_setup_optics(adapter); + INIT_DEBUGOUT1("ixgbe_sfp_probe: flags: %X\n", adapter->optics); + } + autoneg = hw->phy.autoneg_advertised; if ((!autoneg) && (hw->mac.ops.get_link_capabilities)) hw->mac.ops.get_link_capabilities(hw, &autoneg, &negotiate); --------------010003070702060804070603-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 19:29:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD219356 for ; Wed, 22 Oct 2014 19:29:10 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B50A822 for ; Wed, 22 Oct 2014 19:29:10 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id s9MJS3IW081803 for ; Wed, 22 Oct 2014 14:28:03 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id C311418A811 for ; Wed, 22 Oct 2014 14:27:52 -0500 (CDT) Message-ID: <54480578.6020106@shrew.net> Date: Wed, 22 Oct 2014 14:28:56 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> <54458001.6000507@shrew.net> <544611F8.9070403@yandex.ru> <20141021160643.GB2787@1970jan1-epo.ch> <54468B43.40602@shrew.net> <20141021183919.GD2787@1970jan1-epo.ch> In-Reply-To: <20141021183919.GD2787@1970jan1-epo.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 22 Oct 2014 14:28:03 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 19:29:10 -0000 On 10/21/2014 1:39 PM, Kyle Williams wrote: > On Tue Oct 21 11:35:15 2014, Matthew Grooms wrote: >> Hey Kyle, >> >> Thanks for lending a hand. I tested a few myself last night but had no >> luck. This morning I received an email off list that pointed to a patch >> that was merged to 10 stable. It sounds promising ... >> >> Log: >> Merge r263091: fix mbuf flags clash that lead to failure of operation >> of IPSEC and packet filters. >> >> https://lists.freebsd.org/pipermail/svn-src-stable-10/2014-March/001111.html >> >> I won't have a chance to try it until after business hours tonight, but >> will report back to the list with my results. Alternately, I assume you >> also could upgrade to 10.1-RC2 as the MFC for this patch happened back >> in March. I may go this route myself and then bump up to RELEASE in a >> few weeks when it happens. > > r263091, r266800, and r272695 together on 10.0-RELENG works for me. > > I didn't test r263091 by itself. > I couldn't get a kernel to boot without crashing with the single patch, (r263091) applied. With all three patches, I can also confirm that the problem is resolved. And some additional info: I also experimented with using gif + IPsec transport mode instead of enc + IPsec tunnel mode. I was hoping that changing the configuration would work around the issue. Unfortunately, gif + IPsec transport mode was exhibiting the same type of problems that enc + IPsec tunnel mode was, even with a patched kernel ( pf doesn't see the traffic on the gif interface so return traffic gets blocked for lack of a state entry ). Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 20:05:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7893ABE for ; Wed, 22 Oct 2014 20:05:12 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA0DFBD4 for ; Wed, 22 Oct 2014 20:05:12 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id hz1so4347980pad.36 for ; Wed, 22 Oct 2014 13:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KjuiEFNQLsF1kHGelEVNiTYc30MpqzBVpAz9ZL1TDYg=; b=N1owAKrG11azkDYWgicjca9EI/3wRHUORsuSMM9TukEGJvxcTuM/AtqToDV9tqyniE 0QLYoxrOvOXK30da3mJ2wQ8wESStctN6abJmrqm1olPp+/EIjsLt/wtA2ObuIBPHMLtX BApV/R7kFfxFnNweNmxOzo2Kvpt1y3D9h7xhsTRuGp+xwc2tTLA8nQlegElueet9e2fK xKxLjqgQWp1rzKlfbkgkuppPwLbUOhanqnJ8heqo1jU6N7Jy5SN0t3XO9bn4FQRhImsc EOwvtKgYMT0mq2vXFWZHBhJuA8wAAjhmmD/iKDfYRg5Xu241q1U7cx7gCgNcW5ap15+W QEuA== MIME-Version: 1.0 X-Received: by 10.68.236.137 with SMTP id uu9mr329907pbc.98.1414008312251; Wed, 22 Oct 2014 13:05:12 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.70.73.2 with HTTP; Wed, 22 Oct 2014 13:05:12 -0700 (PDT) In-Reply-To: <54480578.6020106@shrew.net> References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> <54458001.6000507@shrew.net> <544611F8.9070403@yandex.ru> <20141021160643.GB2787@1970jan1-epo.ch> <54468B43.40602@shrew.net> <20141021183919.GD2787@1970jan1-epo.ch> <54480578.6020106@shrew.net> Date: Wed, 22 Oct 2014 22:05:12 +0200 X-Google-Sender-Auth: U7XwQ895qrzX10W6zWDcaIOE8-8 Message-ID: Subject: Re: Broken IPsec + enc +pf/ipfw From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Matthew Grooms Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 20:05:12 -0000 On Wed, Oct 22, 2014 at 9:28 PM, Matthew Grooms wrote: > On 10/21/2014 1:39 PM, Kyle Williams wrote: > >> On Tue Oct 21 11:35:15 2014, Matthew Grooms wrote: >> >>> Hey Kyle, >>> >>> Thanks for lending a hand. I tested a few myself last night but had no >>> luck. This morning I received an email off list that pointed to a patch >>> that was merged to 10 stable. It sounds promising ... >>> >>> Log: >>> Merge r263091: fix mbuf flags clash that lead to failure of operation >>> of IPSEC and packet filters. >>> >>> https://lists.freebsd.org/pipermail/svn-src-stable-10/ >>> 2014-March/001111.html >>> >>> I won't have a chance to try it until after business hours tonight, but >>> will report back to the list with my results. Alternately, I assume you >>> also could upgrade to 10.1-RC2 as the MFC for this patch happened back >>> in March. I may go this route myself and then bump up to RELEASE in a >>> few weeks when it happens. >>> >> >> r263091, r266800, and r272695 together on 10.0-RELENG works for me. >> >> I didn't test r263091 by itself. >> >> > I couldn't get a kernel to boot without crashing with the single patch, > (r263091) applied. With all three patches, I can also confirm that the > problem is resolved. > > And some additional info: I also experimented with using gif + IPsec > transport mode instead of enc + IPsec tunnel mode. I was hoping that > changing the configuration would work around the issue. Unfortunately, gif > + IPsec transport mode was exhibiting the same type of problems that enc + > IPsec tunnel mode was, even with a patched kernel ( pf doesn't see the > traffic on the gif interface so return traffic gets blocked for lack of a > state entry ). > > The below patch should fix your issue. diff --git a/sys/netipsec/ipsec_input.c b/sys/netipsec/ipsec_input.c index 15d5bae..c31034a 100644 --- a/sys/netipsec/ipsec_input.c +++ b/sys/netipsec/ipsec_input.c @@ -472,11 +472,11 @@ ipsec4_common_input_cb(struct mbuf *m, struct secasvar *sav, * Pass the mbuf to enc0 for bpf and pfil. We will filter the IPIP * packet later after it has been decapsulated. */ - ipsec_bpf(m, sav, AF_INET, ENC_IN|ENC_BEFORE); + ipsec_bpf(m, sav, AF_INET, saidx->mode == IPSEC_MODE_TRANSPORT ? ENC_IN|ENC_AFTER : ENC_IN|ENC_BEFORE); if (prot != IPPROTO_IPIP) if ((error = ipsec_filter(&m, &sav->sah->saidx, PFIL_IN, - ENC_IN|ENC_BEFORE)) != 0) + saidx->mode == IPSEC_MODE_TRANSPORT ? ENC_IN|ENC_AFTER : ENC_IN|ENC_BEFORE)) != 0) return (error); #endif @@ -727,12 +727,12 @@ ipsec6_common_input_cb(struct mbuf *m, struct secasvar *sav, int skip, int proto * Pass the mbuf to enc0 for bpf and pfil. We will filter the IPIP * packet later after it has been decapsulated. */ - ipsec_bpf(m, sav, AF_INET6, ENC_IN|ENC_BEFORE); + ipsec_bpf(m, sav, AF_INET6, saidx->mode == IPSEC_MODE_TRANSPORT ? ENC_IN|ENC_AFTER : ENC_IN|ENC_BEFORE); /* XXX-BZ does not make sense. */ if (prot != IPPROTO_IPIP) if ((error = ipsec_filter(&m, &sav->sah->saidx, PFIL_IN, - ENC_IN|ENC_BEFORE)) != 0) + saidx->mode == IPSEC_MODE_TRANSPORT ? ENC_IN|ENC_AFTER : ENC_IN|ENC_BEFORE)) != 0) return (error); #endif > Thanks, > > -Matthew > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 21:21:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39435230; Wed, 22 Oct 2014 21:21:51 +0000 (UTC) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 93B876A7; Wed, 22 Oct 2014 21:21:50 +0000 (UTC) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKVEgf7d1QqPPPNOiW9D9oB4gX8fANYTWN@postini.com; Wed, 22 Oct 2014 14:21:50 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id s9MHiNpe025178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Oct 2014 13:44:23 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 13:44:23 -0400 From: "De La Gueronniere, Marc" To: Oleg Bulyzhin , Ryan Stone Subject: Re: buf_ring in HEAD is racy Thread-Topic: buf_ring in HEAD is racy Thread-Index: AQHO+IoP5aLTLgYkGEmAbDJX7D3/RJpnKbIAgdeJa4A= Date: Wed, 22 Oct 2014 17:44:22 +0000 Message-ID: References: <20131226175410.GA15332@lath.rinet.ru> In-Reply-To: <20131226175410.GA15332@lath.rinet.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <30B9E098F3FE3440A5F6F9935657B0B5@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-net , "Charbon, Julien" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 21:21:51 -0000 On 12/26/13, 6:54 PM, "Oleg Bulyzhin" wrote: >On Sat, Dec 14, 2013 at 12:04:57AM -0500, Ryan Stone wrote: >> I am seeing spurious output packet drops that appear to be due to >> insufficient memory barriers in buf_ring. I believe that this is the >> scenario that I am seeing: >>=20 >> 1) The buf_ring is empty, br_prod_head =3D br_cons_head =3D 0 >> 2) Thread 1 attempts to enqueue an mbuf on the buf_ring. It fetches >> br_prod_head (0) into a local variable called prod_head >> 3) Thread 2 enqueues an mbuf on the buf_ring. The sequence of events >> is essentially: >>=20 >> Thread 2 claims an index in the ring and atomically sets br_prod_head >>(say to 1) >> Thread 2 sets br_ring[1] =3D mbuf; >> Thread 2 does a full memory barrier >> Thread 2 updates br_prod_tail to 1 >>=20 >> 4) Thread 2 dequeues the packet from the buf_ring using the >> single-consumer interface. The sequence of events is essentialy: >>=20 >> Thread 2 checks whether queue is empty (br_cons_head =3D=3D br_prod_tail= ), >> this is false >> Thread 2 sets br_cons_head to 1 >> Thread 2 grabs the mbuf from br_ring[1] >> Thread 2 sets br_cons_tail to 1 >>=20 >> 5) Thread 1, which is still attempting to enqueue an mbuf on the ring. >> fetches br_cons_tail (1) into a local variable called cons_tail. It >> sees cons_tail =3D=3D 1 but prod_head =3D=3D 0 and concludes that the ri= ng is >> full and drops the packet (incrementing br_drops unatomically, I might >> add) >>=20 >>=20 >> I can reproduce several drops per minute by configuring the ixgbe >> driver to use only 1 queue and then sending traffic from concurrent 8 >> iperf processes. (You will need this hacky patch to even see the >> drops with netstat, though: >> http://people.freebsd.org/~rstone/patches/ixgbe_br_drops.diff) >>=20 >> I am investigating fixing buf_ring by using acquire/release semantics >> rather than load/store barriers. However, I note that this will >> apparently be the second attempt to fix buf_ring, and I'm seriously >> questioning whether this is worth the effort compared to the >> simplicity of using a mutex. I'm not even convinced that a correct >> lockless implementation will even be a performance win, given the >> number of memory barriers that will apparently be necessary. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >I was able to reproduce this bug. I've used 2-headed intel 10g card with >twinax loopback and 4-core amd phenom. Here some results: >- netperf works better for me than iperf in bug exposing, i was able to > see steady (~20packet per second) packet drop (running 4 netperf clients > simultaniously (UDP_STREAM test)). > >- i think you are right about the reason of those drops: there is a path >in=20 > buf_ring_enqueue() where packet can be dropped without proper >synchronization > with another instance of buf_ring_enqueue(). > >- i've looked through buf_ring.h and here is my opinion: race is possible > between buf_ring_enqueue() and buf_ring_dequeue_mc() which can lead to > memory corruption. (though i didn't find any buf_ring_dequeue_mc() >users in > kernel, and this race is not possible on x86/amd64 archs due to their > memory model, but it should be possible on arm/powerpc). > >I've attached patch which should fix all these problems. If there is no >objection i can commit it. Unfortunatly i have no non-x86 hardware to play >with so i can't test enqueue()/dequeue_mc() race myself. > Hi Oleg and Ryan, We have run into the spurious drop issue too. I could not make sense of seeing a single drop at a time every few seconds i.e. if a queue of 4k element fills, likely more than one packet is going to be dropped once the queue full condition is reached. So we investigated and came to the same conclusion on buf_ring_enqueue being broken, at which point I found this thread. Are there any pending patches/investigations beside Oleg=B9s patch ? We are definitely interested in helping with this, I just want to make sure that we are not duplicating efforts. I also suspect there are further problems with buf_ring. A full wrap around of the atomically swapped value is possible. I.e. the code thinks it just atomically updated a head/tail index when in fact a full wrap around occurred leading to undefined land. A relatively simple way to avoid this is to only mask on ring array access, and to let the head/tail/prod/cons indices overflow the array. Cheers, Marc de la Gueronniere =8B Verisign (apologies for the following legal boilerplate) From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 21:32:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 206B03E0; Wed, 22 Oct 2014 21:32:39 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7A22814; Wed, 22 Oct 2014 21:32:38 +0000 (UTC) Received: by mail-yh0-f44.google.com with SMTP id i57so4266393yha.17 for ; Wed, 22 Oct 2014 14:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=BExGQ+n3bWGz3T/01iK2ojH4SPAL5PxJELn6lEJNYBY=; b=hG57gxHu6+4d3gfv9LSt7dz4OBUyTvNqp/QdNaYE5vgkGr9KDpRW/u3R/vKpqCI1LW fHeYrWvNmz1CvYTGlUHX8HCdBz7SRD6761fEe0Irg8Hq8IJU/aAT086rwWVHeuQ3nXyA 9ADhLzWGrdz7DfkIQeuZ9mpX8iuvpBGQXG7LsIYZhCX2sYzPh0AJP1x+4F5EeM8eKDzs A2nFH951O/Vb9cl+45Pt3z/BMyaGuZrABq58hbl3875q3DZMPe2c613qKAXWGqYA5nxU wa765lcKaLkGEa1QeZIXy6TY/bDWno59eyVPoWWZ8alcjuyb8kFY+GmLKB18QCniCKZm mWqQ== MIME-Version: 1.0 X-Received: by 10.236.16.230 with SMTP id h66mr672605yhh.145.1414013557879; Wed, 22 Oct 2014 14:32:37 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Wed, 22 Oct 2014 14:32:37 -0700 (PDT) In-Reply-To: References: <20131226175410.GA15332@lath.rinet.ru> Date: Wed, 22 Oct 2014 14:32:37 -0700 X-Google-Sender-Auth: PRBMr1ywrOa4oZzcKg-ftLRUzNE Message-ID: Subject: Re: buf_ring in HEAD is racy From: "K. Macy" To: "De La Gueronniere, Marc" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ryan Stone , Oleg Bulyzhin , "Charbon, Julien" , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 21:32:39 -0000 > Hi Oleg and Ryan, > > We have run into the spurious drop issue too. I could not make sense of > seeing a single drop at a time every few seconds i.e. if a queue of 4k > element fills, likely more than one packet is going to be dropped once th= e > queue full condition is reached. So we investigated and came to the same > conclusion on buf_ring_enqueue being broken, at which point I found this > thread. > > Are there any pending patches/investigations beside Oleg=C2=B9s patch ? W= e are > definitely interested in helping with this, I just want to make sure that > we are not duplicating efforts. > > I also suspect there are further problems with buf_ring. A full wrap > around of the atomically swapped value is possible. I.e. the code thinks > it just atomically updated a head/tail index when in fact a full wrap > around occurred leading to undefined land. A relatively simple way to > avoid this is to only mask on ring array access, and to let the > head/tail/prod/cons indices overflow the array. I'll have 40GigE hardware to test with in a week or two. I'll look in to it then. Cheers. -K From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 21:49:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89E5692A for ; Wed, 22 Oct 2014 21:49:40 +0000 (UTC) Received: from nm20-vm2.bullet.mail.ir2.yahoo.com (nm20-vm2.bullet.mail.ir2.yahoo.com [212.82.96.244]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0812C94B for ; Wed, 22 Oct 2014 21:49:39 +0000 (UTC) Received: from [212.82.98.50] by nm20.bullet.mail.ir2.yahoo.com with NNFMP; 22 Oct 2014 21:47:48 -0000 Received: from [212.82.98.68] by tm3.bullet.mail.ir2.yahoo.com with NNFMP; 22 Oct 2014 21:47:48 -0000 Received: from [127.0.0.1] by omp1005.mail.ir2.yahoo.com with NNFMP; 22 Oct 2014 21:47:48 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 287707.64999.bm@omp1005.mail.ir2.yahoo.com Received: (qmail 34609 invoked by uid 60001); 22 Oct 2014 21:47:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1414014468; bh=HE3M4aT6gF5AZ5byj2kuSz06awXrm04vVAx98kh/ud4=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=aKoJHYIpzeVSu4Khg7zlEVlDYPEekBXDqb88BkGlF8l6J0cSk9ty5fNJuVlUu6tmLr0QjBR970ObOuKN3tayEriOTGG3auGG1N5vmry/BQClCX57Rg082ZdOEvLQtK52yb2/lR/vnuUIvIMFDpeerWYh0YuhmmYIdHzppRgy8WM= X-YMail-OSG: FpnvD.4VM1lMQU6iuxxB6Y2ytSXCYmKhIgoHOE5WR_CAzZ0 iArr745qmCZghBTpyzALFsyin5GbxLUXs4P.8KOFXrSHsK9msL7.atnk0vjQ rFqmInmKucZPG8EwyOPDhs6vqLIgIxDQBB18ySO8aydh3wJclw6wno3i7H6r ObFgCqVdLa9133EW1pMWS.T7fMZDIXekr_wutygciTgddsIIC9gcGe.155T9 5qUe4JG871ixU1But5KvwLdUcEQWNKf8BgqNSt1fbnLaYEIqujKHw39Art_i U3NZu2_VBDBhNEOB6y37rbsGZJ3fB6UFHFxh4gza_pFO9dclZLCRq0wBpvy3 xHII5wJnZ6q7KurFMyVecgKNtwt2FDJ5fUTxRewZusuBGyziHWE.k4bIZJls _2mJv0yBGRc.MKd6dRAqa.Bmrpn59IHLyvjHef3vZTBieWhivALeaMk46xia Vx9splpuVzt1xkytYPOg7bMoTAy4gXTCeN9aELUYC2iwZNAU_DUCON7CT3fE JpEBYRKZwrwLXBOBRcCIAVEp8MYxI.EcLumloJLMZ9G7wXlWNVQ-- Received: from [92.254.199.208] by web172806.mail.ir2.yahoo.com via HTTP; Wed, 22 Oct 2014 22:47:48 BST X-Rocket-MIMEInfo: 002.001, SGVsbG8sCgpBIHNpbXBsZSBxdWVzdGlvbixpZiBJIHdhbnQgdG8ga25vdyBpZiB0aGVyZSBpcyBhIHBhdGNoIGZvciBteQpwcm9ibGVtIHdoZXJlIHNob3VsZCBpIExvb2s_aXMgdGhlcmUgYSBkYXRhIGJhc2Ugb3Igc2ltaWxhciB3aXRoCmFsbCBwYXRjaGVzIGZvciBldmVyeSBzb3VyY2UgY29kZSBmaWxlID8gb3IgaG93IGRvZXMgb25lIGdvZXMgYWJvdXQuCk1hbnkgdGhhbmtzCgEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.203.733 Message-ID: <1414014468.49733.YahooMailNeo@web172806.mail.ir2.yahoo.com> Date: Wed, 22 Oct 2014 22:47:48 +0100 From: Tony Moseby Reply-To: Tony Moseby Subject: patches To: "freebsd-net@freebsd.org" , "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 21:49:40 -0000 Hello,=0A=0AA simple question,if I want to know if there is a patch for my= =0Aproblem where should i Look?is there a data base or similar with=0Aall p= atches for every source code file ? or how does one goes about.=0AMany than= ks=0A From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 21:55:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 801B9B16; Wed, 22 Oct 2014 21:55:48 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52A2DA22; Wed, 22 Oct 2014 21:55:48 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id r10so4347717pdi.10 for ; Wed, 22 Oct 2014 14:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lYaral+f2i0Bd9W/bVfl6L1YrIHT6/TqG3BYdjDYgqw=; b=y6/aeMa3vDXaguDb5EjzdA5I1wuPqLtmrp7H0pWN8/3MaVMkPW3QvI7n6PLxb3Wriz ma1Mr+q70NEYWWnurzu12itwjP/epHrs+n/WvVjJjCiwTjYw/rJSCnpYQ34oWg6tBxzb WF2/pi8OWdH7L6nwpormbRfpRqxl8rURTZeNhQtM65zGOw5pGHmio2FB3OiPbrto/Xpg 1cJJA/YqzvKzo0cF3uhxHLDgKQotCCuEj7SR9aS+V6peog4H503ztv3UwWeqKEpeMuAI /YtCsRzMcCx1k0Rg2o4LlQ1+axJGIuzIYNUGTVYQbdJ+/ikH7qjOzMwBDuZ31SPIbOOO OR4Q== X-Received: by 10.66.251.194 with SMTP id zm2mr700747pac.33.1414014947868; Wed, 22 Oct 2014 14:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.24.101 with HTTP; Wed, 22 Oct 2014 14:55:07 -0700 (PDT) In-Reply-To: <54478A59.10804@FreeBSD.org> References: <54478A59.10804@FreeBSD.org> From: Eric Joyner Date: Wed, 22 Oct 2014 14:55:07 -0700 Message-ID: Subject: Re: ixgbe ifmedia handling To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 21:55:48 -0000 Hi, On Wed, Oct 22, 2014 at 3:43 AM, Alexander V. Chernikov < melifaro@freebsd.org> wrote: > There is a problem with correct media reporting in ixgbe: > > ixgbe_setup_optics() is called only at ixgbe_attach(). > This means that: > 1) if SFP slot was empty at the attach() time, "media" part will be set to > adapter->optics = IFM_ETHER | IFM_AUTO; > e.g. after attaching SFP status will look like > media: Ethernet autoselect (autoselect ) > status: active > 2) If SFP slot was not empty, ifmedia will not be updated. > > The former case may trigger problems in other places inside kernel relying > for ifmedia to be set correctly. > For example, ifmedia_baudrate() will return 0 for given active interface > (and this breaks best LACP aggregator selection > making lagg interface attach impossible until module unload or reboot. > > Attached patch seems to work for 82599 NIC, but I'm pretty sure that it > needs more checks. > (And I wonder if we have the same problems with if_ixl). > Your attached patch seems to work okay, but it doesn't deal with changing the baudrate. I don't think we should print out a message every time an SFP module is removed though. Aside from that, what kind of checks should there be? > > While investigating this case/performing tests I've noticed the following: > > * code inside ixgbe_local_timer() probing SFP seems to be dead > /* Check for pluggable optics */ > if (adapter->sfp_probe) > was always false (due to failure to detect/set IXGBE_ERR_SFP_NOT_PRESENT > status?) I will look at removing that. > > * ixgbe_handle_mod() was triggered in 1/4 of cases: > e.g. if you detach SFP witin 2-3 seconds after attach it will not trigger. > Even if detaching SFP which was inserted half an hour ago (and link was > UP) this interrupt does not always trigger. > You mean ixgbe_handle_msf(), right? I've just tried it, and noticed the same thing you do. I think this could be extended -- it'd be good to change if_baudrate when the media type changes if that value is important. For adding to the list of media types, it sounds like it could be an unnecessary hassle. Is it important to be able to force speeds using ifconfig media types vs a sysctl? - Eric From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 22:51:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2C50864 for ; Wed, 22 Oct 2014 22:51:43 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DC7EF23 for ; Wed, 22 Oct 2014 22:51:43 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id n3so2187615wiv.3 for ; Wed, 22 Oct 2014 15:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=J46vLleOc/OwJ8oqOR05s1mOmPZ+Rn/v9CZaL/t8i24=; b=EPjkkbpOj06Xc0XNNqdRCDN8MZxqiv3tsFqWiEWE3mcPKxp6zwLsdR+DDLAJi3EVcL bYP+jHezSobv5wto9IC5+OruzxHzk+hRD22IDu9ga54Vg8BCj5rifREdalbMxWldOv7u Du5H5+Yt/ysdqTBJ7DVuDUkEmwepd+vTEPuzbnC/w0Jwjzxi0l4wtnOLDSZ1W8dhm8cZ sna9nwDu1vvzLY/gZBOGrbqi/ckdz4NR78lJcaRGgcQPbfOh+E4sT3GrBxxHsOA8fVS1 +PATYoTL4dnpynqapiMZJx62TWCECf5pckljHEETTKZLMDXbRfntCLVSLpLN9HlPI+LC 0k8A== MIME-Version: 1.0 X-Received: by 10.194.78.238 with SMTP id e14mr1051956wjx.106.1414018301578; Wed, 22 Oct 2014 15:51:41 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.194.220.227 with HTTP; Wed, 22 Oct 2014 15:51:41 -0700 (PDT) In-Reply-To: <1414014468.49733.YahooMailNeo@web172806.mail.ir2.yahoo.com> References: <1414014468.49733.YahooMailNeo@web172806.mail.ir2.yahoo.com> Date: Wed, 22 Oct 2014 16:51:41 -0600 X-Google-Sender-Auth: Qj9NL78JwJJTPjH9ys2HY2yfc4M Message-ID: Subject: Re: patches From: Alan Somers To: Tony Moseby Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 22:51:43 -0000 On Wed, Oct 22, 2014 at 3:47 PM, Tony Moseby wrote: > Hello, > > A simple question,if I want to know if there is a patch for my > problem where should i Look?is there a data base or similar with > all patches for every source code file ? or how does one goes about. > Many thanks I'm not sure what you're looking for. If you want to see problems reported by other users, check https://bugs.freebsd.org/bugzilla/ . If you want to see changes to FreeBSD source code that haven't yet been merged to your released version, check https://svnweb.freebsd.org/base/head/ -Alan From owner-freebsd-net@FreeBSD.ORG Wed Oct 22 23:41:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9890B524 for ; Wed, 22 Oct 2014 23:41:53 +0000 (UTC) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63D7A64A for ; Wed, 22 Oct 2014 23:41:53 +0000 (UTC) Received: by mail-oi0-f67.google.com with SMTP id v63so896621oia.6 for ; Wed, 22 Oct 2014 16:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wnC8exd1EjkmdoAl5STILu65KejvtLLEFbK3ChmgUrg=; b=bXXp+aarZWEIhB3yY5PZqPYzkDjQ2ywSTOv86C43Xckn6PqQiM/mcFpPu1Y99bW9ba u8sfoun3dGaQFG0je8T1Pg0zLpmI7J42t44lIVvFwpx71jnP7barFqJoLyRlegKE/qSF 0UegcvverfJvvPuPbiQmfNmMYNMYiPnEjvOUQ/uoXZJmfd+/9VkfiFKcGliSXXm7sI6S pSGuQl5iliKkCUVyGFTNw76YOzizKy76+zZM0sAZIJLO3hZ6/GQ4bb6Ugta39vEZcFCE POXCWncjh0CKqcAmLONsqrxANETAn67sHxQPJZsjgBM0T3qfA6c5mBhxdcAmwdXbPgcl 1r1A== MIME-Version: 1.0 X-Received: by 10.202.93.134 with SMTP id r128mr1032295oib.0.1414021312709; Wed, 22 Oct 2014 16:41:52 -0700 (PDT) Received: by 10.76.18.196 with HTTP; Wed, 22 Oct 2014 16:41:52 -0700 (PDT) Date: Wed, 22 Oct 2014 16:41:52 -0700 Message-ID: Subject: ipfw command freezes system From: javocado To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 22 Oct 2014 23:41:53 -0000 I'm seeing an occasional, recurring problem on my 8.3-RELEASE amd64 systems where when I enter an ipfw rule, the system becomes locked up. For example, when entering a command like this: ipfw add 1 allow ip from x.x.x.x to me or other times with a command like: ipfw add xxx skipto ........ the server becomes unreachable via the network. I am however still able to get to a shell via console where I ran top: last pid: 25518; load averages: 0.75, 1.12, 0.93 up 4+00:13:02 13:55:34 221 processes: 1 running, 215 sleeping, 5 lock CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 486M Active, 40G Inact, 174G Wired, 24M Cache, 24G Buf, 18G Free Swap: 32G Total, 32G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 25518 root 1 44 0 9372K 2768K CPU12 12 0:00 0.10% top 79561 xxxx 1 46 0 35284K 13424K *IPFW 12 271:00 0.00% sshd 79564 xxxx 1 45 0 156M 16808K select 0 65:08 0.00% rsync 22311 xxxx 1 44 0 27092K 4676K select 4 13:23 0.00% sshd 13056 xxxx 1 44 0 27092K 4720K select 0 12:13 0.00% sshd 43625 xxxx 1 45 0 29140K 6924K select 5 10:25 0.00% sshd 18925 xxxx 1 44 0 27092K 4640K select 8 10:08 0.00% sshd 14423 xxxx 1 44 0 29140K 6328K select 3 7:59 0.00% sshd 11356 xxxx 1 44 0 12992K 2544K select 2 7:52 0.00% sftp-server 20619 xxxx 1 44 0 116M 101M select 5 6:25 0.00% rsync 98406 xxxx 1 44 0 29140K 7136K select 2 6:09 0.00% sshd 20617 xxxx 1 44 0 35284K 12992K *IPFW 15 6:03 0.00% sshd 54146 xxxx 1 44 0 27092K 4556K select 3 5:04 0.00% sshd 63688 xxxx 1 44 0 27092K 5728K select 16 4:07 0.00% sshd 20624 xxxx 1 44 0 156M 102M select 0 3:45 0.00% rsync 43629 xxxx 1 44 0 5832K 2084K select 0 3:41 0.00% rsync Note those "*IPFW" state processes are long running child sshd processes, not master sshd daemon itself. I've tried to do an ipfw flush in these situations before but those commands never return and the system just stays locked up and unreachable. I was able to issue a reboot from the console, but even that did not complete: Oct 21 13:56:53 xxxx reboot: rebooted by root Oct 21 13:56:54 xxxx syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop... and I had to reset. Here's the ipfw ruleset in place: 00110 count ip from any to any via igb0 in 00111 count ip from any to any via igb0 out 00210 skipto 410 ip from x.x.x.x/27,x.x.x.x/29,x.x.x.x/24,x.x.x.x/28 to me 00210 skipto 410 ip from me to x.x.x.x/27,x.x.x.x/29,x.x.x.x/24,x.x.x.x/28 00211 skipto 410 ip from x.x.x.x/24 to me 00211 skipto 410 ip from me to x.x.x.x/24 00212 skipto 410 ip from x.x.x.x/24 to me 00212 skipto 410 ip from me to x.x.x.x/24 00214 skipto 410 ip from x.x.x.x,x.x.x.x to me 00214 skipto 410 ip from me to x.x.x.x,x.x.x.x 00218 skipto 410 ip from x.x.x.x to me 00218 skipto 410 ip from me to x.x.x.x 00219 skipto 410 ip from x.x.x.x to me 00219 skipto 410 ip from me to x.x.x.x 00225 skipto 410 ip from x.x.x.x to me 00225 skipto 410 ip from me to x.x.x.x 00226 skipto 410 ip from x.x.x.x to me 00226 skipto 410 ip from me to x.x.x.x 00227 skipto 410 ip from x.x.x.x to me 00227 skipto 410 ip from me to x.x.x.x 00310 pipe 5 ip from me to x.x.x.x 00310 pipe 5 ip from x.x.x.x to me 00311 skipto 410 ip from me to x.x.x.x 00311 skipto 410 ip from x.x.x.x to me 00312 pipe 1 ip from any to me 00313 pipe 2 ip from any to me 00314 pipe 3 ip from me to any 00315 pipe 4 ip from me to any 00410 allow tcp from any to any established 00411 allow icmp from any to any icmptypes 0,3,8,11 00420 deny icmp from any to any 00430 allow ip from any to any via lo0 00510 deny ip from any to 127.0.0.0/8 00511 deny ip from 127.0.0.0/8 to any 00512 deny ip from 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 to any 00513 deny ip from any to 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 00514 deny ip from 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any 00515 deny ip from any to 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 00610 deny tcp from any to any tcpflags syn tcpoptions !mss 00611 deny tcp from any to any tcpflags syn,fin 00612 deny tcp from any to any tcpflags fin,psh,rst,urg 00613 deny tcp from any to any tcpflags fin,psh,urg 00614 deny tcp from any to any tcpflags syn,fin,ack,rst 00615 deny tcp from any to any tcpflags !syn,!fin,!ack 01010 allow udp from me to any dst-port 53 01011 allow udp from x.x.x.x,x.x.x.x 53 to me 01012 allow udp from any to me dst-port 33433-33499 01020 allow tcp from any to x.x.x.x dst-port 21,22,62000-64000 setup 65000 deny log logamount 1000 ip from any to me 65001 deny log logamount 1000 ip from any to me6 65535 allow ip from any to any # ipfw pipe list 00001: 200.000 Mbit/s 0 ms burst 0 q131073 50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail sched 65537 type FIFO flags 0x0 0 buckets 1 active 0 ip 0.0.0.0/0 0.0.0.0/0 10 15000 0 0 0 00002: 32.000 Mbit/s 0 ms burst 0 q131074 50 sl. 0 flows (1 buckets) sched 65538 weight 0 lmax 0 pri 0 droptail sched 65538 type FIFO flags 0x1 64 buckets 10 active mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 0 00003: 100.000 Mbit/s 0 ms burst 0 q131075 50 sl. 0 flows (1 buckets) sched 65539 weight 0 lmax 0 pri 0 droptail sched 65539 type FIFO flags 0x0 0 buckets 1 active 0 ip 0.0.0.0/0 0.0.0.0/0 6 312 1 52 0 00004: 24.000 Mbit/s 0 ms burst 0 q131076 50 sl. 0 flows (1 buckets) sched 65540 weight 0 lmax 0 pri 0 droptail sched 65540 type FIFO flags 0x1 64 buckets 9 active mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 0 00005: 40.000 Mbit/s 0 ms burst 0 q131077 50 sl. 0 flows (1 buckets) sched 65541 weight 0 lmax 0 pri 0 droptail sched 65541 type FIFO flags 0x0 0 buckets 0 active What other troubleshooting or remedy should I do via console when this happens, or perhaps is there a problem with the way we've setup our ruleset? Thanks for your help! From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 10:58:27 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3187705 for ; Thu, 23 Oct 2014 10:58:27 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [84.201.143.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 687AF19E for ; Thu, 23 Oct 2014 10:58:26 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward4l.mail.yandex.net (Yandex) with ESMTP id 4EB121440FBA; Thu, 23 Oct 2014 14:58:17 +0400 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id CB0BA16A1526; Thu, 23 Oct 2014 14:58:16 +0400 (MSK) Received: from unknown (unknown [2a02:6b8:0:81f::186]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 6gBhChlJ5A-wFYmEdxA; Thu, 23 Oct 2014 14:58:15 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 5b387603-8b7d-4e1a-9f63-b0c7c8605adf DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1414061896; bh=EOMUeZOdlSc1tQOZzdG9drht7X/oWlpm24qEkz3/I0k=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ftOUhVSUGIiYRO+fwA9vk1cRoTYtKd5dHfCJx7789FtMtw3WHU2ttjw5ndAtYIH8i ARTTkVFG9Bfvc/oJ9oLu5q/BjpueOLvDa9m5Xw7kuPmOEeH2cd2tdrLHRLlYzEaDqs njarke7zGvJD5fMOQC3Zr2HGDLY6iRzitJSblbmE= Authentication-Results: smtp12.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5448DEE8.40100@yandex.ru> Date: Thu, 23 Oct 2014 14:56:40 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Matthew Grooms , freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> <54458001.6000507@shrew.net> <544611F8.9070403@yandex.ru> <20141021160643.GB2787@1970jan1-epo.ch> <54468B43.40602@shrew.net> <20141021183919.GD2787@1970jan1-epo.ch> <54480578.6020106@shrew.net> In-Reply-To: <54480578.6020106@shrew.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Oct 2014 10:58:27 -0000 On 22.10.2014 23:28, Matthew Grooms wrote: > On 10/21/2014 1:39 PM, Kyle Williams wrote: >> On Tue Oct 21 11:35:15 2014, Matthew Grooms wrote: >>> Hey Kyle, >>> >>> Thanks for lending a hand. I tested a few myself last night but had no >>> luck. This morning I received an email off list that pointed to a patch >>> that was merged to 10 stable. It sounds promising ... >>> >>> Log: >>> Merge r263091: fix mbuf flags clash that lead to failure of operation >>> of IPSEC and packet filters. >>> >>> https://lists.freebsd.org/pipermail/svn-src-stable-10/2014-March/001111.html >>> >>> >>> I won't have a chance to try it until after business hours tonight, but >>> will report back to the list with my results. Alternately, I assume you >>> also could upgrade to 10.1-RC2 as the MFC for this patch happened back >>> in March. I may go this route myself and then bump up to RELEASE in a >>> few weeks when it happens. >> >> r263091, r266800, and r272695 together on 10.0-RELENG works for me. >> >> I didn't test r263091 by itself. >> > > I couldn't get a kernel to boot without crashing with the single patch, > (r263091) applied. With all three patches, I can also confirm that the > problem is resolved. > > And some additional info: I also experimented with using gif + IPsec > transport mode instead of enc + IPsec tunnel mode. I was hoping that > changing the configuration would work around the issue. Unfortunately, > gif + IPsec transport mode was exhibiting the same type of problems that > enc + IPsec tunnel mode was, even with a patched kernel ( pf doesn't see > the traffic on the gif interface so return traffic gets blocked for lack > of a state entry ). Since you applied r266800, you now may apply r272394. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 12:17:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A487FB52 for ; Thu, 23 Oct 2014 12:17:00 +0000 (UTC) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D7DFC81 for ; Thu, 23 Oct 2014 12:16:59 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id w7so707522lbi.37 for ; Thu, 23 Oct 2014 05:16:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version:content-transfer-encoding:content-type; bh=wyKHFyYluDGJLAFowQ+ync6fL2ntFB5yeUHGP0rOqAc=; b=I4bMeUDcpfPCnMzaIBEXdzevyvuUYm5Yn8EBnktqRf3TNM1hf5e2Ax7mQtjpn92FEC EAGx5Q+J5A3VbkgnxbkSfqbYvzXxZUsKLSOg8qFwATXrKtvzEqxbKaon5mOxCnxLrF8n +OUmM9mPsvFKxvEYcX3b3DOR/OFNjzpF8oriTnL3dj6YM+SVUx96RwOK4M0V6ZuZUydr 1UpnlioMuPumecJLaNcOY/bDoLOSzt4n1w9bhttKF7QBxQ/slJCvFtpmSYg+PGG4PtAF J8lj2EUOTwVUNGl3w+aX0Egb/mrrKRJstQVgeDgrTBD0JiGCbrHej5Tt8DNjpevTkbXe QAYA== X-Gm-Message-State: ALoCoQmTNgBG9V0D+qYGQyX4KnuMU7I+88EW4SzYzA0IjGli3735Bbc71RHUVQRqgAWPNIZcGHo5 X-Received: by 10.112.51.40 with SMTP id h8mr2904094lbo.91.1414066616998; Thu, 23 Oct 2014 05:16:56 -0700 (PDT) Received: from kde4.my.domain ([188.227.89.2]) by mx.google.com with ESMTPSA id ya10sm691908lbb.6.2014.10.23.05.16.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 05:16:56 -0700 (PDT) From: Oleg Ginzburg To: freebsd-net@freebsd.org Subject: What a reason to run /sbin/atmconfig diag list in /etc/network.subr? Date: Thu, 23 Oct 2014 16:18:39 +0400 Message-ID: <1803551.iBbKEG0GPp@kde4.my.domain> User-Agent: KMail/4.14.2 (FreeBSD/10.0-RELEASE; KDE/4.14.2; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Oct 2014 12:17:00 -0000 Getting the issue when i run a certain number of vnet-epair-jail described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194550 I could not understand why in /etc/network.subr execute atm-case from afexists() function and in particular, why we need to run /sbin/atmconfig diag list 2>/dev/null 2>&1 Can someone explain what it is used for? -- TOX ID: olevole@toxme.se (B4A584A75560D5A93DBF387FAAC56669DA18797078A46B9A9818726BEE643E52A43A6A2E3DA0) E-mail: olevole@olevole.ru XMPP/jabber: olevole@jabber.ru Voice: 199.48.133.74/1001 From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 15:11:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1B91966 for ; Thu, 23 Oct 2014 15:11:42 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5614F325 for ; Thu, 23 Oct 2014 15:11:41 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id s9NFAeA9085133; Thu, 23 Oct 2014 10:10:40 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id A9BAC1884F7; Thu, 23 Oct 2014 10:10:29 -0500 (CDT) Message-ID: <54491AA5.9060602@shrew.net> Date: Thu, 23 Oct 2014 10:11:33 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , freebsd-net@freebsd.org Subject: Re: Broken IPsec + enc +pf/ipfw References: <544535C2.9020301@shrew.net> <544566D2.40303@FreeBSD.org> <544569CF.2060905@shrew.net> <54457599.4060102@yandex.ru> <54458001.6000507@shrew.net> <544611F8.9070403@yandex.ru> <20141021160643.GB2787@1970jan1-epo.ch> <54468B43.40602@shrew.net> <20141021183919.GD2787@1970jan1-epo.ch> <54480578.6020106@shrew.net> <5448DEE8.40100@yandex.ru> In-Reply-To: <5448DEE8.40100@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Thu, 23 Oct 2014 10:10:40 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Oct 2014 15:11:42 -0000 On 10/23/2014 5:56 AM, Andrey V. Elsukov wrote: > On 22.10.2014 23:28, Matthew Grooms wrote: >> On 10/21/2014 1:39 PM, Kyle Williams wrote: >>> On Tue Oct 21 11:35:15 2014, Matthew Grooms wrote: >>>> Hey Kyle, >>>> >>>> Thanks for lending a hand. I tested a few myself last night but had no >>>> luck. This morning I received an email off list that pointed to a patch >>>> that was merged to 10 stable. It sounds promising ... >>>> >>>> Log: >>>> Merge r263091: fix mbuf flags clash that lead to failure of operation >>>> of IPSEC and packet filters. >>>> >>>> https://lists.freebsd.org/pipermail/svn-src-stable-10/2014-March/001111.html >>>> >>>> >>>> I won't have a chance to try it until after business hours tonight, but >>>> will report back to the list with my results. Alternately, I assume you >>>> also could upgrade to 10.1-RC2 as the MFC for this patch happened back >>>> in March. I may go this route myself and then bump up to RELEASE in a >>>> few weeks when it happens. >>> >>> r263091, r266800, and r272695 together on 10.0-RELENG works for me. >>> >>> I didn't test r263091 by itself. >>> >> >> I couldn't get a kernel to boot without crashing with the single patch, >> (r263091) applied. With all three patches, I can also confirm that the >> problem is resolved. >> >> And some additional info: I also experimented with using gif + IPsec >> transport mode instead of enc + IPsec tunnel mode. I was hoping that >> changing the configuration would work around the issue. Unfortunately, >> gif + IPsec transport mode was exhibiting the same type of problems that >> enc + IPsec tunnel mode was, even with a patched kernel ( pf doesn't see >> the traffic on the gif interface so return traffic gets blocked for lack >> of a state entry ). > > Since you applied r266800, you now may apply r272394. > I see. Thanks for your work and the information. I reverted back to using enc + tunnel mode, so I don't need the gif support at the moment. I was just just reporting feedback since I thought it may be useful to someone that stumbles across the thread in the future. Out of curiosity, will/have all these bug fixes be applied to the 10.x branch? It's pretty painful to use as a pf firewall w/ IPsec in it's current state ( 10.0-RELEASE ). -Matthew From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 18:08:15 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E582D382 for ; Thu, 23 Oct 2014 18:08:15 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id CD076A0B for ; Thu, 23 Oct 2014 18:08:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9NI8FvL080532 for ; Thu, 23 Oct 2014 18:08:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 183659] [tcp] TCP stack lock contention with short-lived connections Date: Thu, 23 Oct 2014 18:08:16 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 23 Oct 2014 18:08:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs MFC |In Discussion CC| |jhb@FreeBSD.org --- Comment #7 from John Baldwin --- Further refinements to the original patch are currently in review. Those will need to go in before this is merged to 10. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 18:08:41 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF60C46C for ; Thu, 23 Oct 2014 18:08:41 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id B71D9A16 for ; Thu, 23 Oct 2014 18:08:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9NI8f8w099168 for ; Thu, 23 Oct 2014 18:08:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 183659] [tcp] TCP stack lock contention with short-lived connections Date: Thu, 23 Oct 2014 18:08:41 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhb@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: jch@freebsd.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 23 Oct 2014 18:08:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 John Baldwin changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |jch@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 21:12:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD099396; Thu, 23 Oct 2014 21:12:46 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5304B1C7; Thu, 23 Oct 2014 21:12:46 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so2961819wid.16 for ; Thu, 23 Oct 2014 14:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OwRDfsZqnKitZgnojANMw5tjW7+OoTvS3QmCT3qo4VE=; b=xxVEMCzqxbJfF2+IvbOw1L0JivHaftyA914EDBeA/+FEWQeF19zJpCSFjF1uCDbVfg f4yLhy78LLVj39kLUY1WzypHy/+7dTa4sC6bW85/I6DxaEjaDuvUoBDuYkcue0xwg2/y q16c2GDvdcJhedM/xk3nJ4Zi2ZyKWjUJosVQzBXNdoJgWFhEGEhlIviSvZKSUXd6LwtY X6Jzj+X43YI3KBLJ5OQJlDwStVzeKLW4SKxirC1Gz5+hBQ9GdtuqCAJyncC5g+Gl1yyG Bd/9BsPqOPiGXHehAM462L6pSaCOO3jyHwV/2TipQqPPluiuiPMneqZHrfVpb5bOmPOh Gcqg== MIME-Version: 1.0 X-Received: by 10.180.187.130 with SMTP id fs2mr711853wic.24.1414098764548; Thu, 23 Oct 2014 14:12:44 -0700 (PDT) Received: by 10.217.67.201 with HTTP; Thu, 23 Oct 2014 14:12:44 -0700 (PDT) In-Reply-To: <1569387.ZCJSvuukWl@ralph.baldwin.cx> References: <1410203348.1343.1.camel@bruno> <201410161523.32415.jhb@freebsd.org> <1569387.ZCJSvuukWl@ralph.baldwin.cx> Date: Thu, 23 Oct 2014 14:12:44 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 23 Oct 2014 21:12:47 -0000 On Sat, Oct 18, 2014 at 4:42 AM, John Baldwin wrote: > On Friday, October 17, 2014 11:32:13 PM Jason Wolfe wrote: >> Producing 10G of random traffic against a server with this assertion >> added took about 2 hours to panic, so if it turns out we need anything >> further it should be pretty quick. >> >> #4 list >> 2816 * timer and remember to restart (more output or persist). >> 2817 * If there is more data to be acked, restart retransmit >> 2818 * timer, using current (possibly backed-off) value. >> 2819 */ >> 2820 if (th->th_ack == tp->snd_max) { >> 2821 tcp_timer_activate(tp, TT_REXMT, 0); >> 2822 needoutput = 1; >> 2823 } else if (!tcp_timer_active(tp, TT_PERSIST)) >> 2824 tcp_timer_activate(tp, TT_REXMT, tp->t_rxtcur); > > Bah, this is just a bug in my assertion. Rather than having a separate > tcp_timer_deactivate() routine, a delta of 0 passed to tcp_timer_activate() > means "stop the timer". My assertions were incorrect and need to exclude the > stop case. Here is an updated patch (or you can just fix yours locally): > > Index: tcp_timer.c > =================================================================== > --- tcp_timer.c (revision 273219) > +++ tcp_timer.c (working copy) > @@ -869,10 +869,16 @@ tcp_timer_activate(struct tcpcb *tp, int timer_typ > case TT_REXMT: > t_callout = &tp->t_timers->tt_rexmt; > f_callout = tcp_timer_rexmt; > + if (callout_active(&tp->t_timers->tt_persist) && > + delta != 0) > + panic("scheduling retransmit with persist active"); > break; > case TT_PERSIST: > t_callout = &tp->t_timers->tt_persist; > f_callout = tcp_timer_persist; > + if (callout_active(&tp->t_timers->tt_rexmt) && > + delta != 0) > + panic("scheduling persist with retransmit active"); > break; > case TT_KEEP: > t_callout = &tp->t_timers->tt_keep; > > > -- > John Baldwin John, panic: tcp_setpersist: retransmit pending (kgdb) bt #0 doadump (textdump=1) at pcpu.h:219 #1 0xffffffff806facb1 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0xffffffff806fb014 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0xffffffff808467d3 in tcp_setpersist (tp=) at /usr/src/sys/netinet/tcp_output.c:1619 #4 0xffffffff8084e7b6 in tcp_timer_persist (xtp=0xfffff804ec124c00) at /usr/src/sys/netinet/tcp_timer.c:467 #5 0xffffffff8070d95e in softclock_call_cc (c=0xfffff804ec124ec0, cc=0xffffffff81263380, direct=0) at /usr/src/sys/kern/kern_timeout.c:687 #6 0xffffffff8070dce4 in softclock (arg=) at /usr/src/sys/kern/kern_timeout.c:816 #7 0xffffffff806d16f3 in intr_event_execute_handlers (p=, ie=0xfffff80015214400) at /usr/src/sys/kern/kern_intr.c:1263 #8 0xffffffff806d2056 in ithread_loop (arg=0xfffff800151f7ee0) at /usr/src/sys/kern/kern_intr.c:1276 #9 0xffffffff806cf481 in fork_exit (callout=0xffffffff806d1fc0 , arg=0xfffff800151f7ee0, frame=0xfffffe1f9e9b0ac0) at /usr/src/sys/kern/kern_fork.c:996 #10 0xffffffff80a67c0e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 (kgdb) frame 3 #3 0xffffffff808467d3 in tcp_setpersist (tp=) at /usr/src/sys/netinet/tcp_output.c:1619 1619 panic("tcp_setpersist: retransmit pending"); (kgdb) list 1614 int t = ((tp->t_srtt >> 2) + tp->t_rttvar) >> 1; 1615 int tt; 1616 1617 tp->t_flags &= ~TF_PREVVALID; 1618 if (tcp_timer_active(tp, TT_REXMT)) 1619 panic("tcp_setpersist: retransmit pending"); 1620 /* 1621 * Start/restart persistance timer. 1622 */ 1623 TCPT_RANGESET(tt, t * tcp_backoff[tp->t_rxtshift], (kgdb) up #4 0xffffffff8084e7b6 in tcp_timer_persist (xtp=0xfffff804ec124c00) at /usr/src/sys/netinet/tcp_timer.c:467 467 tcp_setpersist(tp); (kgdb) list 462 (ticks - tp->t_rcvtime) >= TCPTV_PERSMAX) { 463 TCPSTAT_INC(tcps_persistdrop); 464 tp = tcp_drop(tp, ETIMEDOUT); 465 goto out; 466 } 467 tcp_setpersist(tp); 468 tp->t_flags |= TF_FORCEDATA; 469 (void) tcp_output(tp); 470 tp->t_flags &= ~TF_FORCEDATA; Jason From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 22:26:07 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3641C2FB for ; Thu, 23 Oct 2014 22:26:07 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 1E08EB07 for ; Thu, 23 Oct 2014 22:26:07 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9NMQ6n1053311 for ; Thu, 23 Oct 2014 22:26:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Thu, 23 Oct 2014 22:26:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RC2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 23 Oct 2014 22:26:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 ncrogers@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|9.2-STABLE |10.1-RC2 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 23 22:50:41 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72DBEC3A for ; Thu, 23 Oct 2014 22:50:41 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 59D05DB7 for ; Thu, 23 Oct 2014 22:50:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9NMofmS003349 for ; Thu, 23 Oct 2014 22:50:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27 Date: Thu, 23 Oct 2014 22:50:41 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 23 Oct 2014 22:50:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #148084|0 |1 is obsolete| | --- Comment #4 from Eric Joyner --- Created attachment 148597 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148597&action=edit Patch for the core code -- ixgbe.[ch], ixv.[ch], ixgbe_osdep.h -- 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 Thu Oct 23 22:51:46 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E151CD7 for ; Thu, 23 Oct 2014 22:51:46 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 54ED8DCD for ; Thu, 23 Oct 2014 22:51:46 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9NMpkIL014334 for ; Thu, 23 Oct 2014 22:51:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27 Date: Thu, 23 Oct 2014 22:51:46 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit 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.18-1 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, 23 Oct 2014 22:51:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #148085|0 |1 is obsolete| | --- Comment #5 from Eric Joyner --- Created attachment 148598 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148598&action=edit Patch for the shared code -- every other non-core source file -- 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 Thu Oct 23 22:53:14 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46DF5D8D for ; Thu, 23 Oct 2014 22:53:14 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 2E6BADEE for ; Thu, 23 Oct 2014 22:53:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9NMrE7Q031210 for ; Thu, 23 Oct 2014 22:53:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27 Date: Thu, 23 Oct 2014 22:53:14 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 23 Oct 2014 22:53:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 --- Comment #6 from Eric Joyner --- I've attached two updated patches, in svn diff format. The shared code patch is just a more recent version of the previous one I submitted; still more updates to prepare for support for new adapters. The v2 core code patch adds a new change -- I moved ether_ifdetach() up in ixgbe_attach(), and removed the clearing of IFF_UP since the move solved that issue. -- 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 Thu Oct 23 23:04:11 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4CCCF6C for ; Thu, 23 Oct 2014 23:04:11 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id AC469EE4 for ; Thu, 23 Oct 2014 23:04:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9NN4BNX081494 for ; Thu, 23 Oct 2014 23:04:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27 Date: Thu, 23 Oct 2014 23:04:11 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 23 Oct 2014 23:04:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian@freebsd.org --- Comment #7 from Adrian Chadd --- Ok, I'll take a look at it tonight/tomorrow and give it some basic testing. Thanks! -adrian -- 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 Fri Oct 24 05:27:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72AFDB22 for ; Fri, 24 Oct 2014 05:27:01 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BE99843 for ; Fri, 24 Oct 2014 05:27:00 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id ex7so340553wid.0 for ; Thu, 23 Oct 2014 22:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=lp1g4YD/6cXwu8V+0h9QIFGfyJBYzSgKTLEnxgcVWVM=; b=hs1SMwWShS0r1SmqGxmVUIWUBVJJRJIsmcayU6BU+eMi5netrz8xglbvPOyXLVmiLE JD84D/47dDwtGEgsYqaJGHq0o8EpTZDzx1avfaeElKpgOUXsGC9E9QXH2Hmz+Exfuli3 c/K7CU2tjFR+ieA5MN0hQKxDglnHkY6Aaaovk68LUTkrAMHUazwyk7iJIa+HGykdZLHC CFgrHjz3+3RebZs/r15SOOt4B5V/8UhImls7HWKb7OQRRqykzFvdS3VPu8Wd4N07B83+ WFpzIOBZ4ATtUSAG4PtFD18Ume7SyxTMekcNrElfNkWxqlpXlfgAfF72ZDEt2ICFPe9y gVpw== X-Received: by 10.180.83.37 with SMTP id n5mr1605184wiy.7.1414128419282; Thu, 23 Oct 2014 22:26:59 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id wt3sm4333773wjb.40.2014.10.23.22.26.58 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 23 Oct 2014 22:26:58 -0700 (PDT) Date: Fri, 24 Oct 2014 07:26:56 +0200 From: Mateusz Guzik To: freebsd-net@freebsd.org Subject: nd6_timer vs Giant vs locking in general Message-ID: <20141024052656.GG11222@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Oct 2014 05:27:01 -0000 Hello there, dtrace revealed that the kernel schedules nd6_timer a lot. Not only that, his callout is not mpsafe so the kernel locks Giant which I believe is an oversight. Also the code looks really suspicious as it walks V_in6_ifaddrhead without any locking (not to mention there is an interestng comment: XXXRW: in6_ifaddrhead locking :>) Dropping it here in case there is someone interested in fixing this up. -- Mateusz Guzik From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 09:33:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6717112D for ; Fri, 24 Oct 2014 09:33:30 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C8C1209 for ; Fri, 24 Oct 2014 09:33:30 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XhXFK-000D0J-Nc; Fri, 24 Oct 2014 09:17:06 +0400 Message-ID: <544A1C7C.8090005@FreeBSD.org> Date: Fri, 24 Oct 2014 13:31:40 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Mateusz Guzik , freebsd-net@freebsd.org Subject: Re: nd6_timer vs Giant vs locking in general References: <20141024052656.GG11222@dft-labs.eu> In-Reply-To: <20141024052656.GG11222@dft-labs.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Oct 2014 09:33:30 -0000 On 24.10.2014 09:26, Mateusz Guzik wrote: > Hello there, > > dtrace revealed that the kernel schedules nd6_timer a lot. Not only > that, his callout is not mpsafe so the kernel locks Giant which I > believe is an oversight. > > Also the code looks really suspicious as it walks V_in6_ifaddrhead > without any locking (not to mention there is an interestng comment: > XXXRW: in6_ifaddrhead locking :>) Yes, I'm going to fix some issues there after writing proper API. ND changes are in https://reviews.freebsd.org/D903 . > > Dropping it here in case there is someone interested in fixing this up. > From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 11:12:17 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BF2F9BD for ; Fri, 24 Oct 2014 11:12:17 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C408166 for ; Fri, 24 Oct 2014 11:12:17 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id em10so911402wid.13 for ; Fri, 24 Oct 2014 04:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kMwHYIm21meHUtNiKFqlLaHX9G5d0wBRaQnLAazsgvQ=; b=AxNEw/QwEl6Kn9As8U4Xh0AoeNpTgPyWRCbQLw910ktqCdRtETNH5qTpuwwlZMvBBJ secXKT37H2wDua/nCxTsLNk6ao895a9uQY7gxCcDUFDSiXi9I3En/cOkDFO8zVTd4iP4 VUyzYQ2hLmVuzFWPZYMialVH/ao+0PESmbwVXv/764WYlNombuenaAMLPNFHlqDrcpJx End+9ftY3uAx5e+s0TX3hERDuX4NnYrxs7Ilc6t7QTSHwEVA27Ek4sGttU6ua9N1vZh+ zC6pZER0alaiBWYKu5nq1XeK+sOGZ/zlEqR91Gy9P8B+cURx4RA/dwUmhvZ1iCHf6nqJ uqIQ== MIME-Version: 1.0 X-Received: by 10.180.21.163 with SMTP id w3mr3384908wie.48.1414149135531; Fri, 24 Oct 2014 04:12:15 -0700 (PDT) Received: by 10.194.51.164 with HTTP; Fri, 24 Oct 2014 04:12:15 -0700 (PDT) Date: Fri, 24 Oct 2014 11:12:15 +0000 Message-ID: Subject: Is it needed to install netmap-libpcap in FreeBSD 10.1? From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Oct 2014 11:12:17 -0000 Hi all, Someone knows if is it needed to install netmap-libpcap in FreeBSD 10.1 or is libpcap already patched to use with netmap in a default FreeBSD 10.1 installation? Thanks. From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 15:41:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE95D921 for ; Fri, 24 Oct 2014 15:41:07 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6397639 for ; Fri, 24 Oct 2014 15:41:07 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id z10so1651827pdj.15 for ; Fri, 24 Oct 2014 08:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=BgbVE6TbOJr6+5DOj5ZnUZBSy1LTe3GvOemOL75WlAE=; b=XOsGeY97IfDCsL6fVceVGzt2Z/uacMoU9CpOpnppXlB6yLhrTWxrXN6ZXoajtikNhD QRDPLLuSyE+UDA3Nh/PfWNAwqIuMUVvfRbjdRh8ytceNUtxkY+xPkDdIj1wlBC89Q8uO rpXH9ZVUEUpBDOhSFqgK5/2xuK9olfa6vhHvrKsV3U6vpvIsxdUqP4dDPCpi2bAfOGgL +yzROT91Y0ZjgAfl5DWhLKD8nN1xiv3/+ZSADMQ/g4WPXTJheVLSpgVFwQa/PK8cXhxN KGI7JZoRH7tyfVMINHCc9jgvTQ33LHNZ/tSJUm9ay1AdmKpSg2oXP7wqIEBOkMbNaQ4v e0CA== X-Received: by 10.70.61.202 with SMTP id s10mr5528118pdr.124.1414165267185; Fri, 24 Oct 2014 08:41:07 -0700 (PDT) Received: from [192.168.1.118] ([221.232.46.201]) by mx.google.com with ESMTPSA id hm1sm4164886pdb.84.2014.10.24.08.41.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 08:41:06 -0700 (PDT) Message-ID: <544A730B.3060408@gmail.com> Date: Fri, 24 Oct 2014 23:40:59 +0800 From: k simon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: in-kernel nat event log Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Oct 2014 15:41:08 -0000 Hi,lists, I would like to use ipfw in-kernel nat or ng_nat to replace my current iptalbe/netfilter nat. Netfilter provides an application called ulogd2 do export netfilter's conntrack record , does FBSD have similar solutions ? Regards Simon From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 16:56:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19C3EA25 for ; Fri, 24 Oct 2014 16:56:38 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EBF2EE97 for ; Fri, 24 Oct 2014 16:56:37 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-234-114.lns20.per1.internode.on.net [121.45.234.114]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9OGuXe2076122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Oct 2014 09:56:36 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <544A84BC.5000602@freebsd.org> Date: Sat, 25 Oct 2014 00:56:28 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: javocado , freebsd-net@freebsd.org Subject: Re: ipfw command freezes system References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Oct 2014 16:56:38 -0000 On 10/23/14, 7:41 AM, javocado wrote: > I'm seeing an occasional, recurring problem on my 8.3-RELEASE amd64 systems > where when I enter an ipfw rule, the system becomes locked up. > > For example, when entering a command like this: > > ipfw add 1 allow ip from x.x.x.x to me > > or other times with a command like: > > ipfw add xxx skipto ........ be careful of making packet loops. especially with skiptos , state and pipes. depending on the settings of the sysctls that control reinjection behaviour. > the server becomes unreachable via the network. I am however still able to > get to a shell via console where I ran top: > > last pid: 25518; load averages: 0.75, 1.12, 0.93 up 4+00:13:02 > 13:55:34 > 221 processes: 1 running, 215 sleeping, 5 lock > CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > Mem: 486M Active, 40G Inact, 174G Wired, 24M Cache, 24G Buf, 18G Free > Swap: 32G Total, 32G Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 25518 root 1 44 0 9372K 2768K CPU12 12 0:00 0.10% top > 79561 xxxx 1 46 0 35284K 13424K *IPFW 12 271:00 0.00% sshd > 79564 xxxx 1 45 0 156M 16808K select 0 65:08 0.00% rsync > 22311 xxxx 1 44 0 27092K 4676K select 4 13:23 0.00% sshd > 13056 xxxx 1 44 0 27092K 4720K select 0 12:13 0.00% sshd > 43625 xxxx 1 45 0 29140K 6924K select 5 10:25 0.00% sshd > 18925 xxxx 1 44 0 27092K 4640K select 8 10:08 0.00% sshd > 14423 xxxx 1 44 0 29140K 6328K select 3 7:59 0.00% sshd > 11356 xxxx 1 44 0 12992K 2544K select 2 7:52 0.00% > sftp-server > 20619 xxxx 1 44 0 116M 101M select 5 6:25 0.00% rsync > 98406 xxxx 1 44 0 29140K 7136K select 2 6:09 0.00% sshd > 20617 xxxx 1 44 0 35284K 12992K *IPFW 15 6:03 0.00% sshd > 54146 xxxx 1 44 0 27092K 4556K select 3 5:04 0.00% sshd > 63688 xxxx 1 44 0 27092K 5728K select 16 4:07 0.00% sshd > 20624 xxxx 1 44 0 156M 102M select 0 3:45 0.00% rsync > 43629 xxxx 1 44 0 5832K 2084K select 0 3:41 0.00% rsync > > Note those "*IPFW" state processes are long running child sshd processes, > not master sshd daemon itself. > > I've tried to do an ipfw flush in these situations before but those > commands never return and the system just stays locked up and unreachable. > > I was able to issue a reboot from the console, but even that did not > complete: > > Oct 21 13:56:53 xxxx reboot: rebooted by root > Oct 21 13:56:54 xxxx syslogd: exiting on signal 15 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop... > > and I had to reset. > > Here's the ipfw ruleset in place: > > 00110 count ip from any to any via igb0 in > 00111 count ip from any to any via igb0 out > 00210 skipto 410 ip from x.x.x.x/27,x.x.x.x/29,x.x.x.x/24,x.x.x.x/28 to me > 00210 skipto 410 ip from me to > x.x.x.x/27,x.x.x.x/29,x.x.x.x/24,x.x.x.x/28 > 00211 skipto 410 ip from x.x.x.x/24 to me > 00211 skipto 410 ip from me to x.x.x.x/24 > 00212 skipto 410 ip from x.x.x.x/24 to me > 00212 skipto 410 ip from me to x.x.x.x/24 > 00214 skipto 410 ip from x.x.x.x,x.x.x.x to me > 00214 skipto 410 ip from me to x.x.x.x,x.x.x.x > 00218 skipto 410 ip from x.x.x.x to me > 00218 skipto 410 ip from me to x.x.x.x > 00219 skipto 410 ip from x.x.x.x to me > 00219 skipto 410 ip from me to x.x.x.x > 00225 skipto 410 ip from x.x.x.x to me > 00225 skipto 410 ip from me to x.x.x.x > 00226 skipto 410 ip from x.x.x.x to me > 00226 skipto 410 ip from me to x.x.x.x > 00227 skipto 410 ip from x.x.x.x to me skipto tablearg maybe? instead of N rules also, separate all incoming and outgoing packets to diffent sets of rules.. e.g. send all incoming to 10000 and outgoing to 20000 the way you are doing it all packets look at all rules. > 00227 skipto 410 ip from me to x.x.x.x > 00310 pipe 5 ip from me to x.x.x.x > 00310 pipe 5 ip from x.x.x.x to me > 00311 skipto 410 ip from me to x.x.x.x > 00311 skipto 410 ip from x.x.x.x to me > 00312 pipe 1 ip from any to me > 00313 pipe 2 ip from any to me ummm 2 pipes for the same packets? > 00314 pipe 3 ip from me to any > 00315 pipe 4 ip from me to any once again... in and out should be separated. > 00410 allow tcp from any to any established > 00411 allow icmp from any to any icmptypes 0,3,8,11 > 00420 deny icmp from any to any > 00430 allow ip from any to any via lo0 > 00510 deny ip from any to 127.0.0.0/8 > 00511 deny ip from 127.0.0.0/8 to any > 00512 deny ip from 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 to any table > 00513 deny ip from any to 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 table > 00514 deny ip from > 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to > any > 00515 deny ip from any to > 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 > 00610 deny tcp from any to any tcpflags syn tcpoptions !mss table > 00611 deny tcp from any to any tcpflags syn,fin > 00612 deny tcp from any to any tcpflags fin,psh,rst,urg > 00613 deny tcp from any to any tcpflags fin,psh,urg > 00614 deny tcp from any to any tcpflags syn,fin,ack,rst > 00615 deny tcp from any to any tcpflags !syn,!fin,!ack > 01010 allow udp from me to any dst-port 53 > 01011 allow udp from x.x.x.x,x.x.x.x 53 to me > 01012 allow udp from any to me dst-port 33433-33499 > 01020 allow tcp from any to x.x.x.x dst-port 21,22,62000-64000 setup > 65000 deny log logamount 1000 ip from any to me > 65001 deny log logamount 1000 ip from any to me6 > 65535 allow ip from any to any > > # ipfw pipe list > 00001: 200.000 Mbit/s 0 ms burst 0 > q131073 50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 > droptail > sched 65537 type FIFO flags 0x0 0 buckets 1 active > 0 ip 0.0.0.0/0 0.0.0.0/0 10 15000 0 0 0 > > 00002: 32.000 Mbit/s 0 ms burst 0 > q131074 50 sl. 0 flows (1 buckets) sched 65538 weight 0 lmax 0 pri 0 > droptail > sched 65538 type FIFO flags 0x1 64 buckets 10 active > mask: 0x00 0xffffffff/0x0000 -> 0x00000000/0x0000 > 0 > 00003: 100.000 Mbit/s 0 ms burst 0 > q131075 50 sl. 0 flows (1 buckets) sched 65539 weight 0 lmax 0 pri 0 > droptail > sched 65539 type FIFO flags 0x0 0 buckets 1 active > 0 ip 0.0.0.0/0 0.0.0.0/0 6 312 1 52 0 > > 00004: 24.000 Mbit/s 0 ms burst 0 > q131076 50 sl. 0 flows (1 buckets) sched 65540 weight 0 lmax 0 pri 0 > droptail > sched 65540 type FIFO flags 0x1 64 buckets 9 active > mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 > 0 > > 00005: 40.000 Mbit/s 0 ms burst 0 > q131077 50 sl. 0 flows (1 buckets) sched 65541 weight 0 lmax 0 pri 0 > droptail > sched 65541 type FIFO flags 0x0 0 buckets 0 active > > > What other troubleshooting or remedy should I do via console when this > happens, or perhaps is there a problem with the way we've setup our ruleset? > > Thanks for your help! > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 18:47:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BDDDC44 for ; Fri, 24 Oct 2014 18:47:01 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FF45C99 for ; Fri, 24 Oct 2014 18:47:01 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2E5DDB94C; Fri, 24 Oct 2014 14:46:57 -0400 (EDT) From: John Baldwin To: Jason Wolfe Subject: Re: ixgbe(4) spin lock held too long Date: Fri, 24 Oct 2014 14:46:20 -0400 Message-ID: <3632601.GJCTAXMEZu@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <1410203348.1343.1.camel@bruno> <1569387.ZCJSvuukWl@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 24 Oct 2014 14:46:57 -0400 (EDT) Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 24 Oct 2014 18:47:01 -0000 On Thursday, October 23, 2014 02:12:44 PM Jason Wolfe wrote: > On Sat, Oct 18, 2014 at 4:42 AM, John Baldwin wrote: > > On Friday, October 17, 2014 11:32:13 PM Jason Wolfe wrote: > >> Producing 10G of random traffic against a server with this assertion > >> added took about 2 hours to panic, so if it turns out we need anything > >> further it should be pretty quick. > >> > >> #4 list > >> 2816 * timer and remember to restart (more output or > >> persist). 2817 * If there is more data to be acked, > >> restart retransmit 2818 * timer, using current > >> (possibly backed-off) value. 2819 */ > >> 2820 if (th->th_ack == tp->snd_max) { > >> 2821 tcp_timer_activate(tp, TT_REXMT, 0); > >> 2822 needoutput = 1; > >> 2823 } else if (!tcp_timer_active(tp, TT_PERSIST)) > >> 2824 tcp_timer_activate(tp, TT_REXMT, > >> tp->t_rxtcur);> > > Bah, this is just a bug in my assertion. Rather than having a separate > > tcp_timer_deactivate() routine, a delta of 0 passed to > > tcp_timer_activate() > > means "stop the timer". My assertions were incorrect and need to exclude > > the stop case. Here is an updated patch (or you can just fix yours > > locally): > > > > Index: tcp_timer.c > > =================================================================== > > --- tcp_timer.c (revision 273219) > > +++ tcp_timer.c (working copy) > > @@ -869,10 +869,16 @@ tcp_timer_activate(struct tcpcb *tp, int timer_typ > > > > case TT_REXMT: > > t_callout = &tp->t_timers->tt_rexmt; > > f_callout = tcp_timer_rexmt; > > > > + if (callout_active(&tp->t_timers->tt_persist) && > > + delta != 0) > > + panic("scheduling retransmit with persist > > active");> > > break; > > > > case TT_PERSIST: > > t_callout = &tp->t_timers->tt_persist; > > f_callout = tcp_timer_persist; > > > > + if (callout_active(&tp->t_timers->tt_rexmt) && > > + delta != 0) > > + panic("scheduling persist with retransmit > > active");> > > break; > > > > case TT_KEEP: > > t_callout = &tp->t_timers->tt_keep; > > > > -- > > John Baldwin > > John, > > panic: tcp_setpersist: retransmit pending > > (kgdb) bt > #0 doadump (textdump=1) at pcpu.h:219 > #1 0xffffffff806facb1 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:452 > #2 0xffffffff806fb014 in panic (fmt=) at > /usr/src/sys/kern/kern_shutdown.c:759 > #3 0xffffffff808467d3 in tcp_setpersist (tp=) at > /usr/src/sys/netinet/tcp_output.c:1619 > #4 0xffffffff8084e7b6 in tcp_timer_persist (xtp=0xfffff804ec124c00) > at /usr/src/sys/netinet/tcp_timer.c:467 > #5 0xffffffff8070d95e in softclock_call_cc (c=0xfffff804ec124ec0, > cc=0xffffffff81263380, direct=0) > at /usr/src/sys/kern/kern_timeout.c:687 > #6 0xffffffff8070dce4 in softclock (arg=) at > /usr/src/sys/kern/kern_timeout.c:816 > #7 0xffffffff806d16f3 in intr_event_execute_handlers (p= optimized out>, ie=0xfffff80015214400) > at /usr/src/sys/kern/kern_intr.c:1263 > #8 0xffffffff806d2056 in ithread_loop (arg=0xfffff800151f7ee0) at > /usr/src/sys/kern/kern_intr.c:1276 > #9 0xffffffff806cf481 in fork_exit (callout=0xffffffff806d1fc0 > , arg=0xfffff800151f7ee0, > frame=0xfffffe1f9e9b0ac0) at /usr/src/sys/kern/kern_fork.c:996 > #10 0xffffffff80a67c0e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:606 > > (kgdb) frame 3 > #3 0xffffffff808467d3 in tcp_setpersist (tp=) at > /usr/src/sys/netinet/tcp_output.c:1619 > 1619 panic("tcp_setpersist: retransmit pending"); > (kgdb) list > 1614 int t = ((tp->t_srtt >> 2) + tp->t_rttvar) >> 1; > 1615 int tt; > 1616 > 1617 tp->t_flags &= ~TF_PREVVALID; > 1618 if (tcp_timer_active(tp, TT_REXMT)) > 1619 panic("tcp_setpersist: retransmit pending"); > 1620 /* > 1621 * Start/restart persistance timer. > 1622 */ > 1623 TCPT_RANGESET(tt, t * tcp_backoff[tp->t_rxtshift], > > (kgdb) up > #4 0xffffffff8084e7b6 in tcp_timer_persist (xtp=0xfffff804ec124c00) > at /usr/src/sys/netinet/tcp_timer.c:467 > 467 tcp_setpersist(tp); > (kgdb) list > 462 (ticks - tp->t_rcvtime) >= TCPTV_PERSMAX) { > 463 TCPSTAT_INC(tcps_persistdrop); > 464 tp = tcp_drop(tp, ETIMEDOUT); > 465 goto out; > 466 } > 467 tcp_setpersist(tp); > 468 tp->t_flags |= TF_FORCEDATA; > 469 (void) tcp_output(tp); > 470 tp->t_flags &= ~TF_FORCEDATA; > > Jason Weird, this is the same as before. It should have panic'd when it scheduled either one of the timers before this. Can you get a stack trace from the other threads? Perhaps the timers are being scheduled concurrently? Can you also 'set print pretty' and 'p *tp'? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 20:18:10 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51A08F6C for ; Fri, 24 Oct 2014 20:18:10 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 3901C8A2 for ; Fri, 24 Oct 2014 20:18:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9OKIAHD064889 for ; Fri, 24 Oct 2014 20:18:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second Date: Fri, 24 Oct 2014 20:18:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: boba@boba.name X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 24 Oct 2014 20:18:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #4 from boba@boba.name --- (In reply to Hiren Panchasara from comment #2) > (In reply to boba from comment #0) > > It's impossible to create "pipe" with bandwidth higher than 2Gbits per > > second. Possible due to "signed" type of variable. > > > > # ipfw pipe 1 config bw 2700mbit/s > > ipfw: bandwidth too large > > I think you are right that its overflowing because of "signed" type. > > A simple change like this may fix the problem: > > Index: dummynet.c > =================================================================== > --- dummynet.c (revision 270969) > +++ dummynet.c (working copy) > @@ -546,7 +546,7 @@ > if_name[namelen] = '\0'; > *bandwidth = 0; > } else { /* read bandwidth value */ > - int bw; > + uint32_t bw; > char *end = NULL; > > bw = strtoul(arg, &end, 0); This patch will not work at all because of following check few lines after it: if (bw < 0) errx(EX_DATAERR, "bandwidth too large"); -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 20:27:07 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F144D26B for ; Fri, 24 Oct 2014 20:27:07 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id BEC2B9A3 for ; Fri, 24 Oct 2014 20:27:07 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9OKR7nX073621 for ; Fri, 24 Oct 2014 20:27:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second Date: Fri, 24 Oct 2014 20:27:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 24 Oct 2014 20:27:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #5 from Hiren Panchasara --- (In reply to boba from comment #4) > (In reply to Hiren Panchasara from comment #2) > > (In reply to boba from comment #0) > > > It's impossible to create "pipe" with bandwidth higher than 2Gbits per > > > second. Possible due to "signed" type of variable. > > > > > > # ipfw pipe 1 config bw 2700mbit/s > > > ipfw: bandwidth too large > > > > I think you are right that its overflowing because of "signed" type. > > > > A simple change like this may fix the problem: > > > > Index: dummynet.c > > =================================================================== > > --- dummynet.c (revision 270969) > > +++ dummynet.c (working copy) > > @@ -546,7 +546,7 @@ > > if_name[namelen] = '\0'; > > *bandwidth = 0; > > } else { /* read bandwidth value */ > > - int bw; > > + uint32_t bw; > > char *end = NULL; > > > > bw = strtoul(arg, &end, 0); > > This patch will not work at all because of following check few lines after > it: > > if (bw < 0) > errx(EX_DATAERR, "bandwidth too large"); This patch is incomplete. But the check above is needed exactly for the reason of catching overflowing values. Afaik, a couple of things need to be done to make the patch complete: 1) make sure whatever datatype we use for bandwidth is uniform across entire dummynet codebase. i.e. in struct dn_link inside netinet/ip_dummynet.h 2) It currently only handles Mb/s and b/s and not Gb/s while setting bandwidth. If someone else doesn't beat me to it, I'll try to spend some time next week on this. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 22:15:29 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22897C2D for ; Fri, 24 Oct 2014 22:15:29 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id 0936E6CC for ; Fri, 24 Oct 2014 22:15:29 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9OMFStD046656 for ; Fri, 24 Oct 2014 22:15:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second Date: Fri, 24 Oct 2014 22:15:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rizzo@iet.unipi.it X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 24 Oct 2014 22:15:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 rizzo@iet.unipi.it changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rizzo@iet.unipi.it --- Comment #6 from rizzo@iet.unipi.it --- (In reply to Hiren Panchasara from comment #5) > (In reply to boba from comment #4) > > (In reply to Hiren Panchasara from comment #2) > > > (In reply to boba from comment #0) > > > > It's impossible to create "pipe" with bandwidth higher than 2Gbits per > > > > second. Possible due to "signed" type of variable. > > > > > > > > # ipfw pipe 1 config bw 2700mbit/s > > > > ipfw: bandwidth too large > > > > > > I think you are right that its overflowing because of "signed" type. > > > > > > A simple change like this may fix the problem: > > > > > > Index: dummynet.c > > > =================================================================== > > > --- dummynet.c (revision 270969) > > > +++ dummynet.c (working copy) > > > @@ -546,7 +546,7 @@ > > > if_name[namelen] = '\0'; > > > *bandwidth = 0; > > > } else { /* read bandwidth value */ > > > - int bw; > > > + uint32_t bw; > > > char *end = NULL; > > > > > > bw = strtoul(arg, &end, 0); > > > > This patch will not work at all because of following check few lines after > > it: > > > > if (bw < 0) > > errx(EX_DATAERR, "bandwidth too large"); > > This patch is incomplete. But the check above is needed exactly for the > reason of catching overflowing values. > > Afaik, a couple of things need to be done to make the patch complete: > 1) make sure whatever datatype we use for bandwidth is uniform across entire > dummynet codebase. i.e. in struct dn_link inside netinet/ip_dummynet.h > > 2) It currently only handles Mb/s and b/s and not Gb/s while setting > bandwidth. > > If someone else doesn't beat me to it, I'll try to spend some time next week > on this. I think it is a waste of time to work on just extending the input range unless one revises the internals so that dummynet can do shaping with reasonable accuracy in the Gbit/s range. By that i mean the following: First of all change the internals of dummynet to opportunistically check the timer whenever there is traffic, rather than relying on a one-tick granularity. When dummynet was first implemented the timer was the 8254, reading it took forever, and 250-1000us granularity was adequate for the <10Mbit/s range it was meant to emulate. Second, the default parameters (1ms, 50 slots queue) limit the capacity of a pipe to some 600 Mbit/s with 1500-byte packets. Probably the code should print warnings if queue_capacity/tick is too far from the desired rate. Third, the bandwidth value is internally multiplied by other factor in the execution of the scheduling algorithms. If you bump the data type from 31 to 32 or 64 bits, you also need to check that the other computations do not overflow. In any case if you decide to go through this route please pass the code by me for review before committing. -- luigi -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 22:36:29 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 096512DC for ; Fri, 24 Oct 2014 22:36:29 +0000 (UTC) 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 mx1.freebsd.org (Postfix) with ESMTPS id DEFB591D for ; Fri, 24 Oct 2014 22:36:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9OMaSTe094572 for ; Fri, 24 Oct 2014 22:36:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second Date: Fri, 24 Oct 2014 22:36:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hiren@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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.18-1 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, 24 Oct 2014 22:36:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #7 from Hiren Panchasara --- (In reply to rizzo from comment #6) > (In reply to Hiren Panchasara from comment #5) > > (In reply to boba from comment #4) > > > (In reply to Hiren Panchasara from comment #2) > > > > (In reply to boba from comment #0) > > > > > It's impossible to create "pipe" with bandwidth higher than 2Gbits per > > > > > second. Possible due to "signed" type of variable. > > > > > > > > > > # ipfw pipe 1 config bw 2700mbit/s > > > > > ipfw: bandwidth too large > > > > > > > > I think you are right that its overflowing because of "signed" type. > > > > > > > > A simple change like this may fix the problem: > > > > > > > > Index: dummynet.c > > > > =================================================================== > > > > --- dummynet.c (revision 270969) > > > > +++ dummynet.c (working copy) > > > > @@ -546,7 +546,7 @@ > > > > if_name[namelen] = '\0'; > > > > *bandwidth = 0; > > > > } else { /* read bandwidth value */ > > > > - int bw; > > > > + uint32_t bw; > > > > char *end = NULL; > > > > > > > > bw = strtoul(arg, &end, 0); > > > > > > This patch will not work at all because of following check few lines after > > > it: > > > > > > if (bw < 0) > > > errx(EX_DATAERR, "bandwidth too large"); > > > > This patch is incomplete. But the check above is needed exactly for the > > reason of catching overflowing values. > > > > Afaik, a couple of things need to be done to make the patch complete: > > 1) make sure whatever datatype we use for bandwidth is uniform across entire > > dummynet codebase. i.e. in struct dn_link inside netinet/ip_dummynet.h > > > > 2) It currently only handles Mb/s and b/s and not Gb/s while setting > > bandwidth. > > > > If someone else doesn't beat me to it, I'll try to spend some time next week > > on this. > > I think it is a waste of time to work on just extending the input range > unless one revises the internals so that dummynet can do shaping > with reasonable accuracy in the Gbit/s range. Thanks a lot for stopping me before I waste much time on it and come up with a wrong fix. Appreciate all the details you provided. I do not have bandwidth to look into a proper fix right now. cheers, Hiren -- You are receiving this mail because: You are the assignee for the bug.