From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 00:04:22 2007 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 18BD616A418 for ; Sun, 23 Sep 2007 00:04:22 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 69B1113C457 for ; Sun, 23 Sep 2007 00:01:50 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1499246waf for ; Sat, 22 Sep 2007 17:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=3n8NS2ab3vGlvcbO1EL0ARFnAJPvZ7SHCTMUAp5Lc3o=; b=qkb8Mpxl/HQOCbJu5/YzYHvZdeTyZ9eh6JrGqPdmAmW9pZbaJa7t2flSbvzWbbzFOHfj5i1y7TosGClOJ9EVT9fSVR+3eNOx4aOyUdMWupLGJ0E7CridlOB7FVEijCgL7codCpAL7puYgAe//weB+Aa7urSvJEFfqG8q+LWpQXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OLTf0h1HmpewktTzUJVwomwANPdXKOzEx8RwOlGOejUjK77MkclnAB58t/tzgZUoURlAehnPFWpyLGUFG4ptV8Vbsi6S0Cf4oS3KmJGBRJMDX42jVqOAJLHHtjMMfnaz1rwBB0SdxEsYHv++Lyn7WTzZDMQ8MQbkaWOKaki8/gs= Received: by 10.114.75.1 with SMTP id x1mr5135761waa.1190505710348; Sat, 22 Sep 2007 17:01:50 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Sat, 22 Sep 2007 17:01:50 -0700 (PDT) Message-ID: Date: Sat, 22 Sep 2007 17:01:50 -0700 From: "Kip Macy" To: "Jack Vogel" In-Reply-To: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> Cc: "freebsd-net@freebsd.org" , FreeBSD Current Subject: Re: TX Multiqueue? 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, 23 Sep 2007 00:04:22 -0000 My ethng branch supports multiple rx and tx queues. -Kip On 9/22/07, Jack Vogel wrote: > Our newest E1000 nic, the 82575, and the Oplin 10G hardware are capable of > multiple queues both on the receive and the send side. On the receive end for > the Oplin driver the queues actually help distribute interrupts and improve > performance without any special support in the stack. > > I have been asked about multiple queues on the TX side, embedded appliance > type system builders for instance are interested I suppose for > priority queueing. > Is anyone working on this right now, and if not does this sound like something > anyone is interested in doing? > > I would like to see MQ on both TX and RX that drivers could use if able. > > Jack > _______________________________________________ > 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 Sun Sep 23 05:52:24 2007 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 83B5616A417 for ; Sun, 23 Sep 2007 05:52:24 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 7725D13C49D for ; Sun, 23 Sep 2007 05:52:24 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZKOF-000OGo-94 for freebsd-net@freebsd.org; Sun, 23 Sep 2007 05:52:23 +0000 Message-ID: <46F5FF0A.7030203@psg.com> Date: Sat, 22 Sep 2007 19:52:10 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: nat and ipfw - divert or builtin 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, 23 Sep 2007 05:52:24 -0000 freebsd-current i386 / soekris i used to use ipfw to divert to natd. so, when i went to configure a new nat box nat box today, i was 82.3% there when i hit a bunch of nat stuff in ipfw that i do not remember seeing before. it appears that ipfw will nat all on its own without natd and divert. what's the trade-off? which should i use? randy From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 07:41:30 2007 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 EA9C816A417 for ; Sun, 23 Sep 2007 07:41:30 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id CE63213C455 for ; Sun, 23 Sep 2007 07:41:30 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id EB8582F0DF; Sun, 23 Sep 2007 03:24:25 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 23 Sep 2007 03:24:25 -0400 X-Sasl-enc: 2xdGgOmNanCx69GySBMHJThshUtlsXXiKHIonjckJBIE 1190532265 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 508833F31; Sun, 23 Sep 2007 03:24:25 -0400 (EDT) Message-ID: <46F614F2.4050402@freebsd.org> Date: Sun, 23 Sep 2007 00:25:38 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Kip Macy References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , FreeBSD Current , Jack Vogel Subject: Re: TX Multiqueue? 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, 23 Sep 2007 07:41:31 -0000 Kip Macy wrote: > My ethng branch supports multiple rx and tx queues. > > -Kip > What are your plans for how we use/manage/interact with the mutiple rx/tx queues? Darren > On 9/22/07, Jack Vogel wrote: > > Our newest E1000 nic, the 82575, and the Oplin 10G hardware are capable of > > multiple queues both on the receive and the send side. On the receive end for > > the Oplin driver the queues actually help distribute interrupts and improve > > performance without any special support in the stack. > > > > I have been asked about multiple queues on the TX side, embedded appliance > > type system builders for instance are interested I suppose for > > priority queueing. > > Is anyone working on this right now, and if not does this sound like something > > anyone is interested in doing? > > > > I would like to see MQ on both TX and RX that drivers could use if able. > > > > Jack > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 08:12:23 2007 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 1D81F16A511; Sun, 23 Sep 2007 08:12:23 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from relanium.yandex.ru (relanium.yandex.ru [213.180.193.88]) by mx1.freebsd.org (Postfix) with ESMTP id 67D5113C459; Sun, 23 Sep 2007 08:12:22 +0000 (UTC) (envelope-from wawa@yandex-team.ru) Received: from [87.250.227.232] (v3-227-232.yandex.net [87.250.227.232]) by relanium.yandex.ru (8.14.1/8.14.1) with ESMTP id l8N7oEgA089771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2007 11:50:27 +0400 (MSD) (envelope-from wawa@yandex-team.ru) Message-ID: <46F61AB5.4010207@yandex-team.ru> Date: Sun, 23 Sep 2007 11:50:13 +0400 From: Vladimir Ivanov Organization: Yandex LLC User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Kip Macy References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: Dr.Web (R) for Mail Servers on relanium.yandex.ru host X-Antivirus-Code: 100000 Cc: "freebsd-net@freebsd.org" , FreeBSD Current , Jack Vogel Subject: Re: TX Multiqueue? 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, 23 Sep 2007 08:12:23 -0000 Kip Macy wrote: > My ethng branch supports multiple rx and tx queues. > > -Kip > > On 9/22/07, Jack Vogel wrote: >> Our newest E1000 nic, the 82575, and the Oplin 10G hardware are capable of >> multiple queues both on the receive and the send side. On the receive end for >> the Oplin driver the queues actually help distribute interrupts and improve >> performance without any special support in the stack. I've published SMP versions of em and ixgb drivers several months ago (see http://people.yandex-team.ru/~wawa). Did you have time to see it, Jack ? That drivers use several kthreads to process one RX queue. The main idea is to increase a performance. Vladimir >> >> I have been asked about multiple queues on the TX side, embedded applice >> type system builders for instance are interested I suppose for >> priority queueing. >> Is anyone working on this right now, and if not does this sound like something >> anyone is interested in doing? >> >> I would like to see MQ on both TX and RX that drivers could use if able. >> >> Jack From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 15:53:49 2007 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 43CFA16A419 for ; Sun, 23 Sep 2007 15:53:49 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 1CAF313C44B for ; Sun, 23 Sep 2007 15:53:49 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZTmF-000PWo-QR; Sun, 23 Sep 2007 15:53:48 +0000 Message-ID: <46F68BFC.7030800@psg.com> Date: Sun, 23 Sep 2007 05:53:32 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Hermansson References: <46F5FF0A.7030203@psg.com> <46F68B1C.6020303@chdevelopment.se> In-Reply-To: <46F68B1C.6020303@chdevelopment.se> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: nat and ipfw - divert or builtin 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, 23 Sep 2007 15:53:49 -0000 > I believe the integrated version makes configuration simpler. I would > choose the old classic divert with ipfw if it is for a important network > that must work, but if I was running -current I would try the integrated > variant beacuse it seems to be simpler to use. and one less daemon. less code is better code. i will likely give it a try. thanks. randy From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 16:09:52 2007 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 C338116A41A for ; Sun, 23 Sep 2007 16:09:52 +0000 (UTC) (envelope-from mail@chdevelopment.se) Received: from av9-2-sn3.vrr.skanova.net (av9-2-sn3.vrr.skanova.net [81.228.9.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6BE0F13C478 for ; Sun, 23 Sep 2007 16:09:52 +0000 (UTC) (envelope-from mail@chdevelopment.se) Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 4398337F8B; Sun, 23 Sep 2007 17:49:49 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 2F90A37F6C; Sun, 23 Sep 2007 17:49:49 +0200 (CEST) Received: from melissa.chdevelopment.se (90-227-26-163-no68.tbcn.telia.com [90.227.26.163]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id DA39E37E49; Sun, 23 Sep 2007 17:49:48 +0200 (CEST) Message-ID: <46F68B1C.6020303@chdevelopment.se> Date: Sun, 23 Sep 2007 17:49:48 +0200 From: Christer Hermansson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.6) Gecko/20070811 SeaMonkey/1.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <46F5FF0A.7030203@psg.com> In-Reply-To: <46F5FF0A.7030203@psg.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: randy@psg.com Subject: Re: nat and ipfw - divert or builtin 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, 23 Sep 2007 16:09:52 -0000 Randy Bush wrote: > freebsd-current i386 / soekris > > i used to use ipfw to divert to natd. so, when i went to configure a > new nat box nat box today, i was 82.3% there when i hit a bunch of nat > stuff in ipfw that i do not remember seeing before. it appears that > ipfw will nat all on its own without natd and divert. > > what's the trade-off? which should i use? > I only have experience with ipdivert, but I got a tip in this mailing list about using ipnat with ipfw and also about this integrated variant so it seems to be at least 3 different ways to go for nat when running ipfw: divert ipnat ipfw's integrated nat I believe the integrated version makes configuration simpler. I would choose the old classic divert with ipfw if it is for a important network that must work, but if I was running -current I would try the integrated variant beacuse it seems to be simpler to use. -- Christer Hermansson From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 21:12:47 2007 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 3958F16A420 for ; Sun, 23 Sep 2007 21:12:47 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id CB75013C46E for ; Sun, 23 Sep 2007 21:12:46 +0000 (UTC) (envelope-from louie@transsys.com) Received: from [144.202.1.88] (c-69-141-143-164.hsd1.nj.comcast.net [69.141.143.164]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 06E925C4C; Sun, 23 Sep 2007 17:12:41 -0400 (EDT) In-Reply-To: <46F614F2.4050402@freebsd.org> References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> <46F614F2.4050402@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Louis Mamakos Date: Sun, 23 Sep 2007 17:12:40 -0400 To: Darren Reed X-Mailer: Apple Mail (2.752.2) Cc: Kip Macy , FreeBSD Current , Jack Vogel , "freebsd-net@freebsd.org" Subject: Re: TX Multiqueue? 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, 23 Sep 2007 21:12:47 -0000 We've seen problems on other OS's where the locking in the device driver around the process of queuing packets to the device was a performance issue when trying to send relatively small packets. As a workaround, we ended up doing a multi-link/bonding thing over multiple interfaces to get the throughput. This was on an SMP system and the application was such that there were multiple execution threads running in parallel. Having multiple queues, even for a single class of traffic may enable enough additional concurrency in the driver to increase throughput. It's up to driver to use some algorithm to spread the load over the queues to ensure that specific "flows" stay in order, same as if you we doing ether- channel bonding. Of course, if the transmit path through the network stack isn't enabling concurrency, a bottleneck there won't be an issue. Louis Mamakos Just something else to consider.. On Sep 23, 2007, at 3:25 AM, Darren Reed wrote: > Kip Macy wrote: >> My ethng branch supports multiple rx and tx queues. >> >> -Kip >> > > What are your plans for how we use/manage/interact with the mutiple > rx/tx queues? > > Darren > > >> On 9/22/07, Jack Vogel wrote: >> > Our newest E1000 nic, the 82575, and the Oplin 10G hardware are >> capable of >> > multiple queues both on the receive and the send side. On the >> receive end for >> > the Oplin driver the queues actually help distribute interrupts >> and improve >> > performance without any special support in the stack. >> > >> > I have been asked about multiple queues on the TX side, embedded >> appliance >> > type system builders for instance are interested I suppose for >> > priority queueing. >> > Is anyone working on this right now, and if not does this sound >> like something >> > anyone is interested in doing? >> > >> > I would like to see MQ on both TX and RX that drivers could use >> if able. >> > >> > Jack >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" >> > >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 22:38:22 2007 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 C26CC16A419; Sun, 23 Sep 2007 22:38:22 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6173113C455; Sun, 23 Sep 2007 22:38:22 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 604882F004; Sun, 23 Sep 2007 18:38:02 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 23 Sep 2007 18:38:02 -0400 X-Sasl-enc: cDFZ9oVuyYCmZjdT1cSqICDMJ8Rdc03EpCRDvBbpj+h1 1190587082 Received: from [192.168.1.235] (64-142-85-108.dsl.dynamic.sonic.net [64.142.85.108]) by mail.messagingengine.com (Postfix) with ESMTP id 68F0420960; Sun, 23 Sep 2007 18:38:01 -0400 (EDT) Message-ID: <46F6EB10.8060505@freebsd.org> Date: Sun, 23 Sep 2007 15:39:12 -0700 From: Darren Reed User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Louis Mamakos References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> <46F614F2.4050402@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kip Macy , FreeBSD Current , Jack Vogel , "freebsd-net@freebsd.org" Subject: Re: TX Multiqueue? 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, 23 Sep 2007 22:38:22 -0000 Louis Mamakos wrote: > We've seen problems on other OS's where the locking in the device driver > around the process of queuing packets to the device was a performance > issue > when trying to send relatively small packets. As a workaround, we > ended up > doing a multi-link/bonding thing over multiple interfaces to get the > throughput. This was on an SMP system and the application was such that > there were multiple execution threads running in parallel. > > Having multiple queues, even for a single class of traffic may enable > enough > additional concurrency in the driver to increase throughput. It's up to > driver to use some algorithm to spread the load over the queues to ensure > that specific "flows" stay in order, same as if you we doing > ether-channel > bonding. Maybe I'm not interested in the driver having its own algorithm. Maybe I want to reserve a tx/rx queue pair for ssh. Maybe I want to dedicate a tx/rx queue pair for my web server. etc. Darren > Of course, if the transmit path through the network stack isn't enabling > concurrency, a bottleneck there won't be an issue. > > Louis Mamakos > > Just something else to consider.. > > On Sep 23, 2007, at 3:25 AM, Darren Reed wrote: > >> Kip Macy wrote: >>> My ethng branch supports multiple rx and tx queues. >>> >>> -Kip >>> >> >> What are your plans for how we use/manage/interact with the mutiple >> rx/tx queues? >> >> Darren >> >> >>> On 9/22/07, Jack Vogel wrote: >>> > Our newest E1000 nic, the 82575, and the Oplin 10G hardware are >>> capable of >>> > multiple queues both on the receive and the send side. On the >>> receive end for >>> > the Oplin driver the queues actually help distribute interrupts >>> and improve >>> > performance without any special support in the stack. >>> > >>> > I have been asked about multiple queues on the TX side, embedded >>> appliance >>> > type system builders for instance are interested I suppose for >>> > priority queueing. >>> > Is anyone working on this right now, and if not does this sound >>> like something >>> > anyone is interested in doing? >>> > >>> > I would like to see MQ on both TX and RX that drivers could use if >>> able. >>> > >>> > Jack >>> > _______________________________________________ >>> > freebsd-net@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> > To unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@freebsd.org" >>> > >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 22:47:15 2007 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 695A616A421 for ; Sun, 23 Sep 2007 22:47:15 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 17A8813C46E for ; Sun, 23 Sep 2007 22:47:15 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1836726waf for ; Sun, 23 Sep 2007 15:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+dZ9SXbne9IFaDmTF24WejRwA1UKRjI9SeSN72hsHjg=; b=paNy7MIOcWIw1hjjbwu6aNaOSFrRlB13h3urFrDG0JF8mq/Uo3L1MaEGBBFOTrBUDrxYMb9xtCBYM2QXu7PbfLmq6cMcAJIs2Kcwc7HaxqwcpkP3U63QOTla+d7MBDuQwhRWufwGseqgOPKxLU9ojpHYSKbIIIPcx/TPGd3KNRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=d0IazMX2pIvuWuP1DjgA+MpgpP4kIgNDIwDtvqQVSnvDOG9LKac64MTChs604vJFCjL7Err1ZWajZKQ2Ygs+011lVC8/72EX5luCHfpatR7NLh1ezLi272GRS+Egc6qv+v+5gwVcsgwV0XyswBeh46uN6zi6Ej3Ty3cISW0IL2M= Received: by 10.115.55.1 with SMTP id h1mr5616231wak.1190587633970; Sun, 23 Sep 2007 15:47:13 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Sun, 23 Sep 2007 15:47:13 -0700 (PDT) Message-ID: Date: Sun, 23 Sep 2007 15:47:13 -0700 From: "Kip Macy" To: "Darren Reed" In-Reply-To: <46F614F2.4050402@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> <46F614F2.4050402@freebsd.org> Cc: "freebsd-net@freebsd.org" , FreeBSD Current , Jack Vogel Subject: Re: TX Multiqueue? 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, 23 Sep 2007 22:47:15 -0000 On 9/23/07, Darren Reed wrote: > Kip Macy wrote: > > My ethng branch supports multiple rx and tx queues. > > > > -Kip > > > > What are your plans for how we use/manage/interact with the mutiple > rx/tx queues? The rx hardware queue is determined by the hardware. Different hardware allows for different policies. I just use the stock rss_hash of a crc32 of the 4-tuple in cxgb. I've added a field to the pkthdr which cxgb uses the least significant bits of to determine which outbound queue to use. Its up to the upper layers to determine how to set those bits. One of the changes that is required to take advantaged of this is moving the queues into the driver. I've added a new if_start function to ifnet to take advantage of this. I also have a normal if_start function for backward compatibility. -Kip From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 07:20:32 2007 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 A4E8316A418 for ; Mon, 24 Sep 2007 07:20:32 +0000 (UTC) (envelope-from daffy@xview.net) Received: from mail.oav.net (mail.oav.net [193.218.105.18]) by mx1.freebsd.org (Postfix) with ESMTP id 513BE13C48E for ; Mon, 24 Sep 2007 07:20:32 +0000 (UTC) (envelope-from daffy@xview.net) Received: from localhost (localhost [127.0.0.1]) by mail02.oav.net (Postfix) with ESMTP id 9BE2F3F43D; Mon, 24 Sep 2007 09:20:31 +0200 (CEST) (envelope-from daffy@xview.net) X-Virus-Scanned: by amavisd-new at mail02.oav.net Received: from mail02.oav.net ([127.0.0.1]) by localhost (mail02.oav.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id hRjtsKu397Ua; Mon, 24 Sep 2007 09:20:31 +0200 (CEST) Received: from [192.168.0.10] (ble59-1-82-66-131-119.fbx.proxad.net [82.66.131.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail02.oav.net (Postfix) with ESMTP id 08DC53F43B; Mon, 24 Sep 2007 09:20:30 +0200 (CEST) (envelope-from daffy@xview.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9D1C5636-E513-4D88-9B1E-5646C0C0897D@xview.net> Content-Transfer-Encoding: quoted-printable From: Olivier Warin Date: Mon, 24 Sep 2007 09:18:33 +0200 To: Fabien THOMAS X-Mailer: Apple Mail (2.752.3) Cc: freebsd-net@freebsd.org Subject: Re: pollng: pcap bench 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, 24 Sep 2007 07:20:32 -0000 Le 19 sept. 07 =E0 16:59, Fabien THOMAS a =E9crit : > Result of pcap benchmark requested by Vlad Galu: > > Using polling is better. > > Test setup: > --------------- > > netblast -- em|fxp -- pcap_bmark > > under FreeBSD 6.2 > > Small product (fxp interface): > --------------------------------------- > > pollng: > > Captured 30322.00 pps (total of 333542) and dropped 144 > Captured 30358.45 pps (total of 333943) and dropped 219 > Captured 30253.18 pps (total of 332785) and dropped 151 > Captured 30276.82 pps (total of 333045) and dropped 88 > Captured 30362.64 pps (total of 333989) and dropped 369 > > intr: > > Captured 0.01 pps (total of 6877442) and dropped 6876215 > > completly stuck with intr mode so the period take more than 10s. > > Large product (em interface): > --------------------------------------- > > pollng: > Captured 114669.09 pps (total of 1261360) and dropped 0 > Captured 115263.18 pps (total of 1267895) and dropped 0 > Captured 115226.45 pps (total of 1267491) and dropped 0 > Captured 115003.64 pps (total of 1265040) and dropped 0 > > intr: > > Captured 99091.91 pps (total of 1090011) and dropped 629467 > Captured 105180.64 pps (total of 1156987) and dropped 617526 > Captured 99722.36 pps (total of 1096946) and dropped 607367 > Captured 104180.91 pps (total of 1145990) and dropped 626567 Hello Fabien, Thanks one more time for your contribution. One small question for =20 you, what was the overhall packet size during capture ? By the way, I found out similar reports regarding polling in new =20 FreeBSD releases: - http://www.net.t-labs.tu-berlin.de/papers/SWF-PCCH10GEE-07.pdf - a couple on our mailing lists. Would be nice if some commiters can take the time to review this code =20= (pollng). Best regards, /Olivier -- Olivier Warin From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 07:38:34 2007 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 D46EC16A419 for ; Mon, 24 Sep 2007 07:38:34 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id A940413C459 for ; Mon, 24 Sep 2007 07:38:34 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 2C8D83C0490; Mon, 24 Sep 2007 00:38:33 -0700 (PDT) Date: Mon, 24 Sep 2007 00:38:33 -0700 From: Christopher Cowart To: freebsd-net@freebsd.org Message-ID: <20070924073833.GM19429@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org References: <20070818102803.GA1319@jayce.zen.inc> <20070820082728.GA28863@zen.inc> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fBvfXcdybK7Zhu+D" Content-Disposition: inline In-Reply-To: Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2 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, 24 Sep 2007 07:38:34 -0000 --fBvfXcdybK7Zhu+D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 20, 2007 at 12:43:25PM -0400, Scott Ullrich wrote: > On 8/20/07, VANHULLEBUS Yvan wrote: > > I tracked down the problem a few years ago, on FreeBSD 4.11, with > > KAME's IPSec stack. > > > > But the problem was not really in the stack itself, but rather in > > socket processing (in other words: not in netkey/*, but in > > kern/uipc_socket2.c). > > > > And as both IPSec stacks shares some PFKey constraints (for example > > one message per entry when dumping SADB / SPD), I guess the same > > problem existed in FAST_IPSEC. > > > > But when I had some time a few months ago to start filling a PR for > > the problem, I had a look at FreeBSD6 source code, and I noticed that > > sbspace macro (which was a quite important part of the problem) has > > changed, and I didn't have the required setup to do the test again, so > > I just can't be really sure the problem still exists... > > > > But the reported problem really has similar symptoms..... >=20 > Thank you Yvan and George! >=20 > The PR has been filed and the ID# is >=20 > kern/115651 >=20 > I have added some interesting notes that seem to affect NetBSD as well. >=20 > We will be happy to work with anyone to get this solved and access to > the machine in question is available if need be. I'd also like to express an interest in helping with this problem in any way possible. We're running into the same problem on our fileservers and have had to rollback a large project when we unexpectedly discovered the problem. Thanks, --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --fBvfXcdybK7Zhu+D Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvdpeSPHEDszU3zYAQIukQ/5ARJGBR5UNaKsurezCqlM9AvFNhAhEJm8 o6Yl1AEfZwNX0gsQAnANdYrftuo7+EjDyhtulL+dDWqAROHf9iDrvslXy61cZJY4 nnWLOTB2ygF/3LhRFpqggUCcjF8r3HfF9GeLsH7MqUkL6zkGeqnlmsZSMATCwbPv tS0rKMRXY92rx5XIl1Cb3OKGzfu1/4ARbBppMyWUN6c/zlISuJujrY8fkKlY+D/C vMQFQsT3/bqnK+yKoEfBZzVQZ8jS6YVfX89pEDDa4j1bm+FF9nA0ElW024m9qqE7 IrEsmU/2ot4pLYqV5mzqmpSupyg9x+gLxI+ByLpSnm4KrQhQQuts/0A278FikUZo Gsav1CF7g4zut5uz75hmHUrFySjYtQF9bulU+TZlsKK214fsQFLROv1T6qWhaEHu 9DradWNrIV/ySi3XIc2OMKn7IQ3phSqq3OVAJK1/eDF/CayaILQTScexO3434G+I ShnFtR0LvWudEhNR2Fq5ooYe6jLG+4ylGB5Tq98QFBysOXPKAZ8uduitp2Tgd7JS 2J4ljk1SjjIBCRKdvBInAcAKCXX+gxR6kqYSgIiDeX1X9nJxOQHLElQxkCd5FIRU sEhA9BlFVH6JDdfdsvyoFhTguwKvBgeJJHlZtxR42MzJzos04j8vLVvXLeRFoBgB oAwhvcm30tU= =MNBZ -----END PGP SIGNATURE----- --fBvfXcdybK7Zhu+D-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 07:44:38 2007 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 E85EB16A419 for ; Mon, 24 Sep 2007 07:44:38 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id B309513C47E for ; Mon, 24 Sep 2007 07:44:38 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 9E8AC3C048D; Mon, 24 Sep 2007 00:25:18 -0700 (PDT) Date: Mon, 24 Sep 2007 00:25:17 -0700 From: Christopher Cowart To: freebsd-net@freebsd.org Message-ID: <20070924072517.GL19429@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ewGIpL7F8xO9lipn" Content-Disposition: inline Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Large-scale 1-1 NAT 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, 24 Sep 2007 07:44:39 -0000 --ewGIpL7F8xO9lipn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, We're working on expanding our wireless network. Unfortunately, we're running out of IP addresses (aren't we all). As much as I'd love to just tell everyone to use IPv6, that isn't gonna fly. The next plan to=20 consider is using an RFC1918 pool and NATing the traffic. If only it were that simple. The security folks have mandated that anyone who can talk to the internet at large must be individually indentifiable. This means having hundreds of users NATing to a single internet-routable IP isn't happening. I want to try a setup in which we have a big RFC1918 pool of addresses, say 10.8/16. In their initial state, these hosts might NAT to a single public IP and perform some transparent proxying to get them to an authentication page. The firewall on our NAT box would be extremely restrictive for these clients. When a user authenticates, we will allocate a single public IP for the session. At this time, our code would use ipfw to move the user into a different lookup table and also update the NAT table. The real question is: what's the best way to dynamically update the NAT table? It doesn't look like there's any way to have a running natd update its configuration without restarting. That's obviously disruptive. I also doubt it's a good idea to try to launch a single natd process per authenticated client. We have a /22 and a /23 in our public pools, and we expect to max that out (1500+ clients). Has anyone attempted a setup like this? Do you have any pointers for designing this to scale well? We are planning on throwing hardware at it, but that only gets us so far. Thanks for your help, --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --ewGIpL7F8xO9lipn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvdmXSPHEDszU3zYAQLf/w/+P+UfJyspWYEFkVbCWCjiy7MnSXsqqZ8F acbJR/qyXAGySLyPaqcsJnL8Y7tHVQ0cwWgx5C8q+DZdOF8HotOUqnBfZt5B1R7H 4Wtl1ZZMyaggxNY43S1yP1UstPg8xeTrD3h8rGCakwAfVEF8iKFPyvCUm9jDyYEj qZpcaDzssfnJJkWO0eaWTDpLd3TnKVsKMAcKexT9HfjQx6w0VzysQEl85zqV5K89 Sp4vqvGPyVbZspTnjjbtKqSqoV+FAQ9R1cmFiJQqoH4K+ks5KnyL6SV8IlWeO7cj NnnFmZhk9fTU/yFs1PofPSUBgT7D/NHT21Hrcu2j3b2RnmC7oKk3EK8NsOotkTgd 0IEhpN4sXSNScRnkyjZj20XFJLvTObC2AfgZgPbHnSO6PSvfeBtJz4PMOroeCApC 5H5jp4uqMSfCiqfNSeKIGNMjtHvgDSCH2bNYJCSbaQYsY3fQSKkIhOb9P2cRmDoK uYlil+TZAEwzfBQRVQbYwQiQBQs55555UCgsQZVfzAXvEw4/rRZt7VYupMoIWv/c f9Up/UJDYDastEJnLZUbUmdn9UfZtjM5weGat+rt6bzzAVjKlgsINUxAc3nODKQp yMbTcRZ8DT/ycaGKMA0fURGnDcUpEJ5H/eO1s9cKXJhP/r+PyzCCDcmamVtY2Ep4 ChWG4ZZoRkc= =QvqE -----END PGP SIGNATURE----- --ewGIpL7F8xO9lipn-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 07:52:54 2007 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 3144516A46C for ; Mon, 24 Sep 2007 07:52:54 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4FF13C4D3 for ; Mon, 24 Sep 2007 07:52:53 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 02DC33C0473; Mon, 24 Sep 2007 00:52:52 -0700 (PDT) Date: Mon, 24 Sep 2007 00:52:52 -0700 From: Christopher Cowart To: Scott Ullrich Message-ID: <20070924075252.GN19429@hal.rescomp.berkeley.edu> Mail-Followup-To: Scott Ullrich , VANHULLEBUS Yvan , freebsd-net@freebsd.org References: <20070818102803.GA1319@jayce.zen.inc> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yY9LxKOJMX9E+noF" Content-Disposition: inline In-Reply-To: Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2 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, 24 Sep 2007 07:52:54 -0000 --yY9LxKOJMX9E+noF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 18, 2007 at 03:58:16PM -0400, Scott Ullrich wrote: > We have worked around the problem for now with a simple shell script=20 > that looks for racoon falling over and simply restarting it. How are you detecting when racoon gets wedged? I'd like to replicate that on our systems. Thanks, --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --yY9LxKOJMX9E+noF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvds1CPHEDszU3zYAQLhog//dA/aaA9LBc1x9zeEQN1zxboAN5sY9JCb kkkj8+JWfK33GfxKu0tcdjo05otkN/g/Ms/yylgkEOLx/XaNmgEl8BYghzp3Pmuc aMuNwcMz4kYODTD6MEIEYy9/jwG0eexDjOyAJRx7wnuyiI7ipzHoXgZMDjwcDlGh /xgotoXk8Iiq4Eb6evEzePpt179lKVBkVALo3YfhOxOYIB7lN8DplTWL84amy2hu Bm9YlyyjL9y3z6usz8+apEdZVigwZiHYsugssgFlu0gk/LgwFWQ1up+bzRrdL90P 8iKz3jjHvN6tYu94vJ3IvWRLgSrubTSZUmSkL4zaR9Mq+D1x98tdCndbDUvvjLIX 3g8zj3mqT9pY5K0CK4w6RQ2q6jUi0maWjRsHFb0oeRPrRFucD3BkJm79Ka/Wg3tW Y56yBdhg9pMr7AfyDdnHi6tolQ0wyK5bj8BpaEa3IolJzM0+l7rtSQPfiLbYPiV7 6Dl5HiOJyrR2QiQrKN6ATo/obF9MWE4DFSzW7Y9mta0qp/L1lnlKHg8OU1D5J3xS wOodMnSzo64mp9Tu+omoZbcvZGrtm7QiOvwYYLUVZQ2AhNf8OGHTKPJByPXgRVUH j1k1u+hh9rV8k1nESIqJms7YcDBV3K1Jibzxz7hjTa3bx6MhYNaGFl2cKNPr7Gxg KgJ+S0059lw= =wIR4 -----END PGP SIGNATURE----- --yY9LxKOJMX9E+noF-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 08:58:23 2007 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 B042C16A418 for ; Mon, 24 Sep 2007 08:58:23 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (unknown [IPv6:2001:b30:5000:2:20e:cff:fe4b:ca01]) by mx1.freebsd.org (Postfix) with ESMTP id 1269F13C447 for ; Mon, 24 Sep 2007 08:58:23 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id D9E2F50889 for ; Mon, 24 Sep 2007 11:58:21 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5ZNUAvR9m-Z for ; Mon, 24 Sep 2007 11:58:15 +0300 (EEST) Received: from [193.226.5.46] (hades.utcluj.ro [193.226.5.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id D3E0C50884 for ; Mon, 24 Sep 2007 11:58:15 +0300 (EEST) Message-ID: <46F77C27.9050400@net.utcluj.ro> Date: Mon, 24 Sep 2007 11:58:15 +0300 From: Cristian KLEIN User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> In-Reply-To: <20070924072517.GL19429@hal.rescomp.berkeley.edu> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Large-scale 1-1 NAT 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, 24 Sep 2007 08:58:23 -0000 Hi, Christopher Cowart wrote: > Hello, > > We're working on expanding our wireless network. Unfortunately, we're > running out of IP addresses (aren't we all). As much as I'd love to just > tell everyone to use IPv6, that isn't gonna fly. The next plan to > consider is using an RFC1918 pool and NATing the traffic. > > If only it were that simple. The security folks have mandated that > anyone who can talk to the internet at large must be individually > indentifiable. This means having hundreds of users NATing to a single > internet-routable IP isn't happening. We used to have this problem too, for some NATed networks. The solution which has been adopted is to capture the flows on the gateway and send them the security team. The netflow protocol is very well suited for this. > The real question is: what's the best way to dynamically update the NAT > table? You may use IPFW with IPNAT or PF instead. PF is able to reload its configuration without disruption. Moreover, because the state table is not flushed during a reload, you can even move NATed clients from one public IP to another, without them noticing. From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 09:05:44 2007 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 74B5A16A41B for ; Mon, 24 Sep 2007 09:05:44 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 1503213C45D for ; Mon, 24 Sep 2007 09:05:43 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 19374 invoked from network); 24 Sep 2007 04:05:41 -0500 Received: from 124-170-200-37.dyn.iinet.net.au (HELO localhost) (124.170.200.37) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Sep 2007 04:05:41 -0500 Date: Mon, 24 Sep 2007 19:05:38 +1000 From: Norberto Meijome To: "Kevin Oberman" Message-ID: <20070924190538.611cd644@meijome.net> In-Reply-To: <20070921171006.90BEF45027@ptavv.es.net> References: <20070921214602.38487d27@meijome.net> <20070921171006.90BEF45027@ptavv.es.net> X-Mailer: Claws Mail 3.0.1 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Quagga as border router 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, 24 Sep 2007 09:05:44 -0000 On Fri, 21 Sep 2007 10:10:06 -0700 "Kevin Oberman" wrote: > Ever run into a non-existent 'olive'? Hi Kevin, I dont understand :) > Or even a J series Juniper? > Juniper put together a very impressive software based routing system > that is FreeBSD based. Yes, I know of this, but ... I see that Richard has touched what I was going to ask, whether Juniper has extended the fbsd network code or simply used FBSD as the base to build their own system. It's the along the same lines as saying that OS-X was built from FBSD, isn't it ? If what you mean is "look at Juniper's cool/great routing software , using freebsd as a starting point - that kind of thing is what we should try to build" , excellent, that's the kind of answer i was trying to get from someone...what are we aiming for... thanks for your time :) B _________________________ {Beto|Norberto|Numard} Meijome "Produce great people, the rest will follow." Elbert Hubbard I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 09:33:42 2007 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 A56E916A419 for ; Mon, 24 Sep 2007 09:33:42 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 443F013C45B for ; Mon, 24 Sep 2007 09:33:42 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=M8xCqygFC3C5BRG/9/L6NdhSCweKMl6gKWU/uMWMbe2N77MS6oKU8+dHT9EZJDPV5Xi5vC0QnZA2DU98wxCWa4nQkKEw5pAQDtaWbfXj5PiZQv2LkGRg8tVZmxI94P9VfTZywxFbV4oy8DFaR+t73BW7Ro3PEsYnvYsP5sw3WGI=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1IZk23-000DCu-Md; Mon, 24 Sep 2007 13:15:11 +0400 Date: Mon, 24 Sep 2007 13:15:07 +0400 From: Eygene Ryabinkin To: Richard A Steenbergen Message-ID: <20070924091507.GB8111@void.codelabs.ru> References: <46F1AC0B.9040109@ibctech.ca> <46F1BDE1.8090102@gmail.com> <46F1E900.7070604@elischer.org> <46F1F376.3020609@ibctech.ca> <20070920072409.GT79417@elvis.mu.org> <20070920114839.M37866@swaggi.com> <20070921035449.GC1906@gerbil.cluepon.net> <20070921214602.38487d27@meijome.net> <20070921181006.GG1906@gerbil.cluepon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070921181006.GG1906@gerbil.cluepon.net> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.9 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: freebsd-net@freebsd.org, Norberto Meijome Subject: Re: Quagga as border router 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, 24 Sep 2007 09:33:42 -0000 Richard, good day. Fri, Sep 21, 2007 at 02:10:06PM -0400, Richard A Steenbergen wrote: > > Interesting.... what is the golden aim of software based router we should be > > trying to reach? > > Well for starters, to have a routing stack that is based on any modern > techniques developed in the last 20 years or so. It may not even matter, > there is plenty to FreeBSD that has absolutely nothing to do with routing, > and if all you're doing is throw 5Mbps at a core 2 duo it really doesn't > matter how the routing code is implemented. :) There are plenty of good > folks who understand all of this perfectly well (for example Andre > Oppermann), who are working hard to modernize fbsd's routing code, so I > have full faith that it will be fixed eventually. :) Could you please throw some links to these modern techniques? I am keen to read about it. Thank you. -- Eygene From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 10:57:49 2007 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 774C816A418 for ; Mon, 24 Sep 2007 10:57:49 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id EB88A13C43E for ; Mon, 24 Sep 2007 10:57:48 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.46.155] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1IZldA2mYx-0008DK; Mon, 24 Sep 2007 12:57:38 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Mon, 24 Sep 2007 12:57:19 +0200 User-Agent: KMail/1.9.7 References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> <46F77C27.9050400@net.utcluj.ro> In-Reply-To: <46F77C27.9050400@net.utcluj.ro> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3719595.xv0JBbdH5V"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709241257.27219.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19qSWHhcRHglcw4sGRNNpoO/4hhBEsIUvQkjH9 GmT1rAK4RvgfbenjDS8IaGKRS173VWbQ+av5LHa0XP5DeaFiLR MUHsGbphGTIc1BlPfWE0oEWOaiLdEWBgRbREcXCqP4= Cc: Cristian KLEIN , Christopher Cowart Subject: Re: Large-scale 1-1 NAT 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, 24 Sep 2007 10:57:49 -0000 --nextPart3719595.xv0JBbdH5V Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 24 September 2007, Cristian KLEIN wrote: > Hi, > > Christopher Cowart wrote: > > Hello, > > > > We're working on expanding our wireless network. Unfortunately, we're > > running out of IP addresses (aren't we all). As much as I'd love to > > just tell everyone to use IPv6, that isn't gonna fly. The next plan > > to consider is using an RFC1918 pool and NATing the traffic. > > > > If only it were that simple. The security folks have mandated that > > anyone who can talk to the internet at large must be individually > > indentifiable. This means having hundreds of users NATing to a single > > internet-routable IP isn't happening. > > We used to have this problem too, for some NATed networks. The solution > which has been adopted is to capture the flows on the gateway and send > them the security team. The netflow protocol is very well suited for > this. > > > The real question is: what's the best way to dynamically update the > > NAT table? > > You may use IPFW with IPNAT or PF instead. PF is able to reload its > configuration without disruption. Moreover, because the state table is > not flushed during a reload, you can even move NATed clients from one > public IP to another, without them noticing. In fact pf comes with an almost ready-made sollution. Check out authpf(8)= =20 for details. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3719595.xv0JBbdH5V Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG95gWXyyEoT62BG0RArAJAJsFohxWX58R9qWFN3gZBJbfKN3XYgCfeB2y +jtgieVrxM1nMQ32VikG1to= =djUd -----END PGP SIGNATURE----- --nextPart3719595.xv0JBbdH5V-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 11:08:31 2007 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 3072916A473 for ; Mon, 24 Sep 2007 11:08:31 +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 EA78D13C494 for ; Mon, 24 Sep 2007 11:08:30 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8OB8UHa064248 for ; Mon, 24 Sep 2007 11:08:30 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8OB8Tql064244 for freebsd-net@FreeBSD.org; Mon, 24 Sep 2007 11:08:29 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Sep 2007 11:08:29 GMT Message-Id: <200709241108.l8OB8Tql064244@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 you 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, 24 Sep 2007 11:08:31 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge o kern/116172 net Network / ipv6 recursive mutex panic 2 problems total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/21998 net [socket] [patch] ident only for outgoing connections a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net 6.2-STABLE panic during use of multi-cast networking c o kern/116185 net if_iwi driver leads system to reboot o kern/116186 net can not set wi channel on current o kern/116328 net [bge]: Solid hang with bge interface o kern/116330 net [nfe]: network problems under -current, nfe(4) and jum 24 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114095 net [carp] carp+pf delay with high state limit o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f 14 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 13:51:27 2007 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 55CF916A420 for ; Mon, 24 Sep 2007 13:51:27 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 1811313C459 for ; Mon, 24 Sep 2007 13:51:27 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1265207rvb for ; Mon, 24 Sep 2007 06:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XqpGgheV0QWbo5ft+TmTVGjayJpLfehRFksHODTYDQU=; b=fUScWnFoeFBGxjvcT6vKpFkYAOnXsMb3iNolZd++Onx/qntwz7g6Wi4swtjF4JUECXMPB+4Ce7U8U5ffL+63qVCJCLwOa4MbuWZ9nxRBdBFTlCxlx3+ECgO+sLxMYqzTKvURl/hwzP+IPrw+73a2qwtLKCV2NCPUuPuFdXAxUUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E/Yn5kI+GjyUGERIk/9NVRTDMEh2xmqIUos9qDMyzkFisxGp0roqY8GtGcqf2ZmW49fdnjaJZZbavWoCj0+5q+CV4GE1YqxVvr7wgJeyCRbh0qxBDgDDRVno8FfEJ19kxDYwuMnN6F9vqOqNcPFJJJ8vMkgSnTLaTpU+D4Q/7ho= Received: by 10.114.196.1 with SMTP id t1mr6882323waf.1190641886641; Mon, 24 Sep 2007 06:51:26 -0700 (PDT) Received: by 10.115.109.10 with HTTP; Mon, 24 Sep 2007 06:51:26 -0700 (PDT) Message-ID: Date: Mon, 24 Sep 2007 09:51:26 -0400 From: "Scott Ullrich" To: "Scott Ullrich" , "VANHULLEBUS Yvan" , freebsd-net@freebsd.org In-Reply-To: <20070924075252.GN19429@hal.rescomp.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070818102803.GA1319@jayce.zen.inc> <20070924075252.GN19429@hal.rescomp.berkeley.edu> Cc: Subject: Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2 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, 24 Sep 2007 13:51:27 -0000 On 9/24/07, Christopher Cowart wrote: > On Sat, Aug 18, 2007 at 03:58:16PM -0400, Scott Ullrich wrote: > How are you detecting when racoon gets wedged? I'd like to replicate > that on our systems. Our script is primitive at best but does seem to do the job okay: http://pfsense.com/cgi-bin/cvsweb.cgi/pfSense/usr/local/sbin/racoon_watch.sh?rev=1.8;content-type=text%2Fplain Let me know if it helps. This generally well detect the problem quick enough to minimize downtime between the tunnels (in our experience). Scott From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 16:21:48 2007 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 BC68916A41A for ; Mon, 24 Sep 2007 16:21:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outN.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id A55B013C43E for ; Mon, 24 Sep 2007 16:21:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 24 Sep 2007 09:21:47 -0700 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id CDB301264B0 for ; Mon, 24 Sep 2007 09:21:46 -0700 (PDT) Message-ID: <46F7E420.8050202@elischer.org> Date: Mon, 24 Sep 2007 09:21:52 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> In-Reply-To: <20070924072517.GL19429@hal.rescomp.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Large-scale 1-1 NAT 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, 24 Sep 2007 16:21:48 -0000 Christopher Cowart wrote: > Hello, > > We're working on expanding our wireless network. Unfortunately, we're > running out of IP addresses (aren't we all). As much as I'd love to just > tell everyone to use IPv6, that isn't gonna fly. The next plan to > consider is using an RFC1918 pool and NATing the traffic. > > If only it were that simple. The security folks have mandated that > anyone who can talk to the internet at large must be individually > indentifiable. This means having hundreds of users NATing to a single > internet-routable IP isn't happening. Are you sure it doesn't just mean you need to keep logs of who was NAT'd to what at any time? > > I want to try a setup in which we have a big RFC1918 pool of addresses, > say 10.8/16. In their initial state, these hosts might NAT to a single > public IP and perform some transparent proxying to get them to an > authentication page. The firewall on our NAT box would be extremely > restrictive for these clients. > > When a user authenticates, we will allocate a single public IP for the > session. At this time, our code would use ipfw to move the user into a > different lookup table and also update the NAT table. > > The real question is: what's the best way to dynamically update the NAT > table? I don't think we have the ability to do that. it may take some coding on your part. > > It doesn't look like there's any way to have a running natd update its > configuration without restarting. That's obviously disruptive. > > I also doubt it's a good idea to try to launch a single natd process per > authenticated client. We have a /22 and a /23 in our public pools, and > we expect to max that out (1500+ clients). > > Has anyone attempted a setup like this? Do you have any pointers for > designing this to scale well? We are planning on throwing hardware at > it, but that only gets us so far. never heard of such a setup. I suggest you find out if that is the only solution your security people would accept. (As someone doing security stuff for a few years I think that someone is confused somewhere). > > Thanks for your help, > From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 17:28:02 2007 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 D83E416A420 for ; Mon, 24 Sep 2007 17:28:02 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 726B813C45A for ; Mon, 24 Sep 2007 17:28:02 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1230116nfb for ; Mon, 24 Sep 2007 10:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=rsLr4qpMF9BYwrS8aFA2s8fFxMOpQA3hEitfOjdyysw=; b=cTU5BvXEUDR2lfAM7iLIJXF7v1ctsG7ymFFCmOnyvsKFp+/D1i4z11G1dBmxW4lWE5SbtafSb1NehVhrcqARgj5kZNt2Upoi/Es+rXnY2sxR0tTXY84v2O8wulEI0qmWchwXbrwsPrmA9q08uOl+qpxiLy2PX9iv5u7nRlfEJ/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qXeYMVcHrOqnwWYi7eCQ2xRb09s0e+tOgIClVdNQSD35SZdNgezUp/XHvyWV5f5s6Y6B/wo547meBuJap+yON1TM4eGGUd7fS66viwQUiprFPWjWPvcgvYYZWaXFTS9DNIqBRRtYmhBSH3n+iG7zfIg+gw0GMu14Vy4U4HyLNi4= Received: by 10.86.80.5 with SMTP id d5mr4877997fgb.1190654881016; Mon, 24 Sep 2007 10:28:01 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Mon, 24 Sep 2007 10:28:00 -0700 (PDT) Message-ID: <2a41acea0709241028q2503f12fp86eea2d32ac10aa7@mail.gmail.com> Date: Mon, 24 Sep 2007 10:28:00 -0700 From: "Jack Vogel" To: "Kip Macy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com> <46F614F2.4050402@freebsd.org> Cc: Darren Reed , "freebsd-net@freebsd.org" , FreeBSD Current Subject: Re: TX Multiqueue? 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, 24 Sep 2007 17:28:02 -0000 On 9/23/07, Kip Macy wrote: > On 9/23/07, Darren Reed wrote: > > Kip Macy wrote: > > > My ethng branch supports multiple rx and tx queues. > > > > > > -Kip > > > > > > > What are your plans for how we use/manage/interact with the mutiple > > rx/tx queues? > > The rx hardware queue is determined by the hardware. Different > hardware allows for different policies. I just use the stock rss_hash > of a crc32 of the 4-tuple in cxgb. I've added a field to the pkthdr > which cxgb uses the least significant bits of to determine which > outbound queue to use. Its up to the upper layers to determine how to > set those bits. One of the changes that is required to take advantaged > of this is moving the queues into the driver. I've added a new > if_start function to ifnet to take advantage of this. I also have a > normal if_start function for backward compatibility. Yes, the queues in Oplin and Zoar are also a hardware feature, not just some software infrastructure. There are a number of different ways that it can be configured. I did not have some settled notion of how things should be managed but I would rather not have it be something done under the covers in the driver, a configurable stack option seems better to me. This needs to be done right or it will just be a hack, I don't know who the right parties are, it should not be just a one-person decision, those with a stake in this sort of thing should all be involved. Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 20:06:06 2007 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 1DC3416A417 for ; Mon, 24 Sep 2007 20:06:06 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 0D02313C4B3 for ; Mon, 24 Sep 2007 20:06:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IZuBw-0003uz-Al; Mon, 24 Sep 2007 20:06:04 +0000 Message-ID: <46F8189B.900@psg.com> Date: Mon, 24 Sep 2007 10:05:47 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christer Hermansson References: <46F5FF0A.7030203@psg.com> <46F68B1C.6020303@chdevelopment.se> In-Reply-To: <46F68B1C.6020303@chdevelopment.se> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Re: nat and ipfw - divert or builtin 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, 24 Sep 2007 20:06:06 -0000 > divert > ipnat > ipfw's integrated nat > > I believe the integrated version makes configuration simpler. I would > choose the old classic divert with ipfw if it is for a important network > that must work, but if I was running -current I would try the integrated > variant beacuse it seems to be simpler to use. you seem to imply that you have reason to suspect that ipfw integrated nat might not be reliable, or at least not as reliable as divert+natd. any particular experiences or gossip to tell? randy From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 20:35:17 2007 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 2952F16A46B for ; Mon, 24 Sep 2007 20:35:17 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id BA1A013C44B for ; Mon, 24 Sep 2007 20:35:16 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id A37AC3C0482; Mon, 24 Sep 2007 13:35:16 -0700 (PDT) Date: Mon, 24 Sep 2007 13:35:16 -0700 From: Christopher Cowart To: freebsd-net@freebsd.org Message-ID: <20070924203516.GQ19429@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> <46F77C27.9050400@net.utcluj.ro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6JKsAUbrJhuSllgx" Content-Disposition: inline In-Reply-To: <46F77C27.9050400@net.utcluj.ro> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: Large-scale 1-1 NAT 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, 24 Sep 2007 20:35:17 -0000 --6JKsAUbrJhuSllgx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 24, 2007 at 11:58:15AM +0300, Cristian KLEIN wrote: >Christopher Cowart wrote: >>We're working on expanding our wireless network. Unfortunately, we're >>running out of IP addresses (aren't we all). As much as I'd love to just >>tell everyone to use IPv6, that isn't gonna fly. The next plan to=20 >>consider is using an RFC1918 pool and NATing the traffic. >> >>If only it were that simple. The security folks have mandated that >>anyone who can talk to the internet at large must be individually >>indentifiable. This means having hundreds of users NATing to a single >>internet-routable IP isn't happening. > >We used to have this problem too, for some NATed networks. The solution wh= ich >has been adopted is to capture the flows on the gateway and send them the >security team. The netflow protocol is very well suited for this. We have automated intake and processing for security cases. These often just contain the IP the bad traffic appeared to be coming from. While we could probably reconstruct things using netflow, we definitely wouldn't have the staff time to do so. As such, we'd have to keep this information in a database, which will add up fast. Keeping track who was using an IP at a given time is relatively easy. Granted, this places the complexity in the network and not the security processing, but that's where we have resources. >>The real question is: what's the best way to dynamically update the NAT >>table? > >You may use IPFW with IPNAT or PF instead. PF is able to reload its >configuration without disruption. Moreover, because the state table is not >flushed during a reload, you can even move NATed clients from one public I= P to >another, without them noticing. We would prefer to stick with ipfw. The most common documentation I've founded is natd+ipfw. I've also seen pf+ipnat. I haven't really seen any documentation on ipfw+ipnat. Is this possible? Or would we be able to do ipfw+pf+ipnat? What solution would scale best to 1500-4000 authenticated users? --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --6JKsAUbrJhuSllgx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvgfhCPHEDszU3zYAQJ6pA/+NRNqxCImYwNd9Ovhl6eTM+v2JgfIGTnY +EEO+urvaia0YtSh7R3jsW+lbLSEAqd0LIn6Zien88cCqznVNo7VEM9ZoMcmVQCQ U/232xI7KV4BkaFoZHpkUvw+4RRsmWXJm5k8z/G7/xkj2stoz8cQmYmR2ycVLnWb RhoMD5LH7tEGqp2Zs+yd2+SSu426J7XGymDWTIIL36Iw/MthS52/O+P0nMYzPqtG aP8vS+n0yuAbEFonTwd+800iN+NM69K06RVVgaKPWGC+JBCyIu6JovssmW+t4sQ/ Fj6+IappcLw+T0noun2G4H9USjGTLtfBDuXSprCWwCJFiOYa8zKL/GQMECkdm1KL sRipptgCyENpSYNWp6WXh0Pw5Ds+XU0o9d7bR/aY7TVhOQYKYwhMT/nbGU1Iv1wS 0kA87myF1+IU+1u5jZ0hmubctaOaVvE7NolQ66Fp0TcETIC5QWW6ashxvTRvfkv5 TfXL9yDdjHNdbe8vPPVOzuFjF3hY9GsNBHER9f5Q3Wkj7mhos3xWj7cfTd2I5ES1 oG3k4I5V1BJuL9lc4sXfhexsqoVrp2LUQ/N7hXig9C8A6wAUS54BrSEhIrNJL+rP e3LxGdOHNVFSBb8xf6WLrzQ+MCRoz7uFiGOjdEsCE4bigoiHKdaflJvBDwDH8z2c yU5qX66EJnI= =Aw9q -----END PGP SIGNATURE----- --6JKsAUbrJhuSllgx-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 20:37:29 2007 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 8C67A16A419 for ; Mon, 24 Sep 2007 20:37:29 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 7D28313C457 for ; Mon, 24 Sep 2007 20:37:29 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 6F7023C0482; Mon, 24 Sep 2007 13:37:29 -0700 (PDT) Date: Mon, 24 Sep 2007 13:37:29 -0700 From: Christopher Cowart To: freebsd-net@freebsd.org Message-ID: <20070924203729.GR19429@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> <46F77C27.9050400@net.utcluj.ro> <200709241257.27219.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiSnftFthKPM0z4v" Content-Disposition: inline In-Reply-To: <200709241257.27219.max@love2party.net> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: Large-scale 1-1 NAT 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, 24 Sep 2007 20:37:29 -0000 --YiSnftFthKPM0z4v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 24, 2007 at 12:57:19PM +0200, Max Laier wrote: > On Monday 24 September 2007, Cristian KLEIN wrote: > > Christopher Cowart wrote: > > > The real question is: what's the best way to dynamically update the > > > NAT table? > > > > You may use IPFW with IPNAT or PF instead. PF is able to reload its > > configuration without disruption. Moreover, because the state table is > > not flushed during a reload, you can even move NATed clients from one > > public IP to another, without them noticing. >=20 > In fact pf comes with an almost ready-made sollution. Check out authpf(8= )=20 > for details. That looks pretty cool. The problem is these are not local users; the only way to authenticate them is to use web-based services. --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --YiSnftFthKPM0z4v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvggCSPHEDszU3zYAQIKLxAAoCnvCgQj3mKqcBrEsVnnXSuKtHbaOTt2 VDPeUDK+NLc6tFVrfZ2GRVSeEK3nNrlbqeWDZtMR+XG4IMarDO41JyFt9sOY3UTb dK+s7lEA7XNQ1JZ7h6dwtiX/ZkG6wR2248+KcOgObgceegMmFXwwPqsOyAEXLnYY 6dm+aWfqgO6YWiwTGyMMUfdzdMfT33p5vfMvYmbcUKKJ4D71IGNuKmLmDmE6WY97 QgSjsGUsxGDV0hDL9x8URBCz5FrxLDtA2IMtVf5u3YZ+wCBxU8IuCYGOjox+JAmK G9zWUDpy8jIiL0xTkgFtEcGq9pYsZRMJwXcXJ+GInEonWICe0ZKAePNGePkyLk2H OwGDfCE6QyOr7mWrEQOnIxe3xAiamJ8j5EQeSM3Z3TmaCfG5ixl7w1CHDEi1TUyk B8tHCAMP/ZZhkulOcrYPW3E5GEmL8hxZ2a39xI0RNGCUFQJC4mKtAdxv4RsKHpma +uJAlxxDmPo7vWi8P+c7v5G2N+9kaweF6w3PQCmO9F2jXHTtc9TcwU2k9EKp0y9Y PfvgNA45RPcPd2P+1SV2WkXkd7VOTmKL+TuXCvsHq4e4582iFhxaxuOHaxOYVxSB as9OTmuiOZCln57eOWoRw1RPNvczx+JuMFiTwxdV5aAGK6P66/8/8zMQOVsQyY8u OmsNOHuzikI= =aKMp -----END PGP SIGNATURE----- --YiSnftFthKPM0z4v-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 20:55:44 2007 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 E5B9816A417 for ; Mon, 24 Sep 2007 20:55:44 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id D636A13C45B for ; Mon, 24 Sep 2007 20:55:44 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id C3B7C3C0490; Mon, 24 Sep 2007 13:55:44 -0700 (PDT) Date: Mon, 24 Sep 2007 13:55:44 -0700 From: Christopher Cowart To: alexzimnitsky@yandex.ru, freebsd-net@freebsd.org Message-ID: <20070924205544.GS19429@hal.rescomp.berkeley.edu> Mail-Followup-To: alexzimnitsky@yandex.ru, freebsd-net@freebsd.org References: <9RCt3Xt6F9n7.d4lvWzS3@smtp.yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I30T0A8abtL/6dyk" Content-Disposition: inline In-Reply-To: <9RCt3Xt6F9n7.d4lvWzS3@smtp.yandex.ru> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: Large-scale 1-1 NAT 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, 24 Sep 2007 20:55:45 -0000 --I30T0A8abtL/6dyk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 24, 2007 at 01:26:13PM +0400, alexzimnitsky@yandex.ru wrote: > original: >> We're working on expanding our wireless network. Unfortunately, we're >> running out of IP addresses (aren't we all). As much as I'd love to just >> tell everyone to use IPv6, that isn't gonna fly. The next plan to=20 >> consider is using an RFC1918 pool and NATing the traffic. >>=20 >> If only it were that simple. The security folks have mandated that >> anyone who can talk to the internet at large must be individually >> indentifiable. This means having hundreds of users NATing to a single >> internet-routable IP isn't happening. >=20 > do your security foulks want connections to be identifiable=20 > outside-in or inside-out? If inside-out then netflow before single=20 > ip nat should do the trick Complaints from the outside world must be traceable to a single individual behind the NAT. This is a significantly easier, especially in automated case handling, when only one person is using a public IP at a time. >> I want to try a setup in which we have a big RFC1918 pool of addresses, >> say 10.8/16. In their initial state, these hosts might NAT to a single >> public IP and perform some transparent proxying to get them to an >> authentication page. The firewall on our NAT box would be extremely >> restrictive for these clients. >>=20 >> When a user authenticates, we will allocate a single public IP for the >> session. At this time, our code would use ipfw to move the user into a >> different lookup table and also update the NAT table. >>=20 >> The real question is: what's the best way to dynamically update the NAT >> table? >=20 > we used pf to binat people (in parallel with ipfw to filter them).=20 > How are you going to nat them (ipf, pf, netgraph)? Updating rules on=20 > the fly was as simple as reloading them (no disruption to existing=20 > pf states). Netgraph nat states behave similarly. The real problem=20 > with pf binat was when we had about a hundred binat rules it almost=20 > halted the traffic through the router. Are you suggesting that a pf solution isn't going to scale well on the order of 1500 clients? We may even get additional public address space to support 4000 or more clients. Will netgraph scale better? >> It doesn't look like there's any way to have a running natd update its >> configuration without restarting. That's obviously disruptive. >=20 > use ipfw+netgraph instead So you recommend ipfw+netgraph? We don't have any experience working with netgraph. I see ng_nat(4), but if anyone could point me to a more thorough howto, I'd greatly appreciate it. >> I also doubt it's a good idea to try to launch a single natd process per >> authenticated client. We have a /22 and a /23 in our public pools, and >> we expect to max that out (1500+ clients). >=20 > you are right. It is not. > My expirience is it is bad idea to even have more than a couple of=20 > doezns binat rules in sequence (although i tried it with pf, not=20 > with netgraph). >=20 >> Has anyone attempted a setup like this? Do you have any pointers for >> designing this to scale well? We are planning on throwing hardware at >> it, but that only gets us so far. >=20 > my ploblem was how to not reserve large number of small address=20 > pools in advance and use a single pool of /22 to number customers=20 > belonging to many different physical segments (even living behind=20 > different routers). >=20 > i used binat first but it scaled badly, so i found a better=20 > solution. I guess you problem is different. What do you mean? We do have 3 discontiguous subnets (/22, /23, /26), and may add one or more /22 or /23 subnets in the future, so we definitely need the ability to pull from various pools. Our NAT box=20 will be attached to a trunked interface and use vlan interfacess to=20 reach the routers for each of the subnets. Thanks for your experiences trying to get binat to scale -- we were definitely considering the pf+ipnat solution. --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --I30T0A8abtL/6dyk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvgkUCPHEDszU3zYAQJpEA/9EQW1YzBnMLZ3fjpeJJDrj1juOT8bn18Y vQbXNT9v6+st1uspwLZlH4/0AUn+eYQEl0XpwlgNdPE6RArhjeyGmo74szdl67qv KNZyRlJ88haFFgOiQGKsH5dYqEtD8F3gjJo6UGJtdINuFvqR4o0vkVOB97LnSMhq oTuv0yBqSEy/hwNHWqe2eKqy7eLti5LiArRt0x9lIZ8B37XwD3DhEL+jYdGulCzL KV4AiwMvkU+BO5BftHYyMqODZ7QkT6x2r6uO/rb+4EOIoJty7da3oBWmkAHVuwZL OHYdLyvT9uzWBzdoZ+d6JB8Plhppe7fRUWDLa9nyJvG0MQS099QD8rvU8+V4vnwT TzhXEUeIrx7gerWI0dw/8GtI+ow2m/K0sFpnjF38MgJLqoj5rlojuTmAPSVP+nmc wTbN8AzgRnEEpgO5vT6P+0xBeKpFSlq+b7ixd/CANjKxrCpLSC6dUu2JHgzeT9KA 0A9rJ+R9WaZ1cDz4+Fc89DaJypcdH134HTNyFf4m2m77p7YIcGXYBmoHcUrjtjh8 /tQnvaNy2UllVXTkSns3ef+RbxH/ZkFZ4WrlayG2qxuZfZdB9L1IzBoOoKWgendE WFEwqAHwbc+eOLZtwqhuwosxHZEoh0Dv9odSrObF1d40erk8YZl/YdAhv5HVHTPt 3zHOGcvDNtM= =X2hv -----END PGP SIGNATURE----- --I30T0A8abtL/6dyk-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 21:44:56 2007 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 493D316A419 for ; Mon, 24 Sep 2007 21:44:56 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (unknown [IPv6:2001:b30:5000:2:20e:cff:fe4b:ca01]) by mx1.freebsd.org (Postfix) with ESMTP id B94A913C457 for ; Mon, 24 Sep 2007 21:44:55 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id 8C3EF50888 for ; Tue, 25 Sep 2007 00:44:54 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNFNrSnWpIf2 for ; Tue, 25 Sep 2007 00:44:48 +0300 (EEST) Received: from [172.27.2.200] (c7.campus.utcluj.ro [193.226.6.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 5260B50873 for ; Tue, 25 Sep 2007 00:44:48 +0300 (EEST) Message-ID: <46F82FCF.2090203@net.utcluj.ro> Date: Tue, 25 Sep 2007 00:44:47 +0300 From: Cristian KLEIN User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> <46F77C27.9050400@net.utcluj.ro> <20070924203516.GQ19429@hal.rescomp.berkeley.edu> In-Reply-To: <20070924203516.GQ19429@hal.rescomp.berkeley.edu> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Large-scale 1-1 NAT 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, 24 Sep 2007 21:44:56 -0000 Christopher Cowart wrote: > On Mon, Sep 24, 2007 at 11:58:15AM +0300, Cristian KLEIN wrote: >> Christopher Cowart wrote: >>> We're working on expanding our wireless network. Unfortunately, we're >>> running out of IP addresses (aren't we all). As much as I'd love to just >>> tell everyone to use IPv6, that isn't gonna fly. The next plan to >>> consider is using an RFC1918 pool and NATing the traffic. >>> >>> If only it were that simple. The security folks have mandated that >>> anyone who can talk to the internet at large must be individually >>> indentifiable. This means having hundreds of users NATing to a single >>> internet-routable IP isn't happening. >> We used to have this problem too, for some NATed networks. The solution which >> has been adopted is to capture the flows on the gateway and send them the >> security team. The netflow protocol is very well suited for this. > > We have automated intake and processing for security cases. These often > just contain the IP the bad traffic appeared to be coming from. While we > could probably reconstruct things using netflow, we definitely wouldn't > have the staff time to do so. As such, we'd have to keep this > information in a database, which will add up fast. Keeping track who was > using an IP at a given time is relatively easy. Granted, this places the > complexity in the network and not the security processing, but that's > where we have resources. I must admit I haven't thought of this. With this new information I am missing a point. Since you need to make a 1-to-1 association between clients and public IPs, why do you need the NAT at all. Is this to save public IPs by NOT giving them to unauthenticated users? There is another thing I wanted to point out. I remember you used the words "authentication web page". This made me think you are establishing a captive portal, which is not secure at all. If I understand well the authpf solution would be secure, except perhaps a small delay. You might proxy your clients to a "click here and download this preconfigured PuTTY" page. >>> The real question is: what's the best way to dynamically update the NAT >>> table? >> You may use IPFW with IPNAT or PF instead. PF is able to reload its >> configuration without disruption. Moreover, because the state table is not >> flushed during a reload, you can even move NATed clients from one public IP to >> another, without them noticing. > > We would prefer to stick with ipfw. The most common documentation I've > founded is natd+ipfw. I've also seen pf+ipnat. I haven't really seen any > documentation on ipfw+ipnat. Is this possible? Or would we be able to do > ipfw+pf+ipnat? What solution would scale best to 1500-4000 authenticated > users? I have used ipfw + pf for almost a year, for about 400 clients and I am very happy with it. Note that I only use ipfw for dummynet. In all other situations I only use PF. PF uses a binary tree to store NAT states, so it isn't really affected by the number of clients. It also features state timeouts reduction based on the number of NAT states, which is very useful if one Windows station gets a "lets scan the whole /16" virus. From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 22:57:45 2007 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 18A4116A41B for ; Mon, 24 Sep 2007 22:57:45 +0000 (UTC) (envelope-from mail@chdevelopment.se) Received: from av9-1-sn3.vrr.skanova.net (av9-1-sn3.vrr.skanova.net [81.228.9.185]) by mx1.freebsd.org (Postfix) with ESMTP id C34C413C4BB for ; Mon, 24 Sep 2007 22:57:44 +0000 (UTC) (envelope-from mail@chdevelopment.se) Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 7B88938739; Tue, 25 Sep 2007 00:57:43 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 6151338008; Tue, 25 Sep 2007 00:57:43 +0200 (CEST) Received: from melissa.chdevelopment.se (90-227-26-163-no68.tbcn.telia.com [90.227.26.163]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 1EFA037E60; Tue, 25 Sep 2007 00:57:42 +0200 (CEST) Message-ID: <46F840E6.4050007@chdevelopment.se> Date: Tue, 25 Sep 2007 00:57:42 +0200 From: Christer Hermansson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.6) Gecko/20070811 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Randy Bush References: <46F5FF0A.7030203@psg.com> <46F68B1C.6020303@chdevelopment.se> <46F8189B.900@psg.com> In-Reply-To: <46F8189B.900@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: nat and ipfw - divert or builtin 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, 24 Sep 2007 22:57:45 -0000 Randy Bush wrote: >> divert >> ipnat >> ipfw's integrated nat >> >> I believe the integrated version makes configuration simpler. I would >> choose the old classic divert with ipfw if it is for a important network >> that must work, but if I was running -current I would try the integrated >> variant beacuse it seems to be simpler to use. >> > > you seem to imply that you have reason to suspect that ipfw integrated > nat might not be reliable, or at least not as reliable as divert+natd. > any particular experiences or gossip to tell? > > No, like I said I only have experience with divert, but in my opinion it's best to not use the latest software for things that *must* work and the integrated nat is a new thing and only available for -current. However it's based on something that been around for a while, libalias, so I guess it's stable. I'm planning on trying to use ipnat with ipfw on freebsd 6.2 because I think that's simpler than divert and has been around for a while. But again if I was running a system based on -current I would go for the integrated variant. -- Christer Hermansson From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 00:06:04 2007 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 167FA16A418 for ; Tue, 25 Sep 2007 00:06:03 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id EFBE813C43E for ; Tue, 25 Sep 2007 00:06:02 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 8EE1E3C048D; Mon, 24 Sep 2007 17:06:02 -0700 (PDT) Date: Mon, 24 Sep 2007 17:06:02 -0700 From: Christopher Cowart To: freebsd-net@freebsd.org Message-ID: <20070925000602.GT19429@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> <46F77C27.9050400@net.utcluj.ro> <20070924203516.GQ19429@hal.rescomp.berkeley.edu> <46F82FCF.2090203@net.utcluj.ro> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RNYIsZSUNfbU4BwD" Content-Disposition: inline In-Reply-To: <46F82FCF.2090203@net.utcluj.ro> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: Large-scale 1-1 NAT 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, 25 Sep 2007 00:06:04 -0000 --RNYIsZSUNfbU4BwD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2007 at 12:44:47AM +0300, Cristian KLEIN wrote: >Christopher Cowart wrote: >> On Mon, Sep 24, 2007 at 11:58:15AM +0300, Cristian KLEIN wrote: >>> Christopher Cowart wrote: >>>> We're working on expanding our wireless network. Unfortunately, we're >>>> running out of IP addresses (aren't we all). As much as I'd love to ju= st >>>> tell everyone to use IPv6, that isn't gonna fly. The next plan to=20 >>>> consider is using an RFC1918 pool and NATing the traffic. >>>> >>>> If only it were that simple. The security folks have mandated that >>>> anyone who can talk to the internet at large must be individually >>>> indentifiable. This means having hundreds of users NATing to a single >>>> internet-routable IP isn't happening. >>> We used to have this problem too, for some NATed networks. The=20 >>> solution which has been adopted is to capture the flows on the=20 >>> gateway and send them the security team. The netflow protocol is=20 >>> very well suited for this. >>=20 >> We have automated intake and processing for security cases. These often >> just contain the IP the bad traffic appeared to be coming from. While we >> could probably reconstruct things using netflow, we definitely wouldn't >> have the staff time to do so. As such, we'd have to keep this >> information in a database, which will add up fast. Keeping track who was >> using an IP at a given time is relatively easy. Granted, this places the >> complexity in the network and not the security processing, but that's >> where we have resources. > > I must admit I haven't thought of this. With this new information I=20 > am missing a point. Since you need to make a 1-to-1 association=20 > between clients and public IPs, why do you need the NAT at all. Is=20 > this to save public IPs by NOT giving them to unauthenticated users? This is exactly the point. At any given time, people may have their laptop sitting in their rooms plugged into a wired connection or they may be walking near an access point with an iPhone on their person. All of these devices are associating with our APs and eating up public IP addresses, even though they aren't using the network. Our goal is to only allocate the device a public AP after authentication has occured. > There is another thing I wanted to point out. I remember you used the=20 > words "authentication web page". This made me think you are=20 > establishing a captive portal, which is not secure at all. If I=20 > understand well the authpf solution would be secure, except perhaps=20 > a small delay. You might proxy your clients to a "click here and=20 > download this preconfigured PuTTY" page. We are planning on using a captive portal. The only authentication mechanism we have for clients is a web-based SSO solution using CAS that isn't maintained by our staff. The people trying to authenticate are not intended to be local users on the system. What are the security problems you see with a captive portal interface? >>>> The real question is: what's the best way to dynamically update the NAT >>>> table? >>> You may use IPFW with IPNAT or PF instead. PF is able to reload its >>> configuration without disruption. Moreover, because the state table is = not >>> flushed during a reload, you can even move NATed clients from one=20 >>> public IP to another, without them noticing. >>=20 >> We would prefer to stick with ipfw. The most common documentation I've >> founded is natd+ipfw. I've also seen pf+ipnat. I haven't really seen any >> documentation on ipfw+ipnat. Is this possible? Or would we be able to do >> ipfw+pf+ipnat? What solution would scale best to 1500-4000 authenticated >> users? > > I have used ipfw + pf for almost a year, for about 400 clients and I=20 > am very happy with it. Note that I only use ipfw for dummynet. In=20 > all other situations I only use PF. > > PF uses a binary tree to store NAT states, so it isn't really=20 > affected by the number of clients. It also features state timeouts=20 > reduction based on the number of NAT states, which is very useful if=20 > one Windows station gets a "lets scan the whole /16" virus. I received a response off-list (to which I replied on-list) from somebody who said the pf binat solution doesn't scale will beyond 500 clients. We currently have over 1500 public IPs that could be in use,=20 and we may eventually have more than 4000. Can anyone confirm this=20 limitation?=20 --=20 Chris Cowart Lead Systems Administrator Network & Infrastructure Services, RSSP-IT UC Berkeley --RNYIsZSUNfbU4BwD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBRvhQ6iPHEDszU3zYAQKYgw//S6beV0UEc4cXrmRVy6uH3fCS8kzzDbSK 9kTSUXBl6DHixGRwoZ2dUn1RYEiMX4A1ftsSdvTn1UGuohUrrceoOlY6tFHBSzzH o0Ei/33Jl1OTbSU0R0q7HbEasihMu1DtK8yrRPX+GfIIH5o6AHs06+EWuJjdaDd1 Az2lxonQKqkzrEAAz+VOjnA2s/vClVB48/k5q0VHEjnN8NB5HOz4hqBqFt46brTz X+JB5N99IPIjwpSKmlQLQAd9cInb0e1wb+OjTWUZGQOyc8Fb9yBOHYsQ52oY8Q0e SLWCgBmaj8iBCkyj0qxP712HvUkDuvxiIc7O6ETvMb4svI8UyOi1n+IEGNldKbDK iMIgLamXAQUbZ1x6DXyDxAhEFQns10VmK00flzXQQK0V9pn5Zd1d2yHfOjvbDU1q 4kDwX125qsijaNGLRgoBxwcXOUzRhJh8hRiDyxSUn4hDvGWDayEJ95BndK/hieFZ N4oDj+ABS372X2pxJIia0XPXVwcKIRw3tv5vRlSlGYdz32k9ymzyH/aPvjP1jWxr oAwdVk/WhBJIZMx6V4gK//uK2zmzZnetp3ktb0RGCGoDmkQi7QfY+fTH9G/bkRon i8bbpA6SI65GRgyLKzdOhTlN8HMiUa7fx55fEqasXI44vDxdnTo1vVe3z+txB8v7 1b90WqNF1/Q= =DwhU -----END PGP SIGNATURE----- --RNYIsZSUNfbU4BwD-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 07:10:52 2007 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 CFEDD16A419 for ; Tue, 25 Sep 2007 07:10:52 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from bavaria.utcluj.ro (unknown [IPv6:2001:b30:5000:2:20e:cff:fe4b:ca01]) by mx1.freebsd.org (Postfix) with ESMTP id 3287B13C447 for ; Tue, 25 Sep 2007 07:10:52 +0000 (UTC) (envelope-from cristi@net.utcluj.ro) Received: from localhost (localhost [127.0.0.1]) by bavaria.utcluj.ro (Postfix) with ESMTP id F06FE5088A for ; Tue, 25 Sep 2007 10:10:50 +0300 (EEST) X-Virus-Scanned: by the daemon playing with your mail on local.mail.utcluj.ro Received: from bavaria.utcluj.ro ([127.0.0.1]) by localhost (bavaria.utcluj.ro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrXNhVKOsjwY for ; Tue, 25 Sep 2007 10:10:44 +0300 (EEST) Received: from [172.27.2.200] (c7.campus.utcluj.ro [193.226.6.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bavaria.utcluj.ro (Postfix) with ESMTP id 72D8950894 for ; Tue, 25 Sep 2007 10:10:44 +0300 (EEST) Message-ID: <46F8B474.5050609@net.utcluj.ro> Date: Tue, 25 Sep 2007 10:10:44 +0300 From: Cristian KLEIN User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20070924072517.GL19429@hal.rescomp.berkeley.edu> <46F77C27.9050400@net.utcluj.ro> <20070924203516.GQ19429@hal.rescomp.berkeley.edu> <46F82FCF.2090203@net.utcluj.ro> <20070925000602.GT19429@hal.rescomp.berkeley.edu> In-Reply-To: <20070925000602.GT19429@hal.rescomp.berkeley.edu> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Large-scale 1-1 NAT 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, 25 Sep 2007 07:10:52 -0000 >> There is another thing I wanted to point out. I remember you used the >> words "authentication web page". This made me think you are >> establishing a captive portal, which is not secure at all. If I >> understand well the authpf solution would be secure, except perhaps >> a small delay. You might proxy your clients to a "click here and >> download this preconfigured PuTTY" page. > > We are planning on using a captive portal. The only authentication > mechanism we have for clients is a web-based SSO solution using CAS that > isn't maintained by our staff. The people trying to authenticate are not > intended to be local users on the system. What are the security problems > you see with a captive portal interface? I haven't used CAS, but if I understand well from their wiki, CAS by itself isn't meant to keep the session alive. This means that the following scenario could occur: 1) User associates with your AP. 2) User logs in. 3) EvilUser associates with your AP. 4) EvilUser run tcpdump, records IP and MAC of User. 5) EvilUser sends DDoS against User. 6) Having a Windows :P, User is forced to restart his computer. 7) EvilUser sets his MAC and IP to the recorded ones. Some captive portals do keep the session alive, by regularly refreshing the page, using JavaScript or a Java applet. However, this means that the user will have to keep his browser window open. IMHO, this is worse than keeping PuTTY open while connecting to the Internet. From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 00:31:39 2007 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 2A33116A421; Wed, 26 Sep 2007 00:31:39 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5450113C4A8; Wed, 26 Sep 2007 00:31:38 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [85.19.218.45] (account mc467741@c2i.net [85.19.218.45] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 624282714; Wed, 26 Sep 2007 01:31:35 +0200 From: Hans Petter Selasky To: freebsd-scsi@freebsd.org, freebsd-usb@freebsd.org, freebsd-net@freebsd.org Date: Wed, 26 Sep 2007 01:31:47 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709260131.49156.hselasky@c2i.net> Cc: Subject: Request for feedback on common data backstore in the kernel 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, 26 Sep 2007 00:31:39 -0000 Hi, Please keep me CC'ed, hence I'm not on all these lists. In the kernel we currently have two different data backstores: struct mbuf and struct buf These two backstores serve two different device types. "mbufs" are for network devices and "buf" is for disk devices. Problem: The current backstores are loaded into DMA by using the BUS-DMA framework. This appears not to be too fast according to Kip Macy. See: http://perforce.freebsd.org/chv.cgi?CH=126455 Some ideas I have: When a buffer is out out of range for a hardware device and a data-copy is needed I want to simply copy that data in smaller parts to/from a pre-allocated bounce buffer. I want to avoid allocating this buffer when "bus_dmamap_load()" is called. For pre-allocated USB DMA memory I currently have: struct usbd_page struct usbd_page { void *buffer; // virtual address bus_size_t physaddr; // as seen by one of my devices bus_dma_tag_t tag; bus_dmamap_t map; uint32_t length; }; Mostly only "length == PAGE_SIZE" is allowed. When USB allocates DMA memory it allocates the same size all the way and that is PAGE_SIZE bytes. If two different PCI controllers want to communicate directly passing DMA buffers, technically one would need to translate the physical address for device 1 to the physical address as seen by device 2. If this translation table is sorted, the search will be rather quick. Another approach is to limit the number of translations: #define N_MAX_PCI_TRANSLATE 4 struct usbd_page { void *buffer; // virtual address bus_size_t physaddr[N_MAX_PCI_TRANSLATE]; bus_dma_tag_t tag; bus_dmamap_t map; uint32_t length; }; Then PCI device 1 on bus X can use physaddr[0] and PCI device 2 on bus Y can use physaddr[1]. If the physaddr[] is equal to some magic then the DMA buffer is not reachable and must be bounced. Then when two PCI devices talk together all they need to pass is a structure like this: struct usbd_page_cache { struct usbd_page *page_start; uint32_t page_offset_buf; uint32_t page_offset_end; }; And the required DMA address is looked up in some nanos. Has someone been thinking about this topic before ? --HPS From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 06:36:31 2007 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 A1B4F16A419 for ; Wed, 26 Sep 2007 06:36:31 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0D813C480 for ; Wed, 26 Sep 2007 06:36:30 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.14.1/8.14.1) with ESMTP id l8Q62f3g010886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 10:02:41 +0400 (MSD) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.14.1/8.14.1/Submit) id l8Q62f0c010885 for freebsd-net@freebsd.org; Wed, 26 Sep 2007 10:02:41 +0400 (MSD) (envelope-from oleg) Date: Wed, 26 Sep 2007 10:02:41 +0400 From: Oleg Bulyzhin To: freebsd-net@freebsd.org Message-ID: <20070926060241.GA3945@lath.rinet.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) Subject: new mbuf flag proposal 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, 26 Sep 2007 06:36:31 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all. Recently, i discovered following problem (though it was already discussed, = see http://freebsd.rambler.ru/bsdmail/freebsd-ipfw_2006/msg00491.html): pfil handlers (like ipfw or pf) sometime need to create packets (like tcp r= st or icmp errors). In order to avoid loops M_SKIP_FIREWALL flag is used. Unfortunately, this behaviour is not always correct. There are configurations when you need to reinject such packets into pfil(4) handlers (in order to translate them using NAT or apply routing policy=20 or divert them somewhere, etc). In my case i had to modify kernel in order to translate tcp keepalive packets(generated by ipfw) using pfnat. I have a proposal how to solve this: 1) Introduce new mbuf flag, something like M_PFIL_CREATED, which should be used to mark packets created by pfil handler. If packet is not supposed to reenter pfil handlers M_SKIP_FIREWALL can be used instead. 2) When pfil handler generate packet it should be marked either with M_SKIP_FIREWALL or M_PFIL_CREATED. In latter case, pfil handler should a= dd mbuf_tag for distinguishing source of M_PFIL_CREATED flag. So, for packet creation code should be like this: m->m_flags |=3D M_PFIL_CREATED; mtag =3D m_tag_alloc(MTAG_PFIL_CREATED, PFIL_IPFW, 0, M_NOWAIT); if (mtag) { m_tag_prepend(m, mtag); } else { goto drop_pkt; } at the beginning of pfil handler we should have something like this: int dont_emit_pkt =3D 0; if (m->m_flags & M_PFIL_CREATED) { dont_emit_pkt =3D 1; mtag =3D m_tag_locate(m, MTAG_PFIL_CREATED, PFIL_IPFW, NULL); if (mtag) { /* pkt was created by myself */ /* my own packet, handle it with care. */ goto specal_handler; } else { /* pkt was created by other pfil(4) handler */ /* do normal processing but do not emit new packets. */ goto normal_handler; } } This functionality can be archived with mbuf_tag only (without new mbuf fla= g), but it would be ineffective: calling m_tag_locate() (unsuccessful most of the time!) for every packet is rather expensive. What do you think about this? --=20 Oleg. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru =3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFG+fYAryLc73jOEF8RAjuEAJ0Q6RaGDeGRNc4a3dCCE+JdjZUbUwCfYScz mtdSZTHAVlLXO7ckiQIiIrU= =EaIm -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 06:39:41 2007 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 0510B16A41A; Wed, 26 Sep 2007 06:39:41 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E0FDC13C44B; Wed, 26 Sep 2007 06:39:40 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8Q6debq028962; Wed, 26 Sep 2007 06:39:40 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8Q6deVM028958; Wed, 26 Sep 2007 06:39:40 GMT (envelope-from remko) Date: Wed, 26 Sep 2007 06:39:40 GMT Message-Id: <200709260639.l8Q6deVM028958@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: bin/116643: [patch] fstat(1): add INET/INET6 socket details as in NetBSD and OpenBSD 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, 26 Sep 2007 06:39:41 -0000 Synopsis: [patch] fstat(1): add INET/INET6 socket details as in NetBSD and OpenBSD Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Sep 26 06:39:25 UTC 2007 Responsible-Changed-Why: This looks like something for the -net team. http://www.freebsd.org/cgi/query-pr.cgi?pr=116643 From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 04:54:09 2007 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 644EC16A41A for ; Wed, 26 Sep 2007 04:54:09 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 2B14513C458 for ; Wed, 26 Sep 2007 04:54:09 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gkvdzsioz46jvzap@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l8Q4s261083635; Tue, 25 Sep 2007 21:54:02 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l8Q4s2hA083634; Tue, 25 Sep 2007 21:54:02 -0700 (PDT) (envelope-from jmg) Date: Tue, 25 Sep 2007 21:54:01 -0700 From: John-Mark Gurney To: Hans Petter Selasky Message-ID: <20070926045401.GB47467@funkthat.com> Mail-Followup-To: Hans Petter Selasky , freebsd-arch@FreeBSD.org References: <200709260131.49156.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200709260131.49156.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hydrogen.funkthat.com [127.0.0.1]); Tue, 25 Sep 2007 21:54:03 -0700 (PDT) X-Mailman-Approved-At: Wed, 26 Sep 2007 12:56:02 +0000 Cc: freebsd-arch@FreeBSD.org Subject: Re: Request for feedback on common data backstore in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2007 04:54:09 -0000 Hans Petter Selasky wrote this message on Wed, Sep 26, 2007 at 01:31 +0200: > Please keep me CC'ed, hence I'm not on all these lists. > > In the kernel we currently have two different data backstores: > > struct mbuf > > and > > struct buf > > These two backstores serve two different device types. "mbufs" are for network > devices and "buf" is for disk devices. I don't see how this relates to the rest of your email, but even though they are used similarly, their normal size is quite different... mbufs normally contain 64-256 byte packets, w/ large file transfers attaching a 2k cluster (which comes from a different pool than the core mbuf) to the mbuf... buf is usually something like 16k-64k... > Problem: > > The current backstores are loaded into DMA by using the BUS-DMA framework. > This appears not to be too fast according to Kip Macy. See: > > http://perforce.freebsd.org/chv.cgi?CH=126455 This only works on x86/amd64 because of the direct mapped memory that they support.. This would complete break arches like sparc64 that require an iommu to translate the addresses... and also doesn't address keeping the buffers in sync on arches like arm... sparc64 may have many gigs of memory, but only a 2GB window for mapping main memory... It sounds like the x86/amd64 bus_dma implementation needs to be improved to run more quickly... As w/ all things, you can hardcode stuff, but then you loose portability... > Some ideas I have: > > When a buffer is out out of range for a hardware device and a data-copy is > needed I want to simply copy that data in smaller parts to/from a > pre-allocated bounce buffer. I want to avoid allocating this buffer > when "bus_dmamap_load()" is called. > > For pre-allocated USB DMA memory I currently have: > > struct usbd_page > > struct usbd_page { > void *buffer; // virtual address > bus_size_t physaddr; // as seen by one of my devices > bus_dma_tag_t tag; > bus_dmamap_t map; > uint32_t length; > }; > > Mostly only "length == PAGE_SIZE" is allowed. When USB allocates DMA memory it > allocates the same size all the way and that is PAGE_SIZE bytes. I could see attaching preallocated memory to a tag, and having maps that attempt to use this memory, but that's something else... > If two different PCI controllers want to communicate directly passing DMA > buffers, technically one would need to translate the physical address for > device 1 to the physical address as seen by device 2. If this translation > table is sorted, the search will be rather quick. Another approach is to > limit the number of translations: > > #define N_MAX_PCI_TRANSLATE 4 > > struct usbd_page { > void *buffer; // virtual address > bus_size_t physaddr[N_MAX_PCI_TRANSLATE]; > bus_dma_tag_t tag; > bus_dmamap_t map; > uint32_t length; > }; > > Then PCI device 1 on bus X can use physaddr[0] and PCI device 2 on bus Y can > use physaddr[1]. If the physaddr[] is equal to some magic then the DMA buffer > is not reachable and must be bounced. > > Then when two PCI devices talk together all they need to pass is a structure > like this: > > struct usbd_page_cache { > struct usbd_page *page_start; > uint32_t page_offset_buf; > uint32_t page_offset_end; > }; > > And the required DMA address is looked up in some nanos. > > Has someone been thinking about this topic before ? There is no infastructure to support passing dma address between hardware devices, and is complete unrelated to the issues raised above... This requires the ability to pass in a map to a tag and create a new map... It is possible, as on the sun4v where you have two iommu's.. You'd have to program on iommu to point to the other one, to support that... But it is rare to see devices to dma directly to each other... You usually end up dma'ing to main memory, and then having the other device dma it out of memory.. The only time you need to dma between devices is if one has local memory, and the other device is able to sanely populate it... This is very rare... Also, the PCI bus length can get quite long.. With PCIe, each device is now it's own PCI bus, so you're starting to see PCI bus counts in the 10's and 20's, if not higher.. having an area of all of those, and calculating them and filling them out sounds like a huge expense... I'm a bit puzzeled as to what you wanted to solve, as the problem you stated doesn't relate to the solutions you were thinking about... Maybe I'm missing something? Can you give me an example of where cxgb is writing to the memory on another pci bus, and not main memory? P.S. I redirected to -arch as this seems more related than the other lists... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 14:57:49 2007 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 26AA316A419 for ; Wed, 26 Sep 2007 14:57:49 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id C150F13C45D for ; Wed, 26 Sep 2007 14:57:48 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from [192.168.2.10] ([192.168.2.10]) by mail1.cil.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 16:57:46 +0200 Message-ID: <46FA736A.7000206@ide.resurscentrum.se> Date: Wed, 26 Sep 2007 16:57:46 +0200 From: Jon Otterholm User-Agent: Thunderbird 2.0.0.5 (X11/20070723) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 14:57:46.0547 (UTC) FILETIME=[995BC830:01C8004D] Subject: if_em and if_vlan 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, 26 Sep 2007 14:57:49 -0000 Hi. I get "Device busy" when trying to change VLAN-id on a sub-if to em0: [root@host /home/user]# ifconfig vlan100 vlan 100 vlandev em0 ifconfig: SIOCSETVLAN: Device busy [root@host /home/user]# dmesg | grep em0 em0: port 0x4000-0x401f mem 0xee200000-0xee21ffff irq 16 at device 0.0 on pci9 [root@host /home/user]# pciconf -vl em0@pci9:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PM' class = network subclass = ethernet [root@host /home/user]# uname -a FreeBSD host 6.2-STABLE FreeBSD 6.2-STABLE #1: Tue Sep 25 22:29:05 CEST 2007 user@host:/usr/obj/usr/src/sys/host i386 It works if I create a new interface like: [root@host /home/user]# ifconfig vlan100 create and setting the vid and vlandev: [root@host /home/user]# ifconfig vlan100 vlan 100 vlandev em0 But when I try to change the setting: [root@host /home/user]# ifconfig vlan100 vlan 100 vlandev em1 ifconfig: SIOCSETVLAN: Device busy Even if I destroy the interface and create it again I get "Device busy": [root@host /home/user]# ifconfig vlan100 destroy [root@host /home/user]# ifconfig vlan100 create [root@host /home/user]# ifconfig vlan100 vlan 100 vlandev em1 ifconfig: SIOCSETVLAN: Device busy Motherboard is Supermicro PDSMi-LN4+ with four em-interfaces. How do I solve this? //Jon From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 15:00:49 2007 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 AC0D516A418 for ; Wed, 26 Sep 2007 15:00:49 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3663F13C459 for ; Wed, 26 Sep 2007 15:00:48 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IaWUk-0005Xl-Rh for freebsd-net@freebsd.org; Wed, 26 Sep 2007 13:00:02 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Sep 2007 13:00:02 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Sep 2007 13:00:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Wed, 26 Sep 2007 12:45:37 +0200 Lines: 156 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigFB2919C7D08C45C9CD742FC6" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.12 (X11/20060911) X-Enigmail-Version: 0.94.4.0 Sender: news Subject: Panic in rt_check 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, 26 Sep 2007 15:00:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB2919C7D08C45C9CD742FC6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I have a machine that panics almost daily in route.c, in rt_check().=20 This panic has been reported by several users, including Marcel=20 Moolenaar for a machine in freebsd.org. The problem is present in both 6-STABLE and 7-CURRENT, and apparently it = manifests on SMP machines, both i386 and AMD64. The panic backtrace looks like this: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305 cpuid =3D 1 KDB: stack backtrace: db_trace_self_wrapper(c091bcf0,e38b690c,c0659fc1,c093f3cf,1,...) at=20 db_trace_self_wrapper+0x26 kdb_backtrace(c093f3cf,1,c0917de2,e38b6918,1,...) at kdb_backtrace+0x29 panic(c0917de2,c0925d40,519,0,0,...) at panic+0x111 _mtx_lock_flags(c5d333a8,0,c0925d40,519,0,...) at _mtx_lock_flags+0x59 rt_check(e38b6970,e38b698c,c55b7d10,0,0,...) at rt_check+0x11e arpresolve(c4e27000,c5d33d98,c50dbe00,c55b7d10,e38b69a6,...) at=20 arpresolve+0xaf ether_output(c4e27000,c50dbe00,c55b7d10,c5d33d98,ccf8b348,...) at=20 ether_output+0x7e ip_output(c50dbe00,0,e38b6a1c,0,0,...) at ip_output+0xa09 tcp_output(ccefbac8,0,c0929785,91d,0,...) at tcp_output+0x1463 tcp_do_segment(ccefbac8,28,0,1dd,901f,...) at tcp_do_segment+0x1c97 tcp_input(c6095100,14,c4ea3c00,1,0,...) at tcp_input+0xd5e ip_input(c6095100,0,c09258bd,8c,c09efc38,...) at ip_input+0x662 netisr_processqueue(e38b6cc4,c064df85,c09eb940,1,c4d03480,...) at=20 netisr_processqueue+0x98 swi_net(0,0,c0915aee,471,c4d0bd64,...) at swi_net+0xdb ithread_loop(c4d0c270,e38b6d38,c0915862,315,c4d56558,...) at=20 ithread_loop+0x1c5 fork_exit(c063e2d0,c4d0c270,e38b6d38) at fork_exit+0xc5 fork_trampoline() at fork_trampoline+0x8 =2E.. #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0659d2c in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :409 #2 0xc0659ff0 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc064e699 in _mtx_lock_flags (m=3D0x0, opts=3D0, file=3D0xc0925d40=20 "/usr/src/sys/net/route.c", line=3D1305) at /usr/src/sys/kern/kern_mutex.c:178 #4 0xc06fe28e in rt_check (lrt=3D0xe38b6970, lrt0=3D0xe38b698c,=20 dst=3D0xc55b7d10) at /usr/src/sys/net/route.c:1305 #5 0xc070282f in arpresolve (ifp=3D0xc4e27000, rt0=3D0xc5d33d98,=20 m=3D0xc50dbe00, dst=3D0xc55b7d10, desten=3D0xe38b69a6 "") at /usr/src/sys/netinet/if_ether.c:373 #6 0xc06f019e in ether_output (ifp=3D0xc4e27000, m=3D0xc50dbe00,=20 dst=3D0xc55b7d10, rt0=3D0xc5d33d98) at /usr/src/sys/net/if_ethersubr.c:17= 5 #7 0xc07127a9 in ip_output (m=3D0xc50dbe00, opt=3D0x0, ro=3D0xe38b6a1c, = flags=3DVariable "flags" is not available. ) at /usr/src/sys/netinet/ip_output.c:547 #8 0xc076d6e3 in tcp_output (tp=3D0xccefbac8) at=20 /usr/src/sys/netinet/tcp_output.c:1125 #9 0xc076ab87 in tcp_do_segment (m=3D0xc6095100, th=3D0xc6095158,=20 so=3D0xccdb67bc, tp=3D0xccefbac8, drop_hdrlen=3D40, tlen=3D0) at /usr/src/sys/netinet/tcp_input.c:2345 #10 0xc076bb0e in tcp_input (m=3D0xc6095100, off0=3D20) at=20 /usr/src/sys/netinet/tcp_input.c:843 #11 0xc0710c42 in ip_input (m=3D0xc6095100) at=20 /usr/src/sys/netinet/ip_input.c:663 #12 0xc06f9148 in netisr_processqueue (ni=3D0xc09efc38) at=20 /usr/src/sys/net/netisr.c:143 #13 0xc06f925b in swi_net (dummy=3D0x0) at /usr/src/sys/net/netisr.c:256 #14 0xc063e495 in ithread_loop (arg=3D0xc4d0c270) at=20 /usr/src/sys/kern/kern_intr.c:1036 #15 0xc063b845 in fork_exit (callout=3D0xc063e2d0 ,=20 arg=3D0xc4d0c270, frame=3D0xe38b6d38) at /usr/src/sys/kern/kern_fork.c:79= 7 #16 0xc0896f80 in fork_trampoline () at=20 /usr/src/sys/i386/i386/exception.s:205 I've been trying to solve this with Craig Rodrigues, and I've tried=20 several patches, without success. The backtrace above happens on the=20 following code from net/route.c: 1299 /* XXX BSD/OS checks dst->sa_family !=3D AF_NS */ 1300 if (rt->rt_flags & RTF_GATEWAY) { 1301 struct rtentry *temp_rt_gwroute =3D rt->rt_gwroute; 1302 if (temp_rt_gwroute =3D=3D NULL) 1303 goto lookup; 1304 rt =3D rt->rt_gwroute; 1305 RT_LOCK(rt); /* NB: gwroute */ 1306 if(rt0->rt_flags & 0x80000000U){ 1307 /*This rt is under process...*/ 1308 RT_UNLOCK(rt); 1309 RT_UNLOCK(rt0); 1310 goto try_again; 1311 } 1312 if ((rt->rt_flags & RTF_UP) =3D=3D 0) { 1313 rt0->rt_flags |=3D 0x80000000U; 1314 RTFREE_LOCKED(rt); /* unlock gwroute */ 1315 rt =3D rt0; 1316 lookup: 1317 RT_UNLOCK(rt0); 1318 rt =3D rtalloc1(rt->rt_gateway, 1, 0UL); 1319 if (rt =3D=3D rt0) { 1320 rt0->rt_gwroute =3D NULL; 1321 RT_REMREF(rt0); 1322 RT_UNLOCK(rt0); 1323 return (ENETUNREACH); 1324 } 1325 RT_LOCK(rt0); 1326 rt0->rt_gwroute =3D rt; 1327 rt0->rt_flags &=3D (~0x80000000U); 1328 if (rt =3D=3D NULL) { 1329 RT_UNLOCK(rt0); 1330 return (EHOSTUNREACH); 1331 } 1332 } 1333 RT_UNLOCK(rt0); 1334 } This code contains several patches we tried for workarounds, without any = success. The panic is always in RT_LOCK(rt) line: sometimes it's NULL=20 pointer reference, sometimes it's an operation on destroyed mutex. This is a critical problem for me, but I believe it's also critical for=20 other users. Does anyone have more ideas about how to solve this problem? --------------enigFB2919C7D08C45C9CD742FC6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG+jhXldnAQVacBcgRA3zPAKC280XwOEosXgEFzMDgpdPysmovUACdG91H 3agosedq2jMCJfvPaBZ4eP0= =OpkH -----END PGP SIGNATURE----- --------------enigFB2919C7D08C45C9CD742FC6-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 17:38:47 2007 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 174B416A419 for ; Wed, 26 Sep 2007 17:38:47 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id B32AB13C48E for ; Wed, 26 Sep 2007 17:38:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so1370085ugf for ; Wed, 26 Sep 2007 10:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+p93hUmBzaHuxqwjUEdsV4Pxry41K0wqvcXywvO0ejc=; b=MWrXjCGkMqPdH8wKfBaFF0uAqDvt/+QEyW/slMnOPLJWqmmGCx9fTR9XNnLS1+24SDe8RDSPZg+cUNsHx8OWxlHLmVO5LmMzDgOpHS1VK/Ofh9sSVwC1tk6XzgZse9z19OaAIsZ4/F5EHZeolj/wun+kqMJjmeNsrrrY2I0Yk3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DqFFgSC+tZqHpmDOqwB/dUy5C9UGlVIerdzpK25bX0r0WWp6TImJxGXadlrEZHRbiA5o9V4AmSeag6kIz5Zg9SJp9k4JP5LS457UOPOVHD7bla0/mlAmPB/cynfq93keBA0dNAZXdfDMJGsotS6eFDQsC+UnjD045Qmng2Qo0So= Received: by 10.66.249.16 with SMTP id w16mr2507095ugh.1190828325097; Wed, 26 Sep 2007 10:38:45 -0700 (PDT) Received: by 10.86.100.19 with HTTP; Wed, 26 Sep 2007 10:38:45 -0700 (PDT) Message-ID: <2a41acea0709261038q1613525avadadfd68c5ab2789@mail.gmail.com> Date: Wed, 26 Sep 2007 10:38:45 -0700 From: "Jack Vogel" To: "Jon Otterholm" In-Reply-To: <46FA736A.7000206@ide.resurscentrum.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46FA736A.7000206@ide.resurscentrum.se> Cc: freebsd-net@freebsd.org Subject: Re: if_em and if_vlan 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, 26 Sep 2007 17:38:47 -0000 This is not an issue in my current driver base, I am having our test group do some checking since I am not aware of the specific change that fixed this, I am not sure if the CURRENT code has the problem or not, also being tested. Jack On 9/26/07, Jon Otterholm wrote: > Hi. > > I get "Device busy" when trying to change VLAN-id on a sub-if to em0: > > [root@host /home/user]# ifconfig vlan100 vlan 100 vlandev em0 > ifconfig: SIOCSETVLAN: Device busy > > [root@host /home/user]# dmesg | grep em0 > em0: port > 0x4000-0x401f mem 0xee200000-0xee21ffff irq 16 at device 0.0 on pci9 > > [root@host /home/user]# pciconf -vl > em0@pci9:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 PM' > class = network > subclass = ethernet > > [root@host /home/user]# uname -a > FreeBSD host 6.2-STABLE FreeBSD 6.2-STABLE #1: Tue Sep 25 22:29:05 CEST > 2007 user@host:/usr/obj/usr/src/sys/host i386 > > It works if I create a new interface like: > > [root@host /home/user]# ifconfig vlan100 create > > and setting the vid and vlandev: > > [root@host /home/user]# ifconfig vlan100 vlan 100 vlandev em0 > > But when I try to change the setting: > > [root@host /home/user]# ifconfig vlan100 vlan 100 vlandev em1 > ifconfig: SIOCSETVLAN: Device busy > > Even if I destroy the interface and create it again I get "Device busy": > > [root@host /home/user]# ifconfig vlan100 destroy > [root@host /home/user]# ifconfig vlan100 create > [root@host /home/user]# ifconfig vlan100 vlan 100 vlandev em1 > ifconfig: SIOCSETVLAN: Device busy > > Motherboard is Supermicro PDSMi-LN4+ with four em-interfaces. > > How do I solve this? > > //Jon > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 17:51:26 2007 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 3360D16A418; Wed, 26 Sep 2007 17:51:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD0813C458; Wed, 26 Sep 2007 17:51:25 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (wireless.prattprop.com [209.97.224.24] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l8QHp52N063752; Wed, 26 Sep 2007 11:51:12 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46FA9C04.9060603@samsco.org> Date: Wed, 26 Sep 2007 11:51:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Hans Petter Selasky References: <200709260131.49156.hselasky@c2i.net> In-Reply-To: <200709260131.49156.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Wed, 26 Sep 2007 11:51:12 -0600 (MDT) X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, freebsd-usb@freebsd.org, freebsd-net@freebsd.org Subject: Re: Request for feedback on common data backstore in the kernel 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, 26 Sep 2007 17:51:26 -0000 Hans Petter Selasky wrote: > Hi, > > Please keep me CC'ed, hence I'm not on all these lists. > > In the kernel we currently have two different data backstores: > > struct mbuf > > and > > struct buf > > These two backstores serve two different device types. "mbufs" are for network > devices and "buf" is for disk devices. > > Problem: > > The current backstores are loaded into DMA by using the BUS-DMA framework. > This appears not to be too fast according to Kip Macy. See: > > http://perforce.freebsd.org/chv.cgi?CH=126455 > Busdma isn't fast enough for 1Gb and 10Gb network drivers that are trying to max out their packet rates. It's still fine for storage drivers and other slow/medium speed device drivers, like USB and Firewire. I am working on techniques to make the API easier to use and the implementation fast enough for the aforementioned devices. > Some ideas I have: > > When a buffer is out out of range for a hardware device and a data-copy is > needed I want to simply copy that data in smaller parts to/from a > pre-allocated bounce buffer. I want to avoid allocating this buffer > when "bus_dmamap_load()" is called. I think you've missed the point of having architecture portable drivers. John-Mark describes this further. It also makes little sense to push the responsibility for handling bounce buffers out of a central subsystem and back into every driver. Scott From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 18:11:44 2007 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 91BCC16A41A for ; Wed, 26 Sep 2007 18:11:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5C28613C474 for ; Wed, 26 Sep 2007 18:11:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 26 Sep 2007 11:11:43 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 90D16126503; Wed, 26 Sep 2007 11:11:42 -0700 (PDT) Message-ID: <46FAA0DD.6040804@elischer.org> Date: Wed, 26 Sep 2007 11:11:41 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Oleg Bulyzhin References: <20070926060241.GA3945@lath.rinet.ru> In-Reply-To: <20070926060241.GA3945@lath.rinet.ru> Content-Type: multipart/mixed; boundary="------------090905030908090805090805" Cc: freebsd-net@freebsd.org Subject: Re: new mbuf flag proposal 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, 26 Sep 2007 18:11:44 -0000 This is a multi-part message in MIME format. --------------090905030908090805090805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Oleg Bulyzhin wrote: > Hi all. > > Recently, i discovered following problem (though it was already discussed, see > http://freebsd.rambler.ru/bsdmail/freebsd-ipfw_2006/msg00491.html): > pfil handlers (like ipfw or pf) sometime need to create packets (like tcp rst > or icmp errors). In order to avoid loops M_SKIP_FIREWALL flag is used. > Unfortunately, this behaviour is not always correct. > There are configurations when you need to reinject such packets into pfil(4) > handlers (in order to translate them using NAT or apply routing policy > or divert them somewhere, etc). In my case i had to modify kernel > in order to translate tcp keepalive packets(generated by ipfw) using pfnat. HA! I just implemeted this for us at IRONPORT. I added a second flag which allowed the M_SKIP_FIREWALL to be ignored for the first run.. Basically if you generate a RESET packet from within the firewall, and you are doing NAT then you need to allow the outgoing RESET to be translated just like all the other packets of that session.. In the Firewall the presence of the seconf bit negates the existance of M_SKIP_FIREWALL, but it is cleared. meaning that it will do exactly ONE pass through the firewall after being sent out (the pass will be done in ip_output). it is however a specific solution for us.. and probably not general. The trouble is that there is no real fully general solution. I attach my patch. (wonder if it will be stripped for the list?) (if it is I'll cut-n-paste a version later). > > I have a proposal how to solve this: > 1) Introduce new mbuf flag, something like M_PFIL_CREATED, which should be > used to mark packets created by pfil handler. If packet is not supposed > to reenter pfil handlers M_SKIP_FIREWALL can be used instead. > 2) When pfil handler generate packet it should be marked either with > M_SKIP_FIREWALL or M_PFIL_CREATED. In latter case, pfil handler should add > mbuf_tag for distinguishing source of M_PFIL_CREATED flag. > > So, for packet creation code should be like this: > > m->m_flags |= M_PFIL_CREATED; > mtag = m_tag_alloc(MTAG_PFIL_CREATED, PFIL_IPFW, 0, M_NOWAIT); > if (mtag) { > m_tag_prepend(m, mtag); > } else { > goto drop_pkt; > } > > at the beginning of pfil handler we should have something like this: > > int dont_emit_pkt = 0; > > if (m->m_flags & M_PFIL_CREATED) { > dont_emit_pkt = 1; > mtag = m_tag_locate(m, MTAG_PFIL_CREATED, PFIL_IPFW, NULL); > if (mtag) { /* pkt was created by myself */ > /* my own packet, handle it with care. */ > goto specal_handler; > } else { /* pkt was created by other pfil(4) handler */ > > /* do normal processing but do not emit new packets. */ > goto normal_handler; > } > } > > This functionality can be archived with mbuf_tag only (without new mbuf flag), > but it would be ineffective: > calling m_tag_locate() (unsuccessful most of the time!) for every packet is > rather expensive. > > What do you think about this? > not bad, and tries to address my comments about generality. Comments still needed from others however. --------------090905030908090805090805 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="ipfw2_x_reset.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw2_x_reset.patch" Index: sys/netinet/ip_fw2.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v retrieving revision 1.106.2.12 diff -d -u -r1.106.2.12 ip_fw2.c --- sys/netinet/ip_fw2.c 9 Mar 2006 13:42:44 -0000 1.106.2.12 +++ sys/netinet/ip_fw2.c 24 Sep 2007 21:10:21 -0000 @@ -96,6 +96,14 @@ #include /* XXX for in_cksum */ +#if defined M_IRONPORT_FWD +/* generally skip the firewall after the first time, + which will be for redirection. Role on vimage! */ +#define M_FIREWALL_IMMUNITY (M_SKIP_FIREWALL | M_IRONPORT_FWD) +#else +#define M_FIREWALL_IMMUNITY (M_SKIP_FIREWALL) +#endif + /* * set_disable contains one bit per set value (0..31). * If the bit is set, all rules with the corresponding set @@ -750,6 +758,8 @@ flags = TH_RST|TH_ACK; } bcopy(&ti, ip6, sizeof(ti)); + /* tcp_respond keeps the mbuf (and hense flags) */ + args->m->m_flags |= M_FIREWALL_IMMUNITY ; tcp_respond(NULL, ip6, (struct tcphdr *)(ip6 + 1), args->m, ack, seq, flags); @@ -1628,7 +1638,7 @@ */ ip->ip_ttl = ip_defttl; ip->ip_len = m->m_pkthdr.len; - m->m_flags |= M_SKIP_FIREWALL; + m->m_flags |= M_FIREWALL_IMMUNITY; return (m); } @@ -1646,6 +1656,8 @@ ip->ip_len = ntohs(ip->ip_len); ip->ip_off = ntohs(ip->ip_off); } + /* the flags get copied */ + args->m->m_flags |= M_FIREWALL_IMMUNITY; icmp_error(args->m, ICMP_UNREACH, code, 0L, 0); } else if (offset == 0 && args->f_id.proto == IPPROTO_TCP) { struct tcphdr *const tcp = @@ -2139,6 +2169,12 @@ /* end of ipv6 variables */ int is_ipv4 = 0; +#if defined(M_IRONPORT_FWD) + if (m->m_flags & M_IRONPORT_FWD) + /* We have a free pass.. but we only get to use it once */ + m->m_flags &= ~M_IRONPORT_FWD; + else +#endif if (m->m_flags & M_SKIP_FIREWALL) return (IP_FW_PASS); /* accept */ Index: sys/netinet/ip_icmp.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_icmp.c,v retrieving revision 1.101.2.2 diff -d -u -r1.101.2.2 ip_icmp.c --- sys/netinet/ip_icmp.c 16 Feb 2006 17:50:57 -0000 1.101.2.2 +++ sys/netinet/ip_icmp.c 24 Sep 2007 21:10:21 -0000 @@ -269,7 +269,7 @@ * If the original mbuf was meant to bypass the firewall, the error * reply should bypass as well. */ - m->m_flags |= n->m_flags & M_SKIP_FIREWALL; + m->m_flags |= n->m_flags & (M_SKIP_FIREWALL|M_IRONPORT_FWD); m->m_data -= sizeof(struct ip); m->m_len += sizeof(struct ip); m->m_pkthdr.len = m->m_len; Index: sys/netinet/ip_output.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_output.c,v retrieving revision 1.242.2.8 diff -d -u -r1.242.2.8 ip_output.c --- sys/netinet/ip_output.c 31 Jan 2006 16:06:05 -0000 1.242.2.8 +++ sys/netinet/ip_output.c 24 Sep 2007 21:10:21 -0000 @@ -661,6 +661,9 @@ /* Jump over all PFIL processing if hooks are not active. */ if (inet_pfil_hook.ph_busy_count == -1) goto passout; + /* Or if we were told to */ + if ((m->m_flags & (M_IRONPORT_FWD|M_SKIP_FIREWALL)) == M_SKIP_FIREWALL) + goto passout; /* Run through list of hooks for output packets. */ odst.s_addr = ip->ip_dst.s_addr; @@ -672,6 +675,7 @@ /* See if destination IP address was changed by packet filter. */ if (odst.s_addr != ip->ip_dst.s_addr) { + m->m_flags &= ~M_IRONPORT_FWD; m->m_flags |= M_SKIP_FIREWALL; /* If destination is now ourself drop to ip_input(). */ if (in_localip(ip->ip_dst)) { @@ -716,6 +720,8 @@ #endif dst = (struct sockaddr_in *)&ro->ro_dst; bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in)); + /* If we had a free pass for forewarding, lose it */ + m->m_flags &= ~M_IRONPORT_FWD; m->m_flags |= M_SKIP_FIREWALL; m_tag_delete(m, fwd_tag); goto again; Index: sys/sys/mbuf.h =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/sys/mbuf.h,v retrieving revision 1.170.2.6 diff -d -u -r1.170.2.6 mbuf.h --- sys/sys/mbuf.h 23 Mar 2006 23:24:32 -0000 1.170.2.6 +++ sys/sys/mbuf.h 24 Sep 2007 21:10:21 -0000 @@ -167,6 +167,7 @@ #define M_PROTO3 0x0040 /* protocol-specific */ #define M_PROTO4 0x0080 /* protocol-specific */ #define M_PROTO5 0x0100 /* protocol-specific */ +#define M_IRONPORT_FWD 0x2000 /* Allow one (and only one) firewall FWD pass */ #define M_SKIP_FIREWALL 0x4000 /* skip firewall processing */ #define M_FREELIST 0x8000 /* mbuf is on the free list */ @@ -200,7 +201,7 @@ #define M_COPYFLAGS (M_PKTHDR|M_EOR|M_RDONLY|M_PROTO1|M_PROTO1|M_PROTO2|\ M_PROTO3|M_PROTO4|M_PROTO5|M_SKIP_FIREWALL|\ M_BCAST|M_MCAST|M_FRAG|M_FIRSTFRAG|M_LASTFRAG|\ - M_VLANTAG) + M_VLANTAG|M_IRONPORT_FWD) /* * Flags indicating hw checksum support and sw checksum requirements. --------------090905030908090805090805-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 19:56:57 2007 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 9A11716A419; Wed, 26 Sep 2007 19:56:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADDF13C4A6; Wed, 26 Sep 2007 19:56:56 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [85.19.218.45] (account mc467741@c2i.net [85.19.218.45] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 626638699; Wed, 26 Sep 2007 21:56:43 +0200 From: Hans Petter Selasky To: Scott Long Date: Wed, 26 Sep 2007 21:57:00 +0200 User-Agent: KMail/1.9.7 References: <200709260131.49156.hselasky@c2i.net> <46FA9C04.9060603@samsco.org> In-Reply-To: <46FA9C04.9060603@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709262157.02712.hselasky@c2i.net> Cc: freebsd-scsi@freebsd.org, freebsd-arch@freebsd.org, freebsd-usb@freebsd.org, freebsd-net@freebsd.org Subject: Re: Request for feedback on common data backstore in the kernel 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, 26 Sep 2007 19:56:57 -0000 Hi Scott, The discussion has been moved to "freebsd-arch@freebsd.org". Please only reply there next time. On Wednesday 26 September 2007, Scott Long wrote: > Hans Petter Selasky wrote: > > Hi, > > > > Please keep me CC'ed, hence I'm not on all these lists. > > > > In the kernel we currently have two different data backstores: > > > > struct mbuf > > > > and > > > > struct buf > > > > These two backstores serve two different device types. "mbufs" are for > > network devices and "buf" is for disk devices. > > > > Problem: > > > > The current backstores are loaded into DMA by using the BUS-DMA > > framework. This appears not to be too fast according to Kip Macy. See: > > > > http://perforce.freebsd.org/chv.cgi?CH=126455 > > Busdma isn't fast enough for 1Gb and 10Gb network drivers that are > trying to max out their packet rates. It's still fine for storage > drivers and other slow/medium speed device drivers, like USB and > Firewire. I am working on techniques to make the API easier to use > and the implementation fast enough for the aforementioned devices. That's great! > > > Some ideas I have: > > > > When a buffer is out out of range for a hardware device and a data-copy > > is needed I want to simply copy that data in smaller parts to/from a > > pre-allocated bounce buffer. I want to avoid allocating this buffer when > > "bus_dmamap_load()" is called. > > I think you've missed the point of having architecture portable drivers. > John-Mark describes this further. I use the bus_dma framework to allocate and sync all DMA memory, and I assume that is correct. > It also makes little sense to push > the responsibility for handling bounce buffers out of a central > subsystem and back into every driver. I'm thinking about putting some wrappers around the "bus_dmamap_load()" function like: void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf, uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf, uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); But I haven't figured out all the details yet. The "usbd_xxx_load()" functions should automagically figure out what is best to do and it won't be more than a few lines of code. --HPS From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 21:13:36 2007 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 B028616A418 for ; Wed, 26 Sep 2007 21:13:36 +0000 (UTC) (envelope-from m.boyarov@bsd.by) Received: from mx1.cybernet.by (mail.cybernet.by [212.98.164.131]) by mx1.freebsd.org (Postfix) with ESMTP id 2AFBF13C478 for ; Wed, 26 Sep 2007 21:13:36 +0000 (UTC) (envelope-from m.boyarov@bsd.by) Received: from mx1.cybernet.by (mx1.cybernet.by [127.0.0.10]) by mx1.cybernet.by (Postfix) with ESMTP id 867B9CDF5B6 for ; Wed, 26 Sep 2007 23:54:27 +0300 (EEST) Received: from solar.bsd.by (dragonsoul.aichyna.com [87.252.248.30]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cybernet.by (Postfix) with ESMTP id 6B23FCDF531 for ; Wed, 26 Sep 2007 23:54:27 +0300 (EEST) Received: by solar.bsd.by (Postfix, from userid 1001) id D087522853; Wed, 26 Sep 2007 23:56:19 +0300 (EEST) To: freebsd-net@freebsd.org From: m.boyarov@bsd.by (Max N. Boyarov) X-Mailer: Gnus v5.11/GNU Emacs 22.1 Date: Wed, 26 Sep 2007 23:56:15 +0300 Message-ID: <86ir5x5eog.fsf@bsd.by> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV Subject: releng_6_2 pagefault 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, 26 Sep 2007 21:13:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Hi, I have setup RELENG_6_2 system (also check on RELENG_6). But when packet come from net0 to net1 system do pagefault. This is 4 core Intel Xeon. debug.mpsafenet =3D 0. kernel builded with FAST_IPSEC support and isakmpd used for IKE exchange. net image net0 [ gif tunnel ] [ pf based router ] [ ipsec tunnel ] net1 (kgdb) symbol-file /usr/obj/usr/src/sys/ded-mazay/kernel.debug Reading symbols from /usr/obj/usr/src/sys/ded-mazay/kernel.debug...done. (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc053da52 in boot (howto=3D256) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc053dd79 in panic (fmt=3D0xc06eb44b "%s") at /usr/src/sys/kern/kern_s= hutdown.c:565 #3 0xc06c2b9c in trap_fatal (frame=3D0xe35bfaf0, eva=3D12) at /usr/src/sys= /i386/i386/trap.c:838 #4 0xc06c28db in trap_pfault (frame=3D0xe35bfaf0, usermode=3D0, eva=3D12) = at /usr/src/sys/i386/i386/trap.c:745 #5 0xc06c252d in trap (frame=3D {tf_fs =3D -480575480, tf_es =3D 40, tf_ds =3D -987693016, tf_edi =3D= -987664896, tf_esi =3D -989560320, tf_ebp =3D -480511092, tf_isp =3D -4805= 11204, tf_ebx =3D -985463040, tf_edx =3D 0, tf_ecx =3D 4, tf_eax =3D 0, tf_= trapno =3D 12, tf_err =3D 0, tf_eip =3D -1067554940, tf_cs =3D 32, tf_eflag= s =3D 66118, tf_esp =3D 7, tf_ss =3D -985461980}) at /usr/src/sys/i386/i386= /trap.c:435 #6 0xc06addca in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05e6784 in ipsec4_process_packet (m=3D0x0, isr=3D0xc5430700, flags= =3D1, tunalready=3D0) at /usr/src/sys/netipsec/ipsec_output.c:377 #8 0xc05d21db in ip_output (m=3D0xc5048200, opt=3D0x0, ro=3D0xe35bfbc0, fl= ags=3D1, imo=3D0x0, inp=3D0x0) at /usr/src/sys/netinet/ip_output.c:628 #9 0xc05d1654 in ip_forward (m=3D0xc5048200, srcrt=3D0) at /usr/src/sys/ne= tinet/ip_input.c:1923 #10 0xc05d00ae in ip_input (m=3D0xc5048200) at /usr/src/sys/netinet/ip_inpu= t.c:694 #11 0xc05b8dff in netisr_processqueue (ni=3D0xc0772638) at /usr/src/sys/net= /netisr.c:236 #12 0xc05b8fb6 in swi_net (dummy=3D0x0) at /usr/src/sys/net/netisr.c:343 #13 0xc0526411 in ithread_execute_handlers (p=3D0xc4af5430, ie=3D0xc4b47b80= ) at /usr/src/sys/kern/kern_intr.c:682 #14 0xc052652d in ithread_loop (arg=3D0xc4ad88b0) at /usr/src/sys/kern/kern= _intr.c:765 #15 0xc05251c5 in fork_exit (callout=3D0xc05264d8 , arg=3D0xc= 4ad88b0, frame=3D0xe35bfd38) at /usr/src/sys/kern/kern_fork.c:830 #16 0xc06ade2c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 208 (kgdb) frame 7 #7 0xc05e6784 in ipsec4_process_packet (m=3D0x0, isr=3D0xc5430700, flags= =3D1, tunalready=3D0) at /usr/src/sys/netipsec/ipsec_output.c:377 377 if (m->m_len < sizeof (struct ip) && (kgdb) list 372 373 /* 374 * Collect IP_DF state from the outer header. 375 */ 376 if (dst->sa.sa_family =3D=3D AF_INET) { 377 if (m->m_len < sizeof (struct ip) && 378 (m =3D m_pullup(m, sizeof (struct ip)))= =3D=3D NULL) { 379 error =3D ENOBUFS; 380 goto bad; 381 } after crash with disabled ipsec # netstat -m 641/1159/1800 mbufs in use (current/cache/total) 640/684/1324/25600 mbuf clusters in use (current/cache/total/max) 640/459 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 1440K/1657K/3098K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/5/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 9 calls to protocol drain routines =2D-=20 Max N. Boyarov GPG fingerprint =3D F6E5 A1DE 619F 72E3 3EEC 2EFF 5C95 E05C CA05 9E8F (sub= keys.pgp.net) --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG+sdzXJXgXMoFno8RAmyiAKC9fdAED+saVpewJVxrKYfNn2ZSOwCg+Ngg OyILb0SVNcZ4yLhte6a53Jw= =42qY -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 01:13:52 2007 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 EE3ED16A418; Thu, 27 Sep 2007 01:13:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF9B13C48A; Thu, 27 Sep 2007 01:13:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l8R1DPix065986; Wed, 26 Sep 2007 19:13:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46FB03B1.6020100@samsco.org> Date: Wed, 26 Sep 2007 19:13:21 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Hans Petter Selasky References: <200709260131.49156.hselasky@c2i.net> <46FA9C04.9060603@samsco.org> <200709262157.02712.hselasky@c2i.net> In-Reply-To: <200709262157.02712.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Wed, 26 Sep 2007 19:13:26 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, freebsd-arch@freebsd.org, freebsd-usb@freebsd.org, freebsd-net@freebsd.org Subject: Re: Request for feedback on common data backstore in the kernel 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, 27 Sep 2007 01:13:53 -0000 Hans Petter Selasky wrote: > Hi Scott, > > The discussion has been moved to "freebsd-arch@freebsd.org". Please only reply > there next time. > > On Wednesday 26 September 2007, Scott Long wrote: >> Hans Petter Selasky wrote: >>> Hi, >>> >>> Please keep me CC'ed, hence I'm not on all these lists. >>> >>> In the kernel we currently have two different data backstores: >>> >>> struct mbuf >>> >>> and >>> >>> struct buf >>> >>> These two backstores serve two different device types. "mbufs" are for >>> network devices and "buf" is for disk devices. >>> >>> Problem: >>> >>> The current backstores are loaded into DMA by using the BUS-DMA >>> framework. This appears not to be too fast according to Kip Macy. See: >>> >>> http://perforce.freebsd.org/chv.cgi?CH=126455 >> Busdma isn't fast enough for 1Gb and 10Gb network drivers that are >> trying to max out their packet rates. It's still fine for storage >> drivers and other slow/medium speed device drivers, like USB and >> Firewire. I am working on techniques to make the API easier to use >> and the implementation fast enough for the aforementioned devices. > > That's great! > Well, the point is that I'm not sure why you're so worried about performance issues with USB and busdma. Do you have any test data that shows that it's a problem? >>> Some ideas I have: >>> >>> When a buffer is out out of range for a hardware device and a data-copy >>> is needed I want to simply copy that data in smaller parts to/from a >>> pre-allocated bounce buffer. I want to avoid allocating this buffer when >>> "bus_dmamap_load()" is called. >> I think you've missed the point of having architecture portable drivers. >> John-Mark describes this further. > > I use the bus_dma framework to allocate and sync all DMA memory, and I assume > that is correct. > That is one of the uses of busdma, yes. The other is to handle buffers that have been allocated elsewhere in the system. >> It also makes little sense to push >> the responsibility for handling bounce buffers out of a central >> subsystem and back into every driver. > > I'm thinking about putting some wrappers around the "bus_dmamap_load()" > function like: > > void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf, > uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); > > void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf, > uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); > > But I haven't figured out all the details yet. The "usbd_xxx_load()" functions > should automagically figure out what is best to do and it won't be more than > a few lines of code. Can you describe what these two wrappers are supposed to do? Are you expecting bus_dmamap_load() to operate synchronously? Scott From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 02:07:06 2007 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 91E5A16A420 for ; Thu, 27 Sep 2007 02:07:06 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 64C1D13C447 for ; Thu, 27 Sep 2007 02:07:06 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IaimP-000DjL-8Q for freebsd-net@freebsd.org; Thu, 27 Sep 2007 02:07:05 +0000 Message-ID: <46FB1044.7020000@psg.com> Date: Wed, 26 Sep 2007 16:07:00 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: bridging ath 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, 27 Sep 2007 02:07:06 -0000 current i386 thinkpad t41 ifconfig_lo0="inet 127.0.0.1/8" cloned_interfaces="bridge0" ifconfig_bridge0="inet 192.168.0.3/24 addm em0 addm ath0 up" ifconfig_em0="up" ifconfig_ath0="ssid rgnet up" defaultrouter="192.168.0.1" with ether plugged in, i can ping it. unplug ether and no ping over ath0. other hosts are on same ssid and working. em0: flags=8943 metric 0 mtu 1500 options=88 ether 00:0d:60:b2:c5:9e media: Ethernet autoselect (100baseTX ) status: active ath0: flags=8943 metric 0 mtu 1500 ether 00:05:4e:48:ce:66 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/6Mbps) status: associated ssid rgnet channel 6 (2437 Mhz 11g) bssid 00:14:bf:40:eb:88 authmode OPEN privacy OFF txpowmax 34 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 14 roam:rate11g 5 protmode CTS burst bintval 100 lo0: flags=8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 4a:29:32:13:f4:64 inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: ath0 flags=143 member: em0 flags=143 clue by four, please. randy From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 07:21:15 2007 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 6D88216A477; Thu, 27 Sep 2007 07:21:15 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B2B5113C504; Thu, 27 Sep 2007 07:21:13 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8R7LD2e066518; Thu, 27 Sep 2007 07:21:13 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8R7LDsO066514; Thu, 27 Sep 2007 07:21:13 GMT (envelope-from yongari) Date: Thu, 27 Sep 2007 07:21:13 GMT Message-Id: <200709270721.l8R7LDsO066514@freefall.freebsd.org> To: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/116330: [nfe]: network problems under -current, nfe(4) and jumbo packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2007 07:21:15 -0000 Synopsis: [nfe]: network problems under -current, nfe(4) and jumbo packets Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Sep 27 07:20:53 UTC 2007 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=116330 From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 14:15:18 2007 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 DFBB816A417 for ; Thu, 27 Sep 2007 14:15:18 +0000 (UTC) (envelope-from seth.mos@xs4all.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id 81ED113C457 for ; Thu, 27 Sep 2007 14:15:18 +0000 (UTC) (envelope-from seth.mos@xs4all.nl) Received: from [127.0.0.1] ([194.151.164.164]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id l8RE1Wsq025500 for ; Thu, 27 Sep 2007 16:01:34 +0200 (CEST) (envelope-from seth.mos@xs4all.nl) Message-ID: <46FBB7BC.3010301@xs4all.nl> Date: Thu, 27 Sep 2007 16:01:32 +0200 From: Seth Mos User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Racoon 0.7 on FreeBSD 6 with a lot of VPN tunnels 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, 27 Sep 2007 14:15:19 -0000 Hello there, I have problems with racoon hanging in sbwait state with ipsec-tools 0.6.7 or getting into a tailspin on ipsec-tools 0.7. The problem is that the pfkey interface breaks down with a lot of VPN tunnels and spd entries. The FreeBSd PR is here. http://www.freebsd.org/cgi/query-pr.cgi?pr=115651 I have 390 discrete IPSEC VPN tunnels and endpoints. I have loaded this all up into one config. I am using pfSense as the platform of choice. pfSense 1.2-RC2 specifically which is based on FreeBSD 6.2 Stable p7. Note that I am also a pfSense developer. At this current time I have exactly 112 IPSEC tunnels active. I am using 3des-sha1 with a 3600 lifetime for phase 1 and aes128-sha1 with a 28800 lifetime for phase2. On ipsec-tools 0.6.7 I can go by for several days before the racoon process wedges itself into a hanging sbwait state (0% cpu). On ipsec-tools 0.7 the situation is significantly worse and it starts churning 100% cpu somewhere every 1-4 hours. Basically where 0.6.7 was difficult 0.7 has become unworkable. The hardware in question is a Dell PE860 with 6 gigabit nics (about 2mbps ipsec traffic at most) with a DualCore Xeon 3050 2.13Ghz. With 1GB ram. In the pfSense kernel we use this patch. http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/tools/patches/RELENG_6_2/socketvar.h.diff Which helps significantly. Without this patch the situation is the same as I have described above but will be reached at about 30-40 active tunnels instead of the 112 I have now. I really need a reliable solution to this problem. Kind regards, Seth Mos pfSense Developer From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 15:16:18 2007 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 5C93316A419 for ; Thu, 27 Sep 2007 15:16:18 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id C5AB713C480 for ; Thu, 27 Sep 2007 15:16:17 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 9F56A3F1F; Thu, 27 Sep 2007 16:47:48 +0200 (CEST) Date: Thu, 27 Sep 2007 16:47:48 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070927144748.GA26659@zen.inc> References: <46FBB7BC.3010301@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FBB7BC.3010301@xs4all.nl> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Racoon 0.7 on FreeBSD 6 with a lot of VPN tunnels 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, 27 Sep 2007 15:16:18 -0000 On Thu, Sep 27, 2007 at 04:01:32PM +0200, Seth Mos wrote: > Hello there, Hi. > I have problems with racoon hanging in sbwait state with ipsec-tools 0.6.7 > or getting into a tailspin on ipsec-tools 0.7. > > The problem is that the pfkey interface breaks down with a lot of VPN > tunnels and spd entries. The FreeBSd PR is here. > http://www.freebsd.org/cgi/query-pr.cgi?pr=115651 Yep. Unfortunately, this is a well know issue for a quite long time. > I have 390 discrete IPSEC VPN tunnels and endpoints. I have loaded this > all up into one config. I am using pfSense as the platform of choice. > pfSense 1.2-RC2 specifically which is based on FreeBSD 6.2 Stable p7. Note > that I am also a pfSense developer. > > At this current time I have exactly 112 IPSEC tunnels active. I am using > 3des-sha1 with a 3600 lifetime for phase 1 and aes128-sha1 with a 28800 > lifetime for phase2. > > On ipsec-tools 0.6.7 I can go by for several days before the racoon > process wedges itself into a hanging sbwait state (0% cpu). On ipsec-tools > 0.7 the situation is significantly worse and it starts churning 100% cpu > somewhere every 1-4 hours. > > Basically where 0.6.7 was difficult 0.7 has become unworkable. That's strange, I don't remind any change between 0.6 and 0.7 which may generate such difference. And, to be more exact, I don't remember anything in 0.6 branch (or in any other public branch) which may help things work better in such setup. > The hardware in question is a Dell PE860 with 6 gigabit nics (about 2mbps > ipsec traffic at most) with a DualCore Xeon 3050 2.13Ghz. With 1GB ram. > > In the pfSense kernel we use this patch. > http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/tools/patches/RELENG_6_2/socketvar.h.diff > Which helps significantly. Without this patch the situation is the same as > I have described above but will be reached at about 30-40 active tunnels > instead of the 112 I have now. The first thing you can try is that patch in racoon: --- src/libipsec/pfkey.c 1 Aug 2007 11:52:18 -0000 1.13.4.1 +++ src/libipsec/pfkey.c 27 Sep 2007 14:44:27 -0000 @@ -1801,7 +1801,12 @@ pfkey_open() */ (void)setsockopt(so, SOL_SOCKET, SO_SNDBUF, &bufsiz, sizeof(bufsiz)); (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); - + bufsiz = 256 * 1024; + (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); + bufsiz = 512 * 1024; + (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); + bufsiz = 1024 * 1024; + (void)setsockopt(so, SOL_SOCKET, SO_RCVBUF, &bufsiz, sizeof(bufsiz)); __ipsec_errcode = EIPSEC_NO_ERROR; return so; } (you may have problems to directly apply this patch because it's a copy/paste, but it's quite easy to report manually). And as we have more and more requests about such problems, I'll probably directly commit it for ipsec-tools 0.7.1 / HEAD. But I'm quite sure it will not completly solve your problem, it will just raise the limit. Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 15:28:31 2007 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 94FDB16A469 for ; Thu, 27 Sep 2007 15:28:31 +0000 (UTC) (envelope-from wel@skm.net.ua) Received: from mail.skm.net.ua (skm.sat.poltava.ua [193.109.248.245]) by mx1.freebsd.org (Postfix) with ESMTP id 0D8A213C448 for ; Thu, 27 Sep 2007 15:28:31 +0000 (UTC) (envelope-from wel@skm.net.ua) Received: from [193.238.152.25] by mail.skm.net.ua with esmtpa (Exim 4.63) (envelope-from ) id 1IaxXZ-00059m-GH for freebsd-net@freebsd.org; Thu, 27 Sep 2007 17:52:46 +0000 From: "wel@skm.net.ua" To: freebsd-net@freebsd.org In-Reply-To: <20070731120013.285EE16A4E1@hub.freebsd.org> References: <20070731120013.285EE16A4E1@hub.freebsd.org> Content-Type: text/plain Message-Id: <1190638009.11029.14.camel@localhost> Mime-Version: 1.0 Date: Wed, 26 Sep 2007 13:38:18 +0300 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Subject: ng_nat+ng_netflow+mpd4 - ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wel@skm.net.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2007 15:28:31 -0000 Hello I want to count ALL traffic pass trought my gateway, but tool's such as softflowd I don't want to use because there is already ng_netflow and I want use nat from netgraph, may I :)? I have: #ifconfig rl0: flags=8843 mtu 1500 options=8 inet 10.11.2.1 netmask 0xffffff00 broadcast 10.11.2.255 rl1: flags=8843 mtu 1500 options=8 inet 192.168.100.99 netmask 0xffffff00 broadcast 192.168.100.255 plip0: flags=108810 mtu 1500 pfsync0: flags=0<> mtu 2020 syncpeer: 224.0.0.240 maxupd: 128 pflog0: flags=0<> mtu 33208 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 # uname -r 6.2-RELEASE-p7 rl0 - local network rl1 - internet #cat KERNEL options LIBALIAS options NETGRAPH options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_BRIDGE options NETGRAPH_CISCO options NETGRAPH_DEVICE options NETGRAPH_ECHO options NETGRAPH_EIFACE options NETGRAPH_ETHER options NETGRAPH_GIF options NETGRAPH_GIF_DEMUX options NETGRAPH_TAG options NETGRAPH_TCPMSS options NETGRAPH_FEC options NETGRAPH_HOLE options NETGRAPH_IFACE options NETGRAPH_IP_INPUT options NETGRAPH_KSOCKET options NETGRAPH_L2TP options NETGRAPH_LMI options NETGRAPH_NETFLOW options NETGRAPH_ONE2MANY options NETGRAPH_PPP options NETGRAPH_MPPC_ENCRYPTION options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_RFC1490 options NETGRAPH_SOCKET options NETGRAPH_SPLIT options NETGRAPH_TEE options NETGRAPH_TTY options NETGRAPH_UI options NETGRAPH_VJC options NETGRAPH options NETGRAPH_IPFW options NETGRAPH_NAT options NETGRAPH_NETFLOW options NETGRAPH_SPLIT options NETGRAPH_KSOCKET options NETGRAPH_SOCKET options NETGRAPH_IFACE options NETGRAPH_TCPMSS flow-capture + ng_netflow + this script working fine #ngctl -f /ng_netflow #cat /ng_netflow mkpeer rl1: tee lower left name rl1:lower tee0 connect rl1: rl1:lower upper right mkpeer tee0: one2many left2right many0 name tee0:left2right one2many0 connect tee0: one2many0: right2left many1 mkpeer one2many0: netflow one iface0 name one2many0:one netflow mkpeer netflow: ksocket export inet/dgram/udp msg netflow: setifindex { iface=0 index=2 } msg netflow:export connect inet/127.0.0.1:2222 I find this script: When I apply ipfw rules my coputer lost network. I mixed in rules in/out and 70/71. But nat+netflow don't working. I use ipfw-rules only 200 and 201, but it's doesn't working: /sbin/ipfw add 110 ngtee 30 ip from any to any out via ng* /sbin/ipfw add 111 ngtee 30 ip from any to any in via ng* /sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to $EXT_IP out via rl1 /sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not $LOCAL_NET in via rl1 #!/bin/sh EXT_IP="192.168.100.99" LOCAL_NET="10.11.2.0/24" /usr/sbin/ngctl mkpeer ipfw: nat 70 out /usr/sbin/ngctl name ipfw:70 nat /usr/sbin/ngctl connect ipfw: nat: 71 in /usr/sbin/ngctl msg nat: setaliasaddr $EXT_IP /usr/sbin/ngctl mkpeer ipfw: netflow 30 iface0 /usr/sbin/ngctl name ipfw:30 netflow /usr/sbin/ngctl msg netflow: setdlt {iface=0 dlt=12} /usr/sbin/ngctl msg netflow: setifindex {iface=0 index=1} /usr/sbin/ngctl mkpeer netflow: ksocket export inet/dgram/udp /usr/sbin/ngctl msg netflow:export connect inet/127.0.0.1:2222 /sbin/ipfw add 6400 allow all from any to any /sbin/sysctl net.inet.ip.fw.one_pass=0 /sbin/ipfw add 110 ngtee 30 ip from any to any out via ng* /sbin/ipfw add 111 ngtee 30 ip from any to any in via ng* /sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to $EXT_IP out via rl1 /sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not $LOCAL_NET in via rl1 /usr/local/bin/flow-capture -n 287 -w /var/db/flows/ 0.0.0.0/127.0.0.1/2222 From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 17:27:54 2007 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 9C7D716A421; Thu, 27 Sep 2007 17:27:54 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 0CA3113C469; Thu, 27 Sep 2007 17:27:51 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46FBE818.3020800@FreeBSD.org> Date: Thu, 27 Sep 2007 19:27:52 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Panic in rt_check 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, 27 Sep 2007 17:27:54 -0000 Ivan Voras wrote: > Hi, > > I have a machine that panics almost daily in route.c, in rt_check(). > This panic has been reported by several users, including Marcel > Moolenaar for a machine in freebsd.org. > > The problem is present in both 6-STABLE and 7-CURRENT, and apparently it > manifests on SMP machines, both i386 and AMD64. > > The panic backtrace looks like this: > > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305 I've asked this before of others without getting an answer: is it possible that your gateway route is disappearing (e.g. router going offline, flaky switch, cable unplugged, etc)? I have seen this panic (only) in that situation. Kris From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 18:05:54 2007 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 6547516A417; Thu, 27 Sep 2007 18:05:54 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 92B6C13C4B6; Thu, 27 Sep 2007 18:05:52 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46FBF101.6080402@FreeBSD.org> Date: Thu, 27 Sep 2007 20:05:53 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Voras References: <46FBE818.3020800@FreeBSD.org> <9bbcef730709271054k5cbda605wcfd44adede05614f@mail.gmail.com> In-Reply-To: <9bbcef730709271054k5cbda605wcfd44adede05614f@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Panic in rt_check 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, 27 Sep 2007 18:05:54 -0000 Ivan Voras wrote: > On 27/09/2007, Kris Kennaway wrote: >> Ivan Voras wrote: >>> Hi, >>> >>> I have a machine that panics almost daily in route.c, in rt_check(). >>> This panic has been reported by several users, including Marcel >>> Moolenaar for a machine in freebsd.org. >>> >>> The problem is present in both 6-STABLE and 7-CURRENT, and apparently it >>> manifests on SMP machines, both i386 and AMD64. >>> >>> The panic backtrace looks like this: >>> >>> panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305 >> I've asked this before of others without getting an answer: is it >> possible that your gateway route is disappearing (e.g. router going >> offline, flaky switch, cable unplugged, etc)? I have seen this panic >> (only) in that situation. > > If there is a way to find this out from the machine itself, I can try > and look it up, otherwise I don't (and cannot) know. The > infrastructure is a bit big but AFAIK it's nothing special. > > Should I just call mtx_initialized() before the line and bail out if > it isn't? OTOH I need a stable patch that will be committed. You will need to evaluate based on other evidence. e.g. if you've noticed other network flakiness on this machine to do with the gateway. If my guess is correct then it's likely to be a race with something else removing the gateway route without locking it, which means that it's not always going to panic and you may notice other effects from it going away. Checking mtx_initialized won't help in that case because the race is still there. You'd need to check the places that can remove it and make sure they are all correctly locking the route first. Kris From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 18:20:48 2007 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 3FECF16A421 for ; Thu, 27 Sep 2007 18:20:48 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id CEFAD13C46E for ; Thu, 27 Sep 2007 18:20:47 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1635461nzf for ; Thu, 27 Sep 2007 11:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ZT+xDlDiAZ9czmtbozoIkm/fWcY385XooaKdshG8irU=; b=QQ5WMH8dKVcao7UxMVv9wyTHKbPGVxm81VprYlR8QojoWYwPICLYgVJbuEwpwAmizPdtcxGwUOas1Wv295ckENgMZ02dy1sDrX+CwnPRjdz6qh9aZVqHUkbwPVZHGfD+FFp40xfjm6mFXl50EmtJe5UnI2uz6iaB/ADXwvnwVs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lCRWENKgYvfSU7cFzdAhPBv5NKsFQpauW0kGLZi25tOcnJIZyyCPiCE9LA/pVoTv1NPf2P6xpPSShlZ3b1ERM7KFIId33TKrpEevU6lkl7K5ysPkf2Cl+3ijqZVneysJ+XnUfjwQlEyGU95PbaCGBJyarEEo6ctohlMLe8yZ+Mc= Received: by 10.141.161.6 with SMTP id n6mr1049490rvo.1190915678095; Thu, 27 Sep 2007 10:54:38 -0700 (PDT) Received: by 10.141.159.3 with HTTP; Thu, 27 Sep 2007 10:54:38 -0700 (PDT) Message-ID: <9bbcef730709271054k5cbda605wcfd44adede05614f@mail.gmail.com> Date: Thu, 27 Sep 2007 19:54:38 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Kris Kennaway" In-Reply-To: <46FBE818.3020800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46FBE818.3020800@FreeBSD.org> X-Google-Sender-Auth: 8fcf1908c760b556 Cc: freebsd-net@freebsd.org Subject: Re: Panic in rt_check 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, 27 Sep 2007 18:20:48 -0000 On 27/09/2007, Kris Kennaway wrote: > Ivan Voras wrote: > > Hi, > > > > I have a machine that panics almost daily in route.c, in rt_check(). > > This panic has been reported by several users, including Marcel > > Moolenaar for a machine in freebsd.org. > > > > The problem is present in both 6-STABLE and 7-CURRENT, and apparently it > > manifests on SMP machines, both i386 and AMD64. > > > > The panic backtrace looks like this: > > > > panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305 > > I've asked this before of others without getting an answer: is it > possible that your gateway route is disappearing (e.g. router going > offline, flaky switch, cable unplugged, etc)? I have seen this panic > (only) in that situation. If there is a way to find this out from the machine itself, I can try and look it up, otherwise I don't (and cannot) know. The infrastructure is a bit big but AFAIK it's nothing special. Should I just call mtx_initialized() before the line and bail out if it isn't? OTOH I need a stable patch that will be committed. From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 19:08:08 2007 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 08AEC16A420 for ; Thu, 27 Sep 2007 19:08:08 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id A54C913C48D for ; Thu, 27 Sep 2007 19:08:07 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1645621nzf for ; Thu, 27 Sep 2007 12:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=2RABbxk93DCVy8kxuTTzEBq9gAVufX0wUPsYzD+jSB4=; b=EEmfRb0fterpltiqmismI53HfavIvLsLFUUmhDgXVoS12EYMpjnDIQuseQrLUC5fO6QFaZe0sGzk5BhvDgEFTEccd/VneKS3T13tgNAdZ7WB8ERdlbOFfwfEOpJCtYpvanNr+DyaTPlQcsWHVPO5+Ix5FkwJXzw5d7H7GDrBf4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ADiV8PLZzBQbd7F4UtXKIjShhXQ5BCuGocHQLpQUNJ8qoRQhBvt20fCCQcIuhn8v7eCR9seaGpEO9JhTE/Aoa8wSJqbszCHkm6PcQmhFmFHi3AdxUKMjMZA06xh8rzXTEZ8OSscenl0GSwAoy/Yx970N9xfMcK/TYPd4Q62p7Fs= Received: by 10.141.116.16 with SMTP id t16mr1097213rvm.1190920086290; Thu, 27 Sep 2007 12:08:06 -0700 (PDT) Received: by 10.141.159.3 with HTTP; Thu, 27 Sep 2007 12:08:06 -0700 (PDT) Message-ID: <9bbcef730709271208t74938933p704b554625f443ba@mail.gmail.com> Date: Thu, 27 Sep 2007 21:08:06 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Kris Kennaway" In-Reply-To: <46FBF101.6080402@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46FBE818.3020800@FreeBSD.org> <9bbcef730709271054k5cbda605wcfd44adede05614f@mail.gmail.com> <46FBF101.6080402@FreeBSD.org> X-Google-Sender-Auth: 05787ef7a51086a5 Cc: freebsd-net@freebsd.org Subject: Re: Panic in rt_check 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, 27 Sep 2007 19:08:08 -0000 On 27/09/2007, Kris Kennaway wrote: > You will need to evaluate based on other evidence. e.g. if you've > noticed other network flakiness on this machine to do with the gateway. No, I don't think there's anything like that. The panics began when I upgraded to 7-current, the machine was stable under 6-stable. It might be a coincidence or the new code is just more optimized and exposes parallelism more. > Checking mtx_initialized won't help in that case because the race is > still there. You'd need to check the places that can remove it and make > sure they are all correctly locking the route first. I can only grep... From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 19:16:47 2007 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 5E81416A468; Thu, 27 Sep 2007 19:16:47 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id D885113C478; Thu, 27 Sep 2007 19:16:45 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46FC019F.60900@FreeBSD.org> Date: Thu, 27 Sep 2007 21:16:47 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Voras References: <46FBE818.3020800@FreeBSD.org> <9bbcef730709271054k5cbda605wcfd44adede05614f@mail.gmail.com> <46FBF101.6080402@FreeBSD.org> <9bbcef730709271208t74938933p704b554625f443ba@mail.gmail.com> In-Reply-To: <9bbcef730709271208t74938933p704b554625f443ba@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Panic in rt_check 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, 27 Sep 2007 19:16:47 -0000 Ivan Voras wrote: > On 27/09/2007, Kris Kennaway wrote: > >> You will need to evaluate based on other evidence. e.g. if you've >> noticed other network flakiness on this machine to do with the gateway. > > No, I don't think there's anything like that. The panics began when I > upgraded to 7-current, the machine was stable under 6-stable. It might > be a coincidence or the new code is just more optimized and exposes > parallelism more. Yes, that is not really relevant, the same condition could have been occurring on your network prior to the upgrade. You may not notice if e.g. your switch is momentarily dropping carrier every now and then. >> Checking mtx_initialized won't help in that case because the race is >> still there. You'd need to check the places that can remove it and make >> sure they are all correctly locking the route first. > > I can only grep... OK, it likely needs more detailed investigation than that ;-) Kris From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 19:45:40 2007 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 878D916A41A for ; Thu, 27 Sep 2007 19:45:40 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id F252713C45D for ; Thu, 27 Sep 2007 19:45:39 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IazIg-0006jo-5G for freebsd-net@freebsd.org; Thu, 27 Sep 2007 19:45:30 +0000 Received: from 89-172-32-198.adsl.net.t-com.hr ([89.172.32.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 19:45:30 +0000 Received: from ivoras by 89-172-32-198.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 19:45:30 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 27 Sep 2007 21:44:56 +0200 Lines: 37 Message-ID: References: <46FBE818.3020800@FreeBSD.org> <9bbcef730709271054k5cbda605wcfd44adede05614f@mail.gmail.com> <46FBF101.6080402@FreeBSD.org> <9bbcef730709271208t74938933p704b554625f443ba@mail.gmail.com> <46FC019F.60900@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9F25C8AE3EB80075DF35A669" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-32-198.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <46FC019F.60900@FreeBSD.org> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: Panic in rt_check 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, 27 Sep 2007 19:45:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9F25C8AE3EB80075DF35A669 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kris Kennaway wrote: > OK, it likely needs more detailed investigation than that ;-) Hmm, grepping has found one straw-chance: I found that if_stf.c calls rtfree() instead of RTFREE_LOCKED (I cannot tell if RTFREE_LOCKED is really needed in this situation or RTFREE is needed), and a diff to my 6-STABLE kernel configuration shows that I left IPv6 in this time. Apparently, this was patched 4 days ago so I'll try two things: 1) build with the new (patched) version and 2) if that doesn't work (probably won't), I'll remove IPv6 from the kernel and try again. Each of this steps will probably take something like 2 days (the average time between panics is ~~ 1 day) until I can say if there's some progress. --------------enig9F25C8AE3EB80075DF35A669 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG/Ag+ldnAQVacBcgRApa7AJ9rSy4CWQk2YFSQtXqAEGq3fUg/aACghuKI rdH5rIbWnfx18f27bjQ/JHI= =UVdi -----END PGP SIGNATURE----- --------------enig9F25C8AE3EB80075DF35A669-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 21:41:02 2007 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 ADAB816A419 for ; Thu, 27 Sep 2007 21:41:02 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 4C93E13C494 for ; Thu, 27 Sep 2007 21:41:02 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id D754F1CC2C; Fri, 28 Sep 2007 09:41:00 +1200 (NZST) Date: Fri, 28 Sep 2007 09:41:00 +1200 From: Andrew Thompson To: Randy Bush Message-ID: <20070927214100.GB20718@heff.fud.org.nz> References: <46FB1044.7020000@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FB1044.7020000@psg.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Net Subject: Re: bridging ath 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, 27 Sep 2007 21:41:02 -0000 On Wed, Sep 26, 2007 at 04:07:00PM -1000, Randy Bush wrote: > current i386 thinkpad t41 > > ifconfig_lo0="inet 127.0.0.1/8" > cloned_interfaces="bridge0" > ifconfig_bridge0="inet 192.168.0.3/24 addm em0 addm ath0 up" > ifconfig_em0="up" > ifconfig_ath0="ssid rgnet up" > defaultrouter="192.168.0.1" > > with ether plugged in, i can ping it. unplug ether and no ping over > ath0. other hosts are on same ssid and working. I will try to reproduce this in the weekend. Just to make sure, you are pinging 192.168.0.3 from a remote wireless node connected to ath0, and unplugging em0 causes this to fail? Andrew From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 21:51:03 2007 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 612C716A41A for ; Thu, 27 Sep 2007 21:51:03 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 3769513C45B for ; Thu, 27 Sep 2007 21:51:03 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ib1GA-000FIQ-PN; Thu, 27 Sep 2007 21:51:03 +0000 Message-ID: <46FC25C3.8030703@psg.com> Date: Thu, 27 Sep 2007 11:50:59 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Thompson References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> In-Reply-To: <20070927214100.GB20718@heff.fud.org.nz> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: bridging ath 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, 27 Sep 2007 21:51:03 -0000 Andrew Thompson wrote: > On Wed, Sep 26, 2007 at 04:07:00PM -1000, Randy Bush wrote: >> current i386 thinkpad t41 >> >> ifconfig_lo0="inet 127.0.0.1/8" >> cloned_interfaces="bridge0" >> ifconfig_bridge0="inet 192.168.0.3/24 addm em0 addm ath0 up" >> ifconfig_em0="up" >> ifconfig_ath0="ssid rgnet up" >> defaultrouter="192.168.0.1" >> >> with ether plugged in, i can ping it. unplug ether and no ping over >> ath0. other hosts are on same ssid and working. > > I will try to reproduce this in the weekend. Just to make sure, you are > pinging 192.168.0.3 from a remote wireless node connected to ath0, and > unplugging em0 causes this to fail? connect both wireless and ether. it is pingable. disconnect ether. no can ping. reduce to ifconfig_ath0="inet 192.168.0.3/24 ssid rgnet up" with no em0, bridge, ... and it is pingable. randy randy From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 22:28:20 2007 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 265FF16A419 for ; Thu, 27 Sep 2007 22:28:20 +0000 (UTC) (envelope-from wel@skm.net.ua) Received: from mail.skm.net.ua (skm.sat.poltava.ua [193.109.248.245]) by mx1.freebsd.org (Postfix) with ESMTP id 8548013C459 for ; Thu, 27 Sep 2007 22:28:18 +0000 (UTC) (envelope-from wel@skm.net.ua) Received: from [193.238.152.25] by mail.skm.net.ua with esmtpa (Exim 4.63) (envelope-from ) id 1Ib4cj-0006jm-Py for freebsd-net@freebsd.org; Fri, 28 Sep 2007 01:26:35 +0000 From: "wel@skm.net.ua" To: freebsd-net@freebsd.org In-Reply-To: <20070731120013.285EE16A4E1@hub.freebsd.org> References: <20070731120013.285EE16A4E1@hub.freebsd.org> Content-Type: text/plain Message-Id: <1190638009.11029.14.camel@localhost> Mime-Version: 1.0 Date: Thu, 27 Sep 2007 17:52:09 +0300 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: 7bit Subject: ng_nat+ng_netflow+mpd4 - ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wel@skm.net.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2007 22:28:20 -0000 Hello I want to count ALL traffic pass trought my gateway, but tool's such as softflowd I don't want to use because there is already ng_netflow and I want use nat from netgraph, may I :)? I have: #ifconfig rl0: flags=8843 mtu 1500 options=8 inet 10.11.2.1 netmask 0xffffff00 broadcast 10.11.2.255 rl1: flags=8843 mtu 1500 options=8 inet 192.168.100.99 netmask 0xffffff00 broadcast 192.168.100.255 plip0: flags=108810 mtu 1500 pfsync0: flags=0<> mtu 2020 syncpeer: 224.0.0.240 maxupd: 128 pflog0: flags=0<> mtu 33208 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 # uname -r 6.2-RELEASE-p7 rl0 - local network rl1 - internet #cat KERNEL options LIBALIAS options NETGRAPH options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_BRIDGE options NETGRAPH_CISCO options NETGRAPH_DEVICE options NETGRAPH_ECHO options NETGRAPH_EIFACE options NETGRAPH_ETHER options NETGRAPH_GIF options NETGRAPH_GIF_DEMUX options NETGRAPH_TAG options NETGRAPH_TCPMSS options NETGRAPH_FEC options NETGRAPH_HOLE options NETGRAPH_IFACE options NETGRAPH_IP_INPUT options NETGRAPH_KSOCKET options NETGRAPH_L2TP options NETGRAPH_LMI options NETGRAPH_NETFLOW options NETGRAPH_ONE2MANY options NETGRAPH_PPP options NETGRAPH_MPPC_ENCRYPTION options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_RFC1490 options NETGRAPH_SOCKET options NETGRAPH_SPLIT options NETGRAPH_TEE options NETGRAPH_TTY options NETGRAPH_UI options NETGRAPH_VJC options NETGRAPH options NETGRAPH_IPFW options NETGRAPH_NAT options NETGRAPH_NETFLOW options NETGRAPH_SPLIT options NETGRAPH_KSOCKET options NETGRAPH_SOCKET options NETGRAPH_IFACE options NETGRAPH_TCPMSS flow-capture + ng_netflow + this script working fine #ngctl -f /ng_netflow #cat /ng_netflow mkpeer rl1: tee lower left name rl1:lower tee0 connect rl1: rl1:lower upper right mkpeer tee0: one2many left2right many0 name tee0:left2right one2many0 connect tee0: one2many0: right2left many1 mkpeer one2many0: netflow one iface0 name one2many0:one netflow mkpeer netflow: ksocket export inet/dgram/udp msg netflow: setifindex { iface=0 index=2 } msg netflow:export connect inet/127.0.0.1:2222 I find this script: When I apply ipfw rules my coputer lost network. I mixed in rules in/out and 70/71. But nat+netflow don't working. I use ipfw-rules only 200 and 201, but it's doesn't working: /sbin/ipfw add 110 ngtee 30 ip from any to any out via ng* /sbin/ipfw add 111 ngtee 30 ip from any to any in via ng* /sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to $EXT_IP out via rl1 /sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not $LOCAL_NET in via rl1 #!/bin/sh EXT_IP="192.168.100.99" LOCAL_NET="10.11.2.0/24" /usr/sbin/ngctl mkpeer ipfw: nat 70 out /usr/sbin/ngctl name ipfw:70 nat /usr/sbin/ngctl connect ipfw: nat: 71 in /usr/sbin/ngctl msg nat: setaliasaddr $EXT_IP /usr/sbin/ngctl mkpeer ipfw: netflow 30 iface0 /usr/sbin/ngctl name ipfw:30 netflow /usr/sbin/ngctl msg netflow: setdlt {iface=0 dlt=12} /usr/sbin/ngctl msg netflow: setifindex {iface=0 index=1} /usr/sbin/ngctl mkpeer netflow: ksocket export inet/dgram/udp /usr/sbin/ngctl msg netflow:export connect inet/127.0.0.1:2222 /sbin/ipfw add 6400 allow all from any to any /sbin/sysctl net.inet.ip.fw.one_pass=0 /sbin/ipfw add 110 ngtee 30 ip from any to any out via ng* /sbin/ipfw add 111 ngtee 30 ip from any to any in via ng* /sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to $EXT_IP out via rl1 /sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not $LOCAL_NET in via rl1 /usr/local/bin/flow-capture -n 287 -w /var/db/flows/ 0.0.0.0/127.0.0.1/2222 From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 23:03:56 2007 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 5E55116A41B; Thu, 27 Sep 2007 23:03:56 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-defer01.adhost.com (mail-defer01.adhost.com [216.211.128.150]) by mx1.freebsd.org (Postfix) with ESMTP id 372B213C4B5; Thu, 27 Sep 2007 23:03:56 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in03.adhost.com (mail-in03.adhost.com [10.211.128.143]) by mail-defer01.adhost.com (Postfix) with ESMTP id D74C7ED7D8; Thu, 27 Sep 2007 15:44:59 -0700 (PDT) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (unknown [216.211.143.69]) by mail-in03.adhost.com (Postfix) with ESMTP id 67EB9119C51; Thu, 27 Sep 2007 15:44:59 -0700 (PDT) (envelope-from mksmith@adhost.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 27 Sep 2007 15:44:58 -0700 Message-ID: <17838240D9A5544AAA5FF95F8D52031602895DA5@ad-exh01.adhost.lan> In-Reply-To: <46FC25C3.8030703@psg.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bridging ath Thread-Index: AcgBUIogvc69ZQzjTVG5cKw9qWf5dAABy03Q References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> From: "Michael K. Smith - Adhost" To: "Randy Bush" , "Andrew Thompson" Cc: FreeBSD Net Subject: RE: bridging ath 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, 27 Sep 2007 23:03:56 -0000 >=20 > Andrew Thompson wrote: > > On Wed, Sep 26, 2007 at 04:07:00PM -1000, Randy Bush wrote: > >> current i386 thinkpad t41 > >> > >> ifconfig_lo0=3D"inet 127.0.0.1/8" > >> cloned_interfaces=3D"bridge0" > >> ifconfig_bridge0=3D"inet 192.168.0.3/24 addm em0 addm ath0 up" > >> ifconfig_em0=3D"up" > >> ifconfig_ath0=3D"ssid rgnet up" > >> defaultrouter=3D"192.168.0.1" > >> > >> with ether plugged in, i can ping it. unplug ether and no ping over > >> ath0. other hosts are on same ssid and working. > > > > I will try to reproduce this in the weekend. Just to make sure, you > are > > pinging 192.168.0.3 from a remote wireless node connected to ath0, > and > > unplugging em0 causes this to fail? >=20 > connect both wireless and ether. it is pingable. disconnect ether. no > can ping. >=20 > reduce to > ifconfig_ath0=3D"inet 192.168.0.3/24 ssid rgnet up" > with no em0, bridge, ... and it is pingable. >=20 > randy >=20 Just to be sure... net.inet.ip.forwarding=3D1 net.link.ether.bridge.enable=3D1 net.link.ether.bridge.config=3Dem0,ath0 From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 23:20:01 2007 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 422A416A417; Thu, 27 Sep 2007 23:20:01 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED0C13C469; Thu, 27 Sep 2007 23:20:01 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ib2eG-000G0z-9z; Thu, 27 Sep 2007 23:20:00 +0000 Message-ID: <46FC3A8E.20307@psg.com> Date: Thu, 27 Sep 2007 13:19:42 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael K. Smith - Adhost" References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <17838240D9A5544AAA5FF95F8D52031602895DA5@ad-exh01.adhost.lan> In-Reply-To: <17838240D9A5544AAA5FF95F8D52031602895DA5@ad-exh01.adhost.lan> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Andrew Thompson Subject: Re: bridging ath 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, 27 Sep 2007 23:20:01 -0000 > Just to be sure... good questions, thanks for asking > net.inet.ip.forwarding=1 # sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 1 > net.link.ether.bridge.enable=1 > net.link.ether.bridge.config=em0,ath0 # sysctl net.link.ether.bridge.enable sysctl: unknown oid 'net.link.ether.bridge.enable' # sysctl -a | grep bridge net.link.bridge.ipfw: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 1 dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.hostb.0.%desc: Host to PCI bridge dev.agp.0.%desc: Intel 82855 host to AGP bridge dev.isab.0.%desc: PCI-ISA bridge oops! have i left something out of kernel or kld load? randy From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 23:21:47 2007 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 0C41216A41B for ; Thu, 27 Sep 2007 23:21:47 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id A22DD13C468 for ; Thu, 27 Sep 2007 23:21:46 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id D516F1CC26; Fri, 28 Sep 2007 11:21:44 +1200 (NZST) Date: Fri, 28 Sep 2007 11:21:44 +1200 From: Andrew Thompson To: Randy Bush Message-ID: <20070927232144.GA43056@heff.fud.org.nz> References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <17838240D9A5544AAA5FF95F8D52031602895DA5@ad-exh01.adhost.lan> <46FC3A8E.20307@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FC3A8E.20307@psg.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "Michael K. Smith - Adhost" , FreeBSD Net Subject: Re: bridging ath 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, 27 Sep 2007 23:21:47 -0000 On Thu, Sep 27, 2007 at 01:19:42PM -1000, Randy Bush wrote: > > Just to be sure... > > good questions, thanks for asking > > > net.inet.ip.forwarding=1 > > # sysctl net.inet.ip.forwarding > net.inet.ip.forwarding: 1 > > > net.link.ether.bridge.enable=1 > > net.link.ether.bridge.config=em0,ath0 > > # sysctl net.link.ether.bridge.enable > sysctl: unknown oid 'net.link.ether.bridge.enable' > # sysctl -a | grep bridge > net.link.bridge.ipfw: 0 > net.link.bridge.log_stp: 0 > net.link.bridge.pfil_local_phys: 0 > net.link.bridge.pfil_member: 1 > net.link.bridge.pfil_bridge: 1 > net.link.bridge.ipfw_arp: 0 > net.link.bridge.pfil_onlyip: 1 > dev.pcib.0.%desc: ACPI Host-PCI bridge > dev.pcib.1.%desc: ACPI PCI-PCI bridge > dev.pcib.2.%desc: ACPI PCI-PCI bridge > dev.hostb.0.%desc: Host to PCI bridge > dev.agp.0.%desc: Intel 82855 host to AGP bridge > dev.isab.0.%desc: PCI-ISA bridge > > oops! have i left something out of kernel or kld load? No, Michael's example was for old-bridge which is depreciated. You had the config right. Andrew From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 23:28:48 2007 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 C68E716A418; Thu, 27 Sep 2007 23:28:48 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in01.adhost.com (mail-in01.adhost.com [216.211.128.146]) by mx1.freebsd.org (Postfix) with ESMTP id A6C5413C458; Thu, 27 Sep 2007 23:28:48 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (unknown [216.211.143.69]) by mail-in01.adhost.com (Postfix) with ESMTP id 63B9061C32; Thu, 27 Sep 2007 16:28:48 -0700 (PDT) (envelope-from mksmith@adhost.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 27 Sep 2007 16:28:47 -0700 Message-ID: <17838240D9A5544AAA5FF95F8D52031602895DBB@ad-exh01.adhost.lan> In-Reply-To: <20070927232144.GA43056@heff.fud.org.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bridging ath Thread-Index: AcgBXS8g7PP/kM9WQkqW4qKerB0CjQAAFCQw References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <17838240D9A5544AAA5FF95F8D52031602895DA5@ad-exh01.adhost.lan> <46FC3A8E.20307@psg.com> <20070927232144.GA43056@heff.fud.org.nz> From: "Michael K. Smith - Adhost" To: "Andrew Thompson" , "Randy Bush" Cc: FreeBSD Net Subject: RE: bridging ath 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, 27 Sep 2007 23:28:48 -0000 > -----Original Message----- > From: Andrew Thompson [mailto:thompsa@FreeBSD.org] > Sent: Thursday, September 27, 2007 4:22 PM > To: Randy Bush > Cc: Michael K. Smith - Adhost; FreeBSD Net > Subject: Re: bridging ath >=20 > On Thu, Sep 27, 2007 at 01:19:42PM -1000, Randy Bush wrote: > > > Just to be sure... > > > > good questions, thanks for asking > > > > > net.inet.ip.forwarding=3D1 > > > > # sysctl net.inet.ip.forwarding > > net.inet.ip.forwarding: 1 > > > > > net.link.ether.bridge.enable=3D1 > > > net.link.ether.bridge.config=3Dem0,ath0 > > > > # sysctl net.link.ether.bridge.enable > > sysctl: unknown oid 'net.link.ether.bridge.enable' > > # sysctl -a | grep bridge > > net.link.bridge.ipfw: 0 > > net.link.bridge.log_stp: 0 > > net.link.bridge.pfil_local_phys: 0 > > net.link.bridge.pfil_member: 1 > > net.link.bridge.pfil_bridge: 1 > > net.link.bridge.ipfw_arp: 0 > > net.link.bridge.pfil_onlyip: 1 > > dev.pcib.0.%desc: ACPI Host-PCI bridge > > dev.pcib.1.%desc: ACPI PCI-PCI bridge > > dev.pcib.2.%desc: ACPI PCI-PCI bridge > > dev.hostb.0.%desc: Host to PCI bridge > > dev.agp.0.%desc: Intel 82855 host to AGP bridge > > dev.isab.0.%desc: PCI-ISA bridge > > > > oops! have i left something out of kernel or kld load? >=20 > No, Michael's example was for old-bridge which is depreciated. You had > the config right. >=20 Thanks Andrew! In reading http://www.freebsd.org/cgi/man.cgi?query=3Dif_bridge&sektion=3D4 it = looks like either device if_bridge or if_bridge_load=3D"YES" in loader.conf is all that's needed. For testing purposes, you might want to disable the filtering configuration with: sysctl net.link.bridge.pfil_member=3D0 sysctl net.link.bridge.pfil_bridge=3D0 Regards, Mike From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 23:43:52 2007 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 191CC16A417; Thu, 27 Sep 2007 23:43:52 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E13A813C45A; Thu, 27 Sep 2007 23:43:51 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l8RNhoQj007259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 16:43:51 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46FC4036.3040604@errno.com> Date: Thu, 27 Sep 2007 16:43:50 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Randy Bush References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> In-Reply-To: <46FC25C3.8030703@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Net , Andrew Thompson Subject: Re: bridging ath 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, 27 Sep 2007 23:43:52 -0000 Randy Bush wrote: > Andrew Thompson wrote: > >> On Wed, Sep 26, 2007 at 04:07:00PM -1000, Randy Bush wrote: >> >>> current i386 thinkpad t41 >>> >>> ifconfig_lo0="inet 127.0.0.1/8" >>> cloned_interfaces="bridge0" >>> ifconfig_bridge0="inet 192.168.0.3/24 addm em0 addm ath0 up" >>> ifconfig_em0="up" >>> ifconfig_ath0="ssid rgnet up" >>> defaultrouter="192.168.0.1" >>> >>> with ether plugged in, i can ping it. unplug ether and no ping over >>> ath0. other hosts are on same ssid and working. >>> >> I will try to reproduce this in the weekend. Just to make sure, you are >> pinging 192.168.0.3 from a remote wireless node connected to ath0, and >> unplugging em0 causes this to fail? >> > > connect both wireless and ether. it is pingable. disconnect ether. no > can ping. > > reduce to > ifconfig_ath0="inet 192.168.0.3/24 ssid rgnet up" > with no em0, bridge, ... and it is pingable. > Be sure apbridge is enabled so the 802.11 layer does intra-bss bridging; otherwise traffic must be fwd'd by a bridge component (should be on by default). Also you can use tcpdump to check traffic on each interface to isolate the issue. Sam From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 23:58:37 2007 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 6BF4816A417; Thu, 27 Sep 2007 23:58:37 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 549AB13C44B; Thu, 27 Sep 2007 23:58:37 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ib3FO-000GqQ-J1; Thu, 27 Sep 2007 23:58:22 +0000 Message-ID: <46FC439B.60506@psg.com> Date: Thu, 27 Sep 2007 13:58:19 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Michael K. Smith - Adhost" References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <17838240D9A5544AAA5FF95F8D52031602895DA5@ad-exh01.adhost.lan> <46FC3A8E.20307@psg.com> <20070927232144.GA43056@heff.fud.org.nz> <17838240D9A5544AAA5FF95F8D52031602895DBB@ad-exh01.adhost.lan> In-Reply-To: <17838240D9A5544AAA5FF95F8D52031602895DBB@ad-exh01.adhost.lan> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Andrew Thompson Subject: Re: bridging ath 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, 27 Sep 2007 23:58:37 -0000 > device if_bridge > or > if_bridge_load="YES" in loader.conf is all that's needed. if_bridge.ko is automagically loaded, no extra charge > For testing purposes, you might want to disable the filtering > configuration with: > sysctl net.link.bridge.pfil_member=0 > sysctl net.link.bridge.pfil_bridge=0 no help. but thanks. i am sure i am doing something stupid. randy From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 00:35:49 2007 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 B023F16A41A; Fri, 28 Sep 2007 00:35:49 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id A2A1113C4A5; Fri, 28 Sep 2007 00:35:49 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ib3pb-000HjM-U4; Fri, 28 Sep 2007 00:35:48 +0000 Message-ID: <46FC4C5F.8000004@psg.com> Date: Thu, 27 Sep 2007 14:35:43 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Leffler References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <46FC4036.3040604@errno.com> In-Reply-To: <46FC4036.3040604@errno.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Andrew Thompson Subject: Re: bridging ath 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, 28 Sep 2007 00:35:49 -0000 > Be sure apbridge is enabled not running in hostap mode, not an access point > you can use tcpdump to check traffic on each interface to isolate the issue. the ath interface 00:28:26.699253 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 218, length 64 00:28:26.699295 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 218, length 64 00:28:27.710208 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 219, length 64 00:28:27.710220 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 219, length 64 00:28:27.848283 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:28.718895 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 220, length 64 00:28:28.718904 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 220, length 64 00:28:28.974345 arp who-has roam.psg.com tell dhcp1.psg.com 00:28:29.597966 arp who-has ap0.h.psg.com tell hawi0.psg.com 00:28:29.774936 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 221, length 64 00:28:29.774950 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 221, length 64 00:28:29.896361 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:30.407955 arp who-has roam.psg.com tell dhcp1.psg.com 00:28:30.746231 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 222, length 64 00:28:30.746241 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 222, length 64 00:28:31.721041 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 223, length 64 00:28:31.721050 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 223, length 64 00:28:31.841701 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:31.943904 arp who-has roam.psg.com tell dhcp1.psg.com 00:28:32.752380 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 224, length 64 00:28:32.752389 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 224, length 64 00:28:33.480206 IP dhcp1.psg.com.netbios-ns > 192.168.0.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 00:28:33.481099 arp who-has 192.168.0.100 tell dhcp1.psg.com 00:28:33.684970 IP dhcp1.psg.com.netbios-ns > 192.168.0.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 00:28:33.758003 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 225, length 64 00:28:33.758015 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 225, length 64 00:28:33.889567 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:34.773510 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 226, length 64 00:28:34.773518 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 226, length 64 00:28:35.794872 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 227, length 64 00:28:35.794880 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 227, length 64 00:28:35.843019 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:36.756975 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 228, length 64 00:28:36.756984 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 228, length 64 00:28:37.775456 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 229, length 64 00:28:37.775465 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 229, length 64 00:28:37.883867 STP 802.1d, Config, Flags [none], bridge-id 8000.00:15:f2:7a:8e:97.8001, length 43 00:28:38.805287 IP dhcp1.psg.com > hawi0.psg.com: ICMP echo request, id 56334, seq 230, length 64 00:28:38.805296 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 230, length 64 the bridge interface 00:29:14.161340 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 265, length 64 00:29:15.165895 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 266, length 64 00:29:16.150938 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 267, length 64 00:29:17.152661 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 268, length 64 00:29:18.167323 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 269, length 64 00:29:19.177189 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 270, length 64 00:29:20.195071 IP hawi0.psg.com > dhcp1.psg.com: ICMP echo reply, id 56334, seq 271, length 64 randy From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 01:17:04 2007 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 3030316A418; Fri, 28 Sep 2007 01:17:04 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0B25513C457; Fri, 28 Sep 2007 01:17:03 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l8S1H2OB007893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 18:17:03 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46FC560E.1070301@errno.com> Date: Thu, 27 Sep 2007 18:17:02 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Randy Bush References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <46FC4036.3040604@errno.com> <46FC4C5F.8000004@psg.com> In-Reply-To: <46FC4C5F.8000004@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Net , Andrew Thompson Subject: Re: bridging ath 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, 28 Sep 2007 01:17:04 -0000 Randy Bush wrote: >> Be sure apbridge is enabled >> > > not running in hostap mode, not an access point > You can only bridge a wireless card in hostap mode. Sam From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 01:18:42 2007 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 D842016A41B; Fri, 28 Sep 2007 01:18:42 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id D4BB113C478; Fri, 28 Sep 2007 01:18:42 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ib4V8-000ITS-E2; Fri, 28 Sep 2007 01:18:42 +0000 Message-ID: <46FC566F.1080102@psg.com> Date: Thu, 27 Sep 2007 15:18:39 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Leffler References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <46FC4036.3040604@errno.com> <46FC4C5F.8000004@psg.com> <46FC560E.1070301@errno.com> In-Reply-To: <46FC560E.1070301@errno.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Andrew Thompson Subject: Re: bridging ath 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, 28 Sep 2007 01:18:42 -0000 > You can only bridge a wireless card in hostap mode. after your earlier comment, i tried that too :( it's not that i think i have not done something stupid. i just can't find it :) randy From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 01:22:19 2007 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 E8EFA16A46B; Fri, 28 Sep 2007 01:22:19 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id D785813C48D; Fri, 28 Sep 2007 01:22:19 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id l8S1MJFV007934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 18:22:19 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <46FC574B.1070507@errno.com> Date: Thu, 27 Sep 2007 18:22:19 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Randy Bush References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <46FC4036.3040604@errno.com> <46FC4C5F.8000004@psg.com> <46FC560E.1070301@errno.com> In-Reply-To: <46FC560E.1070301@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Net , Andrew Thompson Subject: Re: bridging ath 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, 28 Sep 2007 01:22:20 -0000 Sam Leffler wrote: > Randy Bush wrote: >>> Be sure apbridge is enabled >>> >> >> not running in hostap mode, not an access point >> > > You can only bridge a wireless card in hostap mode. Sorry, engage brain before opening mouth. I don't know what you're trying to do but you're looking in the wrong place and I suspect you're confused about some stuff. When you attach your wired nic to a bridge and and turn the bridge on the nic gets set in promiscuous mode. This is likely why you can ping the other wireless station through the wired nic. To ping the wireless station through your AP then AP must either fwd the packet directly or bridge it using some mechanism. You cannot bridge a wireless interface unless it's operating as an ap. Either way it's an issue at the AP. You can diagnose all this with tcpdump. Sam From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 05:12:18 2007 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 A15D416A419 for ; Fri, 28 Sep 2007 05:12:18 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 29E9B13C44B for ; Fri, 28 Sep 2007 05:12:17 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 34089473; Fri, 28 Sep 2007 08:12:17 +0300 Message-ID: <46FC8D30.7030708@FreeBSD.org> Date: Fri, 28 Sep 2007 08:12:16 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: wel@skm.net.ua References: <20070731120013.285EE16A4E1@hub.freebsd.org> <1190942604.00806258.1190932201@10.7.7.3> In-Reply-To: <1190942604.00806258.1190932201@10.7.7.3> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: ng_nat+ng_netflow+mpd4 - ? 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, 28 Sep 2007 05:12:18 -0000 wel@skm.net.ua пишет: > I want to count ALL traffic pass trought my gateway, but tool's such as > softflowd I don't want to use because there is already ng_netflow and I > want use nat from netgraph, may I :)? > options NETGRAPH ... > options NETGRAPH_TCPMSS You do not need to build it statically. All of them can be loaded as modules. > flow-capture + ng_netflow + this script working fine > #ngctl -f /ng_netflow > #cat /ng_netflow > mkpeer rl1: tee lower left > name rl1:lower tee0 > connect rl1: rl1:lower upper right > mkpeer tee0: one2many left2right many0 > name tee0:left2right one2many0 > connect tee0: one2many0: right2left many1 > mkpeer one2many0: netflow one iface0 > name one2many0:one netflow > mkpeer netflow: ksocket export inet/dgram/udp > msg netflow: setifindex { iface=0 index=2 } > msg netflow:export connect inet/127.0.0.1:2222 It looks overcomplicated to me. There is no need to use tee and one2many there as ng_netflow supports passing traffic via it and supports multiple interfaces. It can be connected just to the interface upper/lower hooks. If you REALLY wish to count both directions on ALL interfaces (and have double traffic accounting) you could connect netflow node twice in different directions. > /sbin/ipfw add 110 ngtee 30 ip from any to any out via ng* > /sbin/ipfw add 111 ngtee 30 ip from any to any in via ng* If you are using mpd4 to operate ng inetrfaces then you can just use it's internal ng_netflow support. > /sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to > $EXT_IP out via rl1 > /sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not > $LOCAL_NET in via rl1 Recheck twice IP in those rules. What you mean by them? -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 16:23:01 2007 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 8555116A421 for ; Fri, 28 Sep 2007 16:23:01 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id E354E13C44B for ; Fri, 28 Sep 2007 16:23:00 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id l8SG3BeV008351; Fri, 28 Sep 2007 20:03:18 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Fri, 28 Sep 2007 20:03:11 +0400 (MSD) From: Maxim Konovalov To: Igor Sysoev In-Reply-To: <20070816142431.GO57126@rambler-co.ru> Message-ID: <20070928200241.F77827@mp2.macomnet.net> References: <20070816142431.GO57126@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: syncookie in 6.x and 7.x 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, 28 Sep 2007 16:23:01 -0000 On Thu, 16 Aug 2007, 18:24+0400, Igor Sysoev wrote: > During testing 7.0-CURRENT I have found that it always sends syncookies > while on early FreeBSD versions "netstat -s -p tcp" always shows: > > 0 cookies sent > 0 cookies received > > I have looked sources and found that in early versions the sent counter > was simply not incremented at all. The patch attached. > > After the patch has been applied I have found that 6 always sends > syncookies too, however, 6 unlike 7 never receives them. Why ? > Mine does: $ netstat -sp tcp | grep cook 51588 cookies sent 25 cookies received $ uname -r 6.2-STABLE -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 16:26:14 2007 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 29E3D16A469; Fri, 28 Sep 2007 16:26:14 +0000 (UTC) (envelope-from Muhammad.Shafiq@neterion.com) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by mx1.freebsd.org (Postfix) with ESMTP id B5AA713C4BF; Fri, 28 Sep 2007 16:26:13 +0000 (UTC) (envelope-from Muhammad.Shafiq@neterion.com) X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Sep 2007 12:14:07 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD770245002D@nekter> In-Reply-To: <2a41acea0709241028q2503f12fp86eea2d32ac10aa7@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TX Multiqueue? Thread-Index: Acf+0Hb5oO1MMOqvQp+6JbpC3kH3PQDFbzCA References: <2a41acea0709221656n4aa62776y488c7f2da262c9f6@mail.gmail.com><46F614F2.4050402@freebsd.org> <2a41acea0709241028q2503f12fp86eea2d32ac10aa7@mail.gmail.com> From: "Muhammad Shafiq" To: "Jack Vogel" , "Kip Macy" Cc: Darren Reed , freebsd-net@freebsd.org, FreeBSD Current Subject: RE: TX Multiqueue? 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, 28 Sep 2007 16:26:14 -0000 -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Jack Vogel Sent: Monday, September 24, 2007 10:28 AM To: Kip Macy Cc: Darren Reed; freebsd-net@freebsd.org; FreeBSD Current Subject: Re: TX Multiqueue? On 9/23/07, Kip Macy wrote: > On 9/23/07, Darren Reed wrote: > > Kip Macy wrote: > > > My ethng branch supports multiple rx and tx queues. > > > > > > -Kip > > > > > > > What are your plans for how we use/manage/interact with the mutiple > > rx/tx queues? > > The rx hardware queue is determined by the hardware. Different > hardware allows for different policies. I just use the stock rss_hash > of a crc32 of the 4-tuple in cxgb. I've added a field to the pkthdr > which cxgb uses the least significant bits of to determine which > outbound queue to use. Its up to the upper layers to determine how to > set those bits. One of the changes that is required to take advantaged > of this is moving the queues into the driver. I've added a new > if_start function to ifnet to take advantage of this. I also have a > normal if_start function for backward compatibility. Yes, the queues in Oplin and Zoar are also a hardware feature, not just some software infrastructure. There are a number of different ways that it can be configured. I did not have some settled notion of how things should be managed but I would rather not have it be something done under the covers in the driver, a configurable stack option seems better to me. This needs to be done right or it will just be a hack, I don't know who the right parties are, it should not be just a one-person decision, those with a stake in this sort of thing should all be involved. [Muhammad Shafiq]=20 Based upon our experience, form other OS(s), the HW TX/RX queues are quite helpful in reducing CPU utilization (in MP machines). For example, XFRAME-I/II TX/RX queues, originally intended for "I/O Virtualization", can be affiliated to specific CPU(s); the resulting locality of reference improves cache hits and reduces lock contention, if any. The HW details of this mechanism can be found at the following link:=20 http://www.neterion.com/support/xframe_developer.html We would prefer to have a configurable, generic, mechanism to exploit the multiple TX/RX queues, now supported by NIC vendors. If possible, the mechanism should be extendable to fit into specific capability/requirement of HW vendors.=20 =20 Cheers, Jack _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 17:28:38 2007 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 3B1AC16A421; Fri, 28 Sep 2007 17:28:38 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id C1BEC13C45D; Fri, 28 Sep 2007 17:28:37 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 28 Sep 2007 09:54:08 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id l8SGxbHd072054; Fri, 28 Sep 2007 09:59:37 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id l8SGxbBv072053; Fri, 28 Sep 2007 09:59:37 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200709281659.l8SGxbBv072053@ambrisko.com> In-Reply-To: To: Ivan Voras Date: Fri, 28 Sep 2007 09:59:37 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Panic in rt_check 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, 28 Sep 2007 17:28:38 -0000 Ivan Voras writes: -- Start of PGP signed section. [ Charset UTF-8 unsupported, converting... ] | Hi, | | I have a machine that panics almost daily in route.c, in rt_check(). | This panic has been reported by several users, including Marcel | Moolenaar for a machine in freebsd.org. | | The problem is present in both 6-STABLE and 7-CURRENT, and apparently it | manifests on SMP machines, both i386 and AMD64. | | The panic backtrace looks like this: | | panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305 | cpuid = 1 | KDB: stack backtrace: | db_trace_self_wrapper(c091bcf0,e38b690c,c0659fc1,c093f3cf,1,...) at | db_trace_self_wrapper+0x26 | kdb_backtrace(c093f3cf,1,c0917de2,e38b6918,1,...) at kdb_backtrace+0x29 | panic(c0917de2,c0925d40,519,0,0,...) at panic+0x111 | _mtx_lock_flags(c5d333a8,0,c0925d40,519,0,...) at _mtx_lock_flags+0x59 | rt_check(e38b6970,e38b698c,c55b7d10,0,0,...) at rt_check+0x11e | arpresolve(c4e27000,c5d33d98,c50dbe00,c55b7d10,e38b69a6,...) at | arpresolve+0xaf | ether_output(c4e27000,c50dbe00,c55b7d10,c5d33d98,ccf8b348,...) at | ether_output+0x7e | ip_output(c50dbe00,0,e38b6a1c,0,0,...) at ip_output+0xa09 | tcp_output(ccefbac8,0,c0929785,91d,0,...) at tcp_output+0x1463 | tcp_do_segment(ccefbac8,28,0,1dd,901f,...) at tcp_do_segment+0x1c97 | tcp_input(c6095100,14,c4ea3c00,1,0,...) at tcp_input+0xd5e | ip_input(c6095100,0,c09258bd,8c,c09efc38,...) at ip_input+0x662 | netisr_processqueue(e38b6cc4,c064df85,c09eb940,1,c4d03480,...) at | netisr_processqueue+0x98 | swi_net(0,0,c0915aee,471,c4d0bd64,...) at swi_net+0xdb | ithread_loop(c4d0c270,e38b6d38,c0915862,315,c4d56558,...) at | ithread_loop+0x1c5 | fork_exit(c063e2d0,c4d0c270,e38b6d38) at fork_exit+0xc5 | fork_trampoline() at fork_trampoline+0x8 | | ... | | #0 doadump () at pcpu.h:195 | 195 pcpu.h: No such file or directory. | in pcpu.h | (kgdb) bt | #0 doadump () at pcpu.h:195 | #1 0xc0659d2c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 | #2 0xc0659ff0 in panic (fmt=Variable "fmt" is not available. | ) at /usr/src/sys/kern/kern_shutdown.c:563 | #3 0xc064e699 in _mtx_lock_flags (m=0x0, opts=0, file=0xc0925d40 | "/usr/src/sys/net/route.c", line=1305) | at /usr/src/sys/kern/kern_mutex.c:178 | #4 0xc06fe28e in rt_check (lrt=0xe38b6970, lrt0=0xe38b698c, | dst=0xc55b7d10) at /usr/src/sys/net/route.c:1305 | #5 0xc070282f in arpresolve (ifp=0xc4e27000, rt0=0xc5d33d98, | m=0xc50dbe00, dst=0xc55b7d10, desten=0xe38b69a6 "") | at /usr/src/sys/netinet/if_ether.c:373 | #6 0xc06f019e in ether_output (ifp=0xc4e27000, m=0xc50dbe00, | dst=0xc55b7d10, rt0=0xc5d33d98) at /usr/src/sys/net/if_ethersubr.c:175 | #7 0xc07127a9 in ip_output (m=0xc50dbe00, opt=0x0, ro=0xe38b6a1c, | flags=Variable "flags" is not available. | ) at /usr/src/sys/netinet/ip_output.c:547 | #8 0xc076d6e3 in tcp_output (tp=0xccefbac8) at | /usr/src/sys/netinet/tcp_output.c:1125 | #9 0xc076ab87 in tcp_do_segment (m=0xc6095100, th=0xc6095158, | so=0xccdb67bc, tp=0xccefbac8, drop_hdrlen=40, tlen=0) | at /usr/src/sys/netinet/tcp_input.c:2345 | #10 0xc076bb0e in tcp_input (m=0xc6095100, off0=20) at | /usr/src/sys/netinet/tcp_input.c:843 | #11 0xc0710c42 in ip_input (m=0xc6095100) at | /usr/src/sys/netinet/ip_input.c:663 | #12 0xc06f9148 in netisr_processqueue (ni=0xc09efc38) at | /usr/src/sys/net/netisr.c:143 | #13 0xc06f925b in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:256 | #14 0xc063e495 in ithread_loop (arg=0xc4d0c270) at | /usr/src/sys/kern/kern_intr.c:1036 | #15 0xc063b845 in fork_exit (callout=0xc063e2d0 , | arg=0xc4d0c270, frame=0xe38b6d38) at /usr/src/sys/kern/kern_fork.c:797 | #16 0xc0896f80 in fork_trampoline () at | /usr/src/sys/i386/i386/exception.s:205 | | I've been trying to solve this with Craig Rodrigues, and I've tried | several patches, without success. The backtrace above happens on the | following code from net/route.c: | | 1299 /* XXX BSD/OS checks dst->sa_family != AF_NS */ | 1300 if (rt->rt_flags & RTF_GATEWAY) { | 1301 struct rtentry *temp_rt_gwroute = rt->rt_gwroute; | 1302 if (temp_rt_gwroute == NULL) | 1303 goto lookup; | 1304 rt = rt->rt_gwroute; | 1305 RT_LOCK(rt); /* NB: gwroute */ | 1306 if(rt0->rt_flags & 0x80000000U){ | 1307 /*This rt is under process...*/ | 1308 RT_UNLOCK(rt); | 1309 RT_UNLOCK(rt0); | 1310 goto try_again; | 1311 } | 1312 if ((rt->rt_flags & RTF_UP) == 0) { | 1313 rt0->rt_flags |= 0x80000000U; | 1314 RTFREE_LOCKED(rt); /* unlock gwroute */ | 1315 rt = rt0; | 1316 lookup: | 1317 RT_UNLOCK(rt0); | 1318 rt = rtalloc1(rt->rt_gateway, 1, 0UL); | 1319 if (rt == rt0) { | 1320 rt0->rt_gwroute = NULL; | 1321 RT_REMREF(rt0); | 1322 RT_UNLOCK(rt0); | 1323 return (ENETUNREACH); | 1324 } | 1325 RT_LOCK(rt0); | 1326 rt0->rt_gwroute = rt; | 1327 rt0->rt_flags &= (~0x80000000U); | 1328 if (rt == NULL) { | 1329 RT_UNLOCK(rt0); | 1330 return (EHOSTUNREACH); | 1331 } | 1332 } | 1333 RT_UNLOCK(rt0); | 1334 } | | This code contains several patches we tried for workarounds, without any | success. The panic is always in RT_LOCK(rt) line: sometimes it's NULL | pointer reference, sometimes it's an operation on destroyed mutex. | | This is a critical problem for me, but I believe it's also critical for | other users. | | Does anyone have more ideas about how to solve this problem? Something along the lines of: Index: sys/net/route.c =================================================================== RCS file: /usr/local/cvsroot/freebsd/src/sys/net/route.c,v retrieving revision 1.109.2.3 diff -u -p -r1.109.2.3 route.c --- sys/net/route.c 25 Feb 2007 05:36:25 -0000 1.109.2.3 +++ sys/net/route.c 27 Sep 2007 02:03:05 -0000 @@ -615,7 +615,8 @@ rtexpunge(struct rtentry *rt) * we held its last reference. */ if (rt->rt_gwroute) { - RTFREE(rt->rt_gwroute); + if (rt->rt_gwroute->rt_refcnt) + RTFREE(rt->rt_gwroute); rt->rt_gwroute = NULL; } @@ -701,7 +702,8 @@ rtrequest1(int req, struct rt_addrinfo * * we held its last reference. */ if (rt->rt_gwroute) { - RTFREE(rt->rt_gwroute); + if (rt->rt_gwroute->rt_refcnt) + RTFREE(rt->rt_gwroute); rt->rt_gwroute = NULL; } @@ -822,9 +824,11 @@ rtrequest1(int req, struct rt_addrinfo * */ if (rn == NULL) { if (rt->rt_gwroute) - RTFREE(rt->rt_gwroute); + if (rt->rt_gwroute->rt_refcnt) + RTFREE(rt->rt_gwroute); if (rt->rt_ifa) - IFAFREE(rt->rt_ifa); + if (rt->rt_ifa->ifa_refcnt) + IFAFREE(rt->rt_ifa); Free(rt_key(rt)); RT_LOCK_DESTROY(rt); uma_zfree(rtzone, rt); @@ -1039,7 +1043,8 @@ rt_setgate(struct rtentry *rt, struct so if (rt->rt_gwroute == gwrt) { RT_REMREF(rt->rt_gwroute); } else - RTFREE(rt->rt_gwroute); + if (rt->rt_gwroute->rt_refcnt) + RTFREE(rt->rt_gwroute); } if ((rt->rt_gwroute = gwrt) != NULL) might help. The problem here was a stale gateway route going away in flight. You might try to check the refcnt of the route. This is common to -current and -stable. In -stable you can "fix" it by turning off mpnetsafe. Your panic looks different then this but it might raise some more questions that could lead to a solution. I'd be looking at rt_gwroute->rt_refcnt. Note that I did get a panic before like yours until I settled on the above patch for another issue. Then that problem and my others didn't occur any more (well in a 6.1 I had to merge in jhb's bpf race fix). So maybe you might want to revert other patches and try just this one. You should be able to poke around the route structure via kgdb. On a cool note I was using kgdb over IPMI serial over lan to the remote host and I could "flip" between various remote hosts :-) Doug A. From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 17:40:44 2007 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 D148516A420 for ; Fri, 28 Sep 2007 17:40:44 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 3B48A13C4B6 for ; Fri, 28 Sep 2007 17:40:43 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id l8SHegg5026697; Fri, 28 Sep 2007 21:40:43 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Fri, 28 Sep 2007 21:40:42 +0400 (MSD) From: Maxim Konovalov To: Igor Sysoev In-Reply-To: <20070816142431.GO57126@rambler-co.ru> Message-ID: <20070928214020.Q77827@mp2.macomnet.net> References: <20070816142431.GO57126@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: syncookie in 6.x and 7.x 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, 28 Sep 2007 17:40:44 -0000 On Thu, 16 Aug 2007, 18:24+0400, Igor Sysoev wrote: > During testing 7.0-CURRENT I have found that it always sends syncookies > while on early FreeBSD versions "netstat -s -p tcp" always shows: > > 0 cookies sent > 0 cookies received > > I have looked sources and found that in early versions the sent counter > was simply not incremented at all. The patch attached. > [...] The patch has beed committed to RELENG_6. Thanks! -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Sat Sep 29 07:25:20 2007 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 9B0FF16A418 for ; Sat, 29 Sep 2007 07:25:20 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 71AD113C467 for ; Sat, 29 Sep 2007 07:25:20 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so3893825waf for ; Sat, 29 Sep 2007 00:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:cc:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; bh=D4uK7gvJg+jBi0LDm8LmDzKmfR7gChWfUymNtD/AZVM=; b=fX41Zi0R3Gul1pzUqIHIxaAn3trEMtkF+faRkdfAzs4A3vIwXHFWPsVfC/HwhRckOpWUZLF7YUbmfn2FsvTzeSHaNeXP05rzFDwlPgLjtP6ZgqtXmCyh6fiVxI0sXf7aPsWOTO0wkaY0cfGhP8OBFZwetg6VkMcc1jJFP18VQ7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:cc:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; b=fmvBt906HcKpzh3LC77r9p95a2vEkpOZID9xO9XDu5YoL9r2Hud5HPI6rFIIC2DrQFjLMw6ct9EUIj56cTQtoqMbztv34SMw+gvlJ5Fti9rAhpi3ivikGouJbZKIMCK6qzybeySFVZa7/mg5PEY6uXjaNFkTMCm/nhKl91pnezc= Received: by 10.114.112.1 with SMTP id k1mr1260866wac.1191049222155; Sat, 29 Sep 2007 00:00:22 -0700 (PDT) Received: from ?127.0.0.1? ( [218.94.128.114]) by mx.google.com with ESMTPS id j7sm7033613wah.2007.09.29.00.00.19 (version=SSLv3 cipher=RC4-MD5); Sat, 29 Sep 2007 00:00:21 -0700 (PDT) Date: Sat, 29 Sep 2007 15:00:12 +0800 From: Deng XueFeng To: freebsd-multimedia@freebsd.org Message-Id: <20070929144813.06FD.DENGXF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.31 [CN] Cc: freebsd-net@freebsd.org Subject: Missey Streaming Server 3.9.4 Released. 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, 29 Sep 2007 07:25:20 -0000 Hi, I am happy to announce that MSS 3.9.4 has been released. Please Download from http://mss.microvideo.cn/ then read docs/INSTALL. :-) What is MSS? MSS is a hign performance Streaming Server which run on FreeBSD and compatible with windows 2003 media service. It implement most of WMS's feature. Requirements Operating System: FreeBSD 6.x Hardware: x86 compatible CPU, and support SSE. Depend Package: libiconv Features 1. Storage Service Support Saving streaming data from the encoder. Suport three method limit: size limit, time limit, Punctuality time limit. Support specified filename format. item include base name, group name, year, month of year, day of month, hours, minutes, seconds, each item can be used more than once, also can add subdir '/' Support specified save type: 1. force save, 2. force no save, 3. encoder specified custom save. Support more than one live streaming upload, max limited to 128. Support forward streaming data to streaming service while saving, which make user can view the live streaming with no delay Support specified ip(if server have more than one IP) and port 2. Streaming Service Support normal streaming service. Support http / rtsp (rtsp disabled in 3.x temporary) streaming protocol Support fast / normal / slow playing. Support server side playlist, similary to smil. Support playlist session Support faststart, the faststart bandwidth and duration can be specefied. Support fastcache, the fastcache speed can be specefied. Support cacheproxy, fastcache and cacheproxy can make user do not redownload the pre-recorded streaming data Support specified expire time when enable fastcache or cacheproxy. Support speficed video message instead the HEX code when meet error. Support specified living streaming delay time. Support specified ip(if server have more than one IP) and port Support specified LRU cache size for prerecorded files. Support specified io and session timeout. Support specified worker thread, depends on your server side performance need. Support user specified plugin. Support realtime pulling a streaming from another server and set it as a live streaming. which can reduce the the bandwidth over two network. Support specified idle time for a pulling streaming. Support user stop the pulling streaming via web. 3. Admin Service Support start / stop / check status about storage services, streaming services one or both via web. Support get all service's configure file via web. Support get current living streaming's (one or both in any type live streaming) name via web. Support set various services configure via web. Support get current various services' stats via web. Support get file list about the saved data, or make a file query with specified key. 4. Other Support specified max live streaming can be upload to mss. Support specified max client at one time. Support specified max bandwidth that can be use. Support I18N charset. -- Deng XueFeng From owner-freebsd-net@FreeBSD.ORG Sat Sep 29 08:01:12 2007 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 85D7B16A419; Sat, 29 Sep 2007 08:01:12 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8E413C459; Sat, 29 Sep 2007 08:01:12 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbXGB-000Lp6-B7; Sat, 29 Sep 2007 08:01:11 +0000 Message-ID: <46FE0640.3030102@psg.com> Date: Fri, 28 Sep 2007 22:01:04 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Leffler References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <46FC4036.3040604@errno.com> <46FC4C5F.8000004@psg.com> <46FC560E.1070301@errno.com> <46FC574B.1070507@errno.com> In-Reply-To: <46FC574B.1070507@errno.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Andrew Thompson Subject: Re: bridging ath 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, 29 Sep 2007 08:01:12 -0000 > I don't know what you're trying to do no surprise. i rarely do. :) > When you attach your wired nic to a bridge and and turn the bridge on > the nic gets set in promiscuous mode. This is likely why you can > ping the other wireless station through the wired nic. To ping the > wireless station through your AP then AP must either fwd the packet > directly or bridge it using some mechanism. You cannot bridge a > wireless interface unless it's operating as an ap. Either way it's > an issue at the AP. sokeris running current application is a remote (via wireless) ether switch wireless client, bridged to the ethers a few devices on the ethers such as desktop, printer, ... it is also a local samba etc, and ipsecs to the AP's net so it does not want to be an AP but it does want to bridge. randy From owner-freebsd-net@FreeBSD.ORG Sat Sep 29 09:30:14 2007 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 34E0216A417 for ; Sat, 29 Sep 2007 09:30:14 +0000 (UTC) (envelope-from wel@skm.net.ua) Received: from mail.skm.net.ua (skm.sat.poltava.ua [193.109.248.245]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABEF13C45D for ; Sat, 29 Sep 2007 09:30:12 +0000 (UTC) (envelope-from wel@skm.net.ua) Received: from [193.238.152.25] by mail.skm.net.ua with esmtpa (Exim 4.63) (envelope-from ) id 1IbbQi-0002z1-Hg for freebsd-net@freebsd.org; Sat, 29 Sep 2007 12:28:21 +0000 From: "wel@skm.net.ua" To: freebsd-net@freebsd.org In-Reply-To: <20070928120019.3F59616A4C8@hub.freebsd.org> References: <20070928120019.3F59616A4C8@hub.freebsd.org> Content-Type: text/plain; charset=UTF-8 Date: Sat, 29 Sep 2007 12:27:45 +0300 Message-Id: <1191058065.10918.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 Content-Transfer-Encoding: quoted-printable Subject: Re: ng_nat+ng_netflow+mpd4 - ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wel@skm.net.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2007 09:30:14 -0000 =D0=92 =D0=9F=D1=82=D0=BD, 28/09/2007 =D0=B2 08:12 +0300, Alexander Motin = =D0=BF=D0=B8=D1=88=D0=B5=D1=82:=20 > wel@skm.net.ua =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > I want to count ALL traffic pass trought my gateway, but tool's such as > > softflowd I don't want to use because there is already ng_netflow and I > > want use nat from netgraph, may I :)? >=20 > > options NETGRAPH > ... > > options NETGRAPH_TCPMSS >=20 > You do not need to build it statically. All of them can be loaded as=20 > modules. ok=20 > > flow-capture + ng_netflow + this script working fine=20 > > #ngctl -f /ng_netflow > > #cat /ng_netflow > > mkpeer rl1: tee lower left > > name rl1:lower tee0 > > connect rl1: rl1:lower upper right > > mkpeer tee0: one2many left2right many0 > > name tee0:left2right one2many0 > > connect tee0: one2many0: right2left many1 > > mkpeer one2many0: netflow one iface0 > > name one2many0:one netflow > > mkpeer netflow: ksocket export inet/dgram/udp > > msg netflow: setifindex { iface=3D0 index=3D2 } > > msg netflow:export connect inet/127.0.0.1:2222 >=20 > It looks overcomplicated to me. There is no need to use tee and one2many=20 > there as ng_netflow supports passing traffic via it and supports=20 > multiple interfaces. It can be connected just to the interface=20 > upper/lower hooks. If you REALLY wish to count both directions on ALL=20 > interfaces (and have double traffic accounting) you could connect=20 > netflow node twice in different directions. I use example. Can you help me to build script to run ng_nat+ng_netflow? > > /sbin/ipfw add 110 ngtee 30 ip from any to any out via ng* > > /sbin/ipfw add 111 ngtee 30 ip from any to any in via ng* >=20 > If you are using mpd4 to operate ng inetrfaces then you can just use=20 > it's internal ng_netflow support. >=20 > > /sbin/ipfw add 200 netgraph 71 all from not $LOCAL_NET to > > $EXT_IP out via rl1 > > /sbin/ipfw add 201 netgraph 70 all from $LOCAL_NET to not > > $LOCAL_NET in via rl1 =20 >=20 > Recheck twice IP in those rules. What you mean by them? When I read man ng_nat theare is exaple, I use it to build script. There is My network: isp-network(192.168.128.0) <<-getway Internet(192.168.100.1) --- 192.168.100.99|FreeBSD6.2|10.11.2.1 -->>local network 10.11.2.0/24 I use it to build only ng_nat: # cat /usr/local/etc/rc.d/ng_nat.sh=20 #!/bin/sh=20 ngctl=3D"/usr/sbin/ngctl "=20 ipfw=3D"/sbin/ipfw "=20 ifconfig=3D"/sbin/ifconfig "=20 tcpdumt=3D"/usr/sbin/tcpdump"=20 nat_ip=3D"192.168.100.99"=20 $ngctl mkpeer ipfw: nat 60 out=20 $ngctl name ipfw:60 nat=20 $ngctl connect ipfw: nat: 61 in=20 $ngctl msg nat: setaliasaddr $nat_ip=20 $ipfw add 10 skipto 65400 ip from 192.168.100.1 to me=20 $ipfw add 300 netgraph 61 all from any to me in via rl1=20 $ipfw add 400 netgraph 60 all from 10.11.2.0/24 to not me out via rl1=20 $ipfw add 500 fwd 192.168.100.1 all from me to any=20 $ipfw delete 10=20 sleep 60 $ngctl list >/ng_nat/ngctllist=20 $ipfw show>/ng_nat/ipfwshow=20 $ifconfig >/ng_nat/ifconfig=20 $ipfw -f flush # pfctl -d=20 pfctl: pf not enabled #cat {ngctl list >}/ng_nat/ngctllist There are 5 total nodes:=20 Name: ngctl1095 Type: socket ID: 00000009 Num hooks: 0=20 Name: nat Type: nat ID: 00000005 Num hooks: 2=20 Name: ipfw Type: ipfw ID: 00000003 Num hooks: 2=20 Name: rl1 Type: ether ID: 00000002 Num hooks: 0=20 Name: rl0 Type: ether ID: 00000001 Num hooks: 0 #cat {ipfw show>}/ng_nat/ipfwshow 00300 202 12523 netgraph 61 ip from any to me in via rl1=20 00400 161 8057 netgraph 60 ip from 10.11.2.0/24 to not me out via rl1=20 00500 174 8963 fwd 192.168.100.1 ip from me to any=20 65400 504 26548 allow ip from any to any=20 65535 2 56 allow ip from any to any #cat {ifconfig >}/ng_nat/ifconfig rl0: flags=3D8843 mtu 1500=20 options=3D8=20 inet 10.11.2.1 netmask 0xffffff00 broadcast 10.11.2.255=20 ether 00:a1:b0:01:05:71=20 media: Ethernet autoselect (100baseTX )=20 status: active=20 rl1: flags=3D8843 mtu 1500=20 options=3D8=20 inet 192.168.100.99 netmask 0xffffff00 broadcast 192.168.100.255=20 ether 00:01:29:76:0f:cd=20 media: Ethernet autoselect (100baseTX )=20 status: active=20 plip0: flags=3D108810 mtu 1500=20 pfsync0: flags=3D0<> mtu 2020=20 syncpeer: 224.0.0.240 maxupd: 128=20 pflog0: flags=3D0<> mtu 33208=20 lo0: flags=3D8049 mtu 16384=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6=20 inet6 ::1 prefixlen 128=20 inet 127.0.0.1 netmask 0xff000000 run tcpdump on 192.168.100.1 (getway to Internet and other network) when run script=20 # tcpdump -i eth1 -f=20 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode=20 listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes=20 22:30:22.430329 arp who-has 192.168.100.1 tell 192.168.100.99=20 22:30:22.438397 arp reply 192.168.100.1 is-at 00:30:4f:25:7a:b1 (oui Unknown)=20 22:30:22.430367 IP 10.11.2.3 > 192.168.100.1: ICMP echo request, id 512, seq 44033, length 40=20 22:30:22.931140 IP 10.11.2.3 > 192.168.128.2: ICMP echo request, id 512, seq 44289, length 40=20 22:30:23.381425 IP 192.168.100.99.59543 > 10.11.25.1.domain: 54371 notify [b2&3=3D0x2400] [1a] SOA? 25.11.10.in-addr.arpa. (95)=20 22:30:23.438366 IP 10.11.25.1.domain > 192.168.100.99.59543: 54371 notify* 0/0/0 (39)=20 22:30:23.881984 IP 192.168.100.99.59543 > 10.11.25.1.domain: 38578 notify [b2&3=3D0x2400] [1a] SOA? skyhome. (74)=20 22:30:24.181110 IP 10.11.25.1.domain > 192.168.100.99.59543: 38578 notify* 0/0/0 (25)=20 22:30:27.930042 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 45825, length 40=20 22:30:27.930128 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 45825, length 40=20 22:30:28.430049 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 46337, length 40=20 22:30:28.430123 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 46081, length 40=20 22:30:28.430921 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 46081, length 40=20 22:30:28.436810 arp who-has 192.168.100.99 tell 192.168.100.1=20 22:30:28.436913 arp reply 192.168.100.99 is-at 00:01:29:76:0f:cd (oui Unknown)=20 22:30:33.429858 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 46593, length 40=20 22:30:33.429945 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 46593, length 40=20 22:30:33.929773 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 46849, length 40=20 22:30:33.929850 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 47105, length 40=20 22:30:33.930216 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 47105, length 40=20 22:30:38.929631 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 47361, length 40=20 22:30:38.929698 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 47361, length 40=20 22:30:39.429559 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 47617, length 40=20 22:30:39.429672 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 47873, length 40=20 22:30:44.429404 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 48129, length 40=20 22:30:44.429475 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 48129, length 40=20 22:30:44.929344 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 48385, length 40=20 22:30:44.929468 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 48641, length 40=20 22:30:44.929880 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 48641, length 40=20 22:30:49.929176 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 48897, length 40=20 22:30:49.929246 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 48897, length 40=20 22:30:50.429144 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 49153, length 40=20 22:30:50.429266 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 49409, length 40=20 22:30:50.494074 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 49409, length 40=20 22:30:55.428970 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 49665, length 40=20 22:30:55.429060 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 49665, length 40=20 22:30:55.928922 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 49921, length 40=20 22:30:55.928996 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 50177, length 40=20 22:30:55.929427 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 50177, length 40=20 22:31:00.427013 arp who-has 192.168.100.99 tell 192.168.100.1=20 22:31:00.427151 arp reply 192.168.100.99 is-at 00:01:29:76:0f:cd (oui Unknown)=20 22:31:00.928744 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 50433, length 40=20 22:31:00.928814 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 50433, length 40=20 22:31:01.428737 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 50689, length 40=20 22:31:01.428853 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 50945, length 40=20 22:31:01.429186 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 50945, length 40=20 22:31:04.731353 IP 192.168.100.99.1036 > 192.168.100.1.domain: 64927+ A? login.icq.com. (31)=20 22:31:04.731427 IP 192.168.100.1 > 192.168.100.99: ICMP 192.168.100.1 udp port domain unreachable, length 67=20 22:31:05.731305 IP 192.168.100.99.1036 > 192.168.128.2.domain: 64927+ A? login.icq.com. (31)=20 22:31:05.732547 IP 192.168.128.2.domain > 192.168.100.99.1036: 64927 2/4/0 CNAME[|domain]=20 22:31:06.428548 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 51201, length 40=20 22:31:06.428621 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 51201, length 40=20 22:31:06.731233 IP 192.168.100.99.1036 > 192.168.100.1.domain: 64927+ A? login.icq.com. (31)=20 22:31:06.731316 IP 192.168.100.1 > 192.168.100.99: ICMP 192.168.100.1 udp port domain unreachable, length 67=20 22:31:06.928525 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 51457, length 40=20 22:31:06.928640 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 51713, length 40=20 22:31:06.929187 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 51713, length 40=20 22:31:08.731195 IP 192.168.100.99.1036 > 192.168.100.1.domain: 64927+ A? login.icq.com. (31)=20 22:31:08.731259 IP 192.168.100.1 > 192.168.100.99: ICMP 192.168.100.1 udp port domain unreachable, length 67=20 22:31:08.731276 IP 192.168.100.99.1036 > 192.168.128.2.domain: 64927+ A? login.icq.com. (31)=20 22:31:08.732343 IP 192.168.128.2.domain > 192.168.100.99.1036: 64927 2/4/0 CNAME[|domain]=20 22:31:11.928333 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 51969, length 40=20 22:31:11.928420 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 51969, length 40=20 22:31:12.428298 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 52225, length 40=20 22:31:12.428371 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 52481, length 40=20 22:31:12.428696 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 52481, length 40=20 22:31:12.731006 IP 192.168.100.99.1036 > 192.168.100.1.domain: 64927+ A? login.icq.com. (31)=20 22:31:12.731068 IP 192.168.100.1 > 192.168.100.99: ICMP 192.168.100.1 udp port domain unreachable, length 67=20 22:31:12.731086 IP 192.168.100.99.1036 > 192.168.128.2.domain: 64927+ A? login.icq.com. (31)=20 22:31:12.731903 IP 192.168.128.2.domain > 192.168.100.99.1036: 64927 2/4/0 CNAME[|domain]=20 22:31:17.428112 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 52737, length 40=20 22:31:17.428182 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 52737, length 40=20 22:31:17.928064 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 52993, length 40=20 22:31:17.928203 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 53249, length 40=20 22:31:17.928804 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 53249, length 40=20 22:31:22.927909 IP 192.168.100.99 > 192.168.100.1: ICMP echo request, id 512, seq 53505, length 40=20 22:31:22.927980 IP 192.168.100.1 > 192.168.100.99: ICMP echo reply, id 512, seq 53505, length 40=20 22:31:23.427881 IP 10.11.2.1 > 10.11.2.3: ICMP echo reply, id 512, seq 53761, length 40=20 22:31:23.428004 IP 192.168.100.99 > 192.168.128.2: ICMP echo request, id 512, seq 54017, length 40=20 22:31:23.428295 IP 192.168.128.2 > 192.168.100.99: ICMP echo reply, id 512, seq 54017, length 40=20 22:31:28.427666 IP 10.11.2.3 > 192.168.100.1: ICMP echo request, id 512, seq 54273, length 40=20 22:31:28.927667 IP 10.11.2.3 > 192.168.128.2: ICMP echo request, id 512, seq 54785, length 40=20 82 packets captured=20 82 packets received by filter=20 0 packets dropped by kernel # sysctl -a | grep one_pass=20 net.inet.ip.fw.one_pass: 0 # ps awx | grep natd=20 1172 p0 R+ 0:00.00 grep natd From owner-freebsd-net@FreeBSD.ORG Sat Sep 29 11:42:46 2007 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 7B9DB16A417 for ; Sat, 29 Sep 2007 11:42:46 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 2838513C48E for ; Sat, 29 Sep 2007 11:42:46 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id C66B71CC26; Sat, 29 Sep 2007 23:42:44 +1200 (NZST) Date: Sat, 29 Sep 2007 23:42:44 +1200 From: Andrew Thompson To: Randy Bush Message-ID: <20070929114244.GC44719@heff.fud.org.nz> References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <46FC4036.3040604@errno.com> <46FC4C5F.8000004@psg.com> <46FC560E.1070301@errno.com> <46FC574B.1070507@errno.com> <46FE0640.3030102@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FE0640.3030102@psg.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Net Subject: Re: bridging ath 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, 29 Sep 2007 11:42:46 -0000 On Fri, Sep 28, 2007 at 10:01:04PM -1000, Randy Bush wrote: > > I don't know what you're trying to do > > no surprise. i rarely do. :) > > > When you attach your wired nic to a bridge and and turn the bridge on > > the nic gets set in promiscuous mode. This is likely why you can > > ping the other wireless station through the wired nic. To ping the > > wireless station through your AP then AP must either fwd the packet > > directly or bridge it using some mechanism. You cannot bridge a > > wireless interface unless it's operating as an ap. Either way it's > > an issue at the AP. > > sokeris running current > application is a remote (via wireless) ether switch > wireless client, bridged to the ethers > a few devices on the ethers such as desktop, printer, ... > it is also a local samba etc, and ipsecs to the AP's net > > so it does not want to be an AP but it does want to bridge. At the bottom of if_bridge(4): "Only wireless interfaces in hostap mode can be bridged due to the 802.11 framing format, bridging a wireless client is not supported yet." From owner-freebsd-net@FreeBSD.ORG Sat Sep 29 14:42:36 2007 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 B863616A419; Sat, 29 Sep 2007 14:42:36 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8ACAA13C457; Sat, 29 Sep 2007 14:42:36 +0000 (UTC) (envelope-from randy@psg.com) Received: from cust16202.lava.net ([64.65.95.74] helo=[192.168.0.101]) by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IbdWd-000MA1-58; Sat, 29 Sep 2007 14:42:35 +0000 Message-ID: <46FE6455.7040203@psg.com> Date: Sat, 29 Sep 2007 04:42:29 -1000 From: Randy Bush User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Thompson References: <46FB1044.7020000@psg.com> <20070927214100.GB20718@heff.fud.org.nz> <46FC25C3.8030703@psg.com> <46FC4036.3040604@errno.com> <46FC4C5F.8000004@psg.com> <46FC560E.1070301@errno.com> <46FC574B.1070507@errno.com> <46FE0640.3030102@psg.com> <20070929114244.GC44719@heff.fud.org.nz> In-Reply-To: <20070929114244.GC44719@heff.fud.org.nz> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: bridging ath 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, 29 Sep 2007 14:42:36 -0000 >> so it does not want to be an AP but it does want to bridge. > At the bottom of if_bridge(4): > "Only wireless interfaces in hostap mode can be bridged due to the > 802.11 framing format, bridging a wireless client is not supported yet." randy, rearchitecting From owner-freebsd-net@FreeBSD.ORG Sat Sep 29 20:24:01 2007 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 55E3116A41A; Sat, 29 Sep 2007 20:24:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 9E64F13C46E; Sat, 29 Sep 2007 20:23:59 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <46FEB462.4040307@FreeBSD.org> Date: Sat, 29 Sep 2007 22:24:02 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: net@FreeBSD.org, silby@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: localhost connections showing source address 0.0.0.0 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, 29 Sep 2007 20:24:01 -0000 Going back at least as far as January 2007 some of the package build machines have occasionally experienced a problem where a fetch(1) via a localhost:3128 squid proxy are denied because squid sees the connection as having a source address of 0.0.0.0 instead of 127.0.0.1. I thought this had stopped but it turns out it was just masked by all the other TCP issues and was still persisting at a low rate (only ~300 occurrences on the machine I checked since January). Can anyone work out how this is happening, or give suggestions on how to debug this further? Kris