From owner-freebsd-net@freebsd.org Sun Mar 6 08:52:48 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 2A3B79DAFCB for ; Sun, 6 Mar 2016 08:52:48 +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 1B06334C for ; Sun, 6 Mar 2016 08:52:48 +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 u268qlfw012556 for ; Sun, 6 Mar 2016 08:52:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206876] ifconfig(8): Inconsistent behavior when creating and giving custom name to interface at the same time Date: Sun, 06 Mar 2016 08:52:47 +0000 X-Bugzilla-Reason: CC 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: easy, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kp@freebsd.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 06 Mar 2016 08:52:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206876 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Sun Mar 6 08:52:04 UTC 2016 New revision: 296425 URL: https://svnweb.freebsd.org/changeset/base/296425 Log: MFC r295836: ifconfig(8): can't use 'name' or 'description' when creating interface wi= th auto numbering If one does 'ifconfig tap create name blah', it will return error because= the 'name' command doesn't properly populate the request sent to ioctl(...). = The 'description' command has the same bug, and is also fixed with this patch. If one does 'ifconfig tap create mtu 9000 name blah', it DOES work, but 'tap0' (or other sequence number) is echoed, instead of the expected 'blah'. (assuming the name change actually succeeded) PR: 206876 Submitted by: Marie Helene Kvello-Aune Differential Revision: https://reviews.freebsd.org/D5341 Changes: stable/10/sbin/ifconfig/ifclone.c stable/10/sbin/ifconfig/ifconfig.c stable/10/sbin/ifconfig/ifconfig.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 6 08:53: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 D69CEA9300D for ; Sun, 6 Mar 2016 08:53:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C75685E2 for ; Sun, 6 Mar 2016 08:53:15 +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 u268rFK7013264 for ; Sun, 6 Mar 2016 08:53:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 206876] ifconfig(8): Inconsistent behavior when creating and giving custom name to interface at the same time Date: Sun, 06 Mar 2016 08:53:15 +0000 X-Bugzilla-Reason: CC 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: easy, patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kp@freebsd.org X-Bugzilla-Flags: mfc-stable10+ X-Bugzilla-Changed-Fields: flagtypes.name 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.21 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, 06 Mar 2016 08:53:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206876 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable10? |mfc-stable10+ Resolution|--- |FIXED Status|Open |Closed --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-net@freebsd.org Sun Mar 6 20:40:44 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 4BF7AAC1FB5; Sun, 6 Mar 2016 20:40:44 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1481E8E2; Sun, 6 Mar 2016 20:40:44 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u26KeWoZ084554; Sun, 6 Mar 2016 12:40:37 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201603062040.u26KeWoZ084554@gw.catspoiler.org> Date: Sun, 6 Mar 2016 12:40:31 -0800 (PST) From: Don Lewis Subject: Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet To: ralsaadi@swin.edu.au cc: aqm@ietf.org, freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, garmitage@swin.edu.au In-Reply-To: <6545444AE21C2749939E637E56594CEA3C187192@gsp-ex02.ds.swin.edu.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 06 Mar 2016 20:40:44 -0000 On 26 Feb, Rasool Al-Saadi wrote: > Dear all, > > I would like to announce that we (myself and Grenville Armitage) > released Dummynet AQM v0.1, which is an independent implementation of > CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the > IETF CoDel [1] and FQ-CoDel [2] Internet-Drafts. We prepared patches > for FreeBSD11-CURRENT-r295345 and FreeBSD 10.x-RELEASE (10.0, 10.1, > 10.2), and a technical report of our implementation. > > Patches and documentation can be found in: > http://caia.swin.edu.au/freebsd/aqm The FreeBSD 10 patch applies cleanly to FreeBSD 10.3-PRERELEASE, but the build fails on i386: /usr/src/sbin/ipfw/dummynet.c:166:5: error: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] ep->par[0], ^~~~~~~~~~ /usr/src/sbin/ipfw/dummynet.c:167:5: error: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] ep->par[1] ); ^~~~~~~~~~ /usr/src/sbin/ipfw/dummynet.c:177:5: error: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] ep->par[0], ^~~~~~~~~~ /usr/src/sbin/ipfw/dummynet.c:178:5: error: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] ep->par[1], ^~~~~~~~~~ /usr/src/sbin/ipfw/dummynet.c:179:5: error: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] ep->par[3], ^~~~~~~~~~ /usr/src/sbin/ipfw/dummynet.c:180:5: error: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] ep->par[4], ^~~~~~~~~~ /usr/src/sbin/ipfw/dummynet.c:181:5: error: format specifies type 'long' but the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] ep->par[5] ^~~~~~~~~~ The proper fix for this on FreeBSD is to cast these values to intmax_t and use the %jd printf format. From owner-freebsd-net@freebsd.org Sun Mar 6 21:00: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 C463DAC29FA for ; Sun, 6 Mar 2016 21:00:23 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBB5994D for ; Sun, 6 Mar 2016 21:00:23 +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 u26L01KP008958 for ; Sun, 6 Mar 2016 21:00:23 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201603062100.u26L01KP008958@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, 06 Mar 2016 21:00:23 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 06 Mar 2016 21:00:23 -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 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; 11 problems total for which you should take action. From owner-freebsd-net@freebsd.org Mon Mar 7 02:46:00 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 4BBA9AC2012; Mon, 7 Mar 2016 02:46:00 +0000 (UTC) (envelope-from ralsaadi@swin.edu.au) Received: from iport1.cc.swin.edu.au (iport1.cc.swin.edu.au [136.186.0.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2F9813; Mon, 7 Mar 2016 02:45:58 +0000 (UTC) (envelope-from ralsaadi@swin.edu.au) X-IronPort-AV: E=Sophos;i="5.22,549,1449493200"; d="scan'208";a="17932489" Received: from gsp-ex03.ds.swin.edu.au (HELO outlook.swin.edu.au) ([136.186.126.19]) by iport1.cc.swin.edu.au with ESMTP; 07 Mar 2016 13:44:48 +1100 Received: from GSP-EX02.ds.swin.edu.au ([169.254.2.71]) by gsp-ex03.ds.swin.edu.au ([169.254.3.89]) with mapi id 14.03.0279.002; Mon, 7 Mar 2016 13:44:48 +1100 From: Rasool Al-Saadi To: Don Lewis CC: "freebsd-net@freebsd.org" , Grenville Armitage , "aqm@ietf.org" , "freebsd-ipfw@freebsd.org" Subject: RE: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet Thread-Topic: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet Thread-Index: AdFwoEB9RcA1ON/lTEC2HgPx0zqG6gG6/jCAACNZWyA= Date: Mon, 7 Mar 2016 02:44:48 +0000 Message-ID: <6545444AE21C2749939E637E56594CEA3C1AC4B9@gsp-ex02.ds.swin.edu.au> References: <6545444AE21C2749939E637E56594CEA3C187192@gsp-ex02.ds.swin.edu.au> <201603062040.u26KeWoZ084554@gw.catspoiler.org> In-Reply-To: <201603062040.u26KeWoZ084554@gw.catspoiler.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.186.126.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Mar 2016 02:46:00 -0000 > -----Original Message----- > From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd- > ipfw@freebsd.org] On Behalf Of Don Lewis > Sent: Monday, 7 March 2016 7:41 AM > To: Rasool Al-Saadi > Cc: freebsd-net@freebsd.org; Grenville Armitage > ; aqm@ietf.org; freebsd-ipfw@freebsd.org > Subject: Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's > ipfw/dummynet >=20 > On 26 Feb, Rasool Al-Saadi wrote: > > Dear all, > > > > I would like to announce that we (myself and Grenville Armitage) > > released Dummynet AQM v0.1, which is an independent implementation > of > > CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on > the > > IETF CoDel [1] and FQ-CoDel [2] Internet-Drafts. We prepared patches > > for FreeBSD11-CURRENT-r295345 and FreeBSD 10.x-RELEASE (10.0, 10.1, > > 10.2), and a technical report of our implementation. > > > > Patches and documentation can be found in: > > http://caia.swin.edu.au/freebsd/aqm >=20 > The FreeBSD 10 patch applies cleanly to FreeBSD 10.3-PRERELEASE, but the > build fails on i386: >=20 > /usr/src/sbin/ipfw/dummynet.c:166:5: error: format specifies type 'long' = but > the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] > ep->par[0], > ^~~~~~~~~~ > /usr/src/sbin/ipfw/dummynet.c:167:5: error: format specifies type 'long' = but > the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] > ep->par[1] ); > ^~~~~~~~~~ > /usr/src/sbin/ipfw/dummynet.c:177:5: error: format specifies type 'long' = but > the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] > ep->par[0], > ^~~~~~~~~~ > /usr/src/sbin/ipfw/dummynet.c:178:5: error: format specifies type 'long' = but > the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] > ep->par[1], > ^~~~~~~~~~ > /usr/src/sbin/ipfw/dummynet.c:179:5: error: format specifies type 'long' = but > the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] > ep->par[3], > ^~~~~~~~~~ > /usr/src/sbin/ipfw/dummynet.c:180:5: error: format specifies type 'long' = but > the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] > ep->par[4], > ^~~~~~~~~~ > /usr/src/sbin/ipfw/dummynet.c:181:5: error: format specifies type 'long' = but > the argument has type 'int64_t' (aka 'long long') [-Werror,-Wformat] > ep->par[5] > ^~~~~~~~~~ >=20 >=20 > The proper fix for this on FreeBSD is to cast these values to intmax_t an= d use > the %jd printf format. >=20 Thanks for testing the patch and fixing the problem. We will apply your fix= to the next version of our patch. Regards, Rasool From owner-freebsd-net@freebsd.org Mon Mar 7 12:56:19 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 3D4E39DBFB8 for ; Mon, 7 Mar 2016 12:56:19 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 BFCA518E for ; Mon, 7 Mar 2016 12:56:18 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id l68so69294723wml.1 for ; Mon, 07 Mar 2016 04:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject; bh=nnSK71ZbaXTIogCPjNViz5Hja4duueo3Y8AZ7ELS8kk=; b=U8t9pyYGcdDw+BbW8aStV10VifxgaYPIzhJUbLEV3pUz9acdItpED5S1ugYORR/Cde Y4BV4kVOtTTHv6CAsB42MP6O/SkVxzAeifU1xLYgCpUPq1VturCKZxdhlWwSyO1YOBBS pdpupGMYTudUu4PsLYBRWQEENTIPXX++x8ZVfLURZt6b6Qai2KpG5KddLmRGIUB4M5RO /THO8XLaW01Rv2V9J/TWpWyXW9QZc8LE0NchM5dyNcgdxX7uFCK2fXq2zsrsgmrfPS5O 3S+36lcqhWhBVLXQylgDjwbc7GeII8uNYKHdzxpTIm29n0n/09YHSDJ4om01mS5JHEo4 bWTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject; bh=nnSK71ZbaXTIogCPjNViz5Hja4duueo3Y8AZ7ELS8kk=; b=O4gLthkcXgU/tVB5+lBEdHT2/mINoS4nNl5qARUMryz6yQpLVWkMjg1Gb2XUtQc3Qs d5nU7ai1O7hjd4pJCSsz1Hh5tIFHaG9Xv1vLgEnSO2ozzxoEa+ryNwobQuNBgX6/s+4i AWGAMHPU4aNLEh1mmBVmYZbCbMLLD1RqWyPFakx2RxYM8FAmdrefEbTFmQMIXiIg2ovU ee+UW6GMYbkMh86Zj/FN+MquY09DdCQSKFyRNA0GG/OkaftrvICcQBwZnr/iyK30Qhq5 kkbUGvJst2JJO1avyYgDmWJv05lvlVfoKdIjsxUMegChlkCuinIqQ2Ust5kuURTaf670 +6dw== X-Gm-Message-State: AD7BkJIyHNQOJq2aHPqVsRYHNIE/Wa4nGfOZlgARo0Bdnkv40SDC60gyFR4Yn8ATGB+u3g== X-Received: by 10.194.76.72 with SMTP id i8mr22561669wjw.117.1457355376429; Mon, 07 Mar 2016 04:56:16 -0800 (PST) Received: from [192.168.2.30] ([2.176.177.244]) by smtp.googlemail.com with ESMTPSA id g3sm17861539wjw.31.2016.03.07.04.56.13 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 04:56:15 -0800 (PST) Message-ID: <56DD7A6A.3070108@gmail.com> Date: Mon, 07 Mar 2016 16:26:10 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: tcp window scaling + syn cookies problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Mar 2016 12:56:19 -0000 Hi, In our network, Windows clients connect to internet via our custom developed transparent tcp proxy (running on 7.3). Things work fine, except that _sometimes_ downloads from the some windows clients become very slow. To debug the problem, we inspected a few packet traces and found out that the problem happens because the proxy TCP stack forgets about client's window scale factor, as illustrated in the following packet trace (it is for a download from ftp.freebsd.org site. x.y.z.y is a windows 8): 1. 15:09:32.765713 IP (tos 0x0, ttl 63, id 16510, offset 0, flags [DF], proto TCP (6), length 52) x.y.z.y.57430 > 96.47.72.72.80: S, cksum 0x8343 (correct), 1530161492:1530161492(0) win 8192 2. 15:09:32.765729 IP (tos 0x0, ttl 64, id 55869, offset 0, flags [none], proto TCP (6), length 52) 96.47.72.72.80 > x.y.z.y.57430: S, cksum 0xe2c0 (correct), 503882603:503882603(0) ack 1530161493 win 65535 3. 15:09:32.766071 IP (tos 0x0, ttl 63, id 16511, offset 0, flags [DF], proto TCP (6), length 40) x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x2192 (correct), ack 1 win 256 4. 15:09:32.770074 IP (tos 0x0, ttl 63, id 16512, offset 0, flags [DF], proto TCP (6), length 408) x.y.z.y.57430 > 96.47.72.72.80: P, cksum 0x259c (correct), 1:369(368) ack 1 win 256 5. 15:09:32.869286 IP (tos 0x0, ttl 64, id 57834, offset 0, flags [none], proto TCP (6), length 40) 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x2122 (correct), ack 369 win 65535 6. 15:09:33.180983 IP (tos 0x0, ttl 64, id 64495, offset 0, flags [none], proto TCP (6), length 296) 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0xbd5a (correct), 1:257(256) ack 369 win 65535 7. 15:09:33.231475 IP (tos 0x0, ttl 63, id 16513, offset 0, flags [DF], proto TCP (6), length 40) x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1f23 (correct), ack 257 win 255 8. 15:09:33.231494 IP (tos 0x0, ttl 64, id 248, offset 0, flags [none], proto TCP (6), length 295) 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0xc9b6 (correct), 257:512(255) ack 369 win 65535 9. 15:09:33.282256 IP (tos 0x0, ttl 63, id 16514, offset 0, flags [DF], proto TCP (6), length 40) x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1e25 (correct), ack 512 win 254 10. 15:09:33.282279 IP (tos 0x0, ttl 64, id 1283, offset 0, flags [none], proto TCP (6), length 294) 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x1e25 (correct), 512:766(254) ack 369 win 65535 11. 15:09:33.333006 IP (tos 0x0, ttl 63, id 16515, offset 0, flags [DF], proto TCP (6), length 40) x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1d28 (correct), ack 766 win 253 12. 15:09:33.333023 IP (tos 0x0, ttl 64, id 2520, offset 0, flags [none], proto TCP (6), length 293) 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x1d28 (correct), 766:1019(253) ack 369 win 65535 13. 15:09:33.383926 IP (tos 0x0, ttl 63, id 16516, offset 0, flags [DF], proto TCP (6), length 40) x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1c2c (correct), ack 1019 win 252 As can be seen, the client advertises a window scale factor of 8 and then correctly sets packet's window size based on the advertised factor. But the proxy seems to forget about client's scale factor and sends as much data as the client's unscaled window size sent in a previous ACK. Now, setting 'net.inet.tcp.syncookies' to zero obviously seems to fix the problem and the download speed becomes as expected. Is this bad interaction between window scaling and syn cookies a known problem? Why it happens? Has it been fixed in later freebsd version? Thanks in advance. -- Best regards Hooman Fazaeli From owner-freebsd-net@freebsd.org Mon Mar 7 14:32:34 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 670A7AC0A36 for ; Mon, 7 Mar 2016 14:32:34 +0000 (UTC) (envelope-from hoomanfazaeli@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 E9CB4970 for ; Mon, 7 Mar 2016 14:32:33 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id n186so88723545wmn.1 for ; Mon, 07 Mar 2016 06:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to; bh=tE7Y4HgQ2cEwPS09znQ+gY4gZ6H9teGhyb5R5QHUCdM=; b=ClfpRsCTRScy2lJ02X43d58Sc52h2BAK/Kg8H1NhbMq750/r4L0yCpIMI5CvVWLwPv cDPS04MrFla4rGH5jhIT00nI3e943FGf4i8bHzDgscLmi/5bHk1gDzTCCtz1SSzeBf90 hZTsD9YQqTd9OWUNAO7wiWd8qvsQj9pu2yMXX61kkGDGh4oBQ23QZH/tCnOjsU79k6l2 lEdws2itAic0z7R/eBLLP5Q+ugTEEqPP1vDpUexbcC3b4RtJi3PxZrm9cXBoTqeo4Yqe jxp4Xj5Rzu4Lbw3QpGIt1hldqfF8dIT0cOij36RZgv+bHrZj6xzEvLSKM/txfGbvLCea 30PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to; bh=tE7Y4HgQ2cEwPS09znQ+gY4gZ6H9teGhyb5R5QHUCdM=; b=jqSCnn3BX6mZNiFiulRxRQW2Zoxz2eciVKZRykmDe20oHyWe4JqYc61GP+lAKTYNBN 2CPU8f9aA10mjJafCsiUUNLlOxGvrvyumgmqNjJEF12OKGzUF/TnIOSkNUzk5ctrtjuQ xzE3y+XDUmZLD5dS1n/QcTolOvYEGiWptDuM+AZiRDslCGlEIOKz0Y9nv+NG1n7UYxyD KbIxb+hePFC/T62xqlXXTleXTIafx2HUTHO0xQxeurUotkzNSnlhruyi0Uhj0wspzZJU lf8UghkMToCNZZuKCQm6LE0rebqAbZcs9/y4ncONJg9Rzy2VW2VjDPvGw9NcDbXZ/Fun FQag== X-Gm-Message-State: AD7BkJLrg89mN0UpLp4gAXaQrXclW/2Q3Vbcp4bharZkHCBG3CMbPbXNr43w+WbPJVWNTw== X-Received: by 10.194.83.101 with SMTP id p5mr23121672wjy.141.1457361152127; Mon, 07 Mar 2016 06:32:32 -0800 (PST) Received: from [192.168.2.30] ([2.176.177.244]) by smtp.googlemail.com with ESMTPSA id hx10sm18215036wjb.25.2016.03.07.06.32.29 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 06:32:31 -0800 (PST) Message-ID: <56DD90F8.60205@gmail.com> Date: Mon, 07 Mar 2016 18:02:24 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: Re: tcp window scaling + syn cookies problem References: <56DD7A6A.3070108@gmail.com> In-Reply-To: <56DD7A6A.3070108@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 07 Mar 2016 14:32:34 -0000 On 2016-03-07 4:26 PM, Hooman Fazaeli wrote: > > Hi, > > In our network, Windows clients connect to internet via our custom developed transparent > tcp proxy (running on 7.3). Things work fine, except that _sometimes_ downloads from the > some windows clients become very slow. To debug the problem, we inspected a few packet traces and > found out that the problem happens because the proxy TCP stack forgets about client's window > scale factor, as illustrated in the following packet trace (it is for a download from > ftp.freebsd.org site. x.y.z.y is a windows 8): > > 1. 15:09:32.765713 IP (tos 0x0, ttl 63, id 16510, offset 0, flags [DF], proto TCP (6), length 52) > x.y.z.y.57430 > 96.47.72.72.80: S, cksum 0x8343 (correct), 1530161492:1530161492(0) win 8192 > > 2. 15:09:32.765729 IP (tos 0x0, ttl 64, id 55869, offset 0, flags [none], proto TCP (6), length 52) > 96.47.72.72.80 > x.y.z.y.57430: S, cksum 0xe2c0 (correct), 503882603:503882603(0) ack 1530161493 win 65535 > > 3. 15:09:32.766071 IP (tos 0x0, ttl 63, id 16511, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x2192 (correct), ack 1 win 256 > > 4. 15:09:32.770074 IP (tos 0x0, ttl 63, id 16512, offset 0, flags [DF], proto TCP (6), length 408) > x.y.z.y.57430 > 96.47.72.72.80: P, cksum 0x259c (correct), 1:369(368) ack 1 win 256 > > 5. 15:09:32.869286 IP (tos 0x0, ttl 64, id 57834, offset 0, flags [none], proto TCP (6), length 40) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x2122 (correct), ack 369 win 65535 > > 6. 15:09:33.180983 IP (tos 0x0, ttl 64, id 64495, offset 0, flags [none], proto TCP (6), length 296) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0xbd5a (correct), 1:257(256) ack 369 win 65535 > > 7. 15:09:33.231475 IP (tos 0x0, ttl 63, id 16513, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1f23 (correct), ack 257 win 255 > > 8. 15:09:33.231494 IP (tos 0x0, ttl 64, id 248, offset 0, flags [none], proto TCP (6), length 295) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0xc9b6 (correct), 257:512(255) ack 369 win 65535 > > 9. 15:09:33.282256 IP (tos 0x0, ttl 63, id 16514, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1e25 (correct), ack 512 win 254 > > 10. 15:09:33.282279 IP (tos 0x0, ttl 64, id 1283, offset 0, flags [none], proto TCP (6), length 294) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x1e25 (correct), 512:766(254) ack 369 win 65535 > > 11. 15:09:33.333006 IP (tos 0x0, ttl 63, id 16515, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1d28 (correct), ack 766 win 253 > > 12. 15:09:33.333023 IP (tos 0x0, ttl 64, id 2520, offset 0, flags [none], proto TCP (6), length 293) > 96.47.72.72.80 > x.y.z.y.57430: ., cksum 0x1d28 (correct), 766:1019(253) ack 369 win 65535 > > 13. 15:09:33.383926 IP (tos 0x0, ttl 63, id 16516, offset 0, flags [DF], proto TCP (6), length 40) > x.y.z.y.57430 > 96.47.72.72.80: ., cksum 0x1c2c (correct), ack 1019 win 252 > > As can be seen, the client advertises a window scale factor of 8 and then correctly > sets packet's window size based on the advertised factor. But the proxy > seems to forget about client's scale factor and sends as much data as the > client's unscaled window size sent in a previous ACK. > > Now, setting 'net.inet.tcp.syncookies' to zero obviously seems to fix the problem > and the download speed becomes as expected. > > Is this bad interaction between window scaling and syn cookies > a known problem? Why it happens? Has it been fixed in later freebsd version? > > Thanks in advance. > A few minutes after posting, I found the following thread which describes an exact duplicate of our problem : https://lists.freebsd.org/pipermail/freebsd-net/2013-February/034519.html -- Best regards Hooman Fazaeli From owner-freebsd-net@freebsd.org Wed Mar 9 07:58:34 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 57647AC79E7; Wed, 9 Mar 2016 07:58:34 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D7A8647; Wed, 9 Mar 2016 07:58:34 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u297wOvK009237; Tue, 8 Mar 2016 23:58:28 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201603090758.u297wOvK009237@gw.catspoiler.org> Date: Tue, 8 Mar 2016 23:58:23 -0800 (PST) From: Don Lewis Subject: Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet To: ralsaadi@swin.edu.au cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, garmitage@swin.edu.au In-Reply-To: <6545444AE21C2749939E637E56594CEA3C187192@gsp-ex02.ds.swin.edu.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 07:58:34 -0000 On 26 Feb, Rasool Al-Saadi wrote: > Dear all, > > I would like to announce that we (myself and Grenville Armitage) released Dummynet AQM v0.1, which is an independent implementation of CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the IETF CoDel [1] and FQ-CoDel [2] Internet-Drafts. > We prepared patches for FreeBSD11-CURRENT-r295345 and FreeBSD 10.x-RELEASE (10.0, 10.1, 10.2), and a technical report of our implementation. > > Patches and documentation can be found in: > http://caia.swin.edu.au/freebsd/aqm Without the patch below, the dummynet module fails to load # kldload dummynet.ko kldload: can't load dummynet.ko: No such file or directory and the following is printed to /var/log/messages: link_elf: symbol sysctl__net_inet_ip_dummynet_children undefined I believe this patch is needed for FreeBSD 11 and all FreeBSD 10 releases. --- sys/netpfil/ipfw/ip_dn_io.c.prev 2016-03-06 00:51:38.012058648 -0800 +++ sys/netpfil/ipfw/ip_dn_io.c 2016-03-08 21:54:47.036921030 -0800 @@ -154,7 +154,7 @@ SYSCTL_DECL(_net_inet); SYSCTL_DECL(_net_inet_ip); -static SYSCTL_NODE(_net_inet_ip, OID_AUTO, dummynet, CTLFLAG_RW, 0, "Dummynet"); +SYSCTL_NODE(_net_inet_ip, OID_AUTO, dummynet, CTLFLAG_RW, 0, "Dummynet"); /* wrapper to pass dn_cfg fields to SYSCTL_* */ //#define DC(x) (&(VNET_NAME(_base_dn_cfg).x)) From owner-freebsd-net@freebsd.org Wed Mar 9 08:37:06 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 8363BAC8292; Wed, 9 Mar 2016 08:37:06 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E9C2F67; Wed, 9 Mar 2016 08:37:05 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from francos-mbp.lastsummer.de (ipservice-092-217-228-193.092.217.pools.vodafone-ip.de [92.217.228.193]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 25E466A60A; Wed, 9 Mar 2016 09:30:15 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet From: Franco Fichtner In-Reply-To: <201603090758.u297wOvK009237@gw.catspoiler.org> Date: Wed, 9 Mar 2016 09:30:14 +0100 Cc: ralsaadi@swin.edu.au, freebsd-net@freebsd.org, garmitage@swin.edu.au, freebsd-ipfw@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <22B0B893-3350-4DDF-925C-A35459807EC1@lastsummer.de> References: <201603090758.u297wOvK009237@gw.catspoiler.org> To: Don Lewis X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.99 at host64.kissl.de X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 08:37:06 -0000 > On 09 Mar 2016, at 8:58 AM, Don Lewis wrote: >=20 > On 26 Feb, Rasool Al-Saadi wrote: >> Dear all, >>=20 >> I would like to announce that we (myself and Grenville Armitage) = released Dummynet AQM v0.1, which is an independent implementation of = CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the = IETF CoDel [1] and FQ-CoDel [2] Internet-Drafts. >> We prepared patches for FreeBSD11-CURRENT-r295345 and FreeBSD = 10.x-RELEASE (10.0, 10.1, 10.2), and a technical report of our = implementation. Great work, Rasool. We are happy with the results of our tests so far. >> Patches and documentation can be found in: >> http://caia.swin.edu.au/freebsd/aqm >=20 > Without the patch below, the dummynet module fails to load >=20 > # kldload dummynet.ko > kldload: can't load dummynet.ko: No such file or directory It works for 10.2-RELEASE with the vanilla patch: root@sensey:~ # kldstat Id Refs Address Size Name 1 10 0xffffffff80200000 2148a60 kernel 2 1 0xffffffff82411000 6129 tmpfs.ko 3 1 0xffffffff82418000 2275 aesni.ko 4 1 0xffffffff8241b000 10dd amdtemp.ko 5 1 0xffffffff8241d000 7761 unionfs.ko root@sensey:~ # kldload dummynet root@sensey:~ # kldstat Id Refs Address Size Name 1 21 0xffffffff80200000 2148a60 kernel 2 1 0xffffffff82411000 6129 tmpfs.ko 3 1 0xffffffff82418000 2275 aesni.ko 4 1 0xffffffff8241b000 10dd amdtemp.ko 5 1 0xffffffff8241d000 7761 unionfs.ko 6 1 0xffffffff82425000 c9f8 dummynet.ko 7 1 0xffffffff82432000 caeb ipfw.ko root@sensey:~ # dmesg [...] ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to = accept, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_aqm dn_aqm CODEL loaded load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched FQ_CODEL loaded= From owner-freebsd-net@freebsd.org Wed Mar 9 10:29: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 9A06BAC98BC for ; Wed, 9 Mar 2016 10:29:15 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64638698 for ; Wed, 9 Mar 2016 10:29:15 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id DE028B61D233 for ; Wed, 9 Mar 2016 11:29:11 +0100 (CET) Date: Wed, 9 Mar 2016 11:29:11 +0100 (CET) From: elof2@sentor.se To: freebsd-net Subject: Source routing howto Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 10:29:15 -0000 Hi all! I've been searching the internet but can't find any good documentation/examples on how to setup source routing in my FreeBSD. What I want to do: Let internet clients connect their OpenVPN to a FreeBSD box. The client's internet traffic should be routed to a separate firewall dedicated for all client networks (VPN and physical), where all clients then leave the network. The FreeBSD box has its own normal default gateway to speak with the internet. This route is needed in order to be able to keep the OpenVPN-traffic flowing. How do I source route the tunneled traffic, coming from e.g. 10.10.10.x to the "client firewall"? Are there any good examples out there? Do I have to compile a custom kernel? (the responses back from that firewall use a normal static route, pointing 10.10.10.0/24 to the FreeBSD box) /Elof From owner-freebsd-net@freebsd.org Wed Mar 9 11:33: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 D41A8AC99F2 for ; Wed, 9 Mar 2016 11:33:38 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 A27416CB for ; Wed, 9 Mar 2016 11:33:38 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 56E3B103B4 for ; Wed, 9 Mar 2016 12:33:27 +0100 (CET) Subject: Re: Source routing howto To: freebsd-net@freebsd.org References: From: Jan Bramkamp Message-ID: <56E00A06.20700@rlwinm.de> Date: Wed, 9 Mar 2016 12:33:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 11:33:38 -0000 On 09/03/16 11:29, elof2@sentor.se wrote: > Hi all! > > I've been searching the internet but can't find any good > documentation/examples on how to setup source routing in my FreeBSD. > > What I want to do: > > Let internet clients connect their OpenVPN to a FreeBSD box. The > client's internet traffic should be routed to a separate firewall > dedicated for all client networks (VPN and physical), where all clients > then leave the network. > > The FreeBSD box has its own normal default gateway to speak with the > internet. > This route is needed in order to be able to keep the OpenVPN-traffic > flowing. > > How do I source route the tunneled traffic, coming from e.g. 10.10.10.x > to the "client firewall"? > > Are there any good examples out there? > Do I have to compile a custom kernel? > > (the responses back from that firewall use a normal static route, > pointing 10.10.10.0/24 to the FreeBSD box) Do I understand you correctly that you have a FreeBSD box acting as * OpenVPN endpoint * router * and firewall all in one system and you want use the OpenVPN tunnel as default route for your *other* hosts? In that case what you need is some kind of *policy* based routing. One way to go about it with more than one FIB (aka kernel routing table). The problem is that you have to decide on the routing table to use before performing the route lookup. For packets forwarded through your FreeBSD router you have to select a non default FIB during input filtering e.g. # simple case ipfw add setfib 1 all from any to any in via $lan_if # complex case for multiple interfaces # ipfw table add ipfw table 1 add $lan_if1 1 ipfw table 1 add $lan_if2 2 ipfw table 1 add $lan_if3 2 ipfw table 1 add $lan_if3 2 # ... # lookup routing table number in a table ipfw add setfib tablearg all from any to any via table(1) For traffic generated by your FreeBSD router you can't use the firewall to set the routing table because locally generated traffic only passes through output filtering by which time the routing decision has already happend. Instead you can set a processes default routing table with the setfib(1) utility or use a setsockopt(2) with SO_SETFIB for each socket. Jails can also set default routing table for sockets created inside the jail. Remember that your DNS resolver can leak a lot of information as well if it uses the default routing table. I would avoid policies based on IP addresses and prefer to define policies based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan123 through the VPN tunnel. From owner-freebsd-net@freebsd.org Wed Mar 9 13:40: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 8E974AC900D for ; Wed, 9 Mar 2016 13:40:26 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55B31C01 for ; Wed, 9 Mar 2016 13:40:25 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id BDF59B61D233; Wed, 9 Mar 2016 14:40:16 +0100 (CET) Date: Wed, 9 Mar 2016 14:40:16 +0100 (CET) From: elof2@sentor.se To: Jan Bramkamp cc: freebsd-net Subject: Re: Source routing howto In-Reply-To: <56E00A06.20700@rlwinm.de> Message-ID: References: <56E00A06.20700@rlwinm.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 13:40:26 -0000 On Wed, 9 Mar 2016, Jan Bramkamp wrote: > On 09/03/16 11:29, elof2@sentor.se wrote: >> I've been searching the internet but can't find any good >> documentation/examples on how to setup source routing in my FreeBSD. >> >> What I want to do: >> >> Let internet clients connect their OpenVPN to a FreeBSD box. The >> client's internet traffic should be routed to a separate firewall >> dedicated for all client networks (VPN and physical), where all clients >> then leave the network. >> >> The FreeBSD box has its own normal default gateway to speak with the >> internet. >> This route is needed in order to be able to keep the OpenVPN-traffic >> flowing. >> >> How do I source route the tunneled traffic, coming from e.g. 10.10.10.x >> to the "client firewall"? >> >> Are there any good examples out there? >> Do I have to compile a custom kernel? >> >> (the responses back from that firewall use a normal static route, >> pointing 10.10.10.0/24 to the FreeBSD box) > > Do I understand you correctly that you have a FreeBSD box acting as > > * OpenVPN endpoint > * router > * and firewall The FreeBSD box is an OpenVPN server. Naturally it is also a router (forwarding enabled). It has local firewall rules (using pf), but when I talk about a firewall I mean a separate box (Juniper/Checkpoint/something). > all in one system and you want use the OpenVPN tunnel as default route for > your *other* hosts? Heh, my description was pretty bad. New try: 100 clients around the world connect to an OpenVPN server called "SRV". SRV has a default route, so incoming and outgoing VPN packets use internet connection A (router A). So far everything is as normal it can be. A server, a default route and an internet connection. Next, all the vpn clients' traffic is sucked into their VPN tunnels (no split tunneling allowed). The clients can reach internal servers. Good. But when the clients surf the web, their traffic originates from SRV, using its default route towards the internet. This works but is no longer what I want. I now want the client traffic, aimed for the internet, to be routed elsewhere. In my case, "elsewhere" is a firewall with its own internet connection (B). The firewall is equipped with extra functions/blades to inspect client traffic and have all the rules for client traffic. So basically I want the remote VPN users' surf traffic to pass through firewall B. ( In my example, the VPN clients will get IPs in the 10.10.10.0/24 range. Firewall B only need to route 10.10.10.0/24 to SRV in order to forward the response surf traffic back to the VPN clients. ) So on SRV I need: * traffic from SRV itself (openvpn responses, freebsd-update, mail, dns and other stuff) to 'any' should be routed to router A. Currently my default route. * traffic with src net 10.10.10.0/24 to 'any' should be routed to B. So two destinations for 'any'. Hence the need for source routing. PS: traffic with src net 10.10.10.0/24 to internal nets, like 10.20.30.0/24, should still be routed normally and not be thrown onto router B. Hope that description is better. > In that case what you need is some kind of *policy* based > routing. > One way to go about it with more than one FIB (aka kernel routing table). The > problem is that you have to decide on the routing table to use before > performing the route lookup. For packets forwarded through your FreeBSD > router you have to select a non default FIB during input filtering e.g. > # simple case > ipfw add setfib 1 all from any to any in via $lan_if > # complex case for multiple interfaces > # ipfw table add > ipfw table 1 add $lan_if1 1 > ipfw table 1 add $lan_if2 2 > ipfw table 1 add $lan_if3 2 > ipfw table 1 add $lan_if3 2 > # ... > # lookup routing table number in a table > ipfw add setfib tablearg all from any to any via table(1) > For traffic generated by your FreeBSD router you can't use the firewall to > set the routing table because locally generated traffic only passes through > output filtering by which time the routing decision has already happend. > Instead you can set a processes default routing table with the setfib(1) > utility or use a setsockopt(2) with SO_SETFIB for each socket. Jails can also > set default routing table for sockets created inside the jail. Heh. Do you mind giving another example now with the above description of the setup? PS: i already use pf, not ipfw, on SRV. > Remember that your DNS resolver can leak a lot of information as well if it > uses the default routing table. Thanks for the heads-up. No, it uses an internal DNS. > I would avoid policies based on IP addresses and prefer to define policies > based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan123 > through the VPN tunnel. The only two things I have to play with here is: * ip range 10.10.10.x or * tun0 Using 'tun0' might not be possible if it has to exist when ipfw/pf load at boot, 'cause tun0 is not created until the openvpn service has started. /Elof From owner-freebsd-net@freebsd.org Wed Mar 9 14:08: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 A2CA9AC9D4E for ; Wed, 9 Mar 2016 14:08:45 +0000 (UTC) (envelope-from Vladimir.Terziev@bwinparty.com) Received: from mgate03.itsfogo.com (mgate03.itsfogo.com [195.72.134.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.itsfogo.com", Issuer "thawte SSL CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 42837D1C for ; Wed, 9 Mar 2016 14:08:44 +0000 (UTC) (envelope-from Vladimir.Terziev@bwinparty.com) From: Vladimir Terziev To: " " CC: Jan Bramkamp , freebsd-net Subject: Re: Source routing howto Thread-Topic: Source routing howto Thread-Index: AQHRee6Q0/m5RgFfW0ymY5bZBvj9cJ9Q6lwAgAAjcACAAAO2gA== Date: Wed, 9 Mar 2016 13:53:33 +0000 Message-ID: References: <56E00A06.20700@rlwinm.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [10.138.239.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <139427116B75014288AF9850E370F1A7@bwinparty.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 14:08:45 -0000 Hi, would this rule to the trick for what you need ? ipfw add fwd Routed_B_IP ip from 10.10.10.0/24 to not 10.0.0.0/8 Regards, Vladimir On Mar 9, 2016, at 3:40 PM, wrote: >=20 > On Wed, 9 Mar 2016, Jan Bramkamp wrote: >> On 09/03/16 11:29, elof2@sentor.se wrote: >>> I've been searching the internet but can't find any good >>> documentation/examples on how to setup source routing in my FreeBSD. >>> What I want to do: >>> Let internet clients connect their OpenVPN to a FreeBSD box. The >>> client's internet traffic should be routed to a separate firewall >>> dedicated for all client networks (VPN and physical), where all clients >>> then leave the network. >>> The FreeBSD box has its own normal default gateway to speak with the >>> internet. >>> This route is needed in order to be able to keep the OpenVPN-traffic >>> flowing. >>> How do I source route the tunneled traffic, coming from e.g. 10.10.10.x >>> to the "client firewall"? >>> Are there any good examples out there? >>> Do I have to compile a custom kernel? >>> (the responses back from that firewall use a normal static route, >>> pointing 10.10.10.0/24 to the FreeBSD box) >>=20 >> Do I understand you correctly that you have a FreeBSD box acting as >>=20 >> * OpenVPN endpoint >> * router >> * and firewall >=20 > The FreeBSD box is an OpenVPN server. > Naturally it is also a router (forwarding enabled). > It has local firewall rules (using pf), but when I talk about a firewall = I mean a separate box (Juniper/Checkpoint/something). >=20 >> all in one system and you want use the OpenVPN tunnel as default route f= or your *other* hosts? >=20 > Heh, my description was pretty bad. >=20 > New try: > 100 clients around the world connect to an OpenVPN server called "SRV". > SRV has a default route, so incoming and outgoing VPN packets use interne= t connection A (router A). >=20 > So far everything is as normal it can be. A server, a default route and a= n internet connection. >=20 > Next, all the vpn clients' traffic is sucked into their VPN tunnels (no s= plit tunneling allowed). > The clients can reach internal servers. Good. > But when the clients surf the web, their traffic originates from SRV, usi= ng its default route towards the internet. >=20 > This works but is no longer what I want. >=20 > I now want the client traffic, aimed for the internet, to be routed elsew= here. In my case, "elsewhere" is a firewall with its own internet connectio= n (B). The firewall is equipped with extra functions/blades to inspect clie= nt traffic and have all the rules for client traffic. >=20 > So basically I want the remote VPN users' surf traffic to pass through fi= rewall B. >=20 > ( > In my example, the VPN clients will get IPs in the 10.10.10.0/24 range. >=20 > Firewall B only need to route 10.10.10.0/24 to SRV in order to forward th= e response surf traffic back to the VPN clients. > ) >=20 >=20 > So on SRV I need: > * traffic from SRV itself (openvpn responses, freebsd-update, mail, dns a= nd other stuff) to 'any' should be routed to router A. Currently my default= route. > * traffic with src net 10.10.10.0/24 to 'any' should be routed to B. >=20 > So two destinations for 'any'. Hence the need for source routing. >=20 > PS: traffic with src net 10.10.10.0/24 to internal nets, like 10.20.30.0/= 24, should still be routed normally and not be thrown onto router B. >=20 > Hope that description is better. >=20 >=20 >> In that case what you need is some kind of *policy* based routing. >> One way to go about it with more than one FIB (aka kernel routing table)= . The problem is that you have to decide on the routing table to use before= performing the route lookup. For packets forwarded through your FreeBSD ro= uter you have to select a non default FIB during input filtering e.g. >> # simple case >> ipfw add setfib 1 all from any to any in via $lan_if >> # complex case for multiple interfaces >> # ipfw table add >> ipfw table 1 add $lan_if1 1 >> ipfw table 1 add $lan_if2 2 >> ipfw table 1 add $lan_if3 2 >> ipfw table 1 add $lan_if3 2 >> # ... >> # lookup routing table number in a table >> ipfw add setfib tablearg all from any to any via table(1) >> For traffic generated by your FreeBSD router you can't use the firewall = to set the routing table because locally generated traffic only passes thro= ugh output filtering by which time the routing decision has already happend= . Instead you can set a processes default routing table with the setfib(1) = utility or use a setsockopt(2) with SO_SETFIB for each socket. Jails can al= so set default routing table for sockets created inside the jail. >=20 > Heh. Do you mind giving another example now with the above description of= the setup? > PS: i already use pf, not ipfw, on SRV. >=20 >=20 >> Remember that your DNS resolver can leak a lot of information as well if= it uses the default routing table. >=20 > Thanks for the heads-up. No, it uses an internal DNS. >=20 >=20 >> I would avoid policies based on IP addresses and prefer to define polici= es based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan123= through the VPN tunnel. >=20 > The only two things I have to play with here is: > * ip range 10.10.10.x > or > * tun0 >=20 > Using 'tun0' might not be possible if it has to exist when ipfw/pf load a= t boot, 'cause tun0 is not created until the openvpn service has started. >=20 > /Elof > _______________________________________________ > 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 Mar 9 14:26: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 670D0AC9512 for ; Wed, 9 Mar 2016 14:26:28 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C57A9DF for ; Wed, 9 Mar 2016 14:26:27 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id 21125B61D233; Wed, 9 Mar 2016 15:26:26 +0100 (CET) Date: Wed, 9 Mar 2016 15:26:26 +0100 (CET) From: elof2@sentor.se To: Vladimir Terziev cc: freebsd-net , Jan Bramkamp Subject: Re: Source routing howto In-Reply-To: Message-ID: References: <56E00A06.20700@rlwinm.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 14:26:28 -0000 Intrersting! Unfortunetly I can't test right now. Will let you know. If I understand correctly, the 'ipfw fwd approach' don't use any FIBs, so it should be applicable to the *outgoing* traffic. Regarding the FIBs: In FreeBSD 10.1 RELEASE, no extra FIBs can be added since that kernel is compiled without support for it. :-( I'm hesitant to break binary compability (I use freebsd-update). Will release 10.3 or 11.0 have "options ROUTETABLES=2" in their GENERIC kernel conf? Anyone knows? /Elof On Wed, 9 Mar 2016, Vladimir Terziev wrote: > Hi, > > would this rule to the trick for what you need ? > > ipfw add fwd Routed_B_IP ip from 10.10.10.0/24 to not 10.0.0.0/8 > > > Regards, > > Vladimir > > > On Mar 9, 2016, at 3:40 PM, > wrote: > >> >> On Wed, 9 Mar 2016, Jan Bramkamp wrote: >>> On 09/03/16 11:29, elof2@sentor.se wrote: >>>> I've been searching the internet but can't find any good >>>> documentation/examples on how to setup source routing in my FreeBSD. >>>> What I want to do: >>>> Let internet clients connect their OpenVPN to a FreeBSD box. The >>>> client's internet traffic should be routed to a separate firewall >>>> dedicated for all client networks (VPN and physical), where all clients >>>> then leave the network. >>>> The FreeBSD box has its own normal default gateway to speak with the >>>> internet. >>>> This route is needed in order to be able to keep the OpenVPN-traffic >>>> flowing. >>>> How do I source route the tunneled traffic, coming from e.g. 10.10.10.x >>>> to the "client firewall"? >>>> Are there any good examples out there? >>>> Do I have to compile a custom kernel? >>>> (the responses back from that firewall use a normal static route, >>>> pointing 10.10.10.0/24 to the FreeBSD box) >>> >>> Do I understand you correctly that you have a FreeBSD box acting as >>> >>> * OpenVPN endpoint >>> * router >>> * and firewall >> >> The FreeBSD box is an OpenVPN server. >> Naturally it is also a router (forwarding enabled). >> It has local firewall rules (using pf), but when I talk about a firewall I mean a separate box (Juniper/Checkpoint/something). >> >>> all in one system and you want use the OpenVPN tunnel as default route for your *other* hosts? >> >> Heh, my description was pretty bad. >> >> New try: >> 100 clients around the world connect to an OpenVPN server called "SRV". >> SRV has a default route, so incoming and outgoing VPN packets use internet connection A (router A). >> >> So far everything is as normal it can be. A server, a default route and an internet connection. >> >> Next, all the vpn clients' traffic is sucked into their VPN tunnels (no split tunneling allowed). >> The clients can reach internal servers. Good. >> But when the clients surf the web, their traffic originates from SRV, using its default route towards the internet. >> >> This works but is no longer what I want. >> >> I now want the client traffic, aimed for the internet, to be routed elsewhere. In my case, "elsewhere" is a firewall with its own internet connection (B). The firewall is equipped with extra functions/blades to inspect client traffic and have all the rules for client traffic. >> >> So basically I want the remote VPN users' surf traffic to pass through firewall B. >> >> ( >> In my example, the VPN clients will get IPs in the 10.10.10.0/24 range. >> >> Firewall B only need to route 10.10.10.0/24 to SRV in order to forward the response surf traffic back to the VPN clients. >> ) >> >> >> So on SRV I need: >> * traffic from SRV itself (openvpn responses, freebsd-update, mail, dns and other stuff) to 'any' should be routed to router A. Currently my default route. >> * traffic with src net 10.10.10.0/24 to 'any' should be routed to B. >> >> So two destinations for 'any'. Hence the need for source routing. >> >> PS: traffic with src net 10.10.10.0/24 to internal nets, like 10.20.30.0/24, should still be routed normally and not be thrown onto router B. >> >> Hope that description is better. >> >> >>> In that case what you need is some kind of *policy* based routing. >>> One way to go about it with more than one FIB (aka kernel routing table). The problem is that you have to decide on the routing table to use before performing the route lookup. For packets forwarded through your FreeBSD router you have to select a non default FIB during input filtering e.g. >>> # simple case >>> ipfw add setfib 1 all from any to any in via $lan_if >>> # complex case for multiple interfaces >>> # ipfw table add >>> ipfw table 1 add $lan_if1 1 >>> ipfw table 1 add $lan_if2 2 >>> ipfw table 1 add $lan_if3 2 >>> ipfw table 1 add $lan_if3 2 >>> # ... >>> # lookup routing table number in a table >>> ipfw add setfib tablearg all from any to any via table(1) >>> For traffic generated by your FreeBSD router you can't use the firewall to set the routing table because locally generated traffic only passes through output filtering by which time the routing decision has already happend. Instead you can set a processes default routing table with the setfib(1) utility or use a setsockopt(2) with SO_SETFIB for each socket. Jails can also set default routing table for sockets created inside the jail. >> >> Heh. Do you mind giving another example now with the above description of the setup? >> PS: i already use pf, not ipfw, on SRV. >> >> >>> Remember that your DNS resolver can leak a lot of information as well if it uses the default routing table. >> >> Thanks for the heads-up. No, it uses an internal DNS. >> >> >>> I would avoid policies based on IP addresses and prefer to define policies based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan123 through the VPN tunnel. >> >> The only two things I have to play with here is: >> * ip range 10.10.10.x >> or >> * tun0 >> >> Using 'tun0' might not be possible if it has to exist when ipfw/pf load at boot, 'cause tun0 is not created until the openvpn service has started. >> >> /Elof >> _______________________________________________ >> 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 Wed Mar 9 14:32: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 DAAE2AC981B for ; Wed, 9 Mar 2016 14:32:40 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [148.251.233.239]) (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 A46A1E1D for ; Wed, 9 Mar 2016 14:32:40 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.local (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id ABC931417; Wed, 9 Mar 2016 15:32:37 +0100 (CET) Subject: Re: Source routing howto To: elof2@sentor.se, Vladimir Terziev References: <56E00A06.20700@rlwinm.de> Cc: freebsd-net From: Jan Bramkamp Message-ID: <56E03404.2040204@rlwinm.de> Date: Wed, 9 Mar 2016 15:32:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 14:32:41 -0000 On 09/03/16 15:26, elof2@sentor.se wrote: > Regarding the FIBs: > > In FreeBSD 10.1 RELEASE, no extra FIBs can be added since that kernel is > compiled without support for it. :-( > I'm hesitant to break binary compability (I use freebsd-update). > > Will release 10.3 or 11.0 have "options ROUTETABLES=2" in their GENERIC > kernel conf? Anyone knows? I don't remember how FreeBSD 10.1 did it, but in FreeBSD 10.2 the number of routing tables (e.g. net.fibs=2) is a boottime loader tunable and can be changed in /boot/loader.conf without rebuilding the kernel. Moving from 10.1 to 10.2 is a painless way to gain this feature if it isn't available in 10.1 already. From owner-freebsd-net@freebsd.org Wed Mar 9 14:38:33 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 13F43AC9A4A for ; Wed, 9 Mar 2016 14:38:33 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD1188E for ; Wed, 9 Mar 2016 14:38:32 +0000 (UTC) (envelope-from elof2@sentor.se) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id C70E0B61D233; Wed, 9 Mar 2016 15:38:30 +0100 (CET) Date: Wed, 9 Mar 2016 15:38:30 +0100 (CET) From: elof2@sentor.se To: Jan Bramkamp cc: Vladimir Terziev , freebsd-net Subject: Re: Source routing howto In-Reply-To: <56E03404.2040204@rlwinm.de> Message-ID: References: <56E00A06.20700@rlwinm.de> <56E03404.2040204@rlwinm.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 14:38:33 -0000 Ah! Yep, that boot option exist in 10.1 as well. :-) Now I have two approaches to test. Thanks! /Elof On Wed, 9 Mar 2016, Jan Bramkamp wrote: > On 09/03/16 15:26, elof2@sentor.se wrote: >> Regarding the FIBs: >> >> In FreeBSD 10.1 RELEASE, no extra FIBs can be added since that kernel is >> compiled without support for it. :-( >> I'm hesitant to break binary compability (I use freebsd-update). >> >> Will release 10.3 or 11.0 have "options ROUTETABLES=2" in their GENERIC >> kernel conf? Anyone knows? > > I don't remember how FreeBSD 10.1 did it, but in FreeBSD 10.2 the number of > routing tables (e.g. net.fibs=2) is a boottime loader tunable and can be > changed in /boot/loader.conf without rebuilding the kernel. Moving from 10.1 > to 10.2 is a painless way to gain this feature if it isn't available in 10.1 > already. > _______________________________________________ > 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 Mar 9 14:41:48 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 D8766AC9B81 for ; Wed, 9 Mar 2016 14:41:48 +0000 (UTC) (envelope-from Vladimir.Terziev@bwinparty.com) Received: from mgate03.itsfogo.com (mgate03.itsfogo.com [195.72.134.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.itsfogo.com", Issuer "thawte SSL CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79CD33B5 for ; Wed, 9 Mar 2016 14:41:47 +0000 (UTC) (envelope-from Vladimir.Terziev@bwinparty.com) From: Vladimir Terziev To: "elof2@sentor.se" CC: freebsd-net , Jan Bramkamp Subject: Re: Source routing howto Thread-Topic: Source routing howto Thread-Index: AQHRee6Q0/m5RgFfW0ymY5bZBvj9cJ9Q6lwAgAAjcACAAAO2gIAACTAAgAAERwA= Date: Wed, 9 Mar 2016 14:41:45 +0000 Message-ID: References: <56E00A06.20700@rlwinm.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [10.138.239.254] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 09 Mar 2016 14:41:48 -0000 Don't forget, your router B should return back to router A (the FreeBSD box= ) all packets destinated to 10.10.10.0/24 . Regards, Vladimir On Mar 9, 2016, at 4:26 PM, elof2@sentor.se wrote: > Intrersting! > Unfortunetly I can't test right now. Will let you know. >=20 > If I understand correctly, the 'ipfw fwd approach' don't use any FIBs, so= it should be applicable to the *outgoing* traffic. >=20 >=20 >=20 > Regarding the FIBs: >=20 > In FreeBSD 10.1 RELEASE, no extra FIBs can be added since that kernel is = compiled without support for it. :-( > I'm hesitant to break binary compability (I use freebsd-update). >=20 > Will release 10.3 or 11.0 have "options ROUTETABLES=3D2" in their GENERIC= kernel conf? Anyone knows? >=20 > /Elof >=20 >=20 > On Wed, 9 Mar 2016, Vladimir Terziev wrote: >=20 >> Hi, >>=20 >> would this rule to the trick for what you need ? >>=20 >> ipfw add fwd Routed_B_IP ip from 10.10.10.0/24 to not 10.0.0.0/8 >>=20 >>=20 >> Regards, >>=20 >> Vladimir >>=20 >>=20 >> On Mar 9, 2016, at 3:40 PM, >> wrote: >>=20 >>>=20 >>> On Wed, 9 Mar 2016, Jan Bramkamp wrote: >>>> On 09/03/16 11:29, elof2@sentor.se wrote: >>>>> I've been searching the internet but can't find any good >>>>> documentation/examples on how to setup source routing in my FreeBSD. >>>>> What I want to do: >>>>> Let internet clients connect their OpenVPN to a FreeBSD box. The >>>>> client's internet traffic should be routed to a separate firewall >>>>> dedicated for all client networks (VPN and physical), where all clien= ts >>>>> then leave the network. >>>>> The FreeBSD box has its own normal default gateway to speak with the >>>>> internet. >>>>> This route is needed in order to be able to keep the OpenVPN-traffic >>>>> flowing. >>>>> How do I source route the tunneled traffic, coming from e.g. 10.10.10= .x >>>>> to the "client firewall"? >>>>> Are there any good examples out there? >>>>> Do I have to compile a custom kernel? >>>>> (the responses back from that firewall use a normal static route, >>>>> pointing 10.10.10.0/24 to the FreeBSD box) >>>>=20 >>>> Do I understand you correctly that you have a FreeBSD box acting as >>>>=20 >>>> * OpenVPN endpoint >>>> * router >>>> * and firewall >>>=20 >>> The FreeBSD box is an OpenVPN server. >>> Naturally it is also a router (forwarding enabled). >>> It has local firewall rules (using pf), but when I talk about a firewal= l I mean a separate box (Juniper/Checkpoint/something). >>>=20 >>>> all in one system and you want use the OpenVPN tunnel as default route= for your *other* hosts? >>>=20 >>> Heh, my description was pretty bad. >>>=20 >>> New try: >>> 100 clients around the world connect to an OpenVPN server called "SRV". >>> SRV has a default route, so incoming and outgoing VPN packets use inter= net connection A (router A). >>>=20 >>> So far everything is as normal it can be. A server, a default route and= an internet connection. >>>=20 >>> Next, all the vpn clients' traffic is sucked into their VPN tunnels (no= split tunneling allowed). >>> The clients can reach internal servers. Good. >>> But when the clients surf the web, their traffic originates from SRV, u= sing its default route towards the internet. >>>=20 >>> This works but is no longer what I want. >>>=20 >>> I now want the client traffic, aimed for the internet, to be routed els= ewhere. In my case, "elsewhere" is a firewall with its own internet connect= ion (B). The firewall is equipped with extra functions/blades to inspect cl= ient traffic and have all the rules for client traffic. >>>=20 >>> So basically I want the remote VPN users' surf traffic to pass through = firewall B. >>>=20 >>> ( >>> In my example, the VPN clients will get IPs in the 10.10.10.0/24 range. >>>=20 >>> Firewall B only need to route 10.10.10.0/24 to SRV in order to forward = the response surf traffic back to the VPN clients. >>> ) >>>=20 >>>=20 >>> So on SRV I need: >>> * traffic from SRV itself (openvpn responses, freebsd-update, mail, dns= and other stuff) to 'any' should be routed to router A. Currently my defau= lt route. >>> * traffic with src net 10.10.10.0/24 to 'any' should be routed to B. >>>=20 >>> So two destinations for 'any'. Hence the need for source routing. >>>=20 >>> PS: traffic with src net 10.10.10.0/24 to internal nets, like 10.20.30.= 0/24, should still be routed normally and not be thrown onto router B. >>>=20 >>> Hope that description is better. >>>=20 >>>=20 >>>> In that case what you need is some kind of *policy* based routing. >>>> One way to go about it with more than one FIB (aka kernel routing tabl= e). The problem is that you have to decide on the routing table to use befo= re performing the route lookup. For packets forwarded through your FreeBSD = router you have to select a non default FIB during input filtering e.g. >>>> # simple case >>>> ipfw add setfib 1 all from any to any in via $lan_if >>>> # complex case for multiple interfaces >>>> # ipfw table add >>>> ipfw table 1 add $lan_if1 1 >>>> ipfw table 1 add $lan_if2 2 >>>> ipfw table 1 add $lan_if3 2 >>>> ipfw table 1 add $lan_if3 2 >>>> # ... >>>> # lookup routing table number in a table >>>> ipfw add setfib tablearg all from any to any via table(1) >>>> For traffic generated by your FreeBSD router you can't use the firewal= l to set the routing table because locally generated traffic only passes th= rough output filtering by which time the routing decision has already happe= nd. Instead you can set a processes default routing table with the setfib(1= ) utility or use a setsockopt(2) with SO_SETFIB for each socket. Jails can = also set default routing table for sockets created inside the jail. >>>=20 >>> Heh. Do you mind giving another example now with the above description = of the setup? >>> PS: i already use pf, not ipfw, on SRV. >>>=20 >>>=20 >>>> Remember that your DNS resolver can leak a lot of information as well = if it uses the default routing table. >>>=20 >>> Thanks for the heads-up. No, it uses an internal DNS. >>>=20 >>>=20 >>>> I would avoid policies based on IP addresses and prefer to define poli= cies based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan1= 23 through the VPN tunnel. >>>=20 >>> The only two things I have to play with here is: >>> * ip range 10.10.10.x >>> or >>> * tun0 >>>=20 >>> Using 'tun0' might not be possible if it has to exist when ipfw/pf load= at boot, 'cause tun0 is not created until the openvpn service has started. >>>=20 >>> /Elof >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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 From owner-freebsd-net@freebsd.org Thu Mar 10 00:15: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 8BF66AC98BD; Thu, 10 Mar 2016 00:15:07 +0000 (UTC) (envelope-from ralsaadi@swin.edu.au) Received: from iport2.cc.swin.edu.au (iport2.cc.swin.edu.au [136.186.0.52]) by mx1.freebsd.org (Postfix) with ESMTP id C67B6AEF; Thu, 10 Mar 2016 00:15:06 +0000 (UTC) (envelope-from ralsaadi@swin.edu.au) X-IronPort-AV: E=Sophos;i="5.24,313,1454936400"; d="scan'208";a="17870105" Received: from gsp-ex01.ds.swin.edu.au (HELO outlook.swin.edu.au) ([136.186.126.17]) by iport2.cc.swin.edu.au with ESMTP; 10 Mar 2016 11:13:55 +1100 Received: from GSP-EX02.ds.swin.edu.au ([169.254.2.71]) by gsp-ex01.ds.swin.edu.au ([169.254.1.193]) with mapi id 14.03.0279.002; Thu, 10 Mar 2016 11:13:55 +1100 From: Rasool Al-Saadi To: Don Lewis CC: "freebsd-net@FreeBSD.org" , "freebsd-ipfw@FreeBSD.org" , Grenville Armitage Subject: RE: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet Thread-Topic: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet Thread-Index: AdFwoEB9RcA1ON/lTEC2HgPx0zqG6gI3P/+AADimT8A= Date: Thu, 10 Mar 2016 00:13:54 +0000 Message-ID: <6545444AE21C2749939E637E56594CEA3C1B0A7C@gsp-ex02.ds.swin.edu.au> References: <6545444AE21C2749939E637E56594CEA3C187192@gsp-ex02.ds.swin.edu.au> <201603090758.u297wOvK009237@gw.catspoiler.org> In-Reply-To: <201603090758.u297wOvK009237@gw.catspoiler.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.186.126.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 10 Mar 2016 00:15:07 -0000 On Wednesday, 9 March 2016, Don Lewis wrote: >=20 > On 26 Feb, Rasool Al-Saadi wrote: > > Dear all, > > > > I would like to announce that we (myself and Grenville Armitage) releas= ed > Dummynet AQM v0.1, which is an independent implementation of CoDel and > FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the IETF > CoDel [1] and FQ-CoDel [2] Internet-Drafts. > > We prepared patches for FreeBSD11-CURRENT-r295345 and FreeBSD 10.x- > RELEASE (10.0, 10.1, 10.2), and a technical report of our implementation= . > > > > Patches and documentation can be found in: > > http://caia.swin.edu.au/freebsd/aqm >=20 > Without the patch below, the dummynet module fails to load >=20 > # kldload dummynet.ko > kldload: can't load dummynet.ko: No such file or directory >=20 > and the following is printed to /var/log/messages: >=20 > link_elf: symbol sysctl__net_inet_ip_dummynet_children undefined Thanks again for testing the patch and for providing feedback. It seems that this error (and the compilation error in your previous email)= appears in i386 versions of FreeBSD.=20 > I believe this patch is needed for FreeBSD 11 and all FreeBSD 10 releases= . I will add you patch to Dummynet AQM v0.2. Regards, Rasool Al-Saadi =20 > --- sys/netpfil/ipfw/ip_dn_io.c.prev 2016-03-06 00:51:38.012058648 -0800 > +++ sys/netpfil/ipfw/ip_dn_io.c 2016-03-08 21:54:47.036921030 -0800 > @@ -154,7 +154,7 @@ >=20 > SYSCTL_DECL(_net_inet); > SYSCTL_DECL(_net_inet_ip); > -static SYSCTL_NODE(_net_inet_ip, OID_AUTO, dummynet, CTLFLAG_RW, 0, > "Dummynet"); > +SYSCTL_NODE(_net_inet_ip, OID_AUTO, dummynet, CTLFLAG_RW, 0, > +"Dummynet"); >=20 > /* wrapper to pass dn_cfg fields to SYSCTL_* */ > //#define DC(x) (&(VNET_NAME(_base_dn_cfg).x)) From owner-freebsd-net@freebsd.org Thu Mar 10 01:02: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 18AE1AC918A for ; Thu, 10 Mar 2016 01:02:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09F6219A for ; Thu, 10 Mar 2016 01:02:57 +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 u2A12tU0040604 for ; Thu, 10 Mar 2016 01:02:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207701] vlan interface over failover lagg has empty/00:00:00:00:00:00 mac/ether address Date: Thu, 10 Mar 2016 01:02:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-BETA2 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: araujo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: araujo@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 10 Mar 2016 01:02:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207701 Marcelo Araujo changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |araujo@FreeBSD.org --- Comment #1 from Marcelo Araujo --- I will take a look on it. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 10 05:37: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 71EA9ACA45F for ; Thu, 10 Mar 2016 05:37:56 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 E7DCCA56 for ; Thu, 10 Mar 2016 05:37:55 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u2A5UU4j041337; Thu, 10 Mar 2016 16:30:31 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 10 Mar 2016 16:30:30 +1100 (EST) From: Ian Smith To: elof2@sentor.se cc: Jan Bramkamp , freebsd-net Subject: Re: Source routing howto In-Reply-To: Message-ID: <20160310153215.V61428@sola.nimnet.asn.au> References: <56E00A06.20700@rlwinm.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 10 Mar 2016 05:37:56 -0000 On Wed, 9 Mar 2016 14:40:16 +0100, elof2@sentor.se wrote: > On Wed, 9 Mar 2016, Jan Bramkamp wrote: [..] > > I would avoid policies based on IP addresses and prefer to define policies > > based on (pseudo-) interfaces e.g. route (and nat?) traffic from vlan123 > > through the VPN tunnel. > > The only two things I have to play with here is: > * ip range 10.10.10.x > or > * tun0 > > Using 'tun0' might not be possible if it has to exist when ipfw/pf load at > boot, 'cause tun0 is not created until the openvpn service has started. I can't speak to pf, but ipfw doesn't require an interface to preexist. I use mpd which creates interface ng0, well after firewall rules have been loaded. In antiquity I used ppp; I can't recall whether the same applied to tun0 similarly, and don't use vpns at all, but: root@x200:~ # kldload ipfw && ipfw add 65000 allow ip from any to any 65000 allow ip from any to any root@x200:~ # ipfw add 20000 count ip from any to any via nonexisting 20000 count ip from any to any via nonexisting root@x200:~ # ipfw -t show 20000 0 0 count ip from any to any via nonexisting 65000 71 6588 Thu Mar 10 16:20:02 2016 allow ip from any to any 65535 0 0 deny ip from any to any cheers, Ian From owner-freebsd-net@freebsd.org Thu Mar 10 07:12:47 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 D0AD5ACA7A8 for ; Thu, 10 Mar 2016 07:12:47 +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 C1930D90 for ; Thu, 10 Mar 2016 07:12:47 +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 u2A7CkM3048811 for ; Thu, 10 Mar 2016 07:12:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207055] ipv6 pmtu discovery not working with pf active Date: Thu, 10 Mar 2016 07:12:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 10 Mar 2016 07:12:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207055 --- Comment #2 from Kristof Provost --- I'm still unable to reproduce this. The bug report (and the linked e-mail) suggest that the ICMP6 packet too big packet is rejected because the TCP header it contains has a sequence number which doesn't match the TCP connection. That's why the patch here seems to help: it bypasses the sequence number ch= eck. Clearly that's not what we want to do though. The first step is determining if the bug is in pf (incorrectly parsing the ICMP6 packet) or in the router/destination host (generating an incorrect IM= CP6 packet). In order to debug this further I'll need the pf rules and a network capture demonstrating the problem. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 10 07:14:10 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 3035CACA865 for ; Thu, 10 Mar 2016 07:14:10 +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 210F5E4F for ; Thu, 10 Mar 2016 07:14:10 +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 u2A7E9Av050754 for ; Thu, 10 Mar 2016 07:14:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 207055] ipv6 pmtu discovery not working with pf active Date: Thu, 10 Mar 2016 07:14:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: hm@hellmuth-michaelis.de X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 10 Mar 2016 07:14:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207055 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |hm@hellmuth-michaelis.de --- Comment #3 from Kristof Provost --- (Assigned to reporter, because more information is required.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Thu Mar 10 07:20:13 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 4E3F6ACAA62; Thu, 10 Mar 2016 07:20:13 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A5B0F3D; Thu, 10 Mar 2016 07:20:13 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u2A7K1v4013479; Wed, 9 Mar 2016 23:20:06 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201603100720.u2A7K1v4013479@gw.catspoiler.org> Date: Wed, 9 Mar 2016 23:20:01 -0800 (PST) From: Don Lewis Subject: Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet To: ralsaadi@swin.edu.au cc: freebsd-net@FreeBSD.org, freebsd-ipfw@FreeBSD.org, garmitage@swin.edu.au In-Reply-To: <6545444AE21C2749939E637E56594CEA3C1B0A7C@gsp-ex02.ds.swin.edu.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 10 Mar 2016 07:20:13 -0000 On 10 Mar, Rasool Al-Saadi wrote: > > > On Wednesday, 9 March 2016, Don Lewis wrote: >> >> On 26 Feb, Rasool Al-Saadi wrote: >> > Dear all, >> > >> > I would like to announce that we (myself and Grenville Armitage) >> > released >> Dummynet AQM v0.1, which is an independent implementation of CoDel >> and FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the IETF >> CoDel [1] and FQ-CoDel [2] Internet-Drafts. >> > We prepared patches for FreeBSD11-CURRENT-r295345 and FreeBSD 10.x- >> RELEASE (10.0, 10.1, 10.2), and a technical report of our >> implementation. >> > >> > Patches and documentation can be found in: >> > http://caia.swin.edu.au/freebsd/aqm >> >> Without the patch below, the dummynet module fails to load >> >> # kldload dummynet.ko >> kldload: can't load dummynet.ko: No such file or directory >> >> and the following is printed to /var/log/messages: >> >> link_elf: symbol sysctl__net_inet_ip_dummynet_children undefined > > Thanks again for testing the patch and for providing feedback. > > It seems that this error (and the compilation error in your previous > email) appears in i386 versions of FreeBSD. I was testing on FreeBSD 10.3-PRERELEASE and would have been willing to bet that the difference in behavior was due to a recent change in FreeBSD. After testing, this second bug is also a difference between i386 and amd64. Digging into the problem, this line in ip_dn_io.c: static SYSCTL_NODE(_net_inet_ip, OID_AUTO, dummynet, CTLFLAG_RW, 0, "Dummynet"); gets translated into: static struct sysctl_oid_list sysctl__net_inet_ip_dummynet_children; static struct sysctl_oid sysctl___net_inet_ip_dummynet = { &sysctl__net_inet_ip_children, { ((void *)0) }, (-1), 1|((0x80000000|0x40000000)), (void*)&sysctl__net_inet_ip_dummynet_children, 0, "dummynet", 0, "N", 0, 0, "Dummynet" }; __asm__(".globl " "__start_set_sysctl_set"); __asm__(".globl " "__stop_set_sysctl_set"); static void const * const __set_sysctl_set_sym_sysctl___net_inet_ip_dummynet __attribute__((__section__("set_" "sysctl_set"))) __attribute__((__used__)) = &sysctl___net_inet_ip_dummynet; _Static_assert((((0x80000000|0x40000000)) & 0xf) == 0 || (((0x80000000|0x40000000)) & 0) == 1, "compile-time assertion failed"); by the C preprocessor, and it shows up in the symbol table of the .o file (on amd64): 0000000000000140 b sysctl__net_inet_ip_dummynet_children where "b" indicates that it is a local symbol in the uninitialized data section. The dn_aqm_codel.c and dn_sched_fq_codel.c files also what access to this SYSCTL_NODE, which they indicated by using: SYSCTL_DECL(_net_inet_ip_dummynet); which gets pre-processed to: extern struct sysctl_oid_list sysctl__net_inet_ip_dummynet_children; which results in an undefined symbol in the compiled .o file: U sysctl__net_inet_ip_dummynet_children A symbol declared as an extern in one compilation until should not get linked to a matching symbol defined as a static in another compilation unit. Looking at the symbol table for the module dummynet.ko, I see both the static and undefined versions of the symbol: 00000000000001b0 b sysctl__net_inet_ip_dummynet_children U sysctl__net_inet_ip_dummynet_children For some reason, the kernel linker on amd64 accepts this module, whereas on i386 it is (correctly in my opinion) rejected. I'll try to put together a simple example that I can use to file a FreeBSD bug report. With the patch (on i386), the symbol is defined as global in ip_dn_io.o: 000000b8 B sysctl__net_inet_ip_dummynet_children and there are no undefined versions of this symbol in the .ko file: 00010e4c b sysctl__net_inet_ip_dummynet_children however I don't know why it is no longer a global in the .ko file. From owner-freebsd-net@freebsd.org Thu Mar 10 08:29: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 948A2ACA708; Thu, 10 Mar 2016 08:29:02 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 567A8C01; Thu, 10 Mar 2016 08:29:02 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u2A8Smbt013642; Thu, 10 Mar 2016 00:28:52 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201603100828.u2A8Smbt013642@gw.catspoiler.org> Date: Thu, 10 Mar 2016 00:28:48 -0800 (PST) From: Don Lewis Subject: Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet To: ralsaadi@swin.edu.au cc: aqm@ietf.org, freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org, garmitage@swin.edu.au In-Reply-To: <6545444AE21C2749939E637E56594CEA3C187192@gsp-ex02.ds.swin.edu.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 10 Mar 2016 08:29:02 -0000 On 26 Feb, Rasool Al-Saadi wrote: > Dear all, > > I would like to announce that we (myself and Grenville Armitage) released Dummynet AQM v0.1, which is an independent implementation of CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the IETF CoDel [1] and FQ-CoDel [2] Internet-Drafts. > We prepared patches for FreeBSD11-CURRENT-r295345 and FreeBSD 10.x-RELEASE (10.0, 10.1, 10.2), and a technical report of our implementation. > > Patches and documentation can be found in: > http://caia.swin.edu.au/freebsd/aqm > > Technical report: > http://caia.swin.edu.au/reports/160226A/CAIA-TR-160226A.pdf I've got some results with running this on my firewall in an attempt to tame a severe bufferbloat problem on my ADSL connection to the outside world. The raw speed numbers reported by my ADSL modem are 6016 Kb/s downstream and 768 Kb/s upstream. I set my MTU to 1492 to avoid fragmentation from PPPoE overhead. Using with things unthrottled, I observe about 5050 Kb/s downstream and 648Kb/s upstream, with a bufferbloat rating of F. I configured the system to use FQ-CoDel, with separate pipes for each direction. Because of the slow upstream speed, I increased the target value for the upstream direction to 25 ms since a maximum size packet will require about 20 ms to send. I also set the net.inet.tcp.experimental.initcwnd10 sysctl value to 0. The latter seemed to help a lot. With this feature enabled, the initial packet blast at the start of the upload caused a large initial latency spike, and the initial transfer rate ended up being very slow and it took a long time to ramp up to its maximum sustained value. My current dummynet pipe bandwidth settings are 4800 Kb/s downstream and 615 Kb/s upstream. The speedtest results for these settings are about 4600 Kb/s downstream and about 600 Kb/s upstream. I'm somewhat disappointed in the bandwith loss, but my bufferbloat rating has improved to mostly A's with some B's. I do still see a large increase in latency at the start of transfers, and then it oscillates for a while before settling down at a reasonable value for the remainder of the transfer. I suspect this is to be expected. It would be nice if the implementation was able to account for the PPPOE and ATM framing overhead like the Linux implementation does. I think that would help performance when there is a mix of packet sizes. From owner-freebsd-net@freebsd.org Fri Mar 11 09:35:01 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 279C2ACBCE0; Fri, 11 Mar 2016 09:35:01 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 09CB31192; Fri, 11 Mar 2016 09:35:01 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u2B9Yo8E017604; Fri, 11 Mar 2016 01:34:55 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201603110934.u2B9Yo8E017604@gw.catspoiler.org> Date: Fri, 11 Mar 2016 01:34:50 -0800 (PST) From: Don Lewis Subject: Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet To: ralsaadi@swin.edu.au cc: freebsd-net@FreeBSD.org, garmitage@swin.edu.au, freebsd-ipfw@FreeBSD.org In-Reply-To: <201603100720.u2A7K1v4013479@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 11 Mar 2016 09:35:01 -0000 On 9 Mar, To: ralsaadi@swin.edu.au wrote: > On 10 Mar, Rasool Al-Saadi wrote: >> >> >> On Wednesday, 9 March 2016, Don Lewis wrote: >>> Without the patch below, the dummynet module fails to load >>> >>> # kldload dummynet.ko >>> kldload: can't load dummynet.ko: No such file or directory >>> >>> and the following is printed to /var/log/messages: >>> >>> link_elf: symbol sysctl__net_inet_ip_dummynet_children undefined >> >> Thanks again for testing the patch and for providing feedback. >> >> It seems that this error (and the compilation error in your previous >> email) appears in i386 versions of FreeBSD. > > I was testing on FreeBSD 10.3-PRERELEASE and would have been willing to > bet that the difference in behavior was due to a recent change in > FreeBSD. After testing, this second bug is also a difference between > i386 and amd64. > For some reason, the kernel linker on amd64 accepts this module, whereas > on i386 it is (correctly in my opinion) rejected. I'll try to put > together a simple example that I can use to file a FreeBSD bug report. FreeBSD bug report here: From owner-freebsd-net@freebsd.org Sat Mar 12 23:57:00 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 7A74AACDFCA for ; Sat, 12 Mar 2016 23:57:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B215334 for ; Sat, 12 Mar 2016 23:57:00 +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 u2CNuxnL051933 for ; Sat, 12 Mar 2016 23:57:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 173137] [lem] em(4) unable to run at gigabit with 9.1-RC2 Date: Sat, 12 Mar 2016 23:56:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: esh@abefar.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 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, 12 Mar 2016 23:57:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D173137 esh@abefar.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |esh@abefar.org --- Comment #3 from esh@abefar.org --- This problem got solved a long time ago. I think it went away with 9.1-RC3,= but I can't remember for sure. It is definitely not happening anymore, so please close this bug. Sorry for not reporting back earlier - I completely forgot about this bug report. :-( --=20 You are receiving this mail because: You are the assignee for the bug.=