From owner-freebsd-net@FreeBSD.ORG Sun Sep 25 05:50:10 2011 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 512C81065674 for ; Sun, 25 Sep 2011 05:50:10 +0000 (UTC) (envelope-from john@feith.com) Received: from feith1.FEITH.COM (feith1.FEITH.COM [192.251.93.1]) by mx1.freebsd.org (Postfix) with ESMTP id EB88B8FC17 for ; Sun, 25 Sep 2011 05:50:08 +0000 (UTC) Received: from jwlab.FEITH.COM (jwlab.FEITH.COM [192.251.93.16]) by feith1.FEITH.COM (8.14.4+Sun/8.12.9) with ESMTP id p8P5e5fV019390; Sun, 25 Sep 2011 01:40:05 -0400 (EDT) (envelope-from john@jwlab.FEITH.COM) Received: from jwlab.FEITH.COM (localhost [127.0.0.1]) by jwlab.FEITH.COM (8.14.4+Sun/8.14.4) with ESMTP id p8P5e5Je007045; Sun, 25 Sep 2011 01:40:05 -0400 (EDT) Received: (from john@localhost) by jwlab.FEITH.COM (8.14.4+Sun/8.14.4/Submit) id p8P5e5N7007044; Sun, 25 Sep 2011 01:40:05 -0400 (EDT) Date: Sun, 25 Sep 2011 01:40:05 -0400 (EDT) From: John Wehle Message-Id: <201109250540.p8P5e5N7007044@jwlab.FEITH.COM> To: eadler@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain X-DCC-dmv.com-Metrics: feith1; whitelist X-Scanned-By: MIMEDefang 2.67 on 192.251.93.1 Cc: freebsd-net@FreeBSD.org Subject: Re: kern/79895: [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph [regression] 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, 25 Sep 2011 05:50:10 -0000 > Is this still an issue on recent versions of FreeBSD? No. I'm sorry ... I don't recall at what point it started working again. -- John From owner-freebsd-net@FreeBSD.ORG Sun Sep 25 08:10:05 2011 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 575D2106566B for ; Sun, 25 Sep 2011 08:10:05 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1044A8FC12 for ; Sun, 25 Sep 2011 08:10:04 +0000 (UTC) Received: by gyf2 with SMTP id 2so4447850gyf.13 for ; Sun, 25 Sep 2011 01:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZTKfcrD/iykWiSWgGEbky+LlwnQDFafnE6gnEpdAAlQ=; b=XBNJ9qk4bTVj4db5hFaDk4TPn6vFcJ93OGtDSx03oGlvmZVpKz7n2v5ijvdS7Ao07Q zCEV44LQsZK8i1nwJjrxR8X2hG0Ft+QHKlt+dmVHyJwsTDEL/+CQbIl5Jam0+irzyV3G xzjvQLu1ONZqbVZhlADlGTe4nFwbYugsSmxCQ= MIME-Version: 1.0 Received: by 10.42.74.131 with SMTP id w3mr6155296icj.223.1316938204168; Sun, 25 Sep 2011 01:10:04 -0700 (PDT) Received: by 10.231.12.138 with HTTP; Sun, 25 Sep 2011 01:10:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 Sep 2011 11:10:04 +0300 Message-ID: From: Sami Halabi To: Rafael Ganascim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: em/igb multiqueue support 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, 25 Sep 2011 08:10:05 -0000 Hi, how you can see if a nic has queue or not, and how much in use? can we configure the amount of queues? i have 2 nics, 82599Eb - ixgbe (10g) and 82571EB - em driver Thanks in advance, Sami On Sat, Sep 24, 2011 at 11:09 PM, Rafael Ganascim wrote: > Hi, > > I think that this is an old question.... > > I think that Intel 82575 (and another models) hardware are capable of > multiple queues both on the receive and the send side. Is it right? > Currently the processing of packets is limited to one CPU per NIC. > > Can we have multiple taskq processes for one NIC in parallel? Is > anyone working on this right now, and if not does this sound like > something > anyone is interested in doing? (yes, I know the Yandex driver). > > -- > Best regards, > > Rafael > _______________________________________________ > 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" > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Sun Sep 25 10:53:07 2011 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 79AE9106564A for ; Sun, 25 Sep 2011 10:53:07 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id D7FD58FC13 for ; Sun, 25 Sep 2011 10:53:06 +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 p8PAr23F067946; Sun, 25 Sep 2011 17:53:02 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E7F0809.6010906@rdtc.ru> Date: Sun, 25 Sep 2011 17:52:57 +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: Rafael Ganascim References: <4E7E433E.5070307@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "net@freebsd.org" Subject: Re: em/igb multiqueue support 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, 25 Sep 2011 10:53:07 -0000 > Thanks! I'm using 7.4.... I will try it with 8.2 > > And, how the load sharing occurs between the queues? The card uses more than one interrupt vector while notifying CPUs on incoming traffic, allowing operating system driver to bind distinct NIC interrupts to distinct CPUs. The card implements Microsoft RSS: http://download.microsoft.com/download/5/d/6/5d6eaf2b-7ddf-476b-93dc-7cf0072878e6/ndis_rss.doc From owner-freebsd-net@FreeBSD.ORG Sun Sep 25 12:53:11 2011 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 71368106564A; Sun, 25 Sep 2011 12:53:11 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 49BA78FC0C; Sun, 25 Sep 2011 12:53:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8PCrB1U026767; Sun, 25 Sep 2011 12:53:11 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8PCrBZt026763; Sun, 25 Sep 2011 12:53:11 GMT (envelope-from eadler) Date: Sun, 25 Sep 2011 12:53:11 GMT Message-Id: <201109251253.p8PCrBZt026763@freefall.freebsd.org> To: john@feith.com, eadler@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/79895: [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph [regression] 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, 25 Sep 2011 12:53:11 -0000 Synopsis: [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph [regression] State-Changed-From-To: feedback->closed State-Changed-By: eadler State-Changed-When: Sun Sep 25 12:53:10 UTC 2011 State-Changed-Why: submitter says the issue has been fixed http://www.freebsd.org/cgi/query-pr.cgi?pr=79895 From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 00:16:02 2011 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 3EB4D106566C for ; Mon, 26 Sep 2011 00:16:02 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 1BDC28FC08 for ; Mon, 26 Sep 2011 00:16:01 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Sep 2011 17:03:59 -0700 From: Ben Hutchings To: Juli Mallett Date: Mon, 26 Sep 2011 01:03:48 +0100 In-Reply-To: References: <20110924173120.GB71672@onelab2.iet.unipi.it> <78FA5152-123E-492C-9A05-E95C474DE469@lists.zabbadoz.net> <20110924205217.GA72397@onelab2.iet.unipi.it> Organization: Solarflare Communications Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2- Content-Transfer-Encoding: 7bit Message-ID: <1316995431.4122.123.camel@deadeye> Mime-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 00:04:00.0174 (UTC) FILETIME=[CB1164E0:01CC7BDF] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18406.005 X-TM-AS-Result: No--21.172500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "Bjoern A. Zeeb" , Luigi Rizzo , net@freebsd.org Subject: Re: which 10GE cards are supported by FreeBSD ? 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, 26 Sep 2011 00:16:02 -0000 On Sat, 2011-09-24 at 13:56 -0700, Juli Mallett wrote: > On Sat, Sep 24, 2011 at 13:52, Luigi Rizzo wrote: > > apart from the typo ("know know") yes the email contained three > > serious questions, two of which (third party drivers and shops > > which carry the card) i cannot answer looking at the tree. > > > > On top of this, some in-tree drivers may be stale, broken, redundant > > (say ixgb vs ixgbe), and so on. And not all hardware can do line > > rate -- not even at 1G, let alone 10G, so it would be good to know > > also some first hand information on performance. > > ixgb vs. ixgbe is not a stale/redundant issue. ixgb only supports the > 82597, which you'll find is not supported by ixgbe. > > I think you'll have a hard time getting reliable performance > information. There's a lot of smoke and mirrors about performance, as > you point out. It has also been my experience that many 10g devices > cannot reliably do 1g line rate with minimal packet sizes. I don't > fully understand why this is, but most people who I've seen give > performance numbers for FreeBSD are looking at bulk transmit, which is > of course not (necessarily) what you care about for netmap. I've yet > to hear from anyone who can name a 10G NIC one can buy that can do > line rate with minimal packet sizes. Solarflare boasts about lower > latency, so perhaps they'll have a better story in that area. [...] Sorry, our current hardware can't move 64-byte frames at 10G line rate. I can check what the maximum packet rate is if you're interested. We will have a FreeBSD driver out real soon now(TM), but most of my work on performance has gone into improving throughput. (The latency should be pretty good if you turn off interrupt moderation, though.) And really I think Onload is more useful than netmap, since it's compatible with existing source and binaries. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 02:02:01 2011 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 C16DA1065674 for ; Mon, 26 Sep 2011 02:02:01 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 578BD8FC18 for ; Mon, 26 Sep 2011 02:02:00 +0000 (UTC) Received: by wwe3 with SMTP id 3so5531459wwe.31 for ; Sun, 25 Sep 2011 19:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=15Ys5PnAkCZZwAjbc5m1QiIw9TZ5FKIBpOvSq0yL5Uk=; b=EkxjJl6wk8OXS3TB+eq41wCxxYEdl+jS1Z9FsMfEO0Xbzb4OCz+qVeIkGoekD1UnB9 Yuw9TY9CO9FG4Z4r17M4iu2OsB/1UYPDXf4SjylLvBYlYNVUh+L/qlD5dM2NCLCm7D9D +5bG0j3lvRqQl28O+xVIG2LZBnGywCTmJMW6c= MIME-Version: 1.0 Received: by 10.216.80.38 with SMTP id j38mr7938477wee.36.1317000668203; Sun, 25 Sep 2011 18:31:08 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Sun, 25 Sep 2011 18:31:08 -0700 (PDT) In-Reply-To: <1316995431.4122.123.camel@deadeye> References: <20110924173120.GB71672@onelab2.iet.unipi.it> <78FA5152-123E-492C-9A05-E95C474DE469@lists.zabbadoz.net> <20110924205217.GA72397@onelab2.iet.unipi.it> <1316995431.4122.123.camel@deadeye> Date: Sun, 25 Sep 2011 21:31:08 -0400 Message-ID: From: Arnaud Lacombe To: Ben Hutchings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Juli Mallett , "Bjoern A. Zeeb" , Luigi Rizzo , net@freebsd.org Subject: Re: which 10GE cards are supported by FreeBSD ? 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, 26 Sep 2011 02:02:01 -0000 Hi, On Sun, Sep 25, 2011 at 8:03 PM, Ben Hutchings wrote: > On Sat, 2011-09-24 at 13:56 -0700, Juli Mallett wrote: >> On Sat, Sep 24, 2011 at 13:52, Luigi Rizzo wrote: >> > apart from the typo ("know know") yes the email contained three >> > serious questions, two of which (third party drivers and shops >> > which carry the card) i cannot answer looking at the tree. >> > >> > On top of this, some in-tree drivers may be stale, broken, redundant >> > (say ixgb vs ixgbe), and so on. =A0And not all hardware can do line >> > rate -- not even at 1G, let alone 10G, so it would be good to know >> > also some first hand information on performance. >> >> ixgb vs. ixgbe is not a stale/redundant issue. =A0ixgb only supports the >> 82597, which you'll find is not supported by ixgbe. >> >> I think you'll have a hard time getting reliable performance >> information. =A0There's a lot of smoke and mirrors about performance, as >> you point out. =A0It has also been my experience that many 10g devices >> cannot reliably do 1g line rate with minimal packet sizes. =A0I don't >> fully understand why this is, but most people who I've seen give >> performance numbers for FreeBSD are looking at bulk transmit, which is >> of course not (necessarily) what you care about for netmap. =A0I've yet >> to hear from anyone who can name a 10G NIC one can buy that can do >> line rate with minimal packet sizes. =A0Solarflare boasts about lower >> latency, so perhaps they'll have a better story in that area. > [...] > > Sorry, our current hardware can't move 64-byte frames at 10G line rate. > I can check what the maximum packet rate is if you're interested. > If you refer to [0] and [1], it would seem that the Solarstorm SFC4000 (B) supports 4e6 pps. That said, that is a number from 2008. > We will have a FreeBSD driver out real soon now(TM), but most of my work > on performance has gone into improving throughput. =A0(The latency should > be pretty good if you turn off interrupt moderation, though.) =A0And > really I think Onload is more useful than netmap, since it's compatible > with existing source and binaries. > By "FreeBSD driver", do you mean just a driver for the card, or the complete Onload stack ? AFAIS, it is currently Linux only. Thanks, - Arnaud [0]: http://www.youtube.com/watch?v=3D1Y8hoznuuuM [1]: http://www.openonload.org/openonload-google-talk.pdf > Ben. > > -- > Ben Hutchings, Staff Engineer, Solarflare > Not speaking for my employer; that's the marketing department's job. > They asked us to note that Solarflare product names are trademarked. > > > _______________________________________________ > 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 Sep 26 04:43:29 2011 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 032F11065694 for ; Mon, 26 Sep 2011 04:43:29 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B3CAF8FC16 for ; Mon, 26 Sep 2011 04:43:28 +0000 (UTC) Received: by vws11 with SMTP id 11so6869813vws.13 for ; Sun, 25 Sep 2011 21:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=WN98/Z6CGYyC2IK3Oej/2rtCJpncUACANbgAK7IQuEY=; b=kcisTTReV2bWzW4YgpF5Qm2Wy/kOPx7wMI90Ww5GIsVwo3KQ6ceKduCfUv4axkNmjT V4Qi4b3qegCouZ6Pgts7p6bGHjjH26wnygJq2rTSqkL8tFOMy3b8yDfkCyu19l9DJBLl IR69hkoa3kBIstbKOyfujMIuDkDlVsveRwTD8= MIME-Version: 1.0 Received: by 10.52.175.230 with SMTP id cd6mr5958048vdc.251.1317012207835; Sun, 25 Sep 2011 21:43:27 -0700 (PDT) Received: by 10.52.107.194 with HTTP; Sun, 25 Sep 2011 21:43:27 -0700 (PDT) Date: Mon, 26 Sep 2011 12:43:27 +0800 Message-ID: From: dave jones To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Kernel panic on FreeBSD 9.0-beta2 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, 26 Sep 2011 04:43:29 -0000 Hi, I have two production machines running on freebsd 9.0-beta2 and both got kernel panic related to networking. Any idea how to solve it? thanks. http://http://60.248.161.9/p1.jpg http://http://60.248.161.9/p2.jpg Regards, Dave. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 05:12:26 2011 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 67270106564A for ; Mon, 26 Sep 2011 05:12:26 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 01A668FC12 for ; Mon, 26 Sep 2011 05:12:25 +0000 (UTC) Received: by wwe3 with SMTP id 3so5630869wwe.31 for ; Sun, 25 Sep 2011 22:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=57OV9F58vkLT+2Sy1sFzT6bncq0p/3FnpDMrmKlxPH4=; b=J6y5kNHu8g++w3YzSRLfNvvVkcnlzn4CgJ5GcGX1zSqrSOuWyT2oL4gyz9Z7LYqb00 FOlNrKtbjUxVQVQr9ojN/5sqZWxEZDhVKQnf8F+dFufJ9PMI30kP6XoOEq5t0ofshFrO WUpfVwjkfvfBj8XZhAxMYZVhKtCwRFhiqWato= MIME-Version: 1.0 Received: by 10.216.80.38 with SMTP id j38mr8135570wee.36.1317013944719; Sun, 25 Sep 2011 22:12:24 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Sun, 25 Sep 2011 22:12:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 01:12:24 -0400 Message-ID: From: Arnaud Lacombe To: dave jones Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 26 Sep 2011 05:12:26 -0000 Hi, On Mon, Sep 26, 2011 at 12:43 AM, dave jones wrote: > Hi, > I have two production machines running on freebsd 9.0-beta2 and both got > kernel panic related to networking. Any idea how to solve it? thanks. > > http://http://60.248.161.9/p1.jpg > http://http://60.248.161.9/p2.jpg > this host is really slow :-) To avoid the waiting time, the backtrace is: in_pcbbind_setup()+0x28f in_pcbbind()+0xa9 udp_bind() bind() kern_bind() syscall_enter() syscall() faulted at VA 0x07. Origin process in named. - Arnaud > Regards, > Dave. > _______________________________________________ > 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 Sep 26 05:41:56 2011 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 B9C33106564A for ; Mon, 26 Sep 2011 05:41:56 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4CBE08FC12 for ; Mon, 26 Sep 2011 05:41:55 +0000 (UTC) Received: by wyj26 with SMTP id 26so3370051wyj.13 for ; Sun, 25 Sep 2011 22:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hSs+QSj20tPzfPF+WGJNRzH8U8Z3fQjKi30gTqbsrow=; b=IGYfxKm/ijnsdp4Z5HtsnitM+wHBlOlV6G3ABrbts2Zj5bJ7n0Nyh1V/r3e6XpUpZO hz5gkf+CYlB+GDN/zdM3rgPMbgyuOAdV92TpAaNKGd9y8AQedJhsJEkK/PXDHoSlX5Aa ICSJyzFPwfxpSEBM5BwZpCv/CLj+yqa9kc2I8= MIME-Version: 1.0 Received: by 10.227.135.130 with SMTP id n2mr6580761wbt.51.1317015715021; Sun, 25 Sep 2011 22:41:55 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Sun, 25 Sep 2011 22:41:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 01:41:55 -0400 Message-ID: From: Arnaud Lacombe To: dave jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 26 Sep 2011 05:41:56 -0000 Hi, On Mon, Sep 26, 2011 at 1:12 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 26, 2011 at 12:43 AM, dave jones wro= te: >> Hi, >> I have two production machines running on freebsd 9.0-beta2 and both got >> kernel panic related to networking. Any idea how to solve it? thanks. >> >> http://http://60.248.161.9/p1.jpg >> http://http://60.248.161.9/p2.jpg >> > this host is really slow :-) > > To avoid the waiting time, the backtrace is: > > in_pcbbind_setup()+0x28f > in_pcbbind()+0xa9 > udp_bind() > bind() > kern_bind() > syscall_enter() > syscall() > > faulted at VA 0x07. Origin process in named. > AFAICT, the crash happens in the following block: /* * XXX * This entire block sorely needs a rewrite. */ if (t && ((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && (so->so_type !=3D SOCK_STREAM || ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) && (ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || (t->inp_socket->so_options & SO_REUSEPORT) =3D=3D 0) && (inp->inp_cred->cr_uid !=3D t->inp_cred->cr_uid)) return (EADDRINUSE); } more specifically, `t->inp_socket' is NULL. The top comment may not be relevant, as it's been here for the past 8 years. =A0- Arnaud > >> Regards, >> Dave. >> _______________________________________________ >> 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 Sep 26 05:45:02 2011 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 0C7F5106566C for ; Mon, 26 Sep 2011 05:45:02 +0000 (UTC) (envelope-from adrian.chadd@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 B836D8FC0A for ; Mon, 26 Sep 2011 05:45:01 +0000 (UTC) Received: by yxk36 with SMTP id 36so5124585yxk.13 for ; Sun, 25 Sep 2011 22:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NQvWKnnqj3ln2FdWed4he7uV9WeUz2XN3MyoOiVSkV0=; b=jZuS7fHM1T1YdRhaUdpJFt7bNW3moBCOvIAKKL28vAc7ze3RcMl0AmZRTGvkDp2e9i LqCKkSXl6VF+zDbzIHJlua2MMH/s2JfsoLdA5VNxDD8YznnhsUAwDX9scvYpC765oeCs djUvSZbPE0w9QXe8pdfXY1O2eqWNm//ut2JMQ= MIME-Version: 1.0 Received: by 10.236.129.165 with SMTP id h25mr36578848yhi.38.1317015901085; Sun, 25 Sep 2011 22:45:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sun, 25 Sep 2011 22:45:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 13:45:01 +0800 X-Google-Sender-Auth: T_BAG6xB4Uwfw2ZQm1RjyXpPVug Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 26 Sep 2011 05:45:02 -0000 On 26 September 2011 13:41, Arnaud Lacombe wrote: > =A0/* > =A0 * XXX > =A0 * This entire block sorely needs a rewrite. > =A0 */ > =A0 =A0 =A0 =A0if (t && > =A0 =A0 =A0 =A0 =A0 =A0((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && > =A0 =A0 =A0 =A0 =A0 =A0(so->so_type !=3D SOCK_STREAM || > =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) && > =A0 =A0 =A0 =A0 =A0 =A0(ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || > =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || > =A0 =A0 =A0 =A0 =A0 =A0 (t->inp_socket->so_options & > =A0 =A0 =A0 =A0 =A0 SO_REUSEPORT) =3D=3D 0) && > =A0 =A0 =A0 =A0 =A0 =A0(inp->inp_cred->cr_uid !=3D > =A0 =A0 =A0 =A0 =A0 =A0 t->inp_cred->cr_uid)) > =A0 =A0 =A0 =A0 =A0return (EADDRINUSE); > =A0 =A0 =A0} > > more specifically, `t->inp_socket' is NULL. The top comment may not be > relevant, as it's been here for the past 8 years. Why would t->inp_socket be NULL at this point? Adrian From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 05:52:24 2011 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 3F5CC1065670 for ; Mon, 26 Sep 2011 05:52:24 +0000 (UTC) (envelope-from gadidot@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 037B08FC0C for ; Mon, 26 Sep 2011 05:52:23 +0000 (UTC) Received: by gyf2 with SMTP id 2so4982604gyf.13 for ; Sun, 25 Sep 2011 22:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=PvnweJrA226fqdLFhPz/trKsezmDOuVggFXE1GhECIo=; b=nZlOE4m74lU/UvzzChdlxn3pUzXlR3n3WbKhPbRFkqU+RXmmOhKxedxRH1ezUFFJTT 91idU7J7rhrF0w8iiUWWb2+Rlbr604zTWRosWPqDWNhqgAIZjMNJGIwQgQUbPYveDKBy OOZ9zjkvKyOIFvCH//qj3rVG4h2GzdfL0tZD8= MIME-Version: 1.0 Received: by 10.68.8.71 with SMTP id p7mr27468273pba.110.1317016342801; Sun, 25 Sep 2011 22:52:22 -0700 (PDT) Received: by 10.143.44.13 with HTTP; Sun, 25 Sep 2011 22:52:22 -0700 (PDT) Date: Mon, 26 Sep 2011 13:52:22 +0800 Message-ID: From: Gi Dot To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Data centers failure proof with CARP. 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, 26 Sep 2011 05:52:24 -0000 Hi, Is it a good idea to use CARP to manage data centers failover? Say for instance I have a total of 3 public IPs: Data center A (master CARP): x.x.x.x Data center B (backup CARP): y.y.y.y CARP Virtual IP: z.z.z.z If there is a network outage occurs at data center A, all traffic to IP z.z.z.z will be routed to IP y.y.y.y. But I guess this will only work if both x.x.x.x and y.y.y.y IPs belong to the same subnet? If this is not a recommended idea (or not feasible), I would appreciate for any suggestion to make my website 'data centers failure proof'. Thanks. -- dot. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 06:06:22 2011 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 94FDE106566C; Mon, 26 Sep 2011 06:06:22 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0563F8FC0A; Mon, 26 Sep 2011 06:06:21 +0000 (UTC) Received: by wwe3 with SMTP id 3so5666780wwe.31 for ; Sun, 25 Sep 2011 23:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3IPLvuJrxWrzwBSqpi7FOhyybb50aG/9rzDR1IlXkws=; b=nJU+82NPRS41gzUQMBspVoEVOuNUG/hbb5xxD46ch77VnjX8ZsWL4GQ0K1fax9Lv+p 77w6NuOGu6gaMcmYREWC9ZUcK750a21zGR4ULImtWVjNMeG1TQQLCC9EAT9E8eSjrwOJ TxEpbO4ykVEEkew4IGhk3WChd0m6wZWqUe7tA= MIME-Version: 1.0 Received: by 10.227.36.197 with SMTP id u5mr6614641wbd.36.1317017180872; Sun, 25 Sep 2011 23:06:20 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Sun, 25 Sep 2011 23:06:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 02:06:20 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 26 Sep 2011 06:06:22 -0000 Hi, On Mon, Sep 26, 2011 at 1:45 AM, Adrian Chadd wrote: > On 26 September 2011 13:41, Arnaud Lacombe wrote: >> =A0/* >> =A0 * XXX >> =A0 * This entire block sorely needs a rewrite. >> =A0 */ >> =A0 =A0 =A0 =A0if (t && >> =A0 =A0 =A0 =A0 =A0 =A0((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && >> =A0 =A0 =A0 =A0 =A0 =A0(so->so_type !=3D SOCK_STREAM || >> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) && >> =A0 =A0 =A0 =A0 =A0 =A0(ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || >> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || >> =A0 =A0 =A0 =A0 =A0 =A0 (t->inp_socket->so_options & >> =A0 =A0 =A0 =A0 =A0 SO_REUSEPORT) =3D=3D 0) && >> =A0 =A0 =A0 =A0 =A0 =A0(inp->inp_cred->cr_uid !=3D >> =A0 =A0 =A0 =A0 =A0 =A0 t->inp_cred->cr_uid)) >> =A0 =A0 =A0 =A0 =A0return (EADDRINUSE); >> =A0 =A0 =A0} >> >> more specifically, `t->inp_socket' is NULL. The top comment may not be >> relevant, as it's been here for the past 8 years. > > Why would t->inp_socket be NULL at this point? > I really have no idea. This is just what gdb's disassembly and gcc's verbose assembly output led me to[0]: it crashes on the following instruction: 0xc0b235af : testb $0x2,0x7(%eax) 0xc0b235b3 : jne 0xc0b235c7 for which gcc originally generated: testb $2, 7(%eax) #, .so_options jne .L523 Test of the second bit at offset 0x7 is consistent with `(t->inp_socket->so_options & SO_REUSEPORT) =3D=3D 0', and that instruction is followed by a bunch of `cr_uid' checks: movl 48(%edi), %eax # .inp_cred, .inp_cred movl 48(%edx), %edx # .inp_cred, .inp_cred movl 4(%eax), %eax # .cr_uid, .cr_uid cmpl 4(%edx), %eax # .cr_uid, .cr_uid jne .L535 #, matching gdb disassembly: 0xc0b235b5 : mov 0x30(%edi),%eax 0xc0b235b8 : mov 0x30(%edx),%edx 0xc0b235bb : mov 0x4(%eax),%eax 0xc0b235be : cmp 0x4(%edx),%eax 0xc0b235c1 : jne 0xc0b236be moreover, .L535 terminates the function and returns EADDRINUSE. That said, I agree, this only tells "where" and "what", not "why" we ended up in this situation :-) - Arnaud [0]: and I'd be glad to be wrong, provided the other side provides a more meaningful answer :) From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 06:24:40 2011 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 929EF106566C for ; Mon, 26 Sep 2011 06:24:40 +0000 (UTC) (envelope-from jshupe@osre.org) Received: from washington.osre.org (washington.osre.org [108.60.195.225]) by mx1.freebsd.org (Postfix) with ESMTP id 4C46B8FC12 for ; Mon, 26 Sep 2011 06:24:39 +0000 (UTC) Received: from [10.45.29.30] (adsl-66-137-83-42.dsl.lgvwtx.swbell.net [66.137.83.42]) by washington.osre.org (Postfix) with ESMTPSA id 4F5923983B for ; Mon, 26 Sep 2011 01:07:34 -0500 (CDT) From: James Shupe To: freebsd-net@freebsd.org In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-sQAI0jyjeI6nauzeDLqZ" Organization: Open Software Research & Education Date: Mon, 26 Sep 2011 01:07:35 -0500 Message-ID: <1317017255.2706.5.camel@jshupe-2530p.osre.org> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-10.el6) Subject: Re: Data centers failure proof with CARP. 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, 26 Sep 2011 06:24:40 -0000 --=-sQAI0jyjeI6nauzeDLqZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable z.z.z.z would have to be an anycast address announced by both datacenters, so your idea is unlikely to work. --=20 James Shupe, OSRE founder/ developer/ engineer jshupe@osre.org | 866.235.1288 BSD/ Linux Support | Metro Ethernet | Hosting check out our site at www.osre.org --=-sQAI0jyjeI6nauzeDLqZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAABAgAGBQJOgBanAAoJEJRf0NzSUh9wawAP/jhdw+lXB0XLf4Vq7TJwxxm6 4N4FSBc7p0QRjO6duQVsAFgfutdQ76kOV5WqiZF1nh3aYFlvF6k5J/wJTYnZFiaC l2DUz7YAFWF3CykNEMUT90niRtdA1zaWoWoXDEE8YpWHISERDWpEWceMizqRm1l6 ZwzxUXgMn1b57iZM+WjP0LNNo5c7OASKrfDu9Xa0i/gNMAcQgOTIlL116WRERg/a dK3XJDfQ1JDWlQ7006AA6oXlum9PrYk+//9OCtLkrN/XQ6apJ1Im4DETSLquzavl r6k3+BzwGqjlC2+ZJhbbx0zKcZiZSUfoVyf5LovLGUO46D4vufYrfX2FLzWu7ta7 CKvYbatdWbZHCLPCgaEMZ2NMgzdlRzY9nYJ8MbzxwTi4d8M8EbB41XpcJ5AfUhR9 JcBpXdKn5aTPH2p0gGaASiFSPoLttZ6S+kr73l+9Y81TtlwmJA2hNZ+8U37MemAm CqCNXJtqIlPrrX4aoMTE58RWJgOqcnhAIpX4+DNLU9nlVimSnEbpa03uyePRIFCK Zk9wfzstTt+CKkKMBVy8nWDxDwPYFuGPMXu6cDzCgugGDJqd+P0ZUNjXR3KmJ632 DMia02Mc2Pf5mz1BUo3LjbMBUUiDVRsKkFDNDPf5Ehpe5UzkXfA5c+kxb/UlJn6c w5+L56PdR8rZhL9d65rP =GvnC -----END PGP SIGNATURE----- --=-sQAI0jyjeI6nauzeDLqZ-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 09:12:46 2011 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 6FCFE106564A; Mon, 26 Sep 2011 09:12:46 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B67C8FC15; Mon, 26 Sep 2011 09:12:45 +0000 (UTC) Received: by vcbf13 with SMTP id f13so3673184vcb.13 for ; Mon, 26 Sep 2011 02:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=F3np5mjZ2/joyL5dsiCHDFNq4Uih4tgfzo95Og9rm5c=; b=pD+RzPr/4y2plSMEz7AxJxv45JsFesHUEU7BDpOAT5Poekuw4Lh/3MgaI90K1udv53 zgF5OLxrK1VmzWA1kdvjAYqyJQt/GAedYeoX+4NgW7XIPPQpsG2iP3Pz/s7S1Vij4hWZ KYNFwsV52p9CsjFb49y1VaXpOqNVuorusZja8= MIME-Version: 1.0 Received: by 10.52.172.207 with SMTP id be15mr5935129vdc.144.1317028365156; Mon, 26 Sep 2011 02:12:45 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.113.202 with HTTP; Mon, 26 Sep 2011 02:12:45 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 11:12:45 +0200 X-Google-Sender-Auth: A2NYUZc_e0UGYluacMwbkEurFBc Message-ID: From: "K. Macy" To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Arnaud Lacombe , dave jones Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 26 Sep 2011 09:12:46 -0000 On Monday, September 26, 2011, Adrian Chadd wrote: > On 26 September 2011 13:41, Arnaud Lacombe wrote: >> /* >> * XXX >> * This entire block sorely needs a rewrite. >> */ >> if (t && >> ((t->inp_flags & INP_TIMEWAIT) == 0) && >> (so->so_type != SOCK_STREAM || >> ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && >> (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || >> ntohl(t->inp_laddr.s_addr) != INADDR_ANY || >> (t->inp_socket->so_options & >> SO_REUSEPORT) == 0) && >> (inp->inp_cred->cr_uid != >> t->inp_cred->cr_uid)) >> return (EADDRINUSE); >> } >> >> more specifically, `t->inp_socket' is NULL. The top comment may not be >> relevant, as it's been here for the past 8 years. > > Why would t->inp_socket be NULL at this point? TIME_WAIT ... > > > Adrian > _______________________________________________ > 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 Sep 26 09:57:32 2011 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 948441065674 for ; Mon, 26 Sep 2011 09:57:32 +0000 (UTC) (envelope-from matt.xtaz@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 50BFF8FC16 for ; Mon, 26 Sep 2011 09:57:31 +0000 (UTC) Received: by vws11 with SMTP id 11so7059828vws.13 for ; Mon, 26 Sep 2011 02:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=k/eudqmMTf+nNVdSzn+iL4aL6EEb5E7qOtuT+avXsyo=; b=SHMuF2fHasCvJ8k8yyZfwS/8A8/9k8yLAs6urNkue8ym4d8UfrGvJE82dXmVdaPROW OFBJdBte8WXIo8tbhoExxUYRBADFJRhpKRDsr+JBFCfaUMAdke22fUYAV3tKl7ywXeR1 N0p/mpcKV5KZtaM0O17WTtnaZaSx+/XYRGHxQ= MIME-Version: 1.0 Received: by 10.52.66.235 with SMTP id i11mr6054635vdt.352.1317029273841; Mon, 26 Sep 2011 02:27:53 -0700 (PDT) Received: by 10.52.167.194 with HTTP; Mon, 26 Sep 2011 02:27:53 -0700 (PDT) Date: Mon, 26 Sep 2011 10:27:53 +0100 Message-ID: From: Matt Smith To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: gif interface not passing IPv6 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: Mon, 26 Sep 2011 09:57:32 -0000 I have a very strange problem with a gif interface that has been confusing me all weekend. For the last six months I have had a gif tunnel setup to an ipv6 tunnel broker which has worked without any issues. On Friday I had a power cut. The power returned, the server restarted, and the tunnel has been down since. I have checked and rechecked the configuration and it all looks identical to what I would expect. I've even gone as far as running a buildworld/kernel in case the power outage corrupted something. The problem is that the gif interface doesn't appear to be processing any IPv6 packets at all, though it works fine with IPv4. I can't ping my side of the tunnel. For example: root@tao[~]# ifconfig gif0 gif0: flags=8051 metric 0 mtu 1280 tunnel inet 192.168.1.2 --> 77.75.104.126 inet6 fe80::240:63ff:fee8:793e%gif0 prefixlen 64 scopeid 0x5 inet6 2a01:348:6:45c::2 --> 2a01:348:6:45c::1 prefixlen 128 deprecated nd6 options=3 options=1 root@tao[~]# ping6 2a01:348:6:45c::2 PING6(56=40+8+8 bytes) 2a01:348:6:45c::2 --> 2a01:348:6:45c::2 root@tao[~]# tcpdump -i gif0 listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes 10:15:12.545930 IP6 cl-1117.lon-02.gb.sixxs.net > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 0, length 16 10:15:13.546316 IP6 cl-1117.lon-02.gb.sixxs.net > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 1, length 16 10:15:14.546220 IP6 cl-1117.lon-02.gb.sixxs.net > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 2, length 16 I've deleted other lines from the tcpdump like neighbour solicitation and only shown the pings. But there is no ping response, only the request. Traceroute shows similar: root@tao[~]# traceroute6 2a01:348:6:45c::2 traceroute6 to 2a01:348:6:45c::2 (2a01:348:6:45c::2) from 2a01:348:6:45c::2, 64 hops max, 12 byte packets 1 * * * If I create an entire new interface, same problem, but as you can see works fine with IPv4: root@tao[~]# ifconfig gif1 create root@tao[~]# ifconfig gif1 tunnel 192.168.1.2 1.2.3.4 root@tao[~]# ifconfig gif1 inet6 2abc::2 2abc::1 prefixlen 128 root@tao[~]# ping6 2abc::2 PING6(56=40+8+8 bytes) 2abc::2 --> 2abc::2 ^C --- 2abc::2 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss root@tao[~]# ifconfig gif1 10.1.1.1 10.1.1.2 root@tao[~]# ping 10.1.1.1 PING 10.1.1.1 (10.1.1.1): 56 data bytes 64 bytes from 10.1.1.1: icmp_seq=0 ttl=64 time=0.105 ms 64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=0.084 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=0.098 ms ^C --- 10.1.1.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.084/0.096/0.105/0.009 ms root@tao[~]# ifconfig gif1 destroy I'm running FreeBSD 8.2-RELEASE-p2. ipfw is compiled in the kernel however even if I flush all the rules so that it's just left with a default allow rule the same thing happens. And as I said before unless I'm being really blind and missed something obvious this config worked fine before my power outage! Here is my routing table for gif0: root@tao[~]# netstat -rn | grep gif0 default 2a01:348:6:45c::1 UGS gif0 2a01:348:6:45c::1 2a01:348:6:45c::2 UH gif0 fe80::%gif0/64 link#5 U gif0 fe80::240:63ff:fee8:793e%gif0 link#5 UHS lo0 ff01:5::/32 fe80::240:63ff:fee8:793e%gif0 U gif0 ff02::%gif0/32 fe80::240:63ff:fee8:793e%gif0 U gif0 And here are my firewall rules to prove it's flushed: root@tao[~]# ipfw list 65535 allow ip from any to any Thanks for any help or suggestions, Regards Matt. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 11:07:07 2011 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 4FBE31065672 for ; Mon, 26 Sep 2011 11:07:07 +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 3D8A88FC08 for ; Mon, 26 Sep 2011 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8QB77KE088218 for ; Mon, 26 Sep 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8QB76L9088216 for freebsd-net@FreeBSD.org; Mon, 26 Sep 2011 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Sep 2011 11:07:06 GMT Message-Id: <201109261107.p8QB76L9088216@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, 26 Sep 2011 11:07:07 -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 -------------------------------------------------------------------------------- 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/160420 net [msk] phy write timeout on HP 5310m 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/159795 net [tcp] excessive duplicate ACKs and TCP session freezes 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/159602 net [netinet] [patch] arp_ifscrub() is called even if IFF_ 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/157429 net [re] Realtek RTL8169 doesn't work with re(4) 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/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if 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/155004 net [bce] [panic] kernel panic in bce0 driver 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 o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u 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 bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. 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 o kern/144572 net [carp] CARP preemption mode traffic partially goes to 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 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/141023 net [carp] CARP arp replays with wrong src mac 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/138620 net [lagg] [patch] lagg port bpf-writes blocked 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 bin/136661 net [patch] ndp(8) ignores -f option 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 o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze 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/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us 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 o 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/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro 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/126714 net [carp] CARP interface renaming makes system no longer 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/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa 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 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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 kern/120130 net [carp] [panic] carp causes kernel panics in any conste 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/117448 net [carp] 6.2 kernel crash [regression] 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 s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if 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 s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress 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 o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 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 s 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 386 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 11:46:40 2011 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 36262106566C for ; Mon, 26 Sep 2011 11:46:40 +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 BB5C08FC16 for ; Mon, 26 Sep 2011 11:46:39 +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 7F93025D3891; Mon, 26 Sep 2011 11:46:38 +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 7DB1FBD3D40; Mon, 26 Sep 2011 11:46:37 +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 LYwfhIHcaVLt; Mon, 26 Sep 2011 11:46:36 +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 2D650BD3C30; Mon, 26 Sep 2011 11:46:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Mon, 26 Sep 2011 11:46:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <108C96DF-9011-4E38-8B0D-0ED6B46B2DE5@lists.zabbadoz.net> References: To: Matt Smith X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 11:46:40 -0000 On Sep 26, 2011, at 9:27 AM, Matt Smith wrote: > root@tao[~]# ifconfig gif0 > gif0: flags=3D8051 metric 0 mtu 1280 > tunnel inet 192.168.1.2 --> 77.75.104.126 Given you are using NAT make sure that works as expected for the gif from the remote end. It might be worth, if you can, do tcpdump on the external interface of your router. Also make sure you can reach the IPv4 tunnel destination.=20 You may consider using sixxs-aicu given the NAT.=20 > inet6 fe80::240:63ff:fee8:793e%gif0 prefixlen 64 scopeid 0x5 > inet6 2a01:348:6:45c::2 --> 2a01:348:6:45c::1 prefixlen 128 = deprecated = ^^^^^^^^^^ There's your problem most likely. What happens if you remove and re-add = the address like: ifconfig gif0 inet6 2a01:348:6:45c::2 -alias ifconfig gif0 inet6 -accept_rtadv ifconfig gif0 inet6 2a01:348:6:45c::2 2a01:348:6:45c::1 alias /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 12:17:06 2011 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 92F84106564A; Mon, 26 Sep 2011 12:17:06 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 271798FC14; Mon, 26 Sep 2011 12:17:06 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 05:17:05 -0700 From: Ben Hutchings To: Arnaud Lacombe Date: Mon, 26 Sep 2011 13:16:54 +0100 In-Reply-To: References: <20110924173120.GB71672@onelab2.iet.unipi.it> <78FA5152-123E-492C-9A05-E95C474DE469@lists.zabbadoz.net> <20110924205217.GA72397@onelab2.iet.unipi.it> <1316995431.4122.123.camel@deadeye> Organization: Solarflare Communications Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2- Content-Transfer-Encoding: 7bit Message-ID: <1317039416.4122.152.camel@deadeye> Mime-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 12:17:05.0706 (UTC) FILETIME=[347CF0A0:01CC7C46] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18408.005 X-TM-AS-Result: No--23.755800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Juli Mallett , "Bjoern A. Zeeb" , Luigi Rizzo , net@freebsd.org Subject: Re: which 10GE cards are supported by FreeBSD ? 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, 26 Sep 2011 12:17:06 -0000 On Sun, 2011-09-25 at 21:31 -0400, Arnaud Lacombe wrote: > Hi, > > On Sun, Sep 25, 2011 at 8:03 PM, Ben Hutchings > wrote: > > On Sat, 2011-09-24 at 13:56 -0700, Juli Mallett wrote: > >> On Sat, Sep 24, 2011 at 13:52, Luigi Rizzo wrote: > >> > apart from the typo ("know know") yes the email contained three > >> > serious questions, two of which (third party drivers and shops > >> > which carry the card) i cannot answer looking at the tree. > >> > > >> > On top of this, some in-tree drivers may be stale, broken, redundant > >> > (say ixgb vs ixgbe), and so on. And not all hardware can do line > >> > rate -- not even at 1G, let alone 10G, so it would be good to know > >> > also some first hand information on performance. > >> > >> ixgb vs. ixgbe is not a stale/redundant issue. ixgb only supports the > >> 82597, which you'll find is not supported by ixgbe. > >> > >> I think you'll have a hard time getting reliable performance > >> information. There's a lot of smoke and mirrors about performance, as > >> you point out. It has also been my experience that many 10g devices > >> cannot reliably do 1g line rate with minimal packet sizes. I don't > >> fully understand why this is, but most people who I've seen give > >> performance numbers for FreeBSD are looking at bulk transmit, which is > >> of course not (necessarily) what you care about for netmap. I've yet > >> to hear from anyone who can name a 10G NIC one can buy that can do > >> line rate with minimal packet sizes. Solarflare boasts about lower > >> latency, so perhaps they'll have a better story in that area. > > [...] > > > > Sorry, our current hardware can't move 64-byte frames at 10G line rate. > > I can check what the maximum packet rate is if you're interested. > > > If you refer to [0] and [1], it would seem that the Solarstorm SFC4000 > (B) supports 4e6 pps. That said, that is a number from 2008. The current SFC9020/SFL9021 products should be the same in this regard. > > We will have a FreeBSD driver out real soon now(TM), but most of my work > > on performance has gone into improving throughput. (The latency should > > be pretty good if you turn off interrupt moderation, though.) And > > really I think Onload is more useful than netmap, since it's compatible > > with existing source and binaries. > > > By "FreeBSD driver", do you mean just a driver for the card, or the > complete Onload stack ? AFAIS, it is currently Linux only. [...] It's a standard kernel net driver. Currently there is no work on Onload for FreeBSD. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 12:28:38 2011 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 377681065675 for ; Mon, 26 Sep 2011 12:28:38 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (xtaz.co.uk [87.194.206.163]) by mx1.freebsd.org (Postfix) with ESMTP id E55778FC0C for ; Mon, 26 Sep 2011 12:28:37 +0000 (UTC) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id 35869B075E9 for ; Mon, 26 Sep 2011 13:03:27 +0100 (BST) Received: by vws11 with SMTP id 11so7160186vws.13 for ; Mon, 26 Sep 2011 05:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.14 with SMTP id i14mr6398707vdf.84.1317038605558; Mon, 26 Sep 2011 05:03:25 -0700 (PDT) Received: by 10.52.167.194 with HTTP; Mon, 26 Sep 2011 05:03:25 -0700 (PDT) In-Reply-To: <108C96DF-9011-4E38-8B0D-0ED6B46B2DE5@lists.zabbadoz.net> References: <108C96DF-9011-4E38-8B0D-0ED6B46B2DE5@lists.zabbadoz.net> Date: Mon, 26 Sep 2011 13:03:25 +0100 Message-ID: From: Matt Smith To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 12:28:38 -0000 On 26 September 2011 12:46, Bjoern A. Zeeb wrote: > Given you are using NAT make sure that works as expected for the gif > from the remote end. =A0 It might be worth, if you can, do tcpdump on > the external interface of your router. > > Also make sure you can reach the IPv4 tunnel destination. I am using NAT yes however as I mentioned, this configuration has worked perfectly before for a good 6 months so I know it works OK usually. Unfortunately it's only a consumer ADSL router so I can't run tcpdump on it but I can reach the remote end: 64 bytes from 77.75.104.126: icmp_seq=3D0 ttl=3D59 time=3D20.521 ms The thing is even if the tunnel was down I should still be able to ping and use the IP on the local end of the tunnel. I've tested this on another FreeBSD box and even making up a fake tunnel using the same commands I mentioned in the previous email it works fine and I can ping abc::2 from it. On this box that doesn't work. > There's your problem most likely. =A0What happens if you remove and re-ad= d the address like: > ifconfig gif0 inet6 2a01:348:6:45c::2 -alias > ifconfig gif0 inet6 -accept_rtadv > ifconfig gif0 inet6 2a01:348:6:45c::2 2a01:348:6:45c::1 alias The deprecated thing I should have deleted actually before I posted the last email. I figured someone would pick up on that! I deprecate the interface so that it chooses another IP that I have on another interface as the IP to source outgoing traffic from. Again, usually this works fine. I have however tested removing that just in case and it made no difference. You can see the second example I made on the original email when I made a fake gif1 interface using 2abc:: root@tao[~]# ifconfig gif0 inet6 2a01:348:6:45c::2 -alias root@tao[~]# ifconfig gif0 inet6 -accept_rtadv root@tao[~]# ifconfig gif0 inet6 2a01:348:6:45c::2 2a01:348:6:45c::1 alias ifconfig: ioctl (SIOCAIFADDR): Invalid argument root@tao[~]# ifconfig gif0 inet6 2a01:348:6:45c::2 2a01:348:6:45c::1 prefixlen 128 root@tao[~]# ping6 2a01:348:6:45c::2 PING6(56=3D40+8+8 bytes) 2a01:348:6:45c::2 --> 2a01:348:6:45c::2 ^C --- 2a01:348:6:45c::2 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss root@tao[~]# ifconfig gif0 gif0: flags=3D8051 metric 0 mtu 1280 tunnel inet 192.168.1.2 --> 77.75.104.126 inet6 fe80::240:63ff:fee8:793e%gif0 prefixlen 64 scopeid 0x5 inet6 2a01:348:6:45c::2 --> 2a01:348:6:45c::1 prefixlen 128 nd6 options=3D1 options=3D1 From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 13:29:25 2011 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 2B08F1065674 for ; Mon, 26 Sep 2011 13:29:25 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id F20FC8FC08 for ; Mon, 26 Sep 2011 13:29:24 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R8BFL-000Dsp-Qq; Mon, 26 Sep 2011 09:29:23 -0400 Date: Mon, 26 Sep 2011 09:29:23 -0400 From: Gary Palmer To: Matt Smith Message-ID: <20110926132923.GB57708@in-addr.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 13:29:25 -0000 On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote: > I have a very strange problem with a gif interface that has been > confusing me all weekend. For the last six months I have had a gif > tunnel setup to an ipv6 tunnel broker which has worked without any > issues. On Friday I had a power cut. The power returned, the server > restarted, and the tunnel has been down since. I have checked and > rechecked the configuration and it all looks identical to what I would > expect. I've even gone as far as running a buildworld/kernel in case > the power outage corrupted something. > > The problem is that the gif interface doesn't appear to be processing > any IPv6 packets at all, though it works fine with IPv4. I can't ping > my side of the tunnel. For example: > > root@tao[~]# ifconfig gif0 > gif0: flags=8051 metric 0 mtu 1280 > tunnel inet 192.168.1.2 --> 77.75.104.126 > inet6 fe80::240:63ff:fee8:793e%gif0 prefixlen 64 scopeid 0x5 > inet6 2a01:348:6:45c::2 --> 2a01:348:6:45c::1 prefixlen 128 deprecated > nd6 options=3 > options=1 > > root@tao[~]# ping6 2a01:348:6:45c::2 > PING6(56=40+8+8 bytes) 2a01:348:6:45c::2 --> 2a01:348:6:45c::2 > > root@tao[~]# tcpdump -i gif0 > listening on gif0, link-type NULL (BSD loopback), capture size 96 bytes > 10:15:12.545930 IP6 cl-1117.lon-02.gb.sixxs.net > > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 0, length 16 > 10:15:13.546316 IP6 cl-1117.lon-02.gb.sixxs.net > > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 1, length 16 > 10:15:14.546220 IP6 cl-1117.lon-02.gb.sixxs.net > > cl-1117.lon-02.gb.sixxs.net: ICMP6, echo request, seq 2, length 16 > > I've deleted other lines from the tcpdump like neighbour solicitation > and only shown the pings. But there is no ping response, only the > request. Do you have access to any other IPv6 hosts on a separate link? If so, I would suggest trying a ping or traceroute back to your IP or IPs across the tunnel and see if the packets are getting back to you. It may be a problem at the other end somewhere. Check with tcpdump of both the IPv4 and IPv6 layers to see if the packets are getting to the kernel but not to the gif interface. Also see if your router is passing packets. If you had a power cut the router may have had some issues and may not be passing the protocol 41 packets. Also, check the sixxs.net docs to make sure you're allowing through necessary packets. I use tunnelbroker.net and they require (or say they do) some packets to get through for the tunnel to stay up, e.g. an IPv4 ping. Gary From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 13:49:53 2011 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 7A5C2106564A for ; Mon, 26 Sep 2011 13:49:53 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (xtaz.co.uk [87.194.206.163]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6738FC12 for ; Mon, 26 Sep 2011 13:49:52 +0000 (UTC) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id B757FB07612; Mon, 26 Sep 2011 14:49:18 +0100 (BST) Received: by vcbf13 with SMTP id f13so3921792vcb.13 for ; Mon, 26 Sep 2011 06:49:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.71.99 with SMTP id t3mr6526832vdu.17.1317044955490; Mon, 26 Sep 2011 06:49:15 -0700 (PDT) Received: by 10.52.167.194 with HTTP; Mon, 26 Sep 2011 06:49:15 -0700 (PDT) In-Reply-To: <20110926132923.GB57708@in-addr.com> References: <20110926132923.GB57708@in-addr.com> Date: Mon, 26 Sep 2011 14:49:15 +0100 Message-ID: From: Matt Smith To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 13:49:53 -0000 On 26 September 2011 14:29, Gary Palmer wrote: > On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote: > Do you have access to any other IPv6 hosts on a separate link? =A0If so, > I would suggest trying a ping or traceroute back to your IP or > IPs across the tunnel and see if the packets are getting back to you. > It may be a problem at the other end somewhere. =A0Check with tcpdump > of both the IPv4 and IPv6 layers to see if the packets are getting > to the kernel but not to the gif interface. =A0Also see if your router > is passing packets. =A0If you had a power cut the router may have had > some issues and may not be passing the protocol 41 packets. > > Also, check the sixxs.net docs to make sure you're allowing through > necessary packets. =A0I use tunnelbroker.net and they require (or say > they do) some packets to get through for the tunnel to stay up, e.g. > an IPv4 ping. > The router is configured to just send all incoming traffic to 192.168.1.2, DMZ mode. This includes all protocols. I then use ipfw on the server to firewall it, though even flushing all rules and completely opening the firewall it still doesn't work. I think you're missing the main issue I have here, which is that the local side doesn't work. If the local side doesn't work then the remote side is irrelevant right now. Point is try this on any FreeBSD box and it will work (I did this earlier today on a friends FreeBSD server to verify): ifconfig gif0 create ifconfig gif0 tunnel 1.2.3.4 ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128 ping6 2abc::2 ifconfig gif0 destroy With that config you should be able to talk locally to 2abc::2 because that's just a local IP on your box. The rest of the config or the state of the internet connection/NAT etc doesn't matter because you're talking to a non existent IP anyway. On my box this doesn't work since the power cut but worked perfectly well before. tcpdump of gif0 shows ping requests but no ping responses. It's as if all IPv6 traffic into gif0 is blackholed. However if I configure an IPv4 address on it with ifconfig gif0 10.1.1.2 10.1.1.1 then I can happily ping 10.1.1.2. So this just affects IPv6. It's a bizarre issue. I'm using exactly the same configuration that worked before the power cut. It's the kind of thing I might expect on a Windows box for something to randomly stop working but FreeBSD should just work! This is why I did a full buildworld/kernel thinking maybe a shared lib or something had become corrupt but to no avail. If there's no suggestions of something else which may have got screwed up I may have to resort to reinstalling the box with a fresh 9.0 install rather than a csup upgrade which would be a first! From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 13:50:52 2011 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 1A32A106566C for ; Mon, 26 Sep 2011 13:50:52 +0000 (UTC) (envelope-from yilinjing2006@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id EA2998FC18 for ; Mon, 26 Sep 2011 13:50:51 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R8Ba7-0000Fx-BK for freebsd-net@freebsd.org; Mon, 26 Sep 2011 06:50:51 -0700 Date: Mon, 26 Sep 2011 06:50:51 -0700 (PDT) From: jyl_2006 To: freebsd-net@freebsd.org Message-ID: <1317045051344-4841420.post@n5.nabble.com> In-Reply-To: References: <1316871818655-4836594.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: message from sctp getsockopt or sctp_opt_info show error 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, 26 Sep 2011 13:50:52 -0000 I use one wireless card to communicate with another computer,which also has one wireless card. Both two computer does not set any system parameters by using command sysctl . I use a tarball to test and record. In this tarball,computer A use sendmsg() to send a file, and computer B use recvmsg() to receive data from computer A. Both the computer enable subscribe.sctp_data_io_event = 1; subscribe.sctp_association_event = 1; When computer A get data from function recvmsg(), I call getsockopt to get status of association. I set sstat_assoc_id as the value given by sctp_notification, and sctp_opt_info's return value is 0, so I guess it work well. But the results shows the value does not correct. Second time,I use two computer,one computer run with Ubuntu, and the other computer run with FreeBSD 9.0 , in Ubuntu,the result is OK, but in Freebsd ,the result keep same value. So , does something we did wrong or steps I missed? -- View this message in context: http://freebsd.1045724.n5.nabble.com/message-from-sctp-getsockopt-or-sctp-opt-info-show-error-tp4836594p4841420.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 14:02:42 2011 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 D5A73106566B; Mon, 26 Sep 2011 14:02:42 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7368FC26; Mon, 26 Sep 2011 14:02:41 +0000 (UTC) Received: by wwe3 with SMTP id 3so6227636wwe.31 for ; Mon, 26 Sep 2011 07:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uafIC7gOQIvS1KfLe0jx6gTdpfmSGpRK0VM8P39Ad2k=; b=YDE0jxW3W+wZWkPuPQJg1azvrn0M/+GM9ltF3fsXC8puH32ApYeFyZP6YCEV3ImX57 1niu6/Wxt5syLicvcpAC/ufQqMe7kUwnvTfAb5FQSUbbq8y5gZq+QWWzq9ZI9ynsv1yT W/9sbCYh7eV7VCM9o58a+AlrCYcWVmelwbWPI= MIME-Version: 1.0 Received: by 10.227.175.77 with SMTP id w13mr5714316wbz.36.1317045760998; Mon, 26 Sep 2011 07:02:40 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Mon, 26 Sep 2011 07:02:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 10:02:40 -0400 Message-ID: From: Arnaud Lacombe To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Adrian Chadd , dave jones Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 26 Sep 2011 14:02:42 -0000 Hi, On Mon, Sep 26, 2011 at 5:12 AM, K. Macy wrote: > > > On Monday, September 26, 2011, Adrian Chadd wrote: >> On 26 September 2011 13:41, Arnaud Lacombe wrote: >>> =A0/* >>> =A0 * XXX >>> =A0 * This entire block sorely needs a rewrite. >>> =A0 */ >>> =A0 =A0 =A0 =A0if (t && >>> =A0 =A0 =A0 =A0 =A0 =A0((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && >>> =A0 =A0 =A0 =A0 =A0 =A0(so->so_type !=3D SOCK_STREAM || >>> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) &= & >>> =A0 =A0 =A0 =A0 =A0 =A0(ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || >>> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || >>> =A0 =A0 =A0 =A0 =A0 =A0 (t->inp_socket->so_options & >>> =A0 =A0 =A0 =A0 =A0 SO_REUSEPORT) =3D=3D 0) && >>> =A0 =A0 =A0 =A0 =A0 =A0(inp->inp_cred->cr_uid !=3D >>> =A0 =A0 =A0 =A0 =A0 =A0 t->inp_cred->cr_uid)) >>> =A0 =A0 =A0 =A0 =A0return (EADDRINUSE); >>> =A0 =A0 =A0} >>> >>> more specifically, `t->inp_socket' is NULL. The top comment may not be >>> relevant, as it's been here for the past 8 years. >> >> Why would t->inp_socket be NULL at this point? > > TIME_WAIT ... > on UDP socket ? - Arnaud From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 14:12:56 2011 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 BA3221065672; Mon, 26 Sep 2011 14:12:56 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 542868FC0A; Mon, 26 Sep 2011 14:12:56 +0000 (UTC) Received: by vws11 with SMTP id 11so7303353vws.13 for ; Mon, 26 Sep 2011 07:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/L2b+pWbz3EuCVgwva7VIXTWcq4uRNxA535XIyN+7q4=; b=w4/2fYJQsYz5eU7qJn53VaJls+fhV5camZva0XyjBE2BhNAUK/UU98AUvUP1a/yCd7 hhDtmw7onuFIo6uI8bC3u6USvfzvUIhjaDcaVCuWL4ZsmpwZAnZ1XH23WPKTiy0GGrR9 ylIQ3LV6sL1cS4732Yi7lOJlysb38xeMoFtLE= MIME-Version: 1.0 Received: by 10.52.23.2 with SMTP id i2mr6551657vdf.412.1317046375295; Mon, 26 Sep 2011 07:12:55 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.113.202 with HTTP; Mon, 26 Sep 2011 07:12:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 16:12:55 +0200 X-Google-Sender-Auth: 05uOTlnDyD3iwXMrVtnE1s0fSjA Message-ID: From: "K. Macy" To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Adrian Chadd , dave jones Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 26 Sep 2011 14:12:56 -0000 Sorry, didn't look at the images (limited bw), I've seen something like this before in timewait. This "can't happen" with UDP so will be interested in learning more about the bug. On Mon, Sep 26, 2011 at 4:02 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 26, 2011 at 5:12 AM, K. Macy wrote: >> >> >> On Monday, September 26, 2011, Adrian Chadd wrote: >>> On 26 September 2011 13:41, Arnaud Lacombe wrote: >>>> =A0/* >>>> =A0 * XXX >>>> =A0 * This entire block sorely needs a rewrite. >>>> =A0 */ >>>> =A0 =A0 =A0 =A0if (t && >>>> =A0 =A0 =A0 =A0 =A0 =A0((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && >>>> =A0 =A0 =A0 =A0 =A0 =A0(so->so_type !=3D SOCK_STREAM || >>>> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) = && >>>> =A0 =A0 =A0 =A0 =A0 =A0(ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || >>>> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || >>>> =A0 =A0 =A0 =A0 =A0 =A0 (t->inp_socket->so_options & >>>> =A0 =A0 =A0 =A0 =A0 SO_REUSEPORT) =3D=3D 0) && >>>> =A0 =A0 =A0 =A0 =A0 =A0(inp->inp_cred->cr_uid !=3D >>>> =A0 =A0 =A0 =A0 =A0 =A0 t->inp_cred->cr_uid)) >>>> =A0 =A0 =A0 =A0 =A0return (EADDRINUSE); >>>> =A0 =A0 =A0} >>>> >>>> more specifically, `t->inp_socket' is NULL. The top comment may not be >>>> relevant, as it's been here for the past 8 years. >>> >>> Why would t->inp_socket be NULL at this point? >> >> TIME_WAIT ... >> > on UDP socket ? > > =A0- Arnaud > From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 14:21:15 2011 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 B95A4106566C; Mon, 26 Sep 2011 14:21:15 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 89AA38FC0C; Mon, 26 Sep 2011 14:21:15 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R8C3X-000Dzv-0A; Mon, 26 Sep 2011 10:21:15 -0400 Date: Mon, 26 Sep 2011 10:21:14 -0400 From: Gary Palmer To: Matt Smith Message-ID: <20110926142114.GC57708@in-addr.com> References: <20110926132923.GB57708@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 14:21:15 -0000 On Mon, Sep 26, 2011 at 02:49:15PM +0100, Matt Smith wrote: > On 26 September 2011 14:29, Gary Palmer wrote: > > On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote: > > Do you have access to any other IPv6 hosts on a separate link? ?If so, > > I would suggest trying a ping or traceroute back to your IP or > > IPs across the tunnel and see if the packets are getting back to you. > > It may be a problem at the other end somewhere. ?Check with tcpdump > > of both the IPv4 and IPv6 layers to see if the packets are getting > > to the kernel but not to the gif interface. ?Also see if your router > > is passing packets. ?If you had a power cut the router may have had > > some issues and may not be passing the protocol 41 packets. > > > > Also, check the sixxs.net docs to make sure you're allowing through > > necessary packets. ?I use tunnelbroker.net and they require (or say > > they do) some packets to get through for the tunnel to stay up, e.g. > > an IPv4 ping. > > > > The router is configured to just send all incoming traffic to > 192.168.1.2, DMZ mode. This includes all protocols. I then use ipfw on > the server to firewall it, though even flushing all rules and > completely opening the firewall it still doesn't work. I think you're > missing the main issue I have here, which is that the local side > doesn't work. If the local side doesn't work then the remote side is > irrelevant right now. > > Point is try this on any FreeBSD box and it will work (I did this > earlier today on a friends FreeBSD server to verify): > > ifconfig gif0 create > ifconfig gif0 tunnel 1.2.3.4 > ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128 > ping6 2abc::2 > ifconfig gif0 destroy > > With that config you should be able to talk locally to 2abc::2 because > that's just a local IP on your box. The rest of the config or the > state of the internet connection/NAT etc doesn't matter because you're > talking to a non existent IP anyway. > > On my box this doesn't work since the power cut but worked perfectly > well before. tcpdump of gif0 shows ping requests but no ping > responses. It's as if all IPv6 traffic into gif0 is blackholed. > However if I configure an IPv4 address on it with ifconfig gif0 > 10.1.1.2 10.1.1.1 then I can happily ping 10.1.1.2. So this just > affects IPv6. Sorry, I missed that as I didn't look closely enough at the IP you were pinging and with DNS resolution left on in the tcpdump I just assumed that sixxs.net has a weird DNS setup. Smells like a routing table problem or similar configuration problem. On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings to the LOCAL endpoint of the gif0 tunnel go over lo0, not the external interface (gif0). I believe that is true for all IPv4 or IPv6 traffic. e.g. # ifconfig gif0 ifconfig: interface gif0 does not exist # ifconfig gif0 create # ifconfig gif0 tunnel 10.10.242.10 1.2.3.4 # ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128 # ping6 2abc::2 PING6(56=40+8+8 bytes) 2abc::2 --> 2abc::2 16 bytes from 2abc::2, icmp_seq=0 hlim=64 time=0.290 ms 16 bytes from 2abc::2, icmp_seq=1 hlim=64 time=0.183 ms ^C --- 2abc::2 ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.183/0.236/0.290/0.054 ms # ifconfig gif0 destroy In another window on the same host # tcpdump -n -p -i lo0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes 15:18:20.611469 IP6 2abc::2 > 2abc::2: ICMP6, echo request, seq 0, length 16 15:18:20.611524 IP6 2abc::2 > 2abc::2: ICMP6, echo reply, seq 0, length 16 15:18:21.611673 IP6 2abc::2 > 2abc::2: ICMP6, echo request, seq 1, length 16 15:18:21.611752 IP6 2abc::2 > 2abc::2: ICMP6, echo reply, seq 1, length 16 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel Regards, Gary From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 14:23:47 2011 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 0EE05106564A for ; Mon, 26 Sep 2011 14:23:47 +0000 (UTC) (envelope-from yilinjing2006@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id DF0F18FC17 for ; Mon, 26 Sep 2011 14:23:46 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R8C5y-0003fH-Ex for freebsd-net@freebsd.org; Mon, 26 Sep 2011 07:23:46 -0700 Date: Mon, 26 Sep 2011 07:23:46 -0700 (PDT) From: jyl_2006 To: freebsd-net@freebsd.org Message-ID: <1317047026455-4841537.post@n5.nabble.com> In-Reply-To: References: <1316871818655-4836594.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: message from sctp getsockopt or sctp_opt_info show error 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, 26 Sep 2011 14:23:47 -0000 OK ,In Ubuntu, I use getsockopt to get sctp_status with lksctp tarball, the result show me that only sender get the correct value about cwnd , the receive's cwnd keep the same value. Second time, I use Ubuntu as sender and use FreeBSD 9.0 as receiver, and I does not set any system parameters by using command sysctl. Both the receiver and sender set subscribe.sctp_data_io_event = 1; subscribe.sctp_association_event = 1; The result same with the first time. So , does something I did wrong or steps I missed? -- View this message in context: http://freebsd.1045724.n5.nabble.com/message-from-sctp-getsockopt-or-sctp-opt-info-show-error-tp4836594p4841537.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 15:04:38 2011 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 2FD41106566B; Mon, 26 Sep 2011 15:04:38 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (xtaz.co.uk [87.194.206.163]) by mx1.freebsd.org (Postfix) with ESMTP id B1FB78FC13; Mon, 26 Sep 2011 15:04:37 +0000 (UTC) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id EC90EB07647; Mon, 26 Sep 2011 16:04:04 +0100 (BST) Received: by vws11 with SMTP id 11so7369218vws.13 for ; Mon, 26 Sep 2011 08:04:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.102 with SMTP id hb6mr6261071vdb.419.1317049440268; Mon, 26 Sep 2011 08:04:00 -0700 (PDT) Received: by 10.52.167.194 with HTTP; Mon, 26 Sep 2011 08:04:00 -0700 (PDT) In-Reply-To: <20110926142114.GC57708@in-addr.com> References: <20110926132923.GB57708@in-addr.com> <20110926142114.GC57708@in-addr.com> Date: Mon, 26 Sep 2011 16:04:00 +0100 Message-ID: From: Matt Smith To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 15:04:38 -0000 On 26 September 2011 15:21, Gary Palmer wrote: > Smells like a routing table problem or similar configuration problem. > On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings > to the LOCAL endpoint of the gif0 tunnel go over lo0, not the external > interface (gif0). =A0I believe that is true for all IPv4 or IPv6 traffic. Interesting. You could be right then. But I still don't understand what could have changed as the rc.conf configuration for this is identical to what it was before the power cut. The deprecated part just makes the outgoing source address algorithm favour the vr0 address, but the same happens no matter if I include that or not. ipv6_enable=3D"YES" ipv6_ifconfig_vr0=3D"2a01:348:294::1 prefixlen 64" gif_interfaces=3D"gif0" gifconfig_gif0=3D"192.168.1.2 77.75.104.126" ipv6_ifconfig_gif0=3D"2a01:348:6:45c::2 2a01:348:6:45c::1 prefixlen 128 deprecated" ipv6_defaultrouter=3D"2a01:348:6:45c::1" ipv6_gateway_enable=3D"YES" rtadvd_enable=3D"YES" rtadvd_interfaces=3D"vr0" Which produces: vr0: flags=3D8843 metric 0 mtu 1500 options=3D82808 ether 00:40:63:e8:79:3e inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::240:63ff:fee8:793e%vr0 prefixlen 64 scopeid 0x1 inet6 2a01:348:294::1 prefixlen 64 nd6 options=3D3 media: Ethernet autoselect (100baseTX ) status: active gif0: flags=3D8051 metric 0 mtu 1280 tunnel inet 192.168.1.2 --> 77.75.104.126 inet6 fe80::240:63ff:fee8:793e%gif0 prefixlen 64 scopeid 0x5 inet6 2a01:348:6:45c::2 --> 2a01:348:6:45c::1 prefixlen 128 depreca= ted nd6 options=3D3 options=3D1 Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 =3D> default 2a01:348:6:45c::1 UGS = gif0 ::1 ::1 UH = lo0 ::ffff:0.0.0.0/96 ::1 UGRS = lo0 2a01:348:6:45c::1 2a01:348:6:45c::2 UH = gif0 2a01:348:294::/64 link#1 U = vr0 2a01:348:294::1 link#1 UHS = lo0 The interesting thing is I've just got the routing table from my friends working server with similar configuration except his is just a tunnel without any subnet and his has this: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 =3D> default 2a01:348:6:45d::1 UGS = gif0 ::1 ::1 UHL = lo0 ::ffff:0.0.0.0/96 ::1 UGRS = lo0 2a01:348:6:45d::1 link#3 UHL = gif0 2a01:348:6:45d::2 link#3 UHL = lo0 I'm wondering why there are clearly significant differences here. If my configuration didn't work before then I can accept that I've screwed up in some way but it's worked for months so I don't understand what's changed now. Unfortunately I don't know what my routing table looked like originally when it worked but I'm thinking for some reason when the box boots it's building the routing table differently to how it was before now? From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 16:05:28 2011 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 B016D106564A for ; Mon, 26 Sep 2011 16:05:28 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 804858FC0C for ; Mon, 26 Sep 2011 16:05:28 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R8DgN-000E8A-5E; Mon, 26 Sep 2011 12:05:27 -0400 Date: Mon, 26 Sep 2011 12:05:27 -0400 From: Gary Palmer To: Matt Smith Message-ID: <20110926160527.GD57708@in-addr.com> References: <20110926132923.GB57708@in-addr.com> <20110926142114.GC57708@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 16:05:28 -0000 On Mon, Sep 26, 2011 at 04:04:00PM +0100, Matt Smith wrote: > On 26 September 2011 15:21, Gary Palmer wrote: > > Smells like a routing table problem or similar configuration problem. > > On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings > > to the LOCAL endpoint of the gif0 tunnel go over lo0, not the external > > interface (gif0). ?I believe that is true for all IPv4 or IPv6 traffic. > > Interesting. You could be right then. But I still don't understand > what could have changed as the rc.conf configuration for this is > identical to what it was before the power cut. The deprecated part > just makes the outgoing source address algorithm favour the vr0 > address, but the same happens no matter if I include that or not. Not sure, however an experiment may be in order # ifconfig gif0 ifconfig: interface gif0 does not exist # ifconfig gif0 create # ifconfig gif0 tunnel 1.2.3.4 # ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128 # netstat -nr -f inet6 | grep 2abc 2abc::1 link#8 UHL gif0 2abc::2 link#8 UHL lo0 # ifconfig gif0 destroy See if your routing table is correct after the test you proposed earlier. Gary From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 16:17:04 2011 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 423A71065670; Mon, 26 Sep 2011 16:17:04 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (xtaz.co.uk [87.194.206.163]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE5E8FC14; Mon, 26 Sep 2011 16:17:03 +0000 (UTC) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id A668BB07733; Mon, 26 Sep 2011 17:17:01 +0100 (BST) Received: by vws11 with SMTP id 11so7460537vws.13 for ; Mon, 26 Sep 2011 09:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.91.97 with SMTP id cd1mr6142317vdb.218.1317053819507; Mon, 26 Sep 2011 09:16:59 -0700 (PDT) Received: by 10.52.167.194 with HTTP; Mon, 26 Sep 2011 09:16:59 -0700 (PDT) In-Reply-To: <20110926160527.GD57708@in-addr.com> References: <20110926132923.GB57708@in-addr.com> <20110926142114.GC57708@in-addr.com> <20110926160527.GD57708@in-addr.com> Date: Mon, 26 Sep 2011 17:16:59 +0100 Message-ID: From: Matt Smith To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 16:17:04 -0000 On 26 September 2011 17:05, Gary Palmer wrote: > > Not sure, however an experiment may be in order > > # ifconfig gif0 > ifconfig: interface gif0 does not exist > # ifconfig gif0 create > # ifconfig gif0 tunnel 1.2.3.4 > # ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128 > # netstat -nr -f inet6 | grep 2abc > 2abc::1 link#8 UHL > gif0 > 2abc::2 link#8 UHL > lo0 > # ifconfig gif0 destroy > > See if your routing table is correct after the test you proposed earlier. > > Here we go: root@tao[~]# ifconfig vr0 inet6 2a01:348:294::1 prefixlen 64 -alias root@tao[~]# ifconfig gif0 destroy root@tao[~]# ifconfig gif0 ifconfig: interface gif0 does not exist Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 (deleted fe80, ff01, ff02 to save space) root@tao[~]# ifconfig gif0 create root@tao[~]# ifconfig gif0 tunnel 192.168.1.2 1.2.3.4 root@tao[~]# ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128 root@tao[~]# netstat -nr -f inet6 | grep 2abc 2abc::1 2abc::2 UH gif0 ff01:5::/32 2abc::2 U gif0 ff02::%gif0/32 2abc::2 U gif0 root@tao[~]# ping6 2abc::2 ping6: UDP connect: No route to host You see why I'm exceptionally confused now?! From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 17:18:09 2011 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 78240106566C for ; Mon, 26 Sep 2011 17:18:09 +0000 (UTC) (envelope-from miwi.freebsd@googlemail.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 30FD68FC0C for ; Mon, 26 Sep 2011 17:18:08 +0000 (UTC) Received: by yxk36 with SMTP id 36so5704422yxk.13 for ; Mon, 26 Sep 2011 10:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=zmolg1xlZ8ICOVkhxLDW0S4Cv9/cZcdsj7iUpqcSxJk=; b=Q2fKK8uHwzaEZVp6EGY8QuU+U/REEOWK0ViYzNOzlQiUFqoNWLYU6v0SKOj5NgLci8 1u87KV/I1T5PhRCuxS6+SSLKwOwMJkv4kKsFlwEGR8Yjx2SXiGYFJ83YoAE1ADPkjf9j RDOT4d0w+xxW6MM8qpAthfK6gWg8xoCDkXYa0= Received: by 10.68.29.73 with SMTP id i9mr30658313pbh.12.1317055996248; Mon, 26 Sep 2011 09:53:16 -0700 (PDT) Received: from [192.168.0.103] ([175.142.212.145]) by mx.google.com with ESMTPS id q10sm74904850pbn.9.2011.09.26.09.53.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 09:53:14 -0700 (PDT) Sender: Martin Wilke Mime-Version: 1.0 (Apple Message framework v1251) Content-Type: multipart/signed; boundary="Apple-Mail=_7C9755A7-3719-4886-B5FC-ADC91485CFB9"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Martin Wilke In-Reply-To: <1317017255.2706.5.camel@jshupe-2530p.osre.org> Date: Tue, 27 Sep 2011 00:53:09 +0800 Message-Id: References: <1317017255.2706.5.camel@jshupe-2530p.osre.org> To: James Shupe X-Mailer: Apple Mail (2.1251) Cc: freebsd-net@freebsd.org Subject: Re: Data centers failure proof with CARP. 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, 26 Sep 2011 17:18:09 -0000 --Apple-Mail=_7C9755A7-3719-4886-B5FC-ADC91485CFB9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Any other Idea what we can do to get a failover between both servers? On Sep 26, 2011, at 2:07 PM, James Shupe wrote: > z.z.z.z would have to be an anycast address announced by both > datacenters, so your idea is unlikely to work. > > -- > James Shupe, OSRE > founder/ developer/ engineer > jshupe@osre.org | 866.235.1288 > BSD/ Linux Support | Metro Ethernet | Hosting > check out our site at www.osre.org --Apple-Mail=_7C9755A7-3719-4886-B5FC-ADC91485CFB9 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk6ArfYACgkQdLJIhLHm/OkHRwCeMVZQ503zL52rkXe2r3AJhTzU dHIAoJLEYIjhMD5aAJRG2Crz8DGeF0W7 =eM3P -----END PGP SIGNATURE----- --Apple-Mail=_7C9755A7-3719-4886-B5FC-ADC91485CFB9-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 19:29:43 2011 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 1E342106564A; Mon, 26 Sep 2011 19:29:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 049588FC08; Mon, 26 Sep 2011 19:29:42 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LS5002GI7CU9Z00@asmtp026.mac.com>; Mon, 26 Sep 2011 11:29:19 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-09-26_07:2011-09-26, 2011-09-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1109260206 From: Chuck Swiger In-reply-to: Date: Mon, 26 Sep 2011 11:29:17 -0700 Message-id: <69A27071-39FF-4AFA-8E06-05ECA1E8DD2C@mac.com> References: <1317017255.2706.5.camel@jshupe-2530p.osre.org> To: Martin Wilke , James Shupe X-Mailer: Apple Mail (2.1084) Cc: freebsd-net Net Subject: Re: Data centers failure proof with CARP. 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, 26 Sep 2011 19:29:43 -0000 Hi-- On Sep 26, 2011, at 9:53 AM, Martin Wilke wrote: > Any other Idea what we can do to get a failover between both servers? Multi datacenter failover is *hard*. You have to evaluate which parts are static systems-- ie, display the same web images from all DCs, provide a current UTC timestamp from NTP, or whatever-- and which parts are transactional: ie, people's email, or placing orders on an online store, etc. Failover of static systems is relatively easier, as they don't need to change from one DC to another, and you can just use short DNS TTLs or outsource to a content distribution network like the various CDN / cloud providers (Akamai, Amazon, Level3, Azure, whatever). Failover of the transactional portion requires extensive effort to understand the transactional model-- are you active/standby, with write-through to the primary and cacheable read-back elsewhere, with a planned transition in the event of failure of the active to promote a standby to active; or are multiple DCs active with some form of load-balancing in place to distribute transactions (geolocation by client IP towards closer DCs, perhaps), etc. And you also have to consider what happens after a failure, and how you reintegrate DCs once a failure is resolved and reassemble your transactional data to be coherent. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 19:50:06 2011 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 C443D1065670 for ; Mon, 26 Sep 2011 19:50:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A25A8FC0A for ; Mon, 26 Sep 2011 19:50:06 +0000 (UTC) Received: by vcbf13 with SMTP id f13so4343338vcb.13 for ; Mon, 26 Sep 2011 12:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vG8uOPi4/46mBcC6WK1Yl3XtpDJc25NVUbSYLL5WZ9E=; b=IJ1ezb7raB+qZHOdhs89jDEFWLlJt/lBpDDsZrEhr/WDvT+Q8wiIkey/2RvGK5Uhwb MMzpsYC5DSuO5pmxiIf1ZAPs5jC3BT2cUEQdgQ5YOAALTzuPgnvhBn1ZRV2BhrTZ1yo/ MeYQv0P8rjrckXk1WM0qf0YBqYMl3yTJ3QHg8= MIME-Version: 1.0 Received: by 10.52.29.103 with SMTP id j7mr6705921vdh.235.1317064820533; Mon, 26 Sep 2011 12:20:20 -0700 (PDT) Received: by 10.220.198.130 with HTTP; Mon, 26 Sep 2011 12:20:20 -0700 (PDT) In-Reply-To: <4E7B450F.5050802@wp.pl> References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> Date: Mon, 26 Sep 2011 12:20:20 -0700 Message-ID: From: Freddie Cash To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 26 Sep 2011 19:50:06 -0000 On Thu, Sep 22, 2011 at 7:24 AM, Marek Salwerowicz wrote: > W dniu 2011-08-10 16:22, Freddie Cash pisze: > > >> The more correct method is to double-NAT the traffic, such >> that the LAN >> clients connect to public IPs, and the DMZ servers see >> connections from >> public IPs. It's more complicated to wrap your head around >> the first time, >> but it prevents private IPs from "leaking" between the LAN, >> the Internet, >> and the DMZ. (It took me 10 years of using IPFW to figure >> this one out.) >> >> # Configure the general natd process for the LAN >> natd -port $port2 -same_ports -use_sockets -alias_address >> x.x.x.171 >> >> # Configure the natd process to NAT from x.x.x.170 to >> 192.168.0.10 using >> some port >> natd -port $port1 -same_ports -use_sockets -alias_address >> x.x.x.170 >> -redirect_address x.x.x.170 192.168.0.10 >> >> # NAT the traffic coming from the LAN to x.x.x.170 >> ipfw add divert $port1 ip from $LAN to x.x.x.170 in recv vr0 >> ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0 >> >> # NAT the traffic going to x.x.x.170 from the LAN >> ipfw add divert $port2 ip from $LAN to 192.168.0.10 out xmit vr2 >> ipfw add allow ip from x.x.x.171 to 192.168.0.10 out xmit vr2 >> >> # NAT the traffic coming from x.x.x.170 to the LAN >> ipfw add divert $port1 ip from 192.168.0.10 to x.x.x.171 in >> recv vr2 >> ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2 >> >> # NAT the traffic going to the LAN from x.x.x.170 >> ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0 >> ipfw add allow ip from x.x.x.170 t0 $LAN out xmit vr0 >> >> The general flow of the rules above is (src --> dest) >> 10.0.0.x --> x.x.x.170 >> 10.0.0.x --> 192.168.0.10 (after first NAT) >> x.x.x.171 --> 192.168.0.10 (after second NAT) >> >> 192.168.0.10 --> x.x.x.171 >> 192.168.0.10 --> 10.0.0.x (after first NAT) >> x.x.x.170 --> 10.0.0.x (after second NAT) >> >> Notice how vr3 is never used in any of the rules above, as the >> packets never >> touch the public interface of the router. >> >> >> > Hi, > > I set up firewall like this: > > Your rules are too generic, they will not work for a double-NAT setup. Each and every single rule must specify the network interface. And it must specify whether it's incoming (in recv) or outgoing (out xmit) traffic. Don't use "via" anywhere. While it's easier to use generic rules to start with, you really need to get very specific, at least for the double-NAT setup. See my example above. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 20:05:07 2011 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 076B71065674 for ; Mon, 26 Sep 2011 20:05:07 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id AAD1C8FC24 for ; Mon, 26 Sep 2011 20:05:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R8HQH-00044m-UO for freebsd-net@freebsd.org; Mon, 26 Sep 2011 22:05:05 +0200 Received: from ip244.gte215.dsl-acs2.sea.iinet.com ([209.20.215.244]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Sep 2011 22:05:05 +0200 Received: from atkin901 by ip244.gte215.dsl-acs2.sea.iinet.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Sep 2011 22:05:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Mark Atkinson Date: Mon, 26 Sep 2011 13:00:38 -0700 Lines: 33 Message-ID: References: <20110926132923.GB57708@in-addr.com> <20110926142114.GC57708@in-addr.com> <20110926160527.GD57708@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip244.gte215.dsl-acs2.sea.iinet.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 In-Reply-To: Subject: Re: gif interface not passing IPv6 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: Mon, 26 Sep 2011 20:05:07 -0000 > root@tao[~]# ifconfig vr0 inet6 2a01:348:294::1 prefixlen 64 -alias > root@tao[~]# ifconfig gif0 destroy > root@tao[~]# ifconfig gif0 > ifconfig: interface gif0 does not exist > Internet6: > Destination Gateway Flags > Netif Expire > ::/96 ::1 UGRS > lo0 > ::1 ::1 UH > lo0 > ::ffff:0.0.0.0/96 ::1 UGRS > lo0 > (deleted fe80, ff01, ff02 to save space) > root@tao[~]# ifconfig gif0 create > root@tao[~]# ifconfig gif0 tunnel 192.168.1.2 1.2.3.4 > root@tao[~]# ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128 > root@tao[~]# netstat -nr -f inet6 | grep 2abc > 2abc::1 2abc::2 UH > gif0 > ff01:5::/32 2abc::2 U > gif0 > ff02::%gif0/32 2abc::2 U > gif0 > root@tao[~]# ping6 2abc::2 > ping6: UDP connect: No route to host > > You see why I'm exceptionally confused now?! Depending on your release you might need to add ifconfig gif0 inet6 -ifdisabled From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 20:49:32 2011 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 EE334106564A for ; Mon, 26 Sep 2011 20:49:32 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 5FCD28FC19 for ; Mon, 26 Sep 2011 20:49:32 +0000 (UTC) Received: from [192.168.1.100] (p508FC2D3.dip.t-dialin.net [80.143.194.211]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7D81B1C0C0BD6; Mon, 26 Sep 2011 22:49:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <1317047026455-4841537.post@n5.nabble.com> Date: Mon, 26 Sep 2011 22:49:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55A19C31-EB84-47B8-B06F-8799F1C160FC@lurchi.franken.de> References: <1316871818655-4836594.post@n5.nabble.com> <1317047026455-4841537.post@n5.nabble.com> To: jyl_2006 X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: message from sctp getsockopt or sctp_opt_info show error 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, 26 Sep 2011 20:49:33 -0000 On Sep 26, 2011, at 4:23 PM, jyl_2006 wrote: > OK ,In Ubuntu, I use getsockopt to get sctp_status with lksctp = tarball, the > result show me that only sender get the correct value about cwnd , the > receive's cwnd keep the same value. cwnd does not change when you don't send anything. Also, cwnd is a local variable only available at the sender side. It is not put on the wire. >=20 > Second time, I use Ubuntu as sender and use FreeBSD 9.0 as receiver, = and I=20 > does not set any system parameters by using command sysctl. >=20 > Both the receiver and sender set > subscribe.sctp_data_io_event =3D 1;=20 > subscribe.sctp_association_event =3D 1;=20 >=20 > The result same with the first time. >=20 > So , does something I did wrong or steps I missed? I'm having a hard time to understand: * What you are observing * What you are expecting * What is the difference between the observed and the expected results. Please be very specific on the three points. Best regards Michael >=20 > -- > View this message in context: = http://freebsd.1045724.n5.nabble.com/message-from-sctp-getsockopt-or-sctp-= opt-info-show-error-tp4836594p4841537.html > Sent from the freebsd-net mailing list archive at Nabble.com. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Mon Sep 26 23:22:01 2011 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 C81E31065670; Mon, 26 Sep 2011 23:22:01 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A0BD88FC14; Mon, 26 Sep 2011 23:22:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8QNM1tU070714; Mon, 26 Sep 2011 23:22:01 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8QNM1Xn070710; Mon, 26 Sep 2011 23:22:01 GMT (envelope-from eadler) Date: Mon, 26 Sep 2011 23:22:01 GMT Message-Id: <201109262322.p8QNM1Xn070710@freefall.freebsd.org> To: lacombar@gmail.com, eadler@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/160873: [igb] igb(4) from HEAD fails to build on 7-STABLE 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, 26 Sep 2011 23:22:01 -0000 Synopsis: [igb] igb(4) from HEAD fails to build on 7-STABLE State-Changed-From-To: open->closed State-Changed-By: eadler State-Changed-When: Mon Sep 26 23:22:01 UTC 2011 State-Changed-Why: fix has been committed ? http://www.freebsd.org/cgi/query-pr.cgi?pr=160873 From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 00:51:55 2011 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 6B86C1065673 for ; Tue, 27 Sep 2011 00:51:55 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 24D5E8FC14 for ; Tue, 27 Sep 2011 00:51:54 +0000 (UTC) Received: by vcbf13 with SMTP id f13so4589738vcb.13 for ; Mon, 26 Sep 2011 17:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BxvcOsZ/lFPV/Im60Hln8gZM5B1oWblB2n1TMZ5cm3k=; b=CmW8VlaEpIi0hrYDZ1xTBwMFbYJtJLyxppFGKxuktvPktquE6sINLhsuc2AqaOtYvT 6/ywFQsD7iTu8yhlgklPbd2cjGzfLfnOz6kEsrSwy+Rp4hCsOvFMXvpkuxtrQb7CTK0C qFa3WvvJIIQBvJlw3mwwFhb0/8kFyjm3/PIx8= MIME-Version: 1.0 Received: by 10.52.95.244 with SMTP id dn20mr6509781vdb.452.1317084714032; Mon, 26 Sep 2011 17:51:54 -0700 (PDT) Received: by 10.52.107.194 with HTTP; Mon, 26 Sep 2011 17:51:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Sep 2011 08:51:53 +0800 Message-ID: From: dave jones To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 27 Sep 2011 00:51:55 -0000 On Mon, Sep 26, 2011 at 1:41 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 26, 2011 at 1:12 AM, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Sep 26, 2011 at 12:43 AM, dave jones wrote: >>> Hi, >>> I have two production machines running on freebsd 9.0-beta2 and both go= t >>> kernel panic related to networking. Any idea how to solve it? thanks. >>> >>> http://http://60.248.161.9/p1.jpg >>> http://http://60.248.161.9/p2.jpg >>> >> this host is really slow :-) >> >> To avoid the waiting time, the backtrace is: >> >> in_pcbbind_setup()+0x28f >> in_pcbbind()+0xa9 >> udp_bind() >> bind() >> kern_bind() >> syscall_enter() >> syscall() >> >> faulted at VA 0x07. Origin process in named. >> > AFAICT, the crash happens in the following block: > > =A0/* > =A0 * XXX > =A0 * This entire block sorely needs a rewrite. > =A0 */ > =A0 =A0 =A0 =A0if (t && > =A0 =A0 =A0 =A0 =A0 =A0((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && > =A0 =A0 =A0 =A0 =A0 =A0(so->so_type !=3D SOCK_STREAM || > =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) && > =A0 =A0 =A0 =A0 =A0 =A0(ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || > =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || > =A0 =A0 =A0 =A0 =A0 =A0 (t->inp_socket->so_options & > =A0 =A0 =A0 =A0 =A0 SO_REUSEPORT) =3D=3D 0) && > =A0 =A0 =A0 =A0 =A0 =A0(inp->inp_cred->cr_uid !=3D > =A0 =A0 =A0 =A0 =A0 =A0 t->inp_cred->cr_uid)) > =A0 =A0 =A0 =A0 =A0return (EADDRINUSE); > =A0 =A0 =A0} > > more specifically, `t->inp_socket' is NULL. The top comment may not be > relevant, as it's been here for the past 8 years. Hi Arnaud, Ah, thanks for the info. I'm wondering if you have a patch to fix that issu= e? Guess what? another production machine got the same panic, oh my~ Is FreeBSD 9 really stable? > =A0- Arnaud BR, Dave. From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 01:19:37 2011 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 B89A8106566B; Tue, 27 Sep 2011 01:19:37 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E61758FC1D; Tue, 27 Sep 2011 01:19:36 +0000 (UTC) Received: by wyj26 with SMTP id 26so4674629wyj.13 for ; Mon, 26 Sep 2011 18:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uhSXWMNuQuLQNMkvVNnen+ykKzDLE0kxMr3hawco9Rk=; b=IzCqyr3bB0hs4WL2LumbnYwupblM6Xr38nKlsAOOdPMLOGs2aMKPXiBx4MoKXMxjF9 pRntKMKweylXZujf58h+2I8j8JIiTGOmmzwr9sD0BlQ2KOdVcA4FGI2ZDsmdWtD28Ool +bbzvyIxtG6JCqutXpvSxtGt7s/VlqpngMOo4= MIME-Version: 1.0 Received: by 10.227.36.229 with SMTP id u37mr6721865wbd.21.1317086375922; Mon, 26 Sep 2011 18:19:35 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Mon, 26 Sep 2011 18:19:35 -0700 (PDT) In-Reply-To: <201109262322.p8QNM1Xn070710@freefall.freebsd.org> References: <201109262322.p8QNM1Xn070710@freefall.freebsd.org> Date: Mon, 26 Sep 2011 21:19:35 -0400 Message-ID: From: Arnaud Lacombe To: eadler@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern/160873: [igb] igb(4) from HEAD fails to build on 7-STABLE 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, 27 Sep 2011 01:19:37 -0000 Hi, On Mon, Sep 26, 2011 at 7:22 PM, wrote: > Synopsis: [igb] igb(4) from HEAD fails to build on 7-STABLE > > State-Changed-From-To: open->closed > State-Changed-By: eadler > State-Changed-When: Mon Sep 26 23:22:01 UTC 2011 > State-Changed-Why: > fix has been committed ? > No. Please re-open, and please, do not close the issue by asking a question and not waiting for the answer. Thanks, - Arnaud > http://www.freebsd.org/cgi/query-pr.cgi?pr=160873 > From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 01:21:15 2011 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 636E91065670; Tue, 27 Sep 2011 01:21:15 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1678FC0A; Tue, 27 Sep 2011 01:21:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8R1LF30083491; Tue, 27 Sep 2011 01:21:15 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8R1LFJV083477; Tue, 27 Sep 2011 01:21:15 GMT (envelope-from eadler) Date: Tue, 27 Sep 2011 01:21:15 GMT Message-Id: <201109270121.p8R1LFJV083477@freefall.freebsd.org> To: lacombar@gmail.com, eadler@FreeBSD.org, freebsd-net@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: kern/160873: [igb] igb(4) from HEAD fails to build on 7-STABLE 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, 27 Sep 2011 01:21:15 -0000 Synopsis: [igb] igb(4) from HEAD fails to build on 7-STABLE State-Changed-From-To: closed->open State-Changed-By: eadler State-Changed-When: Tue Sep 27 01:21:14 UTC 2011 State-Changed-Why: woops, I meant -f not -c, sorry http://www.freebsd.org/cgi/query-pr.cgi?pr=160873 From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 01:24:39 2011 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 5D641106566B for ; Tue, 27 Sep 2011 01:24:39 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E58318FC13 for ; Tue, 27 Sep 2011 01:24:36 +0000 (UTC) Received: by wyj26 with SMTP id 26so4679798wyj.13 for ; Mon, 26 Sep 2011 18:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=U77IhGBCDQ78Zgcs1vR0RqOG32hC9R3hPmHQzIuy59M=; b=NB28YzY5gCIJzO+b/2ePdIzbLeRv/4blcRvTFHK/gkVFm/XacDBrXozcJt5uyj5l8D RCPz/5Gxs0m71igZnt3q+vVfyl5F3XGArLdbkzp3zGDTh8hF2rxXNE+X6XXna95yQ7Xz ufjpp44JTFMESDdl+lHD9Z3tef0xNNkZTfcps= MIME-Version: 1.0 Received: by 10.227.36.229 with SMTP id u37mr6726819wbd.21.1317086675354; Mon, 26 Sep 2011 18:24:35 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Mon, 26 Sep 2011 18:24:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 21:24:35 -0400 Message-ID: From: Arnaud Lacombe To: dave jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 27 Sep 2011 01:24:39 -0000 Hi, On Mon, Sep 26, 2011 at 8:51 PM, dave jones wrote: > On Mon, Sep 26, 2011 at 1:41 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Sep 26, 2011 at 1:12 AM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Mon, Sep 26, 2011 at 12:43 AM, dave jones wrote: >>>> Hi, >>>> I have two production machines running on freebsd 9.0-beta2 and both g= ot >>>> kernel panic related to networking. Any idea how to solve it? thanks. >>>> >>>> http://http://60.248.161.9/p1.jpg >>>> http://http://60.248.161.9/p2.jpg >>>> >>> this host is really slow :-) >>> >>> To avoid the waiting time, the backtrace is: >>> >>> in_pcbbind_setup()+0x28f >>> in_pcbbind()+0xa9 >>> udp_bind() >>> bind() >>> kern_bind() >>> syscall_enter() >>> syscall() >>> >>> faulted at VA 0x07. Origin process in named. >>> >> AFAICT, the crash happens in the following block: >> >> =A0/* >> =A0 * XXX >> =A0 * This entire block sorely needs a rewrite. >> =A0 */ >> =A0 =A0 =A0 =A0if (t && >> =A0 =A0 =A0 =A0 =A0 =A0((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && >> =A0 =A0 =A0 =A0 =A0 =A0(so->so_type !=3D SOCK_STREAM || >> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) && >> =A0 =A0 =A0 =A0 =A0 =A0(ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || >> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || >> =A0 =A0 =A0 =A0 =A0 =A0 (t->inp_socket->so_options & >> =A0 =A0 =A0 =A0 =A0 SO_REUSEPORT) =3D=3D 0) && >> =A0 =A0 =A0 =A0 =A0 =A0(inp->inp_cred->cr_uid !=3D >> =A0 =A0 =A0 =A0 =A0 =A0 t->inp_cred->cr_uid)) >> =A0 =A0 =A0 =A0 =A0return (EADDRINUSE); >> =A0 =A0 =A0} >> >> more specifically, `t->inp_socket' is NULL. The top comment may not be >> relevant, as it's been here for the past 8 years. > > Hi Arnaud, > > Ah, thanks for the info. I'm wondering if you have a patch to fix that is= sue? > Guess what? another production machine got the same panic, oh my~ Can you give us more precision on the condition of the crash ? is it immediately at boot-time ? If not, is it when a special network condition occurs ? What kind of load is named(9) having on average before the panic ? Are you using any fancy configuration or thing out of the ordinary ? Are you using named from the base system, or from port ? Thanks, - Arnaud From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 05:50:56 2011 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 11EF31065672 for ; Tue, 27 Sep 2011 05:50:56 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B95068FC13 for ; Tue, 27 Sep 2011 05:50:55 +0000 (UTC) Received: by vws11 with SMTP id 11so8092452vws.13 for ; Mon, 26 Sep 2011 22:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X59R10adcx7pl69OHVz+b8w//vatNfma5Sj1AXm5Z/8=; b=m8rFd/sG4pnYUrhVKKXg4IHJ5zeNJw6AbQUe1lvuPdZkEW1x4v0nBiiZE/q7eqqp8p YculbpnLW0rvlbqWKQk8vnNasrMm1lybUIoHxEhDRCBjTRlwzvZoLzNZMA8gQOmwjJNB P0Tb/pmdN1dkoL/vfPgmktcJ9CTrVGajG/P2c= MIME-Version: 1.0 Received: by 10.52.24.231 with SMTP id x7mr341364vdf.184.1317102654629; Mon, 26 Sep 2011 22:50:54 -0700 (PDT) Received: by 10.52.107.194 with HTTP; Mon, 26 Sep 2011 22:50:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Sep 2011 13:50:54 +0800 Message-ID: From: dave jones To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 27 Sep 2011 05:50:56 -0000 On Tue, Sep 27, 2011 at 9:24 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 26, 2011 at 8:51 PM, dave jones wrot= e: >> On Mon, Sep 26, 2011 at 1:41 PM, Arnaud Lacombe wrote: >>> Hi, >>> >>> On Mon, Sep 26, 2011 at 1:12 AM, Arnaud Lacombe wrote: >>>> Hi, >>>> >>>> On Mon, Sep 26, 2011 at 12:43 AM, dave jones wrote: >>>>> Hi, >>>>> I have two production machines running on freebsd 9.0-beta2 and both = got >>>>> kernel panic related to networking. Any idea how to solve it? thanks. >>>>> >>>>> http://http://60.248.161.9/p1.jpg >>>>> http://http://60.248.161.9/p2.jpg >>>>> >>>> this host is really slow :-) >>>> >>>> To avoid the waiting time, the backtrace is: >>>> >>>> in_pcbbind_setup()+0x28f >>>> in_pcbbind()+0xa9 >>>> udp_bind() >>>> bind() >>>> kern_bind() >>>> syscall_enter() >>>> syscall() >>>> >>>> faulted at VA 0x07. Origin process in named. >>>> >>> AFAICT, the crash happens in the following block: >>> >>> =A0/* >>> =A0 * XXX >>> =A0 * This entire block sorely needs a rewrite. >>> =A0 */ >>> =A0 =A0 =A0 =A0if (t && >>> =A0 =A0 =A0 =A0 =A0 =A0((t->inp_flags & INP_TIMEWAIT) =3D=3D 0) && >>> =A0 =A0 =A0 =A0 =A0 =A0(so->so_type !=3D SOCK_STREAM || >>> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_faddr.s_addr) =3D=3D INADDR_ANY) &= & >>> =A0 =A0 =A0 =A0 =A0 =A0(ntohl(sin->sin_addr.s_addr) !=3D INADDR_ANY || >>> =A0 =A0 =A0 =A0 =A0 =A0 ntohl(t->inp_laddr.s_addr) !=3D INADDR_ANY || >>> =A0 =A0 =A0 =A0 =A0 =A0 (t->inp_socket->so_options & >>> =A0 =A0 =A0 =A0 =A0 SO_REUSEPORT) =3D=3D 0) && >>> =A0 =A0 =A0 =A0 =A0 =A0(inp->inp_cred->cr_uid !=3D >>> =A0 =A0 =A0 =A0 =A0 =A0 t->inp_cred->cr_uid)) >>> =A0 =A0 =A0 =A0 =A0return (EADDRINUSE); >>> =A0 =A0 =A0} >>> >>> more specifically, `t->inp_socket' is NULL. The top comment may not be >>> relevant, as it's been here for the past 8 years. >> >> Hi Arnaud, >> >> Ah, thanks for the info. I'm wondering if you have a patch to fix that i= ssue? >> Guess what? another production machine got the same panic, oh my~ > Can you give us more precision on the condition of the crash ? is it > immediately at boot-time ? If not, is it when a special network > condition occurs ? What kind of load is named(9) having on average > before the panic ? Are you using any fancy configuration or thing out > of the ordinary ? Are you using named from the base system, or from > port ? Hi Arnaud, Sorry for the confusion. It's not crashed at boot-time and named(9) used to create a caching-only name server and it worked on FreeBSD <=3D 8.2 for yea= rs. I've been using named from the base system. When I switched to 9.0-beta2, it got panic after running three days *sigh* > Thanks, > =A0- Arnaud BR, Dave. From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 05:56:34 2011 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 BAC411065670 for ; Tue, 27 Sep 2011 05:56:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7625D8FC08 for ; Tue, 27 Sep 2011 05:56:34 +0000 (UTC) Received: by yia13 with SMTP id 13so6308305yia.13 for ; Mon, 26 Sep 2011 22:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Pvjb9gswJAu+UP8pao27QPU5xCTg++MUYixugvsH3U0=; b=nkrQbwQgVqd/1+hkebeUUUSSFGsw2iVfI4FA5Q466RCgkhqXHjmeojyR8RTDuD3v06 qWvhlYYK5ivuix+DjeBQGo8ByjGA/YgHZ85tjb4JJ2GFbeN60HR8khoyqLCfScANisVB 22xxAV5LrXzaqcRhWTvCroyDVSvAjn2QrFSGM= MIME-Version: 1.0 Received: by 10.236.124.97 with SMTP id w61mr44340106yhh.106.1317102993632; Mon, 26 Sep 2011 22:56:33 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Mon, 26 Sep 2011 22:56:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Sep 2011 13:56:33 +0800 X-Google-Sender-Auth: T8a5gagEQV7mGQW6egtSwTrcoCM Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 27 Sep 2011 05:56:34 -0000 Can someone please help dave out with the mini dump script stuff that's in 9? That way he can get a crash dump and back trace, all happily wrapped up in a text file? That's likely going to help the relevant developers :-) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 08:12:26 2011 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 92899106564A for ; Tue, 27 Sep 2011 08:12:26 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (xtaz.co.uk [87.194.206.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4BF048FC1A for ; Tue, 27 Sep 2011 08:12:25 +0000 (UTC) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: gmail) by mail.xtaz.co.uk (Postfix) with ESMTPSA id EA675B07794 for ; Tue, 27 Sep 2011 09:12:23 +0100 (BST) Received: by vcbf13 with SMTP id f13so4815266vcb.13 for ; Tue, 27 Sep 2011 01:12:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.70.230 with SMTP id p6mr7709357vdu.228.1317111141724; Tue, 27 Sep 2011 01:12:21 -0700 (PDT) Received: by 10.52.159.103 with HTTP; Tue, 27 Sep 2011 01:12:21 -0700 (PDT) In-Reply-To: References: <20110926132923.GB57708@in-addr.com> <20110926142114.GC57708@in-addr.com> <20110926160527.GD57708@in-addr.com> Date: Tue, 27 Sep 2011 09:12:21 +0100 Message-ID: From: Matt Smith To: Mark Atkinson Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: gif interface not passing IPv6 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: Tue, 27 Sep 2011 08:12:26 -0000 On 26 September 2011 21:00, Mark Atkinson wrote: > Depending on your release you might need to add > > ifconfig gif0 inet6 -ifdisabled Thanks for the suggestion but this also made no difference. The problem isn't that the interface is down or disabled, from other suggestions yesterday it's become apparent that the routing table is being populated incorrectly when the gif interface is configured. No idea why. I've rebooted the server several times so any flags or strange config that's happened would have been removed anyway. I'm hoping somebody on here has some idea about it. Failing that I'm going to just give up and reinstall the server with 9.0 and assume it will work fine after that. I had planned on doing that anyway because I need to re-partition the HDD at some point. I just didn't want to have to do it until at least an RC was released so that I didn't have to rebuild ports again over the shared library version bump that usually happens between BETA and RC. Would be a shame if I can't fix it before that though because I'd like to understand what's gone wrong. From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 10:06:26 2011 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 66B39106567F for ; Tue, 27 Sep 2011 10:06:26 +0000 (UTC) (envelope-from yilinjing2006@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 41F5E8FC19 for ; Tue, 27 Sep 2011 10:06:26 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R8UYT-0004i4-Fz for freebsd-net@freebsd.org; Tue, 27 Sep 2011 03:06:25 -0700 Date: Tue, 27 Sep 2011 03:06:25 -0700 (PDT) From: jyl_2006 To: freebsd-net@freebsd.org Message-ID: <1317117985486-4844762.post@n5.nabble.com> In-Reply-To: <55A19C31-EB84-47B8-B06F-8799F1C160FC@lurchi.franken.de> References: <1316871818655-4836594.post@n5.nabble.com> <1317047026455-4841537.post@n5.nabble.com> <55A19C31-EB84-47B8-B06F-8799F1C160FC@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: message from sctp getsockopt or sctp_opt_info show error 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, 27 Sep 2011 10:06:26 -0000 I am sorry,I make a mistake to test the result of cwnd, now the value of cwnd is ok. Thank you very much. Best regards -- View this message in context: http://freebsd.1045724.n5.nabble.com/message-from-sctp-getsockopt-or-sctp-opt-info-show-error-tp4836594p4844762.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 17:24:42 2011 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 B4DE9106566B for ; Tue, 27 Sep 2011 17:24:42 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 857758FC0A for ; Tue, 27 Sep 2011 17:24:42 +0000 (UTC) Received: from [209.249.190.124] (helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R8ZyA-0006hA-6m for net@freebsd.org; Tue, 27 Sep 2011 11:53:18 -0400 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Sep 2011 11:53:25 -0400 References: To: net@freebsd.org Message-Id: <38979A0E-8B70-4BAD-9E09-857A0EA38F9D@freebsd.org> Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org Cc: Subject: Fwd: [e2e] Nationwide 100Gbps testbed available to researchers 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, 27 Sep 2011 17:24:42 -0000 Somehow we ought to get involved in this. Best, George Begin forwarded message: > From: Brian Tierney > Subject: [e2e] Nationwide 100Gbps testbed available to researchers > Date: September 26, 2011 1:05:12 EDT > To: end2end-interest@postel.org >=20 >=20 > Hi all: >=20 > This may be of interest to those of you working on protocols for = high-speed networks. >=20 > ESnet will be deploying a nationwide 100Gbps testbed by the end of = this year. This testbed is available to anyone. >=20 > For more information see: >=20 > https://sites.google.com/a/lbl.gov/ani-testbed/proposal-process >=20 >=20 >=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Tue Sep 27 20:57:08 2011 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 054F51065678 for ; Tue, 27 Sep 2011 20:57:08 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B94B18FC0A for ; Tue, 27 Sep 2011 20:57:07 +0000 (UTC) Received: by qyk4 with SMTP id 4so8731860qyk.13 for ; Tue, 27 Sep 2011 13:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=WVr9jeiYfsgGnmAxnZ4W3N4snsUniHTGbGLp9lZQM8E=; b=kYGi5WRS5/YIt4ZIf7nGda1BsScQNJmYxVjsuBGs1yyhqJPQDlgNEMOD8l7ylZ2zKL ZSUwMpCpi15OL5SD/bprS5hdfIBtpjrt1Dc0ztqIVFyg1u5QvZ1heSH4UX3wvNyLmz6b WTaSuRVgql6TMoKCv3d2LVVT+4WezgLN64O4o= Received: by 10.229.219.67 with SMTP id ht3mr6269340qcb.30.1317155212118; Tue, 27 Sep 2011 13:26:52 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.229.80.13 with HTTP; Tue, 27 Sep 2011 13:26:32 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 27 Sep 2011 22:26:32 +0200 X-Google-Sender-Auth: S2NU7wBGl6wgvV6VfsJ1rCxwAzk Message-ID: To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: How to protect RIPng or OSPFv3 with 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: Tue, 27 Sep 2011 20:57:08 -0000 Hi, I'm trying to protect RIPng and OSPFv3 (I'm using Quagga and Bird), but I didn't know how to manage multicast traffic with setkey. Does someone have an example of /etc/ipsec.conf for protecting RIPng or OSPF3 ? Thanks, Olivier From owner-freebsd-net@FreeBSD.ORG Wed Sep 28 09:05:55 2011 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 486C3106566B for ; Wed, 28 Sep 2011 09:05:55 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id F178E8FC17 for ; Wed, 28 Sep 2011 09:05:54 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 5A0182798C2; Wed, 28 Sep 2011 10:48:20 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 457CF17050; Wed, 28 Sep 2011 10:48:20 +0200 (CEST) Date: Wed, 28 Sep 2011 10:48:20 +0200 From: VANHULLEBUS Yvan To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= Message-ID: <20110928084820.GA45502@zeninc.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: net@freebsd.org Subject: Re: How to protect RIPng or OSPFv3 with 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: Wed, 28 Sep 2011 09:05:55 -0000 On Tue, Sep 27, 2011 at 10:26:32PM +0200, Olivier Cochard-Labb wrote: > Hi, Hi. > I'm trying to protect RIPng and OSPFv3 (I'm using Quagga and Bird), > but I didn't know how to manage multicast traffic with setkey. You can't: IPsec has NOT be designed to protect multicast traffic (well, there are actually at least some drafts in progress). > Does someone have an example of /etc/ipsec.conf for protecting RIPng or OSPF3 ? The real question is: what exactly are you trying to protect, and on which part of the way..... If your goal is to provide a global ciphering/authentication for some dynamic routing infrastructure, just forget IPsec and search something else designed for multicast / dynamic routing. If you need, for example, to do dynamic routing between sites which have each a single internet connection, and an IPsec tunnel to communicate between LANs, then you MAY be able to do something for your multicast packets by doing some other kind of IP-IP encapsulation before IPsec..... Never tried that, however, I don't know exactly how to do it ! Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Sep 28 09:10:07 2011 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 8B3DF106566C for ; Wed, 28 Sep 2011 09:10:07 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 42EA28FC25 for ; Wed, 28 Sep 2011 09:10:06 +0000 (UTC) Received: by qyk10 with SMTP id 10so2213575qyk.13 for ; Wed, 28 Sep 2011 02:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=KbcLrNGklRD5uBFOJnfuXaUw+gBw30WZeryZ7DBQHE4=; b=EyPup23Wmo/5JJ1yzx6TWrDI6nMAGXg+ty2d7X27ZVbt6wjDxR2yLsKAIimyN11P8J oBbcacBDM+160kVu0FpzT5Fib2h7HG4sux4jXF0vUPoSQbDFk5Y2KepDLeY9L5u6DmB4 eNYbzArZYV0uGYFyuFU0WnZyxEHsDXAIlppQw= Received: by 10.224.196.199 with SMTP id eh7mr6579574qab.302.1317201006120; Wed, 28 Sep 2011 02:10:06 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.229.80.13 with HTTP; Wed, 28 Sep 2011 02:09:46 -0700 (PDT) In-Reply-To: <20110928084820.GA45502@zeninc.net> References: <20110928084820.GA45502@zeninc.net> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 28 Sep 2011 11:09:46 +0200 X-Google-Sender-Auth: dKGpYgihjX0hsI8eizs87IiB_8M Message-ID: To: VANHULLEBUS Yvan Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: How to protect RIPng or OSPFv3 with 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: Wed, 28 Sep 2011 09:10:07 -0000 Hi Yvan, 2011/9/28 VANHULLEBUS Yvan : > >> I'm trying to protect RIPng and OSPFv3 (I'm using Quagga and Bird), >> but I didn't know how to manage multicast traffic with setkey. > > You can't: IPsec has NOT be designed to protect multicast traffic > (well, there are actually at least some drafts in progress). OSPFv3 and RIPng rely on the IPv6 Authentication Header (AH) and IPv6 Encapsulating Security Payload (ESP) in order to provide integrity, authentication, and/or confidentiality. I believed that for configuring HA/ESP header on FreeBSD, I need to use IPSec (setkey)=85 But if you say that IPsec was not be designed to protect multicast traffic: How to protect RIPng/OSPFv3 (multicast based) using AH/ESP ? > > The real question is: what exactly are you trying to protect, and on > which part of the way..... > > If your goal is to provide a global ciphering/authentication for some > dynamic routing infrastructure, just forget IPsec and search something > else designed for multicast / dynamic routing. > My goal is simply to have the same security level as on my RIPv2/OSPFv2 infrastructure (that use "authentication mode md5" for RIPv2 and "authentication message-digest" for OSPFv2) to my RIPng/OSPFv3 infrastructure. Thanks, Olivier From owner-freebsd-net@FreeBSD.ORG Wed Sep 28 13:44:41 2011 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 9DA611065672 for ; Wed, 28 Sep 2011 13:44:41 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 195538FC13 for ; Wed, 28 Sep 2011 13:44:40 +0000 (UTC) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 598172798BF; Wed, 28 Sep 2011 15:44:39 +0200 (CEST) Received: by astro.zen.inc (Postfix, from userid 1000) id 4BDE817050; Wed, 28 Sep 2011 15:44:39 +0200 (CEST) Date: Wed, 28 Sep 2011 15:44:39 +0200 From: VANHULLEBUS Yvan To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= Message-ID: <20110928134439.GA46061@zeninc.net> References: <20110928084820.GA45502@zeninc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: net@freebsd.org Subject: Re: How to protect RIPng or OSPFv3 with 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: Wed, 28 Sep 2011 13:44:41 -0000 On Wed, Sep 28, 2011 at 11:09:46AM +0200, Olivier Cochard-Labb wrote: > Hi Yvan, > > 2011/9/28 VANHULLEBUS Yvan : > > > >> I'm trying to protect RIPng and OSPFv3 (I'm using Quagga and Bird), > >> but I didn't know how to manage multicast traffic with setkey. > > > > You can't: IPsec has NOT be designed to protect multicast traffic > > (well, there are actually at least some drafts in progress). > > OSPFv3 and RIPng rely on the IPv6 Authentication Header (AH) and IPv6 > Encapsulating Security Payload (ESP) in order to provide integrity, > authentication, and/or confidentiality. > > I believed that for configuring HA/ESP header on FreeBSD, I need to > use IPSec (setkey)? But if you say that IPsec was not be designed to > protect multicast traffic: How to protect RIPng/OSPFv3 (multicast > based) using AH/ESP ? That's right: IPsec has been designed for unicast packets..... After quickly reading RFC 4552 (sections 6 and 7), looks like someone had the good idea to go back to manual keying to be able to do some kind of IPsec on multicast packets (well, I'm still not sure IPsec is used for multicast packets, OSPF also seems to sends unicast packets). Such "shared SAs" should resolve some multicast related issues, but the way SPD entries should be created for that is still unclear for me, sorry..... Section 6 of RFC 4552 also seems to have at least one requirement not actually provided by FreeBSD's IPsec stack (well, at least, I don't know how to configure that on FreeBSD....): multiple SPD... Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Sep 28 20:00:48 2011 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 C9C81106566C; Wed, 28 Sep 2011 20:00:48 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 244C68FC0C; Wed, 28 Sep 2011 20:00:47 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so10354785bkb.13 for ; Wed, 28 Sep 2011 13:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=JXpKOQz+IH8OJ2dHN86rew5JbxdIDNnB7w9hTzFFuLI=; b=MR/Ubqb/6GYffSKGkCbKEbxynqyFZvGY/PWzGH7ZTGVFsO+yf6bXhhVCl/3Lde0E3U dBoPjiRQU9iL2xfKKJmTKR2mv40yjl1pE8S7uIm5Gc+ILhFgrd8rVHyqMh27qStORsAj rpZnaPpcKG7xV19+u06o7gBF2dR2J9WObjSf4= Received: by 10.204.137.89 with SMTP id v25mr2689841bkt.368.1317240046794; Wed, 28 Sep 2011 13:00:46 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id z7sm29374611bkt.5.2011.09.28.13.00.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 13:00:44 -0700 (PDT) From: Mikolaj Golub To: "K. Macy" References: X-Comment-To: K. Macy Sender: Mikolaj Golub Date: Wed, 28 Sep 2011 23:00:40 +0300 In-Reply-To: (K. Macy's message of "Mon, 26 Sep 2011 16:12:55 +0200") Message-ID: <8662kcigif.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Arnaud Lacombe , dave jones Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 28 Sep 2011 20:00:49 -0000 --=-=-= On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: KM> Sorry, didn't look at the images (limited bw), I've seen something KM> like this before in timewait. This "can't happen" with UDP so will be KM> interested in learning more about the bug. The panic can be easily triggered by this: --=-=-= Content-Type: application/octet-stream Content-Disposition: inline; filename=test_udp.c Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN5cy9wYXJhbS5oPgojaW5jbHVkZSA8c3lzL3NvY2tldC5oPgojaW5jbHVkZSA8 c3lzL3RpbWUuaD4KCiNpbmNsdWRlIDxuZXRpbmV0L2luLmg+CgojaW5jbHVkZSA8ZXJyLmg+CiNp bmNsdWRlIDxlcnJuby5oPgojaW5jbHVkZSA8c2lnbmFsLmg+CiNpbmNsdWRlIDxzdGRpby5oPgoj aW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KI2luY2x1ZGUgPHVuaXN0ZC5o PgoKI2RlZmluZSBQT1JUCTY2NjYKCmludAptYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKewoJ c3RydWN0IHNvY2thZGRyX2luIHNpbjsKCWludCBmZDsKCglpZiAoZm9yaygpID09IC0xKQoJCWVy cigxLCAiZm9yayIpOwoKCWZvciAoOzspIHsKCQlpZiAoKGZkID0gc29ja2V0KEFGX0lORVQsIFNP Q0tfREdSQU0sIDApKSA9PSAtMSkKCQkJY29udGludWU7CgoJCW1lbXNldCgmc2luLCAwLCBzaXpl b2Yoc2luKSk7CgkJc2luLnNpbl9mYW1pbHkgPSBBRl9JTkVUOwoJCXNpbi5zaW5fcG9ydCA9IGh0 b25zKFBPUlQpOwoKCQliaW5kKGZkLCAoc3RydWN0IHNvY2thZGRyICopICZzaW4sIHNpemVvZihz aW4pKTsKCgkJY2xvc2UoZmQpOwoJfQoKCWV4aXQoMCk7Cn0K --=-=-= The other thread at that moment is in soclose->sofree->upd_detach->in_pcbfree. It looks for me that we should call in_pcbdrop() in udp_close() to remove inpcb from hashed lists, like it is done for tcp_close(). With this patch I don't observe the panic. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=udp_usrreq.c.in_pcbdrop.patch Index: sys/netinet/udp_usrreq.c =================================================================== --- sys/netinet/udp_usrreq.c (revision 225816) +++ sys/netinet/udp_usrreq.c (working copy) @@ -1486,6 +1486,7 @@ udp_close(struct socket *so) inp = sotoinpcb(so); KASSERT(inp != NULL, ("udp_close: inp == NULL")); INP_WLOCK(inp); + in_pcbdrop(inp); if (inp->inp_faddr.s_addr != INADDR_ANY) { INP_HASH_WLOCK(&V_udbinfo); in_pcbdisconnect(inp); --=-=-= Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit KM> On Mon, Sep 26, 2011 at 4:02 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Sep 26, 2011 at 5:12 AM, K. Macy wrote: >>> >>> >>> On Monday, September 26, 2011, Adrian Chadd wrote: >>>> On 26 September 2011 13:41, Arnaud Lacombe wrote: >>>>> š/* >>>>> š * XXX >>>>> š * This entire block sorely needs a rewrite. >>>>> š */ >>>>> š š š šif (t && >>>>> š š š š š š((t->inp_flags & INP_TIMEWAIT) == 0) && >>>>> š š š š š š(so->so_type != SOCK_STREAM || >>>>> š š š š š š ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && >>>>> š š š š š š(ntohl(sin->sin_addr.s_addr) != INADDR_ANY || >>>>> š š š š š š ntohl(t->inp_laddr.s_addr) != INADDR_ANY || >>>>> š š š š š š (t->inp_socket->so_options & >>>>> š š š š š SO_REUSEPORT) == 0) && >>>>> š š š š š š(inp->inp_cred->cr_uid != >>>>> š š š š š š t->inp_cred->cr_uid)) >>>>> š š š š šreturn (EADDRINUSE); >>>>> š š š} >>>>> >>>>> more specifically, `t->inp_socket' is NULL. The top comment may not be >>>>> relevant, as it's been here for the past 8 years. >>>> >>>> Why would t->inp_socket be NULL at this point? >>> >>> TIME_WAIT ... >>> >> on UDP socket ? >> >> š- Arnaud >> KM> _______________________________________________ KM> freebsd-net@freebsd.org mailing list KM> http://lists.freebsd.org/mailman/listinfo/freebsd-net KM> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Mikolaj Golub --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 02:15:14 2011 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 E471B106564A; Thu, 29 Sep 2011 02:15:14 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1658FC0C; Thu, 29 Sep 2011 02:15:14 +0000 (UTC) Received: by vcbf13 with SMTP id f13so128388vcb.13 for ; Wed, 28 Sep 2011 19:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Iwc4Ti/wOhStYN6Bz6yySiCPPqrc+JfOzcjRjqXbqKs=; b=wufUUX90Uab2kYibxKf+Gw7ZmIxIpdue4ILrP7lI7EHUipZxflX1d1GR8/v6wziknf /5Z590MEXAyOlzXBGWrpXRs0uUEJlGnry/zBgA0KcrRwAA2PbS7SijOKCU75L8b/kyGB tDoqhK/iyHWEGbIpZzERzs41eyHzs4j08S6MU= MIME-Version: 1.0 Received: by 10.52.108.68 with SMTP id hi4mr1471994vdb.385.1317262513446; Wed, 28 Sep 2011 19:15:13 -0700 (PDT) Received: by 10.52.107.194 with HTTP; Wed, 28 Sep 2011 19:15:13 -0700 (PDT) In-Reply-To: <8662kcigif.fsf@kopusha.home.net> References: <8662kcigif.fsf@kopusha.home.net> Date: Thu, 29 Sep 2011 10:15:13 +0800 Message-ID: From: dave jones To: Mikolaj Golub Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Adrian Chadd , "K. Macy" , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 29 Sep 2011 02:15:15 -0000 2011/9/29 Mikolaj Golub : > > On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: > > =A0KM> Sorry, didn't look at the images (limited bw), I've seen something > =A0KM> like this before in timewait. This "can't happen" with UDP so will= be > =A0KM> interested in learning more about the bug. > > The panic can be easily triggered by this: > > > > The other thread at that moment is in soclose->sofree->upd_detach->in_pcb= free. > > It looks for me that we should call in_pcbdrop() in udp_close() to remove > inpcb from hashed lists, like it is done for tcp_close(). > > With this patch I don't observe the panic. Hi Mikolaj, You rock! Machines have been running hours without panic after applying your patch. You should commit the atch asap :-) Thank you for your help! Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 02:25:39 2011 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 09A67106564A; Thu, 29 Sep 2011 02:25:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED538FC13; Thu, 29 Sep 2011 02:25:38 +0000 (UTC) Received: by yia13 with SMTP id 13so155709yia.13 for ; Wed, 28 Sep 2011 19:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=esu6ZIGTjQY+hVdjIxl7TROJpvdmNOylCD/6CuIZHKk=; b=f/W6oGAfD7p3Sr+2Y0dhzvWx0e0wqlswGjU3FctoMHlDpniDiYzj/L5RySv3gBjR++ y1Ss1Hj+5I3VOg+jM+Ay2jxZVIxqBovN/+QJ8iGT/XsXwmj2lFh4BRGEXKTkvPl6/mlM 1+bBUqwhNDAVDiLaZux7npDHXH03pR71bjBzs= MIME-Version: 1.0 Received: by 10.236.75.227 with SMTP id z63mr60547254yhd.55.1317263137843; Wed, 28 Sep 2011 19:25:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Wed, 28 Sep 2011 19:25:37 -0700 (PDT) In-Reply-To: References: <8662kcigif.fsf@kopusha.home.net> Date: Thu, 29 Sep 2011 10:25:37 +0800 X-Google-Sender-Auth: O8t5Hg0kmsYxuzLwQ9IEes328Lo Message-ID: From: Adrian Chadd To: dave jones Content-Type: text/plain; charset=ISO-8859-1 Cc: Mikolaj Golub , "freebsd-net@freebsd.org" , "K. Macy" , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 29 Sep 2011 02:25:39 -0000 .. so now there's a patch: * is there a PR for this? * if there is, can we get this patch and the discussion about this bug placed in the PR? :) That way it doesn't get lost. No, I lie. It doesn't get "too lost". :-) Adrian From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 12:58:43 2011 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 A186A1065689 for ; Thu, 29 Sep 2011 12:58:43 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 036B98FC17 for ; Thu, 29 Sep 2011 12:58:42 +0000 (UTC) Received: (qmail 3049 invoked by uid 0); 29 Sep 2011 12:32:02 -0000 Received: from 93.159.253.120 by rms-de010.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Thu, 29 Sep 2011 14:32:01 +0200 From: "Rainer Bredehorn" Message-ID: <20110929123201.282750@gmx.net> MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: eVKxegYpTiE+XqzwZWRwUR99ZUVSRBeT Subject: IPv6 multicast listener discovery 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, 29 Sep 2011 12:58:43 -0000 Hi! The FreeBSD 8.2 sends sevaral MLDv2 listener reports during startup. The system sends one listener report with its solicited multicast address which comes from the automatically generated link local address. But I can see another MLD2 listener report with 2 records. One is the mentioned solicited multicast address. The other one is e.g. ff02::2:2d75:f2b8. I've no idead where it comes from. The interface has only on link local address. It might be a bug in FreeBSD 8.2 Best regards, Rainer. From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 13:44:17 2011 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 EDE3C1065673 for ; Thu, 29 Sep 2011 13:44:17 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0E28FC12 for ; Thu, 29 Sep 2011 13:44:17 +0000 (UTC) Received: from alph.allbsd.org (p1023-ipbf1601funabasi.chiba.ocn.ne.jp [123.220.25.23]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p8TDhsBr088358; Thu, 29 Sep 2011 22:44:05 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p8TDhqXl088189; Thu, 29 Sep 2011 22:43:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 29 Sep 2011 22:43:45 +0900 (JST) Message-Id: <20110929.224345.765877536414872910.hrs@allbsd.org> To: Bredehorn@gmx.de From: Hiroki Sato In-Reply-To: <20110929123201.282750@gmx.net> References: <20110929123201.282750@gmx.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Sep_29_22_43_45_2011_201)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Thu, 29 Sep 2011 22:44:10 +0900 (JST) X-Spam-Status: No, score=-95.8 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, DIRECTOCNDYN, DYN_PBL, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: IPv6 multicast listener discovery 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, 29 Sep 2011 13:44:18 -0000 ----Security_Multipart(Thu_Sep_29_22_43_45_2011_201)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Rainer Bredehorn" wrote in <20110929123201.282750@gmx.net>: Br> Hi! Br> Br> The FreeBSD 8.2 sends sevaral MLDv2 listener reports during startup. Br> The system sends one listener report with its solicited multicast Br> address which comes from the automatically generated link local Br> address. Br> But I can see another MLD2 listener report with 2 records. One is the Br> mentioned solicited multicast address. Br> The other one is e.g. ff02::2:2d75:f2b8. Br> Br> I've no idead where it comes from. The interface has only on link Br> local address. Br> It might be a bug in FreeBSD 8.2 Could you show us more specifics about your configuration and packet dump in question? -- Hiroki ----Security_Multipart(Thu_Sep_29_22_43_45_2011_201)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6EdhEACgkQTyzT2CeTzy0o3wCgoLviiLWcqRDUwRboVJYMcjw8 ri0AnjnRnZqZ4M2BGIfXQhTdhzwvPW4O =6Wl/ -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Sep_29_22_43_45_2011_201)---- From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 15:25:11 2011 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 8EF201065670 for ; Thu, 29 Sep 2011 15:25:11 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 70EE48FC12 for ; Thu, 29 Sep 2011 15:25:10 +0000 (UTC) Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Sep 2011 08:25:09 -0700 From: Ben Hutchings To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Thu, 29 Sep 2011 16:25:06 +0100 Message-ID: <1317309906.2743.9.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2011 15:25:10.0314 (UTC) FILETIME=[F9E0B8A0:01CC7EBB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18414.005 X-TM-AS-Result: No--7.317400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: TSO broken with jumbo MTU 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, 29 Sep 2011 15:25:11 -0000 tcp_output() does: if (... && len > tp->t_maxseg && ...) tso = 1; Then: if (len + optlen + ipoptlen > tp->t_maxopd) { ... if (tso) { ... if (sendalot && off + len < so->so_snd.sb_cc) { len -= len % (tp->t_maxopd - optlen); sendalot = 1; } Then later: if (tso) { KASSERT(len > tp->t_maxopd - optlen, ("%s: len <= tso_segsz", __func__)); m->m_pkthdr.csum_flags |= CSUM_TSO; m->m_pkthdr.tso_segsz = tp->t_maxopd - optlen; } So there is an assumption here that tp->t_maxseg >= tp->t_maxopd - optlen. But tcp_mss_update() does not ensure that at all, because it rounds down tp->t_maxseg to a multiple of MCLBYTES and does not change tp->t_maxopd accordingly: tp->t_maxopd = mss; if (...) mss -= TCPOLEN_TSTAMP_APPA; #if (MCLBYTES & (MCLBYTES - 1)) == 0 if (mss > MCLBYTES) mss &= ~(MCLBYTES-1); #else if (mss > MCLBYTES) mss = mss / MCLBYTES * MCLBYTES; #endif tp->t_maxseg = mss; (All the above code is from 9, but I found the assertion failure on 8.2 which has fairly similar code.) Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 17:11:43 2011 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 471171065675 for ; Thu, 29 Sep 2011 17:11:43 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 088978FC1D for ; Thu, 29 Sep 2011 17:11:37 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p8TH16tg073221 for ; Thu, 29 Sep 2011 10:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317315667; bh=keBJnJSpRGlnKbXsH+L43s5MKJh5wndmSdHk7JJNynY=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=FSz5ATnrX4rBNKWcCBC8aWGSySMH4+0ne+rjnkcGBptuRKxAE4G0GbSEtlYEZ/WnP pT78V/R9kYkDve8jMBgGV0+jDDPpMYSjiVv1e+3Lh9rM8/R/c3vd3XBqkPWT/OmCtE 2a0I+BlSW661l2/0Dj6oo+eHGJDI7JmoCesh0+v4= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Sep 2011 10:01:06 -0700 Message-ID: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Subject: bce(4) with IPMI 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, 29 Sep 2011 17:11:43 -0000 We've been getting reports of odd behavior on our Dell R410 machines when trying to use IPMI. The servers have two NIC's that we have assigned as the IPMI interface(bce0) and production interface(bce1) respectively. Since we don't actually configure bce0 in FreeBSD, we've found that the IPMI interface deactivated when bce(4) loads. I assume that the driver is not initializing the interface correctly in this case and the default case is to turn the interface off. Does it make sense to completely turn off the interface when there is an active link on the port, but no configuration assigned? Sean p.s. Dell's IPMI implementation is ... um ... more difficult than it needs to be. From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 18:09:23 2011 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 D10DB106566C for ; Thu, 29 Sep 2011 18:09:23 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 465BF8FC14 for ; Thu, 29 Sep 2011 18:09:22 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 29508 invoked from network); 29 Sep 2011 20:09:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1317319760; bh=UzhcJfX13XeQ15CSUBXNYlqtEk+baUa6dRXs4g68ko4=; h=From:To:Subject; b=OTPYcAavReoPORBFexWkehEv3ZdgzPeAkum7/l8hrRY2lCsaRf/mySA6h5wfro5iR yNUVUlJq6BXPut/xOBRMXywD+zCvUTbBycKY0acfh6bZ8wDb7xgUncXdVKdTD+vYpL JxcYRkA8UyF5uMCzpx+FreiWbv6L3hKf2obXmUH8= Received: from cwx170.internetdsl.tpnet.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 29 Sep 2011 20:09:20 +0200 Message-ID: <4E84B447.7010509@wp.pl> Date: Thu, 29 Sep 2011 20:09:11 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Freddie Cash , freebsd-net@freebsd.org References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [0TOk] Cc: Subject: Re: ipfw - accessing DMZ from LAN 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, 29 Sep 2011 18:09:24 -0000 W dniu 2011-09-26 21:20, Freddie Cash pisze: > > Your rules are too generic, they will not work for a double-NAT setup. > Each and every single rule must specify the network interface. And it must > specify whether it's incoming (in recv) or outgoing (out xmit) traffic. > Don't use "via" anywhere. > > While it's easier to use generic rules to start with, you really need to get > very specific, at least for the double-NAT setup. > > See my example above. > I look at it but I have problems with understanding the rules. So far I understand the double-NAT like: 1. There are two NAT instances, one for LAN, the other for DMZ host (with public address redirection to DMZ private IP). The first is $lanport, the other $dmzport. The LAN interface is $LANIF, the DMZ interface is $DMZIF 2. When client from LAN wants to connect to DMZ host, using DMZ public IP *only*, the packet goes like this: i. the packet is allowed to enter the router by DMZ NAT port ($dmzport) and $LANIF: ipfw add divert $dmzport ip from $LAN to $DMZ_PUBLIC_IP in recv $LANIF ipfw add allow ip from $LAN to $DMZ_PUBLIC_IP in recv $LANIF <--- why in your example are you using PRIVATE_IP instead of PUBLIC? ii. the packet is redirected to go out to DMZ, using DMZ NAT port: ipfw add divert $dmzport ip from $LAN to $DMZ_PRIVATE_IP out xmit $DMZIF ipfw add allow ip from $ROUTER_PUBLIC_IP to $DMZ_PRIVATE_IP out xmit $DMZIF 3. When DMZ host wants to connect with LAN client: i. the packet goes to router by DMZ NAT port and $DMZIF: ipfw add divert $dmzport ip from $DMZ_PRIVATE_IP to $ROUTER_PUBLIC_IP in recv $DMZIF ipfw add allow ip from $DMZ_PRIVATE_IP to $LAN in recv $DMZIF ii. the packet is redirected to LAN (using _which_ NAT port? For LAN or DMZ? ) ipfw add divert $lanport (I am *not* sure here) from $DMZ_PRIVATE_IP to $LAN out xmit $LANIF ipfw add allow ip from $DMZ_PUBLIC_IP to $LAN out xmit $LANIF 4. Is it OK ? What's the port in 3.ii step ? If I want also to set up NAT rules for my LAN (to allow it to access the Internet, and router), and also for my DMZ hosts (also for the Internet), what should be the order of rules? First 'LAN-DMZ', then 'DMZ', then 'LAN' ? Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 18:43:29 2011 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 1FE081065673 for ; Thu, 29 Sep 2011 18:43:29 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id CF84C8FC0C for ; Thu, 29 Sep 2011 18:43:28 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B4A3028429; Thu, 29 Sep 2011 20:27:15 +0200 (CEST) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id E44FA28424; Thu, 29 Sep 2011 20:27:14 +0200 (CEST) Message-ID: <4E84B882.7040400@quip.cz> Date: Thu, 29 Sep 2011 20:27:14 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Sean Bruno References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: bce(4) with IPMI 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, 29 Sep 2011 18:43:29 -0000 Sean Bruno wrote: > We've been getting reports of odd behavior on our Dell R410 machines > when trying to use IPMI. The servers have two NIC's that we have > assigned as the IPMI interface(bce0) and production interface(bce1) > respectively. > > Since we don't actually configure bce0 in FreeBSD, we've found that the > IPMI interface deactivated when bce(4) loads. I assume that the driver > is not initializing the interface correctly in this case and the default > case is to turn the interface off. Does it make sense to completely > turn off the interface when there is an active link on the port, but no > configuration assigned? I had similar problem few years ago with bge interface. There is following loader tunable option for it: hw.bge.allow_asf Allow the ASF feature for cooperating with IPMI. Can cause sys- tem lockup problems on a small number of systems. Disabled by default. Is it possible that something similar is needed for bce too? Miroslav Lachman From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 19:01:17 2011 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 C21F11065670 for ; Thu, 29 Sep 2011 19:01:17 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEDC8FC0A for ; Thu, 29 Sep 2011 19:01:17 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p8TJ0q6K020428; Thu, 29 Sep 2011 12:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317322852; bh=w3LgCm4wMP7/pGJlTp6toZiV//o4cuDmYTU92ge7H7w=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=Gg46KjqCYbWAE0hVAhaNAEtphtanKAOPq2RzjbeRkDghSugGBfHw/IBFYtAb811LH RzbKDa0SXsD3uQ1FMzmVLLJit9jexmrsisZDG8Vg38tB44WhHqmqyJRt3tSV5e0bg3 yjjB28bfKX1SOOsYnawWafDqKASjk+UcskSg6zPY= From: Sean Bruno To: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <4E84B882.7040400@quip.cz> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <4E84B882.7040400@quip.cz> Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Sep 2011 12:00:51 -0700 Message-ID: <1317322851.2777.12.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: bce(4) with IPMI 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, 29 Sep 2011 19:01:17 -0000 On Thu, 2011-09-29 at 11:27 -0700, Miroslav Lachman wrote: > Sean Bruno wrote: > > We've been getting reports of odd behavior on our Dell R410 machines > > when trying to use IPMI. The servers have two NIC's that we have > > assigned as the IPMI interface(bce0) and production interface(bce1) > > respectively. > > > > Since we don't actually configure bce0 in FreeBSD, we've found that the > > IPMI interface deactivated when bce(4) loads. I assume that the driver > > is not initializing the interface correctly in this case and the default > > case is to turn the interface off. Does it make sense to completely > > turn off the interface when there is an active link on the port, but no > > configuration assigned? > > I had similar problem few years ago with bge interface. There is > following loader tunable option for it: > > hw.bge.allow_asf > Allow the ASF feature for cooperating with IPMI. Can cause sys- > tem lockup problems on a small number of systems. Disabled by > default. > > Is it possible that something similar is needed for bce too? > > Miroslav Lachman Maybe. But from the changelogs of bce(4), it looks like the deactivation of the interface when not configured is pretty much intentional. Sean From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 19:10:34 2011 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 987EF106564A for ; Thu, 29 Sep 2011 19:10:34 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 585778FC14 for ; Thu, 29 Sep 2011 19:10:34 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p8TJAINv023410 for ; Thu, 29 Sep 2011 12:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317323419; bh=q5ohMFLIpJ3qYpWlYqthXg64m9c0QnQ32DMj/FLyQ08=; h=Subject:From:To:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=ZCyoFyIWGYX7ph+cJ8hloZJExPO/wvQdZjOrE200xiEqzGyRvWiQzOtFioOUgZYl4 UYj6xU6W21vW7kSWBk709QskWAiezXEiLSFCgQfZGvml8hX7hKokSE5TOtEoem/0Zs N6NCPDojbDq7lBmI31fzIlObAvzU41ejnAvQaKh8= From: Sean Bruno To: "freebsd-net@freebsd.org" In-Reply-To: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Sep 2011 12:10:18 -0700 Message-ID: <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Subject: Re: bce(4) with IPMI 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, 29 Sep 2011 19:10:34 -0000 On Thu, 2011-09-29 at 10:01 -0700, Sean Bruno wrote: > We've been getting reports of odd behavior on our Dell R410 machines > when trying to use IPMI. The servers have two NIC's that we have > assigned as the IPMI interface(bce0) and production interface(bce1) > respectively. > > Since we don't actually configure bce0 in FreeBSD, we've found that the > IPMI interface deactivated when bce(4) loads. I assume that the driver > is not initializing the interface correctly in this case and the default > case is to turn the interface off. Does it make sense to completely > turn off the interface when there is an active link on the port, but no > configuration assigned? > > Sean > > p.s. Dell's IPMI implementation is ... um ... more difficult than it > needs to be. > I should probably say, this is freebsd7. So I'll peruse the changelogs and see if 7 is missing something here. sean From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 19:57:19 2011 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 3304A1065673 for ; Thu, 29 Sep 2011 19:57:19 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id E2AFC8FC0A for ; Thu, 29 Sep 2011 19:57:18 +0000 (UTC) Received: by vws11 with SMTP id 11so1135274vws.13 for ; Thu, 29 Sep 2011 12:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4MSZkn4qdXhw2HAbfeSfBy+z4iG8TBT6XX8Nh2quCdg=; b=AfaTBXBtwRrpFfCfsyR3+TlOovKt4h0bI1YV9VyEF/9POpOvQ4peOyPXDEVRPS25mw OTGVlLuYGUhgfNF4ij43nt7tfLKwJErpMBShxLHntkBShCH1y17RDjnQ7H/nlZrJdNxk ua+CcAjrgGUtwItX4LbT/teUdcWJWKPJW1wAg= MIME-Version: 1.0 Received: by 10.52.176.196 with SMTP id ck4mr10216023vdc.168.1317326237969; Thu, 29 Sep 2011 12:57:17 -0700 (PDT) Received: by 10.220.186.196 with HTTP; Thu, 29 Sep 2011 12:57:17 -0700 (PDT) In-Reply-To: <4E84B447.7010509@wp.pl> References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> <4E84B447.7010509@wp.pl> Date: Thu, 29 Sep 2011 12:57:17 -0700 Message-ID: From: Freddie Cash To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 29 Sep 2011 19:57:19 -0000 On Thu, Sep 29, 2011 at 11:09 AM, Marek Salwerowicz wrote: > W dniu 2011-09-26 21:20, Freddie Cash pisze: > > Your rules are too generic, they will not work for a double-NAT setup. >> Each and every single rule must specify the network interface. And it >> must >> specify whether it's incoming (in recv) or outgoing (out xmit) traffic. >> Don't use "via" anywhere. >> >> While it's easier to use generic rules to start with, you really need to >> get >> very specific, at least for the double-NAT setup. >> >> See my example above. >> >> I look at it but I have problems with understanding the rules. > So far I understand the double-NAT like: > > 1. There are two NAT instances, one for LAN, the other for DMZ host (with > public address redirection to DMZ private IP). The first is $lanport, the > other $dmzport. The LAN interface is $LANIF, the DMZ interface is $DMZIF > > 2. When client from LAN wants to connect to DMZ host, using DMZ public IP > *only*, the packet goes like this: > > i. the packet is allowed to enter the router by DMZ NAT port ($dmzport) > and $LANIF: > ipfw add divert $dmzport ip from $LAN to $DMZ_PUBLIC_IP in recv > $LANIF > ipfw add allow ip from $LAN to $DMZ_PUBLIC_IP in recv $LANIF <--- > why in your example are you using PRIVATE_IP instead of PUBLIC? > You use the private DMZ IP in the second rule because you are allowing the NAT'd packet through. The first rule matches a packet with src $LAN and dest $DMZ_PUBLIC_IP, and converts it to a packet with src $LAN and dest $DMZ_PRIVATE_IP. Thus, your second rule has to match the new packet. Remember, diverted packets are re-injected into the IPFW rules. > ii. the packet is redirected to go out to DMZ, using DMZ NAT port: > ipfw add divert $dmzport ip from $LAN to $DMZ_PRIVATE_IP out xmit > $DMZIF > ipfw add allow ip from $ROUTER_PUBLIC_IP to $DMZ_PRIVATE_IP out xmit > $DMZIF > > No, the packet is routed to the DMZ network (since the dest is now $DMZ_PRIVATE). But the src is still $LAN (which are private, non-routable IPs), so you have to NAT the packet again, using the $lanport. ipfw add divert $lanport ip from $LAN to $DMZ_PRIVATE_IP out xmit $DMZIF That sends the packet to the LAN NAT instance. The packet starts with src $LAN and dest $DMZ_PRIVATE_IP, and ends up with src $LAN_PUBLIC_IP and dest $DMZ_PRIVATE_IP. So now you need a rule to match that packet: ipfw add allow ip from $LAN_PUBLIC_IP to $DMZ_PRIVATE_IP out xmit $DMZIF Thus, the client connects to $DMZ_PUBLIC_IP, and the server sees the connection comming from $LAN_PUBLIC_IP. Neither side sees any private IPs. 3. When DMZ host wants to connect with LAN client: > > You just reverse the order of the rules: ipfw add divert $lanport ip from $DMZ_PRIVATE_IP to $LAN_PUBLIC_IP in recv $DMZIF ipfw add allow ip from $DMZ_PRIVATE_IP to $LAN in recv $DMZIF ipfw add divert $dmzport ip from $DMZ_PRIVATE_IP to $LAN out xmit $LANIF ipfw add allow ip from $DMZ_PUBLIC_IP to $LAN out xmit $LANIF In generic terms, the packet flow is like this: src: lan private subnet dest: server public ip src: lan private subnet dest: server private ip src: lan private subnet dest: server private ip src: lan public ip dest: server private ip Note how you change first the destination IP via NAT (on the LAN interface); then you change the source IP via NAT (on the DMZ interface). If I want also to set up NAT rules for my LAN (to allow it to access the > Internet, and router), and also for my DMZ hosts (also for the Internet), > what should be the order of rules? > First 'LAN-DMZ', then 'DMZ', then 'LAN' ? > There's no hard-and-fast rules on how you should order your rules (at least, none that I've found anywhere). I prefer to write them such that you have the most specific rules first, and the most generic ones last. So my rulesets generally look like: - rules for the firewall itself - rules for vpn connections end-pointing on the firewall - rules for specific servers with public IPs - rules for the LAN (generally just outgoing traffic) - deny everything as the last rule In the set of rules for the specific servers, I'll split my incoming rules into two sections: from the Internet, from the LAN. That way, all the rules for accessing a specific server are together in one spot. You just have to remember what the LAN private subnet is, the LAN public (NAT) IP is, and the LAN divert port is, so you can use those in the rules for the specific servers. Having everything in one giant rules file, or including config files, helps. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Sep 29 21:23:29 2011 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 5DC851065677 for ; Thu, 29 Sep 2011 21:23:29 +0000 (UTC) (envelope-from marek.salwerowicz@misal.pl) Received: from mail2.misal.pl (mail2.misal.pl [83.19.131.172]) by mx1.freebsd.org (Postfix) with ESMTP id 008BD8FC12 for ; Thu, 29 Sep 2011 21:23:28 +0000 (UTC) Received: from [10.0.0.15] (cwx170.internetdsl.tpnet.pl [83.19.131.170]) by mail2.misal.pl (Postfix) with ESMTPSA id 77C088B3; Thu, 29 Sep 2011 23:08:02 +0200 (CEST) Message-ID: <4E84DE26.6030103@misal.pl> Date: Thu, 29 Sep 2011 23:07:50 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Freddie Cash , freebsd-net@freebsd.org References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> <4E84B447.7010509@wp.pl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 29 Sep 2011 22:20:17 +0000 Cc: Subject: Re: ipfw - accessing DMZ from LAN 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, 29 Sep 2011 21:23:29 -0000 W dniu 2011-09-29 21:57, Freddie Cash pisze: > > > In generic terms, the packet flow is like this: > > > src: lan private subnet dest: server public ip > > > src: lan private subnet dest: server private ip > > > src: lan private subnet dest: server private ip > > > src: lan public ip dest: server private ip > > > Note how you change first the destination IP via NAT (on the LAN interface); > then you change the source IP via NAT (on the DMZ interface). Ok, now I understood (I hope ;) ). My rules are: ipfw add 150 divert $DMZHOST1PORT ip from $LAN1NET to $DMZHOST1PUB in recv $LAN1IF ipfw add 155 allow ip from $LAN1NET to $DMZHOST1 in recv $LAN1IF ipfw add 160 divert $LAN1PORT ip from $LAN1NET to $DMZHOST1 out xmit $DMZIF ipfw add 165 allow ip from $MYPUBLICIP to $DMZHOST1 out xmit $DMZIF ipfw add 170 divert $LAN1PORT ip from $DMZHOST1 to $MYPUBLICIP in recv $DMZIF ipfw add 175 allow ip from $DMZHOST1 to $LAN1NET in recv $DMZIF ipfw add 180 divert $DMZHOST1PORT ip from $DMZHOST1 to $LAN1NET out xmit $LAN1IF ipfw add 185 allow ip from $DMZHOST1PUB to $LAN1NET out xmit $LAN1IF Names are a little different but the idea is the same (MYPUBLICIP == LAN_PUBLIC_IP) And it works. Thanks for help :) > > There's no hard-and-fast rules on how you should order your rules (at least, > none that I've found anywhere). > > I prefer to write them such that you have the most specific rules first, and > the most generic ones last. So eg. the rules specifying traffic between DMZ Host and LAN could be the first, and then rules for "generic" DMZ host traffic (allowing DMZ access to the Internet)? So far I made like this (first DMZ-LAN, then DMZ), but I have some problem: ipfw add 200 divert $DMZHOST1PORT ip from $DMZHOST1 to any in recv $DMZIF ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit $PUBLICIF ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv $PUBLICIF ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF ipfw add 230 divert $DMZHOST1PORT ip from any to $DMZHOST1 out xmit $DMZIF ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF The DMZ host has access to Internet (and is visible as public IP dedicated for that host, so it's what I wanted), but when I connect from the Internet to DMZ host (eg. ssh), I see that the connection comes from itself (DMZ host public IP), instead of real public IP address. I think that I've overNATed something. Do you have any idea? Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 00:13:17 2011 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 57956106564A for ; Fri, 30 Sep 2011 00:13:17 +0000 (UTC) (envelope-from mdfranz@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E4A328FC0A for ; Fri, 30 Sep 2011 00:13:16 +0000 (UTC) Received: by wwe3 with SMTP id 3so1767948wwe.31 for ; Thu, 29 Sep 2011 17:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YsmZHvMizSuNpakIXpvBl/8aaH2I2PjHT4fzF6qa9OM=; b=YD1xEo1tZDcUARbP21etxiHTKwwtmxh0oWzctF6bjCsB1vks++iL2DiCW9lfweQqYN 6m/gYO/rihnArNknuF1vLXkEsQnZ5lhs40n5vaBfMFlTF3B8+BTsZ9hYcuYIKJbn9Q3V HjrUwbLAZWc2TcFGeU/vIUEF6KozLwu+qp8VI= MIME-Version: 1.0 Received: by 10.216.203.79 with SMTP id e57mr1926794weo.12.1317340083308; Thu, 29 Sep 2011 16:48:03 -0700 (PDT) Received: by 10.180.103.5 with HTTP; Thu, 29 Sep 2011 16:48:03 -0700 (PDT) In-Reply-To: <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> Date: Thu, 29 Sep 2011 19:48:03 -0400 Message-ID: From: Matthew Franz To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" Subject: Re: bce(4) with IPMI 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, 30 Sep 2011 00:13:17 -0000 I have a pair of brand new R410's I've been using for CARP+PFSYNC pair. I believe the LOM was disabled by default and have not tried to use it, IIRC. Been using bce0 as the outside interface with no issues and bce1 as the sync.... I'm running FreeBSD 8.2 though. I can get more details about the hardware if it would be helpful... - mdf On Thu, Sep 29, 2011 at 3:10 PM, Sean Bruno wrote: > On Thu, 2011-09-29 at 10:01 -0700, Sean Bruno wrote: >> We've been getting reports of odd behavior on our Dell R410 machines >> when trying to use IPMI. =A0The servers have two NIC's that we have >> assigned as the IPMI interface(bce0) and production interface(bce1) >> respectively. >> >> Since we don't actually configure bce0 in FreeBSD, we've found that the >> IPMI interface deactivated when bce(4) loads. =A0I assume that the drive= r >> is not initializing the interface correctly in this case and the default >> case is to turn the interface off. =A0Does it make sense to completely >> turn off the interface when there is an active link on the port, but no >> configuration assigned? >> >> Sean >> >> p.s. Dell's IPMI implementation is ... um ... more difficult than it >> needs to be. >> > > I should probably say, this is freebsd7. =A0So I'll peruse the changelogs > and see if 7 is missing something here. > > sean > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 -- Matthew Franz mdfranz@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 00:28:28 2011 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 42176106564A for ; Fri, 30 Sep 2011 00:28:28 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id F41198FC13 for ; Fri, 30 Sep 2011 00:28:27 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p8U0SHTG034183; Thu, 29 Sep 2011 17:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317342497; bh=kAlQv7XtKfVK02u2aTkTHJvTisedNiHOwpalYDoc6NE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=g+UTIM713XLqXgu6v7TzMLkKoTYLCzSzV1eYwlmtIafl7j55k5DNAnu+zhKcuk0Bg VhwkUBJSySmU8vDXvUerDERE15asqbi1ZwrC6OWK1g2+EwttP+TMptQei/F/XDBQru a9pO9rNBtIbNRml7kSaJ1WoM0GoYAJd8/N4m8F/o= From: Sean Bruno To: Matthew Franz In-Reply-To: References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Sep 2011 17:28:17 -0700 Message-ID: <1317342497.2777.31.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: bce(4) with IPMI 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, 30 Sep 2011 00:28:28 -0000 On Thu, 2011-09-29 at 16:48 -0700, Matthew Franz wrote: > I have a pair of brand new R410's I've been using for CARP+PFSYNC > pair. I believe the LOM was disabled by default and have not tried to > use it, IIRC. Been using bce0 as the outside interface with no issues > and bce1 as the sync.... > > I'm running FreeBSD 8.2 though. I can get more details about the > hardware if it would be helpful... > Yeah, but are you using IPMI in this case? You message didn't indicate that. The issue is that the IPMI interface that is sharing the primary interface is dying when the system comes up with an "unconfigured" bce0. In your case, you are definitely configuring both interfaces. Sean From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 00:53:24 2011 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 90229106564A for ; Fri, 30 Sep 2011 00:53:24 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC638FC12 for ; Fri, 30 Sep 2011 00:53:24 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p8U0rGan041005; Thu, 29 Sep 2011 17:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317343996; bh=goKaCDOZDnu/5lLK9VoHFZLDm42oysQ+E7ML8besaNU=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=vkmZWstCUPUX1QlPDrXaXQO1xOCN0hunRxo7mPVsR7h1gHdU8Mk+XPfOiEpMnPLgL Wbyv59MvH/sJ76LWzRTxdOO7nmsJ1JEC48Ag9I/RkEitbnku7tNuHas/72wCmXW1Z0 n2jBqmL1TWTlt9nrJxgfXUHbcUBEP/Fvn7MXlSeY= From: Sean Bruno To: "freebsd-net@freebsd.org" In-Reply-To: <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Sep 2011 17:53:16 -0700 Message-ID: <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: davidch@freebsd.org, Pyun YongHyeon Subject: Re: bce(4) with IPMI 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, 30 Sep 2011 00:53:24 -0000 On Thu, 2011-09-29 at 12:10 -0700, Sean Bruno wrote: > On Thu, 2011-09-29 at 10:01 -0700, Sean Bruno wrote: > > We've been getting reports of odd behavior on our Dell R410 machines > > when trying to use IPMI. The servers have two NIC's that we have > > assigned as the IPMI interface(bce0) and production interface(bce1) > > respectively. > > > > Since we don't actually configure bce0 in FreeBSD, we've found that the > > IPMI interface deactivated when bce(4) loads. I assume that the driver > > is not initializing the interface correctly in this case and the default > > case is to turn the interface off. Does it make sense to completely > > turn off the interface when there is an active link on the port, but no > > configuration assigned? > > > > Sean > > > > p.s. Dell's IPMI implementation is ... um ... more difficult than it > > needs to be. > > > > I should probably say, this is freebsd7. So I'll peruse the changelogs > and see if 7 is missing something here. > > sean commenting this change out seems to be helping quite a bit with my issue. I think that this behavior may be wrong in the IPMI shared/nic case. Thoughts? http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210261&r2=210263 From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 01:04:43 2011 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 DB6D8106564A; Fri, 30 Sep 2011 01:04:43 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF588FC1A; Fri, 30 Sep 2011 01:04:42 +0000 (UTC) Received: by vcbf13 with SMTP id f13so1388259vcb.13 for ; Thu, 29 Sep 2011 18:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y00DAH8JemhdxrQyXGY9JWdYqnNtI+DlbW6BBwhJRuY=; b=IY8dEKhXzx5o3TIRDj8ove9JSKl/MLEYRLKKbDKkNh49zH2UwodoQ8/jM7Qkmc8J7X j975I2jJwmpZem+wS3aY/fanRzmsqeItmIxLf/wrWbm7Qa/xKuqAoQQNe8tdeI2yO9Zz xIf5WM4BCGN1TjTwcpLauL+2B6bQOvnkEYgMw= MIME-Version: 1.0 Received: by 10.52.175.230 with SMTP id cd6mr11376598vdc.251.1317344682490; Thu, 29 Sep 2011 18:04:42 -0700 (PDT) Received: by 10.52.107.194 with HTTP; Thu, 29 Sep 2011 18:04:42 -0700 (PDT) In-Reply-To: References: <8662kcigif.fsf@kopusha.home.net> Date: Fri, 30 Sep 2011 09:04:42 +0800 Message-ID: From: dave jones To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: Mikolaj Golub , "freebsd-net@freebsd.org" , "K. Macy" , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 30 Sep 2011 01:04:43 -0000 On Thu, Sep 29, 2011 at 10:25 AM, Adrian Chadd wrote: > .. so now there's a patch: > > * is there a PR for this? > * if there is, can we get this patch and the discussion about this bug > placed in the PR? :) > > That way it doesn't get lost. No, I lie. It doesn't get "too lost". :-) What are you waiting for? The issue is reproducible. If you're running FreeBSD 9 with Mikolaj's test_udp program, you'll get the kernel panic. I think sysadmins won't be happy about this... > Adrian Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 01:49:31 2011 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 261A9106566C; Fri, 30 Sep 2011 01:49:31 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 099E38FC13; Fri, 30 Sep 2011 01:49:30 +0000 (UTC) Received: from [127.0.0.1] (proxy6.corp.yahoo.com [216.145.48.19]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p8U1d8VP061195; Thu, 29 Sep 2011 18:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1317346749; bh=s++EWSCft5ncK2OJQy5RWnHcko2c+P9jT8UU2P5xmGs=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=gY1yIi7dMUlh/udb1YOsiPnzdgO2wNiIOhkyksOohbm0XIKMNUuIg9A8/UYwq3fzr XndQ2VYiqyrFPUFDZctF3jy1a6/Sbwi34YhTr86o7mI69cl/fOCx9AOqrGa+2lNSTW imKp3l20pRkR35nc25BstZv5kzzNqWCwDsepdb5E= From: Sean Bruno To: "freebsd-net@freebsd.org" In-Reply-To: <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Sep 2011 18:39:08 -0700 Message-ID: <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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, 30 Sep 2011 01:49:31 -0000 On Thu, 2011-09-29 at 17:53 -0700, Sean Bruno wrote: > On Thu, 2011-09-29 at 12:10 -0700, Sean Bruno wrote: > > On Thu, 2011-09-29 at 10:01 -0700, Sean Bruno wrote: > > > We've been getting reports of odd behavior on our Dell R410 machines > > > when trying to use IPMI. The servers have two NIC's that we have > > > assigned as the IPMI interface(bce0) and production interface(bce1) > > > respectively. > > > > > > Since we don't actually configure bce0 in FreeBSD, we've found that the > > > IPMI interface deactivated when bce(4) loads. I assume that the driver > > > is not initializing the interface correctly in this case and the default > > > case is to turn the interface off. Does it make sense to completely > > > turn off the interface when there is an active link on the port, but no > > > configuration assigned? > > > > > > Sean > > > > > > p.s. Dell's IPMI implementation is ... um ... more difficult than it > > > needs to be. > > > > > > > I should probably say, this is freebsd7. So I'll peruse the changelogs > > and see if 7 is missing something here. > > > > sean > > commenting this change out seems to be helping quite a bit with my > issue. I think that this behavior may be wrong in the IPMI shared/nic > case. Thoughts? > > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210261&r2=210263 Just a bit more here. bce0: mem 0xda000000-0xdbffffff irq 36 at device 0.0 on pci1 bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xda000000 bce0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 256 to vector 49 bce0: using IRQ 256 for MSI miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x0050ef, model 0x003c, rev. 8 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce0: bpf attached bce0: Ethernet address: 78:2b:cb:38:f1:cf bce0: [MPSAFE] bce0: [ITHREAD] bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3); Flags (MSI|MFW); MFW (NCSI 2.0.11) bce1: mem 0xdc000000-0xddffffff irq 48 at device 0.1 on pci1 bce1: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xdc000000 bce1: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 257 to vector 50 bce1: using IRQ 257 for MSI miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: OUI 0x0050ef, model 0x003c, rev. 8 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce1: bpf attached bce1: Ethernet address: 78:2b:cb:38:f1:d0 bce1: [MPSAFE] bce1: [ITHREAD] bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.3); Flags (MSI|MFW); MFW (NCSI 2.0.11) From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 01:58:32 2011 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 97661106566C; Fri, 30 Sep 2011 01:58:32 +0000 (UTC) (envelope-from adrian.chadd@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 2ACEC8FC0C; Fri, 30 Sep 2011 01:58:31 +0000 (UTC) Received: by yxk36 with SMTP id 36so1500350yxk.13 for ; Thu, 29 Sep 2011 18:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ATj6B1MwTiKNhiNmgC+k/fdDrp3TCMDlJbRynJHwM8s=; b=OTDZ5GsvD2TpcT9s8qEz5I49BkV5Lmxdx4YmKZClaS7julmEPlgaZ1vHI8N+ejnjcp 1SzYUrD0LQpZWM3lspXYGCR5U03mqx0jL4toRhOv4fJUMsnvS73T+uOLtQuepDleooQo FFTDTGZ1Xk/ZVR2uPX6fzUdV3JcY+V9lW8ECI= MIME-Version: 1.0 Received: by 10.236.124.97 with SMTP id w61mr67917967yhh.106.1317347911415; Thu, 29 Sep 2011 18:58:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Thu, 29 Sep 2011 18:58:31 -0700 (PDT) In-Reply-To: References: <8662kcigif.fsf@kopusha.home.net> Date: Fri, 30 Sep 2011 09:58:31 +0800 X-Google-Sender-Auth: SjLlv861DhVRbu878Ym5TaQ7_7s Message-ID: From: Adrian Chadd To: dave jones Content-Type: text/plain; charset=ISO-8859-1 Cc: Mikolaj Golub , "freebsd-net@freebsd.org" , "K. Macy" , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 30 Sep 2011 01:58:32 -0000 On 30 September 2011 09:04, dave jones wrote: > What are you waiting for? The issue is reproducible. If you're running > FreeBSD 9 with Mikolaj's test_udp program, you'll get the kernel panic. > I think sysadmins won't be happy about this... Well, the people familiar with the network stack need to weigh in. I'll poke Robert Watson and see what he thinks. Adrian From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 07:48:59 2011 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 8FB18106564A for ; Fri, 30 Sep 2011 07:48:59 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id E28918FC0A for ; Fri, 30 Sep 2011 07:48:58 +0000 (UTC) Received: (qmail 28802 invoked by uid 0); 30 Sep 2011 07:48:57 -0000 Received: from 93.159.253.120 by rms-de009.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Fri, 30 Sep 2011 09:48:56 +0200 From: "Rainer Bredehorn" Message-ID: <20110930074856.282760@gmx.net> MIME-Version: 1.0 To: freebsd-net@FreeBSD.org X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: X0K2ehYmTXsuQqz1Y2Q5Bn5CRzdyMkMs Cc: Subject: Re: IPv6 multicast listener discovery 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, 30 Sep 2011 07:48:59 -0000 >  Could you show us more specifics about your configuration and packet >  dump in question? Yes! It's the FreeBSD 8.2 release. The only thing which is activated in the rc.conf is ipv6. I've included the ifconfig output and a wireshark capture. The capture is taken during the startup of the FreeBSD system. I would like to know where the address ff02::2:2d75:f2b8 comes from. ------------------------------------------------------- ifconfig -mL plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 capabilities=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 nd6 options=3 rl0: flags=8843 metric 0 mtu 1500 options=3808 capabilities=3808 ether 00:50:fc:b8:54:43 inet6 fe80::250:fcff:feb8:5443%rl0 prefixlen 64 scopeid 0x3 inet 192.168.10.75 netmask 0xffffff00 broadcast 192.168.10.255 nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active supported media: media autoselect media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media 100baseTX mediaopt hw-loopback ----------------------------------------------------------- wireshark capture No.     Time        Source                Destination           Protocol Info      1 0.000000    ::                    ff02::16              ICMPv6   Multicast Listener Report Message v2 Frame 1: 90 bytes on wire (720 bits), 90 bytes captured (720 bits)    Arrival Time: Sep 29, 2011 09:11:06.785821000 UTC    Epoch Time: 1317287466.785821000 seconds    [Time delta from previous captured frame: 0.000000000 seconds]    [Time delta from previous displayed frame: 0.000000000 seconds]    [Time since reference or first frame: 0.000000000 seconds]    Frame Number: 1    Frame Length: 90 bytes (720 bits)    Capture Length: 90 bytes (720 bits)    [Frame is marked: False]    [Frame is ignored: False]    [Protocols in frame: eth:ipv6:icmpv6]    [Coloring Rule Name: ICMP]    [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43), Dst: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)    Destination: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)        Address: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)    Source: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        Address: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)    Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: :: (::), Dst: ff02::16 (ff02::16)    0110 .... = Version: 6        [0110 .... = This field makes the filter "ip.version == 6" possible: 6]    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000        .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)        .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set        .... .... ...0 .... .... .... .... .... = ECN-CE: Not set    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000    Payload length: 36    Next header: IPv6 hop-by-hop option (0x00)    Hop limit: 1    Source: :: (::)    Destination: ff02::16 (ff02::16)    Hop-by-Hop Option        Next header: ICMPv6 (0x3a)        Length: 0 (8 bytes)        PadN: 2 bytes        Router alert: MLD (4 bytes) Internet Control Message Protocol v6    Type: 143 (Multicast Listener Report Message v2)    Code: 0 (Should always be zero)    Checksum: 0x1a8f [correct]    Reserved: 0 (Should always be zero)    Number of records: 1    Changed to exclude: ff02::1:ffb8:5443 (ff02::1:ffb8:5443)        Mode: Changed to exclude (4)        Aux data len: 0        Number of Sources: 0        Multicast Address: ff02::1:ffb8:5443 No.     Time        Source                Destination           Protocol Info      2 0.000097    ::                    ff02::1:ffb8:5443     ICMPv6   Neighbor solicitation for fe80::250:fcff:feb8:5443 Frame 2: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)    Arrival Time: Sep 29, 2011 09:11:06.785918000 UTC    Epoch Time: 1317287466.785918000 seconds    [Time delta from previous captured frame: 0.000097000 seconds]    [Time delta from previous displayed frame: 0.000097000 seconds]    [Time since reference or first frame: 0.000097000 seconds]    Frame Number: 2    Frame Length: 78 bytes (624 bits)    Capture Length: 78 bytes (624 bits)    [Frame is marked: False]    [Frame is ignored: False]    [Protocols in frame: eth:ipv6:icmpv6]    [Coloring Rule Name: ICMP]    [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43), Dst: IPv6mcast_ff:b8:54:43 (33:33:ff:b8:54:43)    Destination: IPv6mcast_ff:b8:54:43 (33:33:ff:b8:54:43)        Address: IPv6mcast_ff:b8:54:43 (33:33:ff:b8:54:43)        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)    Source: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        Address: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)    Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: :: (::), Dst: ff02::1:ffb8:5443 (ff02::1:ffb8:5443)    0110 .... = Version: 6        [0110 .... = This field makes the filter "ip.version == 6" possible: 6]    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000        .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)        .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set        .... .... ...0 .... .... .... .... .... = ECN-CE: Not set    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000    Payload length: 24    Next header: ICMPv6 (0x3a)    Hop limit: 255    Source: :: (::)    Destination: ff02::1:ffb8:5443 (ff02::1:ffb8:5443) Internet Control Message Protocol v6    Type: 135 (Neighbor solicitation)    Code: 0    Checksum: 0xd4df [correct]    Reserved: 0 (Should always be zero)    Target: fe80::250:fcff:feb8:5443 (fe80::250:fcff:feb8:5443) No.     Time        Source                Destination           Protocol Info      3 0.000182    ::                    ff02::16              ICMPv6   Multicast Listener Report Message v2 Frame 3: 90 bytes on wire (720 bits), 90 bytes captured (720 bits)    Arrival Time: Sep 29, 2011 09:11:06.786003000 UTC    Epoch Time: 1317287466.786003000 seconds    [Time delta from previous captured frame: 0.000085000 seconds]    [Time delta from previous displayed frame: 0.000085000 seconds]    [Time since reference or first frame: 0.000182000 seconds]    Frame Number: 3    Frame Length: 90 bytes (720 bits)    Capture Length: 90 bytes (720 bits)    [Frame is marked: False]    [Frame is ignored: False]    [Protocols in frame: eth:ipv6:icmpv6]    [Coloring Rule Name: ICMP]    [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43), Dst: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)    Destination: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)        Address: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)    Source: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        Address: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)    Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: :: (::), Dst: ff02::16 (ff02::16)    0110 .... = Version: 6        [0110 .... = This field makes the filter "ip.version == 6" possible: 6]    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000        .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)        .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set        .... .... ...0 .... .... .... .... .... = ECN-CE: Not set    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000    Payload length: 36    Next header: IPv6 hop-by-hop option (0x00)    Hop limit: 1    Source: :: (::)    Destination: ff02::16 (ff02::16)    Hop-by-Hop Option        Next header: ICMPv6 (0x3a)        Length: 0 (8 bytes)        PadN: 2 bytes        Router alert: MLD (4 bytes) Internet Control Message Protocol v6    Type: 143 (Multicast Listener Report Message v2)    Code: 0 (Should always be zero)    Checksum: 0x4e5c [correct]    Reserved: 0 (Should always be zero)    Number of records: 1    Changed to exclude: ff02::2:2d75:f2b8 (ff02::2:2d75:f2b8)        Mode: Changed to exclude (4)        Aux data len: 0        Number of Sources: 0        Multicast Address: ff02::2:2d75:f2b8 No.     Time        Source                Destination           Protocol Info      4 0.000285    ::                    ff02::16              ICMPv6   Multicast Listener Report Message v2 Frame 4: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)    Arrival Time: Sep 29, 2011 09:11:06.786106000 UTC    Epoch Time: 1317287466.786106000 seconds    [Time delta from previous captured frame: 0.000103000 seconds]    [Time delta from previous displayed frame: 0.000103000 seconds]    [Time since reference or first frame: 0.000285000 seconds]    Frame Number: 4    Frame Length: 110 bytes (880 bits)    Capture Length: 110 bytes (880 bits)    [Frame is marked: False]    [Frame is ignored: False]    [Protocols in frame: eth:ipv6:icmpv6]    [Coloring Rule Name: ICMP]    [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43), Dst: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)    Destination: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)        Address: IPv6mcast_00:00:00:16 (33:33:00:00:00:16)        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)    Source: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        Address: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)    Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: :: (::), Dst: ff02::16 (ff02::16)    0110 .... = Version: 6        [0110 .... = This field makes the filter "ip.version == 6" possible: 6]    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000        .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)        .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set        .... .... ...0 .... .... .... .... .... = ECN-CE: Not set    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000    Payload length: 56    Next header: IPv6 hop-by-hop option (0x00)    Hop limit: 1    Source: :: (::)    Destination: ff02::16 (ff02::16)    Hop-by-Hop Option        Next header: ICMPv6 (0x3a)        Length: 0 (8 bytes)        PadN: 2 bytes        Router alert: MLD (4 bytes) Internet Control Message Protocol v6    Type: 143 (Multicast Listener Report Message v2)    Code: 0 (Should always be zero)    Checksum: 0xf746 [correct]    Reserved: 0 (Should always be zero)    Number of records: 2    Changed to exclude: ff02::2:2d75:f2b8 (ff02::2:2d75:f2b8)        Mode: Changed to exclude (4)        Aux data len: 0        Number of Sources: 0        Multicast Address: ff02::2:2d75:f2b8    Changed to exclude: ff02::1:ffb8:5443 (ff02::1:ffb8:5443)        Mode: Changed to exclude (4)        Aux data len: 0        Number of Sources: 0        Multicast Address: ff02::1:ffb8:5443 No.     Time        Source                Destination           Protocol Info      5 0.000354    fe80::250:fcff:feb8:5443 ff02::2               ICMPv6   Router solicitation from 00:50:fc:b8:54:43 Frame 5: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)    Arrival Time: Sep 29, 2011 09:11:06.786175000 UTC    Epoch Time: 1317287466.786175000 seconds    [Time delta from previous captured frame: 0.000069000 seconds]    [Time delta from previous displayed frame: 0.000069000 seconds]    [Time since reference or first frame: 0.000354000 seconds]    Frame Number: 5    Frame Length: 70 bytes (560 bits)    Capture Length: 70 bytes (560 bits)    [Frame is marked: False]    [Frame is ignored: False]    [Protocols in frame: eth:ipv6:icmpv6]    [Coloring Rule Name: ICMP]    [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43), Dst: IPv6mcast_00:00:00:02 (33:33:00:00:00:02)    Destination: IPv6mcast_00:00:00:02 (33:33:00:00:00:02)        Address: IPv6mcast_00:00:00:02 (33:33:00:00:00:02)        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)    Source: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        Address: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)    Type: IPv6 (0x86dd) Internet Protocol Version 6, Src: fe80::250:fcff:feb8:5443 (fe80::250:fcff:feb8:5443), Dst: ff02::2 (ff02::2)    0110 .... = Version: 6        [0110 .... = This field makes the filter "ip.version == 6" possible: 6]    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000        .... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)        .... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set        .... .... ...0 .... .... .... .... .... = ECN-CE: Not set    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000    Payload length: 16    Next header: ICMPv6 (0x3a)    Hop limit: 255    Source: fe80::250:fcff:feb8:5443 (fe80::250:fcff:feb8:5443)    [Source SA MAC: EdimaxTe_b8:54:43 (00:50:fc:b8:54:43)]    Destination: ff02::2 (ff02::2) Internet Control Message Protocol v6    Type: 133 (Router solicitation)    Code: 0    Checksum: 0xd895 [correct]    ICMPv6 Option (Source link-layer address)        Type: Source link-layer address (1)        Length: 8        Link-layer address: 00:50:fc:b8:54:43 From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 10:04:10 2011 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 9D4C31065674 for ; Fri, 30 Sep 2011 10:04:10 +0000 (UTC) (envelope-from yilinjing@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBE58FC0C for ; Fri, 30 Sep 2011 10:04:10 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1R9ZhR-0004UD-Mz for freebsd-net@freebsd.org; Fri, 30 Sep 2011 02:48:09 -0700 Date: Fri, 30 Sep 2011 02:48:09 -0700 (PDT) From: jyl To: freebsd-net@freebsd.org Message-ID: <1317376089705-4856441.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: when enable options SCTP_DEBUG in kernel configure file , where to get the message of debug? 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, 30 Sep 2011 10:04:10 -0000 My Os is FreeBSD 9.0 Beta2. In kernel configure file, I enable the option of SCTP_DEBUG and rebuild the kernel. Then I use sctp to send or recv data from another computer ,after that I check the result from var/log/message or var/log/dmesg , both of the two files show any message about sctp debug. can anyone help me, why it does not work? Regards. -- View this message in context: http://freebsd.1045724.n5.nabble.com/when-enable-options-SCTP-DEBUG-in-kernel-configure-file-where-to-get-the-message-of-debug-tp4856441p4856441.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 10:49:57 2011 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 D59871065673 for ; Fri, 30 Sep 2011 10:49:57 +0000 (UTC) (envelope-from pluknet@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 984818FC13 for ; Fri, 30 Sep 2011 10:49:57 +0000 (UTC) Received: by yxk36 with SMTP id 36so1856862yxk.13 for ; Fri, 30 Sep 2011 03:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=136CmXty5CpqRKhHd6uXv/N3UUnILsXKb7BhXPQEjRs=; b=LVrl2rHTUtWFh5RbS9tAppXqKo5eLi0LEYnUNYzjnPw7pfnTXBrzf/z0ZRBQg+msdT kGAZCXt8/6d4rlXjnbWd8yTd8A299UttpqbJ2gJZCsmrqWTY+tFGsrwZgo4dlpgWkO5n VzrChmZSGwSS7Z2DMe0z9vZQ+47Lq2lbsr9lA= MIME-Version: 1.0 Received: by 10.150.63.2 with SMTP id l2mr11246653yba.63.1317379796894; Fri, 30 Sep 2011 03:49:56 -0700 (PDT) Received: by 10.151.12.6 with HTTP; Fri, 30 Sep 2011 03:49:56 -0700 (PDT) In-Reply-To: <1317376089705-4856441.post@n5.nabble.com> References: <1317376089705-4856441.post@n5.nabble.com> Date: Fri, 30 Sep 2011 14:49:56 +0400 Message-ID: From: Sergey Kandaurov To: jyl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: when enable options SCTP_DEBUG in kernel configure file , where to get the message of debug? 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, 30 Sep 2011 10:49:57 -0000 On 30 September 2011 13:48, jyl wrote: > My Os is FreeBSD 9.0 Beta2. > In kernel configure file, =A0I enable the option of SCTP_DEBUG and rebuil= d the > kernel. Then I use sctp to send or recv data from another computer ,after > that I check the result from var/log/message or var/log/dmesg , both of t= he > two files show any message about sctp debug. > > can anyone help me, why it does not work? > Hi, you probably also need to actually enable it. Try this: sysctl net.inet.sctp.debug =3D 1 --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 10:57:28 2011 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 07CFA1065675 for ; Fri, 30 Sep 2011 10:57:28 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 92EBD8FC12 for ; Fri, 30 Sep 2011 10:57:27 +0000 (UTC) Received: from [IPv6:2001:638:506:21:224:36ff:feef:67d1] (unknown [IPv6:2001:638:506:21:224:36ff:feef:67d1]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1BCB41C0C0BCE; Fri, 30 Sep 2011 12:57:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <1317376089705-4856441.post@n5.nabble.com> Date: Fri, 30 Sep 2011 12:57:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1317376089705-4856441.post@n5.nabble.com> To: jyl X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: when enable options SCTP_DEBUG in kernel configure file , where to get the message of debug? 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, 30 Sep 2011 10:57:28 -0000 On Sep 30, 2011, at 11:48 AM, jyl wrote: > My Os is FreeBSD 9.0 Beta2. > In kernel configure file, I enable the option of SCTP_DEBUG and = rebuild the > kernel. Then I use sctp to send or recv data from another computer = ,after > that I check the result from var/log/message or var/log/dmesg , both = of the > two files show any message about sctp debug. >=20 > can anyone help me, why it does not work? There is a sysctl variable net.inet.sctp.debug which is a 32-bit bitmask to enable/disable the debug output. To enable all debug output you need = to do sudo sysctl -w net.inet.sctp.debug=3D0xffffffff Best regards Michael >=20 > Regards.=20 >=20 > -- > View this message in context: = http://freebsd.1045724.n5.nabble.com/when-enable-options-SCTP-DEBUG-in-ker= nel-configure-file-where-to-get-the-message-of-debug-tp4856441p4856441.htm= l > Sent from the freebsd-net mailing list archive at Nabble.com. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 13:41:14 2011 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 668FF1065670; Fri, 30 Sep 2011 13:41:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA4A8FC12; Fri, 30 Sep 2011 13:41:14 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CDD4E46B3C; Fri, 30 Sep 2011 09:41:13 -0400 (EDT) Date: Fri, 30 Sep 2011 14:41:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mikolaj Golub In-Reply-To: <8662kcigif.fsf@kopusha.home.net> Message-ID: References: <8662kcigif.fsf@kopusha.home.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "freebsd-net@freebsd.org" , Adrian Chadd , "K. Macy" , Arnaud Lacombe , dave jones Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 30 Sep 2011 13:41:14 -0000 On Wed, 28 Sep 2011, Mikolaj Golub wrote: > On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: > > KM> Sorry, didn't look at the images (limited bw), I've seen something KM> > like this before in timewait. This "can't happen" with UDP so will be KM> > interested in learning more about the bug. > > The panic can be easily triggered by this: Hi: Just catching up on this thread. I think the analysis here is generally right: in 9.0, you're much more likely to see an inpcb with its in_socket pointer cleared in the hash list than in prior releases, and in_pcbbind_setup() trips over this. However, at least on first glance (and from the perspective of invariants here), I think the bug is actualy that in_pcbbind_setup() is asking in_pcblookup_local() for an inpcb and then access the returned inpcb's in_socket pointer without acquiring a lock on the inpcb. Structurally, it can't acquire this lock for lock order reasons -- it already holds the lock on its own inpcb. Therefore, we should only access fields that are safe to follow in an inpcb when you hold a reference via the hash lock and not a lock on the inpcb itself, which appears generally OK (+/-) for all the fields in that clause but the t->inp_socket->so_options dereference. A preferred fix would cache the SO_REUSEPORT flag in an inpcb-layer field, such as inp_flags2, giving us access to its value without having to walk into the attached (or not) socket. This raises another structural question, which is whether we need a new inp_foo flags field that is protected explicitly by the hash lock, and not by the inpcb lock, which could hold fields relevant to address binding. I don't think we need to solve that problem in this context, as a slightly race on SO_REUSEPORT is likely acceptable. The suggested fix does perform the desired function of explicitly detaching the inpcb from the hash list before the socket is disconnected from the inpcb. However, it's incomplete in that the invariant that's being broken is also relied on for other protocols (such as raw sockets). The correct invariant is that inp_socket is safe to follow unconditionally if an inpcb is locked and INP_DROPPED isn't set -- the bug is in "locked" not in "INP_DROPPED", which is why I think this is the wrong fix, even though it prevents a panic :-). Robert From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 14:57:31 2011 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 6EF95106566C for ; Fri, 30 Sep 2011 14:57:31 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id D85978FC12 for ; Fri, 30 Sep 2011 14:57:30 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 6846 invoked from network); 30 Sep 2011 16:57:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1317394647; bh=nHaYcIBp/skHGE/LLi6b9ZBaheXWwr5bW5GcsrlnKqY=; h=From:To:Subject; b=RXox2XvzLa+speS4HLlwQ6BXcnlOJwReNioB90SURHQeQ6og9lRM4AFmytWlfWsLS MN+BqVRD9vdZgVkCbfEPJvaqoWQBficoqGwSgL5BqMr8blMuTD/1HZF+E147Z0gyW/ C3JOARupaQEUQI3z8HC3AczAC/mPLIZvE9gpyhKQ= Received: from cwx170.internetdsl.tpnet.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 30 Sep 2011 16:57:26 +0200 Message-ID: <4E85D8CB.6010104@wp.pl> Date: Fri, 30 Sep 2011 16:57:15 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Freddie Cash , freebsd-net@freebsd.org References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> <4E84B447.7010509@wp.pl> <4E84DE26.6030103@misal.pl> In-Reply-To: <4E84DE26.6030103@misal.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [0aP0] Cc: Subject: Re: ipfw - accessing DMZ from LAN 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, 30 Sep 2011 14:57:31 -0000 W dniu 2011-09-29 23:07, Marek Salwerowicz pisze: > So eg. the rules specifying traffic between DMZ Host and LAN could be > the first, and then rules for "generic" DMZ host traffic (allowing DMZ > access to the Internet)? > So far I made like this (first DMZ-LAN, then DMZ), but I have some > problem: > > ipfw add 200 divert $DMZHOST1PORT ip from $DMZHOST1 to any in recv $DMZIF > ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF > > ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit > $PUBLICIF > ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF > > ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv > $PUBLICIF > ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF > > ipfw add 230 divert $DMZHOST1PORT ip from any to $DMZHOST1 out xmit > $DMZIF > ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF > > The DMZ host has access to Internet (and is visible as public IP > dedicated for that host, so it's what I wanted), but when I connect > from the Internet to DMZ host (eg. ssh), I see that the connection > comes from itself (DMZ host public IP), instead of real public IP > address. > I think that I've overNATed something. > I've answered myself: ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit $PUBLICIF ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv $PUBLICIF ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF So I just removed rules responsible for NAT at $DMZIF and left only NAT at $PUBLICIF. But now there is next problem - when I try to ping /ssh from router to $DMZPUBLICIP, I connect to myself, instead of DMZ host.. From owner-freebsd-net@FreeBSD.ORG Fri Sep 30 15:44:18 2011 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 277EC1065673 for ; Fri, 30 Sep 2011 15:44:18 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D6D5D8FC0A for ; Fri, 30 Sep 2011 15:44:17 +0000 (UTC) Received: by vcbf13 with SMTP id f13so2026718vcb.13 for ; Fri, 30 Sep 2011 08:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zJCAezYDsRzsdoPmkmgsx5jXhJnsyqSo90L1Me6Q2wQ=; b=OiMmPlrXYETvUyip/0ieEP4ARKaomWhBeVL7okMsPH4xczHKMjqOOFhekdOWfS5HD+ dFn47PjBByGVujzyicaOP0+RlYt8atCK6+0JA+t6Gh2c/2GphylVmO2DByLIebxc+WRo t4qdaTYXTZ1x3RZIvcsRWNt7u9nbZqEOkp01o= MIME-Version: 1.0 Received: by 10.220.141.144 with SMTP id m16mr3398124vcu.107.1317397457132; Fri, 30 Sep 2011 08:44:17 -0700 (PDT) Received: by 10.220.186.196 with HTTP; Fri, 30 Sep 2011 08:44:16 -0700 (PDT) In-Reply-To: <4E85D8CB.6010104@wp.pl> References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> <4E84B447.7010509@wp.pl> <4E84DE26.6030103@misal.pl> <4E85D8CB.6010104@wp.pl> Date: Fri, 30 Sep 2011 08:44:16 -0700 Message-ID: From: Freddie Cash To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 30 Sep 2011 15:44:18 -0000 On Fri, Sep 30, 2011 at 7:57 AM, Marek Salwerowicz wrote: > W dniu 2011-09-29 23:07, Marek Salwerowicz pisze: > > So eg. the rules specifying traffic between DMZ Host and LAN could be the >> first, and then rules for "generic" DMZ host traffic (allowing DMZ access to >> the Internet)? >> So far I made like this (first DMZ-LAN, then DMZ), but I have some >> problem: >> >> ipfw add 200 divert $DMZHOST1PORT ip from $DMZHOST1 to any in recv $DMZIF >> ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF >> >> ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit >> $PUBLICIF >> ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF >> >> ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv >> $PUBLICIF >> ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF >> >> ipfw add 230 divert $DMZHOST1PORT ip from any to $DMZHOST1 out xmit $DMZIF >> ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF >> >> The DMZ host has access to Internet (and is visible as public IP dedicated >> for that host, so it's what I wanted), but when I connect from the Internet >> to DMZ host (eg. ssh), I see that the connection comes from itself (DMZ host >> public IP), instead of real public IP address. >> I think that I've overNATed something. >> >> I've answered myself: > > > ipfw add 205 allow ip from $DMZHOST1 to any in recv $DMZIF > > ipfw add 210 divert $DMZHOST1PORT ip from $DMZHOST1 to any out xmit > $PUBLICIF > ipfw add 215 allow ip from $DMZHOST1PUB to any out xmit $PUBLICIF > > ipfw add 220 divert $DMZHOST1PORT ip from any to $DMZHOST1PUB in recv > $PUBLICIF > ipfw add 225 allow ip from any to $DMZHOST1 in recv $PUBLICIF > > > > ipfw add 235 allow ip from any to $DMZHOST1 out xmit $DMZIF > > So I just removed rules responsible for NAT at $DMZIF and left only NAT at > $PUBLICIF. > > But now there is next problem - when I try to ping /ssh from router to > $DMZPUBLICIP, I connect to myself, instead of DMZ host.. > > I'm guessing the router is the FreeBSD box running IPFW? If so, then that's the correct behaviour, as the public IPs are physically assigned to the interfaces on the router. Thus, connecting to the public IPs from the router ... will connect to the router. You need to ping the private IPs from the router, since the router is directly connected to the private networks. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Sat Oct 1 06:15:47 2011 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 485F9106564A; Sat, 1 Oct 2011 06:15:47 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id BA51F8FC08; Sat, 1 Oct 2011 06:15:46 +0000 (UTC) Received: by vws11 with SMTP id 11so2582828vws.13 for ; Fri, 30 Sep 2011 23:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xziKnvwtKl9ezSgUwcQXBP0wWVUpu43G5zpi+5TGs5E=; b=kGEdErG36N/X6T5SmsHGeG1dI5G1YbKT2dj8HBGU+V45YYAv62bAKGWDEJBa9jFfUz ZlE1o/hGW/TCboF6p0A7rr+XUNN5MEo4Qm6/0qTiUrDWTADX77telhayxbXtOeO4O7xh UVwv8r41ZfOZ3kb23GxP3JYILuq8ODyPN4Kwk= MIME-Version: 1.0 Received: by 10.52.94.109 with SMTP id db13mr8924081vdb.318.1317449745940; Fri, 30 Sep 2011 23:15:45 -0700 (PDT) Received: by 10.52.107.194 with HTTP; Fri, 30 Sep 2011 23:15:45 -0700 (PDT) In-Reply-To: References: <8662kcigif.fsf@kopusha.home.net> Date: Sat, 1 Oct 2011 14:15:45 +0800 Message-ID: From: dave jones To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mikolaj Golub , "freebsd-net@freebsd.org" , Adrian Chadd , "K. Macy" , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 01 Oct 2011 06:15:47 -0000 On Fri, Sep 30, 2011 at 9:41 PM, Robert Watson wrote: > > On Wed, 28 Sep 2011, Mikolaj Golub wrote: > >> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: >> >> KM> Sorry, didn't look at the images (limited bw), I've seen something K= M> >> like this before in timewait. This "can't happen" with UDP so will be KM= > >> interested in learning more about the bug. >> >> The panic can be easily triggered by this: > > Hi: > > Just catching up on this thread. =A0I think the analysis here is generall= y > right: in 9.0, you're much more likely to see an inpcb with its in_socket > pointer cleared in the hash list than in prior releases, and > in_pcbbind_setup() trips over this. > > However, at least on first glance (and from the perspective of invariants > here), I think the bug is actualy that in_pcbbind_setup() is asking > in_pcblookup_local() for an inpcb and then access the returned inpcb's > in_socket pointer without acquiring a lock on the inpcb. =A0Structurally,= it > can't acquire this lock for lock order reasons -- it already holds the lo= ck > on its own inpcb. =A0Therefore, we should only access fields that are saf= e to > follow in an inpcb when you hold a reference via the hash lock and not a > lock on the inpcb itself, which appears generally OK (+/-) for all the > fields in that clause but the t->inp_socket->so_options dereference. > > A preferred fix would cache the SO_REUSEPORT flag in an inpcb-layer field= , > such as inp_flags2, giving us access to its value without having to walk > into the attached (or not) socket. > > This raises another structural question, which is whether we need a new > inp_foo flags field that is protected explicitly by the hash lock, and no= t > by the inpcb lock, which could hold fields relevant to address binding. = =A0I > don't think we need to solve that problem in this context, as a slightly > race on SO_REUSEPORT is likely acceptable. > > The suggested fix does perform the desired function of explicitly detachi= ng > the inpcb from the hash list before the socket is disconnected from the > inpcb. However, it's incomplete in that the invariant that's being broken= is > also relied on for other protocols (such as raw sockets). =A0The correct > invariant is that inp_socket is safe to follow unconditionally if an inpc= b > is locked and INP_DROPPED isn't set -- the bug is in "locked" not in > "INP_DROPPED", which is why I think this is the wrong fix, even though it > prevents a panic :-). Hello Robert, Thank you for taking your valuable time to find out the problem. Since I don't have idea about network internals, would you have a patch about this? I'd be glad to test it, thanks again. > Robert Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Sat Oct 1 19:16:38 2011 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 8D726106566B for ; Sat, 1 Oct 2011 19:16:38 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 069D48FC12 for ; Sat, 1 Oct 2011 19:16:37 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 20416 invoked from network); 1 Oct 2011 21:16:35 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1317496595; bh=05feFn/zw2mxwVoyzVgnpL+9vkRSkNHfglX52GFGXj4=; h=From:To:Subject; b=tVtg9Idzli/WWgc5YB4MdzlWAPQ1dJtcJ/PfhUkDGBeXPiAyInh/HDSa2CXmRTWSg dzA6JNVRHm0XQEIPXjiMNRltsU0tL6EctLvwwB/JAFKZ/IJpEccCqMTUUfAgstCCwT +e/Q0m7Iw91Ner1rl67PnPJK9Ps5673ebHNlDpxg= Received: from cwx170.internetdsl.tpnet.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 1 Oct 2011 21:16:35 +0200 Message-ID: <4E876705.3040806@wp.pl> Date: Sat, 01 Oct 2011 21:16:21 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Freddie Cash , freebsd-net@freebsd.org References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> <4E84B447.7010509@wp.pl> <4E84DE26.6030103@misal.pl> <4E85D8CB.6010104@wp.pl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [8fO0] Cc: Subject: Re: ipfw - accessing DMZ from LAN 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, 01 Oct 2011 19:16:38 -0000 W dniu 2011-09-30 17:44, Freddie Cash pisze: > > that's the correct behaviour, as the public IPs are physically assigned to > the interfaces on the router. Thus, connecting to the public IPs from the > router ... will connect to the router. > > You need to ping the private IPs from the router, since the router is > directly connected to the private networks. > And how about pinging from other DMZ host to DMZ host (both are in the same subnet) ? Am I able to allow them to contact using public IPs? Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Sat Oct 1 20:02:46 2011 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 100EC106566C for ; Sat, 1 Oct 2011 20:02:46 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B70188FC19 for ; Sat, 1 Oct 2011 20:02:44 +0000 (UTC) Received: by vcbf13 with SMTP id f13so2890781vcb.13 for ; Sat, 01 Oct 2011 13:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Spp2Sl+n+xUEKN/YW98ke2y3WVMQncu7ufKZHMidXbs=; b=NAlku6HR6x5j9hqUO9h04kvYVr/O6zC4iSASOy/J9AoT9TVmIj9PdrwQVEOLUrI9Cc 7RL8pIqvc8y0ss3nuQSaeVQF+KNM2COjM5uh/tVDLLgMSD6fbPMW8z26JiOoty7u6ZTW iYvVTmIIh+B4yfSHJKyIyFo7W3GgcCBJreGzM= MIME-Version: 1.0 Received: by 10.220.141.144 with SMTP id m16mr3748936vcu.107.1317499363979; Sat, 01 Oct 2011 13:02:43 -0700 (PDT) Received: by 10.220.186.196 with HTTP; Sat, 1 Oct 2011 13:02:43 -0700 (PDT) Received: by 10.220.186.196 with HTTP; Sat, 1 Oct 2011 13:02:43 -0700 (PDT) In-Reply-To: <4E876705.3040806@wp.pl> References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> <4E7B450F.5050802@wp.pl> <4E84B447.7010509@wp.pl> <4E84DE26.6030103@misal.pl> <4E85D8CB.6010104@wp.pl> <4E876705.3040806@wp.pl> Date: Sat, 1 Oct 2011 13:02:43 -0700 Message-ID: From: Freddie Cash To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 01 Oct 2011 20:02:46 -0000 On Oct 1, 2011 12:16 PM, "Marek Salwerowicz" wrote: > > W dniu 2011-09-30 17:44, Freddie Cash pisze: > >> >> that's the correct behaviour, as the public IPs are physically assigned to >> the interfaces on the router. Thus, connecting to the public IPs from the >> router ... will connect to the router. >> >> You need to ping the private IPs from the router, since the router is >> directly connected to the private networks. >> > And how about pinging from other DMZ host to DMZ host (both are in the same subnet) ? > Am I able to allow them to contact using public IPs? No. They would have to connect using private IPs. However, you could setup split-DNS or views and just configure everything to connect using hostnames. It's extra work to setup, but does make things easier down-the-road. Freddie fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Sat Oct 1 21:46:51 2011 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 D8E78106566C for ; Sat, 1 Oct 2011 21:46:51 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3ADEE8FC0A for ; Sat, 1 Oct 2011 21:46:51 +0000 (UTC) Received: from alph.allbsd.org (p1023-ipbf1601funabasi.chiba.ocn.ne.jp [123.220.25.23]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p91LkUoN052018; Sun, 2 Oct 2011 06:46:40 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p91LkTAI081850; Sun, 2 Oct 2011 06:46:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 02 Oct 2011 06:46:11 +0900 (JST) Message-Id: <20111002.064611.1775080469358552234.hrs@allbsd.org> To: Bredehorn@gmx.de From: Hiroki Sato In-Reply-To: <20110930074856.282760@gmx.net> References: <20110930074856.282760@gmx.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Oct__2_06_46_11_2011_456)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Sun, 02 Oct 2011 06:46:45 +0900 (JST) X-Spam-Status: No, score=-95.4 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, DIRECTOCNDYN, DYN_PBL, MIMEQENC, QENCPTR2, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: IPv6 multicast listener discovery 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, 01 Oct 2011 21:46:51 -0000 ----Security_Multipart(Sun_Oct__2_06_46_11_2011_456)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable "Rainer Bredehorn" wrote in <20110930074856.282760@gmx.net>: Br> = Br> > =A0Could you show us more specifics about your configuration and = packet Br> > =A0dump in question? Br> = Br> Yes! It's the FreeBSD 8.2 release. The only thing which is activate= d in the rc.conf is ipv6. Br> I've included the ifconfig output and a wireshark capture. Br> The capture is taken during the startup of the FreeBSD system. Br> I would like to know where the address ff02::2:2d75:f2b8 comes from= .= Thank you. I could not reproduce this on several 8.2 boxes around me yet, but do you have a ping response from ff02::2:2d75:f2b8%rl0? -- Hiroki ----Security_Multipart(Sun_Oct__2_06_46_11_2011_456)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk6HiiMACgkQTyzT2CeTzy2IuwCggXJpk+jTmxyEJwo5KoDyEoD5 GL4AmwXVlbKIeiPKp/8XH5oDEvoL2jBv =maef -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Oct__2_06_46_11_2011_456)---- From owner-freebsd-net@FreeBSD.ORG Sat Oct 1 22:48:40 2011 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 31676106566C for ; Sat, 1 Oct 2011 22:48:40 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B29F18FC0C for ; Sat, 1 Oct 2011 22:48:39 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so4084589bkb.13 for ; Sat, 01 Oct 2011 15:48:38 -0700 (PDT) Received: by 10.204.128.154 with SMTP id k26mr1209161bks.318.1317509317452; Sat, 01 Oct 2011 15:48:37 -0700 (PDT) Received: from [10.254.254.77] (ppp95-165-158-148.pppoe.spdop.ru. [95.165.158.148]) by mx.google.com with ESMTPS id l15sm8648297bkw.9.2011.10.01.15.48.36 (version=SSLv3 cipher=OTHER); Sat, 01 Oct 2011 15:48:36 -0700 (PDT) Message-ID: <4E8798C2.1010107@zonov.org> Date: Sun, 02 Oct 2011 02:48:34 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Johannes References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Intel NIC stops working 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, 01 Oct 2011 22:48:40 -0000 Hi, I see that you use MTU 9000, have you tried to increase kern.ipc.nmbjumbo9? Can you also show output of `vmstat -z | grep mbuf'? -- Andrey Zonov 16.08.2011 0:10, Johannes пишет: > Hi, > > I use an Intel dual nic for my home server. About two weeks ago, it > started to randomly stop > working. A reboot solved this problem. Today it did not even work > after a reboot. > > Since the cooling of my server was insufficient for this summers heat, > it might be a hardware > issue. > > I already checked the cable, that seems to be fine. I also ran the > Intel diagnostics (on windows) > on the cable and on the card, which showed that everything is ok. > > Any idea what the reason might be is appreciated :) > > See debug infos below. What is especially strange is > dev.em.1.debug: -1. I cannot change this, it will stay at -1. Also, > the error count numbers from > sysctl are mostly the same, which is very strange. > > uname -a > FreeBSD frege.fritz.box 8.2-STABLE FreeBSD 8.2-STABLE #15: Tue Aug 9 > 00:00:57 CEST 2011 root@frege.fritz.box:/usr/obj/usr/src/sys/FREGE > amd64 > > netstat -i > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll > em1 9000 00:15:17:51:b4:8f 69 45908905416340 > 0 61 13116830118930 6558415059465 > > pciconf -lv > em0@pci0:1:0:0: class=0x020000 card=0x125e8086 chip=0x105e8086 rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' > class = network > subclass = ethernet > em1@pci0:1:0:1: class=0x020000 card=0x125e8086 chip=0x105e8086 rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > device = 'HP NC360T PCIe DP Gigabit Server Adapter (n1e5132)' > class = network > subclass = ethernet > > sysctl dev.em.1 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.1.%driver: em > dev.em.1.%location: slot=0 function=1 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 > subdevice=0x125e class=0x020000 > dev.em.1.%parent: pci1 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 100 > dev.em.1.flow_control: 3 > dev.em.1.eee_control: 0 > dev.em.1.link_irq: 0 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 4294967295 > dev.em.1.rx_control: 4294967295 > dev.em.1.fc_high_water: 55296 > dev.em.1.fc_low_water: 53796 > dev.em.1.queue0.txd_head: 4294967295 > dev.em.1.queue0.txd_tail: 4294967295 > dev.em.1.queue0.tx_irq: 0 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 4294967295 > dev.em.1.queue0.rxd_tail: 4294967295 > dev.em.1.queue0.rx_irq: 0 > dev.em.1.mac_stats.excess_coll: 4947802323840 > dev.em.1.mac_stats.single_coll: 4947802323840 > dev.em.1.mac_stats.multiple_coll: 4947802323840 > dev.em.1.mac_stats.late_coll: 4947802323840 > dev.em.1.mac_stats.collision_count: 4947802323840 > dev.em.1.mac_stats.symbol_errors: 4947802323840 > dev.em.1.mac_stats.sequence_errors: 4947802323840 > dev.em.1.mac_stats.defer_count: 4947802323840 > dev.em.1.mac_stats.missed_packets: 4947802323925 > dev.em.1.mac_stats.recv_no_buff: 4947802323840 > dev.em.1.mac_stats.recv_undersize: 4947802323840 > dev.em.1.mac_stats.recv_fragmented: 4947802323840 > dev.em.1.mac_stats.recv_oversize: 4947802323840 > dev.em.1.mac_stats.recv_jabber: 4947802323840 > dev.em.1.mac_stats.recv_errs: 4947802323840 > dev.em.1.mac_stats.crc_errs: 4947802323840 > dev.em.1.mac_stats.alignment_errs: 4947802323840 > dev.em.1.mac_stats.coll_ext_errs: 4947802323840 > dev.em.1.mac_stats.xon_recvd: 4947802323840 > dev.em.1.mac_stats.xon_txd: 4947802323840 > dev.em.1.mac_stats.xoff_recvd: -1152 > dev.em.1.mac_stats.xoff_txd: 4947802323840 > dev.em.1.mac_stats.total_pkts_recvd: 4947802324218 > dev.em.1.mac_stats.good_pkts_recvd: 4947802324133 > dev.em.1.mac_stats.bcast_pkts_recvd: 4947802323919 > dev.em.1.mac_stats.mcast_pkts_recvd: 4947802324054 > dev.em.1.mac_stats.rx_frames_64: 4947802323840 > dev.em.1.mac_stats.rx_frames_65_127: 4947802323985 > dev.em.1.mac_stats.rx_frames_128_255: 4947802323879 > dev.em.1.mac_stats.rx_frames_256_511: 4947802323949 > dev.em.1.mac_stats.rx_frames_512_1023: 4947802323840 > dev.em.1.mac_stats.rx_frames_1024_1522: 4947802323840 > dev.em.1.mac_stats.good_octets_recvd: 60519 > dev.em.1.mac_stats.good_octets_txd: 4643 > dev.em.1.mac_stats.total_pkts_txd: 4947802323860 > dev.em.1.mac_stats.good_pkts_txd: 4947802323860 > dev.em.1.mac_stats.bcast_pkts_txd: 4947802323840 > dev.em.1.mac_stats.mcast_pkts_txd: 4947802323860 > dev.em.1.mac_stats.tx_frames_64: 4947802323840 > dev.em.1.mac_stats.tx_frames_65_127: 4947802323848 > dev.em.1.mac_stats.tx_frames_128_255: 4947802323846 > dev.em.1.mac_stats.tx_frames_256_511: 4947802323843 > dev.em.1.mac_stats.tx_frames_512_1023: 4947802323843 > dev.em.1.mac_stats.tx_frames_1024_1522: 4947802323840 > dev.em.1.mac_stats.tso_txd: 4947802323840 > dev.em.1.mac_stats.tso_ctx_fail: 4952097291135 > dev.em.1.interrupts.asserts: 4947802323925 > dev.em.1.interrupts.rx_pkt_timer: 4947802323840 > dev.em.1.interrupts.rx_abs_timer: 4947802323840 > dev.em.1.interrupts.tx_pkt_timer: 4947802323840 > dev.em.1.interrupts.tx_abs_timer: 4947802323840 > dev.em.1.interrupts.tx_queue_empty: 4947802323840 > dev.em.1.interrupts.tx_queue_min_thresh: 4947802323840 > dev.em.1.interrupts.rx_desc_min_thresh: 4947802323840 > dev.em.1.interrupts.rx_overrun: 4947802323840 > _______________________________________________ > 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 Oct 1 22:53:50 2011 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 B39CD106564A; Sat, 1 Oct 2011 22:53:50 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1487D8FC08; Sat, 1 Oct 2011 22:53:49 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so4093040bkb.13 for ; Sat, 01 Oct 2011 15:53:48 -0700 (PDT) Received: by 10.204.152.71 with SMTP id f7mr6239462bkw.53.1317508220531; Sat, 01 Oct 2011 15:30:20 -0700 (PDT) Received: from [10.254.254.77] (ppp95-165-158-148.pppoe.spdop.ru. [95.165.158.148]) by mx.google.com with ESMTPS id v16sm8624355bkd.6.2011.10.01.15.30.19 (version=SSLv3 cipher=OTHER); Sat, 01 Oct 2011 15:30:19 -0700 (PDT) Message-ID: <4E879479.7030406@zonov.org> Date: Sun, 02 Oct 2011 02:30:17 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Brian Somers References: <201107221454.11469.achilov-rn@askd.ru> <20110730194332.GI88174@thong.lan.Awfulhak.org> In-Reply-To: <20110730194332.GI88174@thong.lan.Awfulhak.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Rashid N. Achilov" , freebsd-net@freebsd.org Subject: Re: strange ping on local address 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, 01 Oct 2011 22:53:50 -0000 Hi, Yes, that helps. Source IP address is now the same as destination. Also helps reconfigure main interface, and now source IP address is 127.0.0.1 (and that's correct behaviour). -- Andrey Zonov 30.07.2011 23:43, Brian Somers пишет: > On Fri, Jul 22, 2011 at 02:54:11PM +0700, Rashid N. Achilov wrote: >> When I try to ping local interface - ping missed! When I try to ping this >> interface with -S key (specified the same address) - working. What's a bug? >> In RELENG_7 worked. >> >> local interface on box: >> em0: flags=8943 metric 0 mtu >> 1500 >> options=219b >> ether 00:xx:xx:xx:xx:xx >> inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (100baseTX) >> status: active >> >> ping ordinary: >> master:[root] 105>ping 192.168.1.1 >> PING 192.168.1.1 (192.168.1.1): 56 data bytes >> ^C >> --- 192.168.1.1 ping statistics --- >> 2 packets transmitted, 0 packets received, 100.0% packet loss >> >> ping with -S key: >> master:[root] 106>ping -S 192.168.1.1 192.168.1.1 >> PING 192.168.1.1 (192.168.1.1) from 192.168.1.1: 56 data bytes >> 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.022 ms >> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.030 ms >> ^C >> --- 192.168.1.1 ping statistics --- >> 2 packets transmitted, 2 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 0.022/0.026/0.030/0.004 ms >> >> master:[root] 103>uname -a >> FreeBSD master.askd.ru 8.2-STABLE FreeBSD 8.2-STABLE #1: Fri Jul 15 18:23:18 >> NOVST 2011 root@master-new.askd.gmbh:/usr/obj/usr/src/sys/Master i386 >> >> What's a terrible? I'm understand, that ping "itself" is rarely situation, but >> it worked in 7.x! > What happens if you "route delete 192.168.1.1" and then try the ping > without using -S? >