From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 04:06:44 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF2DC16A421; Sun, 16 Oct 2005 04:06:44 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BE7043D49; Sun, 16 Oct 2005 04:06:43 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9G46Y6B022772; Sun, 16 Oct 2005 14:06:34 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j9G46Ueu017591; Sun, 16 Oct 2005 14:06:31 +1000 Date: Sun, 16 Oct 2005 14:06:32 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Robert Watson In-Reply-To: <20051015194738.C66245@fledge.watson.org> Message-ID: <20051016135234.T86712@delplex.bde.org> References: <17231.43525.446450.161986@grasshopper.cs.duke.edu> <13600.1129298731@critter.freebsd.dk> <17231.50841.442047.622878@grasshopper.cs.duke.edu> <20051015092141.F1403@epsplex.bde.org> <20051015194738.C66245@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Garrett Wollman , Poul-Henning Kamp , Andrew Gallatin , net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) 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, 16 Oct 2005 04:06:45 -0000 On Sat, 15 Oct 2005, Robert Watson wrote: > On Sat, 15 Oct 2005, Bruce Evans wrote: >> ... However, for netisrs I think it is >> common to process only 1 packet per context switch, at least in the >> loopback case. > > The Mach scheduler allows deferred wakeups to be issued -- "wake up a thread > in the sleep queue -- but when it's convenient" to avoid premature preemtion. > This helps avoid immediate preemption where it's unnecessary and/or > undesirable: specifically, to avoid preemption when the preempting thread > will immediately require a lock held by the signalling thread, as occurs with > the netisr and TCP. Hmm, does it still do that? A year or two, at least the loopback case used to run into itself on Giant, and pushing down giant made things worse (scheduling the netisr would switch immediately because the netisr was "MPSAFE" but then the netisr would immediately block on Giant and switch back, so it took 2 expensive context switches instead of just 1 to get a netisr to do anything). > I've not yet investigated tweaking things, or even a > scheduler trace to see for sure that this is happening, but it wouldn't > surprise me at all if we're seeing extra context switches due to premature or > untimely preemption following wakeup. Probably the problem is largest for latency, especially in benchmarks. Latency benchmarks probably have to start cold, so they have no chance of queue lengths > 1, so there must be a context switch per packet and may be 2. Bruce From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 04:16:45 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C81316A420 for ; Sun, 16 Oct 2005 04:16:45 +0000 (GMT) (envelope-from shafi_2k12003@yahoo.com) Received: from web53110.mail.yahoo.com (web53110.mail.yahoo.com [206.190.49.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 0873443D46 for ; Sun, 16 Oct 2005 04:16:44 +0000 (GMT) (envelope-from shafi_2k12003@yahoo.com) Received: (qmail 30219 invoked by uid 60001); 16 Oct 2005 04:16:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NrOxlVCuo2KsINCkeqyZsvRe+6/JV+MOfu8QDD1ihQPqgK+cRh2ntOiGEgmvf1DVGiLk/Um/L1+4y8xx7MuiguIyH7TKD3OrxFsQcyP9NYaENdsrjqUPw/E0O9rS8LKMu5LHD6eAaa2A8pfCM0ObBrRPvbc0SBWWACtLB9l31Pw= ; Message-ID: <20051016041644.30217.qmail@web53110.mail.yahoo.com> Received: from [202.174.155.162] by web53110.mail.yahoo.com via HTTP; Sat, 15 Oct 2005 21:16:44 PDT Date: Sat, 15 Oct 2005 21:16:44 -0700 (PDT) From: shafi kamal To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: For advice in tcp implementation 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, 16 Oct 2005 04:16:45 -0000 Hello, I am wishing to implement tcp minimally .I have taken it as a project work. Is it possible to do that? How much coding capability & man-hour may required through your estimation? I think you are the best man for this advice. Any ref. & source of information for "tcp implementation" will be welcome. Last info i have studied the "tcp/ip implementation in FreeBSD" . Expecting quick response. shafi kamal --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 04:16:57 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEB8616A420 for ; Sun, 16 Oct 2005 04:16:57 +0000 (GMT) (envelope-from shafi_2k12003@yahoo.com) Received: from web53107.mail.yahoo.com (web53107.mail.yahoo.com [206.190.49.57]) by mx1.FreeBSD.org (Postfix) with SMTP id 4E28143D46 for ; Sun, 16 Oct 2005 04:16:57 +0000 (GMT) (envelope-from shafi_2k12003@yahoo.com) Received: (qmail 72486 invoked by uid 60001); 16 Oct 2005 04:16:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ny8kKOg7lU2IjQjnYp7t4kUAtPnC9OvejH9BgLPcTR3tkUOCmIBIhJpzFdwx12RLtm6kJhCl/PzafG6Eqd7pFuf3FnOTPH309k09d99b+QEozBpVDalQlKS7iiHbOA5dh/EfwiqV8hTzOKP2nl566tNSx20h5kcQoxph0kW5c9U= ; Message-ID: <20051016041656.72484.qmail@web53107.mail.yahoo.com> Received: from [202.174.155.162] by web53107.mail.yahoo.com via HTTP; Sat, 15 Oct 2005 21:16:56 PDT Date: Sat, 15 Oct 2005 21:16:56 -0700 (PDT) From: shafi kamal To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: For advice in tcp implementation 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, 16 Oct 2005 04:16:57 -0000 Hello, I am wishing to implement tcp minimally .I have taken it as a project work. Is it possible to do that? How much coding capability & man-hour may required through your estimation? I think you are the best man for this advice. Any ref. & source of information for "tcp implementation" will be welcome. Last info i have studied the "tcp/ip implementation in FreeBSD" . Expecting quick response. shafi kamal --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 04:21:51 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86F0E16A420 for ; Sun, 16 Oct 2005 04:21:51 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id C154C43D49 for ; Sun, 16 Oct 2005 04:21:50 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) by khavrinen.csail.mit.edu (8.13.1/8.13.4) with ESMTP id j9G4Lk1b047015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.csail.mit.edu issuer=Client+20CA); Sun, 16 Oct 2005 00:21:48 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.4/Submit) id j9G4LjB6047012; Sun, 16 Oct 2005 00:21:45 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17233.54617.89368.645866@khavrinen.csail.mit.edu> Date: Sun, 16 Oct 2005 00:21:45 -0400 To: Bruce Evans In-Reply-To: <20051016135234.T86712@delplex.bde.org> References: <17231.43525.446450.161986@grasshopper.cs.duke.edu> <13600.1129298731@critter.freebsd.dk> <17231.50841.442047.622878@grasshopper.cs.duke.edu> <20051015092141.F1403@epsplex.bde.org> <20051015194738.C66245@fledge.watson.org> <20051016135234.T86712@delplex.bde.org> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Sun, 16 Oct 2005 00:21:48 -0400 (EDT) X-Spam-Status: No, score=0.0 required=5.0 tests=none version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu Cc: net@freebsd.org Subject: Re: Call for performance evaluation: net.isr.direct (fwd) 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, 16 Oct 2005 04:21:51 -0000 < said: > Probably the problem is largest for latency, especially in benchmarks. > Latency benchmarks probably have to start cold, so they have no chance > of queue lengths > 1, so there must be a context switch per packet and > may be 2. It has frequently been proposed that one of the deficiencies of the sockets model is that too much work must take place in interrupt context. Several alternatives have been suggested, including user-mode protocol processing (e.g., Exokernel) and event-driven receive (can't think of an example here from the literature). In an alternate universe with truly pervasive threading, one might require an application to "donate" a thread to protocol processing -- effectively combining the two approaches I mentioned -- which would be the way to "win" such latency benchmarks. (The application donating the processing power is then also able to donate its memory.) -GAWollman From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 13:13:42 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74EC416A41F for ; Sun, 16 Oct 2005 13:13:42 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C24D43D48 for ; Sun, 16 Oct 2005 13:13:42 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 51BD0221E; Sun, 16 Oct 2005 09:14:05 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id E658C87; Sun, 16 Oct 2005 09:14:03 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1ER8KX-0008t1-DX; Sun, 16 Oct 2005 14:13:37 +0100 Date: Sun, 16 Oct 2005 14:13:37 +0100 From: Brian Candler To: shafi kamal Message-ID: <20051016131337.GB34124@uk.tiscali.com> References: <20051016041656.72484.qmail@web53107.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051016041656.72484.qmail@web53107.mail.yahoo.com> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: For advice in tcp implementation 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, 16 Oct 2005 13:13:42 -0000 On Sat, Oct 15, 2005 at 09:16:56PM -0700, shafi kamal wrote: > I am wishing to implement tcp minimally .I have taken it as a project > work. Good for you. That has nothing to do with FreeBSD, of course. > Is it possible to do that? Of course it is possible, depending on a suitable definition of "minimal". Try this for size: http://www-ccs.cs.umass.edu/~shri/iPic.html And if it were not possible, then you shouldn't have taken it as a project work, should you? > How much coding capability & man-hour > may required through your estimation? How long is a piece of string? If you don't know anything about programming practices or TCP/IP, or can't be bothered to research the TCP/IP protocols for yourself, then I would say the coding capability required is higher than you possess. > I think you are the best man for > this advice. I find it interesting that you think of a mailing list as a "man". > Expecting quick response. shafi kamal I hope this is quick enough for you. Before you post to any more mailing lists, there is a very useful guide here which I suggest you read: http://www.catb.org/~esr/faqs/smart-questions.html Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 05:48:12 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0F6316A41F for ; Mon, 17 Oct 2005 05:48:12 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5274E43D53 for ; Mon, 17 Oct 2005 05:48:12 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j9H5lGk1050536 for ; Sun, 16 Oct 2005 22:47:17 -0700 (PDT) Date: Mon, 17 Oct 2005 14:47:15 +0900 Message-ID: From: gnn@freebsd.org To: freebsd-net@freebsd.org User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: What are the rules for ref counting of routes? 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, 17 Oct 2005 05:48:12 -0000 Howdy, I'm working out some issues in the neighbor discovery code for IPv6 and there is a ref counting issue. Can someone state clearly the rules around when a route gets a reference added and when it is removed? Thanks, George From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 09:12:44 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AF0416A41F; Mon, 17 Oct 2005 09:12:44 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0280143D46; Mon, 17 Oct 2005 09:12:43 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring [10.0.0.2]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id j9H9CL0v070670; Mon, 17 Oct 2005 10:12:21 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-arch@freebsd.org Date: Mon, 17 Oct 2005 10:12:18 +0100 User-Agent: KMail/1.8.2 References: <2b22951e0510141758x1edef8jf7caf2514c336514@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510171012.20801.dfr@nlsystems.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (itchy.rabson.org [80.177.232.242]); Mon, 17 Oct 2005 10:12:31 +0100 (BST) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.83/1139/Mon Oct 17 01:30:04 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, "Cai, Quanqing" , Katsushi Kobayashi , freebsd-firewire@freebsd.org, Tai-hwa Liang Subject: Re: fwe -> fwip in GENERIC? 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, 17 Oct 2005 09:12:44 -0000 The fwip implementation should be fully compatible with the RFC standard. I'm happy for fwip to replace fwe in GENERIC unless anyone else has an objection. On Saturday 15 October 2005 03:35, Katsushi Kobayashi wrote: > Hi, > > Although I don't know the detail of fwe technology, I understand the > technology is a proprietary one. It is better to provide a > compatibility with RFC standard firewire over IP, if some volunteer > are there. > > On 2005/10/15, at 9:58, Cai, Quanqing wrote: > > Hi guys, > > > > When I was fixing bug kern/82727: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82727, I found we > > use fwe(Ethernet over FireWire) in GENERIC kernel, not fwip(IP over > > FireWire). > > But we all know that IP over FireWire is more widely used on other > > OSes, and > > now this bug is fixed, do we need change fwe to fwip? > > > > I talked it with Tai-hwa Liang, he agrees with me. But he suggests > > me to > > post here for more advices, since there might be some > > considerations such > > like backward compatibility or code size that makes re@ made this > > decision. > > > > Please give you advice or opinion. > > > > Best > > Cai, Quanqing > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch- > > unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to > "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 10:02:08 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 042F416A41F for ; Mon, 17 Oct 2005 10:02:08 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7175443D48 for ; Mon, 17 Oct 2005 10:02:07 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id 7AED6BC037; Mon, 17 Oct 2005 13:02:05 +0300 (EEST) Received: from [10.0.0.1] (vdp1003.ath03.dsl.hol.gr [62.38.168.4])by smtp.freemail.gr (Postfix) with ESMTP id 6F280BC020for ; Mon, 17 Oct 2005 13:02:04 +0300 (EEST) Message-ID: <4353765C.4030802@freemail.gr> Date: Mon, 17 Oct 2005 13:01:00 +0300 From: Chris Dionissopoulos User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: What's wrong with netgraph NG_FWD_NEW_DATA? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dionch@freemail.gr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 10:02:08 -0000 Hi ppl, Trying to split inbound traffic based on layer2 characteristics, i have create a new netgraph module(ng_l2split) using ng_vlan(4) as reference. The design and implementation is pretty simple as ng_vlan : xl0:upper | +---------+ | ng_l2split|-----ng0 (ng_eiface on ngeth0) +---------+ ( --- ng1,2,....) | xl0:lower ng_l2plit has 2 basic hooks as descriped in ng_vlan(4) man page: - downstream hook (attached to physical's "lower" ) - nomatch hook (attached to physical's "upper" ) and for every ng_eiface node you attach you must provide a mac address for filtering (later this will be automated). i.e. #!/bin/sh ngctl -f- < mtu 1500 inet6 fe80::260:8ff:fee8:589e%ngeth0 prefixlen 64 scopeid 0x6 inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 ether 01:02:03:04:05:00 Traffic initiated localy flows prefectly through ngeth0 and xl0 interfaces, but this is not happen for traffic that comes from outside. It seems that doesn't arrive to ngeth0 upper level protocols. Long story short: o physical interface works fine. o app:stack-->ngeth0--->ng0---->xl0:low--->wire [WORKS] o wire --->xl0:low--->ng0--->ngeth0--->stack:app [FAILED] [works] [failed to reply] Here is my rcvdata function : -------ng_l2split.c part----------- static int ng_l2split_rcvdata(hook_p hook, item_p item) { const priv_p priv = NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); struct ether_header *eh; struct ether_addr eaddr; int error; struct mbuf *m; struct filter *f; /* Make sure we have an entire header. */ NGI_GET_M(item, m); if (m->m_len < sizeof(*eh) && (m = m_pullup(m, sizeof(*eh))) == NULL) { NG_FREE_ITEM(item); return (EINVAL); } eh = mtod(m, struct ether_header *); if (hook == priv->downstream_hook) { /* * If from downstream, select between a match hook * or the nomatch hook. */ bcopy(eh->ether_dhost,eaddr.octet, sizeof(eh->ether_dhost)); if ((f = ng_l2split_findentry(priv, &eaddr)) != NULL) { NG_FWD_NEW_DATA(error, item, f->hook, m); printf("send"); } else NG_FWD_NEW_DATA(error, item, priv->nomatch_hook, m); } else NG_FWD_NEW_DATA(error, item, priv->downstream_hook, m); return (error); } ------------------------------------ Any idea what i'm doing wrong? Is NG_FWD_NEW_DATA improperly used? TIA, Chris. p.s. I'm using FreeBSD6-beta5 (Sept-30) ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 10:14:32 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AE2416A41F for ; Mon, 17 Oct 2005 10:14:32 +0000 (GMT) (envelope-from dean@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 294FA43D48 for ; Mon, 17 Oct 2005 10:14:31 +0000 (GMT) (envelope-from dean@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id 88E80A2FD2; Mon, 17 Oct 2005 12:14:30 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1600) id 73A9F22880; Mon, 17 Oct 2005 12:14:30 +0200 (CEST) Date: Mon, 17 Oct 2005 12:14:30 +0200 From: Dean Strik To: Chris Dionissopoulos Message-ID: <20051017101430.GH41710@stack.nl> References: <4353765C.4030802@freemail.gr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wayzTnRSUXKNfBqd" Content-Disposition: inline In-Reply-To: <4353765C.4030802@freemail.gr> X-Really: Yes User-Agent: Mutt/1.5.11 Cc: net@freebsd.org Subject: Re: What's wrong with netgraph NG_FWD_NEW_DATA? 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, 17 Oct 2005 10:14:32 -0000 --wayzTnRSUXKNfBqd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Chris Dionissopoulos wrote: > and for every ng_eiface node you attach you must provide a > mac address for filtering (later this will be automated). [..] > gw0#ifconfig ngeth0 > ngeth0:=20 > flags=3D28943 mt= u=20 > 1500 > inet6 fe80::260:8ff:fee8:589e%ngeth0 prefixlen 64 scopeid 0x6 > inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 > ether 01:02:03:04:05:00 >=20 > Traffic initiated localy flows prefectly through ngeth0 and xl0=20 > interfaces, but > this is not happen for traffic that comes from outside. It seems that=20 > doesn't > arrive to ngeth0 upper level protocols. Haven't looked at the code, but I'm just wondering here... this MAC address is a multicast address, not a unicast one. Should that work as expected at all? --=20 Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli --wayzTnRSUXKNfBqd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDU3mG5Td/bYnvOAMRAjvNAJ4/z0R3Cq5CgJhVqU2N759uhqet8gCgod6E tC0hJ+gua0Wqz5/vN8/kRD0= =RmpU -----END PGP SIGNATURE----- --wayzTnRSUXKNfBqd-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 11:02:01 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F09E16A41F for ; Mon, 17 Oct 2005 11:02:01 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1499A43D49 for ; Mon, 17 Oct 2005 11:02:01 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9HB20VT022426 for ; Mon, 17 Oct 2005 11:02:00 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9HB1xt7022420 for freebsd-net@freebsd.org; Mon, 17 Oct 2005 11:01:59 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 17 Oct 2005 11:01:59 GMT Message-Id: <200510171101.j9HB1xt7022420@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter 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, 17 Oct 2005 11:02:01 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 11:14:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7098316A41F for ; Mon, 17 Oct 2005 11:14:15 +0000 (GMT) (envelope-from toba@etek.chalmers.se) Received: from anubis.medic.chalmers.se (anubis.medic.chalmers.se [129.16.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB4643D49 for ; Mon, 17 Oct 2005 11:14:14 +0000 (GMT) (envelope-from toba@etek.chalmers.se) X-Medic-Info: 6f42.43538785.0 1Q3GXp5LsSeMDdaM Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 4EEDE190EE for ; Mon, 17 Oct 2005 13:14:13 +0200 (CEST) Received: from 192.138.116.163 (SquirrelMail authenticated user toba); by webmail.chalmers.se with HTTP; Mon, 17 Oct 2005 13:14:13 +0200 (CEST) Message-ID: <47134.192.138.116.163.1129547653.squirrel@webmail.chalmers.se> Date: Mon, 17 Oct 2005 13:14:13 +0200 (CEST) From: "Tobias Abrahamsson" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: using BPF and rawsocket 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, 17 Oct 2005 11:14:15 -0000 Hi I have a problem that i hope that someone can help me with. I'm trying to make a computer running a webserver, reachable on a net wich it don't own an address on. In order to let clients reach the server, I use BPF to capture the packets to an address that i have chosen, ( not important wich address, only that it's not on the right net), and then redirect them to my self to reach the webserver. To make the webserver respond to the client I set a static route back to the client ( there is no routers between the clients and the webserver so this works ). I'm using a raw socket to send the capured packets to webserver and there is were I have trouble. When I'm using sendto() it responds with error message: Invalid argument. I can't figure out why that is, but this is the first time I use rawsockets so maby it is easy to fix. Thankful for all ideas. Tobias Abrahamsson PS. the code have testig status so it is not so neat. #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static void print_pkt( char *pkt_ptr ) { int i, print; char ch; struct ip *ip_hdr; ip_hdr = (struct ip *)pkt_ptr; for( i = 0; i < ntohs(ip_hdr->ip_len); i++ ) { ch = 0x00; ch = *(pkt_ptr + i); if( i%8 == 0 ) printf("\n"); print = (int)ch & 0x000000ff; if( (print & 0x000000f0) == 0 ) printf( "0%x:", print ); else printf( "%x:", print ); } printf( "\n" ); } static void send_pkt( int s, struct ip *ip_hdr ) { char *ptr; ssize_t ss; size_t len; struct sockaddr_in saddr; memset( &saddr, 0, sizeof(saddr) ); saddr.sin_family = AF_INET; saddr.sin_port = 80; inet_aton( "10.0.0.0", saddr.sin_addr ); len = ntohs(ip_hdr->ip_len); ptr = (char *)ip_hdr; if( (ss = sendto( s, ptr, len, 0, (const struct sockaddr *)&saddr, sizeof(saddr) )) < 0 ) perror( "sendto could not write" ); printf( "ip_len: %d sent: %d bytes\n", len, ss ); } int main() { int s, snaplen = 1600; char *device, errbuf[ PCAP_ERRBUF_SIZE ]; const int on = 1; const u_char *pkt_ptr; struct ip *ip_hdr; struct pcap_pkthdr pchdr; pcap_t *pd; if( (device = pcap_lookupdev( errbuf )) == NULL ) fprintf( stderr, errbuf ); pd = pcap_open_live( device, snaplen, 1, 1, errbuf); printf( "device %s\n", device ); if( (s = socket( AF_INET, SOCK_RAW, 0 )) < 0 ) perror( "socket" ); if( setsockopt( s, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on) ) < 0 ) perror( "setsockopt" ); while( 1 ) { while( (pkt_ptr = (char *)pcap_next( pd, &pchdr )) == NULL ); ip_hdr = (struct ip *)(pkt_ptr + ETHER_HDR_LEN); if( ntohs(ip_hdr->ip_len) < 100 ) print_pkt( (char *)ip_hdr ); send_pkt( s, ip_hdr ); } } _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 11:49:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFF4316A420 for ; Mon, 17 Oct 2005 11:49:02 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35711.mail.mud.yahoo.com (web35711.mail.mud.yahoo.com [66.163.179.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 06C4F43D4C for ; Mon, 17 Oct 2005 11:49:01 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 32414 invoked by uid 60001); 17 Oct 2005 11:49:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Y0gdjAS2gVbg8HyqdXaNY9kKH4nxrIHPsQCG47r8QWj6iH08bm8O5t7f7hOACBQyYZ/C/3qCsF8Iot0zH+9VsLZj9DRG4mG5Fxe4yJYAKV7+aCYAXhuqFxUksaQGk28Q2o2VsuNULpiadwJgTZduQx5KO1XZ60sNqKR0V18//dY= ; Message-ID: <20051017114901.32412.qmail@web35711.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35711.mail.mud.yahoo.com via HTTP; Mon, 17 Oct 2005 04:49:01 PDT Date: Mon, 17 Oct 2005 04:49:01 -0700 (PDT) From: kamal kc To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: malloc() in kernel and increasing mbuf and cluster size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 11:49:02 -0000 this may be a trivial question for many of you but i am confused in doing memory allocation in the kernel. sys/malloc.h has function prototypes for malloc() kern/kern_malloc.c defines the malloc() the malloc() definition is void * malloc(size, type, flags) unsigned long size; struct malloc_type *type; int flags; i understand the size and flags but what shall i do with the malloc_type. suppose i want to allocate 1024 bytes then how should i call the malloc ? i set --> size=1024 flags=M_WAITOK type=???? (i don't know what/how to initialize the type) Next thing is that i want to make the kernel process network packets very fast. i think of increasing the mbuf and cluster size. i want to if there will be any effect on increasing the mbuf and cluster size. what would be an appropriate size of mbuf and cluster if I use i. 512 MB RAM iI. 1024 MB RAM which parts of the kernel will be affected by changing the mbuf and cluster size ? i think somebody maybe able to help me. thanks folks. kamal __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 12:07:38 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C220416A41F; Mon, 17 Oct 2005 12:07:38 +0000 (GMT) (envelope-from nick@taran.infoua.com.ua) Received: from taran.infoua.com.ua (2s-49.colo1.kv.wnet.ua [217.20.163.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2612943D48; Mon, 17 Oct 2005 12:07:36 +0000 (GMT) (envelope-from nick@taran.infoua.com.ua) Received: from taran.infoua.com.ua (localhost [127.0.0.1]) by taran.infoua.com.ua (8.13.4/8.13.4) with ESMTP id j9HC7Ytf001581; Mon, 17 Oct 2005 15:07:34 +0300 (EEST) (envelope-from nick@taran.infoua.com.ua) Received: (from nick@localhost) by taran.infoua.com.ua (8.13.4/8.13.4/Submit) id j9HC7Ye5001580; Mon, 17 Oct 2005 15:07:34 +0300 (EEST) (envelope-from nick) Date: Mon, 17 Oct 2005 15:07:34 +0300 From: Nick Strebkov To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20051017120734.GA820@taran.infoua.com.ua> Mail-Followup-To: Nick Strebkov , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org References: <20051017114901.32412.qmail@web35711.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline In-Reply-To: <20051017114901.32412.qmail@web35711.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-BETA4 X-Real-Name: =?koi8-u?B?89TSxcLLz9cgSMnLz8zByiDhzsHU?= =?koi8-u?B?z8zYxdfJ3g==?= Cc: Subject: Re: malloc() in kernel and increasing mbuf and cluster size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 12:07:38 -0000 Hi, Kamal On 17.10.2005 04:49:01, kamal kc wrote: > this may be a trivial question for many of you > but i am confused in doing memory allocation in the > kernel. > > sys/malloc.h has function prototypes for malloc() > kern/kern_malloc.c defines the malloc() > > the malloc() definition is > > void * > malloc(size, type, flags) > unsigned long size; > struct malloc_type *type; > int flags; > > i understand the size and flags but what shall i > do with the malloc_type. man 9 malloc :-) -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 12:27:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA11116A41F for ; Mon, 17 Oct 2005 12:27:02 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35703.mail.mud.yahoo.com (web35703.mail.mud.yahoo.com [66.163.179.157]) by mx1.FreeBSD.org (Postfix) with SMTP id CCA1543D60 for ; Mon, 17 Oct 2005 12:26:57 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 58725 invoked by uid 60001); 17 Oct 2005 12:26:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BjOJIls2l9EhbgySTLwhXYpnjkj0cLSzH/+SuQIy038KvHz9j0dwz9w15wf4KlitU78oBXQ9e2ySiDtsqmUqCrop2gZ3HEzNec9dpzaVL7Ma0fqAF4E4L9ZRZjxwWt6ysCLEBPcclS+uIc9sTb34G1NwTIFYbsTPN0FpovgH4dQ= ; Message-ID: <20051017122657.58723.qmail@web35703.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35703.mail.mud.yahoo.com via HTTP; Mon, 17 Oct 2005 05:26:57 PDT Date: Mon, 17 Oct 2005 05:26:57 -0700 (PDT) From: kamal kc To: freebsd-net@freebsd.org In-Reply-To: <20051017120734.GA820@taran.infoua.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: malloc() in kernel and increasing mbuf and cluster size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 12:27:02 -0000 > > sys/malloc.h has function prototypes for malloc() > > kern/kern_malloc.c defines the malloc() > > > > the malloc() definition is > > > > void * > > malloc(size, type, flags) > > unsigned long size; > > struct malloc_type *type; > > int flags; > > > > i understand the size and flags but what shall i > > do with the malloc_type. > > man 9 malloc :-) > i saw the man pages. it says to use malloc_type via MALLOC_DEFINE(type,shortdesc,longdesc) MALLOC_DECLARE(type) the man pages use M_FOOBUF(where did it come from ??) in the field type. Now how should i code it. struct malloc_type mytype; mytype=MALLOC_DEFINE(.....,"mybuffers","mybuffers"); what should i put in the type field ?? thanks in advance, kamal __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 12:34:16 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 272B816A41F; Mon, 17 Oct 2005 12:34:16 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C1C243D49; Mon, 17 Oct 2005 12:34:15 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp211-138.lns1.adl2.internode.on.net [203.122.211.138]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j9HCYC5Z040218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Oct 2005 22:04:13 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Mon, 17 Oct 2005 22:04:10 +0930 User-Agent: KMail/1.8.2 References: <20051017114901.32412.qmail@web35711.mail.mud.yahoo.com> In-Reply-To: <20051017114901.32412.qmail@web35711.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2003707.nlPXxie13S"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510172204.11162.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: kamal kc , freebsd-net@freebsd.org Subject: Re: malloc() in kernel and increasing mbuf and cluster size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 12:34:16 -0000 --nextPart2003707.nlPXxie13S Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 17 Oct 2005 21:19, kamal kc wrote: > void * > malloc(size, type, flags) > unsigned long size; > struct malloc_type *type; > int flags; > > i understand the size and flags but what shall i > do with the malloc_type. man 9 malloc It is used to do basic sanity checking and for statistics. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2003707.nlPXxie13S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDU5pD5ZPcIHs/zowRAvpWAKCW3QGmJhQRgjvzEJ0UAdM6R0dlzACfZx4v 4exRzp88/K58i47YpCTUJ9o= =9elw -----END PGP SIGNATURE----- --nextPart2003707.nlPXxie13S-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 13:11:23 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88A7516A41F for ; Mon, 17 Oct 2005 13:11:23 +0000 (GMT) (envelope-from peter@alastria.net) Received: from pigwidgeon.lancs.ac.uk (pigwidgeon.lancs.ac.uk [148.88.0.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 694A143D5C for ; Mon, 17 Oct 2005 13:11:19 +0000 (GMT) (envelope-from peter@alastria.net) Received: from exchange-fe1.lancs.ac.uk ([148.88.1.22] helo=exchange-fe1.lancs.local) by pigwidgeon.lancs.ac.uk with esmtp (Exim 4.52) id 1ERUln-0005jl-ED for net@freebsd.org; Mon, 17 Oct 2005 14:11:15 +0100 Received: from [148.88.132.153] ([148.88.132.153]) by exchange-fe1.lancs.local with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 Oct 2005 14:11:12 +0100 Message-ID: <4353A2F5.8040108@alastria.net> Date: Mon, 17 Oct 2005 14:11:17 +0100 From: Peter Wood User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2005 13:11:12.0894 (UTC) FILETIME=[3F9101E0:01C5D31C] Cc: Subject: More then 32 bfp devices on Freebsd 5.4-RELEASE-p7 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, 17 Oct 2005 13:11:23 -0000 Good Afternoon, I'm now working at a large UK university in their network support department, as such one of my duties is to monitor the residences network. To this end I have a cloned nic for every vlan that we have on resnet. It roughly comes to over 50 vlans, and FreeBSD its self copes very nicely. However I've run into a small problem when using nmap (and a tiny one in Ethereal). Unless you specify the source address and source interface for scans nmap will open every network device with bpf. The problem comes when it hits the 33rd interface to open, nmap exits. [eclair:~]# nmap -P0 -p 1-65535 -sS 10.34.96.168 Starting nmap 3.93 ( http://www.insecure.org/nmap/ ) at 2005-10-17 14:03 BST getinterfaces: Failed to open ethernet interface (resnet737) QUITTING! If I truss I get the following: open("/dev/bpf29",0x1,01002230274) ERR#16 'Device busy' open("/dev/bpf30",0x1,01002230274) ERR#16 'Device busy' open("/dev/bpf31",0x1,01002230274) ERR#16 'Device busy' write(2,0xbfbfab40,60) = 60 (0x3c) getinterfaces: Failed to open ethernet interface (resnet737) So the question is, how can I allow more then 32 bpf devices, in the old 4.X series I'd have just tagged a number on the end of the kernel line. Any suggestions apreciated, Pete. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 13:31:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5283616A41F; Mon, 17 Oct 2005 13:31:19 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83E8D43D46; Mon, 17 Oct 2005 13:31:18 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp211-138.lns1.adl2.internode.on.net [203.122.211.138]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j9HDVFuO040733 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 17 Oct 2005 23:01:15 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Mon, 17 Oct 2005 23:01:03 +0930 User-Agent: KMail/1.8.2 References: <20051017122657.58723.qmail@web35703.mail.mud.yahoo.com> In-Reply-To: <20051017122657.58723.qmail@web35703.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1889844.n68iqsc57Q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510172301.10658.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: kamal kc , freebsd-net@freebsd.org Subject: Re: malloc() in kernel and increasing mbuf and cluster size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 13:31:19 -0000 --nextPart1889844.n68iqsc57Q Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 17 Oct 2005 21:56, kamal kc wrote: > the man pages use M_FOOBUF(where did it come from ??) > in the field type. 'foo' is a generic term for a random variable name. > Now how should i code it. > > struct malloc_type mytype; > mytype=3DMALLOC_DEFINE(.....,"mybuffers","mybuffers"); > > what should i put in the type field ?? Read the man page!! /* sys/something/foo_extern.h */ MALLOC_DECLARE(M_FOOBUF); /* sys/something/foo_main.c */ MALLOC_DEFINE(M_FOOBUF, "foobuffers", "Buffers to foo data into the ether"); /* sys/something/foo_subr.c */ ... MALLOC(buf, struct foo_buf *, sizeof *buf, M_FOOBUF, M_NOWAIT); Read other code, there are plenty of examples in the tree. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1889844.n68iqsc57Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDU6ee5ZPcIHs/zowRAnuYAJ9GwEylrj8dC3y2wpxVWwXvnwGeuwCgh0L2 +iRcqEliPhd21JD6ENAZF7Y= =KgSV -----END PGP SIGNATURE----- --nextPart1889844.n68iqsc57Q-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 16:59:23 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AB6616A422 for ; Mon, 17 Oct 2005 16:59:23 +0000 (GMT) (envelope-from sangwoos@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E98743D49 for ; Mon, 17 Oct 2005 16:59:22 +0000 (GMT) (envelope-from sangwoos@gmail.com) Received: by qproxy.gmail.com with SMTP id a39so825442qbd for ; Mon, 17 Oct 2005 09:59:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oxstNY7AEnesA0sQB6zdMBEKrD/Hsn8vZ+/A0kmTXr9yNeH2ajBcUi35GrrsZfR/4YKKYK2aAylX1l/i+S6uShKbfgqC19QfKu3xxH+fIYI1Q4UzIEZ0pC4a6uMbMrObywzH7gM4cCexjBfn8Q1ldDIvlmAO6dSXibmSu4D0WAM= Received: by 10.65.119.7 with SMTP id w7mr2161170qbm; Mon, 17 Oct 2005 09:59:21 -0700 (PDT) Received: by 10.65.52.5 with HTTP; Mon, 17 Oct 2005 09:59:21 -0700 (PDT) Message-ID: <4cbd01f40510170959l30f90bc1k@mail.gmail.com> Date: Tue, 18 Oct 2005 01:59:21 +0900 From: Sangwoo Shim To: kamal kc In-Reply-To: <20051017122657.58723.qmail@web35703.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051017120734.GA820@taran.infoua.com.ua> <20051017122657.58723.qmail@web35703.mail.mud.yahoo.com> Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: malloc() in kernel and increasing mbuf and cluster size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 16:59:23 -0000 2005/10/17, kamal kc : > > > sys/malloc.h has function prototypes for malloc() > > > kern/kern_malloc.c defines the malloc() > > > > > > the malloc() definition is > > > > > > void * > > > malloc(size, type, flags) > > > unsigned long size; > > > struct malloc_type *type; > > > int flags; > > > > > > i understand the size and flags but what shall i > > > do with the malloc_type. > > > > man 9 malloc :-) > > > > i saw the man pages. > > it says to use malloc_type via > > MALLOC_DEFINE(type,shortdesc,longdesc) > MALLOC_DECLARE(type) > > the man pages use M_FOOBUF(where did it come from ??) > in the field type. > > Now how should i code it. > > struct malloc_type mytype; > mytype=3DMALLOC_DEFINE(.....,"mybuffers","mybuffers"); > > what should i put in the type field ?? > > thanks in advance, > kamal malloc type is defined for some kind of statistics/trackings. If you define some specific malloc types for your module/driver etc., you can track the memory usage more accurately. For example, if you do vmstat -= m you can see how much memories are used for specific allocations by looking at type field. Regards, Sangwoo Shim > > > > > > > > > __________________________________ > Yahoo! Music Unlimited > Access over 1 million songs. Try it free. > http://music.yahoo.com/unlimited/ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 17:04:09 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4992F16A41F for ; Mon, 17 Oct 2005 17:04:09 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92D9443D80 for ; Mon, 17 Oct 2005 17:04:00 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id 85E01BC020; Mon, 17 Oct 2005 20:03:59 +0300 (EEST) Received: from [10.0.0.1] (vdp1003.ath03.dsl.hol.gr [62.38.168.4])by smtp.freemail.gr (Postfix) with ESMTP id B1FA7BC017; Mon, 17 Oct 2005 20:03:58 +0300 (EEST) Message-ID: <4353D969.1010106@freemail.gr> Date: Mon, 17 Oct 2005 20:03:37 +0300 From: Chris Dionissopoulos User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Strik References: <4353765C.4030802@freemail.gr> <20051017101430.GH41710@stack.nl> In-Reply-To: <20051017101430.GH41710@stack.nl> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: What's wrong with netgraph NG_FWD_NEW_DATA? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dionch@freemail.gr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 17:04:09 -0000 Dean, You 're right about using a unicast mac address , but after doing that it goes even worse. It seems that ngeth0 denies to accept (and forward to upper layers) to any traffic sees, for some reason. After placing static arp entries in both boxes (freebsd+remote) i have the same behavior (as multicast): o physical interface works fine(traffic flows on both directions). o app:stack-->ngeth0:ng0---->xl0:low--->wire [WORKS] o wire --->xl0:low--->ng0:ngeth0--->stack:app [FAILED] tcpdump here(ngeth0) shows traffic (incomming only) I'm really stuck here... Chris. Dean Strik wrote: >Chris Dionissopoulos wrote: > > >>and for every ng_eiface node you attach you must provide a >>mac address for filtering (later this will be automated). >> >> >[..] > > >>gw0#ifconfig ngeth0 >>ngeth0: >>flags=28943 mtu >>1500 >> inet6 fe80::260:8ff:fee8:589e%ngeth0 prefixlen 64 scopeid 0x6 >> inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 >> ether 01:02:03:04:05:00 >> >>Traffic initiated localy flows prefectly through ngeth0 and xl0 >>interfaces, but >>this is not happen for traffic that comes from outside. It seems that >>doesn't >>arrive to ngeth0 upper level protocols. >> >> > >Haven't looked at the code, but I'm just wondering here... this MAC >address is a multicast address, not a unicast one. Should that work as >expected at all? > > > ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 18:13:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E358F16A41F for ; Mon, 17 Oct 2005 18:13:34 +0000 (GMT) (envelope-from zanecb@midwest-connections.com) Received: from mail.midwest-connections.com (mail.midwest-connections.com [69.148.152.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 69D5C43D46 for ; Mon, 17 Oct 2005 18:13:34 +0000 (GMT) (envelope-from zanecb@midwest-connections.com) Received: (qmail 28861 invoked from network); 17 Oct 2005 18:13:04 -0000 Received: from unknown (HELO mwc-acomputer) (zanecb@69.155.32.130) by 0 with SMTP; 17 Oct 2005 18:13:04 -0000 Date: Mon, 17 Oct 2005 13:13:35 -0500 From: "Zane C. B." To: G Bryant Message-ID: <20051017131335.0000239b@mwc-acomputer> In-Reply-To: <4350BC26.6030406@roamingsolutions.net> References: <20051014142223.000048c8@mwc-acomputer> <4350BC26.6030406@roamingsolutions.net> X-Mailer: Sylpheed-Claws 1.0.4.1 Win32 (GTK+ 1.3.0; Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: How would I go about routing something like this? 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, 17 Oct 2005 18:13:35 -0000 Yeah, currently got it setup like that. What I want to do is to route all traffic out through the secondary machine, for packets originating from a specific IP#. So the main router routes packets coming in from some IP#s to the secondary one for filtering. This possible or not workable? Been reading and I am not seeing any thing about how this would be achieved. On Sat, 15 Oct 2005 10:21:58 +0200 G Bryant wrote: > You can either use ipfw fwd command (has to be enabled in the kernel), > where you forward all lan incoming packets with destination port 80, to > the ip and port that the other proxy is listening on, > or (more complicated) you can use squid proxy on your local machine, use > ipfw to fwd all lan incoming packets with destination port 80 to the > port that squid is listening on (normally 3128), and then you have to > specify in the squid config that it must use a different proxy as it's > "parent" proxy. You could then either enable caching on this machine, > or configure it as a "dummy" proxy. > You will probably have to read all the man pages anyway, so use this as > a starting point. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 19:51:30 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAF6016A41F; Mon, 17 Oct 2005 19:51:30 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7254643D49; Mon, 17 Oct 2005 19:51:30 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9HJpUMo010419; Mon, 17 Oct 2005 12:51:30 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9HJpUWN010418; Mon, 17 Oct 2005 12:51:30 -0700 Date: Mon, 17 Oct 2005 12:51:30 -0700 From: Brooks Davis To: "Cai, Quanqing" Message-ID: <20051017195130.GC15097@odin.ac.hmc.edu> References: <2b22951e0510141758x1edef8jf7caf2514c336514@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="69pVuxX8awAiJ7fD" Content-Disposition: inline In-Reply-To: <2b22951e0510141758x1edef8jf7caf2514c336514@mail.gmail.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org, Tai-hwa Liang , freebsd-firewire@freebsd.org, freebsd-arch@freebsd.org Subject: Re: fwe -> fwip in GENERIC? 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, 17 Oct 2005 19:51:31 -0000 --69pVuxX8awAiJ7fD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2005 at 05:58:38PM -0700, Cai, Quanqing wrote: > Hi guys, >=20 > When I was fixing bug kern/82727: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/82727, I found we use > fwe(Ethernet over FireWire) in GENERIC kernel, not fwip(IP over FireWire). > But we all know that IP over FireWire is more widely used on other OSes, = and > now this bug is fixed, do we need change fwe to fwip? >=20 > I talked it with Tai-hwa Liang, he agrees with me. But he suggests me to > post here for more advices, since there might be some considerations such > like backward compatibility or code size that makes re@ made this decisio= n. >=20 > Please give you advice or opinion. Are they incompatable? If no, just add fwip. If so, can that be fixed? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --69pVuxX8awAiJ7fD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDVADBXY6L6fI4GtQRAlHWAJ9M1sCnd5LVyPe+YG9561awzvqLmACgqGWB BkMcZ2xlzrY/KNJLRvLUr6w= =5qnA -----END PGP SIGNATURE----- --69pVuxX8awAiJ7fD-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 22:14:46 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0253416A41F for ; Mon, 17 Oct 2005 22:14:46 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 898E943D46 for ; Mon, 17 Oct 2005 22:14:45 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9HMEdVP027317; Mon, 17 Oct 2005 15:14:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9HMEdsq027316; Mon, 17 Oct 2005 15:14:39 -0700 Date: Mon, 17 Oct 2005 15:14:39 -0700 From: Brooks Davis To: Peter Wood Message-ID: <20051017221439.GJ15097@odin.ac.hmc.edu> References: <4353A2F5.8040108@alastria.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4353A2F5.8040108@alastria.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: net@freebsd.org Subject: Re: More then 32 bfp devices on Freebsd 5.4-RELEASE-p7 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, 17 Oct 2005 22:14:46 -0000 On Mon, Oct 17, 2005 at 02:11:17PM +0100, Peter Wood wrote: > Good Afternoon, > > I'm now working at a large UK university in their network support > department, as such one of my duties is to monitor the residences > network. To this end I have a cloned nic for every vlan that we have on > resnet. It roughly comes to over 50 vlans, and FreeBSD its self copes > very nicely. > > However I've run into a small problem when using nmap (and a tiny one in > Ethereal). Unless you specify the source address and source interface > for scans nmap will open every network device with bpf. The problem > comes when it hits the 33rd interface to open, nmap exits. > > [eclair:~]# nmap -P0 -p 1-65535 -sS 10.34.96.168 > Starting nmap 3.93 ( http://www.insecure.org/nmap/ ) at 2005-10-17 14:03 BST > getinterfaces: Failed to open ethernet interface (resnet737) > QUITTING! > > If I truss I get the following: > > open("/dev/bpf29",0x1,01002230274) ERR#16 'Device busy' > open("/dev/bpf30",0x1,01002230274) ERR#16 'Device busy' > open("/dev/bpf31",0x1,01002230274) ERR#16 'Device busy' > write(2,0xbfbfab40,60) = 60 (0x3c) > getinterfaces: Failed to open ethernet interface (resnet737) > > So the question is, how can I allow more then 32 bpf devices, in the old > 4.X series I'd have just tagged a number on the end of the kernel line. Hmm, I can create more than 32 devices here and the only place the code returns EBUSY is where more than one process attempts to open the same device so there's something unobvious going on in nmap. There should be no real practical limit on bpf devices. -- Brooks From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 05:21:25 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4D7716A41F for ; Tue, 18 Oct 2005 05:21:25 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id D499D43D45 for ; Tue, 18 Oct 2005 05:21:24 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j9I5LH74087432; Tue, 18 Oct 2005 09:21:18 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j9I5LHQZ087431; Tue, 18 Oct 2005 09:21:17 +0400 (MSD) (envelope-from yar) Date: Tue, 18 Oct 2005 09:21:16 +0400 From: Yar Tikhiy To: Peter Wood Message-ID: <20051018052116.GI40896@comp.chem.msu.su> References: <4353A2F5.8040108@alastria.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4353A2F5.8040108@alastria.net> User-Agent: Mutt/1.5.9i Cc: net@freebsd.org Subject: Re: More then 32 bfp devices on Freebsd 5.4-RELEASE-p7 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, 18 Oct 2005 05:21:25 -0000 On Mon, Oct 17, 2005 at 02:11:17PM +0100, Peter Wood wrote: > Good Afternoon, > > I'm now working at a large UK university in their network support > department, as such one of my duties is to monitor the residences > network. To this end I have a cloned nic for every vlan that we have on > resnet. It roughly comes to over 50 vlans, and FreeBSD its self copes > very nicely. > > However I've run into a small problem when using nmap (and a tiny one in > Ethereal). Unless you specify the source address and source interface > for scans nmap will open every network device with bpf. The problem > comes when it hits the 33rd interface to open, nmap exits. > > [eclair:~]# nmap -P0 -p 1-65535 -sS 10.34.96.168 > Starting nmap 3.93 ( http://www.insecure.org/nmap/ ) at 2005-10-17 14:03 BST > getinterfaces: Failed to open ethernet interface (resnet737) > QUITTING! > > If I truss I get the following: > > open("/dev/bpf29",0x1,01002230274) ERR#16 'Device busy' > open("/dev/bpf30",0x1,01002230274) ERR#16 'Device busy' > open("/dev/bpf31",0x1,01002230274) ERR#16 'Device busy' > write(2,0xbfbfab40,60) = 60 (0x3c) > getinterfaces: Failed to open ethernet interface (resnet737) > > So the question is, how can I allow more then 32 bpf devices, in the old > 4.X series I'd have just tagged a number on the end of the kernel line. This is an obvious regression in nmap 3.93, which wasn't there before. Here's the relevant part of eth-bsd.c found in nmap-3.93/libdnet-stripped/src: for (i = 0; i < 32; i++) { snprintf(file, sizeof(file), "/dev/bpf%d", i); e->fd = open(file, O_WRONLY); if (e->fd != -1 || errno != EBUSY) break; } -- Yar From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 07:50:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D4D716A421; Tue, 18 Oct 2005 07:50:57 +0000 (GMT) (envelope-from jan@melen.org) Received: from foxgw.melen.org (Savi-Mel.dna.fi [83.143.60.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFC1543D64; Tue, 18 Oct 2005 07:50:46 +0000 (GMT) (envelope-from jan@melen.org) Received: from [2001:14b8:400:101:208:74ff:fee4:decb] ([IPv6:2001:14b8:400:101:208:74ff:fee4:decb]) (authenticated bits=0) by foxgw.melen.org (8.13.4/8.13.4) with ESMTP id j9I7oWfV024775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Oct 2005 10:50:43 +0300 (EEST) (envelope-from jan@melen.org) From: Jan Mikael Melen To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Date: Tue, 18 Oct 2005 10:50:24 +0300 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510181050.27530.jan@melen.org> X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on foxgw.melen.org X-Virus-Status: Clean Cc: Subject: Unique IPsec security policies 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, 18 Oct 2005 07:50:57 -0000 Hi, Is there a reason why the policies that are defined as unique can't be updated through the pfkey interface? What I'm trying to do is that: 1. I create SP entry and let the kernel assign a request id for policy (reqid in the add is 0). This policy is a tunnel mode policy and I don't have the outer addresses set at this point. Only the inner addresses are set so I'll get the SADB_AQUIRE message with the inner addresses. 2. When my keying daemon get's the acquire from the kernel I run the key exchange and then I send update to the SP with previously gotten reqid and with outer addresses but it fails and kernel prints out: "key_msg2sp: reqid=16384 range violation, updated by kernel." This message comes from the sys/netkey/key.c:1488. It's obvious when I'm adding a new SP entry that this check is done but when updating the SP shouldn't it just check that the value given in update matches the one assigned earlier? Cheers, Jan From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 08:22:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D05916A420 for ; Tue, 18 Oct 2005 08:22:34 +0000 (GMT) (envelope-from yvan.vanhullebus@netasq.com) Received: from smtp.netasq.com (netasq.netasq.com [213.30.137.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A8843D46 for ; Tue, 18 Oct 2005 08:22:33 +0000 (GMT) (envelope-from yvan.vanhullebus@netasq.com) Received: from [10.0.0.126] (unknown [10.0.0.4]) by smtp.netasq.com (Postfix) with ESMTP id C9E3D201BF for ; Tue, 18 Oct 2005 10:19:35 +0200 (CEST) Received: by yvan.netasq.int (Postfix, from userid 1000) id 20A7354A6; Tue, 18 Oct 2005 10:22:30 +0200 (CEST) Date: Tue, 18 Oct 2005 10:22:30 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20051018082230.GA61303@yvan.netasq.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510181050.27530.jan@melen.org> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Unique IPsec security policies 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, 18 Oct 2005 08:22:34 -0000 On Tue, Oct 18, 2005 at 10:50:24AM +0300, Jan Mikael Melen wrote: > Hi, > > Is there a reason why the policies that are defined as unique can't be updated > through the pfkey interface? > > What I'm trying to do is that: > 1. I create SP entry and let the kernel assign a request id for policy (reqid > in the add is 0). This policy is a tunnel mode policy and I don't have the > outer addresses set at this point. Only the inner addresses are set so I'll > get the SADB_AQUIRE message with the inner addresses. Not sure I understood what you are exactly doing, and *why* you want to do that... > 2. When my keying daemon get's the acquire from the kernel I run the key > exchange and then I send update to the SP with previously gotten reqid and > with outer addresses but it fails and kernel prints out: > "key_msg2sp: reqid=16384 range violation, updated by kernel." > This message comes from the sys/netkey/key.c:1488. It's obvious when I'm > adding a new SP entry that this check is done but when updating the SP > shouldn't it just check that the value given in update matches the one > assigned earlier? Perhaps you should just force manual reqids < IPSEC_MANUAL_REQID_MAX when creating your SP entries. In one hand, you're right: when updating SP entries, it can make sense to just ensure that the reqid is the same. In the other hand, as you used some automatic values while creating the SP entry (so, in fact, as you said "I let the kernel do that stuff"), it can be logic to not allow you to do "some non common things" after, even if you want to update it.... Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 08:54:36 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0561916A41F for ; Tue, 18 Oct 2005 08:54:36 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3D5443D46 for ; Tue, 18 Oct 2005 08:54:34 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id 6302EA3F8F for ; Tue, 18 Oct 2005 10:54:32 +0200 (CEST) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18471-07 for ; Tue, 18 Oct 2005 10:54:32 +0200 (CEST) Received: from [192.168.1.159] (unknown [192.168.1.159]) by mail.packetfront.com (Postfix) with ESMTP id 37F50A3F44 for ; Tue, 18 Oct 2005 10:54:32 +0200 (CEST) Message-ID: <4354B7E1.9080708@packetfront.com> Date: Tue, 18 Oct 2005 10:52:49 +0200 From: Ragnar Lonn User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en 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 amavisd-new-20030616-p10 (Debian) at packetfront.com Subject: ngctl: send msg: No buffer space available 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, 18 Oct 2005 08:54:36 -0000 Hi all, I've run into the above problem with Netgraph on a FreeBSD 4.11 system. I know there are sysctl's (net.graph.recvspace and net.graph.maxdgram) you can set in 5.x but how can I get around this problem on a 4.x machine where these sysctl variables dont exist? Regards, /Ragnar From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 10:32:34 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4634716A41F for ; Tue, 18 Oct 2005 10:32:34 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F7843D48 for ; Tue, 18 Oct 2005 10:32:33 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9IAWVrb006814; Tue, 18 Oct 2005 13:32:31 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 94708-03-2; Tue, 18 Oct 2005 13:32:26 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9IASrnK006642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2005 13:28:53 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id j9IASnLF015920; Tue, 18 Oct 2005 13:28:49 +0300 (EEST) (envelope-from ru) Date: Tue, 18 Oct 2005 13:28:49 +0300 From: Ruslan Ermilov To: Ragnar Lonn Message-ID: <20051018102849.GD57000@ip.net.ua> References: <4354B7E1.9080708@packetfront.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M38YqGLZlgb6RLPS" Content-Disposition: inline In-Reply-To: <4354B7E1.9080708@packetfront.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-net@FreeBSD.org Subject: Re: ngctl: send msg: No buffer space available 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, 18 Oct 2005 10:32:34 -0000 --M38YqGLZlgb6RLPS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2005 at 10:52:49AM +0200, Ragnar Lonn wrote: > Hi all, >=20 > I've run into the above problem with Netgraph on a FreeBSD 4.11 system.= =20 > I know there > are sysctl's (net.graph.recvspace and net.graph.maxdgram) you can set in= =20 > 5.x but how > can I get around this problem on a 4.x machine where these sysctl=20 > variables dont exist? >=20 They do exist for sure: $ uname -r 4.11-STABLE $ sysctl net.graph net.graph.abi_version: 2 net.graph.msg_version: 2 net.graph.maxdgram: 20480 net.graph.recvspace: 20480 net.graph.family: 32 net.graph.data.proto: 1 net.graph.control.proto: 2 Perhaps the ng_socket.ko module isn't loaded? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --M38YqGLZlgb6RLPS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDVM5hqRfpzJluFF4RAq2rAJ9ffvAi78+ODkCKSpA4lt1Rwijr5wCfSvCl P9+C8RK2by+f6sXK9ATNOd8= =D5+8 -----END PGP SIGNATURE----- --M38YqGLZlgb6RLPS-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 10:41:27 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E6E416A41F; Tue, 18 Oct 2005 10:41:27 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id E399743D46; Tue, 18 Oct 2005 10:41:26 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id F135EA3F94; Tue, 18 Oct 2005 12:41:24 +0200 (CEST) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23191-07; Tue, 18 Oct 2005 12:41:24 +0200 (CEST) Received: from [192.168.1.159] (unknown [192.168.1.159]) by mail.packetfront.com (Postfix) with ESMTP id 54309A3F8D; Tue, 18 Oct 2005 12:41:24 +0200 (CEST) Message-ID: <4354D0ED.3030200@packetfront.com> Date: Tue, 18 Oct 2005 12:39:41 +0200 From: Ragnar Lonn User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <4354B7E1.9080708@packetfront.com> <20051018102849.GD57000@ip.net.ua> In-Reply-To: <20051018102849.GD57000@ip.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Cc: freebsd-net@FreeBSD.org Subject: Re: ngctl: send msg: No buffer space available 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, 18 Oct 2005 10:41:27 -0000 Ruslan Ermilov wrote: >On Tue, Oct 18, 2005 at 10:52:49AM +0200, Ragnar Lonn wrote: > > >>Hi all, >> >>I've run into the above problem with Netgraph on a FreeBSD 4.11 system. >>I know there >>are sysctl's (net.graph.recvspace and net.graph.maxdgram) you can set in >>5.x but how >>can I get around this problem on a 4.x machine where these sysctl >>variables dont exist? >> >> >> >They do exist for sure: > >Perhaps the ng_socket.ko module isn't loaded? > > > Oops. "kldload ng_socket" made things a lot better, thanks :) I was a bit perplexed as I checked the ng_socket code and saw it reading those variables but I couldn't set them with sysctl. Didn't think about checking whether the module was actually loaded... /Ragnar From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 12:21:27 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A260716A41F; Tue, 18 Oct 2005 12:21:27 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BABE43D46; Tue, 18 Oct 2005 12:21:26 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.3/8.13.3/NinthNine) with ESMTP id j9ICLN6p055540; Tue, 18 Oct 2005 21:21:25 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Tue, 18 Oct 2005 21:21:23 +0900 From: Norikatsu Shigemura To: Doug Rabson Message-Id: <20051018212123.8865775e.nork@FreeBSD.org> In-Reply-To: <200510171012.20801.dfr@nlsystems.com> References: <2b22951e0510141758x1edef8jf7caf2514c336514@mail.gmail.com> <200510171012.20801.dfr@nlsystems.com> X-Mailer: Sylpheed version 2.1.3 (GTK+ 2.6.10; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sakura.ninth-nine.com [219.127.74.121]); Tue, 18 Oct 2005 21:21:25 +0900 (JST) Cc: freebsd-net@FreeBSD.org, avatar@mmlab.cse.yzu.edu.tw, freebsd-firewire@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: fwe -> fwip in GENERIC? 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, 18 Oct 2005 12:21:27 -0000 On Mon, 17 Oct 2005 10:12:18 +0100 Doug Rabson wrote: > The fwip implementation should be fully compatible with the RFC > standard. I'm happy for fwip to replace fwe in GENERIC unless anyone > else has an objection. I disagree. Because fwip and fwe can exist together. So I think that fwip should be added to GENERIC. > On Saturday 15 October 2005 03:35, Katsushi Kobayashi wrote: > > Hi, > > > > Although I don't know the detail of fwe technology, I understand the > > technology is a proprietary one. It is better to provide a > > compatibility with RFC standard firewire over IP, if some volunteer > > are there. > > > > On 2005/10/15, at 9:58, Cai, Quanqing wrote: > > > Hi guys, > > > > > > When I was fixing bug kern/82727: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82727, I found we > > > use fwe(Ethernet over FireWire) in GENERIC kernel, not fwip(IP over > > > FireWire). > > > But we all know that IP over FireWire is more widely used on other > > > OSes, and > > > now this bug is fixed, do we need change fwe to fwip? > > > > > > I talked it with Tai-hwa Liang, he agrees with me. But he suggests > > > me to > > > post here for more advices, since there might be some > > > considerations such > > > like backward compatibility or code size that makes re@ made this > > > decision. > > > > > > Please give you advice or opinion. > > > > > > Best > > > Cai, Quanqing > > > _______________________________________________ > > > freebsd-arch@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > > To unsubscribe, send any mail to "freebsd-arch- > > > unsubscribe@freebsd.org" > > > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to > > "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-firewire@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-firewire > To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 12:34:04 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D245B16A41F; Tue, 18 Oct 2005 12:34:04 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11CB743D45; Tue, 18 Oct 2005 12:34:03 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from [192.168.1.254] (dhcp254.qubesoft.com [192.168.1.254]) by mail.qubesoft.com (8.13.3/8.13.3) with ESMTP id j9ICXnVZ063816; Tue, 18 Oct 2005 13:33:49 +0100 (BST) (envelope-from dfr@nlsystems.com) In-Reply-To: <20051018212123.8865775e.nork@FreeBSD.org> References: <2b22951e0510141758x1edef8jf7caf2514c336514@mail.gmail.com> <200510171012.20801.dfr@nlsystems.com> <20051018212123.8865775e.nork@FreeBSD.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Doug Rabson Date: Tue, 18 Oct 2005 13:33:48 +0100 To: Norikatsu Shigemura X-Mailer: Apple Mail (2.734) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.qubesoft.com X-Virus-Scanned: ClamAV 0.86.2/1142/Tue Oct 18 08:21:37 2005 on mail.qubesoft.com X-Virus-Status: Clean Cc: freebsd-net@FreeBSD.org, avatar@mmlab.cse.yzu.edu.tw, freebsd-firewire@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: fwe -> fwip in GENERIC? 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, 18 Oct 2005 12:34:05 -0000 On 18 Oct 2005, at 13:21, Norikatsu Shigemura wrote: > On Mon, 17 Oct 2005 10:12:18 +0100 > Doug Rabson wrote: > >> The fwip implementation should be fully compatible with the RFC >> standard. I'm happy for fwip to replace fwe in GENERIC unless anyone >> else has an objection. >> > > I disagree. Because fwip and fwe can exist together. > So I think that fwip should be added to GENERIC. Sure - both drivers are tiny and they don't step on each others toes. Longer term, I think we should try to phase out the fwe driver since it doesn't interoperate with any other systems (except Df, I guess). From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 13:48:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3811316A41F for ; Tue, 18 Oct 2005 13:48:18 +0000 (GMT) (envelope-from jan@melen.org) Received: from foxgw.melen.org (Savi-Mel.dna.fi [83.143.60.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7055643D45 for ; Tue, 18 Oct 2005 13:48:17 +0000 (GMT) (envelope-from jan@melen.org) Received: from [2001:14b8:400:101:208:74ff:fee4:decb] ([IPv6:2001:14b8:400:101:208:74ff:fee4:decb]) (authenticated bits=0) by foxgw.melen.org (8.13.4/8.13.4) with ESMTP id j9IDm3hP029247 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 18 Oct 2005 16:48:15 +0300 (EEST) (envelope-from jan@melen.org) From: Jan Mikael Melen To: freebsd-net@freebsd.org Date: Tue, 18 Oct 2005 16:47:27 +0300 User-Agent: KMail/1.8 References: <20051018082230.GA61303@yvan.netasq.int> In-Reply-To: <20051018082230.GA61303@yvan.netasq.int> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200510181647.29627.jan@melen.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on foxgw.melen.org X-Virus-Status: Clean Subject: Re: Unique IPsec security policies 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, 18 Oct 2005 13:48:18 -0000 Hi, On Tuesday 18 October 2005 11:22, VANHULLEBUS Yvan wrote: > On Tue, Oct 18, 2005 at 10:50:24AM +0300, Jan Mikael Melen wrote: > > What I'm trying to do is that: > > 1. I create SP entry and let the kernel assign a request id for policy > > (reqid in the add is 0). This policy is a tunnel mode policy and I don't > > have the outer addresses set at this point. Only the inner addresses are > > set so I'll get the SADB_AQUIRE message with the inner addresses. > > Not sure I understood what you are exactly doing, and *why* you want > to do that... For the why part my answer would be that it's because I don't necessarily know the end-points address before hand. The keying protocol will take care of resolving the address. This is just some experimental stuff I'm working with (ref. http://www.ietf.org/internet-drafts/draft-ietf-hip-arch-03.txt). > > 2. When my keying daemon get's the acquire from the kernel I run the key > > exchange and then I send update to the SP with previously gotten reqid > > and with outer addresses but it fails and kernel prints out: > > "key_msg2sp: reqid=16384 range violation, updated by kernel." > > This message comes from the sys/netkey/key.c:1488. It's obvious when I'm > > adding a new SP entry that this check is done but when updating the SP > > shouldn't it just check that the value given in update matches the one > > assigned earlier? > > Perhaps you should just force manual reqids < IPSEC_MANUAL_REQID_MAX > when creating your SP entries. Always a possiblity but then I would have to know that wheter this value is already being used. So I would prefer that the kernel would assign the values for me, as it is obviously the one whom knows which reqids are already in use. > In one hand, you're right: when updating SP entries, it can make sense > to just ensure that the reqid is the same. > > In the other hand, as you used some automatic values while creating > the SP entry (so, in fact, as you said "I let the kernel do that > stuff"), it can be logic to not allow you to do "some non common > things" after, even if you want to update it.... If this is the case it will make atleast my life a bit harder :-) I think that not allowing the SP to updated might cause also problems with mobike. Cheers, Jan From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 17:51:37 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 723F516A41F for ; Tue, 18 Oct 2005 17:51:37 +0000 (GMT) (envelope-from extech@dod.co.za) Received: from ns2.trimail.co.za (ns2.trimail.co.za [196.25.53.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0A7743D46 for ; Tue, 18 Oct 2005 17:51:32 +0000 (GMT) (envelope-from extech@dod.co.za) Received: from tridan-tsqduwdt (gateway.trimail.co.za [196.25.53.66]) by ns2.trimail.co.za (8.12.9p1/8.12.9) with ESMTP id j9IHgQHx012641 for ; Tue, 18 Oct 2005 19:42:49 +0200 (SAST) (envelope-from extech@dod.co.za) Message-ID: <200510181954020250.00A66152@196.25.53.68> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 18 Oct 2005 19:54:02 +0200 From: "Anton Bester" To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV 0.80/1141/Mon Oct 17 23:38:45 2005 clamav-milter version 0.80j on ns2.trimail.co.za X-Virus-Status: Clean Subject: Bind 8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: extech@dod.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2005 17:51:37 -0000 Hi All, I do not know if this is the correct forum for this questions, if not= please point me in the right direction. My secondary DNS server all of a sudden started to chop up about 100% of my= server's cpu, I'm running a FreeBSD 5.1-RELEASE server with Bind 8. It was= doning fine until I noticed that the sever's cpu running near 100%, it= turned out to be bind. When I restart bind it takes a couple of minutes but then it is back at 70%= - 100% with a lot of traffic being send to my primary DNS server, I have= noticed the following error in the Primary DNS log file: Oct 18 12:24:01 ns /kernel: Limiting icmp unreach response from 315 to 200= packets per second Oct 18 12:24:02 ns /kernel: Limiting icmp unreach response from 259 to 200= packets per second Oct 18 12:24:03 ns /kernel: Limiting icmp unreach response from 223 to 200= packets per second The above disapeared when I have stop bind on the secondary server. The following is a tcpdump from the secondary when bind is running: 19:11:57.499201 PRIMARY.SERVER.3177 > SECONDARY.SERVER.domain: 45643+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.499586 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 57396+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.501314 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 46641+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.501435 PRIMARY.SERVER.3177 > SECONDARY.SERVER.domain: 15653+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.503114 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 9949+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.503140 PRIMARY.SERVER.3177 > SECONDARY.SERVER.domain: 37941+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.504878 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 9772+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.504925 PRIMARY.SERVER.3177 > SECONDARY.SERVER.domain: 48193+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.506677 PRIMARY.SERVER.3177 > SECONDARY.SERVER.domain: 1059+ [1au]= PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.506811 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 32623+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.508561 SECONDARY.SERVER.domain > PRIMARY.SERVER.3177: 28517 1/4/1= (217) 19:11:57.508643 PRIMARY.SERVER.3177 > SECONDARY.SERVER.domain: 63119+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.509849 PRIMARY.SERVER.domain > SECONDARY.SERVER.52770: 28288= 1/4/1 (217) 19:11:57.510078 SECONDARY.SERVER.domain > PRIMARY.SERVER.3177: 13104 1/4/1= (217) 19:11:57.511345 SECONDARY.SERVER.domain > PRIMARY.SERVER.3177: 43705 1/4/1= (217) 19:11:57.511493 PRIMARY.SERVER.domain > SECONDARY.SERVER.52770: 48426= 1/4/1 (217) 19:11:57.512702 SECONDARY.SERVER.domain > PRIMARY.SERVER.3177: 59554 1/4/1= (217) 19:11:57.513345 PRIMARY.SERVER.domain > SECONDARY.SERVER.52770: 48467= 1/4/1 (217) 19:11:57.514387 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 43310+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.515025 PRIMARY.SERVER.domain > SECONDARY.SERVER.52770: 16747= 1/4/1 (217) 19:11:57.523654 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 40443+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.525204 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 24062+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.526786 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 55218+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.528310 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 8947+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.529826 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 30856+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.531340 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 33843+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.532870 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 24256+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.534386 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 64054+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) 19:11:57.536038 SECONDARY.SERVER.52770 > PRIMARY.SERVER.domain: 65247+= [1au] PTR? 74.112.10.196.in-addr.arpa. (55) The same is happening on the Primary Server, when bind is running on the= secondary the cpu of the primary shot up to 70%-100% with the same sort of= tcpdump info as above. Do anybody have an idea what is going on here. Thanks Anton From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 06:51:30 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65E8D16A41F for ; Wed, 19 Oct 2005 06:51:30 +0000 (GMT) (envelope-from shafi_2k12003@yahoo.com) Received: from web53111.mail.yahoo.com (web53111.mail.yahoo.com [206.190.49.61]) by mx1.FreeBSD.org (Postfix) with SMTP id B5BF043D49 for ; Wed, 19 Oct 2005 06:51:27 +0000 (GMT) (envelope-from shafi_2k12003@yahoo.com) Received: (qmail 14101 invoked by uid 60001); 19 Oct 2005 06:51:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tBMdx1KHhPiBWqx6JY4aK090Afw8usc4hfNvc1ZWYpzfUxRUCQIaxVDojR4t+7K8UJ/iTJZz64/UjbB6d6xlBCbKSA7tf6EhemW6FYuRDo5mvWmiBwp7jTSqp4gwIeDq4A9T7NykatbOOuNkrmkjEIgTM0kCjJ7EWq646jd/3Lk= ; Message-ID: <20051019065126.14099.qmail@web53111.mail.yahoo.com> Received: from [202.174.155.163] by web53111.mail.yahoo.com via HTTP; Tue, 18 Oct 2005 23:51:26 PDT Date: Tue, 18 Oct 2005 23:51:26 -0700 (PDT) From: shafi kamal To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: For advice in tcp implementation 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, 19 Oct 2005 06:51:30 -0000 Hello, At first thanks for responding to my mail. Now i can estimate the minimal implementation of tcp/ip stack for microcontrollers. I think uip is a good example of such an implementation. Is there any such suite like uip for i386 platform? Is there any minimal tcp/ip stack implementation that can be used as basis for enhancing gradually ? If that is possible to do using Linux or Unix? Just like Nacos that is used to add features to this operating system kernel. I wish to have such a ref. having proper documentation. Expecting response. shafi kamal --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 10:26:01 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9B3E16A41F for ; Wed, 19 Oct 2005 10:26:01 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id A129243D45 for ; Wed, 19 Oct 2005 10:26:00 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id D26091CCDD; Wed, 19 Oct 2005 23:25:59 +1300 (NZDT) Date: Wed, 19 Oct 2005 23:25:59 +1300 From: Andrew Thompson To: freebsd-net@freebsd.org Message-ID: <20051019102559.GA45909@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: vlan patch 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, 19 Oct 2005 10:26:01 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, It has always bugged me how the vlan code traverses the linked-list for each incoming packet to find the right ifvlan, I have this patch which attempts to fix this. What it does is replace the linear search for the vlan with a constant time lookup. It does this by allocating an array for each vlan enabled parent interface so the tag can be directly indexed. This has an overhead of ~16kb on 32bit, this is not too bad as there is usually only one physical interface when using a large number of vlans. I have measured a 1.6% pps increase with 100 vlans, and 8% with 500, and yes, some people use this many in production. It also has the benefit of enforcing unique vlan tags per parent which the current code doesn't do. Comments welcome. Andrew --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_vlan.diff" Index: if_var.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_var.h,v retrieving revision 1.103 diff -u -p -r1.103 if_var.h --- if_var.h 1 Oct 2005 18:56:18 -0000 1.103 +++ if_var.h 19 Oct 2005 07:22:45 -0000 @@ -134,6 +134,7 @@ struct ifnet { u_short if_index; /* numeric abbreviation for this if */ short if_timer; /* time 'til if_watchdog called */ u_short if_nvlans; /* number of active vlans */ + void *if_vlantags; /* array to hold active vlans */ int if_flags; /* up/down, broadcast, etc. */ int if_capabilities; /* interface capabilities */ int if_capenable; /* enabled features */ Index: if_vlan.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_vlan.c,v retrieving revision 1.88 diff -u -p -r1.88 if_vlan.c --- if_vlan.c 3 Oct 2005 02:24:21 -0000 1.88 +++ if_vlan.c 19 Oct 2005 07:24:58 -0000 @@ -133,7 +133,7 @@ static int vlan_setflag(struct ifnet *if static int vlan_setflags(struct ifnet *ifp, int status); static int vlan_setmulti(struct ifnet *ifp); static int vlan_unconfig(struct ifnet *ifp); -static int vlan_config(struct ifvlan *ifv, struct ifnet *p); +static int vlan_config(struct ifvlan *ifv, struct ifnet *p, int tag); static void vlan_link_state(struct ifnet *ifp, int link); static struct ifnet *vlan_clone_match_ethertag(struct if_clone *, @@ -406,7 +406,7 @@ vlan_clone_create(struct if_clone *ifc, if (ethertag) { VLAN_LOCK(); - error = vlan_config(ifv, p); + error = vlan_config(ifv, p, tag); if (error != 0) { /* * Since we've partialy failed, we need to back @@ -422,7 +422,6 @@ vlan_clone_create(struct if_clone *ifc, return (error); } - ifv->ifv_tag = tag; ifp->if_drv_flags |= IFF_DRV_RUNNING; VLAN_UNLOCK(); @@ -568,10 +567,13 @@ static void vlan_input(struct ifnet *ifp, struct mbuf *m) { struct ether_vlan_header *evl; - struct ifvlan *ifv; + struct ifvlan *ifv = NULL; + struct ifvlan **ifv_tags; struct m_tag *mtag; u_int tag; + ifv_tags = ifp->if_vlantags; + if (m->m_flags & M_VLANTAG) { /* * Packet is tagged, but m contains a normal @@ -620,9 +622,15 @@ vlan_input(struct ifnet *ifp, struct mbu } VLAN_LOCK(); +#if 1 + /* Look up the vlan in the parents tag array. O(1) */ + if (ifp->if_vlantags != NULL) + ifv = ifv_tags[tag]; +#else LIST_FOREACH(ifv, &ifv_list, ifv_list) if (ifp == ifv->ifv_p && tag == ifv->ifv_tag) break; +#endif if (ifv == NULL || (ifv->ifv_ifp->if_flags & IFF_UP) == 0) { VLAN_UNLOCK(); @@ -658,18 +666,26 @@ vlan_input(struct ifnet *ifp, struct mbu } static int -vlan_config(struct ifvlan *ifv, struct ifnet *p) +vlan_config(struct ifvlan *ifv, struct ifnet *p, int tag) { struct ifaddr *ifa1, *ifa2; struct ifnet *ifp; struct sockaddr_dl *sdl1, *sdl2; + struct ifvlan **ifv_tags; VLAN_LOCK_ASSERT(); + ifv_tags = p->if_vlantags; + + /* VID numbers 0x0 and 0xFFF are reserved */ + if (tag == 0 || tag == EVL_VLID_MASK) + return (EINVAL); if (p->if_type != IFT_ETHER) return (EPROTONOSUPPORT); if (ifv->ifv_p) return (EBUSY); + if (p->if_vlantags != NULL && ifv_tags[tag] != NULL) + return (EBUSY); ifv->ifv_encaplen = ETHER_VLAN_ENCAP_LEN; ifv->ifv_mintu = ETHERMIN; @@ -680,7 +696,18 @@ vlan_config(struct ifvlan *ifv, struct i * at various places to see if there is a vlan(4) * attached to this physical interface. */ + + /* Allocate the parents tag array */ + if (p->if_nvlans == 0) { + p->if_vlantags = malloc( + (int)(EVL_VLID_MASK * sizeof(struct ifvlan *)), + M_VLAN, M_WAITOK | M_ZERO); + ifv_tags = p->if_vlantags; + } + p->if_nvlans++; + ifv_tags[tag] = ifv; + ifv->ifv_tag = tag; /* * If the parent supports the VLAN_MTU capability, @@ -763,6 +790,7 @@ vlan_unconfig(struct ifnet *ifp) struct sockaddr_dl *sdl; struct vlan_mc_entry *mc; struct ifvlan *ifv; + struct ifvlan **ifv_tags; struct ifnet *p; int error; @@ -798,7 +826,17 @@ vlan_unconfig(struct ifnet *ifp) } vlan_setflags(ifp, 0); /* clear special flags on parent */ + + ifv_tags = p->if_vlantags; + if (ifv->ifv_tag > 0) + ifv_tags[ifv->ifv_tag] = NULL; + p->if_nvlans--; + /* Deallocate the parents tag array */ + if (p->if_nvlans == 0) { + free(p->if_vlantags, M_VLAN); + p->if_vlantags = NULL; + } } /* Disconnect from parent. */ @@ -998,12 +1036,11 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd break; } VLAN_LOCK(); - error = vlan_config(ifv, p); + error = vlan_config(ifv, p, vlr.vlr_tag); if (error) { VLAN_UNLOCK(); break; } - ifv->ifv_tag = vlr.vlr_tag; ifp->if_drv_flags |= IFF_DRV_RUNNING; VLAN_UNLOCK(); --SUOF0GtieIMvvwua-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 13:20:11 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E30616A41F; Wed, 19 Oct 2005 13:20:11 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4501643D73; Wed, 19 Oct 2005 13:20:03 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id E080B4CF0C; Wed, 19 Oct 2005 13:20:15 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 1B0C54CF0A; Wed, 19 Oct 2005 13:20:13 +0000 (GMT) Message-ID: <43564800.3010309@roq.com> Date: Wed, 19 Oct 2005 23:20:00 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> In-Reply-To: <20051014205434.C66245@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org, stable@freebsd.org Subject: Re: Network performance 6.0 with netperf 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, 19 Oct 2005 13:20:11 -0000 Robert Watson wrote: > > On Fri, 14 Oct 2005, Michael VInce wrote: > >> I been doing some network benchmarking using netperf and just simple >> 'fetch' on a new network setup to make sure I am getting the most out >> of the router and servers, I thought I would post some results in >> case some one can help me with my problems or if others are just >> interested to see the results. > > > Until recently (or maybe still), netperf was compiled with -DHISTOGRAM > by our port/package, which resulted in a significant performance > drop. I believe that the port maintainer and others have agreed to > change it, but I'm not sure if it's been committed yet, or which > packages have been rebuilt. You may want to manually rebuild it to > make sure -DHISTOGRAM isn't set. > > You may want to try setting net.isr.direct=1 and see what performance > impact that has for you. > > Robert N M Watson I reinstalled the netperf to make sure its the latest. I have also decided to upgrade Server-C (the i386 5.4 box) to 6.0RC1 and noticed it gave a large improvement of network performance with a SMP kernel. As with the network setup ( A --- B --- C ) with server B being the gateway, doing a basic 'fetch' from the gateway (B) to the Apache server (C) it gives up to 700mbits/sec transfer performance, doing a fetch from server A thus going through the gateway gives slower but still decent performance of up to 400mbits/sec. B> fetch -o - > /dev/null http://server-c/file1gig.iso - 100% of 1055 MB 69 MBps 00m00s A> fetch -o - > /dev/null http://server-c/file1gig.iso - 100% of 1055 MB 39 MBps 00m00s Netperf from the gateway directly to the apache server (C) 916mbits/sec B> /usr/local/netperf/netperf -l 20 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Elapsed Throughput - 10^6bits/sec: 916.50 Netperf from the client machine through the gateway to the apache server (C) 315mbits/sec A> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Elapsed Throughput - 10^6bits/sec: 315.89 Client to gateway netperf test shows the direct connection between these machines is fast. 912mbits/sec A> /usr/local/netperf/netperf -l 30 -H server-B -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 5734 Elapsed Throughput - 10^6bits/sec: 912.11 The strange thing now is in my last post I was able to get faster speeds from server A to C with 'fetch' tests on non-smp kernels and slower speeds with netperf tests. Now I get speeds a bit slower with fetch tests but faster netperf speed tests with or without SMP on server-C. I was going to test with 'net.isr.dispatch' but the sysctl doesn't appear to exist, doing this returns nothing. 'sysctl -a | grep 'net.isr.dispatch' I also tried polling but its also like that doesn't exist either. ifconfig em3 inet 192.168.1.1 netmask 255.255.255.224 polling ifconfig: polling: Invalid argument When doing netperf tests there was high interrupt usage. CPU states: 0.7% user, 0.0% nice, 13.5% system, 70.0% interrupt, 15.7% idle Also the server B is using its last 2 gigabit ethernet ports which are listed from pciconf -lv as '82547EI Gigabit Ethernet Controller' While the first 2 are listed as 'PRO/1000 P' Does any one know if the PRO/1000P would be better? em0@pci5:4:0: class=0x020000 card=0x118a8086 chip=0x108a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 P' em3@pci9:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller' Cheers, Mike > >> >> The network is currently like this, where machines A and B are the >> Dell 1850s and C is the 2850 x 2 CPU (Server C has Apache2 worker MPM >> on it) and server B is the gateway and A is acting as a client for >> fetch and netperf tests. >> A --- B --- C >> The 2 1850s are running AMD64 Freebsd 6.0rc1 (A and B) while C is >> running 5.4-stable i386 from Oct 12 >> >> My main problem is that if I compile SMP into the machine C >> (5.4stable) the network speed goes down to a range between >> 6mbytes/sec to 15mbytes/sec on SMP. >> If I use GENERIC kernel the performance goes up to what I have show >> below which is around 65megabytes/sec for a 'fetch' get test from >> Apache server and 933mbits/sec for netperf. >> Does any know why why network performance would be so bad on SMP? >> >> Does any one think that if I upgrade the i386 SMP server to 6.0RC1 >> the SMP network performance would improve? This server will be >> running java so I need it to be stable and is the the reason I am >> using i386 and Java 1.4 >> >> I am happy with performance of direct machine to machine (non SMP) >> which is pretty much full 1gigabit/sec speeds. >> Going through the gateway server-B seems to drop its speed down a bit >> for in and out direction tcp speed tests using netperf I get around >> 266mbits/sec from server A through gateway Server-B to server-C which >> is quite adequate for the link I currently have for it. >> >> Doing a 'fetch' get for a 1gig file from the Apache server gives good >> speeds of close to 600mbits/sec but netperf shows its weakness with >> 266mbits/sec. >> This is as fast as I need it to be but does any one know the weak >> points on the router gateway to make it faster? Is this the >> performance I should expect for FreeBSD as a router with gigabit ethers? >> >> I have seen 'net.inet.ip.fastforwarding' in some peoples router >> setups on the list but nothing about what it does or what it can affect. >> I haven't done any testing with polling yet but if I can get over >> 900mbits/sec on the interfaces does polling help with passing packets >> from one interface to the other? >> All machines have PF running other then that they don't really have >> any sysctls or special kernel options. >> >> Here are some speed benchmarks using netperf and 'fetch' gets. >> >> Server A to server C with server C using SMP kernel and just GENERIC >> kernel further below >> >> B# /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 >> -I 99,5 -- -m 4096 -s 57344 -S 57344 >> TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram >> Recv Send Send >> Socket Socket Message Elapsed >> Size Size Size Time Throughput >> bytes bytes bytes secs. 10^6bits/sec >> >> 57344 57344 4096 10.06 155.99 >> tank# fetch -o - > /dev/null http://server-C/file1gig.iso >> - 100% of 1055 MB 13 >> MBps 00m00s >> >> ##### Using generic non SMP kernel >> Server A to server C with server C using GENERIC kernel. >> A# fetch -o - > /dev/null http://server-C/file1gig.iso >> - 100% of 1055 MB 59 >> MBps 00m00s >> >> A# ./tcp_stream_script server-C >> >> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I >> 99,5 -- -m 4096 -s 57344 -S 57344 >> >> Recv Send Send >> Socket Socket Message Elapsed >> Size Size Size Time Throughput >> bytes bytes bytes secs. 10^6bits/sec >> >> 57344 57344 4096 60.43 266.92 >> >> ------------------------------------ >> ############################################### >> Connecting from server-A to B (gateway) >> A# ./tcp_stream_script server-B >> >> ------------------------------------ >> >> /usr/local/netperf/netperf -l 60 -H server-B -t TCP_STREAM -i 10,2 -I >> 99,5 -- -m 4096 -s 57344 -S 57344 >> >> TCP STREAM TEST to server-B : +/-2.5% @ 99% conf. : histogram >> Recv Send Send >> Socket Socket Message Elapsed >> Size Size Size Time Throughput >> bytes bytes bytes secs. 10^6bits/sec >> >> 57344 57344 4096 61.80 926.82 >> >> ------------------------------------ >> ########################################## >> Connecting from server B (gateway) to server C >> Fetch and Apache2 test >> B# fetch -o - > /dev/null http://server-C/file1gig.iso >> - 100% of 1055 MB 74 >> MBps 00m00s >> >> Netperf test >> B# /usr/local/netperf/tcp_stream_script server-C >> >> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I >> 99,5 -- -m 4096 -s 57344 -S 57344 >> >> TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram >> Recv Send Send >> Socket Socket Message Elapsed >> Size Size Size Time Throughput >> bytes bytes bytes secs. 10^6bits/sec >> >> 57344 57344 4096 62.20 933.94 >> >> ------------------------------------ >> >> Cheers, >> Mike >> >> _______________________________________________ >> 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-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 13:59:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BADE16A41F for ; Wed, 19 Oct 2005 13:59:29 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D87EA43D46 for ; Wed, 19 Oct 2005 13:59:28 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 32591E4; Wed, 19 Oct 2005 09:54:23 -0400 (EDT) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id F0C5E37F9; Wed, 19 Oct 2005 09:54:21 -0400 (EDT) Received: from lists by mappit.local.linnet.org with local (Exim 4.54 (FreeBSD)) id 1ESETV-000HAC-3Q; Wed, 19 Oct 2005 14:59:25 +0100 Date: Wed, 19 Oct 2005 14:59:25 +0100 From: Brian Candler To: Anton Bester Message-ID: <20051019135924.GA65967@uk.tiscali.com> References: <200510181954020250.00A66152@196.25.53.68> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510181954020250.00A66152@196.25.53.68> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Bind 8 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, 19 Oct 2005 13:59:29 -0000 On Tue, Oct 18, 2005 at 07:54:02PM +0200, Anton Bester wrote: > The following is a tcpdump from the secondary when bind is running: You really want to use tcpdump -n. Otherwise, every packet seen will trigger a new reverse DNS lookup, which in turn will trigger your nameserver to make further lookups to other nameservers on the Internet. This may mask any underlying problem. Regards, Brian. From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 14:58:28 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E89C16A41F for ; Wed, 19 Oct 2005 14:58:28 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from hotmail.com (bay101-f31.bay101.hotmail.com [64.4.56.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 396DE43D4C for ; Wed, 19 Oct 2005 14:58:28 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Oct 2005 07:58:27 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Wed, 19 Oct 2005 14:58:27 GMT X-Originating-IP: [64.60.108.59] X-Originating-Email: [saundersconsult@hotmail.com] X-Sender: saundersconsult@hotmail.com From: "Shawn Saunders" To: freebsd-net@freebsd.org Date: Wed, 19 Oct 2005 14:58:27 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 19 Oct 2005 14:58:27.0939 (UTC) FILETIME=[8FFA7330:01C5D4BD] Subject: Trying to make a Host into a gigabit hub for testing 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, 19 Oct 2005 14:58:28 -0000 I am setting up a test environment with multiple IDS's. ngctl looks like a solution but it is not broadcasting all packets to all interfaces as the documentation appears to state it should. I've probably made some error in configuration. My goal is to put em0 into a spanned port in promiscuous mode and broadcast all traffic from that port out the other network interfaces. I plan on having em0 (gigabit) and 6 other gigabit interfaces. Each will then echo the same traffic to six other machines (IDS's) for testing. The proof of concept with a gigabit (EM0) and 4 10/100 ethernets (sfx). The 10/100's will be replaced for implementation. Any help would be appreciated. My config follows: ifconfig sf0 up ifconfig sf1 up ifconfig sf2 up ifconfig sf3 up ifconfig em0 up kldload ng_ether.ko kldload ng_one2many.ko kldload ng_fec.ko ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"em0"' ; em0 is the port connected to traffic (sniffing) ngctl msg fec0: set_mode_inet ngctl mkpeer fec0: one2many upper one ngctl connect fec0: fec0:upper lower many0 ngctl connect sf0: fec0:upper lower many1 ngctl connect sf1: fec0:upper lower many2 ngctl connect sf2: fec0:upper lower many3 ngctl connect sf3: fec0:upper lower many4 ngctl msg sf0: setpromisc 1 ngctl msg sf0: setautosrc 0 ngctl msg sf1: setpromisc 1 ngctl msg sf1: setautosrc 0 ngctl msg sf2: setpromisc 1 ngctl msg sf2: setautosrc 0 ngctl msg sf3: setpromisc 1 ngctl msg sf3: setautosrc 0 ngctl msg em0: setpromisc 1 ; I have tried with this set and not. ngctl msg em0: setautosrc 0 ; I have tried with this set and not. ngctl msg fec0:upper setconfig "{ xmitAlg=2 failAlg=1 enabledLinks=[1 1 1 1 1] }" ifconfig fec0 -arp up ; I have tried with this set and not. Am I missing something? Shawn Saunders From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 17:17:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 269C516A421; Wed, 19 Oct 2005 17:17:13 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7C2643D48; Wed, 19 Oct 2005 17:17:11 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9JHHBuH030044; Wed, 19 Oct 2005 10:17:11 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9JHHBUV030043; Wed, 19 Oct 2005 10:17:11 -0700 Date: Wed, 19 Oct 2005 10:17:11 -0700 From: Brooks Davis To: Andrew Thompson Message-ID: <20051019171711.GC20830@odin.ac.hmc.edu> References: <20051019102559.GA45909@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qjNfmADvan18RZcF" Content-Disposition: inline In-Reply-To: <20051019102559.GA45909@heff.fud.org.nz> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org Subject: Re: vlan patch 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, 19 Oct 2005 17:17:13 -0000 --qjNfmADvan18RZcF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2005 at 11:25:59PM +1300, Andrew Thompson wrote: > Hi, > =20 > It has always bugged me how the vlan code traverses the linked-list for > each incoming packet to find the right ifvlan, I have this patch which > attempts to fix this. > =20 > What it does is replace the linear search for the vlan with a constant > time lookup. It does this by allocating an array for each vlan enabled > parent interface so the tag can be directly indexed. > =20 > This has an overhead of ~16kb on 32bit, this is not too bad as there is > usually only one physical interface when using a large number of vlans. > =20 > I have measured a 1.6% pps increase with 100 vlans, and 8% with 500, and > yes, some people use this many in production. > =20 > It also has the benefit of enforcing unique vlan tags per parent which = =20 > the current code doesn't do. I like the idea and had been thinking of doing something similar. I'm a bit concerned about cleanup. It doens't look like the network code needs to grow the ability to unconfig existing vlans if they are there during if_detach. It looks like publishing a pointer to vlan_config is the thing to do. It would be best if the new member where added to the end of struct ifnet to avoid breaking the ABI for now. We may want to develop some sort of policy around that sort of thing where we append each time, but mark the correct location for each one with #ifdef BREAK_IFNET_ABI. Then when an ABI breaking change has to happen in current, we resort the structure correctly. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qjNfmADvan18RZcF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDVn+WXY6L6fI4GtQRAjFHAJ9w/+mD61Qnv7tX1ZasgMUEdfnoawCdHw0f JRYwRvcEhk3pVFVU0lIVVTM= =DY0H -----END PGP SIGNATURE----- --qjNfmADvan18RZcF-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 18:02:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ECF916A41F for ; Wed, 19 Oct 2005 18:02:18 +0000 (GMT) (envelope-from holm@pegasus.freiberg-net.de) Received: from pegasus.freiberg-net.de (pegasus.freibergnet.de [80.243.43.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D1B143D5D for ; Wed, 19 Oct 2005 18:02:16 +0000 (GMT) (envelope-from holm@pegasus.freiberg-net.de) Received: from pegasus.freiberg-net.de (localhost.freiberg-net.de [127.0.0.1]) by pegasus.freiberg-net.de (8.13.4/8.13.1) with ESMTP id j9JI1EOc039274 for ; Wed, 19 Oct 2005 20:01:14 +0200 (CEST) (envelope-from holm@pegasus.freiberg-net.de) Received: (from holm@localhost) by pegasus.freiberg-net.de (8.13.4/8.13.1/Submit) id j9JI1Efp039273 for freebsd-net@freebsd.org; Wed, 19 Oct 2005 20:01:14 +0200 (CEST) (envelope-from holm) Date: Wed, 19 Oct 2005 20:01:14 +0200 From: Holm Tiffe To: freebsd-net@freebsd.org Message-ID: <20051019180114.GB38872@pegasus.freiberg-net.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organization: FreibergNet Internet Services Priority: normal X-Phone: +49-3731-419010 X-Fax: +49-3731-4196026 X-PGP-fingerprint: 86 EC A5 63 B5 28 78 13 8B FC E9 09 04 6E 86 FC Subject: urgent: RELENG_5 ipfw/nat/IPSEC Problem.. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: holm@freibergnet.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2005 18:02:18 -0000 Hi, I have a currently big problem with the following setup: A FreeBSD Box, running 5_STABLE is connected wirh one interface to the public, with the other to an nated' subnet with private address space. I need to allow at least one host from inside the private network access to an outside Cisco VPN concentrator. I've learned in the meantime, that allowing udp connections from inside to the outside net and vis versa is'nt doing the job. (I've struggeled in the meantime over tcpdump, that is showing isakmp packets leaving the external interface, but they dont't really do this..) What exactly I have to do get this working? The FreeBSD Box is out of reach (around 50km from here), I can't access the hosts on the inside network and I dont't have access to the cisco concentrator, so I can't test different setups .. Can please anyone help? Regards, Holm ps: please Cc me, I've currently not subscribed to this list. -- L&P::Kommunikation GbR Holm Tiffe * Administration, Development FreibergNet.de Internet Systems phone +49 3731 419010 Bereich Server & Technik fax +49 3731 4196026 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 21:21:00 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D37C16A41F; Wed, 19 Oct 2005 21:21:00 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A9D943D5A; Wed, 19 Oct 2005 21:20:59 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id C77F31CCDD; Thu, 20 Oct 2005 10:20:57 +1300 (NZDT) Date: Thu, 20 Oct 2005 10:20:57 +1300 From: Andrew Thompson To: Andre Oppermann Message-ID: <20051019212057.GA48129@heff.fud.org.nz> References: <20051019102559.GA45909@heff.fud.org.nz> <43562BBF.197CCF7E@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <43562BBF.197CCF7E@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vlan patch 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, 19 Oct 2005 21:21:00 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 19, 2005 at 01:19:27PM +0200, Andre Oppermann wrote: > Andrew Thompson wrote: > > > > Hi, > > > > It has always bugged me how the vlan code traverses the linked-list for > > each incoming packet to find the right ifvlan, I have this patch which > > attempts to fix this. > > > > I like the concept. You may want to switch to direct indexing only > when the number of vlan exceeds 10 or so. > Thanks for the feedback (and others too), I have updated the patch to switch between array and linked-list searching depending on the number of vlans. cheers, Andrew --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="if_vlan12.diff" Index: if_var.h =================================================================== RCS file: /home/ncvs/src/sys/net/if_var.h,v retrieving revision 1.103 diff -u -p -r1.103 if_var.h --- if_var.h 1 Oct 2005 18:56:18 -0000 1.103 +++ if_var.h 19 Oct 2005 19:35:55 -0000 @@ -134,6 +134,7 @@ struct ifnet { u_short if_index; /* numeric abbreviation for this if */ short if_timer; /* time 'til if_watchdog called */ u_short if_nvlans; /* number of active vlans */ + /* correct location for *if_vlantags when changing ABI */ int if_flags; /* up/down, broadcast, etc. */ int if_capabilities; /* interface capabilities */ int if_capenable; /* enabled features */ @@ -180,6 +181,7 @@ struct ifnet { struct task if_starttask; /* task for IFF_NEEDSGIANT */ struct task if_linktask; /* task for link change events */ struct mtx if_addr_mtx; /* mutex to protect address lists */ + void *if_vlantags; /* array to hold active vlans */ }; typedef void if_init_f_t(void *); Index: if_vlan.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_vlan.c,v retrieving revision 1.88 diff -u -p -r1.88 if_vlan.c --- if_vlan.c 3 Oct 2005 02:24:21 -0000 1.88 +++ if_vlan.c 19 Oct 2005 21:09:56 -0000 @@ -69,6 +69,7 @@ #endif #define VLANNAME "vlan" +#define VLAN_LIST_THRESHOLD 10 struct vlan_mc_entry { struct ether_addr mc_addr; @@ -133,7 +134,7 @@ static int vlan_setflag(struct ifnet *if static int vlan_setflags(struct ifnet *ifp, int status); static int vlan_setmulti(struct ifnet *ifp); static int vlan_unconfig(struct ifnet *ifp); -static int vlan_config(struct ifvlan *ifv, struct ifnet *p); +static int vlan_config(struct ifvlan *ifv, struct ifnet *p, int tag); static void vlan_link_state(struct ifnet *ifp, int link); static struct ifnet *vlan_clone_match_ethertag(struct if_clone *, @@ -406,7 +407,7 @@ vlan_clone_create(struct if_clone *ifc, if (ethertag) { VLAN_LOCK(); - error = vlan_config(ifv, p); + error = vlan_config(ifv, p, tag); if (error != 0) { /* * Since we've partialy failed, we need to back @@ -422,7 +423,6 @@ vlan_clone_create(struct if_clone *ifc, return (error); } - ifv->ifv_tag = tag; ifp->if_drv_flags |= IFF_DRV_RUNNING; VLAN_UNLOCK(); @@ -568,10 +568,13 @@ static void vlan_input(struct ifnet *ifp, struct mbuf *m) { struct ether_vlan_header *evl; - struct ifvlan *ifv; + struct ifvlan *ifv = NULL; + struct ifvlan **ifv_tags; struct m_tag *mtag; u_int tag; + ifv_tags = ifp->if_vlantags; + if (m->m_flags & M_VLANTAG) { /* * Packet is tagged, but m contains a normal @@ -620,9 +623,16 @@ vlan_input(struct ifnet *ifp, struct mbu } VLAN_LOCK(); - LIST_FOREACH(ifv, &ifv_list, ifv_list) - if (ifp == ifv->ifv_p && tag == ifv->ifv_tag) - break; + /* Look up the vlan in the parents tag array if allocated. O(1) */ + if (ifp->if_vlantags != NULL) + ifv = ifv_tags[tag]; + else { + /* Fall back to a linear search. O(n) */ + LIST_FOREACH(ifv, &ifv_list, ifv_list) + if (ifp == ifv->ifv_p && tag == ifv->ifv_tag) + break; + } + if (ifv == NULL || (ifv->ifv_ifp->if_flags & IFF_UP) == 0) { VLAN_UNLOCK(); @@ -658,18 +668,28 @@ vlan_input(struct ifnet *ifp, struct mbu } static int -vlan_config(struct ifvlan *ifv, struct ifnet *p) +vlan_config(struct ifvlan *ifv, struct ifnet *p, int tag) { struct ifaddr *ifa1, *ifa2; struct ifnet *ifp; struct sockaddr_dl *sdl1, *sdl2; + struct ifvlan *ifv2, **ifv_tags; VLAN_LOCK_ASSERT(); + ifv_tags = p->if_vlantags; + + /* VID numbers 0x0 and 0xFFF are reserved */ + if (tag == 0 || tag == EVL_VLID_MASK) + return (EINVAL); if (p->if_type != IFT_ETHER) return (EPROTONOSUPPORT); if (ifv->ifv_p) return (EBUSY); + /* Ensure unique ifnet + tag */ + LIST_FOREACH(ifv2, &ifv_list, ifv_list) + if (p == ifv2->ifv_p && tag == ifv2->ifv_tag) + return (EBUSY); ifv->ifv_encaplen = ETHER_VLAN_ENCAP_LEN; ifv->ifv_mintu = ETHERMIN; @@ -682,6 +702,27 @@ vlan_config(struct ifvlan *ifv, struct i */ p->if_nvlans++; + /* Allocate the parents tag array */ + if (p->if_vlantags == NULL && p->if_nvlans > VLAN_LIST_THRESHOLD) { + p->if_vlantags = malloc( + (int)(EVL_VLID_MASK * sizeof(struct ifvlan *)), + M_VLAN, M_WAITOK | M_ZERO); + ifv_tags = p->if_vlantags; + +#ifdef DEBUG + printf("vlan: changing to array lookup for %s\n", p->if_xname); +#endif + + /* Fill it with existing vlans */ + LIST_FOREACH(ifv2, &ifv_list, ifv_list) + if (ifv2->ifv_p == p) + ifv_tags[ifv2->ifv_tag] = ifv2; + } + + ifv->ifv_tag = tag; + if (p->if_vlantags != NULL) + ifv_tags[tag] = ifv; + /* * If the parent supports the VLAN_MTU capability, * i.e. can Tx/Rx larger than ETHER_MAX_LEN frames, @@ -763,6 +804,7 @@ vlan_unconfig(struct ifnet *ifp) struct sockaddr_dl *sdl; struct vlan_mc_entry *mc; struct ifvlan *ifv; + struct ifvlan **ifv_tags; struct ifnet *p; int error; @@ -798,7 +840,22 @@ vlan_unconfig(struct ifnet *ifp) } vlan_setflags(ifp, 0); /* clear special flags on parent */ + + ifv_tags = p->if_vlantags; + if (p->if_vlantags != NULL && ifv->ifv_tag > 0) + ifv_tags[ifv->ifv_tag] = NULL; + p->if_nvlans--; + /* Deallocate the parents tag array */ + if (p->if_vlantags != NULL && + p->if_nvlans <= VLAN_LIST_THRESHOLD) { + free(p->if_vlantags, M_VLAN); + p->if_vlantags = NULL; +#ifdef DEBUG + printf("vlan: changing to list lookup for %s\n", + p->if_xname); +#endif + } } /* Disconnect from parent. */ @@ -998,12 +1055,11 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd break; } VLAN_LOCK(); - error = vlan_config(ifv, p); + error = vlan_config(ifv, p, vlr.vlr_tag); if (error) { VLAN_UNLOCK(); break; } - ifv->ifv_tag = vlr.vlr_tag; ifp->if_drv_flags |= IFF_DRV_RUNNING; VLAN_UNLOCK(); --huq684BweRXVnRxX-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 21:33:33 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C76B116A41F; Wed, 19 Oct 2005 21:33:33 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3894243D5A; Wed, 19 Oct 2005 21:33:32 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.5.8] (host-81-191-3-170.bluecom.no [81.191.3.170]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j9JLXUdf010994; Wed, 19 Oct 2005 23:33:31 +0200 Message-ID: <4356BBA1.3000103@wm-access.no> Date: Wed, 19 Oct 2005 23:33:21 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael VInce References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> In-Reply-To: <43564800.3010309@roq.com> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, stable@freebsd.org Subject: Re: Network performance 6.0 with netperf 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, 19 Oct 2005 21:33:33 -0000 Michael VInce wrote: > I reinstalled the netperf to make sure its the latest. > > I have also decided to upgrade Server-C (the i386 5.4 box) to 6.0RC1 and > noticed it gave a large improvement of network performance with a SMP > kernel. > > As with the network setup ( A --- B --- C ) with server B being the > gateway, doing a basic 'fetch' from the gateway (B) to the Apache server > (C) it gives up to 700mbits/sec transfer performance, doing a fetch from > server A thus going through the gateway gives slower but still decent > performance of up to 400mbits/sec. Are you by any chance using PCI NIC's? PCI Bus is limited to somewhere around 1 Gbit/s. So if you consider; Theoretical maxium = ( 1Gbps - pci_overhead ) -- Sten Daniel Sψrsdal From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 21:51:15 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C83A716A41F; Wed, 19 Oct 2005 21:51:15 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D0E043D62; Wed, 19 Oct 2005 21:51:13 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from localhost.localdomain (yazzy.yazzy.org [192.168.98.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yazzy.org (Postfix) with ESMTP id 6D9F5398F0; Wed, 19 Oct 2005 23:51:11 +0200 (CEST) Date: Wed, 19 Oct 2005 23:51:11 +0200 From: Marcin Jessa To: FreeBSD-current , net@freebsd.org Message-Id: <20051019235111.2225345e.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: PPPoE and Radius on 6.0RC1 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, 19 Oct 2005 21:51:15 -0000 Hi guys. It seems like PPPoE stoped working with support for radius on 6.0 The log of pppoe and freeradius does not show pppoe attempting to even talk to the radius server. Additionally this message pops up when enabling pppoed: WARNING: attempt to net_add_domain(netgraph) after domainfinalize() My setup worked fine before on FreeBSD 5.x Is that a known issue and is it being worked on? Marcin. From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 22:46:36 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A873F16A41F for ; Wed, 19 Oct 2005 22:46:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C5CF43D69 for ; Wed, 19 Oct 2005 22:46:36 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 19 Oct 2005 15:46:36 -0700 X-IronPort-Anti-Spam-Filtered: true Message-ID: <4356CCCB.7040702@elischer.org> Date: Wed, 19 Oct 2005 15:46:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: probably a simpple answer.. 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, 19 Oct 2005 22:46:36 -0000 A frienn asked me "how do I automatically sence what location my laptop is at and make it use teh right WEP key without manual intervention". I realised I didn't know.. is there a standard way to do this? (I know my MAC does it so I guess it's possible). example : laptop moved between home and office. different keys. automatically connects in and runs dhclient using the correct WEP key depending on where it is when booted. From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 23:07:07 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FA8816A421 for ; Wed, 19 Oct 2005 23:07:07 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5AA243D72 for ; Wed, 19 Oct 2005 23:07:04 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9JN72tw031550; Wed, 19 Oct 2005 16:07:02 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9JN72oJ031549; Wed, 19 Oct 2005 16:07:02 -0700 Date: Wed, 19 Oct 2005 16:07:02 -0700 From: Brooks Davis To: Julian Elischer Message-ID: <20051019230702.GA25227@odin.ac.hmc.edu> References: <4356CCCB.7040702@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <4356CCCB.7040702@elischer.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: net@freebsd.org Subject: Re: probably a simpple answer.. 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, 19 Oct 2005 23:07:07 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 19, 2005 at 03:46:35PM -0700, Julian Elischer wrote: > A frienn asked me "how do I automatically sence what location my laptop= =20 > is at and > make it use teh right WEP key without manual intervention". >=20 > I realised I didn't know.. >=20 > is there a standard way to do this? > (I know my MAC does it so I guess it's possible). >=20 > example : >=20 > laptop moved between home and office. different keys. > automatically connects in and runs dhclient using the correct WEP key > depending on where it is when booted. Upgrade to 6.0 and use wpa_supplicant. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDVtGVXY6L6fI4GtQRAviNAJ46oA8pujvj6ai9WCSvuPfhpuNnmQCglAoF H04bzQLlPVCU8PxlOZDdrvU= =774v -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 00:28:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD73616A41F for ; Thu, 20 Oct 2005 00:28:47 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5364843D5A for ; Thu, 20 Oct 2005 00:28:47 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id C34DCBC047; Thu, 20 Oct 2005 03:28:45 +0300 (EEST) Received: from [10.0.0.1] (vdp1003.ath03.dsl.hol.gr [62.38.168.4])by smtp.freemail.gr (Postfix) with ESMTP id 18E14BC037; Thu, 20 Oct 2005 03:28:44 +0300 (EEST) Message-ID: <4356E47D.605@freemail.gr> Date: Thu, 20 Oct 2005 03:27:41 +0300 From: Chris Dionissopoulos User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shawn Saunders References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Trying to make a Host into a gigabit hub for testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dionch@freemail.gr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2005 00:28:48 -0000 SS>I am setting up a test environment with multiple IDS's. ngctl looks like a solution but it is not broadcasting all packets to all interfaces as the documentation appears to state it should. I've probably made some error in configuration. SS> SS>My goal is to put em0 into a spanned port in promiscuous mode and broadcast all traffic from that port out the other network interfaces. I plan on having em0 (gigabit) and 6 other gigabit interfaces. Each will then echo the same traffic to six other machines (IDS's) for testing. SS> SS>The proof of concept with a gigabit (EM0) and 4 10/100 ethernets (sfx). The 10/100's will be replaced for implementation. SS> SS>Any help would be appreciated. My config follows: Hi, Why to use ng_fec and ng_one2many together? how about something simplier, like: +----------+ -->-sf0:lower--->wire wire>--em:lower->| one2many | -->-sf1:lower--->wire | | -->-sf2:lower--->wire +----------+ -->sf3:lower--->wire ngctl mkpeer em0: one2many lower one ngctl name em0:lower o2m ngctl connect sf0: o2m lower many0 ngctl connect sf1: o2m lower many1 ngctl connect sf2: o2m lower many2 ngctl connect sf3: o2m lower many3 ngctl msg o2m setconfig "{ xmitAlg=2 failAlg=1 enabledLinks=[1 1 1 1 1] }" ngctl msg sf0: setpromisc 1 ngctl msg sf0: setautosrc 0 ngctl msg sf1: setpromisc 1 ngctl msg sf1: setautosrc 0 ngctl msg sf2: setpromisc 1 ngctl msg sf2: setautosrc 0 ngctl msg sf3: setpromisc 1 ngctl msg sf3: setautosrc 0 ngctl msg em0: setpromisc 1 ngctl msg em0: setautosrc 0 This keeps kernel-stack isolated from traffic, I think (and all interfaces involved layer2 unreachable from outsiders). Just tell us if its working for you. Chris. ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 06:10:56 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BE9516A41F for ; Thu, 20 Oct 2005 06:10:56 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id D91DF43D64 for ; Thu, 20 Oct 2005 06:10:55 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from jayton.plus.com ([84.92.156.191] helo=[127.0.0.1]) by pih-relay04.plus.net with esmtp (Exim) id 1ESTda-0003c2-Vm for freebsd-net@freebsd.org; Thu, 20 Oct 2005 07:10:51 +0100 Message-ID: <435734EF.3070109@codegurus.org> Date: Thu, 20 Oct 2005 07:10:55 +0100 From: Jayton Garnett User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ndiscvt not generating ndis_driver_data.h 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, 20 Oct 2005 06:10:56 -0000 Hello, I have previously used ndiscvt one a 5.4 x86 installation of freebsd and it work fine and I am happy with it, however I have tried to get my wifi card working on 5.4 AMD64 and when doing: ndiscvt -i TNET1130.INF -s tnet1130.sys -f Fw1130.bin -o ndis_driver_data.h It does not give me any errors and does not produce the required ndis_driver_data.h I have mounted my 5.4 x86 /usr directory and copied all the file from /sys/modules/if_ndis to my AMD64's /sys/modules/if_ndis and tried to compile it like that which it did with no errors. When I try to load the kernel module produced it gives me a exec error ( presumably because its x86 code and not AMD64 code) I dont want to have my server acting as a gateway either, the two machines are half a meter apart. Any help/info would be very appreciated. Cheers, Jayton From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 06:38:34 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B52E916A41F for ; Thu, 20 Oct 2005 06:38:34 +0000 (GMT) (envelope-from shafi_2k12003@yahoo.com) Received: from web53110.mail.yahoo.com (web53110.mail.yahoo.com [206.190.49.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 39D4E43D64 for ; Thu, 20 Oct 2005 06:38:34 +0000 (GMT) (envelope-from shafi_2k12003@yahoo.com) Received: (qmail 84555 invoked by uid 60001); 20 Oct 2005 06:38:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rCwPW4l1cImX4+lQBefAvDth3KFqIOyI9D4aY0ASqU9pC6ELSxedcX2EwvtsvWUS9gOkS9pvNq+uCAg7EkorbZdA/8E2i6oZgyRLWsHgzuCIqQCuS5sRsEUAjckYUWYMp/BFG4V0T2o6rqhaFGk7L6N1zrKluVxOHYloRsFHLBc= ; Message-ID: <20051020063833.84553.qmail@web53110.mail.yahoo.com> Received: from [202.174.155.163] by web53110.mail.yahoo.com via HTTP; Wed, 19 Oct 2005 23:38:33 PDT Date: Wed, 19 Oct 2005 23:38:33 -0700 (PDT) From: shafi kamal To: net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Advice for tcp implementation 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, 20 Oct 2005 06:38:34 -0000 hello, At first thanks for responding to my mail. Now i can estimate the minimal implementation of tcp/ip stack for microcontrollers. I think uip is a good example of such an implementation. Is there any such suite like uip for i386 platform? Is there any minimal tcp/ip stack implementation that can be used as basis for enhancing gradually ? If that is possible to do using Linux or Unix? I mean, Just like Nacos that is used to add features to this operating system kernel. I wish to have such a ref. having proper documentation. Expecting quick response. shafi kamal --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 07:00:58 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B8CC16A41F; Thu, 20 Oct 2005 07:00:58 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61DEF43D5A; Thu, 20 Oct 2005 07:00:57 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9K70sOV097925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 11:00:55 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9K70sMe097924; Thu, 20 Oct 2005 11:00:54 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 20 Oct 2005 11:00:54 +0400 From: Gleb Smirnoff To: Andrew Thompson Message-ID: <20051020070054.GZ59364@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andrew Thompson , yar@FreeBSD.org, ru@FreeBSD.org, freebsd-net@freebsd.org References: <20051019102559.GA45909@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051019102559.GA45909@heff.fud.org.nz> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, yar@FreeBSD.org, ru@FreeBSD.org Subject: Re: vlan patch 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, 20 Oct 2005 07:00:58 -0000 Andrew, On Wed, Oct 19, 2005 at 11:25:59PM +1300, Andrew Thompson wrote: A> It has always bugged me how the vlan code traverses the linked-list for A> each incoming packet to find the right ifvlan, I have this patch which A> attempts to fix this. A> A> What it does is replace the linear search for the vlan with a constant A> time lookup. It does this by allocating an array for each vlan enabled A> parent interface so the tag can be directly indexed. A> A> This has an overhead of ~16kb on 32bit, this is not too bad as there is A> usually only one physical interface when using a large number of vlans. A> A> I have measured a 1.6% pps increase with 100 vlans, and 8% with 500, and A> yes, some people use this many in production. A> A> It also has the benefit of enforcing unique vlan tags per parent which A> the current code doesn't do. Although the memory overhead is not noticable on modern i386 and amd64 PCs I don't think that we should waste so much memory. We should keep in mind the existence of embedded architectures with little memory. In most cases people use 10 - 30 VLANs. I suggest to use a hash, like it is already done in ng_vlan(4). This hash makes every sixteenth VLAN to fall into same slot. Since most people allocate VLAN ids contiguously the hash distribution should be good. Moreover, I suggest Yar and Ruslan to work together and make the hash code shared between vlan(4) and ng_vlan(4), not copy-and-pasted. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 07:01:48 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 427E616A41F; Thu, 20 Oct 2005 07:01:48 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91EB543D5A; Thu, 20 Oct 2005 07:01:47 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9K71jXH097938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 11:01:46 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9K71jmc097937; Thu, 20 Oct 2005 11:01:45 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 20 Oct 2005 11:01:45 +0400 From: Gleb Smirnoff To: Marcin Jessa Message-ID: <20051020070145.GA59364@cell.sick.ru> References: <20051019235111.2225345e.lists@yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051019235111.2225345e.lists@yazzy.org> User-Agent: Mutt/1.5.6i Cc: FreeBSD-current , net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 20 Oct 2005 07:01:48 -0000 On Wed, Oct 19, 2005 at 11:51:11PM +0200, Marcin Jessa wrote: M> It seems like PPPoE stoped working with support for radius on 6.0 M> The log of pppoe and freeradius does not show pppoe attempting to even talk to the radius server. M> Additionally this message pops up when enabling pppoed: M> WARNING: attempt to net_add_domain(netgraph) after domainfinalize() M> My setup worked fine before on FreeBSD 5.x M> Is that a known issue and is it being worked on? Please show your PPPoE server configuration. Do you use pppoed or mpd? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 08:25:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1014316A41F; Thu, 20 Oct 2005 08:25:59 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4949643D70; Thu, 20 Oct 2005 08:25:57 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 155B74CFF7; Thu, 20 Oct 2005 08:26:11 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 7CF0D4CFFD; Thu, 20 Oct 2005 08:26:09 +0000 (GMT) Message-ID: <43575492.1030503@roq.com> Date: Thu, 20 Oct 2005 18:25:54 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> In-Reply-To: <43564800.3010309@roq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: stable@freebsd.org Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 08:25:59 -0000 Here is my probably final round of tests that I thought could possible be useful to others. I have enabled polling on the interfaces and discovered some of the master secret holy grail sysctls that really make this stuff work. I now get over 900mbits/sec router performance with polling. Having sysctl either net.isr.direct=1 or net.inet.ip.fastforwarding=1 gave roughly an extra 445mbits performance increase according to netperf tests, because my tests aren't really lab strict enough I still haven't been able to easily see a difference between having net.isr.direct=1 or 0 while also having net.inet.ip.fastforwarding set to 1, it does appear that having net.isr.direct=1 might be stealing the job of the net.inet.ip.fastforwarding sysctl because when net.inet.ip.fastforwarding=0 and net.isr.direct=1 on the gateway I still get the 905.48mbit/sec route speed listed below. From the client machine (A) through the gateway (B with polling enabled) to the server (C) With net.isr.direct=1 and net.inet.ip.fastforwarding=1 A> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Elapsed Throughput - 10^6bits/sec: 905.48 With net.isr.direct=0 and net.inet.ip.fastforwarding=0 Elapsed Throughput - 10^6bits/sec: 460.15 Apache get 'fetch' test. A> fetch -o - > /dev/null http://server-C/file1gig.iso - 100% of 1055 MB 67 MBps 00m00s Interestingly when testing from the gateway it self (B) direct to server (C) having 'net.isr.direct=1' slowed down performance to 583mbits/sec B> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Elapsed Throughput - 10^6bits/sec: 583.57 Same test with 'net.isr.direct=0' Elapsed Throughput - 10^6bits/sec: 868.94 I have to ask how can this be possible if when its being used as a router with net.isr.direct=1 it passes traffic at over 900mbits/sec Having net.inet.ip.fastforwarding=1 doesn't affect the performance in these B to C tests. I believe faster performance may still be possible as another rack of gear I have that has another AMD64 6.0 RC1 Dell 2850 (Kes) gives me up to 930mbits/sec in apache fetch tests, I believe its even faster here because its an AMD64 Apache server or its possible it could just have a bit better quality ether cables, as I mentioned before the Apache server for box "C" in above tests is i386 on 6.0RC1. This fetch test is only on a switch with no router between them. spin> fetch -o - > /dev/null http://kes/500megs.zip - 100% of 610 MB 93 MBps So far from this casual testing I have discovered these things on my servers. Using 6.0 on SMP servers gives a big boost in network performance over 5.x SMP using i386 or AMD64 FreeBSD as router on gigabit ethernet with the use of polling gives over x2 performance with the right sysctls. Needs more testing but it appears using AMD64 FreeBSD might be better then i386 for Apache2 network performance on SMP kernels. Single interface speeds tests from the router with polling enabled and with 'net.isr.direct=1' appears to affect performance. Regards, Mike Michael VInce wrote: > Robert Watson wrote: > >> >> On Fri, 14 Oct 2005, Michael VInce wrote: >> >>> I been doing some network benchmarking using netperf and just simple >>> 'fetch' on a new network setup to make sure I am getting the most >>> out of the router and servers, I thought I would post some results >>> in case some one can help me with my problems or if others are just >>> interested to see the results. >> >> >> >> Until recently (or maybe still), netperf was compiled with >> -DHISTOGRAM by our port/package, which resulted in a significant >> performance drop. I believe that the port maintainer and others have >> agreed to change it, but I'm not sure if it's been committed yet, or >> which packages have been rebuilt. You may want to manually rebuild >> it to make sure -DHISTOGRAM isn't set. >> >> You may want to try setting net.isr.direct=1 and see what performance >> impact that has for you. >> >> Robert N M Watson > > > I reinstalled the netperf to make sure its the latest. > > I have also decided to upgrade Server-C (the i386 5.4 box) to 6.0RC1 > and noticed it gave a large improvement of network performance with a > SMP kernel. > > As with the network setup ( A --- B --- C ) with server B being the > gateway, doing a basic 'fetch' from the gateway (B) to the Apache > server (C) it gives up to 700mbits/sec transfer performance, doing a > fetch from server A thus going through the gateway gives slower but > still decent performance of up to 400mbits/sec. > > B> fetch -o - > /dev/null http://server-c/file1gig.iso > - 100% of 1055 MB 69 > MBps 00m00s > > > A> fetch -o - > /dev/null http://server-c/file1gig.iso > - 100% of 1055 MB 39 > MBps 00m00s > > Netperf from the gateway directly to the apache server (C) 916mbits/sec > B> /usr/local/netperf/netperf -l 20 -H server-C -t TCP_STREAM -i 10,2 > -I 99,5 -- -m 4096 -s 57344 -S 57344 > Elapsed Throughput - 10^6bits/sec: 916.50 > > Netperf from the client machine through the gateway to the apache > server (C) 315mbits/sec > A> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 > -I 99,5 -- -m 4096 -s 57344 -S 57344 > Elapsed Throughput - 10^6bits/sec: 315.89 > > Client to gateway netperf test shows the direct connection between > these machines is fast. 912mbits/sec > A> /usr/local/netperf/netperf -l 30 -H server-B -t TCP_STREAM -i 10,2 > -I 99,5 -- -m 4096 -s 57344 -S 5734 > Elapsed Throughput - 10^6bits/sec: 912.11 > > The strange thing now is in my last post I was able to get faster > speeds from server A to C with 'fetch' tests on non-smp kernels and > slower speeds with netperf tests. Now I get speeds a bit slower with > fetch tests but faster netperf speed tests with or without SMP on > server-C. > > I was going to test with 'net.isr.dispatch' but the sysctl doesn't > appear to exist, doing this returns nothing. > 'sysctl -a | grep 'net.isr.dispatch' > > I also tried polling but its also like that doesn't exist either. > ifconfig em3 inet 192.168.1.1 netmask 255.255.255.224 polling > ifconfig: polling: Invalid argument > > When doing netperf tests there was high interrupt usage. > CPU states: 0.7% user, 0.0% nice, 13.5% system, 70.0% interrupt, > 15.7% idle > > Also the server B is using its last 2 gigabit ethernet ports which are > listed from pciconf -lv as '82547EI Gigabit Ethernet Controller' > While the first 2 are listed as 'PRO/1000 P' > Does any one know if the PRO/1000P would be better? > > em0@pci5:4:0: class=0x020000 card=0x118a8086 chip=0x108a8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 P' > > em3@pci9:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82547EI Gigabit Ethernet Controller' > > Cheers, > Mike > >> >>> >>> The network is currently like this, where machines A and B are the >>> Dell 1850s and C is the 2850 x 2 CPU (Server C has Apache2 worker >>> MPM on it) and server B is the gateway and A is acting as a client >>> for fetch and netperf tests. >>> A --- B --- C >>> The 2 1850s are running AMD64 Freebsd 6.0rc1 (A and B) while C is >>> running 5.4-stable i386 from Oct 12 >>> >>> My main problem is that if I compile SMP into the machine C >>> (5.4stable) the network speed goes down to a range between >>> 6mbytes/sec to 15mbytes/sec on SMP. >>> If I use GENERIC kernel the performance goes up to what I have show >>> below which is around 65megabytes/sec for a 'fetch' get test from >>> Apache server and 933mbits/sec for netperf. >>> Does any know why why network performance would be so bad on SMP? >>> >>> Does any one think that if I upgrade the i386 SMP server to 6.0RC1 >>> the SMP network performance would improve? This server will be >>> running java so I need it to be stable and is the the reason I am >>> using i386 and Java 1.4 >>> >>> I am happy with performance of direct machine to machine (non SMP) >>> which is pretty much full 1gigabit/sec speeds. >>> Going through the gateway server-B seems to drop its speed down a >>> bit for in and out direction tcp speed tests using netperf I get >>> around 266mbits/sec from server A through gateway Server-B to >>> server-C which is quite adequate for the link I currently have for it. >>> >>> Doing a 'fetch' get for a 1gig file from the Apache server gives >>> good speeds of close to 600mbits/sec but netperf shows its weakness >>> with 266mbits/sec. >>> This is as fast as I need it to be but does any one know the weak >>> points on the router gateway to make it faster? Is this the >>> performance I should expect for FreeBSD as a router with gigabit >>> ethers? >>> >>> I have seen 'net.inet.ip.fastforwarding' in some peoples router >>> setups on the list but nothing about what it does or what it can >>> affect. >>> I haven't done any testing with polling yet but if I can get over >>> 900mbits/sec on the interfaces does polling help with passing >>> packets from one interface to the other? >>> All machines have PF running other then that they don't really have >>> any sysctls or special kernel options. >>> >>> Here are some speed benchmarks using netperf and 'fetch' gets. >>> >>> Server A to server C with server C using SMP kernel and just GENERIC >>> kernel further below >>> >>> B# /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i >>> 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 >>> TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram >>> Recv Send Send >>> Socket Socket Message Elapsed >>> Size Size Size Time Throughput >>> bytes bytes bytes secs. 10^6bits/sec >>> >>> 57344 57344 4096 10.06 155.99 >>> tank# fetch -o - > /dev/null http://server-C/file1gig.iso >>> - 100% of 1055 MB 13 >>> MBps 00m00s >>> >>> ##### Using generic non SMP kernel >>> Server A to server C with server C using GENERIC kernel. >>> A# fetch -o - > /dev/null http://server-C/file1gig.iso >>> - 100% of 1055 MB 59 >>> MBps 00m00s >>> >>> A# ./tcp_stream_script server-C >>> >>> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 >>> -I 99,5 -- -m 4096 -s 57344 -S 57344 >>> >>> Recv Send Send >>> Socket Socket Message Elapsed >>> Size Size Size Time Throughput >>> bytes bytes bytes secs. 10^6bits/sec >>> >>> 57344 57344 4096 60.43 266.92 >>> >>> ------------------------------------ >>> ############################################### >>> Connecting from server-A to B (gateway) >>> A# ./tcp_stream_script server-B >>> >>> ------------------------------------ >>> >>> /usr/local/netperf/netperf -l 60 -H server-B -t TCP_STREAM -i 10,2 >>> -I 99,5 -- -m 4096 -s 57344 -S 57344 >>> >>> TCP STREAM TEST to server-B : +/-2.5% @ 99% conf. : histogram >>> Recv Send Send >>> Socket Socket Message Elapsed >>> Size Size Size Time Throughput >>> bytes bytes bytes secs. 10^6bits/sec >>> >>> 57344 57344 4096 61.80 926.82 >>> >>> ------------------------------------ >>> ########################################## >>> Connecting from server B (gateway) to server C >>> Fetch and Apache2 test >>> B# fetch -o - > /dev/null http://server-C/file1gig.iso >>> - 100% of 1055 MB 74 >>> MBps 00m00s >>> >>> Netperf test >>> B# /usr/local/netperf/tcp_stream_script server-C >>> >>> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 >>> -I 99,5 -- -m 4096 -s 57344 -S 57344 >>> >>> TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram >>> Recv Send Send >>> Socket Socket Message Elapsed >>> Size Size Size Time Throughput >>> bytes bytes bytes secs. 10^6bits/sec >>> >>> 57344 57344 4096 62.20 933.94 >>> >>> ------------------------------------ >>> >>> Cheers, >>> Mike >>> >>> _______________________________________________ >>> 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-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 08:26:54 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 869D916A431; Thu, 20 Oct 2005 08:26:54 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1647243D62; Thu, 20 Oct 2005 08:26:54 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id F0E4A4CFF9; Thu, 20 Oct 2005 08:27:07 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 183E84CFF7; Thu, 20 Oct 2005 08:27:05 +0000 (GMT) Message-ID: <435754CB.3060501@roq.com> Date: Thu, 20 Oct 2005 18:26:51 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> In-Reply-To: <43564800.3010309@roq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: stable@freebsd.org Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 08:26:54 -0000 Here is my probably final round of tests that I thought could possible be useful to others. I have enabled polling on the interfaces and discovered some of the master secret holy grail sysctls that really make this stuff work. I now get over 900mbits/sec router performance with polling. Having sysctl either net.isr.direct=1 or net.inet.ip.fastforwarding=1 gave roughly an extra 445mbits performance increase according to netperf tests, because my tests aren't really lab strict enough I still haven't been able to easily see a difference between having net.isr.direct=1 or 0 while also having net.inet.ip.fastforwarding set to 1, it does appear that having net.isr.direct=1 might be stealing the job of the net.inet.ip.fastforwarding sysctl because when net.inet.ip.fastforwarding=0 and net.isr.direct=1 on the gateway I still get the 905.48mbit/sec route speed listed below. From the client machine (A) through the gateway (B with polling enabled) to the server (C) With net.isr.direct=1 and net.inet.ip.fastforwarding=1 A> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Elapsed Throughput - 10^6bits/sec: 905.48 With net.isr.direct=0 and net.inet.ip.fastforwarding=0 Elapsed Throughput - 10^6bits/sec: 460.15 Apache get 'fetch' test. A> fetch -o - > /dev/null http://server-C/file1gig.iso - 100% of 1055 MB 67 MBps 00m00s Interestingly when testing from the gateway it self (B) direct to server (C) having 'net.isr.direct=1' slowed down performance to 583mbits/sec B> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Elapsed Throughput - 10^6bits/sec: 583.57 Same test with 'net.isr.direct=0' Elapsed Throughput - 10^6bits/sec: 868.94 I have to ask how can this be possible if when its being used as a router with net.isr.direct=1 it passes traffic at over 900mbits/sec Having net.inet.ip.fastforwarding=1 doesn't affect the performance in these B to C tests. I believe faster performance may still be possible as another rack of gear I have that has another AMD64 6.0 RC1 Dell 2850 (Kes) gives me up to 930mbits/sec in apache fetch tests, I believe its even faster here because its an AMD64 Apache server or its possible it could just have a bit better quality ether cables, as I mentioned before the Apache server for box "C" in above tests is i386 on 6.0RC1. This fetch test is only on a switch with no router between them. spin> fetch -o - > /dev/null http://kes/500megs.zip - 100% of 610 MB 93 MBps So far from this casual testing I have discovered these things on my servers. Using 6.0 on SMP servers gives a big boost in network performance over 5.x SMP using i386 or AMD64 FreeBSD as router on gigabit ethernet with the use of polling gives over x2 performance with the right sysctls. Needs more testing but it appears using AMD64 FreeBSD might be better then i386 for Apache2 network performance on SMP kernels. Single interface speeds tests from the router with polling enabled and with 'net.isr.direct=1' appears to affect performance. Regards, Mike Michael VInce wrote: > Robert Watson wrote: > >> >> On Fri, 14 Oct 2005, Michael VInce wrote: >> >>> I been doing some network benchmarking using netperf and just simple >>> 'fetch' on a new network setup to make sure I am getting the most >>> out of the router and servers, I thought I would post some results >>> in case some one can help me with my problems or if others are just >>> interested to see the results. >> >> >> >> Until recently (or maybe still), netperf was compiled with >> -DHISTOGRAM by our port/package, which resulted in a significant >> performance drop. I believe that the port maintainer and others have >> agreed to change it, but I'm not sure if it's been committed yet, or >> which packages have been rebuilt. You may want to manually rebuild >> it to make sure -DHISTOGRAM isn't set. >> >> You may want to try setting net.isr.direct=1 and see what performance >> impact that has for you. >> >> Robert N M Watson > > > I reinstalled the netperf to make sure its the latest. > > I have also decided to upgrade Server-C (the i386 5.4 box) to 6.0RC1 > and noticed it gave a large improvement of network performance with a > SMP kernel. > > As with the network setup ( A --- B --- C ) with server B being the > gateway, doing a basic 'fetch' from the gateway (B) to the Apache > server (C) it gives up to 700mbits/sec transfer performance, doing a > fetch from server A thus going through the gateway gives slower but > still decent performance of up to 400mbits/sec. > > B> fetch -o - > /dev/null http://server-c/file1gig.iso > - 100% of 1055 MB 69 > MBps 00m00s > > > A> fetch -o - > /dev/null http://server-c/file1gig.iso > - 100% of 1055 MB 39 > MBps 00m00s > > Netperf from the gateway directly to the apache server (C) 916mbits/sec > B> /usr/local/netperf/netperf -l 20 -H server-C -t TCP_STREAM -i 10,2 > -I 99,5 -- -m 4096 -s 57344 -S 57344 > Elapsed Throughput - 10^6bits/sec: 916.50 > > Netperf from the client machine through the gateway to the apache > server (C) 315mbits/sec > A> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 > -I 99,5 -- -m 4096 -s 57344 -S 57344 > Elapsed Throughput - 10^6bits/sec: 315.89 > > Client to gateway netperf test shows the direct connection between > these machines is fast. 912mbits/sec > A> /usr/local/netperf/netperf -l 30 -H server-B -t TCP_STREAM -i 10,2 > -I 99,5 -- -m 4096 -s 57344 -S 5734 > Elapsed Throughput - 10^6bits/sec: 912.11 > > The strange thing now is in my last post I was able to get faster > speeds from server A to C with 'fetch' tests on non-smp kernels and > slower speeds with netperf tests. Now I get speeds a bit slower with > fetch tests but faster netperf speed tests with or without SMP on > server-C. > > I was going to test with 'net.isr.dispatch' but the sysctl doesn't > appear to exist, doing this returns nothing. > 'sysctl -a | grep 'net.isr.dispatch' > > I also tried polling but its also like that doesn't exist either. > ifconfig em3 inet 192.168.1.1 netmask 255.255.255.224 polling > ifconfig: polling: Invalid argument > > When doing netperf tests there was high interrupt usage. > CPU states: 0.7% user, 0.0% nice, 13.5% system, 70.0% interrupt, > 15.7% idle > > Also the server B is using its last 2 gigabit ethernet ports which are > listed from pciconf -lv as '82547EI Gigabit Ethernet Controller' > While the first 2 are listed as 'PRO/1000 P' > Does any one know if the PRO/1000P would be better? > > em0@pci5:4:0: class=0x020000 card=0x118a8086 chip=0x108a8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 P' > > em3@pci9:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82547EI Gigabit Ethernet Controller' > > Cheers, > Mike > >> >>> >>> The network is currently like this, where machines A and B are the >>> Dell 1850s and C is the 2850 x 2 CPU (Server C has Apache2 worker >>> MPM on it) and server B is the gateway and A is acting as a client >>> for fetch and netperf tests. >>> A --- B --- C >>> The 2 1850s are running AMD64 Freebsd 6.0rc1 (A and B) while C is >>> running 5.4-stable i386 from Oct 12 >>> >>> My main problem is that if I compile SMP into the machine C >>> (5.4stable) the network speed goes down to a range between >>> 6mbytes/sec to 15mbytes/sec on SMP. >>> If I use GENERIC kernel the performance goes up to what I have show >>> below which is around 65megabytes/sec for a 'fetch' get test from >>> Apache server and 933mbits/sec for netperf. >>> Does any know why why network performance would be so bad on SMP? >>> >>> Does any one think that if I upgrade the i386 SMP server to 6.0RC1 >>> the SMP network performance would improve? This server will be >>> running java so I need it to be stable and is the the reason I am >>> using i386 and Java 1.4 >>> >>> I am happy with performance of direct machine to machine (non SMP) >>> which is pretty much full 1gigabit/sec speeds. >>> Going through the gateway server-B seems to drop its speed down a >>> bit for in and out direction tcp speed tests using netperf I get >>> around 266mbits/sec from server A through gateway Server-B to >>> server-C which is quite adequate for the link I currently have for it. >>> >>> Doing a 'fetch' get for a 1gig file from the Apache server gives >>> good speeds of close to 600mbits/sec but netperf shows its weakness >>> with 266mbits/sec. >>> This is as fast as I need it to be but does any one know the weak >>> points on the router gateway to make it faster? Is this the >>> performance I should expect for FreeBSD as a router with gigabit >>> ethers? >>> >>> I have seen 'net.inet.ip.fastforwarding' in some peoples router >>> setups on the list but nothing about what it does or what it can >>> affect. >>> I haven't done any testing with polling yet but if I can get over >>> 900mbits/sec on the interfaces does polling help with passing >>> packets from one interface to the other? >>> All machines have PF running other then that they don't really have >>> any sysctls or special kernel options. >>> >>> Here are some speed benchmarks using netperf and 'fetch' gets. >>> >>> Server A to server C with server C using SMP kernel and just GENERIC >>> kernel further below >>> >>> B# /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i >>> 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 >>> TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram >>> Recv Send Send >>> Socket Socket Message Elapsed >>> Size Size Size Time Throughput >>> bytes bytes bytes secs. 10^6bits/sec >>> >>> 57344 57344 4096 10.06 155.99 >>> tank# fetch -o - > /dev/null http://server-C/file1gig.iso >>> - 100% of 1055 MB 13 >>> MBps 00m00s >>> >>> ##### Using generic non SMP kernel >>> Server A to server C with server C using GENERIC kernel. >>> A# fetch -o - > /dev/null http://server-C/file1gig.iso >>> - 100% of 1055 MB 59 >>> MBps 00m00s >>> >>> A# ./tcp_stream_script server-C >>> >>> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 >>> -I 99,5 -- -m 4096 -s 57344 -S 57344 >>> >>> Recv Send Send >>> Socket Socket Message Elapsed >>> Size Size Size Time Throughput >>> bytes bytes bytes secs. 10^6bits/sec >>> >>> 57344 57344 4096 60.43 266.92 >>> >>> ------------------------------------ >>> ############################################### >>> Connecting from server-A to B (gateway) >>> A# ./tcp_stream_script server-B >>> >>> ------------------------------------ >>> >>> /usr/local/netperf/netperf -l 60 -H server-B -t TCP_STREAM -i 10,2 >>> -I 99,5 -- -m 4096 -s 57344 -S 57344 >>> >>> TCP STREAM TEST to server-B : +/-2.5% @ 99% conf. : histogram >>> Recv Send Send >>> Socket Socket Message Elapsed >>> Size Size Size Time Throughput >>> bytes bytes bytes secs. 10^6bits/sec >>> >>> 57344 57344 4096 61.80 926.82 >>> >>> ------------------------------------ >>> ########################################## >>> Connecting from server B (gateway) to server C >>> Fetch and Apache2 test >>> B# fetch -o - > /dev/null http://server-C/file1gig.iso >>> - 100% of 1055 MB 74 >>> MBps 00m00s >>> >>> Netperf test >>> B# /usr/local/netperf/tcp_stream_script server-C >>> >>> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 >>> -I 99,5 -- -m 4096 -s 57344 -S 57344 >>> >>> TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram >>> Recv Send Send >>> Socket Socket Message Elapsed >>> Size Size Size Time Throughput >>> bytes bytes bytes secs. 10^6bits/sec >>> >>> 57344 57344 4096 62.20 933.94 >>> >>> ------------------------------------ >>> >>> Cheers, >>> Mike >>> >>> _______________________________________________ >>> 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-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 08:52:48 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A44AA16A41F; Thu, 20 Oct 2005 08:52:48 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from mail.packetfront.com (mail.packetfront.com [212.247.6.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AED043D62; Thu, 20 Oct 2005 08:52:47 +0000 (GMT) (envelope-from raglon@packetfront.com) Received: from localhost (localhost [127.0.0.1]) by mail.packetfront.com (Postfix) with ESMTP id C9E46A3F82; Thu, 20 Oct 2005 10:52:45 +0200 (CEST) Received: from mail.packetfront.com ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14707-08; Thu, 20 Oct 2005 10:52:45 +0200 (CEST) Received: from [192.168.1.159] (unknown [192.168.1.159]) by mail.packetfront.com (Postfix) with ESMTP id 92A94A3F81; Thu, 20 Oct 2005 10:52:45 +0200 (CEST) Message-ID: <43575A74.6090004@packetfront.com> Date: Thu, 20 Oct 2005 10:51:00 +0200 From: Ragnar Lonn User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> In-Reply-To: <20051020070054.GZ59364@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at packetfront.com Cc: freebsd-net@FreeBSD.org, yar@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson Subject: Re: vlan patch 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, 20 Oct 2005 08:52:48 -0000 Gleb Smirnoff wrote: >Although the memory overhead is not noticable on modern i386 and amd64 >PCs I don't think that we should waste so much memory. We should keep >in mind the existence of embedded architectures with little memory. > >In most cases people use 10 - 30 VLANs. I suggest to use a hash, like it >is already done in ng_vlan(4). This hash makes every sixteenth VLAN to fall >into same slot. Since most people allocate VLAN ids contiguously the hash >distribution should be good. > >Moreover, I suggest Yar and Ruslan to work together and make the hash code >shared between vlan(4) and ng_vlan(4), not copy-and-pasted. > > It looks as if ng_vlan implements a standard hash. Wouldn't a hashtree be a good compromise between speed and memory usage? Of course, a 16-slot hash is a lot better than no hash at all :-) /Ragnar From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 08:57:29 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07D4316A41F; Thu, 20 Oct 2005 08:57:29 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CC643D5A; Thu, 20 Oct 2005 08:57:27 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j9K8vMHV036651; Thu, 20 Oct 2005 12:57:22 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j9K8vMgW036650; Thu, 20 Oct 2005 12:57:22 +0400 (MSD) (envelope-from yar) Date: Thu, 20 Oct 2005 12:57:21 +0400 From: Yar Tikhiy To: Gleb Smirnoff Message-ID: <20051020085721.GC27114@comp.chem.msu.su> References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051020070054.GZ59364@cell.sick.ru> User-Agent: Mutt/1.5.9i Cc: freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson Subject: Re: vlan patch 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, 20 Oct 2005 08:57:29 -0000 On Thu, Oct 20, 2005 at 11:00:54AM +0400, Gleb Smirnoff wrote: > > On Wed, Oct 19, 2005 at 11:25:59PM +1300, Andrew Thompson wrote: > A> It has always bugged me how the vlan code traverses the linked-list for > A> each incoming packet to find the right ifvlan, I have this patch which > A> attempts to fix this. > A> > A> What it does is replace the linear search for the vlan with a constant > A> time lookup. It does this by allocating an array for each vlan enabled > A> parent interface so the tag can be directly indexed. > A> > A> This has an overhead of ~16kb on 32bit, this is not too bad as there is > A> usually only one physical interface when using a large number of vlans. > A> > A> I have measured a 1.6% pps increase with 100 vlans, and 8% with 500, and > A> yes, some people use this many in production. > A> > A> It also has the benefit of enforcing unique vlan tags per parent which > A> the current code doesn't do. > > Although the memory overhead is not noticable on modern i386 and amd64 > PCs I don't think that we should waste so much memory. We should keep > in mind the existence of embedded architectures with little memory. Agreed. On amd64 or another 64-bit platform each physical interface carrying vlans will consume 32k of wired kernel memory, which is a rather valuable resource. We may not spend memory in the kernel as generously as in userland programs because it is usually physical memory spent in this case, not virtual one. > In most cases people use 10 - 30 VLANs. I suggest to use a hash, like it I'd rather not limit our consideration by 10-30 VLANs. People are running networks with hundreds of VLANs terminated at a FreeBSD gateway. Perhaps, the hash table should be roughly adjustable to the current number of configured VLANs. > is already done in ng_vlan(4). This hash makes every sixteenth VLAN to fall > into same slot. Since most people allocate VLAN ids contiguously the hash > distribution should be good. Apropos, XOR-folding used in ng_vlan isn't that dumb, it doesn't make every 16th VLAN fall into the same slot. Of course, you will start getting collisions at most on the 16th VLAN added since 16 is the size of the hash table. > Moreover, I suggest Yar and Ruslan to work together and make the hash code > shared between vlan(4) and ng_vlan(4), not copy-and-pasted. The hash code consists of literally a couple of #define's. And the difference between ng_vlan(4) and vlan(4) is that each ng_vlan node gets its own instance of the hash table. OTOH, in vlan(4) we need to decide if the hash table will be per parent interface or a single global instance. In the latter case we could hash by a combination of the VLAN tag and parent's ifindex. Perhaps this approach will yield more CPU cache hits during hash table lookups. In addition, it will be thriftier in using memory. Locking the global hash table should not be an issue as we can use an sx lock in this case for optimal read access. -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 09:19:36 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ECFE16A41F; Thu, 20 Oct 2005 09:19:36 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B660A43D66; Thu, 20 Oct 2005 09:19:35 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 2927B1CCDD; Thu, 20 Oct 2005 22:19:34 +1300 (NZDT) Date: Thu, 20 Oct 2005 22:19:34 +1300 From: Andrew Thompson To: Gleb Smirnoff , yar@FreeBSD.org, ru@FreeBSD.org, freebsd-net@freebsd.org Message-ID: <20051020091934.GA50908@heff.fud.org.nz> References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051020070054.GZ59364@cell.sick.ru> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: vlan patch 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, 20 Oct 2005 09:19:36 -0000 On Thu, Oct 20, 2005 at 11:00:54AM +0400, Gleb Smirnoff wrote: > Andrew, > > On Wed, Oct 19, 2005 at 11:25:59PM +1300, Andrew Thompson wrote: > A> It has always bugged me how the vlan code traverses the linked-list for > A> each incoming packet to find the right ifvlan, I have this patch which > A> attempts to fix this. > A> > A> What it does is replace the linear search for the vlan with a constant > A> time lookup. It does this by allocating an array for each vlan enabled > A> parent interface so the tag can be directly indexed. > A> > A> This has an overhead of ~16kb on 32bit, this is not too bad as there is > A> usually only one physical interface when using a large number of vlans. > A> > A> I have measured a 1.6% pps increase with 100 vlans, and 8% with 500, and > A> yes, some people use this many in production. > A> > A> It also has the benefit of enforcing unique vlan tags per parent which > A> the current code doesn't do. > > Although the memory overhead is not noticable on modern i386 and amd64 > PCs I don't think that we should waste so much memory. We should keep > in mind the existence of embedded architectures with little memory. > I agree. Did you see the revised patch that sets a threshold before allocating the memory? do you think thats sufficient? Andrew From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 10:25:26 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C38916A41F; Thu, 20 Oct 2005 10:25:26 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB8C743D66; Thu, 20 Oct 2005 10:25:25 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 3357546B10; Thu, 20 Oct 2005 06:25:25 -0400 (EDT) Date: Thu, 20 Oct 2005 11:25:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Michael VInce In-Reply-To: <435754CB.3060501@roq.com> Message-ID: <20051020110409.A24208@fledge.watson.org> References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> <435754CB.3060501@roq.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, stable@freebsd.org Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 10:25:26 -0000 On Thu, 20 Oct 2005, Michael VInce wrote: > Interestingly when testing from the gateway it self (B) direct to server > (C) having 'net.isr.direct=1' slowed down performance to 583mbits/sec net.isr.direct works to improve performance in many cases because it (a) reduces latency, and (b) reduces CPU usage. However, there are cases where it can effectively reduce performance because it reduces the opportunity for parallelism in those cases. Specifically, by constraining computation in in-bound IP path to occuring in a single thread rather than two (ithread vs. ithread and netisr), it prevents that computation from being executed on more than one CPU at a time. Understanding these cases is complicated by the fact that there may be multiple ithreads involved. Let me propose a scenario, which we may be able to confirm by looking at the output of top -S on the system involved: In the two-host test case, your experimental host is using three threads to process packets: the network interface ithread, the netisr thread, and the netserver thread. In the three host test case, where your experimental host is the forwarding system, you are also using three threads: the two interface ithreads, and the netisr. For the two-host case with net.isr.direct, work is split over these threads usefully, such that they form an execution pipeline passing data from CPU to CPU, and getting useful parallelism. Specifically, you are likely seeing significant parallelism between the ithread and the netisr. By turning on net.isr.direct, the in-bound IP stack processing occurs entirely in the ithread, with no work in the netisr, so parallelism is reduced, reducing the rate of work performed due to more synchronous waiting for CPU resources. Another possible issue here is increased delays in responding to interrupts due to high levels of work occuring in the ithread, and therefore more packets dropped from the card. In the three host case with net.isr.direct, all work occurs in the two ithreads, so IP processing in both directions can occur in parallel, whereas without net.isr.direct, all the IP processing happens in a single thread, limiting parallelism. The test to run is to have top -S running on the boxes, and see how much CPU is used by various threads in various test scenarios, and what the constraining resource is on the boxes. For example, if in the net.isr.direct scenario with two hosts, if the ithread for your ethernet interface is between 95% and 100% busy, but with net.isr.direct=0 the work is better split over threads, it might confirm the above description. On the other hand, if in both scenarios, the CPUs and threads aren't maxed out, it might suggest a problem with responsiveness to interrupts and packets dropped in the card, in which case card statistics might be useful to look at. Robert N M Watson > B> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 > -- -m 4096 -s 57344 -S 57344 > Elapsed Throughput - 10^6bits/sec: 583.57 > > Same test with 'net.isr.direct=0' > Elapsed Throughput - 10^6bits/sec: 868.94 > I have to ask how can this be possible if when its being used as a router > with net.isr.direct=1 it passes traffic at over 900mbits/sec > Having net.inet.ip.fastforwarding=1 doesn't affect the performance in these B > to C tests. > > I believe faster performance may still be possible as another rack of gear I > have that has another AMD64 6.0 RC1 Dell 2850 (Kes) gives me up to > 930mbits/sec in apache fetch tests, I believe its even faster here because > its an AMD64 Apache server or its possible it could just have a bit better > quality ether cables, as I mentioned before the Apache server for box "C" in > above tests is i386 on 6.0RC1. > > This fetch test is only on a switch with no router between them. > spin> fetch -o - > /dev/null http://kes/500megs.zip > - 100% of 610 MB 93 MBps > > So far from this casual testing I have discovered these things on my servers. > Using 6.0 on SMP servers gives a big boost in network performance over 5.x > SMP using i386 or AMD64 > FreeBSD as router on gigabit ethernet with the use of polling gives over x2 > performance with the right sysctls. > Needs more testing but it appears using AMD64 FreeBSD might be better then > i386 for Apache2 network performance on SMP kernels. > Single interface speeds tests from the router with polling enabled and with > 'net.isr.direct=1' appears to affect performance. > > Regards, > Mike > > Michael VInce wrote: > >> Robert Watson wrote: >> >>> >>> On Fri, 14 Oct 2005, Michael VInce wrote: >>> >>>> I been doing some network benchmarking using netperf and just simple >>>> 'fetch' on a new network setup to make sure I am getting the most out of >>>> the router and servers, I thought I would post some results in case some >>>> one can help me with my problems or if others are just interested to see >>>> the results. >>> >>> >>> >>> Until recently (or maybe still), netperf was compiled with -DHISTOGRAM by >>> our port/package, which resulted in a significant performance drop. I >>> believe that the port maintainer and others have agreed to change it, but >>> I'm not sure if it's been committed yet, or which packages have been >>> rebuilt. You may want to manually rebuild it to make sure -DHISTOGRAM >>> isn't set. >>> >>> You may want to try setting net.isr.direct=1 and see what performance >>> impact that has for you. >>> >>> Robert N M Watson >> >> >> I reinstalled the netperf to make sure its the latest. >> >> I have also decided to upgrade Server-C (the i386 5.4 box) to 6.0RC1 and >> noticed it gave a large improvement of network performance with a SMP >> kernel. >> >> As with the network setup ( A --- B --- C ) with server B being the >> gateway, doing a basic 'fetch' from the gateway (B) to the Apache server >> (C) it gives up to 700mbits/sec transfer performance, doing a fetch from >> server A thus going through the gateway gives slower but still decent >> performance of up to 400mbits/sec. >> >> B> fetch -o - > /dev/null http://server-c/file1gig.iso >> - 100% of 1055 MB 69 MBps >> 00m00s >> >> >> A> fetch -o - > /dev/null http://server-c/file1gig.iso >> - 100% of 1055 MB 39 MBps >> 00m00s >> >> Netperf from the gateway directly to the apache server (C) 916mbits/sec >> B> /usr/local/netperf/netperf -l 20 -H server-C -t TCP_STREAM -i 10,2 -I >> 99,5 -- -m 4096 -s 57344 -S 57344 >> Elapsed Throughput - 10^6bits/sec: 916.50 >> >> Netperf from the client machine through the gateway to the apache server >> (C) 315mbits/sec >> A> /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I >> 99,5 -- -m 4096 -s 57344 -S 57344 >> Elapsed Throughput - 10^6bits/sec: 315.89 >> >> Client to gateway netperf test shows the direct connection between these >> machines is fast. 912mbits/sec >> A> /usr/local/netperf/netperf -l 30 -H server-B -t TCP_STREAM -i 10,2 -I >> 99,5 -- -m 4096 -s 57344 -S 5734 >> Elapsed Throughput - 10^6bits/sec: 912.11 >> >> The strange thing now is in my last post I was able to get faster speeds >> from server A to C with 'fetch' tests on non-smp kernels and slower speeds >> with netperf tests. Now I get speeds a bit slower with fetch tests but >> faster netperf speed tests with or without SMP on server-C. >> >> I was going to test with 'net.isr.dispatch' but the sysctl doesn't appear >> to exist, doing this returns nothing. >> 'sysctl -a | grep 'net.isr.dispatch' >> >> I also tried polling but its also like that doesn't exist either. >> ifconfig em3 inet 192.168.1.1 netmask 255.255.255.224 polling >> ifconfig: polling: Invalid argument >> >> When doing netperf tests there was high interrupt usage. >> CPU states: 0.7% user, 0.0% nice, 13.5% system, 70.0% interrupt, 15.7% >> idle >> >> Also the server B is using its last 2 gigabit ethernet ports which are >> listed from pciconf -lv as '82547EI Gigabit Ethernet Controller' >> While the first 2 are listed as 'PRO/1000 P' >> Does any one know if the PRO/1000P would be better? >> >> em0@pci5:4:0: class=0x020000 card=0x118a8086 chip=0x108a8086 rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'PRO/1000 P' >> >> em3@pci9:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82547EI Gigabit Ethernet Controller' >> >> Cheers, >> Mike >> >>> >>>> >>>> The network is currently like this, where machines A and B are the Dell >>>> 1850s and C is the 2850 x 2 CPU (Server C has Apache2 worker MPM on it) >>>> and server B is the gateway and A is acting as a client for fetch and >>>> netperf tests. >>>> A --- B --- C >>>> The 2 1850s are running AMD64 Freebsd 6.0rc1 (A and B) while C is running >>>> 5.4-stable i386 from Oct 12 >>>> >>>> My main problem is that if I compile SMP into the machine C (5.4stable) >>>> the network speed goes down to a range between 6mbytes/sec to >>>> 15mbytes/sec on SMP. >>>> If I use GENERIC kernel the performance goes up to what I have show below >>>> which is around 65megabytes/sec for a 'fetch' get test from Apache server >>>> and 933mbits/sec for netperf. >>>> Does any know why why network performance would be so bad on SMP? >>>> >>>> Does any one think that if I upgrade the i386 SMP server to 6.0RC1 the >>>> SMP network performance would improve? This server will be running java >>>> so I need it to be stable and is the the reason I am using i386 and Java >>>> 1.4 >>>> >>>> I am happy with performance of direct machine to machine (non SMP) which >>>> is pretty much full 1gigabit/sec speeds. >>>> Going through the gateway server-B seems to drop its speed down a bit for >>>> in and out direction tcp speed tests using netperf I get around >>>> 266mbits/sec from server A through gateway Server-B to server-C which is >>>> quite adequate for the link I currently have for it. >>>> >>>> Doing a 'fetch' get for a 1gig file from the Apache server gives good >>>> speeds of close to 600mbits/sec but netperf shows its weakness with >>>> 266mbits/sec. >>>> This is as fast as I need it to be but does any one know the weak points >>>> on the router gateway to make it faster? Is this the performance I should >>>> expect for FreeBSD as a router with gigabit ethers? >>>> >>>> I have seen 'net.inet.ip.fastforwarding' in some peoples router setups on >>>> the list but nothing about what it does or what it can affect. >>>> I haven't done any testing with polling yet but if I can get over >>>> 900mbits/sec on the interfaces does polling help with passing packets >>>> from one interface to the other? >>>> All machines have PF running other then that they don't really have any >>>> sysctls or special kernel options. >>>> >>>> Here are some speed benchmarks using netperf and 'fetch' gets. >>>> >>>> Server A to server C with server C using SMP kernel and just GENERIC >>>> kernel further below >>>> >>>> B# /usr/local/netperf/netperf -l 10 -H server-C -t TCP_STREAM -i 10,2 -I >>>> 99,5 -- -m 4096 -s 57344 -S 57344 >>>> TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram >>>> Recv Send Send >>>> Socket Socket Message Elapsed >>>> Size Size Size Time Throughput >>>> bytes bytes bytes secs. 10^6bits/sec >>>> >>>> 57344 57344 4096 10.06 155.99 >>>> tank# fetch -o - > /dev/null http://server-C/file1gig.iso >>>> - 100% of 1055 MB 13 MBps >>>> 00m00s >>>> >>>> ##### Using generic non SMP kernel >>>> Server A to server C with server C using GENERIC kernel. >>>> A# fetch -o - > /dev/null http://server-C/file1gig.iso >>>> - 100% of 1055 MB 59 MBps >>>> 00m00s >>>> >>>> A# ./tcp_stream_script server-C >>>> >>>> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I >>>> 99,5 -- -m 4096 -s 57344 -S 57344 >>>> >>>> Recv Send Send >>>> Socket Socket Message Elapsed >>>> Size Size Size Time Throughput >>>> bytes bytes bytes secs. 10^6bits/sec >>>> >>>> 57344 57344 4096 60.43 266.92 >>>> >>>> ------------------------------------ >>>> ############################################### >>>> Connecting from server-A to B (gateway) >>>> A# ./tcp_stream_script server-B >>>> >>>> ------------------------------------ >>>> >>>> /usr/local/netperf/netperf -l 60 -H server-B -t TCP_STREAM -i 10,2 -I >>>> 99,5 -- -m 4096 -s 57344 -S 57344 >>>> >>>> TCP STREAM TEST to server-B : +/-2.5% @ 99% conf. : histogram >>>> Recv Send Send >>>> Socket Socket Message Elapsed >>>> Size Size Size Time Throughput >>>> bytes bytes bytes secs. 10^6bits/sec >>>> >>>> 57344 57344 4096 61.80 926.82 >>>> >>>> ------------------------------------ >>>> ########################################## >>>> Connecting from server B (gateway) to server C >>>> Fetch and Apache2 test >>>> B# fetch -o - > /dev/null http://server-C/file1gig.iso >>>> - 100% of 1055 MB 74 MBps >>>> 00m00s >>>> >>>> Netperf test >>>> B# /usr/local/netperf/tcp_stream_script server-C >>>> >>>> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I >>>> 99,5 -- -m 4096 -s 57344 -S 57344 >>>> >>>> TCP STREAM TEST to server-C : +/-2.5% @ 99% conf. : histogram >>>> Recv Send Send >>>> Socket Socket Message Elapsed >>>> Size Size Size Time Throughput >>>> bytes bytes bytes secs. 10^6bits/sec >>>> >>>> 57344 57344 4096 62.20 933.94 >>>> >>>> ------------------------------------ >>>> >>>> Cheers, >>>> Mike >>>> >>>> _______________________________________________ >>>> 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-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 11:15:54 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8F1216A42B; Thu, 20 Oct 2005 11:15:54 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3627543D5A; Thu, 20 Oct 2005 11:15:53 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1ESYOI-0002nL-FU; Thu, 20 Oct 2005 13:15:23 +0200 Date: Thu, 20 Oct 2005 13:15:49 +0200 From: Marcin Jessa To: Gleb Smirnoff Message-Id: <20051020131549.5e432073.lists@yazzy.org> In-Reply-To: <20051020070145.GA59364@cell.sick.ru> References: <20051019235111.2225345e.lists@yazzy.org> <20051020070145.GA59364@cell.sick.ru> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 20 Oct 2005 11:15:55 -0000 On Thu, 20 Oct 2005 11:01:45 +0400 Gleb Smirnoff wrote: > On Wed, Oct 19, 2005 at 11:51:11PM +0200, Marcin Jessa wrote: > M> It seems like PPPoE stoped working with support for radius on 6.0 > M> The log of pppoe and freeradius does not show pppoe attempting to > M> even talk to the radius server. Additionally this message pops up > M> when enabling pppoed: WARNING: attempt to net_add_domain(netgraph) > M> after domainfinalize() My setup worked fine before on FreeBSD 5.x > M> Is that a known issue and is it being worked on? > > Please show your PPPoE server configuration. Do you use pppoed or mpd? I use pppoed. Adding netgraph_load="YES" ng_socket_load="YES" to /boot/loader.conf fixed it on my 6.0RC1 ( thanks Julian Elischer ) Frankly I don't understand why this is needed since pppoed loads those modules when it starts up. This is my ppp.conf, just for the record: default: #set log Chat Command Phase #turn on some logging. See man ppp.conf for info set log Chat Command Phase hdlc lqm ipcp enable mschapv2 mschap chap mppe #turn on chap and pap accounting #enable pap mschapv2 mschap chap mppe #turn on chap and pap accounting #enable pap #turn on chap and pap accounting allow mode direct #turn on ppp bridging enable proxy #turn on ppp proxyarping (redundant of above???) disable ipv6cp #we don't use ipv6, don't want the errors set mru 1472 #set mru below 1500 (PPPoE MTU issue) set mtu 1472 #set mtu below 1500 (PPPoE MTU issue) set timeout 0 #no mins time restriction on users #set timeout never set mppe 128 * set ifaddr 192.168.2.8 192.168.2.100-192.168.1.120 255.255.255.255 set log phase ipcp lcp debug #additional debugging nat enable yes set dns 192.168.2.45 192.168.2.8 #set speed sync set cd 3 # checks for the existence of carrier once per second for 5 seconds #set cd 5! #enable echo enable lqr set reconnect 1 5 # Should the line drop unexpectedly , a connection will be re-established after the given timeout. #Specify my wifi gateway IP as well as DHCP pool range set radius /etc/ppp/radius.conf #turn on radius auth and use this file accept dns #turn on dns cacheing/forwarding #enable pap mschapv2 mschap chap mppe #turn on chap and pap accounting disable pap pred1 deflate #disable pred1 and deflate compression along with pap deny pap pred1 deflate #refuse when ask for it From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 12:10:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55E3616A41F; Thu, 20 Oct 2005 12:10:50 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFB8243D77; Thu, 20 Oct 2005 12:10:46 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j9KCAiau047585; Thu, 20 Oct 2005 16:10:44 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j9KCAi99047584; Thu, 20 Oct 2005 16:10:44 +0400 (MSD) (envelope-from yar) Date: Thu, 20 Oct 2005 16:10:43 +0400 From: Yar Tikhiy To: Andrew Thompson Message-ID: <20051020121043.GA47217@comp.chem.msu.su> References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> <20051020091934.GA50908@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051020091934.GA50908@heff.fud.org.nz> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: vlan patch 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, 20 Oct 2005 12:10:50 -0000 On Thu, Oct 20, 2005 at 10:19:34PM +1300, Andrew Thompson wrote: > On Thu, Oct 20, 2005 at 11:00:54AM +0400, Gleb Smirnoff wrote: > > Andrew, > > > > On Wed, Oct 19, 2005 at 11:25:59PM +1300, Andrew Thompson wrote: > > A> It has always bugged me how the vlan code traverses the linked-list for > > A> each incoming packet to find the right ifvlan, I have this patch which > > A> attempts to fix this. > > A> > > A> What it does is replace the linear search for the vlan with a constant > > A> time lookup. It does this by allocating an array for each vlan enabled > > A> parent interface so the tag can be directly indexed. > > A> > > A> This has an overhead of ~16kb on 32bit, this is not too bad as there is > > A> usually only one physical interface when using a large number of vlans. > > A> > > A> I have measured a 1.6% pps increase with 100 vlans, and 8% with 500, and > > A> yes, some people use this many in production. > > A> > > A> It also has the benefit of enforcing unique vlan tags per parent which > > A> the current code doesn't do. > > > > Although the memory overhead is not noticable on modern i386 and amd64 > > PCs I don't think that we should waste so much memory. We should keep > > in mind the existence of embedded architectures with little memory. > > I agree. Did you see the revised patch that sets a threshold before > allocating the memory? do you think thats sufficient? I'm afraid that the simple approach of setting a threshold isn't much better than no such threshold at all. The number of vlans in use tends to grow in time in most cases, but it still will be several times less than the maximum, 4096, which defines the full tag table size. I believe we should keep this in mind. -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 12:13:58 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F15216A41F for ; Thu, 20 Oct 2005 12:13:58 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35712.mail.mud.yahoo.com (web35712.mail.mud.yahoo.com [66.163.179.166]) by mx1.FreeBSD.org (Postfix) with SMTP id C796543D62 for ; Thu, 20 Oct 2005 12:13:57 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 37164 invoked by uid 60001); 20 Oct 2005 12:13:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=sRO4KoQhrbGeAAd5jEON+UFiXHOAh3/MiGp9lJ0/WpTNY/zQW0K2eEIZ6K6AbJRprXcwzDn6UChPButpMoeJuCNsZcyz+Hvi7Zn7MKcOltAz26OzBmC8pNwTXzonh/eOQs1yckBWxyotoNKyqnqrw/7GrLn3wx17uN/9Ii85xWc= ; Message-ID: <20051020121357.37162.qmail@web35712.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35712.mail.mud.yahoo.com via HTTP; Thu, 20 Oct 2005 05:13:57 PDT Date: Thu, 20 Oct 2005 05:13:57 -0700 (PDT) From: kamal kc To: freebsd MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: mbuf passed to if_output() in ip_output() 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, 20 Oct 2005 12:13:58 -0000 dear everybody, i have encountered a problem big enough for me to handle. Actually i am trying to compress the data contained in the ip packets. i see that the data to be passed by ip to link layer output routine is contained in mbuf *m. Now what i tried to do is I tried to copy the original mbufs to newer mbufs and passed the newer mbufs to the if_output() instead of the older ones. And I tried to release the older mbufs myself. For this purpose i wrote the routine below. But it doesn't seem to work. The problem I encounter is the mbuf in the ip_output doesnot seem to be released and gets printed(by my custom routine) infinitely. What is the problem ??? Please help kamal PS. i have put the code with which i tried to replace the original mbufs void copy_the_memorybuffer(struct mbuf **m) { struct mbuf *tmp_mbuf; struct mbuf *mbuf_pointer=*m; //original mbuf header struct mbuf **mnext; struct mbuf **second_mbuf_pointer; struct mbuf **second_packet_pointer; struct mbuf **next_packet; unsigned int ipheaderlength; unsigned int packet_length; unsigned char *ip_char_buffer; int i; //loop variable second_packet_pointer=&mbuf_pointer->m_nextpkt; next_packet=&mbuf_pointer->m_nextpkt; for(;*next_packet;*next_packet=(*next_packet)->m_nextpkt) { if(((*next_packet)->m_flags & M_PKTHDR)!=0) { struct ip *dest_ip; dest_ip=mtod((*next_packet),struct ip *); dest_ip->ip_tos=66; printf("\nDestination ip (next_packet)=%s\n",inet_ntoa(dest_ip->ip_dst)); } second_mbuf_pointer=&(*next_packet)->m_next; mnext=&(*next_packet)->m_next; //keep the first packet as it is for(;*mnext;*mnext=(*mnext)->m_next) //loop until the end of memory buffer { printf("\ninside the for loop(mnext)\n"); if(((*mnext)->m_flags & M_PKTHDR)!=0) //this is the start of the packet { MGETHDR(tmp_mbuf,M_WAIT,(*mnext)->m_type); if(((*mnext)->m_flags & M_EXT)!=0) //uses a cluster MCLGET(tmp_mbuf,M_WAIT); struct ip *my_ip; my_ip=mtod(*mnext,struct ip *); my_ip->ip_tos=55; printf("\nDestination ip=%s\n",inet_ntoa(my_ip->ip_dst)); ipheaderlength=my_ip->ip_hl<<2; //4*ip header length= real header length packet_length=(*mnext)->m_len; ip_char_buffer=(unsigned char *)my_ip; for(i=0;im_data[i]=(*mnext)->m_data[i]; } for(i=ipheaderlength;im_data[i]=(*mnext)->m_data[i]; } tmp_mbuf->m_pkthdr.len=(*mnext)->m_pkthdr.len; tmp_mbuf->m_pkthdr.rcvif=(struct ifnet *)0; tmp_mbuf->m_pkthdr.header=(*mnext)->m_pkthdr.header; tmp_mbuf->m_pkthdr.csum_flags=(*mnext)->m_pkthdr.csum_flags; tmp_mbuf->m_pkthdr.csum_data=(*mnext)->m_pkthdr.csum_data; } else //the mbuf is not the packet header so it does not contain the ip header { MGET(tmp_mbuf,M_WAIT,(*mnext)->m_type); if(((*mnext)->m_flags & M_EXT)!=0) MCLGET(tmp_mbuf,M_WAIT); packet_length=(*mnext)->m_len; for(i=0;im_data[i]=(*mnext)->m_data[i]; } } tmp_mbuf->m_len=(*mnext)->m_len; tmp_mbuf->m_flags=(*mnext)->m_flags; tmp_mbuf->m_nextpkt=(*mnext)->m_nextpkt; tmp_mbuf->m_next=(*mnext)->m_next; *mnext=tmp_mbuf; } m_freem(*second_mbuf_pointer); } *m=mbuf_pointer; return; } __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 12:22:03 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03B8E16A41F; Thu, 20 Oct 2005 12:22:03 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CFC243D66; Thu, 20 Oct 2005 12:22:00 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j9KCLtCf048214; Thu, 20 Oct 2005 16:21:55 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j9KCLqEe048213; Thu, 20 Oct 2005 16:21:52 +0400 (MSD) (envelope-from yar) Date: Thu, 20 Oct 2005 16:21:52 +0400 From: Yar Tikhiy To: Ragnar Lonn Message-ID: <20051020122151.GB47217@comp.chem.msu.su> References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> <43575A74.6090004@packetfront.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43575A74.6090004@packetfront.com> User-Agent: Mutt/1.5.9i Cc: freebsd-net@FreeBSD.org, Gleb Smirnoff , ru@FreeBSD.org, Andrew Thompson Subject: Re: vlan patch 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, 20 Oct 2005 12:22:03 -0000 On Thu, Oct 20, 2005 at 10:51:00AM +0200, Ragnar Lonn wrote: > Gleb Smirnoff wrote: > > >Although the memory overhead is not noticable on modern i386 and amd64 > >PCs I don't think that we should waste so much memory. We should keep > >in mind the existence of embedded architectures with little memory. > > > >In most cases people use 10 - 30 VLANs. I suggest to use a hash, like it > >is already done in ng_vlan(4). This hash makes every sixteenth VLAN to fall > >into same slot. Since most people allocate VLAN ids contiguously the hash > >distribution should be good. > > > >Moreover, I suggest Yar and Ruslan to work together and make the hash code > >shared between vlan(4) and ng_vlan(4), not copy-and-pasted. > > It looks as if ng_vlan implements a standard hash. Wouldn't a hashtree > be a good > compromise between speed and memory usage? Of course, a 16-slot hash is > a lot > better than no hash at all :-) The only problem with the hash currently used in ng_vlan is that it is fixed-width. I think it will be easy to teach it how to cope with variable bit-width of hash using the same xor-folding technique. I hope I'll have free time this week-end to test the performance of the approaches discussed since implementing them is no problem at all. -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 12:32:37 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C1C516A420; Thu, 20 Oct 2005 12:32:37 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 231BF43D5A; Thu, 20 Oct 2005 12:32:36 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=lapdance.yazzy.net) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1ESZaX-0005YO-MA; Thu, 20 Oct 2005 14:32:06 +0200 Date: Thu, 20 Oct 2005 12:31:59 +0000 From: Marcin Jessa To: Marcin Jessa Message-Id: <20051020123159.33f6fa33.lists@yazzy.org> In-Reply-To: <20051020131549.5e432073.lists@yazzy.org> References: <20051019235111.2225345e.lists@yazzy.org> <20051020070145.GA59364@cell.sick.ru> <20051020131549.5e432073.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.2 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: glebius@FreeBSD.org, current@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 20 Oct 2005 12:32:38 -0000 On Thu, 20 Oct 2005 13:15:49 +0200 Marcin Jessa wrote: > On Thu, 20 Oct 2005 11:01:45 +0400 > Gleb Smirnoff wrote: > > > On Wed, Oct 19, 2005 at 11:51:11PM +0200, Marcin Jessa wrote: > > M> It seems like PPPoE stoped working with support for radius on 6.0 > > M> The log of pppoe and freeradius does not show pppoe attempting to > > M> even talk to the radius server. Additionally this message pops up > > M> when enabling pppoed: WARNING: attempt to net_add_domain > > M> (netgraph) after domainfinalize() My setup worked fine before on > > M> FreeBSD 5.x Is that a known issue and is it being worked on? > > > > Please show your PPPoE server configuration. Do you use pppoed or > > mpd? > > I use pppoed. > Adding > netgraph_load="YES" > ng_socket_load="YES" > to /boot/loader.conf fixed it on my 6.0RC1 ( thanks Julian Elischer ) > Frankly I don't understand why this is needed since pppoed loads those > modules when it starts up. Just tested the same setup on 7.0 built tonight and it did not work. The pppoed daemon never sends any requests to freeradius... I tried to additionaly with those modules listed in loader.conf with no luck: ng_ether_load="YES" ng_pppoe_load="YES" > This is my ppp.conf, just for the record: > > default: > #set log Chat Command Phase #turn on some logging. See man > ppp.conf for info set log Chat Command Phase hdlc lqm ipcp > enable mschapv2 mschap chap mppe #turn on chap and pap > accounting > #enable pap mschapv2 mschap chap mppe #turn on chap and pap > #accounting enable pap #turn on chap and pap > #accounting > allow mode direct #turn on ppp bridging > enable proxy #turn on ppp proxyarping (redundant of > above???) disable ipv6cp #we don't use ipv6, don't > want the errors set mru 1472 #set mru below 1500 > (PPPoE MTU issue) set mtu 1472 #set mtu below 1500 > (PPPoE MTU issue) set timeout 0 #no mins time > restriction on users #set timeout never > set mppe 128 * > set ifaddr 192.168.2.8 192.168.2.100-192.168.1.120 255.255.255.255 > set log phase ipcp lcp debug #additional debugging > nat enable yes > set dns 192.168.2.45 192.168.2.8 > #set speed sync > set cd 3 # checks for the existence of carrier > once per second for 5 seconds #set cd 5! > #enable echo > enable lqr > set reconnect 1 5 # Should the line drop unexpectedly , > a connection will be re-established after the given timeout. > > #Specify my wifi gateway IP as well as DHCP pool range > set radius /etc/ppp/radius.conf #turn on radius auth and use > this file accept dns #turn on dns > cacheing/forwarding > > #enable pap mschapv2 mschap chap mppe #turn on chap and pap > #accounting > disable pap pred1 deflate #disable pred1 and deflate > compression along with pap deny pap pred1 deflate > #refuse when ask for it > _______________________________________________ > 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 Thu Oct 20 12:49:42 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE4916A41F; Thu, 20 Oct 2005 12:49:42 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B7CE43D7C; Thu, 20 Oct 2005 12:49:36 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id E6CA64CDEF; Thu, 20 Oct 2005 12:49:50 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id CA95E4CDFC; Thu, 20 Oct 2005 12:49:44 +0000 (GMT) Message-ID: <43579259.8060701@roq.com> Date: Thu, 20 Oct 2005 22:49:29 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> <4356BBA1.3000103@wm-access.no> In-Reply-To: <4356BBA1.3000103@wm-access.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org, stable@freebsd.org Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 12:49:43 -0000 Sten Daniel Sψrsdal wrote: >Michael VInce wrote: > > > >>I reinstalled the netperf to make sure its the latest. >> >>I have also decided to upgrade Server-C (the i386 5.4 box) to 6.0RC1 and >>noticed it gave a large improvement of network performance with a SMP >>kernel. >> >>As with the network setup ( A --- B --- C ) with server B being the >>gateway, doing a basic 'fetch' from the gateway (B) to the Apache server >>(C) it gives up to 700mbits/sec transfer performance, doing a fetch from >>server A thus going through the gateway gives slower but still decent >>performance of up to 400mbits/sec. >> >> > >Are you by any chance using PCI NIC's? PCI Bus is limited to somewhere around 1 Gbit/s. >So if you consider; >Theoretical maxium = ( 1Gbps - pci_overhead ) > > > The 4 ethernet ports on the Dell server are all built-in so I am assuming they are on the best bus available. Mike From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 12:59:12 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA04216A41F for ; Thu, 20 Oct 2005 12:59:12 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EFFC43D5A for ; Thu, 20 Oct 2005 12:59:12 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9KCx9K8001794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 16:59:10 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9KCx9Kq001793; Thu, 20 Oct 2005 16:59:09 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 20 Oct 2005 16:59:09 +0400 From: Gleb Smirnoff To: Marcin Jessa Message-ID: <20051020125909.GG59364@cell.sick.ru> References: <20051019235111.2225345e.lists@yazzy.org> <20051020070145.GA59364@cell.sick.ru> <20051020131549.5e432073.lists@yazzy.org> <20051020123159.33f6fa33.lists@yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051020123159.33f6fa33.lists@yazzy.org> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 20 Oct 2005 12:59:13 -0000 On Thu, Oct 20, 2005 at 12:31:59PM +0000, Marcin Jessa wrote: M> > > On Wed, Oct 19, 2005 at 11:51:11PM +0200, Marcin Jessa wrote: M> > > M> It seems like PPPoE stoped working with support for radius on 6.0 M> > > M> The log of pppoe and freeradius does not show pppoe attempting to M> > > M> even talk to the radius server. Additionally this message pops up M> > > M> when enabling pppoed: WARNING: attempt to net_add_domain M> > > M> (netgraph) after domainfinalize() My setup worked fine before on M> > > M> FreeBSD 5.x Is that a known issue and is it being worked on? M> > > M> > > Please show your PPPoE server configuration. Do you use pppoed or M> > > mpd? M> > M> > I use pppoed. M> > Adding M> > netgraph_load="YES" M> > ng_socket_load="YES" M> > to /boot/loader.conf fixed it on my 6.0RC1 ( thanks Julian Elischer ) M> > Frankly I don't understand why this is needed since pppoed loads those M> > modules when it starts up. M> M> Just tested the same setup on 7.0 built tonight and it did not work. M> The pppoed daemon never sends any requests to freeradius... M> I tried to additionaly with those modules listed in loader.conf with no M> luck: M> ng_ether_load="YES" M> ng_pppoe_load="YES" This is very strange. Because I have recently upgraded one router running pppoed to 6.0-RC1 and I have no problems. Please read on the pppoed logs and see what is the problem. If everything is fine in pppoed logs, then go on with ppp logs. "stopped working" is not really informative. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 13:29:24 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 494BB16A41F for ; Thu, 20 Oct 2005 13:29:24 +0000 (GMT) (envelope-from dom@helenmarks.co.uk) Received: from mail.helenmarks.co.uk (82-68-196-20.dsl.in-addr.zen.co.uk [82.68.196.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBBAA43D62 for ; Thu, 20 Oct 2005 13:29:23 +0000 (GMT) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 47809170A7; Thu, 20 Oct 2005 14:29:22 +0100 (BST) Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34016-05; Thu, 20 Oct 2005 14:29:19 +0100 (BST) Received: by mail.helenmarks.co.uk (Postfix, from userid 80) id B8E1A170A5; Thu, 20 Oct 2005 14:29:19 +0100 (BST) Received: from graphicaldatacapture-ll-194.altohiway.com ([195.12.22.194]) (SquirrelMail authenticated user dom) by www.helenmarks.co.uk with HTTP; Thu, 20 Oct 2005 14:29:19 +0100 (BST) Message-ID: <3100.195.12.22.194.1129814959.squirrel@www.helenmarks.co.uk> Date: Thu, 20 Oct 2005 14:29:19 +0100 (BST) From: "Dominic Marks" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: By ClamAV 0.85.1 Subject: mpd disconnect due to LCP echo not responding 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, 20 Oct 2005 13:29:24 -0000 Hello, I have a number of staff who use pptp links to VPN (Windows to FreeBSD mpd server) in to the Office. Some times when the link is busy the LCP echos won't pass over the link quickly enough and the connection will terminate. Is there anything I can do to prevent this, or at least make it less likely to happen. Options I have thought of are: Increasing the number of echos mpd waits before disconnecting. Increasing the time out for LCP echos. Using traffic shaping to prioritise the LCP traffic over other traffic. Are any of these possible, or is there another way of acheiving the same goal? Some example log output: Oct 19 15:18:38 billy mpd: [ng5] LCP: no reply to 1 echo request(s) Oct 19 15:18:48 billy mpd: [ng5] LCP: no reply to 2 echo request(s) Oct 19 15:18:58 billy mpd: [ng5] LCP: no reply to 3 echo request(s) Oct 19 15:19:08 billy mpd: [ng5] LCP: no reply to 4 echo request(s) Oct 19 15:19:18 billy mpd: [ng5] LCP: no reply to 5 echo request(s) Oct 19 15:19:18 billy mpd: [ng5] LCP: peer not responding to echo requests Thanks, Dominic Marks From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 13:56:09 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2751716A426 for ; Thu, 20 Oct 2005 13:56:09 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B83743D64 for ; Thu, 20 Oct 2005 13:56:08 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9KDu6QE002647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 17:56:07 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9KDu6TM002646; Thu, 20 Oct 2005 17:56:06 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 20 Oct 2005 17:56:06 +0400 From: Gleb Smirnoff To: Dominic Marks Message-ID: <20051020135606.GK59364@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Dominic Marks , freebsd-net@freebsd.org References: <3100.195.12.22.194.1129814959.squirrel@www.helenmarks.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <3100.195.12.22.194.1129814959.squirrel@www.helenmarks.co.uk> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: mpd disconnect due to LCP echo not responding 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, 20 Oct 2005 13:56:09 -0000 Dominic, On Thu, Oct 20, 2005 at 02:29:19PM +0100, Dominic Marks wrote: D> server) in to the Office. Some times when the link is busy the LCP echos D> won't pass over the link quickly enough and the connection will terminate. D> D> Is there anything I can do to prevent this, or at least make it less D> likely to happen. Options I have thought of are: D> D> Increasing the number of echos mpd waits before disconnecting. D> Increasing the time out for LCP echos. So have you tried the two above options or are they not configurable in mpd? D> Using traffic shaping to prioritise the LCP traffic over other traffic. D> D> Are any of these possible, or is there another way of acheiving the same D> goal? D> D> Some example log output: D> D> Oct 19 15:18:38 billy mpd: [ng5] LCP: no reply to 1 echo request(s) D> Oct 19 15:18:48 billy mpd: [ng5] LCP: no reply to 2 echo request(s) D> Oct 19 15:18:58 billy mpd: [ng5] LCP: no reply to 3 echo request(s) D> Oct 19 15:19:08 billy mpd: [ng5] LCP: no reply to 4 echo request(s) D> Oct 19 15:19:18 billy mpd: [ng5] LCP: no reply to 5 echo request(s) D> Oct 19 15:19:18 billy mpd: [ng5] LCP: peer not responding to echo requests D> D> Thanks, D> Dominic Marks D> _______________________________________________ D> freebsd-net@freebsd.org mailing list D> http://lists.freebsd.org/mailman/listinfo/freebsd-net D> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 14:02:04 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D92516A41F for ; Thu, 20 Oct 2005 14:02:04 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ED1C43D69 for ; Thu, 20 Oct 2005 14:02:02 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9KE20s9002900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Oct 2005 18:02:01 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9KE20ts002899 for net@FreeBSD.org; Thu, 20 Oct 2005 18:02:00 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 20 Oct 2005 18:02:00 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20051020140200.GL59364@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZJcv+A0YCCLh2VIg" Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: Subject: em(4) patch for test 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, 20 Oct 2005 14:02:04 -0000 --ZJcv+A0YCCLh2VIg Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Colleagues, since the if_em problem was taken as a late showstopper for 6.0-RELEASE, I am asking you to help with testing of the fixes made in HEAD. Does your em(4) interface wedge for some time? Do you see a lot of errors in 'netstat -i' output? Does these errors increase not monotonously but they have peaks? If the answer is yes, then the attached patch is likely to fix your problem. If the answer is no, then you are still encouraged to help with testing and install the patch to check that no regressions are introduced. If you skip this, then you may encounter regressions after release, so you have been warned. So, in short: please test! Thanks in advance! The patch is against fresh RELENG_6. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --ZJcv+A0YCCLh2VIg Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="if_em.HEAD-RELENG_6.diff" Index: if_em.c =================================================================== RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v retrieving revision 1.65.2.5 retrieving revision 1.81 diff -u -r1.65.2.5 -r1.81 --- if_em.c 7 Oct 2005 14:00:03 -0000 1.65.2.5 +++ if_em.c 20 Oct 2005 09:55:49 -0000 1.81 @@ -31,7 +31,7 @@ ***************************************************************************/ -/*$FreeBSD: src/sys/dev/em/if_em.c,v 1.65.2.5 2005/10/07 14:00:03 glebius Exp $*/ +/*$FreeBSD: src/sys/dev/em/if_em.c,v 1.81 2005/10/20 09:55:49 glebius Exp $*/ #ifdef HAVE_KERNEL_OPTION_HEADERS #include "opt_device_polling.h" @@ -45,13 +45,6 @@ int em_display_debug_stats = 0; /********************************************************************* - * Linked list of board private structures for all NICs found - *********************************************************************/ - -struct adapter *em_adapter_list = NULL; - - -/********************************************************************* * Driver version *********************************************************************/ @@ -326,11 +319,6 @@ adapter->unit = device_get_unit(dev); EM_LOCK_INIT(adapter, device_get_nameunit(dev)); - if (em_adapter_list != NULL) - em_adapter_list->prev = adapter; - adapter->next = em_adapter_list; - em_adapter_list = adapter; - /* SYSCTL stuff */ SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), @@ -511,6 +499,7 @@ err_tx_desc: err_pci: em_free_pci_resources(adapter); + EM_LOCK_DESTROY(adapter); return(error); } @@ -543,14 +532,11 @@ em_stop(adapter); em_phy_hw_reset(&adapter->hw); EM_UNLOCK(adapter); -#if __FreeBSD_version < 500000 - ether_ifdetach(adapter->ifp, ETHER_BPF_SUPPORTED); -#else ether_ifdetach(adapter->ifp); - if_free(ifp); -#endif + em_free_pci_resources(adapter); bus_generic_detach(dev); + if_free(ifp); /* Free Transmit Descriptor ring */ if (adapter->tx_desc_base) { @@ -564,19 +550,8 @@ adapter->rx_desc_base = NULL; } - /* Remove from the adapter list */ - if (em_adapter_list == adapter) - em_adapter_list = adapter->next; - if (adapter->next != NULL) - adapter->next->prev = adapter->prev; - if (adapter->prev != NULL) - adapter->prev->next = adapter->next; - EM_LOCK_DESTROY(adapter); - ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); - ifp->if_timer = 0; - return(0); } @@ -637,12 +612,7 @@ } /* Send a copy of the frame to the BPF listener */ -#if __FreeBSD_version < 500000 - if (ifp->if_bpf) - bpf_mtap(ifp, m_head); -#else BPF_MTAP(ifp, m_head); -#endif /* Set timeout in case hardware has problems transmitting */ ifp->if_timer = EM_TX_TIMEOUT; @@ -797,11 +767,13 @@ struct adapter * adapter; adapter = ifp->if_softc; + EM_LOCK(adapter); /* If we are in this routine because of pause frames, then * don't reset the hardware. */ if (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF) { ifp->if_timer = EM_TX_TIMEOUT; + EM_UNLOCK(adapter); return; } @@ -809,11 +781,10 @@ printf("em%d: watchdog timeout -- resetting\n", adapter->unit); ifp->if_drv_flags &= ~IFF_DRV_RUNNING; - - em_init(adapter); - ifp->if_oerrors++; - return; + + em_init_locked(adapter); + EM_UNLOCK(adapter); } /********************************************************************* @@ -996,51 +967,57 @@ static void em_intr(void *arg) { - u_int32_t loop_cnt = EM_MAX_INTR; - u_int32_t reg_icr; - struct ifnet *ifp; - struct adapter *adapter = arg; + struct adapter *adapter = arg; + struct ifnet *ifp; + uint32_t reg_icr; + int wantinit = 0; EM_LOCK(adapter); - ifp = adapter->ifp; + ifp = adapter->ifp; #ifdef DEVICE_POLLING - if (ifp->if_capenable & IFCAP_POLLING) { + if (ifp->if_capenable & IFCAP_POLLING) { EM_UNLOCK(adapter); - return; + return; } #endif /* DEVICE_POLLING */ - reg_icr = E1000_READ_REG(&adapter->hw, ICR); - if (!reg_icr) { - EM_UNLOCK(adapter); - return; - } - - /* Link status change */ - if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { - callout_stop(&adapter->timer); - adapter->hw.get_link_status = 1; - em_check_for_link(&adapter->hw); - em_print_link_status(adapter); - callout_reset(&adapter->timer, hz, em_local_timer, adapter); - } + for (;;) { + reg_icr = E1000_READ_REG(&adapter->hw, ICR); + if (reg_icr == 0) + break; - while (loop_cnt > 0) { - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - em_process_receive_interrupts(adapter, -1); - em_clean_transmit_interrupts(adapter); - } - loop_cnt--; - } + if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + em_process_receive_interrupts(adapter, -1); + em_clean_transmit_interrupts(adapter); + } - if (ifp->if_drv_flags & IFF_DRV_RUNNING && + /* Link status change */ + if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) { + callout_stop(&adapter->timer); + adapter->hw.get_link_status = 1; + em_check_for_link(&adapter->hw); + em_print_link_status(adapter); + callout_reset(&adapter->timer, hz, em_local_timer, + adapter); + } + + if (reg_icr & E1000_ICR_RXO) { + log(LOG_WARNING, "%s: RX overrun\n", ifp->if_xname); + wantinit = 1; + } + } +#if 0 + if (wantinit) + em_init_locked(adapter); +#endif + if (ifp->if_drv_flags & IFF_DRV_RUNNING && !IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - em_start_locked(ifp); + em_start_locked(ifp); EM_UNLOCK(adapter); - return; + return; } @@ -1095,11 +1072,7 @@ ifmr->ifm_active |= IFM_100_TX; break; case 1000: -#if __FreeBSD_version < 500000 - ifmr->ifm_active |= IFM_1000_TX; -#else ifmr->ifm_active |= IFM_1000_T; -#endif break; } if (adapter->link_duplex == FULL_DUPLEX) @@ -1135,11 +1108,7 @@ adapter->hw.autoneg_advertised = AUTONEG_ADV_DEFAULT; break; case IFM_1000_SX: -#if __FreeBSD_version < 500000 - case IFM_1000_TX: -#else case IFM_1000_T: -#endif adapter->hw.autoneg = DO_AUTO_NEG; adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL; break; @@ -1193,12 +1162,7 @@ DESC_ARRAY desc_array; u_int32_t array_elements; u_int32_t counter; - -#if __FreeBSD_version < 500000 - struct ifvlan *ifv = NULL; -#else struct m_tag *mtag; -#endif bus_dma_segment_t segs[EM_MAX_SCATTER]; bus_dmamap_t map; int nsegs; @@ -1251,14 +1215,7 @@ /* Find out if we are in vlan mode */ -#if __FreeBSD_version < 500000 - if ((m_head->m_flags & (M_PROTO1|M_PKTHDR)) == (M_PROTO1|M_PKTHDR) && - m_head->m_pkthdr.rcvif != NULL && - m_head->m_pkthdr.rcvif->if_type == IFT_L2VLAN) - ifv = m_head->m_pkthdr.rcvif->if_softc; -#else mtag = VLAN_OUTPUT_TAG(ifp, m_head); -#endif /* * When operating in promiscuous mode, hardware encapsulation for @@ -1361,15 +1318,9 @@ adapter->num_tx_desc_avail -= nsegs; } -#if __FreeBSD_version < 500000 - if (ifv != NULL) { - /* Set the vlan id */ - current_tx_desc->upper.fields.special = htole16(ifv->ifv_tag); -#else if (mtag != NULL) { /* Set the vlan id */ current_tx_desc->upper.fields.special = htole16(VLAN_TAG_VALUE(mtag)); -#endif /* Tell hardware to add tag */ current_tx_desc->lower.data |= htole32(E1000_TXD_CMD_VLE); @@ -1611,11 +1562,7 @@ } IF_ADDR_LOCK(ifp); -#if __FreeBSD_version < 500000 - LIST_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { -#else TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { -#endif if (ifma->ifma_addr->sa_family != AF_LINK) continue; @@ -1729,6 +1676,7 @@ mtx_assert(&adapter->mtx, MA_OWNED); INIT_DEBUGOUT("em_stop: begin"); + em_disable_intr(adapter); em_reset_hw(&adapter->hw); callout_stop(&adapter->timer); @@ -1960,11 +1908,7 @@ ifp->if_snd.ifq_drv_maxlen = adapter->num_tx_desc - 1; IFQ_SET_READY(&ifp->if_snd); -#if __FreeBSD_version < 500000 - ether_ifattach(ifp, ETHER_BPF_SUPPORTED); -#else ether_ifattach(ifp, adapter->hw.mac_addr); -#endif ifp->if_capabilities = ifp->if_capenable = 0; @@ -1977,10 +1921,8 @@ * Tell the upper layer(s) we support long frames. */ ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); -#if __FreeBSD_version >= 500000 ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING | IFCAP_VLAN_MTU; ifp->if_capenable |= IFCAP_VLAN_MTU; -#endif #ifdef DEVICE_POLLING ifp->if_capabilities |= IFCAP_POLLING; @@ -2005,15 +1947,9 @@ 0, NULL); ifmedia_add(&adapter->media, IFM_ETHER | IFM_100_TX | IFM_FDX, 0, NULL); -#if __FreeBSD_version < 500000 - ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_TX | IFM_FDX, - 0, NULL); - ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_TX, 0, NULL); -#else ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_T | IFM_FDX, 0, NULL); ifmedia_add(&adapter->media, IFM_ETHER | IFM_1000_T, 0, NULL); -#endif } ifmedia_add(&adapter->media, IFM_ETHER | IFM_AUTO, 0, NULL); ifmedia_set(&adapter->media, IFM_ETHER | IFM_AUTO); @@ -2139,7 +2075,6 @@ goto fail_3; } - dma->dma_size = size; return (0); fail_3: @@ -2545,7 +2480,8 @@ } rx_buffer->m_head = mp; adapter->rx_desc_base[i].buffer_addr = htole64(paddr); - bus_dmamap_sync(adapter->rxtag, rx_buffer->map, BUS_DMASYNC_PREREAD); + bus_dmamap_sync(adapter->rxtag, rx_buffer->map, BUS_DMASYNC_PREREAD | + BUS_DMASYNC_PREWRITE); return(0); } @@ -2786,9 +2722,6 @@ { struct ifnet *ifp; struct mbuf *mp; -#if __FreeBSD_version < 500000 - struct ether_header *eh; -#endif u_int8_t accept_frame = 0; u_int8_t eop = 0; u_int16_t len, desc_len, prev_len_adj; @@ -2809,7 +2742,10 @@ return; } - while ((current_desc->status & E1000_RXD_STAT_DD) && (count != 0)) { + while ((current_desc->status & E1000_RXD_STAT_DD) && + (count != 0) && + (ifp->if_drv_flags & IFF_DRV_RUNNING)) { + struct mbuf *m = NULL; mp = adapter->rx_buffer_area[i].m_head; bus_dmamap_sync(adapter->rxtag, adapter->rx_buffer_area[i].map, @@ -2893,22 +2829,7 @@ if (eop) { adapter->fmp->m_pkthdr.rcvif = ifp; - ifp->if_ipackets++; - -#if __FreeBSD_version < 500000 - eh = mtod(adapter->fmp, struct ether_header *); - /* Remove ethernet header from mbuf */ - m_adj(adapter->fmp, sizeof(struct ether_header)); - em_receive_checksum(adapter, current_desc, - adapter->fmp); - if (current_desc->status & E1000_RXD_STAT_VP) - VLAN_INPUT_TAG(eh, adapter->fmp, - (current_desc->special & - E1000_RXD_SPC_VLAN_MASK)); - else - ether_input(ifp, eh, adapter->fmp); -#else - + ifp->if_ipackets++; em_receive_checksum(adapter, current_desc, adapter->fmp); if (current_desc->status & E1000_RXD_STAT_VP) @@ -2916,17 +2837,10 @@ (current_desc->special & E1000_RXD_SPC_VLAN_MASK), adapter->fmp = NULL); - - if (adapter->fmp != NULL) { - struct mbuf *m = adapter->fmp; - adapter->fmp = NULL; - EM_UNLOCK(adapter); - (*ifp->if_input)(ifp, m); - EM_LOCK(adapter); - } -#endif - adapter->lmp = NULL; + m = adapter->fmp; + adapter->fmp = NULL; + adapter->lmp = NULL; } } else { adapter->dropped_pkts++; @@ -2939,19 +2853,24 @@ /* Zero out the receive descriptors status */ current_desc->status = 0; + bus_dmamap_sync(adapter->rxdma.dma_tag, adapter->rxdma.dma_map, + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); /* Advance the E1000's Receive Queue #0 "Tail Pointer". */ E1000_WRITE_REG(&adapter->hw, RDT, i); /* Advance our pointers to the next descriptor */ - if (++i == adapter->num_rx_desc) { - i = 0; - current_desc = adapter->rx_desc_base; - } else - current_desc++; + if (++i == adapter->num_rx_desc) + i = 0; + if (m != NULL) { + adapter->next_rx_desc_to_check = i; + EM_UNLOCK(adapter); + (*ifp->if_input)(ifp, m); + EM_LOCK(adapter); + i = adapter->next_rx_desc_to_check; + } + current_desc = &adapter->rx_desc_base[i]; } - bus_dmamap_sync(adapter->rxdma.dma_tag, adapter->rxdma.dma_map, - BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); adapter->next_rx_desc_to_check = i; return; } @@ -3255,10 +3174,6 @@ } ifp = adapter->ifp; - /* Fill out the OS statistics structure */ - ifp->if_ibytes = adapter->stats.gorcl; - ifp->if_obytes = adapter->stats.gotcl; - ifp->if_imcasts = adapter->stats.mprc; ifp->if_collisions = adapter->stats.colc; /* Rx Errors */ @@ -3420,10 +3335,8 @@ int error; int usecs; int ticks; - int s; info = (struct em_int_delay_info *)arg1; - adapter = info->adapter; usecs = info->value; error = sysctl_handle_int(oidp, &usecs, 0, req); if (error != 0 || req->newptr == NULL) @@ -3432,8 +3345,10 @@ return EINVAL; info->value = usecs; ticks = E1000_USECS_TO_TICKS(usecs); + + adapter = info->adapter; - s = splimp(); + EM_LOCK(adapter); regval = E1000_READ_OFFSET(&adapter->hw, info->offset); regval = (regval & ~0xffff) | (ticks & 0xffff); /* Handle a few special cases. */ @@ -3453,7 +3368,7 @@ break; } E1000_WRITE_OFFSET(&adapter->hw, info->offset, regval); - splx(s); + EM_UNLOCK(adapter); return 0; } Index: if_em.h =================================================================== RCS file: /home/ncvs/src/sys/dev/em/if_em.h,v retrieving revision 1.32 retrieving revision 1.35 diff -u -r1.32 -r1.35 --- if_em.h 10 Jun 2005 16:49:07 -0000 1.32 +++ if_em.h 20 Oct 2005 09:55:49 -0000 1.35 @@ -31,7 +31,7 @@ ***************************************************************************/ -/*$FreeBSD: src/sys/dev/em/if_em.h,v 1.32 2005/06/10 16:49:07 brooks Exp $*/ +/*$FreeBSD: src/sys/dev/em/if_em.h,v 1.35 2005/10/20 09:55:49 glebius Exp $*/ #ifndef _EM_H_DEFINED_ #define _EM_H_DEFINED_ @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -75,7 +76,6 @@ #include #include #include -#include "opt_bdg.h" #include @@ -164,14 +164,6 @@ */ #define EM_RADV 64 - -/* - * This parameter controls the maximum no of times the driver will loop - * in the isr. - * Minimum Value = 1 - */ -#define EM_MAX_INTR 3 - /* * Inform the stack about transmit checksum offload capabilities. */ @@ -290,7 +282,6 @@ bus_dma_tag_t dma_tag; bus_dmamap_t dma_map; bus_dma_segment_t dma_seg; - bus_size_t dma_size; int dma_nseg; }; @@ -323,8 +314,6 @@ /* Our adapter structure */ struct adapter { struct ifnet *ifp; - struct adapter *next; - struct adapter *prev; struct em_hw hw; /* FreeBSD operating-system-specific structures */ Index: if_em_hw.h =================================================================== RCS file: /home/ncvs/src/sys/dev/em/if_em_hw.h,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- if_em_hw.h 26 May 2005 23:32:02 -0000 1.15 +++ if_em_hw.h 20 Oct 2005 08:46:43 -0000 1.16 @@ -31,7 +31,7 @@ *******************************************************************************/ -/*$FreeBSD: src/sys/dev/em/if_em_hw.h,v 1.15 2005/05/26 23:32:02 tackerman Exp $*/ +/*$FreeBSD: src/sys/dev/em/if_em_hw.h,v 1.16 2005/10/20 08:46:43 glebius Exp $*/ /* if_em_hw.h * Structures, enums, and macros for the MAC */ @@ -556,6 +556,7 @@ E1000_IMS_TXDW | \ E1000_IMS_RXDMT0 | \ E1000_IMS_RXSEQ | \ + E1000_IMS_RXO | \ E1000_IMS_LSC) --ZJcv+A0YCCLh2VIg-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 14:29:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 795A916A420; Thu, 20 Oct 2005 14:29:50 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1863D43D5A; Thu, 20 Oct 2005 14:29:49 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.210] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id j9KETkji044812; Thu, 20 Oct 2005 10:29:47 -0400 (EDT) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <43579259.8060701@roq.com> References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> <4356BBA1.3000103@wm-access.no> <43579259.8060701@roq.com> Date: Thu, 20 Oct 2005 16:26:31 +0200 To: Michael VInce From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: freebsd-net@freebsd.org, stable@freebsd.org, Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 14:29:50 -0000 At 10:49 PM +1000 2005-10-20, Michael VInce wrote: > The 4 ethernet ports on the Dell server are all built-in so I am assuming > they are on the best bus available. In my experience, the terms "Dell" and "best available" very rarely go together. Dell has made a name for themselves by shipping the absolutely cheapest possible hardware they can, with the thinnest possible profit margins, and trying to make up the difference in volume. Issues like support, ease of management, freedom from overheating, etc... get secondary or tertiary consideration, if they get any consideration at all. But maybe that's just me. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 14:57:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37EA016A420 for ; Thu, 20 Oct 2005 14:57:02 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CF9043D66 for ; Thu, 20 Oct 2005 14:57:01 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j9KEv0Ae086789 for ; Thu, 20 Oct 2005 09:57:00 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Oct 20 09:57:00 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j9KEv0QD086787; Thu, 20 Oct 2005 09:57:00 -0500 (CDT) (envelope-from karl) Date: Thu, 20 Oct 2005 09:57:00 -0500 From: Karl Denninger To: Brad Knowles Message-ID: <20051020145700.GA86725@FS.denninger.net> References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> <4356BBA1.3000103@wm-access.no> <43579259.8060701@roq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Cc: Michael VInce , freebsd-net@freebsd.org, stable@freebsd.org, Sten Daniel S?rsdal Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 14:57:02 -0000 I think that's unfair. I have a couple of Dell machines and my biggest complaint with them has been their use of proprietary bolt patterns for their motherboards and similar tomfoolery, preventing you from migrating their hardware as your needs grow. This also guarantees that your $75 power supply becomes a $200 one once the warranty ends - good for them, not good for you. Other than that, I've been pretty happy with their stuff. Sure beats a lot of other "PC" vendors out there in terms of reliability, heat management, BIOS updates, etc. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://genesis3.blogspot.com Musings Of A Sentient Mind On Thu, Oct 20, 2005 at 04:26:31PM +0200, Brad Knowles wrote: > At 10:49 PM +1000 2005-10-20, Michael VInce wrote: > > > The 4 ethernet ports on the Dell server are all built-in so I am assuming > > they are on the best bus available. > > In my experience, the terms "Dell" and "best available" very > rarely go together. > > Dell has made a name for themselves by shipping the absolutely > cheapest possible hardware they can, with the thinnest possible > profit margins, and trying to make up the difference in volume. > Issues like support, ease of management, freedom from overheating, > etc... get secondary or tertiary consideration, if they get any > consideration at all. > > But maybe that's just me. > > -- > Brad Knowles, > > "Those who would give up essential Liberty, to purchase a little > temporary Safety, deserve neither Liberty nor Safety." > > -- Benjamin Franklin (1706-1790), reply of the Pennsylvania > Assembly to the Governor, November 11, 1755 From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 15:18:59 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AD1816A41F; Thu, 20 Oct 2005 15:18:59 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC3A843D62; Thu, 20 Oct 2005 15:18:58 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.210] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id j9KFImZV048385; Thu, 20 Oct 2005 11:18:50 -0400 (EDT) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051020145700.GA86725@FS.denninger.net> References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> <4356BBA1.3000103@wm-access.no> <43579259.8060701@roq.com> <20051020145700.GA86725@FS.denninger.net> Date: Thu, 20 Oct 2005 17:18:35 +0200 To: Karl Denninger From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Michael VInce , Brad Knowles , stable@freebsd.org, Sten Daniel S?rsdal , freebsd-net@freebsd.org Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 15:18:59 -0000 At 9:57 AM -0500 2005-10-20, Karl Denninger wrote: > Other than that, I've been pretty happy with their stuff. Sure beats a lot > of other "PC" vendors out there in terms of reliability, heat management, > BIOS updates, etc. Have you tried Rackable or IronSystems? I've heard that they've been pretty successful at building servers to compete pretty well on price with Dell, while also providing much better customer service, including custom-building servers to your precise requirements. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 15:52:24 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B43716A41F; Thu, 20 Oct 2005 15:52:24 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8753F43D62; Thu, 20 Oct 2005 15:52:23 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 13AC446B03; Thu, 20 Oct 2005 11:52:22 -0400 (EDT) Date: Thu, 20 Oct 2005 16:52:21 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Michael VInce In-Reply-To: <43579259.8060701@roq.com> Message-ID: <20051020165029.C28249@fledge.watson.org> References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> <4356BBA1.3000103@wm-access.no> <43579259.8060701@roq.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, stable@freebsd.org, =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 15:52:24 -0000 On Thu, 20 Oct 2005, Michael VInce wrote: >> Are you by any chance using PCI NIC's? PCI Bus is limited to somewhere >> around 1 Gbit/s. So if you consider; Theoretical maxium = ( 1Gbps - >> pci_overhead ) >> > The 4 ethernet ports on the Dell server are all built-in so I am > assuming they are on the best bus available. At the performance levels you're interested in, it is worth spending a bit of time digging up the specs for the motherboard. You may find, for example, that you can achieve higher packet rates using specific combinations of interfaces on the box, as it is often the case that a single PCI bus will run to a pair of on-board chips. By forwarding on separate busses, you avoid contention, interrupt issues, etc. We have a number of test systems in our netperf test cluster where you can measure 20% or more differences on some tests depending on the combinations of interfaces used. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 16:00:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 036FF16A41F; Thu, 20 Oct 2005 16:00:13 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F4B443D5A; Thu, 20 Oct 2005 16:00:13 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id C051D4CFE1; Thu, 20 Oct 2005 16:00:27 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 242DB4CFCB; Thu, 20 Oct 2005 16:00:25 +0000 (GMT) Message-ID: <4357BF0A.9060504@roq.com> Date: Fri, 21 Oct 2005 02:00:10 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Karl Denninger References: <434FABCC.2060709@roq.com> <20051014205434.C66245@fledge.watson.org> <43564800.3010309@roq.com> <4356BBA1.3000103@wm-access.no> <43579259.8060701@roq.com> <20051020145700.GA86725@FS.denninger.net> In-Reply-To: <20051020145700.GA86725@FS.denninger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Brad Knowles , stable@freebsd.org, Sten Daniel S?rsdal , freebsd-net@freebsd.org Subject: Re: Network performance 6.0 with netperf 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, 20 Oct 2005 16:00:14 -0000 > > >On Thu, Oct 20, 2005 at 04:26:31PM +0200, Brad Knowles wrote: > > >>> At 10:49 PM +1000 2005-10-20, Michael VInce wrote: >>> >> >> >>>> > The 4 ethernet ports on the Dell server are all built-in so I am assuming >>>> > they are on the best bus available. >>> >>> >>> >>> In my experience, the terms "Dell" and "best available" very >>> rarely go together. >>> >>> Dell has made a name for themselves by shipping the absolutely >>> cheapest possible hardware they can, with the thinnest possible >>> profit margins, and trying to make up the difference in volume. >>> Issues like support, ease of management, freedom from overheating, >>> etc... get secondary or tertiary consideration, if they get any >>> consideration at all. >>> >>> But maybe that's just me. >>> >>> -- >>> Brad Knowles, >> >> > I think that's unfair. > I have a couple of Dell machines and my biggest complaint with them > has been > their use of proprietary bolt patterns for their motherboards and similar > tomfoolery, preventing you from migrating their hardware as your needs > grow. > > This also guarantees that your $75 power supply becomes a $200 one > once the > warranty ends - good for them, not good for you. > > Other than that, I've been pretty happy with their stuff. Sure beats a lot > of other "PC" vendors out there in terms of reliability, heat management, > BIOS updates, etc. > > -- > -- > Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights > Activist I have to agree Karl, Those slots aren't proprietary there PCI Express. When I went to open the machine up to put in a PCI multi serial card all I saw were those little modern mean looking PCI Express slots which have the ability to scare any techie, there are no old PCI slots on it, I had to dump my serial card and change over to usb2serial converters by loading the ucom and uplcom as kernel modules so I could use tip to serial out of usb into the single serial port on the Dell machines when the ethernet is down which ended up working out great, I will never need clunky old (and price) multi port PCI serial cards again. If you look at the chipset Intel E7520 of the Dell 1850/2850 (The 2850 is really just a bigger case machine to hold more drives) http://www.intel.com/design/chipsets/embedded/e7520.htm You will see it just only has PCI Express as a minimum which is 64bit/133mhz which does a minimum of 2.5GBs/sec in 1 direction and its a switched based bus technology where there is no sharing of the lanes, there is no old school PCI 32bit/33mhz buses. http://www.pcstats.com/articleview.cfm?articleid=1087&page=3 As for service, I actually ordered two much smaller Dell 750's but because there were out of them for a couple of weeks due to some big company ordering 500 of them I had a bit of an argue with the Dell guy on the phone and got 1850s with scsi raid 1 out of him for the same price. Its been Dell that has shown me how good (and maybe a bit evil) big companies can be. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 17:13:24 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 018F916A41F for ; Thu, 20 Oct 2005 17:13:24 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from hotmail.com (bay101-f35.bay101.hotmail.com [64.4.56.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id B61A943D62 for ; Thu, 20 Oct 2005 17:13:23 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Oct 2005 10:13:23 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Thu, 20 Oct 2005 17:13:23 GMT X-Originating-IP: [64.60.108.59] X-Originating-Email: [saundersconsult@hotmail.com] X-Sender: saundersconsult@hotmail.com In-Reply-To: <4356E47D.605@freemail.gr> From: "Shawn Saunders" To: dionch@freemail.gr Date: Thu, 20 Oct 2005 17:13:23 +0000 X-Priority: 1 Importance: High Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 20 Oct 2005 17:13:23.0519 (UTC) FILETIME=[93BBACF0:01C5D599] Cc: freebsd-net@freebsd.org Subject: Re: Trying to make a Host into a gigabit hub for testing 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, 20 Oct 2005 17:13:24 -0000 Chris, Thanks for the quick response. It looked good, but when I execute each command, I receive an Error on the following: ngctl connect sf0: o2m lower many0 Returns: ngctl: send msg: No such file or directory Did I miss something? Shawn >From: Chris Dionissopoulos >Reply-To: dionch@freemail.gr >To: Shawn Saunders >CC: freebsd-net@freebsd.org >Subject: Re: Trying to make a Host into a gigabit hub for testing >Date: Thu, 20 Oct 2005 03:27:41 +0300 > >SS>I am setting up a test environment with multiple IDS's. ngctl looks >like a solution but it is not broadcasting all packets to all interfaces as >the documentation appears to state it should. I've probably made some >error in configuration. >SS> >SS>My goal is to put em0 into a spanned port in promiscuous mode and >broadcast all traffic from that port out the other network interfaces. I >plan on having em0 (gigabit) and 6 other gigabit interfaces. Each will >then echo the same traffic to six other machines (IDS's) for testing. >SS> >SS>The proof of concept with a gigabit (EM0) and 4 10/100 ethernets (sfx). >The 10/100's will be replaced for implementation. >SS> >SS>Any help would be appreciated. My config follows: > >Hi, >Why to use ng_fec and ng_one2many together? >how about something simplier, like: > > +----------+ -->-sf0:lower--->wire >wire>--em:lower->| one2many | -->-sf1:lower--->wire > | | -->-sf2:lower--->wire > +----------+ -->sf3:lower--->wire > >ngctl mkpeer em0: one2many lower one >ngctl name em0:lower o2m >ngctl connect sf0: o2m lower many0 >ngctl connect sf1: o2m lower many1 >ngctl connect sf2: o2m lower many2 >ngctl connect sf3: o2m lower many3 >ngctl msg o2m setconfig "{ xmitAlg=2 failAlg=1 enabledLinks=[1 1 1 1 1] }" > >ngctl msg sf0: setpromisc 1 >ngctl msg sf0: setautosrc 0 >ngctl msg sf1: setpromisc 1 >ngctl msg sf1: setautosrc 0 >ngctl msg sf2: setpromisc 1 >ngctl msg sf2: setautosrc 0 >ngctl msg sf3: setpromisc 1 >ngctl msg sf3: setautosrc 0 >ngctl msg em0: setpromisc 1 >ngctl msg em0: setautosrc 0 > >This keeps kernel-stack isolated from traffic, I think >(and all interfaces involved layer2 unreachable from outsiders). > >Just tell us if its working for you. > >Chris. > >____________________________________________________________________ >http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. >http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 17:54:10 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01B3816A41F for ; Thu, 20 Oct 2005 17:54:10 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B6AB43D5A for ; Thu, 20 Oct 2005 17:54:09 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id 5E674BC075; Thu, 20 Oct 2005 20:54:08 +0300 (EEST) Received: from [10.0.0.1] (vdp1003.ath03.dsl.hol.gr [62.38.168.4])by smtp.freemail.gr (Postfix) with ESMTP id AA0ABBC054; Thu, 20 Oct 2005 20:54:07 +0300 (EEST) Message-ID: <4357D95C.3080903@freemail.gr> Date: Thu, 20 Oct 2005 20:52:28 +0300 From: Chris Dionissopoulos User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shawn Saunders References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Trying to make a Host into a gigabit hub for testing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dionch@freemail.gr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2005 17:54:10 -0000 > ngctl connect sf0: o2m lower many0 > > Returns: ngctl: send msg: No such file or directory > Is just a syntax error. Replace "o2m" with "o2m:" in every "connect" command (only). Sorry my fault. Chris. ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 18:52:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D87F16A41F for ; Thu, 20 Oct 2005 18:52:18 +0000 (GMT) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (209-162-215-52.dq1sn.easystreet.com [209.162.215.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95FF643D62 for ; Thu, 20 Oct 2005 18:52:17 +0000 (GMT) (envelope-from george@m5p.com) Received: from m5p.com (ssh.m5p.com [IPv6:2001:418:3fd::fb]) by mailhost.m5p.com (8.13.2/8.13.2) with ESMTP id j9KIqGTM020133 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Oct 2005 11:52:16 -0700 (PDT) Received: (from george@localhost) by m5p.com (8.13.2/8.13.2/Submit) id j9KIqFdd051581; Thu, 20 Oct 2005 11:52:15 -0700 (PDT) Date: Thu, 20 Oct 2005 11:52:15 -0700 (PDT) Message-Id: <200510201852.j9KIqFdd051581@m5p.com> From: george+freebsd@m5p.com To: freebsd-net@freebsd.org X-Scanned-By: MIMEDefang 2.49 on IPv6:2001:418:3fd::f7 Subject: re(4) works in 5.3-RELEASE, not in 6.0-RC1 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, 20 Oct 2005 18:52:18 -0000 iI have a RealTek 8169S which works just fine under 5.3-RELEASE. I've been experimenting with 6.0-RC1 booting from CD. It appears to come up with no difficulty, but ping fails, and shortly thereafter, I get "re0: watchdog timeout" in my messages. Although I can't ping other machines and other machines can't ping me, "arp -a" shows the MAC address of other machines on the ethernet segment, and arp on the other machines I tried to ping shows the MAC address of the 6.0 machine. I see the RCS version has gone from 1.28.2.5 in 5.3-RELEASE to 1.46.2.7 in 6.0-RC1, and the changes look numerous but not very big. Should I try compiling the 1.28.2.5 version into a 6.0 kernel and seeing what happens? -- George Mitchell From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 20:01:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AE0A16A41F for ; Thu, 20 Oct 2005 20:01:43 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D107C43D5A for ; Thu, 20 Oct 2005 20:01:42 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j9KKKaaq004576 for ; Thu, 20 Oct 2005 20:20:36 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j9KKKZnY004575 for freebsd-net@freebsd.org; Thu, 20 Oct 2005 20:20:35 GMT (envelope-from dunstan) Date: Thu, 20 Oct 2005 20:20:34 +0000 From: "Wojciech A. Koszek" To: freebsd-net@freebsd.org Message-ID: <20051020202034.GA4556@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Dependency between interfaces 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, 20 Oct 2005 20:01:43 -0000 Hello, Is EVENTHANDLER(9) proper way of notification for standalone driver about network interface attach/detach operations? I've met simple problem in ef(4), which causes machine freeze in following situation: load NIC driver -> load if_ef -> unload NIC driver -> some activity with interface. Althought driver of network interface no longer exists, if_ef does not know about it and continues it's operation. I've seen similar situation for example in ng_fec(4): piece of code needs to call some cleanup routines in order to keep pointers in valid state. I think this situation is almost the same like this current in if_bridge(4). Just repeat situation described above for ef(4), but with if_bridge(4). Regards, -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 20:23:28 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B994F16A41F for ; Thu, 20 Oct 2005 20:23:28 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 445C243D62 for ; Thu, 20 Oct 2005 20:23:28 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 0D9611CCDD; Fri, 21 Oct 2005 09:23:27 +1300 (NZDT) Date: Fri, 21 Oct 2005 09:23:27 +1300 From: Andrew Thompson To: "Wojciech A. Koszek" Message-ID: <20051020202327.GA53753@heff.fud.org.nz> References: <20051020202034.GA4556@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051020202034.GA4556@freebsd.czest.pl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Dependency between interfaces 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, 20 Oct 2005 20:23:28 -0000 On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > Hello, > > Is EVENTHANDLER(9) proper way of notification for standalone driver about > network interface attach/detach operations? I've met simple problem in > ef(4), which causes machine freeze in following situation: load NIC driver > -> load if_ef -> unload NIC driver -> some activity with interface. > Althought driver of network interface no longer exists, if_ef does not know > about it and continues it's operation. > > I've seen similar situation for example in ng_fec(4): piece of code needs to > call some cleanup routines in order to keep pointers in valid state. I think > this situation is almost the same like this current in if_bridge(4). Just > repeat situation described above for ef(4), but with if_bridge(4). > if_bridge(4) now hooks into ether_detach to get notified of a vanishing interface, as of r1.26 (and now in RELENG_6*) Use bridge_ifdetach() to notify the bridge that a member has been detached. The bridge can then remove it from its interface list and not try to send out via a dead pointer. Is it still a problem or did you test on a pre r1.26 kernel? Andrew From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 20:25:49 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 717D216A41F for ; Thu, 20 Oct 2005 20:25:49 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF51343D62 for ; Thu, 20 Oct 2005 20:25:48 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9KKPi2U007225; Thu, 20 Oct 2005 13:25:44 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9KKPiMu007224; Thu, 20 Oct 2005 13:25:44 -0700 Date: Thu, 20 Oct 2005 13:25:44 -0700 From: Brooks Davis To: "Wojciech A. Koszek" Message-ID: <20051020202544.GC18840@odin.ac.hmc.edu> References: <20051020202034.GA4556@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bCsyhTFzCvuiizWE" Content-Disposition: inline In-Reply-To: <20051020202034.GA4556@freebsd.czest.pl> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-net@freebsd.org Subject: Re: Dependency between interfaces 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, 20 Oct 2005 20:25:49 -0000 --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > Hello, >=20 > Is EVENTHANDLER(9) proper way of notification for standalone driver about > network interface attach/detach operations? I've met simple problem in > ef(4), which causes machine freeze in following situation: load NIC driver > -> load if_ef -> unload NIC driver -> some activity with interface. > Althought driver of network interface no longer exists, if_ef does not kn= ow > about it and continues it's operation. >=20 > I've seen similar situation for example in ng_fec(4): piece of code needs= to > call some cleanup routines in order to keep pointers in valid state. I th= ink > this situation is almost the same like this current in if_bridge(4). Just > repeat situation described above for ef(4), but with if_bridge(4). It looks like you could hook into the ifnet_departure_event pretty easily. The one gotcha is that it's called during interface renames so you need to consider that possibility. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --bCsyhTFzCvuiizWE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDV/1HXY6L6fI4GtQRAqBRAJ0d7fIenxmhkt+nb2QdmmZGYUksywCfYXTr P6CHtRxQAtLL/QxHlh1Zlbg= =F1cf -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 20:53:42 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2855316A41F for ; Thu, 20 Oct 2005 20:53:42 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB30143D5A for ; Thu, 20 Oct 2005 20:53:39 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: unknown (tce71.tce85.de: error in processing during lookup of domain of vwsoft.com: Could not find a valid SPF record) client-ip=87.193.6.91; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (unknown [87.193.6.91]) by tce71.tce85.de (Postfix) with ESMTP id 2A74617137 for ; Thu, 20 Oct 2005 22:53:51 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 3845D5C0E for ; Thu, 20 Oct 2005 22:12:08 +0200 (CEST) Message-ID: <4358082A.4060409@vwsoft.com> Date: Thu, 20 Oct 2005 22:12:10 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Subject: IPSec session stalls 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, 20 Oct 2005 20:53:42 -0000 Hi! A few days ago I've managed to setup two IPSec tunnels (3 machines involved) between FreeBSD 5.4R hosts. While I do not fully understand all the options and knobs of IPSec, it was easy to setup (thanks to the handbook guys!). As the tunnels work properly in the first place, there's one issue (on both tunnels). Whenever there's a large amount of traffic per tcp or udp session, the tcp or udp session stalls. For example, I've tried to scp a 1.4M file through one of these tunnels, scp starts to transfer the file and stalls exactly at 49152 bytes being transfered. PcAnywhere (using udp) sessions going through the tunnel work for a few minutes and then the PcAw connection breaks between host and remote. I guess both issues are equal as it generates a lot of traffic in the tunnel. The tunnel itself seems to be stable. I've tried to scp a huge file and ping'ed the other host in another session and no packet loss did appear. what I did: - gif tunnel created on both sides - spd policies setup to encrypt (ipencap) traffic between both machines (in + out) - racoon installed and key timelife set to 1 hour - route set into the tunnel The racoon debug output did not show anything which would lead me to an issue with racoon. Where do I have to look for? How do I debug this problem? Did anybody experience similar problems? Thanks, Volker From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 21:31:16 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89D7716A41F for ; Thu, 20 Oct 2005 21:31:16 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from hotmail.com (bay101-f20.bay101.hotmail.com [64.4.56.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50D1943D62 for ; Thu, 20 Oct 2005 21:31:16 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Oct 2005 14:31:15 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Thu, 20 Oct 2005 21:31:15 GMT X-Originating-IP: [64.60.108.59] X-Originating-Email: [saundersconsult@hotmail.com] X-Sender: saundersconsult@hotmail.com In-Reply-To: <4357D95C.3080903@freemail.gr> From: "Shawn Saunders" To: dionch@freemail.gr Date: Thu, 20 Oct 2005 21:31:15 +0000 X-Priority: 1 Importance: High Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 20 Oct 2005 21:31:15.0730 (UTC) FILETIME=[99E3B720:01C5D5BD] Cc: freebsd-net@freebsd.org Subject: Re: Trying to make a Host into a gigabit hub for testing 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, 20 Oct 2005 21:31:16 -0000 Chris, Now the traffic is going out all the ports, thanks. Only one issue, is that it is also being echo'd back the em0 interface. When I put this under a full GIGABIT load, 6 interfaces feeding back what was just sent them, will kill my primary em0 interface. Is there a way to make the echo from em0 to all other interfaces only go one-way, rather than em0 also being part of the group and receiving everthing it sends back again? Shawn >From: Chris Dionissopoulos >Reply-To: dionch@freemail.gr >To: Shawn Saunders >CC: freebsd-net@freebsd.org >Subject: Re: Trying to make a Host into a gigabit hub for testing >Date: Thu, 20 Oct 2005 20:52:28 +0300 > > >>ngctl connect sf0: o2m lower many0 >> >>Returns: ngctl: send msg: No such file or directory >> >Is just a syntax error. Replace "o2m" with "o2m:" in every "connect" >command (only). >Sorry my fault. > >Chris. > >____________________________________________________________________ >http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. >http://www.freemail.gr - free email service for the Greek-speaking. >_______________________________________________ >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 Thu Oct 20 21:49:26 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F63316A41F for ; Thu, 20 Oct 2005 21:49:26 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA91A43D5A for ; Thu, 20 Oct 2005 21:49:25 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: unknown (tce71.tce85.de: error in processing during lookup of domain of vwsoft.com: Could not find a valid SPF record) client-ip=87.193.4.214; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (unknown [87.193.4.214]) by tce71.tce85.de (Postfix) with ESMTP id 5940017131 for ; Thu, 20 Oct 2005 23:49:34 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 6BE105C0E for ; Thu, 20 Oct 2005 23:47:25 +0200 (CEST) Message-ID: <43581E7F.5080305@vwsoft.com> Date: Thu, 20 Oct 2005 23:47:27 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4358082A.4060409@vwsoft.com> In-Reply-To: <4358082A.4060409@vwsoft.com> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Subject: Re: IPSec session stalls 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, 20 Oct 2005 21:49:26 -0000 hmm, I hate replying to myself.... I've just checked another thing: When disabling pf on both IPSec endpoints (even large) file transfer works fine. I'm using pf and altq with cbq. Removing the pf 'scrub' rules didn't solve it. In the firewall I'll let gif traffic pass with rules like: pass quick on $if_ext proto { ah, esp } from to any keep state queue q_h1 pass quick on $if_ext proto { ah, esp } from any to keep state queue q_h1 pass quick on $if_ext proto ipencap from to any keep state pass quick on $if_ext proto ipencap from any to keep state I guess as all works fine while pf is disabled this is an pf issue, right? Thanks, Volker On 2005-10-20 22:12, Volker wrote: > Hi! > > A few days ago I've managed to setup two IPSec tunnels (3 machines > involved) between FreeBSD 5.4R hosts. > > While I do not fully understand all the options and knobs of IPSec, it > was easy to setup (thanks to the handbook guys!). > > As the tunnels work properly in the first place, there's one issue (on > both tunnels). Whenever there's a large amount of traffic per tcp or udp > session, the tcp or udp session stalls. > > For example, I've tried to scp a 1.4M file through one of these tunnels, > scp starts to transfer the file and stalls exactly at 49152 bytes being > transfered. PcAnywhere (using udp) sessions going through the tunnel > work for a few minutes and then the PcAw connection breaks between host > and remote. I guess both issues are equal as it generates a lot of > traffic in the tunnel. > > The tunnel itself seems to be stable. I've tried to scp a huge file and > ping'ed the other host in another session and no packet loss did appear. > > what I did: > > - gif tunnel created on both sides > - spd policies setup to encrypt (ipencap) traffic between both machines > (in + out) > - racoon installed and key timelife set to 1 hour > - route set into the tunnel > > The racoon debug output did not show anything which would lead me to an > issue with racoon. > > Where do I have to look for? How do I debug this problem? Did anybody > experience similar problems? > > Thanks, > > Volker > From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 22:21:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8308016A41F for ; Thu, 20 Oct 2005 22:21:14 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from hotmail.com (bay101-f31.bay101.hotmail.com [64.4.56.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4999D43D62 for ; Thu, 20 Oct 2005 22:21:14 +0000 (GMT) (envelope-from saundersconsult@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Oct 2005 15:21:14 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Thu, 20 Oct 2005 22:21:13 GMT X-Originating-IP: [64.60.108.59] X-Originating-Email: [saundersconsult@hotmail.com] X-Sender: saundersconsult@hotmail.com In-Reply-To: <4357D95C.3080903@freemail.gr> From: "Shawn Saunders" To: dionch@freemail.gr Date: Thu, 20 Oct 2005 22:21:13 +0000 X-Priority: 1 Importance: High Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 20 Oct 2005 22:21:14.0090 (UTC) FILETIME=[950D24A0:01C5D5C4] Cc: freebsd-net@freebsd.org Subject: Re: Trying to make a Host into a gigabit hub for testing 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, 20 Oct 2005 22:21:14 -0000 Chris, Ignore the last note. It is working, with the correction you gave me below. Working Great. Thanks for all your help. Shawn >From: Chris Dionissopoulos >Reply-To: dionch@freemail.gr >To: Shawn Saunders >CC: freebsd-net@freebsd.org >Subject: Re: Trying to make a Host into a gigabit hub for testing >Date: Thu, 20 Oct 2005 20:52:28 +0300 > > >>ngctl connect sf0: o2m lower many0 >> >>Returns: ngctl: send msg: No such file or directory >> >Is just a syntax error. Replace "o2m" with "o2m:" in every "connect" >command (only). >Sorry my fault. > >Chris. > >____________________________________________________________________ >http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. >http://www.freemail.gr - free email service for the Greek-speaking. >_______________________________________________ >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 Thu Oct 20 22:24:01 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5305116A420 for ; Thu, 20 Oct 2005 22:24:01 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unsane.co.uk [62.140.220.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8886B43D5A for ; Thu, 20 Oct 2005 22:24:00 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (localhost [127.0.0.1]) by unsane.co.uk (8.13.4/8.13.3) with ESMTP id j9KMPV22018644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 23:25:31 +0100 (BST) (envelope-from jhary@unsane.co.uk) Received: from localhost (jhary@localhost) by unsane.co.uk (8.13.4/8.13.3/Submit) with ESMTP id j9KMPVf4018641; Thu, 20 Oct 2005 23:25:31 +0100 (BST) (envelope-from jhary@unsane.co.uk) Date: Thu, 20 Oct 2005 23:25:30 +0100 (BST) From: Vince Hoffman To: Holm Tiffe In-Reply-To: <20051019180114.GB38872@pegasus.freiberg-net.de> Message-ID: <20051020225940.H16510@unsane.co.uk> References: <20051019180114.GB38872@pegasus.freiberg-net.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: urgent: RELENG_5 ipfw/nat/IPSEC Problem.. 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, 20 Oct 2005 22:24:01 -0000 On Wed, 19 Oct 2005, Holm Tiffe wrote: > Hi, > > I have a currently big problem with the following setup: > > A FreeBSD Box, running 5_STABLE is connected wirh one interface to the > public, with the other to an nated' subnet with private address space. > I need to allow at least one host from inside the private network access > to an outside Cisco VPN concentrator. I've learned in the meantime, that > allowing udp connections from inside to the outside net and vis versa is'nt > doing the job. > (I've struggeled in the meantime over tcpdump, that is showing isakmp > packets leaving the external interface, but they dont't really do this..) > > What exactly I have to do get this working? > What I found I needed to do to connect to the work Cisco VPN through my FreeBSD NAT firewall was to tell it not to NAT the source port of the isakmp packets, as isakmps need to have source and destination port 500. using pf the command is (taken from man pf.conf) # Map outgoing packets' source port to an assigned proxy port instead of # an arbitrary port. # In this case, proxy outgoing isakmp with port 500 on the gateway. nat on $ext_if inet proto udp from any port = isakmp to any -> ($ext_if) \ port 500 Not sure about the same for ipfw/natd but i'm sure its doable. Vince > The FreeBSD Box is out of reach (around 50km from here), I can't access the > hosts on the inside network and I dont't have access to the cisco > concentrator, so I can't test different setups .. > > Can please anyone help? > > Regards, > > Holm > > ps: please Cc me, I've currently not subscribed to this list. > -- > L&P::Kommunikation GbR Holm Tiffe * Administration, Development > FreibergNet.de Internet Systems phone +49 3731 419010 > Bereich Server & Technik fax +49 3731 4196026 > D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 01:44:56 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13A3F16A41F; Fri, 21 Oct 2005 01:44:56 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from smtp2.skyinet.net (smtp2.skyinet.net [202.78.97.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A66B043D5A; Fri, 21 Oct 2005 01:44:55 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from fooler (fooler.ilo.skyinet.net [202.78.118.66]) by smtp2.skyinet.net (Postfix) with SMTP id 9CCB15BA43; Fri, 21 Oct 2005 09:44:53 +0800 (PHT) Message-ID: <07c501c5d5e1$0ddf67f0$42764eca@ilo.skyinet.net> From: To: "Marcin Jessa" References: <20051019235111.2225345e.lists@yazzy.org><20051020070145.GA59364@cell.sick.ru><20051020131549.5e432073.lists@yazzy.org> <20051020123159.33f6fa33.lists@yazzy.org> Date: Fri, 21 Oct 2005 09:45:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: glebius@FreeBSD.org, current@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 21 Oct 2005 01:44:56 -0000 ----- Original Message ----- From: "Marcin Jessa" To: "Marcin Jessa" Cc: ; ; Sent: Thursday, October 20, 2005 8:31 PM Subject: Re: PPPoE and Radius on 6.0RC1 > Just tested the same setup on 7.0 built tonight and it did not work. > The pppoed daemon never sends any requests to freeradius... take note that pppoed is the one processing pppoe frames while user ppp is the one communicating with your radius server.... >> set radius /etc/ppp/radius.conf #turn on radius auth and use what does your radius.conf says? fooler. From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 05:22:58 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3C2416A41F for ; Fri, 21 Oct 2005 05:22:58 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03C8743D48 for ; Fri, 21 Oct 2005 05:22:57 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9L5MtUg014783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Oct 2005 09:22:55 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9L5Mtia014782 for net@freebsd.org; Fri, 21 Oct 2005 09:22:55 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 21 Oct 2005 09:22:55 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20051021052255.GV59364@cell.sick.ru> References: <20051020140200.GL59364@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051020140200.GL59364@cell.sick.ru> User-Agent: Mutt/1.5.6i Cc: Subject: Re: em(4) patch for test 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, 21 Oct 2005 05:22:58 -0000 On Thu, Oct 20, 2005 at 06:02:00PM +0400, Gleb Smirnoff wrote: T> Colleagues, T> T> since the if_em problem was taken as a late showstopper for 6.0-RELEASE, T> I am asking you to help with testing of the fixes made in HEAD. T> T> Does your em(4) interface wedge for some time? T> Do you see a lot of errors in 'netstat -i' output? Does these errors T> increase not monotonously but they have peaks? T> T> If the answer is yes, then the attached patch is likely to fix your problem. T> If the answer is no, then you are still encouraged to help with testing T> and install the patch to check that no regressions are introduced. If you T> skip this, then you may encounter regressions after release, so you have T> been warned. T> T> So, in short: please test! Thanks in advance! T> T> The patch is against fresh RELENG_6. Christian has prepared a patch for RELENG_5: http://people.freebsd.org/~csjp/if_em.c.1129840898.diff This is the most important bit in all changes to em. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 05:30:55 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2376516A420; Fri, 21 Oct 2005 05:30:55 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34B6443D45; Fri, 21 Oct 2005 05:30:53 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9L5UdL5014797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Oct 2005 09:30:39 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9L5UXfH014796; Fri, 21 Oct 2005 09:30:33 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 21 Oct 2005 09:30:33 +0400 From: Gleb Smirnoff To: Yar Tikhiy Message-ID: <20051021053033.GW59364@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Yar Tikhiy , freebsd-net@freebsd.org, ru@freebsd.org, Andrew Thompson References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> <20051020085721.GC27114@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051020085721.GC27114@comp.chem.msu.su> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson Subject: Re: vlan patch 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, 21 Oct 2005 05:30:55 -0000 On Thu, Oct 20, 2005 at 12:57:21PM +0400, Yar Tikhiy wrote: Y> The hash code consists of literally a couple of #define's. And the Y> difference between ng_vlan(4) and vlan(4) is that each ng_vlan node Y> gets its own instance of the hash table. OTOH, in vlan(4) we need Y> to decide if the hash table will be per parent interface or a single Y> global instance. In the latter case we could hash by a combination Y> of the VLAN tag and parent's ifindex. Perhaps this approach will Y> yield more CPU cache hits during hash table lookups. In addition, Y> it will be thriftier in using memory. Locking the global hash table Y> should not be an issue as we can use an sx lock in this case for Y> optimal read access. The sx lock is slow. We'd better use per interface hash, and thus get locking instantly, with per-vlan lock. In other case, we will acquire per-vlan lock + the sx lock on every packet. The sx lock actually means mtx_lock+mtx_unlock, thus we will make 3 mutex operations instead of one. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 05:32:32 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1430816A41F for ; Fri, 21 Oct 2005 05:32:32 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C56243D49 for ; Fri, 21 Oct 2005 05:32:31 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9L5WTSb014806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Oct 2005 09:32:30 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9L5WTnv014805; Fri, 21 Oct 2005 09:32:29 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 21 Oct 2005 09:32:28 +0400 From: Gleb Smirnoff To: Shawn Saunders Message-ID: <20051021053228.GX59364@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Shawn Saunders , dionch@freemail.gr, freebsd-net@freebsd.org References: <4357D95C.3080903@freemail.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: dionch@freemail.gr, freebsd-net@FreeBSD.org Subject: Re: Trying to make a Host into a gigabit hub for testing 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, 21 Oct 2005 05:32:32 -0000 On Thu, Oct 20, 2005 at 09:31:15PM +0000, Shawn Saunders wrote: S> Chris, S> S> Now the traffic is going out all the ports, thanks. Only one issue, is S> that it is also being echo'd back the em0 interface. When I put this under S> a full GIGABIT load, 6 interfaces feeding back what was just sent them, S> will kill my primary em0 interface. S> S> Is there a way to make the echo from em0 to all other interfaces only go S> one-way, rather than em0 also being part of the group and receiving S> everthing it sends back again? I haven't yet understood the graph you built, but the Subject line tells me that you should use ng_hub(4), not ng_one2many(4) or ng_fec(4). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 06:07:03 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7A1516A41F; Fri, 21 Oct 2005 06:07:03 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8246F43D45; Fri, 21 Oct 2005 06:07:00 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j9L66tC7097011; Fri, 21 Oct 2005 10:06:55 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j9L66t4j097010; Fri, 21 Oct 2005 10:06:55 +0400 (MSD) (envelope-from yar) Date: Fri, 21 Oct 2005 10:06:55 +0400 From: Yar Tikhiy To: Gleb Smirnoff , freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson Message-ID: <20051021060654.GC69814@comp.chem.msu.su> References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> <20051020085721.GC27114@comp.chem.msu.su> <20051021053033.GW59364@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051021053033.GW59364@cell.sick.ru> User-Agent: Mutt/1.5.9i Cc: Subject: Re: vlan patch 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, 21 Oct 2005 06:07:04 -0000 On Fri, Oct 21, 2005 at 09:30:33AM +0400, Gleb Smirnoff wrote: > On Thu, Oct 20, 2005 at 12:57:21PM +0400, Yar Tikhiy wrote: > Y> The hash code consists of literally a couple of #define's. And the > Y> difference between ng_vlan(4) and vlan(4) is that each ng_vlan node > Y> gets its own instance of the hash table. OTOH, in vlan(4) we need > Y> to decide if the hash table will be per parent interface or a single > Y> global instance. In the latter case we could hash by a combination > Y> of the VLAN tag and parent's ifindex. Perhaps this approach will > Y> yield more CPU cache hits during hash table lookups. In addition, > Y> it will be thriftier in using memory. Locking the global hash table > Y> should not be an issue as we can use an sx lock in this case for > Y> optimal read access. > > The sx lock is slow. We'd better use per interface hash, and thus > get locking instantly, with per-vlan lock. In other case, we will > acquire per-vlan lock + the sx lock on every packet. The sx lock > actually means mtx_lock+mtx_unlock, thus we will make 3 mutex > operations instead of one. OK, let's forget about sx locks. However, a per-interface hash is associated with a _physical_ interface, hence we must find the vlan to lock using the hash first. If there were a physical interface lock held by its driver in each case, it could protect the hash as well. Can we rely on this? -- Yar From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 06:40:46 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ADD416A41F; Fri, 21 Oct 2005 06:40:46 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A86EA43D4C; Fri, 21 Oct 2005 06:40:45 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9L6eTaC015742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Oct 2005 10:40:29 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9L6eT8P015741; Fri, 21 Oct 2005 10:40:29 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 21 Oct 2005 10:40:28 +0400 From: Gleb Smirnoff To: Yar Tikhiy Message-ID: <20051021064028.GZ59364@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Yar Tikhiy , freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> <20051020085721.GC27114@comp.chem.msu.su> <20051021053033.GW59364@cell.sick.ru> <20051021060654.GC69814@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051021060654.GC69814@comp.chem.msu.su> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson Subject: Re: vlan patch 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, 21 Oct 2005 06:40:46 -0000 On Fri, Oct 21, 2005 at 10:06:55AM +0400, Yar Tikhiy wrote: Y> On Fri, Oct 21, 2005 at 09:30:33AM +0400, Gleb Smirnoff wrote: Y> > On Thu, Oct 20, 2005 at 12:57:21PM +0400, Yar Tikhiy wrote: Y> > Y> The hash code consists of literally a couple of #define's. And the Y> > Y> difference between ng_vlan(4) and vlan(4) is that each ng_vlan node Y> > Y> gets its own instance of the hash table. OTOH, in vlan(4) we need Y> > Y> to decide if the hash table will be per parent interface or a single Y> > Y> global instance. In the latter case we could hash by a combination Y> > Y> of the VLAN tag and parent's ifindex. Perhaps this approach will Y> > Y> yield more CPU cache hits during hash table lookups. In addition, Y> > Y> it will be thriftier in using memory. Locking the global hash table Y> > Y> should not be an issue as we can use an sx lock in this case for Y> > Y> optimal read access. Y> > Y> > The sx lock is slow. We'd better use per interface hash, and thus Y> > get locking instantly, with per-vlan lock. In other case, we will Y> > acquire per-vlan lock + the sx lock on every packet. The sx lock Y> > actually means mtx_lock+mtx_unlock, thus we will make 3 mutex Y> > operations instead of one. Y> Y> OK, let's forget about sx locks. However, a per-interface hash is Y> associated with a _physical_ interface, hence we must find the vlan Y> to lock using the hash first. If there were a physical interface Y> lock held by its driver in each case, it could protect the hash as Y> well. Can we rely on this? Oops. When speaking about per-vlan lock, I really meant per-trunk lock. Or are you going to implement per-vlan lock? Is this going to be a benefit? Since all packets on trunk are serialized by NIC driver, can there be any benefit in creating a mutex per vlan interface, not per vlan trunk? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 07:10:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE4A16A41F for ; Fri, 21 Oct 2005 07:10:47 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from corwin.easynet.fr (smarthost168.mail.easynet.fr [212.180.1.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23A2143D46 for ; Fri, 21 Oct 2005 07:10:46 +0000 (GMT) (envelope-from vanhu@zeninc.net) Received: from easyconnect2121135-233.clients.easynet.fr ([212.11.35.233] helo=smtp.zeninc.net) by corwin.easynet.fr with esmtp (Exim 4.50) id 1ESr36-0005oX-Tp for freebsd-net@freebsd.org; Fri, 21 Oct 2005 09:10:45 +0200 Received: by smtp.zeninc.net (smtpd, from userid 1000) id B36913F17; Fri, 21 Oct 2005 09:10:39 +0200 (CEST) Date: Fri, 21 Oct 2005 09:10:39 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20051021071039.GA1876@zen.inc> References: <4358082A.4060409@vwsoft.com> <43581E7F.5080305@vwsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43581E7F.5080305@vwsoft.com> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: IPSec session stalls 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, 21 Oct 2005 07:10:47 -0000 On Thu, Oct 20, 2005 at 11:47:27PM +0100, Volker wrote: > hmm, I hate replying to myself.... :-) [rules] > I guess as all works fine while pf is disabled this is an pf issue, right? Not sure: what you described in your first mail also looks like a "basic" fragmentation problem, which can be easily solved by decreasing MTU on traffic endpoints (you can also play with TCPMSS on one gate, but this will only solve TCP problems...). The pf interaction may only be a side effect of a fragmentation problem. Yvan. -- NETASQ - Secure Internet Connectivity http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 07:45:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ACA216A41F for ; Fri, 21 Oct 2005 07:45:15 +0000 (GMT) (envelope-from freebsd@azimut-tour.ru) Received: from cny.innet.yaroslavl.su (cny.innet.yaroslavl.su [217.15.134.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62A3443D46 for ; Fri, 21 Oct 2005 07:45:13 +0000 (GMT) (envelope-from freebsd@azimut-tour.ru) Received: from tac.innet.yaroslavl.su (tac.innet.yaroslavl.su [217.15.135.68]) by cny.innet.yaroslavl.su (8.11.6/8.11.6) with ESMTP id j9L7jCW26341 for ; Fri, 21 Oct 2005 11:45:12 +0400 (MSD) Received: from greencomp.azimutprint.ru (118.ppp145.yaroslavl.ru [217.15.145.118]) by tac.innet.yaroslavl.su (8.12.11/8.12.11) with ESMTP id j9L7j5L5083471 for ; Fri, 21 Oct 2005 11:45:08 +0400 (MSD) Date: Fri, 21 Oct 2005 11:44:57 +0400 From: "FreeBSD@azimut-tour.ru" X-Mailer: The Bat! (v3.60.07) Professional X-Priority: 3 (Normal) Message-ID: <1755408847.20051021114457@azimut-tour.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: em(4) patch for test X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "FreeBSD@azimut-tour.ru" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 07:45:15 -0000 And for 5-th version will not be? --=20 =D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC, GreenX From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 07:46:20 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEB6016A421; Fri, 21 Oct 2005 07:46:20 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B0DC43D46; Fri, 21 Oct 2005 07:46:16 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j9L7kApx001387; Fri, 21 Oct 2005 11:46:10 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j9L7k7QD001386; Fri, 21 Oct 2005 11:46:07 +0400 (MSD) (envelope-from yar) Date: Fri, 21 Oct 2005 11:46:07 +0400 From: Yar Tikhiy To: Gleb Smirnoff , freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson Message-ID: <20051021074606.GF69814@comp.chem.msu.su> References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> <20051020085721.GC27114@comp.chem.msu.su> <20051021053033.GW59364@cell.sick.ru> <20051021060654.GC69814@comp.chem.msu.su> <20051021064028.GZ59364@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051021064028.GZ59364@cell.sick.ru> User-Agent: Mutt/1.5.9i Cc: Subject: Re: vlan patch 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, 21 Oct 2005 07:46:21 -0000 On Fri, Oct 21, 2005 at 10:40:28AM +0400, Gleb Smirnoff wrote: > On Fri, Oct 21, 2005 at 10:06:55AM +0400, Yar Tikhiy wrote: > Y> On Fri, Oct 21, 2005 at 09:30:33AM +0400, Gleb Smirnoff wrote: > Y> > On Thu, Oct 20, 2005 at 12:57:21PM +0400, Yar Tikhiy wrote: > Y> > Y> The hash code consists of literally a couple of #define's. And the > Y> > Y> difference between ng_vlan(4) and vlan(4) is that each ng_vlan node > Y> > Y> gets its own instance of the hash table. OTOH, in vlan(4) we need > Y> > Y> to decide if the hash table will be per parent interface or a single > Y> > Y> global instance. In the latter case we could hash by a combination > Y> > Y> of the VLAN tag and parent's ifindex. Perhaps this approach will > Y> > Y> yield more CPU cache hits during hash table lookups. In addition, > Y> > Y> it will be thriftier in using memory. Locking the global hash table > Y> > Y> should not be an issue as we can use an sx lock in this case for > Y> > Y> optimal read access. > Y> > > Y> > The sx lock is slow. We'd better use per interface hash, and thus > Y> > get locking instantly, with per-vlan lock. In other case, we will > Y> > acquire per-vlan lock + the sx lock on every packet. The sx lock > Y> > actually means mtx_lock+mtx_unlock, thus we will make 3 mutex > Y> > operations instead of one. > Y> > Y> OK, let's forget about sx locks. However, a per-interface hash is > Y> associated with a _physical_ interface, hence we must find the vlan > Y> to lock using the hash first. If there were a physical interface > Y> lock held by its driver in each case, it could protect the hash as > Y> well. Can we rely on this? > > Oops. When speaking about per-vlan lock, I really meant per-trunk lock. > > Or are you going to implement per-vlan lock? Is this going to be a benefit? > Since all packets on trunk are serialized by NIC driver, can there be any > benefit in creating a mutex per vlan interface, not per vlan trunk? I think you make a good point. Indeed, today 2 threads won't process at once 2 vlan packets coming from the same parent interface. The curious question is whether this state of matters will stay forever. The other approach would be to have separate threads for ip_input, ipfw, ip_output, and the rest of network stack functions, but it appears too inefficient in our case due to the overhead of context switches and locking. So I agree that locking vlans per trunk is better today. Do you think we should stick the vlan mutex into struct ifnet, too, along with the pointer to the vlan hash? Perhaps, it's time to separate vlan-related fields into a separate struct? -- Yar From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 08:01:28 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 358E416A41F; Fri, 21 Oct 2005 08:01:28 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 553F943D46; Fri, 21 Oct 2005 08:01:26 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9L813k4017502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Oct 2005 12:01:04 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9L813GR017501; Fri, 21 Oct 2005 12:01:03 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 21 Oct 2005 12:01:03 +0400 From: Gleb Smirnoff To: Yar Tikhiy Message-ID: <20051021080103.GH59364@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Yar Tikhiy , freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson References: <20051019102559.GA45909@heff.fud.org.nz> <20051020070054.GZ59364@cell.sick.ru> <20051020085721.GC27114@comp.chem.msu.su> <20051021053033.GW59364@cell.sick.ru> <20051021060654.GC69814@comp.chem.msu.su> <20051021064028.GZ59364@cell.sick.ru> <20051021074606.GF69814@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051021074606.GF69814@comp.chem.msu.su> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org, ru@FreeBSD.org, Andrew Thompson Subject: Re: vlan patch 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, 21 Oct 2005 08:01:28 -0000 On Fri, Oct 21, 2005 at 11:46:07AM +0400, Yar Tikhiy wrote: Y> > Or are you going to implement per-vlan lock? Is this going to be a benefit? Y> > Since all packets on trunk are serialized by NIC driver, can there be any Y> > benefit in creating a mutex per vlan interface, not per vlan trunk? Y> Y> I think you make a good point. Indeed, today 2 threads won't process Y> at once 2 vlan packets coming from the same parent interface. The Y> curious question is whether this state of matters will stay forever. Y> The other approach would be to have separate threads for ip_input, Y> ipfw, ip_output, and the rest of network stack functions, but it Y> appears too inefficient in our case due to the overhead of context Y> switches and locking. So I agree that locking vlans per trunk is Y> better today. Y> Y> Do you think we should stick the vlan mutex into struct ifnet, too, Y> along with the pointer to the vlan hash? Perhaps, it's time to Y> separate vlan-related fields into a separate struct? Not sure yet. Now we have only if_nvlans in ifnet, right? If we eliminate the global vlan list search, then we need to invent some if_vlantrunk structure, where we are going to have at least: - nvlans - mutex - hash The question is whether should we embed the structure into ifnet, or allocate it on first vlan created and store only pointer in ifnet. Embedding removes one pointer derefernce and that's good. However embedding enlarges size of ifnet. Dynamic allocation has one more benefit - we can leave vlan interfaces when the parent is destroyed. However, I'm not sure this is a positive feature. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 08:15:20 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 044C916A41F for ; Fri, 21 Oct 2005 08:15:20 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from pleiades.aeternal.net (pleiades.in.markiza.sk [62.168.76.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D52343D46 for ; Fri, 21 Oct 2005 08:15:17 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: by pleiades.aeternal.net (Postfix, from userid 1001) id 7F45F114E1; Fri, 21 Oct 2005 10:15:20 +0200 (CEST) Date: Fri, 21 Oct 2005 10:15:20 +0200 From: martin hudec To: freebsd-net@freebsd.org Message-ID: <20051021081520.GA37772@pleiades.aeternal.net> References: <1755408847.20051021114457@azimut-tour.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <1755408847.20051021114457@azimut-tour.ru> X-Copyright: (C) 2005 Martin Hudec X-Operating-System: FreeBSD pleiades.aeternal.net 7.0-CURRENT i386 X-PGP-Key: http://www.aeternal.net/corwin_aeternal.asc User-Agent: mutt-ng/devel-r535 (FreeBSD) Subject: Re: em(4) patch for test X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin hudec List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 08:15:20 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Fri, Oct 21, 2005 at 11:44:57AM +0400 or thereabouts, FreeBSD@azimut-tou= r.ru wrote: > And for 5-th version will not be? http://people.freebsd.org/~csjp/if_em.c.1129840898.diff --=20 martin hudec * 421 907 303 393 * corwin@aeternal.net * http://www.aeternal.net "Nothing travels faster than the speed of light with the possible=20 exception of bad news, which obeys its own special laws." Douglas Adams, "The Hitchhiker's Guide to the Galaxy" --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDWKOYZYEZIv+rgggRAg9LAJ45Te7KWPGQVH8S75ZKK84y9jylNwCfWfpO FNAZ6U8NsqqSwQnVtcoxJGc= =bsy9 -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 09:29:39 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91A1416A41F; Fri, 21 Oct 2005 09:29:39 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E341D43D45; Fri, 21 Oct 2005 09:29:38 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EStD0-0002Gp-11; Fri, 21 Oct 2005 11:29:07 +0200 Date: Fri, 21 Oct 2005 11:29:34 +0200 From: Marcin Jessa To: Message-Id: <20051021112934.7c857fcc.lists@yazzy.org> In-Reply-To: <07c501c5d5e1$0ddf67f0$42764eca@ilo.skyinet.net> References: <20051019235111.2225345e.lists@yazzy.org> <20051020070145.GA59364@cell.sick.ru> <20051020131549.5e432073.lists@yazzy.org> <20051020123159.33f6fa33.lists@yazzy.org> <07c501c5d5e1$0ddf67f0$42764eca@ilo.skyinet.net> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: glebius@FreeBSD.org, current@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 21 Oct 2005 09:29:39 -0000 On Fri, 21 Oct 2005 09:45:02 +0800 wrote: > ----- Original Message ----- > From: "Marcin Jessa" > To: "Marcin Jessa" > Cc: ; ; > Sent: Thursday, October 20, 2005 8:31 PM > Subject: Re: PPPoE and Radius on 6.0RC1 > > > > Just tested the same setup on 7.0 built tonight and it did not work. > > The pppoed daemon never sends any requests to freeradius... > > take note that pppoed is the one processing pppoe frames while user > ppp is the one communicating with your radius server.... > > >> set radius /etc/ppp/radius.conf #turn on radius auth and > >> use > > what does your radius.conf says? auth 127.0.0.1:1812 secret_pass 3 3 acct 127.0.0.1:1813 secret_pass 3 3 I also tried with the IP of my wired nic auth 192.168.2.8:1812 witelcom123 3 3 acct 192.168.2.8:1813 witelcom123 3 3 Both hosts are enabled as radius clients in freeradius's config file. The problem seems to be ppp is never started by pppoe. and nothing shows in the ppp.log even with full debugging switched on. Running ppp manually and loading the default profile. # ppp Working in interactive mode Using interface: tun0 Warning: tun0: AIFADDR 192.168.2.8 -> 192.168.2.202 returns 0 ppp ON freakbs> load default Warning: tun0: DIFADDR 192.168.2.8 -> 192.168.2.202 returns 0 Warning: tun0: AIFADDR 192.168.2.8 -> 192.168.2.201 returns 0 ppp ON freakbs> show log Log: CCP Chat Command Connect Debug Filter IPCP IPV6CP LCP LQM Phase Radius TCP/IP Tun Warning Error Alert Local: Warning Error Alert Gives me (had to put it on the web, it would be unreadable here): http://www.yazzy.org/debug/ppp1.log Trying to auth user and running ppp in command line: ppp -direct default Gives http://www.yazzy.org/debug/ppp.log Marcin From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 11:45:45 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF7FB16A41F; Fri, 21 Oct 2005 11:45:45 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from smtp1.skyinet.net (smtp1.skyinet.net [202.78.97.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CCE843D45; Fri, 21 Oct 2005 11:45:45 +0000 (GMT) (envelope-from fooler@skyinet.net) Received: from fooler (fooler.ilo.skyinet.net [202.78.118.66]) by smtp1.skyinet.net (Postfix) with SMTP id 580A3582C8; Fri, 21 Oct 2005 19:45:43 +0800 (PHT) Message-ID: <002801c5d634$fdc66bd0$42764eca@ilo.skyinet.net> From: To: "Marcin Jessa" References: <20051019235111.2225345e.lists@yazzy.org><20051020070145.GA59364@cell.sick.ru><20051020131549.5e432073.lists@yazzy.org><20051020123159.33f6fa33.lists@yazzy.org><07c501c5d5e1$0ddf67f0$42764eca@ilo.skyinet.net> <20051021112934.7c857fcc.lists@yazzy.org> Date: Fri, 21 Oct 2005 19:45:52 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: glebius@FreeBSD.org, current@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 21 Oct 2005 11:45:45 -0000 ----- Original Message ----- From: "Marcin Jessa" To: Cc: ; ; Sent: Friday, October 21, 2005 5:29 PM Subject: Re: PPPoE and Radius on 6.0RC1 > The problem seems to be ppp is never started by pppoe. here is a sample configuration for your pppoe server.... assuming you have two intel nics named fxp0 and fxp1... fxp0 is facing the net and fxp1 is facing the pppoe clients... fxp1 is ip less... please do the following... 1. in your kernel config file, add the following options and compile the kernel options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_PPPOE options NETGRAPH_SOCKET 2. in your /etc/rc.conf gateway_enable="YES" ifconfig_fxp0="inet 192.168.2.8 netmask 255.255.255.0" ifconfig_fxp1="up" pppoed_enable="YES" pppoed_flags="-l PPPoE -P /var/run/pppoed.pid" pppoed_interface="fxp1" 3. in your /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command Debug Radius ident user-ppp VERSION (built COMPILATIONDATE) PPPoE: set ifaddr 192.168.2.8 192.168.2.100-192.168.2.120 255.255.255.255 set radius /etc/ppp/radius.conf set dns 192.168.2.45 deny deflate disable deflate accept dns enable lqr enable echo deny pap deny chap deny LANMan deny MSChap enable MSChapV2 disable pred1 disable utmp disable ipv6cp set callback set cbcp set cd 5! set nbns set speed sync set timeout 0 4. in your /etc/ppp/radius.conf auth 127.0.0.1:1812 secret_key 3 3 acct 127.0.0.1:1813 secret_key 3 3 try to remark "set radius /etc/ppp/radius.conf" first in /etc/ppp/ppp.conf to make sure that your pppoe authentication is working without using a radius server... if all went well, then make sure your radius server is working properly by binding to ip address 127.0.0.1 only for security purposes... fooler. From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 11:52:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 694FF16A41F for ; Fri, 21 Oct 2005 11:52:40 +0000 (GMT) (envelope-from yschoi@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7758A43D4C for ; Fri, 21 Oct 2005 11:52:39 +0000 (GMT) (envelope-from yschoi@gmail.com) Received: by xproxy.gmail.com with SMTP id i29so64728wxd for ; Fri, 21 Oct 2005 04:52:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Ujkng3qOIakrr4T/2+CsXAnE3An6H96UFbAC1rc6HWK6n5zECoDwbdfKKTGSXqiG8r25Cf8m9IfZ9gxrXNCYBM0nySw4jHhBi6KJRchubl2UqZAxdyS2TStrW9OqSERI3tqGyMFXq1XpB8TlgWoDnRQ12A+p5jY+LqP16nFUXiU= Received: by 10.70.53.10 with SMTP id b10mr1730031wxa; Fri, 21 Oct 2005 04:52:38 -0700 (PDT) Received: by 10.70.92.1 with HTTP; Fri, 21 Oct 2005 04:52:38 -0700 (PDT) Message-ID: <5a8ce9ca0510210452j274fe919g5c589f2eaf919ff5@mail.gmail.com> Date: Fri, 21 Oct 2005 20:52:38 +0900 From: cys To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: What is the Right Action about window shrinking by zero window advertisement?(tcp_input.c) 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, 21 Oct 2005 11:52:40 -0000 Hi. e.g.) pkt 1 2 3 4 5 6 sent(snd_wnd=3D6) receiver sent ACK 2 with snd_wnd=3D0(pkt 1 received successfully) because rcv buffer is full, pkt 2,3,4, dropped. sender go into persist mode. when pkt 5, 6 arrived, rcv buffer is now empty. So receiver send ACK2 with snd_wnd=3D4 (4 =3D 6-2 : 6 is receiver buffer size, 2 is pkt 5&6) Will sender retransmit packet 2,3,4,5,6...?(without Fast Retransmit or Rtx timeout?) >From above scenario, pkt 2,3,4 dropped due to "receiver congestion" not "network congestion". Can TCP distinguish between them? > 1. (Preferred) accept the shrunk window. In this case, TCP should not > send beyond the new window RHS (SND.UNA+SND.WND-1) but should retransmit > normally up to that point. --snip-- > Setting SND.NXT to SND.UNA is a BSD implementation convenience. The RFC > does not do this. For BSD, SND.MAX contains the "old" value of SND.NXT > (I believe). SND.MAX can always be used to distinguish new data tx from > retx - useful for things like RTTM, some ECN updates, etc. I think above cluase means that TCP can't distinguish. And TCP assume pkt 2,3,4,5,6 is lost& retransmit.(am I right?) Thank you in advance. Subject: Re: [e2e] Question about managing window(rfc1122, 4.2.2.16) On 10/21/05, Steve Arden wrote: > (off-list reply) > > Hi there, > > I believe some of the confusion is because RFC1122 allows two broad > classes of behaviour: > > 1. (Preferred) accept the shrunk window. In this case, TCP should not > send beyond the new window RHS (SND.UNA+SND.WND-1) but should retransmit > normally up to that point. > > 2. Ignore the shrunk window and keep the old window RHS. This is not > ideal but is permitted. Hence everything is SHOULD, SHOULD NOT and MAY > instead of MUST and MUST NOT. > > Because #2 is allowed, and because the window update heuristic may > filter out shrinks anyway, no TCP stack can count on window shrinks > "working". If the window is shrunk and not grown again, the connection > may timeout. > > Roughly speaking, the only real obligation for a sending TCP is not to > crash, and to eventually recover if the window reopens before timeout > occurs. > > > >RFC1122 > > >However, a sending TCP MUST be robust against window shrinking, which > > may >cause the "useable window" (see Section 4.2.3.4) to become > > negative. > > > > > > >If this happens, the sender SHOULD NOT send new data, > > What is the "new data"?? data beyond SND.UNA+SND.WND? > > When does sender start transmit new data? > > New data is anything that has not yet been sent, ie anything beyond > SND.NXT (or SND.MAX depending on the implementation). > > Keep in mind that Stevens, especially vol2, documents the BSD TCP > implementation not the standards. BSD differs from the standards > occasionally for implementation convenience. > > In the case of window shrinks and retransmits, BSD adjust SND.NXT back > to the window limit or the next byte to retransmit. It records the high > watermark in SND.MAX. The RFCs (at least up to 2581) do not do this. > They leave SND.NXT at the highest byte sent. > > This is exactly equivelant, only the variables are defined differently. > So if the RFCs refer to SND.NXT, the BSD equivelant is SND.MAX in some > situations. > > > >but SHOULD retransmit normally the old unacknowledged data > > >between SND.UNA and SND.UNA+SND.WND. > > >The sender MAY also retransmit old data beyond SND.UNA+SND.WND, but > > >SHOULD NOT time out the connection if data beyond the right window > > edge > > >is not acknowledged. If the window shrinks to zero, the TCP > > >MUST probe it in the standard way (see next Section). > > > > Does above cluase mean that TCP can transmit data "before" probing or > > going to persist mode?? > > > > If it is(transmit some pkts before probing), how it can be possible? > > SND.WND is already 0, isn't it? > > No, it does not send packets then probe (well actually that is not > prohibited but it does not make sense). > > The intend (for the preferred behaviour - #1 above) is that TCP either > probes or retransmits data based on the new window. If the window has > shrunk to zero it probes. If it has shrunk (below SND.NXT) but is > non-zero, it should stop sending new data and should retransmit data up > to the new window as timeouts occur. > > This text: > The sender MAY also retransmit old data beyond SND.UNA+SND.WND, > but SHOULD NOT time out the connection if data beyond the right > window edge is not acknowledged. > is there to allow the (non-preferred) behaviour of ignoring the window > shrink (#2 above). > > > If it It isn't, what is the old unacknowledged data? > > TCP already set SND.NXT to SND.UNA. And I think TCP can't distinguish i= t. > > Setting SND.NXT to SND.UNA is a BSD implementation convenience. The RFC > does not do this. For BSD, SND.MAX contains the "old" value of SND.NXT > (I believe). SND.MAX can always be used to distinguish new data tx from > retx - useful for things like RTTM, some ECN updates, etc. > > > Hope this helps. > > -- > > Steve Arden > Neterion Corporation > steve.arden@neterion.com > > > -- cys From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 12:56:01 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F44916A420; Fri, 21 Oct 2005 12:56:01 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5EA743D8B; Fri, 21 Oct 2005 12:55:26 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1ESwQA-0002ei-C2; Fri, 21 Oct 2005 14:54:55 +0200 Date: Fri, 21 Oct 2005 14:55:23 +0200 From: Marcin Jessa To: Message-Id: <20051021145523.097758f5.lists@yazzy.org> In-Reply-To: <002801c5d634$fdc66bd0$42764eca@ilo.skyinet.net> References: <20051019235111.2225345e.lists@yazzy.org> <20051020070145.GA59364@cell.sick.ru> <20051020131549.5e432073.lists@yazzy.org> <20051020123159.33f6fa33.lists@yazzy.org> <07c501c5d5e1$0ddf67f0$42764eca@ilo.skyinet.net> <20051021112934.7c857fcc.lists@yazzy.org> <002801c5d634$fdc66bd0$42764eca@ilo.skyinet.net> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) Cc: glebius@FreeBSD.org, current@FreeBSD.org, net@FreeBSD.org Subject: Re: PPPoE and Radius on 6.0RC1 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, 21 Oct 2005 12:56:01 -0000 On Fri, 21 Oct 2005 19:45:52 +0800 wrote: > ----- Original Message ----- > From: "Marcin Jessa" > To: > Cc: ; ; > Sent: Friday, October 21, 2005 5:29 PM > Subject: Re: PPPoE and Radius on 6.0RC1 > > > > The problem seems to be ppp is never started by pppoe. > > here is a sample configuration for your pppoe server.... assuming you > have two intel nics named fxp0 and fxp1... fxp0 is facing the net and > fxp1 is facing the pppoe clients... fxp1 is ip less... > > please do the following... > > 1. in your kernel config file, add the following options and compile > the kernel > > options NETGRAPH > options NETGRAPH_ETHER > options NETGRAPH_PPPOE > options NETGRAPH_SOCKET > > 2. in your /etc/rc.conf > > gateway_enable="YES" > ifconfig_fxp0="inet 192.168.2.8 netmask 255.255.255.0" > ifconfig_fxp1="up" > pppoed_enable="YES" > pppoed_flags="-l PPPoE -P /var/run/pppoed.pid" > pppoed_interface="fxp1" > > 3. in your /etc/ppp/ppp.conf > > default: > set log Phase Chat LCP IPCP CCP tun command Debug Radius > ident user-ppp VERSION (built COMPILATIONDATE) > > PPPoE: > set ifaddr 192.168.2.8 192.168.2.100-192.168.2.120 255.255.255.255 > set radius /etc/ppp/radius.conf > set dns 192.168.2.45 > deny deflate > disable deflate > accept dns > enable lqr > enable echo > deny pap > deny chap > deny LANMan > deny MSChap > enable MSChapV2 > disable pred1 > disable utmp > disable ipv6cp > set callback > set cbcp > set cd 5! > set nbns > set speed sync > set timeout 0 > > 4. in your /etc/ppp/radius.conf > > auth 127.0.0.1:1812 secret_key 3 3 > acct 127.0.0.1:1813 secret_key 3 3 > > try to remark "set radius /etc/ppp/radius.conf" first > in /etc/ppp/ppp.conf to make sure that your pppoe authentication is > working without using a radius server... if all went well, then make > sure your radius server is working properly by binding to ip address > 127.0.0.1 only for security purposes... Thanks a lot. I recompiled my kernel with the netgraph options and set up the server with your configs. Besides from the fact that I only use my fxp0 in the tests. root 787 0.0 0.1 1256 796 ?? Ss 2:41PM 0:00.02 /usr/libexec/pppoed -l PPPoE -P /var/run/pppoed.pid -p * fxp0 I disabled radius as well adding username and password by hand. Although the radius itself works fine when I test it with radtest and user's credits. Just like before, nothing gets loged in ppp.log and the ppp process itself never gets started up by the pppoe daemon. "on receipt of the SUCCESS indication, pppoed will execute exec /usr/sbin/ppp -direct label" - This part is not taking place.... Marcin. From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 22:34:04 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECFF816A41F for ; Fri, 21 Oct 2005 22:34:04 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from pleiades.aeternal.net (pleiades.in.markiza.sk [62.168.76.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8894843D45 for ; Fri, 21 Oct 2005 22:34:04 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: by pleiades.aeternal.net (Postfix, from userid 1001) id 361E011444; Sat, 22 Oct 2005 00:34:05 +0200 (CEST) Date: Sat, 22 Oct 2005 00:34:05 +0200 From: martin hudec To: freebsd-net@freebsd.org Message-ID: <20051021223405.GJ944@pleiades.aeternal.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xGGVyNQdqA79rdfn" Content-Disposition: inline X-Copyright: (C) 2005 Martin Hudec X-Operating-System: FreeBSD pleiades.aeternal.net 7.0-CURRENT i386 X-PGP-Key: http://www.aeternal.net/corwin_aeternal.asc User-Agent: mutt-ng/devel-r535 (FreeBSD) Subject: trunk(4) feature on FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin hudec List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 22:34:05 -0000 --xGGVyNQdqA79rdfn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, I am just curious, I know that linux has bonding feature to make network cards aggregation, now it is being implemented into upcoming OpenBSD 3.8 - does FreeBSD has something similar? cheers, Martin --=20 martin hudec * 421 907 303 393 * corwin@aeternal.net * http://www.aeternal.net "Nothing travels faster than the speed of light with the possible=20 exception of bad news, which obeys its own special laws." Douglas Adams, "The Hitchhiker's Guide to the Galaxy" --xGGVyNQdqA79rdfn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDWWzdZYEZIv+rgggRArERAJoCLkV8TbC9SErBIqA1nxP8PrhZMgCfWXZX OI2J5jh6zI8Vz12MBlXRmic= =4Z9g -----END PGP SIGNATURE----- --xGGVyNQdqA79rdfn-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 23:58:00 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B49016A41F for ; Fri, 21 Oct 2005 23:58:00 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from pleiades.aeternal.net (pleiades.in.markiza.sk [62.168.76.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9BE743D45 for ; Fri, 21 Oct 2005 23:57:59 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: by pleiades.aeternal.net (Postfix, from userid 1001) id 2F78511444; Sat, 22 Oct 2005 01:58:00 +0200 (CEST) Date: Sat, 22 Oct 2005 01:58:00 +0200 From: martin hudec To: freebsd-net@freebsd.org Message-ID: <20051021235800.GL944@pleiades.aeternal.net> References: <20051021223405.GJ944@pleiades.aeternal.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="73fGQZLCrFzENemP" Content-Disposition: inline In-Reply-To: <20051021223405.GJ944@pleiades.aeternal.net> X-Copyright: (C) 2005 Martin Hudec X-Operating-System: FreeBSD pleiades.aeternal.net 7.0-CURRENT i386 X-PGP-Key: http://www.aeternal.net/corwin_aeternal.asc User-Agent: mutt-ng/devel-r535 (FreeBSD) Subject: Re: trunk(4) feature on FreeBSD? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin hudec List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 23:58:00 -0000 --73fGQZLCrFzENemP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, On Sat, Oct 22, 2005 at 12:34:05AM +0200 or thereabouts, martin hudec wrote: > I am just curious, I know that linux has bonding feature to make > network cards aggregation, now it is being implemented into upcoming > OpenBSD 3.8 - does FreeBSD has something similar? Well, found out this: man 4 ng_one2many. have a nice weekend, Martin --=20 martin hudec * 421 907 303 393 * corwin@aeternal.net * http://www.aeternal.net "Nothing travels faster than the speed of light with the possible=20 exception of bad news, which obeys its own special laws." Douglas Adams, "The Hitchhiker's Guide to the Galaxy" --73fGQZLCrFzENemP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDWYCIZYEZIv+rgggRAjjMAJ4ks5pEwRf4tTPndCf5vi8L7m+1sgCdFa2B evPiurK83wdmmqcTGyQ2/Yk= =bXXR -----END PGP SIGNATURE----- --73fGQZLCrFzENemP-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 00:32:53 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE66116A41F for ; Sat, 22 Oct 2005 00:32:53 +0000 (GMT) (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 8C14E43D45 for ; Sat, 22 Oct 2005 00:32:53 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j9M0Wfkd027568; Fri, 21 Oct 2005 17:32:41 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j9M0WeBI027567; Fri, 21 Oct 2005 17:32:40 -0700 (PDT) (envelope-from jmg) Date: Fri, 21 Oct 2005 17:32:39 -0700 From: John-Mark Gurney To: martin hudec Message-ID: <20051022003239.GA4115@funkthat.com> Mail-Followup-To: martin hudec , freebsd-net@freebsd.org References: <20051021223405.GJ944@pleiades.aeternal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051021223405.GJ944@pleiades.aeternal.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 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 Cc: freebsd-net@freebsd.org Subject: Re: trunk(4) feature on FreeBSD? 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: Sat, 22 Oct 2005 00:32:54 -0000 martin hudec wrote this message on Sat, Oct 22, 2005 at 00:34 +0200: > I am just curious, I know that linux has bonding feature to make > network cards aggregation, now it is being implemented into upcoming > OpenBSD 3.8 - does FreeBSD has something similar? You should look at ng_fec(4) also.. This will make it possible to connect to switches that allow you to trunk... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 09:01:28 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D30416A41F; Sat, 22 Oct 2005 09:01:28 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2092743D49; Sat, 22 Oct 2005 09:01:27 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 0DCEC4D0AA; Sat, 22 Oct 2005 09:01:46 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 347E74CFE1; Sat, 22 Oct 2005 09:01:43 +0000 (GMT) Message-ID: <4359FFE3.7060001@roq.com> Date: Sat, 22 Oct 2005 19:01:23 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20051020140200.GL59364@cell.sick.ru> In-Reply-To: <20051020140200.GL59364@cell.sick.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: net@FreeBSD.org Subject: Re: em(4) patch for test 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, 22 Oct 2005 09:01:28 -0000 Gleb Smirnoff wrote: > Colleagues, > > since the if_em problem was taken as a late showstopper for 6.0-RELEASE, >I am asking you to help with testing of the fixes made in HEAD. > > Does your em(4) interface wedge for some time? > Do you see a lot of errors in 'netstat -i' output? Does these errors > increase not monotonously but they have peaks? > >If the answer is yes, then the attached patch is likely to fix your problem. >If the answer is no, then you are still encouraged to help with testing >and install the patch to check that no regressions are introduced. If you >skip this, then you may encounter regressions after release, so you have >been warned. > > So, in short: please test! Thanks in advance! > >The patch is against fresh RELENG_6. > > Here are some results with my testing A-B-C network. This round of tests was largely focused on my gateway (B) which has 4 em built-in gigabit ether devices with polling and packet filter enabled. Server A and B are Dells 1850 6.0RC1 AMD64, Server C Dell 2850 6.0RC1 i386 I have pushed through many gigs of traffic through B's 2 interfaces using netperf and 'fetch' tests of large files. I have yet to see any errors before patching or after patching on the gateway. But after I finished testing I checked netstat -i and I have errors on my client (A) and server (B) machines which appear to be caused by earlier testing I was doing using Apache benchmark 'ab' so I am going to start testing them. Using the netperf and 'fetch' tests have appeared to never budge any Oerrs or Ierrs stats on any of the machines. After patch. B> netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0* 1500 00:0e:0c:f3:d4:f2 0 0 0 0 0 em1* 1500 00:0e:0c:f3:d4:f3 0 0 0 0 0 em2 1500 00:14:22:f5:ff:4b 39887301 0 24145946 0 0 em3 1500 00:14:22:f5:ff:4c 24144573 0 39885777 0 0 Before patch . B> netstat -i | grep "Link" em0* 1500 00:0e:0c:f3:d4:f2 0 0 0 0 0 em1* 1500 00:0e:0c:f3:d4:f3 0 0 0 0 0 em2 1500 00:14:22:f5:ff:4b 67671693 0 51036449 0 0 em3 1500 00:14:22:f5:ff:4c 49964821 0 65868324 0 0 Client test machine (A) and server machine (C) yet to be patched does have Ierrs errors but not many, the other thing to note that doing the benchmarks netperf and 'fetct' tests listed below (done repeatedly) never made these error stats budge at all. It turns out it was caused by some tests I was doing on these machines a day earlier using apache 'ab' tests which have been really beating up the servers quite well, this being 'A> ab -k -n 19000 -c 1500 http://server-c/133kbyte_file' . I will post some results after this email. Using this test. A> netstat -i | egrep 'em2.*Link|Name' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em2 1500 00:14:ff:15:ff:8e 225763513 5025 311375238 0 0 C> netstat -i | egrep 'em0.*Link|Name' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:14:ff:12:4c:03 347060671 13317 251444959 0 0 Tests used and benchmark results using the netperf and fetch tests. Interestingly it appears to be benchmarking a tiny bit faster after patching, I am I believe its just been luck of the draw testing. A> fetch -o - > /dev/null http://server-C/file1gig.iso A> /usr/local/netperf/netperf -l 60 -H server-C -t TCP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 57344 -S 57344 Before patch Fetch test: 84 MBps Netperf Elapsed Throughput - 10^6bits/sec: 905.77 After patch Fetch test: 85 MBps Netperf Elapsed Throughput - 10^6bits/sec: 909.60 Before patch B> netstat -s tcp: 1070840 packets sent 55362 data packets (7666434 bytes) 183 data packets (189863 bytes) retransmitted 3 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 733560 ack-only packets (178 delayed) 0 URG only packets 0 window probe packets 281674 window update packets 62 control packets 1791219 packets received 53340 acks (for 7668053 bytes) 512 duplicate acks 0 acks for unsent data 1738233 packets (2511401694 bytes) received in-sequence 102 completely duplicate packets (83167 bytes) 0 old duplicate packets 9 packets with some dup. data (5184 bytes duped) 564 out-of-order packets (610315 bytes) 1 packet (0 bytes) of data after window 0 window probes 186 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 13 connection requests 32 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 40 connections established (including accepts) 65 connections closed (including 9 drops) 29 connections updated cached RTT on close 29 connections updated cached RTT variance on close 10 connections updated cached ssthresh on close 5 embryonic connections dropped 53197 segments updated rtt (of 52242 attempts) 113 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 32 keepalive timeouts 29 keepalive probes sent 3 connections dropped by keepalive 434 correct ACK header predictions 1735955 correct data packet header predictions 35 syncache entries added 11 retransmitted 0 dupsyn 0 dropped 32 completed 0 bucket overflow 0 cache overflow 0 reset 3 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 42 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 945 SACK options (SACK blocks) received 666 SACK options (SACK blocks) sent 0 SACK scoreboard overflow udp: 293 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 9 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 0 not for hashed pcb 284 delivered 293 datagrams output ip: 117631875 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 1791512 packets for this host 5 packets for unknown/unsupported protocol 115833063 packets forwarded (115833063 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 1071192 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header Netstat -s results: After patch netstat -s tcp: 3262 packets sent 2299 data packets (2248857 bytes) 215 data packets (239291 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 637 ack-only packets (123 delayed) 0 URG only packets 0 window probe packets 106 window update packets 5 control packets 3046 packets received 1409 acks (for 2253418 bytes) 291 duplicate acks 0 acks for unsent data 1251 packets (877028 bytes) received in-sequence 81 completely duplicate packets (60076 bytes) 2 old duplicate packets 10 packets with some dup. data (7621 bytes duped) 475 out-of-order packets (505701 bytes) 0 packets (0 bytes) of data after window 0 window probes 135 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 3 connection requests 1 connection accept 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 4 connections established (including accepts) 4 connections closed (including 0 drops) 1 connection updated cached RTT on close 1 connection updated cached RTT variance on close 1 connection updated cached ssthresh on close 0 embryonic connections dropped 1409 segments updated rtt (of 1211 attempts) 84 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 65 correct ACK header predictions 595 correct data packet header predictions 1 syncache entrie added 0 retransmitted 0 dupsyn 0 dropped 1 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 0 cookies sent 0 cookies received 33 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 623 SACK options (SACK blocks) received 663 SACK options (SACK blocks) sent 0 SACK scoreboard overflow udp: 33 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to full socket buffers 0 not for hashed pcb 33 delivered 33 datagrams output ip: 64033566 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 3079 packets for this host 0 packets for unknown/unsupported protocol 64030433 packets forwarded (64030433 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 3295 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 09:19:10 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0525716A41F for ; Sat, 22 Oct 2005 09:19:10 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CDF343D55 for ; Sat, 22 Oct 2005 09:19:08 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9M9J6Sj032575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Oct 2005 13:19:06 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9M9J6pX032574; Sat, 22 Oct 2005 13:19:06 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 22 Oct 2005 13:19:05 +0400 From: Gleb Smirnoff To: Michael VInce Message-ID: <20051022091905.GH59364@cell.sick.ru> References: <20051020140200.GL59364@cell.sick.ru> <4359FFE3.7060001@roq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4359FFE3.7060001@roq.com> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: em(4) patch for test 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, 22 Oct 2005 09:19:10 -0000 Michael, big thanks for a very detailed report! On your next test round, can you please also keep an eye on the CPU load. Is it increased measurably by the patch or not. Thanks again! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 10:13:50 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22B4216A420 for ; Sat, 22 Oct 2005 10:13:50 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B65343D5E for ; Sat, 22 Oct 2005 10:13:46 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j9MAWjaq026131; Sat, 22 Oct 2005 10:32:45 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j9MAWggQ026130; Sat, 22 Oct 2005 10:32:42 GMT (envelope-from dunstan) Date: Sat, 22 Oct 2005 10:32:41 +0000 From: "Wojciech A. Koszek" To: Brooks Davis Message-ID: <20051022103240.GA26108@freebsd.czest.pl> References: <20051020202034.GA4556@freebsd.czest.pl> <20051020202544.GC18840@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051020202544.GC18840@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@FreeBSD.org Subject: Re: Dependency between interfaces 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, 22 Oct 2005 10:13:50 -0000 On Thu, Oct 20, 2005 at 01:25:44PM -0700, Brooks Davis wrote: > On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > > Hello, > > > > Is EVENTHANDLER(9) proper way of notification for standalone driver about > > network interface attach/detach operations? I've met simple problem in > > ef(4), which causes machine freeze in following situation: load NIC driver > > -> load if_ef -> unload NIC driver -> some activity with interface. > > Althought driver of network interface no longer exists, if_ef does not know > > about it and continues it's operation. > > > > I've seen similar situation for example in ng_fec(4): piece of code needs to > > call some cleanup routines in order to keep pointers in valid state. I think > > this situation is almost the same like this current in if_bridge(4). Just > > repeat situation described above for ef(4), but with if_bridge(4). > > It looks like you could hook into the ifnet_departure_event pretty > easily. The one gotcha is that it's called during interface renames so > you need to consider that possibility. > Yes, I know. I just wanted to know is it proper solution. I'll try to fix it, once I finish updating my patch for locking in ef(4). Thanks, -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 10:15:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2F1916A41F; Sat, 22 Oct 2005 10:15:07 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E986B43D48; Sat, 22 Oct 2005 10:15:06 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j9MAY6aq026168; Sat, 22 Oct 2005 10:34:06 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j9MAY588026167; Sat, 22 Oct 2005 10:34:05 GMT (envelope-from dunstan) Date: Sat, 22 Oct 2005 10:34:05 +0000 From: "Wojciech A. Koszek" To: Andrew Thompson Message-ID: <20051022103404.GA26148@freebsd.czest.pl> References: <20051020202034.GA4556@freebsd.czest.pl> <20051020202327.GA53753@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051020202327.GA53753@heff.fud.org.nz> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Dependency between interfaces 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, 22 Oct 2005 10:15:08 -0000 On Fri, Oct 21, 2005 at 09:23:27AM +1300, Andrew Thompson wrote: > On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > > Hello, > > > > Is EVENTHANDLER(9) proper way of notification for standalone driver about > > network interface attach/detach operations? I've met simple problem in > > ef(4), which causes machine freeze in following situation: load NIC driver > > -> load if_ef -> unload NIC driver -> some activity with interface. > > Althought driver of network interface no longer exists, if_ef does not know > > about it and continues it's operation. > > > > I've seen similar situation for example in ng_fec(4): piece of code needs to > > call some cleanup routines in order to keep pointers in valid state. I think > > this situation is almost the same like this current in if_bridge(4). Just > > repeat situation described above for ef(4), but with if_bridge(4). > > > > if_bridge(4) now hooks into ether_detach to get notified of a vanishing > interface, as of r1.26 (and now in RELENG_6*) > > Use bridge_ifdetach() to notify the bridge that a member has been > detached. The bridge can then remove it from its interface list and > not try to send out via a dead pointer. > > Is it still a problem or did you test on a pre r1.26 kernel? > Thanks, it seems to work just fine. I've tested it with earlier versions. I'll probably have to play with EVENTHANDLER to fix ef(4). -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 10:38:35 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B66516A41F for ; Sat, 22 Oct 2005 10:38:35 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id F11E243D45 for ; Sat, 22 Oct 2005 10:38:34 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9MAcWa8033097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Oct 2005 14:38:32 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9MAcVwo033096; Sat, 22 Oct 2005 14:38:31 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sat, 22 Oct 2005 14:38:31 +0400 From: Gleb Smirnoff To: Chris Dionissopoulos Message-ID: <20051022103831.GI59364@cell.sick.ru> References: <4353765C.4030802@freemail.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4353765C.4030802@freemail.gr> User-Agent: Mutt/1.5.6i Cc: net@FreeBSD.org Subject: Re: What's wrong with netgraph NG_FWD_NEW_DATA? 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, 22 Oct 2005 10:38:35 -0000 On Mon, Oct 17, 2005 at 01:01:00PM +0300, Chris Dionissopoulos wrote: C> Trying to split inbound traffic based on layer2 characteristics, C> i have create a new netgraph module(ng_l2split) using C> ng_vlan(4) as reference. The design and implementation is C> pretty simple as ng_vlan : C> C> xl0:upper C> | C> +---------+ C> | ng_l2split|-----ng0 (ng_eiface on ngeth0) C> +---------+ ( --- ng1,2,....) C> | C> xl0:lower C> C> ng_l2plit has 2 basic hooks as descriped in ng_vlan(4) man page: C> - downstream hook (attached to physical's "lower" ) C> - nomatch hook (attached to physical's "upper" ) C> C> and for every ng_eiface node you attach you must provide a C> mac address for filtering (later this will be automated). Uhmm, wouldn't it be simplier to use ng_bridge? ,-- ngeth0 (with MAC address X) / xl0:lower -- bridge \ `-- ngeth1 (with MAC address Y) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 10:57:31 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D9DC16A41F; Sat, 22 Oct 2005 10:57:31 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from mail.helenmarks.co.uk (82-68-196-20.dsl.in-addr.zen.co.uk [82.68.196.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id E86DB43D48; Sat, 22 Oct 2005 10:57:30 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 0B7B81710F; Sat, 22 Oct 2005 11:57:25 +0100 (BST) Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72130-09; Sat, 22 Oct 2005 11:57:20 +0100 (BST) Received: from egg (egg.helenmarks.co.uk [192.168.15.3]) by mail.helenmarks.co.uk (Postfix) with ESMTP id 624DF1710E; Sat, 22 Oct 2005 11:57:20 +0100 (BST) From: Dominic Marks To: Gleb Smirnoff Date: Sat, 22 Oct 2005 12:02:38 +0100 User-Agent: KMail/1.8 References: <3100.195.12.22.194.1129814959.squirrel@www.helenmarks.co.uk> <20051020135606.GK59364@cell.sick.ru> In-Reply-To: <20051020135606.GK59364@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510221202.39489.dom@goodforbusiness.co.uk> X-Virus-Scanned: By ClamAV 0.85.1 Cc: freebsd-net@freebsd.org, Dominic Marks Subject: Re: mpd disconnect due to LCP echo not responding 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, 22 Oct 2005 10:57:31 -0000 On Thursday 20 October 2005 14:56, Gleb Smirnoff wrote: > Dominic, > > On Thu, Oct 20, 2005 at 02:29:19PM +0100, Dominic Marks wrote: > D> server) in to the Office. Some times when the link is busy the LCP > echos D> won't pass over the link quickly enough and the connection > will terminate. D> > D> Is there anything I can do to prevent this, or at least make it > less D> likely to happen. Options I have thought of are: > D> > D> Increasing the number of echos mpd waits before disconnecting. > D> Increasing the time out for LCP echos. > > So have you tried the two above options or are they not configurable > in mpd? I haven't looked yet, I was just taking a sounding to see if others had already investigated the issue. Next week I'll be looking into it. Thanks, > D> Using traffic shaping to prioritise the LCP traffic over other > traffic. D> > D> Are any of these possible, or is there another way of acheiving > the same D> goal? > D> > D> Some example log output: > D> > D> Oct 19 15:18:38 billy mpd: [ng5] LCP: no reply to 1 echo > request(s) D> Oct 19 15:18:48 billy mpd: [ng5] LCP: no reply to 2 > echo request(s) D> Oct 19 15:18:58 billy mpd: [ng5] LCP: no reply to > 3 echo request(s) D> Oct 19 15:19:08 billy mpd: [ng5] LCP: no reply > to 4 echo request(s) D> Oct 19 15:19:18 billy mpd: [ng5] LCP: no > reply to 5 echo request(s) D> Oct 19 15:19:18 billy mpd: [ng5] LCP: > peer not responding to echo requests D> > D> Thanks, > D> Dominic Marks > D> _______________________________________________ > D> freebsd-net@freebsd.org mailing list > D> http://lists.freebsd.org/mailman/listinfo/freebsd-net > D> To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" -- Dominic Marks From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 13:18:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2159016A41F; Sat, 22 Oct 2005 13:18:40 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D01743D46; Sat, 22 Oct 2005 13:18:39 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j9MDbbaq026673; Sat, 22 Oct 2005 13:37:38 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j9MDbbGP026672; Sat, 22 Oct 2005 13:37:37 GMT (envelope-from dunstan) Date: Sat, 22 Oct 2005 13:37:35 +0000 From: "Wojciech A. Koszek" To: Andrew Thompson Message-ID: <20051022133735.GA26636@freebsd.czest.pl> References: <20051020202034.GA4556@freebsd.czest.pl> <20051020202327.GA53753@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051020202327.GA53753@heff.fud.org.nz> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Dependency between interfaces 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, 22 Oct 2005 13:18:40 -0000 On Fri, Oct 21, 2005 at 09:23:27AM +1300, Andrew Thompson wrote: > On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > > Hello, > > [..] > > Is it still a problem or did you test on a pre r1.26 kernel? > Results from -CURRENT: I got panic if sk/rl modules are loaded, interfaces added to bridge0 and these drivers kldunload(8)ed: http://freebsd.czest.pl/dunstan/FreeBSD/bridge_rl.trace http://freebsd.czest.pl/dunstan/FreeBSD/bridge_sk.trace Also vlan(4) has similar problems: http://freebsd.czest.pl/dunstan/FreeBSD/vlan_sk dunstan@dunstan:(/usr/src/sys/net)$ grep FreeBSD * | egrep 'if_(clone|vlan|bridge)' if_bridge.c:__FBSDID("$FreeBSD: src/sys/net/if_bridge.c,v 1.29 2005/10/14 20:57:02 thompsa Exp $"); if_bridgevar.h: * $FreeBSD: src/sys/net/if_bridgevar.h,v 1.5 2005/10/14 02:38:47 thompsa Exp $ if_clone.c: * $FreeBSD: src/sys/net/if_clone.c,v 1.7 2005/10/12 19:52:16 thompsa Exp $ if_clone.h: * $FreeBSD: src/sys/net/if_clone.h,v 1.2 2005/01/07 01:45:34 imp Exp $ if_vlan.c: * $FreeBSD: src/sys/net/if_vlan.c,v 1.88 2005/10/03 02:24:21 yar Exp $ if_vlan_var.h: * $FreeBSD: src/sys/net/if_vlan_var.h,v 1.22 2005/08/31 11:36:50 yar Exp $ -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 14:44:37 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D97A916A41F for ; Sat, 22 Oct 2005 14:44:37 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DB3543D60 for ; Sat, 22 Oct 2005 14:44:31 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: pass (tce71.tce85.de: domain of vwsoft.com designates 84.245.164.24 as permitted sender) client-ip=84.245.164.24; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (unknown [84.245.164.24]) by tce71.tce85.de (Postfix) with ESMTP id 2AD6117122 for ; Sat, 22 Oct 2005 16:44:35 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 0A5515C0E for ; Sat, 22 Oct 2005 16:41:13 +0200 (CEST) Message-ID: <435A5D9B.7080309@vwsoft.com> Date: Sat, 22 Oct 2005 16:41:15 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Subject: IPSec tcp session stalling 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, 22 Oct 2005 14:44:38 -0000 Still having the same problem with an IPSec tunnel between FreeBSD 5.4R hosts. Problem description: scp session tries to transfer a large file through an IPSec tunnel. The file is being transmitted but scp says 'stalled' after 56K (49152 bytes file size). The IPSec tunnel itself is still up even after the scp abort. Other tcp sessions break, too when sending too much traffic through the tunnel. I've taken a closer look to it and tried to get something useful out of the tcpdump but I'm unable to see any errors or I'm misinterpreting something. The connection looks like: extIP: A.B.C.D extIP: E.F.G.H host A ------------------ (internet) ------------------ host B tunnelIP: 10.128.1.6 tunnelIP: 10.128.6.1 host A just has an external interface (em1) connected to a leased line with a fixed IP address (IP-addr A.B.C.D). host B has an S-DSL connection at xl0, PPPoE at ng0 (IP-addr. E.F.G.H). Both hosts are using gif for the IPSec tunnel. The routing tables (netstat -rnWf inet) are looking good and IMHO the MTU is fine. host A: em1: flags=8843 mtu 1500 options=b inet A.B.C.D netmask 0xfffffff8 broadcast A.B.C.z ether 00:c0:9f:46:ec:c7 media: Ethernet autoselect (100baseTX ) status: active gif6: flags=8051 mtu 1280 tunnel inet A.B.C.D --> E.F.G.H inet 10.128.1.6 --> 10.128.6.1 netmask 0xffffffff inet6 fe80::2c0:9fff:fe46:ecc6%gif6 prefixlen 64 scopeid 0x4 Routing tables (shortened) Destination Gateway Flags Refs Use Mtu Netif Expire default A.B.C.x UGS 2 516686 1500 em1 10.128.1.6 127.0.0.1 UH 0 14 16384 lo0 10.128.6.1 10.128.1.6 UH 0 6017 1280 gif6 127.0.0.1 127.0.0.1 UH 0 31633 16384 lo0 A.B.C.x/29 link#2 UC 0 0 1500 em1 A.B.C.D 00:c0:9f:46:ec:c7 UHLW 0 112 1500 lo0 On host B the interfaces and routing tables are looking like: xl0: flags=8843 mtu 1500 options=8 inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255 inet6 fe80::260:8ff:fe6c:e73c%xl0 prefixlen 64 scopeid 0x1 ether 00:60:08:6c:e7:3c media: Ethernet 10baseT/UTP (10baseT/UTP ) status: active gif1: flags=8051 mtu 1280 tunnel inet E.F.G.H --> A.B.C.D inet6 fe80::260:8ff:fe6c:e73c%gif1 prefixlen 64 scopeid 0x4 inet 10.128.6.1 --> 10.128.1.6 netmask 0xffffffff ng0: flags=88d1 mtu 1456 inet E.F.G.H --> 217.5.98.186 netmask 0xffffffff Routing tables (shortened) Destination Gateway Flags Refs Use Mtu Netif Expire 0 link#1 UC 0 0 1500 xl0 => default 217.5.98.186 UGS 1 38474 1456 ng0 10.128.1.6 10.128.6.1 UH 4 2196 1280 gif1 127.0.0.1 127.0.0.1 UH 0 80424 16384 lo0 217.5.98.186 E.F.G.H UH 1 0 1456 ng0 E.F.G.H lo0 UHS 0 0 16384 lo0 While trying to fetch a file by scp on host A (receiver) from host B (sender), I captured the following tcpdump on host B: tcpdump -netttvvi gif1: > 000023 AF 2 1280: IP (tos 0x8, ttl 64, id 13202, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 43864:45092(1228) ack 1330 win 33156 > 000207 AF 2 1280: IP (tos 0x8, ttl 64, id 52187, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 45092:46320(1228) ack 1330 win 33156 > 000220 AF 2 1280: IP (tos 0x8, ttl 64, id 33774, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 46320:47548(1228) ack 1330 win 33156 > 003524 AF 2 52: IP (tos 0x8, ttl 64, id 42063, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 38952 win 33156 > 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 48541, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 47548:48776(1228) ack 1330 win 33156 > 011203 AF 2 52: IP (tos 0x8, ttl 64, id 60517, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 41408 win 32542 > 000058 AF 2 1280: IP (tos 0x8, ttl 64, id 15798, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 48776:50004(1228) ack 1330 win 33156 > 000246 AF 2 1280: IP (tos 0x8, ttl 64, id 31721, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 50004:51232(1228) ack 1330 win 33156 > 005147 AF 2 52: IP (tos 0x8, ttl 64, id 22347, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 42636 win 33156 > 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 61057, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 51232:52460(1228) ack 1330 win 33156 > 020769 AF 2 52: IP (tos 0x8, ttl 64, id 27692, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 45092 win 32542 > 000027 AF 2 1280: IP (tos 0x8, ttl 64, id 64167, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 52460:53688(1228) ack 1330 win 33156 > 000209 AF 2 1280: IP (tos 0x8, ttl 64, id 45457, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 53688:54916(1228) ack 1330 win 33156 > 005260 AF 2 52: IP (tos 0x8, ttl 64, id 53832, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 46320 win 33156 > 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 3515, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 54916:56144(1228) ack 1330 win 33156 > 011020 AF 2 52: IP (tos 0x8, ttl 64, id 11608, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 48776 win 32542 > 000026 AF 2 1280: IP (tos 0x8, ttl 64, id 5848, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 56144:57372(1228) ack 1330 win 33156 > 000211 AF 2 1280: IP (tos 0x8, ttl 64, id 39892, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 57372:58600(1228) ack 1330 win 33156 > 005641 AF 2 52: IP (tos 0x8, ttl 64, id 7943, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 50004 win 33156 > 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8678, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 58600:59828(1228) ack 1330 win 33156 > 011072 AF 2 52: IP (tos 0x8, ttl 64, id 38257, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 52460 win 32542 > 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 12255, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 59828:61056(1228) ack 1330 win 33156 > 000209 AF 2 1280: IP (tos 0x8, ttl 64, id 46257, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 61056:62284(1228) ack 1330 win 33156 > 000222 AF 2 1280: IP (tos 0x8, ttl 64, id 4093, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 62284:63512(1228) ack 1330 win 33156 > 007065 AF 2 52: IP (tos 0x8, ttl 64, id 18720, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 53688 win 33156 > 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 38378, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 63512:64740(1228) ack 1330 win 33156 > 011034 AF 2 52: IP (tos 0x8, ttl 64, id 18718, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 56144 win 32542 > 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8148, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 64740:65968(1228) ack 1330 win 33156 > 005991 AF 2 52: IP (tos 0x8, ttl 64, id 62285, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 57372 win 33156 > 010726 AF 2 52: IP (tos 0x8, ttl 64, id 1549, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 59828 win 32542 > 005670 AF 2 52: IP (tos 0x8, ttl 64, id 61504, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 61056 win 33156 > 011260 AF 2 52: IP (tos 0x8, ttl 64, id 32633, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 63512 win 32542 > 005510 AF 2 52: IP (tos 0x8, ttl 64, id 54614, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 64740 win 33156 > 104909 AF 2 52: IP (tos 0x8, ttl 64, id 50471, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 65968 win 33156 tcpdump -netttvvi ng0 host A.B.C.D: > 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 25895, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10b) > 011042 AF 2 128: IP (tos 0x8, ttl 61, id 5786, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf0) > 000226 AF 2 1352: IP (tos 0x8, ttl 64, id 36701, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10c) > 000216 AF 2 1352: IP (tos 0x8, ttl 64, id 8789, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10d) > 004853 AF 2 128: IP (tos 0x8, ttl 61, id 17128, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf1) > 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 34888, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10e) > 018747 AF 2 128: IP (tos 0x8, ttl 61, id 14828, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf2) > 000248 AF 2 1352: IP (tos 0x8, ttl 64, id 34356, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10f) > 000223 AF 2 1352: IP (tos 0x8, ttl 64, id 34151, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x110) > 005030 AF 2 128: IP (tos 0x8, ttl 61, id 45476, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf3) > 000228 AF 2 1352: IP (tos 0x8, ttl 64, id 39765, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x111) > 011247 AF 2 128: IP (tos 0x8, ttl 61, id 63692, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf4) > 000226 AF 2 1352: IP (tos 0x8, ttl 64, id 29240, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x112) > 000222 AF 2 1352: IP (tos 0x8, ttl 64, id 43306, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x113) > 005663 AF 2 128: IP (tos 0x8, ttl 61, id 32980, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf5) > 000228 AF 2 1352: IP (tos 0x8, ttl 64, id 56920, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x114) > 010190 AF 2 128: IP (tos 0x8, ttl 61, id 3206, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf6) > 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 4655, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x115) > 000215 AF 2 1352: IP (tos 0x8, ttl 64, id 62740, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x116) > 000203 AF 2 1352: IP (tos 0x8, ttl 64, id 35642, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x117) > 006875 AF 2 128: IP (tos 0x8, ttl 61, id 37801, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf7) > 000234 AF 2 1352: IP (tos 0x8, ttl 64, id 41803, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x118) > 010651 AF 2 128: IP (tos 0x8, ttl 61, id 54256, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf8) > 000235 AF 2 1352: IP (tos 0x8, ttl 64, id 30732, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x119) > 007913 AF 2 128: IP (tos 0x8, ttl 61, id 7647, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf9) > 011166 AF 2 128: IP (tos 0x8, ttl 61, id 58037, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfa) > 005483 AF 2 128: IP (tos 0x8, ttl 61, id 65275, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfb) > 011250 AF 2 128: IP (tos 0x8, ttl 61, id 47289, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfc) > 005505 AF 2 128: IP (tos 0x8, ttl 61, id 203, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfd) > 104747 AF 2 128: IP (tos 0x8, ttl 61, id 45263, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfe) > 8. 338674 AF 2 128: IP (tos 0x8, ttl 61, id 36351, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xff) > 319992 AF 2 128: IP (tos 0x8, ttl 61, id 18085, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x100) > 441837 AF 2 128: IP (tos 0x8, ttl 61, id 58323, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x101) > 684077 AF 2 128: IP (tos 0x8, ttl 61, id 35487, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x102) > 1. 167602 AF 2 128: IP (tos 0x8, ttl 61, id 34442, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x103) > 2. 136032 AF 2 128: IP (tos 0x8, ttl 61, id 8345, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x104) > 2. 984665 AF 2 128: IP (tos 0x8, ttl 61, id 35456, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x105) >From what I'm seeing host B just stops sending without any reason. At least I don't see any fragmented packets. The only thing I've seen is some packets doesn't get ack'ed by the receiver. These packets never get ack'ed: 46320:47548(1228) 50004:51232(1228) 53688:54916(1228) 57372:58600(1228) 61056:62284(1228) On host A I dumped the following: tcpdump -netttvvi gif6 > 1129985378.941282 AF 2 52: IP (tos 0x8, ttl 64, id 41637, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 45092 win 32542 > 1129985378.952628 AF 2 1280: IP (tos 0x8, ttl 64, id 14004, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 45092:46320(1228) ack 1330 win 33156 > 1129985378.952657 AF 2 52: IP (tos 0x8, ttl 64, id 23243, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 46320 win 33156 > 1129985378.958250 AF 2 1280: IP (tos 0x8, ttl 64, id 4306, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 46320:47548(1228) ack 1330 win 33156 > 1129985378.971118 AF 2 1280: IP (tos 0x8, ttl 64, id 33534, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 47548:48776(1228) ack 1330 win 33156 > 1129985378.971137 AF 2 52: IP (tos 0x8, ttl 64, id 60095, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 48776 win 32542 > 1129985378.982488 AF 2 1280: IP (tos 0x8, ttl 64, id 11459, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 48776:50004(1228) ack 1330 win 33156 > 1129985378.982516 AF 2 52: IP (tos 0x8, ttl 64, id 33184, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 50004 win 33156 > 1129985378.987989 AF 2 1280: IP (tos 0x8, ttl 64, id 54180, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 50004:51232(1228) ack 1330 win 33156 > 1129985378.994231 AF 2 1280: IP (tos 0x8, ttl 64, id 24535, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 51232:52460(1228) ack 1330 win 33156 > 1129985378.994250 AF 2 52: IP (tos 0x8, ttl 64, id 30647, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 52460 win 32542 > 1129985379.012101 AF 2 1280: IP (tos 0x8, ttl 64, id 61397, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 52460:53688(1228) ack 1330 win 33156 > 1129985379.012132 AF 2 52: IP (tos 0x8, ttl 64, id 60550, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 53688 win 33156 > 1129985379.017754 AF 2 1280: IP (tos 0x8, ttl 64, id 28408, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 53688:54916(1228) ack 1330 win 33156 > 1129985379.023720 AF 2 1280: IP (tos 0x8, ttl 64, id 27558, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 54916:56144(1228) ack 1330 win 33156 > 1129985379.023741 AF 2 52: IP (tos 0x8, ttl 64, id 21502, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 56144 win 32542 > 1129985379.035333 AF 2 1280: IP (tos 0x8, ttl 64, id 18885, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 56144:57372(1228) ack 1330 win 33156 > 1129985379.035362 AF 2 52: IP (tos 0x8, ttl 64, id 59875, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 57372 win 33156 > 1129985379.040830 AF 2 1280: IP (tos 0x8, ttl 64, id 37252, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 57372:58600(1228) ack 1330 win 33156 > 1129985379.046576 AF 2 1280: IP (tos 0x8, ttl 64, id 18349, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 58600:59828(1228) ack 1330 win 33156 > 1129985379.046595 AF 2 52: IP (tos 0x8, ttl 64, id 43697, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 59828 win 32542 > 1129985379.064961 AF 2 1280: IP (tos 0x8, ttl 64, id 38300, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 59828:61056(1228) ack 1330 win 33156 > 1129985379.064993 AF 2 52: IP (tos 0x8, ttl 64, id 47539, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 61056 win 33156 > 1129985379.070688 AF 2 1280: IP (tos 0x8, ttl 64, id 30345, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 61056:62284(1228) ack 1330 win 33156 > 1129985379.076184 AF 2 1280: IP (tos 0x8, ttl 64, id 37536, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 62284:63512(1228) ack 1330 win 33156 > 1129985379.076202 AF 2 52: IP (tos 0x8, ttl 64, id 34201, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 63512 win 32542 > 1129985379.081680 AF 2 1280: IP (tos 0x8, ttl 64, id 20637, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 63512:64740(1228) ack 1330 win 33156 > 1129985379.081709 AF 2 52: IP (tos 0x8, ttl 64, id 59866, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 64740 win 33156 > 1129985379.087678 AF 2 1280: IP (tos 0x8, ttl 64, id 35213, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 64740:65968(1228) ack 1330 win 33156 > 1129985379.186906 AF 2 52: IP (tos 0x8, ttl 64, id 2465, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 65968 win 33156 tcpdump -netttvvi em1 host E.F.G.H > 1129985379.064825 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 45003, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x3e) > 1129985379.065024 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 1195, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x2f) > 1129985379.070572 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 36820, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x3f) > 1129985379.076069 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 44971, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x40) > 1129985379.076233 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 56964, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x30) > 1129985379.081565 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 24742, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x41) > 1129985379.081741 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 9390, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x31) > 1129985379.087562 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 48065, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x42) > 1129985379.186945 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 36315, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x32) If I'm not misleaded, this also doesn't show any errors except the missing ack's. host B just stops sending. If there's an ack missing, doesn't have the sending host to just repeat the un-ack'ed packet? The IPSec tunnel does not die. Even shortly after the (scp) transfer stalls the tunnel itself is still usable (for small amounts of data). To make it more worse, when disabling pf at the senders side, the transfer works. I've tripple checked pflog for denied packets on both sides but pf didn't filter any packets out. When disabling the IPSec rules using `setkey -F; setkey -FP' on the tunnel for a moment, the scp transfer does not stall. So it's not a gif issue. It doesn't seem to be an MTU issue (pf has also the rule 'scrub in/out all no-df'), but what kind of issue is that?? Has anybody ever experienced similar things? Or am I misinterpreting the tcpdump output? Any help and hint is appreciated! Without an error message I'm lost. Volker From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 19:08:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B14B16A41F for ; Sat, 22 Oct 2005 19:08:03 +0000 (GMT) (envelope-from andy@triera.net) Received: from deliver-1.mx.triera.net (deliver-1.mx.triera.net [213.161.0.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFD0143D46 for ; Sat, 22 Oct 2005 19:08:02 +0000 (GMT) (envelope-from andy@triera.net) Received: from localhost (in-2.mx.triera.net [213.161.0.26]) by deliver-1.mx.triera.net (Postfix) with ESMTP id 315D7C095 for ; Sat, 22 Oct 2005 21:07:51 +0200 (CEST) Received: from smtp.triera.net (smtp.triera.net [213.161.0.30]) by in-2.mx.triera.net (Postfix) with SMTP id 7E93E1BC07E for ; Sat, 22 Oct 2005 21:07:55 +0200 (CEST) Received: from webmail.triera.net (scandal.triera.net [213.161.0.40]) by smtp.triera.net (Postfix) with SMTP id 057DD1A18AC for ; Sat, 22 Oct 2005 21:07:56 +0200 (CEST) MIME-Version: 1.0 X-Mailer: Triera Internet Webmail Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: Date: Sat, 22 Oct 2005 21:07:55 +0200 From: "Andy Rozman (Aleksander)" To: freebsd-net@freebsd.org X-Originating-IP: [213.161.5.51] X-Virus-Scanned: Triera AV Service Subject: Problem with firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andy@triera.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2005 19:08:03 -0000 Hi ! I am sorry to post this message here, but I think that there are a lot of gurus here, who could help me without a problem. Tilll now I was running ipfw with rule that allows all packets (from kernel) to pass through. In last few weeks I started having problems, since I got quite a lot of packets that server accepted by default. So I removed this kernel directive out, but now I have problem, that I don't know how to set rules. I have on my FreeBSD box two NICs, one for outside internet, and one for internal network, so I am using this machine as router, and as web server,... Problem is that I don't know how to set the rules so that ipfw will allow all directives from inside network to go out, and receive replies. Please send me working config. I tried several configs I found on net, but none of them seem to work... It would probably also be nice to put one working natd + ipfw confguration somewhere in handbook. Please help. Andy P.S: I applied for memebership to list, but I don't know how fast this will be procesed, so please cc to my email. From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 19:16:38 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68EB216A41F for ; Sat, 22 Oct 2005 19:16:38 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAABC43D46 for ; Sat, 22 Oct 2005 19:16:37 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 5B4C54CBA1; Sat, 22 Oct 2005 19:16:57 +0000 (GMT) Received: from [192.168.0.3] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id CB39D4CB98; Sat, 22 Oct 2005 19:16:54 +0000 (GMT) Message-ID: <435A900C.3060602@roq.com> Date: Sun, 23 Oct 2005 05:16:28 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20051019 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Volker References: <435A5D9B.7080309@vwsoft.com> In-Reply-To: <435A5D9B.7080309@vwsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling 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, 22 Oct 2005 19:16:38 -0000 Try sending different sized pings or other packet size control utils to really make sure its not MTU related. Maybe there is an upstream router thats blocking ICMP fragment packets, have you ever seen them? try forcing the creation of some. Mike Volker wrote: >Still having the same problem with an IPSec tunnel between FreeBSD 5.4R >hosts. > >Problem description: >scp session tries to transfer a large file through an IPSec tunnel. The >file is being transmitted but scp says 'stalled' after 56K (49152 bytes >file size). The IPSec tunnel itself is still up even after the scp >abort. Other tcp sessions break, too when sending too much traffic >through the tunnel. > >I've taken a closer look to it and tried to get something useful out of >the tcpdump but I'm unable to see any errors or I'm misinterpreting >something. > >The connection looks like: > >extIP: A.B.C.D >extIP: E.F.G.H >host A ------------------ (internet) ------------------ host B >tunnelIP: 10.128.1.6 tunnelIP: >10.128.6.1 > >host A just has an external interface (em1) connected to a leased line >with a fixed IP address (IP-addr A.B.C.D). >host B has an S-DSL connection at xl0, PPPoE at ng0 (IP-addr. E.F.G.H). > >Both hosts are using gif for the IPSec tunnel. > >The routing tables (netstat -rnWf inet) are looking good and IMHO the >MTU is fine. > >host A: >em1: flags=8843 mtu 1500 > options=b > inet A.B.C.D netmask 0xfffffff8 broadcast A.B.C.z > ether 00:c0:9f:46:ec:c7 > media: Ethernet autoselect (100baseTX ) > status: active >gif6: flags=8051 mtu 1280 > tunnel inet A.B.C.D --> E.F.G.H > inet 10.128.1.6 --> 10.128.6.1 netmask 0xffffffff > inet6 fe80::2c0:9fff:fe46:ecc6%gif6 prefixlen 64 scopeid 0x4 > >Routing tables (shortened) >Destination Gateway Flags Refs Use Mtu >Netif Expire >default A.B.C.x UGS 2 516686 1500 em1 >10.128.1.6 127.0.0.1 UH 0 14 16384 lo0 >10.128.6.1 10.128.1.6 UH 0 6017 1280 gif6 >127.0.0.1 127.0.0.1 UH 0 31633 16384 lo0 >A.B.C.x/29 link#2 UC 0 0 1500 em1 >A.B.C.D 00:c0:9f:46:ec:c7 UHLW 0 112 1500 lo0 > >On host B the interfaces and routing tables are looking like: >xl0: flags=8843 mtu 1500 > options=8 > inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255 > inet6 fe80::260:8ff:fe6c:e73c%xl0 prefixlen 64 scopeid 0x1 > ether 00:60:08:6c:e7:3c > media: Ethernet 10baseT/UTP (10baseT/UTP ) > status: active >gif1: flags=8051 mtu 1280 > tunnel inet E.F.G.H --> A.B.C.D > inet6 fe80::260:8ff:fe6c:e73c%gif1 prefixlen 64 scopeid 0x4 > inet 10.128.6.1 --> 10.128.1.6 netmask 0xffffffff >ng0: flags=88d1 mtu 1456 > inet E.F.G.H --> 217.5.98.186 netmask 0xffffffff > >Routing tables (shortened) >Destination Gateway Flags Refs Use Mtu >Netif Expire >0 link#1 UC 0 0 1500 > xl0 => >default 217.5.98.186 UGS 1 38474 1456 ng0 >10.128.1.6 10.128.6.1 UH 4 2196 1280 gif1 >127.0.0.1 127.0.0.1 UH 0 80424 16384 lo0 >217.5.98.186 E.F.G.H UH 1 0 1456 ng0 >E.F.G.H lo0 UHS 0 0 16384 lo0 > >While trying to fetch a file by scp on host A (receiver) from host B >(sender), I captured the following tcpdump on host B: > >tcpdump -netttvvi gif1: > > >>000023 AF 2 1280: IP (tos 0x8, ttl 64, id 13202, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 43864:45092(1228) ack 1330 win 33156 >>000207 AF 2 1280: IP (tos 0x8, ttl 64, id 52187, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 45092:46320(1228) ack 1330 win 33156 >>000220 AF 2 1280: IP (tos 0x8, ttl 64, id 33774, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 46320:47548(1228) ack 1330 win 33156 >>003524 AF 2 52: IP (tos 0x8, ttl 64, id 42063, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 38952 win 33156 >>000024 AF 2 1280: IP (tos 0x8, ttl 64, id 48541, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 47548:48776(1228) ack 1330 win 33156 >>011203 AF 2 52: IP (tos 0x8, ttl 64, id 60517, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 41408 win 32542 >>000058 AF 2 1280: IP (tos 0x8, ttl 64, id 15798, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 48776:50004(1228) ack 1330 win 33156 >>000246 AF 2 1280: IP (tos 0x8, ttl 64, id 31721, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 50004:51232(1228) ack 1330 win 33156 >>005147 AF 2 52: IP (tos 0x8, ttl 64, id 22347, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 42636 win 33156 >>000024 AF 2 1280: IP (tos 0x8, ttl 64, id 61057, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 51232:52460(1228) ack 1330 win 33156 >>020769 AF 2 52: IP (tos 0x8, ttl 64, id 27692, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 45092 win 32542 >>000027 AF 2 1280: IP (tos 0x8, ttl 64, id 64167, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 52460:53688(1228) ack 1330 win 33156 >>000209 AF 2 1280: IP (tos 0x8, ttl 64, id 45457, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 53688:54916(1228) ack 1330 win 33156 >>005260 AF 2 52: IP (tos 0x8, ttl 64, id 53832, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 46320 win 33156 >>000024 AF 2 1280: IP (tos 0x8, ttl 64, id 3515, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 54916:56144(1228) ack 1330 win 33156 >>011020 AF 2 52: IP (tos 0x8, ttl 64, id 11608, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 48776 win 32542 >>000026 AF 2 1280: IP (tos 0x8, ttl 64, id 5848, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 56144:57372(1228) ack 1330 win 33156 >>000211 AF 2 1280: IP (tos 0x8, ttl 64, id 39892, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 57372:58600(1228) ack 1330 win 33156 >>005641 AF 2 52: IP (tos 0x8, ttl 64, id 7943, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 50004 win 33156 >>000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8678, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 58600:59828(1228) ack 1330 win 33156 >>011072 AF 2 52: IP (tos 0x8, ttl 64, id 38257, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 52460 win 32542 >>000025 AF 2 1280: IP (tos 0x8, ttl 64, id 12255, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 59828:61056(1228) ack 1330 win 33156 >>000209 AF 2 1280: IP (tos 0x8, ttl 64, id 46257, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 61056:62284(1228) ack 1330 win 33156 >>000222 AF 2 1280: IP (tos 0x8, ttl 64, id 4093, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 62284:63512(1228) ack 1330 win 33156 >>007065 AF 2 52: IP (tos 0x8, ttl 64, id 18720, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 53688 win 33156 >>000025 AF 2 1280: IP (tos 0x8, ttl 64, id 38378, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 63512:64740(1228) ack 1330 win 33156 >>011034 AF 2 52: IP (tos 0x8, ttl 64, id 18718, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 56144 win 32542 >>000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8148, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . 64740:65968(1228) ack 1330 win 33156 >>005991 AF 2 52: IP (tos 0x8, ttl 64, id 62285, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 57372 win 33156 >>010726 AF 2 52: IP (tos 0x8, ttl 64, id 1549, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 59828 win 32542 >>005670 AF 2 52: IP (tos 0x8, ttl 64, id 61504, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 61056 win 33156 >>011260 AF 2 52: IP (tos 0x8, ttl 64, id 32633, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 63512 win 32542 >>005510 AF 2 52: IP (tos 0x8, ttl 64, id 54614, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 64740 win 33156 >>104909 AF 2 52: IP (tos 0x8, ttl 64, id 50471, offset 0, flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 65968 win 33156 >> >> > >tcpdump -netttvvi ng0 host A.B.C.D: > > >>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 25895, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10b) >>011042 AF 2 128: IP (tos 0x8, ttl 61, id 5786, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf0) >>000226 AF 2 1352: IP (tos 0x8, ttl 64, id 36701, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10c) >>000216 AF 2 1352: IP (tos 0x8, ttl 64, id 8789, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10d) >>004853 AF 2 128: IP (tos 0x8, ttl 61, id 17128, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf1) >>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 34888, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10e) >>018747 AF 2 128: IP (tos 0x8, ttl 61, id 14828, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf2) >>000248 AF 2 1352: IP (tos 0x8, ttl 64, id 34356, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10f) >>000223 AF 2 1352: IP (tos 0x8, ttl 64, id 34151, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x110) >>005030 AF 2 128: IP (tos 0x8, ttl 61, id 45476, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf3) >>000228 AF 2 1352: IP (tos 0x8, ttl 64, id 39765, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x111) >>011247 AF 2 128: IP (tos 0x8, ttl 61, id 63692, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf4) >>000226 AF 2 1352: IP (tos 0x8, ttl 64, id 29240, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x112) >>000222 AF 2 1352: IP (tos 0x8, ttl 64, id 43306, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x113) >>005663 AF 2 128: IP (tos 0x8, ttl 61, id 32980, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf5) >>000228 AF 2 1352: IP (tos 0x8, ttl 64, id 56920, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x114) >>010190 AF 2 128: IP (tos 0x8, ttl 61, id 3206, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf6) >>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 4655, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x115) >>000215 AF 2 1352: IP (tos 0x8, ttl 64, id 62740, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x116) >>000203 AF 2 1352: IP (tos 0x8, ttl 64, id 35642, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x117) >>006875 AF 2 128: IP (tos 0x8, ttl 61, id 37801, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf7) >>000234 AF 2 1352: IP (tos 0x8, ttl 64, id 41803, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x118) >>010651 AF 2 128: IP (tos 0x8, ttl 61, id 54256, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf8) >>000235 AF 2 1352: IP (tos 0x8, ttl 64, id 30732, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x119) >>007913 AF 2 128: IP (tos 0x8, ttl 61, id 7647, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf9) >>011166 AF 2 128: IP (tos 0x8, ttl 61, id 58037, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfa) >>005483 AF 2 128: IP (tos 0x8, ttl 61, id 65275, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfb) >>011250 AF 2 128: IP (tos 0x8, ttl 61, id 47289, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfc) >>005505 AF 2 128: IP (tos 0x8, ttl 61, id 203, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfd) >>104747 AF 2 128: IP (tos 0x8, ttl 61, id 45263, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfe) >>8. 338674 AF 2 128: IP (tos 0x8, ttl 61, id 36351, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xff) >>319992 AF 2 128: IP (tos 0x8, ttl 61, id 18085, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x100) >>441837 AF 2 128: IP (tos 0x8, ttl 61, id 58323, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x101) >>684077 AF 2 128: IP (tos 0x8, ttl 61, id 35487, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x102) >>1. 167602 AF 2 128: IP (tos 0x8, ttl 61, id 34442, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x103) >>2. 136032 AF 2 128: IP (tos 0x8, ttl 61, id 8345, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x104) >>2. 984665 AF 2 128: IP (tos 0x8, ttl 61, id 35456, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x105) >> >> > > >>From what I'm seeing host B just stops sending without any reason. At >least I don't see any fragmented packets. The only thing I've seen is >some packets doesn't get ack'ed by the receiver. > >These packets never get ack'ed: >46320:47548(1228) >50004:51232(1228) >53688:54916(1228) >57372:58600(1228) >61056:62284(1228) > >On host A I dumped the following: > >tcpdump -netttvvi gif6 > > >>1129985378.941282 AF 2 52: IP (tos 0x8, ttl 64, id 41637, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 45092 win 32542 >>1129985378.952628 AF 2 1280: IP (tos 0x8, ttl 64, id 14004, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 45092:46320(1228) ack 1330 win 33156 >>1129985378.952657 AF 2 52: IP (tos 0x8, ttl 64, id 23243, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 46320 win 33156 >>1129985378.958250 AF 2 1280: IP (tos 0x8, ttl 64, id 4306, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 46320:47548(1228) ack 1330 win 33156 >>1129985378.971118 AF 2 1280: IP (tos 0x8, ttl 64, id 33534, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 47548:48776(1228) ack 1330 win 33156 >>1129985378.971137 AF 2 52: IP (tos 0x8, ttl 64, id 60095, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 48776 win 32542 >>1129985378.982488 AF 2 1280: IP (tos 0x8, ttl 64, id 11459, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 48776:50004(1228) ack 1330 win 33156 >>1129985378.982516 AF 2 52: IP (tos 0x8, ttl 64, id 33184, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 50004 win 33156 >>1129985378.987989 AF 2 1280: IP (tos 0x8, ttl 64, id 54180, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 50004:51232(1228) ack 1330 win 33156 >>1129985378.994231 AF 2 1280: IP (tos 0x8, ttl 64, id 24535, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 51232:52460(1228) ack 1330 win 33156 >>1129985378.994250 AF 2 52: IP (tos 0x8, ttl 64, id 30647, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 52460 win 32542 >>1129985379.012101 AF 2 1280: IP (tos 0x8, ttl 64, id 61397, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 52460:53688(1228) ack 1330 win 33156 >>1129985379.012132 AF 2 52: IP (tos 0x8, ttl 64, id 60550, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 53688 win 33156 >>1129985379.017754 AF 2 1280: IP (tos 0x8, ttl 64, id 28408, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 53688:54916(1228) ack 1330 win 33156 >>1129985379.023720 AF 2 1280: IP (tos 0x8, ttl 64, id 27558, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 54916:56144(1228) ack 1330 win 33156 >>1129985379.023741 AF 2 52: IP (tos 0x8, ttl 64, id 21502, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 56144 win 32542 >>1129985379.035333 AF 2 1280: IP (tos 0x8, ttl 64, id 18885, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 56144:57372(1228) ack 1330 win 33156 >>1129985379.035362 AF 2 52: IP (tos 0x8, ttl 64, id 59875, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 57372 win 33156 >>1129985379.040830 AF 2 1280: IP (tos 0x8, ttl 64, id 37252, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 57372:58600(1228) ack 1330 win 33156 >>1129985379.046576 AF 2 1280: IP (tos 0x8, ttl 64, id 18349, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 58600:59828(1228) ack 1330 win 33156 >>1129985379.046595 AF 2 52: IP (tos 0x8, ttl 64, id 43697, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 59828 win 32542 >>1129985379.064961 AF 2 1280: IP (tos 0x8, ttl 64, id 38300, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 59828:61056(1228) ack 1330 win 33156 >>1129985379.064993 AF 2 52: IP (tos 0x8, ttl 64, id 47539, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 61056 win 33156 >>1129985379.070688 AF 2 1280: IP (tos 0x8, ttl 64, id 30345, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 61056:62284(1228) ack 1330 win 33156 >>1129985379.076184 AF 2 1280: IP (tos 0x8, ttl 64, id 37536, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 62284:63512(1228) ack 1330 win 33156 >>1129985379.076202 AF 2 52: IP (tos 0x8, ttl 64, id 34201, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 63512 win 32542 >>1129985379.081680 AF 2 1280: IP (tos 0x8, ttl 64, id 20637, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 63512:64740(1228) ack 1330 win 33156 >>1129985379.081709 AF 2 52: IP (tos 0x8, ttl 64, id 59866, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 64740 win 33156 >>1129985379.087678 AF 2 1280: IP (tos 0x8, ttl 64, id 35213, offset 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . 64740:65968(1228) ack 1330 win 33156 >>1129985379.186906 AF 2 52: IP (tos 0x8, ttl 64, id 2465, offset 0, flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp sum ok] 1330:1330(0) ack 65968 win 33156 >> >> > >tcpdump -netttvvi em1 host E.F.G.H > > >>1129985379.064825 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 45003, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x3e) >>1129985379.065024 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 1195, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x2f) >>1129985379.070572 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 36820, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x3f) >>1129985379.076069 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 44971, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x40) >>1129985379.076233 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 56964, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x30) >>1129985379.081565 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 24742, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x41) >>1129985379.081741 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 9390, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x31) >>1129985379.087562 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 48065, offset 0, flags [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x0e0dffaa,seq=0x42) >>1129985379.186945 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 36315, offset 0, flags [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x32) >> >> > >If I'm not misleaded, this also doesn't show any errors except the >missing ack's. host B just stops sending. If there's an ack missing, >doesn't have the sending host to just repeat the un-ack'ed packet? > >The IPSec tunnel does not die. Even shortly after the (scp) transfer >stalls the tunnel itself is still usable (for small amounts of data). To >make it more worse, when disabling pf at the senders side, the transfer >works. I've tripple checked pflog for denied packets on both sides but >pf didn't filter any packets out. > >When disabling the IPSec rules using `setkey -F; setkey -FP' on the >tunnel for a moment, the scp transfer does not stall. So it's not a gif >issue. > >It doesn't seem to be an MTU issue (pf has also the rule 'scrub in/out >all no-df'), but what kind of issue is that?? Has anybody ever >experienced similar things? Or am I misinterpreting the tcpdump output? > > >Any help and hint is appreciated! Without an error message I'm lost. > >Volker > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 19:25:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B185C16A41F for ; Sat, 22 Oct 2005 19:25:19 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6035243D45 for ; Sat, 22 Oct 2005 19:25:17 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 01C8C1CCDD; Sun, 23 Oct 2005 08:25:07 +1300 (NZDT) Date: Sun, 23 Oct 2005 08:25:07 +1300 From: Andrew Thompson To: "Wojciech A. Koszek" Message-ID: <20051022192507.GB62360@heff.fud.org.nz> References: <20051020202034.GA4556@freebsd.czest.pl> <20051020202327.GA53753@heff.fud.org.nz> <20051022133735.GA26636@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051022133735.GA26636@freebsd.czest.pl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Dependency between interfaces 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, 22 Oct 2005 19:25:19 -0000 On Sat, Oct 22, 2005 at 01:37:35PM +0000, Wojciech A. Koszek wrote: > On Fri, Oct 21, 2005 at 09:23:27AM +1300, Andrew Thompson wrote: > > On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > > > Hello, > > > > > [..] > > > > Is it still a problem or did you test on a pre r1.26 kernel? > > > > Results from -CURRENT: I got panic if sk/rl modules are loaded, interfaces > added to bridge0 and these drivers kldunload(8)ed: > > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_rl.trace > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_sk.trace > Ah, that makes sense. It looks like I need to change that particular detach not to call back into the drvier to !PROMISC and just make it a clean break :) Andrew From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 19:45:25 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16F8316A4C1 for ; Sat, 22 Oct 2005 19:45:25 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D67BD43D46 for ; Sat, 22 Oct 2005 19:45:15 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id D8FAE1CCDD; Sun, 23 Oct 2005 08:45:06 +1300 (NZDT) Date: Sun, 23 Oct 2005 08:45:06 +1300 From: Andrew Thompson To: "Wojciech A. Koszek" Message-ID: <20051022194506.GC62360@heff.fud.org.nz> References: <20051020202034.GA4556@freebsd.czest.pl> <20051020202327.GA53753@heff.fud.org.nz> <20051022133735.GA26636@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <20051022133735.GA26636@freebsd.czest.pl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Dependency between interfaces 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, 22 Oct 2005 19:45:26 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Oct 22, 2005 at 01:37:35PM +0000, Wojciech A. Koszek wrote: > On Fri, Oct 21, 2005 at 09:23:27AM +1300, Andrew Thompson wrote: > > On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > > > Hello, > > > > > [..] > > > > Is it still a problem or did you test on a pre r1.26 kernel? > > > > Results from -CURRENT: I got panic if sk/rl modules are loaded, interfaces > added to bridge0 and these drivers kldunload(8)ed: > > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_rl.trace > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_sk.trace > Can you please try this patch. cheers, Andrew --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ifdetach2.diff" Index: if_bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_bridge.c,v retrieving revision 1.29 diff -u -p -r1.29 if_bridge.c --- if_bridge.c 14 Oct 2005 20:57:02 -0000 1.29 +++ if_bridge.c 22 Oct 2005 19:41:18 -0000 @@ -219,7 +219,7 @@ static struct bridge_iflist *bridge_look static struct bridge_iflist *bridge_lookup_member_if(struct bridge_softc *, struct ifnet *ifp); static void bridge_delete_member(struct bridge_softc *, - struct bridge_iflist *); + struct bridge_iflist *, int); static int bridge_ioctl_add(struct bridge_softc *, void *); static int bridge_ioctl_del(struct bridge_softc *, void *); @@ -506,7 +506,7 @@ bridge_clone_destroy(struct ifnet *ifp) ifp->if_flags &= ~IFF_UP; while ((bif = LIST_FIRST(&sc->sc_iflist)) != NULL) - bridge_delete_member(sc, bif); + bridge_delete_member(sc, bif, 0); BRIDGE_UNLOCK(sc); @@ -690,26 +690,29 @@ bridge_lookup_member_if(struct bridge_so * Delete the specified member interface. */ static void -bridge_delete_member(struct bridge_softc *sc, struct bridge_iflist *bif) +bridge_delete_member(struct bridge_softc *sc, struct bridge_iflist *bif, + int gone) { struct ifnet *ifs = bif->bif_ifp; BRIDGE_LOCK_ASSERT(sc); - switch (ifs->if_type) { - case IFT_ETHER: - case IFT_L2VLAN: - /* - * Take the interface out of promiscuous mode. - */ - (void) ifpromisc(ifs, 0); - break; + if (!gone) { + switch (ifs->if_type) { + case IFT_ETHER: + case IFT_L2VLAN: + /* + * Take the interface out of promiscuous mode. + */ + (void) ifpromisc(ifs, 0); + break; - default: + default: #ifdef DIAGNOSTIC - panic("bridge_delete_member: impossible"); + panic("bridge_delete_member: impossible"); #endif - break; + break; + } } ifs->if_bridge = NULL; @@ -811,7 +814,7 @@ bridge_ioctl_del(struct bridge_softc *sc if (bif == NULL) return (ENOENT); - bridge_delete_member(sc, bif); + bridge_delete_member(sc, bif, 0); return (0); } @@ -1207,14 +1210,16 @@ static void bridge_ifdetach(struct ifnet *ifp) { struct bridge_softc *sc = ifp->if_bridge; - struct ifbreq breq; + struct bridge_iflist *bif; BRIDGE_LOCK(sc); - memset(&breq, 0, sizeof(breq)); - snprintf(breq.ifbr_ifsname, sizeof(breq.ifbr_ifsname), ifp->if_xname); + bif = bridge_lookup_member_if(sc, ifp); + if (bif == NULL) + return; + + bridge_delete_member(sc, bif, 1); - (void) bridge_ioctl_del(sc, &breq); BRIDGE_UNLOCK(sc); } --wac7ysb48OaltWcw-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 20:09:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA9A616A41F for ; Sat, 22 Oct 2005 20:09:15 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8415243D62 for ; Sat, 22 Oct 2005 20:09:05 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: pass (tce71.tce85.de: domain of vwsoft.com designates 213.6.211.221 as permitted sender) client-ip=213.6.211.221; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (Ad3dd.a.pppool.de [213.6.211.221]) by tce71.tce85.de (Postfix) with ESMTP id E993F17122 for ; Sat, 22 Oct 2005 22:09:11 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id B7E8B5C0F; Sat, 22 Oct 2005 22:01:44 +0200 (CEST) Message-ID: <435AA8BA.6020808@vwsoft.com> Date: Sat, 22 Oct 2005 22:01:46 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Grooms References: <435A85F7.3000909@shrew.net> In-Reply-To: <435A85F7.3000909@shrew.net> X-Enigmail-Version: 0.92.1.0 Content-Type: multipart/mixed; boundary="------------070201090605020103020807" X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Cc: freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling ( me too ) ... 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, 22 Oct 2005 20:09:15 -0000 This is a multi-part message in MIME format. --------------070201090605020103020807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Matthew, thanks for your reply. Glad to hear that I'm not the only one experiencing this problem. So the problem is IPSec + firewall but not related to pf or ipfw. Is it IPSec + bandwidth management?? I've tried a different test setup and just pushed a bunch of (/dev/random) data over a tcp connection through the IPSec tunnel using: %gnetcat 10.128.1.6 49001 /dev/random at host B (10.128.6.1) and did %netcat -l -p 49001 > netcat.out on host A (10.128.1.6). After the file 'netcat.out' reached the file size of 66.108 bytes (around the same size as the scp transfer aborts every time) the tcp stream has been closed with: host B: write(net): Operation not permitted host A: read(net): Connection reset by peer I've managed to get a tcpdump of the gif interfaces on both hosts. Both files are attached to this message (hostA.cap and hostB.cap). These files viewed by ethereal gives a nice look at the tcp flow. There you can see hostB sends three RST packets at the end (for whatever reason). The only thing I've seen (looking a bit ugly) is that hostA answers packets (ACK) before the data payload is being received. At least that's the way tcpdump has seen these packets. That should be related to priorisation of ACK packets using ALTQ. Is anybody else here with deep TCP + IPSec knowledge able to get a look into this? Any known issues? Is there anything I might also check out? Is there a 64k limit with IPSec? :( Thanks, Volker On 2005-10-22 19:33, Matthew Grooms wrote: > Volker, > > I have noticed the same problem. In my case, it only seems to > happen when the traffic is being forwarded across interfaces and pf or > ipfw is enabled. I use purely IPSEC so I would agree that GRE isn't the > problem. This behavior is 100% reproducible for me. If traffic is > forwarded from the host providing the ESP protection or if the firewall > package is disabled, the problem goes away. > > Just some data points. I don't recall seeing this ever happen on > 4.x + ipfw. I experienced this on early 5.x + ipfw, late 5.x + pf and > 6.x + pf. I believe the ipfw versions I tested were prior to the pfil > hooks conversion. > > For example ... > > NODE 1 sftp client > NODE 2 sftp server > IPSEC policy requires ESP protection from NODE 1 or VPN A to NODE 2 > > NODE 1 ------ VPN A ===== VPN B ----- NODE 2 > > 1) NODE 1 <-> NODE 2 sftp via IPSEC pf enabled, traffic stalls > 2) NODE 1 <-> NODE 2 sftp via IPSEC pf disabled, no problems > 3) VPN A <-> NODE 2 sftp via IPSEC pf enabled, no problems > > NOTE : TCP protocol is irrelevant. Haven't tried UDP. --------------070201090605020103020807 Content-Type: application/octet-stream; name="hostB.cap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hostB.cap" 1MOyoQIABAAAAAAAAAAAAGAAAAAAAAAAq4xaQxoqBQBEAAAARAAAAAIAAABFAABAU8YAAEAG CuwKgAYBCoABBuG5v2mFcNGfAAAAALAC//9btwAAAgQE2AEBBAIBAwMBAQEICh6XqFMAAAAA roxaQxQmBQBEAAAARAAAAAIAAABFAABAmssAAEAGw+YKgAYBCoABBuG5v2mFcNGfAAAAALAC //9P/wAAAgQE2AEBBAIBAwMBAQEICh6XtAsAAAAAroxaQ82WBQBEAAAARAAAAAIAAABFAABA HXQAAEAGQT4KgAEGCoAGAb9p4bmPrvSqhXDRoLAS///tUQAAAgQE2AEDAwEBAQgKI426tR6X tAsBAQQCroxaQ/2WBQA4AAAAOAAAAAIAAABFAAA0PMkAAEAGIfUKgAYBCoABBuG5v2mFcNGg j670q4AQgYSroQAAAQEICh6XtCcjjbq1roxaQxaYBQBgAAAAOAQAAAIAAABFAAQ0JaUAAEAG NRkKgAYBCoABBuG5v2mFcNGgj670q4AYgYRHLQAAAQEICh6XtCgjjbq12w3aJB9lIXEtT8eV xj40+AlLKXnAJhcyetg0GUNDGrYdeQvj2JiuUa6MWkOBmQUAYAAAAAQFAAACAAAARQAFALe4 AABABqI5CoAGAQqAAQbhub9phXDVoI+u9KuAEIGE8FUAAAEBCAoel7QoI426taXkiWHuaWbc xemPZDbbKKJqhpdCA/HeKn1t96qFi+7kFnO4Js6OI1CujFpDqpoFAGAAAAAEBQAAAgAAAEUA BQBY0QAAQAYBIQqABgEKgAEG4bm/aYVw2myPrvSrgBCBhBxqAAABAQgKHpe0KCONurUGSyzQ YvsvqYWt1+ufdVmgiS5705ITuuAUMCg8YC7Z2fTIfXIg3Z5uroxaQ5tLBgA4AAAAOAAAAAIA AABFAAA0LhsAAEAGMKMKgAEGCoAGAb9p4bmPrvSrhXDabIAQfx6lCwAAAQEICiONuuQel7Qo roxaQ91LBgBgAAAABAUAAAIAAABFAAUA7PoAAEAGbPcKgAYBCoABBuG5v2mFcN84j670q4AQ gYSJHwAAAQEICh6XtFYjjbrkokP386alFcWj2ti+HvWZN3REEqcTWqy6L2NDsAvARvYbZEDw MbZ0i66MWkPRTAYAYAAAAAQFAAACAAAARQAFADyAAABABh1yCoAGAQqAAQbhub9phXDkBI+u 9KuAEIGERawAAAEBCAoel7RWI4265ABTBKvxpkXp5+ZNzSmerrp51gjXLyxyPTV11SV5Vzx3 A/Qu7EswmpyujFpDfGAGADgAAAA4AAAAAgAAAEUAADQLMQAAQAZTjQqAAQYKgAYBv2nhuY+u 9KuFcN84gBCBhJ3UAAABAQgKI4266R6XtCiujFpDm2AGAGAAAAAEBQAAAgAAAEUABQCIugAA QAbRNwqABgEKgAEG4bm/aYVw6NCPrvSrgBCBhEa9AAABAQgKHpe0WyONuukz7f6dw7RbVjL/ RH681JqJv4Mcbwt7C3DkfMwY5uXNqaJujB+QYrJ+roxaQ3FhBgBgAAAABAUAAAIAAABFAAUA p/8AAEAGsfIKgAYBCoABBuG5v2mFcO2cj670q4AQgYSz/QAAAQEICh6XtFsjjbrpZkPUK0vW 4Ppi6SXJFyR+sKXOvKEwqIQMJ3TKS/h/B/zF7A5CJwflxq6MWkOtAgcAOAAAADgAAAACAAAA RQAANKZYAABABrhlCoABBgqABgG/aeG5j670q4Vw6NCAEH8elkoAAAEBCAojjbsTHpe0Vq6M WkPuAgcAYAAAAAQFAAACAAAARQAFALyVAABABp1cCoAGAQqAAQbhub9phXDyaI+u9KuAEIGE 5ekAAAEBCAoel7SFI427E8yG9sGFQphKj654hVYGFtm7rTgVScEtuzSaDqZJHyiQA2cdtoqk f8yujFpD5gMHAGAAAAAEBQAAAgAAAEUABQA2lAAAQAYjXgqABgEKgAEG4bm/aYVw9zSPrvSr gBCBhNGQAAABAQgKHpe0hSONuxOdd3Lq9P4foI7sywMPOyy1EE0RQSgf7xR/DmUr4S/cAc16 /DyaYFTyroxaQ+UXBwA4AAAAOAAAAAIAAABFAAA0xkAAAEAGmH0KgAEGCoAGAb9p4bmPrvSr hXDtnIAQgYSPDgAAAQEICiONuxgel7RbroxaQwQYBwBgAAAABAUAAAIAAABFAAUAfuAAAEAG 2xEKgAYBCoABBuG5v2mFcPwAj670q4AQgYRhXQAAAQEICh6XtIojjbsYGzgUFVZVRtzDQozv 3ngO33OhOOoR13DUv5WkvoPVtuMl9J6PBNAHYa6MWkNtowcAOAAAADgAAAACAAAARQAANBMO AABABkuwCoABBgqABgG/aeG5j670q4Vw9zSAEH8eh7gAAAEBCAojjbs8Hpe0W66MWkOJowcA YAAAAAQFAAACAAAARQAFAKeeAABABrJTCoAGAQqAAQbhub9phXEAzI+u9KuAEIGESD0AAAEB CAoel7SuI427PK8e+kW9keWEoWxBtesXyrHdxGVWc+Z6r7gNeYjDEeoj/1vq1Xox0ZKujFpD X6QHAGAAAAAEBQAAAgAAAEUABQCsvQAAQAatNAqABgEKgAEG4bm/aYVxBZiPrvSrgBCBhGeN AAABAQgKHpe0riONuzybcF5Xbr8BGlezIWwcahMqkAiy489m2pTbPzUl/w+2PfnNtYKvWAtD roxaQ6K5BwA4AAAAOAAAAAIAAABFAAA0QjgAAEAGHIYKgAEGCoAGAb9p4bmPrvSrhXD8AIAQ gYSAVgAAAQEICiONu0Iel7SFroxaQ8C5BwBgAAAABAUAAAIAAABFAAUAyJMAAEAGkV4KgAYB CoABBuG5v2mFcQpkj670q4AQgYS+VwAAAQEICh6XtLMjjbtCQPTQGPCni/dqumRPGXllxaD0 h/jBBX3yRwxehacZmPro+EWtnZIeKq6MWkOaugcAYAAAAAQFAAACAAAARQAFAB+DAABABjpv CoAGAQqAAQbhub9phXEPMI+u9KuAEIGEPt0AAAEBCAoel7S0I427QhyQDlRa8eG853HPhM0N 7yl5IQnH1Lr8Wa8p0M+2f/8F7Z2TbXN9LX+ujFpD6kYIADgAAAA4AAAAAgAAAEUAADSnMQAA QAa3jAqAAQYKgAYBv2nhuY+u9KuFcQWYgBB/Hnj8AAABAQgKI427ZR6XtIqujFpDBUcIAGAA AAAEBQAAAgAAAEUABQDi6wAAQAZ3BgqABgEKgAEG4bm/aYVxE/yPrvSrgBCBhPoRAAABAQgK Hpe02CONu2Xo3Ju+R3zuGbnoK/Lr4UGpmcUhe/7ie/6S/BOy35zRV0b8BuEHWE+nroxaQ9ZH CABgAAAABAUAAAIAAABFAAUAzcwAAEAGjCUKgAYBCoABBuG5v2mFcRjIj670q4AQgYQvywAA AQEICh6XtNgjjbtlClwybtj8qI+X/xLyeF1E5ONp9a7CoERsm1/hqzRmOtpPIxvnufgWZK6M WkNfWwgAOAAAADgAAAACAAAARQAANJoXAABABsSmCoABBgqABgG/aeG5j670q4VxCmSAEIGE caAAAAEBCAojjbtrHpe0rq6MWkN/WwgAYAAAAAQFAAACAAAARQAFAAWEAABABlRuCoAGAQqA AQbhub9phXEdlI+u9KuAEIGELd0AAAEBCAoel7TdI427a7SgL1md6/FTBQGDOKfZiRKwotWe 9u8gTsF2FoM1E1+Ml6OZHdqP/JiujFpDxIUIADgAAAA4AAAAAgAAAEUAADRmUgAAQAb4awqA AQYKgAYBv2nhuY+u9KuFcRP8gBB/HmpeAAABAQgKI427dh6XtLOujFpD4YUIAGAAAAAEBQAA AgAAAEUABQBq/gAAQAbu8wqABgEKgAEG4bm/aYVxImCPrvSrgBCBhD+ZAAABAQgKHpe06CON u3aNl3VpPdEBhvzN2zNDNriVlEevukXjxfCi+4gGRh1Oasa3ibeEzi6mroxaQ7CGCABgAAAA BAUAAAIAAABFAAUAo7IAAEAGtj8KgAYBCoABBuG5v2mFcScsj670q4AQgYSt4QAAAQEICh6X tOgjjbt26g6m5MO6zkkhe+UIOpMnJRfZafaePCyeYhnOvBY66WbjEFfMZGRxc66MWkMf7wgA OAAAADgAAAACAAAARQAANERHAABABhp3CoABBgqABgG/aeG5j670q4VxGMiAEIGEYu4AAAEB CAojjbuPHpe02K6MWkM+7wgAYAAAAAQFAAACAAAARQAFADnsAABABiAGCoAGAQqAAQbhub9p hXEr+I+u9KuAEIGE9CoAAAEBCAoel7UDI427jxe/9CQMLRoB3z9lcC8CDE754bdFmELH2kzP DTMRF+gLUU9bq8+ARKGujFpDZxMJADgAAAA4AAAAAgAAAEUAADS+EgAAQAagqwqAAQYKgAYB v2nhuY+u9KuFcSJggBB/HluxAAABAQgKI427mh6XtNiujFpDhBMJAGAAAAAEBQAAAgAAAEUA BQBZhwAAQAYAawqABgEKgAEG4bm/aYVxMMSPrvSrgBCBhKTeAAABAQgKHpe1DCONu5odmapf QeaorP3f3lxFeU1YFuyxm0tjNKv0oV3D0F1QZ/9lnSfNIxicroxaQ1cUCQBgAAAABAUAAAIA AABFAAUAD70AAEAGSjUKgAYBCoABBuG5v2mFcTWQj670q4AQgYTYGAAAAQEICh6XtQwjjbua aEeklaadiO6zD3MlXnwpoLD/mrdZ3JpgkRv+nnz5zw8qW0hG8AOE0K6MWkPiKAkAOAAAADgA AAACAAAARQAANHIsAABABuyRCoABBgqABgG/aeG5j670q4VxJyyAEIGEVGkAAAEBCAojjbug Hpe06K6MWkMEKQkAYAAAAAQFAAACAAAARQAFADafAABABiNTCoAGAQqAAQbhub9phXE6XI+u 9KuAEIGE8DwAAAEBCAoel7URI427oIWpf5KhTjcggKQ/1N4WDl/Kjt3FNPYIzPkUz7jR9QGc CYZ+RpZLIl+ujFpDkpAJADgAAAA4AAAAAgAAAEUAADQDQAAAQAZbfgqAAQYKgAYBv2nhuY+u 9KuFcTDEgBB/Hk0dAAABAQgKI427uh6XtOiujFpDsZAJAGAAAAAEBQAAAgAAAEUABQAZoAAA QAZAUgqABgEKgAEG4bm/aYVxPyiPrvSrgBCBhGIRAAABAQgKHpe1LCONu7r10xret5MY1dN3 GnhkUEDwqQ0pFwZ2I0QvY2rgueZP5Lso98GinMIJroxaQ4uRCQBgAAAABAUAAAIAAABFAAUA lKAAAEAGxVEKgAYBCoABBuG5v2mFcUP0j670q4AQgYQjhAAAAQEICh6XtSwjjbu6nkYs9CT3 C2zudRNTa5mCMw0U9vtREp67UeBgw+mWhaOf8CX4mtlfaq6MWkMMswkAOAAAADgAAAACAAAA RQAANCRmAABABjpYCoABBgqABgG/aeG5j670q4VxNZCAEIGERb4AAAEBCAojjbvDHpe1DK6M WkMpswkAYAAAAAQFAAACAAAARQAFAAWJAABABlRpCoAGAQqAAQbhub9phXFIwI+u9KuAEIGE PR0AAAEBCAoel7U1I427w7dwFgFfGNPCwJbZHTjUnBdIbpLwuFxtp7YAN0oHK1Pdi0lta1mS lKOujFpD0t4JADgAAAA4AAAAAgAAAEUAADSbHQAAQAbDoAqAAQYKgAYBv2nhuY+u9KuFcT8o gBB/Hj6BAAABAQgKI427zh6XtQyujFpD8d4JAGAAAAAEBQAAAgAAAEUABQCHigAAQAbSZwqA BgEKgAEG4bm/aYVxTYyPrvSrgBCBhD7xAAABAQgKHpe1QCONu84DXYB+3kkxGjn/YMFStY71 H7Fan+Yjo5/jnvOHTVidPzqQujkvnwy+roxaQ8bfCQBgAAAABAUAAAIAAABFAAUAFY8AAEAG RGMKgAYBCoABBuG5v2mFcVJYj670q4AQgYQsaQAAAQEICh6XtUAjjbvObsgOw9UUtb24fD/O YC5a+XDuqZQlxRM1kPEB0JisOqgRpjWe32BSZ66MWkOYMQoAOAAAADgAAAACAAAARQAANG1d AABABvFgCoABBgqABgG/aeG5j670q4VxQ/SAEIGENxoAAAEBCAojjbvjHpe1LK6MWkO3MQoA YAAAAAQFAAACAAAARQAFAFjnAABABgELCoAGAQqAAQbhub9phXFXJI+u9KuAEIGE0QoAAAEB CAoel7VVI42749ovBoTlqMCswuIKDp171WUFSmzRwuimP45+n0wRwM3mYmSUw2cdCo6ujFpD r1wKADgAAAA4AAAAAgAAAEUAADRcZgAAQAYCWAqAAQYKgAYBv2nhuY+u9KuFcU2MgBB/Hi/d AAABAQgKI4277h6XtSyujFpDylwKAGAAAAAEBQAAAgAAAEUABQAS8AAAQAZHAgqABgEKgAEG 4bm/aYVxW/CPrvSrgBCBhCYJAAABAQgKHpe1YCONu+47TDjjmZEjpMRzYyY8jWes+o68MnDD SQ29Z+Ldz3dkhGCJj/ApKSKwroxaQ7FdCgBgAAAABAUAAAIAAABFAAUA0MoAAEAGiScKgAYB CoABBuG5v2mFcWC8j670q4AQgYSMwQAAAQEICh6XtWEjjbvueOBkByW09aKDNf+tNY5RtHcf SnfvyvpSv+49LHWtg+uthngSgsh0ha6MWkNbfgoAOAAAADgAAAACAAAARQAANE1PAABABhFv CoABBgqABgG/aeG5j670q4VxUliAEIGEKI4AAAEBCAojjbv3Hpe1QK6MWkN7fgoAYAAAAAQF AAACAAAARQAFAKWRAABABrRgCoAGAQqAAQbhub9phXFliI+u9KuAEIGEKZ4AAAEBCAoel7Vp I4279zQCpt00IoJsK6t1mUsKl015/FAByl7OqGErVRrnweX/6fF7WdMVFy2ujFpDn9IKADgA AAA4AAAAAgAAAEUAADQNQgAAQAZRfAqAAQYKgAYBv2nhuY+u9KuFcVvwgBB/HiFGAAABAQgK I428DR6XtUCujFpDxtIKAGAAAAAEBQAAAgAAAEUABQDswwAAQAZtLgqABgEKgAEG4bm/aYVx alSPrvSrgBCBhAK1AAABAQgKHpe1fiONvA1SpqvmAPtiyVq5XQ8QQk4EdCCmT+ChdRV1/VJ3 n14ymJxLO+fnsu5HroxaQ53TCgBgAAAABAUAAAIAAABFAAUAXNgAAEAG/RkKgAYBCoABBuG5 v2mFcW8gj670q4AQgYR6BwAAAQEICh6XtX8jjbwNetBjWt0HppaKypc9aWXHOmUNihjCOkSj 4ItVTZ/DT1MT449RzL7vPq6MWkP0/AoAOAAAADgAAAACAAAARQAANJAiAABABs6bCoABBgqA BgG/aeG5j670q4VxYLyAEIGEGeoAAAEBCAojjbwXHpe1YK6MWkMS/QoAYAAAAAQFAAACAAAA RQAFADKGAABABidsCoAGAQqAAQbhub9phXFz7I+u9KuAEIGEUOIAAAEBCAoel7WJI428F/bp jJcDHehFMIgPfrONc1KCUYJSgdWcO8STTiJLjTGs763WmNPVgYiujFpDzygLADgAAAA4AAAA AgAAAEUAADRFLQAAQAYZkQqAAQYKgAYBv2nhuY+u9KuFcWpUgBB/HhKsAAABAQgKI428Ih6X tWGujFpD7CgLAGAAAAAEBQAAAgAAAEUABQCS7wAAQAbHAgqABgEKgAEG4bm/aYVxeLiPrvSr gBCBhPh8AAABAQgKHpe1lSONvCJ0aBTKqpwFqeabW4eJaonrlBq7v5IiU0eLIKqm4o+tRb1R Mtk3Vxe4roxaQ8QpCwBgAAAABAUAAAIAAABFAAUAyv8AAEAGjvIKgAYBCoABBuG5v2mFcX2E j670q4AQgYQPlgAAAQEICh6XtZUjjbwizaTRsCPgeVYw8KvFNLHe53Ddd7SropdgL9GhN5Ps yRPDsHeOfgVxu66MWkOdKgsAYAAAAAQFAAACAAAARQAFAL2yAABABpw/CoAGAQqAAQbhub9p hXGCUI+u9KuAEIGEpXQAAAEBCAoel7WVI428IoptPxKaTHmWZbher2X7Q/L7LLW/txL+ABWS APfVrxt0Li/B+ol+KJCujFpDTXQLADgAAAA4AAAAAgAAAEUAADSrVgAAQAazZwqAAQYKgAYB v2nhuY+u9KuFcW8ggBCBhAtJAAABAQgKI428Nh6XtX6ujFpDpp8LADgAAAA4AAAAAgAAAEUA ADRCNQAAQAYciQqAAQYKgAYBv2nhuY+u9KuFcXi4gBB/HgQLAAABAQgKI428QR6XtX+ujFpD wZ8LAGAAAAAEBQAAAgAAAEUABQC9+QAAQAab+AqABgEKgAEG4bm/aYVxhxyPrvSrgBCBhFOh AAABAQgKHpe1syONvEEvS8cxFW11wVa7dU/Al/Xdw/A0UqMB7w89Tr7OctxxX9NXWd8EIX0I roxaQ5egCwBgAAAABAUAAAIAAABFAAUAE5oAAEAGRlgKgAYBCoABBuG5v2mFcYvoj670q4AQ gYQr8wAAAQEICh6XtbMjjbxBzoOAHsiAnszIduCY3Fa9l6zZKD+SRJ+TTh5osZUflQA0ZbrI HcBDIa6MWkNvoQsAYAAAAAQFAAACAAAARQAFAHuSAABABt5fCoAGAQqAAQbhub9phXGQtI+u 9KuAEIGEZm8AAAEBCAoel7WzI428QffOyicPcrUTD1cteUfs5Uadsr5K5PWGyKBR8Zu6pevC aPL3gAUbdeiujFpD7ckLADgAAAA4AAAAAgAAAEUAADQhSAAAQAY9dgqAAQYKgAYBv2nhuY+u 9KuFcX2EgBCBhPy3AAABAQgKI428TB6XtZWujFpDD8oLAGAAAAAEBQAAAgAAAEUABQCYkAAA QAbBYQqABgEKgAEG4bm/aYVxlYCPrvSrgBCBhDrjAAABAQgKHpe1viONvEw31W59D/bvMlGy irkxK93PZdafCx+p8wEeqTXzElS3BoPnxSgXN4+IroxaQ0/0CwA4AAAAOAAAAAIAAABFAAA0 cxcAAEAG66YKgAEGCoAGAb9p4bmPrvSrhXGHHIAQfx71egAAAQEICiONvFcel7WVroxaQ2v0 CwBgAAAABAUAAAIAAABFAAUAzvAAAEAGiwEKgAYBCoABBuG5v2mFcZpMj670q4AQgYTIqwAA AQEICh6XtckjjbxXUYdTP7izIefYIGJL+ErnkP47VHFV65ghWbe2LBt3DAQ3euoyd+1dIa6M WkM+9QsAYAAAAAQFAAACAAAARQAFAJaKAABABsNnCoAGAQqAAQbhub9phXGfGI+u9KuAEIGE yIQAAAEBCAoel7XJI428V010DYFmxVPY/HwMumCPcX83n5oim8xBuOxCBfEGlMvGwBNQxIl1 1+qujFpDBz8MADgAAAA4AAAAAgAAAEUAADS6KAAAQAaklQqAAQYKgAYBv2nhuY+u9KuFcYvo gBCBhO4XAAABAQgKI428ah6XtbOujFpDIz8MAGAAAAAEBQAAAgAAAEUABQCi3gAAQAa3EwqA BgEKgAEG4bm/aYVxo+SPrvSrgBCBhPKsAAABAQgKHpe13CONvGrOxVvFwf3I9btcD9mEH2bH LCpqca++WGUIDO6TYMcLQlBdpQBdm7tbroxaQypqDAA4AAAAOAAAAAIAAABFAAA04HoAAEAG fkMKgAEGCoAGAb9p4bmPrvSrhXGVgIAQfx7m2gAAAQEICiONvHUel7WzroxaQ0VqDABgAAAA BAUAAAIAAABFAAUAzLAAAEAGjUEKgAYBCoABBuG5v2mFcaiwj670q4AQgYQjVAAAAQEICh6X tecjjbx1fAZDSiI/E+CF4GwvztAIVt9e9LQ4iVKfxEBFykBQvzNeVyUKMXKnHK6MWkMbawwA YAAAAAQFAAACAAAARQAFACPvAABABjYDCoAGAQqAAQbhub9phXGtfI+u9KuAEIGEdrcAAAEB CAoel7XnI428dQiPKHxQSmEce7DkvmahOewW7VKjDC7EMd8SwZ2zEQeib15QdSPBCS2ujFpD boAMADgAAAA4AAAAAgAAAEUAADTJCwAAQAaVsgqAAQYKgAYBv2nhuY+u9KuFcZpMgBCBhN+X AAABAQgKI428ex6Xtb6ujFpDi4AMAGAAAAAEBQAAAgAAAEUABQAn1gAAQAYyHAqABgEKgAEG 4bm/aYVxskiPrvSrgBCBhEaqAAABAQgKHpe17SONvHs80vSNyepjfwd8PIdx1KJ887gmIWRA ooxiwTG9wbST2/Wg+XkEseuoroxaQ1OsDAA4AAAAOAAAAAIAAABFAAA0r1MAAEAGr2oKgAEG CoAGAb9p4bmPrvSrhXGj5IAQfx7YTwAAAQEICiONvIYel7XJroxaQ2+sDABgAAAABAUAAAIA AABFAAUApK0AAEAGtUQKgAYBCoABBuG5v2mFcbcUj670q4AQgYTLawAAAQEICh6XtfgjjbyG TAD5gy41WQp6mWoJ8PPJoTyJ1huDYCwRUzz4yP43WU/jYdTl5/k/Wq6MWkNDrQwAYAAAAAQF AAACAAAARQAFANiGAABABoFrCoAGAQqAAQbhub9phXG74I+u9KuAEIGEFaMAAAEBCAoel7X4 I428hrCrtFAcHgopmvY5bB3A/pUDhzHaie8lUWW7IqtIrvQJOlPzIgtSCQCujFpD1eAMADgA AAA4AAAAAgAAAEUAADTOCwAAQAaQsgqAAQYKgAYBv2nhuY+u9KuFcaiwgBCBhND9AAABAQgK I428kx6XtdyujFpD8uAMAGAAAAAEBQAAAgAAAEUABQB1wAAAQAbkMQqABgEKgAEG4bm/aYVx wKyPrvSrgBCBhIHjAAABAQgKHpe2BSONvJMk8DmbVg/m0ugiA5yuRcS/SqXYkjSJ2f/7nQ0K aKLJI0nNQz/z2aunroxaQ1YfDQA4AAAAOAAAAAIAAABFAAA0pScAAEAGuZYKgAEGCoAGAb9p 4bmPrvSrhXGySIAQfx7JsAAAAQEICiONvKMel7XnroxaQ3QfDQBgAAAABAUAAAIAAABFAAUA PaMAAEAGHE8KgAYBCoABBuG5v2mFccV4j670q4AQgYS5nwAAAQEICh6XthUjjbyjxIcxMZF6 wSAPav5d3cwQcgrISIINNImtA6+PPURVqJAkfKnsgGz4DK6MWkNLIA0AYAAAAAQFAAACAAAA RQAFACnBAABABjAxCoAGAQqAAQbhub9phXHKRI+u9KuAEIGE8uwAAAEBCAoel7YVI428o49i S8qIYDH2kDt0jDzBjUYjIxzESY8q/AfXe8V/MKrv38X6MGYaFsCujFpDkjUNADgAAAA4AAAA AgAAAEUAADTkNQAAQAZ6iAqAAQYKgAYBv2nhuY+u9KuFcbcUgBCBhMJyAAABAQgKI428qR6X te2ujFpDrzUNAGAAAAAEBQAAAgAAAEUABQD7wQAAQAZeMAqABgEKgAEG4bm/aYVxzxCPrvSr gBCBhKLMAAABAQgKHpe2GyONvKmbkKvqzSQ3AdthJsxxAVsYEVGewNf0BkYv196hI8tD8IBt chugERQ+roxaQxxvDQA4AAAAOAAAAAIAAABFAAA00EUAAEAGjngKgAEGCoAGAb9p4bmPrvSr hXHArIAQfx67JgAAAQEICiONvLgel7X4roxaQ/yEDQA4AAAAOAAAAAIAAABFAAA0kikAAEAG zJQKgAEGCoAGAb9p4bmPrvSrhXHFeIAQgYSz4gAAAQEICiONvL0el7YFroxaQyaFDQAsAAAA LAAAAAIAAABFAAAoPbUAAEAGIRUKgAYBCoABBuG5v2mFccV4AAAAAFAEAACnzAAAroxaQyTV DQA4AAAAOAAAAAIAAABFAAA0rlwAAEAGsGEKgAEGCoAGAb9p4bmPrvSrhXHPEIAQfx6siwAA AQEICiONvNIel7YVroxaQzTVDQAsAAAALAAAAAIAAABFAAAoX6QAAEAG/yUKgAYBCoABBuG5 v2mFcc8QAAAAAFAEAACeNAAAroxaQ6PsDQA4AAAAOAAAAAIAAABFAAA0LmQAAEAGMFoKgAEG CoAGAb9p4bmPrvSrhXHT3IAQgYSlTQAAAQEICiONvNgel7YbroxaQ7LsDQAsAAAALAAAAAIA AABFAAAo1vUAAEAGh9QKgAYBCoABBuG5v2mFcdPcAAAAAFAEAACZaAAA --------------070201090605020103020807 Content-Type: application/octet-stream; name="hostA.cap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hostA.cap" 1MOyoQIABAAAAAAAAAAAAGAAAAAAAAAA4IxaQ/KBAgBEAAAARAAAAAIAAABFAABAmssAAEAG w+YKgAYBCoABBuG5v2mFcNGfAAAAALAC//9P/wAAAgQE2AEBBAIBAwMBAQEICh6XtAsAAAAA 4IxaQxyCAgBEAAAARAAAAAIAAABFAABAHXQAAEAGQT4KgAEGCoAGAb9p4bmPrvSqhXDRoLAS ///tUQAAAgQE2AEDAwEBAQgKI426tR6XtAsBAQQC4IxaQ3nyAgA4AAAAOAAAAAIAAABFAAA0 PMkAAEAGIfUKgAYBCoABBuG5v2mFcNGgj670q4AQgYSroQAAAQEICh6XtCcjjbq14IxaQ1Ib AwBgAAAAOAQAAAIAAABFAAQ0JaUAAEAGNRkKgAYBCoABBuG5v2mFcNGgj670q4AYgYRHLQAA AQEICh6XtCgjjbq12w3aJB9lIXEtT8eVxj40+AlLKXnAJhcyetg0GUNDGrYdeQvj2JiuUeCM WkMrNgMAYAAAAAQFAAACAAAARQAFALe4AABABqI5CoAGAQqAAQbhub9phXDVoI+u9KuAEIGE 8FUAAAEBCAoel7QoI426taXkiWHuaWbcxemPZDbbKKJqhpdCA/HeKn1t96qFi+7kFnO4Js6O I1DgjFpDRDYDADgAAAA4AAAAAgAAAEUAADQuGwAAQAYwowqAAQYKgAYBv2nhuY+u9KuFcNps gBB/HqULAAABAQgKI4265B6XtCjgjFpDHEwDAGAAAAAEBQAAAgAAAEUABQBY0QAAQAYBIQqA BgEKgAEG4bm/aYVw2myPrvSrgBCBhBxqAAABAQgKHpe0KCONurUGSyzQYvsvqYWt1+ufdVmg iS5705ITuuAUMCg8YC7Z2fTIfXIg3Z5u4IxaQ0hMAwA4AAAAOAAAAAIAAABFAAA0CzEAAEAG U40KgAEGCoAGAb9p4bmPrvSrhXDfOIAQgYSd1AAAAQEICiONuukel7Qo4IxaQy3YAwBgAAAA BAUAAAIAAABFAAUA7PoAAEAGbPcKgAYBCoABBuG5v2mFcN84j670q4AQgYSJHwAAAQEICh6X tFYjjbrkokP386alFcWj2ti+HvWZN3REEqcTWqy6L2NDsAvARvYbZEDwMbZ0i+CMWkOp7QMA YAAAAAQFAAACAAAARQAFADyAAABABh1yCoAGAQqAAQbhub9phXDkBI+u9KuAEIGERawAAAEB CAoel7RWI4265ABTBKvxpkXp5+ZNzSmerrp51gjXLyxyPTV11SV5Vzx3A/Qu7EswmpzgjFpD u+0DADgAAAA4AAAAAgAAAEUAADSmWAAAQAa4ZQqAAQYKgAYBv2nhuY+u9KuFcOjQgBB/HpZK AAABAQgKI427Ex6XtFbgjFpDHAMEAGAAAAAEBQAAAgAAAEUABQCIugAAQAbRNwqABgEKgAEG 4bm/aYVw6NCPrvSrgBCBhEa9AAABAQgKHpe0WyONuukz7f6dw7RbVjL/RH681JqJv4Mcbwt7 C3DkfMwY5uXNqaJujB+QYrJ+4IxaQ1EDBAA4AAAAOAAAAAIAAABFAAA0xkAAAEAGmH0KgAEG CoAGAb9p4bmPrvSrhXDtnIAQgYSPDgAAAQEICiONuxgel7Rb4IxaQxIZBABgAAAABAUAAAIA AABFAAUAp/8AAEAGsfIKgAYBCoABBuG5v2mFcO2cj670q4AQgYSz/QAAAQEICh6XtFsjjbrp ZkPUK0vW4Ppi6SXJFyR+sKXOvKEwqIQMJ3TKS/h/B/zF7A5CJwflxuCMWkMrjwQAYAAAAAQF AAACAAAARQAFALyVAABABp1cCoAGAQqAAQbhub9phXDyaI+u9KuAEIGE5ekAAAEBCAoel7SF I427E8yG9sGFQphKj654hVYGFtm7rTgVScEtuzSaDqZJHyiQA2cdtoqkf8zgjFpDO48EADgA AAA4AAAAAgAAAEUAADQTDgAAQAZLsAqAAQYKgAYBv2nhuY+u9KuFcPc0gBB/Hoe4AAABAQgK I427PB6XtFvgjFpDIKUEAGAAAAAEBQAAAgAAAEUABQA2lAAAQAYjXgqABgEKgAEG4bm/aYVw 9zSPrvSrgBCBhNGQAAABAQgKHpe0hSONuxOdd3Lq9P4foI7sywMPOyy1EE0RQSgf7xR/DmUr 4S/cAc16/DyaYFTy4IxaQ1ylBAA4AAAAOAAAAAIAAABFAAA0QjgAAEAGHIYKgAEGCoAGAb9p 4bmPrvSrhXD8AIAQgYSAVgAAAQEICiONu0Iel7SF4IxaQ5q6BABgAAAABAUAAAIAAABFAAUA fuAAAEAG2xEKgAYBCoABBuG5v2mFcPwAj670q4AQgYRhXQAAAQEICh6XtIojjbsYGzgUFVZV RtzDQozv3ngO33OhOOoR13DUv5WkvoPVtuMl9J6PBNAHYeCMWkOzMAUAYAAAAAQFAAACAAAA RQAFAKeeAABABrJTCoAGAQqAAQbhub9phXEAzI+u9KuAEIGESD0AAAEBCAoel7SuI427PK8e +kW9keWEoWxBtesXyrHdxGVWc+Z6r7gNeYjDEeoj/1vq1Xox0ZLgjFpDxDAFADgAAAA4AAAA AgAAAEUAADSnMQAAQAa3jAqAAQYKgAYBv2nhuY+u9KuFcQWYgBB/Hnj8AAABAQgKI427ZR6X tIrgjFpDqUYFAGAAAAAEBQAAAgAAAEUABQCsvQAAQAatNAqABgEKgAEG4bm/aYVxBZiPrvSr gBCBhGeNAAABAQgKHpe0riONuzybcF5Xbr8BGlezIWwcahMqkAiy489m2pTbPzUl/w+2PfnN tYKvWAtD4IxaQ9NGBQA4AAAAOAAAAAIAAABFAAA0mhcAAEAGxKYKgAEGCoAGAb9p4bmPrvSr hXEKZIAQgYRxoAAAAQEICiONu2sel7Su4IxaQyJcBQBgAAAABAUAAAIAAABFAAUAyJMAAEAG kV4KgAYBCoABBuG5v2mFcQpkj670q4AQgYS+VwAAAQEICh6XtLMjjbtCQPTQGPCni/dqumRP GXllxaD0h/jBBX3yRwxehacZmPro+EWtnZIeKuCMWkObcQUAYAAAAAQFAAACAAAARQAFAB+D AABABjpvCoAGAQqAAQbhub9phXEPMI+u9KuAEIGEPt0AAAEBCAoel7S0I427QhyQDlRa8eG8 53HPhM0N7yl5IQnH1Lr8Wa8p0M+2f/8F7Z2TbXN9LX/gjFpDrHEFADgAAAA4AAAAAgAAAEUA ADRmUgAAQAb4awqAAQYKgAYBv2nhuY+u9KuFcRP8gBB/HmpeAAABAQgKI427dh6XtLPgjFpD udIFAGAAAAAEBQAAAgAAAEUABQDi6wAAQAZ3BgqABgEKgAEG4bm/aYVxE/yPrvSrgBCBhPoR AAABAQgKHpe02CONu2Xo3Ju+R3zuGbnoK/Lr4UGpmcUhe/7ie/6S/BOy35zRV0b8BuEHWE+n 4IxaQ+PSBQA4AAAAOAAAAAIAAABFAAA0REcAAEAGGncKgAEGCoAGAb9p4bmPrvSrhXEYyIAQ gYRi7gAAAQEICiONu48el7TY4IxaQ63oBQBgAAAABAUAAAIAAABFAAUAzcwAAEAGjCUKgAYB CoABBuG5v2mFcRjIj670q4AQgYQvywAAAQEICh6XtNgjjbtlClwybtj8qI+X/xLyeF1E5ONp 9a7CoERsm1/hqzRmOtpPIxvnufgWZOCMWkOj/gUAYAAAAAQFAAACAAAARQAFAAWEAABABlRu CoAGAQqAAQbhub9phXEdlI+u9KuAEIGELd0AAAEBCAoel7TdI427a7SgL1md6/FTBQGDOKfZ iRKwotWe9u8gTsF2FoM1E1+Ml6OZHdqP/JjgjFpDtP4FADgAAAA4AAAAAgAAAEUAADS+EgAA QAagqwqAAQYKgAYBv2nhuY+u9KuFcSJggBB/HluxAAABAQgKI427mh6XtNjgjFpDnxQGAGAA AAAEBQAAAgAAAEUABQBq/gAAQAbu8wqABgEKgAEG4bm/aYVxImCPrvSrgBCBhD+ZAAABAQgK Hpe06CONu3aNl3VpPdEBhvzN2zNDNriVlEevukXjxfCi+4gGRh1Oasa3ibeEzi6m4IxaQ8sU BgA4AAAAOAAAAAIAAABFAAA0ciwAAEAG7JEKgAEGCoAGAb9p4bmPrvSrhXEnLIAQgYRUaQAA AQEICiONu6Ael7To4IxaQxEqBgBgAAAABAUAAAIAAABFAAUAo7IAAEAGtj8KgAYBCoABBuG5 v2mFcScsj670q4AQgYSt4QAAAQEICh6XtOgjjbt26g6m5MO6zkkhe+UIOpMnJRfZafaePCye YhnOvBY66WbjEFfMZGRxc+CMWkOMfAYAYAAAAAQFAAACAAAARQAFADnsAABABiAGCoAGAQqA AQbhub9phXEr+I+u9KuAEIGE9CoAAAEBCAoel7UDI427jxe/9CQMLRoB3z9lcC8CDE754bdF mELH2kzPDTMRF+gLUU9bq8+ARKHgjFpDnXwGADgAAAA4AAAAAgAAAEUAADQDQAAAQAZbfgqA AQYKgAYBv2nhuY+u9KuFcTDEgBB/Hk0dAAABAQgKI427uh6XtOjgjFpDMp8GAGAAAAAEBQAA AgAAAEUABQBZhwAAQAYAawqABgEKgAEG4bm/aYVxMMSPrvSrgBCBhKTeAAABAQgKHpe1DCON u5odmapfQeaorP3f3lxFeU1YFuyxm0tjNKv0oV3D0F1QZ/9lnSfNIxic4IxaQ2ifBgA4AAAA OAAAAAIAAABFAAA0JGYAAEAGOlgKgAEGCoAGAb9p4bmPrvSrhXE1kIAQgYRFvgAAAQEICiON u8Mel7UM4IxaQ6+0BgBgAAAABAUAAAIAAABFAAUAD70AAEAGSjUKgAYBCoABBuG5v2mFcTWQ j670q4AQgYTYGAAAAQEICh6XtQwjjbuaaEeklaadiO6zD3MlXnwpoLD/mrdZ3JpgkRv+nnz5 zw8qW0hG8AOE0OCMWkOvygYAYAAAAAQFAAACAAAARQAFADafAABABiNTCoAGAQqAAQbhub9p hXE6XI+u9KuAEIGE8DwAAAEBCAoel7URI427oIWpf5KhTjcggKQ/1N4WDl/Kjt3FNPYIzPkU z7jR9QGcCYZ+RpZLIl/gjFpDxsoGADgAAAA4AAAAAgAAAEUAADSbHQAAQAbDoAqAAQYKgAYB v2nhuY+u9KuFcT8ogBB/Hj6BAAABAQgKI427zh6XtQzgjFpDGR0HAGAAAAAEBQAAAgAAAEUA BQAZoAAAQAZAUgqABgEKgAEG4bm/aYVxPyiPrvSrgBCBhGIRAAABAQgKHpe1LCONu7r10xre t5MY1dN3GnhkUEDwqQ0pFwZ2I0QvY2rgueZP5Lso98GinMIJ4IxaQ1UdBwA4AAAAOAAAAAIA AABFAAA0bV0AAEAG8WAKgAEGCoAGAb9p4bmPrvSrhXFD9IAQgYQ3GgAAAQEICiONu+Mel7Us 4IxaQ5MyBwBgAAAABAUAAAIAAABFAAUAlKAAAEAGxVEKgAYBCoABBuG5v2mFcUP0j670q4AQ gYQjhAAAAQEICh6XtSwjjbu6nkYs9CT3C2zudRNTa5mCMw0U9vtREp67UeBgw+mWhaOf8CX4 mtlfauCMWkMLSAcAYAAAAAQFAAACAAAARQAFAAWJAABABlRpCoAGAQqAAQbhub9phXFIwI+u 9KuAEIGEPR0AAAEBCAoel7U1I427w7dwFgFfGNPCwJbZHTjUnBdIbpLwuFxtp7YAN0oHK1Pd i0lta1mSlKPgjFpDG0gHADgAAAA4AAAAAgAAAEUAADRcZgAAQAYCWAqAAQYKgAYBv2nhuY+u 9KuFcU2MgBB/Hi/dAAABAQgKI4277h6XtSzgjFpDNWoHAGAAAAAEBQAAAgAAAEUABQCHigAA QAbSZwqABgEKgAEG4bm/aYVxTYyPrvSrgBCBhD7xAAABAQgKHpe1QCONu84DXYB+3kkxGjn/ YMFStY71H7Fan+Yjo5/jnvOHTVidPzqQujkvnwy+4IxaQ15qBwA4AAAAOAAAAAIAAABFAAA0 TU8AAEAGEW8KgAEGCoAGAb9p4bmPrvSrhXFSWIAQgYQojgAAAQEICiONu/cel7VA4IxaQyuA BwBgAAAABAUAAAIAAABFAAUAFY8AAEAGRGMKgAYBCoABBuG5v2mFcVJYj670q4AQgYQsaQAA AQEICh6XtUAjjbvObsgOw9UUtb24fD/OYC5a+XDuqZQlxRM1kPEB0JisOqgRpjWe32BSZ+CM WkMpvgcAYAAAAAQFAAACAAAARQAFAFjnAABABgELCoAGAQqAAQbhub9phXFXJI+u9KuAEIGE 0QoAAAEBCAoel7VVI42749ovBoTlqMCswuIKDp171WUFSmzRwuimP45+n0wRwM3mYmSUw2cd Co7gjFpDOr4HADgAAAA4AAAAAgAAAEUAADQNQgAAQAZRfAqAAQYKgAYBv2nhuY+u9KuFcVvw gBB/HiFGAAABAQgKI428DR6XtUDgjFpDnOgHAGAAAAAEBQAAAgAAAEUABQAS8AAAQAZHAgqA BgEKgAEG4bm/aYVxW/CPrvSrgBCBhCYJAAABAQgKHpe1YCONu+47TDjjmZEjpMRzYyY8jWes +o68MnDDSQ29Z+Ldz3dkhGCJj/ApKSKw4IxaQ8boBwA4AAAAOAAAAAIAAABFAAA0kCIAAEAG zpsKgAEGCoAGAb9p4bmPrvSrhXFgvIAQgYQZ6gAAAQEICiONvBcel7Vg4IxaQxL+BwBgAAAA BAUAAAIAAABFAAUA0MoAAEAGiScKgAYBCoABBuG5v2mFcWC8j670q4AQgYSMwQAAAQEICh6X tWEjjbvueOBkByW09aKDNf+tNY5RtHcfSnfvyvpSv+49LHWtg+uthngSgsh0heCMWkOLEwgA YAAAAAQFAAACAAAARQAFAKWRAABABrRgCoAGAQqAAQbhub9phXFliI+u9KuAEIGEKZ4AAAEB CAoel7VpI4279zQCpt00IoJsK6t1mUsKl015/FAByl7OqGErVRrnweX/6fF7WdMVFy3gjFpD nBMIADgAAAA4AAAAAgAAAEUAADRFLQAAQAYZkQqAAQYKgAYBv2nhuY+u9KuFcWpUgBB/HhKs AAABAQgKI428Ih6XtWHgjFpDMV8IAGAAAAAEBQAAAgAAAEUABQDswwAAQAZtLgqABgEKgAEG 4bm/aYVxalSPrvSrgBCBhAK1AAABAQgKHpe1fiONvA1SpqvmAPtiyVq5XQ8QQk4EdCCmT+Ch dRV1/VJ3n14ymJxLO+fnsu5H4IxaQ1tfCAA4AAAAOAAAAAIAAABFAAA0q1YAAEAGs2cKgAEG CoAGAb9p4bmPrvSrhXFvIIAQgYQLSQAAAQEICiONvDYel7V+4IxaQyV1CABgAAAABAUAAAIA AABFAAUAXNgAAEAG/RkKgAYBCoABBuG5v2mFcW8gj670q4AQgYR6BwAAAQEICh6XtX8jjbwN etBjWt0HppaKypc9aWXHOmUNihjCOkSj4ItVTZ/DT1MT449RzL7vPuCMWkOfiggAYAAAAAQF AAACAAAARQAFADKGAABABidsCoAGAQqAAQbhub9phXFz7I+u9KuAEIGEUOIAAAEBCAoel7WJ I428F/bpjJcDHehFMIgPfrONc1KCUYJSgdWcO8STTiJLjTGs763WmNPVgYjgjFpDsYoIADgA AAA4AAAAAgAAAEUAADRCNQAAQAYciQqAAQYKgAYBv2nhuY+u9KuFcXi4gBB/HgQLAAABAQgK I428QR6XtX/gjFpDFLUIAGAAAAAEBQAAAgAAAEUABQCS7wAAQAbHAgqABgEKgAEG4bm/aYVx eLiPrvSrgBCBhPh8AAABAQgKHpe1lSONvCJ0aBTKqpwFqeabW4eJaonrlBq7v5IiU0eLIKqm 4o+tRb1RMtk3Vxe44IxaQ0m1CAA4AAAAOAAAAAIAAABFAAA0IUgAAEAGPXYKgAEGCoAGAb9p 4bmPrvSrhXF9hIAQgYT8twAAAQEICiONvEwel7WV4IxaQ43KCABgAAAABAUAAAIAAABFAAUA yv8AAEAGjvIKgAYBCoABBuG5v2mFcX2Ej670q4AQgYQPlgAAAQEICh6XtZUjjbwizaTRsCPg eVYw8KvFNLHe53Ddd7SropdgL9GhN5PsyRPDsHeOfgVxu+CMWkOD4AgAYAAAAAQFAAACAAAA RQAFAL2yAABABpw/CoAGAQqAAQbhub9phXGCUI+u9KuAEIGEpXQAAAEBCAoel7WVI428Iopt PxKaTHmWZbher2X7Q/L7LLW/txL+ABWSAPfVrxt0Li/B+ol+KJDgjFpDleAIADgAAAA4AAAA AgAAAEUAADRzFwAAQAbrpgqAAQYKgAYBv2nhuY+u9KuFcYccgBB/HvV6AAABAQgKI428Vx6X tZXgjFpDsCoJAGAAAAAEBQAAAgAAAEUABQC9+QAAQAab+AqABgEKgAEG4bm/aYVxhxyPrvSr gBCBhFOhAAABAQgKHpe1syONvEEvS8cxFW11wVa7dU/Al/Xdw/A0UqMB7w89Tr7OctxxX9NX Wd8EIX0I4IxaQ+YqCQA4AAAAOAAAAAIAAABFAAA0uigAAEAGpJUKgAEGCoAGAb9p4bmPrvSr hXGL6IAQgYTuFwAAAQEICiONvGoel7Wz4IxaQ6ZACQBgAAAABAUAAAIAAABFAAUAE5oAAEAG RlgKgAYBCoABBuG5v2mFcYvoj670q4AQgYQr8wAAAQEICh6XtbMjjbxBzoOAHsiAnszIduCY 3Fa9l6zZKD+SRJ+TTh5osZUflQA0ZbrIHcBDIeCMWkMeVgkAYAAAAAQFAAACAAAARQAFAHuS AABABt5fCoAGAQqAAQbhub9phXGQtI+u9KuAEIGEZm8AAAEBCAoel7WzI428QffOyicPcrUT D1cteUfs5Uadsr5K5PWGyKBR8Zu6pevCaPL3gAUbdejgjFpDMFYJADgAAAA4AAAAAgAAAEUA ADTgegAAQAZ+QwqAAQYKgAYBv2nhuY+u9KuFcZWAgBB/HubaAAABAQgKI428dR6XtbPgjFpD GmwJAGAAAAAEBQAAAgAAAEUABQCYkAAAQAbBYQqABgEKgAEG4bm/aYVxlYCPrvSrgBCBhDrj AAABAQgKHpe1viONvEw31W59D/bvMlGyirkxK93PZdafCx+p8wEeqTXzElS3BoPnxSgXN4+I 4IxaQ0ZsCQA4AAAAOAAAAAIAAABFAAA0yQsAAEAGlbIKgAEGCoAGAb9p4bmPrvSrhXGaTIAQ gYTflwAAAQEICiONvHsel7W+4IxaQ42BCQBgAAAABAUAAAIAAABFAAUAzvAAAEAGiwEKgAYB CoABBuG5v2mFcZpMj670q4AQgYTIqwAAAQEICh6XtckjjbxXUYdTP7izIefYIGJL+ErnkP47 VHFV65ghWbe2LBt3DAQ3euoyd+1dIeCMWkODlwkAYAAAAAQFAAACAAAARQAFAJaKAABABsNn CoAGAQqAAQbhub9phXGfGI+u9KuAEIGEyIQAAAEBCAoel7XJI428V010DYFmxVPY/HwMumCP cX83n5oim8xBuOxCBfEGlMvGwBNQxIl11+rgjFpDlJcJADgAAAA4AAAAAgAAAEUAADSvUwAA QAavagqAAQYKgAYBv2nhuY+u9KuFcaPkgBB/HthPAAABAQgKI428hh6XtcngjFpDvcsJAGAA AAAEBQAAAgAAAEUABQCi3gAAQAa3EwqABgEKgAEG4bm/aYVxo+SPrvSrgBCBhPKsAAABAQgK Hpe13CONvGrOxVvFwf3I9btcD9mEH2bHLCpqca++WGUIDO6TYMcLQlBdpQBdm7tb4IxaQ+zL CQA4AAAAOAAAAAIAAABFAAA0zgsAAEAGkLIKgAEGCoAGAb9p4bmPrvSrhXGosIAQgYTQ/QAA AQEICiONvJMel7Xc4IxaQzD2CQBgAAAABAUAAAIAAABFAAUAzLAAAEAGjUEKgAYBCoABBuG5 v2mFcaiwj670q4AQgYQjVAAAAQEICh6Xtecjjbx1fAZDSiI/E+CF4GwvztAIVt9e9LQ4iVKf xEBFykBQvzNeVyUKMXKnHOCMWkOoCwoAYAAAAAQFAAACAAAARQAFACPvAABABjYDCoAGAQqA AQbhub9phXGtfI+u9KuAEIGEdrcAAAEBCAoel7XnI428dQiPKHxQSmEce7DkvmahOewW7VKj DC7EMd8SwZ2zEQeib15QdSPBCS3gjFpDuQsKADgAAAA4AAAAAgAAAEUAADSlJwAAQAa5lgqA AQYKgAYBv2nhuY+u9KuFcbJIgBB/HsmwAAABAQgKI428ox6XtefgjFpDniEKAGAAAAAEBQAA AgAAAEUABQAn1gAAQAYyHAqABgEKgAEG4bm/aYVxskiPrvSrgBCBhEaqAAABAQgKHpe17SON vHs80vSNyepjfwd8PIdx1KJ887gmIWRAooxiwTG9wbST2/Wg+XkEseuo4IxaQ8khCgA4AAAA OAAAAAIAAABFAAA05DUAAEAGeogKgAEGCoAGAb9p4bmPrvSrhXG3FIAQgYTCcgAAAQEICiON vKkel7Xt4IxaQ8BECgBgAAAABAUAAAIAAABFAAUApK0AAEAGtUQKgAYBCoABBuG5v2mFcbcU j670q4AQgYTLawAAAQEICh6XtfgjjbyGTAD5gy41WQp6mWoJ8PPJoTyJ1huDYCwRUzz4yP43 WU/jYdTl5/k/WuCMWkO3WgoAYAAAAAQFAAACAAAARQAFANiGAABABoFrCoAGAQqAAQbhub9p hXG74I+u9KuAEIGEFaMAAAEBCAoel7X4I428hrCrtFAcHgopmvY5bB3A/pUDhzHaie8lUWW7 IqtIrvQJOlPzIgtSCQDgjFpDyVoKADgAAAA4AAAAAgAAAEUAADTQRQAAQAaOeAqAAQYKgAYB v2nhuY+u9KuFccCsgBB/HrsmAAABAQgKI428uB6XtfjgjFpDMHAKAGAAAAAEBQAAAgAAAEUA BQB1wAAAQAbkMQqABgEKgAEG4bm/aYVxwKyPrvSrgBCBhIHjAAABAQgKHpe2BSONvJMk8Dmb Vg/m0ugiA5yuRcS/SqXYkjSJ2f/7nQ0KaKLJI0nNQz/z2aun4IxaQ2dwCgA4AAAAOAAAAAIA AABFAAA0kikAAEAGzJQKgAEGCoAGAb9p4bmPrvSrhXHFeIAQgYSz4gAAAQEICiONvL0el7YF 4IxaQ7mrCgBgAAAABAUAAAIAAABFAAUAPaMAAEAGHE8KgAYBCoABBuG5v2mFccV4j670q4AQ gYS5nwAAAQEICh6XthUjjbyjxIcxMZF6wSAPav5d3cwQcgrISIINNImtA6+PPURVqJAkfKns gGz4DOCMWkMywQoAYAAAAAQFAAACAAAARQAFACnBAABABjAxCoAGAQqAAQbhub9phXHKRI+u 9KuAEIGE8uwAAAEBCAoel7YVI428o49iS8qIYDH2kDt0jDzBjUYjIxzESY8q/AfXe8V/MKrv 38X6MGYaFsDgjFpDQ8EKADgAAAA4AAAAAgAAAEUAADSuXAAAQAawYQqAAQYKgAYBv2nhuY+u 9KuFcc8QgBB/HqyLAAABAQgKI4280h6XthXgjFpDLdcKAGAAAAAEBQAAAgAAAEUABQD7wQAA QAZeMAqABgEKgAEG4bm/aYVxzxCPrvSrgBCBhKLMAAABAQgKHpe2GyONvKmbkKvqzSQ3Adth JsxxAVsYEVGewNf0BkYv196hI8tD8IBtchugERQ+4IxaQ2vXCgA4AAAAOAAAAAIAAABFAAA0 LmQAAEAGMFoKgAEGCoAGAb9p4bmPrvSrhXHT3IAQgYSlTQAAAQEICiONvNgel7Yb4IxaQ5fg CgAsAAAALAAAAAIAAABFAAAoPbUAAEAGIRUKgAYBCoABBuG5v2mFccV4AAAAAFAEAACnzAAA 4IxaQyYvCwAsAAAALAAAAAIAAABFAAAoX6QAAEAG/yUKgAYBCoABBuG5v2mFcc8QAAAAAFAE AACeNAAA4IxaQ4xHCwAsAAAALAAAAAIAAABFAAAo1vUAAEAGh9QKgAYBCoABBuG5v2mFcdPc AAAAAFAEAACZaAAA --------------070201090605020103020807-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 20:35:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0058516A41F for ; Sat, 22 Oct 2005 20:35:12 +0000 (GMT) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [200.46.204.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3886843D46 for ; Sat, 22 Oct 2005 20:35:12 +0000 (GMT) (envelope-from mgrooms@shrew.net) Received: from hole.shrew.net (66-90-165-114.dyn.grandenetworks.net [66.90.165.114]) by shrew.net (Postfix) with ESMTP id F15DF981CB1; Sat, 22 Oct 2005 18:33:31 +0000 (GMT) Received: from [10.22.200.21] ([10.22.200.21]) by hole.shrew.net (8.13.4/8.13.4) with ESMTP id j9MIXSqb077017; Sat, 22 Oct 2005 13:33:30 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-ID: <435A85F7.3000909@shrew.net> Date: Sat, 22 Oct 2005 13:33:27 -0500 From: Matthew Grooms User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: volker@vwsoft.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (hole.shrew.net [66.90.165.114]); Sat, 22 Oct 2005 13:33:30 -0500 (CDT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on hole.shrew.net Cc: freebsd-net@freebsd.org Subject: IPSec tcp session stalling ( me too ) ... 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, 22 Oct 2005 20:35:13 -0000 Volker, I have noticed the same problem. In my case, it only seems to happen when the traffic is being forwarded across interfaces and pf or ipfw is enabled. I use purely IPSEC so I would agree that GRE isn't the problem. This behavior is 100% reproducible for me. If traffic is forwarded from the host providing the ESP protection or if the firewall package is disabled, the problem goes away. Just some data points. I don't recall seeing this ever happen on 4.x + ipfw. I experienced this on early 5.x + ipfw, late 5.x + pf and 6.x + pf. I believe the ipfw versions I tested were prior to the pfil hooks conversion. For example ... NODE 1 sftp client NODE 2 sftp server IPSEC policy requires ESP protection from NODE 1 or VPN A to NODE 2 NODE 1 ------ VPN A ===== VPN B ----- NODE 2 1) NODE 1 <-> NODE 2 sftp via IPSEC pf enabled, traffic stalls 2) NODE 1 <-> NODE 2 sftp via IPSEC pf disabled, no problems 3) VPN A <-> NODE 2 sftp via IPSEC pf enabled, no problems NOTE : TCP protocol is irrelevant. Haven't tried UDP. tcpdump from VPN A internal interface in the (1) case ... tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl1, link-type EN10MB (Ethernet), capture size 96 bytes 12:47:02.673536 IP 10.22.200.21.1223 > 10.20.10.141.ssh: S 929298208:929298208(0) win 16384 12:47:02.714815 IP 10.20.10.141.ssh > 10.22.200.21.1223: S 4112220692:4112220692(0) ack 929298209 win 5840 12:47:02.715005 IP 10.22.200.21.1223 > 10.20.10.141.ssh: . ack 1 win 17520 12:47:04.390884 IP 10.20.10.141.ssh > 10.22.200.21.nerv: P 4052971969:4052972505(536) ack 992811526 win 6432 12:47:04.391082 IP 10.22.200.21.nerv > 10.20.10.141.ssh: . ack 536 win 16319 12:47:06.312301 IP 10.20.10.141.ssh > 10.22.200.21.1223: S 4112220692:4112220692(0) ack 929298209 win 5840 12:47:06.312418 IP 10.22.200.21.1223 > 10.20.10.141.ssh: . ack 1 win 17520 12:47:12.311382 IP 10.20.10.141.ssh > 10.22.200.21.1223: S 4112220692:4112220692(0) ack 929298209 win 5840 12:47:12.311492 IP 10.22.200.21.1223 > 10.20.10.141.ssh: . ack 1 win 17520 12:47:12.349209 IP 10.20.10.141.ssh > 10.22.200.21.1223: P 1:26(25) ack 1 win 5840 12:47:12.349463 IP 10.22.200.21.1223 > 10.20.10.141.ssh: P 1:38(37) ack 26 win 17495 12:47:15.342481 IP 10.20.10.141.ssh > 10.22.200.21.1223: P 1:26(25) ack 1 win 5840 12:47:15.342592 IP 10.22.200.21.1223 > 10.20.10.141.ssh: . ack 26 win 17495 12:47:15.530728 IP 10.22.200.21.1223 > 10.20.10.141.ssh: P 1:446(445) ack 26 win 17495 12:47:22.093189 IP 10.22.200.21.1223 > 10.20.10.141.ssh: P 1:446(445) ack 26 win 17495 12:47:22.140791 IP 10.20.10.141.ssh > 10.22.200.21.1223: . ack 446 win 6432 12:47:22.141931 IP 10.20.10.141.ssh > 10.22.200.21.1223: P 26:666(640) ack 446 win 6432 12:47:22.142232 IP 10.22.200.21.1223 > 10.20.10.141.ssh: P 446:462(16) ack 666 win 16855 12:47:28.136807 IP 10.20.10.141.ssh > 10.22.200.21.1223: P 26:666(640) ack 446 win 6432 12:47:28.137018 IP 10.22.200.21.1223 > 10.20.10.141.ssh: . ack 666 win 16855 12:47:35.218016 IP 10.22.200.21.1223 > 10.20.10.141.ssh: P 446:462(16) ack 666 win 16855 tcpdump from VPN A internal interface in the (2) case ... root@hole# tcpdump -i xl1 src or dst 10.20.10.141 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl1, link-type EN10MB (Ethernet), capture size 96 bytes 12:58:36.411839 IP 10.22.200.21.1228 > 10.20.10.141.ssh: S 3459356125:3459356125(0) win 16384 12:58:36.452844 IP 10.20.10.141.ssh > 10.22.200.21.1228: S 548348284:548348284(0) ack 3459356126 win 5840 12:58:36.452954 IP 10.22.200.21.1228 > 10.20.10.141.ssh: . ack 1 win 17520 12:58:40.048592 IP 10.20.10.141.ssh > 10.22.200.21.1228: S 548348284:548348284(0) ack 3459356126 win 5840 12:58:40.048693 IP 10.22.200.21.1228 > 10.20.10.141.ssh: . ack 1 win 17520 12:58:40.086207 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 1:26(25) ack 1 win 5840 12:58:40.086452 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 1:38(37) ack 26 win 17495 12:58:40.120738 IP 10.20.10.141.ssh > 10.22.200.21.1228: . ack 38 win 5840 12:58:40.120915 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 38:446(408) ack 26 win 17495 12:58:40.124873 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 26:666(640) ack 38 win 5840 12:58:40.199077 IP 10.20.10.141.ssh > 10.22.200.21.1228: . ack 446 win 6432 12:58:40.199198 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 446:462(16) ack 666 win 16855 12:58:40.237038 IP 10.20.10.141.ssh > 10.22.200.21.1228: . ack 462 win 6432 12:58:40.245737 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 666:1202(536) ack 462 win 6432 12:58:40.317230 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 462:990(528) ack 1202 win 16319 12:58:40.390865 IP 10.20.10.141.ssh > 10.22.200.21.1228: . ack 990 win 7504 12:58:40.544484 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 1202:2242(1040) ack 990 win 7504 12:58:40.594600 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 990:1006(16) ack 2242 win 17520 12:58:40.628544 IP 10.20.10.141.ssh > 10.22.200.21.1228: . ack 1006 win 7504 12:58:40.628660 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 1006:1054(48) ack 2242 win 17520 12:58:40.663963 IP 10.20.10.141.ssh > 10.22.200.21.1228: . ack 1054 win 7504 12:58:40.664821 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 2242:2290(48) ack 1054 win 7504 12:58:40.665010 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 1054:1118(64) ack 2290 win 17472 12:58:40.723227 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 2290:2370(80) ack 1118 win 7504 12:58:40.723421 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 1118:1198(80) ack 2370 win 17392 12:58:40.783036 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 2370:2402(32) ack 1198 win 7504 12:58:40.783226 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 1198:1262(64) ack 2402 win 17360 12:58:40.817686 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 2402:2450(48) ack 1262 win 7504 12:58:40.817926 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 1262:1342(80) ack 2450 win 17312 12:58:40.856225 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 2450:2482(32) ack 1342 win 7504 12:58:40.856392 IP 10.22.200.21.1228 > 10.20.10.141.ssh: P 1342:1390(48) ack 2482 win 17280 12:58:40.903573 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 2482:2562(80) ack 1390 win 7504 12:58:40.903921 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 2562:2690(128) ack 1390 win 7504 12:58:40.904061 IP 10.22.200.21.1228 > 10.20.10.141.ssh: . ack 2690 win 17072 12:58:40.942770 IP 10.20.10.141.ssh > 10.22.200.21.1228: P 2690:2738(48) ack 1390 win 7504 12:58:41.088509 IP 10.22.200.21.1228 > 10.20.10.141.ssh: . ack 2738 win 17024 Sorry in advance for not posting as a reply to the original message. I don't subscribe to the list. Just wanted to substantiate Volkers findings. Hope this helps, Matthew Grooms From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 20:51:52 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FE7A16A449 for ; Sat, 22 Oct 2005 20:51:52 +0000 (GMT) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [200.46.204.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id C63FF43D45 for ; Sat, 22 Oct 2005 20:51:51 +0000 (GMT) (envelope-from mgrooms@shrew.net) Received: from hole.shrew.net (66-90-165-114.dyn.grandenetworks.net [66.90.165.114]) by shrew.net (Postfix) with ESMTP id D8B38981CDD; Sat, 22 Oct 2005 18:46:07 +0000 (GMT) Received: from [10.22.200.21] ([10.22.200.21]) by hole.shrew.net (8.13.4/8.13.4) with ESMTP id j9MIk7Y0077455; Sat, 22 Oct 2005 13:46:07 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-ID: <435A88EF.6010706@shrew.net> Date: Sat, 22 Oct 2005 13:46:07 -0500 From: Matthew Grooms User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: volker@vwsoft.com References: <435A85F7.3000909@shrew.net> In-Reply-To: <435A85F7.3000909@shrew.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (hole.shrew.net [66.90.165.114]); Sat, 22 Oct 2005 13:46:07 -0500 (CDT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on hole.shrew.net Cc: freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling ( me too ) ... 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, 22 Oct 2005 20:51:52 -0000 Matthew Grooms wrote: > Volker, > > ipfw is enabled. I use purely IPSEC so I would agree that GRE isn't the > problem. This behavior is 100% reproducible for me. If traffic is > forwarded from the host providing the ESP protection or if the Sorry, this should have read ... > problem. This behavior is 100% reproducible for me. If traffic is > originating from the host providing the ESP protection or if the > firewall package is disabled, the problem goes away. > -Matthew From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 20:54:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76D1616A41F; Sat, 22 Oct 2005 20:54:57 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6565E43D53; Sat, 22 Oct 2005 20:54:52 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j9MKsoaq027847; Sat, 22 Oct 2005 20:54:50 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j9MKsoGg027846; Sat, 22 Oct 2005 20:54:50 GMT (envelope-from dunstan) Date: Sat, 22 Oct 2005 20:54:49 +0000 From: "Wojciech A. Koszek" To: Andrew Thompson Message-ID: <20051022205448.GA27824@freebsd.czest.pl> References: <20051020202034.GA4556@freebsd.czest.pl> <20051020202327.GA53753@heff.fud.org.nz> <20051022133735.GA26636@freebsd.czest.pl> <20051022194506.GC62360@heff.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051022194506.GC62360@heff.fud.org.nz> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Dependency between interfaces 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, 22 Oct 2005 20:54:57 -0000 On Sun, Oct 23, 2005 at 08:45:06AM +1300, Andrew Thompson wrote: > On Sat, Oct 22, 2005 at 01:37:35PM +0000, Wojciech A. Koszek wrote: > > On Fri, Oct 21, 2005 at 09:23:27AM +1300, Andrew Thompson wrote: > > > On Thu, Oct 20, 2005 at 08:20:34PM +0000, Wojciech A. Koszek wrote: > > > > Hello, > > > > > > > > [..] > > > > > > Is it still a problem or did you test on a pre r1.26 kernel? > > > > > > > Results from -CURRENT: I got panic if sk/rl modules are loaded, interfaces > > added to bridge0 and these drivers kldunload(8)ed: > > > > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_rl.trace > > http://freebsd.czest.pl/dunstan/FreeBSD/bridge_sk.trace > > > > Can you please try this patch. Funny thing is that I get panic even without your patch and without any operations on bridge interface: could you try to build if_bridge explicitly in src/sys/module/if_bridge, load and unload it without panic? I get page fault in kernel mode. My kernel has INET6 support compiled in (btw, the same box I used to get trace dump). Any hints? -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 22:12:09 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB29316A41F for ; Sat, 22 Oct 2005 22:12:09 +0000 (GMT) (envelope-from mgrooms@shrew.net) Received: from shrew.net (shrew.net [200.46.204.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F98143D46 for ; Sat, 22 Oct 2005 22:12:09 +0000 (GMT) (envelope-from mgrooms@shrew.net) Received: from hole.shrew.net (66-90-165-114.dyn.grandenetworks.net [66.90.165.114]) by shrew.net (Postfix) with ESMTP id 39C95981CB1; Sat, 22 Oct 2005 22:12:04 +0000 (GMT) Received: from [10.22.200.21] ([10.22.200.21]) by hole.shrew.net (8.13.4/8.13.4) with ESMTP id j9MMC39l084605; Sat, 22 Oct 2005 17:12:04 -0500 (CDT) (envelope-from mgrooms@shrew.net) Message-ID: <435AB933.1050609@shrew.net> Date: Sat, 22 Oct 2005 17:12:03 -0500 From: Matthew Grooms User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mv@roq.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (hole.shrew.net [66.90.165.114]); Sat, 22 Oct 2005 17:12:04 -0500 (CDT) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on hole.shrew.net Cc: volker@vwsoft.com, freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling 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, 22 Oct 2005 22:12:09 -0000 Mike & Volker, >Try sending different sized pings or other packet size control utils to >really make sure its not MTU related. >Maybe there is an upstream router thats blocking ICMP fragment packets, >have you ever seen them? try forcing the creation of some. > >Mike I am experiencing the same issue as Volker and tried sending different sized ICMP packets which seems to work fine. I followed up with a telnet connection which quickly stalled. root@hole# tcpdump -i xl1 src or dst 10.20.10.141 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl1, link-type EN10MB (Ethernet), capture size 96 bytes 16:46:01.676879 IP 10.22.200.21 > 10.20.10.141: ICMP echo request, id 512, seq 15872, length 508 16:46:01.722918 IP 10.20.10.141 > 10.22.200.21: ICMP echo reply, id 512, seq 15872, length 508 16:46:02.691200 IP 10.22.200.21 > 10.20.10.141: ICMP echo request, id 512, seq 16128, length 508 16:46:02.739848 IP 10.20.10.141 > 10.22.200.21: ICMP echo reply, id 512, seq 16128, length 508 16:46:07.015667 IP 10.22.200.21 > 10.20.10.141: ICMP echo request, id 512, seq 16384, length 1008 16:46:07.067792 IP 10.20.10.141 > 10.22.200.21: ICMP echo reply, id 512, seq 16384, length 1008 16:46:08.019359 IP 10.22.200.21 > 10.20.10.141: ICMP echo request, id 512, seq 16640, length 1008 16:46:08.093539 IP 10.20.10.141 > 10.22.200.21: ICMP echo reply, id 512, seq 16640, length 1008 16:46:12.119300 IP 10.22.200.21 > 10.20.10.141: ICMP echo request, id 512, seq 16896, length 1480 16:46:12.119308 IP 10.22.200.21 > 10.20.10.141: icmp 16:46:12.197403 IP 10.20.10.141 > 10.22.200.21: ICMP echo reply, id 512, seq 16896, length 1480 16:46:12.197414 IP 10.20.10.141 > 10.22.200.21: icmp 16:46:13.128799 IP 10.22.200.21 > 10.20.10.141: ICMP echo request, id 512, seq 17152, length 1480 16:46:13.128805 IP 10.22.200.21 > 10.20.10.141: icmp 16:46:13.201023 IP 10.20.10.141 > 10.22.200.21: ICMP echo reply, id 512, seq 17152, length 1480 16:46:13.201033 IP 10.20.10.141 > 10.22.200.21: icmp 16:46:26.872047 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: S 579182992:579182992(0) win 16384 16:46:26.941687 IP 10.20.10.141.telnet > 10.22.200.21.rna-lm: S 2118087729:2118087729(0) ack 579182993 win 5840 16:46:26.941800 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: . ack 1 win 17520 16:46:30.537896 IP 10.20.10.141.telnet > 10.22.200.21.rna-lm: S 2118087729:2118087729(0) ack 579182993 win 5840 16:46:30.538000 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: . ack 1 win 17520 16:46:30.577673 IP 10.20.10.141.54127 > 10.22.200.21.auth: S 2118367383:2118367383(0) win 5840 16:46:30.577770 IP 10.22.200.21.auth > 10.20.10.141.54127: R 0:0(0) ack 2118367384 win 0 16:46:30.620047 IP 10.20.10.141.telnet > 10.22.200.21.rna-lm: P 1:13(12) ack 1 win 5840 16:46:30.620242 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: P 1:7(6) ack 13 win 17508 16:46:33.620543 IP 10.20.10.141.telnet > 10.22.200.21.rna-lm: P 1:13(12) ack 1 win 5840 16:46:33.620651 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: . ack 13 win 17508 16:46:33.964246 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: P 1:16(15) ack 13 win 17508 16:46:40.503254 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: P 1:16(15) ack 13 win 17508 16:46:40.538799 IP 10.20.10.141.telnet > 10.22.200.21.rna-lm: . ack 16 win 5840 16:46:40.538887 IP 10.20.10.141.telnet > 10.22.200.21.rna-lm: P 13:22(9) ack 16 win 5840 16:46:40.539062 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: P 16:28(12) ack 22 win 17499 16:46:46.528977 IP 10.20.10.141.telnet > 10.22.200.21.rna-lm: P 13:22(9) ack 16 win 5840 16:46:46.529081 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: . ack 22 win 17499 16:46:53.628188 IP 10.22.200.21.rna-lm > 10.20.10.141.telnet: P 16:38(22) ack 22 win 17499 16:47:05.221888 IP 10.22.200.21.vpvc > 10.20.10.141.telnet: P 1633240875:1633240887(12) ack 1931964537 win 17487 16:47:05.266687 IP 10.20.10.141.telnet > 10.22.200.21.vpvc: P 1:66(65) ack 12 win 5840 16:47:05.267008 IP 10.22.200.21.vpvc > 10.20.10.141.telnet: P 12:15(3) ack 66 win 17422 16:47:05.300951 IP 10.20.10.141.telnet > 10.22.200.21.vpvc: P 66:112(46) ack 15 win 5840 16:47:05.301179 IP 10.22.200.21.vpvc > 10.20.10.141.telnet: P 15:18(3) ack 112 win 17376 16:47:05.379114 IP 10.20.10.141.telnet > 10.22.200.21.vpvc: . ack 18 win 5840 -Matthew From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 23:23:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 040EF16A41F for ; Sat, 22 Oct 2005 23:23:55 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1201A43D45 for ; Sat, 22 Oct 2005 23:23:54 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: pass (tce71.tce85.de: domain of vwsoft.com designates 83.242.63.100 as permitted sender) client-ip=83.242.63.100; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (100-63-242-83.dip.h-tel.de [83.242.63.100]) by tce71.tce85.de (Postfix) with ESMTP id 268CD17120 for ; Sun, 23 Oct 2005 01:24:05 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id C70F35C0F; Sun, 23 Oct 2005 01:23:34 +0200 (CEST) Message-ID: <435AD808.1030701@vwsoft.com> Date: Sun, 23 Oct 2005 01:23:36 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael VInce References: <435A5D9B.7080309@vwsoft.com> <435A900C.3060602@roq.com> In-Reply-To: <435A900C.3060602@roq.com> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Cc: freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling 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, 22 Oct 2005 23:23:55 -0000 Michael, I not that sure if I'm right in checking what you suggested but when trying to do ping hostB from hostA with oversized packets through the IPSec tunnel by: # ping -c 10 -s 12000 10.128.6.1 I'm getting replies easily. While doing that and tcpdump'ing the gif interface, I'm seeing the fragmented packets coming in properly. If that's a reliable check for MTU than the problem should not be MTU related. Is there any other way to check MTU problems by using `ping'? Thanks, Volker On 2005-10-22 20:16, Michael VInce wrote: > Try sending different sized pings or other packet size control utils to > really make sure its not MTU related. > Maybe there is an upstream router thats blocking ICMP fragment packets, > have you ever seen them? try forcing the creation of some. > > Mike > > Volker wrote: > >> Still having the same problem with an IPSec tunnel between FreeBSD 5.4R >> hosts. >> >> Problem description: >> scp session tries to transfer a large file through an IPSec tunnel. The >> file is being transmitted but scp says 'stalled' after 56K (49152 bytes >> file size). The IPSec tunnel itself is still up even after the scp >> abort. Other tcp sessions break, too when sending too much traffic >> through the tunnel. >> >> I've taken a closer look to it and tried to get something useful out of >> the tcpdump but I'm unable to see any errors or I'm misinterpreting >> something. >> >> The connection looks like: >> >> extIP: A.B.C.D >> extIP: E.F.G.H >> host A ------------------ (internet) ------------------ host B >> tunnelIP: 10.128.1.6 tunnelIP: >> 10.128.6.1 >> >> host A just has an external interface (em1) connected to a leased line >> with a fixed IP address (IP-addr A.B.C.D). >> host B has an S-DSL connection at xl0, PPPoE at ng0 (IP-addr. E.F.G.H). >> >> Both hosts are using gif for the IPSec tunnel. >> >> The routing tables (netstat -rnWf inet) are looking good and IMHO the >> MTU is fine. >> >> host A: >> em1: flags=8843 mtu 1500 >> options=b >> inet A.B.C.D netmask 0xfffffff8 broadcast A.B.C.z >> ether 00:c0:9f:46:ec:c7 >> media: Ethernet autoselect (100baseTX ) >> status: active >> gif6: flags=8051 mtu 1280 >> tunnel inet A.B.C.D --> E.F.G.H >> inet 10.128.1.6 --> 10.128.6.1 netmask 0xffffffff >> inet6 fe80::2c0:9fff:fe46:ecc6%gif6 prefixlen 64 scopeid 0x4 >> >> Routing tables (shortened) >> Destination Gateway Flags Refs Use Mtu >> Netif Expire >> default A.B.C.x UGS 2 516686 1500 em1 >> 10.128.1.6 127.0.0.1 UH 0 14 >> 16384 lo0 >> 10.128.6.1 10.128.1.6 UH 0 6017 >> 1280 gif6 >> 127.0.0.1 127.0.0.1 UH 0 31633 >> 16384 lo0 >> A.B.C.x/29 link#2 UC 0 0 1500 em1 >> A.B.C.D 00:c0:9f:46:ec:c7 UHLW 0 112 1500 lo0 >> >> On host B the interfaces and routing tables are looking like: >> xl0: flags=8843 mtu 1500 >> options=8 >> inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255 >> inet6 fe80::260:8ff:fe6c:e73c%xl0 prefixlen 64 scopeid 0x1 >> ether 00:60:08:6c:e7:3c >> media: Ethernet 10baseT/UTP (10baseT/UTP ) >> status: active >> gif1: flags=8051 mtu 1280 >> tunnel inet E.F.G.H --> A.B.C.D >> inet6 fe80::260:8ff:fe6c:e73c%gif1 prefixlen 64 scopeid 0x4 >> inet 10.128.6.1 --> 10.128.1.6 netmask 0xffffffff >> ng0: flags=88d1 mtu 1456 >> inet E.F.G.H --> 217.5.98.186 netmask 0xffffffff >> >> Routing tables (shortened) >> Destination Gateway Flags Refs Use Mtu >> Netif Expire >> 0 link#1 UC 0 0 1500 >> xl0 => >> default 217.5.98.186 UGS 1 38474 >> 1456 ng0 >> 10.128.1.6 10.128.6.1 UH 4 2196 >> 1280 gif1 >> 127.0.0.1 127.0.0.1 UH 0 80424 >> 16384 lo0 >> 217.5.98.186 E.F.G.H UH 1 0 1456 ng0 >> E.F.G.H lo0 UHS 0 0 16384 lo0 >> >> While trying to fetch a file by scp on host A (receiver) from host B >> (sender), I captured the following tcpdump on host B: >> >> tcpdump -netttvvi gif1: >> >> >>> 000023 AF 2 1280: IP (tos 0x8, ttl 64, id 13202, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 43864:45092(1228) ack 1330 win 33156 >> 565002838> >>> 000207 AF 2 1280: IP (tos 0x8, ttl 64, id 52187, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 45092:46320(1228) ack 1330 win 33156 >> 565002838> >>> 000220 AF 2 1280: IP (tos 0x8, ttl 64, id 33774, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 46320:47548(1228) ack 1330 win 33156 >> 565002838> >>> 003524 AF 2 52: IP (tos 0x8, ttl 64, id 42063, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 38952 win 33156 >>> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 48541, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 47548:48776(1228) ack 1330 win 33156 >> 565002844> >>> 011203 AF 2 52: IP (tos 0x8, ttl 64, id 60517, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 41408 win 32542 >>> 000058 AF 2 1280: IP (tos 0x8, ttl 64, id 15798, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 48776:50004(1228) ack 1330 win 33156 >> 565002855> >>> 000246 AF 2 1280: IP (tos 0x8, ttl 64, id 31721, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 50004:51232(1228) ack 1330 win 33156 >> 565002855> >>> 005147 AF 2 52: IP (tos 0x8, ttl 64, id 22347, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 42636 win 33156 >>> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 61057, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 51232:52460(1228) ack 1330 win 33156 >> 565002861> >>> 020769 AF 2 52: IP (tos 0x8, ttl 64, id 27692, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 45092 win 32542 >>> 000027 AF 2 1280: IP (tos 0x8, ttl 64, id 64167, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 52460:53688(1228) ack 1330 win 33156 >> 565002881> >>> 000209 AF 2 1280: IP (tos 0x8, ttl 64, id 45457, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 53688:54916(1228) ack 1330 win 33156 >> 565002881> >>> 005260 AF 2 52: IP (tos 0x8, ttl 64, id 53832, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 46320 win 33156 >>> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 3515, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 54916:56144(1228) ack 1330 win 33156 >> 565002887> >>> 011020 AF 2 52: IP (tos 0x8, ttl 64, id 11608, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 48776 win 32542 >>> 000026 AF 2 1280: IP (tos 0x8, ttl 64, id 5848, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 56144:57372(1228) ack 1330 win 33156 >> 565002898> >>> 000211 AF 2 1280: IP (tos 0x8, ttl 64, id 39892, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 57372:58600(1228) ack 1330 win 33156 >> 565002898> >>> 005641 AF 2 52: IP (tos 0x8, ttl 64, id 7943, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 50004 win 33156 >>> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8678, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 58600:59828(1228) ack 1330 win 33156 >> 565002904> >>> 011072 AF 2 52: IP (tos 0x8, ttl 64, id 38257, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 52460 win 32542 >>> 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 12255, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 59828:61056(1228) ack 1330 win 33156 >> 565002915> >>> 000209 AF 2 1280: IP (tos 0x8, ttl 64, id 46257, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 61056:62284(1228) ack 1330 win 33156 >> 565002915> >>> 000222 AF 2 1280: IP (tos 0x8, ttl 64, id 4093, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 62284:63512(1228) ack 1330 win 33156 >> 565002915> >>> 007065 AF 2 52: IP (tos 0x8, ttl 64, id 18720, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 53688 win 33156 >>> 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 38378, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 63512:64740(1228) ack 1330 win 33156 >> 565002922> >>> 011034 AF 2 52: IP (tos 0x8, ttl 64, id 18718, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 56144 win 32542 >>> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8148, offset 0, flags >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>> 64740:65968(1228) ack 1330 win 33156 >> 565002934> >>> 005991 AF 2 52: IP (tos 0x8, ttl 64, id 62285, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 57372 win 33156 >>> 010726 AF 2 52: IP (tos 0x8, ttl 64, id 1549, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 59828 win 32542 >>> 005670 AF 2 52: IP (tos 0x8, ttl 64, id 61504, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 61056 win 33156 >>> 011260 AF 2 52: IP (tos 0x8, ttl 64, id 32633, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 63512 win 32542 >>> 005510 AF 2 52: IP (tos 0x8, ttl 64, id 54614, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 64740 win 33156 >>> 104909 AF 2 52: IP (tos 0x8, ttl 64, id 50471, offset 0, flags >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>> 1330:1330(0) ack 65968 win 33156 >>> >> >> >> tcpdump -netttvvi ng0 host A.B.C.D: >> >> >>> 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 25895, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10b) >>> 011042 AF 2 128: IP (tos 0x8, ttl 61, id 5786, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf0) >>> 000226 AF 2 1352: IP (tos 0x8, ttl 64, id 36701, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10c) >>> 000216 AF 2 1352: IP (tos 0x8, ttl 64, id 8789, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10d) >>> 004853 AF 2 128: IP (tos 0x8, ttl 61, id 17128, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf1) >>> 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 34888, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10e) >>> 018747 AF 2 128: IP (tos 0x8, ttl 61, id 14828, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf2) >>> 000248 AF 2 1352: IP (tos 0x8, ttl 64, id 34356, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10f) >>> 000223 AF 2 1352: IP (tos 0x8, ttl 64, id 34151, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x110) >>> 005030 AF 2 128: IP (tos 0x8, ttl 61, id 45476, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf3) >>> 000228 AF 2 1352: IP (tos 0x8, ttl 64, id 39765, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x111) >>> 011247 AF 2 128: IP (tos 0x8, ttl 61, id 63692, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf4) >>> 000226 AF 2 1352: IP (tos 0x8, ttl 64, id 29240, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x112) >>> 000222 AF 2 1352: IP (tos 0x8, ttl 64, id 43306, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x113) >>> 005663 AF 2 128: IP (tos 0x8, ttl 61, id 32980, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf5) >>> 000228 AF 2 1352: IP (tos 0x8, ttl 64, id 56920, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x114) >>> 010190 AF 2 128: IP (tos 0x8, ttl 61, id 3206, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf6) >>> 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 4655, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x115) >>> 000215 AF 2 1352: IP (tos 0x8, ttl 64, id 62740, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x116) >>> 000203 AF 2 1352: IP (tos 0x8, ttl 64, id 35642, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x117) >>> 006875 AF 2 128: IP (tos 0x8, ttl 61, id 37801, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf7) >>> 000234 AF 2 1352: IP (tos 0x8, ttl 64, id 41803, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x118) >>> 010651 AF 2 128: IP (tos 0x8, ttl 61, id 54256, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf8) >>> 000235 AF 2 1352: IP (tos 0x8, ttl 64, id 30732, offset 0, flags >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x119) >>> 007913 AF 2 128: IP (tos 0x8, ttl 61, id 7647, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf9) >>> 011166 AF 2 128: IP (tos 0x8, ttl 61, id 58037, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfa) >>> 005483 AF 2 128: IP (tos 0x8, ttl 61, id 65275, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfb) >>> 011250 AF 2 128: IP (tos 0x8, ttl 61, id 47289, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfc) >>> 005505 AF 2 128: IP (tos 0x8, ttl 61, id 203, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfd) >>> 104747 AF 2 128: IP (tos 0x8, ttl 61, id 45263, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfe) >>> 8. 338674 AF 2 128: IP (tos 0x8, ttl 61, id 36351, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xff) >>> 319992 AF 2 128: IP (tos 0x8, ttl 61, id 18085, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x100) >>> 441837 AF 2 128: IP (tos 0x8, ttl 61, id 58323, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x101) >>> 684077 AF 2 128: IP (tos 0x8, ttl 61, id 35487, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x102) >>> 1. 167602 AF 2 128: IP (tos 0x8, ttl 61, id 34442, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x103) >>> 2. 136032 AF 2 128: IP (tos 0x8, ttl 61, id 8345, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x104) >>> 2. 984665 AF 2 128: IP (tos 0x8, ttl 61, id 35456, offset 0, flags >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x105) >>> >> >> >> >>> From what I'm seeing host B just stops sending without any reason. At >> >> least I don't see any fragmented packets. The only thing I've seen is >> some packets doesn't get ack'ed by the receiver. >> >> These packets never get ack'ed: >> 46320:47548(1228) >> 50004:51232(1228) >> 53688:54916(1228) >> 57372:58600(1228) >> 61056:62284(1228) >> >> On host A I dumped the following: >> >> tcpdump -netttvvi gif6 >> >> >>> 1129985378.941282 AF 2 52: IP (tos 0x8, ttl 64, id 41637, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 45092 win 32542 >> 490857876> >>> 1129985378.952628 AF 2 1280: IP (tos 0x8, ttl 64, id 14004, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 45092:46320(1228) ack 1330 win 33156 >> 574090210> >>> 1129985378.952657 AF 2 52: IP (tos 0x8, ttl 64, id 23243, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 46320 win 33156 >> 490857901> >>> 1129985378.958250 AF 2 1280: IP (tos 0x8, ttl 64, id 4306, offset 0, >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 46320:47548(1228) ack 1330 win 33156 >> 574090210> >>> 1129985378.971118 AF 2 1280: IP (tos 0x8, ttl 64, id 33534, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 47548:48776(1228) ack 1330 win 33156 >> 574090229> >>> 1129985378.971137 AF 2 52: IP (tos 0x8, ttl 64, id 60095, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 48776 win 32542 >> 490857901> >>> 1129985378.982488 AF 2 1280: IP (tos 0x8, ttl 64, id 11459, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 48776:50004(1228) ack 1330 win 33156 >> 574090240> >>> 1129985378.982516 AF 2 52: IP (tos 0x8, ttl 64, id 33184, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 50004 win 33156 >> 490857931> >>> 1129985378.987989 AF 2 1280: IP (tos 0x8, ttl 64, id 54180, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 50004:51232(1228) ack 1330 win 33156 >> 574090240> >>> 1129985378.994231 AF 2 1280: IP (tos 0x8, ttl 64, id 24535, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 51232:52460(1228) ack 1330 win 33156 >> 574090251> >>> 1129985378.994250 AF 2 52: IP (tos 0x8, ttl 64, id 30647, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 52460 win 32542 >> 490857931> >>> 1129985379.012101 AF 2 1280: IP (tos 0x8, ttl 64, id 61397, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 52460:53688(1228) ack 1330 win 33156 >> 574090270> >>> 1129985379.012132 AF 2 52: IP (tos 0x8, ttl 64, id 60550, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 53688 win 33156 >> 490857960> >>> 1129985379.017754 AF 2 1280: IP (tos 0x8, ttl 64, id 28408, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 53688:54916(1228) ack 1330 win 33156 >> 574090270> >>> 1129985379.023720 AF 2 1280: IP (tos 0x8, ttl 64, id 27558, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 54916:56144(1228) ack 1330 win 33156 >> 574090281> >>> 1129985379.023741 AF 2 52: IP (tos 0x8, ttl 64, id 21502, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 56144 win 32542 >> 490857961> >>> 1129985379.035333 AF 2 1280: IP (tos 0x8, ttl 64, id 18885, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 56144:57372(1228) ack 1330 win 33156 >> 574090293> >>> 1129985379.035362 AF 2 52: IP (tos 0x8, ttl 64, id 59875, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 57372 win 33156 >> 490857984> >>> 1129985379.040830 AF 2 1280: IP (tos 0x8, ttl 64, id 37252, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 57372:58600(1228) ack 1330 win 33156 >> 574090293> >>> 1129985379.046576 AF 2 1280: IP (tos 0x8, ttl 64, id 18349, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 58600:59828(1228) ack 1330 win 33156 >> 574090293> >>> 1129985379.046595 AF 2 52: IP (tos 0x8, ttl 64, id 43697, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 59828 win 32542 >> 490857984> >>> 1129985379.064961 AF 2 1280: IP (tos 0x8, ttl 64, id 38300, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 59828:61056(1228) ack 1330 win 33156 >> 574090322> >>> 1129985379.064993 AF 2 52: IP (tos 0x8, ttl 64, id 47539, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 61056 win 33156 >> 490858013> >>> 1129985379.070688 AF 2 1280: IP (tos 0x8, ttl 64, id 30345, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 61056:62284(1228) ack 1330 win 33156 >> 574090322> >>> 1129985379.076184 AF 2 1280: IP (tos 0x8, ttl 64, id 37536, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 62284:63512(1228) ack 1330 win 33156 >> 574090322> >>> 1129985379.076202 AF 2 52: IP (tos 0x8, ttl 64, id 34201, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 63512 win 32542 >> 490858013> >>> 1129985379.081680 AF 2 1280: IP (tos 0x8, ttl 64, id 20637, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 63512:64740(1228) ack 1330 win 33156 >> 574090334> >>> 1129985379.081709 AF 2 52: IP (tos 0x8, ttl 64, id 59866, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 64740 win 33156 >> 490858025> >>> 1129985379.087678 AF 2 1280: IP (tos 0x8, ttl 64, id 35213, offset >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>> 64740:65968(1228) ack 1330 win 33156 >> 574090345> >>> 1129985379.186906 AF 2 52: IP (tos 0x8, ttl 64, id 2465, offset 0, >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>> sum ok] 1330:1330(0) ack 65968 win 33156 >> 490858036> >>> >> >> >> tcpdump -netttvvi em1 host E.F.G.H >> >> >>> 1129985379.064825 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 45003, offset 0, >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: >>> ESP(spi=0x0e0dffaa,seq=0x3e) >>> 1129985379.065024 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>> IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 1195, offset 0, >>> flags [none], length: 128) A.B.C.D > E.F.G.H: >>> ESP(spi=0x029a41b4,seq=0x2f) >>> 1129985379.070572 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 36820, offset 0, >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: >>> ESP(spi=0x0e0dffaa,seq=0x3f) >>> 1129985379.076069 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 44971, offset 0, >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: >>> ESP(spi=0x0e0dffaa,seq=0x40) >>> 1129985379.076233 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>> IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 56964, offset 0, >>> flags [none], length: 128) A.B.C.D > E.F.G.H: >>> ESP(spi=0x029a41b4,seq=0x30) >>> 1129985379.081565 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 24742, offset 0, >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: >>> ESP(spi=0x0e0dffaa,seq=0x41) >>> 1129985379.081741 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>> IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 9390, offset 0, >>> flags [none], length: 128) A.B.C.D > E.F.G.H: >>> ESP(spi=0x029a41b4,seq=0x31) >>> 1129985379.087562 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 48065, offset 0, >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: >>> ESP(spi=0x0e0dffaa,seq=0x42) >>> 1129985379.186945 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>> IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 36315, offset 0, >>> flags [none], length: 128) A.B.C.D > E.F.G.H: >>> ESP(spi=0x029a41b4,seq=0x32) >>> >> >> >> If I'm not misleaded, this also doesn't show any errors except the >> missing ack's. host B just stops sending. If there's an ack missing, >> doesn't have the sending host to just repeat the un-ack'ed packet? >> >> The IPSec tunnel does not die. Even shortly after the (scp) transfer >> stalls the tunnel itself is still usable (for small amounts of data). To >> make it more worse, when disabling pf at the senders side, the transfer >> works. I've tripple checked pflog for denied packets on both sides but >> pf didn't filter any packets out. >> >> When disabling the IPSec rules using `setkey -F; setkey -FP' on the >> tunnel for a moment, the scp transfer does not stall. So it's not a gif >> issue. >> >> It doesn't seem to be an MTU issue (pf has also the rule 'scrub in/out >> all no-df'), but what kind of issue is that?? Has anybody ever >> experienced similar things? Or am I misinterpreting the tcpdump output? >> >> >> Any help and hint is appreciated! Without an error message I'm lost. >> >> Volker >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 23:40:58 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79B4216A41F for ; Sat, 22 Oct 2005 23:40:58 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9746C43D45 for ; Sat, 22 Oct 2005 23:40:57 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C5CC.dip.t-dialin.net [84.163.197.204] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1ETSyh2HWl-0008BF; Sun, 23 Oct 2005 01:40:43 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Sun, 23 Oct 2005 01:40:27 +0200 User-Agent: KMail/1.8.2 References: <435A5D9B.7080309@vwsoft.com> <435A900C.3060602@roq.com> <435AD808.1030701@vwsoft.com> In-Reply-To: <435AD808.1030701@vwsoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart56501954.DhmgN6n76d"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200510230140.42154.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Volker , Michael VInce Subject: Re: IPSec tcp session stalling 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, 22 Oct 2005 23:40:58 -0000 --nextPart56501954.DhmgN6n76d Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To try something else: Could you guys try to disable SACK on the machines=20 involved? I haven't looked at the dumps as of yet, but that's one simple=20 test that might help to identify the problem. sysctl net.inet.tcp.sack.enable=3D0 On Sunday 23 October 2005 02:23, Volker wrote: > Michael, > > I not that sure if I'm right in checking what you suggested but when > trying to do ping hostB from hostA with oversized packets through the > IPSec tunnel by: > > # ping -c 10 -s 12000 10.128.6.1 > > I'm getting replies easily. > > While doing that and tcpdump'ing the gif interface, I'm seeing the > fragmented packets coming in properly. > > If that's a reliable check for MTU than the problem should not be MTU > related. Is there any other way to check MTU problems by using `ping'? > > Thanks, > > Volker > > On 2005-10-22 20:16, Michael VInce wrote: > > Try sending different sized pings or other packet size control utils to > > really make sure its not MTU related. > > Maybe there is an upstream router thats blocking ICMP fragment packets, > > have you ever seen them? try forcing the creation of some. > > > > Mike > > > > Volker wrote: > >> Still having the same problem with an IPSec tunnel between FreeBSD 5.4R > >> hosts. > >> > >> Problem description: > >> scp session tries to transfer a large file through an IPSec tunnel. The > >> file is being transmitted but scp says 'stalled' after 56K (49152 bytes > >> file size). The IPSec tunnel itself is still up even after the scp > >> abort. Other tcp sessions break, too when sending too much traffic > >> through the tunnel. > >> > >> I've taken a closer look to it and tried to get something useful out of > >> the tcpdump but I'm unable to see any errors or I'm misinterpreting > >> something. > >> > >> The connection looks like: > >> > >> extIP: A.B.C.D > >> extIP: E.F.G.H > >> host A ------------------ (internet) ------------------ host B > >> tunnelIP: 10.128.1.6 tunnelI= P: > >> 10.128.6.1 > >> > >> host A just has an external interface (em1) connected to a leased line > >> with a fixed IP address (IP-addr A.B.C.D). > >> host B has an S-DSL connection at xl0, PPPoE at ng0 (IP-addr. E.F.G.H). > >> > >> Both hosts are using gif for the IPSec tunnel. > >> > >> The routing tables (netstat -rnWf inet) are looking good and IMHO the > >> MTU is fine. > >> > >> host A: > >> em1: flags=3D8843 mtu 1500 > >> options=3Db > >> inet A.B.C.D netmask 0xfffffff8 broadcast A.B.C.z > >> ether 00:c0:9f:46:ec:c7 > >> media: Ethernet autoselect (100baseTX ) > >> status: active > >> gif6: flags=3D8051 mtu 1280 > >> tunnel inet A.B.C.D --> E.F.G.H > >> inet 10.128.1.6 --> 10.128.6.1 netmask 0xffffffff > >> inet6 fe80::2c0:9fff:fe46:ecc6%gif6 prefixlen 64 scopeid 0x4 > >> > >> Routing tables (shortened) > >> Destination Gateway Flags Refs Use Mtu > >> Netif Expire > >> default A.B.C.x UGS 2 516686 1500 em1 > >> 10.128.1.6 127.0.0.1 UH 0 14 > >> 16384 lo0 > >> 10.128.6.1 10.128.1.6 UH 0 6017 > >> 1280 gif6 > >> 127.0.0.1 127.0.0.1 UH 0 31633 > >> 16384 lo0 > >> A.B.C.x/29 link#2 UC 0 0 1500 em1 > >> A.B.C.D 00:c0:9f:46:ec:c7 UHLW 0 112 1500 lo0 > >> > >> On host B the interfaces and routing tables are looking like: > >> xl0: flags=3D8843 mtu 1500 > >> options=3D8 > >> inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255 > >> inet6 fe80::260:8ff:fe6c:e73c%xl0 prefixlen 64 scopeid 0x1 > >> ether 00:60:08:6c:e7:3c > >> media: Ethernet 10baseT/UTP (10baseT/UTP ) > >> status: active > >> gif1: flags=3D8051 mtu 1280 > >> tunnel inet E.F.G.H --> A.B.C.D > >> inet6 fe80::260:8ff:fe6c:e73c%gif1 prefixlen 64 scopeid 0x4 > >> inet 10.128.6.1 --> 10.128.1.6 netmask 0xffffffff > >> ng0: flags=3D88d1 mtu = 1456 > >> inet E.F.G.H --> 217.5.98.186 netmask 0xffffffff > >> > >> Routing tables (shortened) > >> Destination Gateway Flags Refs Use Mtu > >> Netif Expire > >> 0 link#1 UC 0 0 1500 > >> xl0 =3D> > >> default 217.5.98.186 UGS 1 38474 > >> 1456 ng0 > >> 10.128.1.6 10.128.6.1 UH 4 2196 > >> 1280 gif1 > >> 127.0.0.1 127.0.0.1 UH 0 80424 > >> 16384 lo0 > >> 217.5.98.186 E.F.G.H UH 1 0 1456 ng0 > >> E.F.G.H lo0 UHS 0 0 16384 lo0 > >> > >> While trying to fetch a file by scp on host A (receiver) from host B > >> (sender), I captured the following tcpdump on host B: > >> > >> tcpdump -netttvvi gif1: > >>> 000023 AF 2 1280: IP (tos 0x8, ttl 64, id 13202, offset 0, flags > >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 43864:45092(1228) ack 1330 win 33156 >>> 565002838> > >>> 000207 AF 2 1280: IP (tos 0x8, ttl 64, id 52187, offset 0, flags > >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 45092:46320(1228) ack 1330 win 33156 >>> 565002838> > >>> 000220 AF 2 1280: IP (tos 0x8, ttl 64, id 33774, offset 0, flags > >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 46320:47548(1228) ack 1330 win 33156 >>> 565002838> > >>> 003524 AF 2 52: IP (tos 0x8, ttl 64, id 42063, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 38952 win 33156 >>> 481770524> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 48541, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 47548:48776(1228) ack 1330 win 33156 >>> 565002844> > >>> 011203 AF 2 52: IP (tos 0x8, ttl 64, id 60517, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 41408 win 32542 >>> 481770530> 000058 AF 2 1280: IP (tos 0x8, ttl 64, id 15798, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 48776:50004(1228) ack 1330 win 33156 >>> 565002855> > >>> 000246 AF 2 1280: IP (tos 0x8, ttl 64, id 31721, offset 0, flags > >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 50004:51232(1228) ack 1330 win 33156 >>> 565002855> > >>> 005147 AF 2 52: IP (tos 0x8, ttl 64, id 22347, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 42636 win 33156 >>> 481770542> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 61057, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 51232:52460(1228) ack 1330 win 33156 >>> 565002861> > >>> 020769 AF 2 52: IP (tos 0x8, ttl 64, id 27692, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 45092 win 32542 >>> 481770547> 000027 AF 2 1280: IP (tos 0x8, ttl 64, id 64167, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 52460:53688(1228) ack 1330 win 33156 >>> 565002881> > >>> 000209 AF 2 1280: IP (tos 0x8, ttl 64, id 45457, offset 0, flags > >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 53688:54916(1228) ack 1330 win 33156 >>> 565002881> > >>> 005260 AF 2 52: IP (tos 0x8, ttl 64, id 53832, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 46320 win 33156 >>> 481770567> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 3515, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 54916:56144(1228) ack 1330 win 33156 >>> 565002887> > >>> 011020 AF 2 52: IP (tos 0x8, ttl 64, id 11608, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 48776 win 32542 >>> 481770568> 000026 AF 2 1280: IP (tos 0x8, ttl 64, id 5848, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 56144:57372(1228) ack 1330 win 33156 >>> 565002898> > >>> 000211 AF 2 1280: IP (tos 0x8, ttl 64, id 39892, offset 0, flags > >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 57372:58600(1228) ack 1330 win 33156 >>> 565002898> > >>> 005641 AF 2 52: IP (tos 0x8, ttl 64, id 7943, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 50004 win 33156 >>> 481770582> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8678, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 58600:59828(1228) ack 1330 win 33156 >>> 565002904> > >>> 011072 AF 2 52: IP (tos 0x8, ttl 64, id 38257, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 52460 win 32542 >>> 481770583> 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 12255, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 59828:61056(1228) ack 1330 win 33156 >>> 565002915> > >>> 000209 AF 2 1280: IP (tos 0x8, ttl 64, id 46257, offset 0, flags > >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 61056:62284(1228) ack 1330 win 33156 >>> 565002915> > >>> 000222 AF 2 1280: IP (tos 0x8, ttl 64, id 4093, offset 0, flags > >>> [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 62284:63512(1228) ack 1330 win 33156 >>> 565002915> > >>> 007065 AF 2 52: IP (tos 0x8, ttl 64, id 18720, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 53688 win 33156 >>> 481770609> 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 38378, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 63512:64740(1228) ack 1330 win 33156 >>> 565002922> > >>> 011034 AF 2 52: IP (tos 0x8, ttl 64, id 18718, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 56144 win 32542 >>> 481770609> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8148, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . > >>> 64740:65968(1228) ack 1330 win 33156 >>> 565002934> > >>> 005991 AF 2 52: IP (tos 0x8, ttl 64, id 62285, offset 0, flags > >>> [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] > >>> 1330:1330(0) ack 57372 win 33156 >>> 481770625> 010726 AF 2 52: IP (tos 0x8, ttl 64, id 1549, offset 0, > >>> flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum > >>> ok] 1330:1330(0) ack 59828 win 32542 >>> 481770625> 005670 AF 2 52: IP (tos 0x8, ttl 64, id 61504, offset 0, > >>> flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum > >>> ok] 1330:1330(0) ack 61056 win 33156 >>> 481770642> 011260 AF 2 52: IP (tos 0x8, ttl 64, id 32633, offset 0, > >>> flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum > >>> ok] 1330:1330(0) ack 63512 win 32542 >>> 481770642> 005510 AF 2 52: IP (tos 0x8, ttl 64, id 54614, offset 0, > >>> flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum > >>> ok] 1330:1330(0) ack 64740 win 33156 >>> 481770650> 104909 AF 2 52: IP (tos 0x8, ttl 64, id 50471, offset 0, > >>> flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum > >>> ok] 1330:1330(0) ack 65968 win 33156 >>> 481770661> > >> > >> tcpdump -netttvvi ng0 host A.B.C.D: > >>> 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 25895, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x10b) > >>> 011042 AF 2 128: IP (tos 0x8, ttl 61, id 5786, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f0) > >>> 000226 AF 2 1352: IP (tos 0x8, ttl 64, id 36701, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x10c) > >>> 000216 AF 2 1352: IP (tos 0x8, ttl 64, id 8789, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x10d) > >>> 004853 AF 2 128: IP (tos 0x8, ttl 61, id 17128, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f1) > >>> 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 34888, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x10e) > >>> 018747 AF 2 128: IP (tos 0x8, ttl 61, id 14828, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f2) > >>> 000248 AF 2 1352: IP (tos 0x8, ttl 64, id 34356, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x10f) > >>> 000223 AF 2 1352: IP (tos 0x8, ttl 64, id 34151, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x110) > >>> 005030 AF 2 128: IP (tos 0x8, ttl 61, id 45476, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f3) > >>> 000228 AF 2 1352: IP (tos 0x8, ttl 64, id 39765, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x111) > >>> 011247 AF 2 128: IP (tos 0x8, ttl 61, id 63692, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f4) > >>> 000226 AF 2 1352: IP (tos 0x8, ttl 64, id 29240, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x112) > >>> 000222 AF 2 1352: IP (tos 0x8, ttl 64, id 43306, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x113) > >>> 005663 AF 2 128: IP (tos 0x8, ttl 61, id 32980, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f5) > >>> 000228 AF 2 1352: IP (tos 0x8, ttl 64, id 56920, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x114) > >>> 010190 AF 2 128: IP (tos 0x8, ttl 61, id 3206, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f6) > >>> 000227 AF 2 1352: IP (tos 0x8, ttl 64, id 4655, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x115) > >>> 000215 AF 2 1352: IP (tos 0x8, ttl 64, id 62740, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x116) > >>> 000203 AF 2 1352: IP (tos 0x8, ttl 64, id 35642, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x117) > >>> 006875 AF 2 128: IP (tos 0x8, ttl 61, id 37801, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f7) > >>> 000234 AF 2 1352: IP (tos 0x8, ttl 64, id 41803, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x118) > >>> 010651 AF 2 128: IP (tos 0x8, ttl 61, id 54256, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f8) > >>> 000235 AF 2 1352: IP (tos 0x8, ttl 64, id 30732, offset 0, flags > >>> [none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=3D0x078b2968,seq=3D0= x119) > >>> 007913 AF 2 128: IP (tos 0x8, ttl 61, id 7647, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= f9) > >>> 011166 AF 2 128: IP (tos 0x8, ttl 61, id 58037, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= fa) > >>> 005483 AF 2 128: IP (tos 0x8, ttl 61, id 65275, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= fb) > >>> 011250 AF 2 128: IP (tos 0x8, ttl 61, id 47289, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= fc) > >>> 005505 AF 2 128: IP (tos 0x8, ttl 61, id 203, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= fd) > >>> 104747 AF 2 128: IP (tos 0x8, ttl 61, id 45263, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= fe) > >>> 8. 338674 AF 2 128: IP (tos 0x8, ttl 61, id 36351, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= ff) > >>> 319992 AF 2 128: IP (tos 0x8, ttl 61, id 18085, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= 100) > >>> 441837 AF 2 128: IP (tos 0x8, ttl 61, id 58323, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= 101) > >>> 684077 AF 2 128: IP (tos 0x8, ttl 61, id 35487, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= 102) > >>> 1. 167602 AF 2 128: IP (tos 0x8, ttl 61, id 34442, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= 103) > >>> 2. 136032 AF 2 128: IP (tos 0x8, ttl 61, id 8345, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= 104) > >>> 2. 984665 AF 2 128: IP (tos 0x8, ttl 61, id 35456, offset 0, flags > >>> [none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=3D0x0858046f,seq=3D0x= 105) > >>> > >>> > >>> > >>> > >>> From what I'm seeing host B just stops sending without any reason. At > >> > >> least I don't see any fragmented packets. The only thing I've seen is > >> some packets doesn't get ack'ed by the receiver. > >> > >> These packets never get ack'ed: > >> 46320:47548(1228) > >> 50004:51232(1228) > >> 53688:54916(1228) > >> 57372:58600(1228) > >> 61056:62284(1228) > >> > >> On host A I dumped the following: > >> > >> tcpdump -netttvvi gif6 > >> > >>> 1129985378.941282 AF 2 52: IP (tos 0x8, ttl 64, id 41637, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 45092 win 32542 >>> 490857876> > >>> 1129985378.952628 AF 2 1280: IP (tos 0x8, ttl 64, id 14004, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 45092:46320(1228) ack 1330 win 33156 >>> 574090210> > >>> 1129985378.952657 AF 2 52: IP (tos 0x8, ttl 64, id 23243, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 46320 win 33156 >>> 490857901> > >>> 1129985378.958250 AF 2 1280: IP (tos 0x8, ttl 64, id 4306, offset 0, > >>> flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 46320:47548(1228) ack 1330 win 33156 >>> 574090210> > >>> 1129985378.971118 AF 2 1280: IP (tos 0x8, ttl 64, id 33534, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 47548:48776(1228) ack 1330 win 33156 >>> 574090229> > >>> 1129985378.971137 AF 2 52: IP (tos 0x8, ttl 64, id 60095, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 48776 win 32542 >>> 490857901> > >>> 1129985378.982488 AF 2 1280: IP (tos 0x8, ttl 64, id 11459, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 48776:50004(1228) ack 1330 win 33156 >>> 574090240> > >>> 1129985378.982516 AF 2 52: IP (tos 0x8, ttl 64, id 33184, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 50004 win 33156 >>> 490857931> > >>> 1129985378.987989 AF 2 1280: IP (tos 0x8, ttl 64, id 54180, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 50004:51232(1228) ack 1330 win 33156 >>> 574090240> > >>> 1129985378.994231 AF 2 1280: IP (tos 0x8, ttl 64, id 24535, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 51232:52460(1228) ack 1330 win 33156 >>> 574090251> > >>> 1129985378.994250 AF 2 52: IP (tos 0x8, ttl 64, id 30647, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 52460 win 32542 >>> 490857931> > >>> 1129985379.012101 AF 2 1280: IP (tos 0x8, ttl 64, id 61397, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 52460:53688(1228) ack 1330 win 33156 >>> 574090270> > >>> 1129985379.012132 AF 2 52: IP (tos 0x8, ttl 64, id 60550, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 53688 win 33156 >>> 490857960> > >>> 1129985379.017754 AF 2 1280: IP (tos 0x8, ttl 64, id 28408, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 53688:54916(1228) ack 1330 win 33156 >>> 574090270> > >>> 1129985379.023720 AF 2 1280: IP (tos 0x8, ttl 64, id 27558, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 54916:56144(1228) ack 1330 win 33156 >>> 574090281> > >>> 1129985379.023741 AF 2 52: IP (tos 0x8, ttl 64, id 21502, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 56144 win 32542 >>> 490857961> > >>> 1129985379.035333 AF 2 1280: IP (tos 0x8, ttl 64, id 18885, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 56144:57372(1228) ack 1330 win 33156 >>> 574090293> > >>> 1129985379.035362 AF 2 52: IP (tos 0x8, ttl 64, id 59875, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 57372 win 33156 >>> 490857984> > >>> 1129985379.040830 AF 2 1280: IP (tos 0x8, ttl 64, id 37252, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 57372:58600(1228) ack 1330 win 33156 >>> 574090293> > >>> 1129985379.046576 AF 2 1280: IP (tos 0x8, ttl 64, id 18349, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 58600:59828(1228) ack 1330 win 33156 >>> 574090293> > >>> 1129985379.046595 AF 2 52: IP (tos 0x8, ttl 64, id 43697, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 59828 win 32542 >>> 490857984> > >>> 1129985379.064961 AF 2 1280: IP (tos 0x8, ttl 64, id 38300, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 59828:61056(1228) ack 1330 win 33156 >>> 574090322> > >>> 1129985379.064993 AF 2 52: IP (tos 0x8, ttl 64, id 47539, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 61056 win 33156 >>> 490858013> > >>> 1129985379.070688 AF 2 1280: IP (tos 0x8, ttl 64, id 30345, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 61056:62284(1228) ack 1330 win 33156 >>> 574090322> > >>> 1129985379.076184 AF 2 1280: IP (tos 0x8, ttl 64, id 37536, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 62284:63512(1228) ack 1330 win 33156 >>> 574090322> > >>> 1129985379.076202 AF 2 52: IP (tos 0x8, ttl 64, id 34201, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 63512 win 32542 >>> 490858013> > >>> 1129985379.081680 AF 2 1280: IP (tos 0x8, ttl 64, id 20637, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 63512:64740(1228) ack 1330 win 33156 >>> 574090334> > >>> 1129985379.081709 AF 2 52: IP (tos 0x8, ttl 64, id 59866, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 64740 win 33156 >>> 490858025> > >>> 1129985379.087678 AF 2 1280: IP (tos 0x8, ttl 64, id 35213, offset > >>> 0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . > >>> 64740:65968(1228) ack 1330 win 33156 >>> 574090345> > >>> 1129985379.186906 AF 2 52: IP (tos 0x8, ttl 64, id 2465, offset 0, > >>> flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp > >>> sum ok] 1330:1330(0) ack 65968 win 33156 >>> 490858036> > >> > >> tcpdump -netttvvi em1 host E.F.G.H > >> > >>> 1129985379.064825 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype > >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 45003, offset 0, > >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: > >>> ESP(spi=3D0x0e0dffaa,seq=3D0x3e) > >>> 1129985379.065024 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype > >>> IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 1195, offset 0, > >>> flags [none], length: 128) A.B.C.D > E.F.G.H: > >>> ESP(spi=3D0x029a41b4,seq=3D0x2f) > >>> 1129985379.070572 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype > >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 36820, offset 0, > >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: > >>> ESP(spi=3D0x0e0dffaa,seq=3D0x3f) > >>> 1129985379.076069 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype > >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 44971, offset 0, > >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: > >>> ESP(spi=3D0x0e0dffaa,seq=3D0x40) > >>> 1129985379.076233 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype > >>> IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 56964, offset 0, > >>> flags [none], length: 128) A.B.C.D > E.F.G.H: > >>> ESP(spi=3D0x029a41b4,seq=3D0x30) > >>> 1129985379.081565 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype > >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 24742, offset 0, > >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: > >>> ESP(spi=3D0x0e0dffaa,seq=3D0x41) > >>> 1129985379.081741 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype > >>> IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 9390, offset 0, > >>> flags [none], length: 128) A.B.C.D > E.F.G.H: > >>> ESP(spi=3D0x029a41b4,seq=3D0x31) > >>> 1129985379.087562 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype > >>> IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 48065, offset 0, > >>> flags [none], length: 1352) E.F.G.H > A.B.C.D: > >>> ESP(spi=3D0x0e0dffaa,seq=3D0x42) > >>> 1129985379.186945 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype > >>> IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 36315, offset 0, > >>> flags [none], length: 128) A.B.C.D > E.F.G.H: > >>> ESP(spi=3D0x029a41b4,seq=3D0x32) > >> > >> If I'm not misleaded, this also doesn't show any errors except the > >> missing ack's. host B just stops sending. If there's an ack missing, > >> doesn't have the sending host to just repeat the un-ack'ed packet? > >> > >> The IPSec tunnel does not die. Even shortly after the (scp) transfer > >> stalls the tunnel itself is still usable (for small amounts of data). = To > >> make it more worse, when disabling pf at the senders side, the transfer > >> works. I've tripple checked pflog for denied packets on both sides but > >> pf didn't filter any packets out. > >> > >> When disabling the IPSec rules using `setkey -F; setkey -FP' on the > >> tunnel for a moment, the scp transfer does not stall. So it's not a gif > >> issue. > >> > >> It doesn't seem to be an MTU issue (pf has also the rule 'scrub in/out > >> all no-df'), but what kind of issue is that?? Has anybody ever > >> experienced similar things? Or am I misinterpreting the tcpdump output? > >> > >> > >> Any help and hint is appreciated! Without an error message I'm lost. > >> > >> Volker > >> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =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 --nextPart56501954.DhmgN6n76d Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDWs36XyyEoT62BG0RAifeAJ9//7n/W1zjEcppA6JD/benByaBeACfbDqM Weh1EBu5vm/w8h2we+KoKXk= =RJ4s -----END PGP SIGNATURE----- --nextPart56501954.DhmgN6n76d-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 23:50:41 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FD4C16A41F for ; Sat, 22 Oct 2005 23:50:41 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16DD843D45 for ; Sat, 22 Oct 2005 23:50:41 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: pass (tce71.tce85.de: domain of vwsoft.com designates 83.242.63.100 as permitted sender) client-ip=83.242.63.100; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (100-63-242-83.dip.h-tel.de [83.242.63.100]) by tce71.tce85.de (Postfix) with ESMTP id B71AC17120 for ; Sun, 23 Oct 2005 01:50:50 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 75B445C0F; Sun, 23 Oct 2005 01:50:15 +0200 (CEST) Message-ID: <435ADE49.9050107@vwsoft.com> Date: Sun, 23 Oct 2005 01:50:17 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <435A5D9B.7080309@vwsoft.com> <435A900C.3060602@roq.com> <435AD808.1030701@vwsoft.com> <200510230140.42154.max@love2party.net> In-Reply-To: <200510230140.42154.max@love2party.net> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Cc: Michael VInce , freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling 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, 22 Oct 2005 23:50:41 -0000 Max, I set sack.enable=0 on both FreeBSD machines but the same happens. Volker On 2005-10-23 00:40, Max Laier wrote: > To try something else: Could you guys try to disable SACK on the machines > involved? I haven't looked at the dumps as of yet, but that's one simple > test that might help to identify the problem. > > sysctl net.inet.tcp.sack.enable=0 > From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 23:56:55 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 500C416A41F for ; Sat, 22 Oct 2005 23:56:55 +0000 (GMT) (envelope-from volker@vwsoft.com) Received: from tce71.tce85.de (tce71.tce85.de [195.145.102.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4029343D45 for ; Sat, 22 Oct 2005 23:56:54 +0000 (GMT) (envelope-from volker@vwsoft.com) Received-SPF: pass (tce71.tce85.de: domain of vwsoft.com designates 83.242.63.100 as permitted sender) client-ip=83.242.63.100; envelope-from=volker@vwsoft.com; helo=mail.vtec.ipme.de; Received: from mail.vtec.ipme.de (100-63-242-83.dip.h-tel.de [83.242.63.100]) by tce71.tce85.de (Postfix) with ESMTP id DA01217120 for ; Sun, 23 Oct 2005 01:56:51 +0200 (CEST) Received: from [192.168.16.3] (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id E72035C12; Sun, 23 Oct 2005 01:56:19 +0200 (CEST) Message-ID: <435ADFB5.10603@vwsoft.com> Date: Sun, 23 Oct 2005 01:56:21 +0100 From: Volker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.6.0.101 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <435A5D9B.7080309@vwsoft.com> <435A900C.3060602@roq.com> <435AD808.1030701@vwsoft.com> <200510230140.42154.max@love2party.net> In-Reply-To: <200510230140.42154.max@love2party.net> X-Enigmail-Version: 0.92.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-TarmacCE-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com Cc: Michael VInce , freebsd-net@freebsd.org Subject: Re: IPSec tcp session stalling 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, 22 Oct 2005 23:56:55 -0000 Max & Co: I've just seen I'm using kernel config 'options IPSEC' on both machines. Should I try 'options FAST_IPSEC'? Would take some hours for kernel recompile. Does the code IPSEC / FAST_IPSEC make a difference (even while having not hardware crypto accelerator)? May I use FAST_IPSEC even without any hw-crypto devices? While reading `man fast_ipsec' I would think it depends on a hw-crypto device... Please tell me if we should check IPSEC / FAST_IPSEC and I'll start a recompile. Volker On 2005-10-23 00:40, Max Laier wrote: > To try something else: Could you guys try to disable SACK on the machines > involved? I haven't looked at the dumps as of yet, but that's one simple > test that might help to identify the problem. > > sysctl net.inet.tcp.sack.enable=0 > > On Sunday 23 October 2005 02:23, Volker wrote: > >>Michael, >> >>I not that sure if I'm right in checking what you suggested but when >>trying to do ping hostB from hostA with oversized packets through the >>IPSec tunnel by: >> >># ping -c 10 -s 12000 10.128.6.1 >> >>I'm getting replies easily. >> >>While doing that and tcpdump'ing the gif interface, I'm seeing the >>fragmented packets coming in properly. >> >>If that's a reliable check for MTU than the problem should not be MTU >>related. Is there any other way to check MTU problems by using `ping'? >> >>Thanks, >> >>Volker >> >>On 2005-10-22 20:16, Michael VInce wrote: >> >>>Try sending different sized pings or other packet size control utils to >>>really make sure its not MTU related. >>>Maybe there is an upstream router thats blocking ICMP fragment packets, >>>have you ever seen them? try forcing the creation of some. >>> >>>Mike >>> >>>Volker wrote: >>> >>>>Still having the same problem with an IPSec tunnel between FreeBSD 5.4R >>>>hosts. >>>> >>>>Problem description: >>>>scp session tries to transfer a large file through an IPSec tunnel. The >>>>file is being transmitted but scp says 'stalled' after 56K (49152 bytes >>>>file size). The IPSec tunnel itself is still up even after the scp >>>>abort. Other tcp sessions break, too when sending too much traffic >>>>through the tunnel. >>>> >>>>I've taken a closer look to it and tried to get something useful out of >>>>the tcpdump but I'm unable to see any errors or I'm misinterpreting >>>>something. >>>> >>>>The connection looks like: >>>> >>>>extIP: A.B.C.D >>>>extIP: E.F.G.H >>>>host A ------------------ (internet) ------------------ host B >>>>tunnelIP: 10.128.1.6 tunnelIP: >>>>10.128.6.1 >>>> >>>>host A just has an external interface (em1) connected to a leased line >>>>with a fixed IP address (IP-addr A.B.C.D). >>>>host B has an S-DSL connection at xl0, PPPoE at ng0 (IP-addr. E.F.G.H). >>>> >>>>Both hosts are using gif for the IPSec tunnel. >>>> >>>>The routing tables (netstat -rnWf inet) are looking good and IMHO the >>>>MTU is fine. >>>> >>>>host A: >>>>em1: flags=8843 mtu 1500 >>>> options=b >>>> inet A.B.C.D netmask 0xfffffff8 broadcast A.B.C.z >>>> ether 00:c0:9f:46:ec:c7 >>>> media: Ethernet autoselect (100baseTX ) >>>> status: active >>>>gif6: flags=8051 mtu 1280 >>>> tunnel inet A.B.C.D --> E.F.G.H >>>> inet 10.128.1.6 --> 10.128.6.1 netmask 0xffffffff >>>> inet6 fe80::2c0:9fff:fe46:ecc6%gif6 prefixlen 64 scopeid 0x4 >>>> >>>>Routing tables (shortened) >>>>Destination Gateway Flags Refs Use Mtu >>>>Netif Expire >>>>default A.B.C.x UGS 2 516686 1500 em1 >>>>10.128.1.6 127.0.0.1 UH 0 14 >>>>16384 lo0 >>>>10.128.6.1 10.128.1.6 UH 0 6017 >>>>1280 gif6 >>>>127.0.0.1 127.0.0.1 UH 0 31633 >>>>16384 lo0 >>>>A.B.C.x/29 link#2 UC 0 0 1500 em1 >>>>A.B.C.D 00:c0:9f:46:ec:c7 UHLW 0 112 1500 lo0 >>>> >>>>On host B the interfaces and routing tables are looking like: >>>>xl0: flags=8843 mtu 1500 >>>> options=8 >>>> inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255 >>>> inet6 fe80::260:8ff:fe6c:e73c%xl0 prefixlen 64 scopeid 0x1 >>>> ether 00:60:08:6c:e7:3c >>>> media: Ethernet 10baseT/UTP (10baseT/UTP ) >>>> status: active >>>>gif1: flags=8051 mtu 1280 >>>> tunnel inet E.F.G.H --> A.B.C.D >>>> inet6 fe80::260:8ff:fe6c:e73c%gif1 prefixlen 64 scopeid 0x4 >>>> inet 10.128.6.1 --> 10.128.1.6 netmask 0xffffffff >>>>ng0: flags=88d1 mtu 1456 >>>> inet E.F.G.H --> 217.5.98.186 netmask 0xffffffff >>>> >>>>Routing tables (shortened) >>>>Destination Gateway Flags Refs Use Mtu >>>>Netif Expire >>>>0 link#1 UC 0 0 1500 >>>>xl0 => >>>>default 217.5.98.186 UGS 1 38474 >>>>1456 ng0 >>>>10.128.1.6 10.128.6.1 UH 4 2196 >>>>1280 gif1 >>>>127.0.0.1 127.0.0.1 UH 0 80424 >>>>16384 lo0 >>>>217.5.98.186 E.F.G.H UH 1 0 1456 ng0 >>>>E.F.G.H lo0 UHS 0 0 16384 lo0 >>>> >>>>While trying to fetch a file by scp on host A (receiver) from host B >>>>(sender), I captured the following tcpdump on host B: >>>> >>>>tcpdump -netttvvi gif1: >>>> >>>>>000023 AF 2 1280: IP (tos 0x8, ttl 64, id 13202, offset 0, flags >>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>43864:45092(1228) ack 1330 win 33156 >>>>565002838> >>>>>000207 AF 2 1280: IP (tos 0x8, ttl 64, id 52187, offset 0, flags >>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>45092:46320(1228) ack 1330 win 33156 >>>>565002838> >>>>>000220 AF 2 1280: IP (tos 0x8, ttl 64, id 33774, offset 0, flags >>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>46320:47548(1228) ack 1330 win 33156 >>>>565002838> >>>>>003524 AF 2 52: IP (tos 0x8, ttl 64, id 42063, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 38952 win 33156 >>>>481770524> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 48541, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>47548:48776(1228) ack 1330 win 33156 >>>>565002844> >>>>>011203 AF 2 52: IP (tos 0x8, ttl 64, id 60517, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 41408 win 32542 >>>>481770530> 000058 AF 2 1280: IP (tos 0x8, ttl 64, id 15798, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>48776:50004(1228) ack 1330 win 33156 >>>>565002855> >>>>>000246 AF 2 1280: IP (tos 0x8, ttl 64, id 31721, offset 0, flags >>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>50004:51232(1228) ack 1330 win 33156 >>>>565002855> >>>>>005147 AF 2 52: IP (tos 0x8, ttl 64, id 22347, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 42636 win 33156 >>>>481770542> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 61057, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>51232:52460(1228) ack 1330 win 33156 >>>>565002861> >>>>>020769 AF 2 52: IP (tos 0x8, ttl 64, id 27692, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 45092 win 32542 >>>>481770547> 000027 AF 2 1280: IP (tos 0x8, ttl 64, id 64167, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>52460:53688(1228) ack 1330 win 33156 >>>>565002881> >>>>>000209 AF 2 1280: IP (tos 0x8, ttl 64, id 45457, offset 0, flags >>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>53688:54916(1228) ack 1330 win 33156 >>>>565002881> >>>>>005260 AF 2 52: IP (tos 0x8, ttl 64, id 53832, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 46320 win 33156 >>>>481770567> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 3515, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>54916:56144(1228) ack 1330 win 33156 >>>>565002887> >>>>>011020 AF 2 52: IP (tos 0x8, ttl 64, id 11608, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 48776 win 32542 >>>>481770568> 000026 AF 2 1280: IP (tos 0x8, ttl 64, id 5848, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>56144:57372(1228) ack 1330 win 33156 >>>>565002898> >>>>>000211 AF 2 1280: IP (tos 0x8, ttl 64, id 39892, offset 0, flags >>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>57372:58600(1228) ack 1330 win 33156 >>>>565002898> >>>>>005641 AF 2 52: IP (tos 0x8, ttl 64, id 7943, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 50004 win 33156 >>>>481770582> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8678, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>58600:59828(1228) ack 1330 win 33156 >>>>565002904> >>>>>011072 AF 2 52: IP (tos 0x8, ttl 64, id 38257, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 52460 win 32542 >>>>481770583> 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 12255, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>59828:61056(1228) ack 1330 win 33156 >>>>565002915> >>>>>000209 AF 2 1280: IP (tos 0x8, ttl 64, id 46257, offset 0, flags >>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>61056:62284(1228) ack 1330 win 33156 >>>>565002915> >>>>>000222 AF 2 1280: IP (tos 0x8, ttl 64, id 4093, offset 0, flags >>>>>[none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>62284:63512(1228) ack 1330 win 33156 >>>>565002915> >>>>>007065 AF 2 52: IP (tos 0x8, ttl 64, id 18720, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 53688 win 33156 >>>>481770609> 000025 AF 2 1280: IP (tos 0x8, ttl 64, id 38378, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>63512:64740(1228) ack 1330 win 33156 >>>>565002922> >>>>>011034 AF 2 52: IP (tos 0x8, ttl 64, id 18718, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 56144 win 32542 >>>>481770609> 000024 AF 2 1280: IP (tos 0x8, ttl 64, id 8148, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.53160: . >>>>>64740:65968(1228) ack 1330 win 33156 >>>>565002934> >>>>>005991 AF 2 52: IP (tos 0x8, ttl 64, id 62285, offset 0, flags >>>>>[none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum ok] >>>>>1330:1330(0) ack 57372 win 33156 >>>>481770625> 010726 AF 2 52: IP (tos 0x8, ttl 64, id 1549, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>ok] 1330:1330(0) ack 59828 win 32542 >>>>481770625> 005670 AF 2 52: IP (tos 0x8, ttl 64, id 61504, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>ok] 1330:1330(0) ack 61056 win 33156 >>>>481770642> 011260 AF 2 52: IP (tos 0x8, ttl 64, id 32633, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>ok] 1330:1330(0) ack 63512 win 32542 >>>>481770642> 005510 AF 2 52: IP (tos 0x8, ttl 64, id 54614, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>ok] 1330:1330(0) ack 64740 win 33156 >>>>481770650> 104909 AF 2 52: IP (tos 0x8, ttl 64, id 50471, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.53160 > 10.128.6.1.22: . [tcp sum >>>>>ok] 1330:1330(0) ack 65968 win 33156 >>>>481770661> >>>> >>>>tcpdump -netttvvi ng0 host A.B.C.D: >>>> >>>>>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 25895, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10b) >>>>>011042 AF 2 128: IP (tos 0x8, ttl 61, id 5786, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf0) >>>>>000226 AF 2 1352: IP (tos 0x8, ttl 64, id 36701, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10c) >>>>>000216 AF 2 1352: IP (tos 0x8, ttl 64, id 8789, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10d) >>>>>004853 AF 2 128: IP (tos 0x8, ttl 61, id 17128, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf1) >>>>>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 34888, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10e) >>>>>018747 AF 2 128: IP (tos 0x8, ttl 61, id 14828, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf2) >>>>>000248 AF 2 1352: IP (tos 0x8, ttl 64, id 34356, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x10f) >>>>>000223 AF 2 1352: IP (tos 0x8, ttl 64, id 34151, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x110) >>>>>005030 AF 2 128: IP (tos 0x8, ttl 61, id 45476, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf3) >>>>>000228 AF 2 1352: IP (tos 0x8, ttl 64, id 39765, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x111) >>>>>011247 AF 2 128: IP (tos 0x8, ttl 61, id 63692, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf4) >>>>>000226 AF 2 1352: IP (tos 0x8, ttl 64, id 29240, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x112) >>>>>000222 AF 2 1352: IP (tos 0x8, ttl 64, id 43306, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x113) >>>>>005663 AF 2 128: IP (tos 0x8, ttl 61, id 32980, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf5) >>>>>000228 AF 2 1352: IP (tos 0x8, ttl 64, id 56920, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x114) >>>>>010190 AF 2 128: IP (tos 0x8, ttl 61, id 3206, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf6) >>>>>000227 AF 2 1352: IP (tos 0x8, ttl 64, id 4655, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x115) >>>>>000215 AF 2 1352: IP (tos 0x8, ttl 64, id 62740, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x116) >>>>>000203 AF 2 1352: IP (tos 0x8, ttl 64, id 35642, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x117) >>>>>006875 AF 2 128: IP (tos 0x8, ttl 61, id 37801, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf7) >>>>>000234 AF 2 1352: IP (tos 0x8, ttl 64, id 41803, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x118) >>>>>010651 AF 2 128: IP (tos 0x8, ttl 61, id 54256, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf8) >>>>>000235 AF 2 1352: IP (tos 0x8, ttl 64, id 30732, offset 0, flags >>>>>[none], length: 1352) E.F.G.H > A.B.C.D: ESP(spi=0x078b2968,seq=0x119) >>>>>007913 AF 2 128: IP (tos 0x8, ttl 61, id 7647, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xf9) >>>>>011166 AF 2 128: IP (tos 0x8, ttl 61, id 58037, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfa) >>>>>005483 AF 2 128: IP (tos 0x8, ttl 61, id 65275, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfb) >>>>>011250 AF 2 128: IP (tos 0x8, ttl 61, id 47289, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfc) >>>>>005505 AF 2 128: IP (tos 0x8, ttl 61, id 203, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfd) >>>>>104747 AF 2 128: IP (tos 0x8, ttl 61, id 45263, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xfe) >>>>>8. 338674 AF 2 128: IP (tos 0x8, ttl 61, id 36351, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0xff) >>>>>319992 AF 2 128: IP (tos 0x8, ttl 61, id 18085, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x100) >>>>>441837 AF 2 128: IP (tos 0x8, ttl 61, id 58323, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x101) >>>>>684077 AF 2 128: IP (tos 0x8, ttl 61, id 35487, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x102) >>>>>1. 167602 AF 2 128: IP (tos 0x8, ttl 61, id 34442, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x103) >>>>>2. 136032 AF 2 128: IP (tos 0x8, ttl 61, id 8345, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x104) >>>>>2. 984665 AF 2 128: IP (tos 0x8, ttl 61, id 35456, offset 0, flags >>>>>[none], length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x0858046f,seq=0x105) >>>>> >>>>> >>>>> >>>>> >>>>>From what I'm seeing host B just stops sending without any reason. At >>>> >>>>least I don't see any fragmented packets. The only thing I've seen is >>>>some packets doesn't get ack'ed by the receiver. >>>> >>>>These packets never get ack'ed: >>>>46320:47548(1228) >>>>50004:51232(1228) >>>>53688:54916(1228) >>>>57372:58600(1228) >>>>61056:62284(1228) >>>> >>>>On host A I dumped the following: >>>> >>>>tcpdump -netttvvi gif6 >>>> >>>> >>>>>1129985378.941282 AF 2 52: IP (tos 0x8, ttl 64, id 41637, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 45092 win 32542 >>>>490857876> >>>>>1129985378.952628 AF 2 1280: IP (tos 0x8, ttl 64, id 14004, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>45092:46320(1228) ack 1330 win 33156 >>>>574090210> >>>>>1129985378.952657 AF 2 52: IP (tos 0x8, ttl 64, id 23243, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 46320 win 33156 >>>>490857901> >>>>>1129985378.958250 AF 2 1280: IP (tos 0x8, ttl 64, id 4306, offset 0, >>>>>flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>46320:47548(1228) ack 1330 win 33156 >>>>574090210> >>>>>1129985378.971118 AF 2 1280: IP (tos 0x8, ttl 64, id 33534, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>47548:48776(1228) ack 1330 win 33156 >>>>574090229> >>>>>1129985378.971137 AF 2 52: IP (tos 0x8, ttl 64, id 60095, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 48776 win 32542 >>>>490857901> >>>>>1129985378.982488 AF 2 1280: IP (tos 0x8, ttl 64, id 11459, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>48776:50004(1228) ack 1330 win 33156 >>>>574090240> >>>>>1129985378.982516 AF 2 52: IP (tos 0x8, ttl 64, id 33184, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 50004 win 33156 >>>>490857931> >>>>>1129985378.987989 AF 2 1280: IP (tos 0x8, ttl 64, id 54180, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>50004:51232(1228) ack 1330 win 33156 >>>>574090240> >>>>>1129985378.994231 AF 2 1280: IP (tos 0x8, ttl 64, id 24535, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>51232:52460(1228) ack 1330 win 33156 >>>>574090251> >>>>>1129985378.994250 AF 2 52: IP (tos 0x8, ttl 64, id 30647, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 52460 win 32542 >>>>490857931> >>>>>1129985379.012101 AF 2 1280: IP (tos 0x8, ttl 64, id 61397, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>52460:53688(1228) ack 1330 win 33156 >>>>574090270> >>>>>1129985379.012132 AF 2 52: IP (tos 0x8, ttl 64, id 60550, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 53688 win 33156 >>>>490857960> >>>>>1129985379.017754 AF 2 1280: IP (tos 0x8, ttl 64, id 28408, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>53688:54916(1228) ack 1330 win 33156 >>>>574090270> >>>>>1129985379.023720 AF 2 1280: IP (tos 0x8, ttl 64, id 27558, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>54916:56144(1228) ack 1330 win 33156 >>>>574090281> >>>>>1129985379.023741 AF 2 52: IP (tos 0x8, ttl 64, id 21502, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 56144 win 32542 >>>>490857961> >>>>>1129985379.035333 AF 2 1280: IP (tos 0x8, ttl 64, id 18885, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>56144:57372(1228) ack 1330 win 33156 >>>>574090293> >>>>>1129985379.035362 AF 2 52: IP (tos 0x8, ttl 64, id 59875, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 57372 win 33156 >>>>490857984> >>>>>1129985379.040830 AF 2 1280: IP (tos 0x8, ttl 64, id 37252, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>57372:58600(1228) ack 1330 win 33156 >>>>574090293> >>>>>1129985379.046576 AF 2 1280: IP (tos 0x8, ttl 64, id 18349, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>58600:59828(1228) ack 1330 win 33156 >>>>574090293> >>>>>1129985379.046595 AF 2 52: IP (tos 0x8, ttl 64, id 43697, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 59828 win 32542 >>>>490857984> >>>>>1129985379.064961 AF 2 1280: IP (tos 0x8, ttl 64, id 38300, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>59828:61056(1228) ack 1330 win 33156 >>>>574090322> >>>>>1129985379.064993 AF 2 52: IP (tos 0x8, ttl 64, id 47539, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 61056 win 33156 >>>>490858013> >>>>>1129985379.070688 AF 2 1280: IP (tos 0x8, ttl 64, id 30345, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>61056:62284(1228) ack 1330 win 33156 >>>>574090322> >>>>>1129985379.076184 AF 2 1280: IP (tos 0x8, ttl 64, id 37536, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>62284:63512(1228) ack 1330 win 33156 >>>>574090322> >>>>>1129985379.076202 AF 2 52: IP (tos 0x8, ttl 64, id 34201, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 63512 win 32542 >>>>490858013> >>>>>1129985379.081680 AF 2 1280: IP (tos 0x8, ttl 64, id 20637, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>63512:64740(1228) ack 1330 win 33156 >>>>574090334> >>>>>1129985379.081709 AF 2 52: IP (tos 0x8, ttl 64, id 59866, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 64740 win 33156 >>>>490858025> >>>>>1129985379.087678 AF 2 1280: IP (tos 0x8, ttl 64, id 35213, offset >>>>>0, flags [none], length: 1280) 10.128.6.1.22 > 10.128.1.6.59762: . >>>>>64740:65968(1228) ack 1330 win 33156 >>>>574090345> >>>>>1129985379.186906 AF 2 52: IP (tos 0x8, ttl 64, id 2465, offset 0, >>>>>flags [none], length: 52) 10.128.1.6.59762 > 10.128.6.1.22: . [tcp >>>>>sum ok] 1330:1330(0) ack 65968 win 33156 >>>>490858036> >>>> >>>>tcpdump -netttvvi em1 host E.F.G.H >>>> >>>> >>>>>1129985379.064825 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 45003, offset 0, >>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>ESP(spi=0x0e0dffaa,seq=0x3e) >>>>>1129985379.065024 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>>>>IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 1195, offset 0, >>>>>flags [none], length: 128) A.B.C.D > E.F.G.H: >>>>>ESP(spi=0x029a41b4,seq=0x2f) >>>>>1129985379.070572 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 36820, offset 0, >>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>ESP(spi=0x0e0dffaa,seq=0x3f) >>>>>1129985379.076069 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 44971, offset 0, >>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>ESP(spi=0x0e0dffaa,seq=0x40) >>>>>1129985379.076233 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>>>>IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 56964, offset 0, >>>>>flags [none], length: 128) A.B.C.D > E.F.G.H: >>>>>ESP(spi=0x029a41b4,seq=0x30) >>>>>1129985379.081565 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 24742, offset 0, >>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>ESP(spi=0x0e0dffaa,seq=0x41) >>>>>1129985379.081741 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>>>>IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 9390, offset 0, >>>>>flags [none], length: 128) A.B.C.D > E.F.G.H: >>>>>ESP(spi=0x029a41b4,seq=0x31) >>>>>1129985379.087562 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype >>>>>IPv4 (0x0800), length 1366: IP (tos 0x8, ttl 61, id 48065, offset 0, >>>>>flags [none], length: 1352) E.F.G.H > A.B.C.D: >>>>>ESP(spi=0x0e0dffaa,seq=0x42) >>>>>1129985379.186945 00:c0:9f:46:ec:c7 > 00:13:c4:fa:6c:20, ethertype >>>>>IPv4 (0x0800), length 142: IP (tos 0x8, ttl 64, id 36315, offset 0, >>>>>flags [none], length: 128) A.B.C.D > E.F.G.H: >>>>>ESP(spi=0x029a41b4,seq=0x32) >>>> >>>>If I'm not misleaded, this also doesn't show any errors except the >>>>missing ack's. host B just stops sending. If there's an ack missing, >>>>doesn't have the sending host to just repeat the un-ack'ed packet? >>>> >>>>The IPSec tunnel does not die. Even shortly after the (scp) transfer >>>>stalls the tunnel itself is still usable (for small amounts of data). To >>>>make it more worse, when disabling pf at the senders side, the transfer >>>>works. I've tripple checked pflog for denied packets on both sides but >>>>pf didn't filter any packets out. >>>> >>>>When disabling the IPSec rules using `setkey -F; setkey -FP' on the >>>>tunnel for a moment, the scp transfer does not stall. So it's not a gif >>>>issue. >>>> >>>>It doesn't seem to be an MTU issue (pf has also the rule 'scrub in/out >>>>all no-df'), but what kind of issue is that?? Has anybody ever >>>>experienced similar things? Or am I misinterpreting the tcpdump output? >>>> >>>> >>>>Any help and hint is appreciated! Without an error message I'm lost. >>>> >>>>Volker >>>> >>>>_______________________________________________ >>>>freebsd-net@freebsd.org mailing list >>>>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >>_______________________________________________ >>freebsd-net@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >