From owner-freebsd-net@FreeBSD.ORG Sun Oct 26 18:11:52 2014 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 E85681A5 for ; Sun, 26 Oct 2014 18:11:52 +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 CEE8E638 for ; Sun, 26 Oct 2014 18:11:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9QIBqYB022859 for ; Sun, 26 Oct 2014 18:11:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194453] [dummynet] pipe config bw parameter is limited to 2Gbits per second Date: Sun, 26 Oct 2014 18:11:53 +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.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: boba@boba.name X-Bugzilla-Status: In Discussion 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: Sun, 26 Oct 2014 18:11:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #8 from boba@boba.name --- > By that i mean the following: > First of all change the internals of dummynet to opportunistically > check the timer whenever there is traffic, rather than relying on > a one-tick granularity. When dummynet was first implemented the timer > was the 8254, reading it took forever, and 250-1000us granularity was > adequate for the <10Mbit/s range it was meant to emulate. > > Second, the default parameters (1ms, 50 slots queue) limit the capacity of > a pipe to some 600 Mbit/s with 1500-byte packets. Probably the code should > print warnings if queue_capacity/tick is too far from the desired rate. > > Third, the bandwidth value is internally multiplied by other factor > in the execution of the scheduling algorithms. If you bump the data type > from 31 to 32 or 64 bits, you also need to check that the other computations > do not overflow. > > In any case if you decide to go through this route please pass the code > by me for review before committing. -- luigi As I understood, this new framework in FreeBSD now can handle 10GB of traffic (http://info.iet.unipi.it/~luigi/netmap/) and supports pipes and dummynet. Is it production-stable ? Is there some sort of "how-to" on how to use it ? boba. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun Oct 26 20:58:42 2014 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 A4D1FF79 for ; Sun, 26 Oct 2014 20:58:42 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla.connectionlost.com.br [131.72.200.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Tiago Felipe Gon????alves", Issuer "Tiago Felipe Gon????alves" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 529D7683 for ; Sun, 26 Oct 2014 20:58:41 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla [131.72.200.69]) by valhalla.connectionlost.com.br (Postfix) with ESMTP id 276CAB2B2C for ; Sun, 26 Oct 2014 18:52:23 -0200 (BRST) Authentication-Results: valhalla.connectionlost.com.br; dkim=pass reason="1024-bit key" header.d=connectionlost.com.br header.i=@connectionlost.com.br header.b=WiI73yvS; dkim-adsp=pass Received: from [192.168.0.69] (unknown [186.250.58.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by valhalla.connectionlost.com.br (Postfix) with ESMTPSA id 33331B2A6D for ; Sun, 26 Oct 2014 18:52:22 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=connectionlost.com.br; s=valhalla; t=1414356742; bh=ppxDag+tU7ACpWL2+WcQxbH5TIQHBkLz4rHHvcb9ByA=; h=Date:From:To:Subject; b=WiI73yvS05B9rS6iiqkGpFggNjvDxWSrVA/FNCbu22vV7VurK1QsrxB82juMm/Dhx fRHKu5jB0k0PI014X8hKrR29VwY+/6zMyCOHmJi3E77dxBCC2J6w4cBL0MipaeOQfe z9fgSh3MX5V2TqwAUCTpx2/zYkF8vQF+AgO22Uvw= Message-ID: <544D5EF6.3080207@connectionlost.com.br> Date: Sun, 26 Oct 2014 18:52:06 -0200 From: Tiago Felipe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: dropped due to the socket Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eReWnswwUufq55nwfKqFWxIm8FfRhhPNM" X-Virus-Scanned: ClamAV using ClamSMTP 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, 26 Oct 2014 20:58:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eReWnswwUufq55nwfKqFWxIm8FfRhhPNM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Good afternoon! I have seen "dropped due to the socket" on multiple servers with Freebsd, this case is a Release 10. # Netstat -s -s =2E.. 4614884 dropped due to the socket =2E.. In this case the current flow is 700mbits download and 80mbits upload, averaging 130kpps. I've done many changes in sysctl.conf and loader.conf, swapped hardware and have not had many improvements. Can anyone tell me the reason? I'm looking for it to weeks, but still no result. Thank you so much. --=20 []s --eReWnswwUufq55nwfKqFWxIm8FfRhhPNM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUTV73AAoJEMR7HC7H8wTJMoIP/3nZ5Df5I15WUZqUSrd4KnDq Qh2VXMnn/HVIDB5D7fXw6/xG9wyUzRRxPtqG5rE86DTLb8iXzvOsizBZPCUF1CLI JmS5uEZABHHZxD6GfvqtseFhuCux/rgxrZDiAqXlPrLiUt5QrB5+4ws6NC5WOvr6 Lq2+Jkd9/l1yvLzuH1RwEYg07wT6KCPdEwlxjaPp0PQlvWBki4qh2Wh7vaupObRk FKp4D/wBerkSC2AczxuNmtdSE6OLwGbN9WZsum+SYU9pSahX46/DdO8OmPLmfShT K0aj4QqJko+p8f9FpHRp6YcdviZMmx0C0ylaE0h4o2/CKeIdD+ZMTI+WssgLGtri yYzaqBPsKe71NRDvz0ZtNX4PST6glrWQw0PbvAZ1sI19ddZGr4Px8rzjUp2kV1fn CLKNjxbVysHR+87qcAsit6nwtun++VJyXTdedUUVB6fOp0yx78fGZESqaIIrBLxg F8FtD36QYWHu2owhAi9Z8eHUwJFotbrzyTBWCYOHddEUqBY0nxXNcSaGCqPosXZx hGn50IiVaKVwYc/wMBn2UtnyaMznhgukCdqGWV74b1g4/GGIXf2ufzqy56PLtLWv QebEyPhj4kQRHJs0bRjBsPx5fEQe3oBpQAYd3bcAzoRzw/Ms/x/1QL07cImp665M DWOPrpRWVAY4qEDnN6dQ =fuBV -----END PGP SIGNATURE----- --eReWnswwUufq55nwfKqFWxIm8FfRhhPNM-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 11:01:08 2014 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 EB43983D for ; Mon, 27 Oct 2014 11:01:08 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla.connectionlost.com.br [131.72.200.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Tiago Felipe Gon????alves", Issuer "Tiago Felipe Gon????alves" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BA8F1D3 for ; Mon, 27 Oct 2014 11:01:08 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla [131.72.200.69]) by valhalla.connectionlost.com.br (Postfix) with ESMTP id 949E2B1653 for ; Mon, 27 Oct 2014 09:00:54 -0200 (BRST) Authentication-Results: valhalla.connectionlost.com.br; dkim=pass reason="1024-bit key" header.d=connectionlost.com.br header.i=@connectionlost.com.br header.b=x3kuNT/h; dkim-adsp=pass Received: from [186.250.58.220] (unknown [186.250.58.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by valhalla.connectionlost.com.br (Postfix) with ESMTPSA id F3349B167A for ; Mon, 27 Oct 2014 09:00:53 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=connectionlost.com.br; s=valhalla; t=1414407654; bh=jBcZ63qub+N77Swm7PrjpzAn+HBum2fA2W7KYBerE6M=; h=Date:From:To:Subject; b=x3kuNT/h7WNHWeNx697NLMNl7C8doy+y0Hlre7N3tsRow+n1JWPQHZZeN4dZWJq8k vfdaD4CGspUSdBuMz/+O9zKXBvbBD6sJwiKfCfrxuLq/fiOen5dbOqAJz8noYCvRGD DHpXWFdgDM6fxAfQW2xWL2tzH2WpoOmYF++cG//c= Message-ID: <544E25E1.8060202@connectionlost.com.br> Date: Mon, 27 Oct 2014 09:00:49 -0200 From: Tiago Felipe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: dropped due to the socket Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SCPVpuisuG4R98ANiSiMNp25T1nnICPI3" X-Virus-Scanned: ClamAV using ClamSMTP 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, 27 Oct 2014 11:01:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SCPVpuisuG4R98ANiSiMNp25T1nnICPI3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Good afternoon! I have seen "dropped due to the socket" on multiple servers with Freebsd, this case is a Release 10. # Netstat -s -s =2E.. 4614884 dropped due to the socket =2E.. In this case the current flow is 700mbits download and 80mbits upload, averaging 130kpps. I've done many changes in sysctl.conf and loader.conf, swapped hardware and have not had many improvements. Can anyone tell me the reason? I'm looking for it to weeks, but still no result. Thank you so much. --=20 []s --SCPVpuisuG4R98ANiSiMNp25T1nnICPI3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUTiXmAAoJEMR7HC7H8wTJpbAP/iAa8Ysq3WdfrBpX44NCwf8T cXyhDNhkbCpBNUD2OCplpNBfdaGL37n3rKbaWyUH6RujwIt8zb3aZyaWjhr1oYVi SICWK8wjY9Rdsv5/iD9OhI8JiezImM8s0kA/CA/UJMuCUTFrSGFxqGZcUTRNN1IC 1wILk7kV1HChRFyNgZVZeT/ytyLRumKo2xwsF4LYYdv0vHPQzHG8YFXugKiXE2Qo lNWZ8/0++jGqxxJY80jfJq8B/3GnAnr8GmqCrwsVkFBOekNUbph5BlPlXhh6iuPo F5gtaQGVuFHwgzu46pKB38FEOtePfceq4uT2AcmgpWao5rIF6pQJTeXl2FxghWpu sWOcFAUvxpcI7M33DMeNeqju2zAbL9KSdmaipW2PYoZUhyGJzj6Bk4cTNdhAnMS6 k0Y2oLN5mG5D64O0UqJaWhMlhAsgQsA50Y/Vn06VrCwTG4dGh6TKZRy7d8CfTVzQ 98HuAxRaE9KV9V/epyXOv2GbB7u/0FbqOUrGO2VE/k0nx1g9TDY86TmKX9YPj+FU jKpjE/uPfvRcl9mUK2HLkIpiTmuNa5Fd/5/gVIQJCx/JkK3DrhPE5V2t3tWiA2NP kAUssyGRs62oZYjxbfifxyNPGIKI5vS2+rUen7+hdA3WBdzJM946h8FYHnLWUPAZ b/BOubkxigJn5m8C7ckp =fdhd -----END PGP SIGNATURE----- --SCPVpuisuG4R98ANiSiMNp25T1nnICPI3-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 11:19:52 2014 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 45BE0DB for ; Mon, 27 Oct 2014 11:19:52 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB5E63E for ; Mon, 27 Oct 2014 11:19:51 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id CD0FF20E7088B; Mon, 27 Oct 2014 11:19:43 +0000 (UTC) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id C0C6A20E70886 for ; Mon, 27 Oct 2014 11:19:43 +0000 (UTC) Message-ID: <544E2ACD.6060901@multiplay.co.uk> Date: Mon, 27 Oct 2014 11:21:49 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: dropped due to the socket References: <544E25E1.8060202@connectionlost.com.br> In-Reply-To: <544E25E1.8060202@connectionlost.com.br> Content-Type: text/plain; charset=utf-8; format=flowed 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, 27 Oct 2014 11:19:52 -0000 I assume you mean "dropped due to *no *socket" which means your seeing requests to a port which isn't open, possibly due to being port scanned? On 27/10/2014 11:00, Tiago Felipe wrote: > Good afternoon! > > I have seen "dropped due to the socket" on multiple servers with > Freebsd, this case is a Release 10. > # Netstat -s -s > ... > 4614884 dropped due to the socket > ... > > In this case the current flow is 700mbits download and 80mbits upload, > averaging 130kpps. > > I've done many changes in sysctl.conf and loader.conf, swapped hardware > and have not had many improvements. > > Can anyone tell me the reason? I'm looking for it to weeks, but still no > result. > > > Thank you so much. > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 11:31:12 2014 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 8D59779C for ; Mon, 27 Oct 2014 11:31:12 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla.connectionlost.com.br [131.72.200.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Tiago Felipe Gon????alves", Issuer "Tiago Felipe Gon????alves" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 11B2280B for ; Mon, 27 Oct 2014 11:31:11 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla [131.72.200.69]) by valhalla.connectionlost.com.br (Postfix) with ESMTP id D1532B19C3 for ; Mon, 27 Oct 2014 09:31:08 -0200 (BRST) Authentication-Results: valhalla.connectionlost.com.br; dkim=pass reason="1024-bit key" header.d=connectionlost.com.br header.i=@connectionlost.com.br header.b=OrYA5Gx2; dkim-adsp=pass Received: from [186.250.58.220] (unknown [186.250.58.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by valhalla.connectionlost.com.br (Postfix) with ESMTPSA id 498C3B167A for ; Mon, 27 Oct 2014 09:31:08 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=connectionlost.com.br; s=valhalla; t=1414409468; bh=vr4h7ncjGiGJs6eLC8S2X47+VQttgm3Qo5AskO4VKpk=; h=Date:From:To:Subject:References:In-Reply-To; b=OrYA5Gx2vWlKnFHtQqxQRHk1LQglzZmn6+l192zwh82tsBNucK4tKZzP7P39eLGVN x4Rnpe9GiGfRAfTE+GN83TO4SSLvFS4WjiHFh8atnaSxcc/CpONrYfKpRU5h1WZYzT I7dzjvxIUzgS7A6r47NvIQkejs1M20xaOlnnwNMI= Message-ID: <544E2CF8.3090208@connectionlost.com.br> Date: Mon, 27 Oct 2014 09:31:04 -0200 From: Tiago Felipe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: dropped due to the socket References: <544E25E1.8060202@connectionlost.com.br> <544E2ACD.6060901@multiplay.co.uk> In-Reply-To: <544E2ACD.6060901@multiplay.co.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fNX7w9sGG4oIXpmKDJuudL3cRp9xsIjpo" X-Virus-Scanned: ClamAV using ClamSMTP 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, 27 Oct 2014 11:31:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fNX7w9sGG4oIXpmKDJuudL3cRp9xsIjpo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Maybe, but do not believe it, because when you turn it on, the counter "dropped due to the socket" has gradually increased, this machine acts as pppoe concentrator, mpd5 and netgraph .. I have clients with public IP and nat44. I'm doing tests yet, but I've read a lot about and looked for similar problems, could not come to a conclusion ... Thank you On 27/10/14 09:21, Steven Hartland wrote: > I assume you mean "dropped due to *no *socket" which means your seeing > requests to a port which isn't open, possibly due to being port scanned= ? >=20 > On 27/10/2014 11:00, Tiago Felipe wrote: >> Good afternoon! >> >> I have seen "dropped due to the socket" on multiple servers with >> Freebsd, this case is a Release 10. >> # Netstat -s -s >> ... >> 4614884 dropped due to the socket >> ... >> >> In this case the current flow is 700mbits download and 80mbits upload,= >> averaging 130kpps. >> >> I've done many changes in sysctl.conf and loader.conf, swapped hardwar= e >> and have not had many improvements. >> >> Can anyone tell me the reason? I'm looking for it to weeks, but still = no >> result. >> >> >> Thank you so much. >> >> >=20 > _______________________________________________ > 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" --=20 []s --fNX7w9sGG4oIXpmKDJuudL3cRp9xsIjpo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUTiz8AAoJEMR7HC7H8wTJ1owP/352eFneInLAtGqeKwJndJfy vc4CTLe7t3UsOaRgrlr8KwC/FPek6sVP4UrHUUABAPyQUs9oIDlk7iC5vgNUtqZD eu93TcRvlk7fcCOXXCPoQpjniPOeEwApMVLpAkAx4UjXvRIz7D14/8bVck1cydCw MHm/rTRGnfRrOO43yTgIHhPF86FkLfTzaFE7yo+Y6Pg4v0D4q0IIvhGThoYnGwlj eQHXX82i2Wue/We9qzAae0bV1NTb4jEEoie0j6eWFTkgerVp4RSddzht6Y3nKIeJ ATh1ymQd9GU/PJGLEh2IE2a7rurBTF/YRM8ySbuz1gaaRY9yjPmj/9gbkqM2H9H1 kisPheceXwrKI0DnO5S3bgoBQisAsOcYfDC8XNo8sW+6h6LEtRDtkWlFN34EQ9Cg mxY1UKKDfrjQGcSSouq/s9Q706yWO7BqZ9jnOAGJhP7n5+0EI2QyOFDuvnNNPwqL WNCT1/dAUJp4TFf6n+Oa5lsOdijHrDrOUZCLV2Zq7XeTn3bQHFZhEmZbCob05wcY iA9CnnpktD3sH16A6bjDjrqmr2+4yWf/PQ4pVGN1zDH2ijlKpkQkP8TkPNQV/Ue5 jbYXt6pqVPkXJnizxBbI21v1LCAua5zSP6eUuG+6uB4ply4h9CW4Yr++nXFCeBMx vgMmXr84+w05sxScgUP2 =DMwK -----END PGP SIGNATURE----- --fNX7w9sGG4oIXpmKDJuudL3cRp9xsIjpo-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 11:44:28 2014 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 B4B87C9D; Mon, 27 Oct 2014 11:44:28 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (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 7AE91A12; Mon, 27 Oct 2014 11:44:28 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xieib-000NwJ-V4; Mon, 27 Oct 2014 11:27:58 +0400 Message-ID: <544E2FA4.8080003@FreeBSD.org> Date: Mon, 27 Oct 2014 15:42:28 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: faith(4) / faithd(8) removal 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: Mon, 27 Oct 2014 11:44:28 -0000 Hello everyone. I'd like to remove faith (IPv6/v4 translator) from base. * It does not seem like a proper way to translate between IPv4/IPv6 traffic. There are several well-documented (and already implemented) technologies: Stateful/stateless NAT64 (rfc 6146, 6145), 464XLAT (6877). Unfortunately, we don't have in-kernel NAT64 implementation, but there are some userland-base one, like net/tayga64. * It does complicate IPv6 processing path * It does not seem to be used: last non-trivial commit was 10 years ago (126781). * OpenBSD removed it in 2013: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/Attic/if_faith.c If there are no objections I'll remove it in a week. From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 12:21:20 2014 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 1DE299E0; Mon, 27 Oct 2014 12:21:20 +0000 (UTC) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 D6B2BE08; Mon, 27 Oct 2014 12:21:19 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1XijIS-0002Dh-4f; Mon, 27 Oct 2014 12:21:16 +0000 Date: Mon, 27 Oct 2014 12:21:16 +0000 From: Gary Palmer To: Tiago Felipe Subject: Re: dropped due to the socket Message-ID: <20141027122116.GA6851@in-addr.com> References: <544E25E1.8060202@connectionlost.com.br> <544E2ACD.6060901@multiplay.co.uk> <544E2CF8.3090208@connectionlost.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544E2CF8.3090208@connectionlost.com.br> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false 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, 27 Oct 2014 12:21:20 -0000 On Mon, Oct 27, 2014 at 09:31:04AM -0200, Tiago Felipe wrote: > Maybe, but do not believe it, because when you turn it on, the counter Turn what on, exactly? > "dropped due to the socket" has gradually increased, this machine acts Please provide the exact output from the "netstat -s -s" command that you are talking about. There is no such statistic "dropped due to the socket". > as pppoe concentrator, mpd5 and netgraph .. > I have clients with public IP and nat44. > > I'm doing tests yet, but I've read a lot about and looked for similar > problems, could not come to a conclusion ... If you are referring to "dropped due to no socket" it means that a UDP packet arrived for a port that had no socket listening on it. If you are referring to another statistic please provide the *exact* statistic If you want to see what UDP requests are being dropped due to no socket then run this as root: sysctl net.inet.udp.log_in_vain=1 it may produce a LOT of logs, so to turn it off again to: sysctl net.inet.udp.log_in_vain=0 The log_in_vain output should go to the console and anywhere in syslog you have configured to receive kern.info syslog events. If you have an idle system where the counter is not incrementing and it is passing no traffic (a VM with no network would be ideal) you can test the behaviour of the "dropped due to no socket" statistic yourself. Run: netstat -s -s | grep 'dropped due to no socket' traceroute localhost netstat -s -s | grep 'dropped due to no socket' The 'dropped due to no socket' count should go up by 3, for the 3 traceroute packets that tried to connect to a port that had no listening socket. You can use the net.inet.udp.log_in_vain sysctl to see the 3 traceroute packets during the test if you are interested. If you aren't running any firewalls, then as Steve mentioned the most likely reason is people scanning your box looking for vulnerabilities. e.g. I see people try to hit the SIP port (UDP 5060) every day on IPs that don't run any SIP services. It's also possible that some customer equipment is hitting ports on your PPPOE termination boxes as the box is the "other end" of the PPPOE session and the customer equipment is trying to use that "other end" for services, e.g. DNS, NTP or similar, even if your PPP session points them elsewhere for those services Regards, Gary > > > Thank you > > On 27/10/14 09:21, Steven Hartland wrote: > > I assume you mean "dropped due to *no *socket" which means your seeing > > requests to a port which isn't open, possibly due to being port scanned? > > > > On 27/10/2014 11:00, Tiago Felipe wrote: > >> Good afternoon! > >> > >> I have seen "dropped due to the socket" on multiple servers with > >> Freebsd, this case is a Release 10. > >> # Netstat -s -s > >> ... > >> 4614884 dropped due to the socket > >> ... > >> > >> In this case the current flow is 700mbits download and 80mbits upload, > >> averaging 130kpps. > >> > >> I've done many changes in sysctl.conf and loader.conf, swapped hardware > >> and have not had many improvements. > >> > >> Can anyone tell me the reason? I'm looking for it to weeks, but still no > >> result. > >> > >> > >> Thank you so much. > >> > >> > > > > _______________________________________________ > > 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" > > -- > []s > From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 12:43:31 2014 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 1C5EE25E; Mon, 27 Oct 2014 12:43:31 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla.connectionlost.com.br [131.72.200.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Tiago Felipe Gon????alves", Issuer "Tiago Felipe Gon????alves" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB4CFF1; Mon, 27 Oct 2014 12:43:30 +0000 (UTC) Received: from valhalla.connectionlost.com.br (valhalla [131.72.200.69]) by valhalla.connectionlost.com.br (Postfix) with ESMTP id 2B1BCB1918; Mon, 27 Oct 2014 10:43:24 -0200 (BRST) Authentication-Results: valhalla.connectionlost.com.br; dkim=pass reason="1024-bit key" header.d=connectionlost.com.br header.i=@connectionlost.com.br header.b=SskiO4Tg; dkim-adsp=pass Received: from [186.250.58.220] (unknown [186.250.58.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by valhalla.connectionlost.com.br (Postfix) with ESMTPSA id 57022B18DE; Mon, 27 Oct 2014 10:43:23 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=connectionlost.com.br; s=valhalla; t=1414413803; bh=RTcFyPwxT/3FPNOO5gp4Wf6jNOk46DBAEDDiZp6iAl8=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=SskiO4TgYvkfFNJvjIxibzQmzaBcW/9dQqgTgK/DnC83CP5ton0vNAKEH/Q12+do9 QT0gC9xN/LlBl65h4CNABthPWT1r4580oQNgD0Mla16xT3xUR8d17r+yx1GmP6jYA9 rUbz5mb0N2yDbUp0ZHDWzUzbF/Vfr54xoclCG7A4= Message-ID: <544E3DE8.2060602@connectionlost.com.br> Date: Mon, 27 Oct 2014 10:43:20 -0200 From: Tiago Felipe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: Gary Palmer Subject: Re: dropped due to the socket References: <544E25E1.8060202@connectionlost.com.br> <544E2ACD.6060901@multiplay.co.uk> <544E2CF8.3090208@connectionlost.com.br> <20141027122116.GA6851@in-addr.com> In-Reply-To: <20141027122116.GA6851@in-addr.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vl2onTpR3dQgfrdq9TsV8ORNXdt4tj9J" X-Virus-Scanned: ClamAV using ClamSMTP 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, 27 Oct 2014 12:43:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0vl2onTpR3dQgfrdq9TsV8ORNXdt4tj9J Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the explanation, net.inet.udp.log_in_vain was very well put, now I can debug better. I'll do some more tests and then come back here to the list. Thank you Steven and Gary. []s On 27/10/14 10:21, Gary Palmer wrote: > On Mon, Oct 27, 2014 at 09:31:04AM -0200, Tiago Felipe wrote: >> Maybe, but do not believe it, because when you turn it on, the counter= >=20 >=20 > Turn what on, exactly? >=20 >=20 >> "dropped due to the socket" has gradually increased, this machine acts= >=20 >=20 > Please provide the exact output from the "netstat -s -s" command that > you are talking about. There is no such statistic > "dropped due to the socket". >=20 >=20 >> as pppoe concentrator, mpd5 and netgraph .. >> I have clients with public IP and nat44. >> >> I'm doing tests yet, but I've read a lot about and looked for similar >> problems, could not come to a conclusion ... >=20 >=20 > If you are referring to "dropped due to no socket" it means that=20 > a UDP packet arrived for a port that had no socket listening on it. >=20 > If you are referring to another statistic please provide the *exact* > statistic >=20 > If you want to see what UDP requests are being dropped due to no > socket then run this as root: >=20 > sysctl net.inet.udp.log_in_vain=3D1 >=20 > it may produce a LOT of logs, so to turn it off again to: >=20 > sysctl net.inet.udp.log_in_vain=3D0 >=20 > The log_in_vain output should go to the console and anywhere in syslog > you have configured to receive kern.info syslog events. >=20 > If you have an idle system where the counter is not incrementing > and it is passing no traffic (a VM with no network would be ideal) > you can test the behaviour of the "dropped due to no socket" statistic = > yourself. >=20 > Run: >=20 > netstat -s -s | grep 'dropped due to no socket' > traceroute localhost > netstat -s -s | grep 'dropped due to no socket' >=20 > The 'dropped due to no socket' count should go up by 3, for the 3 > traceroute packets that tried to connect to a port that had no listenin= g > socket. You can use the net.inet.udp.log_in_vain sysctl to see the 3 > traceroute packets during the test if you are interested.=20 >=20 > If you aren't running any firewalls, then as Steve mentioned the most > likely reason is people scanning your box looking for vulnerabilities. = > e.g. I see people try to hit the SIP port (UDP 5060) every day on IPs > that don't run any SIP services. It's also possible that some > customer equipment is hitting ports on your PPPOE termination boxes > as the box is the "other end" of the PPPOE session and the customer > equipment is trying to use that "other end" for services, e.g. DNS, NTP= > or similar, even if your PPP session points them elsewhere for those > services >=20 > Regards, >=20 > Gary >=20 >> >> >> Thank you >> >> On 27/10/14 09:21, Steven Hartland wrote: >>> I assume you mean "dropped due to *no *socket" which means your seein= g >>> requests to a port which isn't open, possibly due to being port scann= ed? >>> >>> On 27/10/2014 11:00, Tiago Felipe wrote: >>>> Good afternoon! >>>> >>>> I have seen "dropped due to the socket" on multiple servers with >>>> Freebsd, this case is a Release 10. >>>> # Netstat -s -s >>>> ... >>>> 4614884 dropped due to the socket >>>> ... >>>> >>>> In this case the current flow is 700mbits download and 80mbits uploa= d, >>>> averaging 130kpps. >>>> >>>> I've done many changes in sysctl.conf and loader.conf, swapped hardw= are >>>> and have not had many improvements. >>>> >>>> Can anyone tell me the reason? I'm looking for it to weeks, but stil= l no >>>> result. >>>> >>>> >>>> Thank you so much. >>>> >>>> >>> >>> _______________________________________________ >>> 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= " >> >> --=20 >> []s >> >=20 >=20 --=20 []s --0vl2onTpR3dQgfrdq9TsV8ORNXdt4tj9J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUTj3rAAoJEMR7HC7H8wTJlioP/i9Hmeh4qsJB18w+hHIY0Nvv 9++jPfEa2V6/CzZpAZ+zVLVJJXyPdUSfVkslT/CdKBersnyLBFgoQ6t+D/P/g1dk T/QwBDB2aprDFsvQneF4mGhh4dziWcuHw35m2vjbd27ikzIjnkGy/HFmJ48Lbfup yo9dWeIrQTe78bEOz4spDHl7cWZNMCTvi5eDIn9aEdBfKjeCD9wo20YqQpGg+Ovg Shjg5KIQBIoMk80XhzQE5pKe4zQsx8b0LS2y7YsmT5djDq5ok2fCesIetGd7Ks1T HbGhv95vjHcKk1g3L77I10RcRwqctNLpmilI5gXbiAvQwmZY/egk0OW50rjmvNiR baiP0TR/jERM5NmVwcKiGzLOE6HFvPDciJpfaT/Y67veR74cJtQCCz4sg5hSjxDo 4J97ALt5b4YIGJDfjOuKXWa4nLl1NqXYWyet0R7pqaQ3DZTJosh13tUgnp7AWmsJ EixjqUryxqw80bjbqNcqsgk/JuA4m5gth0eSt8nJFTGr+hvrm6ttqtHflsW7IeBk kilCmDCsglab90XUW/QEGrhu/WRl58s9erK7ArktI5P0huA7I6I7DVj2HZ++5SCY 2LiVPJ9e3EsN0ISpWHoUQKn6NbB6svB6QJV5tjKHJgnVjzNVYm5LQGADcSZEdG9U hArmco4Fs4xnVncNK2dZ =DCD3 -----END PGP SIGNATURE----- --0vl2onTpR3dQgfrdq9TsV8ORNXdt4tj9J-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 16:14:32 2014 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 A075E215; Mon, 27 Oct 2014 16:14:32 +0000 (UTC) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA5ECEA; Mon, 27 Oct 2014 16:14:32 +0000 (UTC) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by strudel.ki.iif.hu (Postfix) with ESMTP id C125B461; Mon, 27 Oct 2014 17:14:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id deyEp0f2TuRT; Mon, 27 Oct 2014 17:14:27 +0100 (CET) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 0FFA85C7; Mon, 27 Oct 2014 17:14:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 0273B461; Mon, 27 Oct 2014 17:14:27 +0100 (CET) Date: Mon, 27 Oct 2014 17:14:26 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: "Alexander V. Chernikov" Subject: Re: faith(4) / faithd(8) removal In-Reply-To: <544E2FA4.8080003@FreeBSD.org> Message-ID: References: <544E2FA4.8080003@FreeBSD.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , "freebsd-hackers@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, 27 Oct 2014 16:14:32 -0000 Dear Alexander, On Mon, 27 Oct 2014, Alexander V. Chernikov wrote: > Hello everyone. > > I'd like to remove faith (IPv6/v4 translator) from base. > > * It does not seem like a proper way to translate between IPv4/IPv6 traffic. It is a proper way to translate between IPv4 and IPv6 TCP as defined in https://tools.ietf.org/html/rfc3142 However if there no need for TRT among the FreeBSD users it is completely acceptable to remove from the system. Best Regards, Janos Mohacsi > There are several well-documented (and already implemented) technologies: > Stateful/stateless NAT64 (rfc 6146, 6145), 464XLAT (6877). > Unfortunately, we don't have in-kernel NAT64 implementation, but there > are > some userland-base one, like net/tayga64. > * It does complicate IPv6 processing path > * It does not seem to be used: last non-trivial commit was 10 years ago > (126781). > * OpenBSD removed it in 2013: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/Attic/if_faith.c > > If there are no objections I'll remove it in a week. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 19:51:33 2014 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 A0A5B71F for ; Mon, 27 Oct 2014 19:51:33 +0000 (UTC) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (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 7EF19A95 for ; Mon, 27 Oct 2014 19:51:32 +0000 (UTC) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id 335501F02FF for ; Mon, 27 Oct 2014 15:51:26 -0400 (EDT) Date: Mon, 27 Oct 2014 15:51:24 -0400 From: Mason Loring Bliss To: freebsd-net@freebsd.org Subject: Very bad Realtek problems Message-ID: <20141027195124.GI17150@blisses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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, 27 Oct 2014 19:51:33 -0000 Hi, all. I've been having sporadic and serious problems with the Realtek gigabit interface built into my motherboard. Periodically, it just freezes up. I've tried several things to no avail: turning on DEVICE_POLLING, frobbing bootloader options and sysctl settings, etc. I had a solid week of function with the following: hw.re.msi_disable="1" hw.re.msix_disable="1" dev.re.0.int_rx_mod=0 <-- this one says it can be a loader tuneable, but it didn't work that way - I had to set it from sysctl.conf And then after a reboot, I locked up again on pushing the interface a little with an rsync. However, I've seen interactive sessions lock the thing up too. It's not just when I'd doing big transfers. It's not clear what's happening. I have been capturing stats periodically with 'sysctl dev.re.0.stats=1', but that doesn't always show a problem. For instance, during one of the lock-ups last night, after a reboot, I got this: re0 statistics: Tx frames : 171306 Rx frames : 20271 Tx errors : 0 Rx errors : 0 Rx missed frames : 0 Rx frame alignment errs : 0 Tx single collisions : 0 Tx multiple collisions : 0 Rx unicast frames : 20271 Rx broadcast frames : 0 Rx multicast frames : 0 Tx aborts : 0 Tx underruns : 0 After running overnight, with sporadic automated transfers: re0 statistics: Tx frames : 4658945 Rx frames : 1258514 Tx errors : 0 Rx errors : 33 Rx missed frames : 0 Rx frame alignment errs : 3591 Tx single collisions : 0 Tx multiple collisions : 0 Rx unicast frames : 1255880 Rx broadcast frames : 2411 Rx multicast frames : 223 Tx aborts : 0 Tx underruns : 0 I was seeing the "Rx multicast frames" creep up each time I saw a freeze last night, which was confusing in that I'm not sure why there'd be any multicast traffic. Here's the card from dmesg, with MSI/X turned off: re0: port 0xe800-0xe8ff mem 0xfbfff000-0xfbffffff,0xfbff8000-0xfbffbfff irq 18 at device 0.0 on pci2 re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00200000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: bc:ae:c5:bd:44:e7 The motherboard with this included: Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M4A88T-M Version: Rev X.0x Serial Number: MF70B1G04201588 Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 In general I've been saying "ifconfig re0 down ; ifconfig re0 up" to kick the interface, but last night a friendly person from IRC mentioned that I could work around this by running a steady ping and frobbing mediatype when I see the pings fail. So, I've got this running: while true do ping -c 1 -t 1 firewall > /dev/null 2>&1 if [ $? -ne 0 ]; then date echo "toggling re0" echo ifconfig re0 media 1000baseT mediaopt full-duplex,flowcontrol,master ifconfig re0 media autoselect mediaopt flowcontrol sleep 3 fi sleep 1 done This has been noting failures sporadically throughout the day, but it's allowing traffic to continue moving, albeit with the occasional hiccough. This hardware has been running Debian for a couple years, and it's never had so much as a short hiccough, so I have confidence that the hardware is fine. It suggests that there's something the Linux driver is doing to handle this hardware that FreeBSD isn't doing. For a while I was dual-booting and I'd see errors with FreeBSD running that were't there under Debian. I'd started diving into the source, both Linux and FreeBSD, but I lack sufficient exposure to ethernet driver code to be able to get a high-level picture of what they're doing, and as such I haven't yet noticed any special- case or hardware glitch handling that we're missing, although I might find something eventually. I'm struggling with finding a way to see what's actually happening with this. I've toggled MSI and MSI-X handling, I've turned down interrupt handling delays, I've tried both I/O and memory register transfers, although I'd not actually clear what's happening differently there. I've had polling variously enabled and disabled. One thing to note is that last night's horror while I was trying to move some back-up data was after rebooting from Windows. (Installed on a partition for gaming...) It made me wonder if we're not fully setting up some state on the card. I'd have what felt like a solid, glitchless week before that. FWIW, I'm running 10.1-RC3 on this box and I've seen issues from early on while I was still running 10.0-RELEASE. Thanks in advance for clues. This is a showstopper for futher deployment for me, as I've got these Realtek on-board cards in several boxes, and while the media frobbing largely works, it's not something I can inflict on my users. -- Mason Loring Bliss (( If I have not seen as far as others, it is because mason@blisses.org )) giants were standing on my shoulders. - Hal Abelson From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 01:50:30 2014 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 B57ECF82 for ; Tue, 28 Oct 2014 01:50:30 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 896E8836 for ; Tue, 28 Oct 2014 01:50:30 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id rd3so6664920pab.28 for ; Mon, 27 Oct 2014 18:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Xvl47QnxpG8gh02xp+O4Y+CNlKQ55i5yRyU6NTgftyE=; b=MacN9Kk0p9jKG7pb04t4PYgrcLV/74s6wVt8SUNHjs8OnEkr+YU9W2gd2Hhcmw8m8Z LwsB4mQnM0kISu7XMAGvuWs6ISiJLPdROSnI/UCFsdCNq2YODqQyOgBKqoPQkjQnfnZx 0/VTzhglakrPyW4Fp4eq7oknsnTh+F0KHEZQtUQ+3UJ79teknE7s8TRvQGcKg35D2mgV f2ADScItdir50CETHGeEO12htmQ7f1RRNrFViCUL8oArgxicwbh0QOpN7b4+snDp25Nq BUAgMbNDfW5msaZ7NNA2HX1BXaOV/flg4jp6O01KfaPAC+kaywKMGzWsb+eb/dxxmr2D MW0w== X-Received: by 10.68.189.67 with SMTP id gg3mr94440pbc.158.1414461030142; Mon, 27 Oct 2014 18:50:30 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id d9sm85780pdm.5.2014.10.27.18.50.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 Oct 2014 18:50:28 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 28 Oct 2014 10:50:20 +0900 Date: Tue, 28 Oct 2014 10:50:20 +0900 To: Mason Loring Bliss Subject: Re: Very bad Realtek problems Message-ID: <20141028015020.GB1054@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20141027195124.GI17150@blisses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141027195124.GI17150@blisses.org> User-Agent: Mutt/1.4.2.3i 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, 28 Oct 2014 01:50:30 -0000 On Mon, Oct 27, 2014 at 03:51:24PM -0400, Mason Loring Bliss wrote: > Hi, all. > > I've been having sporadic and serious problems with the Realtek gigabit > interface built into my motherboard. Periodically, it just freezes up. I've > tried several things to no avail: turning on DEVICE_POLLING, frobbing > bootloader options and sysctl settings, etc. > [...] > It's not clear what's happening. I have been capturing stats periodically > with 'sysctl dev.re.0.stats=1', but that doesn't always show a problem. For > instance, during one of the lock-ups last night, after a reboot, I got this: > > re0 statistics: > Tx frames : 171306 > Rx frames : 20271 > Tx errors : 0 > Rx errors : 0 > Rx missed frames : 0 > Rx frame alignment errs : 0 > Tx single collisions : 0 > Tx multiple collisions : 0 > Rx unicast frames : 20271 > Rx broadcast frames : 0 > Rx multicast frames : 0 > Tx aborts : 0 > Tx underruns : 0 > > After running overnight, with sporadic automated transfers: > > re0 statistics: > Tx frames : 4658945 > Rx frames : 1258514 > Tx errors : 0 > Rx errors : 33 > Rx missed frames : 0 > Rx frame alignment errs : 3591 > Tx single collisions : 0 > Tx multiple collisions : 0 > Rx unicast frames : 1255880 > Rx broadcast frames : 2411 > Rx multicast frames : 223 > Tx aborts : 0 > Tx underruns : 0 > > I was seeing the "Rx multicast frames" creep up each time I saw a freeze last > night, which was confusing in that I'm not sure why there'd be any multicast > traffic. RealTek controllers have small number of H/W MAC counters so it's somewhat hard to guess what's happening there. But the RX frame alignment error normally indicates cabling issue or speed/duplex mismatches with link partner. It's normal to see multicast frames in local LAN. > > Here's the card from dmesg, with MSI/X turned off: > > re0: port 0xe800-0xe8ff mem 0xfbfff000-0xfbffffff,0xfbff8000-0xfbffbfff irq 18 at device 0.0 on pci2 > re0: Chip rev. 0x2c000000 > re0: MAC rev. 0x00200000 It seems your controller is RTL8168E. [...] > In general I've been saying "ifconfig re0 down ; ifconfig re0 up" to kick the > interface, but last night a friendly person from IRC mentioned that I could > work around this by running a steady ping and frobbing mediatype when I see > the pings fail. So, I've got this running: > > while true > do > ping -c 1 -t 1 firewall > /dev/null 2>&1 > if [ $? -ne 0 ]; then > date > echo "toggling re0" > echo > ifconfig re0 media 1000baseT mediaopt full-duplex,flowcontrol,master > ifconfig re0 media autoselect mediaopt flowcontrol > sleep 3 > fi > sleep 1 > done Please don't manually set media types for 1000baseT. It will result in speed/duplex mismatches and other issues. Probably this is the main reason why you see RX alignment errors. You should always stick to auto-negotiation with 1000baseT(Flow control can be set though). Manual media configuration is to workaround buggy link partners. > > This has been noting failures sporadically throughout the day, but it's > allowing traffic to continue moving, albeit with the occasional hiccough. > > This hardware has been running Debian for a couple years, and it's never had > so much as a short hiccough, so I have confidence that the hardware is fine. > It suggests that there's something the Linux driver is doing to handle this > hardware that FreeBSD isn't doing. For a while I was dual-booting and I'd see > errors with FreeBSD running that were't there under Debian. > > I'd started diving into the source, both Linux and FreeBSD, but I lack > sufficient exposure to ethernet driver code to be able to get a high-level > picture of what they're doing, and as such I haven't yet noticed any special- > case or hardware glitch handling that we're missing, although I might find > something eventually. > Data sheet for RealTek controller is not publicly available. Linux uses firmwares for every RealTek controllers. I vaguely guess it may be PHY DSP fixups but I don't have any detailed information for the firmwares. > I'm struggling with finding a way to see what's actually happening with this. > I've toggled MSI and MSI-X handling, I've turned down interrupt handling > delays, I've tried both I/O and memory register transfers, although I'd not > actually clear what's happening differently there. I've had polling variously > enabled and disabled. > > One thing to note is that last night's horror while I was trying to move some > back-up data was after rebooting from Windows. (Installed on a partition for > gaming...) It made me wonder if we're not fully setting up some state on the > card. I'd have what felt like a solid, glitchless week before that. > Vendor's Windows driver may access/program large set of registers unknown to re(4). Currently re(4) heavily relies on power on default settings since no detailed register configuration is not available. Some register configurations made in Windows can survive from warm boot. Does cold-boot from Windows make any difference for you? > FWIW, I'm running 10.1-RC3 on this box and I've seen issues from early on > while I was still running 10.0-RELEASE. > > Thanks in advance for clues. This is a showstopper for futher deployment for > me, as I've got these Realtek on-board cards in several boxes, and while the > media frobbing largely works, it's not something I can inflict on my users. > When you notice re(4) is locked up, - does H/W MAC counters still increase? - does interrupt still get generated for TX/RX? - could you narrow down which part of MAC(TX or RX) is in stuck condition? Thanks. From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 03:10:45 2014 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 00708AA for ; Tue, 28 Oct 2014 03:10:44 +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 DBF18F4D for ; Tue, 28 Oct 2014 03:10:44 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9S3Ai7W017526 for ; Tue, 28 Oct 2014 03:10:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 188032] [lo] IPv6 on lo never leaves 'tentative' state if configured with prefixlen 128 Date: Tue, 28 Oct 2014 03:10:44 +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.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: js@jschneider.com X-Bugzilla-Status: In Discussion 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: Tue, 28 Oct 2014 03:10:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188032 js@jschneider.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |js@jschneider.com --- Comment #8 from js@jschneider.com --- I was pulling my hair out all day trying to figure out why my jails weren't working with IPv6, and finally figured out they couldn't use their assigned IP addresses. A few hours later I noticed the "tentative" in ifconfig and eventually stumbled on this PR. IMO, the lack of "ipv6_activate_all_interfaces" should have no effect on the status of the interfaces when they're explicitly configured in jail settings. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 03:14:57 2014 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 C3C0E17D for ; Tue, 28 Oct 2014 03:14:57 +0000 (UTC) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (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 893A961 for ; Tue, 28 Oct 2014 03:14:57 +0000 (UTC) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id A47061F02FF; Mon, 27 Oct 2014 23:14:55 -0400 (EDT) Date: Mon, 27 Oct 2014 23:14:54 -0400 From: Mason Loring Bliss To: Yonghyeon PYUN Subject: Re: Very bad Realtek problems Message-ID: <20141028031454.GQ17150@blisses.org> References: <20141027195124.GI17150@blisses.org> <20141028015020.GB1054@michelle.fasterthan.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141028015020.GB1054@michelle.fasterthan.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 28 Oct 2014 03:14:58 -0000 On Tue, Oct 28, 2014 at 10:50:20AM +0900, Yonghyeon PYUN wrote: > But the RX frame alignment error normally indicates cabling issue or > speed/duplex mismatches with link partner. Hm. I don't think it's a cabling issue since the only thing changing between working (Linux) and flaky (FreeBSD) is the software. If there's a speed/duplex mismatch with a link partner... Well. FreeBSD: media: Ethernet autoselect (1000baseT ) On the Linux side - the link partner: negotiated 1000baseT-FD flow-control, link ok > Please don't manually set media types for 1000baseT. It will result in > speed/duplex mismatches and other issues. Probably this is the main reason > why you see RX alignment errors. No, I was seeing those before the idea of forcing a toggle of media types came up. > You should always stick to auto-negotiation with 1000baseT(Flow control can > be set though). Manual media configuration is to workaround buggy link > partners. The only reason I'm doing it now is to force the interface to work again without ifconfig re0 down / ifconfig re0 up, which was breaking connections completely. I really don't want to do it at all. Some connections still break, although rsync can ride it out. > Data sheet for RealTek controller is not publicly available. Linux uses > firmwares for every RealTek controllers. I vaguely guess it may be PHY DSP > fixups but I don't have any detailed information for the firmwares. On the other side I don't load firmware - it wants to but I don't have the firmware available to be loaded: [ 20.347757] r8169 0000:03:00.0: firmware: agent aborted loading rtl_nic/rtl8168f-1.fw (not found?) [ 20.348164] r8169 0000:03:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168f-1.fw (-2) I'd be happy to use the firmware under FreeBSD if that's an option. > Currently re(4) heavily relies on power on default settings since no > detailed register configuration is not available. Some register > configurations made in Windows can survive from warm boot. I'll try after sending this. I haven't cold-booted this system for... months? I don't remember. I run Windows for a game maybe once every week or two at the moment. > When you notice re(4) is locked up, > - does H/W MAC counters still increase? > - does interrupt still get generated for TX/RX? > - could you narrow down which part of MAC(TX or RX) is in stuck > condition? I'm sorry for the excessive hand-holding needed, but I'm not sure how to find this stuff out. Prior to my finding out about 'sysctl dev.re.0.stats=1' last week I was completely at a loss. If you could tell me how to generate this information I'd be absolutely happy to supply it. Can I dig it out of sysctl? There's not a lot there about re0: # sysctl -a | grep '\.re\.' dev.re.%parent: dev.re.0.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet dev.re.0.%driver: re dev.re.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PCEA.RLAN dev.re.0.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x1043 subdevice=0x8432 class=0x020000 dev.re.0.%parent: pci2 dev.re.0.stats: -1 dev.re.0.wake: 0 Thanks in advance for instructions - I'll collect whatever is needed. I'm going to do a cold boot now, setting no particular options, and see how things go. -- Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come. From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 03:44:48 2014 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 8ABFC71F for ; Tue, 28 Oct 2014 03:44:48 +0000 (UTC) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (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 6B21A377 for ; Tue, 28 Oct 2014 03:44:48 +0000 (UTC) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id 2590D1F02FF; Mon, 27 Oct 2014 23:44:47 -0400 (EDT) Date: Mon, 27 Oct 2014 23:44:45 -0400 From: Mason Loring Bliss To: Yonghyeon PYUN Subject: Re: Very bad Realtek problems Message-ID: <20141028034445.GR17150@blisses.org> References: <20141027195124.GI17150@blisses.org> <20141028015020.GB1054@michelle.fasterthan.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141028015020.GB1054@michelle.fasterthan.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 28 Oct 2014 03:44:48 -0000 On Tue, Oct 28, 2014 at 10:50:20AM +0900, Yonghyeon PYUN wrote: > Currently re(4) heavily relies on power on default settings since no > detailed register configuration is not available. Some register > configurations made in Windows can survive from warm boot. Alright, a cold boot doesn't help. I froze up on an rsync, and observed these stats: re0 statistics: Tx frames : 209681 Rx frames : 27559 Tx errors : 0 Rx errors : 0 Rx missed frames : 0 Rx frame alignment errs : 0 Tx single collisions : 0 Tx multiple collisions : 0 Rx unicast frames : 27548 Rx broadcast frames : 9 Rx multicast frames : 2 Tx aborts : 0 Tx underruns : 0 I rebooted with MSI and MSI-X disabled, and it broke again on an rsync. I observed: re0 statistics: Tx frames : 416065 Rx frames : 47783 Tx errors : 0 Rx errors : 0 Rx missed frames : 0 Rx frame alignment errs : 0 Tx single collisions : 0 Tx multiple collisions : 0 Rx unicast frames : 47757 Rx broadcast frames : 24 Rx multicast frames : 2 Tx aborts : 0 Tx underruns : 0 The multicast frames seem to coincide with interface lock-ups. This time to correct I said ifconfig re0 down; ifconfig re0 up. It came back but the rsync died. I'll be happy to provide further debugging information once I know how to collect it. -- Mason Loring Bliss mason@blisses.org Ewige Blumenkraft! awake ? sleep : random() & 2 ? dream : sleep; -- Hamlet, Act III, Scene I From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 04:05:43 2014 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 41B04ADF for ; Tue, 28 Oct 2014 04:05:43 +0000 (UTC) Received: from o1.email.freshdesk.com (o1.email.freshdesk.com [74.63.234.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5F05823 for ; Tue, 28 Oct 2014 04:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=email.freshdesk.com; h=from:reply-to:to:references:subject:mime-version:content-type:content-transfer-encoding; s=smtpapi; bh=oj/b/3n2M9wi+3LnSYVEPlsf7Fg=; b=gNCdPzyFXPzjRYhmoU /AkqQ3+35E2Nqt1J+lkriQxvGzEe+S6DW+N7DZmLRitgqTqsf1+QLIkDawfxx4Um ULtBcYo7tX/u+irNcI/P88UdyvBdxYRG81jKZl7onjZ3mP+ikCnV8sVcsQgpRiju yycSekD6Mah/2h+kyH0uh9nIc= Received: by filter0219p1mdw1.sendgrid.net with SMTP id filter0219p1mdw1.3728.544F157B1D 2014-10-28 04:03:45.325767441 +0000 UTC Received: from freshdesk.com (ec2-23-20-105-135.compute-1.amazonaws.com [23.20.105.135]) by ismtpd-027.iad1.sendgrid.net (SG) with ESMTP id 14954ec7df7.7c6a.552c54 for ; Tue, 28 Oct 2014 04:03:45 +0000 (GMT) Date: Tue, 28 Oct 2014 04:03:45 +0000 From: BrandMyMail Reply-To: BrandMyMail To: freebsd-net@freebsd.org Message-ID: <544f15a133555_5728cd507816366368@delayed-jobs-2.mail> References: Subject: Ticket Received - [#17163] DELIVERY REPORTS ABOUT YOUR E-MAIL Mime-Version: 1.0 Auto-Submitted: auto-generated X-Auto-Response-Suppress: DR, RN, OOF, AutoReply X-SG-EID: ISGKkmHlRE12gnWy0TjFyGQSFR1WnpjQdICm3qu6YxFabjrS4nHP2gySrvOJ+/bt17w0+uVD7ueK5LV4cRUD+bhtKE+SdpgQujgXvIyV48Hhj4Yis3c51c4I5FTQxZJRcIak6Q35vY89lzJTEm/bwl4KJOzkBFRFwYEQkHK0871p1z1Asyv2IpVa0nw3VxhG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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, 28 Oct 2014 04:05:43 -0000 Dear Freebsd-net, We would like to acknowledge that we have received your= request and a ticket has been created with Ticket ID - 17163. A support re= presentative will be reviewing your request and will send you a personal re= sponse.(usually within 24 hours). To view the status of the ticket or add = comments, please visit http://brandmymail.freshdesk.com/helpdesk/tickets/1= 7163 Thank you for your patience. Sincerely, BrandMyMail Support Team=20 From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 07:32:39 2014 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 092EF74D for ; Tue, 28 Oct 2014 07:32:39 +0000 (UTC) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A05B8F64 for ; Tue, 28 Oct 2014 07:32:38 +0000 (UTC) Received: by mail-oi0-f54.google.com with SMTP id v63so63095oia.27 for ; Tue, 28 Oct 2014 00:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=iOO25ZIobwtSeXzjC88VGDr1pH49Omya2Dv65jeZvp0=; b=Q46+jAKQA1Nx832aybhk4EsYy9BsvOPBL1jkk44nFUr4AGvwIBc94OUhXayWGOYq1Z 0RLB61CuIA5u09XxJdn68Gen3PGdcqkcfED/ZkqVoSt++QcHSpYrs1iHp39jgGuu4Rc9 29zn3ybinBCEJZ7WvIZa2jI+3RXtbTqi62XrNhXyib1NPECFowTF/OqPGF/k0uvZsLOm /g/PynVi7Bi8owi3/ZiiRZELBsynw9dJAaoDSR/KOJjNZfUGL1k1R32GSBZxPuJ/U7/c 9V8u4NoWr82ganurtyTmacWyRG45ygpCPOcpgPZt8iBkE21/PcDSRhN8078Qx9oUel/j HziQ== X-Received: by 10.202.68.2 with SMTP id r2mr1285505oia.49.1414481557767; Tue, 28 Oct 2014 00:32:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.93.40 with HTTP; Tue, 28 Oct 2014 00:32:17 -0700 (PDT) From: Raimundo Santos Date: Tue, 28 Oct 2014 05:32:17 -0200 Message-ID: Subject: ipfw fwd duplicating packets in 9.3-RELEASE To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 28 Oct 2014 07:32:39 -0000 Hello list! I was testing the behaviour of fwd in ipfw from FreeBSd 9.3-RELEASE, latest updates, GENERIC kernel, in this setup: 1x FreeBSD 9.3 as router, with 3 network interfaces 5x OpenBSD 5.5 as network machines, each one connected to FreeBSD via one port. It is a virtual env. FreeBSD em0 (192.168.0.1) -> OpenBSD#1 em0 (192.168.0.2) FreeBSD em1 (192.168.1.1) -> OpenBSD#2 em0 (192.168.1.2) FreeBSD em2 (192.168.2.1) -> OpenBSD#3 em0 (192.168.2.2) FreeBSD em3 (192.168.3.1) -> OpenBSD#4 em0 (192.168.3.2) FreeBSD em4 (192.168.4.1) -> OpenBSD#5 em1 (192.168.4.2) ipfw rule: fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 in recv em4 Then a ping 192.168.1.2 was issued from OpenBSD#5. Interestingly, this rule put a packet on em0 and em1 in FreeBSD. The packet successfully arrived at OpenBSD#1, where it was discarded, and at OpenBSD#2, where it got its reply. Only these combinations of interface direction do not duplicate the packet: out xmit fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 and fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out via em1 Even out recv em4 xmit em1 leads to packet duplication. I think that it is a bad thing for PBR. As I can see from these tests, I can not use all the options to do PBR. In my real needs I have to: 1. let web traffic flow to an cache appliance (from internal network to cache, from internet to cache) 2. do NAT for the internal network under three different links In theory, fwd + in kernel NAT + one_pass=0 could solve the problem. But I am hitting my head in the wall for almost three weeks on this, only now I have the time to test in a more clear way. First I blamed the NAT, after that the one_pass=0, and now, with these results, well... Someone has an explanation about it? Something related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129036? For my real needs, I figured out that it works with <...before NAT aliasing...> fwd CACHE_IP proto tcp src-ip table(INT) dst-port 80 out recv INT_IFACE <...after NAT dealiasing...> fwd CACHE_IP proto tcp dst-ip table(INT) src-port 80 out recv EXT_IFACE But I am not confident that it will remains in good shape without knowing exactly why fwd behaves that way. Thank you in advance for your time, Raimundo Santos From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 12:30:01 2014 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 A8EC2ACF for ; Tue, 28 Oct 2014 12:30:01 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4814E23E for ; Tue, 28 Oct 2014 12:30:01 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id a1so701556wgh.6 for ; Tue, 28 Oct 2014 05:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gXd9gckcGM6DvFsm46GZ5G2qu+QD6pM1uGlHOH+t7gg=; b=IPnVnv8W9DojdYpqkn8K1lMu9Slr09VhVDWIGmmNiRs1pxQ2Ym3s+8Nwa7+RwWZQQ5 GcU6kAvOMKy/JNdbQxS73gDX6qMrg3z9PCdrahzqNlNY9fNMhC/K0EWObnM5oCfFoigY IYMO4eAWiB3dBDfdrC1kPYzrx1Bv1n1wh3K5g2EM6d3uEfZDEEHiK7cQ1YBkgHuxJx3+ ByeEILA/rF7mc/IX3ZntXBANZSYBAlYo945qIIsV9x4eZu6b7X41Vk5n88yem5vHH4OH WqGM4e4H4nk5DxPZgbu0T3ch6hi49pLu4/luyK7ujl+eGE1XKZGJAxIP66LlsFaXPXQN ecrA== MIME-Version: 1.0 X-Received: by 10.194.60.16 with SMTP id d16mr1609974wjr.13.1414499399584; Tue, 28 Oct 2014 05:29:59 -0700 (PDT) Received: by 10.194.51.164 with HTTP; Tue, 28 Oct 2014 05:29:59 -0700 (PDT) Date: Tue, 28 Oct 2014 12:29:59 +0000 Message-ID: Subject: Errors initializing Snort with netmap support From: "C. L. Martinez" To: freebsd-net@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: Tue, 28 Oct 2014 12:30:01 -0000 Hi all, Starting Snort with netmap support in DAQ, returns me the following error: FATAL ERROR: Can't start DAQ (-1) - start_instance: Netmap registration for em0 failed: Invalid argument (22)! DAQ conf: config daq: netmap config daq_dir: /opt/daq/lib/daq config daq_mode: passive #config daq_var: Do I need to setup something else?? Snort is 2.9.7.0 From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 19:41:35 2014 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 1FFF746D; Tue, 28 Oct 2014 19:41:35 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 DDED1CEB; Tue, 28 Oct 2014 19:41:34 +0000 (UTC) Received: from [192.168.200.213] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 37033193964; Tue, 28 Oct 2014 19:41:25 +0000 (UTC) Subject: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers From: Sean Bruno Reply-To: sbruno@freebsd.org To: FreeBSD Net Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Oct 2014 12:41:15 -0700 Message-ID: <1414525275.43009.3.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port 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, 28 Oct 2014 19:41:35 -0000 It looks like recent HEAD seems to fail intermittently here on my home network. It will recover, but urtwn(4) seems to lose an ack or something on txmit. turning on debug, yields this message during the hang event. hw.usb.urtwn.debug: 1 Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit buffers Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit buffers Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue Additionally, I get the following at module load time: urtwn0: on usbus0 urtwn0: could not read efuse byte at address 0x10 urtwn0: could not read efuse byte at address 0x18 From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 01:46:41 2014 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 CB348AAA for ; Wed, 29 Oct 2014 01:46:41 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C3D981D for ; Wed, 29 Oct 2014 01:46:41 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fa1so2028041pad.25 for ; Tue, 28 Oct 2014 18:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Ejmi4qULAHlpBRTQVzB3gPMa/RaKA27HxgjeaBBPuzY=; b=XUH+2sTmCCANb3qtYlxooJthHMD5r3uGlbWVg3IL03NJUwx/OGDSDxdg4OsadnCSzK NoddmuZI/Fjk9jZeNJlrHr94ZjUmdUbHp4QwPFVRJi/752+49DOKtZKO7Dr/yAmIslhX wf3YUcjynvnlo+xi3f1Si/La9ppgDh1T7SKNKqB9nudrASWh11i5WWAwJTAASymiLdAi DalqxuPSkD/V2Ni0yAKvWulcOmXr5NbAnRWXLtTth8MPjuhDHoevzBdNKHj/X4QRfELN 0IVN3SqyNqySFgeu275mw7EeIncq+wR/0bPMPY0iPrfCJ9b91DuOkmIPRCf3SFWRsL4b LSNA== X-Received: by 10.70.65.37 with SMTP id u5mr7249691pds.93.1414547201205; Tue, 28 Oct 2014 18:46:41 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id gm11sm2743471pbd.63.2014.10.28.18.46.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 28 Oct 2014 18:46:39 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 29 Oct 2014 10:46:30 +0900 Date: Wed, 29 Oct 2014 10:46:30 +0900 To: Mason Loring Bliss Subject: Re: Very bad Realtek problems Message-ID: <20141029014630.GA2503@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20141027195124.GI17150@blisses.org> <20141028015020.GB1054@michelle.fasterthan.com> <20141028034445.GR17150@blisses.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20141028034445.GR17150@blisses.org> User-Agent: Mutt/1.4.2.3i 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, 29 Oct 2014 01:46:41 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 27, 2014 at 11:44:45PM -0400, Mason Loring Bliss wrote: > On Tue, Oct 28, 2014 at 10:50:20AM +0900, Yonghyeon PYUN wrote: > > > Currently re(4) heavily relies on power on default settings since no > > detailed register configuration is not available. Some register > > configurations made in Windows can survive from warm boot. > > Alright, a cold boot doesn't help. I froze up on an rsync, and observed these > stats: > > re0 statistics: > Tx frames : 209681 > Rx frames : 27559 > Tx errors : 0 > Rx errors : 0 > Rx missed frames : 0 > Rx frame alignment errs : 0 > Tx single collisions : 0 > Tx multiple collisions : 0 > Rx unicast frames : 27548 > Rx broadcast frames : 9 > Rx multicast frames : 2 > Tx aborts : 0 > Tx underruns : 0 > > I rebooted with MSI and MSI-X disabled, and it broke again on an rsync. I > observed: > > re0 statistics: > Tx frames : 416065 > Rx frames : 47783 > Tx errors : 0 > Rx errors : 0 > Rx missed frames : 0 > Rx frame alignment errs : 0 > Tx single collisions : 0 > Tx multiple collisions : 0 > Rx unicast frames : 47757 > Rx broadcast frames : 24 > Rx multicast frames : 2 > Tx aborts : 0 > Tx underruns : 0 > > The multicast frames seem to coincide with interface lock-ups. > > This time to correct I said ifconfig re0 down; ifconfig re0 up. It came back > but the rsync died. I guess you don't see 'watchdog timeout' errors so driver's watchdog handler didn't help. Given that you can reliably reproduce the issue, let's check simple ones first. Disable all H/W offloading features(TX/RX checksum offloading, TSO, VLAN H/W tag insertion/stripping) and see whether that makes any difference. If that has no difference, identify which part of MAC is in stuck condition. Before interface down/up again after rsync breakage, run tcpdump on your box and see whether you can still see RX packets. If you can see RX packets, it indicates RX MAC still works. After that, run ping(8) to other host and see whether you can see the ICMP echo request packets sent from your host. If you can see the ICMP echo request packets, it indicates TX MAC works. > > I'll be happy to provide further debugging information once I know how to > collect it. > If you think the issue intermittently happens regardless of network load, try attached patch. I'm not sure whether the patch makes any difference for you since many PCIe NICs don't implement CLKREQ feature. It's just a wild guess. Thanks. --ZGiS0Q5IWpPtfppv Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.aspm.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 273756) +++ sys/dev/re/if_re.c (working copy) @@ -1365,6 +1365,7 @@ re_attach(device_t dev) PCIER_LINK_CTL, 2); if ((ctl & PCIEM_LINK_CTL_ASPMC) != 0) { ctl &= ~PCIEM_LINK_CTL_ASPMC; + ctl &= ~PCIEM_LINK_CTL_ECPM; pci_write_config(dev, sc->rl_expcap + PCIER_LINK_CTL, ctl, 2); device_printf(dev, "ASPM disabled\n"); --ZGiS0Q5IWpPtfppv-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 09:35:52 2014 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 A259ABCB; Wed, 29 Oct 2014 09:35:52 +0000 (UTC) Received: from forward4l.mail.yandex.net (forward4l.mail.yandex.net [84.201.143.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5681CC35; Wed, 29 Oct 2014 09:35:51 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward4l.mail.yandex.net (Yandex) with ESMTP id C88E71441295; Wed, 29 Oct 2014 12:35:41 +0300 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 9CF83E40275; Wed, 29 Oct 2014 12:35:40 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:40c:120b:a9ff:fe93:c998]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 97ICnHF1An-ZdSimkOQ; Wed, 29 Oct 2014 12:35:40 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 765454ed-9d77-45d4-b3a9-754409616c00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1414575340; bh=nxJBUaCWwdO7eFbsiYR0jhKO2yDcc2gDW++MYt1m3NM=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type; b=Eh/rtxIqZ19nZ8Q6kOootom9WzTaGHwC/FDHZrqY2CmVymgBwStwk9i593kkftlBH pYcSDoi8+Se0Brwp3nQJ8ByXpyhtQJTbBg3DBVx0+JIVdzsKO6YzSEldovNU+qIbdL Jn8Mz7o77nPe17qN9UKXjFxiT6BwscnXLBczF4ac= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5450B4E5.7020804@yandex.ru> Date: Wed, 29 Oct 2014 12:35:33 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-current Subject: [RFC][RFT] overhaul if_gre(4) Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MvE3iFSrEc0MFFqSF9PRoA2rfJdNneOfc" 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, 29 Oct 2014 09:35:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MvE3iFSrEc0MFFqSF9PRoA2rfJdNneOfc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All, I prepared the patch for review https://reviews.freebsd.org/D1023 Split if_gre(4) into two modules, if_gre(4) for GRE encapsulation and if_me(4) for minimal encapsulation within IP. gre(4) changes: * convert to if_transmit; * rework locking: protect access to softc with rmlock, protect from concurrent ioctls with sx lock; * make implementation conform to the RFC 2784 and partially to RFC 2890; * correct interface accounting for outgoing datagramms (count only payload size); * implement generic support for using IPv6 as delivery header; * add support for GRE checksums - calculate for outgoing datagramms and check for inconming datagramms; * add support for sending sequence number in GRE header; * remove caching routes support. This fixes problem, when gre(4) doesn't work at system startup. But this also removes ability to have tunnels with the same addresses for inner and outer header. * deprecate support for various GREXXX ioctls, use our standard ioctls for tunnels. me(4): * use the same locking model as gre(4); * use if_transmit; * implementation conform to RFC 2004; --=20 WBR, Andrey V. Elsukov --MvE3iFSrEc0MFFqSF9PRoA2rfJdNneOfc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUULTpAAoJEAHF6gQQyKF6+PUIAJgZbHITiPZgBU1pgS7CxcQ7 qaaUc3a8/ClH5pbSH1fdgiboF00ONplUP+F3XElAJn8l9GcfzNEcnBFVffdATaYK NycbCAjYeA9k26pLNiGywianuGI4uOFAOeTXaZhbCIBaaRlIffUCntS1oc/bMZ3w JV/gBHwbGizawOnWkN/MvGvdw8StJmywZyJ8F617xgZ1mzIP6nd2SCfBPRpX2s/w LTAqf3MnIR7bpc4+4qKoVPVmz+SdFDiAFgaxbZ7XeAfoxpJXQzZCYezrw6HzqF8t D7SwSnDJmFGOcMPALNbwK/anyZmwYI1A9V73pkYdCEHBftS1N+aaOh4LMiL4gs4= =5vQs -----END PGP SIGNATURE----- --MvE3iFSrEc0MFFqSF9PRoA2rfJdNneOfc-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 10:42:05 2014 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 571A5EAC; Wed, 29 Oct 2014 10:42:05 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E5083F8; Wed, 29 Oct 2014 10:42:04 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward5l.mail.yandex.net (Yandex) with ESMTP id 55D2BC412EF; Wed, 29 Oct 2014 13:42:01 +0300 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id C1E0AE4012E; Wed, 29 Oct 2014 13:42:00 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:40c:120b:a9ff:fe93:c998]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id oaWXsYcSOI-g0S8WBO7; Wed, 29 Oct 2014 13:42:00 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 12054929-7e41-4b41-a276-28d46211034b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1414579320; bh=kyUzpNy4EShnPNQbaxSGRCp2rUUtQdKF4GFQLel8elY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type; b=cwLGm89uYIGzynLKIoI7foL/9MY+PCoX5IFJrLqjmy9Ro8cFISu/H/rkK4jToco7l h2hZ1uAwtHUg+3joYv61SQbYN+O1qR2Mce+hZMU2BxJXoYWT5MZ+egRPPE8V44uZpz s25rX39yoDWzh8N8ANlBrFrAWCEFYXb/wj7CWbFk= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <5450C470.4060503@yandex.ru> Date: Wed, 29 Oct 2014 13:41:52 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-current Subject: Re: [RFC][RFT] overhaul if_gre(4) References: <5450B4E5.7020804@yandex.ru> In-Reply-To: <5450B4E5.7020804@yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Rs8QASiMnM0H3iSErbUH0qVDx9vgnbOJ" 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, 29 Oct 2014 10:42:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1Rs8QASiMnM0H3iSErbUH0qVDx9vgnbOJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29.10.2014 12:35, Andrey V. Elsukov wrote: > Hi All, >=20 > I prepared the patch for review > https://reviews.freebsd.org/D1023 For those who want to test, I prepared a tarball with sources https://people.freebsd.org/~ae/gre.tgz Modules should work on stable/10 and head/ without modifications. And they will not work on stable/9. --=20 WBR, Andrey V. Elsukov --1Rs8QASiMnM0H3iSErbUH0qVDx9vgnbOJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJUUMR1AAoJEAHF6gQQyKF6sGsIAMDOaRLdWDCRrec5V26BeoC9 3++eh+Yl9vCaXe6/piKATVb+keOxijgoVW/k8XdR5yXRfzJx5fd13PM8bjEJ71H+ TiGt6SSs134zHMIEP1kiNrVJgsEgHtpD9P7hIlntSSNYG9M/rBg860ZzldREbF6x 64hXJZQMAl6s4UH3AMpnVQNesW9zfC7yCB6OEYh8eBfl9vj8q0/onNLSphOxFruX 3d0nm1UY+jxpQV92GgqHyHcxQwcIu8XKQEkAYBwJl9qEza/iljaZW1G47x9YnJSl F/Eze4LD4PuA7IOUy7yxNTrQV5FA6+SnqoHTcq0V6JPhU6sRsMXdrgavrTMSnx4= =4PcY -----END PGP SIGNATURE----- --1Rs8QASiMnM0H3iSErbUH0qVDx9vgnbOJ-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 12:13:14 2014 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 F0B287AB; Wed, 29 Oct 2014 12:13:14 +0000 (UTC) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx11.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CAB5EEE4; Wed, 29 Oct 2014 12:13:14 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,809,1406617200"; d="p7s'?scan'208";a="163835100" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx11-out.netapp.com with ESMTP; 29 Oct 2014 05:13:03 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 29 Oct 2014 05:13:02 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::9047:8c6c:1d6e:4581%21]) with mapi id 15.00.0995.031; Wed, 29 Oct 2014 05:13:02 -0700 From: "Eggert, Lars" To: Jim Harris Subject: Re: Intel DPDK added to FreeBSD ports collection Thread-Topic: Intel DPDK added to FreeBSD ports collection Thread-Index: AQHP7Hw3gU2Lk7ICAUqArFioeiNHHpxHf76A Date: Wed, 29 Oct 2014 12:13:02 +0000 Message-ID: <6211BCB6-990D-4CE6-B780-4E7E131D94DA@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1990.1) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_95A795DB-00F9-435B-BE9C-E7EB2679991A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 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, 29 Oct 2014 12:13:15 -0000 --Apple-Mail=_95A795DB-00F9-435B-BE9C-E7EB2679991A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-10-20, at 17:40, Jim Harris wrote: > Just wanted to send a heads-up that Intel's Data Plane Development Kit > (DPDK) for high speed packet processing was added to the FreeBSD ports > collection last week under net/dpdk. ... > For any questions, please check out dpdk.org and the developer mailing = list > (dev@dpdk.org). that list seems to be more about the development of the kit, rather that = about using the kit? I've started to play with DPDK under FreeBSD, and am getting the = following warning: EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET is = not available - clock timings may be less accurate. This is with the HPET changes rpaulo@ recently committed, and /dev/hpet0 = is present. Lars= --Apple-Mail=_95A795DB-00F9-435B-BE9C-E7EB2679991A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVzCCBhsw ggUDoAMCAQICAwhPlDANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMTIwNjA3MDk0N1oXDTE0MTIwNzA3MDY0MVowOjEYMBYGA1UEAwwPbGFyc0BuZXRhcHAu Y29tMR4wHAYJKoZIhvcNAQkBFg9sYXJzQG5ldGFwcC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDS6c3AH5ZSxTExtqA4RCkRMWmh84KVsbd85iNmeq2VHJv2Pc9TXG6aZz7r3Fjp qXV+VtHlHOzZ1ncpMV0ldJMgi8F45/5WpSMEg4sXnYdtheE3drgWeR816PEaydHqSnaMNutAC7Td ykkOFHXIsVg8IblDXhfiVQiZBZd+Wz6BpyMe59gr4Bpveft18uPQIXSxE95EsDTMyd/UDLVB+AkB gHhO0+XxauzCbNUnubyiYYGOzgQ9G8J3Ewgrr/nVR+CrBCYgIsBP3foo0/h1hE7dHyI0Gl341yR7 J0AHDQ0DPIQOQtscFuRlthksCZLCfVSK6Mh6hVCOMEjVJxrgeBU3AgMBAAGjggLVMIIC0TAJBgNV HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFHIOXgd2Y3/7a+OqwJ2giDTpYULAMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGC MBoGA1UdEQQTMBGBD2xhcnNAbmV0YXBwLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGB tTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm MIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEB GoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBW YWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRw Oi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAMCLv+Qk QYJxSendSLJPbFKuMkgm1PdAVoqxKAi8HmbirBTPhxh0vzhmZ/rneCHHlqY4p6r81+Se9HsqDsB6 DBQ/IbNgs7FQlCqOvCIwbn7VK+k/0eJAyOjIaUDPoD1ZaA1AkaFjJxvD2ZUZLBNq4AvOuP52j0Dm i0FBC6pbBfnz57wuB++3P4NBTfZABbdazHlxl/2z1RGQNGov3R6zwNZLbxU2o2ftEJ48j4unuHjP islFru3GRp4dbm5JLuHjUdDyXtMw6CdDvlmWQCcAgtEfqbGDp9bSSE9vbXbgf8n6iHoIA96HnTBW BTDERdixe8t0T9AyT4ks9eHFLPL+PbwwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVk aWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0U jM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQ dcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O 2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB /wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRA W6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5z dGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww J6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1Bgsr BgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm MA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY 1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0 t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHD RHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI /EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO 7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMY u9jGfIpDLtUUGSgsg2zMGs5R4jGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAwhPlDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEwMjkxMjEzMDFaMCMGCSqGSIb3DQEJBDEWBBQFYDRu+QxklzF6VH7TXFuO w4+V7TCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwhP lDCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCE+U MA0GCSqGSIb3DQEBAQUABIIBALRoH3d7TK1Zg7AQghaMiDndo9Z0W0GGE4VCj7Mk57M4qZDgnoBR Ztonm1AfbZEFDhP3JELmaUeHZ9PVRLnsSJW9LiRShC+w9ZNfbVUzdZ5pTiuZX2YRHMrPLcgUcDEi NOfTw8txo7qfl0IkjcLo5Y9H3assl1LdhCwVAKwBKuYExzr9i+URQRijqepbU/DVkgSpdJMQzE/+ yffQLhRZCrn8UgseOz/a87rJKo9x7LKwAR0ug9gvC9xyZWmD0Jzn9wx21BHB5m0ritvlxDDs07/k tSBdO7Bjomy6970F4jMYPRjyaQHaT34nA/Ql9hs96O6Ahar9BBQxRsxMEbpDtyEAAAAAAAA= --Apple-Mail=_95A795DB-00F9-435B-BE9C-E7EB2679991A-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 14:53:57 2014 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 E35E8759 for ; Wed, 29 Oct 2014 14:53:56 +0000 (UTC) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7BBC2EE for ; Wed, 29 Oct 2014 14:53:56 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id fp1so3076406pdb.41 for ; Wed, 29 Oct 2014 07:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=u3zUqtBxTapjwuk8SF8CBklmKw+2AvgRN0Cf+KGsMT4=; b=FfRlyg3EyPItqD6RTrDCz4vG//FdvhS+OfIXXGOX27XzfBb7cNVT/iSsTinJGRyZpQ eZ285F+HWkTPhgsCgnmJmR6tgeHSqCs2fioQJbv/veOgNs7tfgL4zd4S0XxMUgz6Zna3 DtBHw5KuDmfpHlJIcH5mO4bposGVMh/g/Z6Gmrx2VcuwsBa7YKvwghLGTPDWFb+vUJ8u 0QEeiIbFOJIqe/rzdiLCF0GHrzxwRB1iCyXhR1PprcDNZYBsF6jKOaMyd5MQgzS/1rDf RBXIkdhdh5hFFwZVGqgxfODLZJxEWborr+/3ay4Xib7CM7O4hIar8aVQXl5AfqlxJ0ps LplQ== X-Received: by 10.67.30.34 with SMTP id kb2mr10594404pad.97.1414594436325; Wed, 29 Oct 2014 07:53:56 -0700 (PDT) Received: from billwin7 ([138.75.190.18]) by mx.google.com with ESMTPSA id dp4sm4598084pbc.21.2014.10.29.07.53.55 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Oct 2014 07:53:55 -0700 (PDT) From: "bycn82" To: "'Raimundo Santos'" , References: In-Reply-To: Subject: RE: ipfw fwd duplicating packets in 9.3-RELEASE Date: Wed, 29 Oct 2014 22:53:54 +0800 Message-ID: <009c01cff388$29fe7ec0$7dfb7c40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKz78czrxCpaTTjtGvxKE2W9r8mupp/LhHg Content-Language: en-sg 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, 29 Oct 2014 14:53:57 -0000 Hi, I cannot help to point out when the ICMP packet was duplicated and transfer via 2 different links, If it happens in my machine, I will call this feature "multi-homing". But what I want to say is the firewall rule fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 You can remove the "out" because "xmit" will check the "out interface". Regards, Bycn82 -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Raimundo Santos Sent: Tuesday, 28 October, 2014 3:32 PM To: freebsd-net@freebsd.org Subject: ipfw fwd duplicating packets in 9.3-RELEASE Hello list! I was testing the behaviour of fwd in ipfw from FreeBSd 9.3-RELEASE, latest updates, GENERIC kernel, in this setup: 1x FreeBSD 9.3 as router, with 3 network interfaces 5x OpenBSD 5.5 as network machines, each one connected to FreeBSD via one port. It is a virtual env. FreeBSD em0 (192.168.0.1) -> OpenBSD#1 em0 (192.168.0.2) FreeBSD em1 (192.168.1.1) -> OpenBSD#2 em0 (192.168.1.2) FreeBSD em2 (192.168.2.1) -> OpenBSD#3 em0 (192.168.2.2) FreeBSD em3 (192.168.3.1) -> OpenBSD#4 em0 (192.168.3.2) FreeBSD em4 (192.168.4.1) -> OpenBSD#5 em1 (192.168.4.2) ipfw rule: fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 in recv em4 Then a ping 192.168.1.2 was issued from OpenBSD#5. Interestingly, this rule put a packet on em0 and em1 in FreeBSD. The packet successfully arrived at OpenBSD#1, where it was discarded, and at OpenBSD#2, where it got its reply. Only these combinations of interface direction do not duplicate the packet: out xmit fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 and fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out via em1 Even out recv em4 xmit em1 leads to packet duplication. I think that it is a bad thing for PBR. As I can see from these tests, I can not use all the options to do PBR. In my real needs I have to: 1. let web traffic flow to an cache appliance (from internal network to cache, from internet to cache) 2. do NAT for the internal network under three different links In theory, fwd + in kernel NAT + one_pass=0 could solve the problem. But I am hitting my head in the wall for almost three weeks on this, only now I have the time to test in a more clear way. First I blamed the NAT, after that the one_pass=0, and now, with these results, well... Someone has an explanation about it? Something related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129036? For my real needs, I figured out that it works with <...before NAT aliasing...> fwd CACHE_IP proto tcp src-ip table(INT) dst-port 80 out recv INT_IFACE <...after NAT dealiasing...> fwd CACHE_IP proto tcp dst-ip table(INT) src-port 80 out recv EXT_IFACE But I am not confident that it will remains in good shape without knowing exactly why fwd behaves that way. Thank you in advance for your time, Raimundo Santos _______________________________________________ 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 Oct 29 15:41:41 2014 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 263AE187; Wed, 29 Oct 2014 15:41:41 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDF1AB25; Wed, 29 Oct 2014 15:41:40 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NE70074GQ9AMZ30@st11p02mm-asmtp001.mac.com>; Wed, 29 Oct 2014 15:41:37 +0000 (GMT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Intel DPDK added to FreeBSD ports collection From: Rui Paulo In-reply-to: <6211BCB6-990D-4CE6-B780-4E7E131D94DA@netapp.com> Date: Wed, 29 Oct 2014 08:41:34 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <6211BCB6-990D-4CE6-B780-4E7E131D94DA@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1990.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-29_06:2014-10-28,2014-10-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1410290156 Cc: Jim Harris , "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, 29 Oct 2014 15:41:41 -0000 On Oct 29, 2014, at 05:13, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2014-10-20, at 17:40, Jim Harris wrote: >> Just wanted to send a heads-up that Intel's Data Plane Development = Kit >> (DPDK) for high speed packet processing was added to the FreeBSD = ports >> collection last week under net/dpdk. > ... >> For any questions, please check out dpdk.org and the developer = mailing list >> (dev@dpdk.org). >=20 > that list seems to be more about the development of the kit, rather = that about using the kit? >=20 > I've started to play with DPDK under FreeBSD, and am getting the = following warning: >=20 > EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET is = not available - clock timings may be less accurate. >=20 > This is with the HPET changes rpaulo@ recently committed, and = /dev/hpet0 is present. I still haven't fixed DPDK to use /dev/hpet0. Can you add a symbolic = link /dev/hpet0 -> /dev/hpet? -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 15:49:19 2014 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 C7ABB600 for ; Wed, 29 Oct 2014 15:49:19 +0000 (UTC) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91228BD8 for ; Wed, 29 Oct 2014 15:49:19 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id g201so2484618oib.19 for ; Wed, 29 Oct 2014 08:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/psvpdfQRC5nPPl25sDB6nre2VwnQ+eJoo6mJz3jyvA=; b=hsiCVImlEXrYXbrV+c9ksQNFqnNoE9Q7FFeHD2iXSMWHRSET+oWShB6RYfEEW5Dnqe tvjIabxjPIhuouoca4EVaLWVkDiX58G8lqYMBsWzuBlNufmXm2SKJ4QETuUyok94MppA WbR12STzhhfTyWq8S4PXvVft+wR0ollntlY9GrTHUmv8qYznW2S9A17jNgl1itURlcGK 8K2jtokrb0KsUTy/WZ8LUFuyqSv+L1GygvX4TFyvCqCxk9nnmE3chYWdJCV5mGjWj3wn 8sSiCS66TAcwmx2eSeok+CSqwcAoreZ8R86A14ieyT8rrUbX1RmftjGkq61FB/0MaZuK UoWQ== MIME-Version: 1.0 X-Received: by 10.60.58.71 with SMTP id o7mr70212oeq.85.1414597758854; Wed, 29 Oct 2014 08:49:18 -0700 (PDT) Received: by 10.202.168.84 with HTTP; Wed, 29 Oct 2014 08:49:18 -0700 (PDT) In-Reply-To: References: <6211BCB6-990D-4CE6-B780-4E7E131D94DA@netapp.com> Date: Wed, 29 Oct 2014 08:49:18 -0700 Message-ID: Subject: Re: Intel DPDK added to FreeBSD ports collection From: Jim Harris To: Rui Paulo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , "Eggert, Lars" 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, 29 Oct 2014 15:49:19 -0000 On Wed, Oct 29, 2014 at 8:41 AM, Rui Paulo wrote: > On Oct 29, 2014, at 05:13, Eggert, Lars wrote: > > > > Hi, > > > > On 2014-10-20, at 17:40, Jim Harris wrote: > >> Just wanted to send a heads-up that Intel's Data Plane Development Kit > >> (DPDK) for high speed packet processing was added to the FreeBSD ports > >> collection last week under net/dpdk. > > ... > >> For any questions, please check out dpdk.org and the developer mailing > list > >> (dev@dpdk.org). > > > > that list seems to be more about the development of the kit, rather that > about using the kit? > dev@dpdk.org is mostly development related, but I have seen lots of questions like yours on the list too. > > > I've started to play with DPDK under FreeBSD, and am getting the > following warning: > > > > EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET is > not available - clock timings may be less accurate. > > > > This is with the HPET changes rpaulo@ recently committed, and > /dev/hpet0 is present. > > I still haven't fixed DPDK to use /dev/hpet0. Can you add a symbolic link > /dev/hpet0 -> /dev/hpet? > > This is certainly one problem, but it also looks like DPDK should spit out an error message when it cannot open /dev/hpet. So I suspect CONFIG_RTE_LIBEAL_USE_HPET needs to be set to 'y' as well in your config file. -Jim -- > Rui Paulo > > > > From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 15:50:28 2014 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 DF4E4766; Wed, 29 Oct 2014 15:50:28 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F875BFB; Wed, 29 Oct 2014 15:50:27 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NE7007BCQNZ6Y40@st11p02mm-asmtp001.mac.com>; Wed, 29 Oct 2014 15:50:25 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-29_06:2014-10-28,2014-10-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1410290156 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers From: Rui Paulo In-reply-to: <1414525275.43009.3.camel@bruno> Date: Wed, 29 Oct 2014 08:50:23 -0700 Content-transfer-encoding: quoted-printable Message-id: <87B376C9-72D1-41D8-868C-45908D642CA1@me.com> References: <1414525275.43009.3.camel@bruno> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1990.1) Cc: FreeBSD 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, 29 Oct 2014 15:50:29 -0000 On Oct 28, 2014, at 12:41, Sean Bruno wrote: >=20 > It looks like recent HEAD seems to fail intermittently here on my home > network. It will recover, but urtwn(4) seems to lose an ack or > something on txmit. turning on debug, yields this message during the > hang event. >=20 > hw.usb.urtwn.debug: 1 >=20 > Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of = xmit > buffers > Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue > Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of = xmit > buffers > Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue That means the firmware is stuck and is holding transmit buffers, so we = have no more in the unused list. > Additionally, I get the following at module load time: >=20 > urtwn0: > on usbus0 > urtwn0: could not read efuse byte at address 0x10 > urtwn0: could not read efuse byte at address 0x18 I'm not sure what this is. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 16:30:27 2014 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 3FF3DFEA for ; Wed, 29 Oct 2014 16:30:27 +0000 (UTC) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08FF014A for ; Wed, 29 Oct 2014 16:30:26 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id wp4so2686420obc.11 for ; Wed, 29 Oct 2014 09:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sc24Hos4gPkmY+Jd/gBS41cxHgpwgjqRhmBGdx7VMQU=; b=teWKyRcaRI3M89L9h/qJ5uSiW8dtD//OV3WgwE7AOMmG4SKwF18JGu2FiMzxp36VjO tgEXotCM7qjMIpN1GNQ+WYz2dgBjE8PPKEPE+trFU2uIVfOJjBQ4ak+9hfkB7TmLV/jd vSJ6KsPa8KUKa9IQA4U7/EVll5xaOOvpbYkpP/1gCkPfIoVQMTBp+gvgUkdQjmhZSkn0 KbHRBoANetvMZ3mP1jqpQA5tALjgQBXyYuZ6MfYBzw46dEo7vcGEIXPupAAfv8XM5nFz ash5UxT9Dxe0ifT2R+AZ9RAhsZW4P2y/yODipAQ/T7zljeXrAjqJQFzxfq9A+Qm83MWw kAQg== X-Received: by 10.182.89.194 with SMTP id bq2mr9587648obb.12.1414600226340; Wed, 29 Oct 2014 09:30:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.93.40 with HTTP; Wed, 29 Oct 2014 09:30:06 -0700 (PDT) In-Reply-To: <009c01cff388$29fe7ec0$7dfb7c40$@gmail.com> References: <009c01cff388$29fe7ec0$7dfb7c40$@gmail.com> From: Raimundo Santos Date: Wed, 29 Oct 2014 14:30:06 -0200 Message-ID: Subject: Re: ipfw fwd duplicating packets in 9.3-RELEASE To: bycn82 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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, 29 Oct 2014 16:30:27 -0000 On 29 October 2014 12:53, bycn82 wrote: > > Hi, > I cannot help to point out when the ICMP packet was duplicated and transfer > via 2 different links, If it happens in my machine, I will call this feature > "multi-homing". That is a bit off topic, but how and undesired behaviour could be a feature? It is not only undesired, but it is also undocumented. If I filter incoming packtes, I got it sent to the original and to the fwd destinations, by my tests. I can not see how it is multi-homing. What I know by multi-homing is: two or more interconnections with the same other network, or to the Internet. It implies more care to the outgoing and incoming paths. Who leaves from link 1 will enter via link 1? It is ok to happen that way? Only the context can say that. In my case the packet not only get out via two different links, but it is reaching two *different* machines in different networks. > > But what I want to say is the firewall rule > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 > You can remove the "out" because "xmit" will check the "out interface". Thank you for the clarification. > > > Regards, > Bycn82 Regards, Raimundo Santos > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] > On Behalf Of Raimundo Santos > Sent: Tuesday, 28 October, 2014 3:32 PM > To: freebsd-net@freebsd.org > Subject: ipfw fwd duplicating packets in 9.3-RELEASE > > Hello list! > > I was testing the behaviour of fwd in ipfw from FreeBSd 9.3-RELEASE, latest > updates, GENERIC kernel, in this setup: > > 1x FreeBSD 9.3 as router, with 3 network interfaces 5x OpenBSD 5.5 as > network machines, each one connected to FreeBSD via one port. > > It is a virtual env. > > FreeBSD em0 (192.168.0.1) -> OpenBSD#1 em0 (192.168.0.2) FreeBSD em1 > (192.168.1.1) -> OpenBSD#2 em0 (192.168.1.2) FreeBSD em2 (192.168.2.1) -> > OpenBSD#3 em0 (192.168.2.2) FreeBSD em3 (192.168.3.1) -> OpenBSD#4 em0 > (192.168.3.2) FreeBSD em4 (192.168.4.1) -> OpenBSD#5 em1 (192.168.4.2) > > ipfw rule: > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 in recv em4 > > Then a ping 192.168.1.2 was issued from OpenBSD#5. > > Interestingly, this rule put a packet on em0 and em1 in FreeBSD. The packet > successfully arrived at OpenBSD#1, where it was discarded, and at OpenBSD#2, > where it got its reply. > > Only these combinations of interface direction do not duplicate the packet: > out xmit > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 > > and > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out via em1 > > Even out recv em4 xmit em1 leads to packet duplication. > > I think that it is a bad thing for PBR. As I can see from these tests, I can > not use all the options to do PBR. > > In my real needs I have to: > > 1. let web traffic flow to an cache appliance (from internal network to > cache, from internet to cache) > > 2. do NAT for the internal network under three different links > > In theory, fwd + in kernel NAT + one_pass=0 could solve the problem. But I > am hitting my head in the wall for almost three weeks on this, only now I > have the time to test in a more clear way. First I blamed the NAT, after > that the one_pass=0, and now, with these results, well... > > Someone has an explanation about it? Something related to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129036? > > For my real needs, I figured out that it works with > > <...before NAT aliasing...> > fwd CACHE_IP proto tcp src-ip table(INT) dst-port 80 out recv INT_IFACE > <...after NAT dealiasing...> fwd CACHE_IP proto tcp dst-ip table(INT) > src-port 80 out recv EXT_IFACE > > But I am not confident that it will remains in good shape without knowing > exactly why fwd behaves that way. > > Thank you in advance for your time, > Raimundo Santos > _______________________________________________ > 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 Oct 29 17:01:30 2014 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 620C5330 for ; Wed, 29 Oct 2014 17:01:30 +0000 (UTC) Received: from phlegethon.blisses.org (phlegethon.blisses.org [50.56.97.101]) (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 414056EA for ; Wed, 29 Oct 2014 17:01:29 +0000 (UTC) Received: from blisses.org (cocytus.blisses.org [23.25.209.73]) by phlegethon.blisses.org (Postfix) with ESMTPSA id 7FC061F13CF; Wed, 29 Oct 2014 13:01:28 -0400 (EDT) Date: Wed, 29 Oct 2014 13:01:26 -0400 From: Mason Loring Bliss To: Yonghyeon PYUN Subject: Re: Very bad Realtek problems Message-ID: <20141029170126.GG17150@blisses.org> References: <20141027195124.GI17150@blisses.org> <20141028015020.GB1054@michelle.fasterthan.com> <20141028034445.GR17150@blisses.org> <20141029014630.GA2503@michelle.fasterthan.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029014630.GA2503@michelle.fasterthan.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 29 Oct 2014 17:01:30 -0000 On Wed, Oct 29, 2014 at 10:46:30AM +0900, Yonghyeon PYUN wrote: > Given that you can reliably reproduce the issue, let's check simple ones > first. Just as a quick update, I couldn't tolerate the network outages any more as they were impacting my work, so I bought an Intel NIC. That said, this will actually free me up to do more debugging of the Realtek as soon as I get a chance to finish setting up a small test network - I'll be able to look at both sides of interactions instead of depending on the flaky interface. > If you think the issue intermittently happens regardless of network load, > try attached patch. I'm not sure whether the patch makes any difference for > you since many PCIe NICs don't implement CLKREQ feature. It's just a wild > guess. This is an onboard NIC, for what it's worth, on my: Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: M4A88T-M Version: Rev X.0x I'm not sure if that changes it as compared with a plug-in PCIe device. Just mentioning it for completeness. -- Mason Loring Bliss mason@blisses.org Ewige Blumenkraft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scene I From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 18:05:55 2014 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 09AB892B for ; Wed, 29 Oct 2014 18:05:55 +0000 (UTC) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id AB696EAC for ; Wed, 29 Oct 2014 18:05:54 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id DB7C7D60D14 for ; Thu, 30 Oct 2014 05:05:45 +1100 (AEDT) Date: Thu, 30 Oct 2014 05:05:45 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: net@freebsd.org Subject: inet_pton() broken Message-ID: <20141030024343.X1825@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=BdjhjNd2 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=81UjlLxjhDmUnyrd0swA:9 a=4hHBz5FF3RexTsx6:21 a=Xe7zWXNK51ZHWNYv:21 a=CjuIK1q_8ugA:10 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, 29 Oct 2014 18:05:55 -0000 inet_pton() has regressed to a primitive form that doesn't support hex or octal, at least for ipv4. This breaks at least gethostbyname() on hosts in /etc/hosts. /etc/hosts is still documented as supporting the general form and as "using" [sic] inet_addr(3): % Network addresses are specified in the conventional ``.'' (dot) notation % using the inet_addr(3) routine from the Internet address manipulation % library, inet(3). Host names may contain any printable character other % than a field delimiter, newline, or comment character. This documentation hasn't changed since 4.4BSD. 4.4BSD doesn't even have inet_pton(). It actually uses inet_aton() in gethostbyname(), but inet_aton() is just a inet_addr(3) with a modified API. FreeBSD has used inet_pton() in gethostent() for a long time. It used to work. The format of inet_pton() is undocumented in FreeBSD, except to say that it doesn't support shortened addresses: % The inet_pton() function converts a presentation format address (that is, % printable form as held in a character string) to network format (usually % a struct in_addr or some other internal binary representation, in network % byte order). It returns 1 if the address was valid for the specified % address family, or 0 if the address was not parseable in the specified % address family, or -1 if some system error occurred (in which case errno % will have been set). This function is presently valid for AF_INET and % AF_INET6. % % STANDARDS % The inet_ntop() and inet_pton() functions conform to X/Open Networking % Services Issue 5.2 (``XNS5.2''). Note that inet_pton() does not accept % 1-, 2-, or 3-part dotted addresses; all four parts must be specified and % are interpreted only as decimal values. This is a narrower input set % than that accepted by inet_aton(). POSIX.1-2001 specifies both in_addr() and inet_pton(), but not inet_aton(). Unlike the above, it says what the format for inet_pton() is -- for ipv4, it is just decimal dotted with all 4 components required. So the bug is in gethostbyname() still using inet_pton() after it regressed to be broken to X/Open/POSIX spec. Many programs don't have this bug. The bug broke ifconfig on hosts by name with the names in /etc/hosts (I use some small octal numbers there to line up fields). It was confusing for ifconfig to work for the same addresses that it doesn't work on, then the addresses are given on the command line instead of in /etc/hosts. In /usr/src/*bin, there are now 61 references to inet_pton(), 28 to inet_aton() and 18 to inet_ntoa(). In a 10 year old soure tree where inet_pton() was not broken to spec, there were 35 to inet_pton(), 26 to inet_aton() and 30 to inet_addr(). It looks like there are just a few more ipv6 applications and most inet_aton()s are unchanged, but half the inet_addr()s were changed to the incompatible inet_pton() instead of to the compatible inet_aton(). Indeed, many of the new inet_pton()'s are in mountd, nfsd and rpc.statd. This might break /etc/exports files like /etc/hosts. The format of addresses is more or less documented in exports(5) as being the inet_addr(3) format for ipv4 but more restricted for ipv6: % The third component of a line specifies the host set to which the line % applies. The set may be specified in three ways. The first way is to % list the host name(s) separated by white space. (Standard Internet % ``dot'' addresses may be used in place of names.) The second way is to % % EXAMPLES % ... % /u -maproot=bin: -network 131.104.48 -mask 255.255.255.0 Network addresses are special and use the reduced format. This cannot be parsed by inet_pton(). This probably still works, because there is an RFC related to the bug I am reporting, and the code follows the RFC to avoid regressions in the ipv4 case: mountd parses -network by checking for a hex digit in ; then it calls getaddrinfo(), which has: % switch (afd->a_af) { % case AF_INET: % /* % * RFC3493 requires getaddrinfo() to accept AF_INET formats % * that are accepted by inet_addr() and its family. The % * accepted forms includes the "classful" one, which inet_pton % * does not accept. So we need to separate the case for % * AF_INET. % */ % if (inet_aton(hostname, (struct in_addr *)pton) != 1) % return 0; % break; % default: % if (inet_pton(afd->a_af, hostname, pton) != 1) % return 0; % break; % } Old versions had the AF_INET case under #if 1 with the cryptic comment /*X/Open Spec*/ (does that mean not broken to spec?). % ... % The file system rooted at /a is also exported to the IPv6 network % 3ffe:1ce1:1:fe80:: address, using the upper 64 bits as the prefix. Note % that, unlike with IPv4 network addresses, the specified network address % must be complete, and not just contain the upper bits. With IPv6 % addresses, the -mask option must not be used. This says that the short form is supposed to be accepted in the ipv4 case only. I doubt that it is, because mountd is not as careful as getaddrinfo(). I debugged gethostname() as far as seeing gethostent() call inet_pton(). Apparently, gethostent() also isn't as careful as getaddrinfo(). The RFC is large, but doesn't cover gethostent() at all or gethostname() except to say that it is inadequate for ipv6 so new functions (getaddrinfo()?) are being invented. I think that means ifconfig shouldn't be using gethostname() and FreeBSD's gethostname() shouldn't try so hard to support ipv6, or at least be more complicated so as not to change its behaviour for ipv4. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 00:30:44 2014 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 8B8683A5 for ; Thu, 30 Oct 2014 00:30:44 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E9A0DE for ; Thu, 30 Oct 2014 00:30:44 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id rd3so4278706pab.13 for ; Wed, 29 Oct 2014 17:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ZLeb0Fz4JXQXXuzuCAUJ0EhhMS6mc85VymLdjx/U6NU=; b=b61U9m83MImryt2jPVdnC1s9vCJBg9YcoOXZH7hcfguNGtuRa6vxrkZ0XPqi8BrnHO cNK48woWzvhQ7e8vlOhDxB/zmnJ4sncjZ9pc6mJd/d0gBeX/+LqfJpphsZwj+NK/+FKt mgdcVnJ5L8sw8oMD8wHh5APWmURDdgI8w41k9q4GtnX/AQLaMxvg5SNGQhWqnmyoUoeI IUOrys8IJm5VaIFYIYlJBwpP2L3Ml68ncl5d6+r6vK/IjDceKVflZdD6Rcb0CTSKziWa Nv2AQdgm7qWLTXaDDp9KHAIXAwjOrxT6BR3AfDgX1pPwzvCkmKhFf/StpAnr7QyGA2Ss MInQ== X-Received: by 10.68.65.71 with SMTP id v7mr12886602pbs.125.1414629043934; Wed, 29 Oct 2014 17:30:43 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id n3sm5402924pda.7.2014.10.29.17.30.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 Oct 2014 17:30:42 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 30 Oct 2014 09:30:33 +0900 Date: Thu, 30 Oct 2014 09:30:33 +0900 To: Mason Loring Bliss Subject: Re: Very bad Realtek problems Message-ID: <20141030003033.GA2537@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20141027195124.GI17150@blisses.org> <20141028015020.GB1054@michelle.fasterthan.com> <20141028034445.GR17150@blisses.org> <20141029014630.GA2503@michelle.fasterthan.com> <20141029170126.GG17150@blisses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141029170126.GG17150@blisses.org> User-Agent: Mutt/1.4.2.3i 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: Thu, 30 Oct 2014 00:30:44 -0000 On Wed, Oct 29, 2014 at 01:01:26PM -0400, Mason Loring Bliss wrote: > On Wed, Oct 29, 2014 at 10:46:30AM +0900, Yonghyeon PYUN wrote: > > > Given that you can reliably reproduce the issue, let's check simple ones > > first. > > Just as a quick update, I couldn't tolerate the network outages any more as > they were impacting my work, so I bought an Intel NIC. That said, this will > actually free me up to do more debugging of the Realtek as soon as I get a > chance to finish setting up a small test network - I'll be able to look at > both sides of interactions instead of depending on the flaky interface. > Ok, if you happen to find spare time on testing, let me know your findings. > > > If you think the issue intermittently happens regardless of network load, > > try attached patch. I'm not sure whether the patch makes any difference for > > you since many PCIe NICs don't implement CLKREQ feature. It's just a wild > > guess. > > This is an onboard NIC, for what it's worth, on my: > Yes, it's very common to see LOM version in these days. > Base Board Information > Manufacturer: ASUSTeK Computer INC. > Product Name: M4A88T-M > Version: Rev X.0x > > I'm not sure if that changes it as compared with a plug-in PCIe device. Just > mentioning it for completeness. There is no much difference for driver between LOM and standalone NIC. LOM version may have some modifications compared to engineering samples I have. And motherboard vendors are free to program EEPROM/FLASH of NIC to meet their needs. I don't think the motherboard vendor heavily changed the NIC configuration though. From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 02:37:37 2014 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 CC7B14D5 for ; Thu, 30 Oct 2014 02:37:37 +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 B39DCDCB for ; Thu, 30 Oct 2014 02:37:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9U2bbqI049371 for ; Thu, 30 Oct 2014 02:37:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 188032] [lo] IPv6 on lo never leaves 'tentative' state if configured with prefixlen 128 Date: Thu, 30 Oct 2014 02:37:37 +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.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hrs@FreeBSD.org X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: hrs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 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, 30 Oct 2014 02:37:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188032 Hiroki Sato changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hrs@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |hrs@FreeBSD.org --- Comment #9 from Hiroki Sato --- Take. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 02:53:44 2014 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 EA6B0945; Thu, 30 Oct 2014 02:53:44 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85020F7B; Thu, 30 Oct 2014 02:53:44 +0000 (UTC) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.8/8.14.8) with ESMTP id s9U2qgpc073162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Oct 2014 10:52:42 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.8/8.14.8/Submit) id s9U2qgVL073161; Thu, 30 Oct 2014 10:52:42 +0800 (CST) (envelope-from kevlo) Date: Thu, 30 Oct 2014 10:52:41 +0800 From: Kevin Lo To: sbruno@freebsd.org Subject: Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers Message-ID: <20141030025241.GA73148@ns.kevlo.org> References: <1414525275.43009.3.camel@bruno> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1414525275.43009.3.camel@bruno> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD 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: Thu, 30 Oct 2014 02:53:45 -0000 On Tue, Oct 28, 2014 at 12:41:15PM -0700, Sean Bruno wrote: > > It looks like recent HEAD seems to fail intermittently here on my home > network. It will recover, but urtwn(4) seems to lose an ack or > something on txmit. turning on debug, yields this message during the > hang event. > > hw.usb.urtwn.debug: 1 > > Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit > buffers > Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue > Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit > buffers > Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue > > Additionally, I get the following at module load time: > > urtwn0: > on usbus0 > urtwn0: could not read efuse byte at address 0x10 > urtwn0: could not read efuse byte at address 0x18 Strange. What the wlan dongle model do you use? I have the RTL8188CUS wireless usb adaptor (Edimax EW-7811Un), but I cannot reproduce that issue. Kevin From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 04:24:34 2014 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 9495E894; Thu, 30 Oct 2014 04:24:34 +0000 (UTC) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66B35B6C; Thu, 30 Oct 2014 04:24:34 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id z10so4360936pdj.29 for ; Wed, 29 Oct 2014 21:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9VMUDdhKaNCUrwzGu5Ba+FhLnYQX+/OK/XW4GIlKX1A=; b=lZO4UdIuYXuEpxfKLHVyqpHrdzAr6u1EyK7VzW8XX+phd5dgiOi8MO9Bx4Y55shXfK mQmwrR2VceOSbB/gydREc/bITfZ5/QHNSisPk/nvHxFb2LObyYJ6xniPYkFEq8iUvLOL npmTLwRLKvY45plVdK94E+eLv8w4KPU3AjERyvQxQZwyhAirictULkVeO+Y2h8vRo2h1 QcXXVgcYUQJVn0vR4erBMCBt4Bp34+kDPqmBV6uZHVq9mPjphhDWfQ8fYRXKNr/BznCw g0Dz7unEc93kyyhrSG+d0+oiH5SSUEanFEvowK6QGgg0gTyL7qSKeeeu7MgHvDJeBcdv iHlQ== MIME-Version: 1.0 X-Received: by 10.70.96.162 with SMTP id dt2mr14761368pdb.29.1414643074006; Wed, 29 Oct 2014 21:24:34 -0700 (PDT) Received: by 10.70.42.228 with HTTP; Wed, 29 Oct 2014 21:24:33 -0700 (PDT) In-Reply-To: <20141030063053.12608314@X220.alogt.com> References: <009101cff386$29c30e50$7d492af0$@gmail.com> <20141030063053.12608314@X220.alogt.com> Date: Thu, 30 Oct 2014 12:24:33 +0800 Message-ID: Subject: Re: performance of the swtich/case statements From: bycn82 To: Erich Dollansky , FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ipfw 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, 30 Oct 2014 04:24:34 -0000 Hi, According to my understanding in Java programming, the compiler will automatically store the values into a table and jump to the correct one according to the value only when the condition values are in running number, for example. swtich(a){ case 1: code block 1 case 2: code block 2 case 3: code block 3 case 4: code block 4 default: code block 5 } it will be handled by an array 1-->code block 1 2-->code block 2 3-->code block 3 4-->code block 4 others-->code block 5 so when the value N is greater than or lesser than 1, it will be directly jump to the "code block 5" otherwise, it will jump to N, because call the cases are nice in running numbers, but when the cases are messy, it will by just like lots of if/else On Thu, Oct 30, 2014 at 6:30 AM, Erich Dollansky < erichsfreebsdlist@alogt.com> wrote: > Hi, > > On Wed, 29 Oct 2014 22:39:34 +0800 > "bycn82" wrote: > > > It is using the switch/case statement to make the code clear in the > > > > I am not a C programmer, so I am not clear how the switch/case will be > > optimized by the compiler in FreeBSD. But I used to write a compiler > > by myself and I use a hash table to handle all the conditions in the > > case statements because my compiler don't care about performance!, > > But in C it is different, the case statement can only accept "int" > > values, so I don't think it will use hash or what , it should be > > directly use an array(), So whether it can be optimized it depends on > > the conditions in the switch/case statements, and I noticed that the > > cases statement in the 2 loops are not arranging the opcode in > > running number, so does the compiler smart enough to optimize it? > > > > > I did not check recently. It was already a long, long time ago, that > compilers checked the limits and used the values as an index into a > table to jump to the code. I hope that this did not get changed. > > With other words, the order in the code does not matter. The only > optimisation the compiler can do, is not to use a table if the > statement consists of a low number of entries only. > > Erich > From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 18:09:51 2014 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 59E7212B; Thu, 30 Oct 2014 18:09:51 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 3A24FDF2; Thu, 30 Oct 2014 18:09:51 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 7FE74193964; Thu, 30 Oct 2014 18:09:50 +0000 (UTC) Subject: Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers From: Sean Bruno Reply-To: sbruno@freebsd.org To: Kevin Lo In-Reply-To: <20141030025241.GA73148@ns.kevlo.org> References: <1414525275.43009.3.camel@bruno> <20141030025241.GA73148@ns.kevlo.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Oct 2014 11:09:49 -0700 Message-ID: <1414692589.1773.11.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD 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: Thu, 30 Oct 2014 18:09:51 -0000 On Thu, 2014-10-30 at 10:52 +0800, Kevin Lo wrote: > On Tue, Oct 28, 2014 at 12:41:15PM -0700, Sean Bruno wrote: > > > > It looks like recent HEAD seems to fail intermittently here on my home > > network. It will recover, but urtwn(4) seems to lose an ack or > > something on txmit. turning on debug, yields this message during the > > hang event. > > > > hw.usb.urtwn.debug: 1 > > > > Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit > > buffers > > Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue > > Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit > > buffers > > Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue > > > > Additionally, I get the following at module load time: > > > > urtwn0: > > on usbus0 > > urtwn0: could not read efuse byte at address 0x10 > > urtwn0: could not read efuse byte at address 0x18 > > Strange. What the wlan dongle model do you use? I have the RTL8188CUS > wireless usb adaptor (Edimax EW-7811Un), but I cannot reproduce that issue. > > Kevin urtwn0: on usbus0 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R This is one that I "aquired" from hiren@ ... I assume its supposed to work fine. sean From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 19:11:49 2014 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 E0DCBF5E; Thu, 30 Oct 2014 19:11:49 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 C019E64F; Thu, 30 Oct 2014 19:11:49 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 5E8EA193964; Thu, 30 Oct 2014 19:11:48 +0000 (UTC) Subject: Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers From: Sean Bruno Reply-To: sbruno@freebsd.org To: Kevin Lo In-Reply-To: <1414692589.1773.11.camel@bruno> References: <1414525275.43009.3.camel@bruno> <20141030025241.GA73148@ns.kevlo.org> <1414692589.1773.11.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Oct 2014 12:11:47 -0700 Message-ID: <1414696307.1773.12.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD 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: Thu, 30 Oct 2014 19:11:50 -0000 On Thu, 2014-10-30 at 11:09 -0700, Sean Bruno wrote: > On Thu, 2014-10-30 at 10:52 +0800, Kevin Lo wrote: > > On Tue, Oct 28, 2014 at 12:41:15PM -0700, Sean Bruno wrote: > > > > > > It looks like recent HEAD seems to fail intermittently here on my home > > > network. It will recover, but urtwn(4) seems to lose an ack or > > > something on txmit. turning on debug, yields this message during the > > > hang event. > > > > > > hw.usb.urtwn.debug: 1 > > > > > > Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit > > > buffers > > > Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue > > > Oct 28 12:34:58 bruno kernel: _urtwn_getbuf: _urtwn_getbuf: out of xmit > > > buffers > > > Oct 28 12:34:58 bruno kernel: urtwn_getbuf: urtwn_getbuf: stop queue > > > > > > Additionally, I get the following at module load time: > > > > > > urtwn0: > > > on usbus0 > > > urtwn0: could not read efuse byte at address 0x10 > > > urtwn0: could not read efuse byte at address 0x18 > > > > Strange. What the wlan dongle model do you use? I have the RTL8188CUS > > wireless usb adaptor (Edimax EW-7811Un), but I cannot reproduce that issue. > > > > Kevin > > > urtwn0: > on usbus0 > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R > > This is one that I "aquired" from hiren@ ... I assume its supposed to > work fine. > > sean > I connected this device to a seperate computer and was seeing the same type of timeouts. Just wanted to make sure that it wasn't a USB controller issues. sean From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 19:39:42 2014 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 D1F3B34A; Thu, 30 Oct 2014 19:39:42 +0000 (UTC) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C15C94B; Thu, 30 Oct 2014 19:39:42 +0000 (UTC) Received: by mail-yh0-f54.google.com with SMTP id 29so2119855yhl.41 for ; Thu, 30 Oct 2014 12:39:41 -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=4XNdPwyB2tfjCIHfH2vkgq9PtZ+pgGA+PapNli5mkYU=; b=L4zd1dbjAlLb/LveqOLXxre9QPLsCG841PTQ7WySa5L8oo/70zBqCS2ZnUYb7YSwhI XyZFlqzb9+UfCzQTn9ym0dh2CoRdCdLg8HQrULNyr3KgzC0xe0yyUt6uHD1GF5ztZSZF DM3fAyQhIeJkV+LXHtO56H2dhzgp6SUFp8AYy9nKG5Jc0+f7Ke9yjw/bAIWfSPd6ulVK fAtoA2Lsq+5wPbvqMuC3b5rrZbxcAz6lLcgwbJMlOe1A2uniJThJCREagI6ei7WRoeVI cfl5u63QKsEnxtproENpTuMaZ2uRaxKLYrYTwTxA7mfB9+zviTt4AdZzisiVYqwfKVBC Tmsg== MIME-Version: 1.0 X-Received: by 10.170.221.193 with SMTP id n184mr19703505ykf.25.1414697981658; Thu, 30 Oct 2014 12:39:41 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Thu, 30 Oct 2014 12:39:41 -0700 (PDT) In-Reply-To: References: <20131226175410.GA15332@lath.rinet.ru> Date: Thu, 30 Oct 2014 12:39:41 -0700 X-Google-Sender-Auth: roAY8z0yHtwL8LHtJsljj2CKXUM Message-ID: Subject: Re: buf_ring in HEAD is racy From: "K. Macy" To: "De La Gueronniere, Marc" Content-Type: text/plain; charset=UTF-8 Cc: Ryan Stone , Oleg Bulyzhin , "Charbon, Julien" , freebsd-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: Thu, 30 Oct 2014 19:39:42 -0000 > > I also suspect there are further problems with buf_ring. A full wrap > around of the atomically swapped value is possible. I.e. the code thinks > it just atomically updated a head/tail index when in fact a full wrap > around occurred leading to undefined land. A relatively simple way to > avoid this is to only mask on ring array access, and to let the > head/tail/prod/cons indices overflow the array. > Up until Rui Paulo complained to me of packet drops with buf_ring a couple of days ago I had thought that this patch had been committed. This patch (now 273866) fixes the problem for him. Without further scrutiny and testing I won't provide the UL guarantee for buf_ring_enqueue, but this is a clear improvement. -K From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 23:42:01 2014 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 DE7098F4; Thu, 30 Oct 2014 23:42:00 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (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 B5576354; Thu, 30 Oct 2014 23:42:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=WxOiZICDi4Fxs7ESElswXGhp9FVcedpVd63mEOdP19o=; b=ckXTJTtjCHRM0MH2isErEP8ve4IPTwXF5z2mIgMcj+jSkzXNlT92It9TQyknD9aegJ7zmlRb4BjA134xT5lfPpFeIJ2ldsMmlthl2swGSJ3+VjIb5JRJ03T9D6ygjC8DB68xBKtxl16in5gpspjqeJm2ugXsAmmNoDSJLTzjBQk=; Received: from [182.9.153.44] (port=13067 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpa (Exim 4.82) (envelope-from ) id 1XjzLl-004LHS-9y; Thu, 30 Oct 2014 17:41:53 -0600 Date: Fri, 31 Oct 2014 07:41:49 +0800 From: Erich Dollansky To: bycn82 Subject: Re: performance of the swtich/case statements Message-ID: <20141031074149.591c09de@X220.alogt.com> In-Reply-To: References: <009101cff386$29c30e50$7d492af0$@gmail.com> <20141030063053.12608314@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Net , freebsd-ipfw 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, 30 Oct 2014 23:42:01 -0000 Hi, On Thu, 30 Oct 2014 12:24:33 +0800 bycn82 wrote: > Hi, > According to my understanding in Java programming, the compiler will aren't we talking about C here? Erich > automatically store the values into a table and jump to the correct > one according to the value only when the condition values are in > running number, > > for example. > > swtich(a){ > case 1: code block 1 > case 2: code block 2 > case 3: code block 3 > case 4: code block 4 > default: code block 5 > } > > it will be handled by an array > 1-->code block 1 > 2-->code block 2 > 3-->code block 3 > 4-->code block 4 > others-->code block 5 > > so when the value N is greater than or lesser than 1, it will be > directly jump to the "code block 5" > otherwise, it will jump to N, because call the cases are nice in > running numbers, > > but when the cases are messy, it will by just like lots of if/else > > > On Thu, Oct 30, 2014 at 6:30 AM, Erich Dollansky < > erichsfreebsdlist@alogt.com> wrote: > > > Hi, > > > > On Wed, 29 Oct 2014 22:39:34 +0800 > > "bycn82" wrote: > > > > > It is using the switch/case statement to make the code clear in > > > the > > > > > > I am not a C programmer, so I am not clear how the switch/case > > > will be optimized by the compiler in FreeBSD. But I used to write > > > a compiler by myself and I use a hash table to handle all the > > > conditions in the case statements because my compiler don't care > > > about performance!, But in C it is different, the case statement > > > can only accept "int" values, so I don't think it will use hash > > > or what , it should be directly use an array(), So whether it can > > > be optimized it depends on the conditions in the switch/case > > > statements, and I noticed that the cases statement in the 2 loops > > > are not arranging the opcode in running number, so does the > > > compiler smart enough to optimize it? > > > > > > > > I did not check recently. It was already a long, long time ago, that > > compilers checked the limits and used the values as an index into a > > table to jump to the code. I hope that this did not get changed. > > > > With other words, the order in the code does not matter. The only > > optimisation the compiler can do, is not to use a table if the > > statement consists of a low number of entries only. > > > > Erich > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 05:30:56 2014 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 D2919B0F for ; Fri, 31 Oct 2014 05:30:56 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id BEB50832 for ; Fri, 31 Oct 2014 05:30:56 +0000 (UTC) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 3EA1E341F854 for ; Thu, 30 Oct 2014 22:30:50 -0700 (PDT) Message-ID: <54531E89.3010205@freebsd.org> Date: Thu, 30 Oct 2014 22:30:49 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: performance of the swtich/case statements References: <009101cff386$29c30e50$7d492af0$@gmail.com> <20141030063053.12608314@X220.alogt.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.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, 31 Oct 2014 05:30:56 -0000 Please run compiler with -O2 -S to get the assembly to see what will actually happen. thanks, -Alfred On 10/29/14 9:24 PM, bycn82 wrote: > Hi, > According to my understanding in Java programming, the compiler will > automatically store the values into a table and jump to the correct one > according to the value only when the condition values are in running > number, > > for example. > > swtich(a){ > case 1: code block 1 > case 2: code block 2 > case 3: code block 3 > case 4: code block 4 > default: code block 5 > } > > it will be handled by an array > 1-->code block 1 > 2-->code block 2 > 3-->code block 3 > 4-->code block 4 > others-->code block 5 > > so when the value N is greater than or lesser than 1, it will be directly > jump to the "code block 5" > otherwise, it will jump to N, because call the cases are nice in running > numbers, > > but when the cases are messy, it will by just like lots of if/else > > > On Thu, Oct 30, 2014 at 6:30 AM, Erich Dollansky < > erichsfreebsdlist@alogt.com> wrote: > >> Hi, >> >> On Wed, 29 Oct 2014 22:39:34 +0800 >> "bycn82" wrote: >> >>> It is using the switch/case statement to make the code clear in the >>> >>> I am not a C programmer, so I am not clear how the switch/case will be >>> optimized by the compiler in FreeBSD. But I used to write a compiler >>> by myself and I use a hash table to handle all the conditions in the >>> case statements because my compiler don't care about performance!, >>> But in C it is different, the case statement can only accept "int" >>> values, so I don't think it will use hash or what , it should be >>> directly use an array(), So whether it can be optimized it depends on >>> the conditions in the switch/case statements, and I noticed that the >>> cases statement in the 2 loops are not arranging the opcode in >>> running number, so does the compiler smart enough to optimize it? >>> >>> >> I did not check recently. It was already a long, long time ago, that >> compilers checked the limits and used the values as an index into a >> table to jump to the code. I hope that this did not get changed. >> >> With other words, the order in the code does not matter. The only >> optimisation the compiler can do, is not to use a table if the >> statement consists of a low number of entries only. >> >> Erich >> > _______________________________________________ > 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 Fri Oct 31 05:34:56 2014 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 21340D48; Fri, 31 Oct 2014 05:34:56 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6CFD8E1; Fri, 31 Oct 2014 05:34:55 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id rd3so7043371pab.0 for ; Thu, 30 Oct 2014 22:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MJy/EVOZx1NQcRFf+HWvLtY8/s4p5muelZ7emrG6uHE=; b=Ehg48q9VTGH9HGhupXGmz9WC6HhizqTDazeinj5B9F3cI++RpocU+2LCqTTuJ98DjM wW6h4UNwADp6tXpdnHzQzaUhcmLmNOZ2rCKs++Z1YpNjvpFR0rsrqA/F6EJywaun2tZO YF5DgImtD79WVmnywn2IZxiOSu4Yck5U+q4Q3lfGt7C/GM56DSKgwZWCLmmOx22Gu4sD k1xOQxZSHDA9Je2zwrcerTIfsDbR0igZcLiIVsdoMBXupR/XJFGRDfoVCPYyyvkfHc24 asYv8Z4chVFu+T4J44aCL86LQyKVwhk0NxSfFjku1Cf+dVj0ll3bBt8QDPsyFFkoviFl 4WtA== MIME-Version: 1.0 X-Received: by 10.66.159.3 with SMTP id wy3mr22015816pab.98.1414733695494; Thu, 30 Oct 2014 22:34:55 -0700 (PDT) Received: by 10.70.17.228 with HTTP; Thu, 30 Oct 2014 22:34:55 -0700 (PDT) In-Reply-To: <54531E89.3010205@freebsd.org> References: <009101cff386$29c30e50$7d492af0$@gmail.com> <20141030063053.12608314@X220.alogt.com> <54531E89.3010205@freebsd.org> Date: Fri, 31 Oct 2014 13:34:55 +0800 Message-ID: Subject: Re: performance of the swtich/case statements From: bycn82 To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD 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: Fri, 31 Oct 2014 05:34:56 -0000 actually I just checked that, no performance concern on the switch/case statement already, the compiler will sort the conditions in cases statements ,and since the opcodes are define in an enum, so the compiler will find out that all the conditions are in sequences :) On Fri, Oct 31, 2014 at 1:30 PM, Alfred Perlstein wrote: > Please run compiler with -O2 -S to get the assembly to see what will > actually happen. > > thanks, > -Alfred > > > On 10/29/14 9:24 PM, bycn82 wrote: > >> Hi, >> According to my understanding in Java programming, the compiler will >> automatically store the values into a table and jump to the correct one >> according to the value only when the condition values are in running >> number, >> >> for example. >> >> swtich(a){ >> case 1: code block 1 >> case 2: code block 2 >> case 3: code block 3 >> case 4: code block 4 >> default: code block 5 >> } >> >> it will be handled by an array >> 1-->code block 1 >> 2-->code block 2 >> 3-->code block 3 >> 4-->code block 4 >> others-->code block 5 >> >> so when the value N is greater than or lesser than 1, it will be directly >> jump to the "code block 5" >> otherwise, it will jump to N, because call the cases are nice in running >> numbers, >> >> but when the cases are messy, it will by just like lots of if/else >> >> >> On Thu, Oct 30, 2014 at 6:30 AM, Erich Dollansky < >> erichsfreebsdlist@alogt.com> wrote: >> >> Hi, >>> >>> On Wed, 29 Oct 2014 22:39:34 +0800 >>> "bycn82" wrote: >>> >>> It is using the switch/case statement to make the code clear in the >>>> >>>> I am not a C programmer, so I am not clear how the switch/case will be >>>> optimized by the compiler in FreeBSD. But I used to write a compiler >>>> by myself and I use a hash table to handle all the conditions in the >>>> case statements because my compiler don't care about performance!, >>>> But in C it is different, the case statement can only accept "int" >>>> values, so I don't think it will use hash or what , it should be >>>> directly use an array(), So whether it can be optimized it depends on >>>> the conditions in the switch/case statements, and I noticed that the >>>> cases statement in the 2 loops are not arranging the opcode in >>>> running number, so does the compiler smart enough to optimize it? >>>> >>>> >>>> I did not check recently. It was already a long, long time ago, that >>> compilers checked the limits and used the values as an index into a >>> table to jump to the code. I hope that this did not get changed. >>> >>> With other words, the order in the code does not matter. The only >>> optimisation the compiler can do, is not to use a table if the >>> statement consists of a low number of entries only. >>> >>> Erich >>> >>> _______________________________________________ >> 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" >> >> > _______________________________________________ > 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 Fri Oct 31 09:51:05 2014 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 5E98165A for ; Fri, 31 Oct 2014 09:51:05 +0000 (UTC) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E99C56A0 for ; Fri, 31 Oct 2014 09:51:04 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id b13so6147352wgh.12 for ; Fri, 31 Oct 2014 02:51:03 -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; bh=1KtoXlRues0K4U9pc+iR4d0WHgQOiCh7Obj3vtFg+bw=; b=eiolELz1l4Sm4q+WiZOLgbwglQBI8nFduEQEe10ex5jf7c9Vm7PON5BmyY+WvAnc06 biAyuy+EhcfJDpppnkLWaLnJah7E4VopeoE9K/V7ot79mK5NkFiRq/Iz0rQ024x6b7UF 9QG+nP1CL8Dw3tyAih0UIqT/VuJWE0sVy85zTpjjQYLrZBZFR7HbaW+9b2fxoHvix8Ix dUuxy53HS5vZhWJa588Irw6pOgdXS3ySdihgt5ylLBhd4CnW+pHcoAxvJW6Fwqqy7rLB ZCo3wy2a0juhhbCnJo+FFSzX4BYbSPjnnRGhVZbtpWTaaEyNJN+UMjDQ1oxfLSOVFDCH u08w== X-Received: by 10.194.80.100 with SMTP id q4mr26767263wjx.15.1414749063270; Fri, 31 Oct 2014 02:51:03 -0700 (PDT) Received: from [192.168.2.30] ([2.176.150.113]) by mx.google.com with ESMTPSA id w13sm11476401wjq.29.2014.10.31.02.51.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 02:51:02 -0700 (PDT) Message-ID: <54535B82.405@gmail.com> Date: Fri, 31 Oct 2014 13:20:58 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: transparent udp proxy Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Fri, 31 Oct 2014 09:51:05 -0000 Hi, I my setup, I use a fwd rule to forward all udp traffic to my local proxy: ipfw add 10 fwd localhost,7000 udp from any to any recv em1 The proxy needs to know the original destination address of forwarded datagrams, but there seems to be no way to obtain that address. Using recvmsg with IP_RECVDSTADDR does not help because it returns next-hop address instead of original destination. This is because udp_input() overwrites packet's destination with next-hop address before doing ip_savecontrol. It seems easy to change udp_input to pass the original dest. address to ip_savecontrol. Another soultion would be to implement IP_RECVDSTSOCKADDR option, which records the original destination address:port as a 'struct sockaddr_in[6]' in packet's control data. Comments/suggestions are welcome. -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 10:49:05 2014 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 8088FA31 for ; Fri, 31 Oct 2014 10:49:05 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A682DC1 for ; Fri, 31 Oct 2014 10:49:05 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 6EDF414E12F8; Fri, 31 Oct 2014 13:48:49 +0300 (MSK) Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id E280516A00D0; Fri, 31 Oct 2014 13:48:48 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:40c:120b:a9ff:fe93:c998]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id FEfdVniakq-mmlOXNH8; Fri, 31 Oct 2014 13:48:48 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: f9273d5b-222e-45d9-ad46-fe7e405cc787 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1414752528; bh=B0rRXmgNkgqTpn+NfmjfNbOpg7DOpQm4PMKNPoXz5X4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XkhXBluw01eW3xBV9qprBSaE84QBtFXX/9pshUG+OYpWMMAQSDKan8gNjQ0IA33gw PHBXnpFPP0LiiY7gDLqyrx7FoPLOmEYvnl4FIJFvmrDPbd0822w+B4qC6YBucjYzDm l2sp5sf/D7RSIekdN40SMPbKXTSytDGu88pRVmfg= Authentication-Results: smtp12.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54536909.3030507@yandex.ru> Date: Fri, 31 Oct 2014 13:48:41 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hooman Fazaeli , "freebsd-net@freebsd.org" Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> In-Reply-To: <54535B82.405@gmail.com> Content-Type: text/plain; charset=windows-1252 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, 31 Oct 2014 10:49:05 -0000 On 31.10.2014 12:50, Hooman Fazaeli wrote: > Hi, > > I my setup, I use a fwd rule to forward all udp traffic to my local proxy: > > ipfw add 10 fwd localhost,7000 udp from any to any recv em1 > > The proxy needs to know the original destination address of forwarded > datagrams, but > there seems to be no way to obtain that address. > > Using recvmsg with IP_RECVDSTADDR does not help because it returns > next-hop address > instead of original destination. This is because udp_input() overwrites > packet's destination > with next-hop address before doing ip_savecontrol. Hi, udp_input() doesn't overwrite destination address. Probably you have NAT that does this. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 12:04:16 2014 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 402E4230 for ; Fri, 31 Oct 2014 12:04:16 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCAD9870 for ; Fri, 31 Oct 2014 12:04:15 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id bs8so1097775wib.17 for ; Fri, 31 Oct 2014 05:04:14 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9u7ssuaYQ3JmZUUWyvDyUsFeaPmJAe0sq2W6+qJriYY=; b=rNAogTuesZle73iZRD7MKgFFaSSH6KmO9QGN+KoFRtXxZniUxzAdQ5g5GmUoFqPL4d wlkLkqyAha4QqIw5XoONWHWdOxieNwJcEG9yjmifwRo7xHtQHlNE7AUW/10Pi0YGxZz9 Wrn+RjjQJmuMM1b5S3WDNBvoblYUxIo8POd+V4zAE81pkZQj6xv5lqvKFOQlNR0/JX4d zIFekRlbJRPxW6Pb7fK3b4Ro6tXeG5T7cq+ThgDEygLNIzyc+EHBqafqwIFy7z2d05gr SwpJl3jpbcQGH8BQ6kB7u8TwiXqcvyLBXPeueWolG30+KPRji56ZafHU7JNkqkY6YPWk tGtw== X-Received: by 10.180.210.167 with SMTP id mv7mr3481456wic.15.1414757054014; Fri, 31 Oct 2014 05:04:14 -0700 (PDT) Received: from [192.168.2.30] ([2.176.150.113]) by mx.google.com with ESMTPSA id hu3sm11867481wjb.17.2014.10.31.05.04.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 05:04:13 -0700 (PDT) Message-ID: <54537AB7.5030906@gmail.com> Date: Fri, 31 Oct 2014 15:34:07 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> <54536909.3030507@yandex.ru> In-Reply-To: <54536909.3030507@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 31 Oct 2014 12:04:16 -0000 On 10/31/2014 2:18 PM, Andrey V. Elsukov wrote: > On 31.10.2014 12:50, Hooman Fazaeli wrote: >> Hi, >> >> I my setup, I use a fwd rule to forward all udp traffic to my local proxy: >> >> ipfw add 10 fwd localhost,7000 udp from any to any recv em1 >> >> The proxy needs to know the original destination address of forwarded >> datagrams, but >> there seems to be no way to obtain that address. >> >> Using recvmsg with IP_RECVDSTADDR does not help because it returns >> next-hop address >> instead of original destination. This is because udp_input() overwrites >> packet's destination >> with next-hop address before doing ip_savecontrol. > Hi, > > udp_input() doesn't overwrite destination address. Probably you have NAT > that does this. > There is no NAT stuff. I checked that on 8.4 source: http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c?v=FREEBSD8#L461 -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 12:08:58 2014 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 2AA1F312 for ; Fri, 31 Oct 2014 12:08:58 +0000 (UTC) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [IPv6:2a02:6b8:0:1819::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8FEF8A1 for ; Fri, 31 Oct 2014 12:08:57 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 9669514E131F; Fri, 31 Oct 2014 15:08:55 +0300 (MSK) Received: from smtp13.mail.yandex.net (localhost [127.0.0.1]) by smtp13.mail.yandex.net (Yandex) with ESMTP id 26866E40097; Fri, 31 Oct 2014 15:08:55 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:40c:120b:a9ff:fe93:c998]) by smtp13.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id dZPKuO91pS-8sQCfuUC; Fri, 31 Oct 2014 15:08:54 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: a718863e-3a60-4a8a-afae-20bc0ba886be DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1414757334; bh=NeMQMfdqkmLbY7/DBjcnNcwFJaOYK+kXshSasceOauQ=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bCajlxAenPnO1ihWZqZ/chlsLmXSlmMsf0LSw7rswaN0fWr1F6XPfqHD4wQ40ZBlk Xeu3Utd3vd835nhoXBN6i9FIXx/Adn96PixgWcUl3w3lG0jLYlRMGBB31wdvMKM+Bf aO3y11luJTVT0y8fNENU4Iy+oC5oLd/I+D9yWBYA= Authentication-Results: smtp13.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <54537BD0.20804@yandex.ru> Date: Fri, 31 Oct 2014 15:08:48 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Hooman Fazaeli Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> <54536909.3030507@yandex.ru> <54537AB7.5030906@gmail.com> In-Reply-To: <54537AB7.5030906@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Fri, 31 Oct 2014 12:08:58 -0000 On 31.10.2014 15:04, Hooman Fazaeli wrote: >> Hi, >> >> udp_input() doesn't overwrite destination address. Probably you have NAT >> that does this. >> > There is no NAT stuff. > I checked that on 8.4 source: > http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c?v=FREEBSD8#L461 The more recent FreeBSD versions don't overwrite destination address. https://svnweb.freebsd.org/base?view=revision&revision=225044 -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 12:19:20 2014 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 671BD44F for ; Fri, 31 Oct 2014 12:19:20 +0000 (UTC) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA629991 for ; Fri, 31 Oct 2014 12:19:19 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id ge10so5903102lab.8 for ; Fri, 31 Oct 2014 05:19:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=R3mYbLgaKRGTjp5A12gNES7kH491KJuqQ+Xu9KA3YUc=; b=jhFL3SVnRkGCIXDVIzrjNo6quI/9p1JpOwTGFk1HuMdR7n3WlhsyHF3w3lyCTNW/Tx tU1cX34gedl/9n4SMfDqazEgAVnu1Mn7hlpA5Df0uv28FIF19xGwwoVLvm5Hx7FzrMfq UbfAUpRVjObLQePg5NIx7I4Lg65c8DAuVAwyRmZds3QM7Ymo+x/1rPD1zt5YXc4FGj22 Oh+LAbhlwxxBjbdpWY8iE+ZfsWztCQ+UWd3RUFFELJ8rBKc8sElcXYQaMOB0t0JuV7eB Cv961MbovyFqtm7uhf6vc8f6ds6IKAluKfRpsk5upCZpitaIWTaRLQe/gWq8Jipd0mrk c1GA== X-Gm-Message-State: ALoCoQlRi4THoZY3bC8mWLmkzZsmNvxuQsVA1FB9yX13i0yF9mfPbDZaQSNi/gVrTsyH6EINkV9T X-Received: by 10.112.12.35 with SMTP id v3mr25768830lbb.80.1414757952344; Fri, 31 Oct 2014 05:19:12 -0700 (PDT) Received: from FRI2JCHARBON-M1.local ([217.30.88.7]) by mx.google.com with ESMTPSA id lf5sm4390605lac.16.2014.10.31.05.19.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 05:19:11 -0700 (PDT) Message-ID: <54537E35.2060108@freebsd.org> Date: Fri, 31 Oct 2014 13:19:01 +0100 From: Julien Charbon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net Subject: Re: buf_ring in HEAD is racy References: <20131226175410.GA15332@lath.rinet.ru> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ue48W3K8oNOB8hpL4MxaQn4mP7sKkFQfn" Cc: Oleg Bulyzhin , Ryan Stone , "K. Macy" , "De La Gueronniere, Marc" 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, 31 Oct 2014 12:19:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ue48W3K8oNOB8hpL4MxaQn4mP7sKkFQfn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 30/10/14 20:39, K. Macy wrote: >> I also suspect there are further problems with buf_ring. A full wrap >> around of the atomically swapped value is possible. I.e. the code thin= ks >> it just atomically updated a head/tail index when in fact a full wrap >> around occurred leading to undefined land. A relatively simple way to >> avoid this is to only mask on ring array access, and to let the >> head/tail/prod/cons indices overflow the array. >=20 > Up until Rui Paulo complained to me of packet drops with buf_ring a > couple of days ago I had thought that this patch had been committed. > This patch (now 273866) fixes the problem for him. Without further > scrutiny and testing I won't provide the UL guarantee for > buf_ring_enqueue, but this is a clear improvement. I have tested r273866 fix against our traffic and it seems it fixes the ENOBUFS issue for us too. Below the Dtrace script used for checking who was returning ENOBUFS: $ cat enobufs.d fbt::sendit:return /arg1 =3D=3D ENOBUFS/ { @senditENOBUFS[execname,pid] =3D count(); } fbt::ixgbe_mq_start:return /arg1 =3D=3D ENOBUFS/ { @ixgbeStartENOBUFS[execname,pid] =3D count(); } fbt::ip_output:return /arg1 !=3D 0/ { @ipOutputErr[execname,pid] =3D count(); } END { printf("\nsendit ENOBUFS:\n"); printa(@senditENOBUFS); printf("\nixgbe_mq_start ENOBUFS:\n"); printa(@ixgbeStartENOBUFS); printf("\nip_output Errors:\n"); printa(@ipOutputErr); } The result without the fix: $ dtrace -s enobufs.d dtrace: script 'enobufs.d' matched 4 probes ^C CPU ID FUNCTION:NAME 0 2 :END sendit ENOBUFS: server 1779 47 ixgbe_mq_start ENOBUFS: server 1779 47 ip_output Errors: server 1779 47 Thus 47 ENOBUFS errors, all returned by ixgbe_mq_start() which calls drbr_enqueue(). And result with the fix applied: $ dtrace -s enobufs.d dtrace: script 'enobufs.d' matched 4 probes ^C CPU ID FUNCTION:NAME 3 2 :END sendit ENOBUFS: ixgbe_mq_start ENOBUFS: ip_output Errors: Thus 0 ENOBUFS errors. I will let Marc review this fix further to check his full wrap case. Thanks. -- Julien --ue48W3K8oNOB8hpL4MxaQn4mP7sKkFQfn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUU348AAoJEKVlQ5Je6dhxYGwIALJihOjnir20oD5/J8sDK7Vc 7ypJEga3zc296bM5v5F4r3wRdRH/3iEmVI1f+JI+IU4o40JqhwDNsMBz2DZ41oTO iTtK7KD1v9BxOq8YD/WfMKZmC6Y0yGjd8LRYXZ8YiZLVnbhHioKMvkqn3LMBGOfE 68cJqPgYqEGSURk/lynHAaspS6l1qX0bUjBXDO3Gv79YmO7AcQuFEsc3+tkhfTPE 649ecEgNPDh3uVKT9D9hUdxslw5Rhe97KAj35cEbyQoczMZCvEpoL3VIOhaIYifN djf5J4VsJdcanE3vWkDm1MFxDEsVRJ+CntsMZ7PXSscGjgbgO4pu2Bc3m5UQ9EE= =bm38 -----END PGP SIGNATURE----- --ue48W3K8oNOB8hpL4MxaQn4mP7sKkFQfn-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 12:20:33 2014 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 DFBC0711 for ; Fri, 31 Oct 2014 12:20:33 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7472B9B0 for ; Fri, 31 Oct 2014 12:20:33 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so1130411wid.16 for ; Fri, 31 Oct 2014 05:20:31 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=I0tiPCPh4ugeCy49pe4k6vrHg7HBfPHUwqX98yf/jig=; b=GEGStlpsHYD+i8STqIh721XQD8A/1QidL+NAX8D/gHPhH0gATEGn/wZKPb8jFIequ1 JWqB2QC+TzXaOfDhERj6IpR9yFHxyLjk2sGZNjYxVV7Oa+fg5CF0/z1gQeNLgXbd6QWK ToE9nyp8ntMcHyRwkuS0trJtk4NMIPVqHC4DzTj1N5mSnT0yLEybrrCYnqcJpCQHHJZ8 IzPK9R0rpIk2Aazr9OwdgYKE4tl6/0oSNlTLBKIGEe/2R8OPAbg+pPv15xxX87gJj9Nz /ZrhNoBiSd5Pfi7CWdNL8OFUnb75sZStKbcd6+Vi0r6A5j2JtTR4TB+/8nR0+UW9zrQg wexg== X-Received: by 10.180.90.237 with SMTP id bz13mr3615887wib.50.1414758031678; Fri, 31 Oct 2014 05:20:31 -0700 (PDT) Received: from [192.168.2.30] ([2.176.150.113]) by mx.google.com with ESMTPSA id w10sm11923011wje.10.2014.10.31.05.20.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 05:20:31 -0700 (PDT) Message-ID: <54537E8A.9020500@gmail.com> Date: Fri, 31 Oct 2014 15:50:26 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Andrey V. Elsukov" Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> <54536909.3030507@yandex.ru> <54537AB7.5030906@gmail.com> <54537BD0.20804@yandex.ru> In-Reply-To: <54537BD0.20804@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 31 Oct 2014 12:20:34 -0000 On 10/31/2014 3:38 PM, Andrey V. Elsukov wrote: > On 31.10.2014 15:04, Hooman Fazaeli wrote: >>> Hi, >>> >>> udp_input() doesn't overwrite destination address. Probably you have NAT >>> that does this. >>> >> There is no NAT stuff. >> I checked that on 8.4 source: >> http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c?v=FREEBSD8#L461 > The more recent FreeBSD versions don't overwrite destination address. > > https://svnweb.freebsd.org/base?view=revision&revision=225044 > Yes. It seems so. But still the problem of obtaining original destination port remains. -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 12:26:34 2014 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 EFDB48FF for ; Fri, 31 Oct 2014 12:26:34 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9D67A82 for ; Fri, 31 Oct 2014 12:26:34 +0000 (UTC) Received: from [89.204.135.85] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XkBHc-00069l-Vw; Fri, 31 Oct 2014 13:26:25 +0100 Received: from unixarea.DDR.dd (localhost [127.0.0.1]) by unixarea.DDR.dd (8.14.9/8.14.3) with ESMTP id s9VCQMOo002428; Fri, 31 Oct 2014 13:26:22 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by unixarea.DDR.dd (8.14.9/8.14.3/Submit) id s9VCQLsE002427; Fri, 31 Oct 2014 13:26:21 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: unixarea.DDR.dd: guru set sender to guru@unixarea.de using -f Date: Fri, 31 Oct 2014 13:26:20 +0100 From: Matthias Apitz To: Hooman Fazaeli Subject: Re: transparent udp proxy Message-ID: <20141031122620.GA2416@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , Hooman Fazaeli , "Andrey V. Elsukov" , "freebsd-net@freebsd.org" References: <54535B82.405@gmail.com> <54536909.3030507@yandex.ru> <54537AB7.5030906@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54537AB7.5030906@gmail.com> X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 89.204.135.85 Cc: "freebsd-net@freebsd.org" , "Andrey V. Elsukov" 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, 31 Oct 2014 12:26:35 -0000 El día Friday, October 31, 2014 a las 03:34:07PM +0330, Hooman Fazaeli escribió: > > udp_input() doesn't overwrite destination address. Probably you have NAT > > that does this. > > > There is no NAT stuff. > I checked that on 8.4 source: http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c?v=FREEBSD8#L461 Hi, In the GOD(*) I run a firewall for our company with an UDP gateway; I've pulled out the sources from dust and they are here: http://www.unixarea.de/udprelay.tar.gz See if you can drain something from it. matthias GOD(*): Good Old Days :-) -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 14:00:55 2014 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 028F1BDF for ; Fri, 31 Oct 2014 14:00:55 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 C9CA960A for ; Fri, 31 Oct 2014 14:00:54 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7D13C20A3A for ; Fri, 31 Oct 2014 10:00:53 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Fri, 31 Oct 2014 10:00:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:in-reply-to :references:subject:date; s=smtpout; bh=cFXQc1QyCfhefh5ynO2bmowv m48=; b=bB5uL63kc9GJQ7J74A/CmtrY8KzJt6uTOF21+vPhnIhdB4YOk1D7yP40 WNoNrNUW+qfkqMW2fMLK1Gq68HvUYPUGAIyHYHxrIrWakWoqKgu/126KCYf588nC fBqE23I6KwZnMkDFN4xrZwvgco6YwnnF5eN2dd9QJaqv5+2MvZk= Received: by web3.nyi.internal (Postfix, from userid 99) id 5C84F11A019; Fri, 31 Oct 2014 10:00:53 -0400 (EDT) Message-Id: <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> X-Sasl-Enc: CUkQJf2QF5mMbeIMcVJG4MQcHMYfTuT9HB3j6Qv3Cqfx 1414764053 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-c51dec4f In-Reply-To: <54535B82.405@gmail.com> References: <54535B82.405@gmail.com> Subject: Re: transparent udp proxy Date: Fri, 31 Oct 2014 09:00:53 -0500 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, 31 Oct 2014 14:00:55 -0000 I'm not sure if this is what you're looking for, but perhaps the solution is in net/samplicator ? >From the project's website: This simple program listens for UDP datagrams on a network port, and sends copies of these datagrams on to a set of destinations. Optionally, it can perform sampling, i.e. rather than forwarding every packet, forward only 1 in N. Another option is that it can "spoof" the IP source address, so that the copies appear to come from the original source, rather than the relay. Currently only supports IPv4. From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 15:00:08 2014 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 4B8C6290; Fri, 31 Oct 2014 15:00:08 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2F2AC7C; Fri, 31 Oct 2014 15:00:07 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id d1so1547500wiv.13 for ; Fri, 31 Oct 2014 08:00:05 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uIIToQVcpHPef5EqxjORTnSL0Lld81a2rvfpfCHlmSc=; b=mVuvGFO7Xansbxkf2/mn/FfgCxXg4BAeQFM3qDJuyPaYkvT77p2tUkIpNk6nJTOP60 ahUmVDHjT/lrMm/wrOOXJofqOnXTxRTgA6hdmb1mZyx1RmvSdWKXXviYND91NAhxOOxv z1sXn4AYY5YOljU0kipPlCI+C0/v7/EpBXKKKbxP2/Ow3YXk52K5VCSq7HWZUAxjKnth AoMVq0MiVYIlTsKtDb9aDEdKuOXLNRolTGonVJEo/RlCSRmHY4DoIPlaT33CqIwlUztq ligG4ohhC7hoybHY4qvuLzSvDenubNuj3RzLiHC7fKI1tKBHn50lX1J+MsnwNce/7yKT 3NCQ== X-Received: by 10.180.73.7 with SMTP id h7mr4384154wiv.83.1414767605823; Fri, 31 Oct 2014 08:00:05 -0700 (PDT) Received: from [192.168.2.30] ([2.176.150.113]) by mx.google.com with ESMTPSA id s10sm6856251wix.14.2014.10.31.08.00.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 08:00:05 -0700 (PDT) Message-ID: <5453A3F0.7010706@gmail.com> Date: Fri, 31 Oct 2014 18:30:00 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mark Felder Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> In-Reply-To: <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 31 Oct 2014 15:00:08 -0000 On 10/31/2014 5:30 PM, Mark Felder wrote: > I'm not sure if this is what you're looking for, but perhaps the > solution is in net/samplicator ? > > From the project's website: > > This simple program listens for UDP datagrams on a network port, and > sends copies of these datagrams on to a set of destinations. Optionally, > it can perform sampling, i.e. rather than forwarding every packet, > forward only 1 in N. Another option is that it can "spoof" the IP source > address, so that the copies appear to come from the original source, > rather than the relay. Currently only supports IPv4. > _______________________________________________ > 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" Thanks. I do not thinks it provides what I am looking for. I am not looking for an application performing a specific task, but a mechanism to get the __original__ destination address and port of packets forwarded to a local UDP proxy by ipfw fwd rules. As I figured it out until now, The original destination address may be obtained by IP_RECVDSTADDR on 9.0+ (but not on 8.x and older versions) but there seems to be no mechanism get the _original_ destination _port_ (Apart from this missing mechanism, my proxy is functional and performs what it is intended to do). -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 16:41:29 2014 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 A43E7AC8; Fri, 31 Oct 2014 16:41:29 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 199EBB9A; Fri, 31 Oct 2014 16:41:28 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n12so1545153wgh.13 for ; Fri, 31 Oct 2014 09:41:27 -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=H6qfcETQmbAbpEJPxrTqAP8xxJ8RAOcNMbUdR19YyaU=; b=tGNzszswx4Wk4YOz8P8Y0RxxKIzqAeK7q11tmM4UVQ5DyfA6Lu7O14BYz3IGwgDwJf qLR+NM9iprHdzOQnJA6SRgR0+VyqqIfLsrOyn82Ahwqdj4NH9zEtpuspqjdkB7jW/uV3 1S9oaCyryggw5Jig912ixH6BPHh9scZXntogQJt8auChKMAcQF9KJQd3JW7A5+jixkaR qaj2+Pe2rAuXG+ewtkGmDLHHKgUnlxbXJX07bcn6oof6DT74gm6ONsVlmbK+BLPXxj/c yQ/A6Uk4Hf6KucsM0WwRfkqgWp/IDMuLvYONA+a+dN1JU+dDqW3vE0Y3T1XgXc4YXPPy SN4A== MIME-Version: 1.0 X-Received: by 10.180.106.162 with SMTP id gv2mr4881654wib.26.1414773687410; Fri, 31 Oct 2014 09:41:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 31 Oct 2014 09:41:27 -0700 (PDT) In-Reply-To: <5453A3F0.7010706@gmail.com> References: <54535B82.405@gmail.com> <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> <5453A3F0.7010706@gmail.com> Date: Fri, 31 Oct 2014 09:41:27 -0700 X-Google-Sender-Auth: P6xPrm10uW7CRj4bnZJ5qkhNFUA Message-ID: Subject: Re: transparent udp proxy From: Adrian Chadd To: Hooman Fazaeli Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net , Mark Felder 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, 31 Oct 2014 16:41:29 -0000 Hi, If it's missing in 10 or later then please file a bug and I'll see what it'll take to add another socket option to return the original destination address+port. Thanks, -adrian On 31 October 2014 08:00, Hooman Fazaeli wrote: > On 10/31/2014 5:30 PM, Mark Felder wrote: >> >> I'm not sure if this is what you're looking for, but perhaps the >> solution is in net/samplicator ? >> >> From the project's website: >> >> This simple program listens for UDP datagrams on a network port, and >> sends copies of these datagrams on to a set of destinations. Optionally, >> it can perform sampling, i.e. rather than forwarding every packet, >> forward only 1 in N. Another option is that it can "spoof" the IP source >> address, so that the copies appear to come from the original source, >> rather than the relay. Currently only supports IPv4. >> _______________________________________________ >> 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" > > > Thanks. I do not thinks it provides what I am looking for. > > I am not looking for an application performing a specific task, but a > mechanism > to get the __original__ destination address and port of packets forwarded to > a > local UDP proxy by ipfw fwd rules. As I figured it out until now, The > original destination > address may be obtained by IP_RECVDSTADDR on 9.0+ (but not on 8.x and older > versions) but > there seems to be no mechanism get the _original_ destination _port_ (Apart > from this > missing mechanism, my proxy is functional and performs what it is intended > to do). > > > -- > > Best regards. > Hooman Fazaeli > > _______________________________________________ > 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 Fri Oct 31 17:00:45 2014 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 1B979300; Fri, 31 Oct 2014 17:00:45 +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 6B363DF8; Fri, 31 Oct 2014 17:00:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s9VH0fPd054496; Sat, 1 Nov 2014 04:00:41 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 1 Nov 2014 04:00:41 +1100 (EST) From: Ian Smith To: Hooman Fazaeli Subject: Re: transparent udp proxy In-Reply-To: <5453A3F0.7010706@gmail.com> Message-ID: <20141101035050.R52402@sola.nimnet.asn.au> References: <54535B82.405@gmail.com> <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> <5453A3F0.7010706@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Mark Felder 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, 31 Oct 2014 17:00:45 -0000 On Fri, 31 Oct 2014 18:30:00 +0330, Hooman Fazaeli wrote: > On 10/31/2014 5:30 PM, Mark Felder wrote: > > I'm not sure if this is what you're looking for, but perhaps the > > solution is in net/samplicator ? > > > > From the project's website: > > > > This simple program listens for UDP datagrams on a network port, and > > sends copies of these datagrams on to a set of destinations. Optionally, > > it can perform sampling, i.e. rather than forwarding every packet, > > forward only 1 in N. Another option is that it can "spoof" the IP source > > address, so that the copies appear to come from the original source, > > rather than the relay. Currently only supports IPv4. > Thanks. I do not thinks it provides what I am looking for. > > I am not looking for an application performing a specific task, but a > mechanism to get the __original__ destination address and port of > packets forwarded to a local UDP proxy by ipfw fwd rules. As I > figured it out until now, The original destination address may be > obtained by IP_RECVDSTADDR on 9.0+ (but not on 8.x and older > versions) but there seems to be no mechanism get the _original_ > destination _port_ (Apart from this missing mechanism, my proxy is > functional and performs what it is intended to do). : ipfw add 10 fwd localhost,7000 udp from any to any recv em1 Given these are local packets and that ipfw(8) /fwd states: The fwd action does not change the contents of the packet at all. In particular, the destination address remains unmodified, so packets forwarded to another system will usually be rejected by that system unless there is a matching rule on that system to capture them. For packets forwarded locally, the local address of the socket will be set to the original destination address of the packet. This makes the netstat(1) entry look rather weird but is intended for use with transparent proxy servers. Has the destination port in the received packet been changed to 7000? If not, you're all set. If so, where else could the dst port be stored? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 17:47:19 2014 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 4CA5345F for ; Fri, 31 Oct 2014 17:47:19 +0000 (UTC) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1462B3C6 for ; Fri, 31 Oct 2014 17:47:19 +0000 (UTC) Received: by mail-oi0-f47.google.com with SMTP id a3so5364742oib.6 for ; Fri, 31 Oct 2014 10:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=bTyTuSc1U5BYgug7zlzyyLpsygR78mMD6/NCh9ZsUTQ=; b=ltAf4fTSWWq2cjnfToN/O28UFo/3ejJsB5Qx7gLblwqo+SqZFLZw09GyeUcHldVy8V TWYRFuSAjPfaRnHO7mOlUOaz+NygVcgX42EQjcnyXJZjshgIGJl1U5gPgyjgzrJi0gGC u1wulv42qJCIjpBUxGRUAjZjE5mSsKBp3lwXeA+9IPMihxSSapRlTfwoQC+gl8T4VTVg XnYuYbGemBvZeCxDmouNSB/W0en3flZaLFWpeZrmRpxvMWqUPaoOWsQW4bXQGdeZi65G 30AR4tFtVohqQRdV1BZA1n8W5c1pKJdhbUWhcIzgCrJvaoV/8Nle+0cYpYElziCMkyoH NXSA== X-Received: by 10.60.132.7 with SMTP id oq7mr2842736oeb.61.1414777638333; Fri, 31 Oct 2014 10:47:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.93.40 with HTTP; Fri, 31 Oct 2014 10:46:58 -0700 (PDT) In-Reply-To: References: <009c01cff388$29fe7ec0$7dfb7c40$@gmail.com> From: Raimundo Santos Date: Fri, 31 Oct 2014 15:46:58 -0200 Message-ID: Subject: Re: ipfw fwd duplicating packets in 9.3-RELEASE To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 31 Oct 2014 17:47:19 -0000 For documentation: I do not know why or how, but after trying to reproduce the same strange behaviour, it did not happen. This was after restarting all the test environment. Weird. Sorry for take your time with this strange mess. Regards, Raimundo Santos On 29 October 2014 14:30, Raimundo Santos wrote: > > > On 29 October 2014 12:53, bycn82 wrote: > > > > Hi, > > I cannot help to point out when the ICMP packet was duplicated and > transfer > > via 2 different links, If it happens in my machine, I will call this > feature > > "multi-homing". > > > That is a bit off topic, but how and undesired behaviour could be a > feature? It is not only undesired, but it is also undocumented. > > If I filter incoming packtes, I got it sent to the original and to the fwd > destinations, by my tests. I can not see how it is multi-homing. > > What I know by multi-homing is: two or more interconnections with the same > other network, or to the Internet. It implies more care to the outgoing and > incoming paths. Who leaves from link 1 will enter via link 1? It is ok to > happen that way? Only the context can say that. > > In my case the packet not only get out via two different links, but it is > reaching two *different* machines in different networks. > > > > > But what I want to say is the firewall rule > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 > > You can remove the "out" because "xmit" will check the "out interface". > > Thank you for the clarification. > > > > > > > Regards, > > Bycn82 > > > Regards, > Raimundo Santos > > > > > > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org [mailto: > owner-freebsd-net@freebsd.org] > > On Behalf Of Raimundo Santos > > Sent: Tuesday, 28 October, 2014 3:32 PM > > To: freebsd-net@freebsd.org > > Subject: ipfw fwd duplicating packets in 9.3-RELEASE > > > > Hello list! > > > > I was testing the behaviour of fwd in ipfw from FreeBSd 9.3-RELEASE, > latest > > updates, GENERIC kernel, in this setup: > > > > 1x FreeBSD 9.3 as router, with 3 network interfaces 5x OpenBSD 5.5 as > > network machines, each one connected to FreeBSD via one port. > > > > It is a virtual env. > > > > FreeBSD em0 (192.168.0.1) -> OpenBSD#1 em0 (192.168.0.2) FreeBSD em1 > > (192.168.1.1) -> OpenBSD#2 em0 (192.168.1.2) FreeBSD em2 (192.168.2.1) -> > > OpenBSD#3 em0 (192.168.2.2) FreeBSD em3 (192.168.3.1) -> OpenBSD#4 em0 > > (192.168.3.2) FreeBSD em4 (192.168.4.1) -> OpenBSD#5 em1 (192.168.4.2) > > > > ipfw rule: > > > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 in recv em4 > > > > Then a ping 192.168.1.2 was issued from OpenBSD#5. > > > > Interestingly, this rule put a packet on em0 and em1 in FreeBSD. The > packet > > successfully arrived at OpenBSD#1, where it was discarded, and at > OpenBSD#2, > > where it got its reply. > > > > Only these combinations of interface direction do not duplicate the > packet: > > out xmit > > > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 > > > > and > > > > fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out via em1 > > > > Even out recv em4 xmit em1 leads to packet duplication. > > > > I think that it is a bad thing for PBR. As I can see from these tests, I > can > > not use all the options to do PBR. > > > > In my real needs I have to: > > > > 1. let web traffic flow to an cache appliance (from internal network to > > cache, from internet to cache) > > > > 2. do NAT for the internal network under three different links > > > > In theory, fwd + in kernel NAT + one_pass=0 could solve the problem. But > I > > am hitting my head in the wall for almost three weeks on this, only now I > > have the time to test in a more clear way. First I blamed the NAT, after > > that the one_pass=0, and now, with these results, well... > > > > Someone has an explanation about it? Something related to > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=129036? > > > > For my real needs, I figured out that it works with > > > > <...before NAT aliasing...> > > fwd CACHE_IP proto tcp src-ip table(INT) dst-port 80 out recv INT_IFACE > > <...after NAT dealiasing...> fwd CACHE_IP proto tcp dst-ip table(INT) > > src-port 80 out recv EXT_IFACE > > > > But I am not confident that it will remains in good shape without knowing > > exactly why fwd behaves that way. > > > > Thank you in advance for your time, > > Raimundo Santos > > _______________________________________________ > > 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 Fri Oct 31 18:11:00 2014 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 83CA6C3D for ; Fri, 31 Oct 2014 18:11:00 +0000 (UTC) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00D4D89C for ; Fri, 31 Oct 2014 18:10:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id C6CA6B61D269; Fri, 31 Oct 2014 19:01:54 +0100 (CET) Date: Fri, 31 Oct 2014 19:01:54 +0100 (CET) From: elof2@sentor.se To: freebsd-net Subject: Re: Unable to kill a non-zombie process with -9 In-Reply-To: Message-ID: References: <20141009222926.GC1852@funkthat.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: John-Mark Gurney 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, 31 Oct 2014 18:11:00 -0000 No one have any thoughts about this? Its happening sporadically on several FreeBSD 10 machines of mine, while all of the FreeBSD 9-machines work just fine. If the problem isn't fixed, people won't be able to upgrade to and run snort on FreeBSD 10. log: > I'm starting snort (as root). > > <<>> > Oct 15 08:46:59 snort[22646]: Initializing daemon mode > Oct 15 08:46:59 snort[22648]: Daemon initialized, signaled parent pid: 22646 > Oct 15 08:46:59 snort[22648]: Reload thread starting... > Oct 15 08:46:59 snort[22648]: Reload thread started, thread 0x8146e8800 (22648) > End of log. > > Error! Nothing more happens with the snort process! > Normally it should continue and log the following lines as well: > > > snort[nnn]: Decoding Ethernet > snort[nnn]: Checking PID path... > snort[nnn]: PID path stat checked out ok, PID path set to /var/run/ > snort[nnn]: Writing PID "7627" to file "/var/run//snort_mon0.pid" > snort[nnn]: Chroot directory = /usr/foobar/log > snort[nnn]: Set gid to 100 > snort[nnn]: Set uid to 100 > snort[nnn]: > snort[nnn]: --== Initialization Complete ==-- > snort[nnn]: Commencing packet processing (pid=nnn) > > > > > > When looking at this half-started snort process with 'ps', it looks like > this: > > ps faxulwwj 22648 > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC > root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > > The process is still owned by root, so just as the missing log lines are > saying, it has not yet performed any change of uid/gid. > > > > > So there seem to be two questions. > > Q1) > What happens between "Reload thread started, thread 0x8146e8800 (22648)" and > "Decoding Ethernet"? > Apparently something goes wrong here on FreeBSD 10.0. > (this problem does not always occur, sometimes snort start just fine) > > Q2) > When the process has frozen in this half-started state, it can't be killed > even with a -9. Why? > > > > > John-Mark asked me for some debugging info. Here it is: > > I now run 'kill 22648' on the above semi-started process: > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID > PPID CPU PRI NI MWCHAN PGID SID JOBC > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > new root 22648 52.3 1.1 488552 179344 - Rs 8:46AM 53:36.48 > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > No change. > > > > kill -9 22648 > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID > PPID CPU PRI NI MWCHAN PGID SID JOBC > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > new root 22648 37.7 1.1 488552 179344 - Ts 8:46AM 53:50.87 > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > Less CPU-usage and STAT changed to "Ts". > > > > > kill -CONT 22648 > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID > PPID CPU PRI NI MWCHAN PGID SID JOBC > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > new root 22648 0.0 1.1 488552 179344 - Ts 8:46AM 53:50.88 > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > No change except cpu is down to 0. > > > I now start 'kgdb' > info threads > I found two threads for snort, doing a bt for both of them: > 372 Thread 100602 (PID=22648: snort) sched_switch (td=0xfffff802c061f490, > newtd=, flags=) at > /usr/src/sys/kern/sched_ule.c:1962 > 371 Thread 100598 (PID=22648: snort) sched_switch (td=0xfffff80221857000, > newtd=, flags=) at > /usr/src/sys/kern/sched_ule.c:1962 > thread 372 > [Switching to thread 372 (Thread 100602)]#0 sched_switch > (td=0xfffff802c061f490, newtd=, flags= out>) at /usr/src/sys/kern/sched_ule.c:1962 > 1962 in /usr/src/sys/kern/sched_ule.c > bt > #0 sched_switch (td=0xfffff802c061f490, newtd=, > flags=) at /usr/src/sys/kern/sched_ule.c:1962 > #1 0xffffffff808b8c1e in mi_switch (flags=266, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:494 > #2 0xffffffff808c04b0 in thread_suspend_switch (td=0xfffff802c061f490) at > /usr/src/sys/kern/kern_thread.c:883 > #3 0xffffffff808c0276 in thread_single (mode=1) at > /usr/src/sys/kern/kern_thread.c:713 > #4 0xffffffff8087c1bb in exit1 (td=0xfffff802c061f490, rv=9) at > /usr/src/sys/kern/kern_exit.c:180 > #5 0xffffffff808b2faf in sigexit (td=, sig= optimized out>) at /usr/src/sys/kern/kern_sig.c:2935 > #6 0xffffffff808b3669 in postsig (sig=) at > /usr/src/sys/kern/kern_sig.c:2822 > #7 0xffffffff808f6f57 in ast (framep=) at > /usr/src/sys/kern/subr_trap.c:271 > #8 0xffffffff80c75870 in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:416 > #9 0x0000000801d6f19a in ?? () > Previous frame inner to this frame (corrupt stack?) > > > thread 371 > [Switching to thread 371 (Thread 100598)]#0 sched_switch > (td=0xfffff80221857000, newtd=, flags= out>) at /usr/src/sys/kern/sched_ule.c:1962 > 1962 in /usr/src/sys/kern/sched_ule.c > bt > #0 sched_switch (td=0xfffff80221857000, newtd=, > flags=) at /usr/src/sys/kern/sched_ule.c:1962 > #1 0xffffffff808b8c1e in mi_switch (flags=260, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:494 > #2 0xffffffff808f2e3a in sleepq_wait (wchan=0x0, pri=0) at > /usr/src/sys/kern/subr_sleepqueue.c:620 > #3 0xffffffff80864aad in _cv_wait (cvp=0xffffffff8147a500, > lock=0xffffffff8147a480) at /usr/src/sys/kern/kern_condvar.c:139 > #4 0xffffffff808fb05f in vmem_xalloc (vm=0xffffffff8147a480, size0= optimized out>, align=, phase=0, nocross= optimized out>, minaddr=0, maxaddr=18446735286768857088, flags=8194, > addrp=) at /usr/src/sys/kern/subr_vmem.c:1196 > #5 0xffffffff808fae6b in vmem_alloc (vm=0x0, size=0, flags= out>, addrp=0xfffffe0466e1d6e8) at /usr/src/sys/kern/subr_vmem.c:1082 > #6 0xffffffff80b0fa58 in kmem_malloc (vmem=0xffffffff8147a480, > size=2139729920, flags=2) at /usr/src/sys/vm/vm_kern.c:314 > #7 0xffffffff80b08dfb in uma_large_malloc (size=, > wait=2) at /usr/src/sys/vm/uma_core.c:1006 > #8 0xffffffff80898cf3 in malloc (size=2139729920, mtp=0xffffffff813a0450, > flags=0) at /usr/src/sys/kern/kern_malloc.c:520 > #9 0xffffffff8096307b in bpf_buffer_ioctl_sblen (d=0xfffff80159ea9000, > i=) at /usr/src/sys/net/bpf_buffer.c:183 > #10 0xffffffff80960a3c in bpfioctl (dev=0x0, cmd=, > addr=0xfffff801fbd06b40 "", flags=0, td=0xfffff80221857000) at > /usr/src/sys/net/bpf.c:408 > #11 0xffffffff807ac1df in devfs_ioctl_f (fp=0xfffff8002b3d9d20, > com=3221504614, data=0xfffff801fbd06b40, cred=, > td=0xfffff80221857000) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > #12 0xffffffff808fdfae in kern_ioctl (td=0xfffff80221857000, fd= optimized out>, com=0) at file.h:319 > #13 0xffffffff808fdd2f in sys_ioctl (td=0xfffff80221857000, > uap=0xfffffe0466e1da40) at /usr/src/sys/kern/sys_generic.c:702 > #14 0xffffffff80c8f117 in amd64_syscall (td=0xfffff80221857000, traced=0) at > subr_syscall.c:134 > #15 0xffffffff80c7580b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:391 > #16 0x0000000801d8f08a in ?? () > Previous frame inner to this frame (corrupt stack?) > > > Let me know if I can debug this any further. > > /Elof > > > > On Thu, 9 Oct 2014, John-Mark Gurney wrote: > >> elof2@sentor.se wrote this message on Wed, Oct 08, 2014 at 13:30 +0200: >>> >>> I guess this is a bug report for FreeBSD 10.0. >>> >>> >>> >>> Sometimes I can't kill my snort process on FreeBSD 10.0. >>> It won't die, even with kill -9. >>> >>> I'm not talking about a zombie process. Snort is a process that should >>> die normally. >>> I've run snort on over 100 nodes since FreeBSD v6.x and I've never seen >>> this behavior until now in FreeBSD 10.0. >>> >>> >>> Example: >>> >>> #ps faxuw >>> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME >>> COMMAND >>> root 49222 53.4 2.2 492648 183012 - Rs 11:46AM 7:05.59 >>> /usr/local/bin/snort -q -D -c snort.conf >>> root 47937 0.0 2.2 488552 182864 - Ts 10:56AM 29:35.98 >>> /usr/local/bin/snort -q -D -c snort.conf >> >> What is the MWCHAN? add l to the ps command... >> >>> The pid 47937 has been killed (repeatedly) with -9. >>> Its status is "Ts" meaning it is Stopped. >> >> have you tried to kill -CONT to resume it? >> >>> But it won't actually die and disappear. The only way to get rid of it >>> seem to be to reboot the machine. :-( >>> >>> (pid 49222 is the new process that was started after 47937 was killed) >>> >>> >>> The problem doesn't happen all the time and I haven't found any patterns >>> as to when it does. :-( >>> If I restart snort once every day, it fails to die approximately 2-4 times >>> per month. >>> Even though the problem doesn't happen on every kill, it is a definately a >>> recurring event. >> >> Can you run kgdb on the machine? (yes, it works on a live machine), use >> info threads to find the thread id, and then use thread to >> switch to it, and run bt to get a back trace... >> >>> I began to see it on a heavily loaded 10GE sensor, so I thought it could >>> have something to do with the ix driver, or the heavy load. >>> But now another FreeBSD 10.0-sensor had the exact same problem, and this >>> sensor don't have any 10GE NICs. In fact, this sensor has been running >>> just fine with both FreeBSD 9.1 and 9.3 for the past years. Snort has >>> always terminated correctly! After I reinstalled this machine with FreeBSD >>> 10.0 last friday, snort has then terminated correctly every day until >>> today, when it failed with the above pid 47937. (this sensor use the 'em' >>> driver, not 'ixgbe') >>> >>> I'm running snort with the same configuration, settings, version, daq, >>> libs, etc on 10.0 as I do on 9.3. >>> None of the 9.3 sensors have this problem, so it has to be something new >>> in FreeBSD 10.0. >> >> -- >> John-Mark Gurney Voice: +1 415 225 5579 >> >> "All that I will do, has been done, All that I have, has not." >> > _______________________________________________ > 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 Fri Oct 31 18:25:59 2014 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 0452A46C for ; Fri, 31 Oct 2014 18:25:59 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86E3EAA0 for ; Fri, 31 Oct 2014 18:25:58 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so7154267wgg.33 for ; Fri, 31 Oct 2014 11:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=XBgRBhnFUqg3hWrMVUXSuVycxgeG4MC10bv24B39YGc=; b=pVoR21bc0fsCBNyxilsDHZzhNRMNu++nGyWXG3ICYk5J85pNFsB24b2+LE0n5EcxLv z1Nw09ZSf1cDSSstXTW2wYF2MLMuB2h9cCnvia3PKR+eJ2bv6Y5VVRux2t2ZBlLBJBSr Ag1MjCtT8JaP69QCUu2y08wTF80pv+R7Ykf9tDWrF1iNt1U8pWfZ4lHPvZIbLwPJjPl6 /2+izDw1D25HcRVCoJdDa0+66YX/aR07a3UO9etXsxTYoUQlvC6IoN7QdRe17qTX/mcf WTgq04S8TFR2O6pQ5Ib4lBFRLIaUOrVGZPn18cyM5u5jnYvLVXKHnF75H9bva4ctSIJZ KzlQ== X-Received: by 10.180.12.136 with SMTP id y8mr5702358wib.73.1414779956671; Fri, 31 Oct 2014 11:25:56 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id s10sm7426930wix.14.2014.10.31.11.25.55 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 31 Oct 2014 11:25:55 -0700 (PDT) Date: Fri, 31 Oct 2014 19:25:53 +0100 From: Mateusz Guzik To: elof2@sentor.se Subject: Re: Unable to kill a non-zombie process with -9 Message-ID: <20141031182552.GA20591@dft-labs.eu> References: <20141009222926.GC1852@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net , John-Mark Gurney , snort-devel mailinglist 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, 31 Oct 2014 18:25:59 -0000 On Wed, Oct 15, 2014 at 11:41:33AM +0200, elof2@sentor.se wrote: > > Hi! > > Today the problem reoccurred. > I've now debugged the problem a little furter. > > I'm starting snort (as root). > > <<>> > Oct 15 08:46:59 snort[22646]: Initializing daemon mode > Oct 15 08:46:59 snort[22648]: Daemon initialized, signaled parent > pid: 22646 > Oct 15 08:46:59 snort[22648]: Reload thread starting... > Oct 15 08:46:59 snort[22648]: Reload thread started, thread > 0x8146e8800 (22648) > End of log. > > Error! Nothing more happens with the snort process! > Normally it should continue and log these lines as well: > > > snort[nnn]: Decoding Ethernet > snort[nnn]: Checking PID path... > snort[nnn]: PID path stat checked out ok, PID path set to /var/run/ > snort[nnn]: Writing PID "7627" to file "/var/run//snort_mon0.pid" > snort[nnn]: Chroot directory = /usr/foobar/log > snort[nnn]: Set gid to 100 > snort[nnn]: Set uid to 100 > snort[nnn]: > snort[nnn]: --== Initialization Complete ==-- > snort[nnn]: Commencing packet processing (pid=nnn) > > > > > > When looking at this half-started snort process with 'ps', it looks > like this: > > ps faxulwwj 22648 > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > UID PPID CPU PRI NI MWCHAN PGID SID JOBC > root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > > The process is still owned by root, so just as the missing log lines > are saying, it has not yet performed any change of uid/gid. > > > > > So there seem to be two questions. > > Q1) > What happens between "Reload thread started, thread 0x8146e8800 > (22648)" and "Decoding Ethernet"? > Apparently something goes wrong here on FreeBSD 10.0. > (this problem does not always occur, sometimes snort start just fine) > Nobody can tell with this data. > Q2) > When the process has frozen in this half-started state, it can't be > killed even with a -9. Why? > Temporarily unkillable processes are standard, you can encounter them in BSDs, Solaris, Linux and I would not be surprised if Windows as well. In short, here and there the kernel does something blocking which is not supposed to fail. For instance in a lot of places FreeBSD kernel just waits for memory to be free when allocating. However, if stuff blocks indefinitely, we may be dealing with a bug. > > > > John-Mark asked me for some debugging info. Here it is: > > I now run 'kill 22648' on the above semi-started process: > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > new root 22648 52.3 1.1 488552 179344 - Rs 8:46AM 53:36.48 > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > No change. > > > > kill -9 22648 > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > new root 22648 37.7 1.1 488552 179344 - Ts 8:46AM 53:50.87 > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > Less CPU-usage and STAT changed to "Ts". > > > > > kill -CONT 22648 > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > new root 22648 0.0 1.1 488552 179344 - Ts 8:46AM 53:50.88 > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > No change except cpu is down to 0. > > > I now start 'kgdb' > info threads > I found two threads for snort, doing a bt for both of them: > 372 Thread 100602 (PID=22648: snort) sched_switch > (td=0xfffff802c061f490, newtd=, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1962 > 371 Thread 100598 (PID=22648: snort) sched_switch > (td=0xfffff80221857000, newtd=, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1962 > thread 372 > [Switching to thread 372 (Thread 100602)]#0 sched_switch > (td=0xfffff802c061f490, newtd=, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1962 > 1962 in /usr/src/sys/kern/sched_ule.c > bt > #0 sched_switch (td=0xfffff802c061f490, newtd=, > flags=) at /usr/src/sys/kern/sched_ule.c:1962 > #1 0xffffffff808b8c1e in mi_switch (flags=266, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:494 > #2 0xffffffff808c04b0 in thread_suspend_switch > (td=0xfffff802c061f490) at /usr/src/sys/kern/kern_thread.c:883 > #3 0xffffffff808c0276 in thread_single (mode=1) at > /usr/src/sys/kern/kern_thread.c:713 > #4 0xffffffff8087c1bb in exit1 (td=0xfffff802c061f490, rv=9) at > /usr/src/sys/kern/kern_exit.c:180 > #5 0xffffffff808b2faf in sigexit (td=, > sig=) at /usr/src/sys/kern/kern_sig.c:2935 > #6 0xffffffff808b3669 in postsig (sig=) at > /usr/src/sys/kern/kern_sig.c:2822 > #7 0xffffffff808f6f57 in ast (framep=) at > /usr/src/sys/kern/subr_trap.c:271 > #8 0xffffffff80c75870 in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:416 > #9 0x0000000801d6f19a in ?? () > Previous frame inner to this frame (corrupt stack?) > > > thread 371 > [Switching to thread 371 (Thread 100598)]#0 sched_switch > (td=0xfffff80221857000, newtd=, flags= optimized out>) at /usr/src/sys/kern/sched_ule.c:1962 > 1962 in /usr/src/sys/kern/sched_ule.c > bt > #0 sched_switch (td=0xfffff80221857000, newtd=, > flags=) at /usr/src/sys/kern/sched_ule.c:1962 > #1 0xffffffff808b8c1e in mi_switch (flags=260, newtd=0x0) at > /usr/src/sys/kern/kern_synch.c:494 > #2 0xffffffff808f2e3a in sleepq_wait (wchan=0x0, pri=0) at > /usr/src/sys/kern/subr_sleepqueue.c:620 > #3 0xffffffff80864aad in _cv_wait (cvp=0xffffffff8147a500, > lock=0xffffffff8147a480) at /usr/src/sys/kern/kern_condvar.c:139 Here your thread got blocked trying to acquire a mutex. You can find the owner by inspecting vm (vm=0xffffffff8147a480) -> vm_lock -> mtx_lock. You may need to cast along the way. Roughly speaking (untested): f 4 p (struct vmem *)0xffffffff8147a480)->vm_lock->mtx_lock > #4 0xffffffff808fb05f in vmem_xalloc (vm=0xffffffff8147a480, > size0=, align=, phase=0, > nocross=, minaddr=0, > maxaddr=18446735286768857088, flags=8194, addrp= out>) at /usr/src/sys/kern/subr_vmem.c:1196 > #5 0xffffffff808fae6b in vmem_alloc (vm=0x0, size=0, flags= optimized out>, addrp=0xfffffe0466e1d6e8) at > /usr/src/sys/kern/subr_vmem.c:1082 > #6 0xffffffff80b0fa58 in kmem_malloc (vmem=0xffffffff8147a480, > size=2139729920, flags=2) at /usr/src/sys/vm/vm_kern.c:314 > #7 0xffffffff80b08dfb in uma_large_malloc (size= out>, wait=2) at /usr/src/sys/vm/uma_core.c:1006 > #8 0xffffffff80898cf3 in malloc (size=2139729920, > mtp=0xffffffff813a0450, flags=0) at > /usr/src/sys/kern/kern_malloc.c:520 > #9 0xffffffff8096307b in bpf_buffer_ioctl_sblen > (d=0xfffff80159ea9000, i=) at > /usr/src/sys/net/bpf_buffer.c:183 > #10 0xffffffff80960a3c in bpfioctl (dev=0x0, cmd= out>, addr=0xfffff801fbd06b40 "", flags=0, td=0xfffff80221857000) at > /usr/src/sys/net/bpf.c:408 > #11 0xffffffff807ac1df in devfs_ioctl_f (fp=0xfffff8002b3d9d20, > com=3221504614, data=0xfffff801fbd06b40, cred=, > td=0xfffff80221857000) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > #12 0xffffffff808fdfae in kern_ioctl (td=0xfffff80221857000, > fd=, com=0) at file.h:319 > #13 0xffffffff808fdd2f in sys_ioctl (td=0xfffff80221857000, > uap=0xfffffe0466e1da40) at /usr/src/sys/kern/sys_generic.c:702 > #14 0xffffffff80c8f117 in amd64_syscall (td=0xfffff80221857000, > traced=0) at subr_syscall.c:134 > #15 0xffffffff80c7580b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:391 > #16 0x0000000801d8f08a in ?? () > Previous frame inner to this frame (corrupt stack?) > > -- Mateusz Guzik From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 19:07:02 2014 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 B5C08630; Fri, 31 Oct 2014 19:07:02 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA52F2A; Fri, 31 Oct 2014 19:07:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEEAHTcU1SDaFve/2dsb2JhbABZA4NiWASDAsoeCoZ5VAKBLwEBAQEBfYQCAQEBAwEBAQEgKyALGxgCAg0ZAikBCSYOBwQBHASIFwkNthGVAAEBAQEGAQEBAQEBARuBLY8SAQEbJBAHEYJmgVQFlmKEEoRxlFuEFCEvB4EIOYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,295,1413259200"; d="scan'208";a="165143422" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 31 Oct 2014 15:06:54 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 17845B40E2; Fri, 31 Oct 2014 15:06:54 -0400 (EDT) Date: Fri, 31 Oct 2014 15:06:54 -0400 (EDT) From: Rick Macklem To: elof2@sentor.se Message-ID: <1603084759.3305578.1414782414065.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Unable to kill a non-zombie process with -9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: alc@freebsd.org, freebsd-net , John-Mark Gurney 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, 31 Oct 2014 19:07:02 -0000 elof2@sentor.se wrote: > > No one have any thoughts about this? > > Its happening sporadically on several FreeBSD 10 machines of mine, > while > all of the FreeBSD 9-machines work just fine. > > If the problem isn't fixed, people won't be able to upgrade to and > run > snort on FreeBSD 10. > > log: > > > I'm starting snort (as root). > > > > <<>> > > Oct 15 08:46:59 snort[22646]: Initializing daemon mode > > Oct 15 08:46:59 snort[22648]: Daemon initialized, signaled parent > > pid: 22646 > > Oct 15 08:46:59 snort[22648]: Reload thread starting... > > Oct 15 08:46:59 snort[22648]: Reload thread started, thread > > 0x8146e8800 (22648) > > End of log. > > > > Error! Nothing more happens with the snort process! > > Normally it should continue and log the following lines as well: > > > > > > snort[nnn]: Decoding Ethernet > > snort[nnn]: Checking PID path... > > snort[nnn]: PID path stat checked out ok, PID path set to /var/run/ > > snort[nnn]: Writing PID "7627" to file "/var/run//snort_mon0.pid" > > snort[nnn]: Chroot directory = /usr/foobar/log > > snort[nnn]: Set gid to 100 > > snort[nnn]: Set uid to 100 > > snort[nnn]: > > snort[nnn]: --== Initialization Complete ==-- > > snort[nnn]: Commencing packet processing (pid=nnn) > > > > > > > > > > > > When looking at this half-started snort process with 'ps', it looks > > like > > this: > > > > ps faxulwwj 22648 > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC > > root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > > > > > The process is still owned by root, so just as the missing log > > lines are > > saying, it has not yet performed any change of uid/gid. > > > > > > > > > > So there seem to be two questions. > > > > Q1) > > What happens between "Reload thread started, thread 0x8146e8800 > > (22648)" and > > "Decoding Ethernet"? > > Apparently something goes wrong here on FreeBSD 10.0. > > (this problem does not always occur, sometimes snort start just > > fine) > > > > Q2) > > When the process has frozen in this half-started state, it can't be > > killed > > even with a -9. Why? > > > > > > > > > > John-Mark asked me for some debugging info. Here it is: > > > > I now run 'kill 22648' on the above semi-started process: > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > COMMAND UID > > PPID CPU PRI NI MWCHAN PGID SID JOBC > > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > new root 22648 52.3 1.1 488552 179344 - Rs 8:46AM 53:36.48 > > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > > > No change. > > > > > > > > kill -9 22648 > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > COMMAND UID > > PPID CPU PRI NI MWCHAN PGID SID JOBC > > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > new root 22648 37.7 1.1 488552 179344 - Ts 8:46AM 53:50.87 > > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > > > Less CPU-usage and STAT changed to "Ts". > > > > > > > > > > kill -CONT 22648 > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > COMMAND UID > > PPID CPU PRI NI MWCHAN PGID SID JOBC > > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > new root 22648 0.0 1.1 488552 179344 - Ts 8:46AM 53:50.88 > > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > > > No change except cpu is down to 0. > > > > > > I now start 'kgdb' > > info threads > > I found two threads for snort, doing a bt for both of them: > > 372 Thread 100602 (PID=22648: snort) sched_switch > > (td=0xfffff802c061f490, > > newtd=, flags=) at > > /usr/src/sys/kern/sched_ule.c:1962 > > 371 Thread 100598 (PID=22648: snort) sched_switch > > (td=0xfffff80221857000, > > newtd=, flags=) at > > /usr/src/sys/kern/sched_ule.c:1962 > > thread 372 > > [Switching to thread 372 (Thread 100602)]#0 sched_switch > > (td=0xfffff802c061f490, newtd=, flags= > optimized > > out>) at /usr/src/sys/kern/sched_ule.c:1962 > > 1962 in /usr/src/sys/kern/sched_ule.c > > bt > > #0 sched_switch (td=0xfffff802c061f490, newtd= > out>, > > flags=) at /usr/src/sys/kern/sched_ule.c:1962 > > #1 0xffffffff808b8c1e in mi_switch (flags=266, newtd=0x0) at > > /usr/src/sys/kern/kern_synch.c:494 > > #2 0xffffffff808c04b0 in thread_suspend_switch > > (td=0xfffff802c061f490) at > > /usr/src/sys/kern/kern_thread.c:883 > > #3 0xffffffff808c0276 in thread_single (mode=1) at > > /usr/src/sys/kern/kern_thread.c:713 > > #4 0xffffffff8087c1bb in exit1 (td=0xfffff802c061f490, rv=9) at > > /usr/src/sys/kern/kern_exit.c:180 > > #5 0xffffffff808b2faf in sigexit (td=, > > sig= > optimized out>) at /usr/src/sys/kern/kern_sig.c:2935 > > #6 0xffffffff808b3669 in postsig (sig=) at > > /usr/src/sys/kern/kern_sig.c:2822 > > #7 0xffffffff808f6f57 in ast (framep=) at > > /usr/src/sys/kern/subr_trap.c:271 > > #8 0xffffffff80c75870 in Xfast_syscall () at > > /usr/src/sys/amd64/amd64/exception.S:416 > > #9 0x0000000801d6f19a in ?? () > > Previous frame inner to this frame (corrupt stack?) > > > > > > thread 371 > > [Switching to thread 371 (Thread 100598)]#0 sched_switch > > (td=0xfffff80221857000, newtd=, flags= > optimized > > out>) at /usr/src/sys/kern/sched_ule.c:1962 > > 1962 in /usr/src/sys/kern/sched_ule.c > > bt > > #0 sched_switch (td=0xfffff80221857000, newtd= > out>, > > flags=) at /usr/src/sys/kern/sched_ule.c:1962 > > #1 0xffffffff808b8c1e in mi_switch (flags=260, newtd=0x0) at > > /usr/src/sys/kern/kern_synch.c:494 > > #2 0xffffffff808f2e3a in sleepq_wait (wchan=0x0, pri=0) at > > /usr/src/sys/kern/subr_sleepqueue.c:620 > > #3 0xffffffff80864aad in _cv_wait (cvp=0xffffffff8147a500, > > lock=0xffffffff8147a480) at /usr/src/sys/kern/kern_condvar.c:139 > > #4 0xffffffff808fb05f in vmem_xalloc (vm=0xffffffff8147a480, > > size0= > optimized out>, align=, phase=0, > > nocross= > optimized out>, minaddr=0, maxaddr=18446735286768857088, > > flags=8194, > > addrp=) at /usr/src/sys/kern/subr_vmem.c:1196 > > #5 0xffffffff808fae6b in vmem_alloc (vm=0x0, size=0, flags= > optimized > > out>, addrp=0xfffffe0466e1d6e8) at > > /usr/src/sys/kern/subr_vmem.c:1082 This looks vaguely similar to what I get when I run the system out of boundary tags. (I say "vaguely similar" because you haven't run out of boundary tags, but you may have vmem_xalloc() failing.) When these functions are called with M_NOWAIT, they return failure and a higher level call in the allocation call stack retries it. Then it loops in the kernel in "R" state, which is why it isn't killable. For my case, I believe it happens when the kernel address space gets too fragmented. Also, alc@ recently fixed a problem for low kernel memory cases. I've cc'd him in case he may be able to help? Btw Alan, I was never able to reproduce the M_WAITOK case although my kernel was older than the patch you discussed. I can fairly easily reproduce the M_NOWAIT case, but haven't tried with a recent kernel yet. I have no idea if increasing vm.kmem_size_max might help? rick > > #6 0xffffffff80b0fa58 in kmem_malloc (vmem=0xffffffff8147a480, > > size=2139729920, flags=2) at /usr/src/sys/vm/vm_kern.c:314 > > #7 0xffffffff80b08dfb in uma_large_malloc (size= > out>, > > wait=2) at /usr/src/sys/vm/uma_core.c:1006 > > #8 0xffffffff80898cf3 in malloc (size=2139729920, > > mtp=0xffffffff813a0450, > > flags=0) at /usr/src/sys/kern/kern_malloc.c:520 > > #9 0xffffffff8096307b in bpf_buffer_ioctl_sblen > > (d=0xfffff80159ea9000, > > i=) at /usr/src/sys/net/bpf_buffer.c:183 > > #10 0xffffffff80960a3c in bpfioctl (dev=0x0, cmd= > out>, > > addr=0xfffff801fbd06b40 "", flags=0, td=0xfffff80221857000) at > > /usr/src/sys/net/bpf.c:408 > > #11 0xffffffff807ac1df in devfs_ioctl_f (fp=0xfffff8002b3d9d20, > > com=3221504614, data=0xfffff801fbd06b40, cred= > out>, > > td=0xfffff80221857000) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > > #12 0xffffffff808fdfae in kern_ioctl (td=0xfffff80221857000, > > fd= > optimized out>, com=0) at file.h:319 > > #13 0xffffffff808fdd2f in sys_ioctl (td=0xfffff80221857000, > > uap=0xfffffe0466e1da40) at /usr/src/sys/kern/sys_generic.c:702 > > #14 0xffffffff80c8f117 in amd64_syscall (td=0xfffff80221857000, > > traced=0) at > > subr_syscall.c:134 > > #15 0xffffffff80c7580b in Xfast_syscall () at > > /usr/src/sys/amd64/amd64/exception.S:391 > > #16 0x0000000801d8f08a in ?? () > > Previous frame inner to this frame (corrupt stack?) > > > > > > Let me know if I can debug this any further. > > > > /Elof > > > > > > > > On Thu, 9 Oct 2014, John-Mark Gurney wrote: > > > >> elof2@sentor.se wrote this message on Wed, Oct 08, 2014 at 13:30 > >> +0200: > >>> > >>> I guess this is a bug report for FreeBSD 10.0. > >>> > >>> > >>> > >>> Sometimes I can't kill my snort process on FreeBSD 10.0. > >>> It won't die, even with kill -9. > >>> > >>> I'm not talking about a zombie process. Snort is a process that > >>> should > >>> die normally. > >>> I've run snort on over 100 nodes since FreeBSD v6.x and I've > >>> never seen > >>> this behavior until now in FreeBSD 10.0. > >>> > >>> > >>> Example: > >>> > >>> #ps faxuw > >>> USER PID %CPU %MEM VSZ RSS TT STAT STARTED > >>> TIME > >>> COMMAND > >>> root 49222 53.4 2.2 492648 183012 - Rs 11:46AM > >>> 7:05.59 > >>> /usr/local/bin/snort -q -D -c snort.conf > >>> root 47937 0.0 2.2 488552 182864 - Ts 10:56AM > >>> 29:35.98 > >>> /usr/local/bin/snort -q -D -c snort.conf > >> > >> What is the MWCHAN? add l to the ps command... > >> > >>> The pid 47937 has been killed (repeatedly) with -9. > >>> Its status is "Ts" meaning it is Stopped. > >> > >> have you tried to kill -CONT to resume it? > >> > >>> But it won't actually die and disappear. The only way to get rid > >>> of it > >>> seem to be to reboot the machine. :-( > >>> > >>> (pid 49222 is the new process that was started after 47937 was > >>> killed) > >>> > >>> > >>> The problem doesn't happen all the time and I haven't found any > >>> patterns > >>> as to when it does. :-( > >>> If I restart snort once every day, it fails to die approximately > >>> 2-4 times > >>> per month. > >>> Even though the problem doesn't happen on every kill, it is a > >>> definately a > >>> recurring event. > >> > >> Can you run kgdb on the machine? (yes, it works on a live > >> machine), use > >> info threads to find the thread id, and then use thread > >> to > >> switch to it, and run bt to get a back trace... > >> > >>> I began to see it on a heavily loaded 10GE sensor, so I thought > >>> it could > >>> have something to do with the ix driver, or the heavy load. > >>> But now another FreeBSD 10.0-sensor had the exact same problem, > >>> and this > >>> sensor don't have any 10GE NICs. In fact, this sensor has been > >>> running > >>> just fine with both FreeBSD 9.1 and 9.3 for the past years. Snort > >>> has > >>> always terminated correctly! After I reinstalled this machine > >>> with FreeBSD > >>> 10.0 last friday, snort has then terminated correctly every day > >>> until > >>> today, when it failed with the above pid 47937. (this sensor use > >>> the 'em' > >>> driver, not 'ixgbe') > >>> > >>> I'm running snort with the same configuration, settings, version, > >>> daq, > >>> libs, etc on 10.0 as I do on 9.3. > >>> None of the 9.3 sensors have this problem, so it has to be > >>> something new > >>> in FreeBSD 10.0. > >> > >> -- > >> John-Mark Gurney Voice: +1 415 225 5579 > >> > >> "All that I will do, has been done, All that I have, has not." > >> > > _______________________________________________ > > 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" > > > _______________________________________________ > 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 Fri Oct 31 19:12:19 2014 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 A49EBA86; Fri, 31 Oct 2014 19:12:19 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D19F6A; Fri, 31 Oct 2014 19:12:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s9VJCCR0042606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2014 12:12:13 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s9VJCCN5042605; Fri, 31 Oct 2014 12:12:12 -0700 (PDT) (envelope-from jmg) Date: Fri, 31 Oct 2014 12:12:12 -0700 From: John-Mark Gurney To: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: any reason not to enable IPDIVERT for ipfw module? Message-ID: <20141031191212.GO8852@funkthat.com> Mail-Followup-To: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 31 Oct 2014 12:12:13 -0700 (PDT) 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, 31 Oct 2014 19:12:19 -0000 Can any one think of a good reason not to enable IPDIVERT sockets in the ipfw module? And possibly enabling default to accept? That way you don't have to go to the console when you load the ipfw module because you forgot to auto add the accept all rule? :) something like: ==== //depot/projects/opencrypto/sys/modules/ipfw/Makefile#3 - /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile ==== --- /tmp/tmp.15774.16 2014-10-31 12:11:56.000000000 -0700 +++ /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile 2014-10-31 12:11:54.000000000 -0700 @@ -16,7 +16,10 @@ #CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100 # #If you want it to pass all packets by default -#CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT +CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT +# +#If you want divert sockets +CFLAGS+= -DIPDIVERT # .include -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 19:14:30 2014 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 C4F25D9C; Fri, 31 Oct 2014 19:14:30 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B077C4; Fri, 31 Oct 2014 19:14:30 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s9VJETXQ042646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2014 12:14:29 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s9VJETUc042645; Fri, 31 Oct 2014 12:14:29 -0700 (PDT) (envelope-from jmg) Date: Fri, 31 Oct 2014 12:14:28 -0700 From: John-Mark Gurney To: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: any reason not to enable IPDIVERT for ipfw module? Message-ID: <20141031191428.GP8852@funkthat.com> Mail-Followup-To: freebsd-net@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20141031191212.GO8852@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141031191212.GO8852@funkthat.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 31 Oct 2014 12:14:29 -0700 (PDT) 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, 31 Oct 2014 19:14:30 -0000 John-Mark Gurney wrote this message on Fri, Oct 31, 2014 at 12:12 -0700: > Can any one think of a good reason not to enable IPDIVERT sockets in > the ipfw module? sorry, ignore this... didn't realize ipdivert was loadable as a separate module, ipdivert... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 01:28:29 2014 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 36C69C7; Sat, 1 Nov 2014 01:28:29 +0000 (UTC) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAD00275; Sat, 1 Nov 2014 01:28:28 +0000 (UTC) Received: by mail-oi0-f50.google.com with SMTP id v63so3124019oia.9 for ; Fri, 31 Oct 2014 18:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=d47zLIZrH06oXHgyEodvKkAFAAFr7Q0KN9R8xb08vAg=; b=ynU8wbfanR04lpBx8Og1HZVAnVegF+1rspxtPWotqZO9F4+wjzWE+8P0mItAZdslfX uTfsr5bEssBv4WmpH6fi2XdaHtnX+jBZuZFUaMgOCPi2y+mMiLdOFchP+lQoApCoT27s 8T6QGC2mOmOR5mQv3rmXeZNWfMP3ab4hHtkT2Vq/cGv3Lx0Mbai4hh5n3RHCauGkRZ3U SMqug+ugEDUdUBtriCwUrXOmTXrT6MA0N94VYmjt4f6jYeX/NNjXu4sbG4V0XQvGo85E cIMKe4E/S4R2HKisXSqAo01WEeVALr/QvawPkPHlf0FFOfR+jiqQN77qKTijksjKpwjl 9J1A== MIME-Version: 1.0 X-Received: by 10.182.18.104 with SMTP id v8mr22769616obd.3.1414805308246; Fri, 31 Oct 2014 18:28:28 -0700 (PDT) Received: by 10.202.104.39 with HTTP; Fri, 31 Oct 2014 18:28:28 -0700 (PDT) Received: by 10.202.104.39 with HTTP; Fri, 31 Oct 2014 18:28:28 -0700 (PDT) In-Reply-To: <20141031191212.GO8852@funkthat.com> References: <20141031191212.GO8852@funkthat.com> Date: Fri, 31 Oct 2014 18:28:28 -0700 Message-ID: Subject: Re: any reason not to enable IPDIVERT for ipfw module? From: Freddie Cash To: FreeBSD Arch , freebsd-net Content-Type: text/plain; charset=UTF-8 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: Sat, 01 Nov 2014 01:28:29 -0000 On Oct 31, 2014 12:12 PM, "John-Mark Gurney" wrote: > > Can any one think of a good reason not to enable IPDIVERT sockets in > the ipfw module? > > And possibly enabling default to accept? That way you don't have to > go to the console when you load the ipfw module because you forgot to > auto add the accept all rule? :) You can change the default rule to accept via loader.conf and it will be set when the module is loaded. net.inet.IP.fw.default_to_accept or something Luke that. > something like: > ==== //depot/projects/opencrypto/sys/modules/ipfw/Makefile#3 - /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile ==== > --- /tmp/tmp.15774.16 2014-10-31 12:11:56.000000000 -0700 > +++ /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile 2014-10-31 12:11:54.000000000 -0700 > @@ -16,7 +16,10 @@ > #CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100 > # > #If you want it to pass all packets by default > -#CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT > +CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT > +# > +#If you want divert sockets > +CFLAGS+= -DIPDIVERT > # > > .include > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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 Sat Nov 1 03:23:03 2014 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 E37DEEE9 for ; Sat, 1 Nov 2014 03:23:03 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC0ACECD for ; Sat, 1 Nov 2014 03:23:03 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id a13so2043761igq.11 for ; Fri, 31 Oct 2014 20:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ni94mpPSQNeNNS1AjLdI5j4Viyxi2Xu+l6HTtCidghc=; b=slTguRf+6rIEyi+/1KgetoZ5RP5tbDY5FF8MvjhoWob3lgCgM/fBD47Afrouqef844 pQKacaqN8UQ92yUzexZa75yO6KsHkc91U5O27ok6ZupjhdijGHyAIBUVetmnG9ko0SJx I8D7OB+uLybkhZRPw0Lq6wf8N/muBbqMF3AeJqByHL67M4mscbKGjIPU/BhekhEDus5o uQ2dzj0XQUaL5K+Ljh09DzgcojPEC0/CSK2wutCPoCgePLYIODHPLBhy7/+jsLscEDAN 1CcsRZdKRhQH+7D1u2kzw7DEIRTlOruFmr/jG3xDIg3eD/75FYrU88zTFzgkdKd24Cd9 JoHA== MIME-Version: 1.0 X-Received: by 10.43.75.138 with SMTP id za10mr27840465icb.23.1414812182976; Fri, 31 Oct 2014 20:23:02 -0700 (PDT) Received: by 10.64.9.33 with HTTP; Fri, 31 Oct 2014 20:23:02 -0700 (PDT) Date: Fri, 31 Oct 2014 23:23:02 -0400 Message-ID: Subject: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq From: Chris Inacio To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Sat, 01 Nov 2014 03:23:04 -0000 Hello all, I've tried to find this information in so many ways, but I just can't piece it together, maybe my Google fu is failing me. I have my router/gateway device running FreeBSD 10p11 - so its up to date. On my internal network interface, re1, I'm using dnsmasq to serve both IPv4 DHCP and current private network IPv6 (fc00::). I can successfully configure my public interface (re0) to get IPv6 information from Comcast. I'm getting both a /128 NA for the interface as well as a prefix /64 to allocate IPv6 addresses. The problem is that I get the /64 via dhcp6c operating on my re0 interface, and then I can't figure out how to pass that information to dnsmasq to use it for my internal network. I could only see the /64 by running dhcp6c in foreground+debug mode. Is there a simple solution to this? I'm okay with variations such as "stop using dhcp6c to get the /64 prefix and add `XXXXX` to dnsmasq to do it" or "use dhcp6s to serve the /64 prefix". I am currently having a few issues with dnsmasq, but generally, I still like it. (It keeps crashing with signal 11, but I'm using the version from pkg which doesn't call out to an init script.) But the way dnsmasq handles DHCP, local DNS, and support DNSSEC I like a lot. I find the man pages for dhcp6 pretty awful. The man pages describe the options - but not being able to find what /64 is assigned to dhcp6c other than running in debug mode seems crazy. My configs are really basic. dhcp6c.conf: interface re0 { send ia-pd 0; send ia-na 1; }; id-assoc na 1 { }; id-assoc pd { prefix ::/56 infinity; prefix-interface re0 { sla-len 4; sla-id 1; }; }; dnsmasq.conf: interface=re1 dhcp-range=re1,192.168.1.1,192.168.1.150,255.255.255.0,12h domain-needed bogus-priv resolv-file=/usr/local/etc/dnsmasq-resolv.conf # # serve up our own name # interface-name=aticusjr,re1 # # enable DNSSEC # conf-file=/usr/local/share/dnsmasq/trust-anchors.conf dnssec dnssec-check-unsigned # # do IPv6 router advertisements for internal network # dhcp-range=::,constructor:re1,ra-only enable-ra Any help would be greatly appreciated. thanks Chris From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 03:52:22 2014 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 28120304 for ; Sat, 1 Nov 2014 03:52:22 +0000 (UTC) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D85271A4 for ; Sat, 1 Nov 2014 03:52:21 +0000 (UTC) Received: from [172.16.21.114] (cpe-098-122-037-156.sc.res.rr.com [98.122.37.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EAE921C47; Fri, 31 Oct 2014 23:41:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq From: Tom Pusateri In-Reply-To: Date: Fri, 31 Oct 2014 23:43:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Chris Inacio X-Mailer: Apple Mail (2.1990.1) 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: Sat, 01 Nov 2014 03:52:22 -0000 > On Oct 31, 2014, at 11:23 PM, Chris Inacio wrote: >=20 > Hello all, >=20 > I've tried to find this information in so many ways, but I just can't = piece > it together, maybe my Google fu is failing me. >=20 > I have my router/gateway device running FreeBSD 10p11 - so its up to = date. > On my internal network interface, re1, I'm using dnsmasq to serve both = IPv4 > DHCP and current private network IPv6 (fc00::). >=20 > I can successfully configure my public interface (re0) to get IPv6 > information from Comcast. I'm getting both a /128 NA for the = interface as > well as a prefix /64 to allocate IPv6 addresses. >=20 > The problem is that I get the /64 via dhcp6c operating on my re0 = interface, > and then I can't figure out how to pass that information to dnsmasq to = use > it for my internal network. I could only see the /64 by running = dhcp6c in > foreground+debug mode. >=20 > Is there a simple solution to this? I'm okay with variations such as = "stop > using dhcp6c to get the /64 prefix and add `XXXXX` to dnsmasq to do = it" or > "use dhcp6s to serve the /64 prefix". >=20 > I am currently having a few issues with dnsmasq, but generally, I = still > like it. (It keeps crashing with signal 11, but I'm using the version = from > pkg which doesn't call out to an init script.) But the way dnsmasq = handles > DHCP, local DNS, and support DNSSEC I like a lot. >=20 > I find the man pages for dhcp6 pretty awful. The man pages describe = the > options - but not being able to find what /64 is assigned to dhcp6c = other > than running in debug mode seems crazy. >=20 > My configs are really basic. dhcp6c.conf: >=20 > interface re0 { >=20 > send ia-pd 0; >=20 > send ia-na 1; >=20 > }; >=20 >=20 > id-assoc na 1 { >=20 > }; >=20 >=20 > id-assoc pd { >=20 > prefix ::/56 infinity; >=20 > prefix-interface re0 { >=20 > sla-len 4; >=20 > sla-id 1; >=20 > }; >=20 > }; >=20 >=20 > dnsmasq.conf: >=20 >=20 > interface=3Dre1 >=20 > dhcp-range=3Dre1,192.168.1.1,192.168.1.150,255.255.255.0,12h >=20 > domain-needed >=20 > bogus-priv >=20 > resolv-file=3D/usr/local/etc/dnsmasq-resolv.conf >=20 >=20 > # >=20 > # serve up our own name >=20 > # >=20 > interface-name=3Daticusjr,re1 >=20 >=20 >=20 > # >=20 > # enable DNSSEC >=20 > # >=20 > conf-file=3D/usr/local/share/dnsmasq/trust-anchors.conf >=20 > dnssec >=20 > dnssec-check-unsigned >=20 >=20 > # >=20 > # do IPv6 router advertisements for internal network >=20 > # >=20 > dhcp-range=3D::,constructor:re1,ra-only >=20 > enable-ra >=20 >=20 > Any help would be greatly appreciated. >=20 >=20 > thanks >=20 > Chris I have a similar setup on Time Warner that is working. However, I am = using rtadvd for advertising to my internal networks. Also, I was under = the impression that Comcast only would delegate a /64 or a /60, not a = /56. Timer Warner does delegate a /56. Maybe Comcast has changed. In your case, you are asking for a /56 but then only want to assign 4 = bits off the /64 so your config is inconsistent. You should change to sla-len 8 for a /56 or change the prefix to /60 for = an sla-len of 4. dhcp6c should configure the delegated prefix on your downstream = interface(s) if configured correctly and rtadvd will advertise them = automatically. I have described my configuration here and what should work on Comcast. = Ignore the initial rant about NAT. :) = http://stateful.blogspot.com/2014/09/global-ip-addresses-for-end-to-end.ht= ml If this doesn't help, let me know and I can help you figure it out. Thanks, Tom From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 05:09:49 2014 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 AF2D1FB0 for ; Sat, 1 Nov 2014 05:09:49 +0000 (UTC) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 886604E for ; Sat, 1 Nov 2014 05:09:49 +0000 (UTC) Received: from [172.16.21.114] (cpe-098-122-037-156.sc.res.rr.com [98.122.37.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 8CB691C66; Sat, 1 Nov 2014 01:08:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq From: Tom Pusateri In-Reply-To: Date: Sat, 1 Nov 2014 01:09:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCDF08D-BAF5-4747-91FF-968E51B6AEED@bangj.com> References: To: Chris Inacio X-Mailer: Apple Mail (2.1990.1) 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: Sat, 01 Nov 2014 05:09:49 -0000 > On Oct 31, 2014, at 11:43 PM, Tom Pusateri wrote: >=20 >>=20 >> On Oct 31, 2014, at 11:23 PM, Chris Inacio = wrote: >>=20 >> My configs are really basic. dhcp6c.conf: >>=20 >> interface re0 { >>=20 >> send ia-pd 0; >>=20 >> send ia-na 1; >>=20 >> }; >>=20 >>=20 >> id-assoc na 1 { >>=20 >> }; >>=20 >>=20 >> id-assoc pd { >>=20 >> prefix ::/56 infinity; >>=20 >> prefix-interface re0 { >>=20 >> sla-len 4; >>=20 >> sla-id 1; >>=20 >> }; >>=20 >> }; In addition to my earlier post, you are missing the ID for the ia-pd = association. replace: id-assoc pd { with: id-assoc pd 0 { and you are referencing your upstream interface instead of your = downstream interface in the delegated prefix-interface statement. replace: prefix-interface re0 { with prefix-interface re1 { Thanks, Tom From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 05:16:11 2014 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 EDC0B1CB; Sat, 1 Nov 2014 05:16:11 +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 44F411D6; Sat, 1 Nov 2014 05:16:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA15G85D081579; Sat, 1 Nov 2014 16:16:08 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 1 Nov 2014 16:16:07 +1100 (EST) From: Ian Smith To: Freddie Cash Subject: Re: any reason not to enable IPDIVERT for ipfw module? In-Reply-To: Message-ID: <20141101144834.N52402@sola.nimnet.asn.au> References: <20141031191212.GO8852@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net , freebsd-ipfw@freebsd.org, FreeBSD Arch 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, 01 Nov 2014 05:16:12 -0000 On Fri, 31 Oct 2014 18:28:28 -0700, Freddie Cash wrote: > On Oct 31, 2014 12:12 PM, "John-Mark Gurney" wrote: > > > > Can any one think of a good reason not to enable IPDIVERT sockets in > > the ipfw module? Yes, two. Nowadays people are just as or perhaps more likely to use in-kernel NAT, loading ipfw_nat.ko instead of ipdivert.ko, and there's no good reason to add extra code to ipfw.ko unless it's going to be used. See libalias(3) /MODULAR ARCHITECTURE Similaly there'd be no reason to include dummynet code unless using it. > > And possibly enabling default to accept? That way you don't have to > > go to the console when you load the ipfw module because you forgot to > > auto add the accept all rule? :) That'd reverse some 15+ years of security policy, of having the firewall closed until you've loaded your ruleset, to cater to forgetfulness? :) > You can change the default rule to accept via loader.conf and it will be > set when the module is loaded. > > net.inet.IP.fw.default_to_accept or something Luke that. Yes, net.inet.ip.fw.default_to_accept=1 is a loader tunable, and can be set before ipfw is loaded, unlike the net.inet.ip.fw sysctls which don't exist until ipfw is loaded. Or it can be set to 0 to reverse policy if kernel has been built with 'options IPFIREWALL_DEFAULT_TO_ACCEPT'. Normally /etc/rc.d/ipfw takes care of loading ipfw_nat or ipdivert (or both if you wanted to use both natd(8) and ipfw_nat for some reason?) and/or dummynet, according to the rc.conf variables. I've added freebsd-ipfw@ to ccs, just because it seems relevant .. cheers, Ian > > something like: > > ==== //depot/projects/opencrypto/sys/modules/ipfw/Makefile#3 - > /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile ==== > > --- /tmp/tmp.15774.16 2014-10-31 12:11:56.000000000 -0700 > > +++ /home/jmg/freebsd.p4/opencrypto/sys/modules/ipfw/Makefile > 2014-10-31 12:11:54.000000000 -0700 > > @@ -16,7 +16,10 @@ > > #CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100 > > # > > #If you want it to pass all packets by default > > -#CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT > > +CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT > > +# > > +#If you want divert sockets > > +CFLAGS+= -DIPDIVERT > > # > > > > .include > > > > -- > > John-Mark Gurney Voice: +1 415 225 5579 > > > > "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 05:54:02 2014 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 33CB57F3 for ; Sat, 1 Nov 2014 05:54:02 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 072BC92B for ; Sat, 1 Nov 2014 05:54:01 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NEC008ZAJ1RIB90@st11p02mm-asmtp001.mac.com> for freebsd-net@freebsd.org; Sat, 01 Nov 2014 05:53:54 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-01_02:2014-10-31,2014-11-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411010065 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq From: Rui Paulo In-reply-to: Date: Fri, 31 Oct 2014 22:53:51 -0700 Content-transfer-encoding: quoted-printable Message-id: <44D1EB57-CFB0-4E78-822C-29A9FEA85A66@me.com> References: To: Chris Inacio X-Mailer: Apple Mail (2.1990.1) 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: Sat, 01 Nov 2014 05:54:02 -0000 On Oct 31, 2014, at 20:23, Chris Inacio wrote: >=20 > Hello all, >=20 > I've tried to find this information in so many ways, but I just can't = piece > it together, maybe my Google fu is failing me. >=20 > I have my router/gateway device running FreeBSD 10p11 - so its up to = date. > On my internal network interface, re1, I'm using dnsmasq to serve both = IPv4 > DHCP and current private network IPv6 (fc00::). This prefix has been depreciated. Why aren't you giving global IPv6 = addresses internally anyway? > I can successfully configure my public interface (re0) to get IPv6 > information from Comcast. I'm getting both a /128 NA for the = interface as > well as a prefix /64 to allocate IPv6 addresses. >=20 > The problem is that I get the /64 via dhcp6c operating on my re0 = interface, > and then I can't figure out how to pass that information to dnsmasq to = use > it for my internal network. I could only see the /64 by running = dhcp6c in > foreground+debug mode. The way this works is by prefix delegation. dhcp6c gets a delegated = prefix from the DHCPv6 server and then it's supposed to configure it on = your internal network (re1). You could theoretically write a script that runs when you get a prefix = which configures dnsmasq, but to be honest letting dhcp6c configure the = prefix on your internal network and then running rtadvd is much easier. = Not to mention that not every system out there supports DHCPv6 by = default. > Is there a simple solution to this? I'm okay with variations such as = "stop > using dhcp6c to get the /64 prefix and add `XXXXX` to dnsmasq to do = it" or > "use dhcp6s to serve the /64 prefix". >=20 > I am currently having a few issues with dnsmasq, but generally, I = still > like it. (It keeps crashing with signal 11, but I'm using the version = from > pkg which doesn't call out to an init script.) But the way dnsmasq = handles > DHCP, local DNS, and support DNSSEC I like a lot. >=20 > I find the man pages for dhcp6 pretty awful. The man pages describe = the > options - but not being able to find what /64 is assigned to dhcp6c = other > than running in debug mode seems crazy. There's an alternative: dhclient from ports which includes DHCPv6 = support with prefix delegation. >=20 > My configs are really basic. dhcp6c.conf: >=20 > interface re0 { >=20 > send ia-pd 0; >=20 > send ia-na 1; >=20 > }; >=20 >=20 > id-assoc na 1 { >=20 > }; >=20 >=20 > id-assoc pd { >=20 > prefix ::/56 infinity; >=20 > prefix-interface re0 { >=20 > sla-len 4; >=20 > sla-id 1; >=20 > }; >=20 > }; >=20 >=20 > dnsmasq.conf: >=20 >=20 > interface=3Dre1 >=20 > dhcp-range=3Dre1,192.168.1.1,192.168.1.150,255.255.255.0,12h >=20 > domain-needed >=20 > bogus-priv >=20 > resolv-file=3D/usr/local/etc/dnsmasq-resolv.conf >=20 >=20 > # >=20 > # serve up our own name >=20 > # >=20 > interface-name=3Daticusjr,re1 >=20 >=20 >=20 > # >=20 > # enable DNSSEC >=20 > # >=20 > conf-file=3D/usr/local/share/dnsmasq/trust-anchors.conf >=20 > dnssec >=20 > dnssec-check-unsigned >=20 >=20 > # >=20 > # do IPv6 router advertisements for internal network >=20 > # >=20 > dhcp-range=3D::,constructor:re1,ra-only >=20 > enable-ra >=20 >=20 > Any help would be greatly appreciated. >=20 >=20 > thanks >=20 > Chris > _______________________________________________ > 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" -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 12:08:41 2014 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 655F1E8; Sat, 1 Nov 2014 12:08:41 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB698E4F; Sat, 1 Nov 2014 12:08:40 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id n3so3180699wiv.12 for ; Sat, 01 Nov 2014 05:08:39 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+Qrb8VLlc7TT+OA2A1Fhc+NHpa2loyKle8r3Mj1Cenc=; b=XduhlgQrh5W6fzs1fEUO9OObZ73Z7Iii9o9jmQfpkfPR1Vevj4SgmcUh6bZGqSDlIn uFfiEqNq7xFti3IxADbVqLi1qKemINSwqH7kLXnkoQq43FPg2H+lmgE/90uFP3diMVgi cqheELdMS6D8xU/LSXU2ZB5GrXovbSXMrCkI3RIXW3kKeCSQzkNH6bE90v60P44VkdrR s2YschzamC5bU3/yzIpsx+p3so5sdYG1VAQMPEkT8oSysyV5rwhhuVET7X2MEgqvmwR/ 2JTbFF2jUgwW8IfoJ15CfqPTyQj016y9j+nYicfC+Yp/hJ+pcR7J9eW4Zm/kfJLAFBTR Nnxg== X-Received: by 10.180.205.171 with SMTP id lh11mr3619438wic.66.1414843718978; Sat, 01 Nov 2014 05:08:38 -0700 (PDT) Received: from [192.168.2.30] ([2.176.150.113]) by mx.google.com with ESMTPSA id wc7sm15185143wjc.8.2014.11.01.05.08.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Nov 2014 05:08:38 -0700 (PDT) Message-ID: <5454CD41.9010704@gmail.com> Date: Sat, 01 Nov 2014 15:38:33 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ian Smith Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> <5453A3F0.7010706@gmail.com> <20141101035050.R52402@sola.nimnet.asn.au> In-Reply-To: <20141101035050.R52402@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Felder 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, 01 Nov 2014 12:08:41 -0000 On 10/31/2014 8:30 PM, Ian Smith wrote: > On Fri, 31 Oct 2014 18:30:00 +0330, Hooman Fazaeli wrote: > > On 10/31/2014 5:30 PM, Mark Felder wrote: > > > I'm not sure if this is what you're looking for, but perhaps the > > > solution is in net/samplicator ? > > > > > > From the project's website: > > > > > > This simple program listens for UDP datagrams on a network port, and > > > sends copies of these datagrams on to a set of destinations. Optionally, > > > it can perform sampling, i.e. rather than forwarding every packet, > > > forward only 1 in N. Another option is that it can "spoof" the IP source > > > address, so that the copies appear to come from the original source, > > > rather than the relay. Currently only supports IPv4. > > > Thanks. I do not thinks it provides what I am looking for. > > > > I am not looking for an application performing a specific task, but a > > mechanism to get the __original__ destination address and port of > > packets forwarded to a local UDP proxy by ipfw fwd rules. As I > > figured it out until now, The original destination address may be > > obtained by IP_RECVDSTADDR on 9.0+ (but not on 8.x and older > > versions) but there seems to be no mechanism get the _original_ > > destination _port_ (Apart from this missing mechanism, my proxy is > > functional and performs what it is intended to do). > > : ipfw add 10 fwd localhost,7000 udp from any to any recv em1 > > Given these are local packets and that ipfw(8) /fwd states: > > The fwd action does not change the contents of the packet at all. > In particular, the destination address remains unmodified, so > packets forwarded to another system will usually be rejected by > that system unless there is a matching rule on that system to > capture them. For packets forwarded locally, the local address > of the socket will be set to the original destination address of > the packet. This makes the netstat(1) entry look rather weird > but is intended for use with transparent proxy servers. For FreeBSDs before 9.0, that description is only correct for TCP packets. For 9.0+, it is true for both UDP and TCP. Old kernels (before 9.0), change the destination of UDP packets forwarded to a local address to the forwarded-to address and port (those specified in the fwd rule). > Has the destination port in the received packet been changed to 7000? > > If not, you're all set. If so, where else could the dst port be stored? > > cheers, Ian There is no way to get the destination port. That is the problem. recvmsg(2) only returns source address+port and destination IP address. (on 9.0+). -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 12:10:12 2014 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 35D97178; Sat, 1 Nov 2014 12:10:12 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76510E5C; Sat, 1 Nov 2014 12:10:11 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so9599403wgh.10 for ; Sat, 01 Nov 2014 05:10:09 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0bVNHJINdogJyToy15vIKe4tpddUPr3sNgN0rSWAQ74=; b=v2kIVY07ahzpQKO8ktmWRxR0PwwJwGZ7NbfMOVvpX4clXw9xEaH0CIjGEPimd0FVGM TOzj2Xs6EeRSSlAOrQwaHHLANKGSIgJIL8b77pY+RV52AQbcXi4ZJIAD2cPV40DQqY4E w1rj7DY92vedPsKpnAGBjuis+Tg0suWVQ9VXavuvQs/O8RsPCVf+mBh2wzCt+l8RTwRl VhGyoE/V50lYppanaC1vpMnuTQdKPH8g9mjRoobcn6aydA5IyjP1nQxCDEB2dHyRoYvv fljhURHYg0bqoU+Sq05cFdoUrzqYTm3ADVDcqMYAGdlo8KCdpgVJk0bvf0pSmUGU2LI7 NhxA== X-Received: by 10.180.221.229 with SMTP id qh5mr3578458wic.25.1414843809732; Sat, 01 Nov 2014 05:10:09 -0700 (PDT) Received: from [192.168.2.30] ([2.176.150.113]) by mx.google.com with ESMTPSA id cz3sm15175877wjb.23.2014.11.01.05.10.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Nov 2014 05:10:09 -0700 (PDT) Message-ID: <5454CDA0.1070301@gmail.com> Date: Sat, 01 Nov 2014 15:40:08 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: transparent udp proxy References: <54535B82.405@gmail.com> <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> <5453A3F0.7010706@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Mark Felder 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, 01 Nov 2014 12:10:12 -0000 On 10/31/2014 8:11 PM, Adrian Chadd wrote: > Hi, > > If it's missing in 10 or later then please file a bug and I'll see > what it'll take to add another socket option to return the original > destination address+port. > > Thanks, > > > -adrian > > Thanks. I will check ASAP. -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 14:00:35 2014 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 9A45CE1B; Sat, 1 Nov 2014 14:00:35 +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 EF886AD3; Sat, 1 Nov 2014 14:00:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA1E0TpL099245; Sun, 2 Nov 2014 01:00:29 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 2 Nov 2014 01:00:29 +1100 (EST) From: Ian Smith To: Hooman Fazaeli Subject: Re: transparent udp proxy In-Reply-To: <5454CD41.9010704@gmail.com> Message-ID: <20141102003200.S52402@sola.nimnet.asn.au> References: <54535B82.405@gmail.com> <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> <5453A3F0.7010706@gmail.com> <20141101035050.R52402@sola.nimnet.asn.au> <5454CD41.9010704@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Mark Felder 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, 01 Nov 2014 14:00:35 -0000 On Sat, 1 Nov 2014 15:38:33 +0330, Hooman Fazaeli wrote: > On 10/31/2014 8:30 PM, Ian Smith wrote: [..] > > : ipfw add 10 fwd localhost,7000 udp from any to any recv em1 > > > > Given these are local packets and that ipfw(8) /fwd states: > > > > The fwd action does not change the contents of the packet at all. > > In particular, the destination address remains unmodified, so > > packets forwarded to another system will usually be rejected by > > that system unless there is a matching rule on that system to > > capture them. For packets forwarded locally, the local address > > of the socket will be set to the original destination address of > > the packet. This makes the netstat(1) entry look rather weird > > but is intended for use with transparent proxy servers. > For FreeBSDs before 9.0, that description is only correct for TCP > packets. For 9.0+, it is true for both UDP and TCP. Ok. Well that description, up to that point, is identical from 8.2 to 9.3, so it's been wrong (and incomplete, re UDP) for a long time .. That's what I get for treating ipfw(8) with undue reverence while having virtually no knowledge of socket internals :) Unless you're not getting them in recvmsg() as ipfw forwarded them? Sorry, I'll quit speculating; way out of my depth - or rather, level. > Old kernels (before 9.0), change the destination of UDP packets forwarded to > a local address to > the forwarded-to address and port (those specified in the fwd rule). > > > Has the destination port in the received packet been changed to 7000? > > > > If not, you're all set. If so, where else could the dst port be stored? > There is no way to get the destination port. That is the problem. > recvmsg(2) only returns source address+port and destination IP > address. (on 9.0+). I naively ass(13)umed you'd still have access to raw IP and UDP headers, and that they'd indeed be unchanged. > Best regards. > Hooman Fazaeli cheers (and out), Ian From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 15:23:18 2014 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 15FF9C38 for ; Sat, 1 Nov 2014 15:23:18 +0000 (UTC) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E204C1B5 for ; Sat, 1 Nov 2014 15:23:17 +0000 (UTC) Received: from [172.16.21.114] (cpe-098-122-037-156.sc.res.rr.com [98.122.37.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id B642D1D2E; Sat, 1 Nov 2014 11:21:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Help with IPv6 router gateway config, Comcast, DHCP, dnsmasq From: Tom Pusateri In-Reply-To: <44D1EB57-CFB0-4E78-822C-29A9FEA85A66@me.com> Date: Sat, 1 Nov 2014 11:23:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <92438892-0AAC-4866-B7D9-BAA5B4AF9D9D@bangj.com> References: <44D1EB57-CFB0-4E78-822C-29A9FEA85A66@me.com> To: Rui Paulo X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-net@freebsd.org, Chris Inacio 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, 01 Nov 2014 15:23:18 -0000 > On Nov 1, 2014, at 1:53 AM, Rui Paulo wrote: >=20 >> I find the man pages for dhcp6 pretty awful. The man pages describe = the >> options - but not being able to find what /64 is assigned to dhcp6c = other >> than running in debug mode seems crazy. >=20 > There's an alternative: dhclient from ports which includes DHCPv6 = support with prefix delegation. >=20 Chris' config error caused dhcp6c not to configure his downstream = interface. dhclient from ports will only work with the default prefix length = assigned by the provider. For all providers I have encountered, this is = /64 and a good choice. But if you want multiple /64's for multiple = interfaces, you have to request a larger prefix (/56 or /60 depending on = the policy of the provider). dhclient in ports will not let you do this. In Chris' case, he only has a single downstream interface (for now) and = so dhclient in ports would work for that. Tom= From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 20:23:14 2014 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 903896B1 for ; Sat, 1 Nov 2014 20:23:14 +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 "smtp.wp.pl", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D8A312E for ; Sat, 1 Nov 2014 20:23:13 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 5061 invoked from network); 1 Nov 2014 21:23:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1414873384; bh=dygxzCDkfkTBJqe7WEVADYXHhJkbIwPO85sBbab1im8=; h=From:To:Subject; b=jNCSKdGiCdDOLN3G6KgiXQgsgtYGkgdBYoYQ6H0uik118gPHKwdteYq7Q2J1DkYbf R1jT+QWu1fSJQSh2iwFizDXunMpAntApy0+KrrSjvhjLxldmroQ5I+yY7XYYqL7Xbq utjcxSWMFg3iy/S6zMKggXop2BOoi8YYQaIdlxYI= Received: from 250-210-250-178.ftth.cust.kwaoo.net (HELO [10.0.5.13]) (marek_sal@[178.250.210.250]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for ; 1 Nov 2014 21:23:04 +0100 Message-ID: <54554126.8030606@wp.pl> Date: Sat, 01 Nov 2014 21:23:02 +0100 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Multicast routing, IGMP, IPTV doubts.. References: <543D9C48.3010907@wp.pl> In-Reply-To: <543D9C48.3010907@wp.pl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [wcNE] 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, 01 Nov 2014 20:23:14 -0000 Hello all, W dniu 2014-10-14 o 23:57, Marek Salwerowicz pisze: > Hi all, > > My home router is small FreeBSD 10 box, with 3 ethernet ports, I use > pf as a firewall. > > My ISP provides FTTH, that ends at my home with a small box called > CPE. The CPE contains 4 ethernet ports. On one port I have Internet > access, on the other there is IPTV (that's based on udp/multicast) > > The IPTV works well - when I connect directly my PC to IPTV ethernet > socket - I can watch TV. > > But I would like to have both Internet and IPTV on my desktop at the > same time. > > I've downloaded the igmpproxy package, set up config: despite the igmpproxy software seems to be fixed - no more outputs like: received packet from 10.66.255.248 shorter (32 bytes) than hdr+data length (24+32) I still can't get it running correctly. I have several questions: 1- is loading module ip_mroute sufficient or DO I need really recompile kernel with option MROUTING? 2- does igmpproxy work with if_bridge(4) interfaces (it bridges WiFi with cable LAN) 3- is there any other software I could try? 4- how could I debug the process of multicast routing between upstream and downstream interface? Cheers Marek From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 20:25:23 2014 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 4B06B758; Sat, 1 Nov 2014 20:25:23 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 2B874144; Sat, 1 Nov 2014 20:25:22 +0000 (UTC) Received: from [192.168.192.206] (unknown [129.253.54.225]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 1C8E0193964; Sat, 1 Nov 2014 20:25:11 +0000 (UTC) Subject: Re: urtwn(4) Random freezes, urtwn_getbuf: out of xmit buffers From: Sean Bruno Reply-To: sbruno@freebsd.org To: FreeBSD Net In-Reply-To: <1414696307.1773.12.camel@bruno> References: <1414525275.43009.3.camel@bruno> <20141030025241.GA73148@ns.kevlo.org> <1414692589.1773.11.camel@bruno> <1414696307.1773.12.camel@bruno> Content-Type: text/plain; charset="us-ascii" Date: Sat, 01 Nov 2014 13:24:49 -0700 Message-ID: <1414873489.2069.1.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Kevin Lo 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, 01 Nov 2014 20:25:23 -0000 ooo lovely. Able to get two different panics out of my laptop today. Both in urtwn(4). Is this a USB problem and not a driver failure? https://people.freebsd.org/~sbruno/core.txt.1 https://people.freebsd.org/~sbruno/core.txt.0 sean From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 20:49:10 2014 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 4BF7516D for ; Sat, 1 Nov 2014 20:49:10 +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 "smtp.wp.pl", Issuer "Thawte SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9BF634A for ; Sat, 1 Nov 2014 20:49:09 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 1358 invoked from network); 1 Nov 2014 21:48:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1414874939; bh=kE8hbdYiTIlNi0a7IwSUMnzbP22LSh56jgK8Sp5ZptQ=; h=From:To:Subject; b=vVVCTdsgAmVGnHEm+yP4OSlhxaKAny+e5qPBF3PwD4f5yE5XVHXSYrSFLQxG6BP0i etl9BLS4TDpcKRfogUDHh0tdKukj/h4Z8eJzQgWyBlBwulHigXZi8xq/wwUeKHF11T kFVCNXMJ5pMFU0SnqPmqEmVlFF+SPAO8Rya2zDT0= 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 ; 1 Nov 2014 21:48:59 +0100 Message-ID: <5455472F.7030905@wp.pl> Date: Sat, 01 Nov 2014 21:48:47 +0100 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: Extending TCP window size in FreeBSD 10-RELEASE? 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 [MbN0] 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, 01 Nov 2014 20:49:10 -0000 Hi all, There are 2 boxes with FreeBSD 10-RELEASE: FreeBSD storage3 10.0-RELEASE-p10 FreeBSD 10.0-RELEASE-p10 #0: Mon Oct 20 12:42:25 UTC 2014 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 They are connected using L2 IPsec VPN iperf with extended window size (iperf -s -w 1400K) shows that the connection bandwidth between hosts is around 4Mbit/s I would like to transmit data from box1 ZFS pool to box2 ZFS pool. I am using the mbuffer to do this: on box2 (dst): # mbuffer -v 5 -4 -I 9090 | zfs receive -Fduv tank1/ze-storage2 on box1(src): # zfs send -R tank1/PROD@20141030 | mbuffer -v 5 -4 -O 172.25.25.85:9090 The transfer speed is around 180KB/s (~2Mbit/s) After Googling, I realised I might need to extend the TCP Window (as mbuffer does not extend TCP Window size). On both boxes, I have tuned the following sysctls: # sysctl kern.ipc.maxsockbuf=16777216 # sysctl net.inet.tcp.sendspace=1048576 # sysctl net.inet.tcp.recvspace=1048576 # sysctl net.inet.tcp.rfc1323=1 However, it doesn't make the speed transmission faster. Changing the mbuffer options to: -s 128k -m 1G Neither helps. Do you have any idea how to saturate the L2 IPSec VPN connection between hosts? regards, Marek -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Sat Nov 1 22:45:54 2014 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 6656DEEA; Sat, 1 Nov 2014 22:45:54 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id F0961F8E; Sat, 1 Nov 2014 22:45:53 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAIthVVSDaFve/2dsb2JhbABZA4NiWASDAsoyCoZ5VAKBKgEBAQEBfYQDAQEEAQEBICsgCxsYAgINGQIpAQkmDgcEARwEiCANtH6UFwEBAQEGAQEBAQEBARuBLY8SAQEbJBAHEYJmgVQFlmmEEoR0lGKEFCEvB4EIOYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,295,1413259200"; d="scan'208";a="163906056" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 01 Nov 2014 18:45:46 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 703A7B3FAC; Sat, 1 Nov 2014 18:45:46 -0400 (EDT) Date: Sat, 1 Nov 2014 18:45:46 -0400 (EDT) From: Rick Macklem To: elof2@sentor.se Message-ID: <808120111.3848488.1414881946448.JavaMail.root@uoguelph.ca> In-Reply-To: <1603084759.3305578.1414782414065.JavaMail.root@uoguelph.ca> Subject: Re: Unable to kill a non-zombie process with -9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: alc@freebsd.org, freebsd-net , John-Mark Gurney 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, 01 Nov 2014 22:45:54 -0000 I wrote: > elof2@sentor.se wrote: > > > > No one have any thoughts about this? > > > > Its happening sporadically on several FreeBSD 10 machines of mine, > > while > > all of the FreeBSD 9-machines work just fine. > > > > If the problem isn't fixed, people won't be able to upgrade to and > > run > > snort on FreeBSD 10. > > > > log: > > > > > I'm starting snort (as root). > > > > > > <<>> > > > Oct 15 08:46:59 snort[22646]: Initializing daemon mode > > > Oct 15 08:46:59 snort[22648]: Daemon initialized, signaled parent > > > pid: 22646 > > > Oct 15 08:46:59 snort[22648]: Reload thread starting... > > > Oct 15 08:46:59 snort[22648]: Reload thread started, thread > > > 0x8146e8800 (22648) > > > End of log. > > > > > > Error! Nothing more happens with the snort process! > > > Normally it should continue and log the following lines as well: > > > > > > > > > snort[nnn]: Decoding Ethernet > > > snort[nnn]: Checking PID path... > > > snort[nnn]: PID path stat checked out ok, PID path set to > > > /var/run/ > > > snort[nnn]: Writing PID "7627" to file "/var/run//snort_mon0.pid" > > > snort[nnn]: Chroot directory = /usr/foobar/log > > > snort[nnn]: Set gid to 100 > > > snort[nnn]: Set uid to 100 > > > snort[nnn]: > > > snort[nnn]: --== Initialization Complete ==-- > > > snort[nnn]: Commencing packet processing (pid=nnn) > > > > > > > > > > > > > > > > > > When looking at this half-started snort process with 'ps', it > > > looks > > > like > > > this: > > > > > > ps faxulwwj 22648 > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > > COMMAND UID PPID CPU PRI NI MWCHAN PGID SID JOBC > > > root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > > > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > > > > > > > > The process is still owned by root, so just as the missing log > > > lines are > > > saying, it has not yet performed any change of uid/gid. > > > > > > > > > > > > > > > So there seem to be two questions. > > > > > > Q1) > > > What happens between "Reload thread started, thread 0x8146e8800 > > > (22648)" and > > > "Decoding Ethernet"? > > > Apparently something goes wrong here on FreeBSD 10.0. > > > (this problem does not always occur, sometimes snort start just > > > fine) > > > > > > Q2) > > > When the process has frozen in this half-started state, it can't > > > be > > > killed > > > even with a -9. Why? > > > > > > > > > > > > > > > John-Mark asked me for some debugging info. Here it is: > > > > > > I now run 'kill 22648' on the above semi-started process: > > > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > > COMMAND UID > > > PPID CPU PRI NI MWCHAN PGID SID JOBC > > > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > > > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > > new root 22648 52.3 1.1 488552 179344 - Rs 8:46AM 53:36.48 > > > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > > > > > No change. > > > > > > > > > > > > kill -9 22648 > > > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > > COMMAND UID > > > PPID CPU PRI NI MWCHAN PGID SID JOBC > > > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > > > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > > new root 22648 37.7 1.1 488552 179344 - Ts 8:46AM 53:50.87 > > > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > > > > > Less CPU-usage and STAT changed to "Ts". > > > > > > > > > > > > > > > kill -CONT 22648 > > > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > > > COMMAND UID > > > PPID CPU PRI NI MWCHAN PGID SID JOBC > > > old root 22648 51.8 1.1 488552 179344 - Rs 8:46AM 53:06.52 > > > /usr/local/bin/s 0 1 0 88 0 - 22648 22648 0 > > > new root 22648 0.0 1.1 488552 179344 - Ts 8:46AM 53:50.88 > > > /usr/local/bin/s 0 1 0 52 0 - 22648 22648 0 > > > > > > No change except cpu is down to 0. > > > > > > > > > I now start 'kgdb' > > > info threads > > > I found two threads for snort, doing a bt for both of them: > > > 372 Thread 100602 (PID=22648: snort) sched_switch > > > (td=0xfffff802c061f490, > > > newtd=, flags=) at > > > /usr/src/sys/kern/sched_ule.c:1962 > > > 371 Thread 100598 (PID=22648: snort) sched_switch > > > (td=0xfffff80221857000, > > > newtd=, flags=) at > > > /usr/src/sys/kern/sched_ule.c:1962 > > > thread 372 > > > [Switching to thread 372 (Thread 100602)]#0 sched_switch > > > (td=0xfffff802c061f490, newtd=, flags= > > optimized > > > out>) at /usr/src/sys/kern/sched_ule.c:1962 > > > 1962 in /usr/src/sys/kern/sched_ule.c > > > bt > > > #0 sched_switch (td=0xfffff802c061f490, newtd= > > out>, > > > flags=) at > > > /usr/src/sys/kern/sched_ule.c:1962 > > > #1 0xffffffff808b8c1e in mi_switch (flags=266, newtd=0x0) at > > > /usr/src/sys/kern/kern_synch.c:494 > > > #2 0xffffffff808c04b0 in thread_suspend_switch > > > (td=0xfffff802c061f490) at > > > /usr/src/sys/kern/kern_thread.c:883 > > > #3 0xffffffff808c0276 in thread_single (mode=1) at > > > /usr/src/sys/kern/kern_thread.c:713 > > > #4 0xffffffff8087c1bb in exit1 (td=0xfffff802c061f490, rv=9) at > > > /usr/src/sys/kern/kern_exit.c:180 > > > #5 0xffffffff808b2faf in sigexit (td=, > > > sig= > > optimized out>) at /usr/src/sys/kern/kern_sig.c:2935 > > > #6 0xffffffff808b3669 in postsig (sig=) at > > > /usr/src/sys/kern/kern_sig.c:2822 > > > #7 0xffffffff808f6f57 in ast (framep=) at > > > /usr/src/sys/kern/subr_trap.c:271 > > > #8 0xffffffff80c75870 in Xfast_syscall () at > > > /usr/src/sys/amd64/amd64/exception.S:416 > > > #9 0x0000000801d6f19a in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > > > > > > > thread 371 > > > [Switching to thread 371 (Thread 100598)]#0 sched_switch > > > (td=0xfffff80221857000, newtd=, flags= > > optimized > > > out>) at /usr/src/sys/kern/sched_ule.c:1962 > > > 1962 in /usr/src/sys/kern/sched_ule.c > > > bt > > > #0 sched_switch (td=0xfffff80221857000, newtd= > > out>, > > > flags=) at > > > /usr/src/sys/kern/sched_ule.c:1962 > > > #1 0xffffffff808b8c1e in mi_switch (flags=260, newtd=0x0) at > > > /usr/src/sys/kern/kern_synch.c:494 > > > #2 0xffffffff808f2e3a in sleepq_wait (wchan=0x0, pri=0) at > > > /usr/src/sys/kern/subr_sleepqueue.c:620 > > > #3 0xffffffff80864aad in _cv_wait (cvp=0xffffffff8147a500, > > > lock=0xffffffff8147a480) at /usr/src/sys/kern/kern_condvar.c:139 > > > #4 0xffffffff808fb05f in vmem_xalloc (vm=0xffffffff8147a480, > > > size0= > > optimized out>, align=, phase=0, > > > nocross= > > optimized out>, minaddr=0, maxaddr=18446735286768857088, > > > flags=8194, > > > addrp=) at > > > /usr/src/sys/kern/subr_vmem.c:1196 > > > #5 0xffffffff808fae6b in vmem_alloc (vm=0x0, size=0, > > > flags= > > optimized > > > out>, addrp=0xfffffe0466e1d6e8) at > > > /usr/src/sys/kern/subr_vmem.c:1082 > This looks vaguely similar to what I get when I run the system out of > boundary tags. (I say "vaguely similar" because you haven't run out > of > boundary tags, but you may have vmem_xalloc() failing.) > > When these functions are called with M_NOWAIT, they return failure > and > a higher level call in the allocation call stack retries it. Then it > loops in the kernel in "R" state, which is why it isn't killable. > For my case, I believe it happens when the kernel address space gets > too > fragmented. Also, alc@ recently fixed a problem for low kernel > memory cases. I've cc'd him in case he may be able to help? > > Btw Alan, I was never able to reproduce the M_WAITOK case although my > kernel was older than the patch you discussed. I can fairly easily > reproduce the M_NOWAIT case, but haven't tried with a recent kernel > yet. > > I have no idea if increasing vm.kmem_size_max might help? > > rick > Btw, the patch I was alluding to is r272071 in head (MFC'd to stable/10 as r272221). It is a one-line change to sys/vm/vm_pageout.c. I have no idea if this patch can be applied safely to 10.0, but it might be worth trying the patch to see if it helps with this. rick > > > #6 0xffffffff80b0fa58 in kmem_malloc (vmem=0xffffffff8147a480, > > > size=2139729920, flags=2) at /usr/src/sys/vm/vm_kern.c:314 > > > #7 0xffffffff80b08dfb in uma_large_malloc (size= > > out>, > > > wait=2) at /usr/src/sys/vm/uma_core.c:1006 > > > #8 0xffffffff80898cf3 in malloc (size=2139729920, > > > mtp=0xffffffff813a0450, > > > flags=0) at /usr/src/sys/kern/kern_malloc.c:520 > > > #9 0xffffffff8096307b in bpf_buffer_ioctl_sblen > > > (d=0xfffff80159ea9000, > > > i=) at /usr/src/sys/net/bpf_buffer.c:183 > > > #10 0xffffffff80960a3c in bpfioctl (dev=0x0, cmd= > > out>, > > > addr=0xfffff801fbd06b40 "", flags=0, td=0xfffff80221857000) at > > > /usr/src/sys/net/bpf.c:408 > > > #11 0xffffffff807ac1df in devfs_ioctl_f (fp=0xfffff8002b3d9d20, > > > com=3221504614, data=0xfffff801fbd06b40, cred= > > out>, > > > td=0xfffff80221857000) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 > > > #12 0xffffffff808fdfae in kern_ioctl (td=0xfffff80221857000, > > > fd= > > optimized out>, com=0) at file.h:319 > > > #13 0xffffffff808fdd2f in sys_ioctl (td=0xfffff80221857000, > > > uap=0xfffffe0466e1da40) at /usr/src/sys/kern/sys_generic.c:702 > > > #14 0xffffffff80c8f117 in amd64_syscall (td=0xfffff80221857000, > > > traced=0) at > > > subr_syscall.c:134 > > > #15 0xffffffff80c7580b in Xfast_syscall () at > > > /usr/src/sys/amd64/amd64/exception.S:391 > > > #16 0x0000000801d8f08a in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > > > > > > > Let me know if I can debug this any further. > > > > > > /Elof > > > > > > > > > > > > On Thu, 9 Oct 2014, John-Mark Gurney wrote: > > > > > >> elof2@sentor.se wrote this message on Wed, Oct 08, 2014 at 13:30 > > >> +0200: > > >>> > > >>> I guess this is a bug report for FreeBSD 10.0. > > >>> > > >>> > > >>> > > >>> Sometimes I can't kill my snort process on FreeBSD 10.0. > > >>> It won't die, even with kill -9. > > >>> > > >>> I'm not talking about a zombie process. Snort is a process that > > >>> should > > >>> die normally. > > >>> I've run snort on over 100 nodes since FreeBSD v6.x and I've > > >>> never seen > > >>> this behavior until now in FreeBSD 10.0. > > >>> > > >>> > > >>> Example: > > >>> > > >>> #ps faxuw > > >>> USER PID %CPU %MEM VSZ RSS TT STAT STARTED > > >>> TIME > > >>> COMMAND > > >>> root 49222 53.4 2.2 492648 183012 - Rs 11:46AM > > >>> 7:05.59 > > >>> /usr/local/bin/snort -q -D -c snort.conf > > >>> root 47937 0.0 2.2 488552 182864 - Ts 10:56AM > > >>> 29:35.98 > > >>> /usr/local/bin/snort -q -D -c snort.conf > > >> > > >> What is the MWCHAN? add l to the ps command... > > >> > > >>> The pid 47937 has been killed (repeatedly) with -9. > > >>> Its status is "Ts" meaning it is Stopped. > > >> > > >> have you tried to kill -CONT to resume it? > > >> > > >>> But it won't actually die and disappear. The only way to get > > >>> rid > > >>> of it > > >>> seem to be to reboot the machine. :-( > > >>> > > >>> (pid 49222 is the new process that was started after 47937 was > > >>> killed) > > >>> > > >>> > > >>> The problem doesn't happen all the time and I haven't found any > > >>> patterns > > >>> as to when it does. :-( > > >>> If I restart snort once every day, it fails to die > > >>> approximately > > >>> 2-4 times > > >>> per month. > > >>> Even though the problem doesn't happen on every kill, it is a > > >>> definately a > > >>> recurring event. > > >> > > >> Can you run kgdb on the machine? (yes, it works on a live > > >> machine), use > > >> info threads to find the thread id, and then use thread > > >> > > >> to > > >> switch to it, and run bt to get a back trace... > > >> > > >>> I began to see it on a heavily loaded 10GE sensor, so I thought > > >>> it could > > >>> have something to do with the ix driver, or the heavy load. > > >>> But now another FreeBSD 10.0-sensor had the exact same problem, > > >>> and this > > >>> sensor don't have any 10GE NICs. In fact, this sensor has been > > >>> running > > >>> just fine with both FreeBSD 9.1 and 9.3 for the past years. > > >>> Snort > > >>> has > > >>> always terminated correctly! After I reinstalled this machine > > >>> with FreeBSD > > >>> 10.0 last friday, snort has then terminated correctly every day > > >>> until > > >>> today, when it failed with the above pid 47937. (this sensor > > >>> use > > >>> the 'em' > > >>> driver, not 'ixgbe') > > >>> > > >>> I'm running snort with the same configuration, settings, > > >>> version, > > >>> daq, > > >>> libs, etc on 10.0 as I do on 9.3. > > >>> None of the 9.3 sensors have this problem, so it has to be > > >>> something new > > >>> in FreeBSD 10.0. > > >> > > >> -- > > >> John-Mark Gurney Voice: +1 415 225 5579 > > >> > > >> "All that I will do, has been done, All that I have, has > > >> not." > > >> > > > _______________________________________________ > > > 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" > > > > > _______________________________________________ > > 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" > > > _______________________________________________ > 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" >