From owner-freebsd-net@FreeBSD.ORG Sun Aug 19 05:42:00 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A07D16A417 for ; Sun, 19 Aug 2007 05:42:00 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA6213C46E for ; Sun, 19 Aug 2007 05:42:00 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1-b.corp.dcn.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id l7J5fq5p034028; Sat, 18 Aug 2007 22:41:53 -0700 (PDT) Date: Sun, 19 Aug 2007 12:08:49 +0900 Message-ID: From: "George V. Neville-Neil" To: "Scott Ullrich" In-Reply-To: References: <20070818102803.GA1319@jayce.zen.inc> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2007 05:42:00 -0000 At Sat, 18 Aug 2007 15:58:16 -0400, Scott Ullrich wrote: > Thanks for the very detailed response. We have worked around the > problem for now with a simple shell script that looks for racoon > falling over and simply restarting it. > > Does anyone know if this is fixed in 7-CURRENT? If so we can easily > wait until 7 arrives as we plan on releasing pfSense on the 7 platform > as soon as it is released. > > George, would you like me to file a PR for this against 7-CURRENT? > Please file a PR and assign it to me. I read your kernel config, and it seems you were using FAST_IPSEC, and not Kame IPsec, so I'm wondering how relevant Yvan's comment might be. I think we should look a bit more deeply at this. Best, George From owner-freebsd-net@FreeBSD.ORG Sun Aug 19 10:09:35 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1212016A418 for ; Sun, 19 Aug 2007 10:09:35 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id A323D13C457 for ; Sun, 19 Aug 2007 10:09:34 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 60727 invoked from network); 19 Aug 2007 09:42:52 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay03.pair.com with SMTP; 19 Aug 2007 09:42:52 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 19 Aug 2007 04:42:51 -0500 (CDT) From: Mike Silbersack To: Igor Sysoev In-Reply-To: <20070816142431.GO57126@rambler-co.ru> Message-ID: <20070819043748.I921@odysseus.silby.com> References: <20070816142431.GO57126@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, robert Subject: Re: syncookie in 6.x and 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2007 10:09:35 -0000 On Thu, 16 Aug 2007, Igor Sysoev wrote: > I have looked sources and found that in early versions the sent counter > was simply not incremented at all. The patch attached. The patch looks ready to commit to me. Do you want me to commit or, or do you have another committer lined up? > After the patch has been applied I have found that 6 always sends > syncookies too, however, 6 unlike 7 never receives them. Why ? Have you tried patching 6 so that the syncache is non-functional and forced it to rely on syncookies? Last I checked (which was a long time ago), syncookies worked on 6. Adding a sysctl like 7's net.inet.tcp.syncookies_only to 6 might not be a bad idea, as long as it's behind #ifdef DIAGNOSTIC or INVARIANTS. The question you may really be asking is: Why does 7 *think* that it is receiving syncookies all the time? :) I haven't tried to answer that question yet. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 01:09:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A8A916A417 for ; Mon, 20 Aug 2007 01:09:18 +0000 (UTC) (envelope-from root@runemedia.net) Received: from runemedia.net (206-225-83-111.dedicated.abac.net [206.225.83.111]) by mx1.freebsd.org (Postfix) with ESMTP id 57CF713C480 for ; Mon, 20 Aug 2007 01:09:18 +0000 (UTC) (envelope-from root@runemedia.net) Received: (qmail 1209 invoked by uid 0); 19 Aug 2007 14:30:28 -0400 Date: 19 Aug 2007 14:30:28 -0400 Message-ID: <20070819183028.1204.qmail@runemedia.net> To: freebsd-net@freebsd.org From: dating24 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Your account on dating24.ro Enjoy! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 01:09:18 -0000 [1]www.dating24.ro - anunturi - prietenii - intalniri - matrimoniale - - chat privat - chat public - poze - [2]Intra si tu alaturi de prietenii tai in comunitatea dating24.ro Te asteptam! [3]Inregistreaza-te acum! _________________________________________________________________ Utilizatorii Yahoo, Gmail sau Hotmail! In cazul in care ati primit acest mesaj in Bulk va rugam sa adaugati adresa noreply@dating24.ro in Adress Book sau la Contacte Personale, dupa caz. Va multumim pentru intelegere si va uram succes in continuare. Echipa [4]dating24.ro References 1. http://www.dating24.ro/ 2. http://www.dating24.ro/ 3. http://www.dating24.ro/inregistrare_pas1.php 4. http://www.dating24.ro/ From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 02:48:34 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3ED616A421 for ; Mon, 20 Aug 2007 02:48:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2A513C4E9 for ; Mon, 20 Aug 2007 02:48:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 4658E1CC5D; Mon, 20 Aug 2007 14:48:32 +1200 (NZST) Date: Mon, 20 Aug 2007 14:48:32 +1200 From: Andrew Thompson To: FreeBSD-net Message-ID: <20070820024832.GD81877@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: LAGG handbook entry X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 02:48:34 -0000 Hi, I have been putting together a chapter on 'Link Aggregation and Failover', any feedback/corrections/additions would be appreciated. http://nzfug.nz.freebsd.org/nzfug/HandbookUpdates/NetworkAggregation cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 03:01:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16E9216A417 for ; Mon, 20 Aug 2007 03:01:01 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7F213C468 for ; Mon, 20 Aug 2007 03:01:00 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (8.13.8/8.13.8) with ESMTP id l7K2nwjZ028551 for ; Mon, 20 Aug 2007 12:19:58 +0930 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Mon, 20 Aug 2007 12:30:53 +0930 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 12:30:52 +0930 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.1/8.14.1) with ESMTP id l7K30fu5021850 for ; Mon, 20 Aug 2007 11:00:41 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.1/8.14.1/Submit) id l7K30fj9021849 for freebsd-net@freebsd.org; Mon, 20 Aug 2007 11:00:41 +0800 (WST) (envelope-from wilkinsa) Date: Mon, 20 Aug 2007 11:00:41 +0800 From: "Wilkinson, Alex" To: freebsd-net@freebsd.org Message-ID: <20070820030040.GJ21280@obelix.dsto.defence.gov.au> Mail-Followup-To: freebsd-net@freebsd.org References: <20070820024832.GD81877@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20070820024832.GD81877@heff.fud.org.nz> Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 20 Aug 2007 03:00:53.0147 (UTC) FILETIME=[52170EB0:01C7E2D6] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.0.1021-15368.001 X-TM-AS-Result: No-2.436100-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Re: LAGG handbook entry X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 03:01:01 -0000 0n Mon, Aug 20, 2007 at 02:48:32PM +1200, Andrew Thompson wrote: >I have been putting together a chapter on 'Link Aggregation and >Failover', any feedback/corrections/additions would be appreciated. >http://nzfug.nz.freebsd.org/nzfug/HandbookUpdates/NetworkAggregation Awesome. Great stuff Andrew! Thanks! -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 03:58:37 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A8F316A417 for ; Mon, 20 Aug 2007 03:58:37 +0000 (UTC) (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 019B813C468 for ; Mon, 20 Aug 2007 03:58:36 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l7K3lf8L040037 for ; Sun, 19 Aug 2007 20:47:41 -0700 (PDT) Date: Mon, 20 Aug 2007 12:47:28 +0900 Message-ID: From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Canonical Packet Traces? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 03:58:37 -0000 Howdy, A very slightly off topic question for net@. Does anyone know of a web site that collects and indexes canonical packet traces for network protocols? I'm looking for a good storehouse of traces to use in testing. Best, George From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 06:13:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8322816A417 for ; Mon, 20 Aug 2007 06:13:01 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 024AF13C442 for ; Mon, 20 Aug 2007 06:13:00 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id D7BB25E42; Mon, 20 Aug 2007 10:12:58 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 9CD5E5D36; Mon, 20 Aug 2007 10:12:58 +0400 (MSD) Date: Mon, 20 Aug 2007 10:12:54 +0400 From: Igor Sysoev To: Mike Silbersack Message-ID: <20070820061254.GB11540@rambler-co.ru> References: <20070816142431.GO57126@rambler-co.ru> <20070819043748.I921@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070819043748.I921@odysseus.silby.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-net@freebsd.org, robert Subject: Re: syncookie in 6.x and 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2007 06:13:01 -0000 On Sun, Aug 19, 2007 at 04:42:51AM -0500, Mike Silbersack wrote: > On Thu, 16 Aug 2007, Igor Sysoev wrote: > > >I have looked sources and found that in early versions the sent counter > >was simply not incremented at all. The patch attached. > > The patch looks ready to commit to me. Do you want me to commit or, or do > you have another committer lined up? Feel free to commit. > >After the patch has been applied I have found that 6 always sends > >syncookies too, however, 6 unlike 7 never receives them. Why ? > > Have you tried patching 6 so that the syncache is non-functional and > forced it to rely on syncookies? Last I checked (which was a long time > ago), syncookies worked on 6. Adding a sysctl like 7's > net.inet.tcp.syncookies_only to 6 might not be a bad idea, as long as it's > behind #ifdef DIAGNOSTIC or INVARIANTS. No, I have not tried. > The question you may really be asking is: Why does 7 *think* that it is > receiving syncookies all the time? :) > > I haven't tried to answer that question yet. I have found two 4.8's: 17460166 syncache entries added 106312 retransmitted 90435 dupsyn 0 dropped 17424177 completed 465 bucket overflow 0 cache overflow 21526 reset 13725 stale 0 aborted 0 badack 279 unreach 0 zone failures 0 cookies sent 6 cookies received 1671768 syncache entries added 63163 retransmitted 37566 dupsyn 0 dropped 1645430 completed 248 bucket overflow 0 cache overflow 13144 reset 12888 stale 0 aborted 0 badack 174 unreach 0 zone failures 0 cookies sent 116 cookies received and 4.11's: 5643772 syncache entries added 45993 retransmitted 41452 dupsyn 0 dropped 5630013 completed 298 bucket overflow 0 cache overflow 7374 reset 6030 stale 0 aborted 0 badack 93 unreach 0 zone failures 0 cookies sent 36 cookies received 141791272 syncache entries added 280354 retransmitted 273529 dupsyn 0 dropped 141703800 completed 206 bucket overflow 0 cache overflow 9847 reset 35570 stale 36034 aborted 0 badack 5854 unreach 0 zone failures 0 cookies sent 40 cookies received I have found one 6.1-PRERELEASE with 298 uptime: 2672792190 syncache entries added 83640383 retransmitted 77727918 dupsyn 282 dropped 2645872801 completed 0 bucket overflow 0 cache overflow 10974940 reset 15657014 stale 91 aborted 52 badack 287259 unreach 0 zone failures 0 cookies sent 8 cookies received 4.x have uptimes from week to month. On other 6.x with small uptime and do not see received cookies. And I have no 5.x at all. Anyway, 7 receives cookies much more - here is statistics from 3 days uptime: 52175610 syncache entries added 2092809 retransmitted 2021384 dupsyn 0 dropped 51681903 completed 0 bucket overflow 0 cache overflow 181311 reset 258220 stale 4 aborted 0 badack 18384 unreach 0 zone failures 52175610 cookies sent 16238 cookies received I have found that in 7 received cookies correlate with unreach. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 08:08:01 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16A0616A417 for ; Mon, 20 Aug 2007 08:08:01 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id BE69B13C48D for ; Mon, 20 Aug 2007 08:08:00 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 23893 invoked from network); 20 Aug 2007 02:41:19 -0500 Received: from 203-206-233-219.dyn.iinet.net.au (HELO localhost) (203.206.233.219) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Aug 2007 02:41:19 -0500 Date: Mon, 20 Aug 2007 17:41:13 +1000 From: Norberto Meijome To: gnn@freebsd.org Message-ID: <20070820174113.0deb2477@localhost> In-Reply-To: References: X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Canonical Packet Traces? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 08:08:01 -0000 On Mon, 20 Aug 2007 12:47:28 +0900 gnn@freebsd.org wrote: > A very slightly off topic question for net@. Does anyone know of a > web site that collects and indexes canonical packet traces for network > protocols? I'm looking for a good storehouse of traces to use in > testing. Hi George, not sure if this good enough for what you need: http://wiki.wireshark.org/SampleCaptures and the older one, http://wiki.ethereal.com/SampleCaptures , not sure if this is now included in the wireshark one. Best regards, B _________________________ {Beto|Norberto|Numard} Meijome "There are two kinds of stupid people. One kind says,'This is old and therefore good'. The other kind says, 'This is new, and therefore better.'" John Brunner, 'The Shockwave Rider'. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 08:27:32 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F20F16A419 for ; Mon, 20 Aug 2007 08:27:32 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3024913C428 for ; Mon, 20 Aug 2007 08:27:31 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id B87703F1F; Mon, 20 Aug 2007 10:27:28 +0200 (CEST) Date: Mon, 20 Aug 2007 10:27:28 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070820082728.GA28863@zen.inc> References: <20070818102803.GA1319@jayce.zen.inc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: Scott Ullrich Subject: Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2007 08:27:32 -0000 On Sun, Aug 19, 2007 at 12:08:49PM +0900, George V. Neville-Neil wrote: [....] > Please file a PR and assign it to me. > > I read your kernel config, and it seems you were using FAST_IPSEC, and > not Kame IPsec, so I'm wondering how relevant Yvan's comment might > be. I think we should look a bit more deeply at this. I tracked down the problem a few years ago, on FreeBSD 4.11, with KAME's IPSec stack. But the problem was not really in the stack itself, but rather in socket processing (in other words: not in netkey/*, but in kern/uipc_socket2.c). And as both IPSec stacks shares some PFKey constraints (for example one message per entry when dumping SADB / SPD), I guess the same problem existed in FAST_IPSEC. But when I had some time a few months ago to start filling a PR for the problem, I had a look at FreeBSD6 source code, and I noticed that sbspace macro (which was a quite important part of the problem) has changed, and I didn't have the required setup to do the test again, so I just can't be really sure the problem still exists... But the reported problem really has similar symptoms..... Yvan. -- NETASQ http://www.netasq.com From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 08:41:06 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE3C116A419 for ; Mon, 20 Aug 2007 08:41:06 +0000 (UTC) (envelope-from falcon@beltele.net) Received: from mail.tcm.by (mail.tcm.by [84.201.224.251]) by mx1.freebsd.org (Postfix) with ESMTP id 5462013C442 for ; Mon, 20 Aug 2007 08:41:06 +0000 (UTC) (envelope-from falcon@beltele.net) Received: from skipped_antispam (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 82C89FE21 for ; Mon, 20 Aug 2007 11:22:16 +0300 (EEST) Received: from skipped_antivirus (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E563BFE3D for ; Mon, 20 Aug 2007 11:22:15 +0300 (EEST) Received: from mailhub (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 83790FE2E for ; Mon, 20 Aug 2007 11:22:14 +0300 (EEST) Received: from [84.201.225.45] (unknown [84.201.225.45]) by mail.tcm.by (Postfix) with ESMTP id E624FFE21; Mon, 20 Aug 2007 11:22:13 +0300 (EEST) Date: Mon, 20 Aug 2007 11:22:15 +0300 From: "Denis V. Klimkov" X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <964626485.20070820112215@beltele.net> To: mpd-users@lists.sourceforge.net, FreeBSD Net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: mpd 4.2.2 problem: can't create tcpmss node at "bypass.inet.out1182"->"iface1183": No such file or directory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 08:41:06 -0000 Hello mpd-users, Running mpd 4.2.2 on FreeBSD 6.2-STABLE with about 1000 bundles configured: 10 of them PPTP other PPPoE. Most PPPoE clients work ok but when some of them connecting I see such messge in log: Aug 20 11:13:56 terminator mpd: can't create tcpmss node at "bypass.inet.out1182"->"iface1183": No such file or directory Aug 20 11:13:56 terminator mpd: [ng602] IfaceNgIpInit() error, closing IPCP Aug 20 11:13:56 terminator mpd: [ng602] IPCP: parameter negotiation failed Aug 20 11:13:56 terminator mpd: [ng602] IPCP: SendTerminateReq #17 Aug 20 11:13:56 terminator mpd: [ng602] IFACE: Removing IPv4 address from ng591 failed: Can't assign requested address Aug 20 11:13:56 terminator mpd: [ng602] IFACE: Down event Aug 20 11:13:56 terminator mpd: [ng602] IFACE: Up event and client have to make several attempts till it get connected. There was no such problem with mpd 4.1 with the same config. Changed NG_NETFLOW_MAXIFACES to 16384 in ng_netflow.h doesn't help. Any ideas? -- Denis V. Klimkov Network Administrator TelecomMedia LLC http://www.tcm.by From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 11:08:29 2007 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4216016A4FF for ; Mon, 20 Aug 2007 11:08:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2530F13C491 for ; Mon, 20 Aug 2007 11:08:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7KB8TJV087494 for ; Mon, 20 Aug 2007 11:08:29 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7KB8RLf087490 for freebsd-net@FreeBSD.org; Mon, 20 Aug 2007 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Aug 2007 11:08:27 GMT Message-Id: <200708201108.l7KB8RLf087490@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2007 11:08:29 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/21998 net [socket] [patch] ident only for outgoing connections a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net [ipsec] Filtering incoming packets with enc0 does not o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113359 net [ipv6] panic sbdrop after ICMP6, packet too big o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115413 net [ipv6] ipv6 pmtu not working 21 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/103253 net inconsistent behaviour in arp reply of a bridge o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114095 net [carp] carp+pf delay with high state limit o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f 14 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 15:11:48 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6408416A421 for ; Mon, 20 Aug 2007 15:11:48 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 20C5713C481 for ; Mon, 20 Aug 2007 15:11:48 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 08933619C for ; Mon, 20 Aug 2007 19:11:47 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id C2F456184 for ; Mon, 20 Aug 2007 19:11:46 +0400 (MSD) Date: Mon, 20 Aug 2007 19:11:42 +0400 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20070820151142.GA20183@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Subject: maximum number of outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 15:11:48 -0000 It seems that FreeBSD can not make more than net.inet.ip.portrange.last - net.inet.ip.portrange.first simultaneous outgoing connections, i.e., no more than about 64k. If I made ~64000 connections 127.0.0.1:XXXX > 127.0.0.1:80, then connect() to an external address returns EADDRNOTAVAIL. net.inet.ip.portrange.randomized is 0. sockets, etc. are enough: ITEM SIZE LIMIT USED FREE REQUESTS FAILURES socket: 356, 204809, 13915, 146443, 148189452, 0 inpcb: 180, 204820, 20375, 137277, 147631805, 0 tcpcb: 464, 204800, 13882, 142102, 147631805, 0 tcptw: 48, 41028, 6493, 11213, 29804665, 0 I saw it on 6.2-STABLE. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 16:34:49 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D03F16A420 for ; Mon, 20 Aug 2007 16:34:49 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id EC09013C46A for ; Mon, 20 Aug 2007 16:34:48 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id C569966C2; Mon, 20 Aug 2007 20:34:47 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id BD9C164E2; Mon, 20 Aug 2007 20:34:47 +0400 (MSD) Date: Mon, 20 Aug 2007 20:34:43 +0400 From: Igor Sysoev To: Tom Judge Message-ID: <20070820163443.GE20183@rambler-co.ru> References: <20070820151142.GA20183@rambler-co.ru> <46C9BF02.5050007@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <46C9BF02.5050007@tomjudge.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-net@freebsd.org Subject: Re: maximum number of outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 16:34:49 -0000 On Mon, Aug 20, 2007 at 05:19:14PM +0100, Tom Judge wrote: > Igor Sysoev wrote: > >It seems that FreeBSD can not make more than > > > >net.inet.ip.portrange.last - net.inet.ip.portrange.first > > > >simultaneous outgoing connections, i.e., no more than about 64k. > > > >If I made ~64000 connections 127.0.0.1:XXXX > 127.0.0.1:80, then > >connect() to an external address returns EADDRNOTAVAIL. > > > >net.inet.ip.portrange.randomized is 0. > > > >sockets, etc. are enough: > > > >ITEM SIZE LIMIT USED FREE REQUESTS FAILURES > >socket: 356, 204809, 13915, 146443, 148189452, 0 > >inpcb: 180, 204820, 20375, 137277, 147631805, 0 > >tcpcb: 464, 204800, 13882, 142102, 147631805, 0 > >tcptw: 48, 41028, 6493, 11213, 29804665, 0 > > > >I saw it on 6.2-STABLE. > > > > > > In an ideal world (Not sure if this is quite correct for FreeBSD) TCP > connections are tracked with a pair of tupels source-addr:src-port -> > dst-addr:dst-port > > As your always connecting to the same destination service 127.0.0.1:80 > and always from the same source IP 127.0.0.1 then you only have one > variable left to change, the source port. If you where to use the hole > of the whole of the port range minus the reserved ports you would only > ever be able to make 64512 simultaneous connections. In order to make > more connections the first thing that you may want to start changing is > the source IP. If you added a second IP to you lo0 interface (say > 127.0.0.2) and used a round robin approach to making your out bound > connections then you could make around 129k outbound connections. Connections to 127.0.0.1 were via lo0, external connections are via bge0. > I am not sure if there are any other constraints that need to be taken > into account such as the maximum number of sockets, RAM etc.... No, there are no constraints in memory, sockets, mbufs, clusters, etc. If there's contraint in memory, then FreeBSD simply panics. If there's contraint in mbuf clusters, then process stucks in zonelimit state forever. I suspect that local address in in_pcbbind_setup() is 0.0.0.0 so there is 64K limit. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 16:38:13 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22DE116A417 for ; Mon, 20 Aug 2007 16:38:13 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: from web43142.mail.sp1.yahoo.com (web43142.mail.sp1.yahoo.com [216.252.121.72]) by mx1.freebsd.org (Postfix) with SMTP id E24DB13C45D for ; Mon, 20 Aug 2007 16:38:12 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: (qmail 71223 invoked by uid 60001); 20 Aug 2007 16:11:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=TVRwC9fNwdhYouhXs7AzOCFuS3LzsXSnDWPFA0hSMrQzv0coxk+n9M00lvsAVTxLCxgN6qktDFBQJunIXx0H2rhltiK/3Ku4J9JQJMZlUw60WO96UlOqzMDA929Svvx5xKqC4OgF3YS3cfkH5rRE0hisZxByOo7iZyXkTB/hS7s=; X-YMail-OSG: xakpi6cVM1mVBGm1VGdSy.bsW.HDVffyoizyrwW.ywozNyOcJDWcGs968iP7Kkz98FS9hy4E53ByliN7WG0sJFdTvTizU1sshBU- Received: from [69.147.84.252] by web43142.mail.sp1.yahoo.com via HTTP; Mon, 20 Aug 2007 09:11:32 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.119.3 Date: Mon, 20 Aug 2007 09:11:32 -0700 (PDT) From: Weiguang Shi To: gnn@freebsd.org, net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <395010.70646.qm@web43142.mail.sp1.yahoo.com> Cc: Subject: Re: Canonical Packet Traces? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 16:38:13 -0000 moat.nlanr.org has a huge collection of traces, with dst and src IP address= es anonymized.=0A=0AWei=0A=0A----- Original Message ----=0AFrom: "gnn@freeb= sd.org" =0ATo: net@freebsd.org=0ASent: Sunday, August 19, = 2007 8:47:28 PM=0ASubject: Canonical Packet Traces?=0A=0AHowdy,=0A=0AA very= slightly off topic question for net@. Does anyone know of a=0Aweb site th= at collects and indexes canonical packet traces for network=0Aprotocols? I= 'm looking for a good storehouse of traces to use in=0Atesting.=0A=0ABest,= =0AGeorge=0A_______________________________________________=0Afreebsd-net@f= reebsd.org mailing list=0Ahttp://lists.freebsd.org/mailman/listinfo/freebsd= -net=0ATo unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.or= g"=0A=0A=0A=0A=0A=0A =0A_____________________________________________= _______________________________________=0APinpoint customers who are lookin= g for what you sell. =0Ahttp://searchmarketing.yahoo.com/ From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 16:41:50 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BFE216A419 for ; Mon, 20 Aug 2007 16:41:50 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog14.obsmtp.com (s200aog14.obsmtp.com [207.126.144.128]) by mx1.freebsd.org (Postfix) with SMTP id A647C13C428 for ; Mon, 20 Aug 2007 16:41:49 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Mon, 20 Aug 2007 16:41:44 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id C070F181506; Mon, 20 Aug 2007 17:19:14 +0100 (BST) Message-ID: <46C9BF02.5050007@tomjudge.com> Date: Mon, 20 Aug 2007 17:19:14 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Igor Sysoev References: <20070820151142.GA20183@rambler-co.ru> In-Reply-To: <20070820151142.GA20183@rambler-co.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: maximum number of outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 16:41:50 -0000 Igor Sysoev wrote: > It seems that FreeBSD can not make more than > > net.inet.ip.portrange.last - net.inet.ip.portrange.first > > simultaneous outgoing connections, i.e., no more than about 64k. > > If I made ~64000 connections 127.0.0.1:XXXX > 127.0.0.1:80, then > connect() to an external address returns EADDRNOTAVAIL. > > net.inet.ip.portrange.randomized is 0. > > sockets, etc. are enough: > > ITEM SIZE LIMIT USED FREE REQUESTS FAILURES > socket: 356, 204809, 13915, 146443, 148189452, 0 > inpcb: 180, 204820, 20375, 137277, 147631805, 0 > tcpcb: 464, 204800, 13882, 142102, 147631805, 0 > tcptw: 48, 41028, 6493, 11213, 29804665, 0 > > I saw it on 6.2-STABLE. > > In an ideal world (Not sure if this is quite correct for FreeBSD) TCP connections are tracked with a pair of tupels source-addr:src-port -> dst-addr:dst-port As your always connecting to the same destination service 127.0.0.1:80 and always from the same source IP 127.0.0.1 then you only have one variable left to change, the source port. If you where to use the hole of the whole of the port range minus the reserved ports you would only ever be able to make 64512 simultaneous connections. In order to make more connections the first thing that you may want to start changing is the source IP. If you added a second IP to you lo0 interface (say 127.0.0.2) and used a round robin approach to making your out bound connections then you could make around 129k outbound connections. I am not sure if there are any other constraints that need to be taken into account such as the maximum number of sockets, RAM etc.... Tom From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 16:43:26 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8671B16A417 for ; Mon, 20 Aug 2007 16:43:26 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.231]) by mx1.freebsd.org (Postfix) with ESMTP id 4294913C45D for ; Mon, 20 Aug 2007 16:43:26 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so425371nzf for ; Mon, 20 Aug 2007 09:43:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hGLCs28shajFQ9CJOJ/tX3NWKoY85Mn0wk8wXxs+YMvBaDeqjdaY16MdmO/Gr2HF+2Q767bl0WtV3MZKubRROMc6ile9ASiL/oeXu79FUAVRHZrWKQYUcHEH3obPSCy71xa5wZmVBoH3z3KqgVVD+dsS0oIFSuoVKFwfUMaMeYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kOuyqUxyRdwJVadQ1EaX7RjLu0d+21KThji97GZxRslPXcvkcfJ2LmaXQlrzEgKryBTLCE7qSrcI5DfMyOQn7m8b9HUFPuj9uiwMXN61M/LLooSo8HoSI4mD7gJKYZI1sRy66BgucvThFVI4wlqNCvos87pPlCbwF9LK2scG/Xc= Received: by 10.114.131.9 with SMTP id e9mr168708wad.1187628205067; Mon, 20 Aug 2007 09:43:25 -0700 (PDT) Received: by 10.114.76.7 with HTTP; Mon, 20 Aug 2007 09:43:25 -0700 (PDT) Message-ID: Date: Mon, 20 Aug 2007 12:43:25 -0400 From: "Scott Ullrich" To: "VANHULLEBUS Yvan" In-Reply-To: <20070820082728.GA28863@zen.inc> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070818102803.GA1319@jayce.zen.inc> <20070820082728.GA28863@zen.inc> Cc: freebsd-net@freebsd.org Subject: Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2007 16:43:26 -0000 On 8/20/07, VANHULLEBUS Yvan wrote: > I tracked down the problem a few years ago, on FreeBSD 4.11, with > KAME's IPSec stack. > > But the problem was not really in the stack itself, but rather in > socket processing (in other words: not in netkey/*, but in > kern/uipc_socket2.c). > > And as both IPSec stacks shares some PFKey constraints (for example > one message per entry when dumping SADB / SPD), I guess the same > problem existed in FAST_IPSEC. > > But when I had some time a few months ago to start filling a PR for > the problem, I had a look at FreeBSD6 source code, and I noticed that > sbspace macro (which was a quite important part of the problem) has > changed, and I didn't have the required setup to do the test again, so > I just can't be really sure the problem still exists... > > But the reported problem really has similar symptoms..... Thank you Yvan and George! The PR has been filed and the ID# is kern/115651 I have added some interesting notes that seem to affect NetBSD as well. We will be happy to work with anyone to get this solved and access to the machine in question is available if need be. Scott From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 16:53:57 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F347E16A418 for ; Mon, 20 Aug 2007 16:53:56 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id CF60013C4B0 for ; Mon, 20 Aug 2007 16:53:56 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (hbf1xbqfrscx2yqe@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l7KGruXm069549; Mon, 20 Aug 2007 09:53:56 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l7KGrtIi069547; Mon, 20 Aug 2007 09:53:55 -0700 (PDT) (envelope-from jmg) Date: Mon, 20 Aug 2007 09:53:55 -0700 From: John-Mark Gurney To: Igor Sysoev Message-ID: <20070820165354.GN99491@funkthat.com> Mail-Followup-To: Igor Sysoev , freebsd-net@freebsd.org References: <20070820151142.GA20183@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070820151142.GA20183@rambler-co.ru> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org Subject: Re: maximum number of outgoing connections 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: Mon, 20 Aug 2007 16:53:57 -0000 Igor Sysoev wrote this message on Mon, Aug 20, 2007 at 19:11 +0400: > It seems that FreeBSD can not make more than > > net.inet.ip.portrange.last - net.inet.ip.portrange.first > > simultaneous outgoing connections, i.e., no more than about 64k. > > If I made ~64000 connections 127.0.0.1:XXXX > 127.0.0.1:80, then > connect() to an external address returns EADDRNOTAVAIL. Isn't this more of a limitation of TCP/IP than FreeBSD? because you need to treat the srcip/srcport/dstip/dstport as a unique value, and in your test, you are only changing one of the four... Have you tried running a second we server on port 8080, and see if you can connect another ~64000 connections to that port too? -- 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 Mon Aug 20 18:30:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 454AE16A419 for ; Mon, 20 Aug 2007 18:30:18 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0082913C465 for ; Mon, 20 Aug 2007 18:30:17 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id AE3255DE2; Mon, 20 Aug 2007 22:30:16 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id A51305DCD; Mon, 20 Aug 2007 22:30:16 +0400 (MSD) Date: Mon, 20 Aug 2007 22:30:12 +0400 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20070820183012.GA27177@rambler-co.ru> References: <20070820151142.GA20183@rambler-co.ru> <20070820165354.GN99491@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070820165354.GN99491@funkthat.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: John-Mark Gurney Subject: Re: maximum number of outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 18:30:18 -0000 On Mon, Aug 20, 2007 at 09:53:55AM -0700, John-Mark Gurney wrote: > Igor Sysoev wrote this message on Mon, Aug 20, 2007 at 19:11 +0400: > > It seems that FreeBSD can not make more than > > > > net.inet.ip.portrange.last - net.inet.ip.portrange.first > > > > simultaneous outgoing connections, i.e., no more than about 64k. > > > > If I made ~64000 connections 127.0.0.1:XXXX > 127.0.0.1:80, then > > connect() to an external address returns EADDRNOTAVAIL. > > Isn't this more of a limitation of TCP/IP than FreeBSD? because you > need to treat the srcip/srcport/dstip/dstport as a unique value, and > in your test, you are only changing one of the four... Have you tried > running a second we server on port 8080, and see if you can connect > another ~64000 connections to that port too? No, TCP/IP limitation is for XXXX in 127.0.0.1:XXXX <> 127.0.0.1:80, but FreeBSD limits all outgoing connections to the port range, i.e. local part remote part 127.0.0.1:5000 <> 127.0.0.1:80 192.168.1.1:5000 <> 10.0.0.1:25 can not exist simultaneously, if both connections were started from local host. I can not write a simple test-case program, but I can offer simple setup: cd /usr/ports/www/nginx && make install create simple nginx.conf: ------------ events { worker_connections 20000; } http { server { listen 8080; server_name test; location = /loop { proxy_pass http://127.0.0.1:8080; error_page 502 = /yahoo; } location = /yahoo { proxy_pass http://www.yahoo.com; } } } ------------ set sysctl net.inet.ip.portrange.randomized=0 sysctl net.inet.ip.portrange.first=1024 sysctl net.inet.ip.portrange.last=5000 to see the case with default small number of files, sockets, etc. and run as root: /usr/local/sbin/nginx -c ./nginx.conf then ask http://host:8080/loop in browser. nginx will cycle to itslef, then after first error 2007/08/20 22:05:16 [crit] 29669#0: *94165 connect() to 127.0.0.1:8080 failed (49: Can't assign requested address) while connecting to upstream, client: 127.0.0.1, server: test, URL: "/loop", upstream: "http://127.0.0.1:8080/loop", host: "127.0.0.1:8080" you will see the second error: 2007/08/20 22:05:16 [crit] 29669#0: *94165 connect() to 87.248.113.14:80 failed (49: Can't assign requested address) while connecting to upstream, client: 127.0.0.1, server: test, URL: "/loop", upstream: "http://87.248.113.14:80/loop", host: "127.0.0.1:8080" If you think it may be nginx fault, run this under ktrace/truss and see syscalls. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 18:31:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 224E716A46C for ; Mon, 20 Aug 2007 18:31:01 +0000 (UTC) (envelope-from adityaa.kiran@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id EFDF013C48A for ; Mon, 20 Aug 2007 18:31:00 +0000 (UTC) (envelope-from adityaa.kiran@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so912680waf for ; Mon, 20 Aug 2007 11:31:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=fSPJNqVaefdzuYHXbFG8NZlgxhBqDWVxHDfgUiBQl1cJUYCwlJf1htL6r6sVOZETU/hDfXhEUVJZTY5IYwaW/tU9AElgJxI/ny+8G/AFunHZBXqHlNwBfA7AyXRC+RZGd31rq1290gAaSQPC1jKUkUqTxcZ20pqsg24OAqs71fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=cUyg0Zm0F9uF7ytPE2NsiZyzl6eex+CTbhc/PEl9BRWkBmZ5YRDTohCIK2WF5RYRhNp7eP3xt7As95QZiPuVc2DR5/DcjQ+GW86OqksDOZxXGNI4qt8D3Kaw6vm9SD9uQUawbKTUK2eJhI5J0wLM+7rZBonBqsEeDl0InKT6l14= Received: by 10.114.199.1 with SMTP id w1mr380545waf.1187634660561; Mon, 20 Aug 2007 11:31:00 -0700 (PDT) Received: by 10.114.72.3 with HTTP; Mon, 20 Aug 2007 11:31:00 -0700 (PDT) Message-ID: <994cd1cf0708201131k58a7cbbdh531638ccc925854a@mail.gmail.com> Date: Tue, 21 Aug 2007 00:01:00 +0530 From: "aditya kiran" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Racoon and per-socket based IPSec - Doesnt seem to be working! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2007 18:31:01 -0000 Hi, I need some help for ipsec configurations -- I was trying to use per-socket based IPsec with racoon. I have used setsockopt to set the ipsec policy on the socket. Then i started racoon with default configuration of remote and sainfo being anonymous. Now when i try to send out some ICMP packets, racoon gets a notification for key-acquire; however, racoon seems to be checking the policy id in its database and couldnt find one.. so it has thrown an error saying no spdid found!! and it hasnt initiated any key negotiations... is this expected? racoon doesnt work with per-socket based ipsec? if thats the case; how the SA entry in the security policy in the socket will get filled? Or do I need to use setkey to add an SPD even if i use per-socket based ipsec? can somebody please help me in understanding this? Thanks, Adityaa From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 21:09:01 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B8D616A420 for ; Mon, 20 Aug 2007 21:09:01 +0000 (UTC) (envelope-from SRS0=51c1414937382bb93b9c640e934c9ada58ae09d2=433=es.net=oberman@es.net) Received: from postal1.es.net (postal2.es.net [IPv6:2001:400:14:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id 47FF713C46A for ; Mon, 20 Aug 2007 21:08:59 +0000 (UTC) (envelope-from SRS0=51c1414937382bb93b9c640e934c9ada58ae09d2=433=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id ZDC55958; Mon, 20 Aug 2007 14:08:58 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 326AE4506A; Mon, 20 Aug 2007 14:08:58 -0700 (PDT) To: net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1187644138_93167P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 20 Aug 2007 14:08:58 -0700 From: "Kevin Oberman" Message-Id: <20070820210858.326AE4506A@ptavv.es.net> Cc: andre@networx.ch Subject: Unable to set socket size > 16MB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 21:09:01 -0000 --==_Exmh_1187644138_93167P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I am trying to tune a FreeBSD system for ~100 ms. RTT at 10 Gbps. (I posted another message about this back on 8/17). I am running current of late July 31. I am using iperf and I have confirmed (with gdb) that it is passing setsockopt a size of 67108864 and setsockopt is returning 0. When I capture the SYN packets, I am seeing a window of 64K and a scale factor of 8. For 64 MB, the scale factor should be 10. Is there some hidden limitation that would restrict this or is there a bug involved? I have set net.inet.tcp.(send|recv)space to 64m. kern.ipc.maxsockbuf=134217728. Here is the 3-way handshake: 13:57:45.571614 IP lbl.52460 > perf-bnl.commplex-link: S 4070670678:4070670678(0) win 65535 13:57:45.665645 IP perf-bnl.commplex-link > lbl.52460: S 3909263475:3909263475(0) ack 4070670679 win 65535 13:57:45.665683 IP lbl.52460 > perf-bnl.commplex-link: . ack 1 win 65535 Any reason for this? Any workaround or fix? Or am I missing something? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1187644138_93167P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGygLqkn3rs5h7N1ERAvZCAJ91VskviFrSx8/gzotJauX1QHhV8gCeMv6v +EeYwYXLmnA/y7ofsCB1odE= =lrH3 -----END PGP SIGNATURE----- --==_Exmh_1187644138_93167P-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 21:30:07 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8E3B16A420 for ; Mon, 20 Aug 2007 21:30:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B852013C442 for ; Mon, 20 Aug 2007 21:30:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7KLU7WA031952 for ; Mon, 20 Aug 2007 21:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7KLU76b031948; Mon, 20 Aug 2007 21:30:07 GMT (envelope-from gnats) Date: Mon, 20 Aug 2007 21:30:07 GMT Message-Id: <200708202130.l7KLU76b031948@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jacek Zapala Cc: Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jacek Zapala List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2007 21:30:08 -0000 The following reply was made to PR kern/115413; it has been noted by GNATS. From: Jacek Zapala To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working Date: Mon, 20 Aug 2007 23:24:06 +0200 Described problem shows only with pf enabled. Of course icmpv6 packet too big is not rejected by filter rules: # pfctl -s rules | fgrep big No ALTQ support in kernel ALTQ related functions disabled pass in quick on bce0 inet6 proto ipv6-icmp from any to 2001:xxxx:yyyy::200 icmp6-type toobig From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 21:52:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFF4116A41A for ; Mon, 20 Aug 2007 21:52:18 +0000 (UTC) (envelope-from alamar@alamar.org) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0E613C458 for ; Mon, 20 Aug 2007 21:52:18 +0000 (UTC) (envelope-from alamar@alamar.org) Received: from mail-in-12-z2.arcor-online.net (mail-in-12-z2.arcor-online.net [151.189.8.29]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id AC9C815B63C for ; Mon, 20 Aug 2007 20:58:50 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-12-z2.arcor-online.net (Postfix) with ESMTP id 98C292793FE for ; Mon, 20 Aug 2007 20:58:50 +0200 (CEST) Received: from stronghold.seifert.lan (p549534D1.dip0.t-ipconnect.de [84.149.52.209]) (Authenticated sender: julian.seifert@arcor.de) by mail-in-05.arcor-online.net (Postfix) with ESMTP id C69793BEB2 for ; Mon, 20 Aug 2007 20:58:45 +0200 (CEST) Received: from alamar by stronghold.seifert.lan with local (Exim 4.63) (envelope-from ) id 1INCSY-0001KG-2V for freebsd-net@freebsd.org; Mon, 20 Aug 2007 20:58:42 +0200 Resent-From: alamar@alamar.org Resent-Date: Mon, 20 Aug 2007 20:58:42 +0200 Resent-Message-ID: <20070820185842.GA1971@alamar.org> Resent-To: freebsd-net@freebsd.org Date: Mon, 20 Aug 2007 15:12:18 +0200 To: freebsd-hackers@freebsd.org Message-ID: <20070820131218.GA2198@alamar.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Resent-Date: Mon, 20 Aug 2007 20:58:42 +0200 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: alamar@alamar.org X-SA-Exim-Scanned: No (on stronghold.seifert.lan); SAEximRunCond expanded to false X-Virus-Scanned: ClamAV 0.91.1/4013/Mon Aug 20 18:00:53 2007 on mail-in-05.arcor-online.net X-Virus-Status: Clean Cc: Subject: process freeze (state *inp) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 21:52:18 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm running an ircd (derived from unrealircd) on a FreeBSD 5.5-Release. Most times it runs totally okay but sometimes (not reproducable)=20 the process freezes with state "*inp" shown with "top". On no other operating system this problem occurs. (Linux 2.6.x and FreeBSD 6.2 and -Current)=20 When I googled for information I found this in the FAQ of unrealircd: http://www.unrealircd.com/faq.php#105 I assume the bug they refer to is also present in 5.5-Rls and that this is the cause of the random freezes. I asked the unreal developers if they know any more specifics but they didn't.=20 Does anyone know what "tcp socket bug" they are referring to? I'm not so familiar with the FreeBSD kernel(and debugging it etc.) The simplest solution is probably to upgrade to 6.2 but I'd prefer fixing t= he bug for 5.5.. (I forgot to mention that I formerly had 5.4-RLS installed and experienced = the same problem)=20 MfG, =09 Julian D. `alamar` Seifert -- =20 "Emacs is a nice operating system, but I prefer UNIX." - Tom Christiansen gpg fingerprint: 435D DDDA 251B 9D70 2F72 78E0 AA5F 11F4 A4ED 451E --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGyZMyql8R9KTtRR4RAnqGAKCVioPhY8449JHm1Trpao7V3PO2BgCfQ7H2 1DpjVnr6yOYioyzz9lnL57g= =RIvv -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 20 22:31:55 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D836816A421 for ; Mon, 20 Aug 2007 22:31:55 +0000 (UTC) (envelope-from future@www7.netcologne.de) Received: from www7.netcologne.de (www7.netcologne.de [213.168.87.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9FF2E13C468 for ; Mon, 20 Aug 2007 22:31:55 +0000 (UTC) (envelope-from future@www7.netcologne.de) Received: from www7.netcologne.de (localhost [127.0.0.1]) by www7.netcologne.de (Postfix) with SMTP id B23D3443B2 for ; Tue, 21 Aug 2007 00:06:05 +0200 (MEST) Received: by www7.netcologne.de (sSMTP sendmail emulation); Tue, 21 Aug 2007 00:06:05 +0200 Date: Tue, 21 Aug 2007 00:06:05 +0200 To: freebsd-net@freebsd.org From: Mission Houses Museum Message-Id: <1307462000.554@missionhouses.org> Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Job Offer !!! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Aug 2007 22:31:55 -0000 Mission Houses Museum Work Opportunity........ ........Are you currently looking for an opportunity to work from home or direct from your computer. We have alot of churches,government bodies,banks,companies and other offices around making donations through our mission house to assist the poor all over the world.This is an sensational opportunity for you to work with Mission Houses Museum as our donation officer. This is a fantastic opportunity to build an extremely rewarding career and these opportunities would suit people who need flexible working arrangements and Located anywhere in UK,Canada,Australia. We have got several opportunities available for customer service/ consultants/Accounting/management sectors with a negotiable good salary starting from $15,000.00 - $65,000.00 with discount of 10% on every donations processed. The successful candidate will need to have customer service experience and a computer with internet connnetion. Also you need to like working in a team environment and have good communication skills. **No prior experience required **Work from home --- No daily commute! **Spend more time with your family! **we are assuring you that at no time will you be required to make any upfront payments of your personal funds to us for whatever reason. **Computer at home with access to broadband and checking your email messages at least twice everyday! You can fill the application form below, so that you can start working with Mission Houses Museum as our doantion agent in your area: > - FULL NAME: > - ADDRESS: > - CITY: > - STATE: > - COUNTRY: > - TEL NUMBERS: > - FAX NUMBERS: > - Mobile NUMBERS: > - COMPANY NAME(if any): > - AGE: > - STATUS(MARRIED/SINGLE): > - Direct Mobile Number: > - Yahoo Messenger ID: > - MSN Messenger ID: > - Send your resume letter attached with all this information for Mission Houses Museum phone verification and interview if required. PLEASE SUMMIT THE DETAILS & RESUME LETTER DIRECTLY TO THIS E-MAIL ADDRESS: missionhouse@rexian.com Mission Houses Museum Advertment. Tel: +44-7024067187 E-mail: missionhouse@rexian.com website: http://www.missionhouses.org/ From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 01:19:40 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 208DD16A41A for ; Tue, 21 Aug 2007 01:19:40 +0000 (UTC) (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 0660613C469 for ; Tue, 21 Aug 2007 01:19:40 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id l7L18WCH037363; Mon, 20 Aug 2007 18:08:32 -0700 (PDT) Date: Tue, 21 Aug 2007 10:08:31 +0900 Message-ID: From: "George V. Neville-Neil" To: "Scott Ullrich" In-Reply-To: References: <20070818102803.GA1319@jayce.zen.inc> <20070820082728.GA28863@zen.inc> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 01:19:40 -0000 At Mon, 20 Aug 2007 12:43:25 -0400, Scott Ullrich wrote: > > On 8/20/07, VANHULLEBUS Yvan wrote: > > I tracked down the problem a few years ago, on FreeBSD 4.11, with > > KAME's IPSec stack. > > > > But the problem was not really in the stack itself, but rather in > > socket processing (in other words: not in netkey/*, but in > > kern/uipc_socket2.c). > > > > And as both IPSec stacks shares some PFKey constraints (for example > > one message per entry when dumping SADB / SPD), I guess the same > > problem existed in FAST_IPSEC. > > > > But when I had some time a few months ago to start filling a PR for > > the problem, I had a look at FreeBSD6 source code, and I noticed that > > sbspace macro (which was a quite important part of the problem) has > > changed, and I didn't have the required setup to do the test again, so > > I just can't be really sure the problem still exists... > > > > But the reported problem really has similar symptoms..... > > Thank you Yvan and George! > > The PR has been filed and the ID# is > > kern/115651 > Got it. > I have added some interesting notes that seem to affect NetBSD as well. > > We will be happy to work with anyone to get this solved and access to > the machine in question is available if need be. > Your raccoon config, if you could send it to me, would be helpful. Best, GEorge From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 01:21:24 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D38B16A418 for ; Tue, 21 Aug 2007 01:21:24 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.freebsd.org (Postfix) with ESMTP id E59F513C481 for ; Tue, 21 Aug 2007 01:21:23 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1-b.corp.dcn.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id l7L1AYiP024720; Mon, 20 Aug 2007 18:10:35 -0700 (PDT) Date: Tue, 21 Aug 2007 10:10:33 +0900 Message-ID: From: gnn@freebsd.org To: Weiguang Shi In-Reply-To: <395010.70646.qm@web43142.mail.sp1.yahoo.com> References: <395010.70646.qm@web43142.mail.sp1.yahoo.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.7 Emacs/22.1 (i386-apple-darwin8.9.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: net@freebsd.org Subject: Re: Canonical Packet Traces? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2007 01:21:24 -0000 Thanks to all who responded. I'll check out the links. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 06:15:43 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E6AD16A417 for ; Tue, 21 Aug 2007 06:15:43 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id 20FE513C442 for ; Tue, 21 Aug 2007 06:15:40 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 8510 invoked from network); 21 Aug 2007 01:15:40 -0500 Received: from 203-206-233-219.dyn.iinet.net.au (HELO localhost) (203.206.233.219) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Aug 2007 01:15:40 -0500 Date: Tue, 21 Aug 2007 16:15:36 +1000 From: Norberto Meijome To: Weiguang Shi Message-ID: <20070821161536.634aa7bf@localhost> In-Reply-To: <395010.70646.qm@web43142.mail.sp1.yahoo.com> References: <395010.70646.qm@web43142.mail.sp1.yahoo.com> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: gnn@freebsd.org, net@freebsd.org Subject: [OT] nlanr.org ?? ( was Re: Canonical Packet Traces? ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2007 06:15:43 -0000 On Mon, 20 Aug 2007 09:11:32 -0700 (PDT) Weiguang Shi wrote: > moat.nlanr.org has a huge collection of traces, with dst and src IP addresses anonymized. > ?! it seems someone hijacked nlanr.org's domain : Domain ID:D128379310-LROR Domain Name:NLANR.ORG Created On:06-Sep-2006 04:47:17 UTC Last Updated On:08-Jun-2007 03:13:43 UTC Expiration Date:06-Sep-2007 04:47:17 UTC Sponsoring Registrar:Capitoldomains LLC (R1392-LROR) Status:CLIENT TRANSFER PROHIBITED Registrant ID:CA631071395034-R Registrant Name:Click Cons. Ltd Registrant Street1:Kings Court, Bay Street Registrant Street2:P.O. Box N-3944 Registrant Street3: Registrant City:Nassau Registrant State/Province:- Registrant Postal Code:- Registrant Country:BS Registrant Phone:+852.30178436 Registrant Phone Ext.: Registrant FAX:+852.30178436 Registrant FAX Ext.: Registrant Email:click@ClickConsultingLtd.com Admin ID:CA631071395034-A Admin Name:Click Cons. Ltd Admin Street1:Kings Court, Bay Street Admin Street2:P.O. Box N-3944 Admin Street3: Admin City:Nassau Admin State/Province:- Admin Postal Code:- Admin Country:BS Admin Phone:+852.30178436 Admin Phone Ext.: Admin FAX:+852.30178436 Admin FAX Ext.: Admin Email:click@ClickConsultingLtd.com Tech ID:CA631071395034-T Tech Name:Click Cons. Ltd Tech Street1:Kings Court, Bay Street Tech Street2:P.O. Box N-3944 Tech Street3: Tech City:Nassau Tech State/Province:- Tech Postal Code:- Tech Country:BS Tech Phone:+852.30178436 Tech Phone Ext.: Tech FAX:+852.30178436 Tech FAX Ext.: Tech Email:click@clickconsltd.com Name Server:NS1.PREMIUMTRAFFIC.NET Name Server:NS2.PREMIUMTRAFFIC.NET Name Server:NS3.PREMIUMTRAFFIC.NET Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: blimey. _________________________ {Beto|Norberto|Numard} Meijome "The only people that never change are the stupid and the dead" Jorge Luis Borges. I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 09:14:25 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A2F116A41B for ; Tue, 21 Aug 2007 09:14:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2734613C494 for ; Tue, 21 Aug 2007 09:14:25 +0000 (UTC) (envelope-from max@love2party.net) Received: from dslb-088-066-022-164.pools.arcor-ip.net [88.66.22.164] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1INPoU0Qqh-0001gC; Tue, 21 Aug 2007 11:14:21 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Tue, 21 Aug 2007 11:14:03 +0200 User-Agent: KMail/1.9.7 References: <20070820210858.326AE4506A@ptavv.es.net> In-Reply-To: <20070820210858.326AE4506A@ptavv.es.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2077998.fyJQ7MpuTd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708211114.09938.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+SbQop6jnE8Tf2cN/yab0A4Kw5RBCcQ4w2sgh q0vm2+BKaR4uyxjdTKH1D4L+ffkXNdBH8yBxDi15Mxe8V7M319 SMDy871zuJfW3TQpFC1IksAMicqWYXxtPyhnhxuwPg= Cc: andre@networx.ch, andre@freebsd.org, Kevin Oberman Subject: Re: Unable to set socket size > 16MB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2007 09:14:25 -0000 --nextPart2077998.fyJQ7MpuTd Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 20 August 2007, Kevin Oberman wrote: > I am trying to tune a FreeBSD system for ~100 ms. RTT at 10 Gbps. (I > posted another message about this back on 8/17). I am running current > of late July 31. > > I am using iperf and I have confirmed (with gdb) that it is passing > setsockopt a size of 67108864 and setsockopt is returning 0. When I > capture the SYN packets, I am seeing a window of 64K and a scale > factor of 8. For 64 MB, the scale factor should be 10. > > Is there some hidden limitation that would restrict this or is there a > bug involved? I have set net.inet.tcp.(send|recv)space to > 64m. kern.ipc.maxsockbuf=3D134217728. > > Here is the 3-way handshake: > 13:57:45.571614 IP lbl.52460 > perf-bnl.commplex-link: S > 4070670678:4070670678(0) win 65535 8,sackOK,timestamp 345761341 0> 13:57:45.665645 IP > perf-bnl.commplex-link > lbl.52460: S 3909263475:3909263475(0) ack > 4070670679 win 65535 3623078172 345761341> 13:57:45.665683 IP lbl.52460 > > perf-bnl.commplex-link: . ack 1 win 65535 3623078172> > > Any reason for this? Any workaround or fix? Or am I missing something? =20 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c#rev1.1= 04=20 seems to be the culprit: while (wscale < TCP_MAX_WINSHIFT && (0x1 << wscale) < tcp_minmss) /* 216 */ wscale++; It's obvious that the above will bound wscale to 8 with the default of 216= =20 for minmss. You should be able to set a higher minmss for a temporary=20 work around, but this calculation really seems wrong to me. Esp. given=20 the following comment for tcp_minmss: ... * with packet generation and sending. Set to zero to disable MINMSS * checking. This setting prevents us from sending too small packets. */ =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 --nextPart2077998.fyJQ7MpuTd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGyqzhXyyEoT62BG0RAt0QAJ49D/Bp4kexw5zN0RaLl3UQEkLKkACeK9qJ 8Hv3z5udS7kzhNhL/HMjSzQ= =Iz8f -----END PGP SIGNATURE----- --nextPart2077998.fyJQ7MpuTd-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 10:10:07 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB0BF16A474 for ; Tue, 21 Aug 2007 10:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 38E9713C4B6 for ; Tue, 21 Aug 2007 10:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7LAA6cJ082259 for ; Tue, 21 Aug 2007 10:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7LAA6V7082258; Tue, 21 Aug 2007 10:10:06 GMT (envelope-from gnats) Date: Tue, 21 Aug 2007 10:10:06 GMT Message-Id: <200708211010.l7LAA6V7082258@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jacek Zapala Cc: Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jacek Zapala List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 10:10:07 -0000 The following reply was made to PR kern/115413; it has been noted by GNATS. From: Jacek Zapala To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working Date: Tue, 21 Aug 2007 12:05:18 +0200 Further debugging: scp from src_addr to dst_addr which pf debug enabled shows pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[50400] src_addr[50400] dst_addr[22] [lo=2463013638 high=2463020758 win=32844 modulator=0 wscale=1] [lo=2412460872 high=2412526560 win=1278 modulator=0 wscale=3] 4:4 seq=2463010534 State table: self tcp src_addr[50400] -> dst_addr[22] ESTABLISHED:ESTABLISHED From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 12:11:19 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D85F16A419 for ; Tue, 21 Aug 2007 12:11:19 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2297A13C457 for ; Tue, 21 Aug 2007 12:11:18 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id l7LCBI6X028838 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 14:11:18 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id l7LCBIED012498; Tue, 21 Aug 2007 14:11:18 +0200 (MEST) Date: Tue, 21 Aug 2007 14:11:18 +0200 From: Daniel Hartmeier To: Jacek Zapala Message-ID: <20070821121118.GF27160@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708211010.l7LAA6V7082258@freefall.freebsd.org> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 12:11:19 -0000 When filtering statefully, there is no need for a specific rule allowing ICMPv6 errors like ICMP6_PACKET_TOO_BIG. These ICMPv6 messages contain, as payload, the header of the original packet that triggered the error. pf extracts that inner header and searches for a matching state entry. If a matching state is found, the ICMPv6 error is passed without ruleset evaluation. In your case, a matching state entry (for the corresponding TCP connection) is found, but TCP sequence number checks fail: > pf: BAD ICMP 2:0 some_router -> src_addr > state: TCP src_addr[50400] src_addr[50400] dst_addr[22] > [lo=2463013638 high=2463020758 win=32844 modulator=0 wscale=1] > [lo=2412460872 high=2412526560 win=1278 modulator=0 wscale=3] > 4:4 seq=2463010534 The TCP connection is from src_addr[50400] to dst_addr[22], an outgoing connection (on some interface) for pf. I assume the ICMPv6 error is coming in on the same interface. Since some_router is sending the ICMPv6 error to src, we'd expect that the TCP packet that triggered the error on some_router was sent from src to dst. The first section in square brackets represents src's TCP window, the second one dst's. For packets src sends to dst, dst's window is relevant. For example, a TCP packet from src to dst might have th_seq 2412460873 legitimately, as that is within the window dst accepts (2412460872 to 2412526560). But th_seq of the TCP packet quoted by the ICMPv6 error is 2463010534, which is outside dst's window. Strangely, it is within src's window. I don't understand why some_router would do this. It looks like it's either quoting the wrong TCP header or sending the error to the wrong side, neither of which sounds like an easy mistake to make. Is some_router a FreeBSD 6.2 box, too? It might help if you could capture a tcpdump -s 1600 -nvvvS of one such TCP connection, including the ICMPv6 error. Daniel From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 13:38:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BE3716A41A for ; Tue, 21 Aug 2007 13:38:05 +0000 (UTC) (envelope-from jacek@ipv6.jacek.it.pl) Received: from smtpauth.ipartners.pl (smtpauth3.ipartners.pl [IPv6:2001:4190:8002:1::270]) by mx1.freebsd.org (Postfix) with ESMTP id 1465213C468 for ; Tue, 21 Aug 2007 13:38:03 +0000 (UTC) (envelope-from jacek@ipv6.jacek.it.pl) Received: from kx.jacek.it.pl (cl-158.mbx-01.si.sixxs.net [IPv6:2001:15c0:65ff:9d::2]) (authenticated bits=0) by smtpauth.ipartners.pl with ESMTP id l7LDbrEt029015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Aug 2007 15:37:56 +0200 (CEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by kx.jacek.it.pl (Postfix) with ESMTP id C1C2C5982AD; Tue, 21 Aug 2007 15:37:52 +0200 (CEST) From: Jacek Zapala To: Daniel Hartmeier In-Reply-To: <20070821121118.GF27160@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> Content-Type: multipart/mixed; boundary="=-2QPiulVbjuG3H1/GpwxY" Date: Tue, 21 Aug 2007 15:37:52 +0200 Message-Id: <1187703472.22531.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 13:38:05 -0000 --=-2QPiulVbjuG3H1/GpwxY Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2007-08-21 at 14:11 +0200, Daniel Hartmeier wrote: > But th_seq of the TCP packet quoted by the ICMPv6 error is 2463010534, > which is outside dst's window. Strangely, it is within src's window. > > I don't understand why some_router would do this. It looks like it's > either quoting the wrong TCP header or sending the error to the wrong > side, neither of which sounds like an easy mistake to make. > Is some_router a FreeBSD 6.2 box, too? It is Cisco 7200. Btw, these icmp packets are accepted by FreeBSD kernel after disabling pf. > > It might help if you could capture a tcpdump -s 1600 -nvvvS of one > such > TCP connection, including the ICMPv6 error. Attached. Jacek --=-2QPiulVbjuG3H1/GpwxY Content-Disposition: attachment; filename=tcpdump.txt Content-Type: text/plain; name=tcpdump.txt; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit 15:08:36.600927 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 44) src_addr.55687 > 2002:594c:de3e:1::4.22: S, cksum 0x3013 (correct), 2820359509:2820359509(0) win 65535 15:08:36.847498 IP6 (hlim 51, next-header: TCP (6), length: 40) 2002:594c:de3e:1::4.22 > src_addr.55687: S, cksum 0x760f (correct), 1624375639:1624375639(0) ack 2820359510 win 5712 15:08:36.847545 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 32) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x39d6 (correct), 2820359510:2820359510(0) ack 1624375640 win 32844 15:08:37.175719 IP6 (hlim 51, next-header: TCP (6), length: 63) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0x8f50 (correct), 1624375640:1624375671(31) ack 2820359510 win 714 15:08:37.228281 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 71) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0x4e20 (correct), 2820359510:2820359549(39) ack 1624375671 win 32844 15:08:37.479614 IP6 (hlim 51, next-header: TCP (6), length: 32) 2002:594c:de3e:1::4.22 > src_addr.55687: ., cksum 0xb598 (correct), 1624375671:1624375671(0) ack 2820359549 win 714 15:08:37.479661 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 784) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0x044c (correct), 2820359549:2820360301(752) ack 1624375671 win 32844 15:08:37.491658 IP6 (hlim 51, next-header: TCP (6), length: 736) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0x1d04 (correct), 1624375671:1624376375(704) ack 2820359549 win 714 15:08:37.594223 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 56) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0x02ab (correct), 2820360301:2820360325(24) ack 1624376375 win 32844 15:08:37.764034 IP6 (hlim 51, next-header: TCP (6), length: 32) 2002:594c:de3e:1::4.22 > src_addr.55687: ., cksum 0xadef (correct), 1624376375:1624376375(0) ack 2820360301 win 902 15:08:37.842637 IP6 (hlim 51, next-header: TCP (6), length: 32) 2002:594c:de3e:1::4.22 > src_addr.55687: ., cksum 0xad54 (correct), 1624376375:1624376375(0) ack 2820360325 win 902 15:08:37.843493 IP6 (hlim 51, next-header: TCP (6), length: 184) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0xd122 (correct), 1624376375:1624376527(152) ack 2820360325 win 902 15:08:37.845620 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 176) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0x47e6 (correct), 2820360325:2820360469(144) ack 1624376527 win 32844 15:08:38.112932 IP6 (hlim 51, next-header: TCP (6), length: 688) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0x2a74 (correct), 1624376527:1624377183(656) ack 2820360469 win 1090 15:08:38.369997 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 32) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x2a41 (correct), 2820360469:2820360469(0) ack 1624377183 win 32844 15:08:40.948002 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 48) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0x1892 (correct), 2820360469:2820360485(16) ack 1624377183 win 32844 15:08:41.295621 IP6 (hlim 51, next-header: TCP (6), length: 32) 2002:594c:de3e:1::4.22 > src_addr.55687: ., cksum 0x9bb5 (correct), 1624377183:1624377183(0) ack 2820360485 win 1090 15:08:41.295666 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 80) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0x6fad (correct), 2820360485:2820360533(48) ack 1624377183 win 32844 15:08:41.541047 IP6 (hlim 51, next-header: TCP (6), length: 32) 2002:594c:de3e:1::4.22 > src_addr.55687: ., cksum 0x99e5 (correct), 1624377183:1624377183(0) ack 2820360533 win 1090 15:08:41.542040 IP6 (hlim 51, next-header: TCP (6), length: 80) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0x3c86 (correct), 1624377183:1624377231(48) ack 2820360533 win 1090 15:08:41.542181 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 96) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0xa389 (correct), 2820360533:2820360597(64) ack 1624377231 win 32844 15:08:41.822764 IP6 (hlim 51, next-header: TCP (6), length: 96) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0xa6ad (correct), 1624377231:1624377295(64) ack 2820360597 win 1090 15:08:41.974328 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 32) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x1aee (correct), 2820360597:2820360597(0) ack 1624377295 win 32844 15:08:44.045893 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 176) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0xf110 (correct), 2820360597:2820360741(144) ack 1624377295 win 32844 15:08:44.295775 IP6 (hlim 51, next-header: TCP (6), length: 64) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0x9b15 (correct), 1624377295:1624377327(32) ack 2820360741 win 1278 15:08:44.295998 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 96) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0x4f17 (correct), 2820360741:2820360805(64) ack 1624377327 win 32844 15:08:44.544649 IP6 (hlim 51, next-header: TCP (6), length: 80) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0xc614 (correct), 1624377327:1624377375(48) ack 2820360805 win 1278 15:08:44.544834 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 96) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0xa2c9 (correct), 2820360805:2820360869(64) ack 1624377375 win 32844 15:08:44.801386 IP6 (hlim 51, next-header: TCP (6), length: 80) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0xd629 (correct), 1624377375:1624377423(48) ack 2820360869 win 1278 15:08:44.903997 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 32) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x0c6c (correct), 2820360869:2820360869(0) ack 1624377423 win 32844 15:08:45.147735 IP6 (hlim 51, next-header: TCP (6), length: 80) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0xe6af (correct), 1624377423:1624377471(48) ack 2820360869 win 1278 15:08:45.148027 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 96) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0xb0b8 (correct), 2820360869:2820360933(64) ack 1624377471 win 32844 15:08:45.391362 IP6 (flowlabel 0xae0ac, hlim 64, next-header: TCP (6), length: 1460) src_addr.53916 > dst_addr.22: ., cksum 0x351e (correct), 1982161698:1982163126(1428) ack 1447942263 win 32844 15:08:45.394947 IP6 (hlim 63, next-header: ICMPv6 (58), length: 1240) some_router > src_addr: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 15:08:45.399300 IP6 (hlim 51, next-header: TCP (6), length: 80) 2002:594c:de3e:1::4.22 > src_addr.55687: P, cksum 0x86c9 (correct), 1624377471:1624377519(48) ack 2820360933 win 1278 15:08:45.724239 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 1460) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x4707 (correct), 2820360933:2820362361(1428) ack 1624377519 win 32844 15:08:45.724252 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 1460) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x2e2b (correct), 2820362361:2820363789(1428) ack 1624377519 win 32844 15:08:45.724260 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 232) src_addr.55687 > 2002:594c:de3e:1::4.22: P, cksum 0x891c (correct), 2820363789:2820363989(200) ack 1624377519 win 32844 15:08:45.727576 IP6 (hlim 63, next-header: ICMPv6 (58), length: 1240) some_router > src_addr: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 15:08:45.728669 IP6 (hlim 63, next-header: ICMPv6 (58), length: 1240) some_router > src_addr: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 15:08:45.985316 IP6 (hlim 51, next-header: TCP (6), length: 44) 2002:594c:de3e:1::4.22 > src_addr.55687: ., cksum 0x51d7 (correct), 1624377519:1624377519(0) ack 2820360933 win 1278 15:08:46.435406 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 1460) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x43b1 (correct), 2820360933:2820362361(1428) ack 1624377519 win 32844 15:08:46.438283 IP6 (hlim 63, next-header: ICMPv6 (58), length: 1240) some_router > src_addr: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 15:08:47.953287 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 1460) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x3eed (correct), 2820360933:2820362361(1428) ack 1624377519 win 32844 15:08:47.956548 IP6 (hlim 63, next-header: ICMPv6 (58), length: 1240) some_router > src_addr: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 15:08:50.857446 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 1460) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x3593 (correct), 2820360933:2820362361(1428) ack 1624377519 win 32844 15:08:50.860910 IP6 (hlim 63, next-header: ICMPv6 (58), length: 1240) some_router > src_addr: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 15:08:55.479100 IP6 (flowlabel 0x2d89b, hlim 64, next-header: TCP (6), length: 1460) src_addr.55687 > 2002:594c:de3e:1::4.22: ., cksum 0x23d1 (correct), 2820360933:2820362361(1428) ack 1624377519 win 32844 15:08:55.481831 IP6 (hlim 63, next-header: ICMPv6 (58), length: 1240) some_router > src_addr: [icmp6 sum ok] ICMP6, packet too big, length 1240, mtu 1480 --=-2QPiulVbjuG3H1/GpwxY Content-Disposition: attachment; filename=dmesg.txt Content-Type: text/plain; name=dmesg.txt; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Aug 21 15:06:01 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982161698 Aug 21 15:06:01 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982163126 Aug 21 15:06:02 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982161698 Aug 21 15:06:05 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982161698 Aug 21 15:06:10 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982161698 Aug 21 15:06:16 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53248] src_addr[53248] dst_addr[22] [lo=947831351 high=947838471 win=32844 modulator=0 wscale=1] [lo=1374559184 high=1374624872 win=1278 modulator=0 wscale=3] 4:4 seq=947828247 Aug 21 15:06:20 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982161698 Aug 21 15:06:36 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982161698 Aug 21 15:06:57 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982161698 Aug 21 15:08:32 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53248] src_addr[53248] dst_addr[22] [lo=947831351 high=947838471 win=32844 modulator=0 wscale=1] [lo=1374559184 high=1374624872 win=1278 modulator=0 wscale=3] 4:4 seq=947828247 Aug 21 15:08:45 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[53916] src_addr[53916] dst_addr[22] [lo=1982164754 high=1982171922 win=32844 modulator=0 wscale=1] [lo=1447942263 high=1448007951 win=1278 modulator=0 wscale=3] 4:4 seq=1982161698 Aug 21 15:08:46 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[55687] src_addr[55687] 2002:594c:de3e:1::4[22] [lo=2820363989 high=2820371157 win=32844 modulator=0 wscale=1] [lo=1624377519 high=1624443207 win=1278 modulator=0 wscale=3] 4:4 seq=2820360933 Aug 21 15:08:46 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[55687] src_addr[55687] 2002:594c:de3e:1::4[22] [lo=2820363989 high=2820371157 win=32844 modulator=0 wscale=1] [lo=1624377519 high=1624443207 win=1278 modulator=0 wscale=3] 4:4 seq=2820362361 Aug 21 15:08:46 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[55687] src_addr[55687] 2002:594c:de3e:1::4[22] [lo=2820363989 high=2820371157 win=32844 modulator=0 wscale=1] [lo=1624377519 high=1624443207 win=1278 modulator=0 wscale=3] 4:4 seq=2820360933 Aug 21 15:08:48 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[55687] src_addr[55687] 2002:594c:de3e:1::4[22] [lo=2820363989 high=2820371157 win=32844 modulator=0 wscale=1] [lo=1624377519 high=1624443207 win=1278 modulator=0 wscale=3] 4:4 seq=2820360933 Aug 21 15:08:51 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[55687] src_addr[55687] 2002:594c:de3e:1::4[22] [lo=2820363989 high=2820371157 win=32844 modulator=0 wscale=1] [lo=1624377519 high=1624443207 win=1278 modulator=0 wscale=3] 4:4 seq=2820360933 Aug 21 15:08:55 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[55687] src_addr[55687] 2002:594c:de3e:1::4[22] [lo=2820363989 high=2820371157 win=32844 modulator=0 wscale=1] [lo=1624377519 high=1624443207 win=1278 modulator=0 wscale=3] 4:4 seq=2820360933 Aug 21 15:09:05 FreeBSD kernel: pf: BAD ICMP 2:0 some_router -> src_addr state: TCP src_addr[55687] src_addr[55687] 2002:594c:de3e:1::4[22] [lo=2820363989 high=2820371157 win=32844 modulator=0 wscale=1] [lo=1624377519 high=1624443207 win=1278 modulator=0 wscale=3] 4:4 seq=2820360933 --=-2QPiulVbjuG3H1/GpwxY-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 13:50:53 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 309FB16A481 for ; Tue, 21 Aug 2007 13:50:53 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id CF0FA13C4E9 for ; Tue, 21 Aug 2007 13:50:52 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id l7LDonh3030201 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 15:50:49 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id l7LDomm2004556; Tue, 21 Aug 2007 15:50:48 +0200 (MEST) Date: Tue, 21 Aug 2007 15:50:48 +0200 From: Daniel Hartmeier To: Jacek Zapala Message-ID: <20070821135048.GA32421@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1187703472.22531.4.camel@localhost.localdomain> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 13:50:53 -0000 On Tue, Aug 21, 2007 at 03:37:52PM +0200, Jacek Zapala wrote: > Attached. Thanks, I'll study them. Since you're using TCP window scaling, could you try disabling that (sysctl net.inet.tcp.rfc1323=0 on either peer), and see if it affects things? Just to make sure that's not a part of the problem. Daniel From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 14:17:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71F4A16A41B for ; Tue, 21 Aug 2007 14:17:01 +0000 (UTC) (envelope-from jacek@ipv6.jacek.it.pl) Received: from smtpauth.ipartners.pl (smtpauth3.ipartners.pl [IPv6:2001:4190:8002:1::270]) by mx1.freebsd.org (Postfix) with ESMTP id D5FEE13C46E for ; Tue, 21 Aug 2007 14:17:00 +0000 (UTC) (envelope-from jacek@ipv6.jacek.it.pl) Received: from kx.jacek.it.pl (cl-158.mbx-01.si.sixxs.net [IPv6:2001:15c0:65ff:9d::2]) (authenticated bits=0) by smtpauth.ipartners.pl with ESMTP id l7LEGqL6050548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Aug 2007 16:16:54 +0200 (CEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by kx.jacek.it.pl (Postfix) with ESMTP id 730375982AD; Tue, 21 Aug 2007 16:16:51 +0200 (CEST) From: Jacek Zapala To: Daniel Hartmeier In-Reply-To: <20070821135048.GA32421@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> Content-Type: text/plain Date: Tue, 21 Aug 2007 16:16:51 +0200 Message-Id: <1187705811.30269.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 14:17:01 -0000 On Tue, 2007-08-21 at 15:50 +0200, Daniel Hartmeier wrote: > Since you're using TCP window scaling, could you try disabling that > (sysctl net.inet.tcp.rfc1323=0 on either peer), and see if it affects > things? Just to make sure that's not a part of the problem. Good guess! I have disabled this on sending side (FreeBSD) and it started to work! Btw, how can I examine the route mtu cache? In older FreeBSD netstat -ranW showed cloned routes and their mtus, but this is no longer the case with FreeBSD 6.2. Jacek From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 14:31:28 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BE9916A41A for ; Tue, 21 Aug 2007 14:31:28 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id B486913C483 for ; Tue, 21 Aug 2007 14:31:27 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id l7LEVQT1026877 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 16:31:26 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id l7LEVQIw021411; Tue, 21 Aug 2007 16:31:26 +0200 (MEST) Date: Tue, 21 Aug 2007 16:31:26 +0200 From: Daniel Hartmeier To: Jacek Zapala Message-ID: <20070821143125.GB32421@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> <1187705811.30269.5.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1187705811.30269.5.camel@localhost.localdomain> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 14:31:28 -0000 On Tue, Aug 21, 2007 at 04:16:51PM +0200, Jacek Zapala wrote: > I have disabled this on sending side (FreeBSD) and it started to work! Ah, so it's related to window scaling. Headaches again ;) Is the following a correct view of your setup: src ---- $int_if pf $ext_if ---- router ---- dst Where client src connects to server dst, and you create the state entry when the initial TCP SYN goes out $ext_if on the firewall? The ICMPv6 is coming in on $ext_if, in the reverse direction, relative to the initial TCP SYN? And the router is between pf and dst, on the $ext_if side? Daniel From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 14:38:46 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B63B016A420 for ; Tue, 21 Aug 2007 14:38:45 +0000 (UTC) (envelope-from jacek@ipv6.jacek.it.pl) Received: from smtpauth.ipartners.pl (smtpauth3.ipartners.pl [IPv6:2001:4190:8002:1::270]) by mx1.freebsd.org (Postfix) with ESMTP id 3071513C46C for ; Tue, 21 Aug 2007 14:38:44 +0000 (UTC) (envelope-from jacek@ipv6.jacek.it.pl) Received: from kx.jacek.it.pl (cl-158.mbx-01.si.sixxs.net [IPv6:2001:15c0:65ff:9d::2]) (authenticated bits=0) by smtpauth.ipartners.pl with ESMTP id l7LEccml063532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Aug 2007 16:38:40 +0200 (CEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by kx.jacek.it.pl (Postfix) with ESMTP id CB43F5982AD; Tue, 21 Aug 2007 16:38:37 +0200 (CEST) From: Jacek Zapala To: Daniel Hartmeier In-Reply-To: <20070821143125.GB32421@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> <1187705811.30269.5.camel@localhost.localdomain> <20070821143125.GB32421@insomnia.benzedrine.cx> Content-Type: text/plain Date: Tue, 21 Aug 2007 16:38:37 +0200 Message-Id: <1187707117.846.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 14:38:46 -0000 On Tue, 2007-08-21 at 16:31 +0200, Daniel Hartmeier wrote: > Is the following a correct view of your setup: > > src ---- $int_if pf $ext_if ---- router ---- dst > > Where client src connects to server dst, and you create the state > entry > when the initial TCP SYN goes out $ext_if on the firewall? > > The ICMPv6 is coming in on $ext_if, in the reverse direction, relative > to the initial TCP SYN? > > And the router is between pf and dst, on the $ext_if side? pf is set up on src so it looks like: src with pf ---- router ---- (internet) ---- dst pf rule: pass out quick on $if0 inet6 proto tcp from any to $dst_net port 22 flags S/SA keep state Jacek From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 14:50:49 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C90D616A418 for ; Tue, 21 Aug 2007 14:50:49 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4636F13C480 for ; Tue, 21 Aug 2007 14:50:49 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id l7LEolxD021456 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 16:50:48 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id l7LEolQn026257; Tue, 21 Aug 2007 16:50:47 +0200 (MEST) Date: Tue, 21 Aug 2007 16:50:47 +0200 From: Daniel Hartmeier To: Jacek Zapala Message-ID: <20070821145047.GC32421@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> <1187705811.30269.5.camel@localhost.localdomain> <20070821143125.GB32421@insomnia.benzedrine.cx> <1187707117.846.3.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1187707117.846.3.camel@localhost.localdomain> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 14:50:49 -0000 Could you possibly try the patch below, and see if it fixes the problem (with rfc1323 enabled again)? We're accessing th_flags from the TCP header embedded in the ICMPv6 packet, even though we only pulled up the first 8 bytes of the mbuf, because the sender doesn't have to provide more of the header. There could be random garbage there, and the bit corresponding to TH_SYN might be set, so the window scale factor is not applied. Not sure if that would be reproducable so reliably, but it sure is a bug ;) Daniel Index: pf.c =================================================================== RCS file: /cvs/freebsd/src/sys/contrib/pf/net/pf.c,v retrieving revision 1.34.2.4 diff -u -r1.34.2.4 pf.c --- pf.c 19 Sep 2006 15:45:20 -0000 1.34.2.4 +++ pf.c 21 Aug 2007 14:42:59 -0000 @@ -5118,8 +5118,7 @@ dst = &(*state)->dst; } - if (src->wscale && dst->wscale && - !(th.th_flags & TH_SYN)) + if (src->wscale && dst->wscale) dws = dst->wscale & PF_WSCALE_MASK; else dws = 0; From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 16:17:57 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0AD16A419 for ; Tue, 21 Aug 2007 16:17:57 +0000 (UTC) (envelope-from jacek@ipv6.jacek.it.pl) Received: from smtpauth.ipartners.pl (smtpauth3.ipartners.pl [IPv6:2001:4190:8002:1::270]) by mx1.freebsd.org (Postfix) with ESMTP id 8A26013C45E for ; Tue, 21 Aug 2007 16:17:56 +0000 (UTC) (envelope-from jacek@ipv6.jacek.it.pl) Received: from kx.jacek.it.pl (cl-158.mbx-01.si.sixxs.net [IPv6:2001:15c0:65ff:9d::2]) (authenticated bits=0) by smtpauth.ipartners.pl with ESMTP id l7LGHntF014505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Aug 2007 18:17:51 +0200 (CEST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by kx.jacek.it.pl (Postfix) with ESMTP id CF36E5982AD; Tue, 21 Aug 2007 18:17:48 +0200 (CEST) From: Jacek Zapala To: Daniel Hartmeier In-Reply-To: <20070821145047.GC32421@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> <1187705811.30269.5.camel@localhost.localdomain> <20070821143125.GB32421@insomnia.benzedrine.cx> <1187707117.846.3.camel@localhost.localdomain> <20070821145047.GC32421@insomnia.benzedrine.cx> Content-Type: text/plain Date: Tue, 21 Aug 2007 18:17:48 +0200 Message-Id: <1187713068.3973.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 16:17:57 -0000 On Tue, 2007-08-21 at 16:50 +0200, Daniel Hartmeier wrote: > Could you possibly try the patch below, and see if it fixes the > problem > (with rfc1323 enabled again)? > > We're accessing th_flags from the TCP header embedded in the ICMPv6 > packet, even though we only pulled up the first 8 bytes of the mbuf, > because the sender doesn't have to provide more of the header. > > There could be random garbage there, and the bit corresponding to > TH_SYN might be set, so the window scale factor is not applied. Not > sure > if that would be reproducable so reliably, but it sure is a bug ;) > I have applied the patch and it looks like it has helped. But I'm not sure if I understood well - you suspect that only 8 bytes of tcp header are copied from the original tcp packet to the icmp message by the router? TCP packet in the icmp message looks like almost complete (of course it is shorter than the original due to 1280 bytes icmp packet limit). I have captured that traffic so I can send you full packets if you would like to look at them. Jacek From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 16:35:14 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7919D16A418 for ; Tue, 21 Aug 2007 16:35:14 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [IPv6:2001:6f8:1098::2]) by mx1.freebsd.org (Postfix) with ESMTP id 626D313C474 for ; Tue, 21 Aug 2007 16:35:08 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id l7LGZ5Xs021622 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 18:35:05 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id l7LGZ5aR031035; Tue, 21 Aug 2007 18:35:05 +0200 (MEST) Date: Tue, 21 Aug 2007 18:35:05 +0200 From: Daniel Hartmeier To: Jacek Zapala Message-ID: <20070821163505.GA28667@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> <1187705811.30269.5.camel@localhost.localdomain> <20070821143125.GB32421@insomnia.benzedrine.cx> <1187707117.846.3.camel@localhost.localdomain> <20070821145047.GC32421@insomnia.benzedrine.cx> <1187713068.3973.6.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1187713068.3973.6.camel@localhost.localdomain> User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 16:35:14 -0000 On Tue, Aug 21, 2007 at 06:17:48PM +0200, Jacek Zapala wrote: > I have applied the patch and it looks like it has helped. Great, thank you! > But I'm not sure if I understood well - you suspect that only 8 bytes of > tcp header are copied from the original tcp packet to the icmp message > by the router? No, the router is only required (by the RFCs) to quote the first 8 bytes of the TCP header. It may provide more. But pf can't rely on there being more (another router might legally only provide the minimum, and checking how many bytes there are would mean additional cost), so it only looks at the first 8 bytes. Before it can look at any header fields, it has to 'pull up' the bytes it wants to look at, making them adjacent in memory. It only does that for the first 8 bytes. The bug is/was that it then accessed th_flags, even though that field is beyond the first 8 bytes, and the result was that a random byte was used instead of the th_flags from the TCP header in the ICMP error. Hence, what pf perceived as th_flags randomly had TH_SYN set, which made pf not apply the window scaling factor in the sequence number check. The larger the window scaling factors, the higher the chance that failing to apply the factor will make the difference between allowing the packet and dropping it. I don't know why in your case 'random' means 'mostly/always TH_SYN set', but that might be due to your architecture, or mbuf memory layout. Who knows, that byte might contain a MAC address, and you happen to have a NIC with a specific MAC address byte ;) There's nothing wrong with the router, the bug is in pf. Let me know if anything changes, or when you're sure that the problem is resolved. Thanks for your help! Daniel From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 17:37:01 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1369F16A419 for ; Tue, 21 Aug 2007 17:37:01 +0000 (UTC) (envelope-from adityaa.kiran@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id D069713C4A7 for ; Tue, 21 Aug 2007 17:37:00 +0000 (UTC) (envelope-from adityaa.kiran@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1293966waf for ; Tue, 21 Aug 2007 10:37:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=dsUZLn54zgUEMOZjSHuROxqnAW2w0xfCRRRsB+WNBkLssWej38MjhNi0zneQdiNjU/U9SF7PG5HjCmz2abMMErrbqwwskVZGaWwZ20LNFA2COQhf+p8yZOSHil+8czckD8pOaZc6Af8mKIv3iv5vMzMNz/MDu0ESixoVl7jwOsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SQ3257Q41ytGldUMTk6nzG3jwQ/x5d6n45LKUMbQC24cY+zCBg6IxhfitgtM3zD+V0Y2imakeJIgieU23Z5QD9J6qU8I7HLV2ow1jyP1R1SZLgFA2IJoNs9sJItedMJPlPfvUuvdig4dULPXCYRJy99KndCD2THM9JJYRtkPfiE= Received: by 10.115.78.1 with SMTP id f1mr3030746wal.1187717819304; Tue, 21 Aug 2007 10:36:59 -0700 (PDT) Received: by 10.114.72.3 with HTTP; Tue, 21 Aug 2007 10:36:59 -0700 (PDT) Message-ID: <994cd1cf0708211036j72c84e37iaae4b56274bf9798@mail.gmail.com> Date: Tue, 21 Aug 2007 23:06:59 +0530 From: "aditya kiran" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Racoon - socket based policy negotiation - is it 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, 21 Aug 2007 17:37:01 -0000 Hi, I was wondering why racoon doesnt support negotiation for per-socket policies? Is it because racoon maintains its database based on src and dst addresses and a port based one doesnt always has one? Is this support is planned for any future ipsec-tools release? It is just mentioned at http://www.freshports.org/security/racoon/ that racoon will not negotiate per socket policies . But wil this support is planned for any future racoon release? Any information on this is highly appreciated.. Thanks, Adityaa From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 17:43:16 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A2416A417 for ; Tue, 21 Aug 2007 17:43:16 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 2459D13C4B4 for ; Tue, 21 Aug 2007 17:43:16 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1295942waf for ; Tue, 21 Aug 2007 10:43:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KYQEvTQNsLaYHt3m454khUodyICRsq8dIY4HXgLhfE99j1PoRyDuqfMCdc2psHdS/WelkFVH2WPUnvzoPEtK9Xr+ZGgVmkgpxN/LApd7UKKCkaj1TFgiCvDnrBlQLJZm2rbMho0uO4yT/dJiYWLQCmaxhjI7FF+5do8OYlLjxUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TDeLqB5np8lxPrIAsWxxMlpClFImnnHckFhGXLTmxlFHogchG6ps1c0jsorvMdiJJPIujbALVdCn9JsvUrwOAbSrn23OVCnuPtHrHG3uEl5Cbjd3wbpam+XMer4GSODkem/VqNk8Q9jSoGgaGUJoOamDzqcgC4SGEV/HqZaYfZ0= Received: by 10.114.127.1 with SMTP id z1mr26311wac.1187718195776; Tue, 21 Aug 2007 10:43:15 -0700 (PDT) Received: by 10.114.76.7 with HTTP; Tue, 21 Aug 2007 10:43:15 -0700 (PDT) Message-ID: Date: Tue, 21 Aug 2007 13:43:15 -0400 From: "Scott Ullrich" To: "George V. Neville-Neil" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070818102803.GA1319@jayce.zen.inc> <20070820082728.GA28863@zen.inc> Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: Racoon(ipsec-tools) enters sbwait state or 100% CPU utilization quite often on RELENG_1_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2007 17:43:16 -0000 On 8/20/07, George V. Neville-Neil wrote: > > Your raccoon config, if you could send it to me, would be helpful. Not a problem. Look for an email from "Seth" in your inbox in the next day or so (he is in europe on a different time schedule). Thanks again for your help, George, we appreciate it! Scott From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 21:14:56 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A176016A468 for ; Tue, 21 Aug 2007 21:14:56 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 94B0013C468 for ; Tue, 21 Aug 2007 21:14:56 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 9AC2A1A4D86; Tue, 21 Aug 2007 13:50:55 -0700 (PDT) Date: Tue, 21 Aug 2007 13:50:55 -0700 From: Alfred Perlstein To: net@freebsd.org Message-ID: <20070821205055.GQ87451@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2007 21:14:56 -0000 Hello all, I would like to reserve about 64 entries for VENDOR specific address families in sys/socket.h. I think this will allow vendors to comfortably use the array of address families without worrying about overlap with FreeBSD protocols. If no one objects I plan to commit this in the next few days. The format will be along the lines of: AF_VENDOR0 -> AF_VENDOR63 Suggestions? thank you, -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Tue Aug 21 23:31:51 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F35A16A419 for ; Tue, 21 Aug 2007 23:31:51 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 73DE413C4DA for ; Tue, 21 Aug 2007 23:31:51 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 47E891A4D86; Tue, 21 Aug 2007 16:29:56 -0700 (PDT) Date: Tue, 21 Aug 2007 16:29:56 -0700 From: Alfred Perlstein To: net@freebsd.org Message-ID: <20070821232956.GT87451@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 21 Aug 2007 23:31:51 -0000 I trimmed the sender of this because I got it in private mail, that said I thought it was a good bunch of questions so I am replying to it. > 64? are you intending to bump AF_MAX or allocate them sequentially such > that adding another AF will require AF_MAX to grow a lot? > > In general this seems like a bad idea to me. I suggest you need to > (publicly) explain what you are doing and why this is a good idea. The goal here is to allow vendors to add their own constants without worrying about conflicting with FreeBSD constants. It will allow vendors to maintain some semblance of binary compatibility against FreeBSD. If you look at libpcap: http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/pcap/bpf.h?rev=1.15 You can see that Juniper has asked for some number of reserved "families", in our case, I think it would be a bit greedy to grow the list _just_ for Juniper, so I suggested something that would work for every vendor. As far as implementation details, either one works for me, do you have any particular preference? Other than the actual delta, will this have any noticeable negative impact that you can see? -- - Alfred Perlstein From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 00:12:32 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7644116A419 for ; Wed, 22 Aug 2007 00:12:32 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 0254F13C45A for ; Wed, 22 Aug 2007 00:12:31 +0000 (UTC) (envelope-from max@love2party.net) Received: from dslb-088-066-022-164.pools.arcor-ip.net [88.66.22.164] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1INdg04BDm-00026U; Wed, 22 Aug 2007 02:02:25 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Wed, 22 Aug 2007 02:02:17 +0200 User-Agent: KMail/1.9.7 References: <20070821232956.GT87451@elvis.mu.org> In-Reply-To: <20070821232956.GT87451@elvis.mu.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1348266.DDDgb8NVuj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708220202.23004.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+QibD2haLEIsd07f8pPPmH7GJWH1J6L07KYfy a7/EJtLy98e81u1QhcLFA3n18nC6Db6J2teAF9cyA1YL8DV6xS 4XVh134JJe1CJ0w+KGPfyWABapaXLR27orfcIwq3nA= Cc: Alfred Perlstein Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 00:12:32 -0000 --nextPart1348266.DDDgb8NVuj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 22 August 2007, Alfred Perlstein wrote: > I trimmed the sender of this because I got it in private mail, that > said I thought it was a good bunch of questions so I am replying > to it. > > > 64? are you intending to bump AF_MAX or allocate them sequentially > > such that adding another AF will require AF_MAX to grow a lot? > > > > In general this seems like a bad idea to me. I suggest you need to > > (publicly) explain what you are doing and why this is a good idea. > > The goal here is to allow vendors to add their own constants without > worrying about conflicting with FreeBSD constants. It will allow > vendors to maintain some semblance of binary compatibility against > FreeBSD. > > If you look at libpcap: > > http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/pcap/bpf.h?rev=3D1.15 > > You can see that Juniper has asked for some number of reserved > "families", in our case, I think it would be a bit greedy to > grow the list _just_ for Juniper, so I suggested something that > would work for every vendor. > > As far as implementation details, either one works for me, do you > have any particular preference? > > Other than the actual delta, will this have any noticeable negative > impact that you can see? DLTs are something very different to address families. DLTs are cheap as=20 they are simply a number that is passed around. In contrast to that,=20 there are some AF_MAX sized arrays in the kernel (e.g. if_afdata[] in=20 struct ifnet or the routing tables) these will grow if you change=20 AF_MAX - that's a bad thing! Could you provide a patch with what you have in mind so I (and other=20 similarly confused people) can understand what you have in mind. Extending AF_MAX by 64 is out of the question, IMHO. =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 --nextPart1348266.DDDgb8NVuj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBGy30OXyyEoT62BG0RAjmMAJ0YXaeodrXZxB4UJ0Q2TIP87aKxGACfU0WT H2U6yTwii28tYwucnk1OfWs= =g2Na -----END PGP SIGNATURE----- --nextPart1348266.DDDgb8NVuj-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 01:37:15 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E65116A41B for ; Wed, 22 Aug 2007 01:37:15 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 224CC13C442 for ; Wed, 22 Aug 2007 01:37:15 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id B2BDE17376; Tue, 21 Aug 2007 20:17:31 -0500 (CDT) Date: Tue, 21 Aug 2007 20:17:31 -0500 From: "Christian S.J. Peron" To: Alfred Perlstein Message-ID: <20070822011731.GA50757@sub.vaned.net> References: <20070821205055.GQ87451@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070821205055.GQ87451@elvis.mu.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 01:37:15 -0000 Can you please submit your patch to the group for review? On Tue, Aug 21, 2007 at 01:50:55PM -0700, Alfred Perlstein wrote: > Hello all, > > I would like to reserve about 64 entries for VENDOR specific address > families in sys/socket.h. > > I think this will allow vendors to comfortably use the array of > address families without worrying about overlap with FreeBSD > protocols. > > If no one objects I plan to commit this in the next few days. > > The format will be along the lines of: > > AF_VENDOR0 -> AF_VENDOR63 > > Suggestions? > > thank you, > -- > - Alfred Perlstein > _______________________________________________ > 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" -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 07:25:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C35E16A417 for ; Wed, 22 Aug 2007 07:25:18 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 45F4413C45E for ; Wed, 22 Aug 2007 07:25:18 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 566C0695E; Wed, 22 Aug 2007 11:25:16 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 346A56406; Wed, 22 Aug 2007 11:25:16 +0400 (MSD) Date: Wed, 22 Aug 2007 11:25:11 +0400 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20070822072511.GD59317@rambler-co.ru> References: <20070820151142.GA20183@rambler-co.ru> <20070820165354.GN99491@funkthat.com> <20070820183012.GA27177@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20070820183012.GA27177@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: John-Mark Gurney Subject: Re: maximum number of outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 07:25:18 -0000 On Mon, Aug 20, 2007 at 10:30:12PM +0400, Igor Sysoev wrote: > On Mon, Aug 20, 2007 at 09:53:55AM -0700, John-Mark Gurney wrote: > > > Igor Sysoev wrote this message on Mon, Aug 20, 2007 at 19:11 +0400: > > > It seems that FreeBSD can not make more than > > > > > > net.inet.ip.portrange.last - net.inet.ip.portrange.first > > > > > > simultaneous outgoing connections, i.e., no more than about 64k. > > > > > > If I made ~64000 connections 127.0.0.1:XXXX > 127.0.0.1:80, then > > > connect() to an external address returns EADDRNOTAVAIL. > > > > Isn't this more of a limitation of TCP/IP than FreeBSD? because you > > need to treat the srcip/srcport/dstip/dstport as a unique value, and > > in your test, you are only changing one of the four... Have you tried > > running a second we server on port 8080, and see if you can connect > > another ~64000 connections to that port too? > > No, TCP/IP limitation is for XXXX in 127.0.0.1:XXXX <> 127.0.0.1:80, > but FreeBSD limits all outgoing connections to the port range, i.e. > > local part remote part > 127.0.0.1:5000 <> 127.0.0.1:80 > 192.168.1.1:5000 <> 10.0.0.1:25 > > can not exist simultaneously, if both connections were started from > local host. To be exact - if connect() was called on unbound socket. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 07:27:40 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BA7A16A46B for ; Wed, 22 Aug 2007 07:27:40 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id AFF5813C48A for ; Wed, 22 Aug 2007 07:27:39 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so63871wra for ; Wed, 22 Aug 2007 00:27:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RGkNseICE+UbgsvzoqOSV+L0BUl9AafoMn7RKoTDxTf+VE9M4eG2AyW3hOroEEOO35eI8lojv6FN//X0AWfBcx18mwmsNgLrsZzRDcBpAlS/ZwloGXhm8LJDQUASIMKYSqes4nVpfmet6g9kQOox7f9rD+ifDQBc2D5zVccGcrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=j3VcYOAxQadScPYP1xt74UA5qDV/dk86d1ONwhfha4J3lQ+ymLdToIWSjf2YYKj+S9Pn4qriC6Dcr74zNd6m3zNwQ0nXVDAFf36wMNUqpcm2llG1y63zX8H8fJXjGPmforXssvtyhqub2LDoeCrYVlvAJ6gyVSRFxpHjzJawFSw= Received: by 10.90.81.14 with SMTP id e14mr3825765agb.1187766180366; Wed, 22 Aug 2007 00:03:00 -0700 (PDT) Received: by 10.90.119.18 with HTTP; Wed, 22 Aug 2007 00:03:00 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 10:03:00 +0300 From: "Ivo Vachkov" To: freebsd-net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 07:27:40 -0000 Does FreeBSD rtalloc*() (or any other) functions implement route caching and how ? I looked at the code but it's not exactly easiest thing to read / understand :) Ivo From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 13:00:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4909916A4C6 for ; Wed, 22 Aug 2007 13:00:18 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id EAE0F13C45B for ; Wed, 22 Aug 2007 13:00:17 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so15228anc for ; Wed, 22 Aug 2007 06:00:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=p1OSSF2mXo8n4mWxBAG0h7ljZMnDN1OgngZ3f6e5olq114yVF4xIUZtaQt+Q52HM+IPJNLUboQuNCXUgq61ews2IROOurZcUBHnFfNKhvrUt2t4wtEUvOsq5Bk74b6a/ehnImHwuScVujoFIk0thTYhSpitsJTdTsYshBxsOWX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=LXAj7smKIA1dF+h7MWoyg16MW+mTa7p0aXD3A4DxRjK6KW7kZ4z6kMUKEH/sZ8ODbjZYwN22F0JsawjdEOJ16xmxF+M+UH1UWZelSVqwQHT59/H4xwQHactOOOhNThIDg2qqu4omkQBQf/dm36LQy1r9alJwISiqSOWF/52h908= Received: by 10.90.116.6 with SMTP id o6mr724251agc.1187787599163; Wed, 22 Aug 2007 05:59:59 -0700 (PDT) Received: by 10.90.119.18 with HTTP; Wed, 22 Aug 2007 05:59:59 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 15:59:59 +0300 From: "Ivo Vachkov" To: freebsd-net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Wrong function descriptio X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 13:00:18 -0000 Hello all, I find this: . . . /* * Try to forward a packet based on the destination address. * This is a fast path optimized for the plain forwarding case. * If the packet is handled (and consumed) here then we return 1; * otherwise 0 is returned and the packet should be delivered * to ip_input for full processing. */ struct mbuf * ip_fastforward(struct mbuf *m) . . . in ip_fastfwd.c (FreeBSD CURRENT source tree). I'd say this is probably true for the NetBSD, but i see that return value is actually a pointer to struct mbut, not an integer. Probably someone should update it with the right description of the return value type and meaning. /ipv From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 14:25:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C4516A421 for ; Wed, 22 Aug 2007 14:25:39 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 17F3D13C45B for ; Wed, 22 Aug 2007 14:25:39 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 953412314D; Wed, 22 Aug 2007 10:25:37 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 22 Aug 2007 10:25:37 -0400 X-Sasl-enc: UzovPY+qoIYPHdFvX4gGaXs7u7zXW7QEMQWv/S2gK1hr 1187792737 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id DC4C5148D; Wed, 22 Aug 2007 10:25:36 -0400 (EDT) Message-ID: <46CC475F.8030505@FreeBSD.org> Date: Wed, 22 Aug 2007 15:25:35 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Ivo Vachkov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 14:25:39 -0000 Ivo Vachkov wrote: > Does FreeBSD rtalloc*() (or any other) functions implement route > caching and how ? I looked at the code but it's not exactly easiest > thing to read / understand :) Not really, at least, not in the way one would think. rtalloc() is a legacy function. ip_output() will still call rtalloc() if you pass it a filled out 'struct route', a structure which is not a route, but an internal request to look up a route. This is a wrapper for rtalloc_ign(), which in turn is a wrapper for rtalloc1(), the function which does the actual lookup. rtalloc_ign() is pretty straightforward. Note however that this approach only checks the RTF_UP flag and ifp, nothing more. This makes it suitable for implementing floating statics, but nothing more dynamic than that. regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 14:34:36 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAFF116A41B for ; Wed, 22 Aug 2007 14:34:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8248613C47E for ; Wed, 22 Aug 2007 14:34:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 501EE251E0; Wed, 22 Aug 2007 10:19:30 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 22 Aug 2007 10:19:30 -0400 X-Sasl-enc: ccQ4dmyAhB7O2X4RMFvCjDLowwJL+ENiQoEodWT3vbON 1187792369 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id BF4AB230A3; Wed, 22 Aug 2007 10:19:29 -0400 (EDT) Message-ID: <46CC45F0.3000105@FreeBSD.org> Date: Wed, 22 Aug 2007 15:19:28 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Alfred Perlstein References: <20070821232956.GT87451@elvis.mu.org> In-Reply-To: <20070821232956.GT87451@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 14:34:36 -0000 I second Max. If you are going to introduce a bunch of AF_* constants into the tree you have to be very careful as AF_MAX is used to size arrays and figure out how many radix trie heads to allocate. It could be argued this wastes a bunch of CPU time and memory, though I speculate 'not much' at the moment; I am just a bit concerned that we have ifnet->if_afdata which is also sized based on AF_MAX, 37, even though most of the protocols in it are never attached to ifnets. The only domain I've seen which really uses if_afdata is PF_INET6. PF_INET does not use it at all. In my opinion, there are structures per-family per-ifnet which really belong hung-off ifnet on a 1:1 basis and would simplify some of the lazy allocations we have further down in the stack. If AF_MAX increases significantly so will wasted memory. If you are going to make any significant changes here, please considering moving this stuff to a more dynamic method of allocation. On the other hand, if you don't need to reference these constants in the kernel at all, and they will all exist beyond AF_MAX, then you can disregard what I've said and append them to the rest of the list. That is pretty much what happens for the libpcap/bpf DLT constants (which are not an exact analogue of the AF constants - we don't allocate other, larger kernel structures based on their value). regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 14:38:26 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0194516A469 for ; Wed, 22 Aug 2007 14:38:26 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id B138413C457 for ; Wed, 22 Aug 2007 14:38:25 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so21928anc for ; Wed, 22 Aug 2007 07:38:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FuFE2a0VeZtjNpw/93y+TNA4WJZJsi7ydpxLhBXXCi32zsgxBSrSV5toUtdMI3iirlwV908t836RW5PL4RJoOkjH6OHzTvO/qhIOg5s3vVtz9CYVNb88kbmnDNf7X5RKoiU1cXDeND2oogrsSFfyGqW4cuEb5GycLfznr4mpZ50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C4UrLYAjD6JCO3qmjyXCCX7UvbFkmcN/oo0Go1VloqPZoksjRrUr8lDhzWbq1sZP0dK7zDsYCuLbOKC6Ewgt9XJYKthQKvLPod8/mrFF9MZ/7edio2tyMb8bmtPdVx7VhOBpYLES6p1pwJsWnKqiE44o05nrKCaE7UKUCyAPyK0= Received: by 10.90.113.20 with SMTP id l20mr568440agc.1187793470181; Wed, 22 Aug 2007 07:37:50 -0700 (PDT) Received: by 10.90.119.18 with HTTP; Wed, 22 Aug 2007 07:37:50 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 17:37:50 +0300 From: "Ivo Vachkov" To: "Bruce M. Simpson" In-Reply-To: <46CC475F.8030505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46CC475F.8030505@FreeBSD.org> Cc: freebsd-net Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 14:38:26 -0000 Actually there is: struct route_in6 ip6_forward_rt; that "caches" the last route used (thanks blue !!!) but i think this technique is pointless in a multiflow traffic. Is it reasonable to believe that route caches can improve networking performance or we should leave it up to the routing table itself ? On 8/22/07, Bruce M. Simpson wrote: > Not really, at least, not in the way one would think. rtalloc() is a > legacy function. > > ip_output() will still call rtalloc() if you pass it a filled out > 'struct route', a structure which is not a route, but an internal > request to look up a route. > > This is a wrapper for rtalloc_ign(), which in turn is a wrapper for > rtalloc1(), the function which does the actual lookup. > > rtalloc_ign() is pretty straightforward. Note however that this approach > only checks the RTF_UP flag and ifp, nothing more. This makes it > suitable for implementing floating statics, but nothing more dynamic > than that. > > regards, > BMS > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 14:38:28 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A7F916A4F0 for ; Wed, 22 Aug 2007 14:38:28 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by mx1.freebsd.org (Postfix) with ESMTP id 56E8913C474 for ; Wed, 22 Aug 2007 14:38:28 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so168985wxd for ; Wed, 22 Aug 2007 07:38:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HmQjeKCG73t7WuRtgkQVzxig2RB+RN1q1aIaCjYGFiF3XcEXzHE4Gzzrd3QHCXTka++XpA/ZvI16QJINlwxclOMp6cM/Vy24dX6fV0f7RUZFobM9S9K6MZCPPiFWK8TZZ9izDnWG88rlLZQaRANJmBjw2KaVlfZo/Q52WQhkrwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FsQRP8h9dRcbycbyswCd8q2XeUMxUgW7GYvZpVBG6n/mEDM6EADaNB8OtC2Cz6QKzRJ3QajpOmUvNBIjcWBdy+8y6iYY4FnsQ2atSbzorE9AikPDvMEWpASMUzjB/VHybDZl96u8iNwL/lBS3Uju2VMB4M3IadG6wGcDoshzL9I= Received: by 10.90.50.1 with SMTP id x1mr89492agx.1187793497173; Wed, 22 Aug 2007 07:38:17 -0700 (PDT) Received: by 10.90.119.18 with HTTP; Wed, 22 Aug 2007 07:37:50 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 17:37:50 +0300 From: "Ivo Vachkov" To: "Bruce M. Simpson" In-Reply-To: <46CC475F.8030505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46CC475F.8030505@FreeBSD.org> Cc: freebsd-net Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 14:38:28 -0000 Actually there is: struct route_in6 ip6_forward_rt; that "caches" the last route used (thanks blue !!!) but i think this technique is pointless in a multiflow traffic. Is it reasonable to believe that route caches can improve networking performance or we should leave it up to the routing table itself ? On 8/22/07, Bruce M. Simpson wrote: > Not really, at least, not in the way one would think. rtalloc() is a > legacy function. > > ip_output() will still call rtalloc() if you pass it a filled out > 'struct route', a structure which is not a route, but an internal > request to look up a route. > > This is a wrapper for rtalloc_ign(), which in turn is a wrapper for > rtalloc1(), the function which does the actual lookup. > > rtalloc_ign() is pretty straightforward. Note however that this approach > only checks the RTF_UP flag and ifp, nothing more. This makes it > suitable for implementing floating statics, but nothing more dynamic > than that. > > regards, > BMS > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 15:30:37 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15DBF16A421 for ; Wed, 22 Aug 2007 15:30:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id DA5DC13C4DA for ; Wed, 22 Aug 2007 15:30:36 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 1E0BA23682; Wed, 22 Aug 2007 11:30:36 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 22 Aug 2007 11:30:36 -0400 X-Sasl-enc: 6WVZjMpXUOsQWZTDo2SNLo6+AAa1RXMJgNT1NSywhQWh 1187796635 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id AB63813AD1; Wed, 22 Aug 2007 11:30:35 -0400 (EDT) Message-ID: <46CC5698.7090200@FreeBSD.org> Date: Wed, 22 Aug 2007 16:30:32 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Ivo Vachkov References: <46CC475F.8030505@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 15:30:37 -0000 Ivo Vachkov wrote: > Actually there is: > > struct route_in6 ip6_forward_rt; > > that "caches" the last route used (thanks blue !!!) but i think this > technique is pointless in a multiflow traffic. > Yes, this is why OpenBSD got rid of this form of 'route caching'. > Is it reasonable to believe that route caches can improve networking > performance or we should leave it up to the routing table itself ? > I believe that if one goes beyond a single radix trie, as is needed for multi-pathing with multicast and source policy routing, route caching is *required* to achieve good performance. Also, if FreeBSD moves ARP and NDP out of the radix trie, a route cache would be highly preferable as it amortizes the lock acquisition which would other be required for ARP/NDP/other layer 2 next-hop resolution. BMS From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 15:39:10 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A58FE16A419 for ; Wed, 22 Aug 2007 15:39:10 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id 16E6013C4A8 for ; Wed, 22 Aug 2007 15:39:09 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 5753 invoked by uid 1001); 22 Aug 2007 15:12:28 -0000 Date: Wed, 22 Aug 2007 17:12:28 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20070822151228.GB22194@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: <46CC475F.8030505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 15:39:10 -0000 On Wed, Aug 22, 2007 at 05:37:50PM +0300, Ivo Vachkov wrote: > Actually there is: > > struct route_in6 ip6_forward_rt; > > that "caches" the last route used (thanks blue !!!) but i think this > technique is pointless in a multiflow traffic. > > Is it reasonable to believe that route caches can improve networking > performance or we should leave it up to the routing table itself ? > Just because you believe that route caches are great doesn't mean it is true. Show some real code and include benchmarks with various workloads (e.g. a core router that is hit by many many many sessions). Until now all caching solutions resulted in very bad performance on busy boxes. Remember ip_fastforward or how was it called? Another example are all crapy L3 switches that burn down if the CAM (chache) is flodded. IMO it is better to make the route lookup faster and forget about caching. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 17:13:22 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29E9116A41A for ; Wed, 22 Aug 2007 17:13:22 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id E176513C457 for ; Wed, 22 Aug 2007 17:13:21 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 65B92255C7; Wed, 22 Aug 2007 13:13:21 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 22 Aug 2007 13:13:21 -0400 X-Sasl-enc: GWYHVALrOxgVPSjf8lirsUpbn4cOiALcu9Hz49Ucq3x5 1187802801 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id D6857231E5; Wed, 22 Aug 2007 13:13:20 -0400 (EDT) Message-ID: <46CC6EAF.3010003@FreeBSD.org> Date: Wed, 22 Aug 2007 18:13:19 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Claudio Jeker , freebsd-net@freebsd.org References: <46CC475F.8030505@FreeBSD.org> <20070822151228.GB22194@diehard.n-r-g.com> In-Reply-To: <20070822151228.GB22194@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 17:13:22 -0000 Claudio Jeker wrote: > Just because you believe that route caches are great doesn't mean it is > true. Show some real code and include benchmarks with various workloads > (e.g. a core router that is hit by many many many sessions). > It is a reasonable approach, for a uniprocessor design, to focus on optimizing the route lookup as much as possible. Does this approach scale to SMP, though? This is still a very much open question and from what I have seen of the OpenBSD implementation, it only addresses the uniprocessor case - again please correct me here if I have missed any details. I believe the Linux dst cache is strongly tied to the IBM-patented Remote-Copy-Update algorithm based on what I've read about their LC-trie implementation. > Until now all caching solutions resulted in very bad performance on busy > boxes. Remember ip_fastforward or how was it called? Another example are > all crapy L3 switches that burn down if the CAM (chache) is flodded. > I assume you are referring to NetBSD's flow-based IP forwarding cache, which was implemented outside of the scope of SMP; spl-style interrupt priority masking was still in use at that time. It is established that saturating content-addressable memory is going to lead to the slow path being taken, however, that's the trade-off one makes with these designs. > IMO it is better to make the route lookup faster and forget about caching. > My concern is that you may be comparing apples with oranges here. In the case of SMP, locking does become a consideration, and caches, if carefully implemented, are one way of addressing this. On the other hand, CPU affinity has been proposed as a limited solution, however it depends how this is implemented - affinity for lookups, forwarding, or both? Perhaps there is something I am missing about how the OpenBSD implementation deals with SMP, as I am not as familiar with their code as FreeBSD's. regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 21:39:39 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3DA716A421; Wed, 22 Aug 2007 21:39:39 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 12A4C13C45B; Wed, 22 Aug 2007 21:39:39 +0000 (UTC) (envelope-from max@love2party.net) Received: from dslb-088-064-182-170.pools.arcor-ip.net [88.64.182.170] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1INxvM2KA5-0002Ul; Wed, 22 Aug 2007 23:39:37 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Wed, 22 Aug 2007 23:39:16 +0200 User-Agent: KMail/1.9.7 References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> In-Reply-To: <46CC45F0.3000105@FreeBSD.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2060232.sOZ9M2e3cC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708222339.23287.max@love2party.net> X-Provags-ID: V01U2FsdGVkX197nQx4vovu0OCHfizna8n2hk/CFuO99MqhICD htE7LuEkAkIfJBjFVWq8FEQQT/TcXtp2XGzTczjjSDN92mCHiP gvy2HDiiFdqpth8frbOA+HZHidbGYFQ0muLRNCzr/A= Cc: Alfred Perlstein , "Bruce M. Simpson" Subject: Re: Allocating AF constants for vendors. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 21:39:39 -0000 --nextPart2060232.sOZ9M2e3cC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 22 August 2007, Bruce M. Simpson wrote: [...] > On the other hand, if you don't need to reference these constants in > the kernel at all, and they will all exist beyond AF_MAX, then you can > disregard what I've said and append them to the rest of the list. Please make sure to leave a bit of space between AF_MAX and your constants= =20 so we could still grow AF_MAX if the need should ever arise. =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 --nextPart2060232.sOZ9M2e3cC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD4DBQBGzK0LXyyEoT62BG0RAgFRAJdRG0NUV5hyDwX2A/RJT6aIB18uAJwJVc6l jEKQhhDPFjhkvi5oETp3Lg== =eQFk -----END PGP SIGNATURE----- --nextPart2060232.sOZ9M2e3cC-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 21:50:50 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F2A216A417 for ; Wed, 22 Aug 2007 21:50:50 +0000 (UTC) (envelope-from SRS0=ea0557f14be760df519139ca06405eaece96115c=435=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [IPv6:2001:400:6000:1::66]) by mx1.freebsd.org (Postfix) with ESMTP id 5E62D13C47E for ; Wed, 22 Aug 2007 21:50:49 +0000 (UTC) (envelope-from SRS0=ea0557f14be760df519139ca06405eaece96115c=435=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id BDU65647; Wed, 22 Aug 2007 14:50:47 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 174954507D; Wed, 22 Aug 2007 14:50:47 -0700 (PDT) To: Max Laier In-Reply-To: <200708211114.09938.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1187819447_16164P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 22 Aug 2007 14:50:47 -0700 From: "Kevin Oberman" Message-Id: <20070822215047.174954507D@ptavv.es.net> Cc: freebsd-net@freebsd.org Subject: Re: Unable to set socket size > 16MB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 21:50:50 -0000 --==_Exmh_1187819447_16164P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday Aug. 21, 2007, Max Laier wrote: > On Monday 20 August 2007, Kevin Oberman wrote: > > I am trying to tune a FreeBSD system for ~100 ms. RTT at 10 Gbps. (I > > posted another message about this back on 8/17). I am running current > > of late July 31. > > > > I am using iperf and I have confirmed (with gdb) that it is passing > > setsockopt a size of 67108864 and setsockopt is returning 0. When I > > capture the SYN packets, I am seeing a window of 64K and a scale > > factor of 8. For 64 MB, the scale factor should be 10. > > > > Is there some hidden limitation that would restrict this or is there a > > bug involved? I have set net.inet.tcp.(send|recv)space to > > 64m. kern.ipc.maxsockbuf=3D134217728. > > > > Here is the 3-way handshake: > > 13:57:45.571614 IP lbl.52460 > perf-bnl.commplex-link: S > > 4070670678:4070670678(0) win 65535 > 8,sackOK,timestamp 345761341 0> 13:57:45.665645 IP > > perf-bnl.commplex-link > lbl.52460: S 3909263475:3909263475(0) ack > > 4070670679 win 65535 > 3623078172 345761341> 13:57:45.665683 IP lbl.52460 > > > perf-bnl.commplex-link: . ack 1 win 65535 > 3623078172> > > > > Any reason for this? Any workaround or fix? Or am I missing something? > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c#rev1.104 > seems to be the culprit: > > while (wscale < TCP_MAX_WINSHIFT && > (0x1 << wscale) < tcp_minmss) > /* 216 */ > wscale++; > > It's obvious that the above will bound wscale to 8 with the default of 216 > for minmss. You should be able to set a higher minmss for a temporary > work around, but this calculation really seems wrong to me. Esp. given > the following comment for tcp_minmss: > > ... > * with packet generation and sending. Set to zero to disable MINMSS > * checking. This setting prevents us from sending too small packets. > */ Thanks, Max! That fixed this problem very nicely. I changed minmss and my window went to 64M. I really agree that the code is simply wrong. I'm a bit at a loss as to why this check is done, but I'm probably missing something obvious. In any case, the work-around worked! Now on to the next issue. This got my bandwidth up from 1.4G to 2.3G Still pretty pathetic. I look at a tcptrace and see that the receive window is always sitting at > 50 MB, but the "Outstanding Data" climbs to about 28 MB and stops there. Complete flat line from the to the end of the run. I do see a lot of packets that update the window size only. (That is they have the ACK bit set, but just keep ACKing the same sequence number and differ only in the window size.) Often I get hundreds of them in a row. I think this points out a problem, but probably not what is killing my throughput. I see an old (2004) message to net@freebsd.org which reports this and Andre asked him to submit a PR and send him the PR number. I have no idea if it was ever submitted, but the code is unchanged and I suspect it never was. In any case, I can't find it. I guess I'll go ahead and submit a PR. I'm starting to suspect that the TCP code has a number of issues in cases where there is a great deal of outstanding data due to high bandwidth and long RTTs. This is probably something that has not ever had too much attention or exercise. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1187819447_16164P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGzK+3kn3rs5h7N1ERAoHbAJ9z2Z3VdKpIEJP1GLjCFsczxxiWKgCdG0LP 5xf7SzToKJc36sj/AH/B0e8= =ubTQ -----END PGP SIGNATURE----- --==_Exmh_1187819447_16164P-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 22:44:40 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3897916A417 for ; Wed, 22 Aug 2007 22:44:40 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id B180313C494 for ; Wed, 22 Aug 2007 22:44:39 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 790 invoked by uid 1001); 22 Aug 2007 22:44:38 -0000 Date: Thu, 23 Aug 2007 00:44:38 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20070822224438.GC30376@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: <46CC475F.8030505@FreeBSD.org> <20070822151228.GB22194@diehard.n-r-g.com> <46CC6EAF.3010003@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46CC6EAF.3010003@FreeBSD.org> User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 22:44:40 -0000 On Wed, Aug 22, 2007 at 06:13:19PM +0100, Bruce M. Simpson wrote: > Claudio Jeker wrote: > >Just because you believe that route caches are great doesn't mean it is > >true. Show some real code and include benchmarks with various workloads > >(e.g. a core router that is hit by many many many sessions). > > > > It is a reasonable approach, for a uniprocessor design, to focus on > optimizing the route lookup as much as possible. Does this approach > scale to SMP, though? This is still a very much open question and from > what I have seen of the OpenBSD implementation, it only addresses the > uniprocessor case - again please correct me here if I have missed any > details. > If it does not scale to SMP then you should rethink your design. But adding a cache between the routing table and the actual lookup can be exploited similar to hash lists. Unless you make your cache a full table -- I would not call such a full view table a cache anymore. > I believe the Linux dst cache is strongly tied to the IBM-patented > Remote-Copy-Update algorithm based on what I've read about their LC-trie > implementation. > LC-trie implementations are normaly unable to do in place updates so you need to recalculate the full thing form time to time and then you just replace the pointer to the root in an atomic op. The main problem with LC-tries is that those are covered by some patents -- at least I remember something like this. > >Until now all caching solutions resulted in very bad performance on busy > >boxes. Remember ip_fastforward or how was it called? Another example are > >all crapy L3 switches that burn down if the CAM (chache) is flodded. > > > > I assume you are referring to NetBSD's flow-based IP forwarding cache, > which was implemented outside of the scope of SMP; spl-style interrupt > priority masking was still in use at that time. > FreeBSD had the same code before Andre replaced it with a real solution that does full route lookups. > It is established that saturating content-addressable memory is going to > lead to the slow path being taken, however, that's the trade-off one > makes with these designs. > Yes, the system is super fast if it is unloaded but under load (e.g. an attack) the systems enters a doom loop and kills itself. Honestly such systems are tuned for synthetic benchmarks and fail horribly in real life. > >IMO it is better to make the route lookup faster and forget about caching. > > > My concern is that you may be comparing apples with oranges here. > > In the case of SMP, locking does become a consideration, and caches, if > carefully implemented, are one way of addressing this. > > On the other hand, CPU affinity has been proposed as a limited solution, > however it depends how this is implemented - affinity for lookups, > forwarding, or both? > I just wonder if your little cache will not increase the lookup time in the real world. Take a busy core router with assume 250'000 sessions comming from something like 10'000 to 25'000 unique networks. This numbers are assumptions but if you remember SQLslammer you should realize that hitting a set of 25'000 prefixes is not exagerated. Now assume you added a cache to each CPU holding something like 100 to 1000 entries (you don't want to make it to big). So you will have quite a few cache misses and the cache would be under constant stress because it is way to small. So you will hit the routing table a lot and that's your slow path. Optimizing the slowest path will give you the most bang for the buck. Sure you could blow up your cache until everything fits but as I said for me that is no longer a cache but more an optimized FIB and therfore a routing table. > Perhaps there is something I am missing about how the OpenBSD > implementation deals with SMP, as I am not as familiar with their code > as FreeBSD's. > Honestly OpenBSD does not realy care about fine locked SMP at the moment (still running under big lock). Not that we like to stay there but we lack the manpower at the moment. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 23:22:42 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787A916A418 for ; Wed, 22 Aug 2007 23:22:42 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DDB8613C49D for ; Wed, 22 Aug 2007 23:22:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 52052 invoked from network); 22 Aug 2007 23:12:46 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Aug 2007 23:12:46 -0000 Message-ID: <46CCC548.4060108@freebsd.org> Date: Thu, 23 Aug 2007 01:22:48 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <46CC475F.8030505@FreeBSD.org> <46CC5698.7090200@FreeBSD.org> In-Reply-To: <46CC5698.7090200@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , Ivo Vachkov Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 23:22:42 -0000 Bruce M. Simpson wrote: > Ivo Vachkov wrote: >> Actually there is: >> >> struct route_in6 ip6_forward_rt; >> >> that "caches" the last route used (thanks blue !!!) but i think this >> technique is pointless in a multiflow traffic. >> > > Yes, this is why OpenBSD got rid of this form of 'route caching'. If you have a single flow a radix trie doesn't perform less good than a cache as all nodes are in the CPU cache anyway. >> Is it reasonable to believe that route caches can improve networking >> performance or we should leave it up to the routing table itself ? >> > > I believe that if one goes beyond a single radix trie, as is needed for > multi-pathing with multicast and source policy routing, route caching is > *required* to achieve good performance. No, most likely not. Caching only adds a lot of complexity. All useful caching is already done by the CPU caches. You almost can't do better than that. > Also, if FreeBSD moves ARP and NDP out of the radix trie, a route cache > would be highly preferable as it amortizes the lock acquisition which > would other be required for ARP/NDP/other layer 2 next-hop resolution. Route caching has some side evilness other than being ineffective. For every route change you either have to invalidate the entire cache or you have to do a cache lookup on all CPUs (if you have one per CPU as you seem to suggest) to prevent it from using stale data. If you don't use BGP DFZ sized routing tables caching is pointless anyway. If you do, you get some 1k updates per minute. Lots of cache invalidations. Multi-CPU cache invalidation has big locking implications which makes it inefficient again. There is not really much to win with route caching other than a huge amount of unnecessary complexity. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Aug 22 23:29:52 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C84716A41A for ; Wed, 22 Aug 2007 23:29:52 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A558313C428 for ; Wed, 22 Aug 2007 23:29:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 52130 invoked from network); 22 Aug 2007 23:19:56 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Aug 2007 23:19:56 -0000 Message-ID: <46CCC6F6.8090103@freebsd.org> Date: Thu, 23 Aug 2007 01:29:58 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <46CC475F.8030505@FreeBSD.org> <20070822151228.GB22194@diehard.n-r-g.com> <46CC6EAF.3010003@FreeBSD.org> In-Reply-To: <46CC6EAF.3010003@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Claudio Jeker Subject: Re: Route caching ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 22 Aug 2007 23:29:52 -0000 Bruce M. Simpson wrote: > Claudio Jeker wrote: >> Just because you believe that route caches are great doesn't mean it is >> true. Show some real code and include benchmarks with various workloads >> (e.g. a core router that is hit by many many many sessions). >> > > It is a reasonable approach, for a uniprocessor design, to focus on > optimizing the route lookup as much as possible. Does this approach > scale to SMP, though? This is still a very much open question and from > what I have seen of the OpenBSD implementation, it only addresses the > uniprocessor case - again please correct me here if I have missed any > details. There isn't much SMP routing going on. A particular interface can only be served by one CPU. Other than that the routing table lookup is rather quick and contention seems to be low. It can use RW locks. Many reads to very few writes/changes. > I believe the Linux dst cache is strongly tied to the IBM-patented > Remote-Copy-Update algorithm based on what I've read about their LC-trie > implementation. LC-trie is a compiled trie, not a dynamic one. As long as the prefix stays the same you can just update the nexthop but that's it. >> Until now all caching solutions resulted in very bad performance on busy >> boxes. Remember ip_fastforward or how was it called? Another example are >> all crapy L3 switches that burn down if the CAM (chache) is flodded. >> > > I assume you are referring to NetBSD's flow-based IP forwarding cache, > which was implemented outside of the scope of SMP; spl-style interrupt > priority masking was still in use at that time. The flow based fastforward was horrible. The FreeBSD fastforward since FreeBSD 5.3 is really a fast forward and does process to completion. It is indeed quite a bit faster than normal forwarding. > It is established that saturating content-addressable memory is going to > lead to the slow path being taken, however, that's the trade-off one > makes with these designs. > >> IMO it is better to make the route lookup faster and forget about >> caching. >> > My concern is that you may be comparing apples with oranges here. > > In the case of SMP, locking does become a consideration, and caches, if > carefully implemented, are one way of addressing this. > > On the other hand, CPU affinity has been proposed as a limited solution, > however it depends how this is implemented - affinity for lookups, > forwarding, or both? Incoming traffic has per-interface affinity. The routing lookup happens on the same CPU. No affinity there. Shared read access. > Perhaps there is something I am missing about how the OpenBSD > implementation deals with SMP, as I am not as familiar with their code > as FreeBSD's. The OpenBSD kernel still has a big giant lock around pretty much everything. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 06:30:19 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D590216A419 for ; Thu, 23 Aug 2007 06:30:19 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [IPv6:2001:200:1b1::35]) by mx1.freebsd.org (Postfix) with ESMTP id A65C613C442 for ; Thu, 23 Aug 2007 06:30:19 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 8085973018; Thu, 23 Aug 2007 15:30:18 +0900 (JST) Date: Thu, 23 Aug 2007 15:30:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jacek Zapala In-Reply-To: <1187705811.30269.5.camel@localhost.localdomain> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> <1187705811.30269.5.camel@localhost.localdomain> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, Daniel Hartmeier Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2007 06:30:19 -0000 At Tue, 21 Aug 2007 16:16:51 +0200, Jacek Zapala wrote: > Btw, how can I examine the route mtu cache? In older FreeBSD > netstat -ranW showed cloned routes and their mtus, but this is no longer > the case with FreeBSD 6.2. try sysctl net.inet.tcp.hostcache.list and see the "MTU" column. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 06:34:37 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D02A16A418 for ; Thu, 23 Aug 2007 06:34:37 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [IPv6:2001:200:1b1::35]) by mx1.freebsd.org (Postfix) with ESMTP id 20F4813C458 for ; Thu, 23 Aug 2007 06:34:37 +0000 (UTC) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from jmb.local (unknown [IPv6:2001:200:1b1:1010:217:f2ff:fe26:34a0]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BDA5473019; Thu, 23 Aug 2007 15:34:34 +0900 (JST) Date: Thu, 23 Aug 2007 15:34:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Daniel Hartmeier In-Reply-To: <20070821163505.GA28667@insomnia.benzedrine.cx> References: <200708211010.l7LAA6V7082258@freefall.freebsd.org> <20070821121118.GF27160@insomnia.benzedrine.cx> <1187703472.22531.4.camel@localhost.localdomain> <20070821135048.GA32421@insomnia.benzedrine.cx> <1187705811.30269.5.camel@localhost.localdomain> <20070821143125.GB32421@insomnia.benzedrine.cx> <1187707117.846.3.camel@localhost.localdomain> <20070821145047.GC32421@insomnia.benzedrine.cx> <1187713068.3973.6.camel@localhost.localdomain> <20070821163505.GA28667@insomnia.benzedrine.cx> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.0 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, Jacek Zapala Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2007 06:34:37 -0000 At Tue, 21 Aug 2007 18:35:05 +0200, Daniel Hartmeier wrote: > > But I'm not sure if I understood well - you suspect that only 8 bytes of > > tcp header are copied from the original tcp packet to the icmp message > > by the router? > > No, the router is only required (by the RFCs) to quote the first 8 bytes > of the TCP header. This is not true for IPv6. From Section 2.4 of RFC4443: (c) Every ICMPv6 error message (type < 128) MUST include as much of the IPv6 offending (invoking) packet (the packet that caused the error) as possible without making the error message packet exceed the minimum IPv6 MTU [IPv6]. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 07:17:34 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A257016A417 for ; Thu, 23 Aug 2007 07:17:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3D713C468 for ; Thu, 23 Aug 2007 07:17:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IO6mB-000HAC-NK; Thu, 23 Aug 2007 07:06:44 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IO6m9-0003NF-49; Wed, 22 Aug 2007 21:06:41 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18125.12795.336977.904060@roam.psg.com> Date: Wed, 22 Aug 2007 21:06:35 -1000 To: FreeBSD Net Cc: boris@tagnet.ru Subject: quagga 0.99.8 on current, tcpmd5 config confusion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2007 07:17:34 -0000 just did a cvsup build and portupgrade of a six month old -current i386 system running quagga. quagga cranked to 0.99.8. i got slammed by bgp tcpmd5 requirement. bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 17 bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 18 bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 22 madly googled and found that i needed to hack kernel for tcp md5 hash, even though i am not using md5 auth (these are not really infrastructure peerings. yes i know better for production). # quagga needs this for MD5 passwords on BGP sessions # options TCP_SIGNATURE options IPSEC #options FAST_IPSEC device crypto device cryptodev FAST_IPSEC turned out to be obsolete, so removed with this kernel, i got a lot of whining about no keys tcp_signature_compute: SADB lookup failed for 666.42.69.96 i restarted quagga, and bgpd left a disk flower bgpd[9808]: BGPd 0.99.8 starting: vty@2605, bgp@179 kernel: pid 9808 (bgpd), uid 101: exited on signal 6 which i was too panicked to debug so i went to backup and restored last week's binaries of quagga. things are running, and i am less panicked. enough adrenaline for one day, lemme tell ya. but tell me, what the heck is the correct recipe for a kernel and a quagga build for a bgpd that will play happily together? clue by four please! randy From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 13:34:17 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E627316A473 for ; Thu, 23 Aug 2007 13:34:17 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5378013C4A6 for ; Thu, 23 Aug 2007 13:34:17 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (unknown [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTP id 435A91BAC11 for ; Thu, 23 Aug 2007 15:34:16 +0200 (CEST) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.1/8.14.1) with ESMTP id l7NDYBJ4015288 for ; Thu, 23 Aug 2007 15:34:12 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1187876055; bh=eUdaX9xCv/8wlLAQbor+hHSeYTWBa2+nWwjjTHQ 3Kxo=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding:X-Scanned-By; b=uCQ0Q8FjdfYXjiOgJIRpnDjo oB0dAR9p/oFnjKfCwxWTCtZnxpw3nnTas4bieLRs+UczoPjc+4mz6Izg4hHAnA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=LDNHr+419GVGbeGQO2ArHoBIP7DTin75kcMkuSlUuoHephgnQ6nplV5BgPXYFGHnq Ta5alhyUZY/t0U7/jkiYg== Message-ID: <46CD8CD3.9090109@restart.be> Date: Thu, 23 Aug 2007 15:34:11 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.6 (X11/20070804) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.62 on IPv6:2001:41d0:1:2ad2::1:1 Subject: Wrong order in rc.d (pf and ipv6) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2007 13:34:18 -0000 Hello, I notice that after a reboot, my pf rules don't take the ipv6 address (managed with ipv6_ifconfig_rl0="2001:...:1") into account. rcorder /etc/rc.d/* show that pf is started before network_ipv6, is it normal? Thanks for your time Henri From owner-freebsd-net@FreeBSD.ORG Thu Aug 23 17:07:11 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6901D16A421 for ; Thu, 23 Aug 2007 17:07:11 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: from web43133.mail.sp1.yahoo.com (web43133.mail.sp1.yahoo.com [216.252.121.63]) by mx1.freebsd.org (Postfix) with SMTP id 4C68F13C4CB for ; Thu, 23 Aug 2007 17:07:11 +0000 (UTC) (envelope-from wgshizz@yahoo.com) Received: (qmail 10744 invoked by uid 60001); 23 Aug 2007 16:40:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6HUO84hO4jSGiELwcmqu84WOfSKMucacwCH0hLmEpUU5RI1OGykLOMH/JhF9RhGRjQtWzgP5bUUx9I5y6E356xP59lonwlSgDheLVmWDWHvbRSHXr2tE/AQK7ANIKr+n1to1i1paOdKSZ/3Hl/d1pjt6ogY4b3ZPRiZIWk27fZ4=; X-YMail-OSG: yL1dUucVM1njVrsvPf7ILR4hetPuPc.EF4SUEhliXMZwrDYJ_pdx6tb2uVLsT72Qow-- Received: from [69.147.84.254] by web43133.mail.sp1.yahoo.com via HTTP; Thu, 23 Aug 2007 09:40:30 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.134 Date: Thu, 23 Aug 2007 09:40:30 -0700 (PDT) From: Weiguang Shi To: glebius@freebsd.org, maxim@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <957582.10686.qm@web43133.mail.sp1.yahoo.com> Cc: freebsd-net@freebsd.org Subject: questions wrt ng_netflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Aug 2007 17:07:11 -0000 Hi there,=0A=0AI've been reading netlfow.c in FreeBSD-6.2 and this piece o= f code confuses me.=0A 484 /*=0A 485 * Go th= rough hash and find our entry. If we encounter an=0A 486 * = entry, that should be expired, purge it. We do a reverse=0A 487 = * search since most active entries are first, and most=0A 488 = * searches are done on most active entries.=0A 489 = */=0A 490 TAILQ_FOREACH_REVERSE_SAFE(fle, &hsh->head, fhead,= fle_hash, fle1) {=0A 491 if (bcmp(&r, &fle->f.r, si= zeof(struct flow_rec)) =3D=3D 0)=0A 492 brea= k;=0A 493 if ((INACTIVE(fle) && SMALL(fle)) || AGED(= fle)) {=0A 494 TAILQ_REMOVE(&hsh->head, fle,= fle_hash);=0A 495 expire_flow(priv, &item, = fle, NG_QUEUE);=0A 496 atomic_add_32(&priv->= info.nfinfo_act_exp, 1);=0A 497 }=0A 498 = }=0A=0A +-------------+ +--------+ +--------+ +------= --+ +--------+=0A | Bucket Head |----->| RecA |----->| RecB |--= --->| RecC |----->| RecD |=0A +-------------+ +--------+ += --------+ +--------+ +--------+=0A=0AIn the figure above, let's s= ay our packet matches RecC. So before the=0Amatch, RecD is examined to see = if it's AGED, i.e., it's lasted for too=0Along, or if it's too small and in= active. As the match is found, the=0Acode stops searching.=0A=0AFirst, isn'= t INACTIVE alone enough to expire a flow? Why must INACTIVE=0A_and_ SMALL?= =0A=0ARecA and RecB would not be examined for expiration but since they are= =0Ato the beginning of the queue and therefore actually less recently=0Aacc= essed, they are more likely to be INACTIVE and could be more AGED.=0AI must= be missing something, but what justifies examining RecD but not =0ARecA an= d RecB?=0A=0AThank you very much for your time.=0AWei=0A=0A=0A=0A=0A = =0A________________________________________________________________________= ____________=0ABe a better Heartthrob. Get better relationship answers from= someone who knows. Yahoo! Answers - Check it out. =0Ahttp://answers.yahoo.= com/dir/?link=3Dlist&sid=3D396545433 From owner-freebsd-net@FreeBSD.ORG Fri Aug 24 08:01:14 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A34BB16A418 for ; Fri, 24 Aug 2007 08:01:14 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by mx1.freebsd.org (Postfix) with ESMTP id E2E0213C45D for ; Fri, 24 Aug 2007 08:01:11 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 5DEDF84872; Fri, 24 Aug 2007 10:01:09 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Au7yyBHZ0zMt; Fri, 24 Aug 2007 10:01:03 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id B55DB8480A; Fri, 24 Aug 2007 10:01:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id B4352847C4; Fri, 24 Aug 2007 10:01:03 +0200 (CEST) Date: Fri, 24 Aug 2007 10:01:03 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: hlh@restart.be Message-ID: <20070824095600.B41622@mignon.ki.iif.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Wrong order in rc.d (pf and ipv6) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2007 08:01:14 -0000 Hi Henri, I am not on the list of freebsd-net therefore I send you off list the answers. FreeBSD-pf team rather reluctant to change the order. I sent a PR about this a while ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/113650 Solution is use "(if_name)" in pf rules. pf will use after interface gets ipv6 address. I hope this helps, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From owner-freebsd-net@FreeBSD.ORG Fri Aug 24 08:35:33 2007 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18E4616A419; Fri, 24 Aug 2007 08:35:33 +0000 (UTC) (envelope-from dhartmei@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E3BAF13C457; Fri, 24 Aug 2007 08:35:32 +0000 (UTC) (envelope-from dhartmei@FreeBSD.org) Received: from freefall.freebsd.org (dhartmei@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7O8ZW5I062305; Fri, 24 Aug 2007 08:35:32 GMT (envelope-from dhartmei@freefall.freebsd.org) Received: (from dhartmei@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7O8ZT4t062301; Fri, 24 Aug 2007 08:35:29 GMT (envelope-from dhartmei) Date: Fri, 24 Aug 2007 08:35:29 GMT Message-Id: <200708240835.l7O8ZT4t062301@freefall.freebsd.org> To: jacek@ipv6.jacek.it.pl, dhartmei@FreeBSD.org, freebsd-net@FreeBSD.org From: dhartmei@FreeBSD.org Cc: Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2007 08:35:33 -0000 Synopsis: [ipv6] ipv6 pmtu not working State-Changed-From-To: open->closed State-Changed-By: dhartmei State-Changed-When: Fri Aug 24 08:32:46 UTC 2007 State-Changed-Why: problem was with pf (more details in http://marc.info/?t=118681762200001) now fixed (pf.c 1.46, 1.34.2.6) http://www.freebsd.org/cgi/query-pr.cgi?pr=115413 From owner-freebsd-net@FreeBSD.ORG Fri Aug 24 14:50:28 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D31516A469 for ; Fri, 24 Aug 2007 14:50:28 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id C5AED13C49D for ; Fri, 24 Aug 2007 14:50:27 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (unknown [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTP id AB5EE1BAC11 for ; Fri, 24 Aug 2007 16:50:26 +0200 (CEST) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.1/8.14.1) with ESMTP id l7OEoNMn023904 for ; Fri, 24 Aug 2007 16:50:23 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1187967026; bh=m3BMB+r8P73ZZ35pOgINBgtOUGQRPGBPfGy6yfB 1a+Y=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; b=kq+PiktFT6u PAjIdVKUWonoqP/Ole16zwQOrNPXDzRilaSv92Wxgryj+a5l7BfywhL1ZmWoSR2C2WL aZd1oDqQ== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=0VAHCiwtgkd6E7VFvHMunrTm8pqa0oGM7ntdqxIfSDXFLbEfxTyALcHBXsYos+TxK /KnbH58+6szxLcMUOceqA== Message-ID: <46CEF02F.9070900@restart.be> Date: Fri, 24 Aug 2007 16:50:23 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.6 (X11/20070804) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20070824095600.B41622@mignon.ki.iif.hu> In-Reply-To: <20070824095600.B41622@mignon.ki.iif.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.62 on IPv6:2001:41d0:1:2ad2::1:1 Subject: Re: Wrong order in rc.d (pf and ipv6) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2007 14:50:28 -0000 Mohacsi Janos wrote: > Hi Henri, > I am not on the list of freebsd-net therefore I send you off list > the answers. FreeBSD-pf team rather reluctant to change the order. I > sent a PR about this a while ago: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/113650 > > Solution is use "(if_name)" in pf rules. pf will use after interface Of course, I forget this solution ... I update my pf.conf accordingly. Thanks very much Henri > gets ipv6 address. > > I hope this helps, > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From owner-freebsd-net@FreeBSD.ORG Fri Aug 24 21:26:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C51E16A41A for ; Fri, 24 Aug 2007 21:26:18 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2492313C45E for ; Fri, 24 Aug 2007 21:26:18 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 8AE362316C; Fri, 24 Aug 2007 17:26:17 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 24 Aug 2007 17:26:17 -0400 X-Sasl-enc: G8QBlGCu8FAmGKlJnFpViMvfYm+w7MfnWGo/Uogt6QEg 1187990777 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id E22862E1; Fri, 24 Aug 2007 17:26:16 -0400 (EDT) Message-ID: <46CF4CF7.4030606@FreeBSD.org> Date: Fri, 24 Aug 2007 22:26:15 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Randy Bush References: <18125.12795.336977.904060@roam.psg.com> In-Reply-To: <18125.12795.336977.904060@roam.psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , boris@tagnet.ru Subject: Re: quagga 0.99.8 on current, tcpmd5 config confusion X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Aug 2007 21:26:18 -0000 Randy Bush wrote: > just did a cvsup build and portupgrade of a six month old -current > i386 system running quagga. quagga cranked to 0.99.8. i got > slammed by bgp tcpmd5 requirement. > > bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 17 > bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 18 > bgpd[469]: can't set sockopt TCP_MD5SIG 0 to socket 22 > > madly googled and found that i needed to hack kernel for tcp md5 > hash, even though i am not using md5 auth (these are not really > infrastructure peerings. yes i know better for production). > This I haven't seen before, then again, it's been years since I've used Zebra/Quagga let alone hacked the patch for md5 support, which is now ~3.5 years old. It was only ever intended as a belt-and-braces attempt at getting things up in a way which the sponsor was satisfied with, with no other refinements. I wasn't 100% happy about how I ended up doing the kernel support, and had to go with what I had working in my tree because of that old demon 'economics', rather than doing things 'the right way': i.e. in the IPSEC Security Policy Database (SPD), with the routing daemon loading the keys, rather than the Security Associations Database (SADB) and keys loaded manually using setkey(8). Other individuals have since made changes to this code. Now that we have settled on FAST_IPSEC thanks to gnn's hard work, it will be easier for Someone(tm) to pick this up, as KAME IPSEC and FAST_IPSEC interfaced to key sockets differently enough to change the implementation of the SPD. > with this kernel, i got a lot of whining about no keys > > tcp_signature_compute: SADB lookup failed for 666.42.69.96 > I remember putting in the SADB lookup failed message to help people track down problems with their configuration. If TCP_MD5SIG is not enabled on the tcp socket, no SADB lookup should happen, so you shouldn't be seeing this message. It sounds to me as though Quagga may be enabling the TCP_MD5SIG option unconditionally based on all of the output you've posted. This is obviously incorrect. I can't speak for Quagga, though it seems reasonable to suggest that it shouldn't be doing that unless you tell it to. I believe the MD5 patches only get pulled in if you request them, and that md5 auth specifically needs to be enabled per peer. Still, this is nearly 4 years on and I have other things going on now. regards, BMS From owner-freebsd-net@FreeBSD.ORG Sat Aug 25 10:52:44 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC66A16A420 for ; Sat, 25 Aug 2007 10:52:44 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from dir.bg (mail.dir.bg [194.145.63.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0731413C467 for ; Sat, 25 Aug 2007 10:52:43 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from [87.126.155.81] (account jgordeev HELO [10.102.9.50]) by dir.bg (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 30304747; Sat, 25 Aug 2007 12:52:41 +0300 Message-ID: <46CFFC16.4010009@dir.bg> Date: Sat, 25 Aug 2007 12:53:26 +0300 From: Jordan Gordeev User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20070606 X-Accept-Language: bg, en MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.devel.net To: Norberto Meijome References: <395010.70646.qm@web43142.mail.sp1.yahoo.com> <20070821161536.634aa7bf@localhost> In-Reply-To: <20070821161536.634aa7bf@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: [OT] nlanr.org ?? ( was Re: Canonical Packet Traces? ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Aug 2007 10:52:44 -0000 Norberto Meijome wrote: > On Mon, 20 Aug 2007 09:11:32 -0700 (PDT) > Weiguang Shi wrote: > > >>moat.nlanr.org has a huge collection of traces, with dst and src IP addresses anonymized. >> > > > ?! it seems someone hijacked nlanr.org's domain : See www.nlanr.net and moat.nlanr.net. > > > blimey. > _________________________ > {Beto|Norberto|Numard} Meijome >