From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 05:19:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65AF9106564A; Sun, 10 Jun 2012 05:19:54 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C52448FC0A; Sun, 10 Jun 2012 05:19:53 +0000 (UTC) Received: by werg1 with SMTP id g1so1731874wer.13 for ; Sat, 09 Jun 2012 22:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:to:x-mailer; bh=JEInYSbAlWZ7xrES8D35BwvWYDo2DXI1g3V+zW5Qoqg=; b=ieBc+F+7sf/UbUJgaRPghjL+M9csoYtehMeqSHSyr6O9E8hZ273Lh4jFwfiHyaAztU isrAat7iBXf0xwf1O1AsFs8theJkIz72HcbBd0FqouDAh9xDAL7kAIJKwQ7Hf7nARtg0 JiHxdzmtzSg0vQT74Xpe9pvjLvV2fDMIDCZr4baGuEKfKLYFho2qkZJMV/PYseAxL4Uw mugga9MOdkL3bYCw6+8vUWATW7ARTyW0nM6W9pXkfaHA8WIgtMR4j5KRJCBdllI+mmGi tqFzHkJ1XIElcbbYbyx5N8hzaerYxk9+aedUFHkp5NeQABjQlHzwyFsHKToEB96iyxWl w3bw== Received: by 10.180.98.201 with SMTP id ek9mr11754081wib.7.1339305592668; Sat, 09 Jun 2012 22:19:52 -0700 (PDT) Received: from [10.0.0.86] ([93.152.184.10]) by mx.google.com with ESMTPS id f7sm22784854wiv.2.2012.06.09.22.19.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jun 2012 22:19:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Nikolay Denev Date: Sun, 10 Jun 2012 08:19:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <89C1E1C1-FE04-419D-B4C7-893AF8C12843@gmail.com> To: freebsd-net X-Mailer: Apple Mail (2.1278) Cc: jfv@freebsd.org Subject: 82599EB not supported by ixgbe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2012 05:19:54 -0000 Hello Jack, It seems the following controller is not yet supported by ixgbe(4) : none4@pci0:3:0:0: class=3D0x020000 card=3D0x7b118086 = chip=3D0x154d8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82599EB 10-Gigabit SFP+ Network Connection' class =3D network subclass =3D ethernet none5@pci0:3:0:1: class=3D0x020000 card=3D0x7b118086 = chip=3D0x154d8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82599EB 10-Gigabit SFP+ Network Connection' class =3D network subclass =3D ethernet Any ideas on how to get that working? Is it just a matter of adding the = PCI ID to the source? (I'll try that now) or are there any other differences. Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 07:32:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12E27106566B; Sun, 10 Jun 2012 07:32:54 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 727888FC12; Sun, 10 Jun 2012 07:32:53 +0000 (UTC) Received: by werg1 with SMTP id g1so1769472wer.13 for ; Sun, 10 Jun 2012 00:32:52 -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=E1enrrTkB+CGOVdFFpf3p2CDi2lTzP3s8PnQtvZzJSE=; b=rB2AOavZirpRf5KpttvMD7Kzs7PFasu7VNFlFCfc47e/36Q1cKtGZp/4jy0eMr/0QS 0RB/Z1QSNgFblX2gXHQb/YNKTM+Y/iut+DEEm4hcmCXgzjzPewT7DJPxIXFY7ZJKSVY8 XXVpNoqo1SXhOmR/9D4zvN4ZCW1oXzpbx1aEK3Dctfc4QIkpjpNuxzjmZlGzJmh0N8su lcdJwq56PmiqKiHmzXszsucZZ+G/vS9cjtiskuTcMyvht3FBAmquJpq5Tzsez/NlRved 5kGHHD4YS+8NVoEMMnuKMXSJzjWdmLZoC4Ammxo/XQUVnYTrgiORTXnz/5XC8S8r6BYz CI1A== MIME-Version: 1.0 Received: by 10.216.150.225 with SMTP id z75mr4365756wej.77.1339313572394; Sun, 10 Jun 2012 00:32:52 -0700 (PDT) Received: by 10.180.105.232 with HTTP; Sun, 10 Jun 2012 00:32:52 -0700 (PDT) In-Reply-To: <89C1E1C1-FE04-419D-B4C7-893AF8C12843@gmail.com> References: <89C1E1C1-FE04-419D-B4C7-893AF8C12843@gmail.com> Date: Sun, 10 Jun 2012 00:32:52 -0700 Message-ID: From: Jack Vogel To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: jfv@freebsd.org, freebsd-net Subject: Re: 82599EB not supported by ixgbe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2012 07:32:54 -0000 This was a special 'skew' of the 82599 done for Dell, and as they did not request FreeBSD it did not get called out in our internal development procedures, however you are the second person in a fairly short time who has requested it, and after checking things out there appears to be no reason not to add the ID, so that will be coming shortly. Regards, Jack On Sat, Jun 9, 2012 at 10:19 PM, Nikolay Denev wrote: > Hello Jack, > > It seems the following controller is not yet supported by ixgbe(4) : > > none4@pci0:3:0:0: class=0x020000 card=0x7b118086 chip=0x154d8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82599EB 10-Gigabit SFP+ Network Connection' > class = network > subclass = ethernet > none5@pci0:3:0:1: class=0x020000 card=0x7b118086 chip=0x154d8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82599EB 10-Gigabit SFP+ Network Connection' > class = network > subclass = ethernet > > Any ideas on how to get that working? Is it just a matter of adding the > PCI ID to the source? (I'll try that now) or are > there any other differences. > > Regards, > Nikolay From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 08:04:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42328106566C for ; Sun, 10 Jun 2012 08:04:22 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id B93CD8FC14 for ; Sun, 10 Jun 2012 08:04:21 +0000 (UTC) Received: by wibhj8 with SMTP id hj8so1515635wib.13 for ; Sun, 10 Jun 2012 01:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=NZDJwtIw9vyi5VS4WDXS4bgfRqT1kGZT6jM5410dGYY=; b=h/S8c8+ncQY28Qs4RAjzobWtTe73pmSYa1Tw+3MPl/vFtzEAbvWKcAumKBapm5iZHI 9TwPxJWDGRYXTNUa/1roNac9libga0ib0NCQBUv6H6CeNE5NZInac1cn3wHwYb5KbqcM BMVVCxNW7b1Eqr5+z/ZCGa5qsDMUtgfPR/ADbLTKyHIC2LOsk9ginSdjepZM2vXD+VAG yrDkTmw5AEdaby9zwSK8ApwWTf2ClI6DhrPWgonTIbE07Ih3OSbAh8mi8rL6y+1K1R1K t2TT5/X4F9oYZKsi8QKjwu1yLL1kIoI8FlDkYwPXQLliY6fSFchNyEwyMUwsHSB5XqSQ 0MEQ== Received: by 10.180.98.231 with SMTP id el7mr12352254wib.21.1339315460582; Sun, 10 Jun 2012 01:04:20 -0700 (PDT) Received: from [10.0.0.86] (93-152-184-10.ddns.onlinedirect.bg. [93.152.184.10]) by mx.google.com with ESMTPS id dg2sm24162183wib.4.2012.06.10.01.04.18 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Jun 2012 01:04:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) From: Nikolay Denev In-Reply-To: Date: Sun, 10 Jun 2012 11:04:16 +0300 Message-Id: <3FD0A7C3-ACD9-4264-9891-926CC9ABA6A9@gmail.com> References: <89C1E1C1-FE04-419D-B4C7-893AF8C12843@gmail.com> To: Jack Vogel X-Mailer: Apple Mail (2.1278) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net Subject: Re: 82599EB not supported by ixgbe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2012 08:04:22 -0000 Cool, thanks Jack! Cheers, Nikolay On Jun 10, 2012, at 10:32 AM, Jack Vogel wrote: > This was a special 'skew' of the 82599 done for Dell, and as they did = not request > FreeBSD it did not get called out in our internal development = procedures, however > you are the second person in a fairly short time who has requested it, = and after > checking things out there appears to be no reason not to add the ID, = so that will > be coming shortly. >=20 > Regards, >=20 > Jack >=20 >=20 > On Sat, Jun 9, 2012 at 10:19 PM, Nikolay Denev = wrote: > Hello Jack, >=20 > It seems the following controller is not yet supported by ixgbe(4) : >=20 > none4@pci0:3:0:0: class=3D0x020000 card=3D0x7b118086 = chip=3D0x154d8086 rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82599EB 10-Gigabit SFP+ Network Connection' > class =3D network > subclass =3D ethernet > none5@pci0:3:0:1: class=3D0x020000 card=3D0x7b118086 = chip=3D0x154d8086 rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82599EB 10-Gigabit SFP+ Network Connection' > class =3D network > subclass =3D ethernet >=20 > Any ideas on how to get that working? Is it just a matter of adding = the PCI ID to the source? (I'll try that now) or are > there any other differences. >=20 > Regards, > Nikolay >=20 From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 17:40:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169451065670 for ; Sun, 10 Jun 2012 17:40:05 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B3EDC8FC18 for ; Sun, 10 Jun 2012 17:40:04 +0000 (UTC) Received: by yenl8 with SMTP id l8so2336029yen.13 for ; Sun, 10 Jun 2012 10:40:04 -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=cNeW4lF+7s5mBxSsBs7QCHdO2phu3SQZ41xHaOTrSZ8=; b=YDywgEd2EZerjOl/9O1X+tlz5OMnedVRt+d5Y4iFkd7naw3eL3Rz7pYISlsdeKhpDo +vLYzdUlt+7SgbPG2XMgHhFeD+lf7VU5zYn1g/OBjCNRvyAsuu06sj4uzd9h9+TdPMJO GM7+6LjCF7CJVF9ePALmSwXXSXiaJXMDsSooX+9sw52LB5bofceqHHYKRd3gqRQQXJsq oi1b+OJCWkzaViZ/JqaIMN8C7IsslIzcf4FmivJdziOR0rTSwLDpQs2/Qpez5nrpj/uB sjDA/yK4J/nktnlYba5DyheJ4VmpFllKCg9vLT1mIMGUPLs4HYg+CpPXr7dwSDZCYNSN v1sw== MIME-Version: 1.0 Received: by 10.236.185.38 with SMTP id t26mr17249699yhm.92.1339350004089; Sun, 10 Jun 2012 10:40:04 -0700 (PDT) Received: by 10.100.164.11 with HTTP; Sun, 10 Jun 2012 10:40:04 -0700 (PDT) Date: Sun, 10 Jun 2012 10:40:04 -0700 Message-ID: From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Route addition/deletion by nd6_prefix_(on/off)link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2012 17:40:05 -0000 Hi, I have a question regarding route addition and deletion from these functions for IPv6. Why do we need it? Shouldn't the address configuration take care of installing subnet routes and deletion should take care of their deletion. best, Prabhakar From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 20:49:29 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7A3C1065674 for ; Sun, 10 Jun 2012 20:49:29 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 88CE48FC12 for ; Sun, 10 Jun 2012 20:49:29 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so4918359pbb.13 for ; Sun, 10 Jun 2012 13:49:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=ry4ZAt8PxcZAJhSTMzpKON4rBEZrgfoxyWYVs/H318Y=; b=hGdTZnJEkl1ZQbeQbeCXwI5kQiuthTFTaprR3r/HiCYmK/w/JhsLmMsU3I8eenYAqF Ii44z70Se1CmLd3L4Inkc7wKuDfRQujNHTaOVgeBaDrV7wkEcxKr78lA0DxrtCiFJXTM nf53y8n4uNUgrMgonlnWBOc7gsjHYCBFBUu4/DMoG5bOo9Qc1z5ilYXDpptW4G60hoT0 xAwrZMuX2dpkVEu5euSdS9SujDd+btWc6NWN4AmLMOy4hODf1N/RKi60SWMOy6F4IbJ6 8cfmL7psQ1/AFMeS/gmeskwdSuMyTNAYypXqDXd3CTcrA6AqtWvfswjUCX6mO70m5eEJ xx1A== MIME-Version: 1.0 Received: by 10.68.197.198 with SMTP id iw6mr19438445pbc.36.1339361369146; Sun, 10 Jun 2012 13:49:29 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.73.161 with HTTP; Sun, 10 Jun 2012 13:49:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Jun 2012 08:49:29 +1200 X-Google-Sender-Auth: m_zDPkzZ0EvqnZY0bNs88Ups_O0 Message-ID: From: Andrew Thompson To: Gustau Perez Querol Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm+CLTaNFId8i7AS4837668NIllrTQWfIBoLwPyFUoBIWoNcDhK95WwqxU+8cQz+HLow8HS Cc: net@freebsd.org Subject: Re: Panic with if_bridge when removing components X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2012 20:49:29 -0000 On 10 June 2012 02:27, Gustau Perez Querol wrote: > =A0Hi, > > =A0I'm seeing panics when removing an interface of a bridge. The system r= uns > HEAD/AMD64 r236733. I see no changes to if_bridge.c in the last two days,= so > I would say the problem's still there. I also checked stable and the prob= lem > should be there too. > > =A0The problem is that I have a bridge composed of two ethernet interface= s, an > ath interface and a tap. As soon as I remove any of them the system panic= s. > Because the system runs openvpn with the tap connected to the bridge, whe= n > the system starts to reboot, the openvpn daemon removes the tap and thus > causing also the panic. > > =A0The panic comes because at sys/net/if_bridge.c:943 the struct > *ifnet->if_bridge of the interface removed is set to NULL too early. Beca= use > of this, at sys/net/if_bridge.c:996 we call if_bridge.c:bridge_linkstate > where the struct *ifnet->if_bridge is needed. This causes the panic. I introduced this issue in r234487, please try this patch. http://people.freebsd.org/~thompsa/bridge_link.diff regards, Andrew From owner-freebsd-net@FreeBSD.ORG Sun Jun 10 23:26:01 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 574A5106566B; Sun, 10 Jun 2012 23:26:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9E38FC18; Sun, 10 Jun 2012 23:26:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5ANQ1R6045977; Sun, 10 Jun 2012 23:26:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5ANQ1dR045973; Sun, 10 Jun 2012 23:26:01 GMT (envelope-from linimon) Date: Sun, 10 Jun 2012 23:26:01 GMT Message-Id: <201206102326.q5ANQ1dR045973@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/168670: [vlan] [panic] BPF kernel crash X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2012 23:26:01 -0000 Old Synopsis: BPF kernel crash New Synopsis: [vlan] [panic] BPF kernel crash Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 10 23:25:09 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=168670 From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 03:25:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9DA8106566C for ; Mon, 11 Jun 2012 03:25:29 +0000 (UTC) (envelope-from jeffutter@sadclown.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E2D68FC1C for ; Mon, 11 Jun 2012 03:25:29 +0000 (UTC) Received: by yenl8 with SMTP id l8so2461593yen.13 for ; Sun, 10 Jun 2012 20:25:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=W9AbgU9ck5dYHY53Sj/fMWZTHn6liSP8RDvLrmAaXI8=; b=d8b7Iq3EDjIh8YSwdAQ1uYcqYKmcLdwa2Rpynhc9LEHC5CGwOcr4/FuKcfSfgRP9jB aG3szQ45QHLnqKdUEgXgD+jjdSGAolitvWMnlUzPPavNLXAlm5ScWCdxzTjzH+lw4S5V hrCTdcZM841ztm1lhkVcbaXKR3jLoJ1Qhglzqs8qRL2cZhOWpRqFOMApn2C2EnC605kw J+qKpgzR2M9UP+JE30FiGVcsdIUo1nQGqE0R4VDy7mrevlpZScHfwAoTW2MlR/8nPioW S7RsC/RlSY3SGxr9M3uhr/5jezZtr414QlX07OBi+gDvlIIUUfE4BNEG6vr/JWynGlb3 oNfw== Received: by 10.236.183.227 with SMTP id q63mr18435759yhm.114.1339385128025; Sun, 10 Jun 2012 20:25:28 -0700 (PDT) Received: from [192.168.1.65] (75-48-125-111.lightspeed.klmzmi.sbcglobal.net. [75.48.125.111]) by mx.google.com with ESMTPS id q32sm23353780anh.21.2012.06.10.20.25.26 (version=SSLv3 cipher=OTHER); Sun, 10 Jun 2012 20:25:27 -0700 (PDT) Message-ID: <4FD56526.6090008@sadclown.net> Date: Sun, 10 Jun 2012 23:25:26 -0400 From: Jeffery Utter User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120602 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQnsff4N0WuZtnSuUBYj0M4Loj1nEd/BSlDcHWIeMK2hBE26fbxo/O94lG9yrhymxUKr6QGl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: BCM57781 Adapter Hangs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 03:25:29 -0000 Hi! (Hope this is the right place to ask this) I have a BCM57781 adapter built into a new ASRock motherboard. The adapter runs great, however it periodically dies - about once a day. When it dies existing connections (like ssh) work fine, but any new incoming or outgoing connections fail. I am not running a firewall. When in the crashed state I've checked my ifconfig/routes/resolve.conf all looks good. I have also checked the max/current sockets in sysctl and it is nowhere near the max. The only thing I can do to get my connection working again is /etc/rc.d/netif restart. # pciconf -lvvv bge0@pci0:3:0:0: class=0x020000 card=0x96b11849 chip=0x16b114e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetLink BCM57781 Gigabit Ethernet PCIe' class = network subclass = ethernet # dmesg |grep bge bge0: mem 0xf2110000-0xf211ffff,0xf2100000-0xf210ffff irq 19 at device 0.0 on pci3 bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E miibus0: on bge0 bge0: Ethernet address: bc:5f:f4:43:87:9e # uname -a FreeBSD jeffu-htpc 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu Jun 7 13:34:56 EDT 2012 root@jeffu-htpc:/usr/obj/usr/src/sys/GENERIC amd64 Here is some output while the problem is occurring: # ping google.com ping: cannot resolve google.com: Host name lookup failure # cat /etc/resolv.conf # Generated by resolvconf search gateway.2wire.net nameserver 192.168.1.254 # netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.254 UGS 0 402197 bge0 localhost link#6 UH 0 286788 lo0 192.168.1.0 link#3 U 0 77598 bge0 192.168.1.65 link#3 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire :: localhost UGRS lo0 localhost link#6 UH lo0 ::ffff:0.0.0.0 localhost UGRS lo0 fe80:: localhost UGRS lo0 fe80::%lo0 link#6 U lo0 fe80::1%lo0 link#6 UHS lo0 ff01::%lo0 localhost U lo0 ff02:: localhost UGRS lo0 ff02::%lo0 localhost U lo0 # sysctl -a |grep sockets kern.ipc.maxsockets: 25600 kern.ipc.numopensockets: 251 # dmesg |grep bge bge0: mem 0xf2110000-0xf211ffff,0xf2100000-0xf210ffff irq 19 at device 0.0 on pci3 bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E miibus0: on bge0 bge0: Ethernet address: bc:5f:f4:43:87:9e bge0: link state changed to DOWN bge0: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP ^--- the up/downs were from much earlier # ping 192.168.1.254 PING 192.168.1.254 (192.168.1.254): 56 data bytes --- 192.168.1.254 ping statistics --- 352 packets transmitted, 0 packets received, 100.0% packet loss # ifconfig -a bge0: flags=8843 metric 0 mtu 1500 options=c019b ether bc:5f:f4:43:87:9e inet 192.168.1.65 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active What can i do to troubleshoot this? I've checked the bge manpage and don't see anything related to debugging. From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 05:17:48 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6673A1065670; Mon, 11 Jun 2012 05:17:48 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id DBD0F8FC16; Mon, 11 Jun 2012 05:17:47 +0000 (UTC) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q5B5HePd022802; Mon, 11 Jun 2012 07:17:41 +0200 Received: from webmail.entel.upc.edu (wireless.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id B1C202CBD18; Mon, 11 Jun 2012 07:17:35 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 11 Jun 2012 07:17:35 +0200 From: Gustau Perez Querol To: Andrew Thompson In-Reply-To: References: Message-ID: <3ef7f25e2c85a10266421a7e120d73c2@webmail.entel.upc.edu> X-Sender: gperez@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Mon, 11 Jun 2012 07:17:41 +0200 (CEST) Cc: net@freebsd.org Subject: Re: Panic with if_bridge when removing components X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 05:17:48 -0000 On Mon, 11 Jun 2012 08:49:29 +1200, Andrew Thompson wrote: > On 10 June 2012 02:27, Gustau Perez Querol > wrote: >>  Hi, >> >>  I'm seeing panics when removing an interface of a bridge. The >> system runs >> HEAD/AMD64 r236733. I see no changes to if_bridge.c in the last two >> days, so >> I would say the problem's still there. I also checked stable and the >> problem >> should be there too. >> >>  The problem is that I have a bridge composed of two ethernet >> interfaces, an >> ath interface and a tap. As soon as I remove any of them the system >> panics. >> Because the system runs openvpn with the tap connected to the >> bridge, when >> the system starts to reboot, the openvpn daemon removes the tap and >> thus >> causing also the panic. >> >>  The panic comes because at sys/net/if_bridge.c:943 the struct >> *ifnet->if_bridge of the interface removed is set to NULL too early. >> Because >> of this, at sys/net/if_bridge.c:996 we call >> if_bridge.c:bridge_linkstate >> where the struct *ifnet->if_bridge is needed. This causes the panic. > > > I introduced this issue in r234487, please try this patch. > http://people.freebsd.org/~thompsa/bridge_link.diff > > regards, > Andrew I'll check this evening (if time permits) and report back. From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 06:17:55 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6981C1065680; Mon, 11 Jun 2012 06:17:55 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9AE8FC19; Mon, 11 Jun 2012 06:17:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5B6Htck040622; Mon, 11 Jun 2012 06:17:55 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5B6HtZm040618; Mon, 11 Jun 2012 06:17:55 GMT (envelope-from melifaro) Date: Mon, 11 Jun 2012 06:17:55 GMT Message-Id: <201206110617.q5B6HtZm040618@freefall.freebsd.org> To: melifaro@FreeBSD.org, freebsd-net@FreeBSD.org, melifaro@FreeBSD.org From: melifaro@FreeBSD.org Cc: Subject: Re: kern/168670: [vlan] [panic] BPF kernel crash X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 06:17:55 -0000 Synopsis: [vlan] [panic] BPF kernel crash Responsible-Changed-From-To: freebsd-net->melifaro Responsible-Changed-By: melifaro Responsible-Changed-When: Mon Jun 11 06:17:08 UTC 2012 Responsible-Changed-Why: Take http://www.freebsd.org/cgi/query-pr.cgi?pr=168670 From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 11:07:29 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 962AD106568A for ; Mon, 11 Jun 2012 11:07:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF1B8FC24 for ; Mon, 11 Jun 2012 11:07:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5BB7TF3053380 for ; Mon, 11 Jun 2012 11:07:29 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5BB7SZ4053378 for freebsd-net@FreeBSD.org; Mon, 11 Jun 2012 11:07:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Jun 2012 11:07:28 GMT Message-Id: <201206111107.q5BB7SZ4053378@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 11:07:29 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166550 net [netinet] [patch] Some log lines about arp do not incl o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 404 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 16:32:37 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3CE6106564A for ; Mon, 11 Jun 2012 16:32:37 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 39E668FC08 for ; Mon, 11 Jun 2012 16:32:37 +0000 (UTC) Received: by bkvi18 with SMTP id i18so4625163bkv.13 for ; Mon, 11 Jun 2012 09:32:36 -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=ZtPRNcyGEJ2l4XfIhM6MaAXo9MaBsksSRezMVW6mMMc=; b=rmYG/D228V7JRtjQu3RxXvouIOqStRkXM9o712+ttiKO7muBx8KEhHrpnV07hEc5cU GKLUQVcS7v1D2pz02Cj9GWWvAV3UmZCLl017CRTQrnn/L3sduEvyKtQ6BDrxbzeHHJXY Io7jRH/iYwbkVVxyhA9w/Yq5wlhAZE5R87wPqwdT3TTtcPYRgmIucK9lfTuLK6A3M4Em lViTJcgrdlMtc31h58oveiwfXvxyiXTmO1L1CNudcZTA7/si8EYgpZi1n4PowA81QAyN XWec/5qcBefbWE+yns/VGVlMK29taLSt/21iGdXyzZKH71VR/t3gqZpNd3RXcNSABC4w EqTA== MIME-Version: 1.0 Received: by 10.205.124.8 with SMTP id gm8mr10396413bkc.90.1339432356135; Mon, 11 Jun 2012 09:32:36 -0700 (PDT) Received: by 10.204.100.83 with HTTP; Mon, 11 Jun 2012 09:32:36 -0700 (PDT) In-Reply-To: <20120608171126.GA29273@onelab2.iet.unipi.it> References: <20120608171126.GA29273@onelab2.iet.unipi.it> Date: Mon, 11 Jun 2012 18:32:36 +0200 Message-ID: From: Andreas Nilsson To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: VALE, a Virtual Local Ethernet. http://info.iet.unipi.it/~luigi/vale/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 16:32:37 -0000 I just read the paper and it looks really promising :) I decided to test it and downloaded http://info.iet.unipi.it/~luigi/netmap/20120608-netmap-picobsd-head-amd64.bin( thanks for making it easy to test! ) I booted it up in kvm and it works great! I got 8.86Mpps (64-byte) in the image, that is nice :) I however wanted to test somewhat more realistic traffic flow, but I could not find any nice way to do it. I tried to start a pkt-gen receiver with 2 threads and then launch 2 senders, but that lead to a kernel panic ;) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x471 fault code = supervisor read data, page not present instruction pointer = ... stack pointer = ... frame pointer = ... code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interupt enabled, resume, IOPL = 0 current process = 108 (pkg-gen) I guess that was not the way to achieve a more realstic IMIX ;) Best regards Andreas On Fri, Jun 8, 2012 at 7:11 PM, Luigi Rizzo wrote: > We have just completed a netmap extensions that let you build a > local high speed switch called VALE which i think can be very useful. > > http://info.iet.unipi.it/~luigi/vale/ > > VALE is a software Virtual Local Ethernet whose ports are accessible > using the netmap API. Designed to be used as the interconnect between > virtual machines (or as a fast local bus), it works as a learning > bridge and supports speeds of up to 20 Mpps with short frames, and > an aggregate 70 Gbit/s with 1514-byte packets. The VALE paper > contains more details and performance measurements. > > VALE is implemented as a small extension of the netmap module, and > is available for FreeBSD and Linux. The source code includes a > backend for qemu and KVM, so you can use VALE to interconnect virtual > machines launching them with > > qemu -net nic -net netmap,ifname=vale0 ... > qemu -net nic -net netmap,ifname=vale1 ... > ... > > Processes can talk to a VALE switch too, so you can use the pkt-gen > or bridge tools that are part of the netmap distribution, or even > the pcap.c module that maps libpcap calls into netmap equivalents. > This lets you use VALE for all sort of pcap-based applications. > > More details, code, bootable images on the VALE page, > > http://info.iet.unipi.it/~luigi/vale/ > > feedback welcome, as usual. > > cheers > luigi > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 16:45:27 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 684A2106568B for ; Mon, 11 Jun 2012 16:45:27 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E4D988FC08 for ; Mon, 11 Jun 2012 16:45:26 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id AF82D7300A; Mon, 11 Jun 2012 19:04:17 +0200 (CEST) Date: Mon, 11 Jun 2012 19:04:17 +0200 From: Luigi Rizzo To: Andreas Nilsson Message-ID: <20120611170417.GA12616@onelab2.iet.unipi.it> References: <20120608171126.GA29273@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: VALE, a Virtual Local Ethernet. http://info.iet.unipi.it/~luigi/vale/ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 16:45:27 -0000 On Mon, Jun 11, 2012 at 06:32:36PM +0200, Andreas Nilsson wrote: > I just read the paper and it looks really promising :) > > I decided to test it and downloaded > http://info.iet.unipi.it/~luigi/netmap/20120608-netmap-picobsd-head-amd64.bin( > thanks for making it easy to test! ) > > I booted it up in kvm and it works great! > > I got 8.86Mpps (64-byte) in the image, that is nice :) I however wanted to well, 8.86Mpps with no receivers i guess ? Otherwise i should really update my numbers :) > test somewhat more realistic traffic flow, but I could not find any nice > way to do it. I tried to start a pkt-gen receiver with 2 threads and then > launch 2 senders, but that lead to a kernel panic ;) as you found out, the code has some rough edges especially when dealing with resource shortage. One thing i forgot to mention (i just updated the main page) is to run the hypervisor with a sufficient amount of memory, e.g. -m 512 (for qemu). But i will need to investigate a bit more what happens with multiple receiving threads. cheers luigi > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x471 > fault code = supervisor read data, page not present > instruction pointer = ... > stack pointer = ... > frame pointer = ... > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interupt enabled, resume, IOPL = 0 > current process = 108 (pkg-gen) > > I guess that was not the way to achieve a more realstic IMIX ;) > > Best regards > Andreas > > On Fri, Jun 8, 2012 at 7:11 PM, Luigi Rizzo wrote: > > > We have just completed a netmap extensions that let you build a > > local high speed switch called VALE which i think can be very useful. > > > > http://info.iet.unipi.it/~luigi/vale/ > > > > VALE is a software Virtual Local Ethernet whose ports are accessible > > using the netmap API. Designed to be used as the interconnect between > > virtual machines (or as a fast local bus), it works as a learning > > bridge and supports speeds of up to 20 Mpps with short frames, and > > an aggregate 70 Gbit/s with 1514-byte packets. The VALE paper > > contains more details and performance measurements. > > > > VALE is implemented as a small extension of the netmap module, and > > is available for FreeBSD and Linux. The source code includes a > > backend for qemu and KVM, so you can use VALE to interconnect virtual > > machines launching them with > > > > qemu -net nic -net netmap,ifname=vale0 ... > > qemu -net nic -net netmap,ifname=vale1 ... > > ... > > > > Processes can talk to a VALE switch too, so you can use the pkt-gen > > or bridge tools that are part of the netmap distribution, or even > > the pcap.c module that maps libpcap calls into netmap equivalents. > > This lets you use VALE for all sort of pcap-based applications. > > > > More details, code, bootable images on the VALE page, > > > > http://info.iet.unipi.it/~luigi/vale/ > > > > feedback welcome, as usual. > > > > cheers > > luigi > > -----------------------------------------+------------------------------- > > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL +39-050-2211611 . via Diotisalvi 2 > > Mobile +39-338-6809875 . 56122 PISA (Italy) > > -----------------------------------------+------------------------------- > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 16:55:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 829D1106564A; Mon, 11 Jun 2012 16:55:50 +0000 (UTC) (envelope-from bkolasinski@anl.gov) Received: from lemmy.anl.gov (lemmy.anl.gov [146.137.14.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB518FC14; Mon, 11 Jun 2012 16:55:50 +0000 (UTC) Received: from HETFIELD.anl.gov ([146.137.14.7]) by lemmy.anl.gov ([146.137.14.2]) with mapi; Mon, 11 Jun 2012 11:55:44 -0500 From: "Kolasinski, Brent D." To: "Alexander V. Chernikov" Date: Mon, 11 Jun 2012 11:55:59 -0500 Thread-Topic: Netgraph and Netflow-v9 Thread-Index: Ac1H8wonw6ngEmCbS1uFXahEzAjKcw== Message-ID: In-Reply-To: <4FD31F0A.5090306@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: Re: Netgraph and Netflow-v9 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 16:55:50 -0000 On 6/9/12 5:01 AM, "Alexander V. Chernikov" wrote: >It should disappear after 5-10 minutes. We're using several FreeBSD v9 >sensors with flowd and it seems to run fine (except first 5 minutes >while waiting for template). I'm aware about the problem with templates >timeout working incorrectly and I plan to fix this soon. Looks like it has disappeared, however I am still not seeing any v9 collection. I am assuming I am using export9 correctly in the ngctl commands? > >> >> Commands I am using to export v9 netflow records in ngctl: >> >> mkpeer bce0: netflow lower iface0 >> name bce0:lower netflow >> connect bce0: netflow: upper out0 >> mkpeer netflow: ksocket export9 inet/dgram/udp >> msg netflow:export9 connect inet/: >> >> >> > >--=20 >WBR, Alexander Thanks --Brent From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 17:37:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 01BAE1065672 for ; Mon, 11 Jun 2012 17:37:34 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id E226814DEB0; Mon, 11 Jun 2012 17:36:20 +0000 (UTC) Message-ID: <4FD62C86.4020905@FreeBSD.org> Date: Mon, 11 Jun 2012 21:36:06 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120511 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Kolasinski, Brent D." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: Netgraph and Netflow-v9 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 17:37:34 -0000 On 11.06.2012 20:55, Kolasinski, Brent D. wrote: > > On 6/9/12 5:01 AM, "Alexander V. Chernikov" wrote: > >> It should disappear after 5-10 minutes. We're using several FreeBSD v9 >> sensors with flowd and it seems to run fine (except first 5 minutes >> while waiting for template). I'm aware about the problem with templates >> timeout working incorrectly and I plan to fix this soon. I've done some additional tests and it seems that templates are sent in regular intervals exactly as specified in 'settemplate'. However I still haven't tested this on real collector. > > Looks like it has disappeared, however I am still not seeing any v9 > collection. I am assuming I am using export9 correctly in the ngctl > commands? It seems so. Can you show "ngctl msg netflow: info" ouput ? > 1) bce0 -> in promiscuous mode listening to traffic off of a tap Does bce0 have both UP and RUNNING flags set ? > >> >>> >>> Commands I am using to export v9 netflow records in ngctl: >>> >>> mkpeer bce0: netflow lower iface0 >>> name bce0:lower netflow >>> connect bce0: netflow: upper out0 >>> mkpeer netflow: ksocket export9 inet/dgram/udp >>> msg netflow:export9 connect inet/: >>> >>> >>> >> >> -- >> WBR, Alexander > > > Thanks > > --Brent > > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Mon Jun 11 22:39:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A5D81065670; Mon, 11 Jun 2012 22:39:42 +0000 (UTC) (envelope-from bkolasinski@anl.gov) Received: from dickinson.anl.gov (dickinson.anl.gov [146.137.14.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4443F8FC0A; Mon, 11 Jun 2012 22:39:42 +0000 (UTC) Received: from HETFIELD.anl.gov ([146.137.14.7]) by dickinson.anl.gov ([146.137.14.3]) with mapi; Mon, 11 Jun 2012 17:38:34 -0500 From: "Kolasinski, Brent D." To: "Alexander V. Chernikov" Date: Mon, 11 Jun 2012 17:38:49 -0500 Thread-Topic: Netgraph and Netflow-v9 Thread-Index: Ac1IIu5teLAvVrcNRZyiZprYcSq7fg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: Re: Netgraph and Netflow-v9 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2012 22:39:42 -0000 It appears that it may be something with my current collector. While debugging today, I decided to attempt to run Silk locally on the FreeBSD netflow box. =20 When exporting locally, it is reading the netflow-v9 records. Yay! Our collector is an older Linux box with a manually compiled current version of Silk (not that it should matter which OS is running on the collector) with the libfixbuf patch installed. I wonder what is going on there, alas, that is not your problem :) Thanks for the help! ---------- Brent Kolasinski Cyber Security Program Office Argonne National Laboratory Phone: 630-252-2546 On 6/11/12 5:16 PM, "Kolasinski, Brent D." wrote: > >On 6/11/12 12:36 PM, "Alexander V. Chernikov" >wrote: >> >>It seems so. >> >>Can you show "ngctl msg netflow: info" ouput ? > >Rec'd response "info" (805306369) from "[16]:": >Args: { IPv4 bytes=3D4828162266587 IPv4 packets=3D1005674835 IPv4 records >used=3D61793 fibs allocated=3D1 Active expiries=3D26901592 Inactive >expiries=3D133410564 Inactive timeout=3D15 Active timeout=3D1800 } > > >Now I am generating v5 netflow as well so I can compare - which I am >seeing on the collector. I can turn that off and just leave v9 on if that >helps for debugging purposes. > >> >> > 1) bce0 -> in promiscuous mode listening to traffic off of a tap >> >>Does bce0 have both UP and RUNNING flags set ? > >Yup. Status is: > >bce0: flags=3D28943 >metric 0 mtu 1500 > options=3Dc01bb, >TSO4,VLAN_HWTSO,LINKSTATE> > ether 00:19:b9:**:**:** > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active > > >--Brent > From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 08:00:28 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 719101065672 for ; Tue, 12 Jun 2012 08:00:28 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE5B8FC15 for ; Tue, 12 Jun 2012 08:00:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5C80Ssx056688 for ; Tue, 12 Jun 2012 08:00:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5C80Shi056679; Tue, 12 Jun 2012 08:00:28 GMT (envelope-from gnats) Date: Tue, 12 Jun 2012 08:00:28 GMT Message-Id: <201206120800.q5C80Shi056679@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Rudolf Polzer Cc: Subject: Re: kern/167947: [setfib] [patch] arpresolve checks only the default FIB for the interface route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rudolf Polzer List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 08:00:28 -0000 The following reply was made to PR kern/167947; it has been noted by GNATS. From: Rudolf Polzer To: "bug-followup@FreeBSD.org" , "ndenev@gmail.com" Cc: "christoph.weber-fahr@vodafone.com" Subject: Re: kern/167947: [setfib] [patch] arpresolve checks only the default FIB for the interface route Date: Tue, 12 Jun 2012 09:34:23 +0200 Hi, I had the problem too, and could confirm the fix. FreeBSD ********.arcor.net 8.3-RELEASE-p2 FreeBSD 8.3-RELEASE-p2 #1: Tue Jun 12 09:06:31 CEST 2012 =20 root@********.arcor.net:/usr/src/sys/amd64/compile/GENERICfib amd64 However, the fix ONLY works if using ifconfig ... fib N to set the fib for an interface, and not the FreeBSD 7.x method to assign the FIB via ipfw rules. Just thought I should mention this - in our case, the ifconfig way is the better choice anyway. Best regards, Rudolf Polzer= From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 15:11:35 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 546471065673 for ; Tue, 12 Jun 2012 15:11:35 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from melon.pingpong.net (melon.pingpong.net [79.136.116.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA838FC08 for ; Tue, 12 Jun 2012 15:11:35 +0000 (UTC) Received: from girgBook.local (host-95-199-147-25.mobileonline.telia.com [95.199.147.25]) by melon.pingpong.net (Postfix) with ESMTPA id A99F1256CA for ; Tue, 12 Jun 2012 17:10:53 +0200 (CEST) Message-ID: <4FD75BF8.50606@FreeBSD.org> Date: Tue, 12 Jun 2012 17:10:48 +0200 From: Palle Girgensohn User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org References: <4FD66519.8030503@FreeBSD.org> In-Reply-To: <4FD66519.8030503@FreeBSD.org> X-Enigmail-Version: 1.2.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: VIMAGE, epair/if_bridge or netgraph? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2012 15:11:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm updating some jail servers, and want to use VIMAGE. Compiled it into the kernel, learned the hard way not to even include PF in the same kernel [1], so now it works quite well. I am setting up many similar jails, some for testing, some for production. The applications are web servers, som tomcat+apache's, and some other standard type of services like email and ldap, simple stuff. I need no fancy network control, I just need it to work. For each jail there are two interfaces, one public, connected to a software bridge (if_bridge or ng_bridge) acting as a switch, and one internal, for maintenance, connected to a different software bridge. To each software bridge, I connect a physical external interface from the jail host. I am trying to decide whether to use epair and if_bridge, or to use netgraph. For netgraph, there is a nice package at DruidBSD [3]. When I found that, I had already rewritten the standard jail script, using the v2 patches from polymorf [4]. They work equally fine for my purpose. So now I need to know which scales best, is there a difference in performance or stability between netgraph and epair/if_bridge? Cheers, Palle [1] http://forums.freebsd.org/showthread.php?t=31765 [2] http://forums.freebsd.org/showthread.php?t=31949 [3] http://druidbsd.sourceforge.net/vimage.shtml [4] http://wiki.polymorf.fr/index.php?title=Howto:FreeBSD_jail_vnet -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP11v4AAoJEIhV+7FrxBJDdqoIAI8SHZJbXgvRX6r9Qh5Gr6wz geT16OZXre1qdO8juQnWBt04KYFmuFIrdfLSnMJg8xnsIgtVo5YTedfdG6OjS6RM ztOQvVRPKoSWe07sEhd7GLTDJay0QLu1zADI9IPQStyhffW08z7n1U2FngEtaeDh 2fQhHgI2A1y6NzjChtM6pnK45Gzi08oogGhq3e7A9GQRHhDZLX65m4rtYG7T2Q3U K9cWfPQyH1gn/5Zhakc43uLGWkIzWWqrk6IyU4e0swVTRPZvaZeHyfK7Ni0ysKtd SNE2B3uy6yc5i9o/kFlYAq2nLz8Igs1OwWzarzFAtJg0VcJ+Z1ALw7CRoKHbkz0= =UqA0 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Jun 12 17:43:38 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3A32106567A; Tue, 12 Jun 2012 17:43:38 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 260B98FC1B; Tue, 12 Jun 2012 17:43:37 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q5CHhUlw021496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2012 19:43:30 +0200 Received: from [192.168.1.128] ([80.31.158.180]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q5CHhRaH020489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Jun 2012 19:43:29 +0200 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <20D4B9A0-15D2-439A-99E1-0FD577385C98@entel.upc.edu> X-Mailer: iPhone Mail (9B206) From: Gustau Perez Date: Tue, 12 Jun 2012 19:43:26 +0200 To: Andrew Thompson X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Tue, 12 Jun 2012 19:43:30 +0200 (CEST) Cc: "net@freebsd.org" Subject: Re: Panic with if_bridge when removing components X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2012 17:43:38 -0000 Enviat des del meu iTotxo (disculpeu la brevetat) Sent from my iBrick (excuse me for the brief message) El 10/06/2012, a les 22:49, Andrew Thompson va escriur= e: > On 10 June 2012 02:27, Gustau Perez Querol wrote: >> Hi, >>=20 >> I'm seeing panics when removing an interface of a bridge. The system run= s >> HEAD/AMD64 r236733. I see no changes to if_bridge.c in the last two days,= so >> I would say the problem's still there. I also checked stable and the prob= lem >> should be there too. >>=20 >> The problem is that I have a bridge composed of two ethernet interfaces,= an >> ath interface and a tap. As soon as I remove any of them the system panic= s. >> Because the system runs openvpn with the tap connected to the bridge, whe= n >> the system starts to reboot, the openvpn daemon removes the tap and thus >> causing also the panic. >>=20 >> The panic comes because at sys/net/if_bridge.c:943 the struct >> *ifnet->if_bridge of the interface removed is set to NULL too early. Beca= use >> of this, at sys/net/if_bridge.c:996 we call if_bridge.c:bridge_linkstate >> where the struct *ifnet->if_bridge is needed. This causes the panic. >=20 >=20 > I introduced this issue in r234487, please try this patch. > http://people.freebsd.org/~thompsa/bridge_link.diff >=20 > regards, > Andrewb=20 Wasn't unable to test until now. I've seen it was comitted to head wester= day. I've read the diff and I haven't seen problems so the changes and the M= FC look good to me too. Thanks, Gustau= From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 13:20:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A0FA1065678 for ; Wed, 13 Jun 2012 13:20:02 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DB2548FC1C for ; Wed, 13 Jun 2012 13:20:01 +0000 (UTC) Received: (qmail 72505 invoked from network); 13 Jun 2012 15:17:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Jun 2012 15:17:14 -0000 Message-ID: <4FD8937C.3020005@freebsd.org> Date: Wed, 13 Jun 2012 15:19:56 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nikolay Denev References: <54EF0399-B36E-42CA-9526-DDC7ADA4406A@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-gnats-submit@freebsd.org Subject: Re: FreeBSD 8.2-STABLE sending FIN no ACK packets. kern/168842 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2012 13:20:02 -0000 On 08.06.2012 14:43, Nikolay Denev wrote: > > On Jun 8, 2012, at 4:30 AM, Adrian Chadd wrote: > >> On 7 June 2012 05:41, Nikolay Denev wrote: >>> Hello, >>> >>> I've been pointed out by our partner that we are sending TCP packets with FIN flag and no ACK set, which is triggering >>> alerts on their firewalls. >>> I've investigated, and it appears that some of our FreeBSD hosts are really sending such packets. (they are running some java applications) >>> I did "tcpdump -s0 -vni em1 '(tcp[tcpflags]& tcp-ack == 0)&& (tcp[tcpflags]& tcp-fin != 0)'" to catch them. >>> >>> Is this considered normal? >>> It seems at least Juniper considers this malicious traffic : http://www.juniper.net/techpubs/software/junos-security/junos-security10.0/junos-security-swconfig-security/id-72577.html >> >> Would you please file a PR with this, so it doesn't get lost? >> >> Thanks, >> >> >> Adrian > > Filed as kern/168842, and mistakenly duplicated as kern/168843 (the latter can be closed). > > As I wrote in the PR, I have a PCAP that I can privately share if someone is interested. Hi Nikolay please make the pcap available to me. From the tcpdump in the PR I can't analyze how this stray packet may come about. While certainly a bug it is not a security issue as any compliant tcp stack would drop such a packet on receipt. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 13:30:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17611106566B for ; Wed, 13 Jun 2012 13:30:39 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 552468FC12 for ; Wed, 13 Jun 2012 13:30:38 +0000 (UTC) Received: (qmail 72541 invoked from network); 13 Jun 2012 15:27:51 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Jun 2012 15:27:51 -0000 Message-ID: <4FD895F9.9040109@freebsd.org> Date: Wed, 13 Jun 2012 15:30:33 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Navdeep Parhar References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: seq# of RST in tcp_dropwithreset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2012 13:30:39 -0000 On 07.06.2012 22:28, George Neville-Neil wrote: > > On Mar 27, 2012, at 18:13 , Navdeep Parhar wrote: > >> When the kernel decides to respond with a RST to an incoming TCP >> segment, it uses its ack# (if valid) as the seq# of the RST. See this >> in tcp_dropwithreset: >> >> if (th->th_flags& TH_ACK) { >> tcp_respond(tp, mtod(m, void *), th, m, (tcp_seq)0, >> th->th_ack, TH_RST); >> } else { >> if (th->th_flags& TH_SYN) >> tlen++; >> tcp_respond(tp, mtod(m, void *), th, m, th->th_seq+tlen, >> (tcp_seq)0, TH_RST|TH_ACK); >> } >> >> This can have some unexpected results. I observed this on a link with >> a very high delay (B is FreeBSD, A could be anything). >> >> 1. There is a segment in flight from A to B. The ack# is X (all tx >> from B to A is up to date and acknowledged). >> 2. socket is closed on B. B sends a FIN with seq# X. >> 3. The segment from A arrives and elicits a RST from B. The seq# of >> this RST will again be X. A receives the FIN and then the RST with >> identical sequence numbers. The situation resolves itself eventually, >> when A retransmits and the retransmitted segment ACKs the FIN too and >> so the next time around B sends a RST with the "correct" seq# (one >> after the FIN). >> >> If there is a local tcpcb for the connection with state>= >> ESTABLISHED, wouldn't it be more accurate to use its snd_max as the >> seq# of the RST? >> > > Hi Navdeep, > > Sorry I missed this so many months ago, but jhb@ was kind enough to point this > query out to me. My understanding of correct operation in this case, is that we > do not want to move the sequence number until we have received the ACK of our > FIN, as any other value would indicate to the TCP on A that we have received their > ACK of our FIN, which, in this case, we have not. The fact that there isn't a better > way to indicate the error is a tad annoying, but, and others can correct me if they think > I'm wrong, this is the correct way for the stacks to come to eventual agreement > on the closing of the connection. In this case Navdeep is correct. As long as a tcpcb is around no RST should be generated in step 3 if we are in FIN_WAIT_1, FIN_WAIT_2, CLOSING or TIME_WAIT. What is the code path leading to tcp_dropwithreset()? Normally this should only be reached if no tcpcb is found. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 20:19:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 719291065672 for ; Wed, 13 Jun 2012 20:19:15 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm28.bullet.mail.ne1.yahoo.com (nm28.bullet.mail.ne1.yahoo.com [98.138.90.91]) by mx1.freebsd.org (Postfix) with SMTP id 0E1828FC21 for ; Wed, 13 Jun 2012 20:19:14 +0000 (UTC) Received: from [98.138.90.48] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 20:19:14 -0000 Received: from [98.138.89.173] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 20:19:14 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 20:19:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 485573.29469.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 62700 invoked by uid 60001); 13 Jun 2012 20:19:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339618754; bh=WsyVgCAboENQaheD3REFiOU9uM3dxX18kdyXa8KFLF0=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dMVUk+tDRt2sqvqonOUkRwQJvVWFuTB6AykFr2qb6n+vUHCrmzhVdQPAdQRpsuzZjUZdw3UrFR3FvZpeQOiNtZ0P7IFnn7y+WNsnfs4JjYMV5DVOjd0fH6QNKirimuQ6CDuBjEEwGnlHDvREcBObcJcGS45vivLIvH9KzEphYV0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=csvjWB/KJoBeSZQCAvM575EPVRro2ppBGJZ5sh0U2voOpiW0FqceJb23FCPrT3QGOpvxxUhAc1ppb7DpRn51pZvvX5saRZVoG2xLWnX4KzKypMcSF/VtOHtu+SLPEiZ2Kbk3C/9Qr1NV3ME+WjOvd696bDyopSbZ8ZvBm7X29IE=; X-YMail-OSG: TCewSK8VM1kkYhbQ6vDilqB4FKmvsR0LpenENhpLuBintVh noI3S7zMXQ2Xtk48v9WyfEkrLtdpyiw5cdrjOb4ku6XuNqyLmFLhKXOAGupd WhTba_FwtChxpn4vYWr1IvhJYAnW1yhGpsYNqIQloC7Ym6HbUPfkhLfNKMGj S4huAry4UadC28.I_QNUfQYRnsWWqM2iSsYimtaz62LFXfbgjdpxUOAjsK_u ZfWM1OofpbxMPhTpth_Qmzq41KZFOxUyxGYgd3Fb.jN8oSvEy_jUp7sKi5wl gR58iQFOsM9fJkUgPq5PZ1fG4oOafURFkPXtR_hLVS1aUHpyhUSHeD0n0QwJ XUxqCvgwyfzMYQ2GjPEoG0PTKWM1GHov3cTVbDfylu0q2ISfcSmVB3eeKzo. JqqOXkXko7OseBjVOBhhLUycmbw68d2T6BANwI.niozg7ov7cKZ4RT5Fnsal SYmiVyqD.rY7HuKKNZtyOINEwxXuwefUSJA-- Received: from [174.48.129.108] by web126002.mail.ne1.yahoo.com via HTTP; Wed, 13 Jun 2012 13:19:13 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.118.349524 Message-ID: <1339618753.62596.YahooMailClassic@web126002.mail.ne1.yahoo.com> Date: Wed, 13 Jun 2012 13:19:13 -0700 (PDT) From: Barney Cordoba To: freebsd-net@freebsd.org In-Reply-To: <4F939583.9020408@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Cougar Point on FreeBSD 7? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2012 20:19:15 -0000 Anyone have an info on whether FreeBSD 7 can be made to run on Cougar Point chipset? I see that the C202 wasn't officially supported until 8.2 or so, but is there a compatibility mode that would allow it to be used? BC From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 21:03:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9883F106580D for ; Wed, 13 Jun 2012 21:03:00 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 424F58FC08 for ; Wed, 13 Jun 2012 21:02:58 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id Mqrs1j00E1uE5Es58x2xaF; Wed, 13 Jun 2012 21:02:57 +0000 Received: from sz0092.wc.mail.comcast.net ([76.96.58.150]) by omta16.westchester.pa.mail.comcast.net with comcast id Mx2x1j00S3EUZNL3cx2xnS; Wed, 13 Jun 2012 21:02:57 +0000 Date: Wed, 13 Jun 2012 21:02:57 +0000 (UTC) From: cjharrer@comcast.net To: freebsd-net@freebsd.org Message-ID: <2047697620.40515.1339621377861.JavaMail.root@sz0092a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 X-Originating-IP: [68.80.185.133] X-Mailer: Zimbra 6.0.13_GA_2944 (ZimbraWebClient - SAF3 (Win)/6.0.13_GA_2944) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Christopher J. Harrer" Subject: Window updates during periods of HIGH packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2012 21:03:00 -0000 Running FreeBSD 8.0 Stable and we're running into an issue with window updates during periods of very high DUPLEX network traffic where there are a good number of network packets being dropped. Please let me know if there is a better list to ask this question of. I'm going to use some small, made up numbers to demonstrate what is going on. I can go into more detail with explicit numbers from an internal trace that I created, but it gets pretty long and tedious, so I'd like to see if my example makes sense first. We have a server that is running a lot of NFS traffic (NFSv3 over TCP/IPv4) to a NetApp back-end filer (not sure the filer matters). For the purpose of this problem description, let's assume that I have a send and receive window of 10,000. We have a lot of data outstanding in the network (let's say 9000 bytes), the back-end filer (seq 1,000 to 9,999). The filer is sending us a lot of data concurrent to our 9000 bytes we just sent. Lets assume our rcv_nxt is 1,000. We receive th_seq of 10,000 (out of order) from the filer and it ACK's all of our oustanding data. So, snd_wl1 becomes 10,000 and snd_wl2 becomes 9,999. Our snd_wnd is now 10000, so we begin to send new data (again, we blast it out, so let's assume we have 10,000 more bytes sent). The filer is "resending" sequencne numbers 1,000 through 9,999 because the new data we are sending contains SACK blocks instructing it to. The retransmitted data we are receiving is also acking our new sent data such that when we receive segment with th_seq 9,000 it goes up to 9999 (and completes our out of order processing) all of our data is acked. Now, here's where the problem arises: 1) in processing a WindowUpdate (step6 in tcp_input) the 2nd check that is made is to ensure that tp->snd_wl1 < th->th_seq, in this case, it's not. 10,000 is not less than 9,000. The next check needs th->th_seq == tp->snd_wl1 which also fails, so no window update done. 2) After tcp_reass handles the receipt of the last segment that fills in the "hole" in our stream, tp->t_flags |= TF_ACKNOW (this flag cause tcp_output to skip the check to start the PERSIST timer, because it must force a send (in this case, the send is just an ACK). Any time tcp_reass returns TF_ACKNOW is set. We've gotten a new send down while we were sending data into our open window, so now we're stuck, tp->snd_nxt == tp->snd_una == tp->snd_max and so_snd.sb_cc !=0, TT_PERSIST is NOT running and TT_REXMT is not running. Eventually the filer sends us a FIN to close an "idle" client connection; which is normal operation in this configuration. I have not looked at more recent versions of FreeBSD code yet, I will start doing that now. I just wanted to ask the experts if I'm missing something here, it feels like I am. Thanks in advance for any insight you can provide. Regards, Chris From owner-freebsd-net@FreeBSD.ORG Wed Jun 13 21:40:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B758C1065686 for ; Wed, 13 Jun 2012 21:40:08 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 721B18FC12 for ; Wed, 13 Jun 2012 21:40:08 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta09.westchester.pa.mail.comcast.net with comcast id Mufn1j0091ap0As59xg7N1; Wed, 13 Jun 2012 21:40:07 +0000 Received: from sz0092.wc.mail.comcast.net ([76.96.58.150]) by omta22.westchester.pa.mail.comcast.net with comcast id Mxg61j0043EUZNL3ixg6og; Wed, 13 Jun 2012 21:40:06 +0000 Date: Wed, 13 Jun 2012 21:40:07 +0000 (UTC) From: cjharrer@comcast.net To: freebsd-net@freebsd.org Message-ID: <930457657.42273.1339623607713.JavaMail.root@sz0092a.westchester.pa.mail.comcast.net> In-Reply-To: <2047697620.40515.1339621377861.JavaMail.root@sz0092a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 X-Originating-IP: [68.80.185.133] X-Mailer: Zimbra 6.0.13_GA_2944 (ZimbraWebClient - SAF3 (Win)/6.0.13_GA_2944) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Window updates during periods of HIGH packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2012 21:40:08 -0000 Oops, left one part out below... When snd_nxt == snd_una == snd_max; snd_wnd == 0 which is why we can't send any new data. ----- Original Message ----- From: cjharrer@comcast.net To: freebsd-net@freebsd.org Cc: "Christopher J. Harrer" Sent: Wednesday, June 13, 2012 5:02:57 PM Subject: Window updates during periods of HIGH packet loss Running FreeBSD 8.0 Stable and we're running into an issue with window updates during periods of very high DUPLEX network traffic where there are a good number of network packets being dropped. Please let me know if there is a better list to ask this question of. I'm going to use some small, made up numbers to demonstrate what is going on. I can go into more detail with explicit numbers from an internal trace that I created, but it gets pretty long and tedious, so I'd like to see if my example makes sense first. We have a server that is running a lot of NFS traffic (NFSv3 over TCP/IPv4) to a NetApp back-end filer (not sure the filer matters). For the purpose of this problem description, let's assume that I have a send and receive window of 10,000. We have a lot of data outstanding in the network (let's say 9000 bytes), the back-end filer (seq 1,000 to 9,999). The filer is sending us a lot of data concurrent to our 9000 bytes we just sent. Lets assume our rcv_nxt is 1,000. We receive th_seq of 10,000 (out of order) from the filer and it ACK's all of our oustanding data. So, snd_wl1 becomes 10,000 and snd_wl2 becomes 9,999. Our snd_wnd is now 10000, so we begin to send new data (again, we blast it out, so let's assume we have 10,000 more bytes sent). The filer is "resending" sequencne numbers 1,000 through 9,999 because the new data we are sending contains SACK blocks instructing it to. The retransmitted data we are receiving is also acking our new sent data such that when we receive segment with th_seq 9,000 it goes up to 9999 (and completes our out of order processing) all of our data is acked. Now, here's where the problem arises: 1) in processing a WindowUpdate (step6 in tcp_input) the 2nd check that is made is to ensure that tp->snd_wl1 < th->th_seq, in this case, it's not. 10,000 is not less than 9,000. The next check needs th->th_seq == tp->snd_wl1 which also fails, so no window update done. 2) After tcp_reass handles the receipt of the last segment that fills in the "hole" in our stream, tp->t_flags |= TF_ACKNOW (this flag cause tcp_output to skip the check to start the PERSIST timer, because it must force a send (in this case, the send is just an ACK). Any time tcp_reass returns TF_ACKNOW is set. We've gotten a new send down while we were sending data into our open window, so now we're stuck, tp->snd_nxt == tp->snd_una == tp->snd_max and so_snd.sb_cc !=0, TT_PERSIST is NOT running and TT_REXMT is not running. Eventually the filer sends us a FIN to close an "idle" client connection; which is normal operation in this configuration. I have not looked at more recent versions of FreeBSD code yet, I will start doing that now. I just wanted to ask the experts if I'm missing something here, it feels like I am. Thanks in advance for any insight you can provide. Regards, Chris From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 00:56:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A91A8106566C; Thu, 14 Jun 2012 00:56:51 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 71F258FC19; Thu, 14 Jun 2012 00:56:51 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so3219419pbb.13 for ; Wed, 13 Jun 2012 17:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lFKxvLzQbbFpdXBYNKxP3fLIeyNuaUlq0FJLhnUuo3M=; b=V10GoMrHEm9i5XcksPUxLze1KWP9PnrX6gd7aJryd5yIjKItJ2KLOew7eo8r1OVsxh KnzQ1XTomHy7pEqpdtgddoFh4IlCTwkk87MV1BHr4jx3iUsh+7TiKAxOlCXzsBYrGdUR Kp+ORQyJjOrYvHMnry+HONyvTomQ2RteWahGQ727+eWlewdy5QJSTpfxuI1gmiSNkALO cN0iHkLKt8+9aT8dkC6hOZnTm+uEY91LDbubi8JJKyYKV/v8ylmN1DvpjJ8t5p+txlEO xmZYdWclpK1tGrbVom5gCvdpEB/ILti/Hzp26brcWocmCfuaS+XZW4SB5GL7EOhNY0Vs AbSQ== Received: by 10.68.219.226 with SMTP id pr2mr1863512pbc.1.1339635411264; Wed, 13 Jun 2012 17:56:51 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id ip5sm7544090pbc.3.2012.06.13.17.56.49 (version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 17:56:50 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <4FD936D0.1050005@FreeBSD.org> Date: Wed, 13 Jun 2012 17:56:48 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120609 Thunderbird/13.0 MIME-Version: 1.0 To: Andre Oppermann References: <4FD895F9.9040109@freebsd.org> In-Reply-To: <4FD895F9.9040109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: seq# of RST in tcp_dropwithreset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 00:56:51 -0000 On 06/13/12 06:30, Andre Oppermann wrote: > On 07.06.2012 22:28, George Neville-Neil wrote: >> >> On Mar 27, 2012, at 18:13 , Navdeep Parhar wrote: >> >>> When the kernel decides to respond with a RST to an incoming TCP >>> segment, it uses its ack# (if valid) as the seq# of the RST. See this >>> in tcp_dropwithreset: >>> >>> if (th->th_flags& TH_ACK) { >>> tcp_respond(tp, mtod(m, void *), th, m, (tcp_seq)0, >>> th->th_ack, TH_RST); >>> } else { >>> if (th->th_flags& TH_SYN) >>> tlen++; >>> tcp_respond(tp, mtod(m, void *), th, m, th->th_seq+tlen, >>> (tcp_seq)0, TH_RST|TH_ACK); >>> } >>> >>> This can have some unexpected results. I observed this on a link with >>> a very high delay (B is FreeBSD, A could be anything). >>> >>> 1. There is a segment in flight from A to B. The ack# is X (all tx >>> from B to A is up to date and acknowledged). >>> 2. socket is closed on B. B sends a FIN with seq# X. >>> 3. The segment from A arrives and elicits a RST from B. The seq# of >>> this RST will again be X. A receives the FIN and then the RST with >>> identical sequence numbers. The situation resolves itself eventually, >>> when A retransmits and the retransmitted segment ACKs the FIN too and >>> so the next time around B sends a RST with the "correct" seq# (one >>> after the FIN). >>> >>> If there is a local tcpcb for the connection with state>= >>> ESTABLISHED, wouldn't it be more accurate to use its snd_max as the >>> seq# of the RST? >>> >> >> Hi Navdeep, >> >> Sorry I missed this so many months ago, but jhb@ was kind enough to >> point this >> query out to me. My understanding of correct operation in this case, >> is that we >> do not want to move the sequence number until we have received the ACK >> of our >> FIN, as any other value would indicate to the TCP on A that we have >> received their >> ACK of our FIN, which, in this case, we have not. The fact that there >> isn't a better >> way to indicate the error is a tad annoying, but, and others can >> correct me if they think >> I'm wrong, this is the correct way for the stacks to come to eventual >> agreement >> on the closing of the connection. > > In this case Navdeep is correct. As long as a tcpcb is around no RST > should be generated in step 3 if we are in FIN_WAIT_1, FIN_WAIT_2, CLOSING > or TIME_WAIT. Why not? Generating a RST is the right thing to do when faced with excess data that cannot be delivered because the local socket has closed. My question/concern was about the seq# that the kernel's TCP chose for this RST, not the RST itself. > What is the code path leading to tcp_dropwithreset()? Normally this should > only be reached if no tcpcb is found. I don't remember it off the top of my head, but a quick look at tcp_input.c suggests it must have been this piece of code in tcp_do_segment(): /* * If new data are received on a connection after the * user processes are gone, then RST the other end. */ if ((so->so_state & SS_NOFDREF) && tp->t_state > TCPS_CLOSE_WAIT && tlen) { Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 06:10:44 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B231F1065673; Thu, 14 Jun 2012 06:10:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8B68FC12; Thu, 14 Jun 2012 06:10:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5E6AiNS038627; Thu, 14 Jun 2012 06:10:44 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5E6Aiau038620; Thu, 14 Jun 2012 06:10:44 GMT (envelope-from linimon) Date: Thu, 14 Jun 2012 06:10:44 GMT Message-Id: <201206140610.q5E6Aiau038620@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169023: [libc] [patch] setfsent(), getfsent(), etc. leave /etc/fstab open after exec() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 06:10:44 -0000 Old Synopsis: setfsent(), getfsent(), etc. leave /etc/fstab open after exec() New Synopsis: [libc] [patch] setfsent(), getfsent(), etc. leave /etc/fstab open after exec() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jun 14 06:08:59 UTC 2012 Responsible-Changed-Why: with bugmeister hat, assign this to net@ mostly in the hopes that it will achieve higher visibility. OTOH maybe I should have assigned it to freebsd-fs@. Er, too late now that I have the editor window open ... http://www.freebsd.org/cgi/query-pr.cgi?pr=169023 From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 06:11:14 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 171F41065695; Thu, 14 Jun 2012 06:11:14 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id DE3B28FC17; Thu, 14 Jun 2012 06:11:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5E6BD1n041822; Thu, 14 Jun 2012 06:11:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5E6BD3D041813; Thu, 14 Jun 2012 06:11:13 GMT (envelope-from linimon) Date: Thu, 14 Jun 2012 06:11:13 GMT Message-Id: <201206140611.q5E6BD3D041813@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/169023: [libc] [patch] setfsent(), getfsent(), etc. leave /etc/fstab open after exec() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 06:11:14 -0000 Synopsis: [libc] [patch] setfsent(), getfsent(), etc. leave /etc/fstab open after exec() Responsible-Changed-From-To: freebsd-net->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jun 14 06:10:49 UTC 2012 Responsible-Changed-Why: With bugmeister hat, try to assign this to fs@ to see if it can achieve some higher visibility. http://www.freebsd.org/cgi/query-pr.cgi?pr=169023 From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 07:34:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAA6A106566B for ; Thu, 14 Jun 2012 07:34:05 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [128.127.144.4]) by mx1.freebsd.org (Postfix) with ESMTP id 879DB8FC08 for ; Thu, 14 Jun 2012 07:34:05 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id q5E7C1eC065779 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 14 Jun 2012 13:12:01 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4FD98EC1.50200@norma.perm.ru> Date: Thu, 14 Jun 2012 13:12:01 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4FD236D4.6090409@norma.perm.ru> <20120609170721.GA40355@felucia.tataz.chchile.org> In-Reply-To: <20120609170721.GA40355@felucia.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Thu, 14 Jun 2012 13:12:01 +0600 (YEKT) X-Spam-Status: No hits=-97.8 bayes=0.5 testhits RDNS_NONE=1.274, SPF_SOFTFAIL=0.972,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: if_ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 07:34:05 -0000 Hi, On 09.06.2012 23:07, Jeremie Le Hen wrote: > What it usually done for convenience is to create a gif(4) or gre(4) > tunnel to another network, which is then encrypted using IPSec > transport mode. The inner IP/GRE header is considered as the payload > and it is encrypted. The benefit of this approach is that you "see" > your tunnel, it looks more natural from a system point of view. I > haven't used IPSec in tunnel mode for more than a decades, so I don't > remember how it is manageable. But with the IPSec transport mode + > gif/gre tunnel, you see a full-fledged interface toward the other > network, through which you can route your traffic. Yeah, but nowadays this is sort of a legacy thing. Modern router OSes, like IOS or JunOS operate the ipsec interfaces, and these interfaces are visible in the system and are fully operation in the context of the dynamic routing, and I mean here sending/receiving packets from/to these interfaces. I just wanted FreeBSD to have such a capability. Thank you for an explanation though. Seems like you read only the first few lines of my post. I am fully capable... whatever. Seems like I've already said this in my initial message. Eugene. From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 10:35:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BED2106566B for ; Thu, 14 Jun 2012 10:35:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CCB698FC0C for ; Thu, 14 Jun 2012 10:35:50 +0000 (UTC) Received: (qmail 76817 invoked from network); 14 Jun 2012 12:32:53 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Jun 2012 12:32:53 -0000 Message-ID: <4FD9BE80.1030203@freebsd.org> Date: Thu, 14 Jun 2012 12:35:44 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nikolay Denev References: <54EF0399-B36E-42CA-9526-DDC7ADA4406A@gmail.com> <4FD8937C.3020005@freebsd.org> In-Reply-To: <4FD8937C.3020005@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-gnats-submit@freebsd.org Subject: Re: kern/168842: FreeBSD 8.2-STABLE sending FIN no ACK packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 10:35:51 -0000 On 13.06.2012 15:19, Andre Oppermann wrote: > On 08.06.2012 14:43, Nikolay Denev wrote: >> >> On Jun 8, 2012, at 4:30 AM, Adrian Chadd wrote: >> >>> On 7 June 2012 05:41, Nikolay Denev wrote: >>>> Hello, >>>> >>>> I've been pointed out by our partner that we are sending TCP packets with FIN flag and no ACK >>>> set, which is triggering >>>> alerts on their firewalls. >>>> I've investigated, and it appears that some of our FreeBSD hosts are really sending such >>>> packets. (they are running some java applications) >>>> I did "tcpdump -s0 -vni em1 '(tcp[tcpflags]& tcp-ack == 0)&& (tcp[tcpflags]& tcp-fin != 0)'" to >>>> catch them. >>>> >>>> Is this considered normal? >>>> It seems at least Juniper considers this malicious traffic : >>>> http://www.juniper.net/techpubs/software/junos-security/junos-security10.0/junos-security-swconfig-security/id-72577.html >>>> >>> >>> Would you please file a PR with this, so it doesn't get lost? >>> >>> Thanks, >>> >>> >>> Adrian >> >> Filed as kern/168842, and mistakenly duplicated as kern/168843 (the latter can be closed). >> >> As I wrote in the PR, I have a PCAP that I can privately share if someone is interested. > > Hi Nikolay > > please make the pcap available to me. From the tcpdump in the PR I can't > analyze how this stray packet may come about. OK, thanks for the pcap file which I've analyzed now. > While certainly a bug it is not a security issue as any compliant tcp stack > would drop such a packet on receipt. The stray FIN happens on timeout of unsuccessful connection attempts (SYN_SENT). There are a number of bugs for that case I've identified so far: 1. there is bug in the SYN_SENT inpcb teardown case that causes the wrong FIN to be sent. It may be a residual of T/TCP. 2. the SYN retransmit is broken by sending the first after 3s, and then four in succession at 3.2s, the fifth comes at 6.2s, at 8s the application times out. 3. after the third SYN retransmit we turn off the tcp options, except that SACK_PERM stays on. I'm working on fixes for each of these bugs. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 13:30:06 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B7B8106564A for ; Thu, 14 Jun 2012 13:30:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 657C88FC14 for ; Thu, 14 Jun 2012 13:30:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5EDU6E1072241 for ; Thu, 14 Jun 2012 13:30:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q5EDU5sK072238; Thu, 14 Jun 2012 13:30:05 GMT (envelope-from gnats) Date: Thu, 14 Jun 2012 13:30:05 GMT Message-Id: <201206141330.q5EDU5sK072238@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Alter Cc: Subject: Re: bin/117339: [patch] route(8): loading routing management commands from file X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alter List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 13:30:06 -0000 The following reply was made to PR bin/117339; it has been noted by GNATS. From: Alter To: bug-followup@FreeBSD.org, alter@alter.org.ua Cc: Subject: Re: bin/117339: [patch] route(8): loading routing management commands from file Date: Thu, 14 Jun 2012 16:30:22 +0200 Hello bug-followup, Unified diff for FreeBSD 7.2 is now available: http://alter.org.ua/soft/fbsd/route/route-file_ie.72.20120614u.patch.gz -- Best regards, Alter mailto:alter@alter.org.ua From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 15:57:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D685106566B for ; Thu, 14 Jun 2012 15:57:57 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2378FC12 for ; Thu, 14 Jun 2012 15:57:55 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id CC10BD48129; Thu, 14 Jun 2012 17:57:49 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id A2F9BCA1; Thu, 14 Jun 2012 17:57:48 +0200 (CEST) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 6E3C2E8F0; Thu, 14 Jun 2012 15:57:48 +0000 (UTC) Date: Thu, 14 Jun 2012 17:57:48 +0200 From: Jeremie Le Hen To: "Eugene M. Zheganin" Message-ID: <20120614155748.GC40355@felucia.tataz.chchile.org> Mail-Followup-To: "Eugene M. Zheganin" , freebsd-net@freebsd.org References: <4FD236D4.6090409@norma.perm.ru> <20120609170721.GA40355@felucia.tataz.chchile.org> <4FD98EC1.50200@norma.perm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD98EC1.50200@norma.perm.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: if_ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 15:57:57 -0000 Eugene On Thu, Jun 14, 2012 at 01:12:01PM +0600, Eugene M. Zheganin wrote: > Hi, > > On 09.06.2012 23:07, Jeremie Le Hen wrote: > > What it usually done for convenience is to create a gif(4) or gre(4) > > tunnel to another network, which is then encrypted using IPSec > > transport mode. The inner IP/GRE header is considered as the payload > > and it is encrypted. The benefit of this approach is that you "see" > > your tunnel, it looks more natural from a system point of view. I > > haven't used IPSec in tunnel mode for more than a decades, so I don't > > remember how it is manageable. But with the IPSec transport mode + > > gif/gre tunnel, you see a full-fledged interface toward the other > > network, through which you can route your traffic. > Yeah, but nowadays this is sort of a legacy thing. > Modern router OSes, like IOS or JunOS operate the ipsec interfaces, and > these interfaces are visible in the system and are fully operation in > the context of the dynamic routing, and I mean here sending/receiving > packets from/to these interfaces. I just wanted FreeBSD to have such a > capability. > > Thank you for an explanation though. Seems like you read only the first > few lines of my post. I am fully capable... whatever. Seems like I've > already said this in my initial message. Not at all, I read the whole mail thoroughly actually :-). But I don't work on Cisco/Junipers equipements so I didn't exactly grasp what you meant. By explaining what I know about IPSec on FreeBSD, I didn't mean to let you think you aren't capable -- and I'm sorry if you take it that way -- it was just to engage you to explain things with regards to what I know. Now I understand that what you are actually proposing is basically to make IPSec in tunnel mode create a virtual interface. I don't know why it has never been done so far. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 16:42:47 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 336011065673 for ; Thu, 14 Jun 2012 16:42:47 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 73F6E8FC17 for ; Thu, 14 Jun 2012 16:42:46 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q5EGghY2010658 for ; Thu, 14 Jun 2012 23:42:43 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FDA1483.4090207@rdtc.ru> Date: Thu, 14 Jun 2012 23:42:43 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: ip_output: NAT then IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 16:42:47 -0000 Hi! How do I make FreeBSD 8-based router/NAT/security gateway first perform NAT for outgoing packets then apply IPSEC transport mode for plain TCP traffic? Presently, locally originated packets are encrypted just fine but routed and NAT-ed packet go out unencrypted. I use ipfw nat. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 19:36:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A336106564A for ; Thu, 14 Jun 2012 19:36:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF5C8FC14 for ; Thu, 14 Jun 2012 19:36:41 +0000 (UTC) Received: by dadv36 with SMTP id v36so3158042dad.13 for ; Thu, 14 Jun 2012 12:36:40 -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 :x-google-sender-auth:message-id:subject:from:to:content-type; bh=u0NCCiXvSKYQ98clnZJJZ1VQwKTKSTWilggt8fpA5+M=; b=M6CqjhSaP5377fQWCaTd+BWWzbIhpooQsFz8q+Y34A37LEMJHuQJr6oygcCc3Y0UTA 1bTKw1jCmuYsyHJbBRemcUlSqdPum/SXBGQlqWy36aecIpAY23S6iOWljrtGZngHRYNB zz5cK4WvCEihV6rNaWMuPZrNTfs8bTNsnnapuHD2aWbY2FJv3wa+5aa6ZhPSDF9DTDD0 XThpDbs47lBd3GVWRkM8ClLP3x2Crn4NMxUc609tUr7GELkKd1kefbhyi+JiZxyDJY+v J6YJdKb9Ay/KStixDpEtjK2+ifaXbOs4V1MdrHT8G9VYivRDPTP2KwbpOkAGYyVLpGVP T/cQ== MIME-Version: 1.0 Received: by 10.68.226.226 with SMTP id rv2mr11502601pbc.101.1339702600597; Thu, 14 Jun 2012 12:36:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.91.18 with HTTP; Thu, 14 Jun 2012 12:36:40 -0700 (PDT) In-Reply-To: <20120614155748.GC40355@felucia.tataz.chchile.org> References: <4FD236D4.6090409@norma.perm.ru> <20120609170721.GA40355@felucia.tataz.chchile.org> <4FD98EC1.50200@norma.perm.ru> <20120614155748.GC40355@felucia.tataz.chchile.org> Date: Thu, 14 Jun 2012 12:36:40 -0700 X-Google-Sender-Auth: YNfIDP5ksWv601acTz9UqkoI6J0 Message-ID: From: Adrian Chadd To: "Eugene M. Zheganin" , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: if_ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 19:36:41 -0000 Hm, I remember some reasons down in the deep, distant past as to why ipsec implementations moved away from tunnel mode == tunnel interfaces. When I was being a network engineer during the day, I constantly hated having to implement tunnels using traffic maps rather than actual interfaces. Chances are bz@ would know. I suggest asking him. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 20:21:57 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7EA6106564A for ; Thu, 14 Jun 2012 20:21:57 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFE38FC17 for ; Thu, 14 Jun 2012 20:21:57 +0000 (UTC) Received: by vcbfy7 with SMTP id fy7so1591746vcb.13 for ; Thu, 14 Jun 2012 13:21:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=R8BI57VygRzMg3fh7tJIkc/788EYzZo1cfHGlGnVBMw=; b=Q9UaE0e5dFFVn4dL7RfXDAWHaO+UiaJzhOLr8aeGcsq2h8yM21i1ZkNUjBAYMYh5or 2CsYiAK+MbfnPq1TiKuiCE+0Q5BKuNdYAUIYlvpYGP3/xKlb4IEZG6d+cuIUHk8awe3r /mDGPXwvqBcymHSzEJUkpSpEZKRnPfB0j61xDS+aGHZH/n5fGYi/p4s7lYJX4SSMWKU+ RlBze3NQvZLLydnoSokVilV9czwruL0OweTsX3s8zE7Wwbl+K8GEV+52XCgrsXbApLz6 o98nbW0Dk9fcAg5BGxjnxR0MTbJeYofDLylBAdEqZFAjmTOewvzOhqyMiP6f/kdqGXNR iDZw== MIME-Version: 1.0 Received: by 10.52.72.79 with SMTP id b15mr1469459vdv.13.1339705316664; Thu, 14 Jun 2012 13:21:56 -0700 (PDT) Received: by 10.52.106.166 with HTTP; Thu, 14 Jun 2012 13:21:56 -0700 (PDT) In-Reply-To: <4FDA1483.4090207@rdtc.ru> References: <4FDA1483.4090207@rdtc.ru> Date: Thu, 14 Jun 2012 13:21:56 -0700 Message-ID: From: Michael Sierchio To: Eugene Grosbein Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmnDpJW4nuiU3e4TFYWU3G3d+TrkrE0h2Ho9lEIZt1rJ8rIgzr/7LoEgqzVpwXgw4Cfk7Jv Cc: "net@freebsd.org" Subject: Re: ip_output: NAT then IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 20:21:57 -0000 On Thu, Jun 14, 2012 at 9:42 AM, Eugene Grosbein wrote: > How do I make FreeBSD 8-based router/NAT/security gateway > first perform NAT for outgoing packets then apply IPSEC transport mode > for plain TCP traffic? Forgive me, but I have to ask - why? IPsec implies pairwise association, and relies on a tunnel - which means that each side knows both tunnel endpoints and both internal networks. What do you hope to accomplish with NAT? - M From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 20:30:47 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4B9106566C for ; Thu, 14 Jun 2012 20:30:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 37DA08FC08 for ; Thu, 14 Jun 2012 20:30:47 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id F070825D3887; Thu, 14 Jun 2012 20:30:45 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2ED5DBE8567; Thu, 14 Jun 2012 20:30:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gCp0Qs_eP1UA; Thu, 14 Jun 2012 20:30:44 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id DF47ABE8566; Thu, 14 Jun 2012 20:30:43 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4FDA1483.4090207@rdtc.ru> Date: Thu, 14 Jun 2012 20:30:42 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1EFC4D8F-B195-4BA7-9AE0-7B9CA9C1F2F5@lists.zabbadoz.net> References: <4FDA1483.4090207@rdtc.ru> To: Eugene Grosbein X-Mailer: Apple Mail (2.1084) Cc: "net@freebsd.org" Subject: Re: ip_output: NAT then IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2012 20:30:47 -0000 On 14. Jun 2012, at 16:42 , Eugene Grosbein wrote: > Hi! > > How do I make FreeBSD 8-based router/NAT/security gateway > first perform NAT for outgoing packets then apply IPSEC transport mode > for plain TCP traffic? > > Presently, locally originated packets are encrypted just fine > but routed and NAT-ed packet go out unencrypted. > > I use ipfw nat. You NAT on your inside interface; ipfw can do that; pf cannot, so you are lucky. I have done it about 5-6 years ago. However these is on caveat: you need a SP for both the before-NAT (which you normally do not want) and the after-NAT packets and you usually cannot do that unless you control both sides of the tunnel. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 04:22:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5348D1065674 for ; Fri, 15 Jun 2012 04:22:19 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [128.127.144.4]) by mx1.freebsd.org (Postfix) with ESMTP id B44F58FC1A for ; Fri, 15 Jun 2012 04:22:18 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id q5F4MEBY050850 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 15 Jun 2012 10:22:15 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4FDAB876.8040400@norma.perm.ru> Date: Fri, 15 Jun 2012 10:22:14 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4FD236D4.6090409@norma.perm.ru> <20120609170721.GA40355@felucia.tataz.chchile.org> <4FD98EC1.50200@norma.perm.ru> <20120614155748.GC40355@felucia.tataz.chchile.org> In-Reply-To: <20120614155748.GC40355@felucia.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Fri, 15 Jun 2012 10:22:16 +0600 (YEKT) X-Spam-Status: No hits=-97.8 bayes=0.5 testhits RDNS_NONE=1.274, SPF_SOFTFAIL=0.972,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: if_ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 04:22:19 -0000 Hi. On 14.06.2012 21:57, Jeremie Le Hen wrote: > Not at all, I read the whole mail thoroughly actually :-). But I don't > work on Cisco/Junipers equipements so I didn't exactly grasp what you > meant. > > Okay. Actually, the whole idea is to 'simplify'. The conventional way of creating IPSec makes you do a lot of stuff: creating policies, creating tunnel interfaces, creating isakmp phase 1 and phase 2 proposals. Cisco/Juniper equipment is pretty capable of doing all of this stuff too (if you want fine-grained control), but by defaults they got rid of all of this configuration, it works with defaults, and works fine. And the gre setup is especially complicated when it comes to Juniper, because they totally got rid of the policing mechanism, and there's no way in JunOS (at least in 10.x-12.1) to define a policy about 'what kind of traffic to encrypt with IPSec' like you can do in Linux/*BSD/Cisco. So I'm afraid Cisco can lose this ability too. It is still possible to build a FreeBSD - Juniper gre/ipsec tunnel (and I'm using them), but it requires a twisted hack with routing on the Juniper side, and a pair of _additional_ IP addresses. So, complicated stuff on one side, ipsec interfaces (and some default configs) on the other. Eugene. From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 04:33:42 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73AC31065675 for ; Fri, 15 Jun 2012 04:33:42 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id CB78C8FC0C for ; Fri, 15 Jun 2012 04:33:41 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q5F4XcYW014554; Fri, 15 Jun 2012 11:33:39 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FDABB22.9040305@rdtc.ru> Date: Fri, 15 Jun 2012 11:33:38 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Michael Sierchio References: <4FDA1483.4090207@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "net@freebsd.org" Subject: Re: ip_output: NAT then IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 04:33:42 -0000 15.06.2012 03:21, Michael Sierchio ÐÉÛÅÔ: > On Thu, Jun 14, 2012 at 9:42 AM, Eugene Grosbein wrote: > >> How do I make FreeBSD 8-based router/NAT/security gateway >> first perform NAT for outgoing packets then apply IPSEC transport mode >> for plain TCP traffic? > > Forgive me, but I have to ask - why? > > IPsec implies pairwise association, and relies on a tunnel - which > means that each side knows both tunnel endpoints and both internal > networks. What do you hope to accomplish with NAT? I have a TCP-service inside local network that is accessable for a couple of external hosts via NAT port forwarding. And I need to protect this TCP stream seamlessly with IPSEC transport mode. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 11:42:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A85F1106566B; Fri, 15 Jun 2012 11:42:08 +0000 (UTC) (envelope-from venglin@freebsd.lublin.pl) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [193.138.118.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4958FC1B; Fri, 15 Jun 2012 11:42:08 +0000 (UTC) Received: from [IPv6:2001:1a68:f:0:45b0:efbb:4d95:ee42] (unknown [IPv6:2001:1a68:f:0:45b0:efbb:4d95:ee42]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id A327B23946C; Fri, 15 Jun 2012 13:33:18 +0200 (CEST) Message-ID: <4FDB1D71.6050908@freebsd.lublin.pl> Date: Fri, 15 Jun 2012 13:33:05 +0200 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4DAD3824.7000500@frasunek.com> <20110419074056.GG34767@glebius.int.ru> <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> In-Reply-To: <20110517184613.GN74366@glebius.int.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Gleb Smirnoff , Eugene Grosbein Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 11:42:08 -0000 Dear All, unfortunately, one of my mpd5 PPPoE access servers started panicing every few hours. I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS and DEBUG_MEMGUARD compiled. Unfortunately, I'm unable to catch crashdump. For some reason, it is not saved on dumpdev. The only thing I have is panic string: Fatal trap 9: general protection fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0xffffffff804b4e2d stack pointer = 0x28:0xffffff8185386560 frame pointer = 0x28:0xffffff81853865d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2832 (mpd5) trap number = 9 According to "objdump -d", the fault address points to prelist_remove(). I tried to replace all of hardware, but it still panics in the same way. I would be really grateful for any hints. dmesg output: http://www.frasunek.com/tmp/dmesg.txt kernel config: http://www.frasunek.com/tmp/kernel.txt From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 11:50:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94985106566B; Fri, 15 Jun 2012 11:50:40 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id DA0B38FC19; Fri, 15 Jun 2012 11:50:39 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q5FBoOtJ019303; Fri, 15 Jun 2012 18:50:24 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FDB2180.4030609@rdtc.ru> Date: Fri, 15 Jun 2012 18:50:24 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Przemyslaw Frasunek References: <4DAD3824.7000500@frasunek.com> <20110419074056.GG34767@glebius.int.ru> <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> In-Reply-To: <4FDB1D71.6050908@freebsd.lublin.pl> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Andriy Gapon Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 11:50:40 -0000 15.06.2012 18:33, Przemyslaw Frasunek ÐÉÛÅÔ: > Dear All, > > unfortunately, one of my mpd5 PPPoE access servers started panicing every few > hours. > > I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS and > DEBUG_MEMGUARD compiled. Unfortunately, I'm unable to catch crashdump. For some > reason, it is not saved on dumpdev. The reason is that 8-STABLE fails to stop scheduler on panic that breaks writing of crashdumps. 8.3-STABLE has new sysctl kern.stop_scheduler_on_panic. You should set it to 1 to get crashdumps saved. One more: does your box has PS/2 keyboard or USB? It matters too. For systems having USB keyboard there is another patch needed to obtain crashdumps (by Andriy Gapon): http://www.kuzbass.ru/freebsd/patches/stop_scheduler_on_panic.usb.diff Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 11:57:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27F5E106564A for ; Fri, 15 Jun 2012 11:57:47 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 6F55B8FC15 for ; Fri, 15 Jun 2012 11:57:46 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q5FBvhw2019373; Fri, 15 Jun 2012 18:57:43 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FDB2337.1030403@rdtc.ru> Date: Fri, 15 Jun 2012 18:57:43 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Przemyslaw Frasunek References: <4DAD3824.7000500@frasunek.com> <20110419074056.GG34767@glebius.int.ru> <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <4FDB2180.4030609@rdtc.ru> In-Reply-To: <4FDB2180.4030609@rdtc.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Andriy Gapon Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 11:57:47 -0000 15.06.2012 18:50, Eugene Grosbein ÐÉÛÅÔ: >> unfortunately, one of my mpd5 PPPoE access servers started panicing every few >> hours. >> >> I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS and >> DEBUG_MEMGUARD compiled. Unfortunately, I'm unable to catch crashdump. For some >> reason, it is not saved on dumpdev. > > The reason is that 8-STABLE fails to stop scheduler on panic > that breaks writing of crashdumps. > > 8.3-STABLE has new sysctl kern.stop_scheduler_on_panic. > You should set it to 1 to get crashdumps saved. > > One more: does your box has PS/2 keyboard or USB? It matters too. > For systems having USB keyboard there is another patch needed to obtain > crashdumps (by Andriy Gapon): > > http://www.kuzbass.ru/freebsd/patches/stop_scheduler_on_panic.usb.diff Sorry, right URL is: http://www.grosbein.net/freebsd/patches/stop_scheduler_on_panic.usb.diff Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 11:57:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A58BA106566C for ; Fri, 15 Jun 2012 11:57:51 +0000 (UTC) (envelope-from venglin@freebsd.lublin.pl) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [193.138.118.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2338FC12 for ; Fri, 15 Jun 2012 11:57:51 +0000 (UTC) Received: from [IPv6:2001:1a68:f:0:45b0:efbb:4d95:ee42] (unknown [IPv6:2001:1a68:f:0:45b0:efbb:4d95:ee42]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id 9BC6823946A; Fri, 15 Jun 2012 13:57:50 +0200 (CEST) Message-ID: <4FDB2331.8080207@freebsd.lublin.pl> Date: Fri, 15 Jun 2012 13:57:37 +0200 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eugene Grosbein References: <4DAD3824.7000500@frasunek.com> <20110419074056.GG34767@glebius.int.ru> <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <4FDB2180.4030609@rdtc.ru> In-Reply-To: <4FDB2180.4030609@rdtc.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andriy Gapon Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 11:57:51 -0000 > One more: does your box has PS/2 keyboard or USB? It matters too. > For systems having USB keyboard there is another patch needed to obtain > crashdumps (by Andriy Gapon): Thanks a lot. I have KVM connected using USB. I'll apply this patch. From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 13:10:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9E261065674; Fri, 15 Jun 2012 13:10:28 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9FFA38FC1F; Fri, 15 Jun 2012 13:10:28 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 873EA21211; Fri, 15 Jun 2012 09:10:22 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 15 Jun 2012 09:10:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=RY7b7d/cRV0lGMBVY5ycbR 0tRs8=; b=Mo90MmzHJKEf3UWeQWD95o4VVnyb5gL6ADBNJkt/jlP0+jY510PTwq 7xWmtU0GDgqcSs+h7AC5doxKuiaNeuLU3FlFDJuQ6OAtg8POhDXVKnd/2a9daYbT jusmZNluoaD0MULUU1dwUwh0z0wbeGTEdX5AviCQqYHFhU9EtqjnQ= X-Sasl-enc: kqxjK8/ryWOOkY1bFIzT7UTWNLHCwrbYX2mj8y/3a6XH 1339765822 Received: from [192.168.1.23] (unknown [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPA id 1EE698E01C3; Fri, 15 Jun 2012 09:10:20 -0400 (EDT) Message-ID: <4FDB4276.9020402@freebsd.org> Date: Sat, 16 Jun 2012 00:11:02 +1000 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> <4F7B1981.1050009@freebsd.org> <4F7B80CE.90805@freebsd.org> In-Reply-To: <4F7B80CE.90805@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: darrenr@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 13:10:29 -0000 Andre Oppermann wrote: > On 03.04.2012 17:38, Darren Reed wrote: >> On 3/04/2012 11:45 PM, Andre Oppermann wrote: >>> On 01.04.2012 09:27, Darren Reed wrote: >>>> The problem here is that it only tracks the window size as >>>> it grows, not as it shrinks. Thus the remote end setting its >>>> window size to 0 is ignored. >>> >>> My patch is wrong as the acked count is already integrated >>> by the time we reach this spot. I'm working on a better >>> implementation. >> >> Ok, I'll look forward to seeing and testing it. > > Please test this patch: > http://people.freebsd.org/~andre/tcp_input.c-windowupdate-2012040.diff > > I just completed a number of tests and inspected the debug output as > well as the corresponding tcpdumps. In all could simulate it behaved > correctly now with regard to tracking the window and updates. Today I ran a similar workload to what I had done previously and it seemed to progress without incident. I had tcpdump running to capture the entire session and upon review of that, there are indeed instances where the window from the remote end is advertised as 0. For now at least, that patch seems to do the magic trick. Cheers, Darren From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 14:19:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3F9D1065675 for ; Fri, 15 Jun 2012 14:19:38 +0000 (UTC) (envelope-from cjharrer@comcast.net) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9DC8FC1C for ; Fri, 15 Jun 2012 14:19:38 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta03.westchester.pa.mail.comcast.net with comcast id NccF1j00C27AodY53eKcUG; Fri, 15 Jun 2012 14:19:36 +0000 Received: from sz0092.wc.mail.comcast.net ([76.96.58.150]) by omta19.westchester.pa.mail.comcast.net with comcast id NeKc1j01P3EUZNL3feKcMW; Fri, 15 Jun 2012 14:19:36 +0000 Date: Fri, 15 Jun 2012 14:19:36 +0000 (UTC) From: cjharrer@comcast.net To: freebsd-net@freebsd.org Message-ID: <1929842031.121770.1339769976906.JavaMail.root@sz0092a.westchester.pa.mail.comcast.net> In-Reply-To: <930457657.42273.1339623607713.JavaMail.root@sz0092a.westchester.pa.mail.comcast.net> MIME-Version: 1.0 X-Originating-IP: [68.45.229.179] X-Mailer: Zimbra 6.0.13_GA_2944 (ZimbraWebClient - SAF3 (Win)/6.0.13_GA_2944) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Window updates during periods of HIGH packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 14:19:38 -0000 I did look at later versions of the code and do not see any changes that would affect my test below. I have put a change into the code, which I'm sure would be frowned upon in the manner I did it, that fixes the problem and allows "PERSIST" to clear the situation. My change is in tcp_output.c, there is a block of code that determines whether the REXMT timer needs to be started just prior to calling ip_output; I added an "else" branch to that block that, if the rexmt timer isn't started, I check to see if the PERSIST timer needs to be started, I do this by: } else if ((tp->snd_nxt == tp->snd_una) && (tp->snd_nxt == tp->snd_max) && (so->so_snd.sb_cc != 0) && (tp->snd_wnd = 0)) { tcp_setpersist(tp) } Chris ----- Original Message ----- From: cjharrer@comcast.net To: freebsd-net@freebsd.org Sent: Wednesday, June 13, 2012 5:40:07 PM Subject: Re: Window updates during periods of HIGH packet loss Oops, left one part out below... When snd_nxt == snd_una == snd_max; snd_wnd == 0 which is why we can't send any new data. ----- Original Message ----- From: cjharrer@comcast.net To: freebsd-net@freebsd.org Cc: "Christopher J. Harrer" Sent: Wednesday, June 13, 2012 5:02:57 PM Subject: Window updates during periods of HIGH packet loss Running FreeBSD 8.0 Stable and we're running into an issue with window updates during periods of very high DUPLEX network traffic where there are a good number of network packets being dropped. Please let me know if there is a better list to ask this question of. I'm going to use some small, made up numbers to demonstrate what is going on. I can go into more detail with explicit numbers from an internal trace that I created, but it gets pretty long and tedious, so I'd like to see if my example makes sense first. We have a server that is running a lot of NFS traffic (NFSv3 over TCP/IPv4) to a NetApp back-end filer (not sure the filer matters). For the purpose of this problem description, let's assume that I have a send and receive window of 10,000. We have a lot of data outstanding in the network (let's say 9000 bytes), the back-end filer (seq 1,000 to 9,999). The filer is sending us a lot of data concurrent to our 9000 bytes we just sent. Lets assume our rcv_nxt is 1,000. We receive th_seq of 10,000 (out of order) from the filer and it ACK's all of our oustanding data. So, snd_wl1 becomes 10,000 and snd_wl2 becomes 9,999. Our snd_wnd is now 10000, so we begin to send new data (again, we blast it out, so let's assume we have 10,000 more bytes sent). The filer is "resending" sequencne numbers 1,000 through 9,999 because the new data we are sending contains SACK blocks instructing it to. The retransmitted data we are receiving is also acking our new sent data such that when we receive segment with th_seq 9,000 it goes up to 9999 (and completes our out of order processing) all of our data is acked. Now, here's where the problem arises: 1) in processing a WindowUpdate (step6 in tcp_input) the 2nd check that is made is to ensure that tp->snd_wl1 < th->th_seq, in this case, it's not. 10,000 is not less than 9,000. The next check needs th->th_seq == tp->snd_wl1 which also fails, so no window update done. 2) After tcp_reass handles the receipt of the last segment that fills in the "hole" in our stream, tp->t_flags |= TF_ACKNOW (this flag cause tcp_output to skip the check to start the PERSIST timer, because it must force a send (in this case, the send is just an ACK). Any time tcp_reass returns TF_ACKNOW is set. We've gotten a new send down while we were sending data into our open window, so now we're stuck, tp->snd_nxt == tp->snd_una == tp->snd_max and so_snd.sb_cc !=0, TT_PERSIST is NOT running and TT_REXMT is not running. Eventually the filer sends us a FIN to close an "idle" client connection; which is normal operation in this configuration. I have not looked at more recent versions of FreeBSD code yet, I will start doing that now. I just wanted to ask the experts if I'm missing something here, it feels like I am. Thanks in advance for any insight you can provide. Regards, 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" From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 20:31:46 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F168106566B for ; Fri, 15 Jun 2012 20:31:46 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 470FF8FC12 for ; Fri, 15 Jun 2012 20:31:45 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q5FKVg0j084023; Sat, 16 Jun 2012 00:31:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q5FKVgG2084022; Sat, 16 Jun 2012 00:31:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 16 Jun 2012 00:31:42 +0400 From: Gleb Smirnoff To: Przemyslaw Frasunek Message-ID: <20120615203142.GW28613@glebius.int.ru> References: <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4FDB1D71.6050908@freebsd.lublin.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Eugene Grosbein Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 20:31:46 -0000 On Fri, Jun 15, 2012 at 01:33:05PM +0200, Przemyslaw Frasunek wrote: P> unfortunately, one of my mpd5 PPPoE access servers started panicing every few P> hours. P> P> I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS and P> DEBUG_MEMGUARD compiled. Unfortunately, I'm unable to catch crashdump. For some P> reason, it is not saved on dumpdev. P> P> The only thing I have is panic string: P> P> Fatal trap 9: general protection fault while in kernel mode P> cpuid = 2; apic id = 02 P> instruction pointer = 0x20:0xffffffff804b4e2d P> stack pointer = 0x28:0xffffff8185386560 P> frame pointer = 0x28:0xffffff81853865d0 P> code segment = base 0x0, limit 0xfffff, type 0x1b P> = DPL 0, pres 1, long 1, def32 0, gran 1 P> processor eflags = interrupt enabled, resume, IOPL = 0 P> current process = 2832 (mpd5) P> trap number = 9 P> P> According to "objdump -d", the fault address points to prelist_remove(). P> P> I tried to replace all of hardware, but it still panics in the same way. I would P> be really grateful for any hints. P> P> dmesg output: http://www.frasunek.com/tmp/dmesg.txt P> kernel config: http://www.frasunek.com/tmp/kernel.txt I suspect this isn't related to netgraph, but to IPv6 since prelist_remove() is found in netinet6/nd6_rtr.c. Several times I looked into ND code and found lots of race prone code there. May be some was recently fixed by bz@, but definitely not merged to stable/8. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 20:50:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30600106566C; Fri, 15 Jun 2012 20:50:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id E0D148FC0A; Fri, 15 Jun 2012 20:50:20 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q5FKoHHM089897; Fri, 15 Jun 2012 16:50:17 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4FDBA00A.7010502@sentex.net> Date: Fri, 15 Jun 2012 16:50:18 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gleb Smirnoff References: <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> In-Reply-To: <20120615203142.GW28613@glebius.int.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: Przemyslaw Frasunek , Eugene Grosbein , freebsd-net@freebsd.org Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 20:50:21 -0000 On 6/15/2012 4:31 PM, Gleb Smirnoff wrote: > On Fri, Jun 15, 2012 at 01:33:05PM +0200, Przemyslaw Frasunek wrote: > P> unfortunately, one of my mpd5 PPPoE access servers started panicing every few > P> hours. > P> > P> I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS and > I suspect this isn't related to netgraph, but to IPv6 since prelist_remove() > is found in netinet6/nd6_rtr.c. > > Several times I looked into ND code and found lots of race prone code there. > May be some was recently fixed by bz@, but definitely not merged to stable/8. There were a bunch of commits / fixes by BZ on the 5th of June. Perhaps try updating to RELENG_8 as of today. If you are not using IPv6, perhaps disable for a day to see if that makes a difference stability wise ? It did for me back in Nov when running with v6 on an LNS was not stable. http://lists.freebsd.org/pipermail/svn-src-stable-8/2012-June/007555.html ---Mike > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Jun 15 21:57:37 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B550106566B; Fri, 15 Jun 2012 21:57:37 +0000 (UTC) (envelope-from venglin@freebsd.lublin.pl) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC078FC12; Fri, 15 Jun 2012 21:57:36 +0000 (UTC) Received: from [IPv6:2a02:2928:a:ffff:6d6f:66a5:bf4d:45be] (unknown [IPv6:2a02:2928:a:ffff:6d6f:66a5:bf4d:45be]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id 4B5E4239454; Fri, 15 Jun 2012 23:57:35 +0200 (CEST) Message-ID: <4FDBAFD7.9020606@freebsd.lublin.pl> Date: Fri, 15 Jun 2012 23:57:43 +0200 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0 MIME-Version: 1.0 To: Gleb Smirnoff References: <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> In-Reply-To: <20120615203142.GW28613@glebius.int.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Eugene Grosbein , Mike Tancsa Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Jun 2012 21:57:37 -0000 > I suspect this isn't related to netgraph, but to IPv6 since prelist_remove() > is found in netinet6/nd6_rtr.c. > > Several times I looked into ND code and found lots of race prone code there. > May be some was recently fixed by bz@, but definitely not merged to stable/8. Thanks a lot guys. For now, I disabled IPv6 on this BRAS. Let's see if it's going to help. From owner-freebsd-net@FreeBSD.ORG Sat Jun 16 18:13:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3DA2106564A for ; Sat, 16 Jun 2012 18:13:30 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6BA728FC08 for ; Sat, 16 Jun 2012 18:13:30 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3908865wgb.31 for ; Sat, 16 Jun 2012 11:13:29 -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:content-transfer-encoding; bh=2xM4b8yfj0q94vKeS92Tp9mmdTqpzMMFsRiGs9JiGa0=; b=oSEo1cSfFhCgmcao12BKN1c9dqZCrHPAgwM+40jmtVJt8OrLkvCaRELYb80ydwFNxD uw08mGEifDODkGh0F93nB1524PR54SPrxDn9WYABt/JGyab95FkZyJ5gdeGAjqozil2W DYk0BnHMdorYvImk2x27n5MNHb+9sejrP6XiysojUl+ATo8UPqWFhjQIrL6ISaRpf0Gz hSxlOM6kTtYfer7aimFg0+q6iobaatucaKBl3SYqayMfXmFj+f+tZCVTHu5uEOGr1LL3 9YxMhNEWXG2NWl4YaQWnPAMNtNhIuAwIQfRGuH3rbV8MtcKWI0e/lovk3YKHAmhJUwKx 8hNA== MIME-Version: 1.0 Received: by 10.180.109.197 with SMTP id hu5mr12627727wib.8.1339870409279; Sat, 16 Jun 2012 11:13:29 -0700 (PDT) Received: by 10.216.214.101 with HTTP; Sat, 16 Jun 2012 11:13:29 -0700 (PDT) In-Reply-To: <4FDB2180.4030609@rdtc.ru> References: <4DAD3824.7000500@frasunek.com> <20110419074056.GG34767@glebius.int.ru> <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <4FDB2180.4030609@rdtc.ru> Date: Sat, 16 Jun 2012 14:13:29 -0400 Message-ID: From: Arnaud Lacombe To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: Przemyslaw Frasunek , Andriy Gapon , freebsd-net@freebsd.org Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2012 18:13:31 -0000 Hi, On Fri, Jun 15, 2012 at 7:50 AM, Eugene Grosbein wrote: > 15.06.2012 18:33, Przemyslaw Frasunek =D0=C9=DB=C5=D4: >> Dear All, >> >> unfortunately, one of my mpd5 PPPoE access servers started panicing ever= y few >> hours. >> >> I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS = and >> DEBUG_MEMGUARD compiled. Unfortunately, I'm unable to catch crashdump. F= or some >> reason, it is not saved on dumpdev. > > The reason is that 8-STABLE fails to stop scheduler on panic > that breaks writing of crashdumps. > > 8.3-STABLE has new sysctl kern.stop_scheduler_on_panic. > You should set it to 1 to get crashdumps saved. > Is there technical reason to have the scheduler still running after panic()= ? - Arnaud > One more: does your box has PS/2 keyboard or USB? It matters too. > For systems having USB keyboard there is another patch needed to obtain > crashdumps (by Andriy Gapon): > > http://www.kuzbass.ru/freebsd/patches/stop_scheduler_on_panic.usb.diff > > Eugene Grosbein > > _______________________________________________ > 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 Jun 16 19:22:11 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6CAED106564A; Sat, 16 Jun 2012 19:22:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id E48768FC08; Sat, 16 Jun 2012 19:22:10 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 99AE125D3AC8; Sat, 16 Jun 2012 19:22:08 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 58FCABE8595; Sat, 16 Jun 2012 19:22:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id FSgFVDBBM9ca; Sat, 16 Jun 2012 19:21:43 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 635BABE857E; Sat, 16 Jun 2012 19:21:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4FDBAFD7.9020606@freebsd.lublin.pl> Date: Sat, 16 Jun 2012 19:21:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <63C376CE-C184-47D5-9772-1C5C02C49063@lists.zabbadoz.net> References: <4DB47CE1.8@frasunek.com> <4DB487D2.7030104@rdtc.ru> <4DB48B76.8050101@frasunek.com> <4DB49109.3050002@frasunek.com> <20110425050548.GF34767@glebius.int.ru> <4DBBBAD8.2000705@frasunek.com> <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> To: Przemyslaw Frasunek X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@FreeBSD.org, Gleb Smirnoff , Eugene Grosbein , Mike Tancsa Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2012 19:22:11 -0000 On 15. Jun 2012, at 21:57 , Przemyslaw Frasunek wrote: >> I suspect this isn't related to netgraph, but to IPv6 since = prelist_remove() >> is found in netinet6/nd6_rtr.c. >>=20 >> Several times I looked into ND code and found lots of race prone code = there. >> May be some was recently fixed by bz@, but definitely not merged to = stable/8. >=20 > Thanks a lot guys. For now, I disabled IPv6 on this BRAS. Let's see if = it's > going to help. It will, as there are no fixes in the tree yet for this issue. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!