From owner-freebsd-net@freebsd.org Sun Jun 5 08:44:59 2016 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 EC5D3B6AB82 for ; Sun, 5 Jun 2016 08:44:59 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 858CA18B8 for ; Sun, 5 Jun 2016 08:44:59 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id c74so4824872wme.0 for ; Sun, 05 Jun 2016 01:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t6YMAbsvffSaITYiMUjW6rVZPTKT87FrhDOnTsgivPc=; b=NwsKwInF6P/JvEd8fFlom1iUCoCPBdLEtMMKoo1Zv9+Js73d6wlpdYlrJeXUQDjW24 kJ3JZQOk5gKX1/6Dylw1b1jIh3YEOxMUQVpnyAgMaGE8qNE0Vk2v45UYs9EHh7Gduild VZEWtpC/Nz56L2o4eEk4Pzv6D4f9u//ZATPcqCwp2qIDC0xHQ0aVtVrC0UqqgkWQQey/ lZ4m6+6QfDOPiVEofQOjzXWZlEPNozhvWJfTaeAnQSiMYShGSA4csUferGG3b0ymfSad z0o1YHtQ+cFS3q2SmjVuP2fsAgAtiuefqQV5tZA6AYM0puu02w6Xqs6POJna+oqGvWez qjSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t6YMAbsvffSaITYiMUjW6rVZPTKT87FrhDOnTsgivPc=; b=lrdv2ZrGq9IPDbIZJocmmFbq8Hxa1DgjlBDUD0ecvHrjbJJ8+2Xx2HdM9KlQzigqqF mBnVsz6huDv5W8auiSyeRU9tAVYQdBcWXYoTiXf4BXR1TOWetc33mZpmKGDMhK5iEDJt S7UgZxRG3iGzaAwfePQON5a8sV3qP+p0zGw91DDMf5C67uG5J93slzlVmJpbf+sDsEjk 7+GLLtd7lYcug/0j4p3HGFCuF3AYm4/pszim7/se4a5YI/sjhX1jnHMlQWu6qcpWZBJC bD0JVdI4EtKs1EBF10gONSeO2WPQRxwO1DliXoGyJbjUvcSuHBTKkvRvaah3OpzYTjeo i1kw== X-Gm-Message-State: ALyK8tLGn57Pq01RG77Q6pS+RVn3pGxjXg7Ue90r2U+CzfaGKAKesIzerQr1zE64LXRbjjMVrxZR2cS3FV67OA== X-Received: by 10.194.58.8 with SMTP id m8mr10889925wjq.98.1465116297702; Sun, 05 Jun 2016 01:44:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.151.38 with HTTP; Sun, 5 Jun 2016 01:44:57 -0700 (PDT) In-Reply-To: <20160603131146.GA26528@babolo.ru> References: <574D89F6.3030806@kornberger.name> <57502430.1030309@kornberger.name> <20160603131146.GA26528@babolo.ru> From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Sun, 5 Jun 2016 11:44:57 +0300 Message-ID: Subject: Re: IPFW: table support for MAC addresses? To: Aleksandr A Babaylov <"."@babolo.ru> Cc: "Julian K." , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 05 Jun 2016 08:45:00 -0000 I also need this feature On Fri, Jun 3, 2016 at 4:11 PM, Aleksandr A Babaylov <"."@babolo.ru> wrote: > On Thu, Jun 02, 2016 at 02:18:56PM +0200, Julian K. wrote: > > is there anyone who wants to use MAC based rules with IPFW? > > I want to build a captive portal that also supports IPv6. MAC addresses > > in IPFW tables would help a lot. > I use MAC in IPFW and want MAC in IPFW tables to simplify rules. > > _______________________________________________ > 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 Sun Jun 5 10:41:26 2016 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 68788B696E7 for ; Sun, 5 Jun 2016 10:41:26 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward5h.cmail.yandex.net (forward5h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 251BA1D67 for ; Sun, 5 Jun 2016 10:41:25 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback13h.mail.yandex.net (mxback13h.mail.yandex.net [84.201.186.131]) by forward5h.cmail.yandex.net (Yandex) with ESMTP id BB0CF20CAF; Sun, 5 Jun 2016 13:41:12 +0300 (MSK) Received: from web4h.yandex.ru (web4h.yandex.ru [84.201.186.33]) by mxback13h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 1WdZF1MpLz-fCii3PlW; Sun, 05 Jun 2016 13:41:12 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1465123272; bh=z6Jb+oNRwR/Ku00LZoMK5JNugRGl5BpGWgwL0RKL6rQ=; h=X-Yandex-Sender-Uid:From:Envelope-From:To:Cc:In-Reply-To: References:Subject:MIME-Version:Message-Id:X-Mailer:Date: Content-Transfer-Encoding:Content-Type; b=BaNt9bYOw/YNshqGBtcHNIGFFrGm3wHeBiz/nnF33lysvRo1RE0bk6NIG6d4rIuHV 8tGozUPFMS4Vu9zDuaxcHlOG0Ir02a72n+o55QWl8IoUKVnHiiprtENDAejINGdfti BXC2CvBaL+VNC2eYsZJheS5dz8qwi2sy/L1ToZNg= Authentication-Results: mxback13h.mail.yandex.net; dkim=pass header.i=@ipfw.ru X-Yandex-Suid-Status: 1 0,1 0,1 0,1 0,1 1130000031510964 X-Yandex-Sender-Uid: 1130000014307927 Received: by web4h.yandex.ru with HTTP; Sun, 05 Jun 2016 13:41:12 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: =?utf-8?B?w5Z6a2FuIEtJUklL?= , Aleksandr A Babaylov <"."@babolo.ru> Cc: "freebsd-net@freebsd.org" , Julian K. In-Reply-To: References: <574D89F6.3030806@kornberger.name> <57502430.1030309@kornberger.name> <20160603131146.GA26528@babolo.ru> Subject: Re: IPFW: table support for MAC addresses? MIME-Version: 1.0 Message-Id: <4150711465123272@web4h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 05 Jun 2016 13:41:12 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 05 Jun 2016 10:41:26 -0000 05.06.2016, 11:45, "Özkan KIRIK" : > I also need this feature Are you fine with exact-match mac addresses? (E.g. new array/hash tabletype with the ability to do exact lookup on the source/destination mac address, w/o any masks support). > > On Fri, Jun 3, 2016 at 4:11 PM, Aleksandr A Babaylov <"."@babolo.ru> wrote: > >>  On Thu, Jun 02, 2016 at 02:18:56PM +0200, Julian K. wrote: >>  > is there anyone who wants to use MAC based rules with IPFW? >>  > I want to build a captive portal that also supports IPv6. MAC addresses >>  > in IPFW tables would help a lot. >>  I use MAC in IPFW and want MAC in IPFW tables to simplify rules. >> >>  _______________________________________________ >>  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 Sun Jun 5 12:33:49 2016 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 295D2B69CCC for ; Sun, 5 Jun 2016 12:33:49 +0000 (UTC) (envelope-from jk@kornberger.name) Received: from digineo.de (mail.digineo.de [185.55.116.143]) (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 DFBD61A37; Sun, 5 Jun 2016 12:33:47 +0000 (UTC) (envelope-from jk@kornberger.name) Received: from [192.168.180.22] (p4FF9042B.dip0.t-ipconnect.de [79.249.4.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jk) by digineo.de (Postfix) with ESMTPSA id 49CD0603FE; Sun, 5 Jun 2016 14:33:39 +0200 (CEST) Subject: Re: IPFW: table support for MAC addresses? To: freebsd-net@freebsd.org References: <574D89F6.3030806@kornberger.name> <57502430.1030309@kornberger.name> <20160603131146.GA26528@babolo.ru> <4150711465123272@web4h.yandex.ru> Cc: melifaro@freebsd.org From: Julian Kornberger Message-ID: <57541C1F.8060806@kornberger.name> Date: Sun, 5 Jun 2016 14:33:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <4150711465123272@web4h.yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 05 Jun 2016 12:33:49 -0000 On 05.06.2016 12:41, Alexander V. Chernikov wrote: > Are you fine with exact-match mac addresses? (E.g. new array/hash > tabletype with the ability to do exact lookup on the > source/destination mac address, w/o any masks support). Yes, exact-match would totally satisfy my requirements. Regards, Julian From owner-freebsd-net@freebsd.org Sun Jun 5 15:33:16 2016 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 CFD37B6A42D for ; Sun, 5 Jun 2016 15:33:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C022A18D5 for ; Sun, 5 Jun 2016 15:33:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u55FXG9F048025 for ; Sun, 5 Jun 2016 15:33:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 181703] [re] [patch] Fix Realtek 8111G Ethernet controller not being detected Date: Sun, 05 Jun 2016 15:33: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: 9.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: neel@neelc.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 05 Jun 2016 15:33:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D181703 Neel Chauhan changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|In Progress |Closed --- Comment #3 from Neel Chauhan --- Many years later, FreeBSD has gotten 8111G support. I'm closing this bug as it's irrelevant now. It was a failed attempt at kernel hacking (along with another attempt to put Haswell support, which also failed). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Sun Jun 5 18:04:23 2016 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 DDB79B6ABF4 for ; Sun, 5 Jun 2016 18:04:23 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 99BE813D9 for ; Sun, 5 Jun 2016 18:04:23 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vk0-x236.google.com with SMTP id c66so20274135vkb.3 for ; Sun, 05 Jun 2016 11:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=R3lMQwtN/ZvdmK6RTmjplB3dC1WlXyXyI8CDR0GVHHY=; b=KLlXCUoJydkMB0PK38OlzBIKrQGBH52h8AkewpOP9DA58E3SJTny5XxBKrpX2jpAi9 O/WqDFBbWaXp1/EWgueU+yg5OdR4fx+1vCQJ1Mzv5cMtQo2D9ZSpTEje/dzYHUqP06e4 Tp06JQfK59/DSReAQmgNltL9xLKVgd78rk7hBhFMV2GbmHqjZtfIvHAOy0if4eDhWgrq 28V6a4kU7kp0EWbJJuhAgkE+EFl1+S2vCLZWvpgRFnyGjw/SGnbHpUJ/dajoHtDi1ynH OdW6l5mv5yiioLPDM3GXRBlqcflo0iezAQxZkMMSEmSmjKJ9Yv2Zsrq2/LacioeZB/aA SzjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=R3lMQwtN/ZvdmK6RTmjplB3dC1WlXyXyI8CDR0GVHHY=; b=UwcIWYYSk8aO/qp5MFYiVn4X0boYn+YdnLmeNMc2pPKDnoKxLGtLygBkazuVWtUcT1 XA8C5u5gB1se9HyWal6W8ng/yce1VF4VwSsQMxeFjZcnvLFvSyPp1Vm2pAZiqy5aRh0b fVB3C98GFxdseEWxQvGZpg901DqAIcKo9yPxG6hfwuR1ksHiamM4OMWNe1ccfRgYkz6e 4FEqEW1r4WowFCrPlYHzW3q4eEZnd9PtwiMm79gLxmihFLcABgQ1c+NAnmtmn7A3jSn+ mpHv+vOyh8h7LfQ75WgIkYh3nR9iHFm84wQtMsur73F6giJsHVm56HQcxRvUO0mvVq4w EK5A== X-Gm-Message-State: ALyK8tIyo9K1RBnLG0ec+a+9qADco04SaFoIdRVbzFhre8XJAwyhdCcj0QPs6KOYIp5Mb5PHoTJ51thHtVRoEw== X-Received: by 10.31.85.3 with SMTP id j3mr6271566vkb.156.1465149862605; Sun, 05 Jun 2016 11:04:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.35 with HTTP; Sun, 5 Jun 2016 11:04:22 -0700 (PDT) In-Reply-To: References: <994d23ab-5113-a00a-04eb-f6ecc14b0607@infosecurity.ch> <20160605171724.19fdc344@natsu> <20160605202250.22ad0367@natsu> From: grarpamp Date: Sun, 5 Jun 2016 14:04:22 -0400 Message-ID: Subject: Fwd: Sharing experience with Via Nano 1.6ghz with Padlock hw accel To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 05 Jun 2016 18:04:24 -0000 ---------- Forwarded message ---------- From: fatal Date: Sun, 5 Jun 2016 18:20:56 +0200 Subject: Re: [tor-relays] Sharing experience with Via Nano 1.6ghz with Padlock hw accel To: tor-relays@lists.torproject.org Hello, openssl with enabled padlock and tor stable crashes on my via nano servers running linux and freebsd. without padlock max is ~81 Mbit with linux and ~76 with freebsd (100% load, measured in the last week). From owner-freebsd-net@freebsd.org Sun Jun 5 21:00:45 2016 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 3AFB4B6AAB3 for ; Sun, 5 Jun 2016 21:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CC831488 for ; Sun, 5 Jun 2016 21:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u55L01FN043750 for ; Sun, 5 Jun 2016 21:00:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201606052100.u55L01FN043750@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention Date: Sun, 05 Jun 2016 21:00:45 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 05 Jun 2016 21:00:45 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 In Progress | 206581 | bxe_ioctl_nvram handler is faulty New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic Open | 148807 | [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" a Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 201694 | 10.2-BETA2 crashing when killing VIMAGE/VNET jail Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; 12 problems total for which you should take action. From owner-freebsd-net@freebsd.org Sun Jun 5 23:14:23 2016 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 E2DE1B6B103 for ; Sun, 5 Jun 2016 23:14:23 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from smtp.babolo.ru (smtp.babolo.ru [194.58.246.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.babolo.ru", Issuer "babolo" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 736B91CDC; Sun, 5 Jun 2016 23:14:22 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from cicuta.babolo.ru (cicuta.babolo [127.0.2.61]) by smtp.babolo.ru (8.15.2/8.15.2) with SMTP id u55N3RIL062505; Mon, 6 Jun 2016 02:03:27 +0300 (MSK) (envelope-from "."@babolo.ru) Received: (nullmailer pid 35422 invoked by uid 136); Sun, 05 Jun 2016 23:14:07 -0000 Date: Mon, 6 Jun 2016 02:14:07 +0300 From: Aleksandr A Babaylov <"."@babolo.ru> To: "Alexander V. Chernikov" Cc: ??zkan KIRIK , "freebsd-net@freebsd.org" , "Julian K." Subject: Re: IPFW: table support for MAC addresses? Message-ID: <20160605231407.GB35289@babolo.ru> References: <574D89F6.3030806@kornberger.name> <57502430.1030309@kornberger.name> <20160603131146.GA26528@babolo.ru> <4150711465123272@web4h.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4150711465123272@web4h.yandex.ru> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 05 Jun 2016 23:14:24 -0000 On Sun, Jun 05, 2016 at 01:41:12PM +0300, Alexander V. Chernikov wrote: > 05.06.2016, 11:45, "??zkan KIRIK" : > > I also need this feature > > Are you fine with exact-match mac addresses? Yes, exact-match is fine for me. > (E.g. new array/hash tabletype with the ability to do exact lookup on the source/destination mac address, w/o any masks support). > > On Fri, Jun 3, 2016 at 4:11 PM, Aleksandr A Babaylov <"."@babolo.ru> wrote: > >> šOn Thu, Jun 02, 2016 at 02:18:56PM +0200, Julian K. wrote: > >> š> is there anyone who wants to use MAC based rules with IPFW? > >> š> I want to build a captive portal that also supports IPv6. MAC addresses > >> š> in IPFW tables would help a lot. > >> šI use MAC in IPFW and want MAC in IPFW tables to simplify rules. From owner-freebsd-net@freebsd.org Mon Jun 6 02:24:40 2016 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 67931B6A0CE for ; Mon, 6 Jun 2016 02:24:40 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 211481525; Mon, 6 Jun 2016 02:24:40 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by mail-vk0-x22a.google.com with SMTP id c66so28322287vkb.3; Sun, 05 Jun 2016 19:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J0WcpY3GjA4j3zzSBkPi2ucyQtiE/QYKhjU3AWenWrk=; b=QcgN6d639hvu0qzQHusVsJmv4/1fkX8gZJeVerdX6TOAAWauiagHsT5FPLZffUEQAS rZ9pFg0JgxxbDGBbdp5Qcq/G7E776u7shmN6vEQHG76B5/fAogmzdcyqsNblYPwT+s6f lk35dKNsaRydcKUHZue3w7LAD1mJlwhiPcFs/sl08K+uzBlY7+IypInjrmjPWHMq6IRX eorQG2vatx8I0tH2OavPIyFC2nEos/18xBND++ZLugOZJzJFleIwHrhWnNoLg07zamH1 spU8UHf5mcIdJJ/UOE778UYHnOnAcOrwUWYO2n96YBxxqoSfmtjhD5ZdF+nKI6N2LjRW 8VEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J0WcpY3GjA4j3zzSBkPi2ucyQtiE/QYKhjU3AWenWrk=; b=Ds9k04uB2eixxCDmkFK95RZ4bzUnSM/3OWlOZ3anJ7rrWgP4FeU5Wt9yBFcwG+njpJ eeb8YrslNsYCVhM6pCYR3HKn8ygIvpCP/gfgm20GEz7U3h8518IjoCv0vtqBz7zzo30l Oc1QytzEgI87o3M02MTojbEYxoqDx0PfUCvPRrWC2LBtDFSy6zhgMnidcIX+dJqSPqTO PPolD4oBuf35BsHjJMitldjMZvYK4SgJ1NICydW17JJJLRKXl6G9OBctlvIKBO10cMbo DkDjy8cXf6syUSxze1oQHrsy7RRxkxWCOmee1TIEFTJ9+JVzq4uA6/EjcSqDvFvfTAJC Ds6A== X-Gm-Message-State: ALyK8tLtUutoTxqIh6I1qt4NuW/qNY3hIiCNsFuFGs3wkcEfbP4Jd3Ps8NGvpZQjbnAM2KLblGBED8oDK+ESLg== X-Received: by 10.176.7.73 with SMTP id h67mr7007522uah.91.1465179878991; Sun, 05 Jun 2016 19:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.83.23 with HTTP; Sun, 5 Jun 2016 19:24:38 -0700 (PDT) In-Reply-To: <20160605231407.GB35289@babolo.ru> References: <574D89F6.3030806@kornberger.name> <57502430.1030309@kornberger.name> <20160603131146.GA26528@babolo.ru> <4150711465123272@web4h.yandex.ru> <20160605231407.GB35289@babolo.ru> From: "Sam Fourman Jr." Date: Sun, 5 Jun 2016 19:24:38 -0700 Message-ID: Subject: Re: IPFW: table support for MAC addresses? To: Aleksandr A Babaylov <"."@babolo.ru> Cc: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , "Julian K." Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 06 Jun 2016 02:24:40 -0000 For what it is worth, I also would use this Feature. to whitelist a set of MACS On Sun, Jun 5, 2016 at 4:14 PM, Aleksandr A Babaylov <"."@babolo.ru> wrote: > On Sun, Jun 05, 2016 at 01:41:12PM +0300, Alexander V. Chernikov wrote: > > 05.06.2016, 11:45, "??zkan KIRIK" : > > > I also need this feature > > > > Are you fine with exact-match mac addresses? > Yes, exact-match is fine for me. > > > (E.g. new array/hash tabletype with the ability to do exact lookup on > the source/destination mac address, w/o any masks support). > > > On Fri, Jun 3, 2016 at 4:11 PM, Aleksandr A Babaylov <"."@babolo.ru> > wrote: > > >> On Thu, Jun 02, 2016 at 02:18:56PM +0200, Julian K. wrote: > > >> > is there anyone who wants to use MAC based rules with IPFW? > > >> > I want to build a captive portal that also supports IPv6. MAC > addresses > > >> > in IPFW tables would help a lot. > > >> I use MAC in IPFW and want MAC in IPFW tables to simplify rules. > > _______________________________________________ > 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" > -- Sam Fourman Jr. From owner-freebsd-net@freebsd.org Mon Jun 6 08:40:02 2016 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 A0BA7B6D5DD for ; Mon, 6 Jun 2016 08:40:02 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 790941F00 for ; Mon, 6 Jun 2016 08:40:02 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id CAD9817966; Mon, 6 Jun 2016 08:40:01 +0000 (UTC) Date: Mon, 6 Jun 2016 08:40:01 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D6689+325+6c89ed8b7a9bc66d@reviews.freebsd.org Subject: [Differential] D6689: tcp/lro: Implement hash table for LRO entries. Message-ID: <7f308e3259123615ab8095ec95c1e0ce@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , Thread-Topic: D6689: tcp/lro: Implement hash table for LRO entries. X-Herald-Rules: <64> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGRkYTdkZDNmZDVlODIxOWE3MGU3NDg3NmVjIFdVNuE= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_7f308e3259123615ab8095ec95c1e0ce" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 08:40:02 -0000 --b1_7f308e3259123615ab8095ec95c1e0ce Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit sepherosa_gmail.com updated this revision to Diff 17347. sepherosa_gmail.com added a comment. Address hps's cache pollution concern for queue_mbuf path. Similar approach was in the patch obtained from rrs. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D6689?vs=17214&id=17347 REVISION DETAIL https://reviews.freebsd.org/D6689 AFFECTED FILES sys/netinet/tcp_lro.c sys/netinet/tcp_lro.h EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, rrs, gallatin, glebius, gnn, bz, rwatson, #transport, hselasky Cc: freebsd-net-list --b1_7f308e3259123615ab8095ec95c1e0ce Content-Type: text/x-patch; charset=utf-8; name="D6689.17347.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D6689.17347.patch" ZGlmZiAtLWdpdCBhL3N5cy9uZXRpbmV0L3RjcF9scm8uaCBiL3N5cy9uZXRpbmV0L3RjcF9scm8u aAotLS0gYS9zeXMvbmV0aW5ldC90Y3BfbHJvLmgKKysrIGIvc3lzL25ldGluZXQvdGNwX2xyby5o CkBAIC00MCw2ICs0MCw3IEBACiAKIHN0cnVjdCBscm9fZW50cnkgewogCUxJU1RfRU5UUlkobHJv X2VudHJ5KQluZXh0OworCUxJU1RfRU5UUlkobHJvX2VudHJ5KQloYXNoX25leHQ7CiAJc3RydWN0 IG1idWYJCSptX2hlYWQ7CiAJc3RydWN0IG1idWYJCSptX3RhaWw7CiAJdW5pb24gewpAQCAtOTUs NiArOTYsOCBAQAogCXVuc2lnbmVkIHNob3J0CWxyb19hY2tjbnRfbGltOwkJLyogbWF4ICMgb2Yg YWdncmVnYXRlZCBBQ0tzICovCiAJdW5zaWduZWQgCWxyb19sZW5ndGhfbGltOwkJLyogbWF4IGxl biBvZiBhZ2dyZWdhdGVkIGRhdGEgKi8KIAorCXVfbG9uZwkJbHJvX2hhc2hzejsKKwlzdHJ1Y3Qg bHJvX2hlYWQJKmxyb19oYXNoOwogCXN0cnVjdCBscm9faGVhZAlscm9fYWN0aXZlOwogCXN0cnVj dCBscm9faGVhZAlscm9fZnJlZTsKIH07CmRpZmYgLS1naXQgYS9zeXMvbmV0aW5ldC90Y3BfbHJv LmMgYi9zeXMvbmV0aW5ldC90Y3BfbHJvLmMKLS0tIGEvc3lzL25ldGluZXQvdGNwX2xyby5jCisr KyBiL3N5cy9uZXRpbmV0L3RjcF9scm8uYwpAQCAtNjgsMTkgKzY4LDI0IEBACiAjZW5kaWYKIAog c3RhdGljIHZvaWQJdGNwX2xyb19yeF9kb25lKHN0cnVjdCBscm9fY3RybCAqbGMpOworc3RhdGlj IGludAl0Y3BfbHJvX3J4MihzdHJ1Y3QgbHJvX2N0cmwgKmxjLCBzdHJ1Y3QgbWJ1ZiAqbSwKKwkJ ICAgIHVpbnQzMl90IGNzdW0sIGludCB1c2VfaGFzaCk7CiAKIHN0YXRpYyBfX2lubGluZSB2b2lk Ci10Y3BfbHJvX2FjdGl2ZV9pbnNlcnQoc3RydWN0IGxyb19jdHJsICpsYywgc3RydWN0IGxyb19l bnRyeSAqbGUpCit0Y3BfbHJvX2FjdGl2ZV9pbnNlcnQoc3RydWN0IGxyb19jdHJsICpsYywgc3Ry dWN0IGxyb19oZWFkICpidWNrZXQsCisgICAgc3RydWN0IGxyb19lbnRyeSAqbGUpCiB7CiAKIAlM SVNUX0lOU0VSVF9IRUFEKCZsYy0+bHJvX2FjdGl2ZSwgbGUsIG5leHQpOworCUxJU1RfSU5TRVJU X0hFQUQoYnVja2V0LCBsZSwgaGFzaF9uZXh0KTsKIH0KIAogc3RhdGljIF9faW5saW5lIHZvaWQK IHRjcF9scm9fYWN0aXZlX3JlbW92ZShzdHJ1Y3QgbHJvX2VudHJ5ICpsZSkKIHsKIAotCUxJU1Rf UkVNT1ZFKGxlLCBuZXh0KTsKKwlMSVNUX1JFTU9WRShsZSwgbmV4dCk7CQkvKiBhY3RpdmUgbGlz dCAqLworCUxJU1RfUkVNT1ZFKGxlLCBoYXNoX25leHQpOwkvKiBoYXNoIGJ1Y2tldCAqLwogfQog CiBpbnQKQEAgLTk1LDcgKzEwMCw3IEBACiB7CiAJc3RydWN0IGxyb19lbnRyeSAqbGU7CiAJc2l6 ZV90IHNpemU7Ci0JdW5zaWduZWQgaTsKKwl1bnNpZ25lZCBpLCBlbGVtZW50czsKIAogCWxjLT5s cm9fYmFkX2NzdW0gPSAwOwogCWxjLT5scm9fcXVldWVkID0gMDsKQEAgLTExMCw2ICsxMTUsMTgg QEAKIAlMSVNUX0lOSVQoJmxjLT5scm9fZnJlZSk7CiAJTElTVF9JTklUKCZsYy0+bHJvX2FjdGl2 ZSk7CiAKKwkvKiBjcmVhdGUgaGFzaCB0YWJsZSB0byBhY2NlbGVyYXRlIGVudHJ5IGxvb2t1cCAq LworCWlmIChscm9fZW50cmllcyA+IGxyb19tYnVmcykKKwkJZWxlbWVudHMgPSBscm9fZW50cmll czsKKwllbHNlCisJCWVsZW1lbnRzID0gbHJvX21idWZzOworCWxjLT5scm9faGFzaCA9IHBoYXNo aW5pdF9mbGFncyhlbGVtZW50cywgTV9MUk8sICZsYy0+bHJvX2hhc2hzeiwKKwkgICAgSEFTSF9O T1dBSVQpOworCWlmIChsYy0+bHJvX2hhc2ggPT0gTlVMTCkgeworCQltZW1zZXQobGMsIDAsIHNp emVvZigqbGMpKTsKKwkJcmV0dXJuIChFTk9NRU0pOworCX0KKwogCS8qIGNvbXB1dGUgc2l6ZSB0 byBhbGxvY2F0ZSAqLwogCXNpemUgPSAobHJvX21idWZzICogc2l6ZW9mKHN0cnVjdCBscm9fbWJ1 Zl9zb3J0KSkgKwogCSAgICAobHJvX2VudHJpZXMgKiBzaXplb2YoKmxlKSk7CkBAIC0xNDcsNiAr MTY0LDEzIEBACiAJCW1fZnJlZW0obGUtPm1faGVhZCk7CiAJfQogCisJLyogZnJlZSBoYXNoIHRh YmxlICovCisJaWYgKGxjLT5scm9faGFzaCAhPSBOVUxMKSB7CisJCWZyZWUobGMtPmxyb19oYXNo LCBNX0xSTyk7CisJCWxjLT5scm9faGFzaCA9IE5VTEw7CisJfQorCWxjLT5scm9faGFzaHN6ID0g MDsKKwogCS8qIGZyZWUgbWJ1ZiBhcnJheSwgaWYgYW55ICovCiAJZm9yICh4ID0gMDsgeCAhPSBs Yy0+bHJvX21idWZfY291bnQ7IHgrKykKIAkJbV9mcmVlbShsYy0+bHJvX21idWZfZGF0YVt4XS5t Yik7CkBAIC00ODcsNyArNTExLDcgQEAKIAkJfQogCiAJCS8qIGFkZCBwYWNrZXQgdG8gTFJPIGVu Z2luZSAqLwotCQlpZiAodGNwX2xyb19yeChsYywgbWIsIDApICE9IDApIHsKKwkJaWYgKHRjcF9s cm9fcngyKGxjLCBtYiwgMCwgMCkgIT0gMCkgewogCQkJLyogaW5wdXQgcGFja2V0IHRvIG5ldHdv cmsgbGF5ZXIgKi8KIAkJCSgqbGMtPmlmcC0+aWZfaW5wdXQpKGxjLT5pZnAsIG1iKTsKIAkJCWxj LT5scm9fcXVldWVkKys7CkBAIC01NjEsOCArNTg1LDggQEAKIH0KICNlbmRpZgogCi1pbnQKLXRj cF9scm9fcngoc3RydWN0IGxyb19jdHJsICpsYywgc3RydWN0IG1idWYgKm0sIHVpbnQzMl90IGNz dW0pCitzdGF0aWMgaW50Cit0Y3BfbHJvX3J4MihzdHJ1Y3QgbHJvX2N0cmwgKmxjLCBzdHJ1Y3Qg bWJ1ZiAqbSwgdWludDMyX3QgY3N1bSwgaW50IHVzZV9oYXNoKQogewogCXN0cnVjdCBscm9fZW50 cnkgKmxlOwogCXN0cnVjdCBldGhlcl9oZWFkZXIgKmVoOwpAQCAtNTc4LDYgKzYwMiw4IEBACiAJ dGNwX3NlcSBzZXE7CiAJaW50IGVycm9yLCBpcF9sZW4sIGw7CiAJdWludDE2X3QgZWhfdHlwZSwg dGNwX2RhdGFfbGVuOworCXN0cnVjdCBscm9faGVhZCAqYnVja2V0OworCXVpbnQzMl90IGhhc2g7 CiAKIAkvKiBXZSBleHBlY3QgYSBjb250aWd1b3VzIGhlYWRlciBbZWgsIGlwLCB0Y3BdLiAqLwog CkBAIC02NzAsOCArNjk2LDQxIEBACiAKIAlzZXEgPSBudG9obCh0aC0+dGhfc2VxKTsKIAorCWlm ICghdXNlX2hhc2gpIHsKKwkJYnVja2V0ID0gJmxjLT5scm9faGFzaFswXTsKKwkJZ290byBmaW5k OworCX0KKwlpZiAoTV9IQVNIVFlQRV9JU0hBU0gobSkpIHsKKwkJaGFzaCA9IG0tPm1fcGt0aGRy LmZsb3dpZDsKKwl9IGVsc2UgeworCQlzd2l0Y2ggKGVoX3R5cGUpIHsKKyNpZmRlZiBJTkVUCisJ CWNhc2UgRVRIRVJUWVBFX0lQOgorCQkJaGFzaCA9IGlwNC0+aXBfc3JjLnNfYWRkciArIGlwNC0+ aXBfZHN0LnNfYWRkcjsKKwkJCWJyZWFrOworI2VuZGlmCisjaWZkZWYgSU5FVDYKKwkJY2FzZSBF VEhFUlRZUEVfSVBWNjoKKwkJCWhhc2ggPSBpcDYtPmlwNl9zcmMuczZfYWRkcjMyWzBdICsKKwkJ CSAgICBpcDYtPmlwNl9kc3QuczZfYWRkcjMyWzBdOworCQkJaGFzaCArPSBpcDYtPmlwNl9zcmMu czZfYWRkcjMyWzFdICsKKwkJCSAgICBpcDYtPmlwNl9kc3QuczZfYWRkcjMyWzFdOworCQkJaGFz aCArPSBpcDYtPmlwNl9zcmMuczZfYWRkcjMyWzJdICsKKwkJCSAgICBpcDYtPmlwNl9kc3QuczZf YWRkcjMyWzJdOworCQkJaGFzaCArPSBpcDYtPmlwNl9zcmMuczZfYWRkcjMyWzNdICsKKwkJCSAg ICBpcDYtPmlwNl9kc3QuczZfYWRkcjMyWzNdOworCQkJYnJlYWs7CisjZW5kaWYKKwkJZGVmYXVs dDoKKwkJCWhhc2ggPSAwOworCQkJYnJlYWs7CisJCX0KKwkJaGFzaCArPSB0aC0+dGhfc3BvcnQg KyB0aC0+dGhfZHBvcnQ7CisJfQorCWJ1Y2tldCA9ICZsYy0+bHJvX2hhc2hbaGFzaCAlIGxjLT5s cm9faGFzaHN6XTsKK2ZpbmQ6CiAJLyogVHJ5IHRvIGZpbmQgYSBtYXRjaGluZyBwcmV2aW91cyBz ZWdtZW50LiAqLwotCUxJU1RfRk9SRUFDSChsZSwgJmxjLT5scm9fYWN0aXZlLCBuZXh0KSB7CisJ TElTVF9GT1JFQUNIKGxlLCBidWNrZXQsIGhhc2hfbmV4dCkgewogCQlpZiAobGUtPmVoX3R5cGUg IT0gZWhfdHlwZSkKIAkJCWNvbnRpbnVlOwogCQlpZiAobGUtPnNvdXJjZV9wb3J0ICE9IHRoLT50 aF9zcG9ydCB8fApAQCAtNzc5LDcgKzgzOCw3IEBACiAJLyogU3RhcnQgYSBuZXcgc2VnbWVudCBj aGFpbi4gKi8KIAlsZSA9IExJU1RfRklSU1QoJmxjLT5scm9fZnJlZSk7CiAJTElTVF9SRU1PVkUo bGUsIG5leHQpOwotCXRjcF9scm9fYWN0aXZlX2luc2VydChsYywgbGUpOworCXRjcF9scm9fYWN0 aXZlX2luc2VydChsYywgYnVja2V0LCBsZSk7CiAJZ2V0bWljcm90aW1lKCZsZS0+bXRpbWUpOwog CiAJLyogU3RhcnQgZmlsbGluZyBpbiBkZXRhaWxzLiAqLwpAQCAtODM3LDYgKzg5NiwxMyBAQAog CXJldHVybiAoMCk7CiB9CiAKK2ludAordGNwX2xyb19yeChzdHJ1Y3QgbHJvX2N0cmwgKmxjLCBz dHJ1Y3QgbWJ1ZiAqbSwgdWludDMyX3QgY3N1bSkKK3sKKworCXJldHVybiB0Y3BfbHJvX3J4Mihs YywgbSwgY3N1bSwgMSk7Cit9CisKIHZvaWQKIHRjcF9scm9fcXVldWVfbWJ1ZihzdHJ1Y3QgbHJv X2N0cmwgKmxjLCBzdHJ1Y3QgbWJ1ZiAqbWIpCiB7Cgo= --b1_7f308e3259123615ab8095ec95c1e0ce-- From owner-freebsd-net@freebsd.org Mon Jun 6 08:41:31 2016 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 5EACDB6D65E for ; Mon, 6 Jun 2016 08:41:31 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB2E1189 for ; Mon, 6 Jun 2016 08:41:31 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id E97C817A0B; Mon, 6 Jun 2016 08:41:30 +0000 (UTC) Date: Mon, 6 Jun 2016 08:41:30 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D6689+325+6c89ed8b7a9bc66d@reviews.freebsd.org Subject: [Differential] D6689: tcp/lro: Implement hash table for LRO entries. Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D6689: tcp/lro: Implement hash table for LRO entries. X-Herald-Rules: <64> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGRkYTdkZDNmZDVlODIxOWE3MGU3NDg3NmVjIFdVNzo= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 08:41:31 -0000 sepherosa_gmail.com added a comment. In https://reviews.freebsd.org/D6689#141127, @hselasky wrote: > > Well, as I said the VM does not have the luxury to do sorting :) > > Can you test the existing "tcp_lro_flush_all()" in combination with "tcp_lro_queue_mbuf()" and compare it to your version? Sorting is not as slow as you think. > > --HPS I will use the updated patch to test the hash and the queue_mbuf in Hyper-V. Thanks! REVISION DETAIL https://reviews.freebsd.org/D6689 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, rrs, gallatin, glebius, gnn, bz, rwatson, #transport, hselasky Cc: freebsd-net-list From owner-freebsd-net@freebsd.org Mon Jun 6 10:51:32 2016 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 22FAFB46E5E for ; Mon, 6 Jun 2016 10:51:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 131CF1183 for ; Mon, 6 Jun 2016 10:51:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u56ApVAm041424 for ; Mon, 6 Jun 2016 10:51:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 208392] [ PATCH ] dhclient-script: add support for interface-mtu (26) Date: Mon, 06 Jun 2016 10:51:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: novel@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 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.22 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, 06 Jun 2016 10:51:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208392 Roman Bogorodskiy changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |novel@FreeBSD.org --- Comment #1 from Roman Bogorodskiy --- Created attachment 171088 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D171088&action= =3Dedit proposed fix, v1 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jun 6 10:51:52 2016 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 516C1B46E8D for ; Mon, 6 Jun 2016 10:51:52 +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 424D01258 for ; Mon, 6 Jun 2016 10:51:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u56ApqUs043402 for ; Mon, 6 Jun 2016 10:51:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 208392] [ PATCH ] dhclient: add support for interface-mtu (26) Date: Mon, 06 Jun 2016 10:51:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: novel@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: short_desc 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.22 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, 06 Jun 2016 10:51:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208392 Roman Bogorodskiy changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[ PATCH ] dhclient-script: |[ PATCH ] dhclient: add |add support for |support for interface-mtu |interface-mtu (26) |(26) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Mon Jun 6 13:22:35 2016 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 E65CEB6B09E for ; Mon, 6 Jun 2016 13:22:35 +0000 (UTC) (envelope-from avv314@gmail.com) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A93271370 for ; Mon, 6 Jun 2016 13:22:35 +0000 (UTC) (envelope-from avv314@gmail.com) Received: by mail-yw0-x22a.google.com with SMTP id x189so139592102ywe.3 for ; Mon, 06 Jun 2016 06:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=B544I/68lprcomuq0FP/aaNXAeJXix8pyOzkLapvmW8=; b=uya4vBoXRFp5/gOjNAw0ofFEtrLUCtXe+z0eRI9tXxR1VF+PRd3vF6S3/pt2Ztb2QR S5BZtO2CuigWZwqn9QReasyMY9YBHk/QjWq91FJXXEPy0yE8m6s6juiZkvpU59ddDUj1 rna0EdDRfK9KrJQBpNeLW5sEHLHCSd8X0DJ729TZqu9GU7mSYZf9PsbeuT1Y/RE7Yh9k jVoG7vggTFd1zm35K5TCUMqQghWMCfX62jq7MpaWvEBk+dfSVNxVNVWnNzg2eSM9+Qp+ qyFQXfb2lbQrmGfxUpvR+5pgZRpq8fj8YoLfxLzLIN0ynbx/S2bwTpCYiVKg16JZvuS5 jpRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=B544I/68lprcomuq0FP/aaNXAeJXix8pyOzkLapvmW8=; b=ljfp9ZcOsfzS8nj+fS1bnau14LlgJagVXeq0mNPkRhTSGn4P/M4mrTFM4zTOUv8G/Q xG+QtB0ly6PfOPZEMLiN0W2U6G1HKskR9OnFat8hrwxq3L1itd8oNZS4tN4rWP28PhQw a2JTXxaiGxiXNtQjv4T9qYL3afnNd5HeWKvpSlQtiIsvd0O/iIOT5CqImyS0dtCWxhlU PmMJpbfoP8eIWd/BQCx6pYapGXvZxeSr8hMA7TcnKYJKJx7Yn1k20C79DkyJtp/FE9ac sSv285mrd2I79PZ7FdhSYikxdEQUq24NbipQYPfmE0oMXyJ8r3mJVZTHK3d7u+P28IVl +2XQ== X-Gm-Message-State: ALyK8tJcs8W6nqJukZm2h8FM71G0bo8Q36XJ4IZwPO/xGOEJqGCkhaupaISNdU+S/3gjRxs//SndoWsAKgUgQA== X-Received: by 10.37.13.146 with SMTP id 140mr11430439ybn.112.1465219353398; Mon, 06 Jun 2016 06:22:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.53.1 with HTTP; Mon, 6 Jun 2016 06:22:33 -0700 (PDT) From: Andrew Vylegzhanin Date: Mon, 6 Jun 2016 16:22:33 +0300 Message-ID: Subject: Is netmap jumbo frames broken in STABLE? To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 06 Jun 2016 13:22:36 -0000 Hello all, I have an application that uses netmap for capture jumbo frames. The frames are fixed size and have fixed rate (for example size 5166, rate 50000 pps). The frames are pure Ethernet, without IP header. Everything works fine in 10.0-RELEASE, 10.1-RELEASE. Starting from 10.3 and actual 10-STABLE I've got wrong data from netmap ring. It's looks like packet data broke and packet split on two parts 4092 and 1070 bytes, where original size was 5166. A code ring precessing is based on macros from netmap_user.h : n = nm_ring_space(ring); for (rx = 0; rx < limit; rx++) { struct netmap_slot *slot = &ring->slot[cur]; char *p = NETMAP_BUF(ring, slot->buf_idx); process_payload(p, slot->len, datapx); cur = nm_ring_next(ring, cur); } ring->head = ring->cur = cur; Here is netmap sysctl's: dev.netmap.buf_num=81920 dev.netmap.ring_size=73728 dev.netmap.buf_size=5248 Hardware is Dell R720 (2x E5-2643 v2) with four Intel Ethernet 10G 2P X520 Adapter. I use only one hardware queue per interface. BTW, may be a new version of Intel ixgbe driver (3.1.13-k) is a reason? Does it make sense to try with 11-CURRENT? Thank you in advance. -- Andrew From owner-freebsd-net@freebsd.org Mon Jun 6 14:03:43 2016 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 6810BB6BE88 for ; Mon, 6 Jun 2016 14:03:43 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D01F8116B for ; Mon, 6 Jun 2016 14:03:42 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id b73so95235380lfb.3 for ; Mon, 06 Jun 2016 07:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yeOJCc1YMDRjiEVwJrFL4FWgYg/DwohFKk6rHXRxWag=; b=oBf8r/EFxhKAnaMDDYhv6MPCCyLmRmzhtDz7OP98HkNrSrLdeVHnlGLxNqZETGj0c6 Hesu5Z5zBIu3vh1X1K5xyDoCvqVN/BSLakFA0wpNcEGSWWMEk9MorIBYwzKPIOUwtfl/ rLH8UtSIfwsIsHINdOxUcUqU8nleACt7GyaBWHLl5EtoeHqWom7K2nyeC8+/A6s4tmvD OnZBOD3dh86q84HbsSPZP6iiFo9aeMyT+tsyiQE4rQQ+9qY5lIxwP2Lic7KOrWmb6PeH Nf5MfLaY/NW3Z/p70My0GN44iVKFX2aTY+8llKlqjiD0QX4YrIcNNicroKpwukM43cYx CHcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yeOJCc1YMDRjiEVwJrFL4FWgYg/DwohFKk6rHXRxWag=; b=AsZUE9KlNx/44OWs2FCeDMvK/+KYo3Ql+3T5YoFX4jo+DYFJ2vngW1dD5j+Dd4CDg3 qv3JAZNeph76xQm16Wqv0eoh695rNWovfqKC7hAFWGaevqXJjQZNU0IR20Sdw/flshS8 8NmMRv9k328LvRTr0nvrG450gPAtevEeuSXV67drc21SUtzGY9VG7Mhn17AOtE4D1r05 tZpPFecmrj953DK5V3Y83afXCX/fyPgeP4r1nT6FEoaXtsJXzBlf1/IWUjIotXMaZyvb HPBmx7oxxjcmwzf3JIjS+L7MrTRKbP26BReuE/UgrudtXeheAPGj2XIJ9540M8Qx1Ch/ QQIQ== X-Gm-Message-State: ALyK8tIwsQICT9Zt1EltflvMmf8OsJUmidPyM4HJ7GwlH4Kmkyzdp/wb4KAn/bEZ4tjMimV2qYuAQ8n7xMeE4w== X-Received: by 10.25.167.6 with SMTP id q6mr1166258lfe.173.1465221820930; Mon, 06 Jun 2016 07:03:40 -0700 (PDT) MIME-Version: 1.0 Sender: rizzo.unipi@gmail.com Received: by 10.114.182.76 with HTTP; Mon, 6 Jun 2016 07:03:40 -0700 (PDT) In-Reply-To: References: From: Luigi Rizzo Date: Mon, 6 Jun 2016 16:03:40 +0200 X-Google-Sender-Auth: 8q_crulrKNwKT7zhfQDGBbdYwCc Message-ID: Subject: Re: Is netmap jumbo frames broken in STABLE? To: Andrew Vylegzhanin Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 06 Jun 2016 14:03:43 -0000 On Mon, Jun 6, 2016 at 3:22 PM, Andrew Vylegzhanin wrote= : > Hello all, > > > I have an application that uses netmap for capture jumbo frames. The fram= es > are fixed size and have fixed rate (for example size 5166, rate 50000 pps= ). > The frames are pure Ethernet, without IP header. > > > Everything works fine in 10.0-RELEASE, 10.1-RELEASE. > > > Starting from 10.3 and actual 10-STABLE I've got wrong data from netmap > ring. It's looks like packet data broke and packet split on two parts 409= 2 > and 1070 bytes, where original size was 5166. > > A code ring precessing is based on macros from netmap_user.h : > > > n =3D nm_ring_space(ring); > > for (rx =3D 0; rx < limit; rx++) { > > struct netmap_slot *slot =3D &ring->slot[cur]; > > char *p =3D NETMAP_BUF(ring, slot->buf_idx); > > process_payload(p, slot->len, datapx); > > cur =3D nm_ring_next(ring, cur); > > } > > ring->head =3D ring->cur =3D cur; > > > Here is netmap sysctl's: > > dev.netmap.buf_num=3D81920 > > dev.netmap.ring_size=3D73728 > > dev.netmap.buf_size=3D5248 > > > Hardware is Dell R720 (2x E5-2643 v2) with four Intel Ethernet 10G 2P X52= 0 > Adapter. I use only one hardware queue per interface. > > > BTW, may be a new version of Intel ixgbe driver (3.1.13-k) is a reason? > > =E2=80=8BHi, yes I suspect the problem may be in the new ixgbe driver, probably it programs the hardware to limit buffer sizes to 4k even when large MTUs are in use, so the receiver will split the incoming frame in two buffers, while netmap is expecting only one. I suggest to have a look at the ioctl handler (in the driver) that handles the MTU setting and compare with the code in the previous driver. cheers luigi > Does it make sense to try with 11-CURRENT? > > > Thank you in advance. > > > -- > > Andrew > _______________________________________________ > 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 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@freebsd.org Mon Jun 6 22:47:53 2016 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 9A096B6D2C9 for ; Mon, 6 Jun 2016 22:47:53 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 639C71938 for ; Mon, 6 Jun 2016 22:47:53 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-it0-x229.google.com with SMTP id i65so49269817ith.1 for ; Mon, 06 Jun 2016 15:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8kDc/UaJ3ilZT/DiQMajeAEPImvAdldP2WIoruwAYnc=; b=G7G72ZDk8QULUPS54cQGCi4CfH9g0WxhM5hR6SglHaqdZZrqicVosIO9Fao3b3bHtk zfO3wdIb7vQ1/iWHoFxhzxCGIVsVMyQQKaEM2fa0ObrJzs88klQBY40BfDpgXiv4J9ry hDlLKYEsX4ZbrYMdWPtc9MtSUPukX6eGMxg1LK9LZwUAzkBZyx1BMWbw9wA7idfQ7pyR wtUQGSrIVH8qIB88rpa8zGIwcWIkDtAMQ3aH6u8cPZMALFXWl1jopaGU5ttVRKYksEMc 41Il+Pyn/cPcfp4Iff9BcqR4Hykd2AXk0dJrY3ydIvMjdZ4VSNexwj4vVlXcvzgIY6rl tOJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8kDc/UaJ3ilZT/DiQMajeAEPImvAdldP2WIoruwAYnc=; b=DowoYMWCKJdeYla8+vEdaCLsXo8HHIGEguTXaU5T+eyQmzZPZD2LYxdAYNn51FUsQE Qq+ENlgCUR3VkMCSfzpheWi6qwmXDK90eD0lWLTJCypVd3oY0SrE2ok3Af/FGMNvCPNM CyjaFRjqslEI02a/xj0rxGw920DPUhzlz/s1XAWnvqrH9VKTZf4r+JCdiruNJvbqAZ6I oAL/txj8cDWxnakEALTioTkSyzl3bnP/wNUFpgVO3221XX/IHkt8vvJUGsEnvTwLG6e2 +z75TRwYTjq7N8SkLc6WxPeLsf71a/R9RAnexJTOFJTFWTvwVNmtkQ3vmmPDTm0gt3a1 OYfw== X-Gm-Message-State: ALyK8tK87h8ydtyXdC2af0G4apmovB2NahAG0MGuwdItSbhz8HUsrRdIHdCHUPfsc4Mc7w7OwJ1pGK0QyYagfw== X-Received: by 10.107.159.84 with SMTP id i81mr24045305ioe.29.1465253272756; Mon, 06 Jun 2016 15:47:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.57.9 with HTTP; Mon, 6 Jun 2016 15:47:52 -0700 (PDT) In-Reply-To: References: From: Ryan Stone Date: Mon, 6 Jun 2016 18:47:52 -0400 Message-ID: Subject: Re: Is netmap jumbo frames broken in STABLE? To: Luigi Rizzo Cc: Andrew Vylegzhanin , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 06 Jun 2016 22:47:53 -0000 The use of mbuf clusters larger than a single page really doesn't work. The problem is that over time physical memory becomes fragmented and eventually 9K of contiguous memory can't be allocated anymore. This is why many drivers now limit themselves to page-sized clusters. On Mon, Jun 6, 2016 at 10:03 AM, Luigi Rizzo wrote: > On Mon, Jun 6, 2016 at 3:22 PM, Andrew Vylegzhanin > wrote: > > > Hello all, > > > > > > I have an application that uses netmap for capture jumbo frames. The > frames > > are fixed size and have fixed rate (for example size 5166, rate 50000 > pps). > > The frames are pure Ethernet, without IP header. > > > > > > Everything works fine in 10.0-RELEASE, 10.1-RELEASE. > > > > > > Starting from 10.3 and actual 10-STABLE I've got wrong data from netmap > > ring. It's looks like packet data broke and packet split on two parts > 4092 > > and 1070 bytes, where original size was 5166. > > > > A code ring precessing is based on macros from netmap_user.h : > > > > > > n =3D nm_ring_space(ring); > > > > for (rx =3D 0; rx < limit; rx++) { > > > > struct netmap_slot *slot =3D &ring->slot[cur]; > > > > char *p =3D NETMAP_BUF(ring, slot->buf_idx); > > > > process_payload(p, slot->len, datapx); > > > > cur =3D nm_ring_next(ring, cur); > > > > } > > > > ring->head =3D ring->cur =3D cur; > > > > > > Here is netmap sysctl's: > > > > dev.netmap.buf_num=3D81920 > > > > dev.netmap.ring_size=3D73728 > > > > dev.netmap.buf_size=3D5248 > > > > > > Hardware is Dell R720 (2x E5-2643 v2) with four Intel Ethernet 10G 2P > X520 > > Adapter. I use only one hardware queue per interface. > > > > > > BTW, may be a new version of Intel ixgbe driver (3.1.13-k) is a reason? > > > > > =E2=80=8BHi, > yes I suspect the problem may be in the new ixgbe driver, > probably it programs the hardware to limit buffer sizes to 4k > even when large MTUs are in use, > so the receiver will split > the incoming frame in two buffers, while netmap is expecting > only one. > I suggest to have a look at the ioctl handler (in the driver) > that handles the MTU setting and compare with the code > in the previous driver. > > cheers > luigi > > > > Does it make sense to try with 11-CURRENT? > > > > > > Thank you in advance. > > > > > > -- > > > > Andrew > > _______________________________________________ > > 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" > > > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2217533 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > _______________________________________________ > 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 Jun 7 04:52:12 2016 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 010A3B6DE08 for ; Tue, 7 Jun 2016 04:52:12 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id BA31316EB for ; Tue, 7 Jun 2016 04:52:11 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id D7A7C17EBD; Tue, 7 Jun 2016 04:52:10 +0000 (UTC) Date: Tue, 7 Jun 2016 04:52:10 +0000 To: freebsd-net@freebsd.org From: Phabricator Reply-to: D6688+325+682f43da723b770f@reviews.freebsd.org Subject: [Differential] D6688: net: Use M_HASHTYPE_OPAQUE_HASH if the mbuf flowid has hash properties Message-ID: <13c301ad4f2573b4a89a66923335b8a3@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D6688: net: Use M_HASHTYPE_OPAQUE_HASH if the mbuf flowid has hash properties X-Herald-Rules: <29>, <54>, <55>, <56> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: NzRhYTgzMGNhOTUyZGI3NWI4NGEwOTUyYzhiIFdWUvo= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_13c301ad4f2573b4a89a66923335b8a3" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 04:52:12 -0000 --b1_13c301ad4f2573b4a89a66923335b8a3 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit This revision was automatically updated to reflect the committed changes. Closed by commit rS301538: net: Use M_HASHTYPE_OPAQUE_HASH if the mbuf flowid has hash properties (authored by sephe). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D6688?vs=17213&id=17373#toc REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D6688?vs=17213&id=17373 REVISION DETAIL https://reviews.freebsd.org/D6688 AFFECTED FILES head/sys/dev/cxgb/cxgb_sge.c head/sys/dev/e1000/if_igb.c head/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c head/sys/dev/ixgbe/ix_txrx.c head/sys/dev/ixl/ixl_txrx.c head/sys/dev/mlx5/mlx5_en/mlx5_en_rx.c head/sys/dev/qlxgbe/ql_isr.c head/sys/dev/qlxge/qls_isr.c head/sys/net/flowtable.c head/sys/net/if_vxlan.c head/sys/netinet/sctp_input.c head/sys/netinet/sctp_pcb.c head/sys/ofed/drivers/net/mlx4/en_rx.c EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, rrs, gallatin, glebius, rwatson, gnn, adrian, delphij, bryanv, kmacy, davidcs, bz, np, sbruno, hselasky, tuexen, #intel_networking, erj Cc: freebsd-net-list --b1_13c301ad4f2573b4a89a66923335b8a3 Content-Type: text/x-patch; charset=utf-8; name="D6688.17373.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D6688.17373.patch" ZGlmZiAtLWdpdCBhL2hlYWQvc3lzL29mZWQvZHJpdmVycy9uZXQvbWx4NC9lbl9yeC5jIGIvaGVh ZC9zeXMvb2ZlZC9kcml2ZXJzL25ldC9tbHg0L2VuX3J4LmMKLS0tIGEvaGVhZC9zeXMvb2ZlZC9k cml2ZXJzL25ldC9tbHg0L2VuX3J4LmMKKysrIGIvaGVhZC9zeXMvb2ZlZC9kcml2ZXJzL25ldC9t bHg0L2VuX3J4LmMKQEAgLTYxOSw3ICs2MTksNyBAQAogCiAJCS8qIGZvcndhcmQgVG9lcGxpdHog Y29tcGF0aWJsZSBoYXNoIHZhbHVlICovCiAJCW1iLT5tX3BrdGhkci5mbG93aWQgPSBiZTMyX3Rv X2NwdShjcWUtPmltbWVkX3Jzc19pbnZhbGlkKTsKLQkJTV9IQVNIVFlQRV9TRVQobWIsIE1fSEFT SFRZUEVfT1BBUVVFKTsKKwkJTV9IQVNIVFlQRV9TRVQobWIsIE1fSEFTSFRZUEVfT1BBUVVFX0hB U0gpOwogCQltYi0+bV9wa3RoZHIucmN2aWYgPSBkZXY7CiAJCWlmIChiZTMyX3RvX2NwdShjcWUt PnZsYW5fbXlfcXBuKSAmCiAJCSAgICBNTFg0X0NRRV9WTEFOX1BSRVNFTlRfTUFTSykgewpkaWZm IC0tZ2l0IGEvaGVhZC9zeXMvbmV0aW5ldC9zY3RwX3BjYi5jIGIvaGVhZC9zeXMvbmV0aW5ldC9z Y3RwX3BjYi5jCi0tLSBhL2hlYWQvc3lzL25ldGluZXQvc2N0cF9wY2IuYworKysgYi9oZWFkL3N5 cy9uZXRpbmV0L3NjdHBfcGNiLmMKQEAgLTQwNzAsNyArNDA3MCw3IEBACiAJbmV0LT5mbG93aWQg PSBzdGNiLT5hc29jLm15X3Z0YWcgXgogCSAgICBudG9ocyhzdGNiLT5ycG9ydCkgXgogCSAgICBu dG9ocyhzdGNiLT5zY3RwX2VwLT5zY3RwX2xwb3J0KTsKLQluZXQtPmZsb3d0eXBlID0gTV9IQVNI VFlQRV9PUEFRVUU7CisJbmV0LT5mbG93dHlwZSA9IE1fSEFTSFRZUEVfT1BBUVVFX0hBU0g7CiAJ aWYgKG5ldHApIHsKIAkJKm5ldHAgPSBuZXQ7CiAJfQpkaWZmIC0tZ2l0IGEvaGVhZC9zeXMvbmV0 aW5ldC9zY3RwX2lucHV0LmMgYi9oZWFkL3N5cy9uZXRpbmV0L3NjdHBfaW5wdXQuYwotLS0gYS9o ZWFkL3N5cy9uZXRpbmV0L3NjdHBfaW5wdXQuYworKysgYi9oZWFkL3N5cy9uZXRpbmV0L3NjdHBf aW5wdXQuYwpAQCAtNjIzNiw3ICs2MjM2LDcgQEAKIAkJCXRhZyA9IGh0b25sKHNoLT52X3RhZyk7 CiAJCQlmbG93aWQgPSB0YWcgXiBudG9ocyhzaC0+ZGVzdF9wb3J0KSBeIG50b2hzKHNoLT5zcmNf cG9ydCk7CiAJCQltLT5tX3BrdGhkci5mbG93aWQgPSBmbG93aWQ7Ci0JCQlNX0hBU0hUWVBFX1NF VChtLCBNX0hBU0hUWVBFX09QQVFVRSk7CisJCQlNX0hBU0hUWVBFX1NFVChtLCBNX0hBU0hUWVBF X09QQVFVRV9IQVNIKTsKIAkJfQogCQljcHVfdG9fdXNlID0gc2N0cF9jcHVhcnJ5W2Zsb3dpZCAl IG1wX25jcHVzXTsKIAkJc2N0cF9xdWV1ZV90b19tY29yZShtLCBvZmYsIGNwdV90b191c2UpOwpk aWZmIC0tZ2l0IGEvaGVhZC9zeXMvbmV0L2lmX3Z4bGFuLmMgYi9oZWFkL3N5cy9uZXQvaWZfdnhs YW4uYwotLS0gYS9oZWFkL3N5cy9uZXQvaWZfdnhsYW4uYworKysgYi9oZWFkL3N5cy9uZXQvaWZf dnhsYW4uYwpAQCAtMjIzNyw4ICsyMjM3LDcgQEAKIAlyYW5nZSA9IHNjLT52eGxfbWF4X3BvcnQg LSBzYy0+dnhsX21pbl9wb3J0ICsgMTsKIAogCS8qIGNoZWNrIGlmIGZsb3dpZCBpcyBzZXQgYW5k IG5vdCBvcGFxdWUgKi8KLQlpZiAoTV9IQVNIVFlQRV9HRVQobSkgIT0gTV9IQVNIVFlQRV9OT05F ICYmCi0JICAgIE1fSEFTSFRZUEVfR0VUKG0pICE9IE1fSEFTSFRZUEVfT1BBUVVFKQorCWlmIChN X0hBU0hUWVBFX0lTSEFTSChtKSkKIAkJaGFzaCA9IG0tPm1fcGt0aGRyLmZsb3dpZDsKIAllbHNl CiAJCWhhc2ggPSBqZW5raW5zX2hhc2gobS0+bV9kYXRhLCBFVEhFUl9IRFJfTEVOLApkaWZmIC0t Z2l0IGEvaGVhZC9zeXMvbmV0L2Zsb3d0YWJsZS5jIGIvaGVhZC9zeXMvbmV0L2Zsb3d0YWJsZS5j Ci0tLSBhL2hlYWQvc3lzL25ldC9mbG93dGFibGUuYworKysgYi9oZWFkL3N5cy9uZXQvZmxvd3Rh YmxlLmMKQEAgLTY4OSw3ICs2ODksNyBAQAogCQlyZXR1cm4gKEVIT1NUVU5SRUFDSCk7CiAKIAlp ZiAoTV9IQVNIVFlQRV9HRVQobSkgPT0gTV9IQVNIVFlQRV9OT05FKSB7Ci0JCU1fSEFTSFRZUEVf U0VUKG0sIE1fSEFTSFRZUEVfT1BBUVVFKTsKKwkJTV9IQVNIVFlQRV9TRVQobSwgTV9IQVNIVFlQ RV9PUEFRVUVfSEFTSCk7CiAJCW0tPm1fcGt0aGRyLmZsb3dpZCA9IGZsZS0+Zl9oYXNoOwogCX0K IApkaWZmIC0tZ2l0IGEvaGVhZC9zeXMvZGV2L3FseGdlL3Fsc19pc3IuYyBiL2hlYWQvc3lzL2Rl di9xbHhnZS9xbHNfaXNyLmMKLS0tIGEvaGVhZC9zeXMvZGV2L3FseGdlL3Fsc19pc3IuYworKysg Yi9oZWFkL3N5cy9kZXYvcWx4Z2UvcWxzX2lzci5jCkBAIC0xOTAsNyArMTkwLDcgQEAKIAkJCWlm ICgoY3FfZS0+ZmxhZ3MxICYgUTgxX1JYX0ZMQUdTMV9SU1NfTUFUQ0hfTUFTSykpIHsKIAkJCQly eHItPnJzc19pbnQrKzsKIAkJCQltcC0+bV9wa3RoZHIuZmxvd2lkID0gY3FfZS0+cnNzOwotCQkJ CU1fSEFTSFRZUEVfU0VUKG1wLCBNX0hBU0hUWVBFX09QQVFVRSk7CisJCQkJTV9IQVNIVFlQRV9T RVQobXAsIE1fSEFTSFRZUEVfT1BBUVVFX0hBU0gpOwogCQkJfQogCQkJaWYgKGNxX2UtPmZsYWdz MCAmIChRODFfUlhfRkxBR1MwX1RFIHwKIAkJCQlRODFfUlhfRkxBR1MwX05VIHwgUTgxX1JYX0ZM QUdTMF9JRSkpIHsKZGlmZiAtLWdpdCBhL2hlYWQvc3lzL2Rldi9xbHhnYmUvcWxfaXNyLmMgYi9o ZWFkL3N5cy9kZXYvcWx4Z2JlL3FsX2lzci5jCi0tLSBhL2hlYWQvc3lzL2Rldi9xbHhnYmUvcWxf aXNyLmMKKysrIGIvaGVhZC9zeXMvZGV2L3FseGdiZS9xbF9pc3IuYwpAQCAtMTU5LDcgKzE1OSw3 IEBACiAJaWZfaW5jX2NvdW50ZXIoaWZwLCBJRkNPVU5URVJfSVBBQ0tFVFMsIDEpOwogCiAJbXBm LT5tX3BrdGhkci5mbG93aWQgPSBzZ2MtPnJzc19oYXNoOwotCU1fSEFTSFRZUEVfU0VUKG1wZiwg TV9IQVNIVFlQRV9PUEFRVUUpOworCU1fSEFTSFRZUEVfU0VUKG1wZiwgTV9IQVNIVFlQRV9PUEFR VUVfSEFTSCk7CiAKIAkoKmlmcC0+aWZfaW5wdXQpKGlmcCwgbXBmKTsKIApAQCAtMzI0LDcgKzMy NCw3IEBACiAJbXBmLT5tX3BrdGhkci5jc3VtX2RhdGEgPSAweEZGRkY7CiAKIAltcGYtPm1fcGt0 aGRyLmZsb3dpZCA9IHNnYy0+cnNzX2hhc2g7Ci0JTV9IQVNIVFlQRV9TRVQobXBmLCBNX0hBU0hU WVBFX09QQVFVRSk7CisJTV9IQVNIVFlQRV9TRVQobXBmLCBNX0hBU0hUWVBFX09QQVFVRV9IQVNI KTsKIAogCWlmX2luY19jb3VudGVyKGlmcCwgSUZDT1VOVEVSX0lQQUNLRVRTLCAxKTsKIApkaWZm IC0tZ2l0IGEvaGVhZC9zeXMvZGV2L21seDUvbWx4NV9lbi9tbHg1X2VuX3J4LmMgYi9oZWFkL3N5 cy9kZXYvbWx4NS9tbHg1X2VuL21seDVfZW5fcnguYwotLS0gYS9oZWFkL3N5cy9kZXYvbWx4NS9t bHg1X2VuL21seDVfZW5fcnguYworKysgYi9oZWFkL3N5cy9kZXYvbWx4NS9tbHg1X2VuL21seDVf ZW5fcnguYwpAQCAtMjIyLDExICsyMjIsMTEgQEAKIAkJCU1fSEFTSFRZUEVfU0VUKG1iLCBNX0hB U0hUWVBFX1JTU19JUFY2KTsKIAkJCWJyZWFrOwogCQlkZWZhdWx0OgkvKiBPdGhlciAqLwotCQkJ TV9IQVNIVFlQRV9TRVQobWIsIE1fSEFTSFRZUEVfT1BBUVVFKTsKKwkJCU1fSEFTSFRZUEVfU0VU KG1iLCBNX0hBU0hUWVBFX09QQVFVRV9IQVNIKTsKIAkJCWJyZWFrOwogCQl9CiAjZWxzZQotCQlN X0hBU0hUWVBFX1NFVChtYiwgTV9IQVNIVFlQRV9PUEFRVUUpOworCQlNX0hBU0hUWVBFX1NFVCht YiwgTV9IQVNIVFlQRV9PUEFRVUVfSEFTSCk7CiAjZW5kaWYKIAl9IGVsc2UgewogCQltYi0+bV9w a3RoZHIuZmxvd2lkID0gcnEtPml4OwpkaWZmIC0tZ2l0IGEvaGVhZC9zeXMvZGV2L2l4bC9peGxf dHhyeC5jIGIvaGVhZC9zeXMvZGV2L2l4bC9peGxfdHhyeC5jCi0tLSBhL2hlYWQvc3lzL2Rldi9p eGwvaXhsX3R4cnguYworKysgYi9oZWFkL3N5cy9kZXYvaXhsL2l4bF90eHJ4LmMKQEAgLTE0NTMs MTAgKzE0NTMsMTAgQEAKIAlleCA9IGRlY29kZWQub3V0ZXJfZnJhZzsKIAogCWlmICghZGVjb2Rl ZC5rbm93bikKLQkJcmV0dXJuIE1fSEFTSFRZUEVfT1BBUVVFOworCQlyZXR1cm4gTV9IQVNIVFlQ RV9PUEFRVUVfSEFTSDsKIAogCWlmIChkZWNvZGVkLm91dGVyX2lwID09IEk0MEVfUlhfUFRZUEVf T1VURVJfTDIpIAotCQlyZXR1cm4gTV9IQVNIVFlQRV9PUEFRVUU7CisJCXJldHVybiBNX0hBU0hU WVBFX09QQVFVRV9IQVNIOwogCiAJLyogTm90ZTogYW55dGhpbmcgdGhhdCBnZXRzIHRvIHRoaXMg cG9pbnQgaXMgSVAgKi8KICAgICAgICAgaWYgKGRlY29kZWQub3V0ZXJfaXBfdmVyID09IEk0MEVf UlhfUFRZUEVfT1VURVJfSVBWNikgeyAKQEAgLTE0OTIsNyArMTQ5Miw3IEBACiAJCX0KIAl9CiAJ LyogV2Ugc2hvdWxkIG5ldmVyIGdldCBoZXJlISEgKi8KLQlyZXR1cm4gTV9IQVNIVFlQRV9PUEFR VUU7CisJcmV0dXJuIE1fSEFTSFRZUEVfT1BBUVVFX0hBU0g7CiB9CiAjZW5kaWYgLyogUlNTICov CiAKZGlmZiAtLWdpdCBhL2hlYWQvc3lzL2Rldi9peGdiZS9peF90eHJ4LmMgYi9oZWFkL3N5cy9k ZXYvaXhnYmUvaXhfdHhyeC5jCi0tLSBhL2hlYWQvc3lzL2Rldi9peGdiZS9peF90eHJ4LmMKKysr IGIvaGVhZC9zeXMvZGV2L2l4Z2JlL2l4X3R4cnguYwpAQCAtMTk2NCw3ICsxOTY0LDcgQEAKICNl bmRpZgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVmYXVsdDoKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNX0hBU0hUWVBFX1NFVChzZW5kbXAs Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1fSEFTSFRZUEVf T1BBUVVFKTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTV9I QVNIVFlQRV9PUEFRVUVfSEFTSCk7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0K ICAgICAgICAgICAgICAgICAgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHNlbmRtcC0+bV9wa3RoZHIuZmxvd2lkID0gcXVlLT5tc2l4OwpkaWZmIC0tZ2l0 IGEvaGVhZC9zeXMvZGV2L2h5cGVydi9uZXR2c2MvaHZfbmV0dnNjX2Rydl9mcmVlYnNkLmMgYi9o ZWFkL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2QuYwotLS0gYS9o ZWFkL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2QuYworKysgYi9o ZWFkL3N5cy9kZXYvaHlwZXJ2L25ldHZzYy9odl9uZXR2c2NfZHJ2X2ZyZWVic2QuYwpAQCAtMTMw MCw2ICsxMzAwLDcgQEAKIAlzdHJ1Y3QgaWZuZXQgKmlmcCA9IHJ4ci0+aG5faWZwOwogCXN0cnVj dCBtYnVmICptX25ldzsKIAlpbnQgc2l6ZSwgZG9fbHJvID0gMCwgZG9fY3N1bSA9IDE7CisJaW50 IGhhc2hfdHlwZSA9IE1fSEFTSFRZUEVfT1BBUVVFX0hBU0g7CiAKIAlpZiAoIShpZnAtPmlmX2Ry dl9mbGFncyAmIElGRl9EUlZfUlVOTklORykpCiAJCXJldHVybiAoMCk7CkBAIC0xNDMwLDggKzE0 MzEsNiBAQAogCX0KIAogCWlmIChoYXNoX2luZm8gIT0gTlVMTCAmJiBoYXNoX3ZhbHVlICE9IE5V TEwpIHsKLQkJaW50IGhhc2hfdHlwZSA9IE1fSEFTSFRZUEVfT1BBUVVFOwotCiAJCXJ4ci0+aG5f cnNzX3BrdHMrKzsKIAkJbV9uZXctPm1fcGt0aGRyLmZsb3dpZCA9IGhhc2hfdmFsdWUtPmhhc2hf dmFsdWU7CiAJCWlmICgoaGFzaF9pbmZvLT5oYXNoX2luZm8gJiBORElTX0hBU0hfRlVOQ1RJT05f TUFTSykgPT0KQEAgLTE0NjUsMTQgKzE0NjQsMTUgQEAKIAkJCQlicmVhazsKIAkJCX0KIAkJfQot CQlNX0hBU0hUWVBFX1NFVChtX25ldywgaGFzaF90eXBlKTsKIAl9IGVsc2UgewotCQlpZiAoaGFz aF92YWx1ZSAhPSBOVUxMKQorCQlpZiAoaGFzaF92YWx1ZSAhPSBOVUxMKSB7CiAJCQltX25ldy0+ bV9wa3RoZHIuZmxvd2lkID0gaGFzaF92YWx1ZS0+aGFzaF92YWx1ZTsKLQkJZWxzZQorCQl9IGVs c2UgewogCQkJbV9uZXctPm1fcGt0aGRyLmZsb3dpZCA9IHJ4ci0+aG5fcnhfaWR4OwotCQlNX0hB U0hUWVBFX1NFVChtX25ldywgTV9IQVNIVFlQRV9PUEFRVUUpOworCQkJaGFzaF90eXBlID0gTV9I QVNIVFlQRV9PUEFRVUU7CisJCX0KIAl9CisJTV9IQVNIVFlQRV9TRVQobV9uZXcsIGhhc2hfdHlw ZSk7CiAKIAkvKgogCSAqIE5vdGU6ICBNb3ZlZCBSWCBjb21wbGV0aW9uIGJhY2sgdG8gaHZfbnZf b25fcmVjZWl2ZSgpIHNvIGFsbApkaWZmIC0tZ2l0IGEvaGVhZC9zeXMvZGV2L2UxMDAwL2lmX2ln Yi5jIGIvaGVhZC9zeXMvZGV2L2UxMDAwL2lmX2lnYi5jCi0tLSBhL2hlYWQvc3lzL2Rldi9lMTAw MC9pZl9pZ2IuYworKysgYi9oZWFkL3N5cy9kZXYvZTEwMDAvaWZfaWdiLmMKQEAgLTUxNTQsNyAr NTE1NCw3IEBACiAJCQkJCWRlZmF1bHQ6CiAJCQkJCQkvKiBYWFggZmFsbHRocm91Z2ggKi8KIAkJ CQkJCU1fSEFTSFRZUEVfU0VUKHJ4ci0+Zm1wLAotCQkJCQkJICAgIE1fSEFTSFRZUEVfT1BBUVVF KTsKKwkJCQkJCSAgICBNX0hBU0hUWVBFX09QQVFVRV9IQVNIKTsKIAkJCQl9CiAJCQl9IGVsc2Ug ewogI2lmbmRlZiBJR0JfTEVHQUNZX1RYCmRpZmYgLS1naXQgYS9oZWFkL3N5cy9kZXYvY3hnYi9j eGdiX3NnZS5jIGIvaGVhZC9zeXMvZGV2L2N4Z2IvY3hnYl9zZ2UuYwotLS0gYS9oZWFkL3N5cy9k ZXYvY3hnYi9jeGdiX3NnZS5jCisrKyBiL2hlYWQvc3lzL2Rldi9jeGdiL2N4Z2Jfc2dlLmMKQEAg LTI5MDAsNyArMjkwMCw4IEBACiAJCQllb3AgPSBnZXRfcGFja2V0KGFkYXAsIGRyb3BfdGhyZXNo LCBxcywgbWgsIHIpOwogCQkJaWYgKGVvcCkgewogCQkJCWlmIChyLT5yc3NfaGRyLmhhc2hfdHlw ZSAmJiAhYWRhcC0+dGltZXN0YW1wKSB7Ci0JCQkJCU1fSEFTSFRZUEVfU0VUKG1oLT5taF9oZWFk LCBNX0hBU0hUWVBFX09QQVFVRSk7CisJCQkJCU1fSEFTSFRZUEVfU0VUKG1oLT5taF9oZWFkLAor CQkJCQkgICAgTV9IQVNIVFlQRV9PUEFRVUVfSEFTSCk7CiAJCQkJCW1oLT5taF9oZWFkLT5tX3Br dGhkci5mbG93aWQgPSByc3NfaGFzaDsKIAkJCQl9CiAJCQl9Cgo= --b1_13c301ad4f2573b4a89a66923335b8a3-- From owner-freebsd-net@freebsd.org Tue Jun 7 12:22:27 2016 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 114DAB6EC0D for ; Tue, 7 Jun 2016 12:22:27 +0000 (UTC) (envelope-from avv314@gmail.com) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 C3ADD1652 for ; Tue, 7 Jun 2016 12:22:26 +0000 (UTC) (envelope-from avv314@gmail.com) Received: by mail-yw0-x234.google.com with SMTP id x189so167664254ywe.3 for ; Tue, 07 Jun 2016 05:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oW/JukInd3nfRvTCDB+mkW3xKbwNoZDv3m1jx6MYyBA=; b=AogjMqNA8D4q/OiR7O5WTxhzRLpAxJnG3Wbb16cn390AwOptYJr0HHfKrmQeykk0cS XJT4d4f/8wYdplClsPPOpj89fFH9YXvijtdEsts+GHe65N74+sW9Udk2chHzvTKqlNTj IrgJukhBxlmjOONxqhAvSRQs7B95d6ixh09uipoxE9P87pxQzPu32CdAubllH/rsoMAB VZHlDyJM7bmN3JYLTvxNEGA9dHpD4blXmSPcqpAn+WlHShDzBJOpuffWV2asTG4m45IL Vr9PZc1W5ivd1TWLOR8teyc/LpyumbAn1NW7jx1mX2p/5va2aH7xW9nhJrsHGwM86Jno Y+cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oW/JukInd3nfRvTCDB+mkW3xKbwNoZDv3m1jx6MYyBA=; b=JklQUpcccnmq7i8QyB/gX0I+mVwD2tGPdemyxl+3obAT0Uj+0cH86c98xQmCpaRRw+ Vw70i2BROLOVx/L1ysmmrgwe4Y8vpoUyqji8gtYj4QUFd3u/t6LhnktIRCKSm0+LcKnA tZlItv8MaIM2BcBdgZyXkDMw3tvqZLQl4EVTnNXmpKIL517I8CAHut4Ns8qN5R3OpATY DNI9r3q+pbPs60RWIIctit0sst0xwDXIQVs0cH3+W5AIMdfg4+EJBnwIx+JdGR65e8MS gVeI5lIPhbNQ/QCrDMFtQ5wmxFWeLi1qGaaSarDF9BuJ5GlUnl8MVb7FGcHsrQ49A+6h L5Tg== X-Gm-Message-State: ALyK8tL1Rxtndpwt2zhEUm1eI0FWQ2cZMUNR9eTlFejCm+IqjhhhFgAjiLlBpzea9NJIphfmlMh+mTQ8ebMEPQ== X-Received: by 10.13.206.67 with SMTP id q64mr13532855ywd.28.1465302146067; Tue, 07 Jun 2016 05:22:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.53.1 with HTTP; Tue, 7 Jun 2016 05:22:25 -0700 (PDT) In-Reply-To: References: From: Andrew Vylegzhanin Date: Tue, 7 Jun 2016 15:22:25 +0300 Message-ID: Subject: Re: Is netmap jumbo frames broken in STABLE? To: "freebsd-net@freebsd.org" Cc: Luigi Rizzo , Ryan Stone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 07 Jun 2016 12:22:27 -0000 Just for support Luigi assumption. I've tested on 11.0-ALPHA1 (r301204). Same situation with frame size 5166 and works _well_ with frame size 4032. -- Andrew 2016-06-07 1:47 GMT+03:00 Ryan Stone : > The use of mbuf clusters larger than a single page really doesn't work. > The problem is that over time physical memory becomes fragmented and > eventually 9K of contiguous memory can't be allocated anymore. This is w= hy > many drivers now limit themselves to page-sized clusters. > > On Mon, Jun 6, 2016 at 10:03 AM, Luigi Rizzo wrote: > >> On Mon, Jun 6, 2016 at 3:22 PM, Andrew Vylegzhanin >> wrote: >> >> > Hello all, >> > >> > >> > I have an application that uses netmap for capture jumbo frames. The >> frames >> > are fixed size and have fixed rate (for example size 5166, rate 50000 >> pps). >> > The frames are pure Ethernet, without IP header. >> > >> > >> > Everything works fine in 10.0-RELEASE, 10.1-RELEASE. >> > >> > >> > Starting from 10.3 and actual 10-STABLE I've got wrong data from netma= p >> > ring. It's looks like packet data broke and packet split on two parts >> 4092 >> > and 1070 bytes, where original size was 5166. >> > >> > A code ring precessing is based on macros from netmap_user.h : >> > >> > >> > n =3D nm_ring_space(ring); >> > >> > for (rx =3D 0; rx < limit; rx++) { >> > >> > struct netmap_slot *slot =3D &ring->slot[cur]; >> > >> > char *p =3D NETMAP_BUF(ring, slot->buf_idx); >> > >> > process_payload(p, slot->len, datapx); >> > >> > cur =3D nm_ring_next(ring, cur); >> > >> > } >> > >> > ring->head =3D ring->cur =3D cur; >> > >> > >> > Here is netmap sysctl's: >> > >> > dev.netmap.buf_num=3D81920 >> > >> > dev.netmap.ring_size=3D73728 >> > >> > dev.netmap.buf_size=3D5248 >> > >> > >> > Hardware is Dell R720 (2x E5-2643 v2) with four Intel Ethernet 10G 2P >> X520 >> > Adapter. I use only one hardware queue per interface. >> > >> > >> > BTW, may be a new version of Intel ixgbe driver (3.1.13-k) is a reason= ? >> > >> > >> =E2=80=8BHi, >> yes I suspect the problem may be in the new ixgbe driver, >> probably it programs the hardware to limit buffer sizes to 4k >> even when large MTUs are in use, >> so the receiver will split >> the incoming frame in two buffers, while netmap is expecting >> only one. >> I suggest to have a look at the ioctl handler (in the driver) >> that handles the MTU setting and compare with the code >> in the previous driver. >> >> cheers >> luigi >> >> >> > Does it make sense to try with 11-CURRENT? >> > >> > >> > Thank you in advance. >> > >> > >> > -- >> > >> > Andrew >> > _______________________________________________ >> > 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" >> > >> >> >> >> -- >> -----------------------------------------+------------------------------= - >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2217533 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------= - >> _______________________________________________ >> 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 Jun 7 12:44:18 2016 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 D04B7B6D256 for ; Tue, 7 Jun 2016 12:44:18 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4j.cmail.yandex.net (forward4j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5323E12E5 for ; Tue, 7 Jun 2016 12:44:18 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [IPv6:2a02:6b8:0:801:1::13]) by forward4j.cmail.yandex.net (Yandex) with ESMTP id 8E55221011; Tue, 7 Jun 2016 15:44:02 +0300 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id ECDF91B60357; Tue, 7 Jun 2016 15:44:01 +0300 (MSK) Received: by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 9g6JDzx6vW-i1WOVZca; Tue, 07 Jun 2016 15:44:01 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1465303441; bh=kPklKzAz9/szRF5HhZZhTJMJPDM+BWgjSsq27kr+fVc=; h=Subject:To:References:Cc:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; b=aRh3Zjw9oyK6T0ML+2urevCFiMNLIte/sFa5Xa+X0rGh8rqFhrw17FwSBZR3Ccy8O IgDX7pSHtGELekaaQbFNJD5UxQeWfIAeUNdGh9XOwFfTDCq44yJNYVzI0pUYtUIezF GIWUt2COwhiO3n61NXBN+mbjqufukbBsnCXEa91Q= Authentication-Results: smtp14.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0,1 0 Subject: Re: Is netmap jumbo frames broken in STABLE? To: Andrew Vylegzhanin , "freebsd-net@freebsd.org" References: Cc: Ryan Stone , Luigi Rizzo From: "Andrey V. Elsukov" Message-ID: <5756C17D.1090409@yandex.ru> Date: Tue, 7 Jun 2016 15:43:41 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cPEtbGKx7erBTgBdGKgdWWvSV0JERXWi5" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 07 Jun 2016 12:44:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cPEtbGKx7erBTgBdGKgdWWvSV0JERXWi5 Content-Type: multipart/mixed; boundary="6E0JO9m0tg2pjRP7HmtWlBmwx1AeO0Nsx" From: "Andrey V. Elsukov" To: Andrew Vylegzhanin , "freebsd-net@freebsd.org" Cc: Ryan Stone , Luigi Rizzo Message-ID: <5756C17D.1090409@yandex.ru> Subject: Re: Is netmap jumbo frames broken in STABLE? References: In-Reply-To: --6E0JO9m0tg2pjRP7HmtWlBmwx1AeO0Nsx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07.06.16 15:22, Andrew Vylegzhanin wrote: > Just for support Luigi assumption. >=20 > I've tested on 11.0-ALPHA1 (r301204). > Same situation with frame size 5166 and works _well_ with frame size 40= 32. This was changed in https://svnweb.freebsd.org/base?view=3Drevision&revision=3D283883 In the ixgbe_init_locked() initialization of adapter->rx_mbuf_sz was limited to MJUMPAGESIZE. But I'm agree with Ryan, with this configuration it works more reliable. --=20 WBR, Andrey V. Elsukov --6E0JO9m0tg2pjRP7HmtWlBmwx1AeO0Nsx-- --cPEtbGKx7erBTgBdGKgdWWvSV0JERXWi5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXVsGBAAoJEAHF6gQQyKF6tJ8H/131BlPBIh9UIoSmyKdQqUDv OJTpqik0ldhz7l8m77OSTNNbAlMBa+lKTV48pPC7OMXLg4A4V3uhgH+gqIMtGcYk F1LJFw9/UsxpZ1hrHi6RMhE7V+rMwC9Z47V+9DqdK8FH+q+/bnrN2SJnD6KQ++dx 8MOekPTAVFhhEr45F7UGpyZFtoFCnX3QVAUDvhbmMy4OloNlgr8hkgZNkqlzd/I4 lt8R9oegc4mVJG4W5AttWZ0DtJyI9tsIUuYU2aF8cSP943E5YNU0Lni/A9iBasFt mjMw7hc0OukNM2fvfoQdC8ut0thU0LUvB7QAIEUivNFMCVru9/f2JCmy8H+OdvY= =7XFd -----END PGP SIGNATURE----- --cPEtbGKx7erBTgBdGKgdWWvSV0JERXWi5-- From owner-freebsd-net@freebsd.org Tue Jun 7 12:50:57 2016 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 C5824B6D454 for ; Tue, 7 Jun 2016 12:50:57 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 4968F1875 for ; Tue, 7 Jun 2016 12:50:57 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22f.google.com with SMTP id b73so114310299lfb.3 for ; Tue, 07 Jun 2016 05:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=FgQl+FARYrxIzpniJ77q5EwozxOnPxY7Ajr+JHShlrE=; b=b+LOhI+Dd5AUIIWjGvsqc2mEyf0tGQRG4apxEF5q43ih1yIRRwK14Gb2jmloVE7IHx macjv42maFnPdyZD2WsVvO51hxgt7hgkxHJkFmXuoYfbW+3hz+ICD2I0lSxXaRvrZx2C HRcD03Zz57wT7cTki9Ob7t/0I20eKrIFoMhY5qA+zBRKkR9OprvoJAU36ULp+2rR+unI LN/5LMU5fVIQHmHuFyhfjIRzj179aitNSSzEtoWk+guDPFZx9Xd6Nri0TU67B1ampYAQ +n1TldZH8/Uvd/Psb8P0oNhq0zIGm8Xpmd/XJ6yRtOh41uycvkBe0G7PFSVtvP5B8TFC VlvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=FgQl+FARYrxIzpniJ77q5EwozxOnPxY7Ajr+JHShlrE=; b=Ag/RcumnrYpJHLIAZusCs6TD2AJa1lMh2OjfdNTpNB86fgizw1rveilun73h5M3LYQ 4XJzp3JoLWOKBxinb5BXxaMLIIlBs64LWAqEPjC1LRLwi+fxU2gzGYzr6RBNRfKy26Nc LjnxagVoi+2Vy2R/ghJgQBbXuE4kxCbVOSlPumxnIJmDcaXP6355qbYtdQB00Yn4s2tI ZI/mlhOfrzvXBCi7IR3SpirmncmeEfLFG55LnKujcHR9BK3cVFw4Ro5+eS9Fhk8DXqza /Ym55TQn4fdie5ic8CFquCch9XmFrCQ8T2o/ec9tsLdeqc7Pu3aX0ERAcCemMMdiRCJ+ TlRQ== X-Gm-Message-State: ALyK8tIR+csQUeQyO+19QFusZZC7u/oSL9UgHKBW5TvM0V03m4KITHMPUIN9lwmtXoeVBj/LlJHgbaB0ci2AMw== X-Received: by 10.25.167.6 with SMTP id q6mr2387807lfe.173.1465303855379; Tue, 07 Jun 2016 05:50:55 -0700 (PDT) MIME-Version: 1.0 Sender: rizzo.unipi@gmail.com Received: by 10.114.182.76 with HTTP; Tue, 7 Jun 2016 05:50:54 -0700 (PDT) In-Reply-To: <5756C17D.1090409@yandex.ru> References: <5756C17D.1090409@yandex.ru> From: Luigi Rizzo Date: Tue, 7 Jun 2016 14:50:54 +0200 X-Google-Sender-Auth: cKJNKAWpVtXBk84IMrbWG_uu754 Message-ID: Subject: Re: Is netmap jumbo frames broken in STABLE? To: "Andrey V. Elsukov" Cc: Andrew Vylegzhanin , "freebsd-net@freebsd.org" , Ryan Stone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 07 Jun 2016 12:50:57 -0000 On Tue, Jun 7, 2016 at 2:43 PM, Andrey V. Elsukov wrote= : > On 07.06.16 15:22, Andrew Vylegzhanin wrote: > > Just for support Luigi assumption. > > > > I've tested on 11.0-ALPHA1 (r301204). > > Same situation with frame size 5166 and works _well_ with frame size > 4032. > > This was changed in > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D283883 > > In the ixgbe_init_locked() initialization of adapter->rx_mbuf_sz was > limited to MJUMPAGESIZE. But I'm agree with Ryan, with this > configuration it works more reliable. > =E2=80=8BNothing prevents modifying the configuration while the card is in netmap mode, and reverting to the previous one in regular mode. netmap allocates its own buffers and if it fails the NIC just reverts back to regular mode. This said, we can make netmap work with multiple buffers also on NICs; it is already supported in VALE. Just makes the user code a bit less convenient. cheers luigi From owner-freebsd-net@freebsd.org Tue Jun 7 13:16:18 2016 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 D8920B6DF22 for ; Tue, 7 Jun 2016 13:16:18 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id AB1141BF1 for ; Tue, 7 Jun 2016 13:16:18 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 48C4C178C8; Tue, 7 Jun 2016 13:16:18 +0000 (UTC) Date: Tue, 7 Jun 2016 13:16:18 +0000 To: freebsd-net@freebsd.org From: "gallatin (Andrew Gallatin)" Reply-to: D6689+325+6c89ed8b7a9bc66d@reviews.freebsd.org Subject: [Differential] D6689: tcp/lro: Implement hash table for LRO entries. Message-ID: <63c56653ce25065655ada608a7d498f6@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , Thread-Topic: D6689: tcp/lro: Implement hash table for LRO entries. X-Herald-Rules: <64> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGRkYTdkZDNmZDVlODIxOWE3MGU3NDg3NmVjIFdWySI= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 13:16:19 -0000 gallatin accepted this revision. gallatin added a comment. Looks good in terms of not killing perf. for the sorted case, and I'm fine with it as-is. However, maybe an else would be better than a goto? REVISION DETAIL https://reviews.freebsd.org/D6689 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, rrs, glebius, gnn, bz, rwatson, #transport, hselasky, gallatin Cc: freebsd-net-list From owner-freebsd-net@freebsd.org Wed Jun 8 01:25:43 2016 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 6E123B6FCD7 for ; Wed, 8 Jun 2016 01:25:43 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 396C3173F for ; Wed, 8 Jun 2016 01:25:43 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id D3B1317F42; Wed, 8 Jun 2016 01:25:42 +0000 (UTC) Date: Wed, 8 Jun 2016 01:25:42 +0000 To: freebsd-net@freebsd.org From: "sepherosa_gmail.com (Sepherosa Ziehau)" Reply-to: D6689+325+6c89ed8b7a9bc66d@reviews.freebsd.org Subject: [Differential] D6689: tcp/lro: Implement hash table for LRO entries. Message-ID: <4897e404e91ca8ff9cf04a6e55432783@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D6689: tcp/lro: Implement hash table for LRO entries. X-Herald-Rules: <64> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGRkYTdkZDNmZDVlODIxOWE3MGU3NDg3NmVjIFdXdBY= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 01:25:43 -0000 sepherosa_gmail.com added a comment. In https://reviews.freebsd.org/D6689#142118, @gallatin wrote: > Looks good in terms of not killing perf. for the sorted case, and I'm fine with it as-is. However, maybe an else would be better than a goto? Yeah, sure, I can move the bucket assignment into the {}, and use if-elseif-else to avoid goto. And as for performance, I am running the test using hash table currently. The result of nginx+wrk test is quite promising (web object sizes range from 1KB~40KB; for 4reqs/conn, 4~10K concurrent connection, I am getting 12%~14% performance improvement :). 14reqs/conn nginx+wrk test is still running. REVISION DETAIL https://reviews.freebsd.org/D6689 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, rrs, glebius, gnn, bz, rwatson, #transport, hselasky, gallatin Cc: freebsd-net-list From owner-freebsd-net@freebsd.org Wed Jun 8 09:47:27 2016 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 8EE98B6FA5E for ; Wed, 8 Jun 2016 09:47:27 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 17AB11383 for ; Wed, 8 Jun 2016 09:47:25 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 6971137615D2 for ; Wed, 8 Jun 2016 11:44:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 5D2BF376146E for ; Wed, 8 Jun 2016 11:44:36 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id P-bBuPiMDm2X for ; Wed, 8 Jun 2016 11:44:36 +0200 (CEST) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 4A53A3760A0C for ; Wed, 8 Jun 2016 11:44:36 +0200 (CEST) Date: Wed, 8 Jun 2016 11:44:36 +0200 (CEST) From: Arnaud YSMAL To: freebsd-net@freebsd.org Message-ID: <494678734.3111275.1465379076220.JavaMail.zimbra@stormshield.eu> Subject: [Patch] Changing mac address does not always work MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3111273_1322850569.1465379076220" Thread-Topic: Changing mac address does not always work Thread-Index: coolACGmaTpePzd5iJZlToyt6Bs85w== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 09:47:27 -0000 ------=_Part_3111273_1322850569.1465379076220 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Configuring the network card with the following commands (in this specific order) does not work. # ifconfig em0 down # ifconfig em0 mtu 1500 # ifconfig em0 ether 12:34:56:12:34:56 # ifconfig em0 192.168.1.1/24 # ifconfig em0 up I was able to reproduce this issue on 10.3-RELEASE and HEAD with ix and em drivers. >From what I understand: - When setting the mtu, the driver calls the init of the interface which sets the IFF_DRV_RUNNING flag - When setting the mac address, if_setlladdr (from if.c) copy the mac address but does nothing else (the interface is not up) - When setting the ip address, the driver does not call the init as the IFF_DRV_RUNNING is already set. - When setting the up flag, same as above, the IFF_DRV_RUNNING is already set. In this case the network card does not work as the mac address filter is not up to date. The enclosed path fixes this issue, It changes if_setlladdr in if.c to call the ifp->if_ioctl function with the IFF_UP flag clear even when the interface is not up. The driver will then call its stop function which clear the IFF_DRV_RUNNING. The init will be called when setting the ip address or the up flag. Do you have any advice regarding this patch? Arnaud ------=_Part_3111273_1322850569.1465379076220 Content-Type: text/x-patch; name=down_iface.patch Content-Disposition: attachment; filename=down_iface.patch Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBzeXMvbmV0L2lmLmMgc3lzL25ldC9pZi5jCmluZGV4IDRkNDc1ZDkuLjI1MTU5 MjcgMTAwNjQ0Ci0tLSBzeXMvbmV0L2lmLmMKKysrIHN5cy9uZXQvaWYuYwpAQCAtMzM5NCw2ICsz Mzk0LDcgQEAgaWZfc2V0bGxhZGRyKHN0cnVjdCBpZm5ldCAqaWZwLCBjb25zdCB1X2NoYXIgKmxs YWRkciwgaW50IGxlbikKIAlzdHJ1Y3Qgc29ja2FkZHJfZGwgKnNkbDsKIAlzdHJ1Y3QgaWZhZGRy ICppZmE7CiAJc3RydWN0IGlmcmVxIGlmcjsKKwlpbnQgaXNfdXA7CiAKIAlJRl9BRERSX1JMT0NL KGlmcCk7CiAJaWZhID0gaWZwLT5pZl9hZGRyOwpAQCAtMzQzMSwxNiArMzQzMiwxNyBAQCBpZl9z ZXRsbGFkZHIoc3RydWN0IGlmbmV0ICppZnAsIGNvbnN0IHVfY2hhciAqbGxhZGRyLCBpbnQgbGVu KQogCX0KIAogCS8qCi0JICogSWYgdGhlIGludGVyZmFjZSBpcyBhbHJlYWR5IHVwLCB3ZSBuZWVk CisJICogSWYgdGhlIGludGVyZmFjZSBpcyBhbHJlYWR5IHVwIG9yIGluaXRlZCwgd2UgbmVlZAog CSAqIHRvIHJlLWluaXQgaXQgaW4gb3JkZXIgdG8gcmVwcm9ncmFtIGl0cwogCSAqIGFkZHJlc3Mg ZmlsdGVyLgogCSAqLwotCWlmICgoaWZwLT5pZl9mbGFncyAmIElGRl9VUCkgIT0gMCkgewotCQlp ZiAoaWZwLT5pZl9pb2N0bCkgewotCQkJaWZwLT5pZl9mbGFncyAmPSB+SUZGX1VQOwotCQkJaWZy Lmlmcl9mbGFncyA9IGlmcC0+aWZfZmxhZ3MgJiAweGZmZmY7Ci0JCQlpZnIuaWZyX2ZsYWdzaGln aCA9IGlmcC0+aWZfZmxhZ3MgPj4gMTY7Ci0JCQkoKmlmcC0+aWZfaW9jdGwpKGlmcCwgU0lPQ1NJ RkZMQUdTLCAoY2FkZHJfdCkmaWZyKTsKKwlpc191cCA9IGlmcC0+aWZfZmxhZ3MgJiBJRkZfVVA7 CisJaWYgKGlmcC0+aWZfaW9jdGwpIHsKKwkJaWZwLT5pZl9mbGFncyAmPSB+SUZGX1VQOworCQlp ZnIuaWZyX2ZsYWdzID0gaWZwLT5pZl9mbGFncyAmIDB4ZmZmZjsKKwkJaWZyLmlmcl9mbGFnc2hp Z2ggPSBpZnAtPmlmX2ZsYWdzID4+IDE2OworCQkoKmlmcC0+aWZfaW9jdGwpKGlmcCwgU0lPQ1NJ RkZMQUdTLCAoY2FkZHJfdCkmaWZyKTsKKwkJaWYgKGlzX3VwKSB7CiAJCQlpZnAtPmlmX2ZsYWdz IHw9IElGRl9VUDsKIAkJCWlmci5pZnJfZmxhZ3MgPSBpZnAtPmlmX2ZsYWdzICYgMHhmZmZmOwog CQkJaWZyLmlmcl9mbGFnc2hpZ2ggPSBpZnAtPmlmX2ZsYWdzID4+IDE2Owo= ------=_Part_3111273_1322850569.1465379076220-- From owner-freebsd-net@freebsd.org Wed Jun 8 10:43:32 2016 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 E5D0FB6FAAD; Wed, 8 Jun 2016 10:43:32 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 453EF1B1C; Wed, 8 Jun 2016 10:43:32 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (pc846408.norma.com [IPv6:fd00::73d] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id u58AhR55024539 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2016 15:43:28 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1465382609; bh=UxHrrexhPG3Bdz7REQ2ENRhK/MRSTg8WvFItPi/zFLQ=; h=To:Cc:From:Subject:Date; b=c2a+D+dv3X+PDhkML6rD3yW9+NBLSOAfAi9ekGGyrqPY9HQHEXqQl9fXh37yqaPOC K3VKoa63hm6UwtoaxXjVTvaBE4JIdCXJfsqjDNWkwG+WEZ3urJAuqn1UemUUY0JHgO zDIIibTPyt89nXkdq+RtUO1HgkjioJ8NLDp8IoBk= To: stable@freebsd.org Cc: freebsd-net@freebsd.org From: "Eugene M. Zheganin" Subject: cannot delete on-interface route in FIB Message-ID: <5757F6CF.7070807@norma.perm.ru> Date: Wed, 8 Jun 2016 15:43:27 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 10:43:33 -0000 Hi. (first part of the message is describing why I need this, so impatient people can proceed to th 'setfib 2 route delete' part directly). I have a FreeBSD router connected to the ISP network, which is organized according to the rfc3069 (you know, when all of the clients think they have /24. but in reality they have /32 and a central router is proxy-arping requests). This router is handling two organizations LANs, and it has two Internet links connected, I'm using FIB 0 for the first organization, and FIB 2 for second. To be specific: 46.146.220.88/24 - main router IP, gateway is 46.146.220.254, interface vlan2 46.146.206.94/24 - second router IP, gateway is 46.146.206.254, interface vlan4 Both 46.146.220.24 and .206.254 are the same ISP router. I also have the application server on IP 46.146.220.92, which FIB 0 thinks is on-interface. Now the tricky part: When FIB 0 need to communicate with 46.146.220.92, it does so from it's address 46.146.220.88, since it thinks it's directly reachable. But when requesting MAC from 46.146.220.88 it receives the ISP router MAC, so it does so via ISP router. This part is fine. Now the troubled part: When FIB 2 needs to communicate with 46.146.220.92, it thinks.... yeah, that it's directly reachable from vlan2. When it initiates the session, it takes 46.146.220.88 as source interface and everything is fine (again). But when the client in the LAN initiates the exchange, the packet IP src is translated to the 46.146.206.94 address, and the route still points to the vlan2 interface. So, network stack sends the packet with IP src of 46.146.206.94 via vlan2, and the ISP router seems to dislike such packets. Two workarounds come to mind: - translating the packets from internal LAN destined to specific address of 46.146.220.92 to appropriate address of vlan2 - deleting the on-interface route from FIB 2. I have chosen the second (more obvious to me) but then I discovered that I cannot do this: # setfib 2 route delete 46.146.220.0/24 route: writing to routing socket: Address already in use delete net 46.146.220.0 fib 2: gateway uses the same route why ? Finally I added the host route to 46.146.220.92 in FIB 2 pointing to the appropriate (46.146.206.254) gateway and got my connectivity, but I still don't understand why the deletion of on-interface route is impossible. After all, it's the second FIB, and I don;t understand whet gateway the error is talking about. I tried this without having the default gateway in FIB 2, same result. Thanks. Eugene. From owner-freebsd-net@freebsd.org Wed Jun 8 11:25:24 2016 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 5DB69B6F7D2 for ; Wed, 8 Jun 2016 11:25:24 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 2462A1348 for ; Wed, 8 Jun 2016 11:25:23 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.36] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id 07ABF9DF321 for ; Wed, 8 Jun 2016 13:25:15 +0200 (CEST) From: Borja Marcos Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Problem with ixgbe and lagg Message-Id: <57007695-E755-4B7C-97E2-6B0F3258E769@sarenet.es> Date: Wed, 8 Jun 2016 13:25:14 +0200 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 11:25:24 -0000 Hello, I am unable to set up a LACP based interface with lagg and a two ports = Intel 10 GbE card.=20 When not using lagg, the interfaces work. However, an ifconfig shows = that media is not properly detected. ix2: flags=3D8843 metric 0 mtu = 1500 = options=3De407bb ether 0c:c4:7a:bd:70:26 inet 10.0.5.109 netmask 0xffffff00 broadcast 10.0.5.255=20 nd6 options=3D29 media: Ethernet autoselect (Unknown ) status: active I am using copper SFP+ cables, and just in case I have tried two = different ones: one from Brocade and another one from Prolabs. The PCI identifiers are: % pciconf -lv pci0:130:0:0 ix2@pci0:130:0:0: class=3D0x020000 card=3D0x061115d9 = chip=3D0x10fb8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet % pciconf -lv pci0:130:0:1 ix3@pci0:130:0:1: class=3D0x020000 card=3D0x061115d9 = chip=3D0x10fb8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82599ES 10-Gigabit SFI/SFP+ Network Connection' class =3D network subclass =3D ethernet When plugging the Brocade SFP I get the following message: ix2: Detected phy_type 13 And creating the lagg interface in debug mode I see this: Jun 8 13:16:44 e1 kernel: lagg0: link state changed to UP Jun 8 13:16:44 e1 kernel: ix2: media changed 0x0 -> 0x639, ether =3D 1, = fdx =3D 0, link =3D 1 Jun 8 13:16:44 e1 kernel: ix2: partner timeout changed Jun 8 13:16:44 e1 kernel: ix2: -> UNSELECTED Jun 8 13:16:44 e1 kernel: ix3: media changed 0x0 -> 0x639, ether =3D 1, = fdx =3D 0, link =3D 1 Jun 8 13:16:44 e1 devd: Executing '/etc/rc.d/dhclient quietstart lagg0' Jun 8 13:16:44 e1 kernel: ix3: partner timeout changed Jun 8 13:16:44 e1 kernel: ix3: -> UNSELECTED Jun 8 13:16:44 e1 kernel: ix3: media changed 0x639 -> 0x20, ether =3D = 1, fdx =3D 0, link =3D 0 Jun 8 13:16:44 e1 kernel: ix3: link state changed to DOWN Jun 8 13:16:46 e1 kernel: ix3: media changed 0x20 -> 0x639, ether =3D = 1, fdx =3D 0, link =3D 1 Jun 8 13:16:46 e1 kernel: ix3: link state changed to UP Jun 8 13:16:46 e1 devd: Executing '/etc/rc.d/dhclient quietstart ix3=E2=80= =99 Any ideas? Maybe lagg is confused because it can=E2=80=99t detect the = interface speed? Thanks! Borja. From owner-freebsd-net@freebsd.org Wed Jun 8 11:36:18 2016 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 BB4AAB6F991 for ; Wed, 8 Jun 2016 11:36:18 +0000 (UTC) (envelope-from tom.barbette@ulg.ac.be) Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74A8D19C4 for ; Wed, 8 Jun 2016 11:36:18 +0000 (UTC) (envelope-from tom.barbette@ulg.ac.be) Received: from mbx12-zne.ulg.ac.be (serv470.segi.ulg.ac.be [139.165.32.199]) by serv108.segi.ulg.ac.be (Postfix) with ESMTP id 51E82200E7CC; Wed, 8 Jun 2016 13:28:29 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id 4547A129E986; Wed, 8 Jun 2016 13:28:29 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be ([127.0.0.1]) by localhost (mbx12-zne.ulg.ac.be [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SoX_LZALAPFw; Wed, 8 Jun 2016 13:28:29 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be (mbx12-zne.ulg.ac.be [139.165.32.199]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id 25B5A129E984; Wed, 8 Jun 2016 13:28:29 +0200 (CEST) Date: Wed, 8 Jun 2016 13:28:28 +0200 (CEST) From: tom.barbette@ulg.ac.be To: Luigi Rizzo Cc: "Andrey V. Elsukov" , Andrew Vylegzhanin , freebsd-net@freebsd.org, Ryan Stone Message-ID: <1502708678.10983095.1465385308094.JavaMail.zimbra@ulg.ac.be> In-Reply-To: References: <5756C17D.1090409@yandex.ru> Subject: Re: Is netmap jumbo frames broken in STABLE? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [139.165.223.24] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - GC51 (Linux)/8.0.9_GA_6191) Thread-Topic: Is netmap jumbo frames broken in STABLE? Thread-Index: mYO94Fsj3opgFDUS0sB36D60uFgEEA== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 11:36:18 -0000 Support for fragmented packets with ixgbe was recently added on the linux version of Netmap : https://github.com/luigirizzo/netmap/commit/fc1e77560a8a8ea93cc3594de5fae94334debcd3 I think the change for freebsd would be quite the same looking at https://github.com/freebsd/freebsd/blob/master/sys/dev/netmap/ixgbe_netmap.h#L396 After that, your userspace application simply have to check for the NS_MOREFRAG flag in the receive ring, and if it's set he knows the end of the packet will follow in the next buf. Tom From owner-freebsd-net@freebsd.org Wed Jun 8 11:42:28 2016 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 B2944B6FB4F for ; Wed, 8 Jun 2016 11:42:28 +0000 (UTC) (envelope-from des@des.no) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A47FA1E23 for ; Wed, 8 Jun 2016 11:42:28 +0000 (UTC) (envelope-from des@des.no) Received: by mailman.ysv.freebsd.org (Postfix) id A3D5FB6FB4D; Wed, 8 Jun 2016 11:42:28 +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 A3788B6FB4C for ; Wed, 8 Jun 2016 11:42:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 71BC71E22 for ; Wed, 8 Jun 2016 11:42:28 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id E58D56237 for ; Wed, 8 Jun 2016 11:42:26 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 3C503623D4; Wed, 8 Jun 2016 13:42:28 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: net@freebsd.org Subject: Locking issues in CARP in 10.2 Date: Wed, 08 Jun 2016 13:42:27 +0200 Message-ID: <86y46frjoc.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 11:42:28 -0000 I have two routers which have been unstable ever since I upgraded them from 10.1 to 10.2. The symptoms were mostly livelocks, where the machine doesn't freeze completely but is unusable (network is down, console doesn't refresh, it seems to react to keyboard input and tries but fails to shut down when I press Ctrl+Alt+Del) I suspected that it was related to CARP, because it never happened if the router was taken out of the group (i.e. not just in BACKUP state, but no CARP addresses configured at all), and although I could not confirm this 100%, it seemed to be triggered by adding or removing an address to an interface. VLAN interfaces on these routers are created, destroyed and modified dynamically based on data from the provisioning system, so it's difficult to pinpoint. However, earlier today, one of the routers panicked right as I was taking it offline. I assume that it was triggered by one of two things which happened almost simultaneously: first, the CARP address had been configured on another router, possibly triggering a state change, and second, I manually deleted the CARP address from the router that crashed. Crash dumps were not enabled, but it looks like the instruction pointer was in __mtx_lock_sleep(), around line 438 in sys/kern/kern_mutex.c: 435 v =3D m->mtx_lock; 436 if (v !=3D MTX_UNOWNED) { 437 owner =3D (struct thread *)(v & ~MTX_FLAGMASK); 438 if (TD_IS_RUNNING(owner)) { 439 if (LOCK_LOG_TEST(&m->lock_object, 0)) 440 CTR3(KTR_LOCK, 441 "%s: spinning on %p held by %p", Is this a known issue? If not, has anyone else had similar problems, or does anyone know of locking issues in the CARP code which might trigger a livelock or panic when a CARP address is added or removed? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@freebsd.org Wed Jun 8 12:15:39 2016 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 BDBD4B6D9F7 for ; Wed, 8 Jun 2016 12:15:39 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 125F5116B; Wed, 8 Jun 2016 12:15:37 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 3C967376109B; Wed, 8 Jun 2016 14:12:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 2E7293761044; Wed, 8 Jun 2016 14:12:49 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Txx0IEMw6wMn; Wed, 8 Jun 2016 14:12:49 +0200 (CEST) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 1B89A3760915; Wed, 8 Jun 2016 14:12:49 +0200 (CEST) Date: Wed, 8 Jun 2016 14:12:48 +0200 (CEST) From: Emeric POUPON To: FreeBSD Net Cc: gnn@freebsd.org, jmg@freebsd.org Message-ID: <2079286727.3163127.1465387968941.JavaMail.zimbra@stormshield.eu> Subject: IPSec and large replay window support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Thread-Topic: IPSec and large replay window support Thread-Index: JYX/hDepe//Gsk4+yyl2x1mL618CJw== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 12:15:39 -0000 Hello, We plan to support large replay windows in the IPsec stack. Currently, the replay window size is limited due to the size of the field used in the sadb_sa_replay structure. https://www.ietf.org/rfc/rfc2367.txt : struct sadb_sa { uint16_t sadb_sa_len; uint16_t sadb_sa_exttype; uint32_t sadb_sa_spi; uint8_t sadb_sa_replay; uint8_t sadb_sa_state; uint8_t sadb_sa_auth; uint8_t sadb_sa_encrypt; uint32_t sadb_sa_flags; }; => max is 255*8 = 2040 packets wide. Some time ago we already patched our kernel in order to use a 16bits field. This does the job but we are facing two problems: - the current algorithm is inefficient with large window sizes (bit shifting). - we are still limited in size (65535*8 = 524280 packets) Here are the ideas: - implement RFC 6479 : https://tools.ietf.org/html/rfc6479 - replace the 8bit field with a 32bits field I am not very comfortable with the idea to change a field that is described in the RFC 2367. Is there any other acceptable solution? Adding a new extension? What do you think ? Emeric From owner-freebsd-net@freebsd.org Wed Jun 8 12:17:24 2016 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 62233B6DA92 for ; Wed, 8 Jun 2016 12:17:24 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 3FB8F1269 for ; Wed, 8 Jun 2016 12:17:24 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id A9AB917DDA; Wed, 8 Jun 2016 12:17:23 +0000 (UTC) Date: Wed, 8 Jun 2016 12:17:23 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Reply-to: D6689+325+6c89ed8b7a9bc66d@reviews.freebsd.org Subject: [Differential] D6689: tcp/lro: Implement hash table for LRO entries. Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D6689: tcp/lro: Implement hash table for LRO entries. X-Herald-Rules: <64> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGRkYTdkZDNmZDVlODIxOWE3MGU3NDg3NmVjIFdYDNM= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:17:24 -0000 hselasky added a comment. Hi, Were you able to test the performance using tcp_lro_queue_mbuf() ? Better name for function?? tcp_lro_rx2() -> tcp_lro_rx_sub() --HPS REVISION DETAIL https://reviews.freebsd.org/D6689 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, rrs, glebius, gnn, bz, rwatson, #transport, hselasky, gallatin Cc: freebsd-net-list From owner-freebsd-net@freebsd.org Wed Jun 8 12:43:16 2016 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 174B4B6E2AA; Wed, 8 Jun 2016 12:43:16 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [84.22.110.84]) by mx1.freebsd.org (Postfix) with ESMTP id DBB5D10DB; Wed, 8 Jun 2016 12:43:15 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id ABFBE387E10; Wed, 8 Jun 2016 14:43:10 +0200 (CEST) Date: Wed, 8 Jun 2016 14:43:10 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Getting CARP to broadcast on a different interface Message-ID: <20160608124310.GG2050@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Yb+qhiCg54lqZFXW" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 12:43:16 -0000 --Yb+qhiCg54lqZFXW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, is it possible to configure CARP in such a way that it sends its broadcasts on an interface different from the one that gets the shared IP address assigned? Unfortunately, my provider blocks broadcast and multicast on public interfaces of virtual machines. However, they offer to set up an additional virtual NIC that directly connects multiple virtual machines on which broadcast and multicast are not blocked. So, while I assign a shared IP to the public interface vtnet0, I would like to configure CARP to broadcast on the private interface vtnet1. Is that possible? Or are there alternatives for CARP that support this function? Niklaas --Yb+qhiCg54lqZFXW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWBLSAAoJEG2fODeJrIU/OawP/1FOLu14sNJWJwON1RQCvL6N 0Em7tdAH/dSa9Bev7m/lPG69IcG2LfRba/pPp1HQqpe6O1bNRRVj/oNF6Cgsv9lt JZAj3N8UsaSYnJx05T4YxBomzki8/gdPrUekyzE1PG8Y85UqZQXdipObRPhlyV/k kbE22NYs3mh4UbIyCO/Fno8NWo7d5KXfL2UJpzhofCv8zV0l4mG4Co6a7FOdwUsw tojVJlRZ3jcSRk9K7cJxdx9Q7v04s2Bj2i61odZCEhrbacwPUqjweghgMHipvXTl 5eEZdaU90drCBN19+StToXGSmpttJzNDGjBk0rCTbzFCNFPv/vcboH8Zhpv24yRp iLbUA7t+iIw8l6ys0+lSmINL16+bPv+sbi3YnvfRGMQkd6KhSzKzITRYg9LGXjKs xzQiG8iw+94K2XLZat7NmbOBIvyKSDqBNJiHqjUBlJ1S0mbDagFXS2NC4LZGy6Hl yza8EYHpcI9H/Rg4SFcNB8AQkD8oZxcd9v3wYEsZ4JADgDu+gGsHznLhx7NPAk+7 VANM5fPavVmJfwzZMAZ4xq56qk2sPNrMeCxk+XfHyYQRSjxt30+OJjf+vCytVzrg hQqAVBL0YzCatDKRCRxd4RnN2pL1CxvYQYBY2hVSrjmkJygUjpT9guBsifGPIP/p gP7Qtz95FKXs4xtlbhNb =Wba3 -----END PGP SIGNATURE----- --Yb+qhiCg54lqZFXW-- From owner-freebsd-net@freebsd.org Wed Jun 8 13:29:08 2016 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 77CA0B6F5B9 for ; Wed, 8 Jun 2016 13:29:08 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 542AC17A6 for ; Wed, 8 Jun 2016 13:29:08 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id E3C61179BD; Wed, 8 Jun 2016 13:29:07 +0000 (UTC) Date: Wed, 8 Jun 2016 13:29:07 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Reply-to: D6689+325+6c89ed8b7a9bc66d@reviews.freebsd.org Subject: [Differential] D6689: tcp/lro: Implement hash table for LRO entries. Message-ID: <710b7d6aed22aaab0af38f4cc08b29a6@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: Thread-Topic: D6689: tcp/lro: Implement hash table for LRO entries. X-Herald-Rules: <64> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: ZGRkYTdkZDNmZDVlODIxOWE3MGU3NDg3NmVjIFdYHaM= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:29:08 -0000 hselasky added a comment. @sepherosa_gmail.com Regarding performance. Is it possible to get the Hyper-V to sort the IP-packets before they enter the FreeBSD network stack in the VM? REVISION DETAIL https://reviews.freebsd.org/D6689 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, rrs, glebius, gnn, bz, rwatson, #transport, hselasky, gallatin Cc: freebsd-net-list From owner-freebsd-net@freebsd.org Wed Jun 8 13:54:09 2016 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 BA130B6E298; Wed, 8 Jun 2016 13:54:09 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 37F01174C; Wed, 8 Jun 2016 13:54:09 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id u58DrwkN003789 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Jun 2016 15:53:58 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id u58DrvPT003786; Wed, 8 Jun 2016 15:53:57 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 8 Jun 2016 15:53:57 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: Niklaas Baudet von Gersdorff cc: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Re: Getting CARP to broadcast on a different interface In-Reply-To: <20160608124310.GG2050@box-hlm-03.niklaas.eu> Message-ID: References: <20160608124310.GG2050@box-hlm-03.niklaas.eu> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, AWL autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 13:54:09 -0000 On Wed, 8 Jun 2016 14:43+0200, Niklaas Baudet von Gersdorff wrote: > Hello, > > is it possible to configure CARP in such a way that it sends its > broadcasts on an interface different from the one that gets the shared > IP address assigned? Unfortunately, my provider blocks broadcast and > multicast on public interfaces of virtual machines. > > However, they offer to set up an additional virtual NIC that directly > connects multiple virtual machines on which broadcast and multicast are > not blocked. So, while I assign a shared IP to the public interface > vtnet0, I would like to configure CARP to broadcast on the private > interface vtnet1. > > Is that possible? Or are there alternatives for CARP that support this > function? Although it sounds pretty bad, you could set up CARP on the internal network and use those CARP events to control the main interfaces, e.g. re-adjust their annoncement intervals, or something equally awful. You might end up locked out of your systems unless you can control them remotely using a third set of means, e.g. RDP. Just a quick thought that popped up in my head. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-net@freebsd.org Wed Jun 8 14:37:46 2016 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 8518DB6F85D; Wed, 8 Jun 2016 14:37:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51D121D49; Wed, 8 Jun 2016 14:37:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id s139so15670434oie.2; Wed, 08 Jun 2016 07:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kx8024szjNrS7tCJ4/F+vrEEUPc/ClJvq2uXaP8PDZI=; b=XQGO3rCoupJdh2O5Ebc4/xQQvFG4SjaTwrSzGA8y57PQoFe8I2eeTMTSPJgxzQEp5i FauNKw8ThgzvQnkuBIvUxA7aRbJ3irKmJoBdx/uPDFB8KlhQexNMDgmXX0eBXC1sZxA5 rvKVge7tnK8ZfWDkGyd3IhPKAMOIGcoJFbszDMiNMYQzvkDFuvVWjn3COEa0nO3np5Kc jvSe+eqoiMewRaNDBagt1IGD9Xz7ECsU3hlqPDOiXCN4XeMJN61P0n5SAvaRxWvIG0cH 6N2hyRa0T36eNuxYK2dYXDFd9tMQRg0Qd/zt66h09PNQJcbyaw9tTSnWgXfh78yHmU5y OhQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kx8024szjNrS7tCJ4/F+vrEEUPc/ClJvq2uXaP8PDZI=; b=a8G5oA2CatO4ijk6/BGhQUha2V3WWhR1WZICi0t+Ju73/2hvyvliXkXy/i9qWAXvg/ jDo/kRk/zmJGJmzvnJtfTWBtgC16cEd5FMlCQ1ZFXGG/Lf1vqI2weporncl5EJynTtvp foB/CBeV/7nnRSKOQKab1Ch0RfMHOkkIEk3nrs8Z+QpG9KJgRdafTAtbN6LWmNEkpRz4 GZPC8CdqhNqHsLWBWLQ9VFTC5aIXi60AM7zlGIMFJkmFEne5fNxcjgeFwZNnlskVdc28 H62cQQzg10oCGUJ4OXydJS+DE1OvwLUHLPYjaWM1qaBfRBbUtcxny8FlvuUVd4NSBsXa cC9Q== X-Gm-Message-State: ALyK8tLIRPAgt/GCcCYqOkqriCAINwhJCekiuB0EohRKMnPafAdXVY3bO6eeZJZJKUsGk9kCaOK+d+gg21BmCg== X-Received: by 10.202.86.82 with SMTP id k79mr3192755oib.105.1465396665299; Wed, 08 Jun 2016 07:37:45 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.4.200 with HTTP; Wed, 8 Jun 2016 07:37:44 -0700 (PDT) In-Reply-To: <5757F6CF.7070807@norma.perm.ru> References: <5757F6CF.7070807@norma.perm.ru> From: Alan Somers Date: Wed, 8 Jun 2016 08:37:44 -0600 X-Google-Sender-Auth: g00HKOfA7lKA_G3yfG2GSuLrJbQ Message-ID: Subject: Re: cannot delete on-interface route in FIB To: "Eugene M. Zheganin" Cc: FreeBSD Stable ML , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 14:37:46 -0000 On Wed, Jun 8, 2016 at 4:43 AM, Eugene M. Zheganin wrote: > Hi. > > (first part of the message is describing why I need this, so impatient > people can proceed to th 'setfib 2 route delete' part directly). > > I have a FreeBSD router connected to the ISP network, which is organized > according to the rfc3069 (you know, when all of the clients think they > have /24. but in reality they have /32 and a central router is > proxy-arping requests). This router is handling two organizations LANs, > and it has two Internet links connected, I'm using FIB 0 for the first > organization, and FIB 2 for second. To be specific: > > 46.146.220.88/24 - main router IP, gateway is 46.146.220.254, interface > vlan2 > 46.146.206.94/24 - second router IP, gateway is 46.146.206.254, > interface vlan4 > > Both 46.146.220.24 and .206.254 are the same ISP router. > > I also have the application server on IP 46.146.220.92, which FIB 0 > thinks is on-interface. Now the tricky part: > > When FIB 0 need to communicate with 46.146.220.92, it does so from it's > address 46.146.220.88, since it thinks it's directly reachable. But when > requesting MAC from 46.146.220.88 it receives the ISP router MAC, so it > does so via ISP router. This part is fine. > > Now the troubled part: > > When FIB 2 needs to communicate with 46.146.220.92, it thinks.... yeah, > that it's directly reachable from vlan2. When it initiates the session, > it takes 46.146.220.88 as source interface and everything is fine > (again). But when the client in the LAN initiates the exchange, the > packet IP src is translated to the 46.146.206.94 address, and the route > still points to the vlan2 interface. So, network stack sends the packet > with IP src of 46.146.206.94 via vlan2, and the ISP router seems to > dislike such packets. Two workarounds come to mind: > > - translating the packets from internal LAN destined to specific address > of 46.146.220.92 to appropriate address of vlan2 > - deleting the on-interface route from FIB 2. > > I have chosen the second (more obvious to me) but then I discovered that > I cannot do this: > > # setfib 2 route delete 46.146.220.0/24 > route: writing to routing socket: Address already in use > delete net 46.146.220.0 fib 2: gateway uses the same route > > why ? > > Finally I added the host route to 46.146.220.92 in FIB 2 pointing to the > appropriate (46.146.206.254) gateway and got my connectivity, but I > still don't understand why the deletion of on-interface route is > impossible. After all, it's the second FIB, and I don;t understand whet > gateway the error is talking about. I tried this without having the > default gateway in FIB 2, same result. > > Thanks. > Eugene. What is the value of "sysctl net.add_addr_allfibs"? In your case, it sounds like you want to set it to 0. From owner-freebsd-net@freebsd.org Wed Jun 8 14:56:26 2016 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 99BA9B6FE32; Wed, 8 Jun 2016 14:56:26 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [IPv6:2a02:2770:15:0:21a:4aff:feaa:e902]) by mx1.freebsd.org (Postfix) with ESMTP id 66B961C33; Wed, 8 Jun 2016 14:56:26 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id CA14838841C; Wed, 8 Jun 2016 16:56:22 +0200 (CEST) Date: Wed, 8 Jun 2016 16:56:22 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Re: Getting CARP to broadcast on a different interface Message-ID: <20160608145622.GA8540@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org References: <20160608124310.GG2050@box-hlm-03.niklaas.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 14:56:26 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Trond Endrest=F8l [2016-06-08 15:53 +0200] : > Although it sounds pretty bad, you could set up CARP on the internal=20 > network and use those CARP events to control the main interfaces, e.g.=20 > re-adjust their annoncement intervals, or something equally awful. Thanks, Trond. As you said, not that it sounds like a good idea but it's a solution I will think about. What also came up in my head: Can't I re-reroute the CARP packets with pf somehow? Niklaas --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWDIPAAoJEG2fODeJrIU/Nk4P/j5EIDtSma9q5mj/jKsoEuK+ juCFmLkJlZf0fTEbB89eW+c2EF+2Ce6qu7eF9tf0fI9jC/Flsl+ZZxmgjNr93mE5 MbMbDT7GeAeA7v1UPp2Cxow+D1ziQsbtYLpOLyZKOepdzU++v9NNKrPyzCKqe21q g38LFHfE+gJwxI7UWRRe2rmekNQFkG+eDaFYpR8K0poauyFzd0827Uk1zDS9RlaM zdIueeZGf+1YCQP1f025AN/SeQYoMrOmRxPQfrR00E+8ma3s0uH0TUxgfrkH+uwI Gex3u/fX6fMaessGX1wG1KN8dgrfGwJOzTOHtW4p0h7j3RzrTFh/Y8B4YCmPFjr+ a5t355/RwaWvMn/7XTimIHxvdNu5bppE4EcMGclAZAKurmYQbplHdon8q9VUaUsA rzcOPRayrqSgOxdZASR4YXN3MbKnHZ7BpnGSgdoIRZi0AOJgGVCextUgkyK87Pil sdwzONVUEvTuaBr+KgvmogLuMu/3vcp+mWVQ5j0pHOkDj5CxQbGlNM//yB54MLZY /d9sy/xYTuzAzDnfCHtg0Q1MCHKeJQxPyn5vQhhqk5+mt9C0+VJEo7nS4hGa57Dg sgxc491vr8RJLkCTO35CC+0aKpVRI9+0VOrr4jj15EGM8VTfEaWYYWYL2edtRKbl bHgvd6JlAM8qeE0lOUzx =LS8j -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-net@freebsd.org Wed Jun 8 15:30:40 2016 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 5031BB6F70F; Wed, 8 Jun 2016 15:30:40 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0061.outbound.protection.outlook.com [157.56.110.61]) (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 D33E211A6; Wed, 8 Jun 2016 15:30:38 +0000 (UTC) (envelope-from ddesimone@verio.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verioit.onmicrosoft.com; s=selector1-verio-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IfL1Tl5s9LAQGuvgibdJJ0XfBmRZBJjNRFh06NLldBc=; b=aj+syewHq0S1jtCge15SgbEG9b1NRmBFFyTHNZ/dYBL1ZIOP+3P5tTm/cI3zuJ6Ypu4fi0F/mjD9DRVk+WatFSqGdAHjo1UeWWqeuBoMLurjkk2Gjqo2aYV+Tj/9Mwk6h05Z1GDwtl0wEq4suqpDYyBihkVbYW0ZsReUMFcaQCQ= Received: from SN1PR08MB1821.namprd08.prod.outlook.com (10.162.134.27) by SN1PR08MB1821.namprd08.prod.outlook.com (10.162.134.27) with Microsoft SMTP Server (TLS) id 15.1.517.2; Wed, 8 Jun 2016 15:15:22 +0000 Received: from SN1PR08MB1821.namprd08.prod.outlook.com ([10.162.134.27]) by SN1PR08MB1821.namprd08.prod.outlook.com ([10.162.134.27]) with mapi id 15.01.0517.005; Wed, 8 Jun 2016 15:15:22 +0000 From: David DeSimone To: Niklaas Baudet von Gersdorff CC: "freebsd-questions@freebsd.org" , "freebsd-net@freebsd.org" Subject: RE: Getting CARP to broadcast on a different interface Thread-Topic: Getting CARP to broadcast on a different interface Thread-Index: AQHRwYNZsXrmscfLGkKU4PDC2t//vp/frM0w Date: Wed, 8 Jun 2016 15:15:22 +0000 Message-ID: References: <20160608124310.GG2050@box-hlm-03.niklaas.eu> In-Reply-To: <20160608124310.GG2050@box-hlm-03.niklaas.eu> 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=ddesimone@verio.net; x-originating-ip: [173.71.11.10] x-ms-office365-filtering-correlation-id: 6b32a0c4-d328-459f-7c01-08d38fafb615 x-microsoft-exchange-diagnostics: 1; SN1PR08MB1821; 6:44xdteabsbX9vJvz12UGWwnjYa9UL8ktL2a3Bh9nRKRrrfptRnFeSogCGRb+Oxph1v7pssMQOy6bw1jiSt8ocw9z2vHvtkjpU3pSD2/df2UqFB7LRG0QpugP20pcE3KOkL17/Us7Ue0Hz9zYCP07KF9qj000pUlH0nMyV1E/VGgDgeUciergDiFttldxlR/q5SkQ+6QviaUj4I9F3CUZgyvEgR2jZnkvdBzRm/UOQ24NdgaoFMUJfILxd1zV5J5qqstklgeiyKuAHDISr+tBPcwPC3PvCnHJJBgWtvfKPLI=; 5:p8kLow7cEtUTcVQCX0BPS4CSfVzcEsK2jgNnsjOjmrkIoCCG7QTzB/cIqGIcLjpAwE87HFN3s6wh6Q5UWr3WlbFyQMcXAJ9EW2FSYlKB4I5t1s0HW5L0B70Ff4Q5QaV6dnAeuF2T+3Y9/d3HWJo3dw==; 24:PRqV8BYs7epDC8HH2D2EtooxBywUBRnPbnKKP+B4427NY9yqapm00HhCHfnMzyrjrJZQPtem/w4f5sycAwzBCrTG18XjhNt50r+mqR7t5JE=; 7:Ici8UEhF9uBuTDBFK8ILMYMOQ430tdcMe+LPZcGdprF0lHwcls28vNjzKWx3f4EelKmukW9H7otmtxuIIy/i/M/LttIJhT7dpMPo4pUH0i8qeZeGyfbpZcTLTnSDyakwBUtZmS2Z/s6ZTvGfs625qjY/34dU8HAU5II/FUvEOY8bI7froZMOGY5IvmO3rNglsjhLCcrJACqkkXVufaWPh+R7LqpaGyNjKS5VDGal668= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR08MB1821; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR08MB1821; BCL:0; PCL:0; RULEID:; SRVR:SN1PR08MB1821; x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(377454003)(199003)(13464003)(99286002)(3846002)(77096005)(4326007)(68736007)(33656002)(10400500002)(8936002)(3660700001)(3280700002)(6116002)(586003)(102836003)(105586002)(106116001)(106356001)(92566002)(2950100001)(2900100001)(5890100001)(74316001)(76176999)(50986999)(8676002)(9686002)(5008740100001)(101416001)(86362001)(19580395003)(19580405001)(87936001)(189998001)(5004730100002)(66066001)(5002640100001)(54356999)(5003600100002)(2906002)(81166006)(122556002)(97736004)(81156014)(110136002)(76576001)(11100500001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR08MB1821; H:SN1PR08MB1821.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: verio.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: verio.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2016 15:15:22.3860 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 281c3918-264a-4db4-ab20-2dafa1dca324 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR08MB1821 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 15:30:40 -0000 One of the purposes of the CARP announcements is to announce the location o= f the virtual mac address to the upstream switch fabric. Since CARP uses a= virtual mac that floats between multiple ports, you need to have the CARP = master continually assert that its particular port is the target that shoul= d be used for delivery of packets to the virtual MAC address. Without this= function, switches might still mistakenly deliver their frames to the stan= dby node. The CARP announcements are also helpful in detecting and routing around som= e odd failure scenarios, such as a failure within the upstream fabric, wher= e the master sees link on its port, but can't actually send frames that rea= ch the rest of the network. If the standby can't hear the master's announc= ements any more, it can promote itself to master and hopefully keep your cl= uster online. This would not happen without the announcement feature. I would hope you could explain this to your provider and get them to white-= list CARP announcements because they are defeating important safety feature= s you wish to use. -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Niklaas Baudet von Gersdorff Sent: Wednesday, June 08, 2016 7:43 AM To: freebsd-questions@freebsd.org; freebsd-net@freebsd.org Subject: Getting CARP to broadcast on a different interface Hello, is it possible to configure CARP in such a way that it sends its broadcasts on an interface different from the one that gets the shared IP address assigned? Unfortunately, my provider blocks broadcast and multicast on public interfaces of virtual machines. However, they offer to set up an additional virtual NIC that directly connects multiple virtual machines on which broadcast and multicast are not blocked. So, while I assign a shared IP to the public interface vtnet0, I would like to configure CARP to broadcast on the private interface vtnet1. Is that possible? Or are there alternatives for CARP that support this function? Niklaas ________________________________ This email message is intended for the use of the person to whom it has bee= n sent, and may contain information that is confidential or legally protect= ed. If you are not the intended recipient or have received this message in = error, you are not authorized to copy, distribute, or otherwise use this me= ssage or its attachments. Please notify the sender immediately by return e-= mail and permanently delete this message and any attachments. makes no warr= anty that this email is error or virus free. Thank you. ________________________________ This email message is intended for the use of the person to whom it has bee= n sent, and may contain information that is confidential or legally protect= ed. If you are not the intended recipient or have received this message in = error, you are not authorized to copy, distribute, or otherwise use this me= ssage or its attachments. Please notify the sender immediately by return e-= mail and permanently delete this message and any attachments. NTT America m= akes no warranty that this email is error or virus free. Thank you. ________________________________ From owner-freebsd-net@freebsd.org Wed Jun 8 15:34:56 2016 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 DDE96B6F91B; Wed, 8 Jun 2016 15:34:56 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 549C31983; Wed, 8 Jun 2016 15:34:56 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from [192.168.243.2] ([192.168.243.2]) (authenticated bits=0) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPSA id u58FYqhs049168 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2016 20:34:53 +0500 (YEKT) (envelope-from emz@norma.perm.ru) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=norma.perm.ru; s=key; t=1465400093; bh=F8NHx4kf9SJSqevewiqrJTA/XvzS+l/vdetCfNC4bUs=; h=Subject:References:Cc:To:From:Date:In-Reply-To; b=iVgJBRk81/yK1XfdnJaJ0Pv6gYuyFjumTHefXgiqK6rPvhu+X4UAjrJgXxQFEvHh5 tuSVXoX6J/7VvPqQqlmhJe4ZXJ7ta7mTuVoadztggwwh50wwlAraH8ZL9hmxvhwh+y y2Z0zuB0AuPpt8N5oIVWKlQEtYU3ooWbeQPLSxpY= Subject: Re: cannot delete on-interface route in FIB References: <5757F6CF.7070807@norma.perm.ru> Cc: FreeBSD Net To: FreeBSD Stable ML From: "Eugene M. Zheganin" Message-ID: Date: Wed, 8 Jun 2016 20:34:57 +0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 15:34:57 -0000 Hi. On 08.06.2016 19:37, Alan Somers wrote: > What is the value of "sysctl net.add_addr_allfibs"? In your case, it > sounds like you want to set it to 0. Thanks a lot, looks like it, will try. Eugene. From owner-freebsd-net@freebsd.org Wed Jun 8 16:03:02 2016 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 2A7E8B6F2A7 for ; Wed, 8 Jun 2016 16:03:02 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 01A111ECF for ; Wed, 8 Jun 2016 16:03:01 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id u58Fxqxi056345 for ; Wed, 8 Jun 2016 10:59:52 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (unknown [172.126.77.65]) by mail.shrew.net (Postfix) with ESMTPSA id 8E07318CDEC for ; Wed, 8 Jun 2016 10:59:41 -0500 (CDT) Subject: Re: Getting CARP to broadcast on a different interface To: freebsd-net@freebsd.org References: <20160608124310.GG2050@box-hlm-03.niklaas.eu> <20160608145622.GA8540@box-hlm-03.niklaas.eu> From: Matthew Grooms Message-ID: <7a877e3c-9c77-c104-e47e-94c9d9389656@shrew.net> Date: Wed, 8 Jun 2016 11:02:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160608145622.GA8540@box-hlm-03.niklaas.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 08 Jun 2016 10:59:52 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 16:03:02 -0000 Hi Niklaas, Rewriting the multicast destination would be a neat trick, but sadly no. You can't rewrite a destination address on egress. Using a route-to rule would only modify the destination MAC address. If you were using OpenBSD, you would switch from multicast to unicast using the syncpeer option. Unfortunately that's not supported on FreeBSD. At one point I wrote a broadcast relay daemon to forward select UDP broadcast traffic between two networks separated by an IPsec tunnel. It had limited utility, but it worked well for what I needed it to do. I wonder if someone has written a multicast relay daemon that works in a similar fashion. If so, you could use it to forward CARP traffic to a peer. Super ugly, but it would probably do the trick in this scenario. -Matthew On 6/8/2016 9:56 AM, Niklaas Baudet von Gersdorff wrote: > Trond Endrestøl [2016-06-08 15:53 +0200] : > >> Although it sounds pretty bad, you could set up CARP on the internal >> network and use those CARP events to control the main interfaces, e.g. >> re-adjust their annoncement intervals, or something equally awful. > > Thanks, Trond. As you said, not that it sounds like a good idea but it's > a solution I will think about. > > What also came up in my head: Can't I re-reroute the CARP packets with > pf somehow? > > Niklaas > From owner-freebsd-net@freebsd.org Wed Jun 8 16:19:52 2016 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 42E1FB6F89D for ; Wed, 8 Jun 2016 16:19:52 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 194521DC1 for ; Wed, 8 Jun 2016 16:19:51 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id u58GGlka056383 for ; Wed, 8 Jun 2016 11:16:47 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (unknown [172.126.77.65]) by mail.shrew.net (Postfix) with ESMTPSA id A2F9718C61E for ; Wed, 8 Jun 2016 11:16:36 -0500 (CDT) Subject: Re: Getting CARP to broadcast on a different interface To: freebsd-net@freebsd.org References: <20160608124310.GG2050@box-hlm-03.niklaas.eu> From: Matthew Grooms Message-ID: Date: Wed, 8 Jun 2016 11:19:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 08 Jun 2016 11:16:47 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 16:19:52 -0000 On 6/8/2016 10:15 AM, David DeSimone wrote: > One of the purposes of the CARP announcements is to announce the > location of the virtual mac address to the upstream switch fabric. > Since CARP uses a virtual mac that floats between multiple ports, you > need to have the CARP master continually assert that its particular > port is the target that should be used for delivery of packets to the > virtual MAC address. Without this function, switches might still > mistakenly deliver their frames to the standby node. > > The CARP announcements are also helpful in detecting and routing > around some odd failure scenarios, such as a failure within the > upstream fabric, where the master sees link on its port, but can't > actually send frames that reach the rest of the network. If the > standby can't hear the master's announcements any more, it can > promote itself to master and hopefully keep your cluster online. > This would not happen without the announcement feature. > > I would hope you could explain this to your provider and get them to > white-list CARP announcements because they are defeating important > safety features you wish to use. > You just need a gratuitous ARP on the new switch port after the MAC is migrated. That's how VMs move quickly between hypervisors with almost no downtime. As soon as a MAC is seen on a new port, the switch should overwrite it's notion of the port to MAC association. https://wiki.wireshark.org/Gratuitous_ARP As for the standby node, it should never announce unless the master node fails to suppress it. -Matthew From owner-freebsd-net@freebsd.org Wed Jun 8 16:30:38 2016 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 367F9B6FB8A; Wed, 8 Jun 2016 16:30:38 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [84.22.110.84]) by mx1.freebsd.org (Postfix) with ESMTP id D6E79152D; Wed, 8 Jun 2016 16:30:37 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id A04CE38841C; Wed, 8 Jun 2016 18:30:33 +0200 (CEST) Date: Wed, 8 Jun 2016 18:30:33 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" Subject: Re: Getting CARP to broadcast on a different interface Message-ID: <20160608163033.GC8540@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rz+pwK2yUstbofK6" Content-Disposition: inline In-Reply-To: <7a877e3c-9c77-c104-e47e-94c9d9389656@shrew.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 16:30:38 -0000 --rz+pwK2yUstbofK6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Matthew Grooms [2016-06-08 11:02 -0500] : > Rewriting the multicast destination would be a neat trick, but sadly no.= =20 > You can't rewrite a destination address on egress. Using a route-to rule= =20 > would only modify the destination MAC address. If you were using=20 > OpenBSD, you would switch from multicast to unicast using the syncpeer=20 > option. Unfortunately that's not supported on FreeBSD. >=20 > At one point I wrote a broadcast relay daemon to forward select UDP=20 > broadcast traffic between two networks separated by an IPsec tunnel. It= =20 > had limited utility, but it worked well for what I needed it to do. I=20 > wonder if someone has written a multicast relay daemon that works in a=20 > similar fashion. If so, you could use it to forward CARP traffic to a=20 > peer. Super ugly, but it would probably do the trick in this scenario. Thank you for your explanation. I am far from understanding the underlying mechanisms to really get my head around possible solutions -- your comments helped. And, as you said, maybe there is someone else who came across this problem and has implemented a workaround. David DeSimone [2016-06-08 15:15 +0000] : > One of the purposes of the CARP announcements is to announce the > location of the virtual mac address to the upstream switch fabric. > Since CARP uses a virtual mac that floats between multiple ports, you > need to have the CARP master continually assert that its particular > port is the target that should be used for delivery of packets to the > virtual MAC address. Without this function, switches might still > mistakenly deliver their frames to the standby node. >=20 > The CARP announcements are also helpful in detecting and routing > around some odd failure scenarios, such as a failure within the > upstream fabric, where the master sees link on its port, but can't > actually send frames that reach the rest of the network. If the > standby can't hear the master's announcements any more, it can promote > itself to master and hopefully keep your cluster online. This would > not happen without the announcement feature. >=20 > I would hope you could explain this to your provider and get them to > white-list CARP announcements because they are defeating important > safety features you wish to use. Thank you too, David. I have already contacted my provider about this and they asked me to use keepalived -- which is deprecated in ports... I shall keep them updated about my progress in solving the issue though. Maybe I am lucky and can convince them to white-list the packets at some point. At this stage I am thinking about running CARP on the additional private virtual interface vtnet1 that I got from my provider. As I understood it, nothing is black-listed on these interfaces so CARP packets should go through. Then, I could use devd to assign the public failover IP (that I actually wanted to share with CARP on vtnet0) to the public interface vtnet0. CARP(4) provides an example on how to use carp status change events for additional scripting: --------------------8<-------------------- Processing of carp status change events can be set up by using the fol- lowing devd.conf rule: notify 0 { match "system" "CARP"; match "subsystem" "[0-9]+@[0-9a-z]+"; match "type" "(MASTER|BACKUP)"; action "/root/carpcontrol.sh $subsystem $type"; }; -------------------->8-------------------- Depending von $type, carpcontrol.sh could either ifconfig vtnet0 alias or ifconfig vtnet0 -alias I am not sure whether that works but I'll post my solution if I find one. In the meanwhile, I appreciate any further comment. Niklaas --rz+pwK2yUstbofK6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWEfsAAoJEG2fODeJrIU/Ap4P/RCuNYYBzRfjA61VHVUY1srs ycSSwi7XfIBndLlg1IKw5qvEr7hxg+TDcvEIfXcffsOZDHI6wLqlMe0JBuqqA0u8 9ddUREf712d68HeCY4R05ij5worNbFYeOvTrE9FaaFEzwP47GRRtn1QLotzy+vww lQnZ9HfekHAUdY8XrflVnFOoISffrtQWfokxu+mp3itZy/73K5eTus69vgZ6WY97 FsgKc9vvs19KnVBtvGQ5KZnksnn5qEgJYxujGt1gtQ7GulB4oi8cijqX2pXBnxLI yfmIDIKOzyW1kPnK3/Er7AwAy6YvhcPYpVhQbKqmHHY0Qg8W7O0RVhrL3poY7pC0 b3Q1EfA2YRbTMwsJPCaMIIVeGQXwph2cqycgah+EpqNx90KpiTk8ijgk9I3rILGr a78768FyqVGOPeJKG3iardCssOdot768Q6ekiLQPOIysJKMu3adrOKqLI6OkVhht NKhrCrmQdFoObEYMHAIWROZIiGTGWQoul14NgLQ5BaMhOlbdVAcxwaokMl3vE2cF LaV9V/PL/lcQCfmJ5+ILq04DjxYTuzY79zsxiu6r1x/jPEjTNgtEILFyRoARlTCU nInOUXEfP076zynfyV+iI0SeAdpwMB93hPsTlUK6AinFjBOWRo0xZdfGRaSpk2+R 3I+JZ8AyQZWnaDawmQNI =MAtn -----END PGP SIGNATURE----- --rz+pwK2yUstbofK6-- From owner-freebsd-net@freebsd.org Wed Jun 8 19:23:51 2016 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 66286B7051B; Wed, 8 Jun 2016 19:23:51 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [IPv6:2a02:2770:15:0:21a:4aff:feaa:e902]) by mx1.freebsd.org (Postfix) with ESMTP id 33E781996; Wed, 8 Jun 2016 19:23:51 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id F3C843887B3; Wed, 8 Jun 2016 21:23:47 +0200 (CEST) Date: Wed, 8 Jun 2016 21:23:47 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" Subject: Re: Getting CARP to broadcast on a different interface Message-ID: <20160608192347.GE8540@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" References: <7a877e3c-9c77-c104-e47e-94c9d9389656@shrew.net> <20160608163033.GC8540@box-hlm-03.niklaas.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dWYAkE0V1FpFQHQ3" Content-Disposition: inline In-Reply-To: <20160608163033.GC8540@box-hlm-03.niklaas.eu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 19:23:51 -0000 --dWYAkE0V1FpFQHQ3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Niklaas Baudet von Gersdorff [2016-06-08 18:30 +0200] : > Then, I could use devd to assign the public failover IP (that I actually > wanted to share with CARP on vtnet0) to the public interface vtnet0. > CARP(4) provides an example on how to use carp status change events for > additional scripting: >=20 [...] >=20 > Depending von $type, carpcontrol.sh could either >=20 > ifconfig vtnet0 alias >=20 > or >=20 > ifconfig vtnet0 -alias For that to work I must bind processes to non-local IP addresses. How do I do that? I found this https://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034033.html with some recommendations to do so with ipfw. Can I do something similar with pf? Or is there even another solution for binding to non-local addresses? Niklaas --dWYAkE0V1FpFQHQ3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWHC8AAoJEG2fODeJrIU/s6wP/1u0no+xoMukUOlvk0eIbNIa HXNxvOCGST3pz4Hy2nWXPibjF883oPgmnEMuDA5I18qXfJwOyW9/MzhgiHg/zi73 qp9kQpivxkDfUYuRJrHGM64TqqzJwCXJEDgSJvz/wZY2Dpwtk6uVWJbw/B3zgPSX xQ1Y/Gtdd3Fl9qepDJ52pDmyhmRlf3gd/O4hyZlZd6uCfYJatTcxM3rcJSGW/yPe LoLxuUxzP5A4Ylr8thcnR93ndeZpGzoTBRegVQEhSIZdrRy3dV5W9P/B4xHLKF3y EdD6hJH3rEQ75rhZne0wASbWaA4m3hMbFTRv49o42kvwllikai5Ys8blcwTFXHib FpB/0/LX65q07OiceJ/aYRVXla+F44DTHh8aUIZ4X+8l0l0cvJgWdlEyfPTq6idJ fT4aOLix5P/SDJIRDeXb0ftS/RnR0ztj8Uppr2SU7PccuPvMi0+sYTZm5FtXJ1X+ gIYWMgwBueL+c8xHCK/g/XswGYvzQk9UvErmcEWctLXB7tGdWyckM+0PGnFOd6QK qcJijq8Le5MfCoU8Jp7OnowL9VfWl48DNBvreARXQp+ea9jNK6kDHi3U0A/cwQ/6 bKlWYHcB0TuoytTSbM1wIC1kULttBC8Way81lq3wKPeq8UefLNtmN4fnBwj/5O4o /hatjY5Zi+I3WE6K+at+ =52YN -----END PGP SIGNATURE----- --dWYAkE0V1FpFQHQ3-- From owner-freebsd-net@freebsd.org Wed Jun 8 20:40:50 2016 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 2E001B6F72A for ; Wed, 8 Jun 2016 20:40:50 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 E39D41988 for ; Wed, 8 Jun 2016 20:40:49 +0000 (UTC) (envelope-from ricera10@gmail.com) Received: by mail-yw0-x231.google.com with SMTP id c72so19054650ywb.1 for ; Wed, 08 Jun 2016 13:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=N2H2sMXcObATYuvjSoMmChpbz97jZjkMXDD5HkMhTCA=; b=PeUpZCuQCrbWGUJ/bGTXHoanyeo02bo8CaX1vniWeYCpO/wzi2GQy8bLs65MLju7am mIklgmJCwTfFiB/EmitTf+SA0MgI1r2l5sfd4Z1vSAL2TCK6PhWHLloBBHlYNJMBWtXM 7lTb0Ho3b0Z7l22neY+O5SK8OM2gGuo0Ht9xm865pLQSBOycHvfAVdCaWsleJ2cxmdph lWFkm2anh1p9NUXr6e4Wo1tX/mC2Usi4UJ2z7uMjOtosn840aQW2+bcnjzsTjnM9zd/e d/imoU/pjWNjQ9kVFQZhAzdt3kw7TJQ9FP/2Dy/qa5N6mwevPFfjv9iYft4f78Kkdmtf Wzxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=N2H2sMXcObATYuvjSoMmChpbz97jZjkMXDD5HkMhTCA=; b=SelVwItTccWJNBTK3xPqHRjQu+Ji2HQ6kYg18xB5Tu3lsck3AfmsQpNkeSMI6iCp2i +wNNLryc6Il0qIo4r66IxOYCUYuKw2Ab2AZNDcmUiAWcSUB+akHcO/2iEUxLxIaT/MB7 QYizNac0RLl4cJTCMZPDr+dTWhYzt4gGE5dVltTAgPPO6RNc9wSnOTxhWBEENOia2zHg k+OgEYXE7a8IYPyxswHSAQxPAS6L6WusANSd3C8WUCmaIKb2pLNjutvjbtP73ne0r0H3 VKI7nfo/CiXejHQptdUXJlZermbhfjGy296WCn8H+M3m5EQA1p2Y4NblUAJpbZuJZ2Xx MOlA== X-Gm-Message-State: ALyK8tJ3qj7SX2HsOL8Ejy1rOnHte7dUzW6O+pCgPAmSeN8MSzNzvmimuCWo74bjDfpKz8XnTHYC+JxvVmlDig== X-Received: by 10.129.116.2 with SMTP id p2mr4279069ywc.209.1465418448653; Wed, 08 Jun 2016 13:40:48 -0700 (PDT) MIME-Version: 1.0 References: <494678734.3111275.1465379076220.JavaMail.zimbra@stormshield.eu> In-Reply-To: <494678734.3111275.1465379076220.JavaMail.zimbra@stormshield.eu> From: Eric Joyner Date: Wed, 08 Jun 2016 20:40:39 +0000 Message-ID: Subject: Re: [Patch] Changing mac address does not always work To: Arnaud YSMAL , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 20:40:50 -0000 I think a better fix here is to have the driver not call init_locked() when the driver is not running when setting the MTU. It looks like all the other Intel network drivers do the same thing as this for the MTU. On Wed, Jun 8, 2016 at 2:47 AM Arnaud YSMAL wrote: > Hi, > > Configuring the network card with the following commands (in this specific > order) does not work. > # ifconfig em0 down > # ifconfig em0 mtu 1500 > # ifconfig em0 ether 12:34:56:12:34:56 > # ifconfig em0 192.168.1.1/24 > # ifconfig em0 up > > I was able to reproduce this issue on 10.3-RELEASE and HEAD with ix and em > drivers. > > From what I understand: > - When setting the mtu, the driver calls the init of the interface which > sets the IFF_DRV_RUNNING flag > - When setting the mac address, if_setlladdr (from if.c) copy the mac > address but does nothing else (the interface is not up) > - When setting the ip address, the driver does not call the init as the > IFF_DRV_RUNNING is already set. > - When setting the up flag, same as above, the IFF_DRV_RUNNING is already > set. > > In this case the network card does not work as the mac address filter is > not up to date. > > The enclosed path fixes this issue, > It changes if_setlladdr in if.c to call the ifp->if_ioctl function with > the IFF_UP flag clear even when the interface is not up. > The driver will then call its stop function which clear the > IFF_DRV_RUNNING. > The init will be called when setting the ip address or the up flag. > > Do you have any advice regarding this patch? > > Arnaud_______________________________________________ > 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 Jun 8 23:02:49 2016 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 09985B6FBA2; Wed, 8 Jun 2016 23:02:49 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 BAD081FCC; Wed, 8 Jun 2016 23:02:48 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bAmUi-000Aax-5i; Thu, 09 Jun 2016 02:02:40 +0300 Date: Thu, 9 Jun 2016 02:02:40 +0300 From: Slawa Olhovchenkov To: stable@freebsd.org, freebsd-net@freebsd.org Subject: ipfw fwd to closed port Message-ID: <20160608230240.GA51364@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 08 Jun 2016 23:02:49 -0000 Forwarding by ipfw to closed local port generating RST packet with incorrect checksun. Is this know ussuse? Need open PR? From owner-freebsd-net@freebsd.org Thu Jun 9 05:04:05 2016 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 6AF4BB6EE96 for ; Thu, 9 Jun 2016 05:04:05 +0000 (UTC) (envelope-from rupavath@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (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 BF588178E; Thu, 9 Jun 2016 05:04:04 +0000 (UTC) (envelope-from rupavath@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1Tb7TvBo30AHWxIVrfSC9GFwYif84rqOA2s1+DBucBQ=; b=e3LB/6U7EMgxCJsd77Ugs3WxRESHIHV0JH/R4dqj7E3yC64fjpJBMQCB39R70oo3X2FQjKQJMOVfclcrVWGlzYlyQUCZVlT4vz0xCiVoDZFSUaWgLNSS0dd8sA23i521XPAcEmcWsG5N6vfI/UED1eOEZ9YVMeSFcvEP4BeupL4= Received: from DM2PR0501MB1152.namprd05.prod.outlook.com (10.160.245.154) by DM2PR0501MB1149.namprd05.prod.outlook.com (10.160.245.151) with Microsoft SMTP Server (TLS) id 15.1.506.9; Thu, 9 Jun 2016 04:31:22 +0000 Received: from DM2PR0501MB1152.namprd05.prod.outlook.com ([10.160.245.154]) by DM2PR0501MB1152.namprd05.prod.outlook.com ([10.160.245.154]) with mapi id 15.01.0506.016; Thu, 9 Jun 2016 04:31:22 +0000 From: Sreekanth Rupavatharam To: Jack Vogel CC: hiren panchasara , "freebsd-net@freebsd.org" , "sbruno@FreeBSD.org" , "erj@FreeBSD.org" Subject: Re: Possible transmit/stats problem in igb driver. Thread-Topic: Possible transmit/stats problem in igb driver. Thread-Index: AQHRvEO2jFZU+cZVnkCsgDAxQb6jLZ/Wn9GA//+Y+oCAAH2aAIABBQoAgAB3PICACGRasQ== Date: Thu, 9 Jun 2016 04:31:22 +0000 Message-ID: References: <20160602202015.GG8994@strugglingcoder.info> <9A903EE5-3F2C-46C0-B563-1150F81E3507@juniper.net> <20160602214104.GJ8994@strugglingcoder.info> , In-Reply-To: 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=rupavath@juniper.net; x-originating-ip: [98.207.238.71] x-ms-office365-filtering-correlation-id: 1881d48e-c0a7-4647-194d-08d3901ee94d x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1149; 5:B6SFBkliHaD+byz7spwiV8K8OHz69ULS3vVqyz12Og68yEO0VJYjr1B254rMZzq6Oecp0cXYIcndM5E49rigKMa5BYe1gxFAXIiN9mt3k0SLtgmUhCeAfn1cXo2nVyElmjal+GaK+eqVUHw5fQuuNA==; 24:Hekba9qRp4NaLdt2zKEQdCnE88tL1nRnx6tS+akQLS+XG0iah9vLOhMXbKHW3ggN9U87GG1U0FMw4/JeYX2clDc+lYd4BfecqQs6nWZZCGI=; 7:7TtiireaHHsrMmRDEnNRz24KxGFL0PQTEIsdvzOEwoslw4cNKTPqf/cuCau3yXfVtVy52sOLMOf0cXwYm/jNaTjYjwsVFoqC5Fl32O6VYdb/xq960zKcN1F19Cea5zclC5qNBub7pHy4h9hgJNsH6SsaoVbHnWDAZJbDv6/2AS6XodQqHCXom2c7esz3Nj7DbDmWapdMzVKKjgbAdWj20A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1149; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DM2PR0501MB1149; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1149; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(199003)(189002)(33656002)(101416001)(5002640100001)(3280700002)(54356999)(76176999)(3846002)(3660700001)(68736007)(50986999)(86362001)(97736004)(110136002)(2950100001)(77096005)(189998001)(82746002)(99286002)(4326007)(83716003)(8936002)(93886004)(16236675004)(19580405001)(87936001)(102836003)(2900100001)(36756003)(106116001)(1411001)(11100500001)(105586002)(106356001)(66066001)(19580395003)(10400500002)(5008740100001)(586003)(92566002)(2906002)(81166006)(8676002)(122556002)(81156014)(5004730100002)(6116002)(104396002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1149; H:DM2PR0501MB1152.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 04:31:22.5840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1149 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 09 Jun 2016 05:04:05 -0000 Well, that wasn't the issue. However there are some other details. The devi= ce is DH8900CC(0x8086:0x43a) quad nic serdes interface. The issue happens when th= e device is used in passthrough mode inside a VM. The guest OS is running F= reeBSD 10.1 and the host is Linux. There is no easy way to run this test in= bare metal mode. Another point I confirmed is that the descriptor is consu= med by the hardware(I get igb_txeof calls for the packets). The issue is no= t happening in the previously unified em driver(before igb driver was creat= ed) Thanks, -Sreekanth On Jun 3, 2016, at 1:22 PM, Jack Vogel > wrote: That's an interesting theory, you could add a check into the tx path lookin= g for a zero m_len and see, seems unlikely though :) Jack On Fri, Jun 3, 2016 at 1:15 PM, Sreekanth Rupavatharam > wrote: Wondering if this can happen if somehow the mbuf->m_len is not correct(e.g.= , 0) and thus causing the dma to fail silently. The only way this is happen= ing if the arp request is larger than 64 bytes and the arp response code is= reusing the packet to send a 64 byte response. Thanks, -Sreekanth On 6/2/16, 2:41 PM, "hiren panchasara" > wrote: >+ Sean, Eric > >On 06/02/16 at 09:11P, Sreekanth Rupavatharam wrote: >> Inline >> >> >Apart from stats, do you see anything else going wrong? i.e. do you >> >actually see less packets (arp replies??) than expected? >> >> [SR] The packets are not going out on the wire. The tool doesn?t receive= the packets. That?s how I started noticing the issue. >> >> >Taking your example, tx_packets is something we count in the drivers an= d >> >total_pkts_txd is calculated in the card and we just read it off of it >> >to report (E1000_TPT). >> >> [SR] Correct. My main question would be under what circumstance would th= e packet handed off to hardware will *not* be transmitted?. Especially cons= idering there are no transmit errors or pause frames received. There are no= dma tx failures either. That?s the baffling part. I tried another exercise= where I used ping of various sizes going out, but that doesn?t seem to tri= gger the problem. >> >> >> >To understand your setup better, ixia is the sender and your box with >> >igb(4) is the receiver and your are sending arp requests to it. >> >> Yes, correct. >> >> >Can you post following for working (size <=3D 64bytes) and non-working >> >(size > 64bytes) cases for before/after? >> > >> >sysctl dev.igb | grep tx_packets >> >sysctl dev.igb | grep total_pkts_txd >> >sysctl dev.igb | grep rx_packets >> >sysctl dev.igb | grep total_pkts_recvd >> >> >> Before(not working): >> dev.igb.1.queue0.tx_packets: 24907933 >> dev.igb.1.queue0.rx_packets: 18086575 >> dev.igb.1.mac_stats.total_pkts_recvd: 25057359 >> dev.igb.1.mac_stats.total_pkts_txd: 16647169 >> >> After(not working): >> dev.igb.1.queue0.tx_packets: 24913324 >> dev.igb.1.queue0.rx_packets: 18091832 >> dev.igb.1.mac_stats.total_pkts_recvd: 25062618 >> dev.igb.1.mac_stats.total_pkts_txd: 16647545 >> >netstat -sp arp >> >> The difference is 5391 for queue0.tx_packets but for mac_stats.total_pk= ts_txd is 376 >> Everything else is matching up. >> >> Before (working) >> dev.igb.1.queue0.tx_packets: 25359165 >> dev.igb.1.queue0.rx_packets: 18526094 >> dev.igb.1.mac_stats.total_pkts_recvd: 25508763 >> dev.igb.1.mac_stats.total_pkts_txd: 16831587 >> >> >> After(working) >> dev.igb.1.queue0.tx_packets: 25364597 >> dev.igb.1.queue0.rx_packets: 18531398 >> dev.igb.1.mac_stats.total_pkts_recvd: 25514009 >> dev.igb.1.mac_stats.total_pkts_txd: 16836833 >> >> >> Another interesting stat is >> before_notworking:dev.igb.1.interrupts.tx_queue_empty: 16646890 >> after_notworking:dev.igb.1.interrupts.tx_queue_empty: 16647266 >> >> The difference here is exactly 376 which is the number of packets that t= he device actually claims to have transmitted. It?s as though it didn?t see= the other packets en-queued in the ring descriptor. >> > >Very interesting. Do you tune defaults at all? What does sysctl hw.igb >say? Not sure if bumping up txd would help. > >Adding Sean and Eric to throw some light. > >> >> I can?t do netstat just for arp as these are coming in a tunnel(Packets = don?t? show up as arp on the interface). However, I did see the packet rate= was about 500 packets/sec >> > >Cheers, >Hiren From owner-freebsd-net@freebsd.org Thu Jun 9 13:00:21 2016 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 B2082B6EA04; Thu, 9 Jun 2016 13:00:21 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E2011C3A; Thu, 9 Jun 2016 13:00:20 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id AFF701E46C; Thu, 9 Jun 2016 15:00:17 +0200 (CEST) Received: by vega.codepro.be (Postfix, from userid 1001) id A7C4880AC; Thu, 9 Jun 2016 15:00:17 +0200 (CEST) Date: Thu, 9 Jun 2016 15:00:17 +0200 From: Kristof Provost To: Slawa Olhovchenkov Cc: stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipfw fwd to closed port Message-ID: <20160609130017.GA4071@vega.codepro.be> References: <20160608230240.GA51364@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160608230240.GA51364@zxy.spb.ru> X-Checked-By-NSA: Probably User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 09 Jun 2016 13:00:21 -0000 On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: > Forwarding by ipfw to closed local port generating RST packet with > incorrect checksun. Is this know ussuse? Need open PR? Where did you capture the packet? If you've captured the packet on the machine that generated it tcpdump may indeed claim that the checksum is wrong, because it's computed by the hardware (so after tcpdump captured it). Regards, Kristof From owner-freebsd-net@freebsd.org Thu Jun 9 13:06:05 2016 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 0D764B6EEC5; Thu, 9 Jun 2016 13:06:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 C60F71B7C; Thu, 9 Jun 2016 13:06:04 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bAzer-0005gL-J2; Thu, 09 Jun 2016 16:06:01 +0300 Date: Thu, 9 Jun 2016 16:06:01 +0300 From: Slawa Olhovchenkov To: Kristof Provost Cc: stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipfw fwd to closed port Message-ID: <20160609130601.GS75630@zxy.spb.ru> References: <20160608230240.GA51364@zxy.spb.ru> <20160609130017.GA4071@vega.codepro.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160609130017.GA4071@vega.codepro.be> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 09 Jun 2016 13:06:05 -0000 On Thu, Jun 09, 2016 at 03:00:17PM +0200, Kristof Provost wrote: > On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: > > Forwarding by ipfw to closed local port generating RST packet with > > incorrect checksun. Is this know ussuse? Need open PR? > > Where did you capture the packet? If you've captured the packet on the > machine that generated it tcpdump may indeed claim that the checksum is > wrong, because it's computed by the hardware (so after tcpdump captured > it). On the tun0 (destination of RST packet routed to tun0). tun0: flags=8051 metric 0 mtu 1500 options=80000 inet 192.168.4.1 --> 192.168.4.1 netmask 0xffffff00 inet6 fe80::240:63ff:fedc:ac9e%tun0 prefixlen 64 scopeid 0x9 nd6 options=21 Opened by PID 1345 tun0 don't computed checksum. From owner-freebsd-net@freebsd.org Thu Jun 9 13:08:38 2016 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 3B4D4B6F07B; Thu, 9 Jun 2016 13:08:38 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08AEB1DCA; Thu, 9 Jun 2016 13:08:38 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.65.209.127] (unknown [137.122.64.8]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id D8E661E513; Thu, 9 Jun 2016 15:08:35 +0200 (CEST) From: "Kristof Provost" To: "Slawa Olhovchenkov" Cc: stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipfw fwd to closed port Date: Thu, 09 Jun 2016 09:08:33 -0400 Message-ID: In-Reply-To: <20160609130601.GS75630@zxy.spb.ru> References: <20160608230240.GA51364@zxy.spb.ru> <20160609130017.GA4071@vega.codepro.be> <20160609130601.GS75630@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9.4r5234) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 09 Jun 2016 13:08:38 -0000 On 9 Jun 2016, at 9:06, Slawa Olhovchenkov wrote: > On Thu, Jun 09, 2016 at 03:00:17PM +0200, Kristof Provost wrote: > >> On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: >>> Forwarding by ipfw to closed local port generating RST packet with >>> incorrect checksun. Is this know ussuse? Need open PR? >> >> Where did you capture the packet? If you've captured the packet on the >> machine that generated it tcpdump may indeed claim that the checksum is >> wrong, because it's computed by the hardware (so after tcpdump captured >> it). > > On the tun0 (destination of RST packet routed to tun0). > tun0: flags=8051 metric 0 mtu 1500 > options=80000 > inet 192.168.4.1 --> 192.168.4.1 netmask 0xffffff00 > inet6 fe80::240:63ff:fedc:ac9e%tun0 prefixlen 64 scopeid 0x9 > nd6 options=21 > Opened by PID 1345 > > tun0 don't computed checksum. I’m not sure I understand what you’re trying to say. In any case: either capture the packet outside the machine, or confirm that the checksum is wrong by watching the relevant netstat counters. Regards, Kristof From owner-freebsd-net@freebsd.org Thu Jun 9 13:16:20 2016 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 74984B6F407; Thu, 9 Jun 2016 13:16:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 39E8116B4; Thu, 9 Jun 2016 13:16:20 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1bAzoo-0005ur-9O; Thu, 09 Jun 2016 16:16:18 +0300 Date: Thu, 9 Jun 2016 16:16:18 +0300 From: Slawa Olhovchenkov To: Kristof Provost Cc: stable@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipfw fwd to closed port Message-ID: <20160609131618.GU75630@zxy.spb.ru> References: <20160608230240.GA51364@zxy.spb.ru> <20160609130017.GA4071@vega.codepro.be> <20160609130601.GS75630@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 09 Jun 2016 13:16:20 -0000 On Thu, Jun 09, 2016 at 09:08:33AM -0400, Kristof Provost wrote: > > > On 9 Jun 2016, at 9:06, Slawa Olhovchenkov wrote: > > > On Thu, Jun 09, 2016 at 03:00:17PM +0200, Kristof Provost wrote: > > > >> On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: > >>> Forwarding by ipfw to closed local port generating RST packet with > >>> incorrect checksun. Is this know ussuse? Need open PR? > >> > >> Where did you capture the packet? If you've captured the packet on the > >> machine that generated it tcpdump may indeed claim that the checksum is > >> wrong, because it's computed by the hardware (so after tcpdump captured > >> it). > > > > On the tun0 (destination of RST packet routed to tun0). > > tun0: flags=8051 metric 0 mtu 1500 > > options=80000 > > inet 192.168.4.1 --> 192.168.4.1 netmask 0xffffff00 > > inet6 fe80::240:63ff:fedc:ac9e%tun0 prefixlen 64 scopeid 0x9 > > nd6 options=21 > > Opened by PID 1345 > > > > tun0 don't computed checksum. > > I’m not sure I understand what you’re trying to say. > > In any case: either capture the packet outside the machine, or confirm > that the checksum is wrong by watching the relevant netstat counters. I am have machine with tun0 (see above) and ipfw rules: 04010 23880 2132855 fwd 127.0.0.1,3129 tcp from 192.168.0.0/16 to not me dst-port 80,3128,8080,8100-8105 recv tun0 # netstat -rn 192.168.4.0/24 192.168.4.1 UGS tun0 192.168.4.1 link#9 UH tun0 tun0 handled by coova-chilli. Initator from network 192.168.4.0/24 (ex: 192.168.4.4) send packet to outside, 8.8.8.8 for example. fwd on tun0 forwarded tin 127.0.0.1,3129. No listener on 127.0.0.1:3129, RST generated from 8.8.8.8:80 to 192.168.4.4:2345. This packet routed to tun0 an received by chilli. Checksums must be correct at this point, on tun0 interface for correct handling in chilli. From owner-freebsd-net@freebsd.org Thu Jun 9 17:54:45 2016 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 2BD86B7049D; Thu, 9 Jun 2016 17:54:45 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [84.22.110.84]) by mx1.freebsd.org (Postfix) with ESMTP id AB54F13AF; Thu, 9 Jun 2016 17:54:44 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id 0E4EB387E10; Thu, 9 Jun 2016 19:54:35 +0200 (CEST) Date: Thu, 9 Jun 2016 19:54:35 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" Subject: Re: Getting CARP to broadcast on a different interface Message-ID: <20160609175434.GA2155@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <20160608192347.GE8540@box-hlm-03.niklaas.eu> <20160608163033.GC8540@box-hlm-03.niklaas.eu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 09 Jun 2016 17:54:45 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I can't believe it but I managed to do this: Niklaas Baudet von Gersdorff [2016-06-08 18:30 +0200] : > Then, I could use devd to assign the public failover IP (that I actually > wanted to share with CARP on vtnet0) to the public interface vtnet0. > CARP(4) provides an example on how to use carp status change events for > additional scripting: >=20 > --------------------8<-------------------- >=20 > Processing of carp status change events can be set up by using the fol- > lowing devd.conf rule: >=20 > notify 0 { > match "system" "CARP"; > match "subsystem" "[0-9]+@[0-9a-z]+"; > match "type" "(MASTER|BACKUP)"; > action "/root/carpcontrol.sh $subsystem $type"; > }; >=20 > -------------------->8-------------------- >=20 > Depending von $type, carpcontrol.sh could either >=20 > ifconfig vtnet0 alias >=20 > or >=20 > ifconfig vtnet0 -alias >=20 > I am not sure whether that works but I'll post my solution if I find > one. Obviously, the following set-up is very limited to a prober configuration with CARP on a public network. However, it seems as if supporting CARP in virtualised environments isn't possible because the multicast packages would collide with those of other customers in the same network. So the only solution is to use CARP within a private network for some pseudo-CARP IP. Then, one can use the devd events that are triggered if connection via the private network is lost, to assign and remove the floating public IP that is used for failover. So, let's see how this can be done. I have three hosts A, B, and C. I could not manage to get CARP advertising over a virtual private network of my provider that connects these hosts (CARP used the wrong MAC addresses so the packets weren't translated correctly). But what I managed to get going is CARP advertising over my tinc VPN tap0. So if any host comes online and connects to the other hosts on the VPN, tinc will assign a CARP vhid on tap0. This is /usr/local/etc/tinc/host-up on host A: --------------------8<-------------------- ifconfig $INTERFACE vhid 1 advbase 01 advskew 000 pass 10.99= =2E99.99 alias -------------------->8-------------------- On host B and C the file looks exactly the same except that advbase is five seconds longer each (06 and 11 respectively). (While testing the set-up I realised that latency is too high, so that advskew wouldn't suffice.) I use exactly the same devd.conf as quoted above. I put it under /usr/local/etc/devd. Further, I did the following: sysctl net.inet.carp.preempt=3D1 which should be added to /etc/sysctl.conf. /root/carpcontrol.sh is on every host and looks like the following: --------------------8<-------------------- 1 #!/bin/sh 2 =20 3 subsystem=3D$1 4 type=3D$2 5 vhid=3D"1" 6 c_if=3D"tap0" # CARP interface 7 =20 8 e_if=3D"vtnet0" # external interface 9 IPv4=3D"" 10 IPv4_net=3D"/24" 11 IPv6=3D"" 12 IPv6_net=3D"/64" 13 =20 14 log_tag=3D"carpcontrol.sh" 15 =20 16 remove_floating_ip() { 17 if ifconfig $e_if | grep $IPv4 >/dev/null 18 then 19 ifconfig $e_if $IPv4$IPv4_net -alias && logger -t $log_tag = "Removed $IPv4 on $e_if." 20 fi 21 if ifconfig $e_if | grep $IPv6 >/dev/null 22 then 23 ifconfig $e_if inet6 $IPv6$IPv6_net -alias && logger -t $lo= g_tag "Removed $IPv6 on $e_if." 24 fi 25 } 26 =20 27 add_floating_ip() { 28 ifconfig $e_if $IPv4$IPv4_net alias && logger -t $log_tag "Assi= gned $IPv4 on $e_if." 29 ifconfig $e_if inet6 $IPv6$IPv6_net alias && logger -t $log_tag= "Assigned $IPv6 on $e_if." 30 } 31 =20 32 if [ "$subsystem" =3D "$vhid@$c_if" ] 33 then 34 case $type in=20 35 "MASTER") 36 add_floating_ip 37 ;; 38 "BACKUP") 39 remove_floating_ip 40 ;; 41 esac 42 elif [ "$subsystem" =3D "tinc-down" ] 43 then 44 remove_floating_ip 45 fi -------------------->8-------------------- Probably that's not the best way to do it and probably it could be extended but my sh-skills are quite bad. This works though. The script should be self-explanatory; the only ting that might be unclear are lines 42-45. This is triggered by /usr/local/etc/tinc-down: --------------------8<-------------------- /root/carpcontrol.sh tinc-down -------------------->8-------------------- So, in case I stop tincd on purpose, the floating IP will be removed and becomes free for the other machines. The second host will take over the IP after some seconds. Obviously, there are quite some drawbacks to this but it serves my purpose. Since the machines are virtualised I don't expect them to down by some hardware failure. But I do need failover in case I want to upgrade one machines and need to reboot it. In case I need to do some maintenance, I cut the machine in question =66rom the private network. For some seconds services won't be reachable but after a short while host B will take over. I can upgrade host A and restart it eventually. When host A runs again, it will connect to the tinc VPN and while advertise CARP on that network. So, host A will becomes MASTER again, host B will switch to BACKUP, and C will remain BACKUP. Nonetheless, this is not a perfect solution. "High-availability" (these quotes are on purpose) as achieved this way, depends on the connectivity between the tinc nodes. E.g., if tinc malfunctions and doesn't shutdown properly, the floating IP will stay assigned to the public interface, the other client will loose connectivity to the node, and an additional MASTER will rise. In addition, I had problems using a faster advbase because of latency, I guess, thus there will be some downtime if any MASTER goes down. In this case, the problem was that two hosts could not decide who should be MASTER because there were some connectivity problems between them on the VPN. The crux is that CARP, as implemented in FreeBSD, cannot advertise on unicast. If it could, I would have been able to assign it to the private virtual interface that connects the virtual machines. However, CARP, as implemented in OpenBSD, can do so using a feature called "carppeer". There have been requests whether/when that will be brought to FreeBSD [1-3] but the questions remained without responses.=20 1: https://lists.freebsd.org/pipermail/freebsd-net/2013-November/037106.html 2: https://lists.freebsd.org/pipermail/freebsd-net/2011-February/027999.html 3: https://lists.freebsd.org/pipermail/freebsd-pf/2009-December/005486.html So, where can I post feature requests? :-) Without a way for unicast CARP packets, FreeBSD is of much less value for virtualised environments where multicast packets are an issue because they are blocked by providers. So, setting up a failover set-up becomes a mess (such as the one above). Niklaas Baudet von Gersdorff [2016-06-08 21:23 +0200] : > For that to work I must bind processes to non-local IP addresses. How do > I do that? >=20 > I found this >=20 > https://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034033.h= tml >=20 > with some recommendations to do so with ipfw. Can I do something similar > with pf? Or is there even another solution for binding to non-local > addresses? No longer necessary. I use a pf rule that redirect any traffic arriving on a specific port (this could also be any traffic arriving on the pseudo-CARP IP) to the jail where the load-balancer is listening. Anyway, I'm happy for any comments and further suggestions. Niklaas --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWa1UAAoJEG2fODeJrIU/JcQP/if7WQQrKliePAZBWeTLOdww PDEfG8NzF/ValyiMl8ihSKIZCnWZulMaWWbHrzE0eQzDVunLkG4ZbtmF4eyXPyC8 hpSKUFnlbsBmogSyLegxjP3U5XxQR4y8HJKXLvhNlYfjWta9q3Vuvlg/SL7Lzp3J 1hvwl/jsuexM/qwRaVT4ueRq3UM1lvtS2oun605JAIkw3bhQOoCVVCYX9VQGNriu vzPIVAp9/NP6u44mJRnyxU0ChJDdXQF8evggkACIaRmZV0Jgg3oKuf71jQ0k7d0X 5F9ODt7ZQLrLonQ0jd9eMn9bEMmYStQgBhQywuTCFneoe7ahuM/ds9/hpYpx3TRR jiiuy1hdTvgL+lYV+N3cVmpka+k9c1od2VBGKmf8nzwKadsrv9Yi9ywUYgwjaKnB FdwqEBq/fEd5PiiljmQDsELfacFP2cRbkN3W0dvSEwUVmQlXNIh0abcoOCSzag6Z tnxc8ebTKHcP6QUMQX12l9V7ehU5J2KVCG3ABs2VQGcmrXJBPdx+Vm37oIqf/RCW LS0wZ3zZxGV06NylL5fYgo/8gi7XIiW9MxpkdNlyRLVZPB0ji0eP1NzXyaK5jY+F YXwa92mMMZ35biLQGxXr1UwigkFKnphsqCWuXHhML4wJ/e+cF7XZbDMvcnx5Z9Kp /+1P6QX1apt6qlGHhmFC =nede -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-net@freebsd.org Thu Jun 9 21:15:40 2016 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 A83F7B70EDD for ; Thu, 9 Jun 2016 21:15:40 +0000 (UTC) (envelope-from david_a_bright@dell.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 97DA11C1A for ; Thu, 9 Jun 2016 21:15:40 +0000 (UTC) (envelope-from david_a_bright@dell.com) Received: by mailman.ysv.freebsd.org (Postfix) id 93993B70EDC; Thu, 9 Jun 2016 21:15:40 +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 93460B70EDA for ; Thu, 9 Jun 2016 21:15:40 +0000 (UTC) (envelope-from david_a_bright@dell.com) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "ausxipmktps31.us.dell.com", Issuer "Verizon Public SureServer CA G14-SHA1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 32BD11C15 for ; Thu, 9 Jun 2016 21:15:39 +0000 (UTC) (envelope-from david_a_bright@dell.com) X-Loopcount0: from 76.164.8.179 X-IronPort-AV: E=Sophos;i="5.26,446,1459832400"; d="scan'208";a="407575374" From: David Bright To: "net@FreeBSD.org" Subject: DHCPv6 Support in FreeBSD Base Thread-Topic: DHCPv6 Support in FreeBSD Base Thread-Index: AQHRwpPc/BzxG7cxfUSAxV55qfFvLQ== Date: Thu, 9 Jun 2016 21:14:09 +0000 Message-ID: <6224EC83-3A81-4CE7-83C5-674628F38958@DELL.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.156.108.251] Content-Type: text/plain; charset="utf-8" Content-ID: <65C76EFE1420F94598F2584CB483ED4C@compellent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 09 Jun 2016 21:15:40 -0000 Rm9sbG93aW5nIHVwIG9uIGEgY29udmVyc2F0aW9uIEkgc3RhcnRlZCB0b2RheSBhdCBCU0RDYW4g MjAxNi9EZXZTdW1taXQuDQoNCknigJlkIGxpa2UgdG8gc2VlIHN1cHBvcnQgZm9yIERIQ1B2NiBp biB0aGUgYmFzZSBzeXN0ZW0uIEkgaGF2ZSBtYWRlIG1vZGlmaWNhdGlvbnMgdG8gbmV0d29yay5z dWJyIGFuZCB0aGUgcmMuZCBpbml0IHNjcmlwdHMgdG8gYWxsb3cgY29uZmlndXJpbmcgYSBuZXR3 b3JrIGludGVyZmFjZSB0byB1c2UgREhDUHY2IGluIGEgbWFubmVyIHZlcnkgc2ltaWxhciB0byB0 aGF0IGN1cnJlbnRseSB1c2VkIGZvciBESENQdjQuIFRoaXMgd29ya3MgYXNzdW1pbmcgdGhhdCB5 b3UgaGF2ZSBhIERIQ1B2NiBjbGllbnQuIEZvciB0aGUgcHVycG9zZXMgb2YgbXkgZGV2ZWxvcG1l bnQgSSB1c2VkIHRoZSBJU0MgY2xpZW50IGZyb20gcG9ydHMuDQoNClRoZXNlIGNoYW5nZXMgd2Vy ZSBiYXNlZCBvbiAxMC4wLVJFTEVBU0UgYW5kIEkgYW0gaW4gdGhlIHByb2Nlc3Mgb2YgYWRhcHRp bmcgdGhlc2UgY2hhbmdlcyB0byAxMSBzbyB0aGV5IGNhbiBiZSBwdXNoZWQgdXBzdHJlYW0uIEhv d2V2ZXIsIHRoZXkgd2lsbCBiZSB1bnVzYWJsZSAoYWxiZWl0IGhhcm1sZXNzKSBpbiB0aGUgYmFz ZSBzeXN0ZW0gd2l0aG91dCBhIGNsaWVudC4NCg0KKiBJcyB0aGVyZSBhbnkgYmFycmllciB0byB1 cGRhdGluZyB0aGUgZGhjbGllbnQgaW4gYmFzZSB0byB0aGUgY3VycmVudCBJU0MgZGhjbGllbnQg Zm9yIGJvdGggREhDUHY0ICYgREhDUHY2Pw0KDQoqIElzIHRoZXJlIGFueSBiYXJyaWVyIHRvIHJl cGxhY2luZyB0aGUgY3VycmVudCBkaGNsaWVudC1zY3JpcHQgd2l0aCB0aGF0IHRoYXQgYWNjb21w YW5pZXMgdGhlIElTQyBkaGNsaWVudD8NCiAgICBUaGUgdHdvIHNjcmlwdHMgYXJlIHF1aXRlIGRp ZmZlcmVudCBhbmQgbXkgREhDUHY2IGNoYW5nZXMgY3VycmVudGx5IGFyZSBiYXNlZCBvbiB0aGUg SVNDIGRoY2xpZW50LXNjcmlwdC4gDQoNCkFzIEnigJl2ZSBhbHJlYWR5IGRvbmUgYSBmYWlyIGFt b3VudCBvZiB0aGlzIHdvcmssIEnigJlkIGJlIGhhcHB5IHRvIHdvcmsgb24gZ2V0dGluZyBpdCBp biBzaGFwZSBmb3IgcHVzaGluZyB0byBIRUFELiBJIGhhZCBzZXZlcmFsIHBlb3BsZSB0b2RheSBh dCB0aGUgZGV2c3VtbWl0IGluZGljYXRlIHRoYXQgdGhleSB0aG91Z2h0IHRoYXQgd291bGQgYmUg YSBnb29kIGlkZWEsIGJ1dCBJIHRob3VnaHQgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gYXNr IGFoZWFkIG9mIHRpbWUgaWYgdGhlcmUgd2VyZSBhbnkga25vd24gc3R1bWJsaW5nIGJsb2NrcyB0 byBkb2luZyB0aGF0Lg0KDQpUaGFua3MuICANCg0KDQotLSANCkRhdmlkIEEuIEJyaWdodA0KU3Rv cmFnZSBEZXZlbG9wbWVudCBQcmluY2lwYWwgRW5naW5lZXINCkRlbGwgfCBDb21wZWxsZW50DQpv ZmZpY2UgKzEgOTUyIDM5MiA1ODYxDQpDdWJlIEotNzMxLCA3NjE1IFNtZXRhbmEgTGFuZSwgRWRl biBQcmFpcmllLCBNTiA1NTM0NA0KRGF2aWRfQV9CcmlnaHRAREVMTC5jb20NCg0K From owner-freebsd-net@freebsd.org Thu Jun 9 22:10:22 2016 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 B000FB70D1B for ; Thu, 9 Jun 2016 22:10:22 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9042512D5 for ; Thu, 9 Jun 2016 22:10:22 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8C2C4B70D1A; Thu, 9 Jun 2016 22:10:22 +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 896EFB70D19 for ; Thu, 9 Jun 2016 22:10:22 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E778512D4 for ; Thu, 9 Jun 2016 22:10:21 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org ([IPv6:2400:402e:a012:6300:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id u59MA1V9072632 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Fri, 10 Jun 2016 07:10:12 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org ([IPv6:2400:402e:a012:6300:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id u59MA0ah058421 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jun 2016 07:10:00 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id u59M9xu6058402; Fri, 10 Jun 2016 07:10:00 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 10 Jun 2016 07:08:22 +0900 (JST) Message-Id: <20160610.070822.525071082322626267.hrs@allbsd.org> To: david_a_bright@dell.com Cc: net@FreeBSD.org Subject: Re: DHCPv6 Support in FreeBSD Base From: Hiroki Sato In-Reply-To: <6224EC83-3A81-4CE7-83C5-674628F38958@DELL.com> References: <6224EC83-3A81-4CE7-83C5-674628F38958@DELL.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jun_10_07_08_22_2016_213)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 10 Jun 2016 07:10:14 +0900 (JST) X-Spam-Status: No, score=-96.6 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,RCVD_IN_AHBL,RCVD_IN_AHBL_PROXY,RCVD_IN_AHBL_SPAM,RCVD_IN_CHINA, RCVD_IN_CHINA_KR,RCVD_IN_TAIWAN,RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 09 Jun 2016 22:10:22 -0000 ----Security_Multipart(Fri_Jun_10_07_08_22_2016_213)-- Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 RGF2aWQgQnJpZ2h0IDxkYXZpZF9hX2JyaWdodEBkZWxsLmNvbT4gd3JvdGUNCiAgaW4gPDYyMjRF QzgzLTNBODEtNENFNy04M0M1LTY3NDYyOEYzODk1OEBERUxMLmNvbT46DQoNCmRhPiBGb2xsb3dp bmcgdXAgb24gYSBjb252ZXJzYXRpb24gSSBzdGFydGVkIHRvZGF5IGF0IEJTRENhbg0KZGE+IDIw MTYvRGV2U3VtbWl0Lg0KZGE+IA0KZGE+IEmiZCBsaWtlIHRvIHNlZSBzdXBwb3J0IGZvciBESENQ djYgaW4gdGhlIGJhc2Ugc3lzdGVtLiBJIGhhdmUgbWFkZQ0KZGE+IG1vZGlmaWNhdGlvbnMgdG8g bmV0d29yay5zdWJyIGFuZCB0aGUgcmMuZCBpbml0IHNjcmlwdHMgdG8gYWxsb3cNCmRhPiBjb25m aWd1cmluZyBhIG5ldHdvcmsgaW50ZXJmYWNlIHRvIHVzZSBESENQdjYgaW4gYSBtYW5uZXIgdmVy eSBzaW1pbGFyDQpkYT4gdG8gdGhhdCBjdXJyZW50bHkgdXNlZCBmb3IgREhDUHY0LiBUaGlzIHdv cmtzIGFzc3VtaW5nIHRoYXQgeW91IGhhdmUgYQ0KZGE+IERIQ1B2NiBjbGllbnQuIEZvciB0aGUg cHVycG9zZXMgb2YgbXkgZGV2ZWxvcG1lbnQgSSB1c2VkIHRoZSBJU0MNCmRhPiBjbGllbnQgZnJv bSBwb3J0cy4NCmRhPiANCmRhPiBUaGVzZSBjaGFuZ2VzIHdlcmUgYmFzZWQgb24gMTAuMC1SRUxF QVNFIGFuZCBJIGFtIGluIHRoZSBwcm9jZXNzIG9mDQpkYT4gYWRhcHRpbmcgdGhlc2UgY2hhbmdl cyB0byAxMSBzbyB0aGV5IGNhbiBiZSBwdXNoZWQgdXBzdHJlYW0uIEhvd2V2ZXIsDQpkYT4gdGhl eSB3aWxsIGJlIHVudXNhYmxlIChhbGJlaXQgaGFybWxlc3MpIGluIHRoZSBiYXNlIHN5c3RlbSB3 aXRob3V0IGENCmRhPiBjbGllbnQuDQpkYT4gDQpkYT4gKiBJcyB0aGVyZSBhbnkgYmFycmllciB0 byB1cGRhdGluZyB0aGUgZGhjbGllbnQgaW4gYmFzZSB0byB0aGUgY3VycmVudA0KZGE+ICogSVND IGRoY2xpZW50IGZvciBib3RoIERIQ1B2NCAmIERIQ1B2Nj8NCg0KIGRoY2xpZW50IGluIHRoZSBi YXNlIHN5c3RlbSB3YXMgZGl2ZXJnZWQgZnJvbSBJU0MgY29kZSBiYXNlIGxvbmcgdGltZQ0KIGFn by4gIFNvICJ1cGRhdGluZyBpdCIgaXMgbm90IHNvIHNpbXBsZS4gIEkgYW0gY29uY2VybmVkIHRo YXQgYnkNCiByZXBsYWNpbmcgaXQgY29tcGxldGVseSB3ZSBtaWdodCBiZSBnb2luZyB0byBsb3Nl IGFjY3VtdWxhdGVkDQogaW1wcm92ZW1lbnRzIGluIG91ciBjb2RlIHRob3VnaCBJIGRvIG5vdCBo YXZlIGEgY29tcGxldGUgbGlzdCBvZiB0aGVtDQogbm9yIGNsb3NlbHkgbG9vayBpbnRvIHRoZSBj dXJyZW50IElTQydzIGNvZGUuICBJZiBubyBvbmUgaW52ZXN0aWdhdGVkDQogaXQsIGl0IG5lZWQg dG8gYmUgZG9uZS4NCg0KZGE+ICogSXMgdGhlcmUgYW55IGJhcnJpZXIgdG8gcmVwbGFjaW5nIHRo ZSBjdXJyZW50IGRoY2xpZW50LXNjcmlwdCB3aXRoDQpkYT4gKiB0aGF0IHRoYXQgYWNjb21wYW5p ZXMgdGhlIElTQyBkaGNsaWVudD8NCmRhPiAgICAgVGhlIHR3byBzY3JpcHRzIGFyZSBxdWl0ZSBk aWZmZXJlbnQgYW5kIG15IERIQ1B2NiBjaGFuZ2VzIGN1cnJlbnRseQ0KZGE+ICAgICBhcmUgYmFz ZWQgb24gdGhlIElTQyBkaGNsaWVudC1zY3JpcHQuDQoNCiBJcyBpdCBkaWZmaWN1bHQgZm9yIHVz IHRvIHRoaW5rIHR3byBjbGllbnRzIGZvciBJUHY0IGFuZCBJUHY2DQogcmVzcGVjdGl2ZWx5PyAg SW1wb3J0aW5nIGEgREhDUHY2LW9ubHkgY2xpZW50IGxvb2tzIG11Y2ggZWFzaWVyIGV2ZW4NCiBp ZiB3ZSB1c2UgSVNDJ3MgY29kZS4NCg0KIEFuZCwgSSBwZXJzb25hbGx5IHRoaW5rIGEgc2ltaWxh ciB3YXkgdG8gbmV0d29yay5zdWJyIGZvciBjb25maWd1cmluZw0KIERIQ1B2NiBpcyBub3QgZW5v dWdoIGluIHByYWN0aWNlIGJlY2F1c2UgREhDUHY2IGNsaWVudCBpcyB0eXBpY2FsbHkNCiB0cmln Z2VyZWQgYnkgUkEgb3IgYSBjb21iaW5hdGlvbiB3aXRoIElQVjZDUCBpbiBQUFAuDQoNCiBJIGFs c28gbGlrZSB0byBzZWUgYSBESENQdjYgY2xpZW50IGluIHRoZSBiYXNlIHN5c3RlbSwgYnV0IEkg d291bGQNCiBsaWtlIHNvbWUgbW9yZSBkaXNjdXNzaW9uIGFib3V0IHdoaWNoIGltcGxlbWVudGF0 aW9ucyB3ZSBjYW4vd2FudCB0bw0KIHVzZSBhbmQgdHlwaWNhbCB1c2UgY2FzZXMgYmVmb3JlIGl0 IGhhcHBlbnMuICBQcm9iYWJseSBvdGhlcnMgaGF2ZQ0KIHRoZWlyIG93biBvcGluaW9uLg0KDQot LSBIaXJva2kNCg== ----Security_Multipart(Fri_Jun_10_07_08_22_2016_213)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAldZ6NYACgkQTyzT2CeTzy2jXgCgghFGk8CddZoeF7U+nQ9JHPG7 kmUAn1E9v3+4aJmcQbf8RgTl/rsrgwEn =sFzm -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_10_07_08_22_2016_213)---- From owner-freebsd-net@freebsd.org Fri Jun 10 02:54:58 2016 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 62001AEED0B for ; Fri, 10 Jun 2016 02:54:58 +0000 (UTC) (envelope-from david_a_bright@dell.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 4FB1916DA for ; Fri, 10 Jun 2016 02:54:58 +0000 (UTC) (envelope-from david_a_bright@dell.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4B90FAEED0A; Fri, 10 Jun 2016 02:54:58 +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 48F1CAEED09 for ; Fri, 10 Jun 2016 02:54:58 +0000 (UTC) (envelope-from david_a_bright@dell.com) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "ausxipmktps31.us.dell.com", Issuer "Verizon Public SureServer CA G14-SHA1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F345416D8; Fri, 10 Jun 2016 02:54:57 +0000 (UTC) (envelope-from david_a_bright@dell.com) X-Loopcount0: from 76.164.8.179 X-IronPort-AV: E=Sophos;i="5.26,448,1459832400"; d="scan'208";a="407641398" From: David Bright To: Hiroki Sato CC: "net@FreeBSD.org" Subject: Re: DHCPv6 Support in FreeBSD Base Thread-Topic: DHCPv6 Support in FreeBSD Base Thread-Index: AQHRwpPdKYzUv7bVe0CH0Y50DySuU5/iBYkAgABQAgA= Date: Fri, 10 Jun 2016 02:54:54 +0000 Message-ID: References: <6224EC83-3A81-4CE7-83C5-674628F38958@DELL.com> <20160610.070822.525071082322626267.hrs@allbsd.org> In-Reply-To: <20160610.070822.525071082322626267.hrs@allbsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.156.108.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <227128A1F126314985B108B8B250F522@compellent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 02:54:58 -0000 On Jun 9, 2016, at 18:08, Hiroki Sato wrote: >=20 > I am concerned that by > replacing it completely we might be going to lose accumulated > improvements in our code though I do not have a complete list of them > nor closely look into the current ISC's code. If no one investigated > it, it need to be done. A fair point. > Is it difficult for us to think two clients for IPv4 and IPv6 > respectively? Importing a DHCPv6-only client looks much easier even > if we use ISC's code. I thought of that. It certainly would be possible, although it would mean t= wo clients providing essentially duplicate functionality, thereby leading t= o some bloat in the system image size. --=20 David A. Bright Storage Development Principal Engineer Dell | Compellent office +1 952 392 5861 Cube J-731, 7615 Smetana Lane, Eden Prairie, MN 55344 David_A_Bright@DELL.com From owner-freebsd-net@freebsd.org Fri Jun 10 06:52:30 2016 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 18E5DB716EC; Fri, 10 Jun 2016 06:52:30 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [84.22.110.84]) by mx1.freebsd.org (Postfix) with ESMTP id DCEBD116F; Fri, 10 Jun 2016 06:52:29 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id 41B0E385528; Fri, 10 Jun 2016 08:52:25 +0200 (CEST) Date: Fri, 10 Jun 2016 08:52:25 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: And what about ipv6_defaultrouter? Message-ID: <20160610065224.GB2817@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 06:52:30 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, according to my provider, both the IPv6 and the default gateway for my virtual server are sent via router advertisements. So, I have the following in rc.conf: --------------------8<-------------------- ifconfig_vtnet0=3D"DHCP" ifconfig_vtnet0_ipv6=3D"inet6 accept_rtadv" rtsold_enable=3D"YES" -------------------->8-------------------- Although the machine gets an IPv6, the inet6 default route is not added. Why is that? Something else I need to include? (Interestingly, these were the default settings in rc.conf that I get with a fresh install =66rom my provider. Nevertheless, they don't seem to work.) Well, I thought "no problem" and added the following line: --------------------8<-------------------- ipv6_defaultrouter=3D"" -------------------->8-------------------- But still, after rebooting there is no default route visible when I `netstat -6rn`. Following this, the server is not connected via IPv6. However, if I run route -6 add default manually, the route will be added without problems and I get IPv6 connectivity. Why is that? Do I need an additional setting for the server to accept the advertised default route? Niklaas --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWmOhAAoJEG2fODeJrIU/cHMP/jpVntqrOTGNEKy3UZAGjwO7 i/p0zCj6iDIEK0GNSbUuUQyKkR9TfKhC+3v1JhB/tLQLo2gW2B/HMseWI3AbA0Vo OMOXzSmqVpQGXCwJP/TnWjQYNsvXZv3ExVpoEkSoKSpLilTC/wXrDIZQbF2OdRrz 0On2mmjhkJEJMWZjUhfunAS0wjDo2KecBXRxake3fTqgNQVhEScNbegURT0nNpw0 HliH1mFuGHy4M3bPW3rbZeh37nN+Cfgc/LACi2MDZ8TfBQm2E15MafcjOf2pR3XE JBS0OHZk9XF5OMVwqlfbvpIazJOmxIyMB9j8Uf5LUqs1gc13wQ+MjNuOrx278gYS YSY++c5PVtZIJFGrre2Od4GmN3XRoqIkJOEc4vSP5niHc+sU1ImiwxBGhyBmWx6j T5O5WxkMTNbL7huEKVofu2Jaf2AsJUsb6JdHu7L6pEJwVk4vNzBgwhpLmUucGHFi SL36pdxE/p5vnJy4NxOpiawPYsiDfDJo11KLifj0aBnX5denVoRe6esXODpbNhoA 1k2dtM9BE9589ISgqLWKq3NI8j6lojUscHQI0/do8r6Ot754OliVh9+62ioZyUx0 z9HokKSTQHEqHThOC56wKCmUWllaKU9lY3DFLEDJirk4WLEfELXaPjaVRekfC4dx ySlho1cM0ROtcP8Y1p61 =lbER -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From owner-freebsd-net@freebsd.org Fri Jun 10 07:12:58 2016 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 7E7F2B71B5B; Fri, 10 Jun 2016 07:12:58 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [IPv6:2a02:2770:15:0:21a:4aff:feaa:e902]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9ED1E93; Fri, 10 Jun 2016 07:12:58 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id 4A922385528; Fri, 10 Jun 2016 09:12:54 +0200 (CEST) Date: Fri, 10 Jun 2016 09:12:54 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: And what about ipv6_defaultrouter? Message-ID: <20160610071254.GC2817@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org References: <20160610065224.GB2817@box-hlm-03.niklaas.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline In-Reply-To: <20160610065224.GB2817@box-hlm-03.niklaas.eu> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 07:12:58 -0000 --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Niklaas Baudet von Gersdorff [2016-06-10 08:52 +0200] : > --------------------8<-------------------- > ifconfig_vtnet0="DHCP" > ifconfig_vtnet0_ipv6="inet6 accept_rtadv" > rtsold_enable="YES" > -------------------->8-------------------- [...] > --------------------8<-------------------- > ipv6_defaultrouter="" > -------------------->8-------------------- Plus these lines: --------------------8<-------------------- gateway_enable="YES" ipv6_gateway_enable="YES" -------------------->8-------------------- Niklaas --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWmhwAAoJEG2fODeJrIU/DmMP/iOITkHhxUffYDwFMgzNEFXi LeTTxAeQYNoDIRr+ywyIrriPMwY19MHQcw9pswQFuprdHxXzwuyLoxsLQmknWcov BSVlPHjx5CQDAYpcgK7lVDfPsDgwLD5ydQnHVKVjQhyO0/T6VEKJRSe60XR2PTXE qEGAGby9cr20y7hEHTY+MiqA3lYIT1OQlCREbcbaLbKVCTLDlT5l/7wr480CV4dp UXmthw5tOmdi/iYtJ5XNt6P44kJQowq53l2q5F0cqGhUQHxTRk6tcMF1987begbA dBxdFIOB4GO8NHFotRUmOfBAQYyPXgkZv9Oq3t3EPQoqxbbsnaYT+5/8NanRXMC7 tYzNhf90oFRK6pHCkqZ/IemP5nxbhtyJUFNAPMebaQ1DPrOgCllBIDyliNpIfHw3 7Xzu3uNQcsaeYqxGCe1oTTfBMTsutWvrV2ynl4kyB+qKbU7HDf1gNinl9hV2iPAp n4hsjzWY2ytQlf2wWEQhcbGiZuscPM1fmF8+emx+XAs+n1GWdXoMZ0yZJrvzhCyw yUB6WSnQt0C6fgGbQqDsSbTa80yUg525Med6oTL101Z7Yy4VW6DEykqqYrffFB1n eiJx/AGk8bzeQimi26GKGU+UNDfNv1srrGbZOq6utrdk4Nrgfrxu2SHTpmeHMUpT FMMFSzf26XL0iRwcK8mq =dSCb -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From owner-freebsd-net@freebsd.org Fri Jun 10 10:23:24 2016 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 8C89EB71123; Fri, 10 Jun 2016 10:23:24 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 271B1131E; Fri, 10 Jun 2016 10:23:24 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id m124so95635410wme.1; Fri, 10 Jun 2016 03:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=RoQApsBeSGaBqUZJ3tMsKRbTHaIkiJQZI27vqD98ZxE=; b=g+DtpYpHsJEV6Mpvwtkt6GV1EIWlnpdP0hBh2f85FVingdBKPOmEGD10XHwVeVI3oV bVztp7V0xHDuZm6yjAKUr7lLS8yJIvHYNY67W8UyGslYUXpags5mzUz4bmSMuuo9JOos c4mfiJPo9lHq3NxmUpdsJoCzQRsxve2u6EYunxKMl0w9J3aakJBJbH9hqjuSY44RNRVL FrJB5hVS8QeGcMByG+G1Di892XNo4752VEcIrnz+J5+lQ0sKq8kN/gHCGTX/VQ8BdvkH /EnAtk0XLllf6ZMUb7hf/lKZlKcifJEaQIylBe38rNwtHZEEbHJz8xZPo3Eyp6kBaMsX iFOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=RoQApsBeSGaBqUZJ3tMsKRbTHaIkiJQZI27vqD98ZxE=; b=OoNfYbspbOy+vgpuz5WW301MbjO6yeGwy0gMHjroaqBRBZEW1u8612bze+lJD1ac5h jT7DKHEzWM0q6iHiixb535giii4U9S6Xqy+Xna2UQymSqrgLNn5rh+uODA+uwqW8deVi zor2xKENySP/PJ9G3Jdh8lRW9TfwUxHV8hkjpUygNBYhrb7wktT3XkLI5wqFyHcucGyj SavNFALT8m5D+kwr0edLRqJn+EPuHlDkxUcdEXYXxwFYEPvecqVXIwMPk/uX93ciiVch trjZua7XP2El1f4tebpbLnD2DougB5Ex4Es+QCys87G2H2V10+WynvtyNs5ZhIrFU0uz 3mYA== X-Gm-Message-State: ALyK8tJQ7thKS06jOJ5dR1CfNCnDtXcRrhKi6A63H1SWbtZ0rDk9cY/aU/wkdHoi08nXdovEv/Ld6V7HOrMD9w== X-Received: by 10.28.142.144 with SMTP id q138mr2028873wmd.30.1465554201780; Fri, 10 Jun 2016 03:23:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.6.12 with HTTP; Fri, 10 Jun 2016 03:23:21 -0700 (PDT) In-Reply-To: <20160610071254.GC2817@box-hlm-03.niklaas.eu> References: <20160610065224.GB2817@box-hlm-03.niklaas.eu> <20160610071254.GC2817@box-hlm-03.niklaas.eu> From: krad Date: Fri, 10 Jun 2016 11:23:21 +0100 Message-ID: Subject: Re: And what about ipv6_defaultrouter? To: freebsd-net@freebsd.org, FreeBSD Questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 10:23:24 -0000 No, you should only need the if you want to act as a router for some other machines. gateway_enable="YES" ipv6_gateway_enable="YES" The following should only be required for normal ipv6 ifconfig_vtnet0_ipv6="inet6 accept_rtadv" rtsold_enable="YES" Have a look at these variables, and make sure they are set correctly or on defaults ipv6_network_interfaces=vtnet0 or ipv6_activate_all_interfaces=yes Also make sure the nic is actually up ie do and ifconfig vtnet0 up On 10 June 2016 at 08:12, Niklaas Baudet von Gersdorff wrote: > Niklaas Baudet von Gersdorff [2016-06-10 08:52 +0200] : > > > --------------------8<-------------------- > > ifconfig_vtnet0="DHCP" > > ifconfig_vtnet0_ipv6="inet6 accept_rtadv" > > rtsold_enable="YES" > > -------------------->8-------------------- > [...] > > --------------------8<-------------------- > > ipv6_defaultrouter="" > > -------------------->8-------------------- > > Plus these lines: > > --------------------8<-------------------- > gateway_enable="YES" > ipv6_gateway_enable="YES" > -------------------->8-------------------- > > Niklaas > From owner-freebsd-net@freebsd.org Fri Jun 10 10:23:51 2016 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 B9ED2B71196; Fri, 10 Jun 2016 10:23:51 +0000 (UTC) (envelope-from kraduk@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 4A79314A3; Fri, 10 Jun 2016 10:23:51 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id v199so142533780wmv.0; Fri, 10 Jun 2016 03:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=kQCzvnAEN4Cc6VmVrQoD8vhxGnu/yYO42MW7cmXXq/o=; b=Ksx38M8DrpNafMzp8oHd9gdk1+McfAgXzobmG3C2iJur64iq5wwmsjgSST8pynSdfG yhceychJ1yo5oEd3aDEQKZDjzblFRoafXSLAdkH7Sm260KBe8FMlENxz/SeQTfuEBxVF r0blQrUATnJp5tqdW4EDUjNJjHvgpRunqfpT5OFnCscmojfDC0xzZAwduSdntQkMQjcT 80oWGvqaebBFeCYQseeIbLtUFWQ4XpIMf8p1yIYtvoFhyebqpYZfF5+jZYC7OL16q9Xo CLWFtE4aWe9klB2yjCzTfgiJtGVblKODfSj+h7357CoptqVrA0QsCYf7cfPeso7EZZvY A/gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kQCzvnAEN4Cc6VmVrQoD8vhxGnu/yYO42MW7cmXXq/o=; b=D9L3CqsCktmDmJH47JAXBcwQ3YTVoqKNO1qjfk4TNCc2AC3tVZsmapiQ2eRpdREP9i 9ZRpXMOEgPKKrP/ay5OG224AgIu6ceKUvdtLyfFlxKw7UWIGm9S7ZDCtXSHO3dRztTnb GEUAQyG2A1oYUhk6cxy9f+jL/u8c5OSScqPWH8Olb3uhb+g8x0UuSaL+uz4IOCBTg6vM WvvH3BpCC1sYDub/zwXwWwuvIALfM2gFpUbqJeEzH0byArKWPLF+/+GlAWzoZ1S8ADmY lA0QR7zyZA4rykJQFIO1gxsWJSb5R5tvcJXXMgc1JTfoXTGJ80JFpW5Ub8D/xEeAcnvk uyOQ== X-Gm-Message-State: ALyK8tI3edH9nEc+56QZ3ZMVTUle3MsiiXg/sKpS+DAOJbFk3MVM34fbkLExO38kT5tp6QRAZLrSmFmATt0Z/Q== X-Received: by 10.195.11.103 with SMTP id eh7mr1460367wjd.56.1465554229874; Fri, 10 Jun 2016 03:23:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.6.12 with HTTP; Fri, 10 Jun 2016 03:23:49 -0700 (PDT) In-Reply-To: References: <20160610065224.GB2817@box-hlm-03.niklaas.eu> <20160610071254.GC2817@box-hlm-03.niklaas.eu> From: krad Date: Fri, 10 Jun 2016 11:23:49 +0100 Message-ID: Subject: Re: And what about ipv6_defaultrouter? To: freebsd-net@freebsd.org, FreeBSD Questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 10:23:51 -0000 also dont forget to check in rc.conf.local as well as rc.conf On 10 June 2016 at 11:23, krad wrote: > No, you should only need the if you want to act as a router for some other > machines. > > gateway_enable="YES" > ipv6_gateway_enable="YES" > > The following should only be required for normal ipv6 > > ifconfig_vtnet0_ipv6="inet6 accept_rtadv" > rtsold_enable="YES" > > Have a look at these variables, and make sure they are set correctly or on > defaults > > ipv6_network_interfaces=vtnet0 > or > ipv6_activate_all_interfaces=yes > > > Also make sure the nic is actually up ie do and ifconfig vtnet0 up > > On 10 June 2016 at 08:12, Niklaas Baudet von Gersdorff > wrote: > >> Niklaas Baudet von Gersdorff [2016-06-10 08:52 +0200] : >> >> > --------------------8<-------------------- >> > ifconfig_vtnet0="DHCP" >> > ifconfig_vtnet0_ipv6="inet6 accept_rtadv" >> > rtsold_enable="YES" >> > -------------------->8-------------------- >> [...] >> > --------------------8<-------------------- >> > ipv6_defaultrouter="" >> > -------------------->8-------------------- >> >> Plus these lines: >> >> --------------------8<-------------------- >> gateway_enable="YES" >> ipv6_gateway_enable="YES" >> -------------------->8-------------------- >> >> Niklaas >> > > From owner-freebsd-net@freebsd.org Fri Jun 10 10:31:58 2016 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 D139AB714D2; Fri, 10 Jun 2016 10:31:58 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [84.22.110.84]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD4A1BA7; Fri, 10 Jun 2016 10:31:58 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id 9086D385528; Fri, 10 Jun 2016 12:31:54 +0200 (CEST) Date: Fri, 10 Jun 2016 12:31:54 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, FreeBSD Questions Subject: Re: And what about ipv6_defaultrouter? Message-ID: <20160610103154.GD2817@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, FreeBSD Questions MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NtwzykIc2mflq5ck" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 10:31:58 -0000 --NtwzykIc2mflq5ck Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable krad [2016-06-10 11:23 +0100] : > No, you should only need the if you want to act as a router for some other > machines. >=20 > gateway_enable=3D"YES" > ipv6_gateway_enable=3D"YES" I need these for jails that are connected on lo1 and a VPN tunnel on tap0. Sorry, in case that was essential information that I did not provide. Does that change your recommendations? krad [2016-06-10 11:23 +0100] : > also dont forget to check in rc.conf.local as well as rc.conf I will look into these... Niklaas --NtwzykIc2mflq5ck Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWpcSAAoJEG2fODeJrIU/FpQP/i0VufzQ//XvwK7cDbDNXsGA PsAZzOBy8geBx1yig48jcpc1DRm+1qUUYvMgHuBOKQ5udFnGdG9zT/qidJ9/6W7y nwQ1eKUGZ6N97LdHcPZ2tmTNiiwgcM1A61WWEmDiUtGp1qMJXCTJw7HwWK3OKRYc 5xMJbzK60UNKt14mJwCGwwP9IWPBq2FfyX4Ct5vfMMyS4rHtgMCpwrEWS9Gm9O8n 5lCeU4xb+ibPBpaPTiyDrW4Io2ev8r06YrZzOFYmmeuhBLX/zaSNDj3x4a2nZdre gJcRgJ7fSQUbF1Tb7Hzx0TlZG5HR923Hf0WFvaEEVTMV1JOvX2sbp26OZsjse7Oh GsZ/ZKN2V+xHK/DKyinLOgBjwYgacSg6K4BLGp6A67u21uMjJ3IzDsR/fjblg5M4 1HhoRB9DOrpvgZ9VjUESSWUspdXtfP/8WvjxIKRH/o3R/xZFp0usDTnBYV/WrKHG Q97CYLlWRKO3JugichyLxVm8Wsv6qcuW2Dx5iiOeFiJN/kqSoGO/EsBPfqvQOGyW MXB664t+S5zKY6wcQoU0SBU+w2niKzIFRFRH8yGumMfjgLUqHDzV0vWk7d/3qJsi LiUc7y3laXuOCgAUHWQOJUIxZplNgNbV+9RqRA4hlfDNbE4wUWTKCqmYH50A5nQy kfuWtDpJvZXx7WyAUDmx =k1AE -----END PGP SIGNATURE----- --NtwzykIc2mflq5ck-- From owner-freebsd-net@freebsd.org Fri Jun 10 11:46:56 2016 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 A0F3AB7117B for ; Fri, 10 Jun 2016 11:46:56 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9001BA5 for ; Fri, 10 Jun 2016 11:46:54 +0000 (UTC) (envelope-from arnaud.ysmal@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id A14AF3761041; Fri, 10 Jun 2016 13:43:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 93FBD37612B6; Fri, 10 Jun 2016 13:43:58 +0200 (CEST) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xX1rNv0D7nGv; Fri, 10 Jun 2016 13:43:58 +0200 (CEST) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 80E533761041; Fri, 10 Jun 2016 13:43:58 +0200 (CEST) Date: Fri, 10 Jun 2016 13:43:58 +0200 (CEST) From: Arnaud YSMAL To: Eric Joyner Cc: freebsd-net@freebsd.org Message-ID: <406543187.3842832.1465559038225.JavaMail.zimbra@stormshield.eu> In-Reply-To: References: <494678734.3111275.1465379076220.JavaMail.zimbra@stormshield.eu> Subject: Re: [Patch] Changing mac address does not always work MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3842830_249408216.1465559038223" Thread-Topic: Changing mac address does not always work Thread-Index: X+BsUW4y0Go8LhWhbG7Mahn3vgds4Q== X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 11:46:56 -0000 ------=_Part_3842830_249408216.1465559038223 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you, you can find enclosed a patch following your suggestion. ----- Le 8 Juin 16, =C3=A0 22:40, Eric Joyner ricera10@gmail.com a =C3=A9cr= it : > I think a better fix here is to have the driver not call init_locked() wh= en > the driver is not running when setting the MTU. >=20 > It looks like all the other Intel network drivers do the same thing as th= is > for the MTU. >=20 > On Wed, Jun 8, 2016 at 2:47 AM Arnaud YSMAL > wrote: >=20 >> Hi, >> >> Configuring the network card with the following commands (in this specif= ic >> order) does not work. >> # ifconfig em0 down >> # ifconfig em0 mtu 1500 >> # ifconfig em0 ether 12:34:56:12:34:56 >> # ifconfig em0 192.168.1.1/24 >> # ifconfig em0 up >> >> I was able to reproduce this issue on 10.3-RELEASE and HEAD with ix and = em >> drivers. >> >> From what I understand: >> - When setting the mtu, the driver calls the init of the interface which >> sets the IFF_DRV_RUNNING flag >> - When setting the mac address, if_setlladdr (from if.c) copy the mac >> address but does nothing else (the interface is not up) >> - When setting the ip address, the driver does not call the init as the >> IFF_DRV_RUNNING is already set. >> - When setting the up flag, same as above, the IFF_DRV_RUNNING is alread= y >> set. >> >> In this case the network card does not work as the mac address filter is >> not up to date. >> >> The enclosed path fixes this issue, >> It changes if_setlladdr in if.c to call the ifp->if_ioctl function with >> the IFF_UP flag clear even when the interface is not up. >> The driver will then call its stop function which clear the >> IFF_DRV_RUNNING. >> The init will be called when setting the ip address or the up flag. >> >> Do you have any advice regarding this patch? >> >> Arnaud_______________________________________________ >> 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" ------=_Part_3842830_249408216.1465559038223 Content-Type: text/x-patch; name=fix_init_on_set_mtu.patch Content-Disposition: attachment; filename=fix_init_on_set_mtu.patch Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3N5cy9kZXYvZTEwMDAvaWZfZW0uYyBiL3N5cy9kZXYvZTEwMDAvaWZfZW0u YwppbmRleCAxNGY1NDYzLi5kZGQ2NTFkIDEwMDY0NAotLS0gYS9zeXMvZGV2L2UxMDAwL2lmX2Vt LmMKKysrIGIvc3lzL2Rldi9lMTAwMC9pZl9lbS5jCkBAIC0xMjE0LDcgKzEyMTQsOCBAQCBlbV9p b2N0bChpZl90IGlmcCwgdV9sb25nIGNvbW1hbmQsIGNhZGRyX3QgZGF0YSkKIAkJaWZfc2V0bXR1 KGlmcCwgaWZyLT5pZnJfbXR1KTsKIAkJYWRhcHRlci0+aHcubWFjLm1heF9mcmFtZV9zaXplID0K IAkJICAgIGlmX2dldG10dShpZnApICsgRVRIRVJfSERSX0xFTiArIEVUSEVSX0NSQ19MRU47Ci0J CWVtX2luaXRfbG9ja2VkKGFkYXB0ZXIpOworCQlpZiAoaWZfZ2V0ZHJ2ZmxhZ3MoaWZwKSAmIElG Rl9EUlZfUlVOTklORykKKwkJCWVtX2luaXRfbG9ja2VkKGFkYXB0ZXIpOwogCQlFTV9DT1JFX1VO TE9DSyhhZGFwdGVyKTsKIAkJYnJlYWs7CiAJICAgIH0KZGlmZiAtLWdpdCBhL3N5cy9kZXYvZTEw MDAvaWZfaWdiLmMgYi9zeXMvZGV2L2UxMDAwL2lmX2lnYi5jCmluZGV4IDgzZTFlODMuLmVmNTI1 NmYgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvZTEwMDAvaWZfaWdiLmMKKysrIGIvc3lzL2Rldi9lMTAw MC9pZl9pZ2IuYwpAQCAtMTEwNiw3ICsxMTA2LDggQEAgaWdiX2lvY3RsKHN0cnVjdCBpZm5ldCAq aWZwLCB1X2xvbmcgY29tbWFuZCwgY2FkZHJfdCBkYXRhKQogCQlpZnAtPmlmX210dSA9IGlmci0+ aWZyX210dTsKIAkJYWRhcHRlci0+bWF4X2ZyYW1lX3NpemUgPQogCQkgICAgaWZwLT5pZl9tdHUg KyBFVEhFUl9IRFJfTEVOICsgRVRIRVJfQ1JDX0xFTjsKLQkJaWdiX2luaXRfbG9ja2VkKGFkYXB0 ZXIpOworCQlpZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSkKKwkJCWln Yl9pbml0X2xvY2tlZChhZGFwdGVyKTsKIAkJSUdCX0NPUkVfVU5MT0NLKGFkYXB0ZXIpOwogCQli cmVhazsKIAkgICAgfQpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9lMTAwMC9pZl9sZW0uYyBiL3N5cy9k ZXYvZTEwMDAvaWZfbGVtLmMKaW5kZXggNTBiMmNiMC4uNTViODMxMCAxMDA2NDQKLS0tIGEvc3lz L2Rldi9lMTAwMC9pZl9sZW0uYworKysgYi9zeXMvZGV2L2UxMDAwL2lmX2xlbS5jCkBAIC0xMDUz LDcgKzEwNTMsOCBAQCBsZW1faW9jdGwoaWZfdCBpZnAsIHVfbG9uZyBjb21tYW5kLCBjYWRkcl90 IGRhdGEpCiAJCWlmX3NldG10dShpZnAsIGlmci0+aWZyX210dSk7CiAJCWFkYXB0ZXItPm1heF9m cmFtZV9zaXplID0KIAkJICAgIGlmX2dldG10dShpZnApICsgRVRIRVJfSERSX0xFTiArIEVUSEVS X0NSQ19MRU47Ci0JCWxlbV9pbml0X2xvY2tlZChhZGFwdGVyKTsKKwkJaWYgKChpZl9nZXRkcnZm bGFncyhpZnApICYgSUZGX0RSVl9SVU5OSU5HKSkKKwkJCWxlbV9pbml0X2xvY2tlZChhZGFwdGVy KTsKIAkJRU1fQ09SRV9VTkxPQ0soYWRhcHRlcik7CiAJCWJyZWFrOwogCSAgICB9CmRpZmYgLS1n aXQgYS9zeXMvZGV2L2l4Z2IvaWZfaXhnYi5jIGIvc3lzL2Rldi9peGdiL2lmX2l4Z2IuYwppbmRl eCA0ZWY0OTI5Li40ZGIyNzJjIDEwMDY0NAotLS0gYS9zeXMvZGV2L2l4Z2IvaWZfaXhnYi5jCisr KyBiL3N5cy9kZXYvaXhnYi9pZl9peGdiLmMKQEAgLTUzOSw3ICs1MzksOCBAQCBpeGdiX2lvY3Rs KHN0cnVjdCBpZm5ldCAqIGlmcCwgSU9DVExfQ01EX1RZUEUgY29tbWFuZCwgY2FkZHJfdCBkYXRh KQogCQkJYWRhcHRlci0+aHcubWF4X2ZyYW1lX3NpemUgPQogCQkJCWlmcC0+aWZfbXR1ICsgRVRI RVJfSERSX0xFTiArIEVUSEVSX0NSQ19MRU47CiAKLQkJCWl4Z2JfaW5pdF9sb2NrZWQoYWRhcHRl cik7CisJCQlpZiAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpCisJCQkJaXhn Yl9pbml0X2xvY2tlZChhZGFwdGVyKTsKIAkJCUlYR0JfVU5MT0NLKGFkYXB0ZXIpOwogCQl9CiAJ CWJyZWFrOwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9peGdiZS9pZl9peC5jIGIvc3lzL2Rldi9peGdi ZS9pZl9peC5jCmluZGV4IGRkZWU2OTkuLmNmMjIzMWQgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvaXhn YmUvaWZfaXguYworKysgYi9zeXMvZGV2L2l4Z2JlL2lmX2l4LmMKQEAgLTg5Myw3ICs4OTMsOCBA QCBpeGdiZV9pb2N0bChzdHJ1Y3QgaWZuZXQgKiBpZnAsIHVfbG9uZyBjb21tYW5kLCBjYWRkcl90 IGRhdGEpCiAJCQlpZnAtPmlmX210dSA9IGlmci0+aWZyX210dTsKIAkJCWFkYXB0ZXItPm1heF9m cmFtZV9zaXplID0KIAkJCQlpZnAtPmlmX210dSArIElYR0JFX01UVV9IRFI7Ci0JCQlpeGdiZV9p bml0X2xvY2tlZChhZGFwdGVyKTsKKwkJCWlmIChpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZf UlVOTklORykKKwkJCQlpeGdiZV9pbml0X2xvY2tlZChhZGFwdGVyKTsKICNpZmRlZiBQQ0lfSU9W CiAJCQlpeGdiZV9yZWNhbGN1bGF0ZV9tYXhfZnJhbWUoYWRhcHRlcik7CiAjZW5kaWYKZGlmZiAt LWdpdCBhL3N5cy9kZXYvaXhnYmUvaWZfaXh2LmMgYi9zeXMvZGV2L2l4Z2JlL2lmX2l4di5jCmlu ZGV4IDEzYzJiZWYuLjgwZmIxYjMgMTAwNjQ0Ci0tLSBhL3N5cy9kZXYvaXhnYmUvaWZfaXh2LmMK KysrIGIvc3lzL2Rldi9peGdiZS9pZl9peHYuYwpAQCAtNTc4LDcgKzU3OCw4IEBAIGl4dl9pb2N0 bChzdHJ1Y3QgaWZuZXQgKiBpZnAsIHVfbG9uZyBjb21tYW5kLCBjYWRkcl90IGRhdGEpCiAJCQlp ZnAtPmlmX210dSA9IGlmci0+aWZyX210dTsKIAkJCWFkYXB0ZXItPm1heF9mcmFtZV9zaXplID0K IAkJCQlpZnAtPmlmX210dSArIElYR0JFX01UVV9IRFI7Ci0JCQlpeHZfaW5pdF9sb2NrZWQoYWRh cHRlcik7CisJCQlpZiAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpCisJCQkJ aXh2X2luaXRfbG9ja2VkKGFkYXB0ZXIpOwogCQkJSVhHQkVfQ09SRV9VTkxPQ0soYWRhcHRlcik7 CiAJCX0KIAkJYnJlYWs7CmRpZmYgLS1naXQgYS9zeXMvZGV2L2l4bC9pZl9peGwuYyBiL3N5cy9k ZXYvaXhsL2lmX2l4bC5jCmluZGV4IGQ3NTljZmQuLjhlOWJhODAgMTAwNjQ0Ci0tLSBhL3N5cy9k ZXYvaXhsL2lmX2l4bC5jCisrKyBiL3N5cy9kZXYvaXhsL2lmX2l4bC5jCkBAIC05ODAsNyArOTgw LDggQEAgaXhsX2lvY3RsKHN0cnVjdCBpZm5ldCAqIGlmcCwgdV9sb25nIGNvbW1hbmQsIGNhZGRy X3QgZGF0YSkKIAkJCXZzaS0+bWF4X2ZyYW1lX3NpemUgPQogCQkJCWlmcC0+aWZfbXR1ICsgRVRI RVJfSERSX0xFTiArIEVUSEVSX0NSQ19MRU4KIAkJCSAgICArIEVUSEVSX1ZMQU5fRU5DQVBfTEVO OwotCQkJaXhsX2luaXRfbG9ja2VkKHBmKTsKKwkJCWlmIChpZnAtPmlmX2Rydl9mbGFncyAmIElG Rl9EUlZfUlVOTklORykKKwkJCQlpeGxfaW5pdF9sb2NrZWQocGYpOwogCQkJSVhMX1BGX1VOTE9D SyhwZik7CiAJCX0KIAkJYnJlYWs7CmRpZmYgLS1naXQgYS9zeXMvZGV2L2l4bC9pZl9peGx2LmMg Yi9zeXMvZGV2L2l4bC9pZl9peGx2LmMKaW5kZXggOWU1MjQyYy4uOWJlOGEzNiAxMDA2NDQKLS0t IGEvc3lzL2Rldi9peGwvaWZfaXhsdi5jCisrKyBiL3N5cy9kZXYvaXhsL2lmX2l4bHYuYwpAQCAt Njc2LDcgKzY3Niw4IEBAIGl4bHZfaW9jdGwoc3RydWN0IGlmbmV0ICppZnAsIHVfbG9uZyBjb21t YW5kLCBjYWRkcl90IGRhdGEpCiAJCQl2c2ktPm1heF9mcmFtZV9zaXplID0KIAkJCSAgICBpZnAt PmlmX210dSArIEVUSEVSX0hEUl9MRU4gKyBFVEhFUl9DUkNfTEVOCiAJCQkgICAgKyBFVEhFUl9W TEFOX0VOQ0FQX0xFTjsKLQkJCWl4bHZfaW5pdF9sb2NrZWQoc2MpOworCQkJaWYgKGlmcC0+aWZf ZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKQorCQkJCWl4bHZfaW5pdF9sb2NrZWQoc2MpOwog CQl9CiAJCW10eF91bmxvY2soJnNjLT5tdHgpOwogCQlicmVhazsK ------=_Part_3842830_249408216.1465559038223-- From owner-freebsd-net@freebsd.org Fri Jun 10 11:48:56 2016 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 4A1ADB71200; Fri, 10 Jun 2016 11:48:56 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 D7D4A1C9F; Fri, 10 Jun 2016 11:48:55 +0000 (UTC) (envelope-from kraduk@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id m124so98513492wme.1; Fri, 10 Jun 2016 04:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7QBy4uZqMxTA16f5k49mY0sIbIvVAYvKJ6rTplM47w4=; b=jHjD7iGmxaHE9rHSPBL8wHNHc5ezQLxvEOAABT1PF3SZD0i1jq2QxEZCUyTnJxLloa 6TKPahGP7PgCY4p/GhIOYfcibYgoHxAAp429+hph60ezNOvMJTUlTRDxUBU52xyhnRSG mm8K+iUTsqS/pnG5ZTWtR7NRbTihYdi5FZbHgLV6VPbYqkVyfp5HBckIDU8yyMVSz3ot /k7dsy9gQFx9EE1Fdyu7lBFyPTnyI5jHWSoD+4RyXADiQzWWV/S/OFBFflRlrUGnhzjI bV3wn3gCyzlxr1RZIf/46rX8bJfXw5xNMBJ+vqr65XgTjjxGeMTW6MRhlOTjWquLokr4 Z98A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7QBy4uZqMxTA16f5k49mY0sIbIvVAYvKJ6rTplM47w4=; b=kXbxWu3qRs4rZCaD9kF9udUg5cmpySk0xL9zD45TwD1wVOlaBmlDe1uO0+B2jzUMD0 N+YxVFpTUttVVdQHQEBw3Fwh25NHGmeRDBHhc8GfNH6eJb0LAE8StUuWPVu7cRT6kwqI gv8SRW+mxegEhzV840JvvtzxJqV87DqGr6fcf6Yl5FhDeppJs0BnwvFYsywgq/LPA2ZU dlvIq8OOJeJXLdpJZlpzPnJT1cIQKIKtaeMWZdsHMZeUbPhSVidAqvJCmJv1oik6e4Uk cX82wnsxyUUKf65wjSkEXBHKB6BgB/FIqbm4vhUvO/Kl9guM0O6FTnIV5E2eBr8AlYr5 GMMw== X-Gm-Message-State: ALyK8tLkxceYKoeHjixFLgaSA9hyI/HqJUHQqcFSJQuGeQZyodOfhJNMfPBnsnW5+wkCjg0eoBosNoBlGISuNw== X-Received: by 10.28.155.196 with SMTP id d187mr2459743wme.30.1465559334421; Fri, 10 Jun 2016 04:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.6.12 with HTTP; Fri, 10 Jun 2016 04:48:53 -0700 (PDT) In-Reply-To: <20160610103154.GD2817@box-hlm-03.niklaas.eu> References: <20160610103154.GD2817@box-hlm-03.niklaas.eu> From: krad Date: Fri, 10 Jun 2016 12:48:53 +0100 Message-ID: Subject: Re: And what about ipv6_defaultrouter? To: freebsd-net@freebsd.org, FreeBSD Questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 11:48:56 -0000 i cant remember exactly but i dont think you need them for jails either unless they are vnet ones (depending on your topology). I could be wrong on that though. On 10 June 2016 at 11:31, Niklaas Baudet von Gersdorff wrote: > krad [2016-06-10 11:23 +0100] : > > > No, you should only need the if you want to act as a router for some > other > > machines. > > > > gateway_enable="YES" > > ipv6_gateway_enable="YES" > > I need these for jails that are connected on lo1 and a VPN tunnel on > tap0. Sorry, in case that was essential information that I did not > provide. Does that change your recommendations? > > krad [2016-06-10 11:23 +0100] : > > > also dont forget to check in rc.conf.local as well as rc.conf > > I will look into these... > > Niklaas > From owner-freebsd-net@freebsd.org Fri Jun 10 13:53:07 2016 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 5834DB70182; Fri, 10 Jun 2016 13:53:07 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84B311127; Fri, 10 Jun 2016 13:53:06 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org ([IPv6:2400:402e:a012:6300:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id u5ADqfM6009802 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Fri, 10 Jun 2016 22:52:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org ([IPv6:2400:402e:a012:6300:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id u5ADqffS086759 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jun 2016 22:52:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id u5ADqb7K086756; Fri, 10 Jun 2016 22:52:40 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 10 Jun 2016 22:50:31 +0900 (JST) Message-Id: <20160610.225031.1318863285679295699.hrs@allbsd.org> To: stdin@niklaas.eu Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: And what about ipv6_defaultrouter? From: Hiroki Sato In-Reply-To: <20160610071254.GC2817@box-hlm-03.niklaas.eu> References: <20160610065224.GB2817@box-hlm-03.niklaas.eu> <20160610071254.GC2817@box-hlm-03.niklaas.eu> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jun_10_22_50_31_2016_828)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 10 Jun 2016 22:52:58 +0900 (JST) X-Spam-Status: No, score=-96.6 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,RCVD_IN_AHBL,RCVD_IN_AHBL_PROXY,RCVD_IN_AHBL_SPAM,RCVD_IN_CHINA, RCVD_IN_CHINA_KR,RCVD_IN_TAIWAN,RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 13:53:07 -0000 ----Security_Multipart(Fri_Jun_10_22_50_31_2016_828)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Niklaas Baudet von Gersdorff wrote in <20160610071254.GC2817@box-hlm-03.niklaas.eu>: st> Niklaas Baudet von Gersdorff [2016-06-10 08:52 +0200] : st> st> > --------------------8<-------------------- st> > ifconfig_vtnet0="DHCP" st> > ifconfig_vtnet0_ipv6="inet6 accept_rtadv" st> > rtsold_enable="YES" st> > -------------------->8-------------------- st> [...] st> > --------------------8<-------------------- st> > ipv6_defaultrouter="" st> > -------------------->8-------------------- st> st> Plus these lines: st> st> --------------------8<-------------------- st> gateway_enable="YES" st> ipv6_gateway_enable="YES" st> -------------------->8-------------------- A router does not accept RAs (more strictly, default route information in RA) because it is a sender of RAs. However, some devices such as CPE need to behave like a host for the uplink and a router for the LAN. In that case, an interface on the WAN side has to accept RAs and one on the LAN side has to send RAs. On FreeBSD, there is a knob to support it. Set the following variable to rc.conf in addition to your current configuration: ipv6_cpe_wanif="vtnet0" This touches some per-IF flags and sysctls. For more complex configurations such as having two or more uplinks you need to set them manually, but if you have only one uplink the above variable should do the trick. And, $rtsold_enable is not required unless you want to get DNS server information from RAs. -- Hiroki ----Security_Multipart(Fri_Jun_10_22_50_31_2016_828)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAldaxacACgkQTyzT2CeTzy3RVQCg0tDzc6mr49Vo7ixexi3JETZG m70AnjAG7p2A8ZNmunxxJQX3tDFQ7sT2 =esrc -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_10_22_50_31_2016_828)---- From owner-freebsd-net@freebsd.org Fri Jun 10 17:06:28 2016 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 BD001AD9E05 for ; Fri, 10 Jun 2016 17:06:28 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id AA2CC2F68 for ; Fri, 10 Jun 2016 17:06:28 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: by mailman.ysv.freebsd.org (Postfix) id A98C4AD9E04; Fri, 10 Jun 2016 17:06:28 +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 A934BAD9E03 for ; Fri, 10 Jun 2016 17:06:28 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [IPv6:2607:f740:c::4ae]) (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 921572F67 for ; Fri, 10 Jun 2016 17:06:28 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from chombo.houseloki.net (unknown [IPv6:2601:1c2:1402:3a86:21c:c0ff:fe7f:96ee]) by echo.brtsvcs.net (Postfix) with ESMTPS id 31A585001C; Fri, 10 Jun 2016 17:06:21 +0000 (UTC) Received: from [IPv6:2601:1c2:1402:3a86:3c4b:52fa:e9fd:a39a] (unknown [IPv6:2601:1c2:1402:3a86:3c4b:52fa:e9fd:a39a]) by chombo.houseloki.net (Postfix) with ESMTPSA id 3B25718DF; Fri, 10 Jun 2016 10:06:20 -0700 (PDT) Subject: Re: DHCPv6 Support in FreeBSD Base To: David Bright , "net@FreeBSD.org" References: <6224EC83-3A81-4CE7-83C5-674628F38958@DELL.com> Reply-To: net@FreeBSD.org From: Mel Pilgrim Message-ID: <4a318c6c-ab03-e63c-979f-502bc2afb97e@bluerosetech.com> Date: Fri, 10 Jun 2016 10:06:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <6224EC83-3A81-4CE7-83C5-674628F38958@DELL.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 17:06:28 -0000 On 2016-06-09 14:14, David Bright wrote: > Following up on a conversation I started today at BSDCan > 2016/DevSummit. > > I’d like to see support for DHCPv6 in the base system. I have made > modifications to network.subr and the rc.d init scripts to allow > configuring a network interface to use DHCPv6 in a manner very > similar to that currently used for DHCPv4. This works assuming that > you have a DHCPv6 client. For the purposes of my development I used > the ISC client from ports. > > These changes were based on 10.0-RELEASE and I am in the process of > adapting these changes to 11 so they can be pushed upstream. However, > they will be unusable (albeit harmless) in the base system without a > client. > > * Is there any barrier to updating the dhclient in base to the > current ISC dhclient for both DHCPv4 & DHCPv6? > > * Is there any barrier to replacing the current dhclient-script with > that that accompanies the ISC dhclient? The two scripts are quite > different and my DHCPv6 changes currently are based on the ISC > dhclient-script. > > As I’ve already done a fair amount of this work, I’d be happy to work > on getting it in shape for pushing to HEAD. I had several people > today at the devsummit indicate that they thought that would be a > good idea, but I thought it would be a good idea to ask ahead of time > if there were any known stumbling blocks to doing that. Could the WIDE client be used instead? Unlike the ISC client, it will configure downstream interfaces from PD prefixes without needing an external script. It also completely avoids the problem of trying to update the in-base dhclient. From owner-freebsd-net@freebsd.org Fri Jun 10 19:18:32 2016 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 7FA0DAD97BD; Fri, 10 Jun 2016 19:18:32 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [IPv6:2a02:2770:15:0:21a:4aff:feaa:e902]) by mx1.freebsd.org (Postfix) with ESMTP id 4C82B2F36; Fri, 10 Jun 2016 19:18:32 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id 2AD46385569; Fri, 10 Jun 2016 21:18:28 +0200 (CEST) Date: Fri, 10 Jun 2016 21:18:28 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: And what about ipv6_defaultrouter? Message-ID: <20160610191828.GE2817@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org References: <20160610065224.GB2817@box-hlm-03.niklaas.eu> <20160610071254.GC2817@box-hlm-03.niklaas.eu> <20160610.225031.1318863285679295699.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="84ND8YJRMFlzkrP4" Content-Disposition: inline In-Reply-To: <20160610.225031.1318863285679295699.hrs@allbsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 19:18:32 -0000 --84ND8YJRMFlzkrP4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hiroki Sato [2016-06-10 22:50 +0900] : > A router does not accept RAs (more strictly, default route > information in RA) because it is a sender of RAs. However, some > devices such as CPE need to behave like a host for the uplink and a > router for the LAN. In that case, an interface on the WAN side has > to accept RAs and one on the LAN side has to send RAs. >=20 > On FreeBSD, there is a knob to support it. Set the following > variable to rc.conf in addition to your current configuration: >=20 > ipv6_cpe_wanif=3D"vtnet0" Thanks a lot for pointing that out! I think I read about the variable somewhere but I was not sure what it actually does. Is there some place where I can find more detailed explanation about rc.conf and sysctl settings except man? > And, $rtsold_enable is not required unless you want to get DNS server > information from RAs. Okay, great. I did not know that. Very nice layout for writing emails by the way. Niklaas --84ND8YJRMFlzkrP4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWxJ+AAoJEG2fODeJrIU/pOIP/AgLvNj8PLcWjmEZ8K6p8ToH WibPxiX71h62NIa2GCoYIcU8zzxq8vfjyvkWi6RbPLDhaynpgG34g76U7BognhKZ 2CxKt1Dw+ydcC/oNHkFyoW99SMlHTYRjeJWyOQ7jEKBAjbaJ3E5mwTMk7lsPO8MI RWTtx4r8HtvFup4mkGottkEj7D8AZfQlWdpLZVDPjV669V/tVIFXUUQD0CXf8Y8f kc79EDzwH44Cvm8endYypQT2BD57jzolP2gzj90Vm3U4fqi4Gj8veinnRDdLdUVW MxzgAkS1G6Or2ZzOo2GBfwc85xInnK4eINfJFaXfGPcEQtwH/FDvGOFbBEiNoDOu i40vehgfOEYf5ld4IF5L1h2cqyJfpKvYmsrfdX4Z4Jr5thoTFJ9iwmDUaGgSlixY pinXkQuSmKxBHpMClwVprIcAfp+ovBIFYeS+urXhmLSHBFjSp1JtrNz5LGbSwHL9 A8p3x85zGoStYYpjv4gVG8sjVr3AvmEOHkFD+fRpbCut/EJU74muj1PuCKEAt0R1 3yk4in5TqinMohz3VMzHYUG04V/szsmdl2GrkzRJYN2yFVYjQn6ZMtVGNXekBNjL FsZcqpBD7OKIOBDn7zNHHeLFhkEOFzh/fE3DVrpvwfVKiKRJubgQ7uV9k6tnj4T2 lVJa42PIIAWlSvw3rbOH =r8xT -----END PGP SIGNATURE----- --84ND8YJRMFlzkrP4-- From owner-freebsd-net@freebsd.org Fri Jun 10 20:39:52 2016 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 A3CABAEF2EE; Fri, 10 Jun 2016 20:39:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48D872A65; Fri, 10 Jun 2016 20:39:51 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org ([IPv6:2400:402e:a012:6300:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id u5AKdY5q029049 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Sat, 11 Jun 2016 05:39:45 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org ([IPv6:2400:402e:a012:6300:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id u5AKdXtc094944 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 11 Jun 2016 05:39:33 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id u5AKdUDd094941; Sat, 11 Jun 2016 05:39:33 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 11 Jun 2016 05:37:59 +0900 (JST) Message-Id: <20160611.053759.1734517365141755226.hrs@allbsd.org> To: stdin@niklaas.eu Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: And what about ipv6_defaultrouter? From: Hiroki Sato In-Reply-To: <20160610191828.GE2817@box-hlm-03.niklaas.eu> References: <20160610071254.GC2817@box-hlm-03.niklaas.eu> <20160610.225031.1318863285679295699.hrs@allbsd.org> <20160610191828.GE2817@box-hlm-03.niklaas.eu> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Jun_11_05_37_59_2016_984)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sat, 11 Jun 2016 05:39:47 +0900 (JST) X-Spam-Status: No, score=-96.6 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,RCVD_IN_AHBL,RCVD_IN_AHBL_PROXY,RCVD_IN_AHBL_SPAM,RCVD_IN_CHINA, RCVD_IN_CHINA_KR,RCVD_IN_TAIWAN,RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 20:39:52 -0000 ----Security_Multipart(Sat_Jun_11_05_37_59_2016_984)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Niklaas Baudet von Gersdorff wrote in <20160610191828.GE2817@box-hlm-03.niklaas.eu>: st> Hiroki Sato [2016-06-10 22:50 +0900] : st> st> > A router does not accept RAs (more strictly, default route st> > information in RA) because it is a sender of RAs. However, some st> > devices such as CPE need to behave like a host for the uplink and a st> > router for the LAN. In that case, an interface on the WAN side has st> > to accept RAs and one on the LAN side has to send RAs. st> > st> > On FreeBSD, there is a knob to support it. Set the following st> > variable to rc.conf in addition to your current configuration: st> > st> > ipv6_cpe_wanif="vtnet0" st> st> Thanks a lot for pointing that out! I think I read about the variable st> somewhere but I was not sure what it actually does. Is there some place st> where I can find more detailed explanation about rc.conf and sysctl st> settings except man? Unfortunately there is no documentation other than manual page because this is a bit tricky. rc.conf(5) explains as follows: ---- ipv6_cpe_wanif (str) If the variable is set to an interface name, the ifconfig(8) options ``inet6 -no_radr accept_rtadv'' will be added to the specified interface automatically before evalu- ating ifconfig__ipv6, and two sysctl(8) variables net.inet6.ip6.rfc6204w3 and net.inet6.ip6.no_radr will be set to 1. This means the specified interface will accept ICMPv6 Router Advertisement messages on that link and add the discovered routers into the Default Router List. While the other inter- faces can still accept RA messages if the ``inet6 accept_rtadv'' option is specified, adding routes into the Default Router List will be disabled by ``inet6 no_radr'' option by default. See ifconfig(8) for more details. Note that ICMPv6 Router Advertisement messages will be accepted even when net.inet6.ip6.forwarding is 1 (packet forwarding is enabled) when net.inet6.ip6.rfc6204w3 is set to 1. Default is ``NO''. ---- -- Hiroki ----Security_Multipart(Sat_Jun_11_05_37_59_2016_984)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAldbJScACgkQTyzT2CeTzy3ZWQCghXV4n+OIhgeKSe2TOflxjj8T QCkAmwd3RS7bqAFWVunG5C3tQS62mGlt =44DZ -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jun_11_05_37_59_2016_984)---- From owner-freebsd-net@freebsd.org Fri Jun 10 20:50:35 2016 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 E4048AEF70C; Fri, 10 Jun 2016 20:50:35 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [84.22.110.84]) by mx1.freebsd.org (Postfix) with ESMTP id B18132069; Fri, 10 Jun 2016 20:50:35 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id D3D3D385528; Fri, 10 Jun 2016 22:50:25 +0200 (CEST) Date: Fri, 10 Jun 2016 22:50:25 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: And what about ipv6_defaultrouter? Message-ID: <20160610205025.GG2817@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org References: <20160610071254.GC2817@box-hlm-03.niklaas.eu> <20160610.225031.1318863285679295699.hrs@allbsd.org> <20160610191828.GE2817@box-hlm-03.niklaas.eu> <20160611.053759.1734517365141755226.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BXr400anF0jyguTS" Content-Disposition: inline In-Reply-To: <20160611.053759.1734517365141755226.hrs@allbsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 20:50:36 -0000 --BXr400anF0jyguTS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hiroki Sato [2016-06-11 05:37 +0900] : > Unfortunately there is no documentation other than manual page > because this is a bit tricky. rc.conf(5) explains as follows: >=20 > ---- > ipv6_cpe_wanif >=20 > (str) If the variable is set to an interface name, the > ifconfig(8) options ``inet6 -no_radr accept_rtadv'' will be > added to the specified interface automatically before evalu- > ating ifconfig__ipv6, and two sysctl(8) variables > net.inet6.ip6.rfc6204w3 and net.inet6.ip6.no_radr will be set to > 1. So where would I start to look for further explanations on net.inet6.ip6.rfc6204w3 and net.inet6.ip6.no_radr? sysctl.conf(5) and sysctl(8) don't mention anything about them. Niklaas --BXr400anF0jyguTS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWygCAAoJEG2fODeJrIU/6kAP/jk7mhjB5kspjhIyGsY94r7Z Q5g4+gk8CzrzP/bAY8L8jMe12LJhrPCkQ4S0SpvjaVhfmPYlrMZGakDd0WsorMvt IeAaaukrbrdOzd6hxjTmPyyKz/BFml/45GwsfEv54Ir3jtEdWAnqzka+6Sr6Q2v9 EiIypU8Uvz690+JWXI6pUq0KMrnBadZK8wPDjF983K2Ba7vhM/TFTDsQMM81qSZh K2fXaEZk6xa4Up9LFMcdWRrrzaBlFshDLVVGl3h6bBO/DW/qBmLuLH/HjTivX6/0 XzjqDlEzSFiizV1i3td5b5dUonF6IqmbXIQaAcFXsYyVH0gBpc+pJ//qa9alHzND Ow/IoDhMe+cnm4AwPZtuzULGxfwF9tH57bwN/CIEU2zlTdNkECz7/mn9nBh+qIEx pSxPtAfSECICeV73ZghAJV0jIu3Cgzeam4sB9iQSV/s6wWfmdtB1CVSqQ/ZGYJ2g uABamm6wKkvBngEnivvTNRMUjiiqlWjz0hl/eHwvcNrudwt7FV7MhDhu/UPHHvAQ lVK+dPrXhG9fOjGkphJorPspiDI8vO22Q0Gf+HpZiENorZ1GCp0x5POn37l3m6Rf gPea6Myg6bD5cXbcXaUgSYe5W6E7P1MhhRWy8RH0+CeECeTvBDJVk3jJ/mdKtiWB pS1//2JzyRVt2NNMRUg/ =61oH -----END PGP SIGNATURE----- --BXr400anF0jyguTS-- From owner-freebsd-net@freebsd.org Fri Jun 10 21:00:54 2016 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 4CD17AEFA18; Fri, 10 Jun 2016 21:00:54 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFED12722; Fri, 10 Jun 2016 21:00:53 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org ([IPv6:2400:402e:a012:6300:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id u5AL0ZYT029932 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) (Client CN "/OU=GT07882699/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.allbsd.org", Issuer "/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3"); Sat, 11 Jun 2016 06:00:46 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.allbsd.org ([IPv6:2400:402e:a012:6300:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id u5AL0Wjw007045 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 11 Jun 2016 06:00:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.15.2/8.15.2) with ESMTPA id u5AL0WGd007042; Sat, 11 Jun 2016 06:00:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 11 Jun 2016 06:00:27 +0900 (JST) Message-Id: <20160611.060027.2146801142002777069.hrs@allbsd.org> To: stdin@niklaas.eu Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: And what about ipv6_defaultrouter? From: Hiroki Sato In-Reply-To: <20160610205025.GG2817@box-hlm-03.niklaas.eu> References: <20160610191828.GE2817@box-hlm-03.niklaas.eu> <20160611.053759.1734517365141755226.hrs@allbsd.org> <20160610205025.GG2817@box-hlm-03.niklaas.eu> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Jun_11_06_00_27_2016_968)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sat, 11 Jun 2016 06:00:48 +0900 (JST) X-Spam-Status: No, score=-96.6 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,RCVD_IN_AHBL,RCVD_IN_AHBL_PROXY,RCVD_IN_AHBL_SPAM,RCVD_IN_CHINA, RCVD_IN_CHINA_KR,RCVD_IN_TAIWAN,RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on gatekeeper.allbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 21:00:54 -0000 ----Security_Multipart(Sat_Jun_11_06_00_27_2016_968)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Niklaas Baudet von Gersdorff wrote in <20160610205025.GG2817@box-hlm-03.niklaas.eu>: st> Hiroki Sato [2016-06-11 05:37 +0900] : st> st> > Unfortunately there is no documentation other than manual page st> > because this is a bit tricky. rc.conf(5) explains as follows: st> > st> > ---- st> > ipv6_cpe_wanif st> > st> > (str) If the variable is set to an interface name, the st> > ifconfig(8) options ``inet6 -no_radr accept_rtadv'' will be st> > added to the specified interface automatically before evalu- st> > ating ifconfig__ipv6, and two sysctl(8) variables st> > net.inet6.ip6.rfc6204w3 and net.inet6.ip6.no_radr will be set to st> > 1. st> st> So where would I start to look for further explanations on st> net.inet6.ip6.rfc6204w3 and net.inet6.ip6.no_radr? sysctl.conf(5) and st> sysctl(8) don't mention anything about them. Yes. "no_radr" can be found in ifconfig(8) manual page since it is related to one of the per-IF flags which has the same name. "rfc6204w3" is only documented in the result of "sysctl -d net.inet6.ip6.rfc6204w3". -- Hiroki ----Security_Multipart(Sat_Jun_11_06_00_27_2016_968)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAldbKmsACgkQTyzT2CeTzy2kKwCghJnhj3Rck09WFUD9H3vxU3l2 YAkAn0Z91WCiVkBnkijRn4JkFhHNVWji =Pt+m -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jun_11_06_00_27_2016_968)---- From owner-freebsd-net@freebsd.org Fri Jun 10 21:14:02 2016 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 C004EAEFD50; Fri, 10 Jun 2016 21:14:02 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: from box-hlm-03.niklaas.eu (box-hlm-03.niklaas.eu [84.22.110.84]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9E82D76; Fri, 10 Jun 2016 21:14:02 +0000 (UTC) (envelope-from stdin@niklaas.eu) Received: by box-hlm-03.niklaas.eu (Postfix, from userid 1001) id BF291385528; Fri, 10 Jun 2016 23:13:57 +0200 (CEST) Date: Fri, 10 Jun 2016 23:13:57 +0200 From: Niklaas Baudet von Gersdorff To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: And what about ipv6_defaultrouter? Message-ID: <20160610211357.GH2817@box-hlm-03.niklaas.eu> Mail-Followup-To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org References: <20160610191828.GE2817@box-hlm-03.niklaas.eu> <20160611.053759.1734517365141755226.hrs@allbsd.org> <20160610205025.GG2817@box-hlm-03.niklaas.eu> <20160611.060027.2146801142002777069.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="svExV93C05KqedWb" Content-Disposition: inline In-Reply-To: <20160611.060027.2146801142002777069.hrs@allbsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 21:14:02 -0000 --svExV93C05KqedWb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hiroki Sato [2016-06-11 06:00 +0900] : > "rfc6204w3" is only documented in the result of "sysctl -d > net.inet6.ip6.rfc6204w3". This is what I was looking for. Thanks a lot. Niklaas --svExV93C05KqedWb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXWy2PAAoJEG2fODeJrIU/hegP/jvlSVqrwquPY3rDUg3QDec3 oGqzh/S0FOCHOVKrmywXG6jWgPB9XCarELJBmW3kD7BUOk37R92XlnmjAcm0RhgW sm7gzRHl2aaAwWCWTW17AInXqJfmoagqBOrBQUnEciwB4Ny027e5AHtos+a4H1A0 R3DmTDY1+ey5AbWrqpEshvZpzAJVrINWKaWWf/CBfQ8k5V2qxJuLZARlBISl/CfE rv+hVWdYI/Pvxx4tKDMAJCSTqD136+ppUpgPUIHrW4l34+9FcDf8GOWVLkxjlu/C N3SI+lFRJc6MxRVSZlzRz4H8zMFwtVbvqkJ2QouRNP/q/p/V3rWFLSo4KillclG7 fdZJgIJq7WE5ha4hAbNdsyoJq5CVSAzz0XLXptBxhHVBj4itnG9N7MNqhOp79EWS 464UN4cMo83L/QGNRMO9+2/op7PYNHtZm1xt2WQiw5+HSg9OusRx2FumWrvpAQrR nffZ3N1xKfMWBgjHa7GL1TuRsycdvLQBwdouBVDfXIjZBhGEZPptPdMWada3Z43u 6h/71es5P/OfAGghpgFB6ZFFHlJ76vF544zAK3girEph0EryGyGAaI9UbOEExT2G Xq6wKh/e2g/IgZAgT0gX7t/jRgQEIfP+vz3RTp0bBChq9+9Pbfv2N7lWzpi47dUP Xw0/iVY4k7lRUSUmGCOF =Xt2T -----END PGP SIGNATURE----- --svExV93C05KqedWb-- From owner-freebsd-net@freebsd.org Fri Jun 10 21:27:09 2016 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 A43E0AEFF6E for ; Fri, 10 Jun 2016 21:27:09 +0000 (UTC) (envelope-from david_a_bright@dell.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 927C72177 for ; Fri, 10 Jun 2016 21:27:09 +0000 (UTC) (envelope-from david_a_bright@dell.com) Received: by mailman.ysv.freebsd.org (Postfix) id 91E5BAEFF6D; Fri, 10 Jun 2016 21:27:09 +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 919BCAEFF6C for ; Fri, 10 Jun 2016 21:27:09 +0000 (UTC) (envelope-from david_a_bright@dell.com) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "ausxipmktps31.us.dell.com", Issuer "Verizon Public SureServer CA G14-SHA1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 617152176 for ; Fri, 10 Jun 2016 21:27:08 +0000 (UTC) (envelope-from david_a_bright@dell.com) X-Loopcount0: from 76.164.8.179 X-IronPort-AV: E=Sophos;i="5.26,452,1459832400"; d="scan'208";a="407935251" From: David Bright To: "net@FreeBSD.org" Subject: Re: DHCPv6 Support in FreeBSD Base Thread-Topic: DHCPv6 Support in FreeBSD Base Thread-Index: AQHRwpPdKYzUv7bVe0CH0Y50DySuU5/jQ38AgABI0AA= Date: Fri, 10 Jun 2016 21:27:00 +0000 Message-ID: <21444224-3DE9-4F5C-AE19-A97DE031D807@DELL.com> References: <6224EC83-3A81-4CE7-83C5-674628F38958@DELL.com> <4a318c6c-ab03-e63c-979f-502bc2afb97e@bluerosetech.com> In-Reply-To: <4a318c6c-ab03-e63c-979f-502bc2afb97e@bluerosetech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.156.108.251] Content-Type: text/plain; charset="utf-8" Content-ID: <7B69714E954C9B49A91542C131F5D659@compellent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 10 Jun 2016 21:27:09 -0000 T24gSnVuIDEwLCAyMDE2LCBhdCAxMzowNiwgTWVsIFBpbGdyaW0gPGxpc3RfZnJlZWJzZEBibHVl cm9zZXRlY2guY29tPG1haWx0bzpsaXN0X2ZyZWVic2RAYmx1ZXJvc2V0ZWNoLmNvbT4+IHdyb3Rl Og0KDQpDb3VsZCB0aGUgV0lERSBjbGllbnQgYmUgdXNlZCBpbnN0ZWFkPyAgVW5saWtlIHRoZSBJ U0MgY2xpZW50LCBpdCB3aWxsDQpjb25maWd1cmUgZG93bnN0cmVhbSBpbnRlcmZhY2VzIGZyb20g UEQgcHJlZml4ZXMgd2l0aG91dCBuZWVkaW5nIGFuDQpleHRlcm5hbCBzY3JpcHQuICBJdCBhbHNv IGNvbXBsZXRlbHkgYXZvaWRzIHRoZSBwcm9ibGVtIG9mIHRyeWluZyB0bw0KdXBkYXRlIHRoZSBp bi1iYXNlIGRoY2xpZW50Lg0KDQpUaGUgSVNDIGNsaWVudCBpc27igJl0IHRoZSBvbmx5IGNob2lj ZS4gSSBjaG9zZSB0byB3b3JrIHdpdGggdGhlIElTQyBjbGllbnQgaW4gbXkgd29yayBiZWNhdXNl IHRoZSBjdXJyZW50IEZyZWVCU0QgZGhjbGllbnQgc2hhcmVzIGEgY29tbW9uIGFuY2VzdHJ5IHdp dGggdGhlIGN1cnJlbnQgSVNDIGRoY2xpZW50IGFuZCBhbHNvIGJlY2F1c2UgdGhlIElTQyBkaGNs aWVudCBpbXBsZW1lbnRzIHBzZXVkbyBpbnRlcmZhY2VzLCB3aGljaCBpcyBhIGZlYXR1cmUgdGhh dCBJIG5lZWQgZm9yIG15IGFwcGxpY2F0aW9uLg0KDQpJcyB0aGUgV0lERSBjbGllbnQgc3RpbGwg bWFpbnRhaW5lZD8gV2hlbiBJIGxvb2tlZCwgdGhlIG1vc3QgcmVjZW50IHJlbGVhc2UgSSBmb3Vu ZCB3YXMgZnJvbSAyMDA4LiBQZXJoYXBzIHlvdSBoYXZlIGEgbGluayB0byBhIG1vcmUgcmVjZW50 IHZlcnNpb24gb2YgdGhlIFdJREUgY2xpZW50Lg0KDQpUaGFua3MuDQoNCi0tDQpEYXZpZCBBLiBC cmlnaHQNClN0b3JhZ2UgRGV2ZWxvcG1lbnQgUHJpbmNpcGFsIEVuZ2luZWVyDQpEZWxsIHwgQ29t cGVsbGVudA0Kb2ZmaWNlICsxIDk1MiAzOTIgNTg2MQ0KQ3ViZSBKLTczMSwgNzYxNSBTbWV0YW5h IExhbmUsIEVkZW4gUHJhaXJpZSwgTU4gNTUzNDQNCkRhdmlkX0FfQnJpZ2h0QERFTEwuY29tPG1h aWx0bzpEYXZpZF9BX0JyaWdodEBERUxMLmNvbT4NCg0K From owner-freebsd-net@freebsd.org Sat Jun 11 21:09:15 2016 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 46155AF0CE1 for ; Sat, 11 Jun 2016 21:09:15 +0000 (UTC) (envelope-from rdarbha@juniper.net) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0131.outbound.protection.outlook.com [157.56.110.131]) (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 911922767; Sat, 11 Jun 2016 21:09:14 +0000 (UTC) (envelope-from rdarbha@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ucrnAtPN5IFqUZ2SbclwW0guPOAiMGI1JOiVq1HjqvQ=; b=dbya2jT6IIFnJvdyT8y54EoFDrZ/fLdgoe0LnoGdPRCjUaWukBr9W5TqynNmW+cgWPiJ9CrFmA82F9sjuBxCRuqFKyJrETEavs5k/f8LE4QxZUvvSFYpHYhLpoUKRHABWpng/Y5AXlgNZdeTTnYT3RNpgeiMmxCtDD7X1TxRlgs= Received: from CO2PR05MB2709.namprd05.prod.outlook.com (10.166.200.9) by CO2PR05MB2711.namprd05.prod.outlook.com (10.166.200.11) with Microsoft SMTP Server (TLS) id 15.1.511.8; Sat, 11 Jun 2016 21:09:06 +0000 Received: from CO2PR05MB2709.namprd05.prod.outlook.com ([10.166.200.9]) by CO2PR05MB2709.namprd05.prod.outlook.com ([10.166.200.9]) with mapi id 15.01.0511.013; Sat, 11 Jun 2016 21:09:06 +0000 From: Raviprakash Darbha To: "freebsd-net@freebsd.org" , "andre@freebsd.org" CC: Raviprakash Darbha , Steve Kiernan Subject: Re: Double lock issue of unp_link_rwlock in usrreq.c observed Thread-Topic: Double lock issue of unp_link_rwlock in usrreq.c observed Thread-Index: AQHRshJTR+bDMKnLE0WY8qlRodxbwp/k5tIA Date: Sat, 11 Jun 2016 21:09:06 +0000 Message-ID: References: <948AD75B-BF6E-4672-8B50-9CF9E25667EA@juniper.net> In-Reply-To: <948AD75B-BF6E-4672-8B50-9CF9E25667EA@juniper.net> 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=rdarbha@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-ms-office365-filtering-correlation-id: abf6ed9d-789e-46fe-1aff-08d3923c9f9d x-microsoft-exchange-diagnostics: 1; CO2PR05MB2711; 5:aTHd+U9q/apzIRicBh7lQM2i0ljtfy8tZnWDza34eFjmgjpnj677Qgy1rUhKxsk2h6C7OSX/JOaXGexfGw4iO64aAPPWgM5znpVS3AwBYtoIxlx5FXrB+mXnEtu4Si9YcnsqTslFsY2VkaVIIOXtcw==; 24:tJbksftMGxVrH4uY1FiQuq+W0/2yFWOKd7CB0SPbl1W1JnZSDoPiEXtMG2VMjEZgKOC+D3GrL/+68v04zg/uogFd+xN7ziiD6cSi8Q3lDFs=; 7:GW/qezakt8pumdY3nkY07C+XTIoLRo7GOkmsgDqWlSpa70sdNjDPOCZja835ZxAkHb0GsF8IrrKBLYrJQP8jrPTKnSfYl6ENTWWJ/SKhX3kYwdJkHKqsAwn3IT9Ec2ARnIeIpyAxrotn5FAj6X7aAJ0C8TzkZnR3yX+ibzNo3Yqeq/Ffh/srKeRCdW3bJeaADzSahc4Tn+O3HBw2n8l1WQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2711; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CO2PR05MB2711; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2711; x-forefront-prvs: 0970508454 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(377454003)(189002)(5004730100002)(11100500001)(5008740100001)(106116001)(16236675004)(4001430100002)(105586002)(19580395003)(19580405001)(81166006)(81156014)(8676002)(99286002)(87936001)(189998001)(2900100001)(2950100001)(8936002)(586003)(86362001)(36756003)(106356001)(10400500002)(5001770100001)(97736004)(450100001)(107886002)(3846002)(77096005)(102836003)(122556002)(92566002)(6116002)(33656002)(4326007)(68736007)(2906002)(66066001)(5002640100001)(3280700002)(3660700001)(5890100001)(82746002)(2501003)(83716003)(76176999)(101416001)(50986999)(54356999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2711; H:CO2PR05MB2709.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2016 21:09:06.0085 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2711 X-Mailman-Approved-At: Sat, 11 Jun 2016 22:41:31 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 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, 11 Jun 2016 21:09:15 -0000 UmVzZW5kaW5nIHRoZSBNYWlsLCBpZiBhbnlvbmUgaGFzIGxvb2tlZCBhdCBpdC4NCg0KVGhhbmtz DQpSYXZpUHJha2FzaCBEYXJiaGENCnJkYXJiaGFAanVuaXBlci5uZXQ8bWFpbHRvOnJkYXJiaGFA anVuaXBlci5uZXQ+DQoNCg0KDQoNCk9uIE1heSAxOSwgMjAxNiwgYXQgMjowNiBQTSwgUmF2aVBy YWthc2ggRGFyYmhhIDxyZGFyYmhhQGp1bmlwZXIubmV0PG1haWx0bzpyZGFyYmhhQGp1bmlwZXIu bmV0Pj4gd3JvdGU6DQoNCkhlbGxvIEFuZHJlDQoNCkkgZW5jb3VudGVyZWQgYSBkb3VibGUgbG9j ayBpc3N1ZSBpbiB1bnBfY29ubmVjdGF0IGZ1bmN0aW9uLiBBZnRlciBsb29raW5nIGF0IHRoZSBj b2RlICwgSSB0aGluayB0aGUgdW5wX2xpbmtfcndsb2NrIGlzIGJlaW5nIGxvY2tlZCBvbmNlIHVu cF9jb25uZWN0YXQgYW5kIG9uY2UgYWdhaW4gaW4gdW5wX2RldGFjaCAgKGNhbGxlZCBmcm9tIHNv ZnJlZSApLiBXb3VsZCBsaWtlIHRvIGdldCB5b3VyIG9waW5pb24gb24gdGhlIGlzc3VlIGFuZCB0 aGUgZml4LiBCZWxvdyBpcyB0aGUgZXhhY3QgY2FsbCBzdGFjay4NCg0KDQpVTlBfTElOS19XTE9D SygpOyAgICAgICAgIDzigJTigJTigJTigJTigJTigJTigJTigJTigJTigJQgIDEgc3QgY2FsbA0K 4oCmLi4NCuKApi4uDQppZiAoc28tPnNvX3Byb3RvLT5wcl9mbGFncyAmIFBSX0NPTk5SRVFVSVJF RCkgew0KICAgICBpZiAoc28yLT5zb19vcHRpb25zICYgU09fQUNDRVBUQ09OTg0KICAgICAgICAg Q1VSVk5FVF9TRVQoc28yLT5zb192bmV0KTsNCiAgICAgICAgICBzbzMgPSBzb25ld2Nvbm4oc28y LCAwKTsNCiAgICAgICAgICAvLyBFeHBhbmRpbmcgc29uZXdjb25uDQogICAgICAgICAgew0KICAg ICAgICAgICAgIHNvbmV3Y29ubg0KICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAg 4oCm4oCmDQogICAgICAgICAgICAgICAgICAgc29hbGxvYw0KICAgICAgICAgICAgICAgICAgIOKA puKApi4NCiAgICAgICAgICAgICAgICAgICBwcnVfYXR0YWNoDQogICAgICAgICAgICAgICAgICAg 4oCm4oCmLg0KICAgICAgICAgICAgICAgICAgIGlmICghKGhlYWQtPnNvX29wdGlvbnMgJiBTT19B Q0NFUFRDT05OKSAmJg0KICAgICAgICAgICAgICAgICAgICgoaGVhZC0+c29fcHJvdG8tPnByX3By b3RvY29sICE9IElQUFJPVE9fU0NUUCkgfHwNCiAgICAgICAgICAgICAgICAgICAgKGhlYWQtPnNv X3R5cGUgIT0gU09DS19TRVFQQUNLRVQpKSkgew0KICAgICAgICAgICAgICAgICAgICAgICDigKbi gKbigKYuDQogICAgICAgICAgICAgICAgICAgICAgIHNvZnJlZShzbyk7ICAgICAgICAgICAgIC8q IE5COiByZXR1cm5zIEFDQ0VQVF9VTkxPQ0snZWQuICovDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgLy8gRXhwYW5kaW5nIHNvZnJlZQ0KDQogICAgICAgICAgICAgICAgICAgICAgew0KDQogICAg ICAgICAgICAgICAgICAgICAgICDigKbigKYuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHBy dV9kZXRhY2gNCg0KICAgICAgICAgICAgICAgICAgICAgICAgLy8gZXhwYW5kaW5nIHBydV9kZXRh Y2gNCg0KICAgICAgICAgICAgICAgICAgICAgICAgew0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC8vIFJlY3Vyc2l2ZSB3bG9jayBhY3F1aXJpbmcuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVU5QX0xJTktfV0xPQ0soKSAgICAgPOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlCAgMm5kIENhbGwNCg0KTGV0IG1lIGtub3cgeW91ciB0aG91Z2h0cyBvciBpZiB5b3Ug bmVlZCBtb3JlIGluZm9ybWF0aW9uLiBUaGFua3MgIQ0KDQpUaGFua3MNClJhdmlQcmFrYXNoIERh cmJoYQ0KcmRhcmJoYUBqdW5pcGVyLm5ldDxtYWlsdG86cmRhcmJoYUBqdW5pcGVyLm5ldD4NCg0K DQoNCg0K