From owner-freebsd-net@FreeBSD.ORG Sun Apr 5 05:00:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72E152AF; Sun, 5 Apr 2015 05:00:32 +0000 (UTC) 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 CB795869; Sun, 5 Apr 2015 05:00:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t354dttu042071; Sun, 5 Apr 2015 14:39:55 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 5 Apr 2015 14:39:55 +1000 (EST) From: Ian Smith To: "Robert N. M. Watson" Subject: Re: Patch to reduce use of global IP ID value(s) to avoid leaking information In-Reply-To: Message-ID: <20150405143335.J22893@sola.nimnet.asn.au> References: <551F034A.3040402@selasky.org> <20150403213641.GM64665@glebius.int.ru> <551FA37B.90609@selasky.org> <35F9F267-EDB3-45FC-95E0-4573556BD736@freebsd.org> <551FF191.2090109@selasky.org> <55200A51.3090008@selasky.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Hans Petter Selasky , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 05:00:32 -0000 On Sat, 4 Apr 2015 18:11:55 +0100, Robert N. M. Watson wrote: > On 4 Apr 2015, at 16:59, Hans Petter Selasky wrote: Thankyou Robert for this most interesting dissertation. And thanks Hans for the provocation to draw it forth .. cheers from the peanut gallery, Ian From owner-freebsd-net@FreeBSD.ORG Sun Apr 5 21:00:19 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8050AAFA for ; Sun, 5 Apr 2015 21:00:19 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 54CE6CE6 for ; Sun, 5 Apr 2015 21:00:19 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t35L0J8Y073621 for ; Sun, 5 Apr 2015 21:00:19 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201504052100.t35L0J8Y073621@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 05 Apr 2015 21:00:19 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 21:00:19 -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 ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Apr 6 08:22:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE73E609 for ; Mon, 6 Apr 2015 08:22:59 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.isc.org", Issuer "RapidSSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AF7CA6C2 for ; Mon, 6 Apr 2015 08:22:58 +0000 (UTC) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1C3FB1FCAD6 for ; Mon, 6 Apr 2015 08:22:54 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10302) id EE865216C43; Mon, 6 Apr 2015 08:22:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by bikeshed.isc.org (Postfix) with ESMTP id EDE39216C40; Mon, 6 Apr 2015 08:22:52 +0000 (UTC) Date: Mon, 6 Apr 2015 08:22:52 +0000 (UTC) From: Dan Mahoney To: freebsd-net@freebsd.org Subject: Issue with TCPdump Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) X-OpenPGP-Key-ID: 0xE919EC51 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.ams1.isc.org Cc: plosher@isc.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 08:23:00 -0000 Hey all, Here at ISC, we're seeing a weird issue with the tcpdump command in 10.0-RELEASE. I'm hoping someone can take a look. -- We have an F-root stats collector that we run as part of an annual event to gather data across various root servers. It uses the following tcpdump syntax: /usr/sbin/tcpdump -i em0 -G 600 -s 0 -w /var/tcpdumps/cdg1b-pcap.%Y-%m-%d-%H:%M:%S -z gzip dst net ( 192.5.5.241/32 or 2001:500:2f::f/128) and not ( src net 204.152.184.0/21 or src net 149.20.0.0/16 or src net 2001:04F8::/32 and dst port 22 ) I've included the full command in case it's needed, but the only bits we really care about are -G 600 and -z gzip, which should gzip all the log files, right out of the manpage. What this SHOULD give us is a bunch of gzipped files in /var/tcpdumps. In reality, only the first file is gzipped: root@cdg1b:/var/tcpdumps # ls -al total 66888 drwxr-xr-x 2 root wheel 1024 Apr 6 08:07 . drwxr-xr-x 32 root wheel 1024 Nov 3 10:30 .. -rw-r--r-- 1 root wheel 1762188 Apr 6 04:44 cdg1b-pcap.2015-04-06-04:34:47.gz -rw-r--r-- 1 root wheel 5262738 Apr 6 04:54 cdg1b-pcap.2015-04-06-04:44:47 -rw-r--r-- 1 root wheel 5371252 Apr 6 05:04 cdg1b-pcap.2015-04-06-04:54:47 -rw-r--r-- 1 root wheel 5828832 Apr 6 05:14 cdg1b-pcap.2015-04-06-05:04:47 -rw-r--r-- 1 root wheel 5612538 Apr 6 05:24 cdg1b-pcap.2015-04-06-05:14:47 -rw-r--r-- 1 root wheel 5864548 Apr 6 05:34 cdg1b-pcap.2015-04-06-05:24:47 -rw-r--r-- 1 root wheel 5728222 Apr 6 05:44 cdg1b-pcap.2015-04-06-05:34:47 -rw-r--r-- 1 root wheel 5749591 Apr 6 05:54 cdg1b-pcap.2015-04-06-05:44:47 -rw-r--r-- 1 root wheel 5845820 Apr 6 06:04 cdg1b-pcap.2015-04-06-05:54:47 -rw-r--r-- 1 root wheel 5874731 Apr 6 06:14 cdg1b-pcap.2015-04-06-06:04:47 -rw-r--r-- 1 root wheel 5689875 Apr 6 06:24 cdg1b-pcap.2015-04-06-06:14:47 -rw-r--r-- 1 root wheel 5592813 Apr 6 06:34 cdg1b-pcap.2015-04-06-06:24:47 Sorry for the messy output. I'd happily log this as a bug (either in FreeBSD, or upstream) if someone else could take a look. -Dan From owner-freebsd-net@FreeBSD.ORG Mon Apr 6 16:20:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8FEFBB8 for ; Mon, 6 Apr 2015 16:20:22 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 C27FDD89 for ; Mon, 6 Apr 2015 16:20:22 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id D527C10C48E for ; Mon, 6 Apr 2015 09:20:15 -0700 (PDT) Date: Mon, 6 Apr 2015 09:20:15 -0700 From: hiren panchasara To: freebsd-net@freebsd.org Subject: Re: Bring "netstat -R" to stable10 Message-ID: <20150406162015.GB96049@strugglingcoder.info> References: <20150402205307.GA72165@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xA/XKXTdy9G3iaIz" Content-Disposition: inline In-Reply-To: <20150402205307.GA72165@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:20:22 -0000 --xA/XKXTdy9G3iaIz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/02/15 at 01:53P, hiren panchasara wrote: > I want to use netstat -R on stable10 and following 2 commits are needed > to be MFC'd for that: > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D266418 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D266448 >=20 > r266418 adds a field to 'struct inpcb' but it uses a spare field so I > _think_ it's MFCable and doesn't break KBI/KPI?=20 >=20 > Can someone please comment if that's not the case? I'll go commit this today. Thanks, Hiren --xA/XKXTdy9G3iaIz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVIrI/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lCBcIAJsm4qXrHS8nt5sywoxAtf0B 1l75z+NW8HvQye+xjSmHXWbu/tjFZlR05iMgxWtmCPyJ78xIV3o1I8gO6B8XPezy MRnopfXxh9iEng8qAzV0J5E2ZIumjfccYbVEKPYUQHvgG2Z7WCRYkNx8M6TjfIAT ssCK3mPxu3ZgTg5jd4QDKUPHFoveVtwLbIRb3rQL6DWef9+nFETUDcWwZ0Lt1/AX UYVFlKAHMeCruDExmF+MiQ8f5NnJkvCr1vkDgxk4NfO9VtUZ8XBR2tWaQQnwsgRh 934Q5+wgT7KMUfotR6GpU23WxanHk8Y6RO4Z1IwFh5gZUN9aSY3F0vxFFj/xDfA= =rv2U -----END PGP SIGNATURE----- --xA/XKXTdy9G3iaIz-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 6 16:36:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 182EC25D; Mon, 6 Apr 2015 16:36:22 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EFCF6F7C; Mon, 6 Apr 2015 16:36:21 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id ADF6211E5F; Mon, 6 Apr 2015 09:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1428338174; x=1428352574; bh=y34+aXPQ10nwx8a4FfjLnokPJwLRao3cJWVgBA35F7U=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=ULUvLMIKFYe3uyV3G20iWZN0QdINFxcgv+s9HACNyIohAXgjzEZBM52UjesMUk2Ts RgBGZRmfPkeGwXpmalgR1zJfmI+TzB1f+dyvi5brPkmUwM7p/tW4kIQ02LUFK5RFZS hAfDdIMSsIIPRqm5cxzcmWUBRy6B7eonRxrSoT8o= Message-ID: <5522B5FD.5040308@delphij.net> Date: Mon, 06 Apr 2015 09:36:13 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: hiren panchasara , freebsd-net@freebsd.org Subject: Re: Bring "netstat -R" to stable10 References: <20150402205307.GA72165@strugglingcoder.info> <20150406162015.GB96049@strugglingcoder.info> In-Reply-To: <20150406162015.GB96049@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: re X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:36:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/06/15 09:20, hiren panchasara wrote: > On 04/02/15 at 01:53P, hiren panchasara wrote: >> I want to use netstat -R on stable10 and following 2 commits are >> needed to be MFC'd for that: >> https://svnweb.freebsd.org/base?view=revision&revision=266418 >> https://svnweb.freebsd.org/base?view=revision&revision=266448 >> >> r266418 adds a field to 'struct inpcb' but it uses a spare field >> so I _think_ it's MFCable and doesn't break KBI/KPI? >> >> Can someone please comment if that's not the case? > > I'll go commit this today. I think you should have asked re@ or this may get otherwise unnoticed... I was kinda surprised with the fact that the spare fields are defined as 'uint' and not something like 'u_int32_t' because the former is less defined. We should probably use u_int32_t instead for the spare fields to avoid the ambiguity. However, because all platforms that FreeBSD currently supports have 32-bit int (doing a quick grep of __UINT_MAX), I think the change does not break KBI. The added field does not break KPI. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.2 (FreeBSD) iQIcBAEBCgAGBQJVIrX9AAoJEJW2GBstM+nsqPIQAJbPIm/+CW8M7GYIsi+7uZhB lmre7YxpRQrYZhIEcpbu7M06v/qCzAqnrIxbddOtvOjSvc606yW5fgQlns30IoD0 BzOpu0Q8tTwYMRq2ccQ02hQoODvMkFPNloTqxe5XXs7Gc+QqVQxehmKZhEIpTSDY JzMWmJlfthAl5BUx5c9SbrgYCd9XkLYpqGeRD7KbveU5dlVXB/wEsftRH9d7TrRb Q+Ug6y6nsb0XGF9ayUcsK68EbXSgbxvA3LVummeiRuFuFUcCQ1JqCAIQo13yWckQ bGk8Bw5a5kXUrRzH/TkGHKqUVxxl7hRunUu4NIHmI8wbjS/qcchFiWgC9B2BO4WX ri/2UHYJVf4Ll3gefD6MdG07Y46DZCKtEkcmynxW8jtC+eomi7uQundGr7jKshCt mnT9c/s0lIBwW639QQNEkJOI3/ZZJuU7IjSf7jgbnO0+MD6GS7O4qrxp/yfQxXjJ lSY6qWuxF4eAzv0DUWYpHHG0BT1payu/ZnFgunPyj5ym1Kadm2nASMJt3nCOmlow oapz7K1L5nGAPnQf5JHPO2mHIowLoBJbTYU/KtAZ8HSiKBFBG2EcNd0j9Dd11TD8 uTGNvNVo3CFkyUIU/bRDWbFIP/BXk4BRUepgglDVk+eij24bGX4gCyfFgvWQ+/sw QrAa+rUvIMhaLJL8WuyA =Btjt -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Apr 6 17:40:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D50B1BD4; Mon, 6 Apr 2015 17:40:59 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 BE77A9EA; Mon, 6 Apr 2015 17:40:59 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 8E9D610C96C; Mon, 6 Apr 2015 10:40:57 -0700 (PDT) Date: Mon, 6 Apr 2015 10:40:57 -0700 From: hiren panchasara To: d@delphij.net Subject: Re: Bring "netstat -R" to stable10 Message-ID: <20150406174057.GC96049@strugglingcoder.info> References: <20150402205307.GA72165@strugglingcoder.info> <20150406162015.GB96049@strugglingcoder.info> <5522B5FD.5040308@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V4b9U9vrdWczvw78" Content-Disposition: inline In-Reply-To: <5522B5FD.5040308@delphij.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-net@freebsd.org, re X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 17:40:59 -0000 --V4b9U9vrdWczvw78 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/06/15 at 09:36P, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 04/06/15 09:20, hiren panchasara wrote: > > On 04/02/15 at 01:53P, hiren panchasara wrote: > >> I want to use netstat -R on stable10 and following 2 commits are > >> needed to be MFC'd for that:=20 > >> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D266418=20 > >> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D266448 > >>=20 > >> r266418 adds a field to 'struct inpcb' but it uses a spare field > >> so I _think_ it's MFCable and doesn't break KBI/KPI? > >>=20 > >> Can someone please comment if that's not the case? > >=20 > > I'll go commit this today. >=20 > I think you should have asked re@ or this may get otherwise unnoticed... My bad. That didn't occur to me. >=20 > I was kinda surprised with the fact that the spare fields are defined > as 'uint' and not something like 'u_int32_t' because the former is > less defined. We should probably use u_int32_t instead for the spare > fields to avoid the ambiguity. Yeah, that'd be a separate change.=20 >=20 > However, because all platforms that FreeBSD currently supports have > 32-bit int (doing a quick grep of __UINT_MAX), I think the change does > not break KBI. The added field does not break KPI. Ok, I'll commit to 10 as is. Appreciate you chiming in. Cheers, Hiren --V4b9U9vrdWczvw78 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVIsUoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/loOUH/2RDPcEujem9m/QSzneGlDvL aDWYCU62gzU1Q0XfYN3oISwERDAuoDN4nhNWpNzO+ltUvEUebWDMv/eLEq/BA+3X 2s6thrNrynIHNTkIc8JthwELVsl9e5K+4DzOR6QSG1F7gaAksKDZq5ayxH9Eqsh6 ZrxzzSO+JO4GuX9oK3Gr8uR3TlnfFlhBEbdZOHZz5EOt11ttQhs8Vd/hddXq9wsE KGDbf8vIVup+1ziOFD3qparMYeC1IqBd2lHmM8RvUMN7DhZiwGbwnbZxD0l2rqsV YN0KafFHSfpxhORBwLJxpxUbhJWZZKkuS6Zx7wcV57HkBpMVrJ4pnaKrr7MXXTM= =Kv4Q -----END PGP SIGNATURE----- --V4b9U9vrdWczvw78-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 6 18:15:46 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54D93F73 for ; Mon, 6 Apr 2015 18:15:46 +0000 (UTC) Received: from BLU004-OMC2S18.hotmail.com (blu004-omc2s18.hotmail.com [65.55.111.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 104E0E19 for ; Mon, 6 Apr 2015 18:15:45 +0000 (UTC) Received: from BLU184-W19 ([65.55.111.72]) by BLU004-OMC2S18.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 6 Apr 2015 11:15:39 -0700 X-TMN: [qhah8KKQz7zUfGSGdPzi4xS+4GeEhQEJ] X-Originating-Email: [dr_sweety_1337@hotmail.com] Message-ID: From: Anton Farber To: "freebsd-net@freebsd.org" Subject: FreeBSD sometimes uses the router for packets on the local network Date: Mon, 6 Apr 2015 18:15:39 +0000 Importance: Normal Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 06 Apr 2015 18:15:39.0778 (UTC) FILETIME=[AFEDCE20:01D07095] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 18:15:46 -0000 R29vZCBldmVuaW5nLAoKSSd2ZSBvcGVuZWQgYSB0aHJlYWQgb24gdGhlIEZyZWVCU0QgbmV0d29y a2luZyBmb3J1bSAoaHR0cHM6Ly9mb3J1bXMuZnJlZWJzZC5vcmcvdGhyZWFkcy9qYWlsLWZhaWxz LXRvLWNvbm5lY3QtdG8tbWFpbi1ob3N0LjUwODMzLykgYXMgc29tZXRpbWUgYWdvIG15IEZyZWVC U0Qgc2VydmVyIChpbml0aWFsbHkgcnVubmluZyAxMC4xLCBub3cgQ1VSUkVOVCkgc3RhcnRlZCB0 byBiZWhhdmUgc3RyYW5nZWx5IGFmdGVyIGFuIHVwZ3JhZGUgZnJvbSAxMC4wIHRvIDEwLjEuIEkg Zmlyc3Qgbm90aWNlZCB0aGF0IGEgamFpbCAoMTkyLjE2OC4xLjUpIHdhc24ndCBhYmxlIHRvIGNv bnRhY3QgdGhlIGJhc2Ugc3lzdGVtICgxOTIuMTY4LjEuMSkuIFJ1bm5pbmcgYSB0Y3BkdW1wIHJl dmVhbGVkIHRoZSBmb2xsb3dpbmc6IHRoZSBqYWlsIGlzIHVzaW5nIGVtMCBpbnN0ZWFkIG9mIGxv MCBmb3IgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBiYXNlIHN5c3RlbToKCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQoqIHRjcGR1bXAgb24gZW0wClNvdXJjZSDCoCDCoCDCoERlc3RpbmF0aW9uIFBy b3RvY29sIExlbmd0aCBJbmZvCjE5Mi4xNjguMS41IDE5Mi4xNjguMS4xIFRDUCDCoCDCoCDCoDc0 IMKgIMKgIDI4ODQ44oaSMjIgW1NZTl0KKiB0Y3BkdW1wIG9uIGxvMApTb3VyY2UgwqAgwqAgwqBE ZXN0aW5hdGlvbiBQcm90b2NvbCBMZW5ndGggSW5mbwoxOTIuMTY4LjEuMSAxOTIuMTY4LjEuNSBU Q1AgwqAgwqAgwqA2NCDCoCDCoCAyMuKGkjI4ODQ4IFtTWU4sIEFDS10KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCgpJIGRvbid0IHRoaW5rIHRoYXQgdGhpcyBpcyB0aGUgd2F5IGl0J3Mgc3VwcG9z ZWQgdG8gd29yay4gTmV4dCB0aGluZyB3YXMsIHRoYXQgcmFuZG9tIGhvc3RzIG9uIHRoZSBuZXR3 b3JrIHdlcmUgdW5hYmxlIHRvIGNvbnRhY3QgdGhlIHNlcnZlci4gVGhlIHNlcnZlciBvbiB0aGUg b3RoZXIgaGFuZCB0aG91Z2h0IGl0IG5lZWRlZCB0byByZWFjaCB0aG9zZSBob3N0cyAoaW4gdGhp cyBleGFtcGxlIDE5Mi4xNjguMS42MSkgdmlhIHRoZSByb3V0ZXI6CgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KIyBwaW5nIC1jIDEgMTkyLjE2OC4xLjYxClBJTkcgMTkyLjE2OC4xLjYxICgxOTIu MTY4LjEuNjEpOiA1NiBkYXRhIGJ5dGVzCjM2IGJ5dGVzIGZyb20gcm91dGVyLmxvY2FsLmxhbiAo MTkyLjE2OC4xLjI1NCk6IFJlZGlyZWN0IEhvc3QoTmV3IGFkZHI6IDE5Mi4xNjguMS42MSkKVnIg SEwgVE9TIMKgTGVuIMKgIElEIEZsZyDCoG9mZiBUVEwgUHJvIMKgY2tzIMKgIMKgIMKgU3JjIMKg IMKgIMKgRHN0CjQgwqA1IMKgMDAgMDA1NCBhNzM0IMKgIDAgMDAwMCDCoDQwIMKgMDEgNGZlNiAx OTIuMTY4LjEuMSDCoDE5Mi4xNjguMS42MQoKNjQgYnl0ZXMgZnJvbSAxOTIuMTY4LjEuNjE6IGlj bXBfc2VxPTAgdHRsPTY0IHRpbWU9MS4wMDkgbXMKCi0tLSAxOTIuMTY4LjEuNjEgcGluZyBzdGF0 aXN0aWNzIC0tLQoxIHBhY2tldHMgdHJhbnNtaXR0ZWQsIDEgcGFja2V0cyByZWNlaXZlZCwgMC4w JSBwYWNrZXQgbG9zcwpyb3VuZC10cmlwIG1pbi9hdmcvbWF4L3N0ZGRldiA9IDEuMDA5LzEuMDA5 LzEuMDA5LzAuMDAwIG1zIwotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCk90aGVyIGhvc3RzIG9u IHRoZSBzYW1lIG5ldHdvcmsgd2VyZSBhYmxlIHRvIHJlYWNoIDE5Mi4xNjguMS42MSBkaXJlY3Rs eSwgc28gaXQgY2FuJ3QgYmUgbmVpdGhlciAxOTIuMTY4LjEuNjEgbm9yIHRoZSByb3V0ZXIgKEkg ZG8gbm90IGhhdmUgYW55IHN0YXRpYyByb3V0ZXMgZm9yIDE5Mi4xNjguMS42MS8zMiBvbiBteSBy b3V0ZXIpIHRoYXQgYXJlIGNhdXNpbmcgdGhlIHByb2JsZW1zLiBTdGF0dXMgb24gdGhlIHNlcnZl cjoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQojIGFycCAtYQpzZXJ2ZXIubG9jYWwuTGFuICgx OTIuMTY4LjEuMSkgYXQgMDA6MWM6YzA6NmY6YzI6NjAgb24gZW0wIHBlcm1hbmVudCBbZXRoZXJu ZXRdCmxhcHRvcC5sb2NhbC5MYW4gKDE5Mi4xNjguMS4zMikgYXQgNWM6MjY6MGE6MmE6Mzc6MTAg b24gZW0wIGV4cGlyZXMgaW4gMTE5NyBzZWNvbmRzIFtldGhlcm5ldF0KamFpbC5sb2NhbC5MYW4g KDE5Mi4xNjguMS41KSBhdCAwMDoxYzpjMDo2ZjpjMjo2MCBvbiBlbTAgcGVybWFuZW50IFtldGhl cm5ldF0KV2luWFAubG9jYWwuTGFuICgxOTIuMTY4LjEuNCkgYXQgMDg6MDA6Mjc6ODA6Yjg6MTAg b24gZW0wIGV4cGlyZXMgaW4gMTIwMCBzZWNvbmRzIFtldGhlcm5ldF0KPyAoMTkyLjE2OC4xLjYx KSBhdCAwMDowNDoyMDowNTozMTozOCBvbiBlbTAgZXhwaXJlcyBpbiAxMTUwIHNlY29uZHMgW2V0 aGVybmV0XQo/ICgxOTIuMTY4LjEuMjU1KSBhdCAoaW5jb21wbGV0ZSkgb24gZW0wIGV4cGlyZWQg W2V0aGVybmV0XQpSb3V0ZXIubG9jYWwuTGFuICgxOTIuMTY4LjEuMjU0KSBhdCAwMDowZDpiOTow MDoxMTo2OCBvbiBlbTAgZXhwaXJlcyBpbiAxMTUwIHNlY29uZHMgW2V0aGVybmV0XQpQaG9uZS5s b2NhbC5MYW4gKDE5Mi4xNjguMS4yMSkgYXQgMDA6MGU6MDg6YmM6ZWQ6OTQgb24gZW0wIGV4cGly ZXMgaW4gNzk5IHNlY29uZHMgW2V0aGVybmV0XQojIG5ldHN0YXQgLXJuClJvdXRpbmcgdGFibGVz CgpJbnRlcm5ldDoKRGVzdGluYXRpb24gwqAgwqAgwqAgwqBHYXRld2F5IMKgIMKgIMKgIMKgIMKg IMKgRmxhZ3MgwqAgwqAgwqBOZXRpZiBFeHBpcmUKZGVmYXVsdCDCoCDCoCDCoCDCoCDCoCDCoDE5 Mi4xNjguMS4yNTQgwqAgwqAgwqBVR1MgwqAgwqAgwqAgwqBlbTAKMTI3LjAuMC4xIMKgIMKgIMKg IMKgIMKgbGluayMyIMKgIMKgIMKgIMKgIMKgIMKgIFVIIMKgIMKgIMKgIMKgIGxvMAoxOTIuMTY4 LjEuMC8yNCDCoCDCoCBsaW5rIzEgwqAgwqAgwqAgwqAgwqAgwqAgVSDCoCDCoCDCoCDCoCDCoGVt MAoxOTIuMTY4LjEuMSDCoCDCoCDCoCDCoGxpbmsjMSDCoCDCoCDCoCDCoCDCoCDCoCBVSFMgwqAg wqAgwqAgwqBsbzAKMTkyLjE2OC4xLjUgwqAgwqAgwqAgwqBsaW5rIzEgwqAgwqAgwqAgwqAgwqAg wqAgVUhTIMKgIMKgIMKgIMKgbG8wCjE5Mi4xNjguMS41LzMyIMKgIMKgIGxpbmsjMSDCoCDCoCDC oCDCoCDCoCDCoCBVIMKgIMKgIMKgIMKgIMKgZW0wCgpJbnRlcm5ldDY6CkRlc3RpbmF0aW9uIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEdhdGV3YXkgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgRmxhZ3MgwqAgwqAgwqBOZXRpZiBFeHBpcmUKOjovOTYgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOjoxIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIFVHUlMgwqAgwqAgwqAgbG8wCjo6MSDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBsaW5rIzIgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqBVSCDCoCDCoCDCoCDCoCBsbzAKOjpmZmZmOjAuMC4wLjAvOTYgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgOjoxIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIFVHUlMgwqAgwqAgwqAgbG8wCmZlODA6Oi8xMCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCA6OjEgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVUdS UyDCoCDCoCDCoCBsbzAKZmU4MDo6JWxvMC82NCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCBsaW5rIzIgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBVIMKgIMKgIMKgIMKg IMKgbG8wCmZlODA6OjElbG8wIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGxpbmsj MiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFVIUyDCoCDCoCDCoCDCoGxvMApm ZTgwOjoldHVuMC82NCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGxpbmsjNCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoFUgwqAgwqAgwqAgwqAgdHVuMApmZTgwOjoyMWM6 YzBmZjpmZTZmOmMyNjAldHVuMCDCoCDCoCBsaW5rIzQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqBVSFMgwqAgwqAgwqAgwqBsbzAKZmYwMjo6LzE2IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIDo6MSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCBVR1JTIMKgIMKgIMKgIGxvMAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClNvIHRoZSBz ZXJ2ZXIga25ldyB0aGUgKGNvcnJlY3QpIE1BQyBhZGRyZXNzIG9mIC42MSBidXQgc3RpbGwgdHJp ZWQgdG8gcmVhY2ggaXQgdmlhIHRoZSByb3V0ZXIuIEkndmUgcnVuIGEgdGNwZHVtcCBvbiBlbTAs IHRoaXMgaXMgd2hlcmUgdGhpbmdzIGdldCBpbnRlcmVzdGluZzoKCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpOby4gVGltZSDCoCDCoCDCoFNvdXJjZSDCoCDCoCDCoCDCoERlc3RpbmF0aW9uIMKg UHJvdG9jb2wgTGVuZ3RoIEluZm8KMTg2IDEuMDI4MTg2IMKgMTkyLjE2OC4xLjEgwqAgMTkyLjE2 OC4xLjYxIElDTVAgwqAgwqAgOTggwqAgwqAgRWNobyAocGluZykgcmVxdWVzdCDCoGlkPTB4MjIy MCwgc2VxPTAvMCwgdHRsPTY0IChyZXBseSBpbiAxOTApCgpFdGhlcm5ldCBJSSwgU3JjOiBJbnRl bENvcl82ZjpjMjo2MCAoMDA6MWM6YzA6NmY6YzI6NjApLCBEc3Q6IFBjRW5naW5lXzAwOjExOjY4 ICgwMDowZDpiOTowMDoxMTo2OCkKCk5vLiBUaW1lIMKgIMKgIMKgU291cmNlIMKgIMKgIMKgIMKg RGVzdGluYXRpb24gUHJvdG9jb2wgTGVuZ3RoIEluZm8KMTg5IDEuMDI5MDA4IMKgMTkyLjE2OC4x LjI1NCAxOTIuMTY4LjEuMSBJQ01QIMKgIMKgIDcwIMKgIMKgIFJlZGlyZWN0IMKgIMKgIMKgIMKg IMKgIMKgIChSZWRpcmVjdCBmb3IgaG9zdCkKCkV0aGVybmV0IElJLCBTcmM6IFBjRW5naW5lXzAw OjExOjY4ICgwMDowZDpiOTowMDoxMTo2OCksIERzdDogSW50ZWxDb3JfNmY6YzI6NjAgKDAwOjFj OmMwOjZmOmMyOjYwKQoKTm8uIFRpbWUgwqAgwqAgwqBTb3VyY2UgwqAgwqAgwqAgwqBEZXN0aW5h dGlvbiBQcm90b2NvbCBMZW5ndGggSW5mbwoxOTAgMS4wMjkzOTIgwqAxOTIuMTY4LjEuNjEgwqAx OTIuMTY4LjEuMSBJQ01QIMKgIMKgIDk4IMKgIMKgIEVjaG8gKHBpbmcpIHJlcGx5IMKgIMKgaWQ9 MHgyMjIwLCBzZXE9MC8wLCB0dGw9NjQgKHJlcXVlc3QgaW4gMTg2KQoKRXRoZXJuZXQgSUksIFNy YzogU2xpbURldmlfMDU6MzE6MzggKDAwOjA0OjIwOjA1OjMxOjM4KSwgRHN0OiBJbnRlbENvcl82 ZjpjMjo2MCAoMDA6MWM6YzA6NmY6YzI6NjApCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhl IHNlcnZlciBpc3N1ZXMgYW4gZWNobyByZXF1ZXN0IGZvciAuNjEgYnV0IGlzIHVzaW5nIHRoZSBy b3V0ZXIncyBNQUMgYWRkcmVzcyAoOjY4KSEgT2J2aW91c2x5IHRoZSByb3V0ZXIgYW5zd2VycyB3 aXRoIGEgcmVkaXJlY3QuLgoKSSd2ZSBzaHV0IGRvd24gYWxsIGRhZW1vbnMgYW5kIGtlcm5lbCBt b2R1bGVzIGlmIHBvc3NpYmxlIHVudGlsIGp1c3QgdGhlIGFic29sdXRlIGJhcmUgbWluaW11bSAo c3NoZCwgaW5pdCBhbmQgc29tZSBvdGhlciBiYXNlIHNlcnZpY2VzKSB3YXMgcnVubmluZy4gSSd2 ZSB1cGdyYWRlZCB0byBDVVJSRU5ULiBUaGlzIGRpZG4ndCBjaGFuZ2UgYW55dGhpbmcuIFdoYXQg aGVscGVkIGluIHRoZSBlbmQgd2FzIGlzc3VpbmcgYSAicm91dGUgZmx1c2ggOyByb3V0ZSBhZGQg ZGVmYXVsdCAxOTIuMTY4LjEuMjU0IjogdGhlIHNlcnZlciB3YXMgaW1tZWRpYXRlbHkgYWJsZSB0 byBjb250YWN0IC42MSBkaXJlY3RseS4KClRoZSBwcm9ibGVtIHNlZW1pbmdseSBhcHBlYXJzIHJh bmRvbWx5LCBzb21ldGltZXMgaXQgdGFrZXMgd2Vla3MgZm9yIGl0IHRvIHJlYXBwZWFyLgoKU29y cnkgZm9yIHRoZSBsb25nIHBvc3QsIEkndmUgdHJpZWQgdG8ga2VlcCBpdCBhcyBjb21wYWN0IGFz IHBvc3NpYmxlLiBEb2VzIGFueW9uZSBoYXZlIGFueSBpZGVhIHdoYXQgbWlnaHQgYmUgY2F1c2lu ZyB0aG9zZSBwcm9ibGVtcz8KClJlZ2FyZHMsIEFudG9uIAkJIAkgICAJCSAg From owner-freebsd-net@FreeBSD.ORG Mon Apr 6 18:26:54 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F955295 for ; Mon, 6 Apr 2015 18:26:54 +0000 (UTC) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3ECA7F0F for ; Mon, 6 Apr 2015 18:26:54 +0000 (UTC) Received: by obbfy7 with SMTP id fy7so53425244obb.2 for ; Mon, 06 Apr 2015 11:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Nve5fEhzz+eENzyoH1ewYNIa4bBKuzhCBhjRxTALCCw=; b=YArzdpxjHzgI3WyASVFsi9uwtWuOrOmnZ1+KGUN1tRm/XrQBEt+cC2jX0+s+DX7BWc xvGMdi9+YlzLTiOCAXoKtHiW+gnsoXqR56wVJ4S5rkBueaFrWY3kbjqrRHwEmVE/9WyX U45SvDeydZzBUtFiGF1qFOoQtrr1D8OiZL01SHM30gSyywlz0DnaFJvl+QC44AYSNL7t N5rBZIlVM3L8vVjcFioYlRJy1FAoZP/gsHiVIQpdkzgIh0Ck7FnnRTN4VjBZsZfPTJK+ ESEXK6QnH7Ms0pMaG3DLBnCp5xuM5HPhxHy+DN/1aOydaj1oK8Q/wB2vWbB92LPdh7se qtlw== MIME-Version: 1.0 X-Received: by 10.182.241.99 with SMTP id wh3mr20352307obc.81.1428344813417; Mon, 06 Apr 2015 11:26:53 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.215.7 with HTTP; Mon, 6 Apr 2015 11:26:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Apr 2015 12:26:53 -0600 X-Google-Sender-Auth: i4dnUevXStnj3BcbMpcUPxztXGc Message-ID: Subject: Re: FreeBSD sometimes uses the router for packets on the local network From: Alan Somers To: Anton Farber Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 18:26:54 -0000 On Mon, Apr 6, 2015 at 12:15 PM, Anton Farber wrote: > Good evening, > > I've opened a thread on the FreeBSD networking forum (https://forums.free= bsd.org/threads/jail-fails-to-connect-to-main-host.50833/) as sometime ago = my FreeBSD server (initially running 10.1, now CURRENT) started to behave s= trangely after an upgrade from 10.0 to 10.1. I first noticed that a jail (1= 92.168.1.5) wasn't able to contact the base system (192.168.1.1). Running a= tcpdump revealed the following: the jail is using em0 instead of lo0 for c= ommunicating with the base system: You need to look at your routing tables. From inside the jail, run "netstat -rn -f inet". You probably won't see any entry for 127.0.0.1 or 127.0.0.0/8. Those are the entries that your jail needs in order to talk to the base system. You can add them, but think carefully. Many server processes, such as ntpd, have reduced security for connections coming over 127.0.0.1. Whether or not it is appropriate to add those routes depends on why you are using a jail. -Alan > > ------------------------ > * tcpdump on em0 > Source Destination Protocol Length Info > 192.168.1.5 192.168.1.1 TCP 74 28848=E2=86=9222 [SYN] > * tcpdump on lo0 > Source Destination Protocol Length Info > 192.168.1.1 192.168.1.5 TCP 64 22=E2=86=9228848 [SYN, ACK] > ------------------------ > > I don't think that this is the way it's supposed to work. Next thing was,= that random hosts on the network were unable to contact the server. The se= rver on the other hand thought it needed to reach those hosts (in this exam= ple 192.168.1.61) via the router: > > ------------------------ > # ping -c 1 192.168.1.61 > PING 192.168.1.61 (192.168.1.61): 56 data bytes > 36 bytes from router.local.lan (192.168.1.254): Redirect Host(New addr: 1= 92.168.1.61) > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst > 4 5 00 0054 a734 0 0000 40 01 4fe6 192.168.1.1 192.168.1.61 > > 64 bytes from 192.168.1.61: icmp_seq=3D0 ttl=3D64 time=3D1.009 ms > > --- 192.168.1.61 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/stddev =3D 1.009/1.009/1.009/0.000 ms# > ------------------------ > > Other hosts on the same network were able to reach 192.168.1.61 directly,= so it can't be neither 192.168.1.61 nor the router (I do not have any stat= ic routes for 192.168.1.61/32 on my router) that are causing the problems. = Status on the server: > > ------------------------ > # arp -a > server.local.Lan (192.168.1.1) at 00:1c:c0:6f:c2:60 on em0 permanent [eth= ernet] > laptop.local.Lan (192.168.1.32) at 5c:26:0a:2a:37:10 on em0 expires in 11= 97 seconds [ethernet] > jail.local.Lan (192.168.1.5) at 00:1c:c0:6f:c2:60 on em0 permanent [ether= net] > WinXP.local.Lan (192.168.1.4) at 08:00:27:80:b8:10 on em0 expires in 1200= seconds [ethernet] > ? (192.168.1.61) at 00:04:20:05:31:38 on em0 expires in 1150 seconds [eth= ernet] > ? (192.168.1.255) at (incomplete) on em0 expired [ethernet] > Router.local.Lan (192.168.1.254) at 00:0d:b9:00:11:68 on em0 expires in 1= 150 seconds [ethernet] > Phone.local.Lan (192.168.1.21) at 00:0e:08:bc:ed:94 on em0 expires in 799= seconds [ethernet] > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Netif Expire > default 192.168.1.254 UGS em0 > 127.0.0.1 link#2 UH lo0 > 192.168.1.0/24 link#1 U em0 > 192.168.1.1 link#1 UHS lo0 > 192.168.1.5 link#1 UHS lo0 > 192.168.1.5/32 link#1 U em0 > > Internet6: > Destination Gateway Flags = Netif Expire > ::/96 ::1 UGRS = lo0 > ::1 link#2 UH = lo0 > ::ffff:0.0.0.0/96 ::1 UGRS = lo0 > fe80::/10 ::1 UGRS = lo0 > fe80::%lo0/64 link#2 U = lo0 > fe80::1%lo0 link#2 UHS = lo0 > fe80::%tun0/64 link#4 U = tun0 > fe80::21c:c0ff:fe6f:c260%tun0 link#4 UHS = lo0 > ff02::/16 ::1 UGRS = lo0 > ------------------------ > > So the server knew the (correct) MAC address of .61 but still tried to re= ach it via the router. I've run a tcpdump on em0, this is where things get = interesting: > > ------------------------ > No. Time Source Destination Protocol Length Info > 186 1.028186 192.168.1.1 192.168.1.61 ICMP 98 Echo (ping) requ= est id=3D0x2220, seq=3D0/0, ttl=3D64 (reply in 190) > > Ethernet II, Src: IntelCor_6f:c2:60 (00:1c:c0:6f:c2:60), Dst: PcEngine_00= :11:68 (00:0d:b9:00:11:68) > > No. Time Source Destination Protocol Length Info > 189 1.029008 192.168.1.254 192.168.1.1 ICMP 70 Redirect = (Redirect for host) > > Ethernet II, Src: PcEngine_00:11:68 (00:0d:b9:00:11:68), Dst: IntelCor_6f= :c2:60 (00:1c:c0:6f:c2:60) > > No. Time Source Destination Protocol Length Info > 190 1.029392 192.168.1.61 192.168.1.1 ICMP 98 Echo (ping) reply= id=3D0x2220, seq=3D0/0, ttl=3D64 (request in 186) > > Ethernet II, Src: SlimDevi_05:31:38 (00:04:20:05:31:38), Dst: IntelCor_6f= :c2:60 (00:1c:c0:6f:c2:60) > ------------------------ > > The server issues an echo request for .61 but is using the router's MAC a= ddress (:68)! Obviously the router answers with a redirect.. > > I've shut down all daemons and kernel modules if possible until just the = absolute bare minimum (sshd, init and some other base services) was running= . I've upgraded to CURRENT. This didn't change anything. What helped in the= end was issuing a "route flush ; route add default 192.168.1.254": the ser= ver was immediately able to contact .61 directly. > > The problem seemingly appears randomly, sometimes it takes weeks for it t= o reappear. > > Sorry for the long post, I've tried to keep it as compact as possible. Do= es anyone have any idea what might be causing those problems? > > Regards, Anton > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 6 23:42:46 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DF81F39 for ; Mon, 6 Apr 2015 23:42:46 +0000 (UTC) Received: from mail.techlistingz.com (mail.techlistingz.com [60.243.245.61]) by mx1.freebsd.org (Postfix) with ESMTP id B97C2960 for ; Mon, 6 Apr 2015 23:42:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.techlistingz.com (Postfix) with ESMTP id 331F01A89E68 for ; Tue, 7 Apr 2015 04:33:17 +0530 (IST) Received: from mail.techlistingz.com ([127.0.0.1]) by localhost (mail.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjySSp2G2yOm for ; Tue, 7 Apr 2015 04:33:17 +0530 (IST) Received: from WSC32 (unknown [125.99.249.4]) by mail.techlistingz.com (Postfix) with ESMTPSA id 2C9B31A8C9EC for ; Tue, 7 Apr 2015 04:33:09 +0530 (IST) From: "Jessica Alba" To: Subject: Contact Appending Services Date: Mon, 6 Apr 2015 15:58:43 -0700 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBwvTb2+RhQzvjMThCfp3mMk4Zudg== Content-Language: en-us x-cr-hashedpuzzle: APU4 Bmbb Cc1q CyNE EYyr Epqk Fxo7 GKjF HG4Y HhIm IPT3 IXs9 I8Ja I+vB J70B KcJ9; 1; ZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {AD64C75F-4CAC-473E-9CFD-311E74067563}; agBlAHMAcwBpAGMAYQBAAGwAZQBhAGQAbgB1AHIAdAB1AHIAaQBuAGcAcwAuAGMAbwBtAA==; Mon, 06 Apr 2015 22:58:40 GMT; QwBvAG4AdABhAGMAdAAgAEEAcABwAGUAbgBkAGkAbgBnACAAUwBlAHIAdgBpAGMAZQBzAA== x-cr-puzzleid: {AD64C75F-4CAC-473E-9CFD-311E74067563} Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 23:42:46 -0000 Hi, I hope you are the right person to discuss about the Data Appending Services and B2B or B2C Contacts. Would you are interested to get in touch with all Top Decision Makers from your industry? We expertise in Data Appending Services and B2B or B2C Contacts:- Data Appending Services: - We can add/ replace any missing/ inaccurate e-mails from your in-house data base and get you the most updates e-mails. All of these e-mails are Opt-in/ permission Passed. If you are interested in our Data Appending Service send me 25-50 Random samples from your data base for a free test and I would revert with the appended results for your review. We are Data Compilers and Wholesalers our Master database size is over 400 Million across the Globe. We have the most competitive pricing for our clients, all that sums to the maximum number of client satisfaction. B2B or B2C Contacts: - We can also assist you in acquiring contacts according to your target market for your Marketing Initiatives like Email Marketing, Tele Marketing, Direct Mailing and Fax Campaigns. Our Lists Includes:-Company Name, Contact Name, Phone Number, Email address, Fax Number, Physical Address with City, State, Country, Zip Code, SIC Code, Revenue Size, Employee Size, Website URL etc If you are interested send me your exact target audience, so that I can give you more information, Pricing as well as few samples, just for your review Industry -------------------------- (Any Industry), Title -------------------------- (Any Job Title), Geography -------------------------- (Any Geography) Looking forward to your response. Best Regards, Jessica Alba Demand Generation Executive If you don't wish to receive any further email from us Please mention 'Leave Out' in Subject. From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 03:13:58 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2E4EF26 for ; Tue, 7 Apr 2015 03:13:58 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB4113A for ; Tue, 7 Apr 2015 03:13:58 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t373Dvej053477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 6 Apr 2015 20:13:57 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <55234B74.5020506@rawbw.com> Date: Mon, 06 Apr 2015 20:13:56 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: net@freebsd.org Subject: [BUG?] dhclient sends packets with source IP address that has been deleted Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 03:13:58 -0000 I am observing what dhclient sends to the server. Source IP of the packet it sends is the previous DHCP lease. This address doesn't exist any more, because I manually deleted it with 'ifconfig em0 remove ' command. Yet, when I rerun dhclient, it takes this address from /var/db/dhclient.leases.em0 and sends the UDP packet with this non-existent IP as source address in IP header. This looks very weird to me, though I am not sure what the practical implications of this might be. My guess is that it is able to do this because it injects packets with bpf. Should this thing be fixed, or this is harmless? Some other host might have this IP address by the time dhclient runs, and this might cause confusion somewhere. 10.1 STABLE Yuri From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 05:47:17 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD02C90E for ; Tue, 7 Apr 2015 05:47:17 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FE821DA for ; Tue, 7 Apr 2015 05:47:17 +0000 (UTC) Received: by iebmp1 with SMTP id mp1so38309819ieb.0 for ; Mon, 06 Apr 2015 22:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9bYgqFXHFLU0v3oD1mtSJMNNDotdGh/3UPw6T4lY5mI=; b=qzQ7IFsS4xBUSPNMrYSt0PTTFV4SH7Xva1iPq7pp1DL9h7VJl8GK0q2ByctFZ4YL+q LCpdT3rhruKVCM0z3WagRy1ZPlsBdapG8Dhc2qcfh4GEju/N+aZB+881sZyG/vCq+qcd 97cMOahsfFxoHopMnEDWCpwXzK1mx17Ehn18YdkxYVEe53/TUQGLGX5mpLRo/nOnNVTr ppVtLpcOOq391ydPaKN06CM1ylQj+ys8rpAhJWP/QHfB7ruCZ2C7WhTw6YPCyNwlzBhn x62TnhTF68cIzlIvsg2GjsqRSIwTOGHxNqnLguDo+dTC+UOGk+XkDFR1tSc+PtAY6dLD O7XQ== MIME-Version: 1.0 X-Received: by 10.42.23.17 with SMTP id q17mr7334066icb.4.1428385636885; Mon, 06 Apr 2015 22:47:16 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Mon, 6 Apr 2015 22:47:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Apr 2015 22:47:16 -0700 X-Google-Sender-Auth: YArqJqM5xKfxjw3R0abqvH2DuNw Message-ID: Subject: Re: Issue with TCPdump From: Kevin Oberman To: Dan Mahoney Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , plosher@isc.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 05:47:17 -0000 On Mon, Apr 6, 2015 at 1:22 AM, Dan Mahoney wrote: > Hey all, > > Here at ISC, we're seeing a weird issue with the tcpdump command in > 10.0-RELEASE. I'm hoping someone can take a look. > -- > > We have an F-root stats collector that we run as part of an annual event > to gather data across various root servers. It uses the following tcpdump > syntax: > > /usr/sbin/tcpdump -i em0 -G 600 -s 0 -w > /var/tcpdumps/cdg1b-pcap.%Y-%m-%d-%H:%M:%S -z gzip dst net ( > 192.5.5.241/32 or 2001:500:2f::f/128) and not ( src net 204.152.184.0/21 > or src net 149.20.0.0/16 or src net 2001:04F8::/32 and dst port 22 ) > > I've included the full command in case it's needed, but the only bits we > really care about are -G 600 and -z gzip, which should gzip all the log > files, right out of the manpage. > > What this SHOULD give us is a bunch of gzipped files in /var/tcpdumps. In > reality, only the first file is gzipped: > > root@cdg1b:/var/tcpdumps # ls -al > total 66888 > drwxr-xr-x 2 root wheel 1024 Apr 6 08:07 . > drwxr-xr-x 32 root wheel 1024 Nov 3 10:30 .. > -rw-r--r-- 1 root wheel 1762188 Apr 6 04:44 > cdg1b-pcap.2015-04-06-04:34:47.gz > -rw-r--r-- 1 root wheel 5262738 Apr 6 04:54 > cdg1b-pcap.2015-04-06-04:44:47 > -rw-r--r-- 1 root wheel 5371252 Apr 6 05:04 > cdg1b-pcap.2015-04-06-04:54:47 > -rw-r--r-- 1 root wheel 5828832 Apr 6 05:14 > cdg1b-pcap.2015-04-06-05:04:47 > -rw-r--r-- 1 root wheel 5612538 Apr 6 05:24 > cdg1b-pcap.2015-04-06-05:14:47 > -rw-r--r-- 1 root wheel 5864548 Apr 6 05:34 > cdg1b-pcap.2015-04-06-05:24:47 > -rw-r--r-- 1 root wheel 5728222 Apr 6 05:44 > cdg1b-pcap.2015-04-06-05:34:47 > -rw-r--r-- 1 root wheel 5749591 Apr 6 05:54 > cdg1b-pcap.2015-04-06-05:44:47 > -rw-r--r-- 1 root wheel 5845820 Apr 6 06:04 > cdg1b-pcap.2015-04-06-05:54:47 > -rw-r--r-- 1 root wheel 5874731 Apr 6 06:14 > cdg1b-pcap.2015-04-06-06:04:47 > -rw-r--r-- 1 root wheel 5689875 Apr 6 06:24 > cdg1b-pcap.2015-04-06-06:14:47 > -rw-r--r-- 1 root wheel 5592813 Apr 6 06:34 > cdg1b-pcap.2015-04-06-06:24:47 > > Sorry for the messy output. I'd happily log this as a bug (either in > FreeBSD, or upstream) if someone else > could take a look. > > -Dan > I just tried this and it worked fine for me. All files were compressed and suffixed with ".gz". My command was: tcpdump -i wlan0 -p -G 500 -z gzip -s0 -w test.pcap.%Y-%m-%d-%H:%M:%S While I didn't think any options were positional, I did move "-z gzip" before "-G 500" This is on 10-Stable, so it may have been fixed, but I don't see any relevant updates since 10.0. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 07:04:42 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F81ADAD for ; Tue, 7 Apr 2015 07:04:42 +0000 (UTC) Received: from BLU004-OMC2S3.hotmail.com (blu004-omc2s3.hotmail.com [65.55.111.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAE62C29 for ; Tue, 7 Apr 2015 07:04:41 +0000 (UTC) Received: from BLU184-W77 ([65.55.111.71]) by BLU004-OMC2S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 7 Apr 2015 00:04:40 -0700 X-TMN: [+7La/djPBdN3P4A6UBR/sAKh71ddKHDV] X-Originating-Email: [dr_sweety_1337@hotmail.com] Message-ID: From: Anton Farber To: "freebsd-net@freebsd.org" Subject: RE: FreeBSD sometimes uses the router for packets on the local network Date: Tue, 7 Apr 2015 07:04:40 +0000 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2015 07:04:40.0363 (UTC) FILETIME=[1DDC57B0:01D07101] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 07:04:42 -0000 > On Mon=2C Apr 6=2C 2015 at 12:15 PM=2C Anton Farber > wrote: > > I've opened a thread on the FreeBSD networking forum (https://forums.fr= eebsd.org/threads/jail-fails-to-connect-to-main-host.50833/) as sometime ag= o my FreeBSD server (initially running 10.1=2C now CURRENT) started to beha= ve strangely after an upgrade from 10.0 to 10.1. I first noticed that a jai= l (192.168.1.5) wasn't able to contact the base system (192.168.1.1). Runni= ng a tcpdump revealed the following: the jail is using em0 instead of lo0 f= or communicating with the base system: >=20 > You need to look at your routing tables. From inside the jail=2C run > "netstat -rn -f inet". You probably won't see any entry for 127.0.0.1 > or 127.0.0.0/8. Those are the entries that your jail needs in order > to talk to the base system. You can add them=2C but think carefully. > Many server processes=2C such as ntpd=2C have reduced security for > connections coming over 127.0.0.1. Whether or not it is appropriate > to add those routes depends on why you are using a jail. Ok=2C so the behaviour I'm seeing regarding the communication between jail = and base system is to be expected then. My reason for posting it was=2C tha= t I was unsure whether it might have anything to do with the main problem. = I don't think that this is the case so the question remains=2C why is my Fr= eeBSD server sometimes using the router for contacting hosts on the local n= etwork? Regards=2C Anton = From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 07:30:00 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1A117A3 for ; Tue, 7 Apr 2015 07:30:00 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 326DFEB2 for ; Tue, 7 Apr 2015 07:30:00 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t377To4W080612 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 10:29:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t377To4W080612 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t377Tnxc080611; Tue, 7 Apr 2015 10:29:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 Apr 2015 10:29:49 +0300 From: Konstantin Belousov To: Anton Farber Subject: Re: FreeBSD sometimes uses the router for packets on the local network Message-ID: <20150407072949.GA2379@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 07:30:00 -0000 On Tue, Apr 07, 2015 at 07:04:40AM +0000, Anton Farber wrote: > > On Mon, Apr 6, 2015 at 12:15 PM, Anton Farber > > wrote: > > > I've opened a thread on the FreeBSD networking forum (https://forums.freebsd.org/threads/jail-fails-to-connect-to-main-host.50833/) as sometime ago my FreeBSD server (initially running 10.1, now CURRENT) started to behave strangely after an upgrade from 10.0 to 10.1. I first noticed that a jail (192.168.1.5) wasn't able to contact the base system (192.168.1.1). Running a tcpdump revealed the following: the jail is using em0 instead of lo0 for communicating with the base system: > > > > You need to look at your routing tables. From inside the jail, run > > "netstat -rn -f inet". You probably won't see any entry for 127.0.0.1 > > or 127.0.0.0/8. Those are the entries that your jail needs in order > > to talk to the base system. You can add them, but think carefully. > > Many server processes, such as ntpd, have reduced security for > > connections coming over 127.0.0.1. Whether or not it is appropriate > > to add those routes depends on why you are using a jail. > > Ok, so the behaviour I'm seeing regarding the communication between jail and base system is to be expected then. My reason for posting it was, that I was unsure whether it might have anything to do with the main problem. I don't think that this is the case so the question remains, why is my FreeBSD server sometimes using the router for contacting hosts on the local network? This was very strange proposal to look at routing tables inside jail. Do you use VNET-enabled kernel ? If not, there is no separate instance of the network stack per jail. The netstat -rn output in jail for non-VNET kernels is simply not relevant to your problem. The same issues must be present when non-jailed process using the same source address selection. From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 11:29:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00851263 for ; Tue, 7 Apr 2015 11:29:46 +0000 (UTC) Received: from BLU004-OMC2S19.hotmail.com (blu004-omc2s19.hotmail.com [65.55.111.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB665F97 for ; Tue, 7 Apr 2015 11:29:46 +0000 (UTC) Received: from BLU184-W14 ([65.55.111.73]) by BLU004-OMC2S19.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 7 Apr 2015 04:29:45 -0700 X-TMN: [Kys4RFdSBs42Q70TDaDHMprXvQ/39gBF] X-Originating-Email: [dr_sweety_1337@hotmail.com] Message-ID: From: Anton Farber To: "freebsd-net@freebsd.org" Subject: RE: FreeBSD sometimes uses the router for packets on the local network Date: Tue, 7 Apr 2015 11:29:45 +0000 Importance: Normal In-Reply-To: <20150407072949.GA2379@kib.kiev.ua> References: , , , <20150407072949.GA2379@kib.kiev.ua> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2015 11:29:45.0301 (UTC) FILETIME=[25F14850:01D07126] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 11:29:47 -0000 > On Tue=2C Apr 07=2C 2015 at 07:04:40AM +0000=2C Anton Farber wrote:=0A= >>> On Mon=2C Apr 6=2C 2015 at 12:15 PM=2C Anton Farber=0A= >>> wrote:=0A= >>>> I've opened a thread on the FreeBSD networking forum (https://forums.f= reebsd.org/threads/jail-fails-to-connect-to-main-host.50833/) as sometime a= go my FreeBSD server (initially running 10.1=2C now CURRENT) started to beh= ave strangely after an upgrade from 10.0 to 10.1. I first noticed that a ja= il (192.168.1.5) wasn't able to contact the base system (192.168.1.1). Runn= ing a tcpdump revealed the following: the jail is using em0 instead of lo0 = for communicating with the base system:=0A= >>> =0A= >>> You need to look at your routing tables. From inside the jail=2C run=0A= >>> "netstat -rn -f inet". You probably won't see any entry for 127.0.0.1= =0A= >>> or 127.0.0.0/8. Those are the entries that your jail needs in order=0A= >>> to talk to the base system. You can add them=2C but think carefully.=0A= >>> Many server processes=2C such as ntpd=2C have reduced security for=0A= >>> connections coming over 127.0.0.1. Whether or not it is appropriate=0A= >>> to add those routes depends on why you are using a jail.=0A= >> =0A= >> Ok=2C so the behaviour I'm seeing regarding the communication between ja= il and base system is to be expected then. My reason for posting it was=2C = that I was unsure whether it might have anything to do with the main proble= m. I don't think that this is the case so the question remains=2C why is my= FreeBSD server sometimes using the router for contacting hosts on the loca= l network?=0A= > =0A= > This was very strange proposal to look at routing tables inside jail.=0A= > Do you use VNET-enabled kernel ? If not=2C there is no separate instance = of=0A= > the network stack per jail. The netstat -rn output in jail for non-VNET= =0A= > kernels is simply not relevant to your problem. The same issues must be= =0A= > present when non-jailed process using the same source address selection.= =0A= =0A= No=2C I'm not using a VNET-enabled kernel (at least not to my knowledge :).= I'm not sure whether my problem is jail related at all... It's just where = it first manifested itself: suddenly I wasn't able to connect from my jail = to the base system when using SSH or IMAP (roundcube). It was only later on= e that I realized=2C that the base system was having troubles connecting to= random hosts on the local network (as described in my initial post).=0A= =0A= Regards=2C Anton = From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 14:53:55 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF1C5846 for ; Tue, 7 Apr 2015 14:53:55 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADAAEBA for ; Tue, 7 Apr 2015 14:53:55 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 730255A9F27; Tue, 7 Apr 2015 14:53:54 +0000 (UTC) Date: Tue, 7 Apr 2015 14:53:54 +0000 From: Brooks Davis To: Yuri Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted Message-ID: <20150407145354.GA9746@spindle.one-eyed-alien.net> References: <55234B74.5020506@rawbw.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <55234B74.5020506@rawbw.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 14:53:55 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 06, 2015 at 08:13:56PM -0700, Yuri wrote: > I am observing what dhclient sends to the server. Source IP of the=20 > packet it sends is the previous DHCP lease. This address doesn't exist=20 > any more, because I manually deleted it with 'ifconfig em0 remove '= =20 > command. Yet, when I rerun dhclient, it takes this address from=20 > /var/db/dhclient.leases.em0 and sends the UDP packet with this=20 > non-existent IP as source address in IP header. >=20 > This looks very weird to me, though I am not sure what the practical=20 > implications of this might be. My guess is that it is able to do this=20 > because it injects packets with bpf. > Should this thing be fixed, or this is harmless? >=20 > Some other host might have this IP address by the time dhclient runs,=20 > and this might cause confusion somewhere. I suppose that since dhclient has been killed and restarted it can't know it's on the same network, but in practice you want to try to get the same lease again and fall back if it turns out you've moved or your dhcp server is broken and lost state. I don't see how this would hurt anything. -- Brooks --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUj74EACgkQXY6L6fI4GtQQBgCfQ4mF8TiUlPEfEvRxEb1aozke D4wAmwTO3OW/4SnWleWnS6xI3BTCDJQZ =Ab4r -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 21:08:04 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59A7DF99; Tue, 7 Apr 2015 21:08:04 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 42036AE2; Tue, 7 Apr 2015 21:08:04 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t37L7vjd055834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 7 Apr 2015 14:07:58 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <5524472C.1050905@rawbw.com> Date: Tue, 07 Apr 2015 14:07:56 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: net@freebsd.org Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted References: <55234B74.5020506@rawbw.com> <20150407145354.GA9746@spindle.one-eyed-alien.net> In-Reply-To: <20150407145354.GA9746@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Brooks Davis X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 21:08:04 -0000 On 04/07/2015 07:53, Brooks Davis wrote: > I suppose that since dhclient has been killed and restarted it can't > know it's on the same network, but in practice you want to try to get > the same lease again and fall back if it turns out you've moved or your dhcp > server is broken and lost state. I don't see how this would hurt anything. Let's say dhclient is restarted after a while (ex. after the reboot), when some other host already has that same IP address. dhclient sends the broadcast with it, and the response will be sent to another host, which currently has that address, and that other host will discard this response. dhclient keeps trying for many seconds, doesn't get any response. Then it falls back to sending from 0.0.0.0->255.255.255.255 (as it should have done in the first place), and immediately gets the valid response. The problem delays DHCP handshake, this is how this can hurt. dhclient comes from OpenBSD upstream. It has been discontinued in OpenBSD, due to them thinking it has a lot of problems. Maybe FreeBSD should also replace dhclient? Yuri From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 22:24:23 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2436A4D; Tue, 7 Apr 2015 22:24:23 +0000 (UTC) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 81633620; Tue, 7 Apr 2015 22:24:23 +0000 (UTC) Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 76.31.09025.11954255; Tue, 7 Apr 2015 15:24:17 -0700 (PDT) X-AuditID: 11973e15-f79fd6d000002341-2d-55245911f842 Received: from [17.149.235.34] (Unknown_Domain [17.149.235.34]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 90.7B.24525.1E854255; Tue, 7 Apr 2015 15:23:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted From: Charles Swiger In-Reply-To: <5524472C.1050905@rawbw.com> Date: Tue, 7 Apr 2015 15:24:17 -0700 Message-Id: References: <55234B74.5020506@rawbw.com> <20150407145354.GA9746@spindle.one-eyed-alien.net> <5524472C.1050905@rawbw.com> To: Yuri X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUi2FCYqisYqRJqcPqNksXr/5UWi9Y2slp8 2H6AyYHZY8an+SweC9dcYA1giuKySUnNySxLLdK3S+DKWPX2AHPBN+WK4zffszQwLpbrYuTk kBAwkZhx5TgThC0mceHeerYuRi4OIYF9jBLNC+aywBRd2DeTFSIxlUliwcx2ZpAEs0CCxOO+ lawgNq+AgcTcU1/AJgkLhEvsOzgLqIaDg01ATWLCRB6QMKeApsTHAyfAZrIIqEgcWXmUCWKM hUTft42MEGOsJJbtegVWIyRQIfFg91mw8SICkhKXbpxlBxkpISAv0bMpHeQcCYEJbBIrFp9n n8AoOAvJRbOQXAQR15ZYtvA18yygdmYBHYnJCxlRhSHsj+ePMC1gZFvFKJSbmJmjm5lnppdY UJCTqpecn7uJERT20+1EdzCeWWV1iFGAg1GJh5dBTjlUiDWxrLgy9xCjNAeLkjiv+mGlUCGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2MYUkaXMUZaXw952eqfIy5re/U8mWl3owue8PP3QsS oyXU9xQ8K3izp1Bd7Xxe0KK9No/OeW78wnPscOe1tdksfHcilzM9uC13rUloeV/THA6hVyV3 Tr6MSK2Tlt2/dOkL56jjOmqJ+Sym5hcf67JJPKv5feDwNod/ottP/7gYcSuN5f2it+dWKLEU ZyQaajEXFScCABfxgh1cAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUiOPW1ku7DCJVQg7kfNSxe/6+0WLS2kdXi w/YDTA7MHjM+zWfxWLjmAmsAUxSXTUpqTmZZapG+XQJXxqq3B5gLvilXHL/5nqWBcbFcFyMn h4SAicSFfTNZIWwxiQv31rN1MXJxCAlMZZJYMLOdGSTBLJAg8bhvJVgRr4CBxNxTX5hAbGGB cIl9B2cB1XBwsAmoSUyYyAMS5hTQlPh44AQLiM0ioCJxZOVRJogxFhJ93zYyQoyxkli26xVY jZBAhcSD3WfBxosISEpcunGWHWSkhIC8RM+m9AmMfLOQHDELyREQcW2JZQtfM88C6mAW0JGY vJARVRjC/nj+CNMCRrZVjAJFqTmJleZ6iQUFOal6yfm5mxhBYdpQmLqDsXG51SFGAQ5GJR5e BjnlUCHWxLLiytxDjBIczEoivAsdVUKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ82oFA6UE0hNL UrNTUwtSi2CyTBycUg2Ma8Qbqr7GuyRPf6S3rPahQPD75jBdibWKyzL3Xko377kQcE5aj5Xl ktCUoI/XZR7/uPPvV2drW8Zn9mMXVW9s0dILvXjyRl6wHMO+fta/E6VLqhIS30+ZptwZqtGz bfLTRslT/iV/5V29hRwd06YkBRernHedLdMxdfn9jLDHJpz/7mvcKbupxFKckWioxVxUnAgA i4Zd+U8CAAA= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Brooks Davis , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 22:24:23 -0000 On Apr 7, 2015, at 2:07 PM, Yuri wrote: > On 04/07/2015 07:53, Brooks Davis wrote: >> I suppose that since dhclient has been killed and restarted it can't >> know it's on the same network, but in practice you want to try to get >> the same lease again and fall back if it turns out you've moved or = your dhcp >> server is broken and lost state. I don't see how this would hurt = anything. >=20 > Let's say dhclient is restarted after a while (ex. after the reboot), = when some other host already has that same IP address. dhclient sends = the broadcast with it, and the response will be sent to another host, = which currently has that address, and that other host will discard this = response. dhclient keeps trying for many seconds, doesn't get any = response. Then it falls back to sending from 0.0.0.0->255.255.255.255 = (as it should have done in the first place), and immediately gets the = valid response. The problem delays DHCP handshake, this is how this can = hurt. In point of fact, the IP used for the source address doesn't matter too = much for DHREQUESTs because they are subnet local (by definition), and = the replies will reach the original sender because they are addressed to = the layer-2 MAC address of that host. DHCP operates as much on layer-2 = as layer-3 and dhclient, ISC dhcpd, and other DHCP software should = handle such cases. There is a specific protocol coming from Zeroconf defined here: http://www.ietf.org/rfc/rfc5227.txt = ...which talks about how to handle potential IP conflicts via ARP = probing. Regards, --=20 -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 22:37:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E23CDCEA for ; Tue, 7 Apr 2015 22:37:51 +0000 (UTC) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.wp.pl", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69E207BF for ; Tue, 7 Apr 2015 22:37:50 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 4343 invoked from network); 8 Apr 2015 00:11:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1428444667; bh=BDQbYLXIGybD2CnAmwySaiz3LDw64RjaIQLa/8mpJog=; h=From:To:Subject; b=fY97k//LW4o+RslSYf/x+liMWvAEqy+iEDgnXWJV+pXOJPWoBv5M+HWah904dRjjx sNyOjzea9l9JevFCL0Vn+QRfTGi8d8mWW1/qHK8KSNjhTyLLBnImwdCsnE/xYYF5GE /d4NFEtT5rR2n/fD8UgrMLV4PW8nZk6TM/ix5TTQ= Received: from 250-210-250-178.ftth.cust.kwaoo.net (HELO [10.0.5.10]) (marek_sal@[178.250.210.250]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 8 Apr 2015 00:11:07 +0200 Message-ID: <552455EB.7080609@wp.pl> Date: Wed, 08 Apr 2015 00:10:51 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: RTT and TCP Window size doubts, bandwidth issues Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [oVOB] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 22:37:52 -0000 Hi list, I am trying to find correct setup of sysctl's for following machines (VMs under Vmware Workstation 8) to test large TCP window size: There are 2 boxes, each of them has following setup: - % uname -a FreeBSD freeA 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 - 4GB of RAM - 1 NIC without any modifications, iperf reports bandwidth speed ~1Gbit/s between hosts: server-side: # iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ client-side: # iperf -c 192.168.108.140 ------------------------------------------------------------ Client connecting to 192.168.108.140, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.108.141 port 35282 connected with 192.168.108.140 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.46 GBytes 1.25 Gbits/sec I want to simulate (using dummynet) link between hosts with bandwidth 400mbit/s and latency ~20ms. In order to do that, I create the ipfw pipe on one box: IPFW="ipfw -q" $IPFW pipe 1 config bw 400Mbit/s delay 10ms $IPFW add 1500 pipe 1 ip from any to any after running ipfw, bandwidth with default kernel sysctl becomes lower: client-side: ------------------------------------------------------------ Client connecting to 192.168.108.140, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.108.141 port 35340 connected with 192.168.108.140 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 12.5 MBytes 10.4 Mbits/sec I'd like to achieve bandwidth ~400Mbit/s. I've modified following sysctl's (both on client- and server-side): kern.ipc.maxsockbuf=33554432 # (default 2097152) net.inet.tcp.sendbuf_max=33554432 # (default 2097152) net.inet.tcp.recvbuf_max=33554432 # (default 2097152) net.inet.tcp.cc.algorithm=htcp # (default newreno) #enabled in /boot/loader.conf also net.inet.tcp.cc.htcp.adaptive_backoff=1 # (default 0 ; disabled) net.inet.tcp.cc.htcp.rtt_scaling=1 # (default 0 ; disabled) net.inet.tcp.mssdflt=1460 # (default 536) net.inet.tcp.minmss=1300 # (default 216) net.inet.tcp.rfc1323=1 # (default 1) net.inet.tcp.rfc3390=1 # (default 1) net.inet.tcp.sendspace=8388608 # (default 32768) net.inet.tcp.recvspace=8388608 # (default 65536) net.inet.tcp.sendbuf_inc=32768 # (default 8192 ) net.inet.tcp.recvbuf_inc=65536 # (default 16384) But the results are not really good as I expected: server-side: # iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 8.00 MByte (default) ------------------------------------------------------------ client-side: # iperf -c 192.168.108.140 ------------------------------------------------------------ Client connecting to 192.168.108.140, TCP port 5001 TCP window size: 8.00 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.108.141 port 21894 connected with 192.168.108.140 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.1 sec 24.2 MBytes 20.2 Mbits/sec I was trying to follow the articles: - http://www.psc.edu/index.php/networking/641-tcp-tune - https://fasterdata.es.net/host-tuning/freebsd/ But can't really figure out what / how should be tuned in order to achieve good results. If anyone could find some time and give me some hints, I'd be pleased! Cheers Marek From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 01:50:17 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D310F1B for ; Wed, 8 Apr 2015 01:50:17 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 87057F33 for ; Wed, 8 Apr 2015 01:50:17 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t381oGUd080223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 7 Apr 2015 18:50:16 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <55248957.60109@rawbw.com> Date: Tue, 07 Apr 2015 18:50:15 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: net@freebsd.org Subject: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 01:50:17 -0000 I noticed that the socket bound to '0.0.0.0' only receives UDP broadcasts when they are sent from zero IP: 0.0.0.0->255.255.255.255. When the source IP is not zeros, but some valid IP on that network, socket never receives such broadcast. I compared two packets in wireshark as they arrive, and the only difference on Ether/IP/UDP level is source IP. Is there any reason why source IP address would influence the reception of the broadcast packets? I use this python3 program to create bound socket and listen: #!/usr/bin/env python3.4 import socket sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.bind(('0.0.0.0', 67)) print("Waiting for broadcast") (data, flags, ancillary, addr) = sock.recvmsg(4096, 256) print("Received broadcast packet") I use dhclient to send broadcast packets. It sends with src=0.0.0.0 when no /var/db/dhclient.leases.* exists, and it always sends with src= when the previous lease exists. 10.1 STABLE Yuri From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 08:04:23 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F78640E; Wed, 8 Apr 2015 08:04:23 +0000 (UTC) Received: from relay.mailchannels.net (ftx-008-i775.relay.mailchannels.net [50.61.143.75]) by mx1.freebsd.org (Postfix) with ESMTP id 2F45AC88; Wed, 8 Apr 2015 08:04:21 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|opaldns Received: from smtp5.ore.mailhop.org (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id F25201207B4; Wed, 8 Apr 2015 08:04:12 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|opaldns Received: from smtp5.ore.mailhop.org (smtp5.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Wed, 08 Apr 2015 08:04:13 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|opaldns X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428480253081:782897074 X-MC-Ingress-Time: 1428480253081 Received: from pool-71-255-171-111.bstnma.east.verizon.net ([71.255.171.111] helo=homobox.opal.com) by smtp5.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Yfky2-0008Ct-Vt; Wed, 08 Apr 2015 08:04:11 +0000 Received: from shibato (ip51cd975c.adsl-surfen.hetnet.nl [81.205.151.92]) (authenticated bits=0) by homobox.opal.com (8.14.9/8.14.9) with ESMTP id t38841Op098650 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 8 Apr 2015 04:04:03 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 71.255.171.111 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX19v3yEEGBvbUCSgj9C5Upeb Date: Wed, 8 Apr 2015 10:03:49 +0200 From: "J.R. Oldroyd" To: Brooks Davis Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted Message-ID: <20150408100349.31a74103@shibato> In-Reply-To: <20150407145354.GA9746@spindle.one-eyed-alien.net> References: <55234B74.5020506@rawbw.com> <20150407145354.GA9746@spindle.one-eyed-alien.net> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/q39P7DUM2TL0ieEE8Zo497T"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (homobox.opal.com [71.255.171.111]); Wed, 08 Apr 2015 04:04:04 -0400 (EDT) X-Spam-Status: No, score=3.5 required=5.0 tests=AWL,BAYES_40, FSL_HELO_NON_FQDN_1,RCVD_IN_PBL shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on homobox.opal.com X-AuthUser: opaldns Cc: Yuri , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 08:04:23 -0000 --Sig_/q39P7DUM2TL0ieEE8Zo497T Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 7 Apr 2015 14:53:54 +0000 Brooks Davis wrote: > > On Mon, Apr 06, 2015 at 08:13:56PM -0700, Yuri wrote: > > I am observing what dhclient sends to the server. Source IP of the=20 > > packet it sends is the previous DHCP lease. This address doesn't exist= =20 > > any more, because I manually deleted it with 'ifconfig em0 remove '= =20 > > command. Yet, when I rerun dhclient, it takes this address from=20 > > /var/db/dhclient.leases.em0 and sends the UDP packet with this=20 > > non-existent IP as source address in IP header. > >=20 > > This looks very weird to me, though I am not sure what the practical=20 > > implications of this might be. My guess is that it is able to do this=20 > > because it injects packets with bpf. > > Should this thing be fixed, or this is harmless? > >=20 > > Some other host might have this IP address by the time dhclient runs,=20 > > and this might cause confusion somewhere. >=20 > I suppose that since dhclient has been killed and restarted it can't > know it's on the same network, but in practice you want to try to get > the same lease again and fall back if it turns out you've moved or your d= hcp > server is broken and lost state. I don't see how this would hurt anythin= g. >=20 > -- Brooks This bit me, too, some time back, when I was writing some custom dhcpd back-end scripts. dhclient is broadcasting (to 255.255.255.255) an initial DHCPREQUEST to try to re-obtain its old IP. The old IP is used as the source IP and the message body also contains the old IP request. =46rom RFC2131, section 4.1: DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0. Note the "must" there. So the current behavior looks like an error, to me. If the re-obtaining of the old IP fails, DHCPDISCOVER messages are then sent and these do have source 0.0.0.0 which is per the standard. -jr --Sig_/q39P7DUM2TL0ieEE8Zo497T Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUk4OoACgkQls33urr0k4kNlwCfR8IXSPnjhyPcLX2UhhmjNox+ 9FgAnRBqsJaJU7pSinoBwil7MnnraQUW =Wq2K -----END PGP SIGNATURE----- --Sig_/q39P7DUM2TL0ieEE8Zo497T-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 09:04:41 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6C45891 for ; Wed, 8 Apr 2015 09:04:40 +0000 (UTC) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.wp.pl", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D53266D for ; Wed, 8 Apr 2015 09:04:39 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 4379 invoked from network); 8 Apr 2015 10:37:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1428482276; bh=p/Ojzj6FT+2JyoeRcmI5TTNaT+xK12XIcEuwm3dhuMc=; h=From:To:Subject; b=dD+IkN1EIQ51iy5V45PiSpHpmLAq3P+n6uvdrnHhkbuR0u3Jo23oDbOZIEJrutiAl eXhtnizdjewHqmIL1JqdlK8SU13LLpZ+jiXvy9wfjhF2HljFPELWsCtGYutvpBEbj0 J2srGEB/iJsqTWheRsoBB/j2AVCvOqa2teTeSOrY= Received: from pb-d-128-141-172-176.cern.ch (HELO [128.141.172.176]) (marek_sal@[128.141.172.176]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 8 Apr 2015 10:37:56 +0200 Message-ID: <5524E8D5.8000109@wp.pl> Date: Wed, 08 Apr 2015 10:37:41 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: ipfw / dummynet does not hit the rules? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [YdPU] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 09:04:41 -0000 Hi all, I have simple VM ('freeC') with 3 NICs: - em0 connected to NAT (acces to SSH) - em1 connected to "segment 1" - em2 connected to "segment 2" there are 2 other VMs: - freeA connected to "segment 1", 10.0.0.1/24 - freeB connected to "segment 2", 10.0.0.2/24 Idea: Create a L2 bridge on freeC (em1-em2) and control the bandwidth / rtt using dummynet. Setup of freeC: root@freeC:~ # uname -a FreeBSD freeC 10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr 7 01:09:46 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 root@freeC:~ # root@freeC:~ # cat /boot/loader.conf dummynet_load="YES" if_bridge_load="YES" root@freeC:~ # cat /etc/rc.conf hostname="freeC" ifconfig_em0="DHCP" sshd_enable="YES" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev="AUTO" cloned_interfaces="bridge0" ifconfig_bridge0="addm em1 addm em2 up" ifconfig_em1="up" ifconfig_em2="up" firewall_enable="YES" firewall_type="open" root@freeC:~ # cat /etc/sysctl.conf net.link.bridge.ipfw=1 net.inet.ip.fw.verbose=1 net.inet.ip.fw.verbose_limit=5 net.inet.ip.fastforwarding=0 net.inet.ip.dummynet.io_fast=0 freeA is able to ping freeB and vice-versa. Now I'd like to limit bandwidth and add delay: root@freeC:~ # ipfw pipe 1 config bw 400Mbit/s delay 100ms root@freeC:~ # ipfw pipe 1 show 00001: 400.000 Mbit/s 100 ms burst 0 q131073 50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail sched 65537 type FIFO flags 0x0 0 buckets 0 active root@freeC:~ # ipfw add 2000 pipe 1 all from any to any root@freeC:~ # ipfw show 00100 0 0 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 02000 41 5164 pipe 1 ip from any to any 65000 540 51995 allow ip from any to any 65535 2 400 deny ip from any to any freeA is still pining freeB with RTT~0,2 ms (I expected 200ms) Another try with "layer2" rule: root@freeC:~ # ipfw show 00100 0 0 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 02000 0 0 pipe 1 ip from any to any layer2 65000 621 60067 allow ip from any to any 65535 2 400 deny ip from any to any root@freeC:~ # Boxes freeA and freeB are still pinging with RTT ~0.2ms Please note the counters - they are not increasing. Is this a bug or am I doing sth wrong? Best regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 10:30:57 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DE6ED9ED for ; Wed, 8 Apr 2015 10:30:56 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABCC4F77 for ; Wed, 8 Apr 2015 10:30:56 +0000 (UTC) Received: by pacyx8 with SMTP id yx8so110276721pac.1 for ; Wed, 08 Apr 2015 03:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=uAWg0WlXH0wzgV+TzMNKJxAHcdfRMdWC/MS1uC+jFhk=; b=Dksc36odVbemmv/cqwzQK3oXYDDayeDnk1EWvADo9Y3PFj0m+hanxfieVBLnnfKxS8 LOf7ox4EnazBIUBf1fU8NzUZnqHlcPj6s1iiUfvVMoIwgcX1RNtuHwnyi1WvLHa7OOrw UbIGsIwVumjBVY/8EiZxyGAte0dQUbKciViCg399lH2I5obIbkEaaZ41CiUPpRNPkacw NqBQlrXGgM5OPkiUnHjokOroMOTe5QX9VFAO02vu5I191WdGR7qBl9CGKUuWIuwQMMEB vAInUFcX2N1WO/b7ewRotNWgzF2CcMLpFIkvGiazvsKUAaStQKHbzZo1GV7LhtVwte26 da4w== X-Received: by 10.70.89.237 with SMTP id br13mr45475451pdb.135.1428489056331; Wed, 08 Apr 2015 03:30:56 -0700 (PDT) Received: from [172.29.229.7] ([116.197.184.12]) by mx.google.com with ESMTPSA id t8sm10593875pbs.59.2015.04.08.03.30.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2015 03:30:55 -0700 (PDT) Message-ID: <5525035B.9050200@gmail.com> Date: Wed, 08 Apr 2015 16:00:51 +0530 From: Ashish Gupta User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: net@freebsd.org Subject: Netmap usage in Freebsd10 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 10:30:57 -0000 Hi Netmap developers, In very simple application, I am using two freebsd10 vm's spawned using Qemu. About my environment, Underlying host os is linux, freebsd10 vm's are guest vms. These two bsd10 vm's are connected using em interface (which again Qemu emulated). |====== 10.10.10.1 (em) =======| | vm1 |<---------------------------------------------->| vm2 | |====== 10.10.10.2(em) ====== | If i start rapid ping between these vm, i see idle cpu remaining in system (bsd10 vm) is just 10-20%. checking further looking all cpu is going in em driver call (interrupt enable/disable) etc. ======= last pid: 8709; load averages: 1.89, 1.57, 1.76 up 0+00:38:44 05:59:46 30 processes: 3 running, 27 sleeping CPU: 2.0% user, 0.0% nice, 72.9% system, 10.2% interrupt, 14.9% idle <<<<<<<<<<<<<<<<<<<<<<<<< Mem: 138M Active, 642M Inact, 91M Wired, 89M Buf, 2624M Free Swap: 1024M Total, 1024M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 8089 root 1 25 0 18880K 3788K RUN 0:15 6.98% sshd 8628 root 1 29 0 14456K 1832K RUN 0:11 6.40% ping ========== I was thinking if i can make use of netmap here to achieve better performance, which will also leave some cpu for other application to run in vm. I enabled netmap related code changes in if_lem.c of bsd10 but looks like these changes also expects change in Qemu side also. ======= /* * Uncomment the following extensions for better performance in a VM, * especially if you have support in the hypervisor. * See http://info.iet.unipi.it/~luigi/netmap/ */ #define BATCH_DISPATCH #define NIC_SEND_COMBINING #define NIC_PARAVIRT /* enable virtio-like synchronization */ ----------- #ifdef NIC_PARAVIRT device_printf(dev, "driver supports paravirt, subdev 0x%x\n", adapter->hw.subsystem_device_id); if (adapter->hw.subsystem_device_id == E1000_PARA_SUBDEV) { <<<<<<<<<< =========== Qemu by default emulated em device with subsystem_device_id as 0x1100. It mean by enabling netmap change alone in bsd10 will not help. we also need changes from Qemu. I checked latest Qemu code but i dont see they emulating em with above subsystem_device_id. Can some one tell me about how to enable Qemu side change, if there is any patch available please provide me that to try. Do we also need application level change (to use /dev/netmap) to gain mentioned performance gain or we can get little bit of gain by just enabling kernel level changes. --Regards, Ashish Gupta From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 12:44:07 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2E5E8B0 for ; Wed, 8 Apr 2015 12:44:07 +0000 (UTC) Received: from a0i241.smtpcorp.com (a0i241.smtpcorp.com [216.22.15.73]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAE31F3 for ; Wed, 8 Apr 2015 12:44:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a0_1; h=Feedback-ID:X-Smtpcorp-Track:Message-ID:Date:Subject:To:From; bh=Dfy7jNQpMZzDXPr1p10UjG+GnLBqrmicSwqFmYMsY2o=; b=ZwWlz3gJzPWG6lHobWEY5dYFmcLMebXf4J+AV0WzxDln+p6cd7JPBgGS+BzoKgHD/NKZo7YF09yXTd0O2JHwir2kgI2HddO7vK5v3VNCxYzGmZHB2hxH4iZ3iN6sCSJy7hhyKECiAkeirE6CD8Tka1LXR6cd6ZUNUhX5LYEWhpU=; From: Daniel Corbe To: Yuri Subject: Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address References: <55248957.60109@rawbw.com> Date: Wed, 08 Apr 2015 08:32:13 -0400 In-Reply-To: <55248957.60109@rawbw.com> (yuri@rawbw.com's message of "Tue, 07 Apr 2015 18:50:15 -0700") Message-ID: <878ue2n6lu.fsf@corbe.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Smtpcorp-Track: 1Yfp9Vmkf4HKRN.JRBQSgpEI Feedback-ID: 10661m:10661aegzayD:10661sApYUW4ktf:SMTPCORP Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 12:44:07 -0000 If nobody answers this question by the time I get home I'll try and help; however, in the mean time I do have a couple of suggestions. Have you tried writing the equivalent program in C using the sockets API? IE is this a python specific problem or a sockets problem in general? The second thing is you may just want to try using raw sockets instead. -Daniel Yuri writes: > I noticed that the socket bound to '0.0.0.0' only receives UDP > broadcasts when they are sent from zero IP: > 0.0.0.0->255.255.255.255. When the source IP is not zeros, but some > valid IP on that network, socket never receives such broadcast. > > I compared two packets in wireshark as they arrive, and the only > difference on Ether/IP/UDP level is source IP. > > Is there any reason why source IP address would influence the > reception of the broadcast packets? > > I use this python3 program to create bound socket and listen: > #!/usr/bin/env python3.4 > import socket > sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) > sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) > sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) > sock.bind(('0.0.0.0', 67)) > print("Waiting for broadcast") > (data, flags, ancillary, addr) = sock.recvmsg(4096, 256) > print("Received broadcast packet") > > I use dhclient to send broadcast packets. It sends with src=0.0.0.0 > when no /var/db/dhclient.leases.* exists, and it always sends with > src= when the previous lease exists. > > 10.1 STABLE > > Yuri > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 13:14:02 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 558B2E60 for ; Wed, 8 Apr 2015 13:14:02 +0000 (UTC) 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 5233B641 for ; Wed, 8 Apr 2015 13:14:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t38DDoE9004446; Wed, 8 Apr 2015 23:13:50 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 8 Apr 2015 23:13:50 +1000 (EST) From: Ian Smith To: Marek Salwerowicz Subject: Re: RTT and TCP Window size doubts, bandwidth issues In-Reply-To: <552455EB.7080609@wp.pl> Message-ID: <20150408225751.D22893@sola.nimnet.asn.au> References: <552455EB.7080609@wp.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 13:14:02 -0000 On Wed, 8 Apr 2015 00:10:51 +0200, Marek Salwerowicz wrote: > Hi list, > > I am trying to find correct setup of sysctl's for following machines (VMs > under Vmware Workstation 8) to test large TCP window size: > > > There are 2 boxes, each of them has following setup: > - % uname -a > FreeBSD freeA 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 > UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > amd64 > > - 4GB of RAM > - 1 NIC > > without any modifications, iperf reports bandwidth speed ~1Gbit/s between > hosts: > > server-side: > # iperf -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > > client-side: > > # iperf -c 192.168.108.140 > ------------------------------------------------------------ > Client connecting to 192.168.108.140, TCP port 5001 > TCP window size: 32.5 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.108.141 port 35282 connected with 192.168.108.140 port > 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 1.46 GBytes 1.25 Gbits/sec > > > > I want to simulate (using dummynet) link between hosts with bandwidth > 400mbit/s and latency ~20ms. > In order to do that, I create the ipfw pipe on one box: > IPFW="ipfw -q" > > > $IPFW pipe 1 config bw 400Mbit/s delay 10ms > > $IPFW add 1500 pipe 1 ip from any to any > > > after running ipfw, bandwidth with default kernel sysctl becomes lower: > > client-side: > ------------------------------------------------------------ > Client connecting to 192.168.108.140, TCP port 5001 > TCP window size: 32.5 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.108.141 port 35340 connected with 192.168.108.140 port > 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.1 sec 12.5 MBytes 10.4 Mbits/sec > > > > I'd like to achieve bandwidth ~400Mbit/s. > > I've modified following sysctl's (both on client- and server-side): > > kern.ipc.maxsockbuf=33554432 # (default 2097152) > > net.inet.tcp.sendbuf_max=33554432 # (default 2097152) > net.inet.tcp.recvbuf_max=33554432 # (default 2097152) > > net.inet.tcp.cc.algorithm=htcp # (default newreno) #enabled in > /boot/loader.conf also > net.inet.tcp.cc.htcp.adaptive_backoff=1 # (default 0 ; disabled) > > net.inet.tcp.cc.htcp.rtt_scaling=1 # (default 0 ; disabled) > > net.inet.tcp.mssdflt=1460 # (default 536) > > net.inet.tcp.minmss=1300 # (default 216) > > net.inet.tcp.rfc1323=1 # (default 1) > net.inet.tcp.rfc3390=1 # (default 1) > > > net.inet.tcp.sendspace=8388608 # (default 32768) > net.inet.tcp.recvspace=8388608 # (default 65536) > > net.inet.tcp.sendbuf_inc=32768 # (default 8192 ) > net.inet.tcp.recvbuf_inc=65536 # (default 16384) > > > > But the results are not really good as I expected: > > server-side: > # iperf -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 8.00 MByte (default) > ------------------------------------------------------------ > > client-side: > # iperf -c 192.168.108.140 > ------------------------------------------------------------ > Client connecting to 192.168.108.140, TCP port 5001 > TCP window size: 8.00 MByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.108.141 port 21894 connected with 192.168.108.140 port > 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.1 sec 24.2 MBytes 20.2 Mbits/sec > > > I was trying to follow the articles: > - http://www.psc.edu/index.php/networking/641-tcp-tune > - https://fasterdata.es.net/host-tuning/freebsd/ > > But can't really figure out what / how should be tuned in order to achieve > good results. > > If anyone could find some time and give me some hints, I'd be pleased! Many of your tunings are over my head, but I can see that you've nicely emulated a half-duplex link; you want one pipe for each direction for a fast bidirectional link. See ipfw(8) /TRAFFIC SHAPING Also be sure of your setting of sysctl net.inet.ip.fw.one_pass, here and also re your later post re ipfw / dummynet, which also wants 2 pipes. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 17:18:45 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 562AB3A3 for ; Wed, 8 Apr 2015 17:18:45 +0000 (UTC) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id AB7A4AA2 for ; Wed, 8 Apr 2015 17:18:44 +0000 (UTC) Received: from lgwl-lstewart2.corp.netflix.com (unknown [69.53.237.72]) by lauren.room52.net (Postfix) with ESMTPSA id 55D0C7E81E; Thu, 9 Apr 2015 03:18:35 +1000 (EST) Message-ID: <552562E9.9060103@freebsd.org> Date: Wed, 08 Apr 2015 10:18:33 -0700 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Marek Salwerowicz , "freebsd-net@freebsd.org" Subject: Re: RTT and TCP Window size doubts, bandwidth issues References: <552455EB.7080609@wp.pl> In-Reply-To: <552455EB.7080609@wp.pl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:18:45 -0000 On 04/07/15 15:10, Marek Salwerowicz wrote: > Hi list, > > I am trying to find correct setup of sysctl's for following machines > (VMs under Vmware Workstation 8) to test large TCP window size: > > > There are 2 boxes, each of them has following setup: > - % uname -a > FreeBSD freeA 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 > 19:00:21 UTC 2015 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > - 4GB of RAM > - 1 NIC > > without any modifications, iperf reports bandwidth speed ~1Gbit/s > between hosts: > > server-side: > # iperf -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > > client-side: > > # iperf -c 192.168.108.140 > ------------------------------------------------------------ > Client connecting to 192.168.108.140, TCP port 5001 > TCP window size: 32.5 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.108.141 port 35282 connected with 192.168.108.140 > port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 1.46 GBytes 1.25 Gbits/sec > > > > I want to simulate (using dummynet) link between hosts with bandwidth > 400mbit/s and latency ~20ms. > In order to do that, I create the ipfw pipe on one box: > IPFW="ipfw -q" > > > $IPFW pipe 1 config bw 400Mbit/s delay 10ms > > $IPFW add 1500 pipe 1 ip from any to any You should set up 2 pipes, one for each direction of traffic, and you also might want to explicitly set the queue size in bytes in addition to the bw and delay parameters. > after running ipfw, bandwidth with default kernel sysctl becomes lower: > > client-side: > ------------------------------------------------------------ > Client connecting to 192.168.108.140, TCP port 5001 > TCP window size: 32.5 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.108.141 port 35340 connected with 192.168.108.140 > port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.1 sec 12.5 MBytes 10.4 Mbits/sec > > > > I'd like to achieve bandwidth ~400Mbit/s. Better calculate the BDP then: 400E6 x 20E-3 = 977Kb, so you'll want to make sure your socket buffers and window can accommodation ~1Mb of data. > I've modified following sysctl's (both on client- and server-side): > > kern.ipc.maxsockbuf=33554432 # (default 2097152) > > net.inet.tcp.sendbuf_max=33554432 # (default 2097152) > net.inet.tcp.recvbuf_max=33554432 # (default 2097152) > > net.inet.tcp.cc.algorithm=htcp # (default newreno) #enabled in > /boot/loader.conf also > net.inet.tcp.cc.htcp.adaptive_backoff=1 # (default 0 ; disabled) > > net.inet.tcp.cc.htcp.rtt_scaling=1 # (default 0 ; disabled) You shouldn't need to tune any of the above, and NewReno should be capable of filling a 1MB pipe. > net.inet.tcp.mssdflt=1460 # (default 536) > > net.inet.tcp.minmss=1300 # (default 216) You should not change either of these. > net.inet.tcp.rfc1323=1 # (default 1) > net.inet.tcp.rfc3390=1 # (default 1) 3390 has no effect if you have net.inet.tcp.experimental.initcwnd10=1 which is default on 10.X (unfortunately, IMO). > net.inet.tcp.sendspace=8388608 # (default 32768) > net.inet.tcp.recvspace=8388608 # (default 65536) You shouldn't need to tune these if sockbuf autotuning is enabled, which will grow the default up to sendbuf_max, which defaults to larger than 1MB so you should be fine. > net.inet.tcp.sendbuf_inc=32768 # (default 8192 ) > net.inet.tcp.recvbuf_inc=65536 # (default 16384) Tuning these is ok though also probably unnecessary. > But the results are not really good as I expected: > > server-side: > # iperf -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 8.00 MByte (default) > ------------------------------------------------------------ > > client-side: > # iperf -c 192.168.108.140 > ------------------------------------------------------------ > Client connecting to 192.168.108.140, TCP port 5001 > TCP window size: 8.00 MByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.108.141 port 21894 connected with 192.168.108.140 > port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.1 sec 24.2 MBytes 20.2 Mbits/sec > > > I was trying to follow the articles: > - http://www.psc.edu/index.php/networking/641-tcp-tune > - https://fasterdata.es.net/host-tuning/freebsd/ > > But can't really figure out what / how should be tuned in order to > achieve good results. > > If anyone could find some time and give me some hints, I'd be pleased! On the sender (iperf client): kldload siftr sysctl net.inet.siftr.enabled=1 sysctl net.inet.siftr.enabled=0 You can then post process the /var/log/siftr.log to pull out just the iperf related lines: cat /var/log/siftr.log | grep "192.168.108.140,5001" > iperf.siftr Then you can look at socket buffer occupancies, cwnd vs snd_wnd vs time, loss recovery, etc to see why things are not behaving. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 21:21:21 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32242E06 for ; Wed, 8 Apr 2015 21:21:21 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 012C3BDF for ; Wed, 8 Apr 2015 21:21:20 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t38LLCC3080218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Apr 2015 14:21:13 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <55259BC7.6040502@rawbw.com> Date: Wed, 08 Apr 2015 14:21:11 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: net@freebsd.org Subject: Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address References: <55248957.60109@rawbw.com> <878ue2n6lu.fsf@corbe.net> In-Reply-To: <878ue2n6lu.fsf@corbe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Corbe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:21:21 -0000 On 04/08/2015 05:32, Daniel Corbe wrote: > If nobody answers this question by the time I get home I'll try and > help; however, in the mean time I do have a couple of suggestions. > > Have you tried writing the equivalent program in C using the sockets > API? IE is this a python specific problem or a sockets problem in > general? > > The second thing is you may just want to try using raw sockets instead. I verified before with ktrace, and now, following your suggestion, rewrote it in C, and result is the same. When I change SOCK_DGRAM->SOCK_RAW it keeps getting some other packets, sin_port doesn't seem to matter. Also, UDP is the practically important case. Unless there is some reasonable explanation why ip source address can influence reception, I believe this is a bug in kernel. And pretty important one, because it can hurt DHCP servers. Yuri --- C program exhibiting the problem --- #include #include #include #include #include #define CK(func, call...) if ((call) < 0) {perror(#func); exit(1);} int main() { int sock, one = 1; ssize_t count; struct sockaddr_in sa; char buffer[4096]; struct sockaddr_storage src_addr; struct iovec iov[1]; iov[0].iov_base=buffer; iov[0].iov_len=sizeof(buffer); struct msghdr msg; msg.msg_name=&src_addr; msg.msg_namelen=sizeof(src_addr); msg.msg_iov=iov; msg.msg_iovlen=1; msg.msg_control=0; msg.msg_controllen=0; CK(socket, sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) CK(setsockopt, setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one))) CK(setsockopt, setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &one, sizeof(one))) sa.sin_family = AF_INET; sa.sin_addr.s_addr = htonl(INADDR_ANY); //sa.sin_port = htons(67); sa.sin_port = htons(1767); CK(bind, bind(sock, (const struct sockaddr*)&sa, sizeof(sa))) printf("Waiting for broadcast\n"); CK(recvmsg, count = recvmsg(sock, &msg, 0)) printf("Received broadcast packet: %zd bytes\n", count); return 0; } From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 22:33:09 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BAB35AF for ; Wed, 8 Apr 2015 22:33:09 +0000 (UTC) Received: from remote.thehowies.com (50-197-91-217-static.hfc.comcastbusiness.net [50.197.91.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A57D368 for ; Wed, 8 Apr 2015 22:33:08 +0000 (UTC) Received: from PRIMARY.thehowies.local ([fe80::497b:de8e:1045:4c2a]) by PRIMARY.thehowies.local ([fe80::497b:de8e:1045:4c2a%24]) with mapi id 14.03.0224.002; Wed, 8 Apr 2015 15:31:54 -0700 From: John Howie To: Yuri , "net@freebsd.org" Subject: Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address Thread-Topic: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address Thread-Index: AQHQcZ5h2I9CcpL4u0iz7C/8UqpBP51DEDWjgAEFxYD//9CxgA== Date: Wed, 8 Apr 2015 22:31:53 +0000 Message-ID: References: <55248957.60109@rawbw.com> <878ue2n6lu.fsf@corbe.net> <55259BC7.6040502@rawbw.com> In-Reply-To: <55259BC7.6040502@rawbw.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [12.130.116.80] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Daniel Corbe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:33:09 -0000 Hi Yuri, Is your machine a router or gateway, or have a firewall? Are you trying to capture all broadcast packets, or just UDP targeted and broadcast packets to a particular port? Regards, John On 4/8/15, 5:21 PM, "Yuri" wrote: >On 04/08/2015 05:32, Daniel Corbe wrote: >> If nobody answers this question by the time I get home I'll try and >> help; however, in the mean time I do have a couple of suggestions. >> >> Have you tried writing the equivalent program in C using the sockets >> API? IE is this a python specific problem or a sockets problem in >> general? >> >> The second thing is you may just want to try using raw sockets instead. > >I verified before with ktrace, and now, following your suggestion, >rewrote it in C, and result is the same. >When I change SOCK_DGRAM->SOCK_RAW it keeps getting some other packets, >sin_port doesn't seem to matter. Also, UDP is the practically important >case. > >Unless there is some reasonable explanation why ip source address can >influence reception, I believe this is a bug in kernel. And pretty >important one, because it can hurt DHCP servers. > >Yuri > > >--- C program exhibiting the problem --- > >#include >#include >#include >#include >#include > >#define CK(func, call...) if ((call) < 0) {perror(#func); exit(1);} > >int main() { > int sock, one =3D 1; > ssize_t count; > struct sockaddr_in sa; > char buffer[4096]; > struct sockaddr_storage src_addr; > > struct iovec iov[1]; > iov[0].iov_base=3Dbuffer; > iov[0].iov_len=3Dsizeof(buffer); > > struct msghdr msg; > msg.msg_name=3D&src_addr; > msg.msg_namelen=3Dsizeof(src_addr); > msg.msg_iov=3Diov; > msg.msg_iovlen=3D1; > msg.msg_control=3D0; > msg.msg_controllen=3D0; > > CK(socket, sock =3D socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) > CK(setsockopt, setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &one, >sizeof(one))) > CK(setsockopt, setsockopt(sock, SOL_SOCKET, SO_BROADCAST, &one, >sizeof(one))) > sa.sin_family =3D AF_INET; > sa.sin_addr.s_addr =3D htonl(INADDR_ANY); > //sa.sin_port =3D htons(67); > sa.sin_port =3D htons(1767); > CK(bind, bind(sock, (const struct sockaddr*)&sa, sizeof(sa))) > > printf("Waiting for broadcast\n"); > CK(recvmsg, count =3D recvmsg(sock, &msg, 0)) > printf("Received broadcast packet: %zd bytes\n", count); > > return 0; >} > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 22:38:51 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D249468C; Wed, 8 Apr 2015 22:38:51 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id BA94B394; Wed, 8 Apr 2015 22:38:51 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t38Mcn1Y087814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Apr 2015 15:38:50 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <5525ADF8.8020808@rawbw.com> Date: Wed, 08 Apr 2015 15:38:48 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "J.R. Oldroyd" , Brooks Davis Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted References: <55234B74.5020506@rawbw.com> <20150407145354.GA9746@spindle.one-eyed-alien.net> <20150408100349.31a74103@shibato> In-Reply-To: <20150408100349.31a74103@shibato> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:38:51 -0000 On 04/08/2015 01:03, J.R. Oldroyd wrote: > From RFC2131, section 4.1: > > DHCP messages broadcast by a client prior to that client obtaining > its IP address must have the source address field in the IP header > set to 0. > > Note the "must" there. > > So the current behavior looks like an error, to me. I suspected that this is the violation of DHCP specs. Many times I saw how FreeBSD to FreeBSD DHCP handshake is delayed without an apparent reason. I think this bug combined with another one when broadcast UDP packet isn't received when source IP is set is the cause of such DHCP delays. Yuri From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 22:42:49 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1100D745 for ; Wed, 8 Apr 2015 22:42:49 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id ED5D463D for ; Wed, 8 Apr 2015 22:42:48 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t38MgjX7087923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Apr 2015 15:42:46 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <5525AEE4.3030400@rawbw.com> Date: Wed, 08 Apr 2015 15:42:44 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Howie , "net@freebsd.org" Subject: Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address References: <55248957.60109@rawbw.com> <878ue2n6lu.fsf@corbe.net> <55259BC7.6040502@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Corbe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:42:49 -0000 On 04/08/2015 15:31, John Howie wrote: > Is your machine a router or gateway, or have a firewall? Are you trying to > capture all broadcast packets, or just UDP targeted and broadcast packets > to a particular port? No, it isn't a gateway or router, and no firewall. Trying to capture all broadcast UDP to a particular port. Observing this with with virtual machine dhcp client bridged to the host through tapN. Host is otherwise just a plain FreeBSD workstation itself. Yuri From owner-freebsd-net@FreeBSD.ORG Wed Apr 8 23:07:55 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0F66D33 for ; Wed, 8 Apr 2015 23:07:55 +0000 (UTC) Received: from remote.thehowies.com (50-197-91-217-static.hfc.comcastbusiness.net [50.197.91.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 782938A2 for ; Wed, 8 Apr 2015 23:07:54 +0000 (UTC) Received: from PRIMARY.thehowies.local ([fe80::497b:de8e:1045:4c2a]) by PRIMARY.thehowies.local ([fe80::497b:de8e:1045:4c2a%24]) with mapi id 14.03.0224.002; Wed, 8 Apr 2015 16:07:54 -0700 From: John Howie To: Yuri , "net@freebsd.org" Subject: Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address Thread-Topic: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address Thread-Index: AQHQcZ5h2I9CcpL4u0iz7C/8UqpBP51DEDWjgAEFxYD//9CxgIAARhgA///D9gA= Date: Wed, 8 Apr 2015 23:07:52 +0000 Message-ID: References: <55248957.60109@rawbw.com> <878ue2n6lu.fsf@corbe.net> <55259BC7.6040502@rawbw.com> <5525AEE4.3030400@rawbw.com> In-Reply-To: <5525AEE4.3030400@rawbw.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [12.130.116.80] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <220F0500137B8443865F884310B7FDCE@thehowies.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Daniel Corbe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:07:55 -0000 Hi Yuri, Have you tried using a static IP address for the host and VM, and disabling DHCP? The DHCP client will bind to and use 0.0.0.0 to get an IP address. The SO_REUSEADDR rule is that every tuple (proto, src ip, src port, dst ip, dst prt) must be unique. I am wondering if that is where your problem lies. There might be something that is shortcutting the uniqueness of the tuple and just focusing on IP addresses. I would validate that for you but I am at 35000=B9 right now... Regards, John On 4/8/15, 6:42 PM, "Yuri" wrote: >On 04/08/2015 15:31, John Howie wrote: >> Is your machine a router or gateway, or have a firewall? Are you trying >>to >> capture all broadcast packets, or just UDP targeted and broadcast >>packets >> to a particular port? > >No, it isn't a gateway or router, and no firewall. Trying to capture all >broadcast UDP to a particular port. > >Observing this with with virtual machine dhcp client bridged to the host >through tapN. Host is otherwise just a plain FreeBSD workstation itself. > >Yuri From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 01:43:24 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65B25281 for ; Thu, 9 Apr 2015 01:43:24 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA0CA32 for ; Thu, 9 Apr 2015 01:43:23 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t391hMZ0099643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Apr 2015 18:43:22 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <5525D939.4030506@rawbw.com> Date: Wed, 08 Apr 2015 18:43:21 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Howie , "net@freebsd.org" Subject: Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address References: <55248957.60109@rawbw.com> <878ue2n6lu.fsf@corbe.net> <55259BC7.6040502@rawbw.com> <5525AEE4.3030400@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 01:43:24 -0000 On 04/08/2015 16:07, John Howie wrote: > Have you tried using a static IP address for the host and VM, and > disabling DHCP? The DHCP client will bind to and use 0.0.0.0 to get an IP > address. The SO_REUSEADDR rule is that every tuple (proto, src ip, src > port, dst ip, dst prt) must be unique. I am wondering if that is where > your problem lies. There might be something that is shortcutting the > uniqueness of the tuple and just focusing on IP addresses. I would > validate that for you but I am at 35000¹ right now... > Hi John, I apologize, I actually did have ipfw rules set, and ipfw is the culprit. Yuri From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 02:59:09 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88D16EC0 for ; Thu, 9 Apr 2015 02:59:09 +0000 (UTC) Received: from remote.thehowies.com (50-197-91-217-static.hfc.comcastbusiness.net [50.197.91.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "remote.thehowies.com", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 600AA20E for ; Thu, 9 Apr 2015 02:59:08 +0000 (UTC) Received: from PRIMARY.thehowies.local ([fe80::497b:de8e:1045:4c2a]) by PRIMARY.thehowies.local ([fe80::497b:de8e:1045:4c2a%24]) with mapi id 14.03.0224.002; Wed, 8 Apr 2015 19:59:04 -0700 From: John Howie To: Yuri , "net@freebsd.org" Subject: Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address Thread-Topic: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address Thread-Index: AQHQcZ5h2I9CcpL4u0iz7C/8UqpBP51DEDWjgAEFxYD//9CxgIAARhgA///D9gCAAG6BgP//0hcA Date: Thu, 9 Apr 2015 02:59:03 +0000 Message-ID: References: <55248957.60109@rawbw.com> <878ue2n6lu.fsf@corbe.net> <55259BC7.6040502@rawbw.com> <5525AEE4.3030400@rawbw.com> <5525D939.4030506@rawbw.com> In-Reply-To: <5525D939.4030506@rawbw.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [12.130.116.80] Content-Type: text/plain; charset="euc-kr" Content-ID: <8438A392D065A3489496CC7650ED9D12@thehowies.local> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:59:09 -0000 SGkgWXVyaSwNCg0KTm8gbmVlZCB0byBhcG9sb2dpemUhIFNvbWV0aW1lcyBpdCB0YWtlcyBhIGRp c3Bhc3Npb25hdGUgcGVyc29uIHRvIHJldmlldw0KdGhlIHByb2JsZW0gdG8gaGVscCB5b3UgZmlu ZCB0aGUgc29sdXRpb24uIFlvdSBmb3VuZCBpdCwgbm90IG1lLiBJIGp1c3QNCmhlbHBlZCB5b3Ug Z2V0IHRoZXJloaYNCg0KU3RpbGwgYXQgMzUwMDChryAobGl0ZXJhbGx5KSwgdHJ5aW5nIHRvIGdl dCB0byB3aGVyZSBJIGFtIGdvaW5nIQ0KDQpSZWdhcmRzLA0KDQpKb2huDQoNCg0KT24gNC84LzE1 LCA5OjQzIFBNLCAiWXVyaSIgPHl1cmlAcmF3YncuY29tPiB3cm90ZToNCg0KPk9uIDA0LzA4LzIw MTUgMTY6MDcsIEpvaG4gSG93aWUgd3JvdGU6DQo+PiBIYXZlIHlvdSB0cmllZCB1c2luZyBhIHN0 YXRpYyBJUCBhZGRyZXNzIGZvciB0aGUgaG9zdCBhbmQgVk0sIGFuZA0KPj4gZGlzYWJsaW5nIERI Q1A/IFRoZSBESENQIGNsaWVudCB3aWxsIGJpbmQgdG8gYW5kIHVzZSAwLjAuMC4wIHRvIGdldCBh bg0KPj5JUA0KPj4gYWRkcmVzcy4gVGhlIFNPX1JFVVNFQUREUiBydWxlIGlzIHRoYXQgZXZlcnkg dHVwbGUgKHByb3RvLCBzcmMgaXAsIHNyYw0KPj4gcG9ydCwgZHN0IGlwLCBkc3QgcHJ0KSBtdXN0 IGJlIHVuaXF1ZS4gSSBhbSB3b25kZXJpbmcgaWYgdGhhdCBpcyB3aGVyZQ0KPj4geW91ciBwcm9i bGVtIGxpZXMuIFRoZXJlIG1pZ2h0IGJlIHNvbWV0aGluZyB0aGF0IGlzIHNob3J0Y3V0dGluZyB0 aGUNCj4+IHVuaXF1ZW5lc3Mgb2YgdGhlIHR1cGxlIGFuZCBqdXN0IGZvY3VzaW5nIG9uIElQIGFk ZHJlc3Nlcy4gSSB3b3VsZA0KPj4gdmFsaWRhdGUgdGhhdCBmb3IgeW91IGJ1dCBJIGFtIGF0IDM1 MDAwqfYgcmlnaHQgbm93Li4uDQo+Pg0KPg0KPkhpIEpvaG4sDQo+DQo+SSBhcG9sb2dpemUsIEkg YWN0dWFsbHkgZGlkIGhhdmUgaXBmdyBydWxlcyBzZXQsIGFuZCBpcGZ3IGlzIHRoZSBjdWxwcml0 Lg0KPg0KPll1cmkNCg0K From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 03:47:57 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 444449F4; Thu, 9 Apr 2015 03:47:57 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 069E0AB6; Thu, 9 Apr 2015 03:47:57 +0000 (UTC) Received: by iejt8 with SMTP id t8so19262059iej.2; Wed, 08 Apr 2015 20:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WRWFGFkWT0nFmDdFMwnppFiHWVXzKdSd1VX5jfhR9S0=; b=v4tplU/+dn/TV84YXvG77kBniJa99hMP5w++IQMVr62R+78e1HST7LwUCkZmQQM4cS L0Ev/6JUIwUxsa2qPf+MW0NfmzJRSsyuQEFoIQpK+5A57I4kf9ngRlFHePuvvPied65A gqIoOpPjy6mEgUffhK0ZzyRQLJfkzqgY7tWNSQKEPfz9Oo/MWQAWgt4PiN4cRDlzChpZ lPsXi+N0D+fZMLYOpDoxe9F6/mcuiPUZVNXp7tLNPeQMrTokruDTvhe+6yu1N9DS5/Sf eqcczrR24v3LyhDOr+NC+LKshexKVPS3BBCKSPPXv11PYsJU8uQVfrq3kmcc8zh4wrbM aMmg== MIME-Version: 1.0 X-Received: by 10.107.27.143 with SMTP id b137mr43750047iob.76.1428551276163; Wed, 08 Apr 2015 20:47:56 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Wed, 8 Apr 2015 20:47:56 -0700 (PDT) In-Reply-To: <20150408100349.31a74103@shibato> References: <55234B74.5020506@rawbw.com> <20150407145354.GA9746@spindle.one-eyed-alien.net> <20150408100349.31a74103@shibato> Date: Wed, 8 Apr 2015 20:47:56 -0700 X-Google-Sender-Auth: Rb1vrxTy_l8t1_svVLP4tfKfVKo Message-ID: Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted From: Kevin Oberman To: "J.R. Oldroyd" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Yuri , Brooks Davis , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 03:47:57 -0000 On Wed, Apr 8, 2015 at 1:03 AM, J.R. Oldroyd wrote: > On Tue, 7 Apr 2015 14:53:54 +0000 Brooks Davis wrote: > > > > On Mon, Apr 06, 2015 at 08:13:56PM -0700, Yuri wrote: > > > I am observing what dhclient sends to the server. Source IP of the > > > packet it sends is the previous DHCP lease. This address doesn't exist > > > any more, because I manually deleted it with 'ifconfig em0 remove ' > > > command. Yet, when I rerun dhclient, it takes this address from > > > /var/db/dhclient.leases.em0 and sends the UDP packet with this > > > non-existent IP as source address in IP header. > > > > > > This looks very weird to me, though I am not sure what the practical > > > implications of this might be. My guess is that it is able to do this > > > because it injects packets with bpf. > > > Should this thing be fixed, or this is harmless? > > > > > > Some other host might have this IP address by the time dhclient runs, > > > and this might cause confusion somewhere. > > > > I suppose that since dhclient has been killed and restarted it can't > > know it's on the same network, but in practice you want to try to get > > the same lease again and fall back if it turns out you've moved or your > dhcp > > server is broken and lost state. I don't see how this would hurt > anything. > > > > -- Brooks > > This bit me, too, some time back, when I was writing some custom dhcpd > back-end scripts. > > dhclient is broadcasting (to 255.255.255.255) an initial DHCPREQUEST > to try to re-obtain its old IP. The old IP is used as the source IP > and the message body also contains the old IP request. > > From RFC2131, section 4.1: > > DHCP messages broadcast by a client prior to that client obtaining > its IP address must have the source address field in the IP header > set to 0. > > Note the "must" there. > > So the current behavior looks like an error, to me. > > If the re-obtaining of the old IP fails, DHCPDISCOVER messages are > then sent and these do have source 0.0.0.0 which is per the standard. > > -jr > This one gets rather confusing and is subject to some interpretation. The idea is that a system should attempt to maintain the same address, if possible. That is why the dhclient.leases files are there. Even if a system has its interface shut down or is rebooted, the file contains the last assigned address. If it issues a request and the network is different, it will not get the address. If it is on the same network, it will get it's old address. >From the RFC 4.3.2 DHCPREQUEST message: 'requested IP address' option MUST be filled in with client's notion of its previously assigned address. The data in dhclient.leases provides that notion, and the interface has had a previously assigned address, but I agree that this is debatable. I think the word "notion" provides a clear indication of the intent. I know that Windows XP-SP2 behaved this way. I have not looked at anything more recent as that what we ran at work when I last was responsible for running a DHCP server. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 04:00:29 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79D7BC56 for ; Thu, 9 Apr 2015 04:00:29 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 60AB8CB5 for ; Thu, 9 Apr 2015 04:00:29 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t3940SWx012945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Apr 2015 21:00:28 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <5525F95B.80403@rawbw.com> Date: Wed, 08 Apr 2015 21:00:27 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: John Howie , "net@freebsd.org" Subject: Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address References: <55248957.60109@rawbw.com> <878ue2n6lu.fsf@corbe.net> <55259BC7.6040502@rawbw.com> <5525AEE4.3030400@rawbw.com> <5525D939.4030506@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 04:00:29 -0000 On 04/08/2015 19:59, John Howie wrote: > Still at 35000¡¯ (literally), trying to get to where I am going! Oh, you are flying! I first didn't understand what 35000' meant. Have a safe rest of the flight! Yuri From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 08:56:18 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8A37959; Thu, 9 Apr 2015 08:56:18 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i372.relay.mailchannels.net [174.136.5.173]) by mx1.freebsd.org (Postfix) with ESMTP id A97C0B0; Thu, 9 Apr 2015 08:56:17 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|opaldns Received: from smtp3.ore.mailhop.org (ip-10-213-14-133.us-west-2.compute.internal [10.213.14.133]) by relay.mailchannels.net (Postfix) with ESMTPA id 5F09A6068D; Thu, 9 Apr 2015 08:40:54 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|opaldns Received: from smtp3.ore.mailhop.org (smtp3.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Thu, 09 Apr 2015 08:40:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|opaldns X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428568854488:600923317 X-MC-Ingress-Time: 1428568854488 Received: from pool-71-255-171-111.bstnma.east.verizon.net ([71.255.171.111] helo=homobox.opal.com) by smtp3.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Yg816-0001fi-6H; Thu, 09 Apr 2015 08:40:52 +0000 Received: from shibato (ip51cd975c.adsl-surfen.hetnet.nl [81.205.151.92]) (authenticated bits=0) by homobox.opal.com (8.14.9/8.14.9) with ESMTP id t398eXLD050295 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Apr 2015 04:40:35 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 71.255.171.111 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1/JgSHPJ+8QqKedRrXWhpJd Date: Thu, 9 Apr 2015 10:40:17 +0200 From: "J.R. Oldroyd" To: Kevin Oberman Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted Message-ID: <20150409104017.0cd5c909@shibato> In-Reply-To: References: <55234B74.5020506@rawbw.com> <20150407145354.GA9746@spindle.one-eyed-alien.net> <20150408100349.31a74103@shibato> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Bn1Zy/M7J9lqQOzGibDudTT"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (homobox.opal.com [71.255.171.111]); Thu, 09 Apr 2015 04:40:36 -0400 (EDT) X-Spam-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_50, FSL_HELO_NON_FQDN_1,RCVD_IN_PBL shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on homobox.opal.com X-AuthUser: opaldns Cc: Yuri , Brooks Davis , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 08:56:18 -0000 --Sig_/Bn1Zy/M7J9lqQOzGibDudTT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 8 Apr 2015 20:47:56 -0700 Kevin Oberman wrote: > The > idea is that a system should attempt to maintain the same address, if > possible. That is why the dhclient.leases files are there. Even if a syst= em > has its interface shut down or is rebooted, the file contains the last > assigned address. If it issues a request and the network is different, it > will not get the address. If it is on the same network, it will get it's > old address. >=20 > >From the RFC 4.3.2 DHCPREQUEST message: > 'requested IP address' option MUST be filled in with client's notion of i= ts > previously assigned address. >=20 The data from the leases file is used to fill in the requested IP address in the message body. The source address of the packet should be set to 0. The fix appears to be pretty trivial: Index: sbin/dhclient/dhclient.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sbin/dhclient/dhclient.c (revision 280783) +++ sbin/dhclient/dhclient.c (working copy) @@ -1460,7 +1460,8 @@ memcpy(&to.s_addr, ip->client->destination.iabuf, sizeof(to.s_addr)); =20 - if (ip->client->state !=3D S_REQUESTING) + if (ip->client->state !=3D S_REQUESTING && + ip->client->state !=3D S_REBOOTING) memcpy(&from, ip->client->active->address.iabuf, sizeof(from)); else --Sig_/Bn1Zy/M7J9lqQOzGibDudTT Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUmOvsACgkQls33urr0k4neZQCfUg6I2WmBwYwq+zmg18c5syOV 1UYAnR5ZmrgJPjeVpKYutqfYOunX1pRG =2g1Q -----END PGP SIGNATURE----- --Sig_/Bn1Zy/M7J9lqQOzGibDudTT-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 14:11:40 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86350898 for ; Thu, 9 Apr 2015 14:11:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B107E43 for ; Thu, 9 Apr 2015 14:11:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t39EBeSb025151 for ; Thu, 9 Apr 2015 14:11:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193743] [re] RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically Date: Thu, 09 Apr 2015 14:11:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ohartman@zedat.fu-berlin.de X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:11:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193743 --- Comment #2 from ohartman@zedat.fu-berlin.de --- See also: Bug 197535 - [re] [panic] if_re (Realtek 8168) causes memory write after free and kernel panic and https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d6e572911a4cb2b9fcd1c26a38d5317a3971f2fd (reported by Luca Pizzamiglio). The proposed patch solved the problems I encountered. Obviously Linux people also encountered this problem and solved it - but FreeBSD not. it would be nice having this nasty and unnecessary issue solved. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 16:59:10 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC35087C for ; Thu, 9 Apr 2015 16:59:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9237177A for ; Thu, 9 Apr 2015 16:59:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t39GxAxh081753 for ; Thu, 9 Apr 2015 16:59:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197535] [re] [panic] if_re (Realtek 8168) causes memory write after free and kernel panic Date: Thu, 09 Apr 2015 16:59: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: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable10? 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.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 16:59:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197535 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ngie@FreeBSD.org --- Comment #12 from Garrett Cooper,425-314-3911 --- The patch (minus the commented out code) LGTM. I=E2=80=99ll test it out on = my workstation (a few kldunload/kldload/ifconfig/dhclient runs) and commit it = if no one objects in a few days. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 17:00:05 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 336F5986 for ; Thu, 9 Apr 2015 17:00:05 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19190799 for ; Thu, 9 Apr 2015 17:00:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t39H04bt083706 for ; Thu, 9 Apr 2015 17:00:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197535] [re] [panic] if_re (Realtek 8168) causes memory write after free and kernel panic Date: Thu, 09 Apr 2015 17:00:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:00:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 --- Comment #13 from Garrett Cooper,425-314-3911 --- And just for reference, here's what I'm running: re0@pci0:6:0:0: class=0x020000 card=0x83671043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet $ uname -a FreeBSD bayonetta.local 9.3-RELEASE FreeBSD 9.3-RELEASE #0 r268512: Thu Jul 10 23:44:39 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 20:19:47 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD44847A for ; Thu, 9 Apr 2015 20:19:47 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2664319 for ; Thu, 9 Apr 2015 20:19:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t39KJlVG034194 for ; Thu, 9 Apr 2015 20:19:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 172675] [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hostcache.list) race condition causing memory corruption Date: Thu, 09 Apr 2015 20:19: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: 8.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: nitroboost@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution bug_severity Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:19:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172675 nitroboost@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED Severity|Affects Only Me |Affects Some People --- Comment #9 from nitroboost@gmail.com --- John's fix was brought to 9 / 10, where I can confirm it works as intended. Thanks! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 21:36:27 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFC994BA for ; Thu, 9 Apr 2015 21:36:27 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B51D2ED6 for ; Thu, 9 Apr 2015 21:36:27 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t39LaRDD073425 for ; Thu, 9 Apr 2015 21:36:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193743] [re] RTL8111/8168B PCI Express Gigabit Ethernet controller: doesn't work properly, problems getting UP automatically Date: Thu, 09 Apr 2015 21:36:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:36:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193743 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: marius Date: Thu Apr 9 21:35:45 UTC 2015 New revision: 281337 URL: https://svnweb.freebsd.org/changeset/base/281337 Log: Don't enable RX and TX before their initial configuration is done, i. e. after setting up interrupt moderation but before turning interrupts on. This matches what Realtek's r8168 Linux driver does as of version 8.039.00 and fixes problems with certain incarnations of certain MAC revisions like the interface requiring an extra up/down-cycle after boot to start working or DMA configuration not being adhered to. PR: 193743, 197535 MFC after: 1 week Changes: head/sys/dev/re/if_re.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Apr 9 21:36:29 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 710FC4BF for ; Thu, 9 Apr 2015 21:36:29 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5681BED9 for ; Thu, 9 Apr 2015 21:36:29 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t39LaT4X073436 for ; Thu, 9 Apr 2015 21:36:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 197535] [re] [panic] if_re (Realtek 8168) causes memory write after free and kernel panic Date: Thu, 09 Apr 2015 21:36:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- 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: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:36:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197535 --- Comment #14 from commit-hook@freebsd.org --- A commit references this bug: Author: marius Date: Thu Apr 9 21:35:45 UTC 2015 New revision: 281337 URL: https://svnweb.freebsd.org/changeset/base/281337 Log: Don't enable RX and TX before their initial configuration is done, i. e. after setting up interrupt moderation but before turning interrupts on. This matches what Realtek's r8168 Linux driver does as of version 8.039.00 and fixes problems with certain incarnations of certain MAC revisions like the interface requiring an extra up/down-cycle after boot to start working or DMA configuration not being adhered to. PR: 193743, 197535 MFC after: 1 week Changes: head/sys/dev/re/if_re.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 01:00:22 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87EA2235 for ; Fri, 10 Apr 2015 01:00:22 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6E98B8A5 for ; Fri, 10 Apr 2015 01:00:22 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t3A10LPJ036304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 9 Apr 2015 18:00:21 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <552720A4.5030006@rawbw.com> Date: Thu, 09 Apr 2015 18:00:20 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: net@freebsd.org Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted References: <55234B74.5020506@rawbw.com> In-Reply-To: <55234B74.5020506@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 01:00:22 -0000 On 04/06/2015 20:13, Yuri wrote: > I am observing what dhclient sends to the server. Source IP of the > packet it sends is the previous DHCP lease. This address doesn't exist > any more, because I manually deleted it with 'ifconfig em0 remove > ' command. Yet, when I rerun dhclient, it takes this address from > /var/db/dhclient.leases.em0 and sends the UDP packet with this > non-existent IP as source address in IP header. Here is why I was asking many annoying questions lately in this ML: https://github.com/yurivict/freebsd-vbox-to-tor New service to connect VirtualBox VM to TOR using firewall rules and tap(4) interfaces. Security-through-isolation. Yuri From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 04:08:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3D14113; Fri, 10 Apr 2015 04:08:40 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (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 ADAD7E25; Fri, 10 Apr 2015 04:08:40 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 22C4E10C237; Thu, 9 Apr 2015 21:08:34 -0700 (PDT) Date: Thu, 9 Apr 2015 21:08:34 -0700 From: hiren panchasara To: freebsd-net@freebsd.org Subject: Idle connections via accept_filter(9) Message-ID: <20150410040834.GG61327@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TdkiTnkLhLQllcMS" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: nitroboost@gmail.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 04:08:40 -0000 --TdkiTnkLhLQllcMS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable If a connections comes on a socket with accf_data(9) (for example) but never sends any data, it'll occupy resources via staying forever in listen queue of partial unaccepted connections (socket->so_incomp) which can be seen as incqlen in 'netstat -Lan'. Kernel will never pass this connection down to the application as the filter criteria hasn't been met (no data) and application would never know about this connection. What I am not sure is what would be the state of the connection and state of the socket when in this situation. We do come here after finishing 3WHS but before handing this over to the application i.e. before the accept(). =46rom uipc_socket.c: * From the passive side, a socket is created with two queues of sockets: * so_incomp for connections in progress and so_comp for connections already * made and awaiting user acceptance. As a protocol is preparing incoming * connections, it creates a socket structure queued on so_incomp by calling * sonewconn(). When the connection is established, soisconnected() is * called, and transfers the socket structure to so_comp, making it availab= le * to accept(). So, it looks like the connection would be in ESTABLISHED state but socket would be stuck in the so_incomp queue. Other than this special condition of accpet_filter, can such a situation occur? Any insight/help into understanding this scenario and a way to cleanup these connections would be great. (I know tcp doesn't care/worry about idle sitting connections; we have keepalives to check the health of the connection but that's it, afaik) Cheers, Hiren --TdkiTnkLhLQllcMS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVJ0zBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l+scH/1Kbtqk9r05PTMCnZqXfe7PG Qh/USdnXzGcnxhZKIIT1F/c+pb2+YfTAa8CzdiD0kh+IV+zgTPsRNOfc1eKnLMTt jhh2umZ2KX8PDy2KMk8/WTPmyrNz7I9ifFOBI5wGLpItau7NvQsFBQGQO0P6Mypo YsD2S3Bqu2MaK1An9dhlc9jHK10P242S/nbMEmsaLDp2euGTCVyXZdgGa+oqUTkt BMbrHEHKbyZssfrzcJnzwMCAlF1Ut8CK3kJ9m92yAJlm6rHgdct9E+fjP9XM4Tuw 1EMbp5nSzAjpQvSlW8U4wxEB6/FmJVULf2iO9bCJZggFB+/k6ZfY6YgvQlSC+4A= =5rNB -----END PGP SIGNATURE----- --TdkiTnkLhLQllcMS-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 11:03:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B542719E; Fri, 10 Apr 2015 11:03:22 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CDA922E; Fri, 10 Apr 2015 11:03:22 +0000 (UTC) Received: by iget9 with SMTP id t9so12340521ige.1; Fri, 10 Apr 2015 04:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ipjR6BYI6i0KX5KleHVkXZOHvVUxcnK22SGyr/Cr6dQ=; b=ulyMyVOyzUlMJrcQnKSKDePYH7NrI1601VjRveC0jPQFYbSlbDUTzvCg5cCqEbI4IG qeUEJ1PIVnGGQQ3RzWRIe6/25uHh0se9bj9s6R7zJT25bDfzaCM8oLaTfGzZjmArfrzR Mmh4DsbpZ1LlxKSQ/PtehTi1JN5lwRfi5X9NQrAChcayPlviGgHB03cjqfHYPB1sfop4 RbQKXYbKfBSoMWpF3JOpH6jRIp7zxk2XrG4gKwWdoZsi7XkvFAEHQOK43vBkFLc8ARao t/E7J2tHRFNsYmEWQWMpA9wPCsoKyR4iPY/ORUO64VG7kmgu6gUWF88Wr9aIGA8B2ZpE Mm3w== MIME-Version: 1.0 X-Received: by 10.107.130.145 with SMTP id m17mr1451070ioi.89.1428663801815; Fri, 10 Apr 2015 04:03:21 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.36.67.139 with HTTP; Fri, 10 Apr 2015 04:03:21 -0700 (PDT) Date: Fri, 10 Apr 2015 07:03:21 -0400 X-Google-Sender-Auth: eJSSFAe4gFi88H-8Zncz_cSyl4M Message-ID: Subject: Why is backup carp node seeing traffic? From: J David To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 11:03:22 -0000 With a setup containing two carp/pf firewall/load-balancers in front of six web servers, some packets are popping up on the backup carp node. All eight machines are connected to a (fault tolerant) 10Gbit switch over dual ix connections in an LACP lagg. The carp/pf nodes use VLANs to split incoming and outgoing traffic. With some careful tcpdumping, we have identified that the problem is that every now and then (about 1 in 1000 connections), the first SYN-ACK packet from a web server is returned to the backup carp node instead of the primary. There, it gets dropped and there's a 3-second delay until the client host retransmits the SYN packet. Actually quite a bit more traffic than that winds up on the backup node, maybe as much as a few % of total traffic, but it seems like the initial SYN packet is the only one that gets dropped. This may be because pfsync hasn't created the state on the backup node yet? Here's what the tcpdump looks like from each machine, showing all the packets on the web server, all but one of the packets on the primary carp node, and the "missing" SYN-ACK packet on the backup carp node. Web server: 07:02:05.257968 IP 192.168.0.17.30892 > 192.168.80.2.80: Flags [S], seq 1377231734, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 371382342 ecr 0], length 0 07:02:05.258016 IP 192.168.80.2.80 > 192.168.0.17.30892: Flags [S.], seq 1053809273, ack 1377231735, win 0, options [mss 1460], length 0 07:02:08.254929 IP 192.168.0.17.30892 > 192.168.80.2.80: Flags [S], seq 1377231734, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 371385342 ecr 0], length 0 07:02:08.254943 IP 192.168.80.2.80 > 192.168.0.17.30892: Flags [S.], seq 1053809273, ack 1377231735, win 0, options [mss 1460], length 0 07:02:08.255332 IP 192.168.0.17.30892 > 192.168.80.2.80: Flags [.], ack 1, win 65535, length 0 07:02:08.255383 IP 192.168.80.2.80 > 192.168.0.17.30892: Flags [.], ack 1, win 65535, length 0 07:02:08.256155 IP 192.168.0.17.30892 > 192.168.80.2.80: Flags [P.], seq 1:28, ack 1, win 65535, length 27 Primary carp node: (client is identical) 07:02:05.258324 IP 192.168.0.17.30892 > 192.168.80.2.80: Flags [S], seq 1377231734, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 371382342 ecr 0], length 0 07:02:08.255287 IP 192.168.0.17.30892 > 192.168.80.2.80: Flags [S], seq 1377231734, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 371385342 ecr 0], length 0 07:02:08.255331 IP 192.168.80.2.80 > 192.168.0.17.30892: Flags [S.], seq 1053809273, ack 1377231735, win 0, options [mss 1460], length 0 07:02:08.255691 IP 192.168.0.17.30892 > 192.168.80.2.80: Flags [.], ack 1, win 65535, length 0 07:02:08.255766 IP 192.168.80.2.80 > 192.168.0.17.30892: Flags [.], ack 1, win 65535, length 0 07:02:08.256519 IP 192.168.0.17.30892 > 192.168.80.2.80: Flags [P.], seq 1:28, ack 1, win 65535, length 27 Backup carp node: 07:02:05.263024 IP 192.168.80.2.80 > 192.168.0.17.30892: Flags [S.], seq 1053809273, ack 1377231735, win 0, options [mss 1460], length 0 There are no carp failovers, interface write errors are <1/million and the error counters don't increase while the problem is happening. Switch says no errors, no LACP drops, nothing. The total traffic levels are low. This problem happens in waves, weirdly usually at low-usage times like the middle of the night. The primary carp node is ~98% idle. All the hardware checks out, and they are all physical machines, no virtualization or jails or anything going on. The logs are silent while this is happening. Six of the eight systems, including both carp nodes, are running 9.3. Two of the web servers are running 10.1. The problem does happen with all six web servers. The problem is definitely related to carp. If the default route is changed from the carp address to the master node's address on that same interface on some or all of the web servers, the problem will go away for only those servers. As soon as it's switched back, the problem returns. Similarly, running a flood ping against the carp address from a web server: $ sudo ping -c 100000 -f 192.168.80.254 PING 192.168.80.254 (192.168.80.254): 56 data bytes ......................................................... --- 192.168.80.254 ping statistics --- 100000 packets transmitted, 99944 packets received, 0.1% packet loss round-trip min/avg/max/stddev = 0.017/0.024/0.535/0.013 ms Produced exactly 56 stray ICMP echo request (100000 - 99944 = 56) on the backup server: $ sudo tcpdump -n -i vlan2 host 192.168.80.254 and icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes 10:36:34.432811 IP 192.168.80.6 > 192.168.80.254: ICMP echo request, id 22737, seq 16720, length 64 10:36:34.443833 IP 192.168.80.6 > 192.168.80.254: ICMP echo request, id 22737, seq 16721, length 64 10:36:34.454830 IP 192.168.80.6 > 192.168.80.254: ICMP echo request, id 22737, seq 16722, length 64 10:36:34.465831 IP 192.168.80.6 > 192.168.80.254: ICMP echo request, id 22737, seq 16723, length 64 [ ... etc ... ] ^C 56 packets captured 1219 packets received by filter 0 packets dropped by kernel One thing of note is that the stray packets all appear to be about 11ms apart. That pattern is consistent across all 56 packets and is repeatable. Finally, here is the ifconfig on the carp nodes, from the carp interface all the way down to the wire. Master: carp2: flags=49 metric 0 mtu 1500 inet 192.168.80.254 netmask 0xfffffff0 inet6 fd00:0:0:80::254 prefixlen 64 nd6 options=21 carp: MASTER vhid 2 advbase 1 advskew 0 vlan2: flags=8943 metric 0 mtu 1500 options=303 ether 90:e2:ba:0d:0a:98 inet 192.168.80.251 netmask 0xfffffff0 broadcast 192.168.80.255 inet6 fe80::92e2:baff:fe0d:a98%vlan2 prefixlen 64 scopeid 0xa inet6 fd00:0:0:80::251 prefixlen 64 nd6 options=21 media: Ethernet autoselect status: active vlan: 2 parent interface: lagg0 lagg0: flags=8943 metric 0 mtu 1500 options=407bb ether 90:e2:ba:0d:0a:98 inet6 fe80::92e2:baff:fe0d:a98%lagg0 prefixlen 64 scopeid 0x8 nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: ix1 flags=1c laggport: ix0 flags=1c ix0: flags=8943 metric 0 mtu 1500 options=407bb ether 90:e2:ba:0d:0a:98 inet6 fe80::92e2:baff:fe0d:a98%ix0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (10Gbase-Twinax ) status: active ix1: flags=8943 metric 0 mtu 1500 options=407bb ether 90:e2:ba:0d:0a:98 inet6 fe80::92e2:baff:fe0d:a99%ix1 prefixlen 64 scopeid 0x2 nd6 options=29 media: Ethernet autoselect (10Gbase-Twinax ) status: active Backup: carp2: flags=49 metric 0 mtu 1500 inet 192.168.80.254 netmask 0xfffffff0 inet6 fd00:0:0:80::254 prefixlen 64 nd6 options=21 carp: BACKUP vhid 2 advbase 1 advskew 150 vlan2: flags=8943 metric 0 mtu 1500 options=303 ether 90:e2:ba:0d:0a:7d inet 192.168.80.252 netmask 0xfffffff0 broadcast 192.168.80.255 inet6 fe80::92e2:baff:fe0d:a7d%vlan2 prefixlen 64 scopeid 0xa inet6 fd00:0:0:80::252 prefixlen 64 nd6 options=21 media: Ethernet autoselect status: active vlan: 2 parent interface: lagg0 lagg0: flags=8943 metric 0 mtu 1500 options=407bb ether 90:e2:ba:0d:0a:7d inet6 fe80::92e2:baff:fe0d:a7d%lagg0 prefixlen 64 scopeid 0x8 nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: ix0 flags=1c laggport: ix1 flags=1c ix0: flags=8943 metric 0 mtu 1500 options=407bb ether 90:e2:ba:0d:0a:7d inet6 fe80::92e2:baff:fe0d:a7c%ix0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (10Gbase-Twinax ) status: active ix1: flags=8943 metric 0 mtu 1500 options=407bb ether 90:e2:ba:0d:0a:7d inet6 fe80::92e2:baff:fe0d:a7d%ix1 prefixlen 64 scopeid 0x2 nd6 options=29 media: Ethernet autoselect (10Gbase-Twinax ) status: active Why are packets showing up at the backup node? Why is it intermittent? Can anything be done to eliminate this issue? Thanks for any advice! From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 11:11:23 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E2ED41A for ; Fri, 10 Apr 2015 11:11:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7A462CE for ; Fri, 10 Apr 2015 11:11:22 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3ABBMY1055068 for ; Fri, 10 Apr 2015 11:11:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Date: Fri, 10 Apr 2015 11:11:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sebastian.huber@embedded-brains.de X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 11:11:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 sebastian.huber@embedded-brains.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian.huber@embedded-br | |ains.de --- Comment #16 from sebastian.huber@embedded-brains.de --- I see this problem also with the port of the FreeBSD 9-stable (2015-04-09) network stack to the RTEMS real-time operating system (Altera Cyclone V target). It occurs quite frequently with multiple concurrent IPv4 TCP transfers to /dev/null and from /dev/zero. The stack trace is: 000|panic(fmt = 0x00636E14) 001|sbsndptr(?, ?, ?, ?) 002|tcp_output(?) 003|tcp_do_segment(?, ?, so = 0x3FF3D7C0, tp = 0x3FF2F828, drop_hdrlen = 52, tlen = 0, iptos = 0, ?) 004|tcp_input(m = 0x3FF21700, ?) 005|ip_input(m = 0x3FF21700) 006|netisr_dispatch_src(?, ?, ?) 007|ether_demux(ifp = 0x006DFEE0, m = 0x3FF21700) 008|ether_nh_input(?) 009|netisr_dispatch_src(?, ?, ?) 010|dwc_rxfinish_locked(inline) 010|dwc_intr(arg = 0x006DEA20) 011|bsp_interrupt_server_task(?) 012|Thread_Handler() ---|end of frame -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 11:33:31 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DCB8B3E for ; Fri, 10 Apr 2015 11:33:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 534BC7C6 for ; Fri, 10 Apr 2015 11:33:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3ABXVjk076591 for ; Fri, 10 Apr 2015 11:33:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Date: Fri, 10 Apr 2015 11:33:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rwatson@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 11:33:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 --- Comment #17 from Robert Watson --- sbdrop() performs invariant checks as it tears down a socket buffer on final close -- originally intended to validate a set of values cached by the socket buffer that could (in the presence of a socket-buffer bug) get out of sync with the chain stored there. However, these checks have proven something of a 'canary' for many possible underlying bugs involving mbuf chains and socket buffers. I've seen the panics most frequently in the presence of device-driver concurrency bugs -- e.g., in which a driver makes changes to the mbuf chain after handing the mbuf off to the network stack via netisr, for example, or involving improper freeing of an mbuf by other code while it remains referenced by a socket buffer. Others have spotted them in the presence of other classes of network-stack race conditions -- most involving a failure to have a single thread or object own an mbuf. As such, seeing this panic is a symptom of many possible underlying problems and hence not a specific 'bug' per se. However, as a useful rule of thumb: when I spot this panic, I look first at the device driver to make sure that there is no possible use of mbuf after it is passed as an argument to netisr. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 11:47:23 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C728F93 for ; Fri, 10 Apr 2015 11:47:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 620A48FF for ; Fri, 10 Apr 2015 11:47:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3ABlN8J086833 for ; Fri, 10 Apr 2015 11:47:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Date: Fri, 10 Apr 2015 11:47:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sebastian.huber@embedded-brains.de X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 11:47:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 --- Comment #18 from sebastian.huber@embedded-brains.de --- (In reply to Robert Watson from comment #17) Thanks for the warning. The driver looks all right. I update yesterday from FreeBSD 9.3 to 9-stable 2015-04-09 since previously I had other problems. For example a NULL pointer dereference in tcp_reass() (I guess the temporary stack element remained on the list and was overwritten in a second call) and a corruption of a UMA keg (mbuf_packet zone). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 15:28:43 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 497CEE98; Fri, 10 Apr 2015 15:28:43 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 E9CBB874; Fri, 10 Apr 2015 15:28:42 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id t3AFSfwr056215; Fri, 10 Apr 2015 08:28:41 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id t3AFSfsT056214; Fri, 10 Apr 2015 08:28:41 -0700 (PDT) (envelope-from david) Date: Fri, 10 Apr 2015 08:28:41 -0700 From: David Wolfskill To: mobile@freebsd.org Subject: Recognizing & using a Broadcom wireless mini-PCI card? Message-ID: <20150410152841.GI15644@albert.catwhisker.org> Reply-To: net@freebsd.org, mobile@freebsd.org, David Wolfskill MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0OkqknLvuh6i3jtt" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 15:28:43 -0000 --0OkqknLvuh6i3jtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable My current laptop (Dell Precision M4800) mostly works well under FreeBSD; one of its shortcomings is that the wireless card with which it came shows up as : none1@pci0:3:0:0: class=3D0x028000 card=3D0x00171028 chip=3D0x43b114e= 4 rev=3D0x03 hdr=3D0x00 vendor =3D 'Broadcom Corporation' class =3D network After reading bwn(4) a bit, I had thought/hoped that perhaps the lack of recognition of the device was because I hadn't loaded the kernel mo= dules that bwn(4) cited. So I tried inserting: if_bwn_load=3D"YES" # siba_bwn_load=3D"YES" bwn_v4_lp_ucode_load=3D"YES" bwn_v4_ucode_load=3D"YES" into /boot/loader.conf & rebooting (to ensure that the modules were present as early as possible... no joy: the above was obtained after such a reboot. As a circumvention, I've swpped the iwn(4) card in from my revious laptop, but it's not exactly ideal, either. How might I help get the above-described Broadcom device functional in a FreeBSD environment? Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --0OkqknLvuh6i3jtt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVJ+wpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk75a0P/2nW4BfTujrVafwuh4WnERm6 9glPdcCB37ZG4h/GRDJV4nF5nynurIOGU4nYSy8FAIjLKEmqQv9zaCSMclK4L8Cb 1y7XX11xdkBAp/pZgqAJwUewh7Sgq6zTBlAMj3IqljooHzEbLFK6GWtC4rIWpFcH kbci2K3Ub+0mA8TCpHUk3FdX5BGAxlRvlMedmCYqjGbOA5cg9eo5X55al5+Tsmb1 8zLDu/9+ud/CNbTyKpOwjaJgzFGjfjfPIbK5uQBur6Ya+Djdf8WtdTqqFNNjhbN2 RRyCwc9wUbXZ3KyQnDDVTcBEa1S3QnzgbsUiTMiqPsCauZzm+PpYgQboMdpIxKWl 3lPzLYGzmkVw7VLbgoRs5okbwWlfFXI/ADZy2QDrUmzCdAbHFWsas8GWwnP6aUr/ SVxSKFgPaHoMc3OCTekjS3L2nnWy76YWJh7h4o2QKv+AIgwSASBkkI5A5rmkBDwe k6AZ0irUVUDDKt6LnBH18Vbv1Bsh0kKtyC9x7EaQdJnrJN95IuwsDzpecN+DFHp/ tsfCGmbF/ApIDLx5BVfmYG0BiL2ezLOYf+gW/chmFmlG0odTETPiWHhDBdfmstEg TDYI5RtcjYPrv+R0VBYT1d1Ula7NyVrJ+eWoQ5QiwS/+IubRKdzwu0dcesuy4wkn 1h81XmxFBIe9sYaj/Jj5 =pyn/ -----END PGP SIGNATURE----- --0OkqknLvuh6i3jtt-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 15:48:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4DA4650; Fri, 10 Apr 2015 15:48:06 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F8B9B55; Fri, 10 Apr 2015 15:48:06 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so1152250igb.1; Fri, 10 Apr 2015 08:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=mIO7gwiJhU+0RVpOw2abRRNRPcY7zj3wUV/I7pfZU8w=; b=E1QG6mFQm9qTNwp1JJEuJsVCB65DdFhJ1mb2Dqnoatbqa13Flx2dJHN6qs7Cf1alyb wR2SPiKucbNa/aFm50DbKTth8ENn2/rivkRdwLmjLWeA3C0/Z/5ViMJlihYxgZbKvOuW 04tpazsJs4su+yphRrP7Fx4w6J7C4Pjt9H2RvtMcqrphhn7y77LLEnZH/BHpNaEaaR4z Yax5wuj2bsdtN3r/sFQvFddfvzu0MKDZrX7q7ZZBGfzh/IfMvPYEuKywTTNGogyiPgyC 20UywolBRZ/fZr9cLCtPq0XUNhXx7RVKwn0OcXU6iGV1BNqxJdWkN1PHpwrZc6jgeXsY Zzyw== MIME-Version: 1.0 X-Received: by 10.42.119.142 with SMTP id b14mr4502945icr.29.1428680885753; Fri, 10 Apr 2015 08:48:05 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.36.67.139 with HTTP; Fri, 10 Apr 2015 08:48:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Apr 2015 11:48:05 -0400 X-Google-Sender-Auth: sKZiDtAYXeQ_Mo_dLNJ_wBeLCRY Message-ID: Subject: Re: Why is backup carp node seeing traffic? From: J David To: freebsd-net@freebsd.org, "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 15:48:06 -0000 On Fri, Apr 10, 2015 at 7:03 AM, J David wrote: > Why are packets showing up at the backup node? Why is it > intermittent? Can anything be done to eliminate this issue? To follow up on this, I think I have identified the problem behavior. Here is a tcpdump of carp traffic seen by the web test client (on vlan4): $ sudo tcpdump -e -i net0 -n carp and ether src 00:00:5e:00:01:04 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on net0, link-type EN10MB (Ethernet), capture size 65535 bytes 15:20:36.659743 00:00:5e:00:01:04 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.0.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 4, prio 0, authtype none, intvl 1s, length 36 15:20:37.660173 00:00:5e:00:01:04 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.0.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 4, prio 0, authtype none, intvl 1s, length 36 15:20:38.660787 00:00:5e:00:01:04 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.0.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 4, prio 0, authtype none, intvl 1s, length 36 15:20:39.661177 00:00:5e:00:01:04 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.0.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 4, prio 0, authtype none, intvl 1s, length 36 15:20:40.661614 00:00:5e:00:01:04 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.0.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 4, prio 0, authtype none, intvl 1s, length 36 15:20:41.662149 00:00:5e:00:01:04 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.0.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 4, prio 0, authtype none, intvl 1s, length 36 15:20:42.662593 00:00:5e:00:01:04 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.0.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 4, prio 0, authtype none, intvl 1s, length 36 This is exactly what one would expect to see: carp advertisements only from the master node, every 1 second, like clockwork. Now, here is a tcpdump of carp traffic seen by the web server (on vlan2, where the problem is seen): $ sudo tcpdump -e -n -i vlan2 carp and ether src 00:00:5e:00:01:02 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes 15:22:24.946405 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36 15:22:25.946910 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36 15:22:26.947406 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36 15:22:27.299658 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 240, authtype none, intvl 1s, length 36 15:22:27.947905 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36 15:22:28.948407 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36 15:22:29.948906 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36 15:22:30.692661 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 240, authtype none, intvl 1s, length 36 As before, the master is advertising once per second, like clockwork. Yet every few seconds, the backup advertises itself anyway, using the carp interface MAC to do it. It seems certain that this causes the switch to decide that MAC has now moved to the backup's switch port, so it sends traffic there until the next packet arrives with this source address from the master, switching it back. tcpdump run on the backup shows that it is receiving the advertisements from the master just fine, then acting like it didn't: $ sudo tcpdump -e -n -i vlan2 carp and ether src 00:00:5e:00:01:02 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes 15:27:22.099936 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36 15:27:22.099938 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 0, authtype none, intvl 1s, length 36 15:27:22.495786 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 240, authtype none, intvl 1s, length 36 The web server shows that the "leaking" advertisements from the backup happen every 3.2 seconds: $ sudo tcpdump -c 4 -e -n -i vlan2 carp and ether src 00:00:5e:00:01:02 and host 192.168.80.252 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes 15:34:33.547068 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 240, authtype none, intvl 1s, length 36 15:34:36.745077 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 240, authtype none, intvl 1s, length 36 15:34:39.943078 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 240, authtype none, intvl 1s, length 36 15:34:43.141084 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 240, authtype none, intvl 1s, length 36 4 packets captured 13788 packets received by filter 0 packets dropped by kernel That is with advskew=0 on the master and advskew=50 on the backup. Setting advskew=250 on the backup increases the interval to 3.98 seconds: $ sudo tcpdump -c 4 -e -n -i vlan2 carp and ether src 00:00:5e:00:01:02 and host 192.168.80.252 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes 15:36:05.363113 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 250, authtype none, intvl 1s, length 36 15:36:09.342124 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 250, authtype none, intvl 1s, length 36 15:36:13.321122 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 250, authtype none, intvl 1s, length 36 15:36:17.300134 00:00:5e:00:01:02 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 192.168.80.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 2, prio 250, authtype none, intvl 1s, length 36 4 packets captured 19658 packets received by filter 0 packets dropped by kernel So, the carp backup leaks packets at the rate of exactly 3 seconds + the advskew interval (1s * advskew/255). And in fact the logs on the carp backup do indicate that it thinks it's doing the world a favor. It's full of: Apr 10 15:44:53 fw2 kernel: carp2: link state changed to UP Apr 10 15:44:53 fw2 kernel: carp2: MASTER -> BACKUP (more frequent advertisement received) Apr 10 15:44:53 fw2 kernel: carp2: link state changed to DOWN Apr 10 15:44:57 fw2 kernel: carp2: link state changed to UP Apr 10 15:44:57 fw2 kernel: carp2: MASTER -> BACKUP (more frequent advertisement received) Apr 10 15:44:57 fw2 kernel: carp2: link state changed to DOWN Apr 10 15:45:00 fw2 kernel: carp2: link state changed to UP Apr 10 15:45:00 fw2 kernel: carp2: MASTER -> BACKUP (more frequent advertisement received) Apr 10 15:45:00 fw2 kernel: carp2: link state changed to DOWN (Unfortunately I was only looking at the master's logs before. :( ) Does this shed any light on why this might be happening? Thanks! From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 16:27:01 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4C6461A; Fri, 10 Apr 2015 16:27:01 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AAC0DB; Fri, 10 Apr 2015 16:27:01 +0000 (UTC) Received: by igblo3 with SMTP id lo3so2119115igb.1; Fri, 10 Apr 2015 09:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=AvK2vIdJWEMNCY/Vqzx/gBlaPcgJU0D2Nou2JduQNlQ=; b=R5R30AV0Iky+VEeDLZ4wEQ016inHympJ71+QzePOZdw+WlyjbjsAuXhK9e++YMV9Sy ECqkzuSPJTDyy1Z3Gxw+v715pIBuDxuMB7dwV4poeY9nj99YlbBiCbQmpiPwtW+nCXr3 wDvtrPBtmW1gRLwXYr9hHvpRxSLl4vSCGFsYYuwtMHN4/EpFn8Xuz8q6DYjvjlRApSoo xkKZhrgYCQjvAT0agEsOArS9PSEBkPT3Qvx7ABsrfWimQuhcl9FzJrtBBZ+9ISivNHnv E5uPkFQIhEHFCaHG75k6aLTXB4Fjaak1MM0CVxXWPitTqPsnz6mG/G5j2N723C4woDTM DS5A== MIME-Version: 1.0 X-Received: by 10.50.57.36 with SMTP id f4mr19411461igq.6.1428683221103; Fri, 10 Apr 2015 09:27:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Fri, 10 Apr 2015 09:27:01 -0700 (PDT) In-Reply-To: <20150410152841.GI15644@albert.catwhisker.org> References: <20150410152841.GI15644@albert.catwhisker.org> Date: Fri, 10 Apr 2015 09:27:01 -0700 X-Google-Sender-Auth: sbuCD1VPL5M1wTyRQPzhNY9XLlk Message-ID: Subject: Re: Recognizing & using a Broadcom wireless mini-PCI card? From: Adrian Chadd To: "net@freebsd.org" , "freebsd-mobile@freebsd.org" , David Wolfskill Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 16:27:02 -0000 Hi, Someone has to maintain / update the broadcom wifi drivers. Sorry :( -a On 10 April 2015 at 08:28, David Wolfskill wrote: > My current laptop (Dell Precision M4800) mostly works well under > FreeBSD; one of its shortcomings is that the wireless card with which it > came shows up as : > > none1@pci0:3:0:0: class=0x028000 card=0x00171028 chip=0x43b114e4 rev=0x03 hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > > After reading bwn(4) a bit, I had thought/hoped that perhaps the > lack of recognition of the device was because I hadn't loaded the kernel modules that bwn(4) cited. So I tried inserting: > > if_bwn_load="YES" > # siba_bwn_load="YES" > bwn_v4_lp_ucode_load="YES" > bwn_v4_ucode_load="YES" > > into /boot/loader.conf & rebooting (to ensure that the modules were > present as early as possible... no joy: the above was obtained after > such a reboot. > > As a circumvention, I've swpped the iwn(4) card in from my revious > laptop, but it's not exactly ideal, either. > > How might I help get the above-described Broadcom device functional > in a FreeBSD environment? > > Thanks! > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Those who murder in the name of God or prophet are blasphemous cowards. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-net@FreeBSD.ORG Fri Apr 10 21:17:20 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B27A4C7 for ; Fri, 10 Apr 2015 21:17:20 +0000 (UTC) Received: from mail.afubra.com.br (mail.afubra.com.br [200.180.137.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2809989A for ; Fri, 10 Apr 2015 21:17:19 +0000 (UTC) Received: by mail.afubra.com.br (Postfix, from userid 99) id 9298D5B6D9F; Fri, 10 Apr 2015 18:09:26 -0300 (BRT) To: net@freebsd.org Subject: Notice to Appear Date: Fri, 10 Apr 2015 18:09:26 -0300 From: "State Court" Reply-To: "State Court" Message-ID: <3c75a7c6e48eba7574cb053f4d7cfd5a@mail.afubra.com.br> X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:17:20 -0000 Notice to Appear, You have to appear in the Court on the April 19. You are kindly asked to prepare and bring the documents relating to the case to Court on the specified date. Note: The case may be heard by the judge in your absence if you do not come. You can review complete details of the Court Notice in the attachment. Yours faithfully, Duane Savage, Clerk of Court. From owner-freebsd-net@FreeBSD.ORG Sat Apr 11 15:06:00 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AD1833C; Sat, 11 Apr 2015 15:06:00 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4F55BE4D; Sat, 11 Apr 2015 15:05:58 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|opaldns Received: from smtp6.ore.mailhop.org (ip-10-229-11-165.us-west-2.compute.internal [10.229.11.165]) by relay.mailchannels.net (Postfix) with ESMTPA id 17940100404; Sat, 11 Apr 2015 14:30:34 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|opaldns Received: from smtp6.ore.mailhop.org ([TEMPUNAVAIL]. [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Sat, 11 Apr 2015 14:30:34 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|opaldns X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1428762634231:1929163759 X-MC-Ingress-Time: 1428762634231 Received: from pool-71-255-171-111.bstnma.east.verizon.net ([71.255.171.111] helo=homobox.opal.com) by smtp6.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YgwQW-0003VD-FR; Sat, 11 Apr 2015 14:30:28 +0000 Received: from shibato (ip51cd975c.adsl-surfen.hetnet.nl [81.205.151.92]) (authenticated bits=0) by homobox.opal.com (8.14.9/8.14.9) with ESMTP id t3BEULe1054319 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Sat, 11 Apr 2015 10:30:23 -0400 (EDT) (envelope-from fbsd@opal.com) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 71.255.171.111 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1/2DwNzhriximH8sd9eG7XL Date: Sat, 11 Apr 2015 16:30:09 +0200 From: "J.R. Oldroyd" To: Kevin Oberman Subject: Re: [BUG?] dhclient sends packets with source IP address that has been deleted Message-ID: <20150411163009.76078f44@shibato> In-Reply-To: <20150409104017.0cd5c909@shibato> References: <55234B74.5020506@rawbw.com> <20150407145354.GA9746@spindle.one-eyed-alien.net> <20150408100349.31a74103@shibato> <20150409104017.0cd5c909@shibato> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/B64G8MnCde4ozdB4jB3yO0Y"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (homobox.opal.com [71.255.171.111]); Sat, 11 Apr 2015 10:30:25 -0400 (EDT) X-Spam-Status: No, score=4.1 required=5.0 tests=AWL,BAYES_50, FSL_HELO_NON_FQDN_1,RCVD_IN_PBL shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on homobox.opal.com X-AuthUser: opaldns Cc: Yuri , Brooks Davis , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 15:06:00 -0000 --Sig_/B64G8MnCde4ozdB4jB3yO0Y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 9 Apr 2015 10:40:17 +0200 "J.R. Oldroyd" wrote: > >=20 > The fix appears to be pretty trivial: I have submitted PR 199378 with this patch. -jr --Sig_/B64G8MnCde4ozdB4jB3yO0Y Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUpL/YACgkQls33urr0k4nAzwCgjkLPWxGI79KvMDyBOi//SJR0 WWYAnRqVSSFLEVyeOu19W0VU3MXp7qJv =pPy5 -----END PGP SIGNATURE----- --Sig_/B64G8MnCde4ozdB4jB3yO0Y--