From owner-freebsd-net@freebsd.org Sun Dec 31 08:54: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 C22A7EAB49F for ; Sun, 31 Dec 2017 08:54:45 +0000 (UTC) (envelope-from gessel@blackrosetech.com) Received: from shiofuki.blackrosetech.com (shiofuki.blackrosetech.com [173.228.36.135]) (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 A81766993D for ; Sun, 31 Dec 2017 08:54:45 +0000 (UTC) (envelope-from gessel@blackrosetech.com) Received: from shiofuki (shiofuki [10.3.69.135]) by shiofuki.blackrosetech.com (Postfix) with ESMTP id 32C3C390EC3 for ; Sun, 31 Dec 2017 00:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at blackrosetech.com Received: from shiofuki.blackrosetech.com ([10.3.69.135]) by shiofuki (shiofuki.blackrosetech.com [10.3.69.135]) (amavisd-new, port 10024) with ESMTP id tCYaX7W58v4I for ; Sun, 31 Dec 2017 00:46:34 -0800 (PST) Received: from [10.2.69.6] (unknown [10.2.69.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gessel@blackrosetech.com) by shiofuki.blackrosetech.com (Postfix) with ESMTPSA id 621B0390EB7 for ; Sun, 31 Dec 2017 00:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackrosetech.com; s=BRTDKIM; t=1514709993; bh=1YUXrO9jnFqgylnBzTSt2m5jBQNVxVWY/lfjdLBuwnU=; h=To:From:Subject:Date; b=Ft44rcguWfLAzEkTPxoorzUz6hg6QhHCBG4i0h+hORreWc6W96vBicQQxjkP13+ae mg3MddFiU4D1Qko7padUsu40VXGf+Gp9lU6CH4xXW+Lon5JsgLo8O4VVXqW7hQT+uv V+TVfK+mbdA0eU7fD6IOyZBCreXUVqmoqRA/cdhk= To: freebsd-net@freebsd.org From: David Gessel Subject: Error logging: KLD if_en.ko depends on atm - not avail or version mismatch Message-ID: <8be9cc06-057e-699d-4393-a5eb69832b9c@blackrosetech.com> Date: Sun, 31 Dec 2017 11:46:29 +0300 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 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: Sun, 31 Dec 2017 08:54:45 -0000 FreeBSD 10.3-RELEASE #0 r327345 I'm getting a lot of errors that read: Dec 30 09:54:59 gamanjiru kernel: KLD if_en.ko: depends on atm - not available or version mismatch Dec 30 09:54:59 gamanjiru kernel: linker_load_file: Unsupported file type The source does not seem to be the jails, since stopping jails doesn't stop the error notifications. I've synced source, built world and kernel, installed both and yet the errors persist. I have a mildly customized kernel config, but I can't find any refrence to either if_en.ko nor "atm" kldstat -v | grep if 237 if_lo 104 if_ixgbe 235 if_faith 239 if_vlan 236 if_gif 238 if_tun # kldload if_en.ko kldload: an error occurred while loading the module. Please check dmesg(8) for more details. (which are the errors above) I'm really not sure what's calling if_en.ko (networking is working fine). Nor any idea why anything would ask for a "Midway-based ATM interface". There's no ATM hardware on the box. if_en isn't referenced at all in /bootpool/boot/loader.confand /bootpool/boot/defaults/loader.conf shows "if_en_load="NO" # Midway-based ATM interfaces" I asked at https://forums.freebsd.org/threads/63915/#post-370896 and was advised "You may be better asking on the freebsd-net mailing list. I know there's plans to remove ATM related stuff and the en driver was effected, but I don't think it should effect you." The errors are being generated in the host as well as all jails running on the system. Any leads very much appreciated. -David From owner-freebsd-net@freebsd.org Mon Jan 1 00:30:18 2018 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 293CAEAF54C for ; Mon, 1 Jan 2018 00:30:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 134E36AE88 for ; Mon, 1 Jan 2018 00:30:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w010UHCK059591 for ; Mon, 1 Jan 2018 00:30:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w010UHbL059590 for freebsd-net@FreeBSD.org; Mon, 1 Jan 2018 00:30:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 82470] FreeBSD advertises wrong window scale in some situations Date: Mon, 01 Jan 2018 00:30:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 5.4-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eadler@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 01 Jan 2018 00:30:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D82470 Eitan Adler changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #5 from Eitan Adler --- Inspection of code appears to show that this problem has since been fixed. = If I have mis-read the code please feel free to re-open. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 1 14:07:36 2018 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 E29EFEAB8B7 for ; Mon, 1 Jan 2018 14:07:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB9526E0C2 for ; Mon, 1 Jan 2018 14:07:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w01E7aTd071755 for ; Mon, 1 Jan 2018 14:07:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w01E7aFA071754 for freebsd-net@FreeBSD.org; Mon, 1 Jan 2018 14:07:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 224795] vlan interfaces created off tap devices do not work Date: Mon, 01 Jan 2018 14:07:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@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: 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: Mon, 01 Jan 2018 14:07:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224795 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jan 1 15:40:31 2018 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 DB4E9EAF0D0 for ; Mon, 1 Jan 2018 15:40:31 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B5A2970BBC for ; Mon, 1 Jan 2018 15:40:31 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B2466EAF0CE; Mon, 1 Jan 2018 15:40:31 +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 B1E36EAF0CD for ; Mon, 1 Jan 2018 15:40:31 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 6C2C470BBA for ; Mon, 1 Jan 2018 15:40:31 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qt0-x22e.google.com with SMTP id a16so60479822qtj.3 for ; Mon, 01 Jan 2018 07:40:31 -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=k0rCVedNhRNLz22UxZ1g6VOG+Ma7zP4R0CIjMstHZzw=; b=pzy16QOG/N0Tfy93CK94s800YHPe0ZFnxbf/w4PDQAuq2H5i/PieilY8aOrXnQYv6U SANsda5eZIm7Xbld2zZ2Fye9dRYEktQyHfsrdFkmNa0Cid2Dn587KRL8hZ4KqlpFKH9w hzdiLASKPdIJo5VHRojop051gd57ocEz1OCuTPvlv4N81qHQSP05968zgC/g63hjhCwE alEwTLcYLFMr0er8wNkQYsOZnyeNM3zesalqtB+3c3PWFMARKSwfY/mzuMFDJa5xlmuv xB2jbxGCEvb4SD3rGtnOLPkzetXA45nr81zbpd+qCLlEBNSL5CMEAkJvlMOa+GZgNsqf sIIA== 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=k0rCVedNhRNLz22UxZ1g6VOG+Ma7zP4R0CIjMstHZzw=; b=ULaJh2jdXL5MyNmbCKSgW+O/ftI8127F7D7uvFuh6X7wEjnnIK3BZbB4af6MPl5mRl YzvYxWDrmPCta9CIov57JyVBqzntZ4t3LvtdLk8jcAdrsdadsHRGEaRT5aLKrRQlqeNW URV8SnS/it/QIQCCF5rEEY+aMiiNKTrRamfXBOPNvxJgKHiLtJXpklemzEe5nYUEPYj/ FV9PuEymbMcUX364JU12S+twO06FF7E2ZVSIwFTg2CLyHt68Xunbv2BzbbTJfrN47Rph r+CVwDyWkVgp9wBu0TTYotmkHZv5vV+8S78eA8D/zdu90dsTjPj5FUxvt0CUsK/T3qzL r+jg== X-Gm-Message-State: AKGB3mKrJX8Ld7scn2PQTjCKPOzlLY18DQlmv+ORJasLso+KRH8Qq/GH ZVxckUbx1BwGzQe2QfLlPRRlSLU5isUsh+zwrOZCOw== X-Google-Smtp-Source: ACJfBot09qksH3jgPD/fwpF/UuWn3qq9wcbrmRsRUC9izfGx68mOiYrNEf8b39bY3plbk9r10IpEbRC29pqkGStvwXA= X-Received: by 10.200.2.150 with SMTP id p22mr59152571qtg.328.1514821229652; Mon, 01 Jan 2018 07:40:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.5 with HTTP; Mon, 1 Jan 2018 07:40:29 -0800 (PST) In-Reply-To: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> References: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> From: Vincenzo Maffione Date: Mon, 1 Jan 2018 16:40:29 +0100 Message-ID: Subject: Re: Linux netmap memory allocation To: Charlie Smurthwaite Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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: Mon, 01 Jan 2018 15:40:32 -0000 Hi, If you have 32 NICs you should open 32 netmap file descriptors, (and you should not specify 64 in nr_arg1 or 256 in nr_arg3, this is for different usecases). Also, since you want to do zercopy you must not specify a separate memory area (nr_arg2), but use the same one. You may want to use the high level API nm_open() https://github.com/luigirizzo/netmap/blob/master/sys/net/netmap_user.h#L307 You may also want to look at the netmap tutorial to get a better idea of how the API works (https://github.com/vmaffione/netmap-tutorial). Cheers, Vincenzo 2017-12-28 18:34 GMT+01:00 Charlie Smurthwaite : > 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 = 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 = open("/dev/netmap", 0); // Open a generic netmap socket > strcpy(req.nr_name, "enp8s0f0"); // Copy NIC name into request > req.nr_version = NETMAP_API; // Set version number > req.nr_flags = NR_REG_ONE_NIC; // We will be using a single hw ring > > // Select ring 0, disable TX on poll > req.nr_ringid = NETMAP_NO_TX_POLL | NETMAP_HW_RING | 0; > > // Ask for 64 additional rings to be allocated (32 * (TX+RX)) > req.nr_arg1 = 64; > > // Allocate a separate memory area for each thread > req.nr_arg2 = 10 + thread_id; > > // Ask for additional buffers (256 per ring) > req.nr_arg3 = 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://atech.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 > in error, we would appreciate it if you could let us know and delete the > message. aTech Media Limited is a UK limited company, registration number > 5523199. Dial 9 Communications Limited is a UK limited company, > registration number 7740921. Viaduct Hosting Limited is a UK limited > company, registration number 8514362. All companies are registered at Unit > 9 Winchester Place, North Street, Poole, Dorset, BH15 1NX. > _______________________________________________ > 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" > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Mon Jan 1 16:14:49 2018 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 B8B30EB09B1 for ; Mon, 1 Jan 2018 16:14:49 +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 83DAA71E77 for ; Mon, 1 Jan 2018 16:14:49 +0000 (UTC) (envelope-from charlie@atech.media) Received: by mailman.ysv.freebsd.org (Postfix) id 8035FEB09B0; Mon, 1 Jan 2018 16:14:49 +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 7FBD7EB09AF for ; Mon, 1 Jan 2018 16:14:49 +0000 (UTC) (envelope-from charlie@atech.media) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50078.outbound.protection.outlook.com [40.107.5.78]) (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 BA4D271E76 for ; Mon, 1 Jan 2018 16:14:47 +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=Tzs1JB1B1LpdYlWn1NNOGP0xbD2fy3LW3btHkc8K/0E=; b=XgIZIh645BM5IMOLaYtcg2hdRRUjCAZvxgpoS0qaBALs59ofy8xzKmvO877LuJpCTRjuqLJOLxdgsW40j53kxFejlcSWVlzKKDnjyHhiYqdm8y87cWObDHh3K1z/fOSjPuS0CzOgoTYTWYIk0rj+YGjBUC0qz3BC8i88gyXQ0MA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=charlie@atech.media; Received: from [10.0.8.11] (185.102.133.45) by DB6PR05MB3494.eurprd05.prod.outlook.com (2603:10a6:6:1e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.15; Mon, 1 Jan 2018 16:14:44 +0000 Subject: Re: Linux netmap memory allocation To: Vincenzo Maffione Cc: "freebsd-net@freebsd.org" References: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> From: Charlie Smurthwaite Message-ID: <6c5de1ed-0545-31b3-d0e2-4258fa4ccf1c@atech.media> Date: Mon, 1 Jan 2018 16:14:41 +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: Content-Language: en-US X-Originating-IP: [185.102.133.45] X-ClientProxiedBy: LNXP265CA0012.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::24) To DB6PR05MB3494.eurprd05.prod.outlook.com (2603:10a6:6:1e::33) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8d8afe69-370d-4b75-1896-08d55132c56e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:DB6PR05MB3494; X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3494; 3:J1tFE9/VNvotgitpDVrAPu22yYq5EUSZiZSMOXoSOmJkvpxs847vyelcPhyQA/m5qmnN/+9xKSWz0aQD+/j84dDkep7RyKXgvBTFQKGVqOQd1DTBwxsIPfBsNfrbGkhhXbjhhMSizSFoEdR8Q7ow/UGNf7lC3tPsv3mxa8biDYMkt1cYxZ8m1edCzNqCw+JtYXxJhUgMMybgmK+l2YcVuhoJ3yCq7OB+JqBYcerggM61MyyD8nHiQ1lZS7vmr1Nz; 25:6/RFVmodZ9c+vD4gJvSkgHtmt1iGbsI1iHsu0NHP+mkkL2cb5hPdvEvu7F1dqBia/+C7q0WtIv3Q1lpclE/T/onrKmsUP4bZaaB+LF82WOjqFKHY1Ondw0wr7dJDgcE6Xb77RvdqB4Tz3XmDT0/WQDps/tlMFZwqehy1YPOg8z1SDs+xINBhBgnR+dZ0jwHhvpyJD+lOfac9IAYZdVvBZEchLKCX/+5IljAof3TlWiutRraaeS2Qu2IzEDnD2/jeE7gfs08YSaK1Npv7v6F1frz3hhGI6gxB4fLF7cq/eZJR+ex/T2u2EBYWs4jApQKRt/Qajj7bzxnqtr/O1GGxWQ==; 31:hCP7MK2RT6H2pkbf8rHNkKkWa0876/UkJmLAE+asrKju7b9Zdid4MfFo2FDrluusKtOMUkOSigWKOC1fLyOasxNQgWVi0AvU6XSC+HJ5/walc/LOpb6bfpt6753/rZoGH4tGHyJDYvP3ftBdRh2u4D9MFxmozYuSeIgSQVb/iIdMT1WT5K3kKfLLK5l+3cZpCYoA9cD7qVFllmpPl32N0bq6W+WzI6l6SLKnQrrxYO4= X-MS-TrafficTypeDiagnostic: DB6PR05MB3494: X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3494; 20:Ftoxu3XBA/pYJEHJW+FQlacEBSPOiAtgMgb4dkV5hVO5aoYFZYQE7MtEFvYvODP7l4QJEkG2Bti2cwjOak6jsDYpcV5cOgPaoaLgkdvVhUv+m0QlfXhAmdRMk4jcBJCMtRvzLPx0leHZLPbfTzqe9hxBQ9UB5N493NhQwVm7u31ENtbSGybAaTkaiFQydZxRzoSGzUVej9y+CnyRbiIqJU/7ft4lyNtNLxBOgjCjfKafimeIN28kweTJDWsXYAvj; 4:t7Md5WmmKQZCooVVGVcznCUUDCIboZ9JmfizrfdL/VcRiLRwsfi0csgr0W5PWMiqV5d74/0tWJlhHawVKwr3Hsu9a+iwfdB/J2+0gukqY89qWdzISUALWUZG0PFt1F3zOp9iQR361EHf/eOBck3n8g6uXyDQ6BtCtZmBuyfTye+U6xICm90C+5Km7FFh/GgwRkQcNIfxJOpYFz8Iq+L3dHB+QWhnNZJ/yryJX5smqzA+34SMHSSLhgEVy2UlsLy4B+be7/rjvEgweeGc3hLuy7bYa+0tKUeXescsvVDYM8GiUU6czbqt0HUt9HDC3sGMvSaKByDdt+DYiJkmJlSiuGqBUXTByAf55Yuiw6tBxA56IpU4xu8rfL7aJheVMcr0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820)(75325880899374)(83272782819144); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(944501075)(93006095)(93001095)(6041268)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(20161123555045)(201703061421075)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:DB6PR05MB3494; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR05MB3494; X-Forefront-PRVS: 0539EEBD11 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(376002)(39380400002)(366004)(52544003)(189003)(199004)(24454002)(377424004)(43784003)(68736007)(77096006)(6486002)(8676002)(81156014)(575784001)(8936002)(3480700004)(31696002)(508600001)(81166006)(86362001)(2906002)(3846002)(64126003)(6916009)(105586002)(6666003)(2950100002)(31686004)(606006)(106356001)(6116002)(53936002)(65826007)(5660300001)(33896004)(33964004)(6306002)(76176011)(16576012)(59450400001)(386003)(54896002)(84326002)(229853002)(39060400002)(345774005)(4326008)(52116002)(6246003)(16526018)(83506002)(97736004)(966005)(4001150100001)(7736002)(236005)(25786009)(53546011)(37036004)(58126008)(66066001)(65956001)(65806001)(16586007)(46492003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR05MB3494; 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: =?us-ascii?Q?1; DB6PR05MB3494; 23:R0mYLuGL0VLrxQ6bQsh1QIhcZ8/DeXvxr0TKrZn4p?= =?us-ascii?Q?bPwZUuoQl+9fWTlrlmB3W659BrkuOfV4d+x7TU3ddvr8Z+umzxbMtfsFYqeR?= =?us-ascii?Q?oYUhcppuvTyldsJ5xZMIt81mWmwU6XIoQYf+vWTcVKMP0tYM8izh0GeB2LXc?= =?us-ascii?Q?tQ/8zZtWFUf+yuHoKvqZg6snxYNsKFliAB/JmEQzLFNr+xmSl9RPuBzFOzfI?= =?us-ascii?Q?omQEN2I6k34+PpxOgv8IRfXnY2Qew2INdUsPdYtDLfxcUUCLr4phVBDiON/s?= =?us-ascii?Q?A8aEQU8RrFHflLh48I8gB3485bEzkxoe2uve/BNRAcAWST64oPth1rUCyYkv?= =?us-ascii?Q?TdGxt8Bovymu8jAsTWBqB56RNK7dK8aFdYqUelS7A68iY6CjQzzOIS/i7Mug?= =?us-ascii?Q?oMGfPxscjgyzg0zSXzXnY/EK2K3RhIrtzzT3flde95OgCBV8en23jGyZ2AxO?= =?us-ascii?Q?HcSi5lUFG8GsjwDU664MgDyUYSKFXqLl4GYUZTsxwhyKVbXbzmACNWC32kPL?= =?us-ascii?Q?No2nq5fm2sAHtS6ZZ3UAGcfvpJT8ubUqW4IXahwSF+mLm76TyP9dFRvhPAUU?= =?us-ascii?Q?knwBeBHaQN5T08FTsUMQv/IXB/Xt5SVhNjUESGnoHsyyjqhn/t6RmiBwzndR?= =?us-ascii?Q?MzEl1Kpdg3mhrlzygjEOQYw5s465A3GlCEuWu8PU6+b2bpJX/ijWt0B1PXxk?= =?us-ascii?Q?D//tyKPbAppOqodcy69VtIBFuzHlyhAky8qmcwyb2lGretd70aInrMzwia0h?= =?us-ascii?Q?2RlTg9TIoql9OBgasYPAVyY6YT/TXQ0KcSf0P/Nf0NXoSD/S4lDxewDgVKRD?= =?us-ascii?Q?Cn+NZjZ5n6QFpFg/jHqusB+Mu+/2Vf7MhQGyxZVvApDkgI0O0qeolm/eLYhZ?= =?us-ascii?Q?dONe9BcDOkX7txP7YE4IsUuLPY0pkxPLffvy0TC4StEgGov82c3ElySEKIH1?= =?us-ascii?Q?6GUfKqC0tAeL1rFEqzdX00yhfFyCoDA2Sk+hEVNa4qwwieAw2G7Jbh9EkOeb?= =?us-ascii?Q?dt1QnVF/fr8y/Pdiv6uNE40lxnPswT9mIO06bxI/7RPamE4t7h+UWnNFINDF?= =?us-ascii?Q?oK3L/Ae9lOLWkKWxKaTa74o0MA0gInA4W48X+RuWIDiBUqgR0tl1ZMNXeBa5?= =?us-ascii?Q?lIoy5JzrRIfiVyPiIpzYLVXvhAo0ZIIoYSHhtdCpKqKZxCopJVTL75jl0Q/K?= =?us-ascii?Q?GfyJ6yZ0mzfvagps5QbCZl0IIQaxVgl36vfoUuyQS0gfNKHHs20m7lzAzmCR?= =?us-ascii?Q?JG09Jwjjq0GQeWkYJLiwjnDiYNg+qiZI0+Rufuc9qHjRzm8ahQxOwfIRXO/Y?= =?us-ascii?Q?ly/YrI3MJHm4fXHZGx3x7k7XUDFs/j1zQpqhWxcgfTmpRajV7pifYDz6qCh9?= =?us-ascii?Q?7dSRiMiSopa1rwTpvQzGTB5wpZsdopgSoSLOVEqxRvf70cwRZH/q2EQUIFoB?= =?us-ascii?Q?MbOCSdths+Zwdw/aICB+XlJKFPcap+kkRZ9IiSxNnit9nXXzG0eOosrSKlcs?= =?us-ascii?Q?3KjYxSy+nWJkgAskeSQ0M3zyKgypeeszCUhz9y2p04Wke208cAE6A7WPrq3I?= =?us-ascii?Q?H0p/j64WnUbEVCzog=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR05MB3494; 6:wf2bCoODQNdXGIv10RayeD4S3lqBrODCcYp/0nkvCB4TTOpChxsSJr8wSH3v0/Cps3EjmOAmSQZlMBzWEhMVZHchhDNldE0AeEbzHOJKHzL1hXV1MCV6bSrh5WIja/z8V4Gul6JllYzp22KjWG6DynRyc0xxTnuAW/sLShs9CpZMyEW/7NsrvAXwZmWtQb9Fs37LeLMumcRayJhHH4tz7rrQcIqgk/wMcpIw3cm7zlpt+4vwET+OgIDQYu8hJrRVJVMsZkOG2L6lmn+bKy0RGlbDySqgdVken6wQ39seTOtFnGnwkLNliNbrAfohldtda/MG77L0SEgVt/Jz1rDItALoqo5Z/3ln6W+cOvEXE0U=; 5:nEalYNQY+OI5/eLH3oh/1Bbx+rd4MLQ3jpfd1VBtjeaUUhOffCDapqDVQts0ZGx8s6V4R7wGSj9FdJfbAuuSLbxZPLH7N2LU4hZQ2q0lrW8i1Jj+bC0lYlET/rcX9DPCY8UBMWb5UyF7C4twVuoGS7ohbdWDoduKrg4BkfW0IzE=; 24:jJcNtFF+OpV0alAuPAD958kr5lvwujB8BAdwx4RbqNZTeIQP463WJ3YsLAvm/24gAwJJy1/AA4+RjMsSXRkBG0pcERPwTl90YBYk3Dixz0I=; 7:wX71JcpNpWgDaIXRY2tOlXkYsbhNKF6/a8dMJojAJHDR/d5pf0FEN6UwIjKrNqeuD5GXaWa45TbxZz5oqtV6RWLwxG0W/yUcJX6Yg8zlz/ZBEclE8ZzADLTVOQZDNrkjYAqI4co36nVJUW0B3Xeu5EDJHgXjHGNmtakKeSCNt+iUC+3yvEgI6NML32v3pRwqrfBaz60KH6KknheG3G8GBUL1uGtCCyXQTmnCgPwzigGK5WV7LRWJGxcaj7VNVEYI SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: atech.media X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jan 2018 16:14:44.4397 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8d8afe69-370d-4b75-1896-08d55132c56e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a8f6edf-720f-4e3d-b767-1360e39a8cdf X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR05MB3494 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: Mon, 01 Jan 2018 16:14:49 -0000 Hi, Thank you for your reply. I was able to resolve this. 1) I do indeed open one FD per NIC 2) I no longer specify nr_arg1, nr_arg2 nor nr_arg3. Instead I just verify that all NICs return with identical nr_arg2 so that the memory is shared between them. 3) I properly initialized my memory, my failure to do so was causing me a lot of confusion, The resulting memory space is large enough for all the NICs, and everything works perfectly with zero-copy forwarding, great! The only thing I am still having trouble with is the ability to simultaneously trigger a TX and an RX sync on all NICs. I have tried select, poll, and epoll, and in all cases, RX rings are updated but TX rings are not and TX packets are not pushed out (this occurs using both native and emulated netmap modes). I notice the documentation says "Note that on epoll and kqueue, NETMAP_NO_TX_POLL and NETMAP_DO_RX_POLL only have an effect when some event is posted for the file descriptor.", but the behaviour seems the same on poll and select as well as epoll, perhaps this is a linux-specific implementation detail? I have also found that all of these mechanisms seem to incur a very high cost in terms of CPU time (making them no more efficient than busy waiting at 1Mpps+). My current approach is as follows, but I feel like there should be a better option:     for(int n=0; n Hi, >   If you have 32 NICs you should open 32 netmap file descriptors, (and > you should not specify 64 in nr_arg1 or 256 in nr_arg3, this is for > different usecases). Also, since you want to do zercopy you must not > specify a separate memory area (nr_arg2), but use the same one. > You may want to use the high level API nm_open() > https://github.com/luigirizzo/netmap/blob/master/sys/net/netmap_user.h#L307 > > You may also want to look at the netmap tutorial to get a better idea > of how the API works (https://github.com/vmaffione/netmap-tutorial). > > Cheers, >   Vincenzo > > 2017-12-28 18:34 GMT+01:00 Charlie Smurthwaite >: > > 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 = 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 = open("/dev/netmap", 0);     // Open a generic netmap socket >   strcpy(req.nr_name, "enp8s0f0"); // Copy NIC name into request >   req.nr_version = NETMAP_API;     // Set version number >   req.nr_flags = NR_REG_ONE_NIC;   // We will be using a single hw > ring > >   // Select ring 0, disable TX on poll >   req.nr_ringid = NETMAP_NO_TX_POLL | NETMAP_HW_RING | 0; > >   // Ask for 64 additional rings to be allocated (32 * (TX+RX)) >   req.nr_arg1 = 64; > >   // Allocate a separate memory area for each thread >   req.nr_arg2 = 10 + thread_id; > >   // Ask for additional buffers (256 per ring) >   req.nr_arg3 = 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://atech.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 in error, we would appreciate it > if you could let us know and delete the message. aTech Media > Limited is a UK limited company, registration number 5523199. Dial > 9 Communications Limited is a UK limited company, registration > number 7740921. Viaduct Hosting Limited is a UK limited company, > registration number 8514362. All companies are registered at Unit > 9 Winchester Place, North Street, Poole, Dorset, BH15 1NX. > _______________________________________________ > 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 > " > > > > > -- > Vincenzo Maffione From owner-freebsd-net@freebsd.org Mon Jan 1 21:05:55 2018 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 2FAACE810F5 for ; Mon, 1 Jan 2018 21:05:55 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 091747E781 for ; Mon, 1 Jan 2018 21:05:55 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 05785E810F3; Mon, 1 Jan 2018 21:05: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 050FFE810F2 for ; Mon, 1 Jan 2018 21:05:55 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 BC9EC7E780 for ; Mon, 1 Jan 2018 21:05:54 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qk0-x22c.google.com with SMTP id o126so47218370qke.12 for ; Mon, 01 Jan 2018 13:05:54 -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=NOabmQldPtUeN1XQfoYpS4s5R6EEySs4NyuTd3b9bGg=; b=PdnZo2/dXFWPaV91DxAYGUsCZKPcPYM7LhQMpw1Xqx1oHZ88iGtWdZAz+S+Fl9mgoD RptNYjRmL75U/kWRC654vSaUwyZBbszMnTHyhtjl2laH8PgC4k0u9CnzFGprmx4yxc4k 9+drcFza9MgzFxZBM69caGWj1DGYh8DxXvuE4c844PUJMcQqNiKzfnrDobDwcl63acwT sZ4yAJIvIpDiqlFFbR7nfshIVzSm7x3QtWfHicnG53NW4vByVfeXcPza3fio2dwi6paB I0G3NqT1ftAJSRSNiL+mhkSKp6gCMgZ+sasjoKutjyWY8qI6M5fUOu8mg4D6tURJPlea XpXQ== 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=NOabmQldPtUeN1XQfoYpS4s5R6EEySs4NyuTd3b9bGg=; b=DLthlFgHcvCEF2x5okE5znFUPY+e/yqzfXt/KR8pI00Gr8CJZwTyYxVivNtC6WEPjp qtjlz0kX1mXtRr5psrbzxPFCj/17nBEG1lwvqD8tj9+Y7zKotSwYyok5qcP1CS+4Rsb5 FdbQ/wP1jWzzg8JLwbIshxYZwuOiP6NMulhEj/TgKsJ3PHKTfMfxxlNp42Ev6nF3eL9W JR9GRqkC4lOjeoLJsXh3hTQ/2LgCmFYTEKaSZoJ4zMu8LsOqctJcx7qE36p0rEwXjucm WXPhwx47TLJ7YOXP8EGPdyh35xwxBKTODp61EL4nz2XRpYdUiqbL5frIuh6SErcl8IgV 7mIw== X-Gm-Message-State: AKGB3mKWAF9u+ZF4RAlTWyCznjygbqWzqzTOeXYRP52hnHTiO2WxzAeJ yv+RlwQ/gx4h5K6CYELBs7LJuT8Uj+rBmIWJF+OvAA== X-Google-Smtp-Source: ACJfBovm/Y1Yad+m9sZfLc9a88uMfQxFEdGQ5K+bP6up1S/m0Umh7v7HoW/UbkPyTMCZxf7iCccib0RX744QevOYUcc= X-Received: by 10.55.33.170 with SMTP id f42mr54124289qki.138.1514840753606; Mon, 01 Jan 2018 13:05:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.5 with HTTP; Mon, 1 Jan 2018 13:05:53 -0800 (PST) In-Reply-To: <6c5de1ed-0545-31b3-d0e2-4258fa4ccf1c@atech.media> References: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> <6c5de1ed-0545-31b3-d0e2-4258fa4ccf1c@atech.media> From: Vincenzo Maffione Date: Mon, 1 Jan 2018 22:05:53 +0100 Message-ID: Subject: Re: Linux netmap memory allocation To: Charlie Smurthwaite Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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: Mon, 01 Jan 2018 21:05:55 -0000 2018-01-01 17:14 GMT+01:00 Charlie Smurthwaite : > Hi, > > Thank you for your reply. I was able to resolve this. > > 1) I do indeed open one FD per NIC > 2) I no longer specify nr_arg1, nr_arg2 nor nr_arg3. Instead I just verify > that all NICs return with identical nr_arg2 so that the memory is shared > between them. > 3) I properly initialized my memory, my failure to do so was causing me a > lot of confusion, > > The resulting memory space is large enough for all the NICs, and > everything works perfectly with zero-copy forwarding, great! > > The only thing I am still having trouble with is the ability to > simultaneously trigger a TX and an RX sync on all NICs. I have tried > select, poll, and epoll, and in all cases, RX rings are updated but TX > rings are not and TX packets are not pushed out (this occurs using both > native and emulated netmap modes). I notice the documentation says "Note > that on epoll and kqueue, NETMAP_NO_TX_POLL and NETMAP_DO_RX_POLL only have > an effect when some event is posted for the file descriptor.", but the > behaviour seems the same on poll and select as well as epoll, perhaps this > is a linux-specific implementation detail? > I have also found that all of these mechanisms seem to incur a very high > cost in terms of CPU time (making them no more efficient than busy waiting > at 1Mpps+). My current approach is as follows, but I feel like there should > be a better option: > > for(int n=0; n // usleep(10); // More CPU time seems to be saved with a careful > sleep than with select/poll/epoll > ioctl(fds[n], NIOCTXSYNC); > ioctl(fds[n], NIOCRXSYNC); > rxring = rxrings[n]; > while (!nm_ring_empty(rxring)) { > // Forward any packets waiting in this NIC's RX ring to the > appropriate TX ring > } > } > If you are using poll() or select() you should not use ioctl(NIOC*XSYNC), as the txsync/rxsync operations are automatically performed within the poll()/select() syscall (at least assuming you did not specify NETMAP_NO_TX_POLL). Also, whether netmap calls or does not call txsync/rxsync on certain rings depends on the parameters passed to nm_open(). Make sure you check for nm_ring_space(txring) when forwarding. Cheers, Vincenzo > Thanks again, > > Charlie > > > On 01/01/18 15:40, Vincenzo Maffione wrote: > > Hi, > If you have 32 NICs you should open 32 netmap file descriptors, (and you > should not specify 64 in nr_arg1 or 256 in nr_arg3, this is for different > usecases). Also, since you want to do zercopy you must not specify a > separate memory area (nr_arg2), but use the same one. > You may want to use the high level API nm_open() > https://github.com/luigirizzo/netmap/blob/master/sys/net/ > netmap_user.h#L307 > > You may also want to look at the netmap tutorial to get a better idea of > how the API works (https://github.com/vmaffione/netmap-tutorial). > > Cheers, > Vincenzo > > 2017-12-28 18:34 GMT+01:00 Charlie Smurthwaite : > >> 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 = 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 = open("/dev/netmap", 0); // Open a generic netmap socket >> strcpy(req.nr_name, "enp8s0f0"); // Copy NIC name into request >> req.nr_version = NETMAP_API; // Set version number >> req.nr_flags = NR_REG_ONE_NIC; // We will be using a single hw ring >> >> // Select ring 0, disable TX on poll >> req.nr_ringid = NETMAP_NO_TX_POLL | NETMAP_HW_RING | 0; >> >> // Ask for 64 additional rings to be allocated (32 * (TX+RX)) >> req.nr_arg1 = 64; >> >> // Allocate a separate memory area for each thread >> req.nr_arg2 = 10 + thread_id; >> >> // Ask for additional buffers (256 per ring) >> req.nr_arg3 = 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://atech.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 in error, we would appreciate it if you could let us know and >> delete the message. aTech Media Limited is a UK limited company, >> registration number 5523199. Dial 9 Communications Limited is a UK limited >> company, registration number 7740921. Viaduct Hosting Limited is a UK >> limited company, registration number 8514362. All companies are registered >> at Unit 9 Winchester Place, North Street, Poole, Dorset, BH15 1NX. >> _______________________________________________ >> 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" >> > > > > -- > Vincenzo Maffione > > > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Mon Jan 1 22:05:13 2018 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 A1A14E86087 for ; Mon, 1 Jan 2018 22:05:13 +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 6B25180907 for ; Mon, 1 Jan 2018 22:05:13 +0000 (UTC) (envelope-from charlie@atech.media) Received: by mailman.ysv.freebsd.org (Postfix) id 67051E86086; Mon, 1 Jan 2018 22:05:13 +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 668DFE86084 for ; Mon, 1 Jan 2018 22:05:13 +0000 (UTC) (envelope-from charlie@atech.media) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0070.outbound.protection.outlook.com [104.47.1.70]) (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 A988D80906 for ; Mon, 1 Jan 2018 22:05:11 +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=cd4SGEbPqtqfZ6zFGgceNSdt9tF2A2BL8RI+Ednwe54=; b=fvIodqmcv+F9Ja5E51Pww8mUQp/TCUG1CSokBnwTaXAqVbG2QhjlBzuS5yxA7vNFGDqYjops1SKrhQ0ex95QV8A65INwYCiw+CJx5h62OHa2w9aOFetUVHDtGx7U22ZSNOhtK9a3DGztS8HitR2OfZ9vMJBSUO7tFWcI8ii+VnA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=charlie@atech.media; Received: from [10.0.8.11] (185.102.133.45) by AM4PR05MB3492.eurprd05.prod.outlook.com (2603:10a6:205:6::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.8; Mon, 1 Jan 2018 22:05:08 +0000 Subject: Re: Linux netmap memory allocation To: Vincenzo Maffione Cc: "freebsd-net@freebsd.org" References: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> <6c5de1ed-0545-31b3-d0e2-4258fa4ccf1c@atech.media> From: Charlie Smurthwaite Message-ID: Date: Mon, 1 Jan 2018 22:05:04 +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: Content-Language: en-US X-Originating-IP: [185.102.133.45] X-ClientProxiedBy: LNXP265CA0031.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5c::19) To AM4PR05MB3492.eurprd05.prod.outlook.com (2603:10a6:205:6::33) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6e5e5521-0e0a-4824-2055-08d55163b87d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:AM4PR05MB3492; X-Microsoft-Exchange-Diagnostics: 1; AM4PR05MB3492; 3:mKPRsV8Jn4wU4ii/FenHbjBRFWKnHnjyrm9xnuPQsVOdOOgWaMUMKyUbscLZq6rOjOnmASetQDyAJQrwZNPx0M0r1A4KmE+wDKz5x5E5LwCSpYI3PQxzz88msKP7g7Hk/RjnfX6Xyge4/1Tq/CzpIGvUCtdBc4nIq2lUJGdNzMkkDzhYAIxFFYfbigxq+bvGlwLdU64/iIm7gKTbqN+5pMaooyuH/6fPQiuL0OO9EftYPnq4seVwWEZBIIRLW/kY; 25:7NnkJh9gfe6qPYrdwgqev8Vw2LVl09TchRLSFgLeVwp6eEgCRCVmtxBjJrn/8s9YFtf+qJQNDEe4E1gSPFzQiwl0JfYYqlhAc77Nvq6zQTeu4PxHqOv/qB5DaR7wJdav3PBuPZlCBu+fiOt2oWgsQwAuAC5SmoysTw6mUwcYfHwIFp1yXV5VizF5Qw0E0FUNlWsr4xCImB12MeB2WZ60UlCn2tNBaL+Xh7Z6C8CHfzr7wnko8UcWpghq16Vqn+2aNlDkWMDFwihFjo+vHKJG6fCN+48i+GQlhpZrrzvxoMTYLf9EOssAmAl1qU6PKx14f1JI5XFOUdbNN6VkJd/ADg==; 31:WsIZ1dgiX87xXn14KcLcCnU3F9sbncm2XAyVi5WCLjACFLPC7ltDsM4V2n6meg/dOB7tuIyoo7B8nzrRcoQIHfyCKAmhKSJz4ZPOk07curcFWhWuvKJpk4Jx39nwQ8Fa/N34Lz1/gEHVTlBkJmHQJESAGLi7Vm4ZlTF62awqfrWLEYSO3YLpklYjk+io70i6ELbQ60PVv5v7oeHi3yJxHYn7zKb4Y34x/X/RgBOrKHs= X-MS-TrafficTypeDiagnostic: AM4PR05MB3492: X-Microsoft-Exchange-Diagnostics: 1; AM4PR05MB3492; 20:7Tmyhkuqc50YsGh77I3l4ljAy11O6KF50mDqoEvngTRI32zQmv8IksyurKsg0BK8msmkSVYf8Z243KNlwX7muJ5vDeFO2fw7NV4KKr4MW0X4vPv1rRQOwzFaX5nfmZVfECixiLu8N5PYlD5qCOr2oKWqoqBOOEM9GleLcOxIACR5oY5ydIlJQuRPCWNCbL2tDS8inPpJmEvArNTjSpO6VoL2AShhiqqX/KYAKXY+XfB8BslMb4hGhm3lTubHE5Xk; 4:IZcDK/pOPIj3PrXE35hmK7F3CxxpWJ+DVQEio/TQafBXsFUjAVPVKcOPq4OJ6FCM0CbgXfYCMxXBVkDTfkDTQGAXY3iBworjPjgplqEePAxTnAFCLYFEX9SnvM6wLu7CGyLTdBpOD8XzlNW1pnEreH4FVEtJpzfYe1Mlo1vXg5AXHoHQZxW1bElWqbh4y0rcIXc0RTbPESWxudoHIV/C1KC4oveOP/LJcAlkzoKfQtMsDespf/bdGVIqCzbjztM3X34gvAKty2jzZK9xFZ6VhHaMmFt2p3M6QEYMgmuvCY2RgzpvfPcZH1rNb8j8yvmI X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(944501075)(6041268)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:AM4PR05MB3492; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR05MB3492; X-Forefront-PRVS: 0539EEBD11 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(396003)(366004)(376002)(39830400003)(39380400002)(189003)(199004)(52544003)(24454002)(43784003)(377424004)(68736007)(478600001)(7736002)(39060400002)(33896004)(386003)(4326008)(16526018)(3846002)(59450400001)(606006)(76176011)(6116002)(33964004)(31686004)(53546011)(105586002)(25786009)(8676002)(52116002)(966005)(106356001)(64126003)(6916009)(345774005)(65826007)(81166006)(316002)(83506002)(65806001)(8936002)(6666003)(2906002)(37036004)(81156014)(229853002)(97736004)(2950100002)(16586007)(3480700004)(65956001)(16576012)(6246003)(236005)(5660300001)(512874002)(86362001)(58126008)(66066001)(31696002)(77096006)(53936002)(93886005)(575784001)(54896002)(6306002)(6486002)(84326002)(46492003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR05MB3492; 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: =?us-ascii?Q?1; AM4PR05MB3492; 23:z1Yu81kNpramTmg6Oh/et5MpgM89nsOz4GzbU2M1K?= =?us-ascii?Q?WlBcA3XWPKQiDLFd76U324AWTK3ffid3eYM38StB9fZhpHU3MZAEKtbRMSRm?= =?us-ascii?Q?Af/oTm1qKSkZ+rwNlHx6ylL2QczmyyeGlFGh/hjN4hBrSiQIOqtXVzjYvsVL?= =?us-ascii?Q?9gOGFHKh0s3BY3zvtwAVo0yXfPt5YZNPn4b/pGQsr3tN6Ivj054EMFfSiNIn?= =?us-ascii?Q?XqZAJDvf41rNfgaMlX8moINmgW71qGVn3nUHrpergEsDYC8GDKap+Jdqmrp7?= =?us-ascii?Q?Gk/yghLYgzugHxSjvklp4BVmTe8T3xwvaq62H7X6Fd4UGayRKdQ4utxAeeKl?= =?us-ascii?Q?s+5CmchDJrsY+a7u+QCZx9Vv1sJZKmSDyNjR7XHs1+3RaTdtdwompo/r58mi?= =?us-ascii?Q?2Zk7iLkcHy2NIDRyVNxAfCYcaML3l4xyHHp381p2lYv/jMzfss4bGeRe8Jvk?= =?us-ascii?Q?xFuYpX59nR4Q9HOUBxrF0DipSfSxDfO0TfV5pxMq18SzBq/05694o3QrlzGD?= =?us-ascii?Q?kgZW6YgBiz+NWKrAC02P+c/xAnF11SXVrZVfh6xxU/fRrRFLhymiJTra/7c6?= =?us-ascii?Q?Janky4bjYyo7J/3c6Coa+j+r6AayguOaW1yfrkBG6146F4oRFo83Je3PsDBQ?= =?us-ascii?Q?GrikZBWthpO3MhKznvDUbz4DhvTFb64CyaAAXe0fXBUzc6Ccl1LJ/Uhi408Y?= =?us-ascii?Q?Yt2kppdC0UqPn23yeG68Lxzxz7Pke7UuHv2Rs+zwbyES6rnm4hKXL/pI1pwM?= =?us-ascii?Q?Y+gTEyl9uTDuD3oEDSLkZOvGfZWXSYznjO/LxNAiKER1Oy9Ev5l1cNYZ+zbv?= =?us-ascii?Q?cwYi/D9+tz2KA5Drp66UqswD7xuSWYnnGW9hgS2PZ/JhmRLdXJ3pYlD1OP7d?= =?us-ascii?Q?WykVxfDzcuaozjmkeIZzEz6W2rw01Mp3e3WcbtaYKbsFf10u4HrUdr4NajQc?= =?us-ascii?Q?M4lJqTVzMr3aaUKfJCSHMsQfCA1A+WGxm0XNKIKhTBy1prqA7B1IW0H1UKTz?= =?us-ascii?Q?c4uFLoIn25zKRAvCExG8UOPWL3KPov86QWWlxEFPALrOGotYUoOcB05J7+b5?= =?us-ascii?Q?5UEMxw+HBH/+NB8VQcZtUf6l/wiIskvUvZfdDpqvAgxXHfdjz70INipcUKNs?= =?us-ascii?Q?qbb7H7aIctXaGTUXzZmDN8ZeJ5uOnX1c4QbFOqodOj4gToUkdV4Gg5iTrueG?= =?us-ascii?Q?QBCRzV4wodT+lpkvYDEY8+BSw3c8dut0bd//qZbBCfEoJlAJfauz0HYa6E71?= =?us-ascii?Q?J1Z/9F1AC/mOLN1hBsKedLSuYFpYHP90BGfGPjnFMYlBiacAA3lzOqzwXVEU?= =?us-ascii?Q?//0k14HPNrbm7mh2BHnXFi0HJlw3MkMaCYxpixB7/fxIMzT/6EkVhI8ND/7t?= =?us-ascii?Q?9SLY9MbNrtkVFKwIH0P3hgHrh928aIVG9WmcreSyxryBZNC6Zg5tIBfDQbz1?= =?us-ascii?Q?Q15Ee7D3z/RSvMPAxCeQ3AbetLJwLhTGcUNs2tmBIY1BdUGa1M0TEGk1cPeu?= =?us-ascii?Q?2+v7q7SXQ5WB3jDEEEU1cNPhh8BvC2o6C9KYPL0q7cvIi5YBmIX+V0B2NkTt?= =?us-ascii?Q?lBFb/eDM0FR1ztt8NzSOUBrU2rB7dDvV7z3TS2uBRkFeozzio8WYFrczjPrL?= =?us-ascii?Q?4qs/TFXJJzpQBvq9eVwY4wdDatGMzHuajzOXJ6ePmk=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR05MB3492; 6:gg2w+kcmwEhz73ZeirG2OTyMNNDOcN9KKcHhHKMdwsSlQ+TgtctlQvRDZSXUuCapQuOywqF8fQs4npDqJT303lyIuUj6EEPVs5F5Chfzf5h+oS6eYC/k6totmX6pTfsI3stvZuHQ5EGy5K7pFJHl9f4O9O5Ci4IZqSbE17uoLndmSoDwXwootnk94megapAYsDYvaHIo8kmhJ9ckzoLiAN+g2JQvgcu+iBoT/8c8GDr724+x+F9tWWqrh99OqkmiUTMNUb5APtpHV9tRbzI04GW/UOOzv5qDCzRMFUVcbuqwI0bqVR/Tp+q6ri4JSUgpQR5Q9jRGLwEaD4QPONAR5GAQgZojDCjz9oSMthA/ZGM=; 5:CRv6z7l3BZ7ikvGd06ZYTZIvaU8h41biRx15RiY7DvSexjkjc+84um9nSa1kvVNSU35vU9SYgSHD23rzE+ePQ4ThswnXCcCYvXcfc+DS9ULUa0ZZPHpeQ33TO/gm2yHGLsnHV3mjpmRorzvi6GLY/b17Y38vGeqkbN6ZHRTW/7s=; 24:yGwDFABA1egnmR/J3WFWCz6G7rlVJF0VWNZ4gupDJFhBuh5u4TMXHjB0ewb1FQpBxBgDWiwLFy1IOiC6pxNeKqElVWQNBY/uTLY5IXYTF9Q=; 7:JI4IFy1Pvnz6SFmZBGhP7tSdfkOCaFOIkWbr7vbPSsZge4wQfFHfFiCR9z4bsUkzp2EheiIzjb1eH8KEoIrkD4XkubfPGnc+J/0Fof5QG+Qopm95eEqWg0mqUgndbCS/MqOVlLcOtTUExoeCVFoofyQmGCpkksE27V5jJpoxq3UfE2y5C7Z5a0sSlSzxqrvf/3q/fh7eYY4RBQRIPpdomxp9bwXCEe5jBAG9hBOT0VZDjHdQS146ZPYXjReM3lZI SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: atech.media X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jan 2018 22:05:08.0207 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6e5e5521-0e0a-4824-2055-08d55163b87d X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a8f6edf-720f-4e3d-b767-1360e39a8cdf X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB3492 Content-Type: text/plain; charset="utf-8"; format=flowed 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: Mon, 01 Jan 2018 22:05:13 -0000 On 01/01/18 21:05, Vincenzo Maffione wrote: 2018-01-01 17:14 GMT+01:00 Charlie Smurthwaite >: Hi, Thank you for your reply. I was able to resolve this. 1) I do indeed open one FD per NIC 2) I no longer specify nr_arg1, nr_arg2 nor nr_arg3. Instead I just verify = that all NICs return with identical nr_arg2 so that the memory is shared be= tween them. 3) I properly initialized my memory, my failure to do so was causing me a l= ot of confusion, The resulting memory space is large enough for all the NICs, and everything= works perfectly with zero-copy forwarding, great! The only thing I am still having trouble with is the ability to simultaneou= sly trigger a TX and an RX sync on all NICs. I have tried select, poll, and= epoll, and in all cases, RX rings are updated but TX rings are not and TX = packets are not pushed out (this occurs using both native and emulated netm= ap modes). I notice the documentation says "Note that on epoll and kqueue, = NETMAP_NO_TX_POLL and NETMAP_DO_RX_POLL only have an effect when some event= is posted for the file descriptor.", but the behaviour seems the same on p= oll and select as well as epoll, perhaps this is a linux-specific implement= ation detail? I have also found that all of these mechanisms seem to incur a very high co= st in terms of CPU time (making them no more efficient than busy waiting at= 1Mpps+). My current approach is as follows, but I feel like there should b= e a better option: for(int n=3D0; n web. https://at= ech.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 Tue Jan 2 05:33:23 2018 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 D0CC9EB3AFD for ; Tue, 2 Jan 2018 05:33:23 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEA66FD26 for ; Tue, 2 Jan 2018 05:33:22 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39904131 for freebsd-net@freebsd.org; Tue, 02 Jan 2018 11:28:31 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id w025XH9i090676 for ; Tue, 2 Jan 2018 12:33:19 +0700 (+07) (envelope-from vas@mpeks.tomsk.su) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id w025XDTr090675 for freebsd-net@freebsd.org; Tue, 2 Jan 2018 12:33:13 +0700 (+07) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Tue, 2 Jan 2018 12:33:13 +0700 From: Victor Sudakov To: freebsd-net@freebsd.org Subject: Multiple instances of hostapd? Message-ID: <20180102053313.GA90610@admin.sibptus.transneft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.9.1 (2017-09-22) 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, 02 Jan 2018 05:33:23 -0000 Dear Colleagues, I would like to run multiple instances of hostapd, each per a wlanX interface. I see some provisions for multiple instances inside the /etc/rc.d/hostapd file, but cannot grok the correct rc.conf syntax instead of just hostapd_enable="YES" for a single instance. I don't see it documented anywhere either. Thank you for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 From owner-freebsd-net@freebsd.org Tue Jan 2 05:51:33 2018 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 EA513EB4A81 for ; Tue, 2 Jan 2018 05:51:33 +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 C20C670891 for ; Tue, 2 Jan 2018 05:51:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-206-51-137.dyn.iinet.net.au [203.206.51.137] (may be forged)) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w025pPhF028165 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Jan 2018 21:51:28 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: VLANing between jails not segmenting traffic To: Eugene Grosbein , Farhan Khan , freebsd-net@freebsd.org References: <4d50ef1e-1cc2-aca2-d390-313ef824d524@gmail.com> <59F79902.40408@grosbein.net> From: Julian Elischer Message-ID: <9cdad78c-5663-ab66-37ed-025251780440@freebsd.org> Date: Tue, 2 Jan 2018 13:51:18 +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: <59F79902.40408@grosbein.net> 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: Tue, 02 Jan 2018 05:51:34 -0000 On 31/10/17 5:26 am, Eugene Grosbein wrote: > 31.10.2017 4:08, Farhan Khan пишет: >> Hi all, >> >> I am trying to experiment with setting up two jails on different VLANs, but have not been able to segment traffic. >> >> My configuration was to create vlan1 for jail1 and vlan2 for jail2. >> >> I did the following commands: >> ifconfig vlan1 create vlan 1 vlandev em0 >> ifconfig vlan1 10.1.0.1/24 >> ifconfig vlan2 create vlan 2 vlandev em0 >> ifconfig vlan2 10.2.0.1/24 >> >> Within each jail, I set the interface to be vlan1 and vlan2 and assigned them the IP addresses 10.1.0.2/24 and 10.2.0.2/24, respectively. >> >> I can still have connectivity between the two VLANs. >> >> Oddly enough, jail1 with IP 10.1.0.2 does not even have a static route outbound at all. An `ifconfig` shows 0xffffff00 (/24) so my expected behavior would be to say "unable to route". It can even connect to the external interface's IP address. At a minimum it should not even know how to connect to the 10.2.0.0/24 network at all. >> >> I was advised that its connectivity is because Jails use the base system's routing table. If so, how could one possibly separate network traffic? That's the entire purpose of VLANing. >> >> I have been advised to use pf to prevent that, but shouldn't VLANing provide that separation mechanism? I do not know what I might be doing wrong here. > It seems you are looking for isolated network stacks for jails each having distinct route table etc. > You need options VIMAGE for your kernel and create jails with vnet option (man jail) > to obtain this feature. so, a couple of months later, did you try  out VIMAGE? it's designed to give you EXACTLY what you are looking for. > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@freebsd.org Tue Jan 2 06:46:47 2018 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 A592CEB6DFC for ; Tue, 2 Jan 2018 06:46:47 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 6F9A172387 for ; Tue, 2 Jan 2018 06:46:47 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-oi0-x241.google.com with SMTP id f69so32771557oig.10 for ; Mon, 01 Jan 2018 22:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sToXamNTRVguq3rV2NHwAjOqk3M8r1MLA0/uGNjRwZY=; b=Dvwi7ZavbxNQPcly9P0jufDnsEaZB6/QPh1AMFNzi2tOqR7vJj7QyCSJMcYn5evrS1 wG5we7vKUV8Iy8nxj9h9DwjH4ZgJjijA5xlxJjGJn5IJoatu53s06QJwzWjc1f/v1dEl 7NgmKx6f8/+Oy/uwy9Igp1WJIVii3nL2HjUuE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sToXamNTRVguq3rV2NHwAjOqk3M8r1MLA0/uGNjRwZY=; b=Tpjys6tFhBzsHvChDpne5GPp43w9OaGoMy4BxREq29Kg+zOiq9Jx4EAq8dFq43/UBv 1vsZrQFYqajFLZYA3TIwh6JFecUP229ktOgTIGXg4aFTzXMd9Kr/1iV7VO4sNpPFTLEy Yy8qZptImdXs7n2yyAKNx3ro8XjdMvpp5CUNONZGjFCwlTtSjUz9zkzVU/M9L7XjTfA7 HWFMibstg71um0jIQXYuyALlh6vkkh3Ubi8weaf2O9SyBBFG33YUj+JSwDRKfbOBNTs3 F5xbzCEFrprcnUCO9P0NJz9DiVEVBJzxVSXVuLZP33aRdhVlWKXPTQJ88ifJoIkotJ5J tr4Q== X-Gm-Message-State: AKGB3mL6BUJUGLu0cSGaDrCghsNDTdTkG9iNvtSgbR2+0reHjYTs0A0G rPZO94WnBjPwexRPkNIcnY0qnNPyRno= X-Google-Smtp-Source: ACJfBosl4ov6z8WO6eAt/4AKPKwGXwlvVQg2qMyBikbz84TA+tPKhE/tutoP5aTnLrbGTNiGX7aWdA== X-Received: by 10.202.223.194 with SMTP id w185mr32103531oig.45.1514875606129; Mon, 01 Jan 2018 22:46:46 -0800 (PST) Received: from [192.168.23.194] (cpe-70-114-214-127.austin.res.rr.com. [70.114.214.127]) by smtp.gmail.com with ESMTPSA id t140sm18670573oif.40.2018.01.01.22.46.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jan 2018 22:46:45 -0800 (PST) Mime-Version: 1.0 (1.0) Subject: Re: Multiple instances of hostapd? From: Jim Thompson X-Mailer: iPhone Mail (15C153) In-Reply-To: <20180102053313.GA90610@admin.sibptus.transneft.ru> Date: Tue, 2 Jan 2018 00:46:44 -0600 Cc: freebsd-net@freebsd.org Message-Id: References: <20180102053313.GA90610@admin.sibptus.transneft.ru> To: Victor Sudakov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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, 02 Jan 2018 06:46:47 -0000 https://lists.freebsd.org/pipermail/freebsd-wireless/2015-January/005345.html > On Jan 1, 2018, at 11:33 PM, Victor Sudakov wrote: > > Dear Colleagues, > > I would like to run multiple instances of hostapd, each per a wlanX > interface. I see some provisions for multiple instances inside the > /etc/rc.d/hostapd file, but cannot grok the correct rc.conf syntax > instead of just hostapd_enable="YES" for a single instance. > > I don't see it documented anywhere either. > > Thank you for any input. > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > AS43859 > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@freebsd.org Tue Jan 2 09:07:53 2018 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 D7CD5EBC72E for ; Tue, 2 Jan 2018 09:07:53 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4B27B76B00 for ; Tue, 2 Jan 2018 09:07:51 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39904195 for freebsd-net@freebsd.org; Tue, 02 Jan 2018 15:03:02 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.15.2/8.15.2) with ESMTP id w0297lgI092091 for ; Tue, 2 Jan 2018 16:07:49 +0700 (+07) (envelope-from vas@mpeks.tomsk.su) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.15.2/8.15.2/Submit) id w0297i0W092090 for freebsd-net@freebsd.org; Tue, 2 Jan 2018 16:07:44 +0700 (+07) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Tue, 2 Jan 2018 16:07:44 +0700 From: Victor Sudakov To: freebsd-net@freebsd.org Subject: Re: Multiple instances of hostapd? Message-ID: <20180102090744.GA92056@admin.sibptus.transneft.ru> References: <20180102053313.GA90610@admin.sibptus.transneft.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.9.1 (2017-09-22) 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, 02 Jan 2018 09:07:53 -0000 Jim Thompson wrote: > https://lists.freebsd.org/pipermail/freebsd-wireless/2015-January/005345.html Jim, Are you sure it's a working/complete example? From rc.conf(5) I would rather expect the configs to need names /etc/hostapd-wlan0.conf, /etc/hostapd-wlan1.conf, and not /etc/hostapd2.conf, /etc/hostapd3.conf etc. Besides, why does the poster still have /etc/hostapd.conf? The post you are referring to looks like the poster starts hostapd manually, and only one instance. Need clarification please. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 From owner-freebsd-net@freebsd.org Tue Jan 2 11:36:20 2018 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 E383AE86F55 for ; Tue, 2 Jan 2018 11:36:20 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BB4BB7B610 for ; Tue, 2 Jan 2018 11:36:20 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BA8CAE86F4C; Tue, 2 Jan 2018 11:36:20 +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 BA260E86F4A for ; Tue, 2 Jan 2018 11:36:20 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 7DF987B60F for ; Tue, 2 Jan 2018 11:36:20 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qk0-x235.google.com with SMTP id j137so43211425qke.10 for ; Tue, 02 Jan 2018 03:36:20 -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=wVdZ1CzOEUETiBUBtW7Jap7tCi0jffg6UtrrNso3Pag=; b=UurbqyTQ3xjwhMCMxxho8j88v4V9oTk/kRlBFylvCMCisUgK3bSRZ6TCBozSJsXmD6 8YesMpqJzIDWYVwRK6pGUFrWMAN7iRxY1Dc4FZzOpeSxQn9AABqW4qkhlCsJKQ0QoIwx jT4YLIQeV3EaBa9TOWE5pffDR1SH7qiQI5dvVlEZPrQQVyiF3V53l/Nik2jzjNloLsg0 87SxH912YGjJAoUQfaKb2xynw+CgkpSeWCC/aT2/v6KJfGBX7rx4RI7Icv4HxpzuNFEe z/9LVB79ddQv7ip5x/2iSvqhaoBi/zg2nMQDkHv+UQ+NjTxTdtUpkP7qFlM7QCtJgH+I EAdg== 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=wVdZ1CzOEUETiBUBtW7Jap7tCi0jffg6UtrrNso3Pag=; b=ODEzD52usQq2ijn7l2yUwP7NQ7aziIr1cX0Rt/XCIe3sZ4GP6WXe/YQWdLojKo8pqS KGo+d0Coyzc/zuCw9ZaAJE4wHLZyvoHB6OlWrBB9nY05WrI5vTgRpppQJNAiSvpBMtkQ zyl74BZuEkHYdOASKj7sUHUjTnfBzk9ZQa2LEd+uTgksbZdEJlrhNz8XlungVqHRcVsP 1E4Yng08dvevo/R0Zf/rFrs2zA2Aam7WNH8oqmR+BEOwGteaIZ1ezjUwnG/PTTZC4NnX bxc8poxBxsTNXwRwxDDZjViAC1LmpyvvRdqdcRYDUWm0EJ7ycLfj5+p6Vovoacte9zZt xi2A== X-Gm-Message-State: AKGB3mJiFDshRGK8K90dNiMk/ubburG6R2VQyqWBNRr99we4qdvQIMYC DRAmWQQTcA8Eh0yl8BQWNJvtQxg62ANpmKW8jqJvXA== X-Google-Smtp-Source: ACJfBotQu7XgVlUW+zZK9lmL/+z+JYNcwt0ajc7KbU6ygeO3XmwbHbUCrBUHa8Aq9/PZtHm8D85RrUDi7TaeHOZQpXs= X-Received: by 10.55.212.204 with SMTP id s73mr49083519qks.142.1514892979264; Tue, 02 Jan 2018 03:36:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.5 with HTTP; Tue, 2 Jan 2018 03:36:18 -0800 (PST) In-Reply-To: References: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> <6c5de1ed-0545-31b3-d0e2-4258fa4ccf1c@atech.media> From: Vincenzo Maffione Date: Tue, 2 Jan 2018 12:36:18 +0100 Message-ID: Subject: Re: Linux netmap memory allocation To: Charlie Smurthwaite Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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, 02 Jan 2018 11:36:21 -0000 2018-01-01 23:05 GMT+01:00 Charlie Smurthwaite : > > On 01/01/18 21:05, Vincenzo Maffione wrote: > > > > 2018-01-01 17:14 GMT+01:00 Charlie Smurthwaite : > >> Hi, >> >> Thank you for your reply. I was able to resolve this. >> >> 1) I do indeed open one FD per NIC >> 2) I no longer specify nr_arg1, nr_arg2 nor nr_arg3. Instead I just >> verify that all NICs return with identical nr_arg2 so that the memory is >> shared between them. >> 3) I properly initialized my memory, my failure to do so was causing me a >> lot of confusion, >> >> The resulting memory space is large enough for all the NICs, and >> everything works perfectly with zero-copy forwarding, great! >> >> The only thing I am still having trouble with is the ability to >> simultaneously trigger a TX and an RX sync on all NICs. I have tried >> select, poll, and epoll, and in all cases, RX rings are updated but TX >> rings are not and TX packets are not pushed out (this occurs using both >> native and emulated netmap modes). I notice the documentation says "Note >> that on epoll and kqueue, NETMAP_NO_TX_POLL and NETMAP_DO_RX_POLL only have >> an effect when some event is posted for the file descriptor.", but the >> behaviour seems the same on poll and select as well as epoll, perhaps this >> is a linux-specific implementation detail? >> > I have also found that all of these mechanisms seem to incur a very high >> cost in terms of CPU time (making them no more efficient than busy waiting >> at 1Mpps+). My current approach is as follows, but I feel like there should >> be a better option: >> >> for(int n=0; n> // usleep(10); // More CPU time seems to be saved with a careful >> sleep than with select/poll/epoll >> ioctl(fds[n], NIOCTXSYNC); >> ioctl(fds[n], NIOCRXSYNC); >> rxring = rxrings[n]; >> while (!nm_ring_empty(rxring)) { >> // Forward any packets waiting in this NIC's RX ring to the >> appropriate TX ring >> } >> } >> > > If you are using poll() or select() you should not use ioctl(NIOC*XSYNC), > as the txsync/rxsync operations are automatically performed within the > poll()/select() syscall (at least assuming you did not specify > NETMAP_NO_TX_POLL). > Also, whether netmap calls or does not call txsync/rxsync on certain rings > depends on the parameters passed to nm_open(). > Make sure you check for nm_ring_space(txring) when forwarding. > > Cheers, > Vincenzo > > > > Hi Vincenzo, > > Thanks again for your assistance. You state the following (as does the > manual): > > "If you are using poll() or select() you should not use ioctl(NIOC*XSYNC), > as the txsync/rxsync operations are automatically performed within the > poll()/select() syscall (at least assuming you did not specify > NETMAP_NO_TX_POLL)." > > However, this is not happening for me :( > > I am using poll(), and I am not specifying NETMAP_NO_TX_POLL, and have > found that sometimes frames and sent only when the TX buffer is full, and > sometimes they are not sent at all. They are never sent as expected on > every invocation of poll(). If I run ioctl(NIOCTXSYNC) manually, everything > works correctly. I assume I have simply missed something from my nmreq. > I don't think you have missed anything within nmreq. I see that you are waiting for POLLIN only (and this is right in your router case), so poll() will actually invoke txsync on interface #i only when netmap intercepts an RX or TX interrupt on interface #i. This means that packets may stall for long time in the TX rings if you don't call ioctl(TXSYNC). The manual is not wrong, however. You can look at the apps/bridge/bridge.c example to understand where this "poll automatically calls txsync" thing is useful. > You also mentioned: "whether netmap calls or does not call txsync/rxsync > on certain rings depends on the parameters passed to nm_open()". I do not > use the nm_open helper method, but I am extremely interested to know what > parameters would affect this bahaviour, as this would seem very relevant to > my problem. > Yes, we do not normally use the low level interface (ioctl(REGIF)), because it's just simpler to use the nm_open() interface. Within the first parameter of nm_open() you can specify to open just one RX/TX rings couple, e.g. with "enp1f0s1-3". Then you usually want to mmap() just once (as you do in your program); with nm_open(), you do that with the NM_OPEN_NO_MMAP flag. > > If you are interested or if it helps explain my question, my complete code > (hopefully well commented but far from complete) can be found here: > https://github.com/catphish/netmap-router/blob/ > 58a9b957c19b0a012088c491bd58bc3161a56ff1/router.c > > Specifically, if the ioctl call at line 92 is removed, the code does not > work (packets are not transmitted, or are only transmitted when the buffer > is full, which of these 2 behaviours seems to be random), however I would > expect it to work because I do not specify NETMAP_NO_TX_POLL, and I would > therefore hope that the poll() call on line 80 would have the same effect. > Yes, that depends on when netmap_poll() is called by the kernel, that depends on when something is ready for receive on the file descriptor. Looking at your program, I think you need to call ioctl(TXSYNC), at least because you don't want to introduce artificial/unbounded latency. However, since these calls are expensive, you could use them only when necessary (e.g. when you nm_ring_space(txring) == 0 or when you actually forwarded some packets on txring. > > I hope this all makes sense, and again, I hope I have simply missed > something from the nmreq i pass to NIOCREGIF. > > It is worth mentioning that with the exception of this problem / > confusion, I am getting extremely good results from this code and netmap in > general. > That's nice to hear :) Your program looks simple enough that we could even add it to the examples (as an example of routing logic). Cheers, VIncenzo > > Charlie > > > *Charlie Smurthwaite* > Technical Director > > *tel.* *email.* charlie@atech.media *web.* https://atech.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 in error, we would appreciate it if you could let us know and > delete the message. aTech Media Limited is a UK limited company, > registration number 5523199. Dial 9 Communications Limited is a UK limited > company, registration number 7740921. Viaduct Hosting Limited is a UK > limited company, registration number 8514362. All companies are registered > at Unit 9 Winchester Place, North Street, Poole, Dorset, BH15 1NX.* > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Tue Jan 2 19:11:09 2018 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 5C052EB4304 for ; Tue, 2 Jan 2018 19:11:09 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [IPv6:2001:41d0:302:1100::7:9a96]) (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 229A06DD67; Tue, 2 Jan 2018 19:11:08 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from [IPv6:2003:8c:2e01:df01:bcbc:ff4e:2390:8572] (p2003008C2E01DF01BCBCFF4E23908572.dip0.t-ipconnect.de [IPv6:2003:8c:2e01:df01:bcbc:ff4e:2390:8572]) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 3zB3Z00sPNz3N7; Tue, 2 Jan 2018 20:11:04 +0100 (CET) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at mail.enfer-du-nord.net Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [SOLVED] performance issue within VNET jail From: Michael Grimm In-Reply-To: <5FD6CE98-601B-46B7-B598-83BE5A31200A@ellael.org> Date: Tue, 2 Jan 2018 20:11:03 +0100 Cc: bryanv@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <53C901D3-FA1B-49E7-8623-7FE23493B7E8@ellael.org> References: <4F5EE3F6-0163-4435-8726-56B0D4AE9FAF@ellael.org> <8102F5FD-DCFC-4EF8-A443-9E6C9EB1F467@ellael.org> <8C8A172B-4D4F-4066-8B94-EF5F59E2D345@ellael.org> <5A3D67EC.6010907@grosbein.net> <53687746-C487-4712-AA52-DE86CE70FDEF@ellael.org> <5FD6CE98-601B-46B7-B598-83BE5A31200A@ellael.org> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=2.2 required=5.0 tests=RDNS_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.mer-waases.lan 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, 02 Jan 2018 19:11:09 -0000 Hi, let me come back to this issue I did report end of last year: = https://lists.freebsd.org/pipermail/freebsd-net/2017-December/049470.html My setup: vtnet/pf-NAT <=E2=80=94> epairXa (bridge0) epairXb <-> vnet jail My observations regarding a sample download like "wget = https://download.freebsd.org/ftp/releases/ISO-IMAGES/11.1/FreeBSD-11.1-REL= EASE-amd64-bootonly.iso -O /dev/null" (-) expected performance at the host of about 30 MB/s (-) dramatic loss of performance inside a vnet jail down to = about 80 KB/s My solution: adding 'hw.vtnet.lro_disable=3D"1"' to /boot/loader.conf In the meantime I did find a comparable reference regarding Linux:=20 "Previously, network drivers that had Large Receive Offload = (LRO) enabled by default caused the system to run slow,=20 lose frame, and eventually prevent communication, when using = software bridging. With this update, LRO is automatically=20 disabled by the kernel on systems with a bridged configuration, = thus preventing this bug." https://bugzilla.redhat.com/show_bug.cgi?id=3D772317 I do not have the knowledge to judge if that should be disabled in = FreeBSD as well when software bridging is involved, thus I just want to = let you know.=20 (And that's the reason that I have included the author of the vnet = driver in CC.) With kind regards, Michael= From owner-freebsd-net@freebsd.org Tue Jan 2 20:44:02 2018 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 BFF40EB878B; Tue, 2 Jan 2018 20:44:02 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id AC50872689; Tue, 2 Jan 2018 20:44:01 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 083683AEF2; Tue, 2 Jan 2018 12:38:20 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-hardware@freebsd.org, freebsd-net@freebsd.org Subject: Recommendations for cheap PCI-E network adapter ? Date: Tue, 02 Jan 2018 12:38:19 -0800 Message-ID: <14197.1514925499@segfault.tristatelogic.com> 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, 02 Jan 2018 20:44:02 -0000 I need to buy a PCI-E ethernet card. It won't really matter if it is 10/100/1000 or just 10/100 but it has to work with FreeBSD at a minimum. It would be Nice if it was also supported by Linux and Windoze7, but that isn't really critical. I'm a serious cheapskate, so I'd like to spend as little as possible. I don't need anything super-deluxe. Whatever is cheapest will be fine, even if the performance is only so-so. Recommendations would be appreciated. P.S. The small amount of research I just now did suggests that Realtek based cards should be avoided, but one reviewer said that the Rosewill RC-411v3 works just fine on Ubuntu, so I'm not sure what to think about Realtek-based cards now. The price is right (for me) on the Rosewill RC-411v3, but various online threads (relating to Realtek chips) give me pause... https://forums.freebsd.org/threads/60033/ https://forums.freebsd.org/threads/55861/ I really can't see blowing fifty bucks on a simple, low-end ethernet card, but everything inexpensive seems to be Realtek-based. :-( From owner-freebsd-net@freebsd.org Tue Jan 2 20:47:18 2018 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 2AEA1EB8A82; Tue, 2 Jan 2018 20:47:18 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 9D62C72976; Tue, 2 Jan 2018 20:47:17 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id o26so42668212lfc.10; Tue, 02 Jan 2018 12:47: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=afRxBTHA7+rHM5ITvQ0QIDpnRk263mQEpx7Yhb0aYW8=; b=Ei5ERtnqmcdLovigglQcmgiYnb8BWImVFLDfEbhI+916ZHTOVW22x52QtB0Q3vSGbZ s/GUh9+QTvAWnmq9JPrNEaJz1ZAiVpRyyvURQOOkcx+k9C7WC2P96yUDbkuVTAbQDBEw VjA71cVULZfdNOd8LgxDciG+uf7/8edtQ+WV8r6gWIEEKG1Ai6VVVlEM+mSn5wkRMRnj ae3NzvxpO7zYLEKVAbwEjVZgpaUt+H0pDNd826UluL/qiNJ/vkuy9ev23ygAKRvS8ZC8 V03/w+4SUU2xoWV4E0R+QIvhBNmvMFMbvO33t6wrbfdVoGHWdFDSKbRzpMZ+Xy91sc1u yoXw== 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=afRxBTHA7+rHM5ITvQ0QIDpnRk263mQEpx7Yhb0aYW8=; b=ALU+gqcPlgZWpjOBzg8BTN8kHZO3YMBiAYK1a0GbRPl/giFL2w5AoFAv7ztMhAPqTj ZD+/MQsg4USY45yI+pAQroQTarqPJHbFZytRgqYxMd8D77nNZFyDZbaTDQ9LVZ07W5H4 YGIpBgKpZkdhHoMaJov9mxlP+g0h9nhZoTLqOWb1W4XWU6LREmKDJpbubD+D6oHalStr fliIqho+0LOlVFzCk4rTpESft//SDaraAhb9NQUvvByQT5OZ+lfQQc2QnbS5ziMlCVsu rsnoEG0sJdSoPIq3NSlKshra+3N/2hBliHVNBrogLUJF3mMdy13kX0HNbtfFRoRWBJw0 qPxg== X-Gm-Message-State: AKGB3mKrIw91xs80Du7XFOZOXOUI5hQlrBrrHPmFPF1lYvBLneeEK6+W WaR2dJIrItEO6zbWFASRAwDZc8IYr8gPmS48Og81FQ== X-Google-Smtp-Source: ACJfBosmqZdAk9kHB4yTXynKiUJ6sboTM29k70zCkaxPDbRjWZZopREkRI0fJLU3RAC9NkjS6ipNq4hnb3CvlsYnTUw= X-Received: by 10.25.193.197 with SMTP id r188mr18507815lff.43.1514926035619; Tue, 02 Jan 2018 12:47:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.207 with HTTP; Tue, 2 Jan 2018 12:47:14 -0800 (PST) Received: by 10.25.163.207 with HTTP; Tue, 2 Jan 2018 12:47:14 -0800 (PST) In-Reply-To: References: <4F5EE3F6-0163-4435-8726-56B0D4AE9FAF@ellael.org> <8102F5FD-DCFC-4EF8-A443-9E6C9EB1F467@ellael.org> <8C8A172B-4D4F-4066-8B94-EF5F59E2D345@ellael.org> <5A3D67EC.6010907@grosbein.net> <53687746-C487-4712-AA52-DE86CE70FDEF@ellael.org> <5FD6CE98-601B-46B7-B598-83BE5A31200A@ellael.org> From: Freddie Cash Date: Tue, 2 Jan 2018 12:47:14 -0800 Message-ID: Subject: Re: [SOLVED] performance issue within VNET jail To: Michael Grimm Cc: "Bjoern A. Zeeb" , freebsd-net , freebsd-pf@freebsd.org 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: Tue, 02 Jan 2018 20:47:18 -0000 On Dec 23, 2017 6:06 AM, "Michael Grimm" wrote: I will skip these questions for the time being, because I did solve my issue 15 minutes before your mail ;-) And I feel sorry for all your now "wasted" efforts in trying to help me. As I am using vtnet interface in a cloud environment (Public Cloud by OVH) I did read the vtnet(4) man pages and stumbled about "LOADER TUNABLES" like= : hw.vtnet.lro_disable hw.vtnet.X.lro_disable This tunable disables LRO. The default value is 0. Well, without knowing and understanding the implications of those loader tunables I did disabled them step by step, and bingo, setting =E2=80=A6 hw.vtnet.lro_disable=3D"1" =E2=80=A6 in /boot/loader.conf" and performance is back from KB/s to MB/s. I really do not understand what I have done and why it is working and whether that will have negative implications for my servers. Perhaps someone of you experts could help me understand it. I don't know all the specifics, but PF and IPFW really like to work on individual packets from NICs, especially when doing NAT. They don't play well with batched receives via LRO and batch transmits via TSO. Disabling those on the NICs being used for packet filtering greatly improves throughout. Not sure about PF man page, but pretty sure the IPFW man page mentions disabling those. From owner-freebsd-net@freebsd.org Tue Jan 2 21:01:35 2018 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 88404EB950E; Tue, 2 Jan 2018 21:01:35 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 4E95573532; Tue, 2 Jan 2018 21:01:35 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: by mail-it0-x234.google.com with SMTP id o130so12201562itg.0; Tue, 02 Jan 2018 13:01:35 -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=QGEEwWUENb/jcTsusFIS0Bil8uPU4lYc0otMLf7MHlI=; b=AxhUY8cBAAxcHfMMFFdaLzooGLrOmkWKmcPZ4S5Mth5loB6PyxkA8xRcsisTapjtWo nXeQzyiUYn1Z0/hm474ng1U9afsJ1brP3wUJZegrR86V6cbBuotTKXkbCPtvwsQZ9+ni 7pTLYf0Xft7wn8+fkgvqSnaypsQvKIKrVTJ4IMuYif2ihxDB8m4K7TvlZmE79WGeKcT9 i9dN8zOCQkbk0chWfsQusiE2ga0dKaUpCRO8q3UWg7BOTd6Ps7Fo7OViPGlIhR5K+tEw 1btQ58vy4YbEqyj5ylNnrotZ1eeL2VVZckNVvInWJp9le9p8ap+5DeyoeV+tAxV/gmDs 33pg== 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=QGEEwWUENb/jcTsusFIS0Bil8uPU4lYc0otMLf7MHlI=; b=X09tqnKR/5JNxFrOc7M/WXh9bLgqVL9Rxv3nb6RZl/Rhg885B4bVFYa0OYsFjj+3gl ghNt/8ZRTUPKVFysxwTBczjsl2tDpJs8gDVYKgwpm68LENCWIxHB2BtSHGbWMq/vFp1V jhiNKcx+JYf95go/6wchnZA+aa54Pqwy/53Lu+8Q7PYRxUqnzAbmaK9xM5Ip6pKOP9+T qdskcgRMEqDAv5rAzr0k6U6LdR3jM6HUvAW1ZMjbyj/8xZ5rmN9ITQPWOP0HmbbE+dRg QfEvb9iH7ywPos0lHBVZBkS598E6q9XGShNlM/vvg+5MlPG4mXJ81LWazQhuredxP33o fs0Q== X-Gm-Message-State: AKGB3mJ/i3Rk8mC0TycXzJraFinljlTTcrOAXnpsBaffD8QV8TfIAkag YLuDhtrMAqgYASt1OVe1kqgelniTZKGJ3goH93c= X-Google-Smtp-Source: ACJfBotbpIAibF/7Noaq8o6rxr9S5ghqK6LOL97VeQnQ2hGpNW/hl73HQFTVMzPNq1S7csCLmbahSOol79PIexJJK7Y= X-Received: by 10.36.225.136 with SMTP id n130mr7662210ith.146.1514926894596; Tue, 02 Jan 2018 13:01:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.180.34 with HTTP; Tue, 2 Jan 2018 13:01:34 -0800 (PST) In-Reply-To: <14197.1514925499@segfault.tristatelogic.com> References: <14197.1514925499@segfault.tristatelogic.com> From: Adam Vande More Date: Tue, 2 Jan 2018 15:01:34 -0600 Message-ID: Subject: Re: Recommendations for cheap PCI-E network adapter ? To: "Ronald F. Guilmette" Cc: freebsd-hardware@freebsd.org, freebsd-net Content-Type: text/plain; charset="UTF-8" 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, 02 Jan 2018 21:01:35 -0000 On Tue, Jan 2, 2018 at 2:38 PM, Ronald F. Guilmette wrote: > > I need to buy a PCI-E ethernet card. It won't really matter if it > is 10/100/1000 or just 10/100 but it has to work with FreeBSD at a > minimum. It would be Nice if it was also supported by Linux and > Windoze7, but that isn't really critical. > > I'm a serious cheapskate, so I'd like to spend as little as possible. > I don't need anything super-deluxe. Whatever is cheapest will be fine, > even if the performance is only so-so. > > Recommendations would be appreciated. > > > P.S. The small amount of research I just now did suggests that Realtek > based cards should be avoided, but one reviewer said that the Rosewill > RC-411v3 works just fine on Ubuntu, so I'm not sure what to think about > Realtek-based cards now. The price is right (for me) on the Rosewill > RC-411v3, but various online threads (relating to Realtek chips) give > me pause... > > https://forums.freebsd.org/threads/60033/ > > https://forums.freebsd.org/threads/55861/ > > I really can't see blowing fifty bucks on a simple, low-end ethernet card, > but everything inexpensive seems to be Realtek-based. :-( > > You can get an new but older Intel PCI-E from the big retailer in the sky for ~$20USD. -- Adam From owner-freebsd-net@freebsd.org Tue Jan 2 21:33:29 2018 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 E3052EBAC0A; Tue, 2 Jan 2018 21:33:29 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 70516749DD; Tue, 2 Jan 2018 21:33:29 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id a79so184783wma.0; Tue, 02 Jan 2018 13:33: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=7SjbRbldEyOfQAkoAn4pIjZruJl3/+Di5B/hHX8P02w=; b=EwHv4TRA/UTEIpPpDD4wTXoC/2DZSwolYdj2HHtG0GrrA6GoPL4rfjoAgDeoaAnkX6 M4pMfvH3Dp+Ir/7xHt6TcE9VO8rrCjK7NqBZbauBRRNfKBsaRiP1jN1lUWzDlLrhRQcb KYpF8B9ELB2wA1RAutyU/cOr5kGpPJ3pjTZblKd+yxqFfB50Oj6QEVp5BFvYLSDCqydH SUjGRkCLBgsjSwIfTPje/by8LotB1ifQlvoiVeLpohm+xVd8azY0doW+54/lWnbMqp4W VTbcxW3NAFHb/AbCKDX/n+1d+gyaXC3lWpL4mmzTTYaMT6Y5ah20PngeLLzk3b1EZUrI EOEA== 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=7SjbRbldEyOfQAkoAn4pIjZruJl3/+Di5B/hHX8P02w=; b=G4gEfoR9C+H5sdKXDRzqz9ex40XaYwr//g/Gl70LrqsTd1mbaq7gWRTrIRsSEugjQj bkfrIvx+NMn/o0+kYEdhPqewRxyw3FmExzuiJd22FPoUmo4TGZ+4eWq03dpPRCslTQ1N 5kczePynRvgvFJLqr9PjqYxaDxRnNDj6FvVxaCq/69NWQFeTAoZBNB5HWkZWCa0u2fQL y6qenjjYtkKV3XZ11vN07jJtzegHtjEugva+lWbnQFW4hiQAtM0U3iEwkFYbSyM4JWo3 WikHIOYQKtqNRPPK92SrZpBx9gHMT5//3rbo5hg5/kwa0WzXRI8Lbr5/+J/ImtP87Rr3 04Kw== X-Gm-Message-State: AKGB3mI+Mk3gUyYcc3ALBUv4MonsEaY9POyRhf+3T/pvoAI8icKwovru KTLZ0iZrcrpnZr5I/JpwV9Xxe1/K5XLTQzkoTRqEMTjL X-Google-Smtp-Source: ACJfBoum/qo7kVFJf2SXORU+pf3/Iz97bp7+aDUTJZEveRFBbBB+c9dIB1/lKaiAgxTSp7qiqw4aeKnG73utFbg4OJs= X-Received: by 10.80.137.154 with SMTP id g26mr63069551edg.146.1514928807819; Tue, 02 Jan 2018 13:33:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Tue, 2 Jan 2018 13:33:07 -0800 (PST) In-Reply-To: <14197.1514925499@segfault.tristatelogic.com> References: <14197.1514925499@segfault.tristatelogic.com> From: John Lyon Date: Tue, 2 Jan 2018 16:33:07 -0500 Message-ID: Subject: Re: Recommendations for cheap PCI-E network adapter ? To: "Ronald F. Guilmette" Cc: freebsd-hardware@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" 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, 02 Jan 2018 21:33:30 -0000 Work and work well are two very different things. :-) What's your use case? If this is for a home box, developer box, or something that is not "enterprise production," then I wouldn't worry about RealTek cards bought in the last 5 years. Their 10/100 cards from 15 years ago were crap, which is how they earned their bad reputation. However, the continuing dismissiveness towards RealTek is mostly undeserved in my opinion. The issue currently is the state of the drivers themselves and not the cards. For example, the drivers themselves that FreeBSD includes have problems. However, you can always download the source code to the latest FreeBSD drivers from the RealTek website and all of the "bugs" disappear. For example, using the included FreeBSD drivers on my firewall/router (which uses RealTek NICS), I would get mysterious watchdog timeouts in my system logs and eventual disconnects from the WAN. The only way to reconnect was to reboot. The disconnect would occure every few days to a week when processing more than ~200 Mb of sustained traffic. After downloading, compiling, and installing the latest drivers available on the RealTek website, my problems disappeared. I can now route at sustained gigabit speeds. But this is true of any piece of hardware - you use old or bad drivers and you get bad results. You use newer drivers with the bugs worked out, you get better performance. A large part of the reason why Intel NICS are so beloved and perform so admirably is that the quality of their drivers is much higher. That said, if you're cost sensitive, buy your NICS used. There are lots of suppliers that take decommissioned servers and sell them for parts. The NICS might not be new, they might not even be manufactured anymore, but they are perfectly serviceable. Last time I checked, the going rate for used Intel NICS was something like $10 per port + shipping. I think used Broadcom NICS were similar in pricing. Both have good driver support for both FreeBSD and Linux out of the box, so you don't have to worry about the hassle of downloading, compiling, and installing newer drivers from source. -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Tue, Jan 2, 2018 at 3:38 PM, Ronald F. Guilmette wrote: > > I need to buy a PCI-E ethernet card. It won't really matter if it > is 10/100/1000 or just 10/100 but it has to work with FreeBSD at a > minimum. It would be Nice if it was also supported by Linux and > Windoze7, but that isn't really critical. > > I'm a serious cheapskate, so I'd like to spend as little as possible. > I don't need anything super-deluxe. Whatever is cheapest will be fine, > even if the performance is only so-so. > > Recommendations would be appreciated. > > > P.S. The small amount of research I just now did suggests that Realtek > based cards should be avoided, but one reviewer said that the Rosewill > RC-411v3 works just fine on Ubuntu, so I'm not sure what to think about > Realtek-based cards now. The price is right (for me) on the Rosewill > RC-411v3, but various online threads (relating to Realtek chips) give > me pause... > > https://forums.freebsd.org/threads/60033/ > > https://forums.freebsd.org/threads/55861/ > > I really can't see blowing fifty bucks on a simple, low-end ethernet card, > but everything inexpensive seems to be Realtek-based. :-( > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@freebsd.org Tue Jan 2 21:53:21 2018 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 C7CE6EBB7ED; Tue, 2 Jan 2018 21:53:21 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from kicp.uchicago.edu (kicp.uchicago.edu [128.135.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id AA3D97553E; Tue, 2 Jan 2018 21:53:21 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from point.uchicago.edu (point.uchicago.edu [128.135.52.6]) by kicp.uchicago.edu (Postfix) with ESMTP id 8D7DA71804B; Tue, 2 Jan 2018 15:34:58 -0600 (CST) Subject: Re: Recommendations for cheap PCI-E network adapter ? To: "Ronald F. Guilmette" , freebsd-hardware@freebsd.org, freebsd-net@freebsd.org References: <14197.1514925499@segfault.tristatelogic.com> From: Valeri Galtsev Message-ID: Date: Tue, 2 Jan 2018 15:34:58 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <14197.1514925499@segfault.tristatelogic.com> 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: Tue, 02 Jan 2018 21:53:21 -0000 On 01/02/18 14:38, Ronald F. Guilmette wrote: > > I need to buy a PCI-E ethernet card. It won't really matter if it > is 10/100/1000 or just 10/100 but it has to work with FreeBSD at a > minimum. It would be Nice if it was also supported by Linux and > Windoze7, but that isn't really critical. I have Intel and Broadcom ethernet chips on several servers that run FreeBSD. They are supported under Linux and MS Widows as well. Valeri > > I'm a serious cheapskate, so I'd like to spend as little as possible. > I don't need anything super-deluxe. Whatever is cheapest will be fine, > even if the performance is only so-so. > > Recommendations would be appreciated. > > > P.S. The small amount of research I just now did suggests that Realtek > based cards should be avoided, but one reviewer said that the Rosewill > RC-411v3 works just fine on Ubuntu, so I'm not sure what to think about > Realtek-based cards now. The price is right (for me) on the Rosewill > RC-411v3, but various online threads (relating to Realtek chips) give > me pause... > > https://forums.freebsd.org/threads/60033/ > > https://forums.freebsd.org/threads/55861/ > > I really can't see blowing fifty bucks on a simple, low-end ethernet card, > but everything inexpensive seems to be Realtek-based. :-( > _______________________________________________ > 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" > -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ From owner-freebsd-net@freebsd.org Tue Jan 2 23:07:10 2018 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 C5F2AEBE243 for ; Tue, 2 Jan 2018 23:07:10 +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 8E25877B0F for ; Tue, 2 Jan 2018 23:07:10 +0000 (UTC) (envelope-from charlie@atech.media) Received: by mailman.ysv.freebsd.org (Postfix) id 8A959EBE241; Tue, 2 Jan 2018 23:07:10 +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 8A0A6EBE240 for ; Tue, 2 Jan 2018 23:07:10 +0000 (UTC) (envelope-from charlie@atech.media) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00089.outbound.protection.outlook.com [40.107.0.89]) (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 CA66677B0E for ; Tue, 2 Jan 2018 23:07:08 +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=FHj7BWZYvoJotajglFIOkLPlB7yHgOwERSL0ppCONwY=; b=BmU0P4jCCQ+VaMXT2MNje41BOS12Il1KYmzmLIuajTNkmRqTGRNOQcsVGwoiqnnE3WPxFA65UvRcITJiAFFFdzEknzamjPKSgusOuJVR1G6JRd1AVfIGXLswr+Lxi4Ja5K5gRT5hN7knPDT7hLli7EncxkuJMfgJSZMsFhD6+RM= 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.386.5; Tue, 2 Jan 2018 23:07:05 +0000 Subject: Re: Linux netmap memory allocation To: Vincenzo Maffione Cc: "freebsd-net@freebsd.org" References: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> <6c5de1ed-0545-31b3-d0e2-4258fa4ccf1c@atech.media> From: Charlie Smurthwaite Message-ID: Date: Tue, 2 Jan 2018 23:07:01 +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: Content-Language: en-US X-Originating-IP: [185.102.133.45] X-ClientProxiedBy: AM5PR0601CA0031.eurprd06.prod.outlook.com (2603:10a6:203:68::17) To VI1PR05MB3501.eurprd05.prod.outlook.com (2603:10a6:802:1e::31) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: faf1bb57-f5c2-4e37-df0f-08d552358a91 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307)(7153060); SRVR:VI1PR05MB3501; X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB3501; 3:zS+1XwQttvblqctnrzPAcAwz0D5Go361lXlzfcOn2HlRyYdIX6x6Sc8RVoEWhDVElLvZsPsA0AVEk6IyzPInJGAE4s4kHIJYSzbREfdolYTdxil8PPvQRrnm/Jv9Zw4UlnM/p2wD//Yydreg7JCPSdPKWv1bJb3nU2gmSy1EXcbpAl7xS3azcBR4uQkSYvxyZjM5fySmbVsu6vciH7bdkRJ4ZCLwp+nQ9D83DZzsdJ4SMu6uHJvfS045dRK8/ORV; 25:zm+vugeLktRMigJfRCkf/lxE2pbSlHMAoL/ZNfTCNuDHjtaScmzqVHvONtTH7l3rfDFkvyDn96mvNSnOsSmM8og5yQUjd8uXB8Nz/+WpTF+NF5Lc9Rwv+8WyvxejltENXvDDdHLtyzBXSJTdVjZZkHUGK43UjmwT3VjCKnW/6lzXqNvwauJ/a+1Rs9vlmzMNhcm/M2Pf9lIuAIS7Zy84zzCzYxialyBNJUVfBApeoOhxuJHzG315DVmTpFxOA2MZuZKUv+i2FyCjVpg4LbteUSzw7hyEE/IQNRUtTjLU+H+rGNppF7xK7h1TR8UDzqvDkANPGQaRHhHOpYxsYsjxKA==; 31:pC6NS2kBXk1mllTOu63gmqmindegvzZswoLMCs3FNfQon3nLgP28TN4wD5wQiJ5H1EPM/K7FeBmbIwO3h5J500c6+Plx00U2AxVPDmd1LZE80tGc2o4HLw84/kXZ3Y6/fWX+blZ4cjHynnGjQWnpNbZl0432dBsEbaXX9M8ZABFW8SDP5Y29OWjB9P2NR9Paire6MdVjTRjInYNf1LfDTh3fNkQN5xz9E3oOv6P2ns0= X-MS-TrafficTypeDiagnostic: VI1PR05MB3501: X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB3501; 20:OaoEXYrUeFkmesWZe3Wl3Z9eilKU5SFqIUX0cB87P4Pove9Slk2eXtZCG6+cMvA8BTSZ998hSqipfp/9yh+SNKJewRCJhcb1ZAMJupo5olzXosbv6tBJVhUFCw1RKwcqI4R5sPcuZdYjIWP0dHvxPWkmMQG8X0+kzL7RRGcrwxSZPVa+8Y6tliL8Pj7yC2rdnn+S+kmBY7owWWv1I4nWvU9DMtPqBcfgnR5G286qURmFC6586bJKZfK1lL0GMmSp; 4:07ZN8ArV8jtHVl0NU1+wBHAiSvVQmL23PLL1zmW+9P0yB0BI9nluKTo051RoLkW0pCg02jLB9eKZqjuayliQZgpvAwpIU8nKGD86E/PMq2mhprvHagYOkSSyMD3Dri3ChTBR8hfT+ufJkKtr3BwqskTFSdTXN3bebtpKLkstgQCfm17RanlDFFVwH+YdnF/qS/o5Uq17D0kjUi5J2KwFx25s0HtJkOP1MJ4dSDsVxNKBvZfnIcJHY4IbzfOXKsfwlRYOBfZMS8EuoS9VXbDZiFMvGNQUr8hIrWuUuHQB5KaMDF2HsliR0PnjACFMz92AfVXs6ymCsCi1HRX19QrfLtqEI/R2EyKqo/GtNHsxa10= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(190756311086443)(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231023)(944501075)(6041268)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(2016111802025)(20161123564045)(6072148)(6043046)(201708071742011); SRVR:VI1PR05MB3501; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR05MB3501; X-Forefront-PRVS: 0540846A1D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(979002)(6049001)(39830400003)(346002)(376002)(39380400002)(366004)(396003)(69224002)(189003)(199004)(52544003)(3846002)(2950100002)(5660300001)(84326002)(6666003)(58126008)(606006)(93886005)(106356001)(97736004)(16586007)(236005)(8936002)(6916009)(52116002)(37036004)(83506002)(105586002)(53936002)(316002)(65826007)(7736002)(16576012)(16526018)(6116002)(31686004)(64126003)(345774005)(553524004)(8676002)(478600001)(77096006)(386003)(575784001)(966005)(86362001)(31696002)(81166006)(229853002)(6486002)(59450400001)(81156014)(33964004)(33896004)(4326008)(68736007)(6306002)(54896002)(3480700004)(39060400002)(2906002)(25786009)(65956001)(76176011)(65806001)(6246003)(66066001)(46492003)(969003)(989001)(999001)(1009001)(1019001); 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) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=charlie@atech.media; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR05MB3501; 23:OY1PwCdqxZRIThNv459mnLwyYX7VXB1VexWt72/NO?= =?us-ascii?Q?p6uUsnm+QOxyXhqdid3hgs6VGIFuGEngUkL4H9KUw5CmUFId/mBsLECguZQd?= =?us-ascii?Q?rst/XsLD4pKSNzNmn2L3xw3cmCBvEb4l0liWeYyJKQut6qE43PM/n6CIBT4+?= =?us-ascii?Q?veR/KNNs/BQifSrXBjv+EE8X/awXXcHDZbGOnjUmH3LRapmNZoXNFtK4SL21?= =?us-ascii?Q?+3C9yt0dKx94y1L7guDVE7ZCJIR+L3NuwdsZ1Igei+QPNHj8TZZwql2n/My7?= =?us-ascii?Q?VyjtcXuwS6Zoqh3h+Vy9M1ziXuTlxwWYmhomp5b45KOOIFtmZfiFyvqjpElh?= =?us-ascii?Q?bVzu1ETLkLT+ClAZuImbnfZmZOXWaJZAM16T0subUzk22PLIhPmXu5FmeKFE?= =?us-ascii?Q?p/1u6jnAnLN2K2pLGowA//ifAv1ACbi1GkuFLg23rNg+AvyEGtOOQJyzIOQY?= =?us-ascii?Q?E55Cr6bZnUnUbxZ/z81+qTG0LkEmKWi1b5Fa9U1QII88NRygleGU+UEcBeku?= =?us-ascii?Q?uHso1UOw+5ZVzYAdN6kNxxvjG3+jIrfj6neEjehpGPKUqIMG6WBJjzlrT6mX?= =?us-ascii?Q?PaQJ9l8psiuL1/JwZMGSdfCB+Q5YZrd4P+tsJj/qjGVpc7IYa64SbAiiMEeM?= =?us-ascii?Q?iATx5dhXX7twzWl5i+4tTMIzdZ+wnCeDUfET7IkhEqCTHv9ZIGW/GdPaf1gr?= =?us-ascii?Q?wotf00O0HT9CFzbIOOeNoG82A3zrfmFutykH/fz7og2sHXB7qFOLzbQO7zkD?= =?us-ascii?Q?5wYeNPZ85b0vh+YH4L4ZhrMbc/YuxAbZmb6IdUifkfs2++5UuyIvb4Q/R88P?= =?us-ascii?Q?U0/7e5Vp/i+tD9Ua4kPcnr4dxK2fSeQKMuPBwG573FS4O5PeJsRLXBKeu+ou?= =?us-ascii?Q?dCklB7HPtXAc4voUUSWQsA77Mj+qRuwhW6BFb2Jd4jXYBKvSphuAA3HMY342?= =?us-ascii?Q?gw3eJYZr9PZOTwa5YIuHkGuoWsAooHfL7c7g4YpLoFTux2E14U/wTiqNFMUA?= =?us-ascii?Q?dqd+tyfRy4drobo6D0fMgYZdhb+lrUqZclk5QnykxV3X2mH95SZPghTGW7kc?= =?us-ascii?Q?YMMy3gFbRNUCRhWig6rJ3+yP/K95KnDAIG3QXf5cJmMkKqIw+lpUgSOnWWlU?= =?us-ascii?Q?+g+rTmE2c8+Gugnxbgpw0fIIc0Bde84ZIRGYibIm4CogfhPy5DQn2tbZpnZv?= =?us-ascii?Q?8yHnxAA6qH4HCmLgSBFlvhBPnPFvCTFhnUDEore9sfX7aCfNKc7xRKgvQ3x8?= =?us-ascii?Q?c92olXHxPlbOmZ8+NWO6v2E4JNNmlyUJBn7B6xAc5OjeGoqYh7+wxncqqdJR?= =?us-ascii?Q?wM2opD6qpMdx+XELDKVtAd8Qpe5D4jXNtQtVBd1boAIen9SeSSZGduAmqY5f?= =?us-ascii?Q?dYvDK6bb5uu+qMXeRPxY6K1w4RDBytg59opnR+Qej52xGl5B4UMb2IIGmqCc?= =?us-ascii?Q?mtx3lPR4RRzCuBHMYmRPWaNupwu7/+6itWt3LhwkOubKzy1dLK22W3qPvXsd?= =?us-ascii?Q?6VEinoYtSsg0SeI/LnSqkJwreJ5vCeMoe5tEyTiEmoPNa7XRDvkNHEOdfp/5?= =?us-ascii?Q?ugRIc24IU9rEL+mv40gS3NsD9QchDybWH4kcNwCL+2AgjiN3f75Pqtsfox3Y?= =?us-ascii?Q?Ox00UHBKQK47R1jSYGzwJdr0SqOm9NwEfcpZrdACfNdctZvcWOZm/HYGq2qW?= =?us-ascii?Q?J98?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR05MB3501; 6:KQN/jFcfaXsE8ewG3QDE68qbQ0fe8PDHTlpi+k4xd31TClNFbmdTUAk0oVwtTGClHerv4eTELnaLqya4PDMR+cCatMWzAFWjJa4veGQXSv8f67hmzxIz4K3g3Ssm4blSLa26ULM4AW2Ca0Agd5iurjawZ7nyogHUasHdxXbhZqmsCh3l522Hu5nbmKmaIcwnDv7q6AJKCWe1RBSUeiBo6GCv8JvmENWXhSvf3FaTVCsjdhcCwr/K8SnLmp7wrsWejKHnddQen1U4AgQOkKGhvYx9VzurWq8H/N83QMB1UNxxPeGpFADxFanXdvz6Syyk+hY2iEmM3zrs0Kp4Dl7fsqxJb30vLBS/9OVuoBeHnMQ=; 5:XorkjxfNCVTAwdMTUfm/55HTbdtKC4xt6oYocljwCdqGbSxP0cJE5PTKDBZkOn50cDId5+m6OTPeREYdhNMTmwYRH8rR0GyJYq85FLdgYVVfWKDRtK8H0+zklRwEIfMxgoDN8ElYvwi900jEASjL60ETWGzeCwGJIpRQm48ZpOE=; 24:AcXqUHgoru43GdfrdlcivTK5uyCHsPSWFFbzU2VEf1MfwKgrPUIWZ/w/PyT1OHWEesYp3F/qESwmb78UrEJAQncY7lWeQCHy1xF3brqdAxQ=; 7:64O5Vd2AOyayqLw1xRWzuXoTugtUGwIWCqeNYonfLbyy1Y/mEwD5oYSqwuHAxwz5xKLFUX96rKoWwnjCefzT1VQfQDgMkWQibz86f43XkPOG6DrdXsvQZuMUud306dO4ngic4mJpScwX2BWyuBGIABI2gu73yytEDSGl8cpar9GtWVfCGqqhwAuwjEjhdo/ho0ZuVLQBs4d6O0QDquMl/jx5v36LNPR9l0m8854CHm8KQ/+6IHCWELx2ZF8f1yve SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: atech.media X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jan 2018 23:07:05.2478 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: faf1bb57-f5c2-4e37-df0f-08d552358a91 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7a8f6edf-720f-4e3d-b767-1360e39a8cdf X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB3501 Content-Type: text/plain; charset="utf-8"; format=flowed 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: Tue, 02 Jan 2018 23:07:10 -0000 Hi Vincenzo, I am using poll(), and I am not specifying NETMAP_NO_TX_POLL, and have foun= d that sometimes frames and sent only when the TX buffer is full, and somet= imes they are not sent at all. They are never sent as expected on every inv= ocation of poll(). If I run ioctl(NIOCTXSYNC) manually, everything works co= rrectly. I assume I have simply missed something from my nmreq. I don't think you have missed anything within nmreq. I see that you are wa= iting for POLLIN only (and this is right in your router case), so poll() wi= ll actually invoke txsync on interface #i only when netmap intercepts an RX= or TX interrupt on interface #i. This means that packets may stall for lon= g time in the TX rings if you don't call ioctl(TXSYNC). The manual is not w= rong, however. You can look at the apps/bridge/bridge.c example to understa= nd where this "poll automatically calls txsync" thing is useful. Thank you for the clarification. I have now altered my code to call TXSYNC = after each iteration, but only if I have modified the TX ring for that inte= rface. This seems to work perfectly. The patch can be seen at https://githu= b.com/catphish/netmap-router/commit/2961ab16f14a8b2a2561c9d73f73857e523cc17= 7 You also mentioned: "whether netmap calls or does not call txsync/rxsync on= certain rings depends on the parameters passed to nm_open()". I do not use= the nm_open helper method, but I am extremely interested to know what para= meters would affect this bahaviour, as this would seem very relevant to my = problem. Yes, we do not normally use the low level interface (ioctl(REGIF)), because= it's just simpler to use the nm_open() interface. Within the first paramet= er of nm_open() you can specify to open just one RX/TX rings couple, e.g. w= ith "enp1f0s1-3". Then you usually want to mmap() just once (as you do in y= our program); with nm_open(), you do that with the NM_OPEN_NO_MMAP flag. I did look at nm_open, and even read the source of nm_open to discover how = to implement the shared memory, but (for no good reason) I preferred to set= up the interface manually. If you are interested or if it helps explain my question, my complete code = (hopefully well commented but far from complete) can be found here: https:/= /github.com/catphish/netmap-router/blob/58a9b957c19b0a012088c491bd58bc3161a= 56ff1/router.c Specifically, if the ioctl call at line 92 is removed, the code does not wo= rk (packets are not transmitted, or are only transmitted when the buffer is= full, which of these 2 behaviours seems to be random), however I would exp= ect it to work because I do not specify NETMAP_NO_TX_POLL, and I would ther= efore hope that the poll() call on line 80 would have the same effect. Yes, that depends on when netmap_poll() is called by the kernel, that depen= ds on when something is ready for receive on the file descriptor. Looking at your program, I think you need to call ioctl(TXSYNC), at least b= ecause you don't want to introduce artificial/unbounded latency. However, s= ince these calls are expensive, you could use them only when necessary (e.g= . when you nm_ring_space(txring) =3D=3D 0 or when you actually forwarded so= me packets on txring. Per the patch above I now call TXSYNC on an interface only after pushing a = batch of packets to it and this seems to work perfectly, at least with a go= od balance between performance and latency. If nm_ring_space(txring) =3D=3D= 0 I just drop frames until the next batch. I don't TXSYNC part way through= a batch, it hasn't yet seemed necessary, but I may need to look into this = later. I'm running this on a 6-core 2.8GHz Xeon with a 4-port i350-T4 NIC. I thoug= ht I'd just post some stats of the performance I observe using my code (exc= luding the routing table lookup as this isn't relevant to netmap). Not real= ly looking for any advice here, just thought I'd share my results. All examples are with 1.488Mpps (1 x 1Gbps) input and no packet loss observ= ed: 1 thread - CPU usage =3D 100%, batch size =3D 4 2 thread - CPU usage =3D 54% (27% x 2), batch size =3D 12 4 thread - CPU usage =3D 98% (25% x 4), batch size =3D 8 6 thread - CPU usage =3D 124% (21% x 6), batch size =3D 8 And again with 2.976Mpps (2 x 1Gbps) input and no packet loss observed: 1 thread - CPU usage =3D 100%, batch size =3D 12 2 thread - CPU usage =3D 68% (34% x 2), batch size =3D 21 4 thread - CPU usage =3D 100% (25% x 4), batch size =3D 17 6 thread - CPU usage =3D 105% (18% x 6), batch size =3D 16 These results seem excellent and demonstrate that netmap is scaling as expe= cted with both threads and packet volume. The higher thread count will be m= ore beneficial when I am doing more processing on each packet. I hope this all makes sense, and again, I hope I have simply missed somethi= ng from the nmreq i pass to NIOCREGIF. It is worth mentioning that with the exception of this problem / confusion,= I am getting extremely good results from this code and netmap in general. That's nice to hear :) Your program looks simple enough that we could even add it to the examples = (as an example of routing logic). I'd be very happy to contribute to the documentation in any way that may be= helpful. I have added a permissive licence to my Github repository just in= case my code of of use to anyone else. It is currently somewhat incomplete= as an IPv4 router as it doesn't update MAC addresses on frames before forw= arding them, and because the interface names are hardcoded, but when it's m= ore complete I'd be very happy for it to be contributed to the examples. Of= course anyone is free to use my code for any purpose too. Thanks for all your assistance! I'm happy enough with this that I will move= on to looking at my IP routing code. Charlie Charlie Smurthwaite Technical Director tel. email. charlie@atech.media web. https://at= ech.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 Tue Jan 2 23:14:58 2018 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 48A11EBE799; Tue, 2 Jan 2018 23:14:58 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 244007821A; Tue, 2 Jan 2018 23:14:57 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w02NEtvs093503; Tue, 2 Jan 2018 15:14:55 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w02NEtfK093502; Tue, 2 Jan 2018 15:14:55 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801022314.w02NEtfK093502@pdx.rh.CN85.dnsmgr.net> Subject: Re: Recommendations for cheap PCI-E network adapter ? In-Reply-To: <14197.1514925499@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Tue, 2 Jan 2018 15:14:55 -0800 (PST) CC: freebsd-hardware@freebsd.org, freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 02 Jan 2018 23:14:58 -0000 > > I need to buy a PCI-E ethernet card. It won't really matter if it > is 10/100/1000 or just 10/100 but it has to work with FreeBSD at a > minimum. It would be Nice if it was also supported by Linux and > Windoze7, but that isn't really critical. > > I'm a serious cheapskate, so I'd like to spend as little as possible. > I don't need anything super-deluxe. Whatever is cheapest will be fine, > even if the performance is only so-so. > > Recommendations would be appreciated. > > > P.S. The small amount of research I just now did suggests that Realtek > based cards should be avoided, but one reviewer said that the Rosewill > RC-411v3 works just fine on Ubuntu, so I'm not sure what to think about > Realtek-based cards now. The price is right (for me) on the Rosewill > RC-411v3, but various online threads (relating to Realtek chips) give > me pause... > > https://forums.freebsd.org/threads/60033/ > > https://forums.freebsd.org/threads/55861/ > > I really can't see blowing fifty bucks on a simple, low-end ethernet card, > but everything inexpensive seems to be Realtek-based. :-( I would seek the used channel, you can easily get good Intel chip based nics that just tend to work everywhere, are 10/100/1000, for well under $20 shipped, and often close to $10.00. ebay is the source. Se the em(4) man page for a good list of chips and cards. These well outwork and outperform any realtek card you might find, I have used realtek when it is a builtin, or for simple testing. The 8111 gigabit chips seem to work well everyplace I have used them. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Wed Jan 3 05:11:58 2018 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 AF37EEAB6E8 for ; Wed, 3 Jan 2018 05:11:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C9F637D4 for ; Wed, 3 Jan 2018 05:11:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w035Bwsr002533 for ; Wed, 3 Jan 2018 05:11:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w035BwoO002532 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 05:11:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 138678] [lo] FreeBSD does not assign linklocal address to loopbacks >0 Date: Wed, 03 Jan 2018 05:11:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eadler@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Wed, 03 Jan 2018 05:11:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D138678 Eitan Adler changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Open Assignee|freebsd-net@FreeBSD.org |freebsd-bugs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 05:12:17 2018 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 5B282EAB8A3 for ; Wed, 3 Jan 2018 05:12:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C8903A6A for ; Wed, 3 Jan 2018 05:12:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w035CHVu004683 for ; Wed, 3 Jan 2018 05:12:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w035CHgN004682 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 05:12:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 154214] [stf] [panic] Panic when creating stf interface Date: Wed, 03 Jan 2018 05:12:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eadler@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 03 Jan 2018 05:12:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D154214 Eitan Adler changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |freebsd-bugs@FreeBSD.org Status|In Progress |Open --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 05:12:22 2018 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 6C79AEAB939 for ; Wed, 3 Jan 2018 05:12:22 +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 4FD7F3B10 for ; Wed, 3 Jan 2018 05:12:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w035CMNt004886 for ; Wed, 3 Jan 2018 05:12:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w035CMVn004885 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 05:12:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171532] [ndis] ndis(4) driver includes 'pccard'-specific code, even if 'device pccard' absent from config Date: Wed, 03 Jan 2018 05:12:22 +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: 8.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eadler@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Wed, 03 Jan 2018 05:12:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D171532 Eitan Adler changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Open Assignee|freebsd-net@FreeBSD.org |freebsd-bugs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 05:12:31 2018 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 0B351EABA12 for ; Wed, 3 Jan 2018 05:12:31 +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 8E70B3C00 for ; Wed, 3 Jan 2018 05:12:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w035CSp2005144 for ; Wed, 3 Jan 2018 05:12:28 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w035CSU5005143 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 05:12:28 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 143622] [pfil] [patch] unlock pfil lock while calling firewall hooks Date: Wed, 03 Jan 2018 05:12:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 1.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eadler@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Wed, 03 Jan 2018 05:12:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D143622 Eitan Adler changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Open Assignee|freebsd-net@FreeBSD.org |freebsd-bugs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 08:48:02 2018 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 1DE6DEB45F2 for ; Wed, 3 Jan 2018 08:48:02 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id EA0EF6A276 for ; Wed, 3 Jan 2018 08:48:01 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E960AEB45F1; Wed, 3 Jan 2018 08:48:01 +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 E8E8FEB45F0 for ; Wed, 3 Jan 2018 08:48:01 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 9DD936A275 for ; Wed, 3 Jan 2018 08:48:01 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-qt0-x232.google.com with SMTP id g10so1288758qtj.12 for ; Wed, 03 Jan 2018 00:48:01 -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=jqM5VbpbsnlrVAZ7Bwur45KC8ph7HeaFDL2XsGZNQIE=; b=fJdIA808ErUSBtac7Fz/G9QsFCHJ7/UpGtiRdVYy8yS4Z57TXHmtZJTeuslX6YAbJa Ca8BK4yThTDDXTdx3wLi5Y4yLoQq6hFISkrIR5xWRk3lcPZL/d90zotsZweRG7/O0Bs/ uabWo25BFvcBbf0A5BZ+Bk+42oaLXN9P7NTYANuTJyqpFtIfvBnO4El5VV5rjsrdx6rj FEBZ9FwLZurt1QayXYMmU8EdPVOHOwZNhKsjZLafON8C8FDuuyshuk7H0QUUeGQIUzrR SWjNV1BiOpfH8M4BnLpSncZEenf6NBkHsdCgyh48pZx31Pf+YuwlyFU9PEryIeY2B7vB NUkA== 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=jqM5VbpbsnlrVAZ7Bwur45KC8ph7HeaFDL2XsGZNQIE=; b=kBN8usQ/SEFIzc77pisQuxEaLjPHrZaIAGtkPDWFKZkBlZbcD2DI5yER8QMpyZzwqe g7JFq5vA/u5CP6Agw5O+2Wj2Q0qQsuJWIATPG0C/2ow6M18wPit9ILE1utYgABjik4bf CrcCJZ7Q4XH9PdTdpT0da2ubrKDGyTK74LcWbyaB3VPRddVejiutYWB8isUro3vpjTVS u3c5bGzO3PEvrWqsGSrHRAXO0V128O7AKwFd8IDsMJtw0k9ZX0XubW5l48oAevyQ8SXG bTVEBhg+Ltkz46f+8QXWSJqlzo2YenoqRv1PGrrrg/Gg1DUnCbIsAIBXspqm/2Ojjg8u g5AQ== X-Gm-Message-State: AKGB3mLY6KLuGA/GjnRwENAC5cSuGbmxGc+NwS2l50kpoRKLowY+gu7b YD9Ic3Amj+swc83AIqemIMy35nbXc+hGHvFm0bg= X-Google-Smtp-Source: ACJfBotM7LUxGtTiq2GFQQzQHRa3T81rdufVxUHuLtnyAB0u0rhNyBi/EBrGLAlwnf4436ABeeyVrqjUWLb8YPAFfEc= X-Received: by 10.237.55.226 with SMTP id j89mr801530qtb.173.1514969280571; Wed, 03 Jan 2018 00:48:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.5 with HTTP; Wed, 3 Jan 2018 00:48:00 -0800 (PST) In-Reply-To: References: <7b85fc73-9cc8-0a60-5264-d26f47af5eae@atech.media> <6c5de1ed-0545-31b3-d0e2-4258fa4ccf1c@atech.media> From: Vincenzo Maffione Date: Wed, 3 Jan 2018 09:48:00 +0100 Message-ID: Subject: Re: Linux netmap memory allocation To: Charlie Smurthwaite Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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, 03 Jan 2018 08:48:02 -0000 Hi Charlie, 2018-01-03 0:07 GMT+01:00 Charlie Smurthwaite : > Hi Vincenzo, > > >> I am using poll(), and I am not specifying NETMAP_NO_TX_POLL, and have >> found that sometimes frames and sent only when the TX buffer is full, and >> sometimes they are not sent at all. They are never sent as expected on >> every invocation of poll(). If I run ioctl(NIOCTXSYNC) manually, everything >> works correctly. I assume I have simply missed something from my nmreq. >> > > I don't think you have missed anything within nmreq. I see that you are > waiting for POLLIN only (and this is right in your router case), so poll() > will actually invoke txsync on interface #i only when netmap intercepts an > RX or TX interrupt on interface #i. This means that packets may stall for > long time in the TX rings if you don't call ioctl(TXSYNC). The manual is > not wrong, however. You can look at the apps/bridge/bridge.c example to > understand where this "poll automatically calls txsync" thing is useful. > > Thank you for the clarification. I have now altered my code to call TXSYNC > after each iteration, but only if I have modified the TX ring for that > interface. This seems to work perfectly. The patch can be seen at > https://github.com/catphish/netmap-router/commit/ > 2961ab16f14a8b2a2561c9d73f73857e523cc177 > I see, it looks good. > > > >> You also mentioned: "whether netmap calls or does not call txsync/rxsync >> on certain rings depends on the parameters passed to nm_open()". I do not >> use the nm_open helper method, but I am extremely interested to know what >> parameters would affect this bahaviour, as this would seem very relevant to >> my problem. >> > > Yes, we do not normally use the low level interface (ioctl(REGIF)), > because it's just simpler to use the nm_open() interface. Within the first > parameter of nm_open() you can specify to open just one RX/TX rings couple, > e.g. with "enp1f0s1-3". Then you usually want to mmap() just once (as you > do in your program); with nm_open(), you do that with the NM_OPEN_NO_MMAP > flag. > > I did look at nm_open, and even read the source of nm_open to discover how > to implement the shared memory, but (for no good reason) I preferred to set > up the interface manually. > That's ok. > >> If you are interested or if it helps explain my question, my complete >> code (hopefully well commented but far from complete) can be found here: >> https://github.com/catphish/netmap-router/blob/58a9b957c19b0 >> a012088c491bd58bc3161a56ff1/router.c >> >> Specifically, if the ioctl call at line 92 is removed, the code does not >> work (packets are not transmitted, or are only transmitted when the buffer >> is full, which of these 2 behaviours seems to be random), however I would >> expect it to work because I do not specify NETMAP_NO_TX_POLL, and I would >> therefore hope that the poll() call on line 80 would have the same effect. >> > > Yes, that depends on when netmap_poll() is called by the kernel, that > depends on when something is ready for receive on the file descriptor. > Looking at your program, I think you need to call ioctl(TXSYNC), at least > because you don't want to introduce artificial/unbounded latency. However, > since these calls are expensive, you could use them only when necessary > (e.g. when you nm_ring_space(txring) == 0 or when you actually forwarded > some packets on txring. > > Per the patch above I now call TXSYNC on an interface only after pushing a > batch of packets to it and this seems to work perfectly, at least with a > good balance between performance and latency. If nm_ring_space(txring) == 0 > I just drop frames until the next batch. I don't TXSYNC part way through a > batch, it hasn't yet seemed necessary, but I may need to look into this > later. > Right, there are some heuristics you can try. Calling TXSYNC if you find nm_ring_space(txring) == 0 while forwarding is a common one, as you suggest. It can be beneficial or not, depending on your machine, NIC and workload, so one should just try. > > I'm running this on a 6-core 2.8GHz Xeon with a 4-port i350-T4 NIC. I > thought I'd just post some stats of the performance I observe using my code > (excluding the routing table lookup as this isn't relevant to netmap). Not > really looking for any advice here, just thought I'd share my results. > > All examples are with 1.488Mpps (1 x 1Gbps) input and no packet loss > observed: > 1 thread - CPU usage = 100%, batch size = 4 > 2 thread - CPU usage = 54% (27% x 2), batch size = 12 > 4 thread - CPU usage = 98% (25% x 4), batch size = 8 > 6 thread - CPU usage = 124% (21% x 6), batch size = 8 > > And again with 2.976Mpps (2 x 1Gbps) input and no packet loss observed: > 1 thread - CPU usage = 100%, batch size = 12 > 2 thread - CPU usage = 68% (34% x 2), batch size = 21 > 4 thread - CPU usage = 100% (25% x 4), batch size = 17 > 6 thread - CPU usage = 105% (18% x 6), batch size = 16 > > These results seem excellent and demonstrate that netmap is scaling as > expected with both threads and packet volume. The higher thread count will > be more beneficial when I am doing more processing on each packet. > Yes, as you can see the batch size is very beneficial to CPU utilization and packet rate, because poll/ioctl are kind of expensive. You could try to achieve higher batch to possibly better results. If you don't mind adding a controlled latency you could experiment with adding something like "usleep(30)" in your forwarding loop: this should lead to larger batches. > > >> I hope this all makes sense, and again, I hope I have simply missed >> something from the nmreq i pass to NIOCREGIF. >> >> It is worth mentioning that with the exception of this problem / >> confusion, I am getting extremely good results from this code and netmap in >> general. >> > > That's nice to hear :) > Your program looks simple enough that we could even add it to the examples > (as an example of routing logic). > > I'd be very happy to contribute to the documentation in any way that may > be helpful. I have added a permissive licence to my Github repository just > in case my code of of use to anyone else. It is currently somewhat > incomplete as an IPv4 router as it doesn't update MAC addresses on frames > before forwarding them, and because the interface names are hardcoded, but > when it's more complete I'd be very happy for it to be contributed to the > examples. Of course anyone is free to use my code for any purpose too. > > Thanks for all your assistance! I'm happy enough with this that I will > move on to looking at my IP routing code. > Ok, thanks! Vincenzo > > Charlie > > > > *Charlie Smurthwaite* > Technical Director > > *tel.* *email.* charlie@atech.media *web.* https://atech.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 in error, we would appreciate it if you could let us know and > delete the message. aTech Media Limited is a UK limited company, > registration number 5523199. Dial 9 Communications Limited is a UK limited > company, registration number 7740921. Viaduct Hosting Limited is a UK > limited company, registration number 8514362. All companies are registered > at Unit 9 Winchester Place, North Street, Poole, Dorset, BH15 1NX.* > -- Vincenzo Maffione From owner-freebsd-net@freebsd.org Wed Jan 3 09:50:56 2018 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 6125CEB6C6E for ; Wed, 3 Jan 2018 09:50:56 +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 4C6846C5B1 for ; Wed, 3 Jan 2018 09:50:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w039ouXa001632 for ; Wed, 3 Jan 2018 09:50:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w039ouC8001631 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 09:50:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 138678] [lo] FreeBSD does not assign linklocal address to loopbacks >0 Date: Wed, 03 Jan 2018 09:50:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Wed, 03 Jan 2018 09:50:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D138678 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugen@freebsd.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 09:55:09 2018 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 17C29EB6FB2 for ; Wed, 3 Jan 2018 09:55:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 032576C99A for ; Wed, 3 Jan 2018 09:55:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w039t8Rw016073 for ; Wed, 3 Jan 2018 09:55:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w039t8XL016072 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 09:55:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 218895] ifconfig name with same group name will crash the system Date: Wed, 03 Jan 2018 09:55:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: eugen@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: 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: Wed, 03 Jan 2018 09:55:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218895 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |universite@ukr.net --- Comment #4 from Eugene Grosbein --- *** Bug 154214 has been marked as a duplicate of this bug. *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 10:26:25 2018 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 714FBEB822B for ; Wed, 3 Jan 2018 10:26:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C5296D8BA for ; Wed, 3 Jan 2018 10:26:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w03AQPdX093213 for ; Wed, 3 Jan 2018 10:26:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w03AQPSd093212 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 10:26:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 171532] [ndis] ndis(4) driver includes 'pccard'-specific code, even if 'device pccard' absent from config Date: Wed, 03 Jan 2018 10:26:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Wed, 03 Jan 2018 10:26:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D171532 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugen@freebsd.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --- Comment #3 from Eugene Grosbein --- This is still the problem for stable/11: if_ndis calls functions ndis_alloc_amem/ndis_free_amem from if_ndis_pccard without compile-time che= cks whether device pccard's included or not. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 10:29:43 2018 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 3BC5EEB84B7 for ; Wed, 3 Jan 2018 10:29:43 +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 26BD46DB98 for ; Wed, 3 Jan 2018 10:29:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w03ATh9E097679 for ; Wed, 3 Jan 2018 10:29:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w03AThwZ097678 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 10:29:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 143622] [pfil] [patch] unlock pfil lock while calling firewall hooks Date: Wed, 03 Jan 2018 10:29:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 1.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to 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: Wed, 03 Jan 2018 10:29:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D143622 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org CC| |eugen@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 13:12:12 2018 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 75106EBE7C2 for ; Wed, 3 Jan 2018 13:12:12 +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 602C673BC1 for ; Wed, 3 Jan 2018 13:12:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w03DCCJL075641 for ; Wed, 3 Jan 2018 13:12:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w03DCChK075640 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 13:12:12 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 143622] [pfil] [patch] unlock pfil lock while calling firewall hooks Date: Wed, 03 Jan 2018 13:12:12 +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: 1.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@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: Wed, 03 Jan 2018 13:12:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D143622 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #4 from Andrey V. Elsukov --- I would just note, that ipfw expects PFIL lock is held while it processes a packet. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 14:38:15 2018 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 17425E80112 for ; Wed, 3 Jan 2018 14:38:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2E6B7629A for ; Wed, 3 Jan 2018 14:38:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w03EcEki081710 for ; Wed, 3 Jan 2018 14:38:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w03EcEhf081709 for freebsd-net@FreeBSD.org; Wed, 3 Jan 2018 14:38:14 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 138678] [lo] FreeBSD does not assign linklocal address to loopbacks >0 Date: Wed, 03 Jan 2018 14:38:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-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, 03 Jan 2018 14:38:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D138678 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #3 from Andrey V. Elsukov --- Created attachment 189363 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D189363&action= =3Dedit Proposed patch in6_ifattach fails to add IPv6 loopback address to loopback interface due t= o it already exists on lo0 and then just exits before LLA should be assigned. This patch changes the behavior, it checks for IPv6 loopback address existe= nce in the whole system, not only on given interface. And if loopback address is already configured, it doesn't try assign it again. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Jan 3 19:22:54 2018 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 6B6FBEAB335; Wed, 3 Jan 2018 19:22:54 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id E5DAF289D; Wed, 3 Jan 2018 19:22:52 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id B32F83AEF8; Wed, 3 Jan 2018 11:22:51 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-hardware@freebsd.org, freebsd-net Subject: Re: Recommendations for cheap PCI-E network adapter ? In-Reply-To: Date: Wed, 03 Jan 2018 11:22:51 -0800 Message-ID: <18791.1515007371@segfault.tristatelogic.com> 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, 03 Jan 2018 19:22:54 -0000 I just wanted to say thanks to everyone for the suggestions and insight. I think that I'll end up buying a used Intel PCI-E gigabit card off of Fleabay, and that ought to do it. From owner-freebsd-net@freebsd.org Wed Jan 3 20:13:33 2018 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 EFD0EEAD36C; Wed, 3 Jan 2018 20:13:33 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id D489D63CF2; Wed, 3 Jan 2018 20:13:32 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id E34703AEF8; Wed, 3 Jan 2018 12:13:31 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-hardware@freebsd.org, freebsd-net@freebsd.org Subject: Re: Recommendations for cheap PCI-E network adapter ? In-Reply-To: Date: Wed, 03 Jan 2018 12:13:31 -0800 Message-ID: <18959.1515010411@segfault.tristatelogic.com> 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, 03 Jan 2018 20:13:34 -0000 In message , John Lyon wrote: >What's your use case? If this is for a home box, developer box, or >something that is not "enterprise production," then I wouldn't worry about >RealTek cards bought in the last 5 years. Their 10/100 cards from 15 years >ago were crap, which is how they earned their bad reputation. However, the >continuing dismissiveness towards RealTek is mostly undeserved in my >opinion. This is just for my home network. Not "mission critical", but I don't want my equipment being eternally flaky, of course. And I am not enthused about the possibility of having to frequently build and/or install a new driver that isn't in the stock FreeBSD releases. >The issue currently is the state of the drivers themselves and not the >cards. For example, the drivers themselves that FreeBSD includes have >problems. However, you can always download the source code to the latest >FreeBSD drivers from the RealTek website and all of the "bugs" disappear. Hummm... Am I being naive to ask why, if there are better drivers available, they do not get rolled into -CURRENT? >That said, if you're cost sensitive, buy your NICS used. Oh yes! This is for a "new" system build for which I am buying everything as used parts. Depending on which specific motherboard I decide to go with, I may or may not have a good old fashioned PCI slot to work with on the motherboard. If I do, then I'm good, because as I discovered last night, I have/had, sitting inside a box of old parts up on my top shelf, no fewer than four (4) Realtek cards, two (2) Intel cards, two (2) Netgear cards, one (1) HP card, and even one ancient 3Com 3C509B card. (I'm pretty sure that all of these are 10/100 cards. They are definitely all PCI.) The problem is that all these cards are verging on being obsolete now, because many newer motherboards... and even ones that are several years old now... have dropped the old fashioned PCI slots altogether (e.g. ASUS B85M-G). >Last time I checked, the going rate for >used Intel NICS was something like $10 per port + shipping. I think used >Broadcom NICS were similar in pricing. Really? Where? I checked on FleaBay and as far as -Intel- PCI-E cards, the best I could find was about $12 USD. I don't know how to search FleaBay for Broadcom-based cards, because I don't know any relevant model numbers (or even manufacturer names). From owner-freebsd-net@freebsd.org Wed Jan 3 20:17:48 2018 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 494EAEAD615 for ; Wed, 3 Jan 2018 20:17:48 +0000 (UTC) (envelope-from alena@salesllp.net) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-bo1ind01on0065.outbound.protection.outlook.com [104.47.101.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT TLS CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 62B106407E for ; Wed, 3 Jan 2018 20:17:46 +0000 (UTC) (envelope-from alena@salesllp.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT2831389.onmicrosoft.com; s=selector1-salesllp-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GUYQ9c7RqywrtzVAxkVn3iUTNAIl85NhFDCnmlb/jwg=; b=HIMUtfTAijXVNTzOmldNQa8oozK7HAUEOvo36PRwS4VbloxRaYInUcRznURmchRuDUz6UuX2MmucS9lvGuGza1u//E4Z+GUyNqnr3EeXGYB5PRuQGtdabu8033COlTDZBkQWJFI+TzraNX2bVtTFuoz3brkI8SqqtzeEQR3rWgQ= Received: from MA1PR01MB0040.INDPRD01.PROD.OUTLOOK.COM (10.164.118.144) by MA1PR01MB0038.INDPRD01.PROD.OUTLOOK.COM (10.164.118.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.8; Wed, 3 Jan 2018 20:17:43 +0000 Received: from MA1PR01MB0040.INDPRD01.PROD.OUTLOOK.COM ([10.164.118.144]) by MA1PR01MB0040.INDPRD01.PROD.OUTLOOK.COM ([10.164.118.144]) with mapi id 15.20.0366.009; Wed, 3 Jan 2018 20:17:43 +0000 From: Alena Seth To: "freebsd-net@freebsd.org" Subject: Compliance and Risk Management Thread-Topic: Compliance and Risk Management Thread-Index: AdOEoGwLBqwkGfvTTX+4GPwpYEwbDQ== Date: Wed, 3 Jan 2018 20:17:41 +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=alena@salesllp.net; x-originating-ip: [49.205.218.216] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MA1PR01MB0038; 7:I7bauX7qsPeJ5hf79ABsNm1eLrTfGhfHDJQsG+LOBiQFOaRF4YIVcgqDbUys6EXVl0GjHleP7mg68RDuQDolrSXExr0UQpYdeNxFrR3FEt57H/+klU9Qa8ze9ZJs84lv8nI0S5TsYss5EYGXImNVvfZ4EUOtFSVJ+1ZipmzYvgzZsbt11GqD7X0mOLhY87DNLwdiBYfg48VGk9ojM8PZzJasb7TXkA1ewx9Rel1LMatE42xYZn2ClKfq1ZRUrj81 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c3be3647-28db-4cc7-2f60-08d552e70c1a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:MA1PR01MB0038; x-ms-traffictypediagnostic: MA1PR01MB0038: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(944501075)(10201501046)(6041268)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(2016111802025)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(6043046)(201708071742011); SRVR:MA1PR01MB0038; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MA1PR01MB0038; x-forefront-prvs: 0541031FF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(376002)(346002)(39380400002)(199004)(189003)(6916009)(99286004)(106356001)(105586002)(53936002)(2351001)(97736004)(6506007)(3280700002)(66066001)(2900100001)(59450400001)(77096006)(2906002)(86362001)(5640700003)(102836004)(7736002)(5660300001)(55016002)(6436002)(81156014)(8676002)(14454004)(478600001)(74316002)(316002)(68736007)(3480700004)(6116002)(54896002)(81166006)(9476002)(33656002)(25786009)(6306002)(9686003)(9326002)(4743002)(3660700001)(8936002)(7696005)(2501003)(9406002)(3846002)(202454002); DIR:OUT; SFP:1101; SCL:1; SRVR:MA1PR01MB0038; H:MA1PR01MB0040.INDPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: salesllp.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: oah+sME7RxWCLa5jCUK8tmG87VQV32lvEDDUDapNiBMko2y2mthdadQcDgtD0KLeRMcNpGfT/Bh6gC89gAWzbw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: salesllp.net X-MS-Exchange-CrossTenant-Network-Message-Id: c3be3647-28db-4cc7-2f60-08d552e70c1a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 20:17:41.8320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 13090198-6af4-4804-8825-6b1638c24a01 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR01MB0038 Content-Type: text/plain; charset="us-ascii" 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, 03 Jan 2018 20:17:48 -0000 Hi, Would you be interested in an email leads of Compliance and Risk Management= Executives? We can help you reach out to. Title includes: ? Chief Compliance Officer ? VP Compliance ? Compliance Manager ? Compliance Officer ? Chief Risk Officer ? VP of Risk Management ? Director of Risk Management ? Risk Manager The list comes with complete contact information like Contact name, Email a= ddress, Title, Company name, Phone number, Mailing address, etc. I'd be happy to send over few sample records on your request, and set up a = time to discuss in detail. If this is not relevant to you, please reply back with your Target Market, = we have all types of target markets available. If there is someone else in your organization that I need to speak with, I'= d be grateful if you would forward this email to the appropriate contact an= d help me with the introduction. Have a great day! Regards, Alena Seth / Info Solutions If you don't wish to receive emails from us reply back with "Unsubscribe". From owner-freebsd-net@freebsd.org Wed Jan 3 20:28:04 2018 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 40EA5EADCF3; Wed, 3 Jan 2018 20:28:04 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 BF7CA64C2B; Wed, 3 Jan 2018 20:28:03 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id 64so4701815wme.3; Wed, 03 Jan 2018 12:28:03 -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=0WkRpcdny6UWxs8fVkTGADpT/JrU3601QqC9F50SQTU=; b=PqAfmyiAQ6gKnYrC8GhgMbiQIh9fGyQiCv6MuS6+Y3/z+vooCxQJvfdBoOpmnE0IFO uPD3o8ErKvAyKheYuxTye7isxbZdrElZILgspAZHWF0Oq0LNTbfaewFg2GWZKuuQ9oKm wdU/B1R3mgXFYcHkLDecXmfj0kp89vo5s99bS+ebZdIRDFnIr5VUEM+tzxh+T77roy/b jF90LpObn0gY3OakqfTPHmmXEm5BR8kAcbAZr2NoRRh+mDBl5JyrADQW5xu+monOknpX JJ7knN1s0V+gwn5FqVD6vsSU7u3TWfkQc/V99+U3CMMnEM0XosqrppR0+PWrqL56LmTe N5Ww== 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=0WkRpcdny6UWxs8fVkTGADpT/JrU3601QqC9F50SQTU=; b=Y5nGOdqaAHbCcw2NtGrgOX8VenBUX3/moROnGh3C2cKZju6ORU0VNaqZxqnlv6BbQA dFLOXOp7hhupzUgw06+gwWL0f070lsZI8Q9PDdwrjdIivhIrLENI/qD9TJEoiuJgMCf+ cupsRgak09jN6DQS+TTFqSYjhdDZt8lUIODj+3xrdXQc1nZJN7/JLtZqwA6l+0eam+Au +89tm62In1kthROew1XwM3ET65ak4wQDBhF+E951MO+/g8i57YWeswH6MhmzOi4IeZHb UKBjRFyybWJ0mk9idgIwfYEb9m8AYuMUSWJvjgs/GNnGM7Lxfn/rU55NTJPWYjzWuvtG Boag== X-Gm-Message-State: AKGB3mKW5hiTYnHaETqUm187/wRfC6fVJqrDip070LIHN802DiZsluRT gFpFwSL9O3PPSes61h5iESzDsI2LNRz8RYccbfI= X-Google-Smtp-Source: ACJfBosECe/b+p38rJlLo4DN7xXo3ZmJr/4j1ONlCKycg9dl95g+UUTCgssuDHCL3ZkvGROVdaUoLNrsl91KxNhA+Z0= X-Received: by 10.80.184.52 with SMTP id j49mr4154388ede.160.1515011282320; Wed, 03 Jan 2018 12:28:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Wed, 3 Jan 2018 12:27:41 -0800 (PST) In-Reply-To: <18959.1515010411@segfault.tristatelogic.com> References: <18959.1515010411@segfault.tristatelogic.com> From: John Lyon Date: Wed, 3 Jan 2018 15:27:41 -0500 Message-ID: Subject: Re: Recommendations for cheap PCI-E network adapter ? To: "Ronald F. Guilmette" Cc: freebsd-hardware@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" 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, 03 Jan 2018 20:28:04 -0000 To answer your first question, the better drivers might be in -CURRENT but I would never know as I run -RELEASE/STABLE. :-) However, I can think of any number of possibilities (one, some, or none of which may be true), including: - Licensing incompatibilities - Regressions for older hardware (I can confirm based on personal experience that the latest vendor drivers perform worse on my ~10 year old RealTek cards than the FreeBSD supplied drivers) - Lack of awareness (the RealTek website lists their drivers as being for FreeBSD 8.x but they are really for 11.x and RealTek just never updated their site) - Other reasons known to those more knowledgeable. For your second question, my pricing information is a few years old. When I searched, I was looking on Ebay and Amazon for used parts. I would not be surprised if there were a slight ($1-$2) price inflation between then and now. -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Wed, Jan 3, 2018 at 3:13 PM, Ronald F. Guilmette wrote: > > In message ail.com>, > John Lyon wrote: > > >What's your use case? If this is for a home box, developer box, or > >something that is not "enterprise production," then I wouldn't worry about > >RealTek cards bought in the last 5 years. Their 10/100 cards from 15 > years > >ago were crap, which is how they earned their bad reputation. However, > the > >continuing dismissiveness towards RealTek is mostly undeserved in my > >opinion. > > This is just for my home network. Not "mission critical", but I don't want > my equipment being eternally flaky, of course. And I am not enthused about > the possibility of having to frequently build and/or install a new driver > that isn't in the stock FreeBSD releases. > > >The issue currently is the state of the drivers themselves and not the > >cards. For example, the drivers themselves that FreeBSD includes have > >problems. However, you can always download the source code to the latest > >FreeBSD drivers from the RealTek website and all of the "bugs" disappear. > > Hummm... Am I being naive to ask why, if there are better drivers > available, > they do not get rolled into -CURRENT? > > >That said, if you're cost sensitive, buy your NICS used. > > Oh yes! This is for a "new" system build for which I am buying everything > as used parts. Depending on which specific motherboard I decide to go > with, > I may or may not have a good old fashioned PCI slot to work with on the > motherboard. > > If I do, then I'm good, because as I discovered last night, I have/had, > sitting > inside a box of old parts up on my top shelf, no fewer than four (4) > Realtek > cards, two (2) Intel cards, two (2) Netgear cards, one (1) HP card, and > even > one ancient 3Com 3C509B card. (I'm pretty sure that all of these are > 10/100 > cards. They are definitely all PCI.) > > The problem is that all these cards are verging on being obsolete now, > because > many newer motherboards... and even ones that are several years old now... > have > dropped the old fashioned PCI slots altogether (e.g. ASUS B85M-G). > > >Last time I checked, the going rate for > >used Intel NICS was something like $10 per port + shipping. I think used > >Broadcom NICS were similar in pricing. > > Really? Where? > > I checked on FleaBay and as far as -Intel- PCI-E cards, the best I could > find > was about $12 USD. > > I don't know how to search FleaBay for Broadcom-based cards, because I > don't > know any relevant model numbers (or even manufacturer names). > > _______________________________________________ > 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 Jan 3 20:40:17 2018 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 2E168EAE60E for ; Wed, 3 Jan 2018 20:40:17 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (mail.dpedia.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E31D2654A9 for ; Wed, 3 Jan 2018 20:40:15 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [87.152.190.69] (helo=localhost.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1eWppb-0000jl-VB; Wed, 03 Jan 2018 21:40:12 +0100 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.unixarea.de (8.15.2/8.14.9) with ESMTPS id w03KeBMd003187 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Jan 2018 21:40:11 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by localhost.my.domain (8.15.2/8.14.9/Submit) id w03KeAUk003186; Wed, 3 Jan 2018 21:40:10 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Wed, 3 Jan 2018 21:40:10 +0100 From: Matthias Apitz To: Alena Seth Cc: "freebsd-net@freebsd.org" Subject: Re: Compliance and Risk Management Message-ID: <20180103204010.GA3093@c720-r314251> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Alena Seth , "freebsd-net@freebsd.org" References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 12.0-CURRENT r314251 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. User-Agent: Mutt/1.8.0 (2017-02-23) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 87.152.190.69 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, 03 Jan 2018 20:40:17 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable El d=C3=ADa mi=C3=A9rcoles, enero 03, 2018 a las 08:17:41p. m. +0000, Alena= Seth escribi=C3=B3: > Hi, >=20 > Would you be interested in an email leads of Compliance and Risk Manageme= nt Executives? We can help you reach out to. >=20 > Title includes: >=20 > ... Normally I just send such "offers" to where they belong: SPAM learning folder for SpamAssassin ... But this one asks me to make a comment. IMHO, "Compliance" nowadays tries to be the ultimate corporate answer on all questions in place of ethics, responsibilities and common sense. matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, =E2=8C=82 http://www.unixarea.d= e/ =F0=9F=93=B1 +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXmn7rBYYViyzy/vBR8z35Hb+nREFAlpNP6gACgkQR8z35Hb+ nRFj7w/9Fx892FqPlejZ9uGXN6/V2z9Jk/5JylSvh8+zwW5AI8afXd4ZZvTzfBbl 2jdlCp2r8d3HnOFgX9TMM1gEwnfSN/1znHtbXMxoGZQhRFCU/VXtiOl+eTwPoK9M 84W89GXoT/6CtOYHZgBUlKgScbhE5WsWZD6N6G48WEpY3UNFUwPMNv4jOCUoCDvr 4YAbP8nIzy3Mfwz5qtUE6V/AWRkZ0kP5QueeJOnnPqkqX0bV5GXEt0t0YweoYR3w u5DVUDIVc+JthCm5nDRXpBh9K1UOeIjm6B3i1KhviorLEmTuoZqvUFWFbiGKnmd8 FsNxJGvyKd3TtKR3R1s1dzK48JYt8LhUvwzQkR9USDYDvv1wa55aqfhKaTJEU3Aj g607LQfYOS0GONDTgBP+eaOd8LaofPuMIGdUS2LGCSGHqoSKA+md1vUwWXff8yis /mM6vzixzlDPbmPeth9FjgWQVh+F5+HdBge7hNBzsDpDwSoEOCyf6H9DIZoLktsW hC9fHsD5kOr22AdidDm8yqC4RAnKILd+gEQIFlbgBX0QvKyk+z/NTySvekndvX98 AH7fRDeQu+0c44l2Vib1mnwuCmYKMcealrGQf15KfiYXa+UW7otvbluZcjsBDozX /jXj6qPMYkcmH9zBpmhzc/w+B7g8uQq3mOwESvloluv9NPBCoOo= =Xy3F -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-net@freebsd.org Wed Jan 3 21:51:21 2018 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 90D3CEB1134; Wed, 3 Jan 2018 21:51:21 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 69681681E2; Wed, 3 Jan 2018 21:51:20 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w03LpC3d098173; Wed, 3 Jan 2018 13:51:12 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w03LpCtO098172; Wed, 3 Jan 2018 13:51:12 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201801032151.w03LpCtO098172@pdx.rh.CN85.dnsmgr.net> Subject: Re: Recommendations for cheap PCI-E network adapter ? In-Reply-To: <18959.1515010411@segfault.tristatelogic.com> To: "Ronald F. Guilmette" Date: Wed, 3 Jan 2018 13:51:12 -0800 (PST) CC: freebsd-hardware@freebsd.org, freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 03 Jan 2018 21:51:21 -0000 > > In message , > John Lyon wrote: > > >What's your use case? If this is for a home box, developer box, or > >something that is not "enterprise production," then I wouldn't worry about > >RealTek cards bought in the last 5 years. Their 10/100 cards from 15 years > >ago were crap, which is how they earned their bad reputation. However, the > >continuing dismissiveness towards RealTek is mostly undeserved in my > >opinion. > > This is just for my home network. Not "mission critical", but I don't want > my equipment being eternally flaky, of course. And I am not enthused about > the possibility of having to frequently build and/or install a new driver > that isn't in the stock FreeBSD releases. > > >The issue currently is the state of the drivers themselves and not the > >cards. For example, the drivers themselves that FreeBSD includes have > >problems. However, you can always download the source code to the latest > >FreeBSD drivers from the RealTek website and all of the "bugs" disappear. > > Hummm... Am I being naive to ask why, if there are better drivers available, > they do not get rolled into -CURRENT? > > >That said, if you're cost sensitive, buy your NICS used. > > Oh yes! This is for a "new" system build for which I am buying everything > as used parts. Depending on which specific motherboard I decide to go with, > I may or may not have a good old fashioned PCI slot to work with on the > motherboard. > > If I do, then I'm good, because as I discovered last night, I have/had, sitting > inside a box of old parts up on my top shelf, no fewer than four (4) Realtek > cards, two (2) Intel cards, two (2) Netgear cards, one (1) HP card, and even > one ancient 3Com 3C509B card. (I'm pretty sure that all of these are 10/100 > cards. They are definitely all PCI.) > > The problem is that all these cards are verging on being obsolete now, because > many newer motherboards... and even ones that are several years old now... have > dropped the old fashioned PCI slots altogether (e.g. ASUS B85M-G). > > >Last time I checked, the going rate for > >used Intel NICS was something like $10 per port + shipping. I think used > >Broadcom NICS were similar in pricing. > > Really? Where? > > I checked on FleaBay and as far as -Intel- PCI-E cards, the best I could find > was about $12 USD. > > I don't know how to search FleaBay for Broadcom-based cards, because I don't > know any relevant model numbers (or even manufacturer names). ebay search for broadcom gigabit I see some Dell cards, dual port, $9.95 And some single ports at $4.99 These are shipped prices. Some people cuss at Broadcom, some people swear by them. I don't own any of there cards, but I have never had problems with the inbuilt broadcom nics in any of my dell servers. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-net@freebsd.org Thu Jan 4 16:24:56 2018 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 CC6B8EC1644 for ; Thu, 4 Jan 2018 16:24:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id A5C72720AB for ; Thu, 4 Jan 2018 16:24:56 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 3DDB927502 for ; Thu, 4 Jan 2018 11:17:57 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 67B18107F17 for ; Thu, 4 Jan 2018 10:17:55 -0600 (CST) To: freebsd-net@freebsd.org From: Karl Denninger Subject: IP networking single socket, both IPv4 and V6? Message-ID: <2b3944fc-df1a-9998-876e-ad74f8cc073d@denninger.net> Date: Thu, 4 Jan 2018 10:17:51 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000401010701080301060501" 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, 04 Jan 2018 16:24:56 -0000 This is a cryptographically signed message in MIME format. --------------ms000401010701080301060501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've written a fair bit of code that binds to both Ipv4 and v6 for incoming connections, using two sockets (one for each.) Perusing around the 'net I see an implementation note written by IBM that implies that on their Unix implementation you can set up an INET6 listener and it will open listeners on *both* IPv4 and v6; you code it as an Ipv6 socket/bind/listen/accept, and if an Ipv4 connection comes in you get a prefix'd IPv4 address back when you call getpeername(). This would obviously shorten up code and remove the need to open the second listener socket, but playing with this on FreeBSD it doesn't appear to work -- I only get the IPv6 listener in "netstat -a -n" showing up and as expected a connection to a v4 address on that port fails (refused, since there's no listener.) Is this something that *should* work on FreeBSD? Ref: https://www.ibm.com/support/knowledgecenter/en/ssw_i5_54/rzab6/xacceptbot= h.htm --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000401010701080301060501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMTA0MTYxNzUx WjBPBgkqhkiG9w0BCQQxQgRAP9L1dEmSWx5oNr1aDJakkvgoECF3aNR6nLV3ZyrjNVVMAKiN 9zT4gjhgjcYgd6GbLNd03GFQ2YVRvqFoggiQsjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCV5YM+79aTzl2VENvRZs5CpMglOOAPYSjIVbFuYbmXuiHwcPw25/e0u7S9SPCc8zst JyuBpn8AdE63gifrX4IkCM9nYlRSG5bGp+BpNs6ODDmGLx0BQkDrtdY1YeckuWGlqTKKDx7N NCdsmJXqOt3TCh0yVmur2RPgby25xNqCs7thRWUbhXn9EaToX86J5anrNQWBQ4QYt/uQy4a8 XydrCBsOYIqRsYhCFAEalqXqwdrVIIiB9V1/DS8M4N0s3FrX7MLt9dMhqD5QNXGb7YEPyDVp uPGbyKFa4K5Twzgfchi2r4qpxEgvl6hQukxpgRPTvKtEu1DKwr0dLJSdx2CZG6wBcLuTHI5o 9+3bjVmC2s+AfqlnSqYGMfKx6MtVumz8UmDjAS1cYruYexwpji9jcqJ81U9iNffIjSg14d/z MROaZ1LCdNL5Gww6Lu7y6LRbJSryxG94WWZ/LjJVkwRbwvmGKxLWTghjm54PZQzhkbEn03IZ dOqyvHXYTJaO+s286v4uLDcnb/1DjhlclNQYKrmPx2s6bkMjIZsQppz3Yj38VIuM2xniKY04 BYJouxVjADsfN7indVI1Dseu2ZNPzQiyzY30+g7kdNfoqYHp9OZ1wh2zD8hhxAgGcNu7pgSJ xqtJ0X26xLkqm5+OADb8Btn6gsMfVV+TOEn3reEe0QAAAAAAAA== --------------ms000401010701080301060501-- From owner-freebsd-net@freebsd.org Thu Jan 4 16:48:31 2018 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 1D2D9EA4183 for ; Thu, 4 Jan 2018 16:48:31 +0000 (UTC) (envelope-from lew@perftech.com) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.194.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-gw.pt.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E205F73086 for ; Thu, 4 Jan 2018 16:48:30 +0000 (UTC) (envelope-from lew@perftech.com) X-ASG-Debug-ID: 1515083529-09411a0f9912d2c00001-QdxwpM Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id VCsomdT4O9CEiTsV (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 04 Jan 2018 10:32:09 -0600 (CST) X-Barracuda-Envelope-From: lew@perftech.com X-Barracuda-Effective-Source-IP: mail.pt.net[206.210.194.11] X-Barracuda-Apparent-Source-IP: 206.210.194.11 Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 2B6828428F0; Thu, 4 Jan 2018 10:32:09 -0600 (CST) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id LM1uC34GxSMC; Thu, 4 Jan 2018 10:32:08 -0600 (CST) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 3F9C28428F3; Thu, 4 Jan 2018 10:32:08 -0600 (CST) X-Virus-Scanned: amavisd-new at pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id AagaoLVyC4di; Thu, 4 Jan 2018 10:32:08 -0600 (CST) Received: from dhcp-221-110.perftech.com (dhcp-221-110.perftech.com [206.210.221.110]) (Authenticated sender: lew@pt.net) by mail.pt.net (Postfix) with ESMTPSA id 29E658428F0; Thu, 4 Jan 2018 10:32:08 -0600 (CST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: IP networking single socket, both IPv4 and V6? From: Lewis Donzis X-ASG-Orig-Subj: Re: IP networking single socket, both IPv4 and V6? In-Reply-To: <2b3944fc-df1a-9998-876e-ad74f8cc073d@denninger.net> Date: Thu, 4 Jan 2018 10:32:07 -0600 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2b3944fc-df1a-9998-876e-ad74f8cc073d@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3445.5.20) X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1515083529 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://smtp-gw.pt.net:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at pt.net X-Barracuda-Scan-Msg-Size: 1583 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.46545 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 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, 04 Jan 2018 16:48:31 -0000 On Jan 4, 2018, at 10:17 AM, Karl Denninger wrote: >=20 > I've written a fair bit of code that binds to both Ipv4 and v6 for > incoming connections, using two sockets (one for each.) >=20 > Perusing around the 'net I see an implementation note written by IBM > that implies that on their Unix implementation you can set up an INET6 > listener and it will open listeners on *both* IPv4 and v6; you code it > as an Ipv6 socket/bind/listen/accept, and if an Ipv4 connection comes = in > you get a prefix'd IPv4 address back when you call getpeername(). >=20 > This would obviously shorten up code and remove the need to open the > second listener socket, but playing with this on FreeBSD it doesn't > appear to work -- I only get the IPv6 listener in "netstat -a -n" > showing up and as expected a connection to a v4 address on that port > fails (refused, since there's no listener.) >=20 > Is this something that *should* work on FreeBSD? It works. We do it all the time. You either have to set the sysctl: net.inet6.ip6.v6only=3D0 which you can do in /etc/sysctl.conf or with the sysctl utility, or, in = your program, use setsockopt to turn off the V6ONLY option, e.g.: setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &(int){0}, sizeof (int)); // = Turn off v6-only We use the first method, which is broken in FreeBSD 11.1 prior to patch = level 5 or 6, I can=E2=80=99t remember which, but works in all others. = The second method is considered to be more portable. FWIW, Linux, by default, sets v6only off, so it doesn't require anything = special. From owner-freebsd-net@freebsd.org Thu Jan 4 16:54:53 2018 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 70C76EA4BC0 for ; Thu, 4 Jan 2018 16:54:53 +0000 (UTC) (envelope-from lew@perftech.com) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.194.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-gw.pt.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40474736EE for ; Thu, 4 Jan 2018 16:54:52 +0000 (UTC) (envelope-from lew@perftech.com) X-ASG-Debug-ID: 1515084832-09411a0f9912d47b0001-QdxwpM Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id N6uP43Fu48EFdzZF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 04 Jan 2018 10:53:52 -0600 (CST) X-Barracuda-Envelope-From: lew@perftech.com X-Barracuda-Effective-Source-IP: mail.pt.net[206.210.194.11] X-Barracuda-Apparent-Source-IP: 206.210.194.11 Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id AD9A98426C7; Thu, 4 Jan 2018 10:53:52 -0600 (CST) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id G8m4VIgi5OP2; Thu, 4 Jan 2018 10:53:52 -0600 (CST) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 22F278426C8; Thu, 4 Jan 2018 10:53:52 -0600 (CST) X-Virus-Scanned: amavisd-new at pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id FoQGUUFGXoz0; Thu, 4 Jan 2018 10:53:52 -0600 (CST) Received: from dhcp-221-110.perftech.com (dhcp-221-110.perftech.com [206.210.221.110]) (Authenticated sender: lew@pt.net) by mail.pt.net (Postfix) with ESMTPSA id 0FF98842697; Thu, 4 Jan 2018 10:53:52 -0600 (CST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: IP networking single socket, both IPv4 and V6? From: Lewis Donzis X-ASG-Orig-Subj: Re: IP networking single socket, both IPv4 and V6? In-Reply-To: Date: Thu, 4 Jan 2018 10:53:51 -0600 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <64BFEA30-EF91-4AAB-9E4F-5937CCAEB92B@perftech.com> References: <2b3944fc-df1a-9998-876e-ad74f8cc073d@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3445.5.20) X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1515084832 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://smtp-gw.pt.net:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at pt.net X-Barracuda-Scan-Msg-Size: 2411 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.46545 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 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, 04 Jan 2018 16:54:53 -0000 > On Jan 4, 2018, at 10:32 AM, Lewis Donzis wrote: >=20 > On Jan 4, 2018, at 10:17 AM, Karl Denninger = wrote: >>=20 >> I've written a fair bit of code that binds to both Ipv4 and v6 for >> incoming connections, using two sockets (one for each.) >>=20 >> Perusing around the 'net I see an implementation note written by IBM >> that implies that on their Unix implementation you can set up an = INET6 >> listener and it will open listeners on *both* IPv4 and v6; you code = it >> as an Ipv6 socket/bind/listen/accept, and if an Ipv4 connection comes = in >> you get a prefix'd IPv4 address back when you call getpeername(). >>=20 >> This would obviously shorten up code and remove the need to open the >> second listener socket, but playing with this on FreeBSD it doesn't >> appear to work -- I only get the IPv6 listener in "netstat -a -n" >> showing up and as expected a connection to a v4 address on that port >> fails (refused, since there's no listener.) >>=20 >> Is this something that *should* work on FreeBSD? >=20 > It works. We do it all the time. You either have to set the sysctl: >=20 > net.inet6.ip6.v6only=3D0 >=20 > which you can do in /etc/sysctl.conf or with the sysctl utility, or, = in your program, use setsockopt to turn off the V6ONLY option, e.g.: >=20 > setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &(int){0}, sizeof (int)); = // Turn off v6-only >=20 > We use the first method, which is broken in FreeBSD 11.1 prior to = patch level 5 or 6, I can=E2=80=99t remember which, but works in all = others. The second method is considered to be more portable. >=20 > FWIW, Linux, by default, sets v6only off, so it doesn't require = anything special. I forgot about one other option, which we used to get around the = regression in 11.1 until the kernel gets fixed. Because libc functions = are generally published with a weak reference, you can overload the = socket() function in your own code, like this: int socket (int domain, int type, int protocol) { extern int _socket(int domain, int type, int protocol); int s =3D _socket(domain, type, protocol); if (s >=3D 0 && domain =3D=3D PF_INET6) setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &(int){0}, sizeof (int)); = // Turn off v6-only return s; } We put that in one of our own shared libraries that we bind all of our = programs to, and that solves it without having to change a lot of code.= From owner-freebsd-net@freebsd.org Thu Jan 4 17:28:38 2018 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 0B394EA77F2 for ; Thu, 4 Jan 2018 17:28:38 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id BD35E74E66 for ; Thu, 4 Jan 2018 17:28:37 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id C740427502 for ; Thu, 4 Jan 2018 12:28:07 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id E469F1080EC for ; Thu, 4 Jan 2018 11:28:05 -0600 (CST) Subject: Re: IP networking single socket, both IPv4 and V6? To: freebsd-net@freebsd.org References: <2b3944fc-df1a-9998-876e-ad74f8cc073d@denninger.net> From: Karl Denninger Message-ID: <1d904614-1a3e-bfae-d8d4-843faf528be3@denninger.net> Date: Thu, 4 Jan 2018 11:28:02 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010806010102080303090803" 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, 04 Jan 2018 17:28:38 -0000 This is a cryptographically signed message in MIME format. --------------ms010806010102080303090803 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/4/2018 10:32, Lewis Donzis wrote: > On Jan 4, 2018, at 10:17 AM, Karl Denninger wrote:= >> I've written a fair bit of code that binds to both Ipv4 and v6 for >> incoming connections, using two sockets (one for each.) >> >> Perusing around the 'net I see an implementation note written by IBM >> that implies that on their Unix implementation you can set up an INET6= >> listener and it will open listeners on *both* IPv4 and v6; you code it= >> as an Ipv6 socket/bind/listen/accept, and if an Ipv4 connection comes = in >> you get a prefix'd IPv4 address back when you call getpeername(). >> >> This would obviously shorten up code and remove the need to open the >> second listener socket, but playing with this on FreeBSD it doesn't >> appear to work -- I only get the IPv6 listener in "netstat -a -n" >> showing up and as expected a connection to a v4 address on that port >> fails (refused, since there's no listener.) >> >> Is this something that *should* work on FreeBSD? > It works. We do it all the time. You either have to set the sysctl: > > net.inet6.ip6.v6only=3D0 > > which you can do in /etc/sysctl.conf or with the sysctl utility, or, in= your program, use setsockopt to turn off the V6ONLY option, e.g.: > > setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &(int){0}, sizeof (int)); /= / Turn off v6-only > > We use the first method, which is broken in FreeBSD 11.1 prior to patch= level 5 or 6, I can=E2=80=99t remember which, but works in all others. = The second method is considered to be more portable. > > FWIW, Linux, by default, sets v6only off, so it doesn't require anythin= g special. > Well that explains why it didn't work as expected... thanks :-) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010806010102080303090803 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMTA0MTcyODAy WjBPBgkqhkiG9w0BCQQxQgRAuZ+lItUZNp7ZNU8PvzFokd3cvF3rww2WCrZh1+78xNCsvoWg k4qPC152TBNJUQnoG6ocXRg8vfVvxUvvjbduCjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCkZKc9S5rQS51Xls5QGt8oCJoO5Zji0nuebcsCjC4684l79LgSf2GX1fckGHBQaUjL hInd8q5mHbpndRkh6BznQzCJ8MWnaBgpYzo3rLnwsvDpp+SwPuQjJOUistDRBsVqpHgmys02 UPbsYg+OaZbh1b//r3aZZDcllESysV0fID5ZLKMr2eWiqsp5e9Z3Vr2PY8P+6BDGAekyICQs 2QkQPoLmFGjHFhcvpmyRRHaYKAIBMYDokXBZuYK3dpxjFTLHDKsaNWfmisUbj6V8b4VEwsb+ Sirg71fpLjhfH/HXb0845Yb1sO1HaeatAHJKws5MRCBU2rlisH7mUam8tg2mRDnpImuGBdRb FDH7DKu5Xw/5c557PcFoV33X3V1wEdsRHuHDsaW5vlvmBwkdpuUBHBRm9JQ2Q2n5zbfOnsAL orzRE8t0EArlrWRC0zZ1ACeyP7tNQfkHf1ybo1/WGcjJ2+i9krGy/g32YsVPe7BkIkBTYmGy nQmvRpF1ECChGNyCmj7xtv4yMrXIenivynAD73JFf5wjAmbrsQ3Dir86DPjoLHfEoVmpJx0H LGRkHXgGLBBAajzkwHE1CS2bUIB9F5IXcP6P1oJ5AKX/rvkKCYQ+xmpROvtTEAHxbKUI3K9q ixecobmPfIZMMedXMtWUbnSa3/bxgjNRCvCLlbJNfAAAAAAAAA== --------------ms010806010102080303090803-- From owner-freebsd-net@freebsd.org Thu Jan 4 19:44:15 2018 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 87A45EB1703 for ; Thu, 4 Jan 2018 19:44:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72A037C28A for ; Thu, 4 Jan 2018 19:44:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w04JiFVl022259 for ; Thu, 4 Jan 2018 19:44:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w04JiFr6022258 for freebsd-net@FreeBSD.org; Thu, 4 Jan 2018 19:44:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 221919] ixl: TX queue hang when using TSO and having a high and mixed network load Date: Thu, 04 Jan 2018 19:44:15 +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: erj@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: Thu, 04 Jan 2018 19:44:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221919 --- Comment #11 from Eric Joyner --- This should be fixed in ixl-1.9.5. We're working on getting that upstreamed, but in the meantime, you can down= load it from the Intel download center. https://downloadcenter.intel.com/download/25160/Intel-Network-Adapter-Drive= r-for-PCIe-40-Gigabit-Ethernet-Network-Connection-under-FreeBSD-?product=3D= 36773 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 5 14:03:41 2018 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 BFCB7EAB0BC for ; Fri, 5 Jan 2018 14:03:41 +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 AA86C6A791 for ; Fri, 5 Jan 2018 14:03:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w05E3fbS000895 for ; Fri, 5 Jan 2018 14:03:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w05E3fiq000894 for freebsd-net@FreeBSD.org; Fri, 5 Jan 2018 14:03:41 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 224922] ip_reass should reset M_PKTHDR bit of fragmented packet for NIC which can produce !WRITEABLE mbuf Date: Fri, 05 Jan 2018 14:03:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@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: 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: Fri, 05 Jan 2018 14:03:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224922 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 5 14:08:06 2018 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 60545EAB4D7 for ; Fri, 5 Jan 2018 14:08:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 495696A9AA for ; Fri, 5 Jan 2018 14:08:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w05E868e007019 for ; Fri, 5 Jan 2018 14:08:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w05E866G007018 for freebsd-net@FreeBSD.org; Fri, 5 Jan 2018 14:08:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 224922] ip_reass should reset M_PKTHDR bit of fragmented packet for NIC which can produce !WRITEABLE mbuf Date: Fri, 05 Jan 2018 14:08:06 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@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: 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: Fri, 05 Jan 2018 14:08:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224922 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugen@freebsd.org --- Comment #1 from Eugene Grosbein --- (In reply to Harsh Jain from comment #0) Problem Reports should be self-contained, if possible. Please include relev= ant information here. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Jan 5 19:54:04 2018 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 C9571EBD116 for ; Fri, 5 Jan 2018 19:54:04 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 3CDE17B233 for ; Fri, 5 Jan 2018 19:54:02 +0000 (UTC) (envelope-from reshadpatuck1@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id j137so7314123qke.10 for ; Fri, 05 Jan 2018 11:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=H1dYT9mKFEyNb34T8HW1Jy7J945Cw1Q+hHEJDz5Y2E0=; b=Yf6s5Da1G6LU9PAYaQiAm8QXoaKF7QdDGN4EhQd0dYOA2+TCRAN1bhWIaKngJ7c7Hg X8PAbId41U6kv2YynF6zsB4fZiFvihfwo+Wn8PPoVCRTkk9dytzWXEF1oMBCnxFyBlvr 5td+SEg/u2IWWCuP+in8eAfH5haEEyFDXAZxS37qM+78BpM9trwN9g9dvYeoZc0G4sVy LLBosBKhvQt140gLSPFoq9f2r73xq5O5TMhVBlAMO9L9q7wrHjHOv6Cv/IvGtvJkxW5J igCgzN1HzHjCwbU1juRfn4TFI5H0fFG5jLRM8mEEKxenVke6N0ioSXLn7WPsqqFin38g yBkQ== 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=H1dYT9mKFEyNb34T8HW1Jy7J945Cw1Q+hHEJDz5Y2E0=; b=JXj/hbs1rkarSxYhJ7qggSdqR0VvJUfwMm+fBR+uR7nT7y12IazMrUhi6oeHyqH+6x sTQ7RXmn0hhgZ3tvb0UYLR+pFRJS2ouS3U9Jjw4xh/9MjUcvFmpbGCYGEgkWSGKALG52 hV0egOPAWxsby5lgWbCPaYS66rwqT7Ypd25jfh/waZvPB/DeYUy8ARjcq3azx5huIuRa GQQJV4sfJvqTd4I6Pt0u2Wjm+pSMF4BGmGEz2y9XMNOXTq4JDqMNHtzEl48x4B1LnU+4 ucTxe1j7QVWIMT3pnv80I6dSKJVVNNl1JHZZwdpm7p/qdYTDFgZWBAMfgBH4kVsVzXMc 1vlw== X-Gm-Message-State: AKwxytcfcAmcYiTvf3tZeqJE/cUi4+zM3Fdv/a+FaCGdYc7AZRV/bd2J NJJHEXErL5+5ZztDBsSh9Etbtehx9favGRi38MyfAEeJ X-Google-Smtp-Source: ACJfBov/xz9d16Oj8P4Zt7mjhOhjYaA0LDaKX6ODVPsV7Nu1PviIUil1JRReHTeSeB1MdS1+dIlc9deK9gTMt4caxdg= X-Received: by 10.55.15.2 with SMTP id z2mr5891466qkg.91.1515182040906; Fri, 05 Jan 2018 11:54:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.54.92 with HTTP; Fri, 5 Jan 2018 11:54:00 -0800 (PST) From: Reshad Patuck Date: Sat, 6 Jan 2018 01:24:00 +0530 Message-ID: Subject: [vnet][epair] epair interface stops working after some time To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" 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, 05 Jan 2018 19:54:04 -0000 Hey, I am having a strange issue with one of my servers. I have a couple of VNET jails FreeBSD 12 r321619 set up using if_bridge and epairs. Each VNET jail (and the host too) has a pf firewall limiting inbound traffic. Everything works as intended for some time (1-5 days), services inside the jail work and the jail can connect out to the rest of the network. After some time of working fine I suddenly find that the jails stop receiving traffic and can not send traffic out. Essentially the traffic on one end of the epair does not come out the other. I have linked to a diagram with my network setup for the jails. Essentially the same setup is running on another identical server at another location and has been running for atleast two weeks without any issues. The symptoms are as follows: - I can connect to the server via ssh (on igb0 at IP 192.168.1.50). - All connections from outside the jails work fine from (192.168.1.50 to external IPs) - I can not connect to any services running inside the jails from either outside or inside the server - I can not connect out from the jails (jexec in to the jails and then attempt to connect out) - When I attempt to connect out from one of the jails: - I see arp traffic (via tcpdump) on the epair inside the jail (epair0b) - I cant see the same arp traffic (via tcpdump) on the epair outside the jail (epair0a) - 'arp -a' insde the jails shows incomplete arps for any external IP I try to reach. - When I tcpdump on igb0, bridge0 or epair0a I see broadcast/multicast/general network traffic. - When I tcpdump on epair0b I see no traffic at all. I have done the following on both servers to test what happens: - Created a new epair interface epair3a and epair3b - upped both interfaces - given epair3a IP address 10.20.30.40/24 (I don't have this subnet anywhere in my network) - attempted to ping 10.20.30.50 - checked for any packets on epair3b On the server where epairs are working, I can see APR packets for 10.20.30.50, but on the server where epairs are not working I cant see any packets on epair3b. I can however see the arp packets on epair3a on both servers. This is the third time I have found this on the same server and the other server is still going strong. After rebooting the server this problem seems to go away temporarily, but seems to manifest itself again after some time. Any commands, ideas, thoughts on how to troubleshoot what is wrong here will be much appreciated. Please let me know if there is anything I can do the debug this issue or if you need any other information. Thanks and best regards, Reshad Link to network diagram: https://i.imgur.com/1XdRjt0.jpg From owner-freebsd-net@freebsd.org Fri Jan 5 23:42:04 2018 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 9438BEA7857 for ; Fri, 5 Jan 2018 23:42:04 +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 7F63E6639F for ; Fri, 5 Jan 2018 23:42:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w05Ng4cp085685 for ; Fri, 5 Jan 2018 23:42:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w05Ng4ib085684 for freebsd-net@FreeBSD.org; Fri, 5 Jan 2018 23:42:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 224922] ip_reass should reset M_PKTHDR bit of fragmented packet for NIC which can produce !WRITEABLE mbuf Date: Fri, 05 Jan 2018 23:42:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: np@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: np@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 05 Jan 2018 23:42:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224922 Navdeep Parhar changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |np@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sat Jan 6 04:16:43 2018 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 78A22EB79F9 for ; Sat, 6 Jan 2018 04:16:43 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 CAD24715D0; Sat, 6 Jan 2018 04:16:42 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id f206so5644390wmf.5; Fri, 05 Jan 2018 20:16:42 -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=tG4jY94Adp+8sTbpdRF9Fn+j1gHUmPQ3AJYqKBseaK0=; b=eunjuwP8BehbWxTFxpKGABk3JNErOP64O/til2mrN7VWg/+dbIkleDWAl4CVmC3mQt vQw8GsoV0d6g7Z/a1CjIlztSLB+LRkfsd80yljDOyo6EOX/rYnWF+F73q7Ptp8yePUeN RkKpGIc/1QWB7C3wlh/2ehcOrAwOhUX5GCh7q6sW8XKfBGkTsgeXQWVQoAwrvjEQlHMQ QFzFW5yk/DgEiYXmGLUlsjwkPmWdWsjyHsDWbl3i/dRonzpxbWJsxIomTZU0MRmKGRz+ 9VqFzA3yLbvfO9gO1w4ghhY5d4LUT01sh01UkKrURiy3B/rEPyFslMn31DkZOOUvqBDf PN6Q== 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=tG4jY94Adp+8sTbpdRF9Fn+j1gHUmPQ3AJYqKBseaK0=; b=DeqD2BssoibLfJFBmMe3WjmT4N5ErG3KNmus1gg/iTK5fhblfABtXEOVr8kQJa96xI 9Jjba5g4vOuVNICutT6WmaMvOlWgbnqF3jOcFi8v+1GhnsUrGeeAkHShmKRqMKgiz24P 378iYac6+YoEk3t5Bf8dThNpwrzkm5YyGkNZ2MCGI/e+6wB5Uhiy6DUooniLT2WJdanM PJKN888Mr3KeqBxaj3PCqoQfpNta3HG6mACQwQc36DcTXFLDbhJ+uIYpd+xJJsIb5Dgl h521I+Go53kQFuGfFexCzqM0prj8B51ejBl5b0yGj3HitFQDm3AY3qn7zzyoWfGaYTXm q3IA== X-Gm-Message-State: AKGB3mKYl/MDtzsfjctz6ljOOfYAo99kdLMujS7Xh0bpJuXxgO/IyAq0 IYMd58OajNU6JGXuHYrhUxmtL43ssYcYmwh86jE9KxBU X-Google-Smtp-Source: ACJfBovyxQ7V7xG04liips7oQ8Ym/LuNYiXceoMaD2mEi6CyvTUOFtgTWRvg3HHOt8P4f0d2gTa+UTx7VWfqgk4kW9A= X-Received: by 10.80.203.204 with SMTP id l12mr6899094edi.146.1515212200482; Fri, 05 Jan 2018 20:16:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Fri, 5 Jan 2018 20:16:19 -0800 (PST) In-Reply-To: <3b8d46da-75e3-79f2-379c-b27a88e80733@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> <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> From: John Lyon Date: Fri, 5 Jan 2018 23:16:19 -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: Sat, 06 Jan 2018 04:16:43 -0000 Julian, So this didn't work when I tried to implement it on hardware in real life and I can't figure out why. I am sure it's really basic, but the error message is not very descriptive. I use the following script to create a graph that filters the EAP traffic and forwards directly from the first Ethernet interface to the second. It works perfectly. kldload ng_etf ngctl mkpeer igb0: etf lower downstream ngctl name igb0:lower waneapfilter ngctl connect waneapfilter: igb0: nomatch upper ngctl connect wanfilter: igb1: waneapout lower ngctl msg wanfilter: 'setfilter { matchhook=3D"waneapout" ethertype=3D0x888e }' The end result is that EAPOL frames are forwarded directly from igb0 (WAN) to igb1 (LAN). Graphically, it looks like (arrows indicating flow of traffic): igb0]lower--->>downstream[ETF0]nomatch--->>upper[igb0... waneapout | |------>>lower[igb1.... However, I also need to do the reverse and forward EAPOL frames in the opposite direction from igb1 (LAN) to igb0 (WAN). Graphically, I want (arrows indicating flow): igb1]lower--->>downstream[ETF1]nomatch--->>upper[igb1... laneapout | |------>>lower[igb0.... So I try a mirror image of my first script. However, when I type the first line of: ngctl mkpeer igb1: etf lower downstream I get the following error message: ngctl: send msg: File exists. My guess (based on an earlier email in this thread) is that because I've already connected my first NG_ETF node to the lower hook of igb1 (in order to forward traffic out that interface), I am getting the error that the "File exists" when I try to connect a second ETF node to igb1 lower. If this is the case, how can I write traffic out the interface, while filtering incoming traffic on the same interface? I tried to used two different ETF nodes, as suggested, but get an error message when I try. Thanks for any help. I feel like I am so close. At this point, I probably should have just jumped ship and tried an alternate solution, but I just can't allow the machine to win. :-) I have to get this working! -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Fri, Dec 29, 2017 at 4:06 AM, Julian Elischer wrote= : > 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 connectio= n > 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 o= f >>>> escape characters in case it's an issue with my syntax and I get the s= ame >>>> 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 t= he >>>> bottom of the relevant Netgraph man pages. I figured that must mean i= f 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 downstrea= m >>>> 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 Sat Jan 6 13:22:29 2018 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 3A0C0EB91FA for ; Sat, 6 Jan 2018 13:22:29 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 E2B126D815; Sat, 6 Jan 2018 13:22:28 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-yb0-x232.google.com with SMTP id f16so2885360ybn.0; Sat, 06 Jan 2018 05:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W+fuMXKUPeBIkCpoHhZjnSRepcpKzLwy+hZ6+wpB+Ec=; b=l2/n+LFDmBALRuxhIXhXBDCSAogMVbkolyi675a0WPQjVhkET1Io0DnufaEctVVzFa RX2xT7iohQ4DGPZntzNb5xLaFoJLpk6MPc2LWj+OyrWzjHzqMQJuP0QUR/WDBGa4iHxT Sjf49Qt0IQWX8q1bY9ut/74Z9QpjqGVFvbG2/9L8UFOiWTsku4vcVFvBBlrrl7cdhgcn Pi19Lr+VQx04I7v7XHq6Zw+Zj77PkoobECDThjX2A4iS/M8PSn43+JMfmB3HbnFnbf2h 6G2mKWNsdpFzz4UD9lyKmRAQD8OnaQE5PZpyJCV500XFMGKpSs1xDMlqDlEoEkcDC2f3 PDyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W+fuMXKUPeBIkCpoHhZjnSRepcpKzLwy+hZ6+wpB+Ec=; b=WI3md/3fEKiSyciJKTIQwz8TH4Qf+f6NOKeL3JdBmHhIsTOcP7b5TFk3p3iAWkW9Qd rryCyMK1yN393bxPh1asH+BlTnah/MZCnUwqouZFDpT6aMGt5L/mNqMYv1xgSX4gCQJX S6wNbGt/v5Oxe9uQ7E07AwcceE9ROvQo1VGpqB11raUt5uEk69XYi7psYeJy7xQAlYK3 v7PDk1dYe5THQy0VF5xJpmwe0Hdm+ojPJPNz6jOa9wsWQOAta5pB7xFfx6KdAPp0eEgA eLHcDQISAzwQlwpNcZZHxjytogwPF4u09sBg8Ds6FHWWYYFymgiImBmTeq09EBpSDizA WfsA== X-Gm-Message-State: AKGB3mIHGDOgNUeoEzqjXAqaRQeClnE14QUlAk9L0+kNc+cpcKaJGl0x wQRVZoFtbQTCeKn+eEt8s2JDBni0 X-Google-Smtp-Source: ACJfBotInTY4kxDdafbkjmtDyPVA/yBImP/Vbns8Dmr+t9jS33xRFv3CLP7W/7oc9JPbli487LzvKw== X-Received: by 10.37.61.194 with SMTP id k185mr6000608yba.221.1515244947632; Sat, 06 Jan 2018 05:22:27 -0800 (PST) Received: from [192.168.1.242] (108-215-31-234.lightspeed.tukrga.sbcglobal.net. [108.215.31.234]) by smtp.gmail.com with ESMTPSA id g37sm3472983ywk.95.2018.01.06.05.22.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jan 2018 05:22:26 -0800 (PST) Mime-Version: 1.0 (1.0) Subject: Re: Need Netgraph Help [fixed] From: John Lyon X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Sat, 6 Jan 2018 08:22:25 -0500 Cc: "freebsd-net@freebsd.org" , Eugene Grosbein Message-Id: <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> 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> <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> To: Julian Elischer 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: Sat, 06 Jan 2018 13:22:29 -0000 I just woke up with a follow-up question that may be my aha moment. Are Net= graph edges between nodes always bidirectional? I have been treating all of t= he edges as unidirectional, requiring me to create two separate Netgraphs. B= ut if they are bidirectional, that would explain some things. Thanks. Sent from my iPhone > On Jan 5, 2018, at 11:16 PM, John Lyon wrote: >=20 > Julian, >=20 > So this didn't work when I tried to implement it on hardware in real life a= nd I can't figure out why. I am sure it's really basic, but the error messa= ge is not very descriptive. >=20 > I use the following script to create a graph that filters the EAP traffic a= nd forwards directly from the first Ethernet interface to the second. It wo= rks perfectly. >=20 > kldload ng_etf > ngctl mkpeer igb0: etf lower downstream > ngctl name igb0:lower waneapfilter > ngctl connect waneapfilter: igb0: nomatch upper > ngctl connect wanfilter: igb1: waneapout lower > ngctl msg wanfilter: 'setfilter { matchhook=3D"waneapout" ethertype=3D= 0x888e }' >=20 > The end result is that EAPOL frames are forwarded directly from igb0 (WAN)= to igb1 (LAN). Graphically, it looks like (arrows indicating flow of traff= ic): > igb0]lower--->>downstream[ETF0]nomatch--->>upper[igb0... > waneapout > | > |------>>lower[igb1.... > However, I also need to do the reverse and forward EAPOL frames in the opp= osite direction from igb1 (LAN) to igb0 (WAN). Graphically, I want (arrows i= ndicating flow): > igb1]lower--->>downstream[ETF1]nomatch--->>upper[igb1... > laneapout > | > |------>>lower[igb0.... > So I try a mirror image of my first script. However, when I type the firs= t line of: > ngctl mkpeer igb1: etf lower downstream > I get the following error message: > ngctl: send msg: File exists. > My guess (based on an earlier email in this thread) is that because I've a= lready connected my first NG_ETF node to the lower hook of igb1 (in order to= forward traffic out that interface), I am getting the error that the "File e= xists" when I try to connect a second ETF node to igb1 lower. If this is th= e case, how can I write traffic out the interface, while filtering incoming t= raffic on the same interface? I tried to used two different ETF nodes, as su= ggested, but get an error message when I try.=20 > Thanks for any help. I feel like I am so close. At this point, I probabl= y should have just jumped ship and tried an alternate solution, but I just c= an't allow the machine to win. :-) I have to get this working! >=20 >=20 > -------------------------------- > John L. Lyon > PGP Key Available At:=20 > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >=20 >> On Fri, Dec 29, 2017 at 4:06 AM, Julian Elischer wro= te: >>> On 29/12/17 10:52 am, John Lyon wrote: >>> It works!!! In virtual machine land at least, it works! It will be int= eresting to see what happens when the rubber meets the road and I actually t= est it "in the field." >>>=20 >>> The issue was a missing single line that was not obvious from the man pa= ges: >>>=20 >>> sudo ngctl connect eapfilter: ix1: eapout lower >> your next issue will be that you can only attach em1:lower to a single pe= er at a time. So return packets can not DTRT. >>=20 >> 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 wi= ll feed back out the input hook. >>=20 >> so you need this: >>=20 >> em0]lower---downstream[ETF0]nomatch---upper[em0... >> eapout >> | >> | >> eapout >> em1]lower---downstream[ETF1]nomatch---upper[em1... >>=20 >> =20 >> ie. use an etf node on each interface. >>=20 >>=20 >> =20 >>=20 >>>=20 >>> Apparently, I had not created an alias for the connection between the ET= F 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. >>>=20 >>> Thanks so much for your help. >>>=20 >>>=20 >>> -------------------------------- >>> John L. Lyon >>> PGP Key Available At:=20 >>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>>=20 >>>> On Thu, Dec 28, 2017 at 9:48 AM, Julian Elischer w= rote: >>>>> On 28/12/17 9:59 pm, Julian Elischer wrote: >>>>>> On 28/12/17 1:37 am, John Lyon wrote: >>>>>> Julian, >>>>>>=20 >>>>>> Unfortunately, this issue remains unresolved. I would like to think t= hat 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 of e= rrors. No matter what I do, I can't connect the no match hook of an ETF nod= e to the upper hook of an ng_ether node. Do you have any insights into why t= his might be occurring? >>>>>>=20 >>>>>> By the way, thanks for reaching out to me! I was going to email you d= irectly after the holidays since your name and email address are at the bott= om of the relevant Netgraph man pages. I figured that must mean if you didn= 't know the answer, no one does. :-) >>>>>=20 >>>>> what is EAP? >>>>> what about return EAP packets? (are there any?) >>>>=20 >>>> oops left out a line from the cut-n-paste... >>>>>=20 >>>>> 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 l= ower >>>>> nomatch ix0 ether 00000003 upper >>>>> downstream ix0 ether 00000003 lower >>>>> $ sudo ngctl msg eapfilter: 'setfilter { matchhook=3D"eapout" ethertyp= e=3D0x888e }' >>>>> $ >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>>=20 >>>>>> -------------------------------- >>>>>> John L. Lyon >>>>>> PGP Key Available At: >>>>>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>>>>>=20 >>>>>> On Wed, Dec 27, 2017 at 10:32 AM, Julian Elischer > wrote: >>>>>>=20 >>>>>> John did you get a resolution to this issue? >>>>>>=20 >>>>>>=20 >>>>>> On 16/12/17 2:59 am, John Lyon wrote: >>>>>>=20 >>>>>> Harry and Eugene (and others), >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> As Eugene stated: >>>>>>=20 >>>>>> 1) referenced "matchook" exists and you should not >>>>>> use "indirect name" >>>>>>=20 >>>>>> here, >>>>>>=20 >>>>>> only hook own name, or else you get error ENOENT (No >>>>>> such file or >>>>>>=20 >>>>>> directory); >>>>>>=20 >>>>>> This does not seem to be a problem as the upper and lower >>>>>> hooks for the em1 >>>>>> already exist (I can confirm this). >>>>>>=20 >>>>>> 2) referenced "matchook" is *not* downstream hook, >>>>>> or else you get error >>>>>> EINVAL (Invalid argument); >>>>>>=20 >>>>>> I read the ng_etf.c file in the source tree and found this >>>>>> little snippet: >>>>>>=20 >>>>>> /* and is not the downstream hook */ >>>>>> if (hook =3D=3D etfp->downstream_hook.hook) { >>>>>> error =3D EINVAL; >>>>>> break; >>>>>> } >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 3) it was not already configured, or else you get >>>>>> error EEXIST (File >>>>>>=20 >>>>>> exists). >>>>>>=20 >>>>>> I am not getting this error, so it appears not to be an >>>>>> issue in my case. >>>>>>=20 >>>>>> What am I missing here? The man page states that "*any >>>>>> other *hook" can be >>>>>>=20 >>>>>> 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 wron= g? >>>>>>=20 >>>>>> Thanks for all of your help, patience, and understanding. >>>>>>=20 >>>>>>=20 >>>>>> -------------------------------- >>>>>> John L. Lyon >>>>>> PGP Key Available At: >>>>>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>>>>> >>>>>>=20 >>>>>> On Fri, Dec 15, 2017 at 3:48 AM, Harry Schmalzbauer >>>>>> > >>>>>> wrote: >>>>>>=20 >>>>>> Bez=C3=BCglich Eugene Grosbein's Nachricht vom 14.12.2017= >>>>>> 23:07 (localtime): >>>>>>=20 >>>>>> 15.12.2017 4:27, John Lyon wrote: >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>> and I >>>>>>=20 >>>>>> can't tell what I am doing wrong since >>>>>> my script closely follows the >>>>>> example provided in the n= g_etf man page. >>>>>>=20 >>>>>> For some context, I'm trying to filter >>>>>> EAP traffic coming in on my LAN >>>>>> interface. Any ethernet f= rames that >>>>>> correspond to EAP traffic need >>>>>>=20 >>>>>> to be >>>>>>=20 >>>>>> immediately forwarded from the LAN >>>>>> interface to my WAN interface. All >>>>>> other ethernet frames coming in on my >>>>>> LAN interface need to be >>>>>>=20 >>>>>> handled by >>>>>>=20 >>>>>> the kernel's network stack. A (horrid) >>>>>> ASCII art representation of my >>>>>> desired netgraph would look like this: >>>>>>=20 >>>>>> lower -> em0 -> downstream -> ETF -> no >>>>>> match -> upper em0 >>>>>> -> match -> >>>>>> lower em1 >>>>>>=20 >>>>>> The script I have written is this: >>>>>>=20 >>>>>> #! /bin/sh >>>>>> ngctl mkpeer em0: etf lower downstre= am >>>>>> ngctl name em0:lower lan_filter >>>>>> ngctl connect em0: lan_filter: >>>>>> upper nomatch >>>>>> ngctl msg lan_filter: setfilter { >>>>>> matchhook=3D"em1:lower" >>>>>> ethertype=3D0x888e } >>>>>>=20 >>>>>> Unfortunately, the last line of my >>>>>> script generates the following >>>>>>=20 >>>>>> error >>>>>>=20 >>>>>> message: >>>>>>=20 >>>>>> ngctl: send msg: Invalid Argument >>>>>>=20 >>>>>> For "setfilter" command to work, ng_etf requires that= : >>>>>>=20 >>>>>> 1) referenced "matchook" exists and you should not >>>>>> use "indirect name" >>>>>>=20 >>>>>> here, >>>>>>=20 >>>>>> only hook own name, or else you get error ENOENT (No >>>>>> such file or >>>>>>=20 >>>>>> directory); >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>> exists). >>>>>>=20 >>>>>> 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 th= e >>>>>> 'msg' command. >>>>>>=20 >>>>>> Do idea about the intention, so for the rest you have to >>>>>> tweak as needed. >>>>>>=20 >>>>>> -harry >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> freebsd-net@freebsd.org >>>>>> mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>> >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-net-unsubscribe@freebsd.org >>>>>> " >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"= >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From owner-freebsd-net@freebsd.org Sat Jan 6 16:31:14 2018 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 7317AEC0AE2 for ; Sat, 6 Jan 2018 16:31:14 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA 3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0252D7562D for ; Sat, 6 Jan 2018 16:31:13 +0000 (UTC) (envelope-from zec@fer.hr) Received: from x23 (31.147.124.149) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 6 Jan 2018 17:29:59 +0100 Date: Sat, 6 Jan 2018 17:30:49 +0100 From: Marko Zec To: John Lyon CC: "freebsd-net@freebsd.org" Subject: Re: Need Netgraph Help [fixed] Message-ID: <20180106173049.48e1f044@x23> In-Reply-To: <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> 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> <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.124.149] 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: Sat, 06 Jan 2018 16:31:14 -0000 On Sat, 6 Jan 2018 08:22:25 -0500 John Lyon wrote: > I just woke up with a follow-up question that may be my aha moment. > Are Netgraph edges between nodes always bidirectional? I have been > treating all of the edges as unidirectional, requiring me to create > two separate Netgraphs. But if they are bidirectional, that would > explain some things. edges -> hooks in netgraph parlance man 4 netgraph -> /Hooks -> "Data flows bidirectionally between nodes" A lot of people arrive at BSD / netgraph with previous experiences with the Click modular router, which might have caused the confusion, since in Click all datapaths are always unidirectional. Not (necessarily) so in netgraph. From owner-freebsd-net@freebsd.org Sat Jan 6 19:39:23 2018 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 69811DB8107 for ; Sat, 6 Jan 2018 19:39:23 +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 3D8107C4F5 for ; Sat, 6 Jan 2018 19:39:22 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-223-243.dyn.iinet.net.au [124.148.223.243]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w06Jd8NA054358 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 6 Jan 2018 11:39:13 -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> <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> From: Julian Elischer Message-ID: Date: Sun, 7 Jan 2018 03:39:02 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> 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: Sat, 06 Jan 2018 19:39:23 -0000 On 6/1/18 9:22 pm, John Lyon wrote: > I just woke up with a follow-up question that may be my aha moment. >  Are Netgraph edges between nodes always bidirectional? I have been > treating all of the edges as unidirectional, requiring me to create > two separate Netgraphs.  But if they are bidirectional, that would > explain some things. yes edges are bidirectional see the following paragraph from the ng_etf man page: -----      Packets traveling in the other direction (towards the downstream hook)      are also examined and filtered.  If a packet has an ethertype that      matches one of the values configured into the node, it must have arrived      in on the hook for which that value was configured, otherwise it will be      discarded.  Ethertypes of values other than those configured by the con-      trol messages must have arrived via the nomatch hook. ----- here is the picture of what you need, You will see this below in the old emails: 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.     ngctl mkpeer igb0: etf lower downstream     ngctl name igb0:lower waneapfilter     ngctl connect waneapfilter: igb0: nomatch upper     ngctl mkpeer igb1: etf lower downstream     ngctl name igb1:lower laneapfilter     ngctl connect laneapfilter: igb1: nomatch upper     ngctl connect waneapfilter laneapfilter eapout eapout     ngctl msg waneapfilter: 'setfilter { matchhook="eapout" ethertype=0x888e }'     ngctl msg laneapfilter: 'setfilter { matchhook="eapout" ethertype=0x888e }' > > Thanks. > > Sent from my iPhone > > On Jan 5, 2018, at 11:16 PM, John Lyon > wrote: > >> Julian, >> >> So this didn't work when I tried to implement it on hardware in >> real life and I can't figure out why.  I am sure it's really basic, >> but the error message is not very descriptive. >> >> I use the following script to create a graph that filters the EAP >> traffic and forwards directly from the first Ethernet interface to >> the second.  It works perfectly. >> >>     kldload ng_etf >>     ngctl mkpeer igb0: etf lower downstream >>     ngctl name igb0:lower waneapfilter >>     ngctl connect waneapfilter: igb0: nomatch upper >>     ngctl connect wanfilter: igb1: waneapout lower >>     ngctl msg wanfilter: 'setfilter { matchhook="waneapout" >> ethertype=0x888e }' >> >> The end result is that EAPOL frames are forwarded directly from >> igb0 (WAN) to igb1 (LAN).  Graphically, it looks like (arrows >> indicating flow of traffic): >> igb0]lower--->>downstream[ETF0]nomatch--->>upper[igb0... >> waneapout >> | >> |------>>lower[igb1.... >> However, I also need to do the reverse and forward EAPOL frames in the opposite direction from igb1 (LAN) to igb0 (WAN). Graphically, I want (arrows indicating flow): >> igb1]lower--->>downstream[ETF1]nomatch--->>upper[igb1... laneapout | >> |------>>lower[igb0.... >> So I try a mirror image of my first script. However, when I type the first line of: >> ngctl mkpeer igb1: etf lower downstream >> I get the following error message: >> ngctl: send msg: File exists. >> My guess (based on an earlier email in this thread) is that because I've already connected my first NG_ETF node to the lower hook of igb1 (in order to forward traffic out that interface), I am getting the error that the "File exists" when I try to connect a second ETF node to igb1 lower. If this is the case, how can I write traffic out the interface, while filtering incoming traffic on the same interface? I tried to used two different ETF nodes, as suggested, but get an error message when I try. >> Thanks for any help. I feel like I am so close. At this point, I probably should have just jumped ship and tried an alternate solution, but I just can't allow the machine to win. :-) I have to get this working! >> >> -------------------------------- >> John L. Lyon >> PGP Key Available At: >> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >> >> On Fri, Dec 29, 2017 at 4:06 AM, Julian Elischer >> > wrote: >> >> 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 Sat Jan 6 20:02:32 2018 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 78D3ADBB479 for ; Sat, 6 Jan 2018 20:02:32 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 B52F97D3F5; Sat, 6 Jan 2018 20:02:31 +0000 (UTC) (envelope-from johnllyon@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id i11so7853233wmf.4; Sat, 06 Jan 2018 12:02:31 -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=n0R9O7XCmKXC4QK+GhEZUdf2YTi0fHP++/6qczmXCcU=; b=RzW5WcGGeVtRu9gm12J+pXbWpvvsoUnBK6FFNWEAv9dEc06p0LcMCc3/BokxSfIZQy TLObmkUk24z1+3TXaZ7TvBRk+VY8yQ7pTjA4uDpAijK3ZhafB79XW1yy6aTzyPgRMSwC 0CGJxqkWiNE6sLsySJeE4YG0vZdV4J5ZvH8baMgVg5qmfUx2XxH6fEmfGs//A8A1maXR EOil78asDCfz43HtvKGO6OoVgx4cTTmqMp3oHgcPKQXGfGKVjrU2faS4oWBE+y5FfUtv ISGtHM6+QksNV3NDtoHqiccD5/hAzyXBv6QphAKhzZRRdlyu59RvGq+C346bh/qh+E6r Sb6A== 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=n0R9O7XCmKXC4QK+GhEZUdf2YTi0fHP++/6qczmXCcU=; b=mXfS2yvVlVm4+7VXhe2C8wHjZfkH1hBdmlVWUvwn60T4hzTjU2vzNXO/5Wx1BBFDG/ CA/Vag/aVWFZW4HgFu4ZMdMPTTitILocDM0+ByjnwTqy//jQydTgsiEOrFzRevUxAehY rjZgxXoPV/rj27oGFLTdGkPUjnTrHUhcan7sqyaNQxCd8hEf3DD8exqyXSbF9wmpLdMV P3VpD/zCFU0VCPVFaI7UQabKgWC2ppgckjnG7i/dtT6E2opvE+lHiHJQndyHewBgEigr 6i70FDu0RM8SeK7MSssBOjJAquKKitqtXJAsHJKc3UmGQmYKRDI6NLgV+Mx9wYKU5gna H0jg== X-Gm-Message-State: AKGB3mKzOxJBkG63wekd0bBxdJ9lQRj/1zY3zYTTuLzxspPH0CjqAy7w 3bIFpn+JjDC7RSK38ss14gHeWIUktdnF7vG5EXmFgFDc X-Google-Smtp-Source: ACJfBovUmT+3QrUB8QXhLePf8vCsOndF+//hqE3kDwNPBtYAfoq6OMXg9xr9EHKGb81tr3O7ztYDxQmnUmYyQAxLaq0= X-Received: by 10.80.161.167 with SMTP id 36mr9685505edk.38.1515268949244; Sat, 06 Jan 2018 12:02:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.211.20 with HTTP; Sat, 6 Jan 2018 12:02:08 -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> <4fee4ea6-9b35-afba-6d5d-24ecca3e28c6@freebsd.org> <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> From: John Lyon Date: Sat, 6 Jan 2018 15:02:08 -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: Sat, 06 Jan 2018 20:02:32 -0000 Thanks for the clarification and all the help. After Marko clarified that that edges/hooks are bidirectional, I was able to get it working WAN to LAN and LAN to WAN by using a pair of one2many and ETF nodes. The commands were (from memory): #Create Unfiltered WAN Path ngctl mkpeer igb0: one2many lower one ngctl name igb0:lower wanmux ngctl mkpeer wanmux: etf many0 downstream ngctl name wanmux:many0 wanfilter ngctl connect wanfilter: igb0: nomatch upper #Create Unfilter LAN Path ngctl mkpeer igb1: one2many lower one ngctl name igb1:lower lanmux ngctl mkpeer lanmux: etf many0 downstream ngctl name lanmux:many0 lanfilter ngctl connect lanfilter: igb1 nomatch upper #Cross Connect Two Paths ngctl connect wanfilter wanmux waneapout many1 ngctl connect lanfilter lanmux laneapout many1 #Filter Cross Connections ngctl msg wanfilter: 'setfilter { matchhook=3D"waneapout" ethertype=3D0x888= e }' ngctl msg lanfilter: 'setfilter { matchhook=3D"laneapout" ethertype=3D0x888= e }' The graph looks like this: igb0] <----> [mux0] <---> [etf0] <----> [igb0 \ / X / \ igb1] <----> [mux1] <---> [etf1] <----> [igb1 It was conceptually easier for me to wrap my head around and it appears to work (somewhat). But if I can get it to work, I like Julian's approach better as it is simpler and uses fewer nodes. Thanks again for all the help! -------------------------------- John L. Lyon PGP Key Available At: https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc On Sat, Jan 6, 2018 at 2:39 PM, Julian Elischer wrote: > On 6/1/18 9:22 pm, John Lyon wrote: > > I just woke up with a follow-up question that may be my aha moment. Are > Netgraph edges between nodes always bidirectional? I have been treating a= ll > of the edges as unidirectional, requiring me to create two separate > Netgraphs. But if they are bidirectional, that would explain some things= . > > > yes edges are bidirectional > > see the following paragraph from the ng_etf man page: > ----- > Packets traveling in the other direction (towards the downstream hoo= k) > are also examined and filtered. If a packet has an ethertype that > matches one of the values configured into the node, it must have > arrived > in on the hook for which that value was configured, otherwise it wil= l > be > discarded. Ethertypes of values other than those configured by the > con- > trol messages must have arrived via the nomatch hook. > ----- > > here is the picture of what you need, > You will see this below in the old emails: > > 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. > > ngctl mkpeer igb0: etf lower downstream > ngctl name igb0:lower waneapfilter > ngctl connect waneapfilter: igb0: nomatch upper > > ngctl mkpeer igb1: etf lower downstream > ngctl name igb1:lower laneapfilter > ngctl connect laneapfilter: igb1: nomatch upper > > ngctl connect waneapfilter laneapfilter eapout eapout > > ngctl msg waneapfilter: 'setfilter { matchhook=3D"eapout" > ethertype=3D0x888e }' > ngctl msg laneapfilter: 'setfilter { matchhook=3D"eapout" > ethertype=3D0x888e }' > > > Thanks. > > Sent from my iPhone > > On Jan 5, 2018, at 11:16 PM, John Lyon wrote: > > Julian, > > So this didn't work when I tried to implement it on hardware in real life > and I can't figure out why. I am sure it's really basic, but the error > message is not very descriptive. > > I use the following script to create a graph that filters the EAP traffic > and forwards directly from the first Ethernet interface to the second. I= t > works perfectly. > > kldload ng_etf > ngctl mkpeer igb0: etf lower downstream > ngctl name igb0:lower waneapfilter > ngctl connect waneapfilter: igb0: nomatch upper > ngctl connect wanfilter: igb1: waneapout lower > ngctl msg wanfilter: 'setfilter { matchhook=3D"waneapout" > ethertype=3D0x888e }' > > The end result is that EAPOL frames are forwarded directly from igb0 (WAN= ) > to igb1 (LAN). Graphically, it looks like (arrows indicating flow of > traffic): > > igb0]lower--->>downstream[ETF0]nomatch--->>upper[igb0... > waneapout > | > |------>>lower[igb1.... > > However, I also need to do the reverse and forward EAPOL frames in the op= posite direction from igb1 (LAN) to igb0 (WAN). Graphically, I want (arrow= s indicating flow): > > igb1]lower--->>downstream[ETF1]nomatch--->>upper[igb1... > laneapout > | > |------>>lower[igb0.... > > So I try a mirror image of my first script. However, when I type the fir= st line of: > > ngctl mkpeer igb1: etf lower downstream > > I get the following error message: > > ngctl: send msg: File exists. > > My guess (based on an earlier email in this thread) is that because I've = already connected my first NG_ETF node to the lower hook of igb1 (in order = to forward traffic out that interface), I am getting the error that the "Fi= le exists" when I try to connect a second ETF node to igb1 lower. If this = is the case, how can I write traffic out the interface, while filtering inc= oming traffic on the same interface? I tried to used two different ETF node= s, as suggested, but get an error message when I try. > > Thanks for any help. I feel like I am so close. At this point, I probab= ly should have just jumped ship and tried an alternate solution, but I just= can't allow the machine to win. :-) I have to get this working! > > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Fri, Dec 29, 2017 at 4:06 AM, Julian Elischer > wrote: > >> 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 ho= ok >> 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 ET= F >> and the ether nodes. Once this connect command was issued, the connecti= on >> 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 hoo= k 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=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 wron= g? >>>>> >>>>> 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 downstre= am >>>>> 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 th= e >>>>> '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 Sat Jan 6 20:06:24 2018 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 AE437DBB761 for ; Sat, 6 Jan 2018 20:06:24 +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 780C07D547 for ; Sat, 6 Jan 2018 20:06:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (124-148-223-243.dyn.iinet.net.au [124.148.223.243]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w06K6HFC054462 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 6 Jan 2018 12:06:20 -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> <3b8d46da-75e3-79f2-379c-b27a88e80733@freebsd.org> <47C0E33A-E815-4860-A25C-F29BBB8D6787@gmail.com> From: Julian Elischer Message-ID: <9fe76b26-2d1c-939a-8ece-947f5140bc0f@freebsd.org> Date: Sun, 7 Jan 2018 04:06:11 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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: Sat, 06 Jan 2018 20:06:24 -0000 On 7/1/18 4:02 am, John Lyon wrote: > Thanks for the clarification and all the help. > > After Marko clarified that that edges/hooks are bidirectional, I was > able to get it working WAN to LAN and LAN to WAN by using a pair of > one2many and ETF nodes. > > The commands were (from memory): > > #Create Unfiltered WAN Path > ngctl mkpeer igb0: one2many lower one > ngctl name igb0:lower wanmux > ngctl mkpeer wanmux: etf many0 downstream > ngctl name wanmux:many0 wanfilter > ngctl connect wanfilter: igb0: nomatch upper > > #Create Unfilter LAN Path > ngctl mkpeer igb1: one2many lower one > ngctl name igb1:lower lanmux > ngctl mkpeer lanmux: etf many0 downstream > ngctl name lanmux:many0 lanfilter > ngctl connect lanfilter: igb1 nomatch upper > > #Cross Connect Two Paths > ngctl connect wanfilter wanmux waneapout many1 > ngctl connect lanfilter lanmux laneapout many1 > > #Filter Cross Connections > ngctl msg wanfilter: 'setfilter { matchhook="waneapout" > ethertype=0x888e }' > ngctl msg lanfilter: 'setfilter { matchhook="laneapout" > ethertype=0x888e }' > > The graph looks like this: > > igb0] <----> [mux0] <---> [etf0] <----> [igb0 >                                \       / >                                   X >                                /      \ > igb1] <----> [mux1] <---> [etf1] <----> [igb1 > > > It was conceptually easier for me to wrap my head around and it > appears to work (somewhat).  But if I can get it to work, I like > Julian's approach better as it is simpler and uses fewer nodes. etf includes a mux/demux..  the link is bidirectional. > > Thanks again for all the help! > > -------------------------------- > John L. Lyon > PGP Key Available At: > https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc > > On Sat, Jan 6, 2018 at 2:39 PM, Julian Elischer > wrote: > > On 6/1/18 9:22 pm, John Lyon wrote: >> I just woke up with a follow-up question that may be my aha >> moment.  Are Netgraph edges between nodes always bidirectional? >> I have been treating all of the edges as unidirectional, >> requiring me to create two separate Netgraphs.  But if they are >> bidirectional, that would explain some things. > > yes edges are bidirectional > > see the following paragraph from the ng_etf man page: > ----- >      Packets traveling in the other direction (towards the > downstream hook) >      are also examined and filtered.  If a packet has an > ethertype that >      matches one of the values configured into the node, it must > have arrived >      in on the hook for which that value was configured, > otherwise it will be >      discarded.  Ethertypes of values other than those > configured by the con- >      trol messages must have arrived via the nomatch hook. > ----- > > here is the picture of what you need, > You will see this below in the old emails: > > 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. > >     ngctl mkpeer igb0: etf lower downstream >     ngctl name igb0:lower waneapfilter >     ngctl connect waneapfilter: igb0: nomatch upper > >     ngctl mkpeer igb1: etf lower downstream >     ngctl name igb1:lower laneapfilter >     ngctl connect laneapfilter: igb1: nomatch upper > >     ngctl connect waneapfilter laneapfilter eapout eapout > >     ngctl msg waneapfilter: 'setfilter { matchhook="eapout" > ethertype=0x888e }' >     ngctl msg laneapfilter: 'setfilter { matchhook="eapout" > ethertype=0x888e }' > >> >> Thanks. >> >> Sent from my iPhone >> >> On Jan 5, 2018, at 11:16 PM, John Lyon > > wrote: >> >>> Julian, >>> >>> So this didn't work when I tried to implement it on hardware >>> in real life and I can't figure out why.  I am sure it's >>> really basic, but the error message is not very descriptive. >>> >>> I use the following script to create a graph that filters the >>> EAP traffic and forwards directly from the first Ethernet >>> interface to the second.  It works perfectly. >>> >>>     kldload ng_etf >>>     ngctl mkpeer igb0: etf lower downstream >>>     ngctl name igb0:lower waneapfilter >>>     ngctl connect waneapfilter: igb0: nomatch upper >>>     ngctl connect wanfilter: igb1: waneapout lower >>>     ngctl msg wanfilter: 'setfilter { matchhook="waneapout" >>> ethertype=0x888e }' >>> >>> The end result is that EAPOL frames are forwarded directly >>> from igb0 (WAN) to igb1 (LAN).  Graphically, it looks like >>> (arrows indicating flow of traffic): >>> igb0]lower--->>downstream[ETF0]nomatch--->>upper[igb0... >>> waneapout >>> | >>> |------>>lower[igb1.... >>> However, I also need to do the reverse and forward EAPOL frames in the opposite direction from igb1 (LAN) to igb0 (WAN). Graphically, I want (arrows indicating flow): >>> igb1]lower--->>downstream[ETF1]nomatch--->>upper[igb1... >>> laneapout | |------>>lower[igb0.... >>> So I try a mirror image of my first script. However, when I type the first line of: >>> ngctl mkpeer igb1: etf lower downstream >>> I get the following error message: >>> ngctl: send msg: File exists. >>> My guess (based on an earlier email in this thread) is that because I've already connected my first NG_ETF node to the lower hook of igb1 (in order to forward traffic out that interface), I am getting the error that the "File exists" when I try to connect a second ETF node to igb1 lower. If this is the case, how can I write traffic out the interface, while filtering incoming traffic on the same interface? I tried to used two different ETF nodes, as suggested, but get an error message when I try. >>> Thanks for any help. I feel like I am so close. At this point, I probably should have just jumped ship and tried an alternate solution, but I just can't allow the machine to win. :-) I have to get this working! >>> >>> -------------------------------- >>> John L. Lyon >>> PGP Key Available At: >>> https://www.dropbox.com/s/skmedtscs0tgex7/02150BFE.asc >>> >>> >>> On Fri, Dec 29, 2017 at 4:06 AM, Julian Elischer >>> > wrote: >>> >>> 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 >>>> " >>>> >>>> >>>> >>>> >>> >>> > >