From owner-freebsd-net@freebsd.org Sun Dec 24 02:06:11 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA61FE8CFA6 for ; Sun, 24 Dec 2017 02:06:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C54F329AC for ; Sun, 24 Dec 2017 02:06:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBO26BvN029034 for ; Sun, 24 Dec 2017 02:06:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 224371] vxlan leaks memory Date: Sun, 24 Dec 2017 02:06:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 24 Dec 2017 02:06:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224371 --- Comment #2 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Sun Dec 24 02:05:19 UTC 2017 New revision: 327141 URL: https://svnweb.freebsd.org/changeset/base/327141 Log: MFC r326898: Fix possible memory leak. vxlan_ftable entries are sorted in descending order, due to wrong argum= ents order it is possible to stop search before existing element will be fou= nd. Then new element will be allocated in vxlan_ftable_update_locked() and = can be inserted in the list second time or trigger MPASS() assertion with enabled INVARIANTS. PR: 224371 Changes: _U stable/11/ stable/11/sys/net/if_vxlan.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 24 02:07:14 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA989E8D07E for ; Sun, 24 Dec 2017 02:07:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C956D2AC0 for ; Sun, 24 Dec 2017 02:07:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBO27ElN030749 for ; Sun, 24 Dec 2017 02:07:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 224371] vxlan leaks memory Date: Sun, 24 Dec 2017 02:07:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 24 Dec 2017 02:07:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224371 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Sun Dec 24 02:06:17 UTC 2017 New revision: 327142 URL: https://svnweb.freebsd.org/changeset/base/327142 Log: MFC r326898: Fix possible memory leak. vxlan_ftable entries are sorted in descending order, due to wrong argum= ents order it is possible to stop search before existing element will be fou= nd. Then new element will be allocated in vxlan_ftable_update_locked() and = can be inserted in the list second time or trigger MPASS() assertion with enabled INVARIANTS. PR: 224371 Changes: _U stable/10/ stable/10/sys/net/if_vxlan.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Dec 24 02:07:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A70BDE8D090 for ; Sun, 24 Dec 2017 02:07:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92A132AC3 for ; Sun, 24 Dec 2017 02:07:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBO27Ro6031132 for ; Sun, 24 Dec 2017 02:07:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 224371] vxlan leaks memory Date: Sun, 24 Dec 2017 02:07: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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution cc bug_status assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 24 Dec 2017 02:07:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224371 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |ae@FreeBSD.org Status|New |Closed Assignee|freebsd-net@FreeBSD.org |ae@FreeBSD.org --- Comment #4 from Andrey V. Elsukov --- Fixed in head/, stable/11 and stable/10. Thanks! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Dec 25 11:34:57 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2603E852AE for ; Mon, 25 Dec 2017 11:34:57 +0000 (UTC) (envelope-from menyy@mellanox.com) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00040.outbound.protection.outlook.com [40.107.0.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 495E113BC for ; Mon, 25 Dec 2017 11:34:55 +0000 (UTC) (envelope-from menyy@mellanox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DDRQbDt24eFGfMPOv5ixzinAnnez3EzN+3XSnqwdIIc=; b=OBU9HFL0MAOvTKMcYkVxQIfPMZBUI24Vx+vj3rbgaZQaBi2CwERb5yJPusVgtpjvrFR29XCZKgY8X5Fd7ywkrMFFCdQG02ew6FmgwXtkkNkqeTk8pezzm97GCwKoe146oSd2yUtBrru4BrpeTOpkPUC8x1aESyr8FdpJpfOjfGE= Received: from VI1PR0501MB2863.eurprd05.prod.outlook.com (10.172.12.8) by VI1PR0501MB2591.eurprd05.prod.outlook.com (10.168.137.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.14; Mon, 25 Dec 2017 11:34:52 +0000 Received: from VI1PR0501MB2863.eurprd05.prod.outlook.com ([fe80::d65:824:64e3:9602]) by VI1PR0501MB2863.eurprd05.prod.outlook.com ([fe80::d65:824:64e3:9602%18]) with mapi id 15.20.0345.016; Mon, 25 Dec 2017 11:34:52 +0000 From: Meny Yossefi To: "freebsd-net@FreeBSD.org" CC: Konstantin Belousov , Hans Petter Selasky , Slava Shwartsman , Matthew Finlay Subject: Setting priority per flow Thread-Topic: Setting priority per flow Thread-Index: AdN9XHjyTAaPViC/Sn2rJ3WzUNBQqg== Date: Mon, 25 Dec 2017 11:34:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=menyy@mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0501MB2591; 6:jl4OjyAWSsYA+UgpJx0wBziQn3k7H2PHqoHCcnbxycfaVKZhYMerKiY5JHA3YTfPLKHRonQwjBibwIjJznpF2iVsyT1ksXnuCaTusiadzqq61Ok4sZBBPTYywfVEap2eXPhLVLS6Jjhna/B1RJX43nCkAB1QeOTqmMwhX1wRipjME9o4aueOjUySx0yDzoAEDigCJ59Gauv2509nol0LcugG8RE3sAutJdrzHZN/V1J6prpqXLfDG6VAAkvWJqgi64cjO+rxRtXeUfW6wqv31nnGo/ZHSdx8YIaXxiVMEEV5B6tSSQkVhsPCdvCwASbWUCxgQS4IcwU0eDTisWLjBxAm+RTw1TYnuEA2N2v4qdSbtXTau+rPl395EFhHED9r; 5:7wPzs8b3yJ8OBLe6R6bZeLLta6ihbB0kdUX08VPclBc5mfqm4i9hPG+E1Vi/aBux61cJDsyFU9roVxBt6cPUaDN0WyIel9GdBd6mqEMeRl47SnuUkWBjreamoypC5a6GI95djaW4hyjOBdIA4TWCh5j9WUl4JQeboKOc6K/A/s8=; 24:gixOgidb28rsIbrOSxhtVkgU0pF7lqI2yp9Cb6k6okv8eusJKQkg6VwAFG+m5oORSuCkoSWmYU4Rpa1aQO2gDIlzUeyZ4t5JRuD2oonzEJw=; 7:OCfgXU66qIXt6867gL4F+elR3D0pEWe4BM6GsZWBSV0l9WNcus9SinZwXF7r9DVPP2zgVS3oBwgrmGkqTqabY72AghL3vNb2hMc688WsgidnSAq42g909u/Bc5ZscIWly0n9tgGhFLKari4oVvZ3WBLtUZpEJ6aarqz71DoQ8TJ4pnxEhqdf9tjoFWCfCK73DZb982ahxU/jTfZGkUsjRUhdp5f7B4eo0K88T2U3YE7a9Fnasymi8PB561jQkCFp x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-ms-office365-filtering-correlation-id: 19e819da-7675-4475-ecfa-08d54b8b83b1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(48565401081)(2017052603307)(7153060); SRVR:VI1PR0501MB2591; x-ms-traffictypediagnostic: VI1PR0501MB2591: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231023)(944501075)(93006095)(93001095)(6055026)(6041268)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0501MB2591; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR0501MB2591; x-forefront-prvs: 0532BF6DC2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(366004)(376002)(396003)(346002)(53754006)(51874003)(189003)(199004)(5250100002)(106356001)(105586002)(2351001)(33656002)(68736007)(86362001)(2501003)(2900100001)(9686003)(55016002)(66066001)(5640700003)(3846002)(6116002)(5660300001)(81156014)(99286004)(81166006)(74316002)(7696005)(6436002)(6916009)(7736002)(107886003)(478600001)(305945005)(25786009)(97736004)(14454004)(8936002)(3480700004)(2906002)(8676002)(53936002)(6506007)(3660700001)(102836004)(3280700002)(54906003)(4326008)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0501MB2591; H:VI1PR0501MB2863.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: eYBZLjUIDXdAfLcqjuFCJ/yebcq5Nn9wyJayq2I8w97EWbLGUe1RP+N46hJe+/tov+PsQeDD+WqrZVHDu2YxSA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19e819da-7675-4475-ecfa-08d54b8b83b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Dec 2017 11:34:52.3556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2591 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 25 Dec 2017 11:34:57 -0000 Hi all, I'd like to set priority per flow in FreeBSD for PFC use. In Linux, I can do so using a socket option (SO_PRIORITY) which eventually = will be mapped into the PCP bits in the VLAN tag. Is there a FreeBSD equivalent? So far I could only find an 'ifconfig' optio= n to set PCP ('vlanpcp'), but that's only per VLAN interface, not a specifi= c flow. Also, is there a way to configure prio-tagging (priority over VLAN ID 0)? I= t seems that setting VLAN with ID 0 is not permitted:=20 sys/net/if_vlan.c, vlan_config() lines 1418: /* * Don't let the caller set up a VLAN VID with * anything except VLID bits. * VID numbers 0x0 and 0xFFF are reserved. */ if (vid =3D=3D 0 || vid =3D=3D 0xFFF || (vid & ~EVL_VLID_MASK)) return (EINVAL); Nothing on the receive side suggests this case is being handled as well. I Would appreciate an elaborated answer in case I'm missing something here. Thanks in advance, Meny From owner-freebsd-net@freebsd.org Tue Dec 26 04:43:51 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E67BE9FB6E for ; Tue, 26 Dec 2017 04:43:51 +0000 (UTC) (envelope-from harsh@chelsio.com) Received: from stargate.chelsio.com (stargate.chelsio.com [12.32.117.8]) (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 F36BF646F5 for ; Tue, 26 Dec 2017 04:43:50 +0000 (UTC) (envelope-from harsh@chelsio.com) Received: from [10.193.189.121] (harsh.asicdesigners.com [10.193.189.121]) by stargate.chelsio.com (8.13.8/8.13.8) with ESMTP id vBQ4hjUp010107; Mon, 25 Dec 2017 20:43:46 -0800 To: freebsd-net@freebsd.org From: Harsh Jain Subject: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled Cc: harsh@chelsio.com Message-ID: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> Date: Tue, 26 Dec 2017 10:13:44 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Dec 2017 04:43:51 -0000 Hi All, If I try to run ping of size say 6000 in IPSec transport mode, m_unshare() panic with following trace. It seems that while re-assembly of IP packet "ip_reass" missed re-setting of "M_PKTHDR".  After applying below patch things work fine. Can some one suggest Is it a BUG or I am missing somethings. panic: m_unshare: m0 0xfffff80020f82600, m 0xfffff8005d054100 has M_PKTHDR cpuid = 15 time = 1495578455 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfffffe044e9bb890 kdb_backtrace() at kdb_backtrace+0x53/frame 0xfffffe044e9bb960 vpanic() at vpanic+0x269/frame 0xfffffe044e9bba30 kassert_panic() at kassert_panic+0xc7/frame 0xfffffe044e9bbac0 m_unshare() at m_unshare+0x578/frame 0xfffffe044e9bbbc0 esp_output() at esp_output+0x44c/frame 0xfffffe044e9bbe40 ipsec4_perform_request() at ipsec4_perform_request+0x5df/frame 0xfffffe044e9bbff0 Patch to fix diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index bf5e209ad3b..c9044652ba2 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -21,7 +21,7 @@  cpu            HAMMER  ident          GENERIC -makeoptions    DEBUG=-g                # Build kernel with gdb(1) debug symbols +makeoptions    DEBUG="-g -O0"          # Build kernel with gdb(1) debug symbols  makeoptions    WITH_CTF=1              # Run ctfconvert(1) for DTrace support  options        SCHED_ULE               # ULE scheduler diff --git a/sys/netinet/ip_reass.c b/sys/netinet/ip_reass.c index fbf9c176956..c6755c99f72 100644 --- a/sys/netinet/ip_reass.c +++ b/sys/netinet/ip_reass.c @@ -247,6 +247,7 @@ ip_reass(struct mbuf *m)                 goto done;         } else {                 fp->ipq_nfrags++; +               m->m_flags &= ~M_PKTHDR;  #ifdef MAC                 mac_ipq_update(m, fp);  #endif Thanks & Regards Harsh Jain From owner-freebsd-net@freebsd.org Tue Dec 26 09:55:42 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56569E815C8 for ; Tue, 26 Dec 2017 09:55:42 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward101o.mail.yandex.net (forward101o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCB5A6D2EE for ; Tue, 26 Dec 2017 09:55:41 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback5o.mail.yandex.net (mxback5o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1f]) by forward101o.mail.yandex.net (Yandex) with ESMTP id 3E4AD13418A3; Tue, 26 Dec 2017 12:55:29 +0300 (MSK) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [2a02:6b8:0:1a2d::26]) by mxback5o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 2JB01pu6GR-tMbiZqU5; Tue, 26 Dec 2017 12:55:23 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1514282123; bh=f6eIt9pESZzbXDZHeD6Cy6YbQn8m3Xvf1l8exVlxWV8=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=Xpx5l4e8OT7+5zKwxwxtOUJndluP02m3ldHkCHECZzHakR9c/nPl+A2ry/Ew0pOwR Ba/f4qEDFmHNZ1qLEfNc7EbDL94vDYxrYEc2qMTv3hJd/BmdEsfMVgfqkkliOVfblq I1vGgAEAdHexev2irgqH6UZDK3n8R7VkI0bua2ms= Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id qd9z8lOUyW-tMu0PRsf; Tue, 26 Dec 2017 12:55:22 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1514282122; bh=f6eIt9pESZzbXDZHeD6Cy6YbQn8m3Xvf1l8exVlxWV8=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=IyV+Uo6DtbgTnz05QNetazuEZfosH2ThbJexwfuUQv/VNSRkmEhuQB3JDM9Ll9j5V DC/aIcJSrnK0DJ8gKCVQzppx1L7Ov274abSJNR2kVBgddXVVaVhUIjK3yLbsWdb+Z7 qNDnzLthqine5uSkLZiB+9U6Ytpf2c6E0YxueFVY= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled To: Harsh Jain , freebsd-net@freebsd.org References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> Date: Tue, 26 Dec 2017 12:52:34 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="giudNWLMnbHfGdEAqIVvhWbiDTvOIjcC9" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Dec 2017 09:55:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --giudNWLMnbHfGdEAqIVvhWbiDTvOIjcC9 Content-Type: multipart/mixed; boundary="cdUnNoLdFC1fNs7dmKTdNXiod0W9CeqdP"; protected-headers="v1" From: "Andrey V. Elsukov" To: Harsh Jain , freebsd-net@freebsd.org Message-ID: <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> In-Reply-To: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> --cdUnNoLdFC1fNs7dmKTdNXiod0W9CeqdP Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 26.12.2017 07:43, Harsh Jain wrote: > Hi All, >=20 > If I try to run ping of size say 6000 in IPSec transport mode, m_unshar= e() panic with following trace. It seems that while re-assembly of IP pac= ket "ip_reass" missed re-setting of "M_PKTHDR". After applying below pat= ch things work fine. Can some one suggest Is it a BUG or I am missing som= ethings. >=20 > panic: m_unshare: m0 0xfffff80020f82600, m 0xfffff8005d054100 has M_PKT= HDR > cpuid =3D 15 > time =3D 1495578455 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfffffe044= e9bb890 > kdb_backtrace() at kdb_backtrace+0x53/frame 0xfffffe044e9bb960 > vpanic() at vpanic+0x269/frame 0xfffffe044e9bba30 > kassert_panic() at kassert_panic+0xc7/frame 0xfffffe044e9bbac0 > m_unshare() at m_unshare+0x578/frame 0xfffffe044e9bbbc0 > esp_output() at esp_output+0x44c/frame 0xfffffe044e9bbe40 > ipsec4_perform_request() at ipsec4_perform_request+0x5df/frame 0xfffffe= 044e9bbff0 Hi, it seems unusual that IP reassembly happens on outbound path. Do you have some packet normalization using firewall? --=20 WBR, Andrey V. Elsukov --cdUnNoLdFC1fNs7dmKTdNXiod0W9CeqdP-- --giudNWLMnbHfGdEAqIVvhWbiDTvOIjcC9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlpCG+IACgkQAcXqBBDI oXpoUwgAoyNBFvmFW2bgLl6Xx9krr38ZQ7Iz9m1CE3n+uOvpBjTSd5xeh54xFyOd zqwas/0C4OCTZTo7+QOJ4SeUAUxwQiZEEzpvZHkisjWb7E1gxiCREGAFexLgJ1DP B2RTJzw7+oHlFEItk0MiluW4PAIl8KvtbJTrdKec2VgTbsy+pMYSNx5v62o5K6/6 evvKMjc2Hu3VVUBQYcVh6yO9+fJ33Z4judyyF78vsS6tsuMv0rgyGpaTjT6OFp8Y qf6i0w11ALivMj/UUryFly6yk1xMsyguuo1EvmkmpAqC7udhrhUqSJB/dM45eS+/ 6iP9xRLP1RDfLA/c7OEZeiof2CL/1Q== =iB3v -----END PGP SIGNATURE----- --giudNWLMnbHfGdEAqIVvhWbiDTvOIjcC9-- From owner-freebsd-net@freebsd.org Tue Dec 26 10:22:46 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 485D3E8305C for ; Tue, 26 Dec 2017 10:22:46 +0000 (UTC) (envelope-from harsh@chelsio.com) Received: from stargate.chelsio.com (stargate.chelsio.com [12.32.117.8]) (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 372BE6E56E for ; Tue, 26 Dec 2017 10:22:45 +0000 (UTC) (envelope-from harsh@chelsio.com) Received: from [10.193.189.121] (harsh.asicdesigners.com [10.193.189.121]) by stargate.chelsio.com (8.13.8/8.13.8) with ESMTP id vBQAMhUE012031; Tue, 26 Dec 2017 02:22:44 -0800 Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled To: "Andrey V. Elsukov" , freebsd-net@freebsd.org References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> From: Harsh Jain Message-ID: Date: Tue, 26 Dec 2017 15:52:42 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Dec 2017 10:22:46 -0000 On 26-12-2017 15:22, Andrey V. Elsukov wrote: > On 26.12.2017 07:43, Harsh Jain wrote: >> Hi All, >> >> If I try to run ping of size say 6000 in IPSec transport mode, m_unshare() panic with following trace. It seems that while re-assembly of IP packet "ip_reass" missed re-setting of "M_PKTHDR". After applying below patch things work fine. Can some one suggest Is it a BUG or I am missing somethings. >> >> panic: m_unshare: m0 0xfffff80020f82600, m 0xfffff8005d054100 has M_PKTHDR >> cpuid = 15 >> time = 1495578455 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfffffe044e9bb890 >> kdb_backtrace() at kdb_backtrace+0x53/frame 0xfffffe044e9bb960 >> vpanic() at vpanic+0x269/frame 0xfffffe044e9bba30 >> kassert_panic() at kassert_panic+0xc7/frame 0xfffffe044e9bbac0 >> m_unshare() at m_unshare+0x578/frame 0xfffffe044e9bbbc0 >> esp_output() at esp_output+0x44c/frame 0xfffffe044e9bbe40 >> ipsec4_perform_request() at ipsec4_perform_request+0x5df/frame 0xfffffe044e9bbff0 > Hi, > > it seems unusual that IP reassembly happens on outbound path. It can be re-produced with single Ping packet on chelsio(cxgbe) NIC. I tried with Intel NIC. It seems they re-produce M_WRITEABLE() buffer(follows different path in m_unshare) which is not true for cxgbe. > Do you have some packet normalization using firewall? Default FREEBSD current installation. No explicit firewall. What you think above patch makes sense. > From owner-freebsd-net@freebsd.org Tue Dec 26 10:44:02 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F740E84504 for ; Tue, 26 Dec 2017 10:44:02 +0000 (UTC) (envelope-from reply@west-art.net) Received: from west-art.net (west-art.net [162.144.110.111]) (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 466BC6F1FB for ; Tue, 26 Dec 2017 10:44:02 +0000 (UTC) (envelope-from reply@west-art.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=west-art.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:List-Unsubscribe:Message-ID:Subject:Reply-To:From:To:Date:Sender :Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yvMI2DNxUuY8EQagGY2ftVhkcGmjtJxwrRPfqTdyQfg=; b=lcRb1dmQLHc/H5aoRNjth/FlC0 elTkFWQgIBviuu6s/0yY5O9SOyuBWgDMSBzowVVaZf7hJ4o3ME12Ou60xV3VGwnhMa/wjUJ6SXwiX BnC3EOLDmYFdPmmekEs8bSdYT8UOCybIp068FLPx7ngRiY+i8sZSJ9aum4f1alaoCW2pHFpSAi+8n nwCTLirgIQQ2D4uKHjOCzPW3ZfX8nfky/y+8ZPuOUPAtKL6Ezd8tDtoEtWYosR/ws+rtiDClUCiqc HufWiAz7sjbs+m0bVwV7N5qw5289cuiLK/YOZFAxAi0YhW8t3B0gILOCKaUZlPLtHeMnCTTrEKFCb ot7mZzHg==; Received: from westartn by server.west-art.net with local (Exim 4.89_1) (envelope-from ) id 1eTmi5-00029r-3F for freebsd-net@freebsd.org; Tue, 26 Dec 2017 12:43:49 +0200 Date: Tue, 26 Dec 2017 10:43:40 +0000 To: freebsd-net@freebsd.org From: Benefis Company Reply-To: crisstianciubuc@gmail.com Subject: Dear Friends, our discount offer will continue till the end on this month! Message-ID: <18b1bbd0d2c0be5d7f381c281ddecccd@massmail.benefistutu.com> X-Mailer: Mailster 2.2.14 (5.2.22) X-Mailster: 6f82520695a80b7fb9638ba982630bbb X-Mailster-Campaign: 296 X-Mailster-ID: 34695d011f7794251628561f772eda6d X-Message-ID: <5a4227e5146d5-6f82520695a80b7fb9638ba982630bbb-296-34695d011f7794251628561f772eda6d@massmail.benefistutu.com> MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.west-art.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [500 500] / [47 12] X-AntiAbuse: Sender Address Domain - west-art.net X-Get-Message-Sender-Via: server.west-art.net: authenticated_id: westartn/sender_address_domain X-Authenticated-Sender: server.west-art.net: reply@west-art.net X-Source: /usr/bin/php X-Source-Args: /usr/bin/php X-Source-Dir: west-art.net:/public_html/massmail Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Dec 2017 10:44:02 -0000 [1] [2] Dear Friends, our discount offer will continue till the end on this month! [3] Get a Beautiful, Professional Ballet Costume for all you performances in the upcoming new year at a 15% discount! Also DON'T FORGET ABOUT OUR E-GIFT CARD - THE BEST GIFT OPTION FOR ANY OCCASION! [4] [facebook] [5] [instagram] [6] [pinterest] [7] [twitter] [8] [linkedin] [9] [youtube] [10] UNSUBSCRIBE! [11] Benefis Co. 1995-2017 [MailerLite] [12] Links: ------ [1] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cDovL2JlbmVmaXNzaG9wLmNvbS8_bD1lbiZhbXA7YT1kZXRhaWxzJmFtcDtpPTExNzYz [2] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly9iZW5lZmlzdHV0dS5jb20v [3] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly9iZW5lZmlzdHV0dS5jb20v/1 [4] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly9iZW5lZmlzdHV0dS5jb20vaW5kZXgucGhwP3JvdXRlPWluZm9ybWF0aW9uL2luZm9ybWF0aW9uJmFtcDtpbmZvcm1hdGlvbl9pZD0xOQ [5] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL0JlbmVmaXMtQmFsbGV0LUNvc3R1bWVzLTEyMTc2ODAzNDgzNzcxMS8 [6] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly93d3cuaW5zdGFncmFtLmNvbS90ZXJlbnRpZXZhOTgxNi8 [7] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly93d3cucGludGVyZXN0LmNvbS9iYmFsbGV0Y29zdHVtZXMv [8] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly90d2l0dGVyLmNvbS9iZW5lZmlzc2hvcA [9] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL2JlbmVmaXNzaG9wY29tLw [10] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly93d3cueW91dHViZS5jb20vdXNlci9CZW5lZmlzc2hvcA [11] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly9iZW5lZmlzdHV0dS5jb20vdW5zdWJzY3JpYmUvdW5zdWJzY3JpYmUuaHRtbA [12] https://massmail.benefistutu.com/mailster/296/6f82520695a80b7fb9638ba982630bbb/aHR0cHM6Ly93d3cubWFpbGVybGl0ZS5jb20 From owner-freebsd-net@freebsd.org Tue Dec 26 11:36:02 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2119E87230 for ; Tue, 26 Dec 2017 11:36:02 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward104j.mail.yandex.net (forward104j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 730A87130A for ; Tue, 26 Dec 2017 11:36:02 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback20j.mail.yandex.net (mxback20j.mail.yandex.net [IPv6:2a02:6b8:0:1619::114]) by forward104j.mail.yandex.net (Yandex) with ESMTP id 74E5E4111B; Tue, 26 Dec 2017 14:35:59 +0300 (MSK) Received: from smtp4j.mail.yandex.net (smtp4j.mail.yandex.net [2a02:6b8:0:1619::15:6]) by mxback20j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Q5lWXZPsKI-ZxYiYY2Z; Tue, 26 Dec 2017 14:35:59 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1514288159; bh=gJ/Gy2SCeU90i24913+aQNKi0om+cjUZcZKClhTQtDo=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=ERDwMJ0Iw+KdlWWMz5E4jchi899LuXlWWSqAAUSDuhhnYh2u8D/mdcucqSgjeS6Fx dS1LtSHVUaj72ZsB4bRahpQGycgKWKII2s17jiMNElB6iD0G9uFUdAGiRwFjkUysLL iXfLS6xv4azgZqC3/l1ee/RakAhYuYa+qyYZ0M+4= Received: by smtp4j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id LT5bzeAmOe-Zwx4R7oc; Tue, 26 Dec 2017 14:35:58 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1514288158; bh=gJ/Gy2SCeU90i24913+aQNKi0om+cjUZcZKClhTQtDo=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=oyZzsC4BvtDANyfR9CmtQ1w4Y/Iz9ThJ5J0buKogWJu3jtITEQsOvpNc9jEm02+dT zkyRvxAxXZmEoxvOiHrTmDkwxeF35PmJCW4kq5EX90MQNDlomSJd2nuhSTEIuBz4uC 9TKR5VpSaKEWMG17vZBK8Nb1DQxHURXFm5I18B/Q= Authentication-Results: smtp4j.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled To: Harsh Jain , freebsd-net@freebsd.org References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: Date: Tue, 26 Dec 2017 14:33:04 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WUp1Gkiol6r8GwihO60R2BQFxQ43xhLLL" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 26 Dec 2017 11:36:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WUp1Gkiol6r8GwihO60R2BQFxQ43xhLLL Content-Type: multipart/mixed; boundary="LXau3uXE3xeG2wKXx8OV7wRRdsfm6Kn9U"; protected-headers="v1" From: "Andrey V. Elsukov" To: Harsh Jain , freebsd-net@freebsd.org Message-ID: Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> In-Reply-To: --LXau3uXE3xeG2wKXx8OV7wRRdsfm6Kn9U Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 26.12.2017 13:22, Harsh Jain wrote: >>> panic: m_unshare: m0 0xfffff80020f82600, m 0xfffff8005d054100 has M_P= KTHDR >>> cpuid =3D 15 >>> time =3D 1495578455 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfffffe0= 44e9bb890 >>> kdb_backtrace() at kdb_backtrace+0x53/frame 0xfffffe044e9bb960 >>> vpanic() at vpanic+0x269/frame 0xfffffe044e9bba30 >>> kassert_panic() at kassert_panic+0xc7/frame 0xfffffe044e9bbac0 >>> m_unshare() at m_unshare+0x578/frame 0xfffffe044e9bbbc0 >>> esp_output() at esp_output+0x44c/frame 0xfffffe044e9bbe40 >>> ipsec4_perform_request() at ipsec4_perform_request+0x5df/frame 0xffff= fe044e9bbff0 >> Hi, >> >> it seems unusual that IP reassembly happens on outbound path. > It can be re-produced with single Ping packet on chelsio(cxgbe) NIC. I = tried with Intel NIC. It seems they re-produce M_WRITEABLE() buffer(follo= ws different path in m_unshare) which is not true for cxgbe. In my view, IP fragmentation should occur in ip_output after IPsec encryption. Something like: 1. rip_output() has mbuf chain where only first mbuf has M_PKTHDR flag 2. ip_output() -> IPSEC_OUTPUT() -> esp_output() -> m_unshare(). We should still have only one mbuf with M_PKTHDR flag here. 3. esp_output_cb() -> ipsec_process_done() -> ip_output() 4. Now IP fragmentation should occur: ip_fragment() creates chain of mbufs to send, where M_PKTHDR flag will be set for each fragment. >> Do you have some packet normalization using firewall? > Default FREEBSD current installation. No explicit firewall. > What you think above patch makes sense. It is not clear to me why it helps. The panic happens on outbound path, where mbuf should be allocated by network stack and should be writeable. ip_reass() usually used on inbound path. I think the patch just hides the problem in another place. Do you mean that cxgbe can produce !WRITEABLE mbuf for received packet and then pass it to the network stack? --=20 WBR, Andrey V. Elsukov --LXau3uXE3xeG2wKXx8OV7wRRdsfm6Kn9U-- --WUp1Gkiol6r8GwihO60R2BQFxQ43xhLLL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlpCM3EACgkQAcXqBBDI oXoKSQf+LOnwK7M78ZKfmidNEe+2Fzk4fW6KmlNRWNq2nc9n9qGz0wY3sPTx40u/ nj/oOfstoIPjJdQ31iFSLwLFW18beb85ysd9UJlDORlfVNS+DZHV5wCFOmG5u9jj SHEGF5OY2TrA8ek3XaBwRs6pl+eG7h1poupdSgR8FNO1567onqeKXegydstIsNwT n2Q/LpJ2vd49eHigHB+C2qzt+GQGbBNiY8Iw+hdpQsSDR86HthJTlkPY06UPNHyu PrPRa838TI+BSpw1oe76SQ6mhFLPjz0zN9uRSahYtSoUhHnGrSpbKG332CwOHrsX btptPf1wiidsLBpZeXjqEsELw91QaQ== =Inge -----END PGP SIGNATURE----- --WUp1Gkiol6r8GwihO60R2BQFxQ43xhLLL-- From owner-freebsd-net@freebsd.org Wed Dec 27 15:32:30 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B642AE9603B for ; Wed, 27 Dec 2017 15:32:30 +0000 (UTC) (envelope-from julian@freebsd.org) 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 99D5D69BED for ; Wed, 27 Dec 2017 15:32:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBRFWMsM002215 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Dec 2017 07:32:27 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help To: John Lyon , Harry Schmalzbauer Cc: freebsd-net@freebsd.org, Eugene Grosbein References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> From: Julian Elischer Message-ID: <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> Date: Wed, 27 Dec 2017 23:32:16 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Dec 2017 15:32:30 -0000 John did you get a resolution to this issue? On 16/12/17 2:59 am, John Lyon wrote: > Harry and Eugene (and others), > > I appreciate all of your help. It's been really insightful. Although I > feel like I'm getting much closer to the solution, I don't think my problem > has been diagnosed. I've outlined my thought process below. Can you > please tell me if I am misunderstanding something? Admittedly, I am not a > kernel developer and my C language skills have atrophied the last few > years. However, I've reviewed my script and I looked in the code for > ng_etf.c and I don't think I am violating any of the requirements for > linking a hook for no match. > > As Eugene stated: > >>> 1) referenced "matchook" exists and you should not use "indirect name" > here, >>> only hook own name, or else you get error ENOENT (No such file or > directory); > > This does not seem to be a problem as the upper and lower hooks for the em1 > already exist (I can confirm this). > >>> 2) referenced "matchook" is *not* downstream hook, or else you get error >>> EINVAL (Invalid argument); > I read the ng_etf.c file in the source tree and found this little snippet: > > /* and is not the downstream hook */ > if (hook == etfp->downstream_hook.hook) { > error = EINVAL; > break; > } > > This appears to be an error check to make sure you are not creating a cycle > in the graph by referencing the ETF node's own downstream hook (i.e. > filtering incoming traffic and circularly feeding non-matching frames back > into the ETF's own filter). I'm not doing this. I am feeding non-matching > packets into the *lower* hook of another ether node and not back into the > *downstream* hook of the etf node I am creating. As a result, my netgraph > should not be triggering this error condition. > >>> 3) it was not already configured, or else you get error EEXIST (File > exists). > > I am not getting this error, so it appears not to be an issue in my case. > > What am I missing here? The man page states that "*any other *hook" can be > used for the non-matching packets. So the man page says this should work, > and there's no explicit error condition that I see (caveat, I have not > written in C for at least 10 years - PEBKAC is entirely possible) that > would be triggered in the ng_etf code. So what is going wrong? > > Thanks for all of your help, patience, and understanding. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer > wrote: > >> Bezüglich Eugene Grosbein's Nachricht vom 14.12.2017 23:07 (localtime): >>> 15.12.2017 4:27, John Lyon wrote: >>> >>>>>> I'm a new Netgraph user, but am having some problems with a simple >>>>>> Netgraph >>>>>> script I have written. Unfortunately, the error message is cryptic >> and I >>>>>> can't tell what I am doing wrong since my script closely follows the >>>>>> example provided in the ng_etf man page. >>>>>> >>>>>> For some context, I'm trying to filter EAP traffic coming in on my LAN >>>>>> interface. Any ethernet frames that correspond to EAP traffic need >> to be >>>>>> immediately forwarded from the LAN interface to my WAN interface. All >>>>>> other ethernet frames coming in on my LAN interface need to be >> handled by >>>>>> the kernel's network stack. A (horrid) ASCII art representation of my >>>>>> desired netgraph would look like this: >>>>>> >>>>>> lower -> em0 -> downstream -> ETF -> no match -> upper em0 >>>>>> -> match -> >>>>>> lower em1 >>>>>> >>>>>> The script I have written is this: >>>>>> >>>>>> #! /bin/sh >>>>>> ngctl mkpeer em0: etf lower downstream >>>>>> ngctl name em0:lower lan_filter >>>>>> ngctl connect em0: lan_filter: upper nomatch >>>>>> ngctl msg lan_filter: setfilter { matchhook="em1:lower" >>>>>> ethertype=0x888e } >>>>>> >>>>>> Unfortunately, the last line of my script generates the following >> error >>>>>> message: >>>>>> >>>>>> ngctl: send msg: Invalid Argument >>> For "setfilter" command to work, ng_etf requires that: >>> >>> 1) referenced "matchook" exists and you should not use "indirect name" >> here, >>> only hook own name, or else you get error ENOENT (No such file or >> directory); >>> 2) referenced "matchook" is *not* downstream hook, or else you get error >>> EINVAL (Invalid argument); >>> 3) it was not already configured, or else you get error EEXIST (File >> exists). >> >> Eugene kindly looked into the code and found that the error is due to >> wrong matchhook definition. >> I've never had any contact with ng_etf yet, but according to the man >> page, you need to set the (additional) filter hook by 'nghook -a >> lan_filter: mydrain' and use 'matchhook=mydrain' for the 'msg' command. >> >> Do idea about the intention, so for the rest you have to tweak as needed. >> >> -harry >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@freebsd.org Wed Dec 27 17:37:51 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B9D0EA33FE for ; Wed, 27 Dec 2017 17:37:51 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 931FE6E9EA; Wed, 27 Dec 2017 17:37:50 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id i11so40298172wmf.4; Wed, 27 Dec 2017 09:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FK9rcfAA8k6cwnzxaiY/LM75kqNJAmXAGTgFPwvLuYo=; b=UMECy+QK14DtpsqYHeyJdaD4oT3fnDkS5QtrJVtq7FYY3nmx/pfjEWrxRUI8gRZCK6 KSHurVFBgyMhyngiJhBIy4N6l+do4aWTvMldCsAU1QdwBfIAslRo7VviZDia/s8lh5IU oMc5iPuOgq9F3ZIexj+lleHVNSViznmL/FVNjjjAiCmUcJSZ23egpzbZzFo0FhcXjTik kMo97JOGbY9gMH1KZo/N77DjuMogsGqCprsteZhijQK/i5MTrwU3wuXg5RwRVX5mtCNU MMXwdBKcbZebLJmp0rnRa8nTNFDWRTKd5GmDSZZmqHji8Gmiv0K9Nk/Hk4c7FuHeyGqr EexQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FK9rcfAA8k6cwnzxaiY/LM75kqNJAmXAGTgFPwvLuYo=; b=litih4XVtzM5km186gI5eecOBLEWdo+Acj++eIHfs7pjYFS2NALRnY6kW7XR98Jwg1 ZEQrPINwW/7TtB7M6qAF2G1OZiY8KKGxAFkNJMDANGtwyMROIQQvpvmDo/LbkKMHDf4x QADBqd3svcSERyzEkEFISHVLqQbocY1K+Ohoc6ttfrIhP6hwbKowt8PefZNsgo0KPiSp 8ok7ZSqD4PBZs8UShYZQiKG27QBWdRpPAtITbA/8ACXtIZ7M9EaZ6UeihCvcrZyEKbdp LU3XoqKP5OXaiT3AlYNcKK0d0+1VcgbbCO78suhUf3d+G4iPXWIxoJ9yUxTZeG6wKbzD NyeA== X-Gm-Message-State: AKGB3mIxGhzHjCEIyYU36FhaGqy5kK9VKNwpVPa8IP/WlUgQankfRM3f zkZknTQAFCe8jJhnNvJouT2LgjyK9svUaG6pEueVLw== X-Google-Smtp-Source: ACJfBosqqjgg5KrEngKPrkQFSSn0Jrlk7caTofe1ajgdNuXqe2VWOlIBwN746oFcRU5/fdtVxMYB3wTtQmeZk4jDz4A= X-Received: by 10.80.184.52 with SMTP id j49mr35635180ede.160.1514396268342; Wed, 27 Dec 2017 09:37:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Wed, 27 Dec 2017 09:37:27 -0800 (PST) In-Reply-To: <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> From: John Lyon Date: Wed, 27 Dec 2017 12:37:27 -0500 Message-ID: Subject: Re: Need Netgraph Help To: Julian Elischer Cc: Harry Schmalzbauer , freebsd-net@freebsd.org, Eugene Grosbein Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Dec 2017 17:37:51 -0000 Julian, Unfortunately, this issue remains unresolved. I would like to think that this is just a PEBKAC issue, but I have tried every permutation of escape characters in case it's an issue with my syntax and I get the same set of errors. No matter what I do, I can't connect the no match hook of an ETF node to the upper hook of an ng_ether node. Do you have any insights into why this might be occurring? By the way, thanks for reaching out to me! I was going to email you directly after the holidays since your name and email address are at the bottom of the relevant Netgraph man pages. I figured that must mean if you didn't know the answer, no one does. :-) Thanks. -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer wrote: > John did you get a resolution to this issue? > > > On 16/12/17 2:59 am, John Lyon wrote: > >> Harry and Eugene (and others), >> >> I appreciate all of your help. It's been really insightful. Although I >> feel like I'm getting much closer to the solution, I don't think my >> problem >> has been diagnosed. I've outlined my thought process below. Can you >> please tell me if I am misunderstanding something? Admittedly, I am not= a >> kernel developer and my C language skills have atrophied the last few >> years. However, I've reviewed my script and I looked in the code for >> ng_etf.c and I don't think I am violating any of the requirements for >> linking a hook for no match. >> >> As Eugene stated: >> >> 1) referenced "matchook" exists and you should not use "indirect name" >>>> >>> here, >> >>> only hook own name, or else you get error ENOENT (No such file or >>>> >>> directory); >> >> This does not seem to be a problem as the upper and lower hooks for the >> em1 >> already exist (I can confirm this). >> >> 2) referenced "matchook" is *not* downstream hook, or else you get error >>>> EINVAL (Invalid argument); >>>> >>> I read the ng_etf.c file in the source tree and found this little >> snippet: >> >> /* and is not the downstream hook */ >> if (hook =3D=3D etfp->downstream_hook.hook) { >> error =3D EINVAL; >> break; >> } >> >> This appears to be an error check to make sure you are not creating a >> cycle >> in the graph by referencing the ETF node's own downstream hook (i.e. >> filtering incoming traffic and circularly feeding non-matching frames ba= ck >> into the ETF's own filter). I'm not doing this. I am feeding >> non-matching >> packets into the *lower* hook of another ether node and not back into th= e >> *downstream* hook of the etf node I am creating. As a result, my netgra= ph >> should not be triggering this error condition. >> >> 3) it was not already configured, or else you get error EEXIST (File >>>> >>> exists). >> >> I am not getting this error, so it appears not to be an issue in my case= . >> >> What am I missing here? The man page states that "*any other *hook" can >> be >> >> used for the non-matching packets. So the man page says this should wor= k, >> and there's no explicit error condition that I see (caveat, I have not >> written in C for at least 10 years - PEBKAC is entirely possible) that >> would be triggered in the ng_etf code. So what is going wrong? >> >> Thanks for all of your help, patience, and understanding. >> >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >> wrote: >> >> Bez=C3=BCglich Eugene Grosbein's Nachricht vom 14.12.2017 23:07 (localti= me): >>> >>>> 15.12.2017 4:27, John Lyon wrote: >>>> >>>> I'm a new Netgraph user, but am having some problems with a simple >>>>>>> Netgraph >>>>>>> script I have written. Unfortunately, the error message is cryptic >>>>>>> >>>>>> and I >>> >>>> can't tell what I am doing wrong since my script closely follows the >>>>>>> example provided in the ng_etf man page. >>>>>>> >>>>>>> For some context, I'm trying to filter EAP traffic coming in on my >>>>>>> LAN >>>>>>> interface. Any ethernet frames that correspond to EAP traffic need >>>>>>> >>>>>> to be >>> >>>> immediately forwarded from the LAN interface to my WAN interface. All >>>>>>> other ethernet frames coming in on my LAN interface need to be >>>>>>> >>>>>> handled by >>> >>>> the kernel's network stack. A (horrid) ASCII art representation of my >>>>>>> desired netgraph would look like this: >>>>>>> >>>>>>> lower -> em0 -> downstream -> ETF -> no match -> upper em0 >>>>>>> -> matc= h >>>>>>> -> >>>>>>> lower em1 >>>>>>> >>>>>>> The script I have written is this: >>>>>>> >>>>>>> #! /bin/sh >>>>>>> ngctl mkpeer em0: etf lower downstream >>>>>>> ngctl name em0:lower lan_filter >>>>>>> ngctl connect em0: lan_filter: upper nomatch >>>>>>> ngctl msg lan_filter: setfilter { matchhook=3D"em1:lower" >>>>>>> ethertype=3D0x888e } >>>>>>> >>>>>>> Unfortunately, the last line of my script generates the following >>>>>>> >>>>>> error >>> >>>> message: >>>>>>> >>>>>>> ngctl: send msg: Invalid Argument >>>>>>> >>>>>> For "setfilter" command to work, ng_etf requires that: >>>> >>>> 1) referenced "matchook" exists and you should not use "indirect name" >>>> >>> here, >>> >>>> only hook own name, or else you get error ENOENT (No such file or >>>> >>> directory); >>> >>>> 2) referenced "matchook" is *not* downstream hook, or else you get err= or >>>> EINVAL (Invalid argument); >>>> 3) it was not already configured, or else you get error EEXIST (File >>>> >>> exists). >>> >>> Eugene kindly looked into the code and found that the error is due to >>> wrong matchhook definition. >>> I've never had any contact with ng_etf yet, but according to the man >>> page, you need to set the (additional) filter hook by 'nghook -a >>> lan_filter: mydrain' and use 'matchhook=3Dmydrain' for the 'msg' comman= d. >>> >>> Do idea about the intention, so for the rest you have to tweak as neede= d. >>> >>> -harry >>> >>> >>> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> > From owner-freebsd-net@freebsd.org Wed Dec 27 20:09:41 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5BB9EAA6A1 for ; Wed, 27 Dec 2017 20:09:41 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFEAA75DCC for ; Wed, 27 Dec 2017 20:09:41 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pg0-x235.google.com with SMTP id q12so2143439pgt.7 for ; Wed, 27 Dec 2017 12:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=r3vwxU3x+tUzwkP10lDzYctOQQ3el14GrJ/fcFfk9Hk=; b=sxiYFHFKzYpP6/Haafxbik2x8+dtcp7fgCcoQzupZ6EsL89EwozMPXisNzq4Znxufe cEEcmqomMALcOj1/PgtUh75gGpwebH6GESyMRQjRP3IDSr/kmwC24tEcnZuWDFe/OAMP njzGx0z1fiQ/r8e9ZWXrLKEMQ1pMWgwZQEqRurn0dxjpLbxfeMAc3f1eWHDM57j2RurN 8XQplUNoXPgeX0Bqu0ykKlDQsCushOCIqVotnB07Y2kabPk4TZGggKSlDw0wuL2anHgK 5o5tfLDslBV4+rA1/pzkP8ZWfprrEC8ZmRcqmOb09g/i4e7MtRNDyQVPXlPV/nLJkm5b htdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=r3vwxU3x+tUzwkP10lDzYctOQQ3el14GrJ/fcFfk9Hk=; b=NQjY8YY8rPfnrf/NpucZmssgTDuSYGCFVeEBZWu5wpxV7nVA7YcNGDB1wi3n1ZWtQa ZnW1vkkWMiMzaZU7vct7WNXQ6tzlaWViFHZHLvRVImOoRF+0xQepNfUZm28GOsDcN4AA uY4p5+Gni+2rUrF+7hsPIqsC27PI3/7dh8gIqj3N83qsYqEelTf3LZ3fqwa7YfyGR9Yr rNM22UCSLSmsIb+PEXjJnCg8REYsckRL4wnLyNdrJ8PheQb++gw+DmG+9HQwn/Degg15 9zF2xmE5L/bu5erWpoJggSBd5zRkZ510UWLtwWN/uNjWsw9LBARVBRrLNAK/BX0tCLKZ zDJw== X-Gm-Message-State: AKGB3mLB11XPm8mTY/Ng9Ox0kQtYWyvStlJ69sT4dDVTcy2vekCzV5do u7Jw/8w1RmSoLkgtDwku+mSzPA== X-Google-Smtp-Source: ACJfBovRxCUJGcjPhe8w58kjGnujUPhum4m/zctN7f1wocvn3ncOlGvGoBoa4i7ZcsRJfWi1ITsc6g== X-Received: by 10.98.33.8 with SMTP id h8mr29302981pfh.160.1514405380983; Wed, 27 Dec 2017 12:09:40 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id b8sm6468838pgt.14.2017.12.27.12.09.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 12:09:40 -0800 (PST) Sender: Navdeep Parhar Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled To: "Andrey V. Elsukov" , Harsh Jain , freebsd-net@freebsd.org References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> From: Navdeep Parhar Message-ID: Date: Wed, 27 Dec 2017 12:09:39 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Dec 2017 20:09:42 -0000 On 12/26/2017 03:33, Andrey V. Elsukov wrote: > On 26.12.2017 13:22, Harsh Jain wrote: >>>> panic: m_unshare: m0 0xfffff80020f82600, m 0xfffff8005d054100 has M_PKTHDR >>>> cpuid = 15 >>>> time = 1495578455 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfffffe044e9bb890 >>>> kdb_backtrace() at kdb_backtrace+0x53/frame 0xfffffe044e9bb960 >>>> vpanic() at vpanic+0x269/frame 0xfffffe044e9bba30 >>>> kassert_panic() at kassert_panic+0xc7/frame 0xfffffe044e9bbac0 >>>> m_unshare() at m_unshare+0x578/frame 0xfffffe044e9bbbc0 >>>> esp_output() at esp_output+0x44c/frame 0xfffffe044e9bbe40 >>>> ipsec4_perform_request() at ipsec4_perform_request+0x5df/frame 0xfffffe044e9bbff0 >>> Hi, >>> >>> it seems unusual that IP reassembly happens on outbound path. >> It can be re-produced with single Ping packet on chelsio(cxgbe) NIC. I tried with Intel NIC. It seems they re-produce M_WRITEABLE() buffer(follows different path in m_unshare) which is not true for cxgbe. > > In my view, IP fragmentation should occur in ip_output after IPsec > encryption. Something like: > > 1. rip_output() has mbuf chain where only first mbuf has M_PKTHDR flag > 2. ip_output() -> IPSEC_OUTPUT() -> esp_output() -> m_unshare(). We > should still have only one mbuf with M_PKTHDR flag here. > 3. esp_output_cb() -> ipsec_process_done() -> ip_output() > 4. Now IP fragmentation should occur: ip_fragment() creates chain of > mbufs to send, where M_PKTHDR flag will be set for each fragment. > >>> Do you have some packet normalization using firewall? >> Default FREEBSD current installation. No explicit firewall. >> What you think above patch makes sense. > > It is not clear to me why it helps. The panic happens on outbound path, > where mbuf should be allocated by network stack and should be writeable. > ip_reass() usually used on inbound path. I think the patch just hides > the problem in another place. > Do you mean that cxgbe can produce !WRITEABLE mbuf for received packet > and then pass it to the network stack? > Yes, cxgbe does that. But I think the real bug here is in ip_reass because it doesn't properly get rid of the pkthdr of the fragments while creating the reassembled datagram. cxgbe happens to trip on this easily because it often creates !WRITEABLE mbufs. This should fix it: https://people.freebsd.org/~np/ip_reass_demotehdr.diff It will also fix leaks in configurations where mbuf tags are in use by default (for example with MAC), ip_reass is involved during rx, and the mbuf chain never gets m_demote'd elsewhere (meaning ip_reass should have freed the tags itself). Regards, Navdeep From owner-freebsd-net@freebsd.org Wed Dec 27 21:05:24 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FE50EAD1C3 for ; Wed, 27 Dec 2017 21:05:24 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward105o.mail.yandex.net (forward105o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4510784BD; Wed, 27 Dec 2017 21:05:23 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback10j.mail.yandex.net (mxback10j.mail.yandex.net [IPv6:2a02:6b8:0:1619::113]) by forward105o.mail.yandex.net (Yandex) with ESMTP id 40267444345D; Thu, 28 Dec 2017 00:02:31 +0300 (MSK) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [2a02:6b8:0:1a2d::27]) by mxback10j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id EPMgVBINFL-2Ui09Co6; Thu, 28 Dec 2017 00:02:31 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1514408551; bh=ZITsc3IV6t0hoZRsE7WvnCX/gkkcjomONo/4tQy15mY=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=nlX9vSUPaYlp58lCe23XlnMD72/9or+qrqywVq9i1sCyNx++3XQLRn80GJg4ymlUz jrqTwp9OLPWy6PgGfsOHpLotNLWJrcNTs819QILKW1beo++pbPnLTGfEjt1ZPHg8L1 dte13WJEEumqJB3IYgV7IGqnxHtiGRAkZRaUGfr8= Received: by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id BWG64avJIB-2URS7KoQ; Thu, 28 Dec 2017 00:02:30 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1514408550; bh=ZITsc3IV6t0hoZRsE7WvnCX/gkkcjomONo/4tQy15mY=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=lG78gMsP6Nu92RRBGjjypjn/kpW9MWUyA9bOCo3x8cp9fHicCrgj6lYVE/VWaMB9A QzmHk7lIZf+qv2S6KY971LhaV5gCUwsst6mtVJ1HLMf0dx52Qa4KTGI3Kpg80YUVjI TWOHCCvhn5kQm66d0VZbm/AYwZmrvS7n09ui1BVc= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled To: Navdeep Parhar , Harsh Jain , freebsd-net@freebsd.org References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: Date: Wed, 27 Dec 2017 23:59:37 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4gb4mTbdfBpwBtocIOKKlUdGpAlv3kQBm" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Dec 2017 21:05:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4gb4mTbdfBpwBtocIOKKlUdGpAlv3kQBm Content-Type: multipart/mixed; boundary="qlGvXlWklCDPqffVLVvgcWBHH5qkfvQ1n"; protected-headers="v1" From: "Andrey V. Elsukov" To: Navdeep Parhar , Harsh Jain , freebsd-net@freebsd.org Message-ID: Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> In-Reply-To: --qlGvXlWklCDPqffVLVvgcWBHH5qkfvQ1n Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 27.12.2017 23:09, Navdeep Parhar wrote: >> It is not clear to me why it helps. The panic happens on outbound path= , >> where mbuf should be allocated by network stack and should be writeabl= e. >> ip_reass() usually used on inbound path. I think the patch just hides >> the problem in another place. >> Do you mean that cxgbe can produce !WRITEABLE mbuf for received packet= >> and then pass it to the network stack? >=20 > Yes, cxgbe does that. But I think the real bug here is in ip_reass > because it doesn't properly get rid of the pkthdr of the fragments whil= e > creating the reassembled datagram. cxgbe happens to trip on this easil= y > because it often creates !WRITEABLE mbufs. =46rom the quick look, I don't see the code in netipsec and in crypto, that does check mbuf is WRITEABLE. It is expected that in most cases for received mbuf the data will be decrypted and copied back into the given buffer. Can this lead to memory corruption? > This should fix it: > https://people.freebsd.org/~np/ip_reass_demotehdr.diff >=20 > It will also fix leaks in configurations where mbuf tags are in use by > default (for example with MAC), ip_reass is involved during rx, and the= > mbuf chain never gets m_demote'd elsewhere (meaning ip_reass should hav= e > freed the tags itself). I think such chain with several mbufs with M_PKTHDR flag is created with m_cat() due to !WRITEABLE mbufs. And when mbuf chain will be freed, the tags chain will be also destroyed by mbuf zone destructor. If you think it solves the problem, the IPv6 fragment reassembly probably needs the same code. But I think that M_WRITEABLE flag is not properly handled is the problem too. --=20 WBR, Andrey V. Elsukov --qlGvXlWklCDPqffVLVvgcWBHH5qkfvQ1n-- --4gb4mTbdfBpwBtocIOKKlUdGpAlv3kQBm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlpECbkACgkQAcXqBBDI oXrwZwf+L14Z5JAVa9WsIE7eZIU7gPHoC8z1mm5W6K7CLVDCYVrVPmveO1fCUGyB y+yQYhprKjQFZX1WzXJ5kcaIJBswSNdZFZqWpQ/N6lDSiUaRt0sh7lbssNsw3Dai +XLdmPsjGsYPlFzWI/TFhaDm0oU5qbjz1O0xFSkuUQZR4Jv46fKcJsZ4FjCD50HX kTxjT//EImaS+Fs33+eTvoddvXUpiDIC2CzRnr7nK6TUJ+Ef/f98Rbw4f9CTXwPh cAU2TyBLTst9L5YrpbvgofpDCOSkZBDivsujx+c2mNpW0LjBNeLwLAR/mcnAoP8E iFi94U+szBoo061obcUn2a/FKx0mXA== =JOZM -----END PGP SIGNATURE----- --4gb4mTbdfBpwBtocIOKKlUdGpAlv3kQBm-- From owner-freebsd-net@freebsd.org Wed Dec 27 22:10:42 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35CB7E80ECC for ; Wed, 27 Dec 2017 22:10:42 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2DF07A8DD for ; Wed, 27 Dec 2017 22:10:41 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pl0-x233.google.com with SMTP id 62so18634578pld.7 for ; Wed, 27 Dec 2017 14:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vPr1Hj/jUBjvqGSwSPBtz/j3GseTuRWDPVMZ8Z9MNQk=; b=QKHEe67V4iVJO0CEowI/XHvdk5pjfD6kiuNjFD6kgpsioxFlb8jpCVk8kRwXcVJxB0 7f4k0tPrTQUPJwYj3bGrOsSMjvdVHx14vCeMx5AxrhoHav7zPswMc7Iz80gn6W5JAqqT XbZfroTyPTiSGx0543lO9uGx+G46+aRnMeIIxZizvq2fcHIp3Fiw6r/kLLA6Bend6EeO Vic9EpHaqlnONzbfRcEyq6XnMnUPsEhuZT0iGgHOpODsNzhoUhIQ66I2AYSO5+JQHY27 ch5OPBL/XGay1wga+mfXAIdX8nW5IxFN2UcVxVuDQTqaJS9miwCz45dI/j86ewE0uUAn +IwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vPr1Hj/jUBjvqGSwSPBtz/j3GseTuRWDPVMZ8Z9MNQk=; b=HwPhcDYlS90ouENfBxmtVttLn0durYH29smWdJkrFcRifbKd8WjbLeOJP5SxZPOQcy UhS44ZUdNLj1fT079XTW7kQ5QzQW5h3FzikEo5Me81OmSEEj/ADKgJXS5rn6drNZbv9C Y+qUKKVRKgYdWvdAi5ZOp1FBoYdQRXhVwo3TOcUy+clTl3A2VAILg2ET9aSz19ittl/D GZljNRUuOcEkf1dKeNiBuzXui8kQaBqpsW2MKdykiDqzFQTVAahig5QCnNEAZatn+2Yf aKIrUTddUBFcxapM8uICjExFp70ftIiNuocGHXg9wWuxwASB99VHqYeEg7EKVjexcxCI U1RA== X-Gm-Message-State: AKGB3mImBvLlqnRyBGE5W2wADpmJ9WfF7JfO1Bzhx52ZoLQuycxDyOiS FqUnlpX1DxIGleTXDf9a9nR1hQ== X-Google-Smtp-Source: ACJfBosYhp7iRWUU2uPqmk+6zifoTM9NXjdilmMW8LoRscjBygyr52EaMb9XhLUGIRHrp85o+DtJHg== X-Received: by 10.84.244.199 with SMTP id f7mr29814498plt.181.1514412641101; Wed, 27 Dec 2017 14:10:41 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id n6sm73232513pfg.188.2017.12.27.14.10.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 14:10:40 -0800 (PST) Sender: Navdeep Parhar Subject: Re: [freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled To: "Andrey V. Elsukov" , Harsh Jain , freebsd-net@freebsd.org References: <73302ead-b2e9-c25b-4d11-475f38dec1a1@chelsio.com> <993c58bb-3bf2-d6a3-9a05-13e1631aec87@yandex.ru> From: Navdeep Parhar Message-ID: <2887a9d7-6b72-25a4-84da-74578b54d103@FreeBSD.org> Date: Wed, 27 Dec 2017 14:10:39 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 27 Dec 2017 22:10:42 -0000 On 12/27/2017 12:59, Andrey V. Elsukov wrote: > On 27.12.2017 23:09, Navdeep Parhar wrote: >>> It is not clear to me why it helps. The panic happens on outbound path, >>> where mbuf should be allocated by network stack and should be writeable. >>> ip_reass() usually used on inbound path. I think the patch just hides >>> the problem in another place. >>> Do you mean that cxgbe can produce !WRITEABLE mbuf for received packet >>> and then pass it to the network stack? >> >> Yes, cxgbe does that. But I think the real bug here is in ip_reass >> because it doesn't properly get rid of the pkthdr of the fragments while >> creating the reassembled datagram. cxgbe happens to trip on this easily >> because it often creates !WRITEABLE mbufs. > > From the quick look, I don't see the code in netipsec and in crypto, > that does check mbuf is WRITEABLE. It is expected that in most cases for > received mbuf the data will be decrypted and copied back into the given > buffer. Can this lead to memory corruption? > >> This should fix it: >> https://people.freebsd.org/~np/ip_reass_demotehdr.diff >> >> It will also fix leaks in configurations where mbuf tags are in use by >> default (for example with MAC), ip_reass is involved during rx, and the >> mbuf chain never gets m_demote'd elsewhere (meaning ip_reass should have >> freed the tags itself). > > I think such chain with several mbufs with M_PKTHDR flag is created with > m_cat() due to !WRITEABLE mbufs. And when mbuf chain will be freed, the > tags chain will be also destroyed by mbuf zone destructor. I see m_freem/m_free will do the right thing but such a chain isn't legal. m_unshare is complaining about it here. m_sanity on the chain will fail too. m_cat says it will leave the pkthdr alone so it is working as advertised. It's the caller's job to clean up headers etc. to keep the mbuf chain valid. > > If you think it solves the problem, the IPv6 fragment reassembly > probably needs the same code. But I think that M_WRITEABLE flag is not > properly handled is the problem too. > I think M_WRITEABLE is being handled properly here. m_unshare deals with the chain just fine apart from this assert about multiple M_PKTHDR. I'll fix IP6 reassembly too and post to phabricator if the change looks ok? Regards, Navdeep From owner-freebsd-net@freebsd.org Thu Dec 28 08:56:39 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50FB4E817AC for ; Thu, 28 Dec 2017 08:56:39 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2231B7238C for ; Thu, 28 Dec 2017 08:56:39 +0000 (UTC) (envelope-from kevin.bowling@kev009.com) Received: by mail-it0-x232.google.com with SMTP id r6so28051027itr.3 for ; Thu, 28 Dec 2017 00:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=ExWgBBM3H/YmrcGF/dgHhIU2oC9PjLp2W0/CwBEDCKM=; b=couX4H9559ISWf1GFLqz4J/L5daK2k27lebLyU6lAfkSZXq+t2gtKBRskLDbhwAjRM YaPHZvWCpd8UPGe7PW8c71zxLaa9zYi1QNUvtxf2MLEBa7keOLj7D2D4wxeG9TlY4sdl 6JdkPhFAXhjyIhouCXTjT8fjWly/fG1P5y10k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ExWgBBM3H/YmrcGF/dgHhIU2oC9PjLp2W0/CwBEDCKM=; b=ksoInFiLB450sFD87TQ16t+Tok303jN+QwqaVfSzyUJG+3Kjv2XbNtujtRpZ45ioYz e9pxyydSJSUiVp2FL6bMeVy5ThdkfVELnxrrSPY0qOFSoTmseIyQoGMzKA254uijFR4o PfFwBFNv/3lXlqU8UBXdHvqrihbJuD+j7ZwzT9vkfxXlXIhBakNAW5KHzpDF33/7r9RM bDuSjTdbFtUf+9LJ3O6OOfPwa1IatCm3qGJ9JA3SUovVI6zUvMaIE3GCgz/E1ZRTnJbw kLugID79hGan4nuMrBFlpaXO+5Rhl52ZUdBfvz72pbd2SNg7rM8YgEWdcPQ/vWGFaIvM oKMQ== X-Gm-Message-State: AKGB3mKxc6wyYKLbh0nEIwMl8UIrjmM6KzVVe9K/cfu8/MqNJiIFKDOX WVcbSrTAWMTTBYPq6BJd8Rlxk+BRnIexv4MllOxGH+K5 X-Google-Smtp-Source: ACJfBotrSR7Z9BVM45DZdxz7ad++Ka63HL7LQOKhmfKUr0hn/JU+rtypN4ELOw5uk5YPdnk/llvwWPaWKqAw1oFUTBU= X-Received: by 10.36.50.11 with SMTP id j11mr41781994ita.153.1514451398116; Thu, 28 Dec 2017 00:56:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.57.13 with HTTP; Thu, 28 Dec 2017 00:56:37 -0800 (PST) From: Kevin Bowling Date: Thu, 28 Dec 2017 01:56:37 -0700 Message-ID: Subject: Remove 'ixgb' from HEAD To: FreeBSD Net Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 08:56:39 -0000 The ixgb driver was used only briefly by one sub family of devices in the first half of the 2000s. It's not a power efficient card with a massive on board xenpak. The driver saw little specific (not API/treewide stuff) maintenance post FreeBSD 5 in which the last real intentional commit directly on the driver was by someone admitting they didn't have a card but spotting a bunch of errors in the driver. It's unlikely the driver is suitable for commercial use as it stands, and I wouldn't trust it in a home server. If someone actually uses ixgb and sends me one I will flatten it into iflib ixgbe. You can get one for $250 here :o) https://www.ebay.com/itm/Intel-PRO-10GbE-SR-PCI-X-PXLA8591SR-Server-Adapter-/110895948350 Otherwise I propose it be removed in HEAD, which gives a generous deorbiting period of September 30, 2021 in stable/11. Regards, Kevin From owner-freebsd-net@freebsd.org Thu Dec 28 14:00:05 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48493E9FBE7 for ; Thu, 28 Dec 2017 14:00:05 +0000 (UTC) (envelope-from julian@freebsd.org) 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 274F77C410 for ; Thu, 28 Dec 2017 14:00:01 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBSDxjxE004019 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Dec 2017 05:59:52 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help To: John Lyon References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> From: Julian Elischer Cc: "freebsd-net@freebsd.org" , Eugene Grosbein Message-ID: Date: Thu, 28 Dec 2017 21:59:40 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 14:00:05 -0000 On 28/12/17 1:37 am, John Lyon wrote: > Julian, > > Unfortunately, this issue remains unresolved.  I would like to think > that this is just a PEBKAC issue, but I have tried every permutation > of escape characters in case it's an issue with my syntax and I get > the same set of errors.  No matter what I do, I can't connect the no > match hook of an ETF node to the upper hook of an ng_ether node.  Do > you have any insights into why this might be occurring? > > By the way, thanks for reaching out to me!  I was going to email you > directly after the holidays since your name and email address are at > the bottom of the relevant Netgraph man pages.  I figured that must > mean if you didn't know the answer, no one does. :-) what is EAP? what about return EAP packets? (are there any?) I think this is what you want: $ sudo ngctl list There are 7 total nodes:   Name: igb0            Type: ether           ID: 00000001   Num hooks: 0   Name: igb1            Type: ether           ID: 00000002   Num hooks: 0   Name: ix0             Type: ether           ID: 00000003   Num hooks: 0   Name: ix1             Type: ether           ID: 00000004   Num hooks: 0   Name: tap0            Type: ether           ID: 00000005   Num hooks: 0   Name: bridge3         Type: ether           ID: 00000006   Num hooks: 0   Name: ngctl7372       Type: socket          ID: 00000007   Num hooks: 0 $ sudo kldload ng_etf $ sudo ngctl name ix0:lower eapfilter $ sudo ngctl connect eapfilter: ix0: nomatch upper $ sudo ngctl connect eapfilter: ix1: eapout lower $ sudo ngctl show eapfilter:   Name: eapfilter       Type: etf             ID: 00000021   Num hooks: 3   Local hook      Peer name       Peer type    Peer ID         Peer hook   ----------      ---------       --------- -------         ---------   eapout          ix1             ether 00000004        lower   nomatch         ix0             ether 00000003        upper   downstream      ix0             ether 00000003        lower $ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" ethertype=0x888e }' $ > > Thanks. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer > > wrote: > > John did you get a resolution to this issue? > > > On 16/12/17 2:59 am, John Lyon wrote: > > Harry and Eugene (and others), > > I appreciate all of your help.  It's been really > insightful.  Although I > feel like I'm getting much closer to the solution, I don't > think my problem > has been diagnosed.  I've outlined my thought process > below.  Can you > please tell me if I am misunderstanding something? > Admittedly, I am not a > kernel developer and my C language skills have atrophied the > last few > years.  However, I've reviewed my script and I looked in the > code for > ng_etf.c and I don't think I am violating any of the > requirements for > linking a hook for no match. > > As Eugene stated: > > 1) referenced "matchook" exists and you should not > use "indirect name" > > here, > > only hook own name, or else you get error ENOENT (No > such file or > > directory); > > This does not seem to be a problem as the upper and lower > hooks for the em1 > already exist (I can confirm this). > > 2) referenced "matchook" is *not* downstream hook, > or else you get error > EINVAL (Invalid argument); > > I read the ng_etf.c file in the source tree and found this > little snippet: > > /* and is not the downstream hook */ > if (hook == etfp->downstream_hook.hook) { >      error = EINVAL; >      break; > } > > This appears to be an error check to make sure you are not > creating a cycle > in the graph by referencing the ETF node's own downstream > hook (i.e. > filtering incoming traffic and circularly feeding > non-matching frames back > into the ETF's own filter).  I'm not doing this.  I am > feeding non-matching > packets into the *lower* hook of another ether node and not > back into the > *downstream* hook of the etf node I am creating.  As a > result, my netgraph > should not be triggering this error condition. > > 3) it was not already configured, or else you get > error EEXIST (File > > exists). > > I am not getting this error, so it appears not to be an > issue in my case. > > What am I missing here?  The man page states that "*any > other *hook" can be > > used for the non-matching packets.  So the man page says > this should work, > and there's no explicit error condition that I see (caveat, > I have not > written in C for at least 10 years  - PEBKAC is entirely > possible) that > would be triggered in the ng_etf code.  So what is going wrong? > > Thanks for all of your help, patience, and understanding. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > > On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer > > > wrote: > > Bezüglich Eugene Grosbein's Nachricht vom 14.12.2017 > 23:07 (localtime): > > 15.12.2017 4:27, John Lyon wrote: > > I'm a new Netgraph user, but am having > some problems with a simple > Netgraph > script I have written.  Unfortunately, > the error message is cryptic > > and I > > can't tell what I am doing wrong since > my script closely follows the > example provided in the ng_etf man page. > > For some context, I'm trying to filter > EAP traffic coming in on my LAN > interface.  Any ethernet frames that > correspond to EAP traffic need > > to be > > immediately forwarded from the LAN > interface to my WAN interface.  All > other ethernet frames coming in on my > LAN interface need to be > > handled by > > the kernel's network stack.  A (horrid) > ASCII art representation of my > desired netgraph would look like this: > > lower -> em0 -> downstream -> ETF -> no > match -> upper em0 >                 -> match -> > lower em1 > > The script I have written is this: > >      #! /bin/sh >      ngctl mkpeer em0: etf lower downstream >      ngctl name em0:lower lan_filter >      ngctl connect em0: lan_filter: > upper nomatch >      ngctl msg lan_filter: setfilter { > matchhook="em1:lower" > ethertype=0x888e } > > Unfortunately, the last line of my > script generates the following > > error > > message: > >      ngctl: send msg: Invalid Argument > > For "setfilter" command to work, ng_etf requires that: > > 1) referenced "matchook" exists and you should not > use "indirect name" > > here, > > only hook own name, or else you get error ENOENT (No > such file or > > directory); > > 2) referenced "matchook" is *not* downstream hook, > or else you get error > EINVAL (Invalid argument); > 3) it was not already configured, or else you get > error EEXIST (File > > exists). > > Eugene kindly looked into the code and found that the > error is due to > wrong matchhook definition. > I've never had any contact with ng_etf yet, but > according to the man > page, you need to set the (additional) filter hook by > 'nghook -a > lan_filter: mydrain' and use 'matchhook=mydrain' for the > 'msg' command. > > Do idea about the intention, so for the rest you have to > tweak as needed. > > -harry > > > _______________________________________________ > freebsd-net@freebsd.org > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org > " > > > > From owner-freebsd-net@freebsd.org Thu Dec 28 14:48:37 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 529D9EA2A95 for ; Thu, 28 Dec 2017 14:48:37 +0000 (UTC) (envelope-from julian@freebsd.org) 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 3464C7E2EE for ; Thu, 28 Dec 2017 14:48:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBSEmSAU004193 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Dec 2017 06:48:33 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help [fixed] From: Julian Elischer To: John Lyon Cc: "freebsd-net@freebsd.org" , Eugene Grosbein References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> Message-ID: <4fee4ea6-9b35-afba-6d5d-24ecca3e28c6@freebsd.org> Date: Thu, 28 Dec 2017 22:48:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 14:48:37 -0000 On 28/12/17 9:59 pm, Julian Elischer wrote: > On 28/12/17 1:37 am, John Lyon wrote: >> Julian, >> >> Unfortunately, this issue remains unresolved.  I would like to >> think that this is just a PEBKAC issue, but I have tried every >> permutation of escape characters in case it's an issue with my >> syntax and I get the same set of errors.  No matter what I do, I >> can't connect the no match hook of an ETF node to the upper hook of >> an ng_ether node.  Do you have any insights into why this might be >> occurring? >> >> By the way, thanks for reaching out to me!  I was going to email >> you directly after the holidays since your name and email address >> are at the bottom of the relevant Netgraph man pages.  I figured >> that must mean if you didn't know the answer, no one does. :-) > > what is EAP? > what about return EAP packets? (are there any?) oops left out a line from the cut-n-paste... > > I think this is what you want: > $ sudo ngctl list > There are 7 total nodes: >   Name: igb0            Type: ether           ID: 00000001   Num > hooks: 0 >   Name: igb1            Type: ether           ID: 00000002   Num > hooks: 0 >   Name: ix0             Type: ether           ID: 00000003   Num > hooks: 0 >   Name: ix1             Type: ether           ID: 00000004   Num > hooks: 0 >   Name: tap0            Type: ether           ID: 00000005   Num > hooks: 0 >   Name: bridge3         Type: ether           ID: 00000006   Num > hooks: 0 >   Name: ngctl7372       Type: socket          ID: 00000007   Num > hooks: 0 > $ sudo kldload ng_etf $ sudo ngctl mkpeer ix0: etf lower downstream > $ sudo ngctl name ix0:lower eapfilter > $ sudo ngctl connect eapfilter: ix0: nomatch upper > $ sudo ngctl connect eapfilter: ix1: eapout lower > $ sudo ngctl show eapfilter: >   Name: eapfilter       Type: etf             ID: 00000021   Num > hooks: 3 >   Local hook      Peer name       Peer type    Peer ID Peer hook >   ----------      ---------       --------- ------- --------- >   eapout          ix1             ether 00000004        lower >   nomatch         ix0             ether 00000003        upper >   downstream      ix0             ether 00000003        lower > $ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" > ethertype=0x888e }' > $ > > >> >> Thanks. >> >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer >> > wrote: >> >>     John did you get a resolution to this issue? >> >> >>     On 16/12/17 2:59 am, John Lyon wrote: >> >>         Harry and Eugene (and others), >> >>         I appreciate all of your help.  It's been really >>         insightful.  Although I >>         feel like I'm getting much closer to the solution, I don't >>         think my problem >>         has been diagnosed.  I've outlined my thought process >>         below.  Can you >>         please tell me if I am misunderstanding something? >>         Admittedly, I am not a >>         kernel developer and my C language skills have atrophied the >>         last few >>         years.  However, I've reviewed my script and I looked in the >>         code for >>         ng_etf.c and I don't think I am violating any of the >>         requirements for >>         linking a hook for no match. >> >>         As Eugene stated: >> >>                 1) referenced "matchook" exists and you should not >>                 use "indirect name" >> >>         here, >> >>                 only hook own name, or else you get error ENOENT (No >>                 such file or >> >>         directory); >> >>         This does not seem to be a problem as the upper and lower >>         hooks for the em1 >>         already exist (I can confirm this). >> >>                 2) referenced "matchook" is *not* downstream hook, >>                 or else you get error >>                 EINVAL (Invalid argument); >> >>         I read the ng_etf.c file in the source tree and found this >>         little snippet: >> >>         /* and is not the downstream hook */ >>         if (hook == etfp->downstream_hook.hook) { >>              error = EINVAL; >>              break; >>         } >> >>         This appears to be an error check to make sure you are not >>         creating a cycle >>         in the graph by referencing the ETF node's own downstream >>         hook (i.e. >>         filtering incoming traffic and circularly feeding >>         non-matching frames back >>         into the ETF's own filter).  I'm not doing this.  I am >>         feeding non-matching >>         packets into the *lower* hook of another ether node and not >>         back into the >>         *downstream* hook of the etf node I am creating.  As a >>         result, my netgraph >>         should not be triggering this error condition. >> >>                 3) it was not already configured, or else you get >>                 error EEXIST (File >> >>         exists). >> >>         I am not getting this error, so it appears not to be an >>         issue in my case. >> >>         What am I missing here?  The man page states that "*any >>         other *hook" can be >> >>         used for the non-matching packets.  So the man page says >>         this should work, >>         and there's no explicit error condition that I see (caveat, >>         I have not >>         written in C for at least 10 years  - PEBKAC is entirely >>         possible) that >>         would be triggered in the ng_etf code.  So what is going >> wrong? >> >>         Thanks for all of your help, patience, and understanding. >> >> >>         -------------------------------- >>         John L. Lyon >>         PGP Key Available At: >>         https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> >>         On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >>         > >>         wrote: >> >>             Bezüglich Eugene Grosbein's Nachricht vom 14.12.2017 >>             23:07 (localtime): >> >>                 15.12.2017 4:27, John Lyon wrote: >> >>                             I'm a new Netgraph user, but am having >>                             some problems with a simple >>                             Netgraph >>                             script I have written. Unfortunately, >>                             the error message is cryptic >> >>             and I >> >>                             can't tell what I am doing wrong since >>                             my script closely follows the >>                             example provided in the ng_etf man page. >> >>                             For some context, I'm trying to filter >>                             EAP traffic coming in on my LAN >>                             interface.  Any ethernet frames that >>                             correspond to EAP traffic need >> >>             to be >> >>                             immediately forwarded from the LAN >>                             interface to my WAN interface.  All >>                             other ethernet frames coming in on my >>                             LAN interface need to be >> >>             handled by >> >>                             the kernel's network stack.  A (horrid) >>                             ASCII art representation of my >>                             desired netgraph would look like this: >> >>                             lower -> em0 -> downstream -> ETF -> no >>                             match -> upper em0 >>                                             -> match -> >>                             lower em1 >> >>                             The script I have written is this: >> >>                                  #! /bin/sh >>                                  ngctl mkpeer em0: etf lower >> downstream >>                                  ngctl name em0:lower lan_filter >>                                  ngctl connect em0: lan_filter: >>                             upper nomatch >>                                  ngctl msg lan_filter: setfilter { >>                             matchhook="em1:lower" >>                             ethertype=0x888e } >> >>                             Unfortunately, the last line of my >>                             script generates the following >> >>             error >> >>                             message: >> >>                                  ngctl: send msg: Invalid Argument >> >>                 For "setfilter" command to work, ng_etf requires that: >> >>                 1) referenced "matchook" exists and you should not >>                 use "indirect name" >> >>             here, >> >>                 only hook own name, or else you get error ENOENT (No >>                 such file or >> >>             directory); >> >>                 2) referenced "matchook" is *not* downstream hook, >>                 or else you get error >>                 EINVAL (Invalid argument); >>                 3) it was not already configured, or else you get >>                 error EEXIST (File >> >>             exists). >> >>             Eugene kindly looked into the code and found that the >>             error is due to >>             wrong matchhook definition. >>             I've never had any contact with ng_etf yet, but >>             according to the man >>             page, you need to set the (additional) filter hook by >>             'nghook -a >>             lan_filter: mydrain' and use 'matchhook=mydrain' for the >>             'msg' command. >> >>             Do idea about the intention, so for the rest you have to >>             tweak as needed. >> >>             -harry >> >> >>         _______________________________________________ >>         freebsd-net@freebsd.org >>         mailing list >>         https://lists.freebsd.org/mailman/listinfo/freebsd-net >> >>         To unsubscribe, send any mail to >>         "freebsd-net-unsubscribe@freebsd.org >>         " >> >> >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@freebsd.org Thu Dec 28 15:58:30 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D1FDEA6373 for ; Thu, 28 Dec 2017 15:58:30 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0741080680; Thu, 28 Dec 2017 15:58:30 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id f140so44365847wmd.2; Thu, 28 Dec 2017 07:58:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L+j2U9V8bUDEwUGFKp0X3rmFBz2uXTZuISmMhxIPpfo=; b=XsjU1fTmF/dMbsy1iEupYGfN1+6uf9du5AsdoaLrnBNdIyvTxYw1xzFK/WTk1ArZJl cV9MzjoAZTHIHExbrRffiFMAX58amzg1RV0JfQEG8C1JspJk6eYBXIxZmFFL8geCyzk3 0RbUwQrWV7RTCktHFlAf2WClWBQ/KwRsdewSfRVU95280USymTbEIuRE3RkdlQeq85tF wa0WXtMncOrYSYQai9V8TpyZIX8pkcr5z+kXYtuRorFZ2jsV6eDumKYTfNG8ro/gyoRm IewPpcnpwDbw9QWYZHszLcsHCfiTcP9JD69cck1JyEAGhXzl6msICQuPAmX/PedEjFGa YccQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L+j2U9V8bUDEwUGFKp0X3rmFBz2uXTZuISmMhxIPpfo=; b=jjYxJXst+rJ3gFfZ1U9BdNwd6CDwR7Ut1Li/cdpa0bYIFyS1CzsPMrfITvqR2Q2DTx YdwAoxqFEtK8pB53uBR5QYT+JvdMlfTE40U6MXR+8QerawVcJKT4/ZbcKZ9DsoHaIxrP PJYOyosJTXzXe95jRYkBauf2Z8Uf4xW+LPJtRfQYTd9SYaami5yQwniPUPuV7bLhlCDA /QIAI7Z3t1CTjCYXKAgksRimv8AdXChFG3tgNzvptxYjEyy2F+cQO07Bss8TVw3Dpdyv pSO5PuJjxSfNLPkFeUtcXv3/jopiqEW0lyXnrv7RKYtN/eWnYDyvhkpa517LvhMiGlZn njjg== X-Gm-Message-State: AKGB3mIegprYr5FQ+HinmPE+Y37zpN92r15+OnZ+BI+9RikNSIv8nJpN GQihzsxp3lDIzttaC0Zdr151DnBa7j3likimPaDHiL33 X-Google-Smtp-Source: ACJfBosJ+OmsWpzyka6eoDOIkVbzOcxQvZnVCrCvbxUsTS66TUaQfC5+aHAHFUHxPDLBw5jW64dml4yz7TyPqWGcvAw= X-Received: by 10.80.184.52 with SMTP id j49mr39872629ede.160.1514476708222; Thu, 28 Dec 2017 07:58:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Thu, 28 Dec 2017 07:58:07 -0800 (PST) In-Reply-To: References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> From: John Lyon Date: Thu, 28 Dec 2017 10:58:07 -0500 Message-ID: Subject: Re: Need Netgraph Help To: Julian Elischer Cc: "freebsd-net@freebsd.org" , Eugene Grosbein Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 15:58:30 -0000 Julian, That looks exactly like what I want! It also looks like what I thought I was doing. I have no idea why it worked for you and not for me. :-( I will copy and paste tonight after work (making changes for em0 and em1 on my own test system) and see if I can get it to work. If it works, I will figure out what I was doing wrong and let the world know in case anyone wants to Google it in the future. If it doesn't work -- I'll be back. :-) To answer your other questions: (1) EAP (or more accurately in this case EAPOL) is the extensible authentication protocol over LAN and is used for 802.1X port authentication. The authentication frames are marked with the ethertype 0x888e to distinguish them from other Ethernet frames. They are also assigned the broadcast MAC address of 01:80:c2:00:00:03. Because 802.1D states that a standard compliant switch or bridge cannot forward frames with a MAC address in the range of 01:80:c2:00:00:00 to 01:80:c2:00:00:0f, you can't just create a bridge in FreeBSD between the two interfaces since the FreeBSD bridge code is standard compliant. So I have to process and forward the frames another way and it looks like Netgraph will let me do it. Otherwise, I'm going to have to patch the bridge code in the kernel to include a sysctl variable that enables or disables this compliance. (2) You are correct that there are return frames (not packets as this all occurs at layer 2). However, the graph to handle the return frames is going to just be a mirror of the the graph for processing the outgoing frames. So if I can get it working in one direction, it's trivial to create a mirror image graph for the reverse direction. Thanks! -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Thu, Dec 28, 2017 at 8:59 AM, Julian Elischer wrote= : > On 28/12/17 1:37 am, John Lyon wrote: > > Julian, > > Unfortunately, this issue remains unresolved. I would like to think that > this is just a PEBKAC issue, but I have tried every permutation of escape > characters in case it's an issue with my syntax and I get the same set of > errors. No matter what I do, I can't connect the no match hook of an ETF > node to the upper hook of an ng_ether node. Do you have any insights int= o > why this might be occurring? > > By the way, thanks for reaching out to me! I was going to email you > directly after the holidays since your name and email address are at the > bottom of the relevant Netgraph man pages. I figured that must mean if y= ou > didn't know the answer, no one does. :-) > > > what is EAP? > what about return EAP packets? (are there any?) > > I think this is what you want: > $ sudo ngctl list > There are 7 total nodes: > Name: igb0 Type: ether ID: 00000001 Num hooks: 0 > Name: igb1 Type: ether ID: 00000002 Num hooks: 0 > Name: ix0 Type: ether ID: 00000003 Num hooks: 0 > Name: ix1 Type: ether ID: 00000004 Num hooks: 0 > Name: tap0 Type: ether ID: 00000005 Num hooks: 0 > Name: bridge3 Type: ether ID: 00000006 Num hooks: 0 > Name: ngctl7372 Type: socket ID: 00000007 Num hooks: 0 > $ sudo kldload ng_etf > $ sudo ngctl name ix0:lower eapfilter > $ sudo ngctl connect eapfilter: ix0: nomatch upper > $ sudo ngctl connect eapfilter: ix1: eapout lower > $ sudo ngctl show eapfilter: > Name: eapfilter Type: etf ID: 00000021 Num hooks: 3 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > eapout ix1 ether 00000004 lower > nomatch ix0 ether 00000003 upper > downstream ix0 ether 00000003 lower > $ sudo ngctl msg eapfilter: 'setfilter { matchhook=3D"eapout" > ethertype=3D0x888e }' > $ > > > > > Thanks. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer > wrote: > >> John did you get a resolution to this issue? >> >> >> On 16/12/17 2:59 am, John Lyon wrote: >> >>> Harry and Eugene (and others), >>> >>> I appreciate all of your help. It's been really insightful. Although = I >>> feel like I'm getting much closer to the solution, I don't think my >>> problem >>> has been diagnosed. I've outlined my thought process below. Can you >>> please tell me if I am misunderstanding something? Admittedly, I am no= t >>> a >>> kernel developer and my C language skills have atrophied the last few >>> years. However, I've reviewed my script and I looked in the code for >>> ng_etf.c and I don't think I am violating any of the requirements for >>> linking a hook for no match. >>> >>> As Eugene stated: >>> >>> 1) referenced "matchook" exists and you should not use "indirect name" >>>>> >>>> here, >>> >>>> only hook own name, or else you get error ENOENT (No such file or >>>>> >>>> directory); >>> >>> This does not seem to be a problem as the upper and lower hooks for the >>> em1 >>> already exist (I can confirm this). >>> >>> 2) referenced "matchook" is *not* downstream hook, or else you get erro= r >>>>> EINVAL (Invalid argument); >>>>> >>>> I read the ng_etf.c file in the source tree and found this little >>> snippet: >>> >>> /* and is not the downstream hook */ >>> if (hook =3D=3D etfp->downstream_hook.hook) { >>> error =3D EINVAL; >>> break; >>> } >>> >>> This appears to be an error check to make sure you are not creating a >>> cycle >>> in the graph by referencing the ETF node's own downstream hook (i.e. >>> filtering incoming traffic and circularly feeding non-matching frames >>> back >>> into the ETF's own filter). I'm not doing this. I am feeding >>> non-matching >>> packets into the *lower* hook of another ether node and not back into t= he >>> *downstream* hook of the etf node I am creating. As a result, my >>> netgraph >>> should not be triggering this error condition. >>> >>> 3) it was not already configured, or else you get error EEXIST (File >>>>> >>>> exists). >>> >>> I am not getting this error, so it appears not to be an issue in my cas= e. >>> >>> What am I missing here? The man page states that "*any other *hook" ca= n >>> be >>> >>> used for the non-matching packets. So the man page says this should >>> work, >>> and there's no explicit error condition that I see (caveat, I have not >>> written in C for at least 10 years - PEBKAC is entirely possible) that >>> would be triggered in the ng_etf code. So what is going wrong? >>> >>> Thanks for all of your help, patience, and understanding. >>> >>> >>> -------------------------------- >>> John L. Lyon >>> PGP Key Available At: >>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>> >>> On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >>> wrote: >>> >>> Bez=C3=BCglich Eugene Grosbein's Nachricht vom 14.12.2017 23:07 (localt= ime): >>>> >>>>> 15.12.2017 4:27, John Lyon wrote: >>>>> >>>>> I'm a new Netgraph user, but am having some problems with a simple >>>>>>>> Netgraph >>>>>>>> script I have written. Unfortunately, the error message is crypti= c >>>>>>>> >>>>>>> and I >>>> >>>>> can't tell what I am doing wrong since my script closely follows the >>>>>>>> example provided in the ng_etf man page. >>>>>>>> >>>>>>>> For some context, I'm trying to filter EAP traffic coming in on my >>>>>>>> LAN >>>>>>>> interface. Any ethernet frames that correspond to EAP traffic nee= d >>>>>>>> >>>>>>> to be >>>> >>>>> immediately forwarded from the LAN interface to my WAN interface. Al= l >>>>>>>> other ethernet frames coming in on my LAN interface need to be >>>>>>>> >>>>>>> handled by >>>> >>>>> the kernel's network stack. A (horrid) ASCII art representation of m= y >>>>>>>> desired netgraph would look like this: >>>>>>>> >>>>>>>> lower -> em0 -> downstream -> ETF -> no match -> upper em0 >>>>>>>> -> >>>>>>>> match -> >>>>>>>> lower em1 >>>>>>>> >>>>>>>> The script I have written is this: >>>>>>>> >>>>>>>> #! /bin/sh >>>>>>>> ngctl mkpeer em0: etf lower downstream >>>>>>>> ngctl name em0:lower lan_filter >>>>>>>> ngctl connect em0: lan_filter: upper nomatch >>>>>>>> ngctl msg lan_filter: setfilter { matchhook=3D"em1:lower" >>>>>>>> ethertype=3D0x888e } >>>>>>>> >>>>>>>> Unfortunately, the last line of my script generates the following >>>>>>>> >>>>>>> error >>>> >>>>> message: >>>>>>>> >>>>>>>> ngctl: send msg: Invalid Argument >>>>>>>> >>>>>>> For "setfilter" command to work, ng_etf requires that: >>>>> >>>>> 1) referenced "matchook" exists and you should not use "indirect name= " >>>>> >>>> here, >>>> >>>>> only hook own name, or else you get error ENOENT (No such file or >>>>> >>>> directory); >>>> >>>>> 2) referenced "matchook" is *not* downstream hook, or else you get >>>>> error >>>>> EINVAL (Invalid argument); >>>>> 3) it was not already configured, or else you get error EEXIST (File >>>>> >>>> exists). >>>> >>>> Eugene kindly looked into the code and found that the error is due to >>>> wrong matchhook definition. >>>> I've never had any contact with ng_etf yet, but according to the man >>>> page, you need to set the (additional) filter hook by 'nghook -a >>>> lan_filter: mydrain' and use 'matchhook=3Dmydrain' for the 'msg' comma= nd. >>>> >>>> Do idea about the intention, so for the rest you have to tweak as >>>> needed. >>>> >>>> -harry >>>> >>>> >>>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >>> >> > > From owner-freebsd-net@freebsd.org Thu Dec 28 16:10:58 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF78EEA6C20 for ; Thu, 28 Dec 2017 16:10:58 +0000 (UTC) (envelope-from julian@freebsd.org) 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 BED1080CEF for ; Thu, 28 Dec 2017 16:10:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBSGAljW004481 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Dec 2017 08:10:52 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help To: John Lyon Cc: "freebsd-net@freebsd.org" , Eugene Grosbein References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> From: Julian Elischer Message-ID: <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org> Date: Fri, 29 Dec 2017 00:10:41 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 16:10:59 -0000 On 28/12/17 11:58 pm, John Lyon wrote: > Julian, > > That looks exactly like what I want! It also looks like what I > thought I was doing.  I have no idea why it worked for you and not > for me.  :-( > > I will copy and paste tonight after work (making changes for em0 and > em1 on my own test system) and see if I can get it to work.  If it > works, I will figure out what I was doing wrong and let the world > know in case anyone wants to Google it in the future. If it doesn't > work -- I'll be back. :-) > > To answer your other questions: > > (1) EAP (or more accurately in this case EAPOL) is the extensible > authentication protocol over LAN and is used for 802.1X port > authentication.  The authentication frames are marked with the > ethertype 0x888e to distinguish them from other Ethernet frames.  > They are also assigned the broadcast MAC address of > 01:80:c2:00:00:03. Because 802.1D states that a standard compliant > switch or bridge cannot forward frames with a MAC address inthe > range of 01:80:c2:00:00:00 to 01:80:c2:00:00:0f, you can't just > create a bridge in FreeBSD between the two interfaces since the > FreeBSD bridge code is standard compliant.  So I have to process and > forward the frames another way and it looks like Netgraph will let > me do it.  Otherwise, I'm going to have to patch the bridge code in > the kernel to include a sysctl variable that enables or disables > this compliance. or use the netgraph bridge. ng_bridge. it doesn't care as far as I know. it's job it to produce "bump in the wire" devices. see /usr/share/examples/netgraph. > > (2) You are correct that there are return frames (not packets as > this all occurs at layer 2). However, the graph to handle the return > frames is going to just be a mirror of the the graph for processing > the outgoing frames.  So if I can get it working in one direction, > it's trivial to create a mirror image graph for the reverse direction. > > Thanks! > > > > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Thu, Dec 28, 2017 at 8:59 AM, Julian Elischer > wrote: > > On 28/12/17 1:37 am, John Lyon wrote: >> Julian, >> >> Unfortunately, this issue remains unresolved. I would like to >> think that this is just a PEBKAC issue, but I have tried every >> permutation of escape characters in case it's an issue with my >> syntax and I get the same set of errors.  No matter what I do, >> I can't connect the no match hook of an ETF node to the upper >> hook of an ng_ether node.  Do you have any insights into why >> this might be occurring? >> >> By the way, thanks for reaching out to me!  I was going to >> email you directly after the holidays since your name and email >> address are at the bottom of the relevant Netgraph man pages.  >> I figured that must mean if you didn't know the answer, no one >> does. :-) > > what is EAP? > what about return EAP packets? (are there any?) > > I think this is what you want: > $ sudo ngctl list > There are 7 total nodes: >   Name: igb0            Type: ether           ID: 00000001   Num > hooks: 0 >   Name: igb1            Type: ether           ID: 00000002   Num > hooks: 0 >   Name: ix0             Type: ether           ID: 00000003   Num > hooks: 0 >   Name: ix1             Type: ether           ID: 00000004   Num > hooks: 0 >   Name: tap0            Type: ether           ID: 00000005   Num > hooks: 0 >   Name: bridge3         Type: ether           ID: 00000006   Num > hooks: 0 >   Name: ngctl7372       Type: socket          ID: 00000007   Num > hooks: 0 > $ sudo kldload ng_etf > $ sudo ngctl name ix0:lower eapfilter > $ sudo ngctl connect eapfilter: ix0: nomatch upper > $ sudo ngctl connect eapfilter: ix1: eapout lower > $ sudo ngctl show eapfilter: >   Name: eapfilter       Type: etf             ID: 00000021   Num > hooks: 3 >   Local hook      Peer name       Peer type Peer ID         Peer > hook >   ----------      ---------       --------- -------         > --------- >   eapout          ix1             ether 00000004        lower >   nomatch         ix0             ether 00000003        upper >   downstream      ix0             ether 00000003        lower > $ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" > ethertype=0x888e }' > $ > > > >> >> Thanks. >> >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> >> On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer >> > wrote: >> >> John did you get a resolution to this issue? >> >> >> On 16/12/17 2:59 am, John Lyon wrote: >> >> Harry and Eugene (and others), >> >> I appreciate all of your help.  It's been really >> insightful.  Although I >> feel like I'm getting much closer to the solution, I >> don't think my problem >> has been diagnosed.  I've outlined my thought process >> below.  Can you >> please tell me if I am misunderstanding something?  >> Admittedly, I am not a >> kernel developer and my C language skills have >> atrophied the last few >> years.  However, I've reviewed my script and I looked >> in the code for >> ng_etf.c and I don't think I am violating any of the >> requirements for >> linking a hook for no match. >> >> As Eugene stated: >> >> 1) referenced "matchook" exists and you should >> not use "indirect name" >> >> here, >> >> only hook own name, or else you get error >> ENOENT (No such file or >> >> directory); >> >> This does not seem to be a problem as the upper and >> lower hooks for the em1 >> already exist (I can confirm this). >> >> 2) referenced "matchook" is *not* downstream >> hook, or else you get error >> EINVAL (Invalid argument); >> >> I read the ng_etf.c file in the source tree and found >> this little snippet: >> >> /* and is not the downstream hook */ >> if (hook == etfp->downstream_hook.hook) { >>      error = EINVAL; >>      break; >> } >> >> This appears to be an error check to make sure you are >> not creating a cycle >> in the graph by referencing the ETF node's own >> downstream hook (i.e. >> filtering incoming traffic and circularly feeding >> non-matching frames back >> into the ETF's own filter).  I'm not doing this.  I am >> feeding non-matching >> packets into the *lower* hook of another ether node and >> not back into the >> *downstream* hook of the etf node I am creating.  As a >> result, my netgraph >> should not be triggering this error condition. >> >> 3) it was not already configured, or else you >> get error EEXIST (File >> >> exists). >> >> I am not getting this error, so it appears not to be an >> issue in my case. >> >> What am I missing here?  The man page states that "*any >> other *hook" can be >> >> used for the non-matching packets.  So the man page >> says this should work, >> and there's no explicit error condition that I see >> (caveat, I have not >> written in C for at least 10 years  - PEBKAC is >> entirely possible) that >> would be triggered in the ng_etf code. So what is going >> wrong? >> >> Thanks for all of your help, patience, and understanding. >> >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> >> On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >> > >> wrote: >> >> Bezüglich Eugene Grosbein's Nachricht vom >> 14.12.2017 23:07 (localtime): >> >> 15.12.2017 4:27, John Lyon wrote: >> >> I'm a new Netgraph user, but am >> having some problems with a simple >> Netgraph >> script I have written. >> Unfortunately, the error message is >> cryptic >> >> and I >> >> can't tell what I am doing wrong >> since my script closely follows the >> example provided in the ng_etf man >> page. >> >> For some context, I'm trying to >> filter EAP traffic coming in on my LAN >> interface.  Any ethernet frames >> that correspond to EAP traffic need >> >> to be >> >> immediately forwarded from the LAN >> interface to my WAN interface.  All >> other ethernet frames coming in on >> my LAN interface need to be >> >> handled by >> >> the kernel's network stack.  A >> (horrid) ASCII art representation of my >> desired netgraph would look like this: >> >> lower -> em0 -> downstream -> ETF >> -> no match -> upper em0 >> -> match -> >> lower em1 >> >> The script I have written is this: >> >>      #! /bin/sh >>      ngctl mkpeer em0: etf lower >> downstream >>      ngctl name em0:lower lan_filter >>      ngctl connect em0: lan_filter: >> upper nomatch >>      ngctl msg lan_filter: >> setfilter { matchhook="em1:lower" >> ethertype=0x888e } >> >> Unfortunately, the last line of my >> script generates the following >> >> error >> >> message: >> >>      ngctl: send msg: Invalid Argument >> >> For "setfilter" command to work, ng_etf >> requires that: >> >> 1) referenced "matchook" exists and you should >> not use "indirect name" >> >> here, >> >> only hook own name, or else you get error >> ENOENT (No such file or >> >> directory); >> >> 2) referenced "matchook" is *not* downstream >> hook, or else you get error >> EINVAL (Invalid argument); >> 3) it was not already configured, or else you >> get error EEXIST (File >> >> exists). >> >> Eugene kindly looked into the code and found that >> the error is due to >> wrong matchhook definition. >> I've never had any contact with ng_etf yet, but >> according to the man >> page, you need to set the (additional) filter hook >> by 'nghook -a >> lan_filter: mydrain' and use 'matchhook=mydrain' >> for the 'msg' command. >> >> Do idea about the intention, so for the rest you >> have to tweak as needed. >> >> -harry >> >> >> _______________________________________________ >> freebsd-net@freebsd.org >> mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org >> " >> >> >> >> > > From owner-freebsd-net@freebsd.org Thu Dec 28 16:37:18 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 782B1EA7F55 for ; Thu, 28 Dec 2017 16:37:18 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A3341BBF; Thu, 28 Dec 2017 16:37:18 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id g75so45024495wme.0; Thu, 28 Dec 2017 08:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PawD6w+4oeWXoclqh5zM8oL73czp9gFumHjqaySdNus=; b=Jb/QtmNOEkwwwh5ar/kb7+vKZ9EMnpNuF2Ox1GfSGwZdzdGNUrblpa7aBIyGr6ENMO z25NxPFWpQb6VC6JejqChM8NqNPyzaSxGWulWs3qqYxeXqn8qtIky1DU0aD2bIWmo5rI mGggErDHJHMb9anC1WSFGHc8eRQUYn1dlcBOEmWn+EB4Dbk+un8G/xScKVCzUF65FJRD O/iz0EXfsQaJ4tu+aIIAtbIhuJzGbFjO4qJHA74NdwGJKAPdq0ltH4HR97mxH6pIcXC7 E+AIdcH8JDvhKtFpnj3OT2oDOXEji0YADqLuJjfVt4qwkQl5m3MnOHvAWukEEwfLrtvx BlCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PawD6w+4oeWXoclqh5zM8oL73czp9gFumHjqaySdNus=; b=Wo4yU5XBECozD41L5hOaemVfEBlj1S/vOZJh2MmLXZa6blwIkE6cGqbP5BQCCfX0Cf F7/NtR7Ic+mwXwBz2x+4nnOaUl+15BrxTvGOhyCHWLLTbP+mMTZWzeiwqbKUl1UiymLu aae8i3m7BrZvo6YgaiTY+XlPt0+LnhJxOLT7bN0BLi9axFwu/SD1lDO044Ixcsv5A5xy lP+lEGrzz64exHLAdOmEmrAZ5hGDuwHkUitaXO0RLIEjUx2fpteyN8A6LluQEdcbNj6m 4/3NBId/DYrY9a8xzyV2BosYAjn7zhQAZyIYfA63rUtUUPvFujeyCXalfGphAr/D2LzW 69kg== X-Gm-Message-State: AKGB3mL5h1Sa1pOsm6vePP1g1vlMSeRwOJeLPjo0jzXf+KfsHP1Rz8Xk Znq1iCwNTlhR8RXOVIRvZgI4gojAO+ddadrWwc1DOMAM X-Google-Smtp-Source: ACJfBosyllFsiqv57mVbZCq7zoqpClBrFWeNoAbyR0uz/PsxmeGjFox3e12HLTdD37RkyzAc7yUVDVbPmrO0ohUVhRI= X-Received: by 10.80.230.3 with SMTP id y3mr41268558edm.211.1514479035760; Thu, 28 Dec 2017 08:37:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Thu, 28 Dec 2017 08:36:55 -0800 (PST) In-Reply-To: <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org> References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org> From: John Lyon Date: Thu, 28 Dec 2017 11:36:55 -0500 Message-ID: Subject: Re: Need Netgraph Help To: Julian Elischer Cc: "freebsd-net@freebsd.org" , Eugene Grosbein Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 16:37:18 -0000 The netgraph bridge would probably forward the 802.1x frames, but the man page says that firewalling on the netgraph bridge is not supported. I need to process with the firewall all of the other traffic that is not EAPOL frames. -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Thu, Dec 28, 2017 at 11:10 AM, Julian Elischer wrote: > On 28/12/17 11:58 pm, John Lyon wrote: > > Julian, > > That looks exactly like what I want! It also looks like what I thought I > was doing. I have no idea why it worked for you and not for me. :-( > > I will copy and paste tonight after work (making changes for em0 and em1 > on my own test system) and see if I can get it to work. If it works, I > will figure out what I was doing wrong and let the world know in case > anyone wants to Google it in the future. If it doesn't work -- I'll be > back. :-) > > To answer your other questions: > > (1) EAP (or more accurately in this case EAPOL) is the extensible > authentication protocol over LAN and is used for 802.1X port > authentication. The authentication frames are marked with the ethertype > 0x888e to distinguish them from other Ethernet frames. They are also > assigned the broadcast MAC address of 01:80:c2:00:00:03. Because 802.1D > states that a standard compliant switch or bridge cannot forward frames > with a MAC address in the range of 01:80:c2:00:00:00 to > 01:80:c2:00:00:0f, you can't just create a bridge in FreeBSD between the > two interfaces since the FreeBSD bridge code is standard compliant. So I > have to process and forward the frames another way and it looks like > Netgraph will let me do it. Otherwise, I'm going to have to patch the > bridge code in the kernel to include a sysctl variable that enables or > disables this compliance. > > or use the netgraph bridge. ng_bridge. it doesn't care as far as I know. > it's job it to produce "bump in the wire" devices. > see /usr/share/examples/netgraph. > > > > (2) You are correct that there are return frames (not packets as this all > occurs at layer 2). However, the graph to handle the return frames is > going to just be a mirror of the the graph for processing the outgoing > frames. So if I can get it working in one direction, it's trivial to > create a mirror image graph for the reverse direction. > > Thanks! > > > > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Thu, Dec 28, 2017 at 8:59 AM, Julian Elischer > wrote: > >> On 28/12/17 1:37 am, John Lyon wrote: >> >> Julian, >> >> Unfortunately, this issue remains unresolved. I would like to think tha= t >> this is just a PEBKAC issue, but I have tried every permutation of escap= e >> characters in case it's an issue with my syntax and I get the same set o= f >> errors. No matter what I do, I can't connect the no match hook of an ET= F >> node to the upper hook of an ng_ether node. Do you have any insights in= to >> why this might be occurring? >> >> By the way, thanks for reaching out to me! I was going to email you >> directly after the holidays since your name and email address are at the >> bottom of the relevant Netgraph man pages. I figured that must mean if = you >> didn't know the answer, no one does. :-) >> >> >> what is EAP? >> what about return EAP packets? (are there any?) >> >> I think this is what you want: >> $ sudo ngctl list >> There are 7 total nodes: >> Name: igb0 Type: ether ID: 00000001 Num hooks: = 0 >> Name: igb1 Type: ether ID: 00000002 Num hooks: = 0 >> Name: ix0 Type: ether ID: 00000003 Num hooks: = 0 >> Name: ix1 Type: ether ID: 00000004 Num hooks: = 0 >> Name: tap0 Type: ether ID: 00000005 Num hooks: = 0 >> Name: bridge3 Type: ether ID: 00000006 Num hooks: = 0 >> Name: ngctl7372 Type: socket ID: 00000007 Num hooks: = 0 >> $ sudo kldload ng_etf >> $ sudo ngctl name ix0:lower eapfilter >> $ sudo ngctl connect eapfilter: ix0: nomatch upper >> $ sudo ngctl connect eapfilter: ix1: eapout lower >> $ sudo ngctl show eapfilter: >> Name: eapfilter Type: etf ID: 00000021 Num hooks: = 3 >> Local hook Peer name Peer type Peer ID Peer hook >> ---------- --------- --------- ------- --------- >> eapout ix1 ether 00000004 lower >> nomatch ix0 ether 00000003 upper >> downstream ix0 ether 00000003 lower >> $ sudo ngctl msg eapfilter: 'setfilter { matchhook=3D"eapout" >> ethertype=3D0x888e }' >> $ >> >> >> >> >> Thanks. >> >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer >> wrote: >> >>> John did you get a resolution to this issue? >>> >>> >>> On 16/12/17 2:59 am, John Lyon wrote: >>> >>>> Harry and Eugene (and others), >>>> >>>> I appreciate all of your help. It's been really insightful. Although= I >>>> feel like I'm getting much closer to the solution, I don't think my >>>> problem >>>> has been diagnosed. I've outlined my thought process below. Can you >>>> please tell me if I am misunderstanding something? Admittedly, I am >>>> not a >>>> kernel developer and my C language skills have atrophied the last few >>>> years. However, I've reviewed my script and I looked in the code for >>>> ng_etf.c and I don't think I am violating any of the requirements for >>>> linking a hook for no match. >>>> >>>> As Eugene stated: >>>> >>>> 1) referenced "matchook" exists and you should not use "indirect name" >>>>>> >>>>> here, >>>> >>>>> only hook own name, or else you get error ENOENT (No such file or >>>>>> >>>>> directory); >>>> >>>> This does not seem to be a problem as the upper and lower hooks for th= e >>>> em1 >>>> already exist (I can confirm this). >>>> >>>> 2) referenced "matchook" is *not* downstream hook, or else you get err= or >>>>>> EINVAL (Invalid argument); >>>>>> >>>>> I read the ng_etf.c file in the source tree and found this little >>>> snippet: >>>> >>>> /* and is not the downstream hook */ >>>> if (hook =3D=3D etfp->downstream_hook.hook) { >>>> error =3D EINVAL; >>>> break; >>>> } >>>> >>>> This appears to be an error check to make sure you are not creating a >>>> cycle >>>> in the graph by referencing the ETF node's own downstream hook (i.e. >>>> filtering incoming traffic and circularly feeding non-matching frames >>>> back >>>> into the ETF's own filter). I'm not doing this. I am feeding >>>> non-matching >>>> packets into the *lower* hook of another ether node and not back into >>>> the >>>> *downstream* hook of the etf node I am creating. As a result, my >>>> netgraph >>>> should not be triggering this error condition. >>>> >>>> 3) it was not already configured, or else you get error EEXIST (File >>>>>> >>>>> exists). >>>> >>>> I am not getting this error, so it appears not to be an issue in my >>>> case. >>>> >>>> What am I missing here? The man page states that "*any other *hook" >>>> can be >>>> >>>> used for the non-matching packets. So the man page says this should >>>> work, >>>> and there's no explicit error condition that I see (caveat, I have not >>>> written in C for at least 10 years - PEBKAC is entirely possible) tha= t >>>> would be triggered in the ng_etf code. So what is going wrong? >>>> >>>> Thanks for all of your help, patience, and understanding. >>>> >>>> >>>> -------------------------------- >>>> John L. Lyon >>>> PGP Key Available At: >>>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>>> >>>> On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >>> > >>>> wrote: >>>> >>>> Bez=C3=BCglich Eugene Grosbein's Nachricht vom 14.12.2017 23:07 (local= time): >>>>> >>>>>> 15.12.2017 4:27, John Lyon wrote: >>>>>> >>>>>> I'm a new Netgraph user, but am having some problems with a simple >>>>>>>>> Netgraph >>>>>>>>> script I have written. Unfortunately, the error message is crypt= ic >>>>>>>>> >>>>>>>> and I >>>>> >>>>>> can't tell what I am doing wrong since my script closely follows the >>>>>>>>> example provided in the ng_etf man page. >>>>>>>>> >>>>>>>>> For some context, I'm trying to filter EAP traffic coming in on m= y >>>>>>>>> LAN >>>>>>>>> interface. Any ethernet frames that correspond to EAP traffic ne= ed >>>>>>>>> >>>>>>>> to be >>>>> >>>>>> immediately forwarded from the LAN interface to my WAN interface. A= ll >>>>>>>>> other ethernet frames coming in on my LAN interface need to be >>>>>>>>> >>>>>>>> handled by >>>>> >>>>>> the kernel's network stack. A (horrid) ASCII art representation of = my >>>>>>>>> desired netgraph would look like this: >>>>>>>>> >>>>>>>>> lower -> em0 -> downstream -> ETF -> no match -> upper em0 >>>>>>>>> -> >>>>>>>>> match -> >>>>>>>>> lower em1 >>>>>>>>> >>>>>>>>> The script I have written is this: >>>>>>>>> >>>>>>>>> #! /bin/sh >>>>>>>>> ngctl mkpeer em0: etf lower downstream >>>>>>>>> ngctl name em0:lower lan_filter >>>>>>>>> ngctl connect em0: lan_filter: upper nomatch >>>>>>>>> ngctl msg lan_filter: setfilter { matchhook=3D"em1:lower" >>>>>>>>> ethertype=3D0x888e } >>>>>>>>> >>>>>>>>> Unfortunately, the last line of my script generates the following >>>>>>>>> >>>>>>>> error >>>>> >>>>>> message: >>>>>>>>> >>>>>>>>> ngctl: send msg: Invalid Argument >>>>>>>>> >>>>>>>> For "setfilter" command to work, ng_etf requires that: >>>>>> >>>>>> 1) referenced "matchook" exists and you should not use "indirect nam= e" >>>>>> >>>>> here, >>>>> >>>>>> only hook own name, or else you get error ENOENT (No such file or >>>>>> >>>>> directory); >>>>> >>>>>> 2) referenced "matchook" is *not* downstream hook, or else you get >>>>>> error >>>>>> EINVAL (Invalid argument); >>>>>> 3) it was not already configured, or else you get error EEXIST (File >>>>>> >>>>> exists). >>>>> >>>>> Eugene kindly looked into the code and found that the error is due to >>>>> wrong matchhook definition. >>>>> I've never had any contact with ng_etf yet, but according to the man >>>>> page, you need to set the (additional) filter hook by 'nghook -a >>>>> lan_filter: mydrain' and use 'matchhook=3Dmydrain' for the 'msg' comm= and. >>>>> >>>>> Do idea about the intention, so for the rest you have to tweak as >>>>> needed. >>>>> >>>>> -harry >>>>> >>>>> >>>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>>> >>>> >>> >> >> > > From owner-freebsd-net@freebsd.org Thu Dec 28 17:34:14 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C226CEAABA4 for ; Thu, 28 Dec 2017 17:34:14 +0000 (UTC) (envelope-from charlie@atech.media) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 90E093EE5 for ; Thu, 28 Dec 2017 17:34:14 +0000 (UTC) (envelope-from charlie@atech.media) Received: by mailman.ysv.freebsd.org (Postfix) id 8D000EAABA3; Thu, 28 Dec 2017 17:34:14 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C998EAABA2 for ; Thu, 28 Dec 2017 17:34:14 +0000 (UTC) (envelope-from charlie@atech.media) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40058.outbound.protection.outlook.com [40.107.4.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8AA13EE4 for ; Thu, 28 Dec 2017 17:34:12 +0000 (UTC) (envelope-from charlie@atech.media) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atech.media; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fHYUqgdUZLGK8/369CP1I3Qv7aKqCCLhdHbQNY0vZtw=; b=CyyrMTUoLeUdu2IqqeCq3Lqvutf9DF/HzMCzSCVcZFfo/ak8j3hZt/1DzojAuAayC+A4bxwEoulmbBCOsS15JTOwt4RHDFZr1gBsmTaC5kmeYr9KvV539Hgcq58ocjnCobBJIi7Me72/mSecn9Gta4+GN5tVUQ++Ufteq6E1984= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=charlie@atech.media; Received: from [10.0.8.11] (185.102.133.45) by HE1PR05MB3498.eurprd05.prod.outlook.com (2603:10a6:7:32::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.14; Thu, 28 Dec 2017 17:34:09 +0000 From: Charlie Smurthwaite To: net@freebsd.org Subject: Linux netmap memory allocation Message-ID: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> Date: Thu, 28 Dec 2017 17:34:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Originating-IP: [185.102.133.45] X-ClientProxiedBy: DB6P195CA0011.EURP195.PROD.OUTLOOK.COM (2603:10a6:4:cb::21) To HE1PR05MB3498.eurprd05.prod.outlook.com (2603:10a6:7:32::16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8c723cae-cded-4a60-67ba-08d54e193435 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:HE1PR05MB3498; X-Microsoft-Exchange-Diagnostics: 1; HE1PR05MB3498; 3:f/KoSpUQFgQqxAQVNRKHH92dsiOSXjQLcktXvC8yce/w7MFjNkaAfCGY2JPxQ+3g0ehPtmQRlylOe1Z9Kvu9z100CuqeBgTA4OaEUsggFPvdD2oqGvN+UrgPFG/fCyZmqAcF4y+3+sb4nGgqkvptMGRXAgJ/M+Vzgz3f5gkVsmTsGTLo487fBqHcmJxr3LhSeQFuqbdhvppK+RGNB3NhlhiaTvwvH+lnrIcFJwYDAeaj5wNUMdFQcEAV8RmWMOSp; 25:yGwmbHvTw9dYbv19+yZTtBEvEcwyi5E9nNiGOprGhUuicyvAxylleyZgvwOu94k8wVBI2CMTbAiYkA7V9qoJutM/mBEzTl1SlPZ4+Rty19YwrOsnuUMNa0Qx6IgVOWKMKatJsuxShZlKYdD5pMiyIbDK2QN3Zsw+UTKFuH9S2zV6GrMho/mRCbfwwv9OL8baqmjd8A+bX2GtvuBzaNSe6ebTCa4zTjE8tWS09DcYZE5n1Io1O4POU7nkiSZD1zmZttBjjMuuLN0rE3vu4gR6REowpzeufRosuRH4viO+1D3x4cpMPw/QMhTJ5XsVF2tPPiDF7KI42mlq5f9v5pMK4w==; 31:jnIHilkOvwjlqqwJYVtFbbvyMnIMb49XOg+j6Ac1sIEm/bRFwXvC2iUfQTGm+ufM1QdUV+k+TVaE3mNaLVI3qogilLUCW0skof5j+6UMk6E4qTkrdEFQ5hG+YQS4BHCnQGGbHanWYJeQ7rIES/Tji/wpYxmLK6RaY8reJl//0uAqMXgiqNreIA6JrJyDwwohRQynXfCmsvz7S/9x/+ZNC6ajfLCnkGezCkQGL54hJtk= X-MS-TrafficTypeDiagnostic: HE1PR05MB3498: X-Microsoft-Exchange-Diagnostics: 1; HE1PR05MB3498; 20:oY9NUITQ0eneBWiz6+NoqkDlJ/MLjqWeWOiQp7eYvL81CQRSmRfIRfRtrSXkxNDodwioHQVsJQt3Wt6crPQvXILT0SPU06MNS46H6EWgSMfbnJTER/c5JKnOylPST4CQXQoI6NGFZHu/CvXkAY8c+tddw6we9VYr/OyDmNaWpmotwydfOMrqVg5Aqv49dqxKFCwLLXQQmVvDOmMW8AD/IQpiPjM55JyWDNzDGdPdE7QZS7eOuBIKY/UaMt/PgUth; 4:GtvdIjXK7GuNg9a5fFPuW+u4hDPjNWFW3yBvt50ih3rVDMg96USaGPXgcGoyPQ5XNdpLG+Mq6WaEkkx1fCaBf1gNM5u3E7Ihbp1TDAXHusn74PN1xuNNsVxq7e3pWDrVVcvi/QqTpr7s86gENB0OZT9S94zOz5IiwCBg+hk+XYj6GcSOfcP8OuQNIquTNzUzuGZLNQ6FF51LC2/qTwmUxrWar2ZZgbpra0upQYBxbsyVWknwd/Rp6Zk8AUqc7RISLjZ3qBzFHhUlyzYR2R5uSA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:HE1PR05MB3498; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR05MB3498; X-Forefront-PRVS: 05352A48BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(376002)(39830400003)(39380400002)(346002)(366004)(396003)(52544003)(189003)(199004)(6666003)(16526018)(106356001)(316002)(2351001)(386003)(3480700004)(66066001)(65826007)(6306002)(65806001)(53936002)(2361001)(64126003)(966005)(5660300001)(97736004)(81156014)(305945005)(31686004)(23676004)(8676002)(2906002)(50466002)(83506002)(67846002)(81166006)(6916009)(105586002)(7736002)(33896004)(8936002)(58126008)(77096006)(16576012)(47776003)(8746002)(59450400001)(2486003)(65956001)(68736007)(478600001)(52146003)(6116002)(3846002)(25786009)(575784001)(31696002)(6486002)(52116002)(86362001)(46492003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR05MB3498; H:[10.0.8.11]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: atech.media does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA1TUIzNDk4OzIzOjNnV2MvVlhud2JiVDZreURUWDR5WVRwTWEz?= =?utf-8?B?U3d0Q2s5K0Q2bUZUbUZYemxCQWo2UXFUQnA1QndoaGVuMkRBQXdoeGJ2ZWlj?= =?utf-8?B?UTRvZHdQZTlVTno4NW5UYzMwVWxHWjdnZDhYNG9ISzdCMkk3UU1yMks2RllU?= =?utf-8?B?OWJETXNmUWdlbHFNZis0TTBWbDk4WkVVZ053bEE2dEgzL3huT2ZZUVlNNGlZ?= =?utf-8?B?R0ExVEp5VE9VdU5hekhSazBTa1FIUHFobFMyUk4wWS9JdjF0MU10SCtWanhP?= =?utf-8?B?Y3pCTjNwQktFZldCZGt2R20xempQOUNoTlkvK05JUi9BNW5vQlByTjd2Yyts?= =?utf-8?B?YTBvK2tsT1hGOFpDZzBEU1orQnlxczhOSnJaU1JnQ2JDc0dvRTV5dlMxejgr?= =?utf-8?B?R2dMWFlQaG1UNEJYUkJyV1U2clY0anlTNm5ITlltbVBlcE15OWhCbUloekZT?= =?utf-8?B?b243bExuWHg5c1NaMUk4ZTNCS1lkYnQ3dlJrT3V1RkI3T2owYm9ndUo3ZWp0?= =?utf-8?B?V1hQTTVaVDJJV1hTc0ZrbmgvKy94c0NTK0QzcWxlYWJvYnJDY0lHS2lBUTZ4?= =?utf-8?B?YjE0Z25QYzdpdTRpZS9uSUNvSExQb1pDSjdVY20vSUN5UnY2dHpWd1oxWUM4?= =?utf-8?B?QkxMdDZKQ1UzZTh4NU5qSW1hOVhQODF4dTRXaml2TnRYd0RKM0MzOVR4SEtG?= =?utf-8?B?R094bUxUSTdQS1dnMUlkWVFFVHdwQmZYejlGdkgwa2txVHd4N281dkZzVWNa?= =?utf-8?B?OUN1cXd2WlI1Z0VpSS83NSszc0tJL3BuTG11cUljVGR4ZDhSUmZwbFE3OEt2?= =?utf-8?B?WFVkckpqbU9KT3hERFN6TVhuU0pBR2hTU2RMWEVWOW1SVEp2SEtFNXlwbmRT?= =?utf-8?B?SmV3OWJxbHVTb2tzTmFUbXU5M0hJR2hZR1Eya3BxTUgxSFR0c0dreEpVVWpT?= =?utf-8?B?TlVGaDgxZ0tOTHJXeXE0bzAvUE9kMjFpU2sxcGRpYWowYlJvS1ZjVkEyR2Vz?= =?utf-8?B?ZE1jdUFQVXU0OUJseFovNGdIY1NycjVtUjNwV1ByazMxRkFtRkJHeDJjVDVu?= =?utf-8?B?T2NuajFlY2Eyb2Y0dlJVSWZVamY0Mkl1dHNzcHJjK0JDL2VtdjFONlMxZ29v?= =?utf-8?B?Znphc1JnbTFKTXkvbjF3bjR0VTgvOUgzaDZHQjhjL1ZOT2hhamw1RUZJNzVz?= =?utf-8?B?QnJlNXowTThoVXBDdGNHeWtSNGgrN0VpMFVWWkV4emc1ZU1yZzMwZ0c2dVE1?= =?utf-8?B?TXlRK0s2LzNwL1JWT2Fwa0x2VzdraE5ZOGYzL3BnWndEbXFwT2J6Y0RucXV3?= =?utf-8?B?MmRscFZTakNxSGpYbG15Z3JORGhEY1FaRGtrQjI1TmVNQ2dtRXl2WmtCN2ha?= =?utf-8?B?SVV5RXduMEtIWlZvbkg1bXBQbzVURGtxaDljWi9xaEhwVTFiMEl6ZVBvWXY2?= =?utf-8?B?bEtzRGZFT3g0RkFnYXpyeHM5QkNNakFrdVdrWHNVMzRHOWlTQ1Q4NVBiUnNY?= =?utf-8?B?WmpaSmVueEp4Y3g0TndZTUw1TlpPNjVyOVJOdmhqcGtBb054RVJ0QkZLRmlS?= =?utf-8?B?eTR3ZGhmK0pGckY4eEU4YTZ0RE0rbTRkM0dCWjVveHR3bm1EYS9ZRXFkbWVv?= =?utf-8?B?dG5FLzZoaU0zUzl4aEhjS09xam02SFcrdU1QTUdmR0hlaFA1SG52VkladWNw?= =?utf-8?B?UUFSNzkrQUl3SVVZMVpidWRTWm42WWh2QldGM2lxNGJkei83ei85MzhHT1Bx?= =?utf-8?B?eTZlQzkvL0QvaEFMWnBPM0N0Sjh6OExVRWxuOXBOR1FoSERpd1Rwb2xVODdQ?= =?utf-8?B?VExuSWgrL2UwZkFqY1Jhall2dmNjZEdRRjhEYkJpVDNydHJxelB6eUFLWlZk?= =?utf-8?Q?YvsLSarb5tkEvCZ5N3OSyTCjjx3T1B+0?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR05MB3498; 6:sfNCRZxxHAc7gH8jFjYcs0l61Ys6P+VhuErEr/I76S2Ai83UnxC1uQ+z0KbI1w/QnHVM8a6W+FiSNsWQQQ0UYe7a/qdxGXYYhXgugLh0FFFkz2Qf32WHYGPzyscwbAnQkXf2P+zPECRhmCS7JHmQFB2wEkfnHdiDFVN+aazXLcVT0Usvbt+oFP3Eh5aT397TrqvIKK1+hs0L5Lfr+yr9yAcuL1eugAf3HwJvJbTe4QvlJUYAhmwPkpdwfq/Bb4cRFYxJp7/FX7+mY97fS+J5iUkcMMlDmTaOGvrjG5mt9hNXCvBWZiy6dYCE7FEIYiQ67gw8TO0SZ30lc+doxvNBlc+09Ln4RgOADNSR2NObai8=; 5:CcxqxPZTbPpxTD1hmpvvB3n712NUAMP8mfk94PZu+g2DVVlMyI5cPKNAg3tMD12z1p3ByDrQ/6WrVXlpd9qS3eVaW8ctTLxLM6Fsg7bbqHOQjbArbkTsPdrExBMG0TJ+a8syJszikQ6bHcQMQ1eXHcwvccPozLb1oVh1UeINFkA=; 24:WpRIFKdDFMNfcz9LDheuANSaM9XfXxAMjksuvhug6H2HtYHBiZVquf9sSKXUs8rQ/jZOqpAto7saXV0d0TybiRFmp8SRplcXJwe441cEfdw=; 7:D4+TLkSx9f1X2S7hToLZipcTMUeSwolZgPId7zATu+MuIm8ZrHUjHupFqK1kuyE6M5IK6CTKDFWS5z26R4LTfebqe2E36+pCWyN/WUq424xSk+GyMmXms2/Lq6TeVHgUZ2CjiJSlJxDJXjkhcJzIUK6/3c/qByxYkkT3l2nVQStih7fO0a2yMrqXpvr4MuVe3VGbkbCk2jsY/hhnFel6zXX0LalxhWk0vz3IRA0VkNPLNIr3iOE1JsdZXEvuoKgv SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: atech.media X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Dec 2017 17:34:09.7826 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8c723cae-cded-4a60-67ba-08d54e193435 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a8f6edf-720f-4e3d-b767-1360e39a8cdf X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR05MB3498 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 17:34:14 -0000 Hi, I'm just starting to use netmap and it is my intention to do zero-copy forwarding of frames between a large number of NICs. I am using Intel i350 (igb) on Linux. I therefore require a large memory area for rings and buffers. My calculation: 32 NICs * 2 rings (TX+RX) * 256 frames * 2048 bytes =3D 32MB I am currently having a problem (or perhaps just a misunderstanding) regarding allocation of this memory. I am attempting to use the following code: void thread_main(int thread_id) { struct nmreq req; // A struct for the netmap request int fd; // File descriptor for netmap socket void * mem; // Pointer to allocated memory area fd =3D open("/dev/netmap", 0); // Open a generic netmap socket strcpy(req.nr_name, "enp8s0f0"); // Copy NIC name into request req.nr_version =3D NETMAP_API; // Set version number req.nr_flags =3D NR_REG_ONE_NIC; // We will be using a single hw ring // Select ring 0, disable TX on poll req.nr_ringid =3D NETMAP_NO_TX_POLL | NETMAP_HW_RING | 0; // Ask for 64 additional rings to be allocated (32 * (TX+RX)) req.nr_arg1 =3D 64; // Allocate a separate memory area for each thread req.nr_arg2 =3D 10 + thread_id; // Ask for additional buffers (256 per ring) req.nr_arg3 =3D 64*256; // Initialize port ioctl(fd, NIOCREGIF, &req); // Check the allocated memory size printf("memsize: %u\n", req.nr_memsize); // Check the allocated memory area printf("nr_arg2: %u\n", req.nr_arg2); } The output is as follows: memsize: 4206859 nr_arg2: 10 This is far short of the amount of memory I am hoping to be allocated. Am I doing something wrong, or is this simply an indication that the driver is unwilling to allocate more than 4MB? A secondary (related) problem is that if I don't set arg1,arg2,arg3 in my code (ie they will be zero), then I get varying output (it varies between each of the following): memsize: 4206843 nr_arg2: 0 memsize: 343019520 nr_arg2: 1 Any pointers would be appreciated. Thanks! Charlie Charlie Smurthwaite Technical Director tel. email. charlie@atech.media web. https://a= tech.media This e-mail has been sent by aTech Media Limited (or one of its assoicated = group companys, Dial 9 Communications Limited or Viaduct Hosting Limited). = Its contents are confidential therefore if you have received this message i= n error, we would appreciate it if you could let us know and delete the mes= sage. aTech Media Limited is a UK limited company, registration number 5523= 199. Dial 9 Communications Limited is a UK limited company, registration nu= mber 7740921. Viaduct Hosting Limited is a UK limited company, registration= number 8514362. All companies are registered at Unit 9 Winchester Place, N= orth Street, Poole, Dorset, BH15 1NX. From owner-freebsd-net@freebsd.org Thu Dec 28 18:29:11 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5DE0EAD160 for ; Thu, 28 Dec 2017 18:29:11 +0000 (UTC) (envelope-from julian@freebsd.org) 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 AA58564EB8 for ; Thu, 28 Dec 2017 18:29:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBSISufh004892 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Dec 2017 10:29:06 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help To: John Lyon Cc: "freebsd-net@freebsd.org" , Eugene Grosbein References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> <1abf4796-a88d-ab40-c05d-bed85877bb40@freebsd.org> From: Julian Elischer Message-ID: <4d9c2d9d-b3b3-e3bd-a4ae-11a1d27f7d71@freebsd.org> Date: Fri, 29 Dec 2017 02:28:50 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 18:29:11 -0000 On 29/12/17 12:36 am, John Lyon wrote: > The netgraph bridge would probably forward the 802.1x frames, but > the man page says that firewalling on the netgraph bridge is not > supported.  I need to process with the firewall all of the other > traffic that is not EAPOL frames. ok > > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Thu, Dec 28, 2017 at 11:10 AM, Julian Elischer > > wrote: > > On 28/12/17 11:58 pm, John Lyon wrote: >> Julian, >> >> That looks exactly like what I want!  It also looks like what I >> thought I was doing.  I have no idea why it worked for you and >> not for me.  :-( >> >> I will copy and paste tonight after work (making changes for >> em0 and em1 on my own test system) and see if I can get it to >> work.  If it works, I will figure out what I was doing wrong >> and let the world know in case anyone wants to Google it in the >> future. If it doesn't work -- I'll be back. :-) >> >> To answer your other questions: >> >> (1) EAP (or more accurately in this case EAPOL) is the >> extensible authentication protocol over LAN and is used for >> 802.1X port authentication.  The authentication frames are >> marked with the ethertype 0x888e to distinguish them from other >> Ethernet frames. They are also assigned the broadcast MAC >> address of 01:80:c2:00:00:03. Because 802.1D states that a >> standard compliant switch or bridge cannot forward frames with >> a MAC address inthe range of 01:80:c2:00:00:00 to >> 01:80:c2:00:00:0f, you can't just create a bridge in FreeBSD >> between the two interfaces since the FreeBSD bridge code is >> standard compliant.  So I have to process and forward the >> frames another way and it looks like Netgraph will let me do >> it.  Otherwise, I'm going to have to patch the bridge code in >> the kernel to include a sysctl variable that enables or >> disables this compliance. > or use the netgraph bridge. ng_bridge. it doesn't care as far as > I know. it's job it to produce "bump in the wire" devices. > see /usr/share/examples/netgraph. > > >> >> (2) You are correct that there are return frames (not packets >> as this all occurs at layer 2).  However, the graph to handle >> the return frames is going to just be a mirror of the the graph >> for processing the outgoing frames.  So if I can get it working >> in one direction, it's trivial to create a mirror image graph >> for the reverse direction. >> >> Thanks! >> >> >> >> >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> >> On Thu, Dec 28, 2017 at 8:59 AM, Julian Elischer >> > wrote: >> >> On 28/12/17 1:37 am, John Lyon wrote: >>> Julian, >>> >>> Unfortunately, this issue remains unresolved.  I would >>> like to think that this is just a PEBKAC issue, but I have >>> tried every permutation of escape characters in case it's >>> an issue with my syntax and I get the same set of errors.  >>> No matter what I do, I can't connect the no match hook of >>> an ETF node to the upper hook of an ng_ether node.  Do you >>> have any insights into why this might be occurring? >>> >>> By the way, thanks for reaching out to me!  I was going to >>> email you directly after the holidays since your name and >>> email address are at the bottom of the relevant Netgraph >>> man pages.  I figured that must mean if you didn't know >>> the answer, no one does. :-) >> >> what is EAP? >> what about return EAP packets? (are there any?) >> >> I think this is what you want: >> $ sudo ngctl list >> There are 7 total nodes: >>   Name: igb0            Type: ether           ID: >> 00000001   Num hooks: 0 >>   Name: igb1            Type: ether           ID: >> 00000002   Num hooks: 0 >>   Name: ix0             Type: ether           ID: >> 00000003   Num hooks: 0 >>   Name: ix1             Type: ether           ID: >> 00000004   Num hooks: 0 >>   Name: tap0            Type: ether           ID: >> 00000005   Num hooks: 0 >>   Name: bridge3         Type: ether           ID: >> 00000006   Num hooks: 0 >>   Name: ngctl7372       Type: socket          ID: >> 00000007   Num hooks: 0 >> $ sudo kldload ng_etf >> $ sudo ngctl name ix0:lower eapfilter >> $ sudo ngctl connect eapfilter: ix0: nomatch upper >> $ sudo ngctl connect eapfilter: ix1: eapout lower >> $ sudo ngctl show eapfilter: >>   Name: eapfilter       Type: etf             ID: >> 00000021   Num hooks: 3 >>   Local hook      Peer name Peer type    Peer ID         >> Peer hook >>   ----------      --------- ---------    -------         >> --------- >>   eapout          ix1 ether        00000004        lower >>   nomatch         ix0 ether        00000003        upper >>   downstream      ix0 ether        00000003        lower >> $ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" >> ethertype=0x888e }' >> $ >> >> >> >>> >>> Thanks. >>> >>> >>> -------------------------------- >>> John L. Lyon >>> PGP Key Available At: >>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>> >>> >>> On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer >>> > wrote: >>> >>> John did you get a resolution to this issue? >>> >>> >>> On 16/12/17 2:59 am, John Lyon wrote: >>> >>> Harry and Eugene (and others), >>> >>> I appreciate all of your help.  It's been really >>> insightful.  Although I >>> feel like I'm getting much closer to the solution, >>> I don't think my problem >>> has been diagnosed.  I've outlined my thought >>> process below.  Can you >>> please tell me if I am misunderstanding >>> something?  Admittedly, I am not a >>> kernel developer and my C language skills have >>> atrophied the last few >>> years.  However, I've reviewed my script and I >>> looked in the code for >>> ng_etf.c and I don't think I am violating any of >>> the requirements for >>> linking a hook for no match. >>> >>> As Eugene stated: >>> >>> 1) referenced "matchook" exists and you >>> should not use "indirect name" >>> >>> here, >>> >>> only hook own name, or else you get error >>> ENOENT (No such file or >>> >>> directory); >>> >>> This does not seem to be a problem as the upper >>> and lower hooks for the em1 >>> already exist (I can confirm this). >>> >>> 2) referenced "matchook" is *not* >>> downstream hook, or else you get error >>> EINVAL (Invalid argument); >>> >>> I read the ng_etf.c file in the source tree and >>> found this little snippet: >>> >>> /* and is not the downstream hook */ >>> if (hook == etfp->downstream_hook.hook) { >>>      error = EINVAL; >>>      break; >>> } >>> >>> This appears to be an error check to make sure you >>> are not creating a cycle >>> in the graph by referencing the ETF node's own >>> downstream hook (i.e. >>> filtering incoming traffic and circularly feeding >>> non-matching frames back >>> into the ETF's own filter).  I'm not doing this.  >>> I am feeding non-matching >>> packets into the *lower* hook of another ether >>> node and not back into the >>> *downstream* hook of the etf node I am creating.  >>> As a result, my netgraph >>> should not be triggering this error condition. >>> >>> 3) it was not already configured, or else >>> you get error EEXIST (File >>> >>> exists). >>> >>> I am not getting this error, so it appears not to >>> be an issue in my case. >>> >>> What am I missing here?  The man page states that >>> "*any other *hook" can be >>> >>> used for the non-matching packets.  So the man >>> page says this should work, >>> and there's no explicit error condition that I see >>> (caveat, I have not >>> written in C for at least 10 years  - PEBKAC is >>> entirely possible) that >>> would be triggered in the ng_etf code.  So what is >>> going wrong? >>> >>> Thanks for all of your help, patience, and >>> understanding. >>> >>> >>> -------------------------------- >>> John L. Lyon >>> PGP Key Available At: >>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>> >>> >>> On Fri, Dec 15, 2017 at 3:48 AM, Harry >>> Schmalzbauer >> > >>> wrote: >>> >>> Bezüglich Eugene Grosbein's Nachricht vom >>> 14.12.2017 23:07 (localtime): >>> >>> 15.12.2017 4:27, John Lyon wrote: >>> >>> I'm a new Netgraph user, but >>> am having some problems with a >>> simple >>> Netgraph >>> script I have written. >>> Unfortunately, the error >>> message is cryptic >>> >>> and I >>> >>> can't tell what I am doing >>> wrong since my script closely >>> follows the >>> example provided in the ng_etf >>> man page. >>> >>> For some context, I'm trying >>> to filter EAP traffic coming >>> in on my LAN >>> interface.  Any ethernet >>> frames that correspond to EAP >>> traffic need >>> >>> to be >>> >>> immediately forwarded from the >>> LAN interface to my WAN >>> interface. All >>> other ethernet frames coming >>> in on my LAN interface need to be >>> >>> handled by >>> >>> the kernel's network stack. A >>> (horrid) ASCII art >>> representation of my >>> desired netgraph would look >>> like this: >>> >>> lower -> em0 -> downstream -> >>> ETF -> no match -> upper em0 >>> -> match -> >>> lower em1 >>> >>> The script I have written is this: >>> >>>      #! /bin/sh >>>      ngctl mkpeer em0: etf >>> lower downstream >>>      ngctl name em0:lower >>> lan_filter >>>      ngctl connect em0: >>> lan_filter: upper nomatch >>>      ngctl msg lan_filter: >>> setfilter { matchhook="em1:lower" >>> ethertype=0x888e } >>> >>> Unfortunately, the last line >>> of my script generates the >>> following >>> >>> error >>> >>> message: >>> >>>      ngctl: send msg: Invalid >>> Argument >>> >>> For "setfilter" command to work, ng_etf >>> requires that: >>> >>> 1) referenced "matchook" exists and you >>> should not use "indirect name" >>> >>> here, >>> >>> only hook own name, or else you get error >>> ENOENT (No such file or >>> >>> directory); >>> >>> 2) referenced "matchook" is *not* >>> downstream hook, or else you get error >>> EINVAL (Invalid argument); >>> 3) it was not already configured, or else >>> you get error EEXIST (File >>> >>> exists). >>> >>> Eugene kindly looked into the code and found >>> that the error is due to >>> wrong matchhook definition. >>> I've never had any contact with ng_etf yet, >>> but according to the man >>> page, you need to set the (additional) filter >>> hook by 'nghook -a >>> lan_filter: mydrain' and use >>> 'matchhook=mydrain' for the 'msg' command. >>> >>> Do idea about the intention, so for the rest >>> you have to tweak as needed. >>> >>> -harry >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org >>> mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> >>> To unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@freebsd.org >>> " >>> >>> >>> >>> >> >> > > From owner-freebsd-net@freebsd.org Thu Dec 28 18:43:16 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9F8CEADB4E for ; Thu, 28 Dec 2017 18:43:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C857E658B7 for ; Thu, 28 Dec 2017 18:43:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBSIhGJL022574 for ; Thu, 28 Dec 2017 18:43:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Thu, 28 Dec 2017 18:43:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kurt@thinkcsc.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 18:43:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 KurtC changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kurt@thinkcsc.com --- Comment #8 from KurtC --- I am running into this exact Malicious Driver Detection event under high lo= ad on a X710-DA2 running driver 1.7.12. Disabling TSO does not fix the problem for me. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Dec 28 20:28:35 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F080FEB255E for ; Thu, 28 Dec 2017 20:28:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D71166979E for ; Thu, 28 Dec 2017 20:28:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBSKSYvt070987 for ; Thu, 28 Dec 2017 20:28:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Thu, 28 Dec 2017 20:28:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: incin@incin.me X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 20:28:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 Wallace changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |incin@incin.me --- Comment #9 from Wallace --- We are having the same issue on a new Supermicro server purchsed this month. ixl0@pci0:26:0:0: class=3D0x020000 card=3D0x37d215d9 chip=3D0x37d2808= 6 rev=3D0x09 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Ethernet Connection X722 for 10GBASE-T' class =3D network subclass =3D ethernet Dec 27 10:23:03 hostname kernel: ixl0: WARNING: queue 1 appears to be hung! Dec 27 10:23:03 hostname kernel: ixl0: WARNING: Resetting! Dec 27 10:23:10 hostname kernel: ixl0: Malicious Driver Detection event 14 = on TX queue 1, pf number 0 Dec 27 10:23:10 hostname kernel: ixl0: MDD TX event is for this function! After playing with lro and tso things seemed to be better. No more errors in the log files and NFS shares seemed more stable. Over the past week it seem= ed it didn't matter if there was light or heavy traffic.=20 Errors:=20 ixl0: flags=3D8843 metric 0 mtu 1500 =20=20=20=20=20=20=20 options=3D6407bb ether ac:1f:6b:61:a3:80 hwaddr ac:1f:6b:61:a3:80 inet x.x.x.x netmask 0xfffff800 broadcast x.x.x.x inet x.x.x.x netmask 0xfffff800 broadcast x.x.x.x=20 nd6 options=3D29 media: Ethernet autoselect (10Gbase-T ) status: active No Errors: [root@backup0 ~]# ifconfig ixl0 -lro -tso [root@backup0 ~]# ifconfig ixl0 ixl0: flags=3D8843 metric 0 mtu 1500 =20=20=20=20=20=20=20 options=3D6400bb ether ac:1f:6b:61:a3:80 hwaddr ac:1f:6b:61:a3:80 inet x.x.x.x netmask 0xfffff800 broadcast x.x.x.x=20 inet x.x.x.x netmask 0xfffff800 broadcast x.x.x.x nd6 options=3D29 media: Ethernet [root@hostname /var/log]# freebsd-version -k 11.1-RELEASE-p4 [root@hostname /var/log]# freebsd-version -u 11.1-RELEASE-p6 I can provide more info if anyone needs it or help debug the issue more. Thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Thu Dec 28 23:14:56 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31E1BE87649 for ; Thu, 28 Dec 2017 23:14:56 +0000 (UTC) (envelope-from charlie@atech.media) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F32AC70C80 for ; Thu, 28 Dec 2017 23:14:55 +0000 (UTC) (envelope-from charlie@atech.media) Received: by mailman.ysv.freebsd.org (Postfix) id F28A8E87648; Thu, 28 Dec 2017 23:14:55 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2294E87647 for ; Thu, 28 Dec 2017 23:14:55 +0000 (UTC) (envelope-from charlie@atech.media) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0073.outbound.protection.outlook.com [104.47.1.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C4C070C7E for ; Thu, 28 Dec 2017 23:14:53 +0000 (UTC) (envelope-from charlie@atech.media) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atech.media; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jLafLtGj5a6oZ/NxEFEG8wXMbFML9mZjPLWXcMYoKzM=; b=Z9SXw1QffQdGjlzLxmdefxaRUTCrqefM/vnc274COx2M3REh6G/+og+OzxIM7VpdWkTH8jho32flnc/9OK71N+EDouy7NVo0Mi6uSF/Ok5uguEStpeX2UYBbd2p1YoinAknfA7n+nTna8qEHFRjE0VG1BAuJUQpzMqfG1IuGWc8= Received: from [10.0.8.11] (185.102.133.45) by VI1PR05MB3501.eurprd05.prod.outlook.com (2603:10a6:802:1e::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.14; Thu, 28 Dec 2017 23:14:50 +0000 Subject: Re: Linux netmap memory allocation From: Charlie Smurthwaite To: net@freebsd.org References: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> Message-ID: <682a059e-130a-99c2-b7e6-4a865098e965@atech.media> Date: Thu, 28 Dec 2017 23:14:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: [185.102.133.45] X-ClientProxiedBy: VI1PR08CA0097.eurprd08.prod.outlook.com (2603:10a6:800:d3::23) To VI1PR05MB3501.eurprd05.prod.outlook.com (2603:10a6:802:1e::31) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e05b2625-bc4d-4325-62fa-08d54e48cbc8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:VI1PR05MB3501; X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB3501; 3:Ghmg0yShaAGc1XC9CJXmEmlSadoyamLXhofgB7o4+qnduRrFf4e30qM8qHnbNrDPiefI5uEd/WWSA39bKAYgEWnK/z5GV8iwJN63ritkh9Nb6ZCOC1is1k46uYFYIw0m+eaJd8jyTcfb1IHorxHLyzrDPFbr3dREGDLD86LTzAmga1lpf64Ox9hptJmQ812y1VemMPNxtLsE3Ar1JwAbiD2p+ZVmgfoBCs4hAZOKDxx2xWVA1GaClQx2emVGKqn8; 25:XeaLhRsEQzXqTnaeg6C8Q8DF2L+FKhC2HdQeNUBee1ZIstT3zNcQsevVBxW1kwlc5ri3fcJDQ2hkoNKt6RFvkSJEZtDvqwh41ge2mzXwlNYOiyQA6IkS7Pt5NmBJ37m8u3GArBQITaPKr+Tn3qbrkEtt+RJhOsEvIzT16BcMQ/Rkcg26O4GHAbsK35Gs1KjZEa/uGITi3iyMVdUW6l6bE7V4SqMcnexf8AOOMlQXEsoGvSJvCllhh1ntDhD5DqzKhhZCvhQQnkfaa/if8i+Hy0/SXfhyVQo1geZRzS/+Oe/WY9RcOsNVuUuk2Vudi3LEejLvOUnkZriparO2p6TquA==; 31:AQH9Cm+U0yVqv0jO/czzh4Vqul7ylAYrLd82W+OZMHsO1ZoE9qW7QmAXK0YdXPXOB96lyW7zjhAjQZLbbzzhuLH38SRGKTD61JskEkJmv9AnoZyLhkJLJhuPxp/tt/mM8LRjYhVCPBUvxIYfAkJ1L+SKsEgbQEIYUx0oAhEsydDwTJpcCiiPoKOblk89yL+AfR2r0DUQ/PAKU0/5Gv00xDXC+xaz1zyctB1QnnDJXR8= X-MS-TrafficTypeDiagnostic: VI1PR05MB3501: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=charlie@atech.media; X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB3501; 20:s3vE0ZoDtyQd1O54M2lWMPBuvpMAQr2IrGGIgRwTbZH+RqgP7u/qku/nMl3JMqw2obcjuRiUprKkODMiEtCeNZFOXkF4Cq45gP3qY+rW9K1AWqUNEoiXpwxjKWlmlBoxrNe3COw/NIN7aRFYU8P/frQd66ElebEqoMtSxH/9AKl59B/oZjKDW097x7jI4f6n1h1zyCjxptD6qyhCanXPdu7+ZxI2JFQsLj7sCqsDxlOgEuFSDoiK6bloBG9Mqzib; 4:eeCOhu1+Q4PxWE3PuX0i+/WY/LzWFOxnXZ+8g1viUlT0QmGAWbzXuuSMPb70ksbqdNGQqDtJyyIxJ6kQP1KCHtNXBl2OAdim2SbfTn7+oZiXnl9V0qeWwzT7Txx7u3DiNXi4/OLpySVnaCCxH3rNiyadm6KtKL+B+8xn7SBFs+4dk6KGjaZFnhyKXFrIR8AbyXDfRys1ZNmZ1TmdszcFxKaHqaFV3nuv8+5isIFrFz/SZpv79pqR14LwlAU+S660V+LFZnB4gCjU6iZARjx35Q== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231023)(944501075)(93006095)(93001095)(6041268)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(2016111802025)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:VI1PR05MB3501; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR05MB3501; X-Forefront-PRVS: 05352A48BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(376002)(39380400002)(396003)(346002)(39830400003)(52544003)(24454002)(189003)(199004)(7736002)(105586002)(53936002)(50466002)(64126003)(6306002)(2351001)(6246003)(106356001)(86362001)(16526018)(97736004)(229853002)(25786009)(478600001)(966005)(6486002)(6666003)(81156014)(2361001)(31696002)(31686004)(47776003)(8676002)(77096006)(65806001)(65956001)(66066001)(65826007)(2906002)(2950100002)(6916009)(5660300001)(6116002)(3846002)(575784001)(305945005)(2486003)(59450400001)(67846002)(68736007)(23676004)(76176011)(58126008)(52146003)(81166006)(3480700004)(8936002)(83506002)(52116002)(8746002)(33896004)(386003)(16576012)(316002)(53546011)(46492003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB3501; H:[10.0.8.11]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: atech.media does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA1TUIzNTAxOzIzOlhnVWsra2V4djhwcFNER01HTTFWUEozTWtC?= =?utf-8?B?eGNRcjdPVy9HVEEwWGlKNWhZb2kvL3YybUFIZWNEbmIyeDh4VFQzUDNsT3B6?= =?utf-8?B?YWwxb2U0RGpkN3JnVzRoaW9ZNFp0eDN2NmJGcGpJVnhvRnNlaS84bm9lMWpQ?= =?utf-8?B?dFk0UXVnc1lpcnJrc2VrR05CVE83clpMZnpBOGNMTzIxTW0ydGQ4clUyc2xo?= =?utf-8?B?c2dWQWFnZU51VGFsbFBxWDYxYmRxTmNiMEJoazVwK1FMSlE3am9mc2c5NTZZ?= =?utf-8?B?RW1DU1U0dTB3QTNpRHhwZjJZK1dOOUROaFlmL3k5ejJqb1dPTTVYS1pPWEpa?= =?utf-8?B?YUNKem1UWnI1YlQ0MlJEQU9rKzBkUXVMQVdJeGxxVjVTUDFqRGJvV0ZVbWEy?= =?utf-8?B?VWlaQnN2R2srcGp5MUxjbXArbWpBV2ZDMTBLVEJZZlU2cUcvODZmWjZLQlhq?= =?utf-8?B?YWpTcEZyMjFFbUdDWXVva2UzUDlJbHNPd1Q5V2N4VXNlcWcvTGZuOFJyR2pK?= =?utf-8?B?b2krUzFsVlJtSW52R0RRcGFlWXdJQ09Vclk1ZGZjMVJWQzUrbC8weE81ME1S?= =?utf-8?B?a2ZiVkQzNFBjZ1o0eHVjVWUxOFN5Sk9RQm0wWThXSDdDWTJ6TGdlTFduVFZX?= =?utf-8?B?LzdGbEl1eGZnMHNHblhVQzBYYUFQZ2ZwdzJpZ3VkbjFkek95bVJZWmVHdnpj?= =?utf-8?B?eGdhc3hGeTVMZmxGM1NnZ3dhRW9aQlZvVUtaUkl5V2paR0E3ajRTREExMHBv?= =?utf-8?B?L0FNOUwvNlpWeFo1Z3ZWc0EwNWVqMTViVVlnQ1BMb2F4SVdnalhkMUlhTGxK?= =?utf-8?B?Z2poaHZFS2pBVDhLVHEvb1NoRk11VzFhWFFFZjlVYUVoYldzMGhNcGxJdElD?= =?utf-8?B?Y2hmenRTQ0JxOTU0czdHaWYwUTZBall0a0tKUUEvckFlUXh2R2NSUTZtckwz?= =?utf-8?B?ZG1sWUUremlvcFNtV1EwK0Z2WTFVcnFvWUVpSTMwRisvOUhyYW9ndlFWN3Fs?= =?utf-8?B?YjQwWXNsYTFGc3RBOTdHaHhiNGYrVzF0RXl2U3UwWDBqeTVoZXlyWVdtN29G?= =?utf-8?B?MVB4UW5kWEtiZ1VWOEFnbXhwTEtaZjgvYlRINjFzdk5YUWdic29CTXJFQmlV?= =?utf-8?B?bTdPbXk3UVUwRVBvV0E5YjZKckFsaFRuUlJBM01xaGpuZDZLdkxVUUh6ditV?= =?utf-8?B?UUJ4WTNPZVZkU0d0bjhmOFZtc00rQTVHT0JSeXQrbnp4aTcrM05wVGF2RHU0?= =?utf-8?B?eXo3QUl4VWJvR250ZWd2dlFrOWtxVnY1TVlTLzArK2VuSm1HNTJERWJyWDl4?= =?utf-8?B?aFpOTFNyemxGZXByNjViSFczVUEwcEk2dzlNZmZHYmZWdFFFY2c3NjBPaGpE?= =?utf-8?B?eHZEM0l3T2lUM3dab1d5bUdLb1h1c1NiSDdHU1NhTUZWOG8wMnA3UENvYk1C?= =?utf-8?B?ZDdXOHlwY0wva21KdFgwczdQSTVBdmd2RzBuM1cxeW1pRHJnWnVYRGhSdFYz?= =?utf-8?B?aU9NZXRsWm82eGJmbHpVWnBVWTRhdC9hWkQ1VHR0K3d4cUtGSFphNEI4VlZp?= =?utf-8?B?SUVQVWNlN01rWW1xRElCQ0pMS2c0RWtoYms3YThTaWRpRG5HUWI3MWRPbzN0?= =?utf-8?B?V1luMXFFQ0xTb3dXMnBBUll4bzJjaFd4NEV6YXBJbHhpNC9tWndmTEhyb2Vk?= =?utf-8?B?WGZuODdzeTdHUlRVbG9kcjF4cnlnNHQwUktiTlQ3ZXZRZzkwb0ZSZnp4Szlw?= =?utf-8?B?RmFsN1lEeG9DdzNyZG1JbGRDNHA0eTFUODQ3L3pUZFlsaHN5bG1zTldMTHMv?= =?utf-8?B?NGJtYXRUdXVlSTlydXplcCtFYmFoSmd6MVJ0czZyaVcvQWlXNDcvSXR4UWdC?= =?utf-8?B?SzRKZU9lNkhLWlpzaWc0bitNUFhaNjNmZVVoOXczZ2t2S3hLSm5OM1kvekZY?= =?utf-8?B?bVAvVTJMTzJSdTd3MWorUE5qKzVHcU1PTjJOWGRBUmhNNU5lY2FHU0l5cnVV?= =?utf-8?B?QVVPUlhKL3UxRjZ4R0Vlc1NZR3NBQkh0cUpvbjRRSGVNNkFSeUFWMFZZUkUr?= =?utf-8?Q?93BwU1nXnrrWZ4Q6CU7goQuDZ?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB3501; 6:LmPPLiYVfBmIEEjN/Y9mr76n/DoveLRsstNk9ZYHG7OMZ7hRsmC7LdpcB1GncbiIg0fpyth0YBAeGqyXHpiPDJzssLvKdccoPprVqc1icPL62NMrRQzQHC5jE5/hoLvFgVKsWTBtKt+PM5x60JSiGEMmtFfvciCqdaPEVRbF6jFAGJgIBYV6gZE9LvV7Wnd7W2XiF95YsgEHzF4iwZGy3w2BkXeX26La7S7W6li/7Ppl3agKJnleDu5mc+gMqbZHMTp+kc5P9tpgHmxtctsAzLHufl0+7kd82k1rtEhfEcR0ApTQ/riuV11rDvZPTrQuCdzbxYaTRczltR9YM2+gCYS7VLTqXLHS+Ad0ke0Lxu0=; 5:TOGTbZN7tV/NOf4bBUVnsqzkYpYouLQ8YMsQ+KNTW9Cof96clGQner/CM3cBFOMPjjcvGZkPQkazZiljSPeLlUO1Z9LGLIJDz4+surva/tHF2+LUTYDrisLxAHGe27j29Vlm4+cywn2Z3zhVbQMQvzlA0d8Bc6/tBi5HjNo8J7Y=; 24:bHy178MSWGdrmBu1V6IY+jlvfBCchZo4vPdDcza2rLpFh3nMl50xrlLFy56P+Ct4H6MP4/AOqAXKi5IzkK2d84Nz/cVpv0BrWdZqDQk4xag=; 7:Etkj5Nh/7GKjYVqGCQIQx5k9n4MK6hKhRB++Z19aAtjg5jNySw0j4mPk/ZDPqhXlJP9UeKQ9dpoZkNAKYhpa7E2OLg+sYnOCyryEV1f/dexorfrkTNRPB5+1GYQG++acqM3g0l863cT1BTBkzbEKGvhMXUO8tqPmQYVkTeyHuQN6r/RWr2eylQ4NATmOcGjh1EloQ+KsG41En0W4JzYv0opvEjBiZtOL83RIvd5JkH2CWZEGlC9vT8PjqTOTRrty SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: atech.media X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Dec 2017 23:14:50.3968 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e05b2625-bc4d-4325-62fa-08d54e48cbc8 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a8f6edf-720f-4e3d-b767-1360e39a8cdf X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB3501 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 28 Dec 2017 23:14:56 -0000 Hi, To answer my own question, I have resolved this, there were seemingly 3 errors in my use of the API: 1) I did not initialize the req struct. Some uninitialized data were being passed to the ioctl. I feel silly. 2) Values greater then 1 do not seem to be accepted by nr_arg2, setting this to 1, or to 0 (which resolves to 1) works. 3) When fixing the above, the memory size is always 343019520, plenty for my requirement. Thanks, Charlie On 28/12/17 17:34, Charlie Smurthwaite wrote: > Hi, > > I'm just starting to use netmap and it is my intention to do zero-copy > forwarding of frames between a large number of NICs. I am using Intel > i350 (igb) on Linux. I therefore require a large memory area for rings > and buffers. > > My calculation: > 32 NICs * 2 rings (TX+RX) * 256 frames * 2048 bytes =3D 32MB > > I am currently having a problem (or perhaps just a misunderstanding) > regarding allocation of this memory. I am attempting to use the > following code: > > void thread_main(int thread_id) { > struct nmreq req; // A struct for the netmap request > int fd; // File descriptor for netmap socket > void * mem; // Pointer to allocated memory area > > fd =3D open("/dev/netmap", 0); // Open a generic netmap socket > strcpy(req.nr_name, "enp8s0f0"); // Copy NIC name into request > req.nr_version =3D NETMAP_API; // Set version number > req.nr_flags =3D NR_REG_ONE_NIC; // We will be using a single hw ring > > // Select ring 0, disable TX on poll > req.nr_ringid =3D NETMAP_NO_TX_POLL | NETMAP_HW_RING | 0; > > // Ask for 64 additional rings to be allocated (32 * (TX+RX)) > req.nr_arg1 =3D 64; > > // Allocate a separate memory area for each thread > req.nr_arg2 =3D 10 + thread_id; > > // Ask for additional buffers (256 per ring) > req.nr_arg3 =3D 64*256; > > // Initialize port > ioctl(fd, NIOCREGIF, &req); > > // Check the allocated memory size > printf("memsize: %u\n", req.nr_memsize); > // Check the allocated memory area > printf("nr_arg2: %u\n", req.nr_arg2); > } > > The output is as follows: > > memsize: 4206859 > nr_arg2: 10 > > This is far short of the amount of memory I am hoping to be allocated. > Am I doing something wrong, or is this simply an indication that the > driver is unwilling to allocate more than 4MB? > > A secondary (related) problem is that if I don't set arg1,arg2,arg3 in > my code (ie they will be zero), then I get varying output (it varies > between each of the following): > > memsize: 4206843 > nr_arg2: 0 > > memsize: 343019520 > nr_arg2: 1 > > Any pointers would be appreciated. Thanks! > > Charlie Charlie Smurthwaite Technical Director tel. email. charlie@atech.media web. https://a= tech.media This e-mail has been sent by aTech Media Limited (or one of its assoicated = group companys, Dial 9 Communications Limited or Viaduct Hosting Limited). = Its contents are confidential therefore if you have received this message i= n error, we would appreciate it if you could let us know and delete the mes= sage. aTech Media Limited is a UK limited company, registration number 5523= 199. Dial 9 Communications Limited is a UK limited company, registration nu= mber 7740921. Viaduct Hosting Limited is a UK limited company, registration= number 8514362. All companies are registered at Unit 9 Winchester Place, N= orth Street, Poole, Dorset, BH15 1NX. From owner-freebsd-net@freebsd.org Fri Dec 29 01:56:07 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23C1CEA19BB for ; Fri, 29 Dec 2017 01:56:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11729764F7 for ; Fri, 29 Dec 2017 01:56:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBT1u4B2089741 for ; Fri, 29 Dec 2017 01:56:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Fri, 29 Dec 2017 01:56:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: wollman@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Dec 2017 01:56:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 --- Comment #10 from Garrett Wollman --- (In reply to Ryan Stone from comment #7) Doesn't seem to have made any difference. (Had to wait for the post-Xmas outage window now that this server is in production.) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Dec 29 02:52:45 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E132EA46CC for ; Fri, 29 Dec 2017 02:52:45 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3FAB7802D; Fri, 29 Dec 2017 02:52:44 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id f140so46157688wmd.2; Thu, 28 Dec 2017 18:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pPESrq8xIErFyjccG0USH5QS78qh4d2HEI2raxMSKN8=; b=cg2I68dNgQwXRW2xMeFc4ab4zAiQdcV+Q8J98ks1M43P5AkzigleDpe5p4LUHxg3cj lCXmP+D8Wnm0HSprgMCnxuVhYp4GAsNxANCD08mcs4/lCW+ohAQPxn8IgTjgyiIoxYMF RSOlbbt4b+mWiEsuxySt8J2D/+DoNDjQyLkqcYODKDHb0VWKDqf2xTAgtU0vjM/1SK2l QH8wHvvBcCHwomETnZDGVZmnOheS1J2bHqFUDgHZw4RIfKzlfEh8x/SfihBAH56aWs2N QEVJIPgNbfwDv1XPn1zSj85s5ce7SAxvmSA5iu6eeGKdOzf2FfyRVyRb6h9MFV0/wCgA urjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pPESrq8xIErFyjccG0USH5QS78qh4d2HEI2raxMSKN8=; b=m1IM/VB1niG3HVXRUxcAazAfPw4nL7LHIIS7hjkTCuW7Gs4+7CbxkBwlQg6wee0QX8 YhouwwOVvXKfwXriz5aamTBIeJFtXp9hHjSZudU+8sQJXvpYhKq5vyOHVK7OyvXuLUB0 Nx2l7pfeJZHNQ9fPdgEpQxSDA/weBZo7aWsxnbBdabxO86lGZC1X5MKybYAWHsX1JFNj l5BKu96iWuT57jyTeBPqza777bfLSMR3Alxb6ORx1GMi7sFZmx/q4iVhferu8aXpicnU NZ5DTd589393if15WJlPgofKQHa8GzpZC6dj//a39bxswE8Dvn8mNoBnQgtFRMQCF/+Y fSkA== X-Gm-Message-State: AKGB3mKt7IdWF1y2UlkhvtB38DXLSQP3ZsHO+/ey+AgzLH58M7FLVDFY OUwICgMpBG9FLVqTqrqE5qUZDolbL64K+axvEX81vnvQ X-Google-Smtp-Source: ACJfBouj43eAArrqaJsCbsUoi+yzX2tRYjyVW/Pb9g4QVxdzyKISYvJm1FCsD4gZtRJJVFKvwzQAexFVfLfkMQIzRAE= X-Received: by 10.80.230.3 with SMTP id y3mr43176145edm.211.1514515963201; Thu, 28 Dec 2017 18:52:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Thu, 28 Dec 2017 18:52:22 -0800 (PST) In-Reply-To: <4fee4ea6-9b35-afba-6d5d-24ecca3e28c6@freebsd.org> References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> <4fee4ea6-9b35-afba-6d5d-24ecca3e28c6@freebsd.org> From: John Lyon Date: Thu, 28 Dec 2017 21:52:22 -0500 Message-ID: Subject: Re: Need Netgraph Help [fixed] To: Julian Elischer Cc: "freebsd-net@freebsd.org" , Eugene Grosbein Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Dec 2017 02:52:45 -0000 It works!!! In virtual machine land at least, it works! It will be interesting to see what happens when the rubber meets the road and I actually test it "in the field." The issue was a missing single line that was not obvious from the man pages= : sudo ngctl connect eapfilter: ix1: eapout lower Apparently, I had not created an alias for the connection between the ETF and the ether nodes. Once this connect command was issued, the connection to the lower hook of the ether node was ready to be connected to the ETF. Thanks *so much* for your help. -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Thu, Dec 28, 2017 at 9:48 AM, Julian Elischer wrote= : > On 28/12/17 9:59 pm, Julian Elischer wrote: > >> On 28/12/17 1:37 am, John Lyon wrote: >> >>> Julian, >>> >>> Unfortunately, this issue remains unresolved. I would like to think >>> that this is just a PEBKAC issue, but I have tried every permutation of >>> escape characters in case it's an issue with my syntax and I get the sa= me >>> set of errors. No matter what I do, I can't connect the no match hook = of >>> an ETF node to the upper hook of an ng_ether node. Do you have any >>> insights into why this might be occurring? >>> >>> By the way, thanks for reaching out to me! I was going to email you >>> directly after the holidays since your name and email address are at th= e >>> bottom of the relevant Netgraph man pages. I figured that must mean if= you >>> didn't know the answer, no one does. :-) >>> >> >> what is EAP? >> what about return EAP packets? (are there any?) >> > > oops left out a line from the cut-n-paste... > >> >> I think this is what you want: >> $ sudo ngctl list >> There are 7 total nodes: >> Name: igb0 Type: ether ID: 00000001 Num hooks: = 0 >> Name: igb1 Type: ether ID: 00000002 Num hooks: = 0 >> Name: ix0 Type: ether ID: 00000003 Num hooks: = 0 >> Name: ix1 Type: ether ID: 00000004 Num hooks: = 0 >> Name: tap0 Type: ether ID: 00000005 Num hooks: = 0 >> Name: bridge3 Type: ether ID: 00000006 Num hooks: = 0 >> Name: ngctl7372 Type: socket ID: 00000007 Num hooks: = 0 >> $ sudo kldload ng_etf >> > $ sudo ngctl mkpeer ix0: etf lower downstream > >> $ sudo ngctl name ix0:lower eapfilter >> $ sudo ngctl connect eapfilter: ix0: nomatch upper >> $ sudo ngctl connect eapfilter: ix1: eapout lower >> $ sudo ngctl show eapfilter: >> Name: eapfilter Type: etf ID: 00000021 Num hooks: = 3 >> Local hook Peer name Peer type Peer ID Peer hook >> ---------- --------- --------- ------- --------- >> eapout ix1 ether 00000004 lower >> nomatch ix0 ether 00000003 upper >> downstream ix0 ether 00000003 lower >> $ sudo ngctl msg eapfilter: 'setfilter { matchhook=3D"eapout" >> ethertype=3D0x888e }' >> $ >> >> >> >>> Thanks. >>> >>> >>> -------------------------------- >>> John L. Lyon >>> PGP Key Available At: >>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>> >>> On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer >> > wrote: >>> >>> John did you get a resolution to this issue? >>> >>> >>> On 16/12/17 2:59 am, John Lyon wrote: >>> >>> Harry and Eugene (and others), >>> >>> I appreciate all of your help. It's been really >>> insightful. Although I >>> feel like I'm getting much closer to the solution, I don't >>> think my problem >>> has been diagnosed. I've outlined my thought process >>> below. Can you >>> please tell me if I am misunderstanding something? >>> Admittedly, I am not a >>> kernel developer and my C language skills have atrophied the >>> last few >>> years. However, I've reviewed my script and I looked in the >>> code for >>> ng_etf.c and I don't think I am violating any of the >>> requirements for >>> linking a hook for no match. >>> >>> As Eugene stated: >>> >>> 1) referenced "matchook" exists and you should not >>> use "indirect name" >>> >>> here, >>> >>> only hook own name, or else you get error ENOENT (No >>> such file or >>> >>> directory); >>> >>> This does not seem to be a problem as the upper and lower >>> hooks for the em1 >>> already exist (I can confirm this). >>> >>> 2) referenced "matchook" is *not* downstream hook, >>> or else you get error >>> EINVAL (Invalid argument); >>> >>> I read the ng_etf.c file in the source tree and found this >>> little snippet: >>> >>> /* and is not the downstream hook */ >>> if (hook =3D=3D etfp->downstream_hook.hook) { >>> error =3D EINVAL; >>> break; >>> } >>> >>> This appears to be an error check to make sure you are not >>> creating a cycle >>> in the graph by referencing the ETF node's own downstream >>> hook (i.e. >>> filtering incoming traffic and circularly feeding >>> non-matching frames back >>> into the ETF's own filter). I'm not doing this. I am >>> feeding non-matching >>> packets into the *lower* hook of another ether node and not >>> back into the >>> *downstream* hook of the etf node I am creating. As a >>> result, my netgraph >>> should not be triggering this error condition. >>> >>> 3) it was not already configured, or else you get >>> error EEXIST (File >>> >>> exists). >>> >>> I am not getting this error, so it appears not to be an >>> issue in my case. >>> >>> What am I missing here? The man page states that "*any >>> other *hook" can be >>> >>> used for the non-matching packets. So the man page says >>> this should work, >>> and there's no explicit error condition that I see (caveat, >>> I have not >>> written in C for at least 10 years - PEBKAC is entirely >>> possible) that >>> would be triggered in the ng_etf code. So what is going wrong? >>> >>> Thanks for all of your help, patience, and understanding. >>> >>> >>> -------------------------------- >>> John L. Lyon >>> PGP Key Available At: >>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>> >>> >>> On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >>> > >>> wrote: >>> >>> Bez=C3=BCglich Eugene Grosbein's Nachricht vom 14.12.2017 >>> 23:07 (localtime): >>> >>> 15.12.2017 4:27, John Lyon wrote: >>> >>> I'm a new Netgraph user, but am having >>> some problems with a simple >>> Netgraph >>> script I have written. Unfortunately, >>> the error message is cryptic >>> >>> and I >>> >>> can't tell what I am doing wrong since >>> my script closely follows the >>> example provided in the ng_etf man page. >>> >>> For some context, I'm trying to filter >>> EAP traffic coming in on my LAN >>> interface. Any ethernet frames that >>> correspond to EAP traffic need >>> >>> to be >>> >>> immediately forwarded from the LAN >>> interface to my WAN interface. All >>> other ethernet frames coming in on my >>> LAN interface need to be >>> >>> handled by >>> >>> the kernel's network stack. A (horrid) >>> ASCII art representation of my >>> desired netgraph would look like this: >>> >>> lower -> em0 -> downstream -> ETF -> no >>> match -> upper em0 >>> -> match -> >>> lower em1 >>> >>> The script I have written is this: >>> >>> #! /bin/sh >>> ngctl mkpeer em0: etf lower downstream >>> ngctl name em0:lower lan_filter >>> ngctl connect em0: lan_filter: >>> upper nomatch >>> ngctl msg lan_filter: setfilter { >>> matchhook=3D"em1:lower" >>> ethertype=3D0x888e } >>> >>> Unfortunately, the last line of my >>> script generates the following >>> >>> error >>> >>> message: >>> >>> ngctl: send msg: Invalid Argument >>> >>> For "setfilter" command to work, ng_etf requires that: >>> >>> 1) referenced "matchook" exists and you should not >>> use "indirect name" >>> >>> here, >>> >>> only hook own name, or else you get error ENOENT (No >>> such file or >>> >>> directory); >>> >>> 2) referenced "matchook" is *not* downstream hook, >>> or else you get error >>> EINVAL (Invalid argument); >>> 3) it was not already configured, or else you get >>> error EEXIST (File >>> >>> exists). >>> >>> Eugene kindly looked into the code and found that the >>> error is due to >>> wrong matchhook definition. >>> I've never had any contact with ng_etf yet, but >>> according to the man >>> page, you need to set the (additional) filter hook by >>> 'nghook -a >>> lan_filter: mydrain' and use 'matchhook=3Dmydrain' for the >>> 'msg' command. >>> >>> Do idea about the intention, so for the rest you have to >>> tweak as needed. >>> >>> -harry >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org >>> mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> >>> To unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@freebsd.org >>> " >>> >>> >>> >>> >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> > From owner-freebsd-net@freebsd.org Fri Dec 29 08:58:03 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82173EB2B5D for ; Fri, 29 Dec 2017 08:58:03 +0000 (UTC) (envelope-from julian@freebsd.org) 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 56A4329FB for ; Fri, 29 Dec 2017 08:58:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBT8vphs007687 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Dec 2017 00:57:56 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help [fixed] To: John Lyon Cc: "freebsd-net@freebsd.org" , Eugene Grosbein References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> <4fee4ea6-9b35-afba-6d5d-24ecca3e28c6@freebsd.org> From: Julian Elischer Message-ID: <17173623-2aee-4259-6bd3-6ba0bfd7e404@freebsd.org> Date: Fri, 29 Dec 2017 16:57:45 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Dec 2017 08:58:03 -0000 On 29/12/17 10:52 am, John Lyon wrote: > It works!!!  In virtual machine land at least, it works!  It will be > interesting to see what happens when the rubber meets the road and I > actually test it "in the field." > > The issue was a missing single line that was not obvious from the > man pages: > >     sudo ngctl connect eapfilter: ix1: eapout lower > > Apparently, I had not created an alias for the connection between > the ETF and the ether nodes.  Once this connect command was issued, > the connection to the lower hook of the ether node was ready to be > connected to the ETF. The  shown line assigns a linkage for matching frames to use. Until it exists, you can not use it in a rule. Match rules can only reference existing hooks. > > Thanks _so much_ for your help. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Thu, Dec 28, 2017 at 9:48 AM, Julian Elischer > wrote: > > On 28/12/17 9:59 pm, Julian Elischer wrote: > > On 28/12/17 1:37 am, John Lyon wrote: > > Julian, > > Unfortunately, this issue remains unresolved.  I would > like to think that this is just a PEBKAC issue, but I > have tried every permutation of escape characters in > case it's an issue with my syntax and I get the same set > of errors.  No matter what I do, I can't connect the no > match hook of an ETF node to the upper hook of an > ng_ether node.  Do you have any insights into why this > might be occurring? > > By the way, thanks for reaching out to me!  I was going > to email you directly after the holidays since your name > and email address are at the bottom of the relevant > Netgraph man pages.  I figured that must mean if you > didn't know the answer, no one does. :-) > > > what is EAP? > what about return EAP packets? (are there any?) > > > oops left out a line from the cut-n-paste... > > > I think this is what you want: > $ sudo ngctl list > There are 7 total nodes: >   Name: igb0            Type: ether           ID: 00000001   > Num hooks: 0 >   Name: igb1            Type: ether           ID: 00000002   > Num hooks: 0 >   Name: ix0             Type: ether           ID: 00000003   > Num hooks: 0 >   Name: ix1             Type: ether           ID: 00000004   > Num hooks: 0 >   Name: tap0            Type: ether           ID: 00000005   > Num hooks: 0 >   Name: bridge3         Type: ether           ID: 00000006   > Num hooks: 0 >   Name: ngctl7372       Type: socket          ID: 00000007   > Num hooks: 0 > $ sudo kldload ng_etf > > $ sudo ngctl mkpeer ix0: etf lower downstream > > $ sudo ngctl name ix0:lower eapfilter > $ sudo ngctl connect eapfilter: ix0: nomatch upper > $ sudo ngctl connect eapfilter: ix1: eapout lower > $ sudo ngctl show eapfilter: >   Name: eapfilter       Type: etf             ID: 00000021   > Num hooks: 3 >   Local hook      Peer name       Peer type    Peer ID Peer hook >   ----------      ---------       --------- ------- --------- >   eapout          ix1             ether 00000004 lower >   nomatch         ix0             ether 00000003 upper >   downstream      ix0             ether 00000003 lower > $ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" > ethertype=0x888e }' > $ > > > > Thanks. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > > On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer > > >> > wrote: > >     John did you get a resolution to this issue? > > >     On 16/12/17 2:59 am, John Lyon wrote: > >         Harry and Eugene (and others), > >         I appreciate all of your help.  It's been really >         insightful.  Although I >         feel like I'm getting much closer to the > solution, I don't >         think my problem >         has been diagnosed.  I've outlined my thought > process >         below.  Can you >         please tell me if I am misunderstanding something? >         Admittedly, I am not a >         kernel developer and my C language skills have > atrophied the >         last few >         years.  However, I've reviewed my script and I > looked in the >         code for >         ng_etf.c and I don't think I am violating any of the >         requirements for >         linking a hook for no match. > >         As Eugene stated: > >                 1) referenced "matchook" exists and you > should not >                 use "indirect name" > >         here, > >                 only hook own name, or else you get > error ENOENT (No >                 such file or > >         directory); > >         This does not seem to be a problem as the upper > and lower >         hooks for the em1 >         already exist (I can confirm this). > >                 2) referenced "matchook" is *not* > downstream hook, >                 or else you get error >                 EINVAL (Invalid argument); > >         I read the ng_etf.c file in the source tree and > found this >         little snippet: > >         /* and is not the downstream hook */ >         if (hook == etfp->downstream_hook.hook) { >              error = EINVAL; >              break; >         } > >         This appears to be an error check to make sure > you are not >         creating a cycle >         in the graph by referencing the ETF node's own > downstream >         hook (i.e. >         filtering incoming traffic and circularly feeding >         non-matching frames back >         into the ETF's own filter).  I'm not doing > this.  I am >         feeding non-matching >         packets into the *lower* hook of another ether > node and not >         back into the >         *downstream* hook of the etf node I am > creating.  As a >         result, my netgraph >         should not be triggering this error condition. > >                 3) it was not already configured, or > else you get >                 error EEXIST (File > >         exists). > >         I am not getting this error, so it appears not > to be an >         issue in my case. > >         What am I missing here?  The man page states > that "*any >         other *hook" can be > >         used for the non-matching packets.  So the man > page says >         this should work, >         and there's no explicit error condition that I > see (caveat, >         I have not >         written in C for at least 10 years  - PEBKAC is > entirely >         possible) that >         would be triggered in the ng_etf code.  So what > is going wrong? > >         Thanks for all of your help, patience, and > understanding. > > >         -------------------------------- >         John L. Lyon >         PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > > > >         On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >         > >> >         wrote: > >             Bezüglich Eugene Grosbein's Nachricht vom > 14.12.2017 >             23:07 (localtime): > >                 15.12.2017 4:27, John Lyon wrote: > >                             I'm a new Netgraph user, but > am having >                             some problems with a simple >                             Netgraph >                             script I have written. > Unfortunately, >                             the error message is cryptic > >             and I > >                             can't tell what I am doing > wrong since >                             my script closely follows the >                             example provided in the > ng_etf man page. > >                             For some context, I'm trying > to filter >                             EAP traffic coming in on my LAN >                             interface.  Any ethernet > frames that >                             correspond to EAP traffic need > >             to be > >                             immediately forwarded from > the LAN >                             interface to my WAN > interface.  All >                             other ethernet frames coming > in on my >                             LAN interface need to be > >             handled by > >                             the kernel's network stack. > A (horrid) >                             ASCII art representation of my >                             desired netgraph would look > like this: > >                             lower -> em0 -> downstream > -> ETF -> no >                             match -> upper em0 >                                             -> match -> >                             lower em1 > >                             The script I have written is > this: > >                                  #! /bin/sh >                                  ngctl mkpeer em0: etf > lower downstream >                                  ngctl name em0:lower > lan_filter >                                  ngctl connect em0: > lan_filter: >                             upper nomatch >                                  ngctl msg lan_filter: > setfilter { >                             matchhook="em1:lower" >                             ethertype=0x888e } > >                             Unfortunately, the last line > of my >                             script generates the following > >             error > >                             message: > >                                  ngctl: send msg: > Invalid Argument > >                 For "setfilter" command to work, ng_etf > requires that: > >                 1) referenced "matchook" exists and you > should not >                 use "indirect name" > >             here, > >                 only hook own name, or else you get > error ENOENT (No >                 such file or > >             directory); > >                 2) referenced "matchook" is *not* > downstream hook, >                 or else you get error >                 EINVAL (Invalid argument); >                 3) it was not already configured, or > else you get >                 error EEXIST (File > >             exists). > >             Eugene kindly looked into the code and found > that the >             error is due to >             wrong matchhook definition. >             I've never had any contact with ng_etf yet, but >             according to the man >             page, you need to set the (additional) > filter hook by >             'nghook -a >             lan_filter: mydrain' and use > 'matchhook=mydrain' for the >             'msg' command. > >             Do idea about the intention, so for the rest > you have to >             tweak as needed. > >             -harry > > >         _______________________________________________ > freebsd-net@freebsd.org > > >         mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > > >         To unsubscribe, send any mail to >         "freebsd-net-unsubscribe@freebsd.org > >         >" > > > > > > _______________________________________________ > freebsd-net@freebsd.org > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org > " > > > > From owner-freebsd-net@freebsd.org Fri Dec 29 09:06:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33379EB3425 for ; Fri, 29 Dec 2017 09:06:27 +0000 (UTC) (envelope-from julian@freebsd.org) 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 113643257 for ; Fri, 29 Dec 2017 09:06:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBT96HKT007719 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Dec 2017 01:06:23 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Need Netgraph Help [fixed] To: John Lyon Cc: "freebsd-net@freebsd.org" , Eugene Grosbein References: <5A3225BF.6020205@omnilan.de> <5A32F63E.8010205@grosbein.net> <5A338C5A.20300@omnilan.de> <2e0525c8-2251-a5f5-45d1-fe44ebe318f7@freebsd.org> <4fee4ea6-9b35-afba-6d5d-24ecca3e28c6@freebsd.org> From: Julian Elischer Message-ID: <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> Date: Fri, 29 Dec 2017 17:06:12 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Dec 2017 09:06:27 -0000 On 29/12/17 10:52 am, John Lyon wrote: > It works!!!  In virtual machine land at least, it works!  It will be > interesting to see what happens when the rubber meets the road and I > actually test it "in the field." > > The issue was a missing single line that was not obvious from the > man pages: > >     sudo ngctl connect eapfilter: ix1: eapout lower your next issue will be that you can only attach em1:lower to a single peer at a time. So return packets can not DTRT. You will need to either put a multiplexing node in each interface, OR if I wrote it correctly, use the fact that packets fed into an etf match hook will feed back out the input hook. so you need this: em0]lower---downstream[ETF0]nomatch---upper[em0... eapout | | eapout em1]lower---downstream[ETF1]nomatch---upper[em1... ie. use an etf node on each interface. > > Apparently, I had not created an alias for the connection between > the ETF and the ether nodes.  Once this connect command was issued, > the connection to the lower hook of the ether node was ready to be > connected to the ETF. > > Thanks _so much_ for your help. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Thu, Dec 28, 2017 at 9:48 AM, Julian Elischer > wrote: > > On 28/12/17 9:59 pm, Julian Elischer wrote: > > On 28/12/17 1:37 am, John Lyon wrote: > > Julian, > > Unfortunately, this issue remains unresolved.  I would > like to think that this is just a PEBKAC issue, but I > have tried every permutation of escape characters in > case it's an issue with my syntax and I get the same set > of errors.  No matter what I do, I can't connect the no > match hook of an ETF node to the upper hook of an > ng_ether node.  Do you have any insights into why this > might be occurring? > > By the way, thanks for reaching out to me!  I was going > to email you directly after the holidays since your name > and email address are at the bottom of the relevant > Netgraph man pages.  I figured that must mean if you > didn't know the answer, no one does. :-) > > > what is EAP? > what about return EAP packets? (are there any?) > > > oops left out a line from the cut-n-paste... > > > I think this is what you want: > $ sudo ngctl list > There are 7 total nodes: >   Name: igb0            Type: ether           ID: 00000001   > Num hooks: 0 >   Name: igb1            Type: ether           ID: 00000002   > Num hooks: 0 >   Name: ix0             Type: ether           ID: 00000003   > Num hooks: 0 >   Name: ix1             Type: ether           ID: 00000004   > Num hooks: 0 >   Name: tap0            Type: ether           ID: 00000005   > Num hooks: 0 >   Name: bridge3         Type: ether           ID: 00000006   > Num hooks: 0 >   Name: ngctl7372       Type: socket          ID: 00000007   > Num hooks: 0 > $ sudo kldload ng_etf > > $ sudo ngctl mkpeer ix0: etf lower downstream > > $ sudo ngctl name ix0:lower eapfilter > $ sudo ngctl connect eapfilter: ix0: nomatch upper > $ sudo ngctl connect eapfilter: ix1: eapout lower > $ sudo ngctl show eapfilter: >   Name: eapfilter       Type: etf             ID: 00000021   > Num hooks: 3 >   Local hook      Peer name       Peer type    Peer ID Peer hook >   ----------      ---------       --------- ------- --------- >   eapout          ix1             ether 00000004 lower >   nomatch         ix0             ether 00000003 upper >   downstream      ix0             ether 00000003 lower > $ sudo ngctl msg eapfilter: 'setfilter { matchhook="eapout" > ethertype=0x888e }' > $ > > > > Thanks. > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > > On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer > > >> > wrote: > >     John did you get a resolution to this issue? > > >     On 16/12/17 2:59 am, John Lyon wrote: > >         Harry and Eugene (and others), > >         I appreciate all of your help.  It's been really >         insightful.  Although I >         feel like I'm getting much closer to the > solution, I don't >         think my problem >         has been diagnosed.  I've outlined my thought > process >         below.  Can you >         please tell me if I am misunderstanding something? >         Admittedly, I am not a >         kernel developer and my C language skills have > atrophied the >         last few >         years.  However, I've reviewed my script and I > looked in the >         code for >         ng_etf.c and I don't think I am violating any of the >         requirements for >         linking a hook for no match. > >         As Eugene stated: > >                 1) referenced "matchook" exists and you > should not >                 use "indirect name" > >         here, > >                 only hook own name, or else you get > error ENOENT (No >                 such file or > >         directory); > >         This does not seem to be a problem as the upper > and lower >         hooks for the em1 >         already exist (I can confirm this). > >                 2) referenced "matchook" is *not* > downstream hook, >                 or else you get error >                 EINVAL (Invalid argument); > >         I read the ng_etf.c file in the source tree and > found this >         little snippet: > >         /* and is not the downstream hook */ >         if (hook == etfp->downstream_hook.hook) { >              error = EINVAL; >              break; >         } > >         This appears to be an error check to make sure > you are not >         creating a cycle >         in the graph by referencing the ETF node's own > downstream >         hook (i.e. >         filtering incoming traffic and circularly feeding >         non-matching frames back >         into the ETF's own filter).  I'm not doing > this.  I am >         feeding non-matching >         packets into the *lower* hook of another ether > node and not >         back into the >         *downstream* hook of the etf node I am > creating.  As a >         result, my netgraph >         should not be triggering this error condition. > >                 3) it was not already configured, or > else you get >                 error EEXIST (File > >         exists). > >         I am not getting this error, so it appears not > to be an >         issue in my case. > >         What am I missing here?  The man page states > that "*any >         other *hook" can be > >         used for the non-matching packets.  So the man > page says >         this should work, >         and there's no explicit error condition that I > see (caveat, >         I have not >         written in C for at least 10 years  - PEBKAC is > entirely >         possible) that >         would be triggered in the ng_etf code.  So what > is going wrong? > >         Thanks for all of your help, patience, and > understanding. > > >         -------------------------------- >         John L. Lyon >         PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > > > >         On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >         > >> >         wrote: > >             Bezüglich Eugene Grosbein's Nachricht vom > 14.12.2017 >             23:07 (localtime): > >                 15.12.2017 4:27, John Lyon wrote: > >                             I'm a new Netgraph user, but > am having >                             some problems with a simple >                             Netgraph >                             script I have written. > Unfortunately, >                             the error message is cryptic > >             and I > >                             can't tell what I am doing > wrong since >                             my script closely follows the >                             example provided in the > ng_etf man page. > >                             For some context, I'm trying > to filter >                             EAP traffic coming in on my LAN >                             interface.  Any ethernet > frames that >                             correspond to EAP traffic need > >             to be > >                             immediately forwarded from > the LAN >                             interface to my WAN > interface.  All >                             other ethernet frames coming > in on my >                             LAN interface need to be > >             handled by > >                             the kernel's network stack. > A (horrid) >                             ASCII art representation of my >                             desired netgraph would look > like this: > >                             lower -> em0 -> downstream > -> ETF -> no >                             match -> upper em0 >                                             -> match -> >                             lower em1 > >                             The script I have written is > this: > >                                  #! /bin/sh >                                  ngctl mkpeer em0: etf > lower downstream >                                  ngctl name em0:lower > lan_filter >                                  ngctl connect em0: > lan_filter: >                             upper nomatch >                                  ngctl msg lan_filter: > setfilter { >                             matchhook="em1:lower" >                             ethertype=0x888e } > >                             Unfortunately, the last line > of my >                             script generates the following > >             error > >                             message: > >                                  ngctl: send msg: > Invalid Argument > >                 For "setfilter" command to work, ng_etf > requires that: > >                 1) referenced "matchook" exists and you > should not >                 use "indirect name" > >             here, > >                 only hook own name, or else you get > error ENOENT (No >                 such file or > >             directory); > >                 2) referenced "matchook" is *not* > downstream hook, >                 or else you get error >                 EINVAL (Invalid argument); >                 3) it was not already configured, or > else you get >                 error EEXIST (File > >             exists). > >             Eugene kindly looked into the code and found > that the >             error is due to >             wrong matchhook definition. >             I've never had any contact with ng_etf yet, but >             according to the man >             page, you need to set the (additional) > filter hook by >             'nghook -a >             lan_filter: mydrain' and use > 'matchhook=mydrain' for the >             'msg' command. > >             Do idea about the intention, so for the rest > you have to >             tweak as needed. > >             -harry > > >         _______________________________________________ > freebsd-net@freebsd.org > > >         mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > > >         To unsubscribe, send any mail to >         "freebsd-net-unsubscribe@freebsd.org > >         >" > > > > > > _______________________________________________ > freebsd-net@freebsd.org > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org > " > > > > From owner-freebsd-net@freebsd.org Fri Dec 29 10:47:55 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 399B8E8177E for ; Fri, 29 Dec 2017 10:47:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27B1E65426 for ; Fri, 29 Dec 2017 10:47:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBTAlss1049549 for ; Fri, 29 Dec 2017 10:47:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 224247] [patch] RFC 6980 requires to drop fragmented IPv6 neighbour discovery Date: Fri, 29 Dec 2017 10:47:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 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, 29 Dec 2017 10:47:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224247 --- Comment #7 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Fri Dec 29 10:47:25 UTC 2017 New revision: 327337 URL: https://svnweb.freebsd.org/changeset/base/327337 Log: MFC r326876: Follow the RFC6980 and silently ignore following IPv6 NDP messages that had the IPv6 fragmentation header: o Neighbor Solicitation o Neighbor Advertisement o Router Solicitation o Router Advertisement o Redirect Introduce M_FRAGMENTED mbuf flag, and set it after IPv6 fragment reasse= mbly is completed. Then check the presence of this flag in correspondig ND6 handling routines. PR: 224247 Changes: _U stable/11/ stable/11/sys/netinet6/frag6.c stable/11/sys/netinet6/icmp6.c stable/11/sys/netinet6/in6.h stable/11/sys/netinet6/nd6_nbr.c stable/11/sys/netinet6/nd6_rtr.c --=20 You are receiving this mail because: You are the assignee for the bug.=