From owner-freebsd-net Mon Sep 16 2:31:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69FAC37B400 for ; Mon, 16 Sep 2002 02:31:18 -0700 (PDT) Received: from pop3.psconsult.nl (ps226.psconsult.nl [193.67.147.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74B4E43E7B for ; Mon, 16 Sep 2002 02:31:16 -0700 (PDT) (envelope-from paul@pop3.psconsult.nl) Received: (from paul@localhost) by pop3.psconsult.nl (8.9.2/8.9.2) id LAA36321 for freebsd-net@freebsd.org; Mon, 16 Sep 2002 11:31:14 +0200 (CEST) (envelope-from paul) Date: Mon, 16 Sep 2002 11:31:14 +0200 From: Paul Schenkeveld To: FreeBSD Net Subject: Token Ring - Ethernet bridge Message-ID: <20020916113114.A36237@psconsult.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All, During migration from token ring to ethernet one of my customers needs to internetwork the two. They are running both IP and IPX protocols and so the easiest way would be to bridge the two. FreeBSD still has the oltr token-ring driver (no manpage however) and FreeBSD has bridge(4) and ng_bridge(4) so I'd like to give it a try if there's any chance of success. However, both bridge(4) and ng_bridge(4) manual pages only talk about ethernet bridging. Hence the simple question: Is there any chance I can use FreeBSD as a bridge between token-ring and ethernet or will I be wasting my time trying to get the thing to work. PS. Before I can try there are some logistics involved in getting all hardware and myself to the customer site so any advise (even negative) is very much appreciated. Regards, Paul Schenkeveld To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 8:42:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1A3237B400 for ; Mon, 16 Sep 2002 08:42:44 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id A3E7943E4A for ; Mon, 16 Sep 2002 08:42:43 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 11454 invoked by uid 1031); 16 Sep 2002 15:39:51 -0000 Date: Mon, 16 Sep 2002 16:39:50 +0100 From: Bruce M Simpson To: Paul Schenkeveld Cc: FreeBSD Net Subject: Re: Token Ring - Ethernet bridge Message-ID: <20020916153950.GL28076@spc.org> Mail-Followup-To: Bruce M Simpson , Paul Schenkeveld , FreeBSD Net References: <20020916113114.A36237@psconsult.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020916113114.A36237@psconsult.nl> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Sep 16, 2002 at 11:31:14AM +0200, Paul Schenkeveld wrote: > Is there any chance I can use FreeBSD as a bridge between > token-ring and ethernet or will I be wasting my time trying > to get the thing to work. The short answer is no, as oltr doesn't use the ether subsystem, and ng_bridge uses hooks inside net/if_ethrsubr.c to do its thing. Also, all the bridge support is in there, anyway. BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 9: 9:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9109B37B400 for ; Mon, 16 Sep 2002 09:09:22 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C63143E42 for ; Mon, 16 Sep 2002 09:09:21 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.5/8.11.4) with ESMTP id g8GFkF0x052863; Mon, 16 Sep 2002 18:46:15 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3D85FCC6.D53030DD@he.iki.fi> Date: Mon, 16 Sep 2002 18:46:14 +0300 From: Petri Helenius X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.6-STABLE i386) X-Accept-Language: en,fi MIME-Version: 1.0 To: Bruce M Simpson Cc: Paul Schenkeveld , FreeBSD Net Subject: Re: Token Ring - Ethernet bridge References: <20020916113114.A36237@psconsult.nl> <20020916153950.GL28076@spc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce M Simpson wrote: > > On Mon, Sep 16, 2002 at 11:31:14AM +0200, Paul Schenkeveld wrote: > > Is there any chance I can use FreeBSD as a bridge between > > token-ring and ethernet or will I be wasting my time trying > > to get the thing to work. > > The short answer is no, as oltr doesn't use the ether subsystem, and > ng_bridge uses hooks inside net/if_ethrsubr.c to do its thing. Also, > all the bridge support is in there, anyway. > Not *BSD related but since none of the OS's do this, best solution for a transition is probably to buy a secondhand Cisco or other gear like that for bridging purposes. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 9:44:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA6637B400 for ; Mon, 16 Sep 2002 09:44:53 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 4148943E9C for ; Mon, 16 Sep 2002 09:44:52 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 1916 invoked by uid 1031); 16 Sep 2002 16:42:06 -0000 Date: Mon, 16 Sep 2002 17:42:06 +0100 From: Bruce M Simpson To: freebsd-net@freebsd.org Subject: Proposal: adopt SIOCGLIFNUM interface for enumerating iflist. Message-ID: <20020916164206.GN28076@spc.org> Mail-Followup-To: Bruce M Simpson , freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org All, I propose we adopt the SIOCGLIFNUM interface from Solaris 8 for enumerating the list of configured interfaces on a system. Many userland applications now traverse the interface list to gather interface information, in particular those which make use of multicast IP, or for example, those which search for configured wireless interfaces on a system. At this time these applications have to play 'elastic buffer' games with the SIOCGIFCONF ioctl in order to get all of the relevant information. By allowing userland applications to determine the size of this buffer at runtime, we eliminate the need for repeated calls to ifioctl(). I'd like to know everyone's thoughts on the matter... BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 9:54:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BC5F37B400 for ; Mon, 16 Sep 2002 09:54:21 -0700 (PDT) Received: from vreme.yubc.net (vreme.yubc.net [212.124.160.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54FBC43E4A for ; Mon, 16 Sep 2002 09:54:03 -0700 (PDT) (envelope-from ssgrr2003w@rti7020.etf.bg.ac.yu) Received: (from root@localhost) by vreme.yubc.net (8.11.6/8.11.6) id g8GGwZ019613 for freebsd-net@freebsd.org; Mon, 16 Sep 2002 18:58:35 +0200 Date: Mon, 16 Sep 2002 18:58:35 +0200 From: ssgrr2003w@rti7020.etf.bg.ac.yu Message-Id: <200209161658.g8GGwZ019613@vreme.yubc.net> Subject: Invitation to SSGRR conferences in ITALY! To: freebsd-net@freebsd.org Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org CALL FOR PAPERS AND PARTICIPATION AT SSGRR CONFERENCES IN YEAR 2003 The SSGRR (Scuola Superiore G Reiss Romoli) Congress Center, Telecom Italia Learning Services, L'Aquila (near Rome), ITALY (www.ssgrr.it). Respected Dr. We are honored to invite you to submit and present your paper(s) at the two SSGRR conferences specified below: INTERNATIONAL CONFERENCES ON ADVANCES IN INFRASTRUCTURE FOR ELECTRONIC BUSINESS, EDUCATION, SCIENCE, MEDICINE, AND MOBILE TECHNOLOGIES ON THE INTERNET WINTER Conference 2003: >From Monday January 6 at 5pm till Sunday January 12 at 10am To submit paper or ask questions: ssgrr2003w@rti7020.etf.bg.ac.yu Keynotes: Lyman (Berkeley), Neuhold (Fraunhofer), Neal (Tufts Medical School), ... SUMMER Conference 2003: >From Monday July 28 at 5pm till Sunday August 3 at 10am To submit paper or ask questions: ssgrr2003s@rti7020.etf.bg.ac.yu Keynotes: Kroto (Nobel Laureate), Patt (IEEE Eckert-Mauchly Laureate), Carlton (US Air Force Surgeon General), ... For details, see IEEE COMPUTER, Aug 2002 (page 33) and the WWW site www.ssgrr.it (written carefully+precisely, with answers to all FAQ). Check with past participants (their names/emails are on the WWW). Most of them believe this is the most interesting, rewarding, and definitely the most hospitable conference they ever attended! Fast professional and peer review in 15 days. Capacity of the SSGRR congress center is 200 participants. The list of participants will be closed after 200 papers accepted. Consequently, SUBMIT YOUR PAPER(S) AS EARLY AS POSSIBLE! ______________________________________________________________________ Location (see WWW for details): SSGRR is the DE-LUX congress and education center of the Telecom Italia Learning Services, located about 60 miles from Rome, near Gran Sasso (the highest Appenini peak), with fast access to the major Appenini ski resorts (in winters, 15 minutes by car), and Adriatic sea beaches (in summers, 45 minutes by car). Keynotes (see WWW for details): A Nobel Laureate was the keynote speaker each year in the past (Jerome Friedman of MIT, Robert Richardson of Cornell, etc...), and the major 2003 keynote is also reserved for a Nobel Laureate (Harry Kroto from United Kingdom). Other 2003 keynote speakers are Yale Patt from UofTexas@Austin (an IEEE Eckert-Mauchly Laureate), Paul Carlton (US Air Force Surgeon General), etc. Schedule (see WWW for details): Monday = Arrival day, registration, and cocktail Tuesday = Gran Sasso Nat'l Lab tour, tutorials, and opening ceremony Wednesday/Thursday/Friday = Presentation of research papers Saturday = Tutorials and peripathetic discussions Sunday = Departure day Deadlines (see WWW for details): For title and abstract (about 100 words): October 15, 2002 (for Winter 2003) April 30, 2003 (for Summer 2003) For papers (IEEE Transactions format, min 4 pages, max 1MB): November 15, 2002 (for Winter 2003) May 30, 2003 (for Summer 2003) For payment (stay, and fee if applicable): December 10, 2002 (for Winter 2003) June 30, 2003 (for Summer 2003) Payment (see WWW for details): No conference fee for those with papers to present (others: euro600). No fee for tutorials. All participants must stay inside SSGRR (no outside stays allowed). Full 6-day stay (from Monday evening till Sunday breakfast): euro1200. A 5-day stay (without one tutorial day): euro1000. Minimal 4-day stay (for research papers only): euro 800. Favourable conditions for accompanying persons (see the WWW). For late payment rules see the WWW. Important (see WWW for details): When submitting your paper, insert the 3-letter field code (exact codes on WWW), so the placement of papers per sessions is more efficient. Insert your WWW site URL (if you have one). If you submit a paper, you will get 2 other papers for a fast review (in up to 10 days). Your presentation time is 25 minutes, plus 5 minutes for discussions. Chairman of the session is the presenter of the last paper in that session. Moving of presentation slots is not permitted (in cases of non-show-up). If you like to be reinvited for a future SSGRR conference, let us know. If you like to be removed from the list, please let us know, too. WE HOPE TO SEE YOU AT SSGRR! Professor Veljko Milutinovic, General Chairman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 10: 0:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93D5237B401 for ; Mon, 16 Sep 2002 10:00:20 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id E416443E6E for ; Mon, 16 Sep 2002 10:00:19 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020916170019.LVJS26988.sccrmhc01.attbi.com@InterJet.elischer.org>; Mon, 16 Sep 2002 17:00:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA95559; Mon, 16 Sep 2002 09:51:05 -0700 (PDT) Date: Mon, 16 Sep 2002 09:51:05 -0700 (PDT) From: Julian Elischer To: Bruce M Simpson Cc: Paul Schenkeveld , FreeBSD Net Subject: Re: Token Ring - Ethernet bridge In-Reply-To: <20020916153950.GL28076@spc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org but the oltr could be MADE to use it if you ar a bit of a hacker.. (or at least to get the equivalent code) On Mon, 16 Sep 2002, Bruce M Simpson wrote: > On Mon, Sep 16, 2002 at 11:31:14AM +0200, Paul Schenkeveld wrote: > > Is there any chance I can use FreeBSD as a bridge between > > token-ring and ethernet or will I be wasting my time trying > > to get the thing to work. > > The short answer is no, as oltr doesn't use the ether subsystem, and > ng_bridge uses hooks inside net/if_ethrsubr.c to do its thing. Also, > all the bridge support is in there, anyway. > > BMS > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 10:12:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA17D37B401 for ; Mon, 16 Sep 2002 10:12:34 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0176943E42 for ; Mon, 16 Sep 2002 10:12:34 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g8GHCWVo023805 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 16 Sep 2002 13:12:33 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g8GHCWak023802; Mon, 16 Sep 2002 13:12:32 -0400 (EDT) (envelope-from wollman) Date: Mon, 16 Sep 2002 13:12:32 -0400 (EDT) From: Garrett Wollman Message-Id: <200209161712.g8GHCWak023802@khavrinen.lcs.mit.edu> To: Bruce M Simpson Cc: freebsd-net@FreeBSD.ORG Subject: Proposal: adopt SIOCGLIFNUM interface for enumerating iflist. In-Reply-To: <20020916164206.GN28076@spc.org> References: <20020916164206.GN28076@spc.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > At this time these applications have to play 'elastic buffer' games with the > SIOCGIFCONF ioctl in order to get all of the relevant information. By allowing > userland applications to determine the size of this buffer at runtime, we > eliminate the need for repeated calls to ifioctl(). We have already done so: sysctl net.route.iflist. It might be worth our while to also support the Solaris method, but IMHO there is far too much confusion over this function to be adding another way to do it. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 10:35:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98FFF37B400 for ; Mon, 16 Sep 2002 10:35:54 -0700 (PDT) Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A69643E42 for ; Mon, 16 Sep 2002 10:35:48 -0700 (PDT) (envelope-from brunner@nic-naa.net) Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g8GHa2KY003921; Mon, 16 Sep 2002 13:36:02 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200209161736.g8GHa2KY003921@nic-naa.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: Bruce M Simpson , Paul Schenkeveld , FreeBSD Net , brunner@nic-naa.net Subject: Re: Token Ring - Ethernet bridge In-Reply-To: Message from Julian Elischer of "Mon, 16 Sep 2002 09:51:05 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Sep 2002 13:36:02 -0400 From: Eric Brunner-Williams in Portland Maine Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org uhh... wakeup(&me->ibm_4.3bsd) What are people using for token-ring now a days? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 11:22:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33F9337B400 for ; Mon, 16 Sep 2002 11:22:49 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B50643E6E for ; Mon, 16 Sep 2002 11:22:48 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 123044CED7 for ; Mon, 16 Sep 2002 14:22:43 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA28367 for ; Mon, 16 Sep 2002 14:22:42 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA21679; Mon, 16 Sep 2002 11:22:42 -0700 (PDT) Message-Id: <200209161822.LAA21679@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: freebsd-net@FreeBSD.ORG Subject: Re: Proposal: adopt SIOCGLIFNUM interface for enumerating iflist. References: <20020916164206.GN28076@spc.org> <200209161712.g8GHCWak023802@khavrinen.lcs.mit.edu> Date: Mon, 16 Sep 2002 11:22:41 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I would be amenable to SIOCGIFNUM (note: not the L version), as a simple extension to the "legacy" SIOCGIFCONF interface, and adding further functionality such as the filtering that Solaris implements with the SIOCGLIF* ioctls using sysctl. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 11:40:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70CCB37B400 for ; Mon, 16 Sep 2002 11:40:24 -0700 (PDT) Received: from quadric.isometry.net (pc3-oxfd1-3-cust229.oxf.cable.ntl.com [213.107.68.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD57643E4A for ; Mon, 16 Sep 2002 11:40:23 -0700 (PDT) (envelope-from freebsd@lineone.net) Received: from ishadow (ishadow [192.168.108.2]) by quadric.isometry.net (Postfix) with ESMTP id 0888E425 for ; Mon, 16 Sep 2002 18:40:20 +0000 (UTC) From: "Robin Breathe" To: Subject: Problems with ipfilter 3.4.29 under -STABLE (post 31/08/2002) Date: Mon, 16 Sep 2002 19:40:21 +0100 Message-ID: <000101c25db0$83062340$026ca8c0@ishadow> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I'm interested to know if anyone is successfully running ipf/ipnat under -STABLE from after the merge on the 31st of August (http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/ipfilter/). I have found that my existing rulesets fail with the new code. ipf blocks everything, and ipnat doesn't do NAT. My rules are at http://isometry.net/freebsd/ipfilter/, and they've worked flawlessly with previous versions of ipfilter, in particular 3.4.27 from 4.6.2-RELEASE to which I have reverted. I am making, and installing the base system and kernel using the makefile from http://www.freebsddiary.org/samples/makefile.for.build.world which has also always worked flawlessly for me. I am trying to work out whether the problem lies with the recent merge of ipfilter 3.4.29, or with my config. And from all the testing I've been able to do, the problem seems to lie with ipfilter. Other people's experiences with the new code would be greatly appreciated. -- Robin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 14: 2:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8BE437B400; Mon, 16 Sep 2002 14:02:40 -0700 (PDT) Received: from quadric.isometry.net (pc3-oxfd1-3-cust229.oxf.cable.ntl.com [213.107.68.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1032143E3B; Mon, 16 Sep 2002 14:02:40 -0700 (PDT) (envelope-from robin@isometry.net) Received: from ishadow (ishadow [192.168.108.2]) by quadric.isometry.net (Postfix) with ESMTP id BDEF0234; Mon, 16 Sep 2002 21:02:36 +0000 (UTC) From: "Robin Breathe" To: , , Cc: "'Darren Reed'" Subject: RE: Problems with ipfilter 3.4.29 under -STABLE (post 31/08/2002) Date: Mon, 16 Sep 2002 22:02:37 +0100 Message-ID: <000e01c25dc4$63174dc0$026ca8c0@ishadow> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000101c25db0$83062340$026ca8c0@ishadow> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apologies for posting this message. It seems that it was broken for me from 31/08/2002 until around 12/09/2002 (the last time I tried) after which I lost hope, seeing no changes on cvsweb. However having recompiled against today's -STABLE (~7pm GMT) things are running dandy (all other methodology being the same). Thanks to everyone that responded to my query, and to Darren Reed for his development of ipfilter :) -- Robin > Hi all, > > I'm interested to know if anyone is successfully running > ipf/ipnat under > -STABLE from after the merge on the 31st of August > (http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/ipfilter/). > > I have found that my existing rulesets fail with the new code. ipf > blocks everything, and ipnat doesn't do NAT. My rules are at > http://isometry.net/freebsd/ipfilter/, and they've worked flawlessly > with previous versions of ipfilter, in particular 3.4.27 from > 4.6.2-RELEASE to which I have reverted. > > I am making, and installing the base system and kernel using the > makefile from > http://www.freebsddiary.org/samples/makefile.for.build.world which has > also always worked flawlessly for me. > > I am trying to work out whether the problem lies with the recent merge > of ipfilter 3.4.29, or with my config. And from all the testing I've > been able to do, the problem seems to lie with ipfilter. > Other people's > experiences with the new code would be greatly appreciated. > > -- Robin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 15:15: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F040437B400 for ; Mon, 16 Sep 2002 15:15:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72FB143E65 for ; Mon, 16 Sep 2002 15:15:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id PAA10399; Mon, 16 Sep 2002 15:00:45 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g8GLxfe88208; Mon, 16 Sep 2002 14:59:41 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200209162159.g8GLxfe88208@arch20m.dellroad.org> Subject: Re: Proposal: adopt SIOCGLIFNUM interface for enumerating iflist. In-Reply-To: <200209161712.g8GHCWak023802@khavrinen.lcs.mit.edu> "from Garrett Wollman at Sep 16, 2002 01:12:32 pm" To: Garrett Wollman Date: Mon, 16 Sep 2002 14:59:41 -0700 (PDT) Cc: Bruce M Simpson , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Garrett Wollman writes: > > At this time these applications have to play 'elastic buffer' games with the > > SIOCGIFCONF ioctl in order to get all of the relevant information. By allowing > > userland applications to determine the size of this buffer at runtime, we > > eliminate the need for repeated calls to ifioctl(). > > We have already done so: sysctl net.route.iflist. FYI, libpdel (ports:devel/libpdel) has code that shows how to do this and makes it easier. Install the port and type 'man if_get_list' for details. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 21:53:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70A2737B400 for ; Mon, 16 Sep 2002 21:53:11 -0700 (PDT) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 934BA43E72 for ; Mon, 16 Sep 2002 21:53:10 -0700 (PDT) (envelope-from freebsd-lists@lister.dnsalias.net) Received: from ilister.dialup.dstc.edu.au (ilister.dialup.dstc.edu.au [130.102.182.103]) by piglet.dstc.edu.au (8.12.3/8.12.3) with ESMTP id g8H4r4pl016685; Tue, 17 Sep 2002 14:53:05 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id g8H4r2D82742; Tue, 17 Sep 2002 14:53:02 +1000 (EST) (envelope-from freebsd-lists@lister.dnsalias.net) Date: Tue, 17 Sep 2002 14:53:02 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Bruce M Simpson Cc: freebsd-net@FreeBSD.ORG Subject: Re: Proposal: adopt SIOCGLIFNUM interface for enumerating iflist. In-Reply-To: <20020916164206.GN28076@spc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: SPAMASSASSIN: This message probably not SPAM X-Spam-Score: -4.4, Required: 5 X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 16 Sep 2002, Bruce M Simpson wrote: >At this time these applications have to play 'elastic buffer' games with the >SIOCGIFCONF ioctl in order to get all of the relevant information. By allowing >userland applications to determine the size of this buffer at runtime, we >eliminate the need for repeated calls to ifioctl(). NetBSD returns the required buffer size in ifc.ifc_len so you only need to call ioctl at most twice (once to determine the buffer size and once with a buffer large enough). Just another option (with precedent)... Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 16 23:32:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88A3F37B400 for ; Mon, 16 Sep 2002 23:32:47 -0700 (PDT) Received: from firmlai.bal.ru (firmlai.bal.ru [195.42.138.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4079743E42 for ; Mon, 16 Sep 2002 23:32:41 -0700 (PDT) (envelope-from oleg@firmlai.bal.ru) Received: from oleg.bal.ru (oleg.bal.ru [195.42.138.3]) by firmlai.bal.ru (8.10.0.Beta6/oleg@bal.ru) with ESMTP id g8H6WFc76795 for ; Tue, 17 Sep 2002 10:32:32 +0400 (MSD) Date: Tue, 17 Sep 2002 10:32:22 +0400 From: Oleg Borowkov X-Mailer: The Bat! (v1.61) Personal Reply-To: Oleg Borowkov Organization: LAI Firm X-Priority: 3 (Normal) Message-ID: <184676800.20020917103222@firmlai.bal.ru> Disposition-Notification-To: oleg@firmlai.bal.ru To: freebsd-net@FreeBSD.ORG Subject: ed0: NIC memory corrupt - invalid packet length 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi freebsd-net! FreeBSD 4.4-RC and FreeBSD 4.5-STABLE ed0 RTL8029 after tcpdump -i ed0 command kernel log messages: > ed0: promiscuous mode enabled > ed0: NIC memory corrupt - invalid packet length 10 > ed0: NIC memory corrupt - invalid packet length 9 > ed0: NIC memory corrupt - invalid packet length 9 > ed0: NIC memory corrupt - invalid packet length 8 > ed0: NIC memory corrupt - invalid packet length 9 > ed0: promiscuous mode disabled > ed0: promiscuous mode enabled ... What's this? and how i can fix it's? -- Oleg oleg@firmlai.bal.ru icq:34687903 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 17 15:33: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F32437B401 for ; Tue, 17 Sep 2002 15:33:01 -0700 (PDT) Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id A867343E77 for ; Tue, 17 Sep 2002 15:33:00 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g8HMWlG49098 for ; Tue, 17 Sep 2002 15:32:47 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.1/8.12.1/meer) with ESMTP id g8HMWxde015311 for ; Tue, 17 Sep 2002 15:33:00 -0700 (PDT) Message-Id: <200209172233.g8HMWxde015311@mail.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-net@freebsd.org Subject: Possible mbuf leak in if_fxp.c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Sep 2002 15:32:59 -0700 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Folks, I note that in -STABLE, in the file dev/if_fxp.c, the routine fxp_start() calls bpf_mtap() a few lines before the end of the function. There is no associated "free" with this call. It looks like fxp_intr_body() is supposed to free transmitted packets, but I'm not sure this is happening. Can someone verify my (il)logic? Thanks, George -- George V. Neville-Neil gnn@neville-neil.com Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 17 17:55:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D8FF37B401 for ; Tue, 17 Sep 2002 17:55:49 -0700 (PDT) Received: from mail016.syd.optusnet.com.au (mail016.syd.optusnet.com.au [210.49.20.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D44943E8A for ; Tue, 17 Sep 2002 17:55:48 -0700 (PDT) (envelope-from david.burns@dugeem.net) Received: from dugeem.net (c19426.carlnfd1.nsw.optusnet.com.au [211.28.175.9]) by mail016.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g8I0tia17749; Wed, 18 Sep 2002 10:55:45 +1000 Message-ID: <3D87CEFF.1010409@dugeem.net> Date: Wed, 18 Sep 2002 10:55:27 +1000 From: David Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Fettig Cc: net@FreeBSD.ORG Subject: Re: Network Transfer Speed Issues - Tweaks/Advice? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Steve Fettig wrote: > > I recently set up an NFS server to run daily backups on. The server was > built using an old P150 w/ 90 MB of ram and a 6GB hard drive. (All > servers in this experiment are set up using FBSD 4.6.2 and the client is > a Mac PowerBook G4 running Mac OS X.) Attached to it is an external > SCSI hard drive enclosure with 4 47GB SCSI drives running off an > AHA-2490UW SCSI adapter. I am getting really odd performance when doing > an NFS transfer (I also get odd performance out of scp) from the machine > I am trying to back up. I will get a burst of 20Mbps for about 30 > seconds, then it will ramp down to 1 Mbps for about 2 minutes, ramp > backup to 20 Mbps, then back down to 1 Mbps and so on. > You need to break the problem down ... Is the system CPU and/or IO bound during the backup? Also try some quick benchmarks to verify basic system performance levels: Network IO - use ttcp (or netperf etc), and Disk IO - use bonnie (or similar). NB Of course you can't simply take such benchmarks results and put them together - but you will gain a better understanding of where the potential slowdowns may be. Lastly, performance issues on older Pentiums can also result from poor memory bandwidth and/or PCI chipset problems. I recently replaced a P120 with a Celeron 333 - the performance improvement was surprising. Regards, David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 17 18:16:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A6DB37B401 for ; Tue, 17 Sep 2002 18:16:29 -0700 (PDT) Received: from outboundx.mv.meer.net (outboundx.mv.meer.net [209.157.152.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B67E643E86 for ; Tue, 17 Sep 2002 18:16:28 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outboundx.mv.meer.net (8.11.6/8.11.6) with ESMTP id g8I1GFG58551 for ; Tue, 17 Sep 2002 18:16:15 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from neville-neil.com ([209.157.133.226]) by mail.meer.net (8.12.1/8.12.1/meer) with ESMTP id g8I1GRde041576 for ; Tue, 17 Sep 2002 18:16:27 -0700 (PDT) Message-Id: <200209180116.g8I1GRde041576@mail.meer.net> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-net@freebsd.org Subject: Not losing mbufs from if_fxp.c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Sep 2002 18:16:27 -0700 From: "George V. Neville-Neil" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Folks, Luigi got ahold of me and straightened me out on the fxp driver. There is a problem though. If you generate a LOT of ARP traffic on a FreeBSD box (-STABLE) you can run out of mbufs. I'm looking into this presently and will tell you if I find anything useful to be done about this. Later, George -- George V. Neville-Neil gnn@neville-neil.com Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 17 23: 9:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE38B37B401 for ; Tue, 17 Sep 2002 23:09:48 -0700 (PDT) Received: from mta.inode.at (mta.inode.at [213.229.60.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 000E443E3B for ; Tue, 17 Sep 2002 23:09:47 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from smtp-02.inode.at ([62.99.194.4] helo=smtp.inode.at) by mta.inode.at with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.00) id 17rY5s-0005jB-00 for freebsd-net@freebsd.org; Wed, 18 Sep 2002 08:13:48 +0200 Received: from line-e-19.adsl-dynamic.inode.at ([62.99.165.19]:1043 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 17rY0m-0007H2-00 for freebsd-net@freebsd.org; Wed, 18 Sep 2002 08:08:32 +0200 Message-ID: <3D881806.2080302@inode.at> Date: Wed, 18 Sep 2002 08:07:02 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: de-de, de-at, de, en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ppp client-callback Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I allready asked this about one year ago and now I'm asking this again: Does ppp now support client-callback? Does mpd support client-callback? Does anybody know another ppp-software wich supports that? bye, -- -- -------------------------------------- E-mail: Michael.Bretterklieber@jawa.at ---------------------------- JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at --------- privat ----------- E-mail: mbretter@inode.at homepage: http://www.inode.at/mbretter -------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Sep 17 23:50: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D80837B401 for ; Tue, 17 Sep 2002 23:50:05 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27B4843E4A for ; Tue, 17 Sep 2002 23:50:04 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.5/8.11.4) with ESMTP id g8I6o20x071765 for ; Wed, 18 Sep 2002 09:50:02 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3D882218.249F72BE@he.iki.fi> Date: Wed, 18 Sep 2002 09:50:01 +0300 From: Petri Helenius X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.6-STABLE i386) X-Accept-Language: en,fi MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: socket receive space Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org What is the (preferred) way to figure out how much data is waiting on the receive buffer on a socket? I'm running largish >1M receive buffers and would like to log a warning message if the buffers ever get used near-full. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 0:31:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88B4537B401 for ; Wed, 18 Sep 2002 00:31:29 -0700 (PDT) Received: from pirzyk.org (dsl-65-184-181-29.telocity.com [65.184.181.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id E16B343E86 for ; Wed, 18 Sep 2002 00:31:28 -0700 (PDT) (envelope-from jim@pirzyk.org) Received: from snoopy (snoopy-wap.pirzyk.org [10.26.0.10]) by pirzyk.org (8.12.3/8.12.3) with ESMTP id g8I7Tasp003386 for ; Wed, 18 Sep 2002 00:29:36 -0700 (PDT) (envelope-from jim@pirzyk.org) Content-Type: text/plain; charset="us-ascii" From: Jim Pirzyk To: freebsd-net@freebsd.org Subject: getnetbyname broken for DNS case? Date: Wed, 18 Sep 2002 00:32:11 -0700 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209180032.11590.jim@pirzyk.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am trying to debug a problem that I have with /etc/exports. I cannot put in the symbolic name for my network (10.26.0.0) without putting it in /etc/networks. It is currently in DNS, but it looks like the getnetbyname is not working correctly for the DNS case. The functions that are broken is _getnetbydnsname() and getnetanswer(). The _getnetbydnsname() is easily fixed by changing T_PTR to T_A in res_query(), but getnetanswer() is harder to solve. It is not parsing the format of the result correctly. First I had to put some code in to test "type" being T_PTR only if "net_i" is set to BYADDR and T_A if "net_i" is set to BYNAME. When I go into the res_hnok() test, it is assumed by the code that it IP address is in ascii format, which it is not (it is in network binary order). If I remove the res_hnok() test, then it does not load the netent.n_net address correctly. The code is broken for both -CURRENT and -STABLE. So my question is then, can I rewrite getnetbyname() to use gethostbyname() call and massage the result to a netent entry? This would solve the DNS result parsing problem and would also get us T_AAA (IPv6) network name addresses. I would also implement getnetbyaddr() in terms of gethostbyaddr() too. - JimP --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o jim@pirzyk.org ----------------------------------------------- _'\<,_ (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 1:26:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8421B37B401; Wed, 18 Sep 2002 01:26:44 -0700 (PDT) Received: from proton.hexanet.fr (proton.hexanet.fr [81.23.32.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 637B643E65; Wed, 18 Sep 2002 01:26:43 -0700 (PDT) (envelope-from c.prevotaux@hexanet.fr) Received: from hexanet.fr (localhost [127.0.0.1]) by proton.hexanet.fr (8.12.5/8.12.5) with SMTP id g8I8QZxW074165; Wed, 18 Sep 2002 10:26:36 +0200 (CEST) (envelope-from c.prevotaux@hexanet.fr) Date: Wed, 18 Sep 2002 10:26:35 +0200 From: Christophe Prevotaux To: Barney Wolff Cc: net@freebsd.org, smp@freebsd.org Subject: Re: SMP strange behaviour [HELP] Message-Id: <20020918102635.5ba9a91b.c.prevotaux@hexanet.fr> In-Reply-To: <20020917171348.GA35523@tp.databus.com> References: <20020917133505.7fa15f08.c.prevotaux@hexanet.fr> <20020917151328.GA32915@tp.databus.com> <20020917182921.5fe18620.c.prevotaux@hexanet.fr> <20020917171348.GA35523@tp.databus.com> Organization: HEXANET Sarl X-Mailer: Sylpheed version 0.8.0 (GTK+ 1.2.10; i386-portbld-freebsd4.6) X-NCC-RegID: fr.hexanet Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I tries it , but it does not solve the problem however when doing this I noticed the lge0 interface goes down because when I do an ifconfig lge0 up I can log in again on the lge0 interface. Any other ideas ? On Tue, 17 Sep 2002 13:13:48 -0400 Barney Wolff wrote: > Do (as root) > sysctl net.inet.tcp.path_mtu_discovery=0 > on the side sending the big data and see if the problem goes away. > tcpdump -v should show the DF flag set if pmtud is in use. > > On Tue, Sep 17, 2002 at 06:29:21PM +0200, Christophe Prevotaux wrote: > > uhmm how can i find out about this ? > > When I do a tcpdump I see nothing related to this > > > > I will use ethereal to look at it and I'll let you know > > -- > Barney Wolff > I'm available by contract or FT: http://www.databus.com/bwresume.pdf > -- -- =============================================================== Christophe Prevotaux Email: c.prevotaux@hexanet.fr HEXANET SARL URL: http://www.hexanet.fr/ Z.A.C Les Charmilles Tel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center =============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 8: 3:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64E3A37B401 for ; Wed, 18 Sep 2002 08:03:34 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 252D443E42 for ; Wed, 18 Sep 2002 08:03:33 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.5/8.11.4) with ESMTP id g8IF3T0x094470 for ; Wed, 18 Sep 2002 18:03:31 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3D8895BE.F2F12CED@he.iki.fi> Date: Wed, 18 Sep 2002 18:03:26 +0300 From: Petri Helenius X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.6-STABLE i386) X-Accept-Language: en,fi MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: socket buffers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I played around adjusting udp socket buffers for a while and noticed that if the input buffer is set to a value, packets start getting dropped when npkt*MTU > SO_RCVBUF so if a socket receives 100 byte packets over an ethernet interface of 1500 byte MTU and receive buffer of 100k the packets start dropping at less than 10k received data in a buffer. Is this a feature or a bug? I'm running RELENG_4 from a few weeks ago. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 8:51:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B1CB37B401 for ; Wed, 18 Sep 2002 08:51:15 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id A90F743E4A for ; Wed, 18 Sep 2002 08:50:52 -0700 (PDT) (envelope-from justin@mac.com) Received: from smtp-relay02.mac.com (smtp-relay02-en1 [10.13.10.225]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id g8IFnpxD011616 for ; Wed, 18 Sep 2002 08:49:51 -0700 (PDT) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtp-relay02.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g8IFnsZH029433 for ; Wed, 18 Sep 2002 08:49:54 -0700 (PDT) Received: from grinch ([12.234.224.67]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H2N5B500.825 for ; Wed, 18 Sep 2002 08:49:53 -0700 Date: Wed, 18 Sep 2002 08:49:52 -0700 Subject: Re: socket buffers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: "Justin C. Walker" To: freebsd-net@FreeBSD.ORG Content-Transfer-Encoding: 7bit In-Reply-To: <3D8895BE.F2F12CED@he.iki.fi> Message-Id: <453BBE24-CB1E-11D6-891F-00306544D642@mac.com> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday, September 18, 2002, at 08:03 AM, Petri Helenius wrote: > > I played around adjusting udp socket buffers for a while and noticed > that if the input buffer is set to a value, packets start getting > dropped > when npkt*MTU > SO_RCVBUF so if a socket receives 100 byte packets over > an ethernet interface of 1500 byte MTU and receive buffer of 100k the > packets > start dropping at less than 10k received data in a buffer. This is, I think, normal behavior. Check Wright/Stevens (TCP/IP Illustrated, V2), Ch. 2, where this is discussed (as I recall). A socket buffer counts not only the valid data bytes enqueued, but also the size of the mbufs used. The reasoning is clear: in order to avoid having all the mbufs in the system end up on a single queue, because very small packets are being received, counting mbuf space limits the number of mbufs that can be sucked up by one direction for one socket. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | It's not whether you win or lose... | It's whether *I* win or lose. *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 11: 2: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B58E937B401 for ; Wed, 18 Sep 2002 11:02:01 -0700 (PDT) Received: from mailtest.btconnex.net (mailtest.btconnex.net [66.207.192.8]) by mx1.FreeBSD.org (Postfix) with SMTP id D835F43E3B for ; Wed, 18 Sep 2002 11:02:00 -0700 (PDT) (envelope-from eperrin@bwlogic.com) Received: (qmail 80784 invoked from network); 18 Sep 2002 17:59:48 -0000 Received: from unknown (HELO bwlogic.com) (66.207.209.2) by mailtest.btconnex.net with SMTP; 18 Sep 2002 17:59:48 -0000 Message-ID: <3D88BF92.9010308@bwlogic.com> Date: Wed, 18 Sep 2002 14:01:54 -0400 From: Elliott Perrin User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: MPD as a PPTP server Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am not currently on freebsd-net so if you could cc me in replies it would be appreciated. I have a FreeBSD 4.6.2-RELEASE running mpd 3.9 serving as a PPTP server. I have setup PPTP boxes using MPD before but have run into a problem this time. In the past I would use set ipcp ranges 1.2.3.4/32 192.168.1.100/32 where 1.2.3.4 was the external interface of the machine. This worked with multiple links under 3.7, but doesn't seem to under 3.9 Do I have to set a different address for every client connection in tehe first part of the ipcp ranges like this? set ipcp ranges 192.168.1.1/32 192.168.1.100/32 set ipcp ranges 192.168.1.2/32 192.168.1.101/32 and if so, do the first addresses have to corespond to an existing interface requiring me to alias the interface with more than 1 IP. TIA eperrin@bwlogic.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 11:32:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEC6937B401 for ; Wed, 18 Sep 2002 11:32:11 -0700 (PDT) Received: from mailtest.btconnex.net (mailtest.btconnex.net [66.207.192.8]) by mx1.FreeBSD.org (Postfix) with SMTP id E5C2A43E42 for ; Wed, 18 Sep 2002 11:32:10 -0700 (PDT) (envelope-from eperrin@bwlogic.com) Received: (qmail 98543 invoked from network); 18 Sep 2002 18:29:58 -0000 Received: from unknown (HELO bwlogic.com) (66.207.209.2) by mailtest.btconnex.net with SMTP; 18 Sep 2002 18:29:58 -0000 Message-ID: <3D88C6A4.9050704@bwlogic.com> Date: Wed, 18 Sep 2002 14:32:04 -0400 From: Elliott Perrin User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: More on MPD PPTP problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Please cc me on responses sorry fo rthe second post, I realised afterwards I should be posting logs and configs if i am going to ask people for help with the problem. It seems as though I can only setup mpd to listen for one inbound connection. No ng interfaces are present prior to initializing mpd, which I make sure of using ngctl when the links are not shutdown after killing mpd. In the mpd.conf file I have posted below, I have used both the 172.22.4.1/32 address listed and 1.2.3.4/32 as the first number in the ipcp ranges statement. I get the same result each time. 172.22.4.1/32 is an actual interface on the machine. Here is a snip from my log file to show the problem I am having Sep 18 14:21:34 gw mpd: mpd: pid 37673, version 3.9 (root@localhost 18:08 12-Sep-2002) Sep 18 14:21:34 gw mpd: [moveable1] ppp node is "mpd37673-moveab" Sep 18 14:21:34 gw mpd: mpd: local IP address for PPTP is 1.2.3.4 Sep 18 14:21:34 gw mpd: [moveable1] using interface ng0 Sep 18 14:21:34 gw mpd: [moveable2] can't name ppp node: Address already in use Sep 18 14:21:34 gw mpd: [moveable2] netgraph initialization failed Sep 18 14:21:34 gw mpd: [moveable3] can't name ppp node: Address already in use Sep 18 14:21:34 gw mpd: [moveable3] netgraph initialization failed Sep 18 14:21:34 gw mpd: [moveable4] can't name ppp node: Address already in use Sep 18 14:21:34 gw mpd: [moveable4] netgraph initialization failed Sep 18 14:21:34 gw mpd: [moveable5] can't name ppp node: Address already in use Sep 18 14:21:34 gw mpd: [moveable5] netgraph initialization failed My mpd.links file moveable1: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate moveable2: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate moveable3: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate moveable4: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate moveable5: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originatedefault: and my mpd.conf file default: load moveable1 load moveable2 load moveable3 load moveable4 load moveable5 moveable1: new -i ng0 moveable1 moveable1 set ipcp ranges 172.22.4.1/32 172.22.4.105/32 load client_standard moveable2: new -i ng1 moveable2 moveable2 set ipcp ranges 172.22.4.1/32 172.22.4.106/32 load client_standard moveable3: new -i ng2 moveable3 moveable3 set ipcp ranges 172.22.4.1/32 172.22.4.107/32 load client_standard moveable4: new -i ng3 moveable4 moveable4 set ipcp ranges 172.22.4.1/32 172.22.4.108/32 load client_standard moveable5: new -i ng4 moveable5 moveable5 set ipcp ranges 172.22.4.1/32 172.22.4.109/32 load client_standard client_standard: set iface disable on-demand set iface enable proxy-arp set iface route 172.22.16.0/23 set iface idle 1800 set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link mtu 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 172.22.4.51 set bundle enable compression set ccp yes mppc set bundle enable crypt-reqd set ccp yes mpp-e128 set ccp yes mpp-stateless Any hints????? Cheers, eperrin@bwlogic.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 17: 7:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C746337B401; Wed, 18 Sep 2002 17:07:09 -0700 (PDT) Received: from femme.sapphite.org (pcp02268182pcs.longhl01.md.comcast.net [68.50.99.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6146A43E3B; Wed, 18 Sep 2002 17:06:46 -0700 (PDT) (envelope-from trish@bsdunix.net) Received: from localhost (trish@localhost [127.0.0.1]) by femme.sapphite.org (8.12.6/8.12.5) with ESMTP id g8J05U7U097571; Wed, 18 Sep 2002 20:06:10 -0400 (EDT) (envelope-from trish@bsdunix.net) Date: Wed, 18 Sep 2002 20:05:29 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Cc: Subject: Broken IPv4 in IPv6 on -current? Message-ID: <20020918200221.I266-100000@femme.sapphite.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org FreeBSD femme.sapphite.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Mon Sep 9 10:23:22 EDT 2002 trish@femme.sapphite.org:/admins/obj/admins/src/sys/FEMME i386 foo.c: #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { struct sockaddr_in6 addr; struct hostent *hostinfo; int sock; memset(&addr, 0, sizeof(struct sockaddr_in6)); addr.sin6_addr = in6addr_any; addr.sin6_family = AF_INET6; if(argc < 2) return 0; hostinfo = gethostbyname2(argv[1], AF_INET6); memcpy((char *)&addr.sin6_addr, hostinfo->h_addr, hostinfo->h_length); addr.sin6_family = hostinfo->h_addrtype; addr.sin6_port = htons((u_short)5555); sock = socket(AF_INET6, SOCK_STREAM, 0); bind(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr_in6)); listen(sock, 5); sleep(60); return 0; } femme:~#strace ./foo ::ffff:127.0.0.1 execve(0xbfbff5c0, [0xbfbffaa4], [/* 0 vars */]) = 0 mmap(0, 2664, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2805f000 munmap(0x2805f000, 2664) = 0 __sysctl([...], 0x2805e4c8, 0xbfbff864, NULL, 0) = 0 mmap(0, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0x2805f000 geteuid(0) = 0 getuid() = 0 (euid 0) getegid(0) = 0 getgid() = 0 (egid 0) open("/var/run/ld-elf.so.hints", O_RDONLY) = 3 read(3, "ins/src/libexec/rtld-elf/rtld.c:"..., 128) = 128 lseek(3, 549755813888, SEEK_SET) = 128 read(3, "/usr/lib:/usr/lib/compat:/usr/X1"..., 145) = 145 close(3) = 0 access("/usr/lib/libc.so.5", F_OK) = 0 open("/usr/lib/libc.so.5", O_RDONLY) = 3 fstat(3, {st_mode=0, st_size=0, ...}) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 mmap(0, 741376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x28067000 mmap(0x28103000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x9b00000000000) = 0x28103000 mmap(0x28108000, 81920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0x28108000 close(3) = 0 mmap(0, 184, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2811c000 munmap(0x2811c000, 184) = 0 mprotect(0x28067000, 638976, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mmap(0, 18856, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2811c000 munmap(0x2811c000, 18856) = 0 mprotect(0x28067000, 638976, PROT_READ|PROT_EXEC) = 0 sigaction(SIGILL, {SIG_DFL}, {SIG_DFL}) = 0 sigprocmask(SIG_BLOCK, NULL, []) = 0 sigaction(SIGILL, {SIG_DFL}, NULL) = 0 sigprocmask(SIG_BLOCK, ~[ILL TRAP ABRT EMT FPE BUS SEGV SYS], []) = 0 sigprocmask(SIG_SETMASK, [], NULL) = 0 stat("/etc/nsswitch.conf", {st_mode=S_IFBLK|S_ISGID|0554, st_rdev=makedev(40, 2037645344), ...}) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 3 readlink("/etc/malloc.conf", 0xbfbff830, 63) = -1 ENOENT (No such file or directory) mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0x2811c000 break(0x804b000) = 0 break(0x804c000) = 0 break(0x804d000) = 0 break(0x804e000) = 0 break(0x804f000) = 0 ioctl(3, TIOCGETA, 0xbfbff800) = -1 ENOTTY (Inappropriate ioctl for device) fstat(3, {st_mode=0177350, st_size=18446461400436899560, ...}) = 0 break(0x8051000) = 0 read(3, "hosts: files dns \n", 8192) = 18 read(3, "", 8192) = 0 break(0x8052000) = 0 break(0x8053000) = 0 ioctl(3, TIOCGETA, 0xbfbff7f0) = -1 ENOTTY (Inappropriate ioctl for device) close(3) = 0 open("/etc/hosts", O_RDONLY) = 3 gettimeofday({1869638985, 1651078003}, NULL) = 0 getpid() = 97560 (ppid 97559) issetugid(0x7ae) = 0 open("/etc/resolv.conf", O_RDONLY) = 4 fstat(4, {st_mode=S_IFBLK|S_ISGID|0566, st_rdev=makedev(114, 543490165), ...}) = 0 read(4, "search sapphite.org\nnameserver 6"..., 8192) = 86 read(4, "", 8192) = 0 close(4) = 0 issetugid(0x7ae) = 0 fstat(3, {st_mode=0150320, st_size=15046755950319947984, ...}) = 0 read(3, "# $FreeBSD: src/etc/hosts,v 1.11"..., 8192) = 1360 read(3, "", 8192) = 0 close(3) = 0 socket(PF_INET6, SOCK_STREAM, 0) = 3 bind(3, {sin_family=0xd0 /* AF_??? */, {sa_family=208, sa_data="\320\320\320\320\320\320\320\320\320\320\320\320\320\320"...}, 28) = -1 EADDRNOTAVAIL (Can't assign requested address) listen(3, 5) = 0 nanosleep(0xbfbff9f8, 0xbfbff9f0^C its pretty bizarre.... -- Trish Lynch trish@bsdunix.net Ecartis Core Team trish@listmistress.org Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 18:27:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 081C737B401; Wed, 18 Sep 2002 18:27:11 -0700 (PDT) Received: from femme.sapphite.org (pcp02268182pcs.longhl01.md.comcast.net [68.50.99.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4064043E4A; Wed, 18 Sep 2002 18:27:10 -0700 (PDT) (envelope-from trish@bsdunix.net) Received: from localhost (trish@localhost [127.0.0.1]) by femme.sapphite.org (8.12.6/8.12.5) with ESMTP id g8J1Pn3b000570; Wed, 18 Sep 2002 21:26:33 -0400 (EDT) (envelope-from trish@bsdunix.net) Date: Wed, 18 Sep 2002 21:25:49 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Cc: Subject: Broken IPv4 in IPv6 on -current (addendum) Message-ID: <20020918212502.X458-100000@femme.sapphite.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org THis works fine on DP-1. So it broke somewhere between then and now. -Trish -- Trish Lynch trish@bsdunix.net Ecartis Core Team trish@listmistress.org Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 18:45:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0877637B4E6; Wed, 18 Sep 2002 18:45:51 -0700 (PDT) Received: from femme.sapphite.org (pcp02268182pcs.longhl01.md.comcast.net [68.50.99.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F82F43E4A; Wed, 18 Sep 2002 18:45:50 -0700 (PDT) (envelope-from trish@bsdunix.net) Received: from localhost (trish@localhost [127.0.0.1]) by femme.sapphite.org (8.12.6/8.12.5) with ESMTP id g8J1iX3b000782; Wed, 18 Sep 2002 21:45:13 -0400 (EDT) (envelope-from trish@bsdunix.net) Date: Wed, 18 Sep 2002 21:44:33 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Cc: Subject: ipv4 in ipv6 issue solved Message-ID: <20020918214345.O458-100000@femme.sapphite.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org sysctl net.inet6.ip6.v6only=0 -Trish -- Trish Lynch trish@bsdunix.net Ecartis Core Team trish@listmistress.org Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 20:11:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A14D737B401; Wed, 18 Sep 2002 20:11:30 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 621D243E65; Wed, 18 Sep 2002 20:11:29 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:1c30:4bd3:50b6:c139]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8J3ASt49324; Thu, 19 Sep 2002 12:10:28 +0900 (JST) Date: Thu, 19 Sep 2002 12:10:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Trish Lynch Cc: , Subject: Re: ipv4 in ipv6 issue solved In-Reply-To: <20020918214345.O458-100000@femme.sapphite.org> References: <20020918214345.O458-100000@femme.sapphite.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 47 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Wed, 18 Sep 2002 21:44:33 -0400 (EDT), >>>>> Trish Lynch said: > sysctl net.inet6.ip6.v6only=0 This should also work: *** foo.c.orig Thu Sep 19 12:05:04 2002 --- foo.c Thu Sep 19 12:05:56 2002 *************** *** 14,19 **** --- 14,20 ---- struct sockaddr_in6 addr; struct hostent *hostinfo; int sock; + int off; memset(&addr, 0, sizeof(struct sockaddr_in6)); *************** *** 30,35 **** --- 31,40 ---- addr.sin6_port = htons((u_short)5555); sock = socket(AF_INET6, SOCK_STREAM, 0); + #ifdef IPV6_V6ONLY + off = 0; + setsockopt(sock, IPPROTO_IPV6, &off, sizeof(off)); + #endif bind(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr_in6)); listen(sock, 5); I'd recommend this approach rather than to use sysctl, particularly for new applications built from the scratch, because we can control the policy per-socket basis. You may have to note that draft-ietf-ipngwg-rfc2553bis-06.txt specifies 0 as the default value of the option while FreeBSD does not follow the specification. Even though the clear specification, there is a certain amount of stack developers who have a different opinion on this and intentionally reverse the default. So, the safest way is to set the value explicitly. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 21: 5: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51B8A37B401 for ; Wed, 18 Sep 2002 21:05:05 -0700 (PDT) Received: from mx2.licentia.net (24-196-96-227.jvl.wi.charter.com [24.196.96.227]) by mx1.FreeBSD.org (Postfix) with SMTP id 8214043E75 for ; Wed, 18 Sep 2002 21:05:04 -0700 (PDT) (envelope-from lists@stevenfettig.com) Received: (qmail 45251 invoked from network); 19 Sep 2002 04:04:59 -0000 Received: from unknown (HELO Unknown21) (10.6.18.1) by mx2.licentia.net with SMTP; 19 Sep 2002 04:04:59 -0000 Date: Wed, 18 Sep 2002 23:04:58 -0500 Subject: Re: Network Transfer Speed Issues - Tweaks/Advice? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Steve Fettig To: David Burns , net@freebsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <3D87CEFF.1010409@dugeem.net> Message-Id: X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I really appreciate everyone who offered up a few ideas and answers. One of the first things I finally figured out was that the adapter was failing... hmmm doesn't make sense - it didn't fail completely, but I swapped it out with a different adapter (same thing 2940UW) and the performance change was quite remarkable. That still didn't solve the huge discrepancy in speed difference between my other SCSI (internal) drives and the ones I am working with, however. My next test will be to build a system from the ground up w/ a 500 MHz processor and a 133 MHz FSB. I am also wondering if I really missed the boat on the drives, too. They are "older" 5400 RPM SCSI drives (HUGE drives physically) but I don't see how they would be any slower than an IDE 5400 RPM drive - which they are and quite a bit so. As for all of the other stuff, the CPU load is usually at a steady 15% (nfsd). Since that is the only service running (besides the required daemons on a somewhat vanilla system) and the only load that the "server" is under, I don't think that is an issue. I am going to test system performance with the suggested programs (that was another thing I was looking for in the answer, although I guess I didn't say it...) and see what happens. I am starting to think that this is a combination of controller and system not having the performance I was expecting. Everything on the net end seems to be functioning without problem - no lost packets, broken communication, etc. Well, the testing goes on. Please continue to comment if you have any ideas (especially with regards to kernel tweaks, etc). Thanks, Steve On Tuesday, September 17, 2002, at 07:55 , David Burns wrote: > Steve Fettig wrote: >> I recently set up an NFS server to run daily backups on. The server >> was built using an old P150 w/ 90 MB of ram and a 6GB hard drive. >> (All servers in this experiment are set up using FBSD 4.6.2 and the >> client is a Mac PowerBook G4 running Mac OS X.) Attached to it is an >> external SCSI hard drive enclosure with 4 47GB SCSI drives running off >> an AHA-2490UW SCSI adapter. I am getting really odd performance when >> doing an NFS transfer (I also get odd performance out of scp) from the >> machine I am trying to back up. I will get a burst of 20Mbps for >> about 30 seconds, then it will ramp down to 1 Mbps for about 2 >> minutes, ramp backup to 20 Mbps, then back down to 1 Mbps and so on. > You need to break the problem down ... Is the system CPU and/or IO > bound during the backup? Also try some quick benchmarks to verify basic > system performance levels: Network IO - use ttcp (or netperf etc), and > Disk IO - use bonnie (or similar). > > NB Of course you can't simply take such benchmarks results and put them > together - but you will gain a better understanding of where the > potential slowdowns may be. > > Lastly, performance issues on older Pentiums can also result from poor > memory bandwidth and/or PCI chipset problems. I recently replaced a > P120 with a Celeron 333 - the performance improvement was surprising. > > Regards, > David > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 18 21:32:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7069A37B401 for ; Wed, 18 Sep 2002 21:32:26 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 139BC43E65 for ; Wed, 18 Sep 2002 21:32:25 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c1-vpn1.isi.edu [128.9.176.27]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g8J4W8C23026; Wed, 18 Sep 2002 21:32:08 -0700 (PDT) Message-ID: <3D895348.3000706@isi.edu> Date: Wed, 18 Sep 2002 21:32:08 -0700 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Fettig Cc: David Burns , net@freebsd.org Subject: Re: Network Transfer Speed Issues - Tweaks/Advice? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050505020809000700020107" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms050505020809000700020107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Steve, your setup is way to complex. As David suggested, first try to establish whether the network connection between the two machines is the problem or not. Forget about NFS for now, just benchmark TCP and UDP (which do you NFS mount over, by the way?) If network performance is erratic, isolate the setup from cross traffic, and swap out NICs, hubs and or switches. Only after you've ruled out the network would I start worrying about disks, controllers and NFS settings. The idea here is to change ONE parameter in the setup at a time, and rerun your benchmark of choice. Steve Fettig wrote: > I really appreciate everyone who offered up a few ideas and answers. > One of the first things I finally figured out was that the adapter was > failing... hmmm doesn't make sense - it didn't fail completely, but I > swapped it out with a different adapter (same thing 2940UW) and the > performance change was quite remarkable. That still didn't solve the > huge discrepancy in speed difference between my other SCSI (internal) > drives and the ones I am working with, however. My next test will be to > build a system from the ground up w/ a 500 MHz processor and a 133 MHz > FSB. I am also wondering if I really missed the boat on the drives, > too. They are "older" 5400 RPM SCSI drives (HUGE drives physically) but > I don't see how they would be any slower than an IDE 5400 RPM drive - > which they are and quite a bit so. > As for all of the other stuff, the CPU load is usually at a steady 15% > (nfsd). Since that is the only service running (besides the required > daemons on a somewhat vanilla system) and the only load that the > "server" is under, I don't think that is an issue. I am going to test > system performance with the suggested programs (that was another thing I > was looking for in the answer, although I guess I didn't say it...) and > see what happens. I am starting to think that this is a combination of > controller and system not having the performance I was expecting. > Everything on the net end seems to be functioning without problem - no > lost packets, broken communication, etc. > > Well, the testing goes on. Please continue to comment if you have any > ideas (especially with regards to kernel tweaks, etc). > > Thanks, > Steve > > On Tuesday, September 17, 2002, at 07:55 , David Burns wrote: > >> Steve Fettig wrote: >> >>> I recently set up an NFS server to run daily backups on. The server >>> was built using an old P150 w/ 90 MB of ram and a 6GB hard drive. >>> (All servers in this experiment are set up using FBSD 4.6.2 and the >>> client is a Mac PowerBook G4 running Mac OS X.) Attached to it is an >>> external SCSI hard drive enclosure with 4 47GB SCSI drives running >>> off an AHA-2490UW SCSI adapter. I am getting really odd performance >>> when doing an NFS transfer (I also get odd performance out of scp) >>> from the machine I am trying to back up. I will get a burst of >>> 20Mbps for about 30 seconds, then it will ramp down to 1 Mbps for >>> about 2 minutes, ramp backup to 20 Mbps, then back down to 1 Mbps and >>> so on. >> >> You need to break the problem down ... Is the system CPU and/or IO >> bound during the backup? Also try some quick benchmarks to verify >> basic system performance levels: Network IO - use ttcp (or netperf >> etc), and Disk IO - use bonnie (or similar). >> >> NB Of course you can't simply take such benchmarks results and put >> them together - but you will gain a better understanding of where the >> potential slowdowns may be. >> >> Lastly, performance issues on older Pentiums can also result from poor >> memory bandwidth and/or PCI chipset problems. I recently replaced a >> P120 with a Celeron 333 - the performance improvement was surprising. >> >> Regards, >> David >> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Lars Eggert USC Information Sciences Institute --------------ms050505020809000700020107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMDkxOTA0MzIwOFowIwYJKoZIhvcNAQkEMRYEFFBcbECimnFwfNPqmFAH k+YyVSNOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAE2zZ20onfGzhWgb9bpf8WZ2Bph4zLInjaJj4iP3nyig7OIDWF0Qh WzvqszYB0BcVIJE2TuEjyBCfDW0J1XnELIgin7WxFqlnhhGAhA3IBApj6y8HIQaBuCDGbpvb 7h0ojnRfdoe2uCH5hqinv6Pmz2VmO1CLJ02UtO5LJqQWy4bSYAlhAaiik77d9KD88k4uGufQ itGoW2Tu3QjBJTvhC2TyqqjAGGZAVgLW6aDnUQqX0+nTCoqpxNwhCDJcq/Wgs9LEsbEctwFK bYAbOyeasXATjHBi7nIm7wWHEjvJyzmyUnqC/jb94pj5tIWmjMC8c8trwuXwmNVq77UFo0hf zwAAAAAAAA== --------------ms050505020809000700020107-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 1: 7:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9943337B401; Thu, 19 Sep 2002 01:07:17 -0700 (PDT) Received: from ady.warpnet.ro (ady.warpnet.ro [217.156.25.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89CC743E75; Thu, 19 Sep 2002 01:07:15 -0700 (PDT) (envelope-from ady@freebsd.ady.ro) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id LAA85948; Thu, 19 Sep 2002 11:07:08 +0300 (EEST) (envelope-from ady@freebsd.ady.ro) Date: Thu, 19 Sep 2002 11:07:07 +0300 (EEST) From: Adrian Penisoara X-Sender: ady@ady.warpnet.ro To: freebsd-net@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Desired feature: ipfw pass for routed IPs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, When building anti-spoofing firewall rules on a routing server it would be very helpfull to have a way to tell ipfw (or other firewalling mechanisms) to pass all pachets that the source or destination IP has a valid (static/daemon) routing entry in the kernel. Something maybe like: ipfw add allow ip from any to any routed static via xl0 ipfw add deny ip from any to any via xl0 The 'routed' keyword should accept route associated flags (like those listed in route(8)). That would be a desired feature too, because some routing daemons mark their routes in a different way (for example Zebra brings up the RTF_PROTO1 flag on its routes). It's been said that iproute2 in the recent Linux kernels alreay support this, but I haven't checked out closely. How hard would that be to implement ? Thank you, Adrian Penisoara Ady (@freebsd.ady.ro) ____________________________________________________________________ | An age is called Dark not because the light fails to shine, but | | because people refuse to see it. | | -- James Michener, "Space" | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 1:40:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D46D37B401; Thu, 19 Sep 2002 01:40:31 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF13B43E65; Thu, 19 Sep 2002 01:40:29 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.5/8.12.5) with ESMTP id g8J8di6K054382 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 19 Sep 2002 10:39:45 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.1.10]) by cicely5.cicely.de (8.12.6/8.12.6) with ESMTP id g8J8dgaL006060 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 19 Sep 2002 10:39:43 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (localhost [127.0.0.1]) by cicely8.cicely.de (8.12.6/8.12.6) with ESMTP id g8J8dfhC022270; Thu, 19 Sep 2002 10:39:42 +0200 (CEST) (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.12.6/8.12.6/Submit) id g8J8dfMv022269; Thu, 19 Sep 2002 10:39:41 +0200 (CEST) Date: Thu, 19 Sep 2002 10:39:40 +0200 From: Bernd Walter To: Trish Lynch Cc: freebsd-net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Broken IPv4 in IPv6 on -current? Message-ID: <20020919083939.GD19408@cicely8.cicely.de> Reply-To: ticso@cicely.de References: <20020918200221.I266-100000@femme.sapphite.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020918200221.I266-100000@femme.sapphite.org> X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 User-Agent: Mutt/1.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Sep 18, 2002 at 08:05:29PM -0400, Trish Lynch wrote: > FreeBSD femme.sapphite.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Mon Sep 9 > 10:23:22 EDT 2002 > trish@femme.sapphite.org:/admins/obj/admins/src/sys/FEMME i386 > > its pretty bizarre.... It's disabled by default: [238]cicely8> sysctl net.inet6.ip6.v6only net.inet6.ip6.v6only: 1 The prefered way to handle IPv6 as well as IPv4 connects you should listen to both addresses. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 1:44:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A33037B401 for ; Thu, 19 Sep 2002 01:44:30 -0700 (PDT) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39F0843E6E for ; Thu, 19 Sep 2002 01:44:29 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 48445431DD; Thu, 19 Sep 2002 10:44:28 +0200 (CEST) Received: from it.uc3m.es (mira.it.uc3m.es [163.117.140.166]) by smtp02.uc3m.es (Postfix) with ESMTP id 8468F99F2A; Thu, 19 Sep 2002 10:44:27 +0200 (CEST) Message-ID: <3D898E6B.692C3C43@it.uc3m.es> Date: Thu, 19 Sep 2002 10:44:27 +0200 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.5-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Lista , "(Lista) bind9-users@isc.org" Subject: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello: I need to make some tests with IPv6 anycast addresses, and I've found out that when /etc/resolv.conf has an IPv6 anycast address, the DNS response isn't accepted because it comes from an unicast IPv6 address. I've been digging into the source code of /usr/src/lib/libc/net/res_* and I've found these constants: RES_INSECURE1 RES_INSECURE2 and a compilation option called: CHECK_SRVR_ADDR What I would like to do is re-compile the resolver library to accept DNS responses coming from a unicast IPv6 address to solve the problem mentioned above. What's better... to *un*define CHECK_SRVR_ADDR or to include RES_INSECURE1 into RES_DEFAULT ? Do you think it's a good idea to do this ? what are the security implications ? PS: RES_DEFAULT appears in "resolv.h" Best Regards. -- JFRH. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 11:14: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1A3037B401; Thu, 19 Sep 2002 11:14:05 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0676B43E6A; Thu, 19 Sep 2002 11:14:05 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020919181404.LXDJ14978.sccrmhc01.attbi.com@blossom.cjclark.org>; Thu, 19 Sep 2002 18:14:04 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g8JIE3Wn018929; Thu, 19 Sep 2002 11:14:03 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g8JIE1KU018928; Thu, 19 Sep 2002 11:14:01 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Thu, 19 Sep 2002 11:14:01 -0700 From: "Crist J. Clark" To: Adrian Penisoara Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Desired feature: ipfw pass for routed IPs Message-ID: <20020919181401.GA18752@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Sep 19, 2002 at 11:07:07AM +0300, Adrian Penisoara wrote: > Hi, > > When building anti-spoofing firewall rules on a routing server it > would be very helpfull to have a way to tell ipfw (or other firewalling > mechanisms) to pass all pachets that the source or destination IP has a > valid (static/daemon) routing entry in the kernel. > > Something maybe like: > > ipfw add allow ip from any to any routed static via xl0 > ipfw add deny ip from any to any via xl0 > > The 'routed' keyword should accept route associated flags (like those > listed in route(8)). That would be a desired feature too, because some > routing daemons mark their routes in a different way (for example Zebra > brings up the RTF_PROTO1 flag on its routes). > > It's been said that iproute2 in the recent Linux kernels alreay > support this, but I haven't checked out closely. > > How hard would that be to implement ? On input packets, it'd be painful and not really practical. On output packets, it shouldn't be _too_ bad since the routing information would be available. I'm not quite sure I understand why it would be needed. If there isn't a route to send a packet out of an interface, it won't go out of the interface. Under what conditions would you see yourself blocking packets? Is this really an ackbassward way to filter routes from routing daemons? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 14:18: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0DF037B401 for ; Thu, 19 Sep 2002 14:18:02 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685F243E65 for ; Thu, 19 Sep 2002 14:18:02 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA36937; Thu, 19 Sep 2002 14:14:07 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g8JLD3rf062158; Thu, 19 Sep 2002 14:13:03 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g8JLD3me062157; Thu, 19 Sep 2002 14:13:03 -0700 (PDT) From: Archie Cobbs Message-Id: <200209192113.g8JLD3me062157@arch20m.dellroad.org> Subject: Re: More on MPD PPTP problem In-Reply-To: <3D88C6A4.9050704@bwlogic.com> "from Elliott Perrin at Sep 18, 2002 02:32:04 pm" To: Elliott Perrin Date: Thu, 19 Sep 2002 14:13:03 -0700 (PDT) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Elliott Perrin writes: > Sep 18 14:21:34 gw mpd: [moveable5] can't name ppp node: Address already in use This is a somewhat obscure error caused by using bundle names that are longer than NG_NODELEN (16+NUL). Try replacing "movable*" with "mov*" everywhere in mpd.conf & mpd.links. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 14:18: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E234F37B418 for ; Thu, 19 Sep 2002 14:18:04 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 090F743E6A for ; Thu, 19 Sep 2002 14:18:04 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA36928; Thu, 19 Sep 2002 14:11:29 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g8JLAPrf062088; Thu, 19 Sep 2002 14:10:25 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g8JLAOlA062087; Thu, 19 Sep 2002 14:10:24 -0700 (PDT) From: Archie Cobbs Message-Id: <200209192110.g8JLAOlA062087@arch20m.dellroad.org> Subject: Re: MPD as a PPTP server In-Reply-To: <3D88BF92.9010308@bwlogic.com> "from Elliott Perrin at Sep 18, 2002 02:01:54 pm" To: Elliott Perrin Date: Thu, 19 Sep 2002 14:10:24 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Elliott Perrin writes: > I am not currently on freebsd-net so if you could cc me in replies it would be > appreciated. > > I have a FreeBSD 4.6.2-RELEASE running mpd 3.9 serving as a PPTP server. > > I have setup PPTP boxes using MPD before but have run into a problem this time. In > the past I would use > > set ipcp ranges 1.2.3.4/32 192.168.1.100/32 > > where 1.2.3.4 was the external interface of the machine. This worked with multiple > links under 3.7, but doesn't seem to under 3.9 > > Do I have to set a different address for every client connection in tehe first part > of the ipcp ranges like this? > > set ipcp ranges 192.168.1.1/32 192.168.1.100/32 > set ipcp ranges 192.168.1.2/32 192.168.1.101/32 Mpd should be happy using the same local address for multiple connections. Can you be more specific than "it doesn't seem to work" ? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 14:21:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30F7937B401; Thu, 19 Sep 2002 14:21:20 -0700 (PDT) Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99E8C43E77; Thu, 19 Sep 2002 14:21:19 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id 0A45415E47; Thu, 19 Sep 2002 17:21:19 -0400 (EDT) Date: Thu, 19 Sep 2002 17:21:18 -0400 From: Richard A Steenbergen To: "Crist J. Clark" Cc: Adrian Penisoara , freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Desired feature: ipfw pass for routed IPs Message-ID: <20020919212118.GU1123@overlord.e-gerbil.net> References: <20020919181401.GA18752@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020919181401.GA18752@blossom.cjclark.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Sep 19, 2002 at 11:14:01AM -0700, Crist J. Clark wrote: > On input packets, it'd be painful and not really practical. On output > packets, it shouldn't be _too_ bad since the routing information would > be available. > > I'm not quite sure I understand why it would be needed. If there isn't > a route to send a packet out of an interface, it won't go out of the > interface. Under what conditions would you see yourself blocking > packets? Is this really an ackbassward way to filter routes from > routing daemons? Sounds like he wants an implementation of unicast reverse path forwarding (uRPF) loose-mode to prevent source address spoofing of non-announced space. uRPF is simple, you do a 2nd routing lookup on the src address to check for a valid return route, either a) with a nexthop to the interface on which the packet was received, for filtering customers, or b) with a nexthop to any interface, for inbound on network borders. Strict-mode is only useful for devices which route, but loose-mode could potentially be used to reduce the impact of random source DoS attacks (sounds like something linux would do :P). Unfortunately, the performance impact of doing radix tree lookups for a full routing table to filter this way would probably be worse than not filtering at all. While any device which calls itself a modern router SHOULD have this functionality, I think there are more important things to fix first. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 14:30: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C797737B401 for ; Thu, 19 Sep 2002 14:30:07 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 362C343E3B for ; Thu, 19 Sep 2002 14:30:07 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA37028; Thu, 19 Sep 2002 14:20:23 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g8JLJJrf062189; Thu, 19 Sep 2002 14:19:19 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g8JLJJLW062188; Thu, 19 Sep 2002 14:19:19 -0700 (PDT) From: Archie Cobbs Message-Id: <200209192119.g8JLJJLW062188@arch20m.dellroad.org> Subject: Re: ppp client-callback In-Reply-To: <3D881806.2080302@inode.at> "from Michael Bretterklieber at Sep 18, 2002 08:07:02 am" To: Michael Bretterklieber Date: Thu, 19 Sep 2002 14:19:19 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Michael Bretterklieber writes: > Does mpd support client-callback? No, sorry. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 16: 0: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CD7A37B401 for ; Thu, 19 Sep 2002 15:59:59 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08C4543E4A for ; Thu, 19 Sep 2002 15:59:58 -0700 (PDT) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8JMxsB5065119; Fri, 20 Sep 2002 08:59:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209192259.g8JMxsB5065119@drugs.dv.isc.org> To: Juan Francisco Rodriguez Hervella Cc: Lista , "(Lista) bind9-users@isc.org" From: Mark.Andrews@isc.org Subject: Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem) In-reply-to: Your message of "Thu, 19 Sep 2002 10:44:27 +0200." <3D898E6B.692C3C43@it.uc3m.es> Date: Fri, 20 Sep 2002 08:59:54 +1000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Hello: > > I need to make some tests with IPv6 anycast addresses, > and I've found out that when /etc/resolv.conf has an > IPv6 anycast address, the DNS response isn't accepted because > it comes from an unicast IPv6 address. > > I've been digging into the source code of > /usr/src/lib/libc/net/res_* > and I've found these constants: > > RES_INSECURE1 > RES_INSECURE2 > > and a compilation option called: > > CHECK_SRVR_ADDR > > > What I would like to do is re-compile > the resolver library to accept DNS responses > coming from a unicast IPv6 address to solve > the problem mentioned above. > > What's better... to *un*define CHECK_SRVR_ADDR > or to include RES_INSECURE1 into RES_DEFAULT ? > Do you think it's a good idea to do this ? > what are the security implications ? > > PS: RES_DEFAULT appears in "resolv.h" > > Best Regards. > > -- > JFRH. > IPv6 anycast addresses are a joke as they are currently defined. Don't bother with them until there behaviour gets redefined by the IETF. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 16: 0:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6661C37B404 for ; Thu, 19 Sep 2002 16:00:24 -0700 (PDT) Received: from mail.cragx.fgov.be (mail.cragx.fgov.be [193.190.115.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7F4643E4A for ; Thu, 19 Sep 2002 16:00:22 -0700 (PDT) (envelope-from bind9-users-bounce@isc.org) Received: from mail pickup service by mail.cragx.fgov.be with Microsoft SMTPSVC; Fri, 20 Sep 2002 00:56:07 +0200 MIME-Version: 1.0 x-sender: bind9-users-bounce@isc.org x-receiver: webmaster@cragx.fgov.be Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Received: from minardi.isc.org ([204.152.189.14]) by mail.cragx.fgov.be with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Sep 2002 00:56:05 +0200 Received: from rc.isc.org (rc.isc.org [204.152.187.2]) by minardi.isc.org (Postfix) with ESMTP id 2435C2C76; Thu, 19 Sep 2002 23:00:06 +0000 (UTC) (envelope-from bind9-users-bounce@isc.org) Received: with ECARTIS (v1.0.0; list bind9-users); Thu, 19 Sep 2002 23:00:05 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Delivered-To: bind9-users@rc.isc.org Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by rc.isc.org (Postfix) with ESMTP id 7148AA60 for ; Thu, 19 Sep 2002 23:00:01 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8JMxsB5065119; Fri, 20 Sep 2002 08:59:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-ID: <200209192259.g8JMxsB5065119@drugs.dv.isc.org> To: "Juan Francisco Rodriguez Hervella" Cc: "Lista" , From: Subject: Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem) In-Reply-To: Your message of "Thu, 19 Sep 2002 10:44:27 +0200." <3D898E6B.692C3C43@it.uc3m.es> Date: Fri, 20 Sep 2002 08:59:54 +1000 X-archive-position: 8976 X-ecartis-version: Ecartis v1.0.0 X-original-sender: Mark_Andrews@isc.org X-list: bind9-users X-OriginalArrivalTime: 19 Sep 2002 22:56:06.0015 (UTC) FILETIME=[BC6350F0:01C2602F] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > Hello: > > I need to make some tests with IPv6 anycast addresses, > and I've found out that when /etc/resolv.conf has an > IPv6 anycast address, the DNS response isn't accepted because > it comes from an unicast IPv6 address. > > I've been digging into the source code of > /usr/src/lib/libc/net/res_* > and I've found these constants: > > RES_INSECURE1 > RES_INSECURE2 > > and a compilation option called: > > CHECK_SRVR_ADDR > > > What I would like to do is re-compile > the resolver library to accept DNS responses > coming from a unicast IPv6 address to solve > the problem mentioned above. > > What's better... to *un*define CHECK_SRVR_ADDR > or to include RES_INSECURE1 into RES_DEFAULT ? > Do you think it's a good idea to do this ? > what are the security implications ? > > PS: RES_DEFAULT appears in "resolv.h" > > Best Regards. > > -- > JFRH. > IPv6 anycast addresses are a joke as they are currently defined. Don't bother with them until there behaviour gets redefined by the IETF. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 19: 9:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8CF037B401 for ; Thu, 19 Sep 2002 19:09:44 -0700 (PDT) Received: from mailtest.btconnex.net (mailtest.btconnex.net [66.207.192.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 6330043E4A for ; Thu, 19 Sep 2002 19:09:43 -0700 (PDT) (envelope-from eperrin@bwlogic.com) Received: (qmail 78021 invoked from network); 20 Sep 2002 02:07:28 -0000 Received: from unknown (HELO bwlogic.com) (66.207.209.2) by mailtest.btconnex.net with SMTP; 20 Sep 2002 02:07:28 -0000 Message-ID: <3D8A8364.2020008@bwlogic.com> Date: Thu, 19 Sep 2002 22:09:40 -0400 From: Elliott Perrin User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@freebsd.org Subject: Re: More on MPD PPTP problem References: <200209192113.g8JLD3me062157@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org That fixed the problem. All five now load. Thanks a bunch. Elliott Archie Cobbs wrote: > Elliott Perrin writes: > >>Sep 18 14:21:34 gw mpd: [moveable5] can't name ppp node: Address already in use >> > > This is a somewhat obscure error caused by using bundle names that > are longer than NG_NODELEN (16+NUL). > > Try replacing "movable*" with "mov*" everywhere in mpd.conf & mpd.links. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 21:50:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 456CC37B401 for ; Thu, 19 Sep 2002 21:50:32 -0700 (PDT) Received: from web14208.mail.yahoo.com (web14208.mail.yahoo.com [216.136.173.72]) by mx1.FreeBSD.org (Postfix) with SMTP id 1367743E3B for ; Thu, 19 Sep 2002 21:50:32 -0700 (PDT) (envelope-from neelnatu@yahoo.com) Message-ID: <20020920045031.98699.qmail@web14208.mail.yahoo.com> Received: from [66.171.82.32] by web14208.mail.yahoo.com via HTTP; Thu, 19 Sep 2002 21:50:31 PDT Date: Thu, 19 Sep 2002 21:50:31 -0700 (PDT) From: Neelkanth Natu Subject: clusters not used in /dev/tun ? To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I noticed that tunwrite() does not allocate a cluster, even if the size of the packet is greater than or equal to MINCLSIZE. Rather it stores the packet in a mbuf chain. Is there any reason why this is so ? I thought that packets with size >= MINCLSIZE are traditionally stored in clusters. Can someone please take a look at the patch for -current below ? thanks Neel --- /home/neel/if_tun.c.current Thu Sep 19 21:19:19 2002 +++ if_tun.c Thu Sep 19 21:32:05 2002 @@ -717,27 +717,32 @@ } tlen = uio->uio_resid; - /* get a header mbuf */ - MGETHDR(m, M_DONTWAIT, MT_DATA); - if (m == NULL) - return (ENOBUFS); - mlen = MHLEN; - top = 0; mp = ⊤ while (error == 0 && uio->uio_resid > 0) { + if (top == 0) { + MGETHDR(m, M_DONTWAIT, MT_DATA); + mlen = MHLEN; + } else { + MGET(m, M_DONTWAIT, MT_DATA); + mlen = MLEN; + } + if (m == 0) { + error = ENOBUFS; + break; + } + if (uio->uio_resid >= MINCLSIZE) { + MCLGET(m, M_DONTWAIT); + if (m->m_flags & M_EXT) { + mlen = MCLBYTES; + } else { + /* store the data in the mbuf itself */ + } + } m->m_len = min(mlen, uio->uio_resid); error = uiomove(mtod (m, caddr_t), m->m_len, uio); *mp = m; mp = &m->m_next; - if (uio->uio_resid > 0) { - MGET (m, M_DONTWAIT, MT_DATA); - if (m == 0) { - error = ENOBUFS; - break; - } - mlen = MLEN; - } } if (error) { if (top) __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 22: 0:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2323237B401 for ; Thu, 19 Sep 2002 22:00:55 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18CC043E3B for ; Thu, 19 Sep 2002 22:00:54 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8K50Jt60406; Fri, 20 Sep 2002 14:00:20 +0900 (JST) Date: Fri, 20 Sep 2002 14:00:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mark_Andrews@isc.org Cc: Juan Francisco Rodriguez Hervella , Lista , "(Lista) bind9-users@isc.org" Subject: Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem) In-Reply-To: <200209192259.g8JMxsB5065119@drugs.dv.isc.org> References: <3D898E6B.692C3C43@it.uc3m.es> <200209192259.g8JMxsB5065119@drugs.dv.isc.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 20 Sep 2002 08:59:54 +1000, >>>>> Mark_Andrews@isc.org said: > IPv6 anycast addresses are a joke as they are currently > defined. Don't bother with them until there behaviour > gets redefined by the IETF. (I'm just asking,) what is the "joke" part of the current definition? The restriction that an anycast address must not be used as a packet's source address? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 22:41: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEEFA37B401 for ; Thu, 19 Sep 2002 22:41:03 -0700 (PDT) Received: from web12202.mail.yahoo.com (web12202.mail.yahoo.com [216.136.173.86]) by mx1.FreeBSD.org (Postfix) with SMTP id B296F43E6E for ; Thu, 19 Sep 2002 22:41:03 -0700 (PDT) (envelope-from kshitijgunjikar@yahoo.com) Message-ID: <20020920054103.13006.qmail@web12202.mail.yahoo.com> Received: from [203.124.128.243] by web12202.mail.yahoo.com via HTTP; Thu, 19 Sep 2002 22:41:03 PDT Date: Thu, 19 Sep 2002 22:41:03 -0700 (PDT) From: kshitij gunjikar Subject: sendto question To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All, I have question on sendto? If we set the socket address as 255.255.255.255. Will the packet be broadcasted on all (broadcastable) interfaces? I have two broadcastable interfaces but I observed it sends to only one interface? Anything else has to done to send broadcast on all interfaces? Regards Kshitij __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 22:49: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7103A37B401 for ; Thu, 19 Sep 2002 22:49:01 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1577A43E42 for ; Thu, 19 Sep 2002 22:49:00 -0700 (PDT) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8K5mrB5067818; Fri, 20 Sep 2002 15:48:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209200548.g8K5mrB5067818@drugs.dv.isc.org> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Juan Francisco Rodriguez Hervella , Lista , "(Lista) bind9-users@isc.org" From: Mark.Andrews@isc.org Subject: Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem) In-reply-to: Your message of "Fri, 20 Sep 2002 14:00:46 +0900." Date: Fri, 20 Sep 2002 15:48:53 +1000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >>>>> On Fri, 20 Sep 2002 08:59:54 +1000, > >>>>> Mark_Andrews@isc.org said: > > > IPv6 anycast addresses are a joke as they are currently > > defined. Don't bother with them until there behaviour > > gets redefined by the IETF. > > (I'm just asking,) what is the "joke" part of the current definition? > The restriction that an anycast address must not be used as a packet's > source address? Yes, and I know why the restriction is in RFC 1884 and it is a reasonable restriction. A client application shouldn't have to care if a packet is sent to a anycast address and the reply should appear to come from the anycast address from the point of view of the application. Until anycast addresses meet the above they will be a joke. With multicast and broadcast you know in advance that you will get return a traffic from a different address. Anycast addresses appear to the client application as unicast addresses. They should behave like unicast addresses for the client application. Server applications may need additional smarts to cope with anycast addresses. But really the IP stack should deal with 99% of this. Mark > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 22:49:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64D9837B401 for ; Thu, 19 Sep 2002 22:49:25 -0700 (PDT) Received: from mail.cragx.fgov.be (mail.cragx.fgov.be [193.190.115.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA8FD43E77 for ; Thu, 19 Sep 2002 22:49:23 -0700 (PDT) (envelope-from bind9-users-bounce@isc.org) Received: from mail pickup service by mail.cragx.fgov.be with Microsoft SMTPSVC; Fri, 20 Sep 2002 07:45:10 +0200 MIME-Version: 1.0 x-sender: bind9-users-bounce@isc.org x-receiver: webmaster@cragx.fgov.be Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Received: from minardi.isc.org ([204.152.189.14]) by mail.cragx.fgov.be with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Sep 2002 07:45:09 +0200 Received: from rc.isc.org (rc.isc.org [204.152.187.2]) by minardi.isc.org (Postfix) with ESMTP id 461772213; Fri, 20 Sep 2002 05:49:10 +0000 (UTC) (envelope-from bind9-users-bounce@isc.org) Received: with ECARTIS (v1.0.0; list bind9-users); Fri, 20 Sep 2002 05:49:09 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Delivered-To: bind9-users@rc.isc.org Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by rc.isc.org (Postfix) with ESMTP id 3835AA60 for ; Fri, 20 Sep 2002 05:49:05 +0000 (UTC) (envelope-from marka@drugs.dv.isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8K5mrB5067818; Fri, 20 Sep 2002 15:48:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-ID: <200209200548.g8K5mrB5067818@drugs.dv.isc.org> To: "=?us-ascii?Q?JINMEI_Tatuya_/_=1B$B=3F@L"@C#.FreeBSD.ORG:H=1B=28B?= Cc: "Juan Francisco Rodriguez Hervella" , "Lista" , From: Subject: Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem) In-Reply-To: Your message of "Fri, 20 Sep 2002 14:00:46 +0900." Date: Fri, 20 Sep 2002 15:48:53 +1000 X-archive-position: 8980 X-ecartis-version: Ecartis v1.0.0 X-original-sender: Mark_Andrews@isc.org X-list: bind9-users X-OriginalArrivalTime: 20 Sep 2002 05:45:09.0656 (UTC) FILETIME=[E189B980:01C26068] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >>>>> On Fri, 20 Sep 2002 08:59:54 +1000, > >>>>> Mark_Andrews@isc.org said: > > > IPv6 anycast addresses are a joke as they are currently > > defined. Don't bother with them until there behaviour > > gets redefined by the IETF. > > (I'm just asking,) what is the "joke" part of the current definition? > The restriction that an anycast address must not be used as a packet's > source address? Yes, and I know why the restriction is in RFC 1884 and it is a reasonable restriction. A client application shouldn't have to care if a packet is sent to a anycast address and the reply should appear to come from the anycast address from the point of view of the application. Until anycast addresses meet the above they will be a joke. With multicast and broadcast you know in advance that you will get return a traffic from a different address. Anycast addresses appear to the client application as unicast addresses. They should behave like unicast addresses for the client application. Server applications may need additional smarts to cope with anycast addresses. But really the IP stack should deal with 99% of this. Mark > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 19 23:37:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C51C237B401 for ; Thu, 19 Sep 2002 23:37:24 -0700 (PDT) Received: from venus.vincentjardin.net (AVelizy-102-1-3-174.abo.wanadoo.fr [217.128.244.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4236B43E4A for ; Thu, 19 Sep 2002 23:37:24 -0700 (PDT) (envelope-from jardin@venus.vincentjardin.net) Received: by venus.vincentjardin.net (Postfix, from userid 501) id C00921503A0; Fri, 20 Sep 2002 08:52:06 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-15" From: Vincent Jardin To: FreeBSD-net@freebsd.org Subject: IP[6]FW and active FTP Date: Fri, 20 Sep 2002 08:52:06 +0200 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020920065206.C00921503A0@venus.vincentjardin.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am wondering howto support non passive FTP sessions with IPFW or IP6FW. It looks that IPFilter supports this feature, but what's about the regular FreeBSD Firewall ? I would prefer to use ipfw because I do not want to change my IPFW rules. Thanks, Vincent To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 5:46:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8C2E37B401; Fri, 20 Sep 2002 05:46:56 -0700 (PDT) Received: from hotmail.com (f94.law9.hotmail.com [64.4.9.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18AED43E75; Fri, 20 Sep 2002 05:46:56 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 20 Sep 2002 05:46:55 -0700 Received: from 80.75.12.38 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 20 Sep 2002 12:46:55 GMT X-Originating-IP: [80.75.12.38] From: "soheil h" To: freebsd-net@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Subject: VTUN PING TIME Date: Fri, 20 Sep 2002 17:16:55 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Sep 2002 12:46:55.0935 (UTC) FILETIME=[CD4174F0:01C260A3] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi list I have several vtun sessions about 40 sessions on one server It works nice till now but it's about 3 days that the ping time goes up to 3000 ms over the tunnel (while the ping time not over the tunnel is 650 ms ) the type is TUN with lzo:5 and proto udp !!!! i omit the compression and change the proto but it doesn't work . the ping times are like this 650 ms 650 ms 650 ms 650 ms 650 ms 1200 ms 3000 ms ..... 650 ms I want to know what is this ???????????? my boxes are freebsd. thanx _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 8:46: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9751437B401; Fri, 20 Sep 2002 08:45:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id F234743E3B; Fri, 20 Sep 2002 08:45:57 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (w81zldwdrouhv7er@nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g8KFjuC01343; Fri, 20 Sep 2002 08:45:56 -0700 (PDT) Message-ID: <3D8B42B3.9050109@isi.edu> Date: Fri, 20 Sep 2002 08:45:55 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: soheil h Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: VTUN PING TIME References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080400090405080106010201" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms080400090405080106010201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit soheil h wrote: > Hi list > I have several vtun sessions about 40 sessions on one server > It works nice till now but it's about 3 days that the ping time goes up > to 3000 ms over the tunnel (while the ping time not over the tunnel is > 650 ms ) ... Since the ping time over the base network doesn't change, you may want to ask this on the vtun mailing list, too: http://vtun.sourceforge.net/ What's the load on the box when the ping times go up? Vtun is userland. I'd also try not compressing, it doesn't save much. Lars -- Lars Eggert USC Information Sciences Institute --------------ms080400090405080106010201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9 VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR 1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/ r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAyMDkyMDE1NDU1NlowIwYJKoZIhvcNAQkEMRYEFKAmfIj1oA7vhtQcs7e5 7n4neFeUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAIrRXdbysGXc9ECYI1YIRuTRgeijHKRmGd3lpm76ONqdXmIbSQF+U ehyGu4cXXv0G+C38EOX06MLvCbAz8mSs7aX3XxPFedkSvuXnyXF9WIddE4na8y/m6YluWI6l Qnm9zK12Re1NfgihDE15fFro48UjJ8NZfWw/DtfrnYB3CGX0N1cza3spB03iW0jdgGnfkSjU brqkSuehvwZZI5ZMJwkvbdyiIoeYQsAdkwETBUwKY1uk6PlV0POQasXmEL2uGl9Wcb3dW82O zMQNCRWg7+G4E2bUDp9gBleNjB0/YbmEsIqtnFRfoFhW2CKgvFVb5owneRBbiAkwZ0z9JIrf iwAAAAAAAA== --------------ms080400090405080106010201-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 10:20:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2420537B401 for ; Fri, 20 Sep 2002 10:20:42 -0700 (PDT) Received: from mta.inode.at (mta.inode.at [213.229.60.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id B17F043E6A for ; Fri, 20 Sep 2002 10:20:40 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from smtp-01.inode.at ([62.99.194.3] helo=smtp.inode.at) by mta.inode.at with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.00) id 17sRWN-0002uS-00 for FreeBSD-net@freebsd.org; Fri, 20 Sep 2002 19:24:51 +0200 Received: from line-c-134.adsl-dynamic.inode.at ([62.99.151.134]:1049 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 17sRS6-0002RE-00; Fri, 20 Sep 2002 19:20:27 +0200 Message-ID: <3D8B5840.6050504@inode.at> Date: Fri, 20 Sep 2002 19:17:52 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: de-de, de-at, de, en-us, en MIME-Version: 1.0 To: Vincent Jardin , FreeBSD-net@freebsd.org Subject: Re: IP[6]FW and active FTP References: <20020920065206.C00921503A0@venus.vincentjardin.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, add to your natd.conf the punch_fw option bye, Vincent Jardin schrieb: > Hi, > > I am wondering howto support non passive FTP sessions with IPFW or IP6FW. It > looks that IPFilter supports this feature, but what's about the regular > FreeBSD Firewall ? > > I would prefer to use ipfw because I do not want to change my IPFW rules. > > Thanks, > Vincent > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > -- -- -------------------------------------- E-mail: Michael.Bretterklieber@jawa.at ---------------------------- JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at --------- privat ----------- E-mail: mbretter@inode.at homepage: http://www.inode.at/mbretter -------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 10:21:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 759F537B401 for ; Fri, 20 Sep 2002 10:21:56 -0700 (PDT) Received: from mta.inode.at (mta.inode.at [213.229.60.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C63043E3B for ; Fri, 20 Sep 2002 10:21:55 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from smtp-01.inode.at ([62.99.194.3] helo=smtp.inode.at) by mta.inode.at with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.00) id 17sRXa-00036k-00 for freebsd-net@FreeBSD.ORG; Fri, 20 Sep 2002 19:26:06 +0200 Received: from line-c-134.adsl-dynamic.inode.at ([62.99.151.134]:1050 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 17sRTK-0002St-00 for freebsd-net@FreeBSD.ORG; Fri, 20 Sep 2002 19:21:42 +0200 Message-ID: <3D8B588B.5080301@inode.at> Date: Fri, 20 Sep 2002 19:19:07 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: de-de, de-at, de, en-us, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Re: ppp client-callback References: <200209192119.g8JLJJLW062188@arch20m.dellroad.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, do you have the intention to implement this in the near future? bye, Archie Cobbs schrieb: > Michael Bretterklieber writes: > >>Does mpd support client-callback? > > > No, sorry. > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > -- -- -------------------------------------- E-mail: Michael.Bretterklieber@jawa.at ---------------------------- JAWA Management Software GmbH Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax: ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage: http://www.jawa.at --------- privat ----------- E-mail: mbretter@inode.at homepage: http://www.inode.at/mbretter -------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 18: 0:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7F1A37B408 for ; Fri, 20 Sep 2002 18:00:18 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C16A43E65 for ; Fri, 20 Sep 2002 18:00:18 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020921010016.TONW21615.rwcrmhc51.attbi.com@InterJet.elischer.org> for ; Sat, 21 Sep 2002 01:00:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA21823 for ; Fri, 20 Sep 2002 17:53:50 -0700 (PDT) Date: Fri, 20 Sep 2002 17:53:49 -0700 (PDT) From: Julian Elischer To: net@freebsd.org Subject: Tcp question. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org OK so I have 3 machines: A------router--------B-------router--------C if I send data from B to A I see 7MB/sec. if I send data from B to C I see 700KB/sec tcpdump shows some odd behaviour in the slow link: (tcpdump run from (B)) The initial negotiation appers as: 000000 DAL-DMZ-IFACE.916 > DAL-DMZ-HOST.ssh: S [tcp sum ok] 643471912:1643471912(0) win 16384 (DF) (ttl 64, id 5122, len 60) 000554 DAL-DMZ-HOST.ssh > DAL-DMZ-IFACE.916: S [tcp sum ok] 2813576059:2813576059(0) ack 1643471913 win 24624 (DF) (ttl 64, id 18212, len 60) 000496 DAL-DMZ-IFACE.916 > DAL-DMZ-HOST.ssh: . [tcp sum ok] ack 1 win 16416 (DF) (ttl 64, id 5123, len 52) 014218 DAL-DMZ-HOST.ssh > DAL-DMZ-IFACE.916: P [tcp sum ok] 1:29(28) ack 1 win 24624 (DF) (ttl 64, id 18213, len 80) snapsot once transfer has started shows: 003589 C.ssh > B.916: P 3725:3769(44) ack 60722 win 24624 nop,nop,timestamp 259781841 16260556> (DF) (ttl 64, id 18250, len 96) 001155 B.916 > C.ssh: . 60722:62090(1368) ack 3769 win 16416 nop,nop,timestamp 16260556 259781841> (DF) (ttl 64, id 5212, len 1420) 000014 B.916 > C.ssh: . 62090:63458(1368) ack 3769 win 16416 nop,nop,timestamp 16260556 259781841> (DF) (ttl 64, id 5213, len 1420) 000014 B.916 > C.ssh: . 63458:64826(1368) ack 3769 win 16416 nop,nop,timestamp 16260556 259781841> (DF) (ttl 64, id 5214, len 1420) 000012 B.916 > C.ssh: . 64826:66194(1368) ack 3769 win 16416 nop,nop,timestamp 16260556 259781841> (DF) (ttl 64, id 5215, len 1420) 000026 B.916 > C.ssh: . 66194:67562(1368) ack 3769 win 16416 nop,nop,timestamp 16260556 259781841> (DF) (ttl 64, id 5216, len 1420) 000014 B.916 > C.ssh: . 67562:68930(1368) ack 3769 win 16416 nop,nop,timestamp 16260556 259781841> (DF) (ttl 64, id 5217, len 1420) 000013 B.916 > C.ssh: . 68930:70298(1368) ack 3769 win 16416 nop,nop,timestamp 16260556 259781841> (DF) (ttl 64, id 5218, len 1420) 000765 C.ssh > B.916: . [tcp sum ok] ack 63458 win 24624 nop,nop,timestamp 259781842 16260556> (DF) (ttl 64, id 18251, len 52) 000221 C.ssh > B.916: . [tcp sum ok] ack 66194 win 24624 nop,nop,timestamp 259781842 16260556> (DF) (ttl 64, id 18252, len 52) **why wait here**? 003030 C.ssh > B.916: . [tcp sum ok] ack 68930 win 24624 nop,nop,timestamp 259781842 16260556> (DF) (ttl 64, id 18253, len 52) 000279 C.ssh > B.916: P 3769:3813(44) ack 70298 win 24624 nop,nop,timestamp 259781842 16260556> (DF) (ttl 64, id 18254, len 96) 000711 B.916 > C.ssh: P 70298:70810(512) ack 3813 win 16372 nop,nop,timestamp 16260557 259781842> (DF) (ttl 64, id 5219, len 564) My question is: "Why, when the acks have come back for upto offset 66194 does the sender not start sending more data.. I might also add that I don't see why it stopped doing so because the window is NOT full. Contrast this with the transfer from B to A (TEN times the throughput) initial setup packets: 000000 B.914 > A.ssh: S [tcp sum ok] 2201265429:2201265429(0) win 16384 (DF) (ttl 64, id 20682, len 60) 000359 A.ssh > B.914: S [tcp sum ok] 434721721:434721721(0) ack 2201265430 win 17376 (DF) (ttl 62, id 13590, len 60) 000048 B.914 > A.ssh: . [tcp sum ok] ack 1 win 17376 (DF) (ttl 64, id 20683, len 52) 002443 A.ssh > B.914: P 1:55(54) ack 1 win 17376 (DF) (ttl 62, id 13593, len 106) data once transfer is under way.. 000233 A.ssh > B.914: . [tcp sum ok] ack 185678 win 5256 (DF) [tos 0x8] (ttl 62, id 13716, len 52) 000240 A.ssh > B.914: . [tcp sum ok] ack 188574 win 2360 (DF) [tos 0x8] (ttl 62, id 13717, len 52) 000218 A.ssh > B.914: . [tcp sum ok] ack 190022 win 17296 (DF) [tos 0x8] (ttl 62, id 13718, len 52) 000069 B.914 > A.ssh: P 190022:191470(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20841, len 1500) 000654 B.914 > A.ssh: . 191470:192918(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20842, len 1500) 000022 B.914 > A.ssh: . 192918:194366(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20843, len 1500) 000021 B.914 > A.ssh: . 194366:195814(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20844, len 1500) 000012 B.914 > A.ssh: . 195814:197262(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20845, len 1500) 000021 B.914 > A.ssh: . 197262:198710(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20846, len 1500) 000024 B.914 > A.ssh: . 198710:200158(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20847, len 1500) 000012 B.914 > A.ssh: . 200158:201606(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20848, len 1500) 000021 B.914 > A.ssh: . 201606:203054(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20849, len 1500) 000023 B.914 > A.ssh: . 203054:204502(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20850, len 1500) 000019 B.914 > A.ssh: . 204502:205950(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20851, len 1500) 000640 A.ssh > B.914: . [tcp sum ok] ack 192918 win 14400 (DF) [tos 0x8] (ttl 62, id 13719, len 52) 000240 A.ssh > B.914: . [tcp sum ok] ack 195814 win 11504 (DF) [tos 0x8] (ttl 62, id 13720, len 52) 000227 A.ssh > B.914: . [tcp sum ok] ack 198710 win 8608 (DF) [tos 0x8] (ttl 62, id 13721, len 52) 000121 A.ssh > B.914: . [tcp sum ok] ack 200158 win 17376 (DF) [tos 0x8] (ttl 62, id 13722, len 52) 000021 B.914 > A.ssh: . 205950:207398(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20852, len 1500) 000011 B.914 > A.ssh: . 207398:208846(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20853, len 1500) 000012 B.914 > A.ssh: . 208846:210294(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20854, len 1500) 000013 B.914 > A.ssh: . 210294:211742(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20855, len 1500) 000029 B.914 > A.ssh: P 211742:213190(1448) ack 367 win 17376 (DF) [tos 0x8] (ttl 64, id 20856, len 1500) 000154 A.ssh > B.914: . [tcp sum ok] ack 203054 win 14480 (DF) [tos 0x8] (ttl 62, id 13723, len 52) This is FreeBSD 4.4 PLUS the following patch to tcp that came from 4.5. Index: sys/netinet/tcp_var.h =================================================================== RCS file: /build/cvs/freebsd/src/sys/netinet/tcp_var.h,v retrieving revision 1.56.2.8 diff -u -r1.56.2.8 tcp_var.h --- sys/netinet/tcp_var.h 22 Aug 2001 00:59:13 -0000 1.56.2.8 +++ sys/netinet/tcp_var.h 7 Mar 2002 18:40:18 -0000 @@ -95,6 +95,7 @@ #define TF_SENDCCNEW 0x08000 /* send CCnew instead of CC in SYN */ #define TF_MORETOCOME 0x10000 /* More data to be appended to sock */ #define TF_LQ_OVERFLOW 0x20000 /* listen queue overflow */ +#define TF_RXWIN0SENT 0x40000 /* sent a receiver win 0 in response */ int t_force; /* 1 if forcing out a byte */ tcp_seq snd_una; /* send unacknowledged */ Index: sys/kern/uipc_socket.c =================================================================== RCS file: /build/cvs/freebsd/src/sys/kern/uipc_socket.c,v retrieving revision 1.68.2.16 diff -u -r1.68.2.16 uipc_socket.c --- sys/kern/uipc_socket.c 14 Jun 2001 20:46:06 -0000 1.68.2.16 +++ sys/kern/uipc_socket.c 7 Mar 2002 18:37:50 -0000 @@ -910,6 +910,14 @@ !sosendallatonce(so) && !nextrecord) { if (so->so_error || so->so_state & SS_CANTRCVMORE) break; + /* + * The window might have closed to zero, make + * sure we send an ack now that we've drained + * the buffer or we might end up blocking until + * the idle takes over (5 seconds). + */ + if (pr->pr_flags & PR_WANTRCVD && so->so_pcb) + (*pr->pr_usrreqs->pru_rcvd)(so, flags); error = sbwait(&so->so_rcv); if (error) { sbunlock(&so->so_rcv); Index: sys/netinet/tcp_input.c =================================================================== RCS file: /build/cvs/freebsd/src/sys/netinet/tcp_input.c,v retrieving revision 1.107.2.16 diff -u -r1.107.2.16 tcp_input.c --- sys/netinet/tcp_input.c 22 Aug 2001 00:59:12 -0000 1.107.2.16 +++ sys/netinet/tcp_input.c 7 Mar 2002 18:38:37 -0000 @@ -158,10 +158,15 @@ #endif /* - * Indicate whether this ack should be delayed. + * Indicate whether this ack should be delayed. We can delay the ack if + * - delayed acks are enabled and + * - there is no delayed ack timer in progress and + * - our last ack wasn't a 0-sized window. We never want to delay + * the ack that opens up a 0-sized window. */ #define DELAY_ACK(tp) \ - (tcp_delack_enabled && !callout_pending(tp->tt_delack)) + (tcp_delack_enabled && !callout_pending(tp->tt_delack) && \ + (tp->t_flags & TF_RXWIN0SENT) == 0) static int tcp_reass(tp, th, tlenp, m) @@ -840,7 +845,7 @@ #endif tp = intotcpcb(inp); tp->t_state = TCPS_LISTEN; - tp->t_flags |= tp0->t_flags & (TF_NOPUSH|TF_NOOPT); + tp->t_flags |= tp0->t_flags & (TF_NOPUSH|TF_NOOPT|TF_NODELAY); /* Compute proper scaling value from buffer space */ while (tp->request_r_scale < TCP_MAX_WINSHIFT && Index: sys/netinet/tcp_output.c =================================================================== RCS file: /build/cvs/freebsd/src/sys/netinet/tcp_output.c,v retrieving revision 1.39.2.10 diff -u -r1.39.2.10 tcp_output.c --- sys/netinet/tcp_output.c 7 Jul 2001 04:30:38 -0000 1.39.2.10 +++ sys/netinet/tcp_output.c 7 Mar 2002 18:45:18 -0000 @@ -116,7 +116,9 @@ u_char opt[TCP_MAXOLEN]; unsigned ipoptlen, optlen, hdrlen; int idle, sendalot; +#if 0 int maxburst = TCP_MAXBURST; +#endif struct rmxp_tao *taop; struct rmxp_tao tao_noncached; #ifdef INET6 @@ -268,28 +270,38 @@ win = sbspace(&so->so_rcv); /* - * Sender silly window avoidance. If connection is idle - * and can send all data, a maximum segment, - * at least a maximum default-size segment do it, - * or are forced, do it; otherwise don't bother. - * If peer's buffer is tiny, then send - * when window is at least half open. - * If retransmitting (possibly after persist timer forced us - * to send into a small window), then must resend. + * Sender silly window avoidance. We transmit under the following + * conditions when len is non-zero: + * + * - We have a full segment + * - This is the last buffer in a write()/send() and we are + * either idle or running NODELAY + * - we've timed out (e.g. persist timer) + * - we have more then 1/2 the maximum send window's worth of + * data (receiver may be limited the window size) + * - we need to retransmit */ if (len) { if (len == tp->t_maxseg) goto send; - if (!(tp->t_flags & TF_MORETOCOME) && - (idle || tp->t_flags & TF_NODELAY) && - (tp->t_flags & TF_NOPUSH) == 0 && - len + off >= so->so_snd.sb_cc) + /* + * NOTE! on localhost connections an 'ack' from the remote + * end may occur synchronously with the output and cause + * us to flush a buffer queued with moretocome. XXX + * + * note: the len + off check is almost certainly unnecessary. + */ + if (!(tp->t_flags & TF_MORETOCOME) && /* normal case */ + (idle || (tp->t_flags & TF_NODELAY)) && + len + off >= so->so_snd.sb_cc && + (tp->t_flags & TF_NOPUSH) == 0) { goto send; - if (tp->t_force) + } + if (tp->t_force) /* typ. timeout case */ goto send; if (len >= tp->max_sndwnd / 2 && tp->max_sndwnd > 0) goto send; - if (SEQ_LT(tp->snd_nxt, tp->snd_max)) + if (SEQ_LT(tp->snd_nxt, tp->snd_max)) /* retransmit case */ goto send; } @@ -688,6 +700,20 @@ if (win > (long)TCP_MAXWIN << tp->rcv_scale) win = (long)TCP_MAXWIN << tp->rcv_scale; th->th_win = htons((u_short) (win>>tp->rcv_scale)); + + /* + * Adjust the RXWIN0SENT flag - indicate that we have advertised + * a 0 window. This may cause the remote transmitter to stall. This + * flag tells soreceive() to disable delayed acknowledgements when + * draining the buffer. This can occur if the receiver is attempting + * to read more data then can be buffered prior to transmitting on + * the connection. + */ + if (win == 0) + tp->t_flags |= TF_RXWIN0SENT; + else + tp->t_flags &= ~TF_RXWIN0SENT; + if (SEQ_GT(tp->snd_up, tp->snd_nxt)) { th->th_urp = htons((u_short)(tp->snd_up - tp->snd_nxt)); th->th_flags |= TH_URG; @@ -912,7 +938,17 @@ tp->t_flags &= ~TF_ACKNOW; if (tcp_delack_enabled) callout_stop(tp->tt_delack); +#if 0 + /* + * This completely breaks TCP if newreno is turned on. What happens + * is that if delayed-acks are turned on on the receiver, this code + * on the transmitter effectively destroys the TCP window, forcing + * it to four packets (1.5Kx4 = 6K window). + */ if (sendalot && (!tcp_do_newreno || --maxburst)) + goto again; +#endif + if (sendalot) goto again; return (0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 18:52:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24CE237B401 for ; Fri, 20 Sep 2002 18:52:54 -0700 (PDT) Received: from out1.mx.nwbl.wi.voyager.net (out1.mx.nwbl.wi.voyager.net [169.207.3.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2FDF43E77 for ; Fri, 20 Sep 2002 18:52:53 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop2.nwbl.wi.voyager.net (pop2.nwbl.wi.voyager.net [169.207.3.115]) by out1.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id ADF5FE29D8; Fri, 20 Sep 2002 20:52:51 -0500 (CDT) Received: from [10.1.1.6] (d30.as29.nwbl0.wi.voyager.net [169.207.73.30]) by pop2.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g8L1qo124667; Fri, 20 Sep 2002 20:52:50 -0500 (CDT) Date: Fri, 20 Sep 2002 20:56:44 -0500 (CDT) From: Mike Silbersack To: Julian Elischer Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: Message-ID: <20020920204805.G6326-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 20 Sep 2002, Julian Elischer wrote: > OK so I have 3 machines: > > > A------router--------B-------router--------C > > > if I send data from B to A I see 7MB/sec. > if I send data from B to C I see 700KB/sec > > tcpdump shows some odd behaviour in the slow link: > (tcpdump run from (B)) Could you repost with more of the timestamp intact? It's really hard to read as is. > 000221 C.ssh > B.916: . [tcp sum ok] ack 66194 win 24624 > nop,nop,timestamp 259781842 16260556> (DF) > (ttl 64, id 18252, len 52) > **why wait here**? > 003030 C.ssh > B.916: . [tcp sum ok] ack 68930 win 24624 > nop,nop,timestamp 259781842 16260556> (DF) > (ttl 64, id 18253, len 52) > 000279 C.ssh > B.916: P 3769:3813(44) ack 70298 win 24624 > nop,nop,timestamp 259781842 16260556> (DF) > (ttl 64, id 18254, len 96) Hm, the TCP stack doesn't look like it thinks that it's waiting... the timestamps don't seem to be incrementing. Of course, since I can't see the timestamp, I don't know what waiting means. :) Have you tried disabling delayed acks just to be doubly sure that the delayed ack code isn't causing the problem somehow? Also, is C really a FreeBSD box? I didn't think we used window sizes of 24K. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 19:20:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6C7937B401 for ; Fri, 20 Sep 2002 19:20:10 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C66443E4A for ; Fri, 20 Sep 2002 19:20:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020921022009.ZRJI28420.sccrmhc03.attbi.com@InterJet.elischer.org>; Sat, 21 Sep 2002 02:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA22205; Fri, 20 Sep 2002 19:19:03 -0700 (PDT) Date: Fri, 20 Sep 2002 19:19:03 -0700 (PDT) From: Julian Elischer To: Mike Silbersack Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: <20020920204805.G6326-100000@patrocles.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org p.s. just for kicks I turned off newreno and set teh slowstart flightsize up.. net.inet.tcp.local_slowstart_flightsize: 65535 net.inet.tcp.newreno: 0 no real difference. On Fri, 20 Sep 2002, Mike Silbersack wrote: > > On Fri, 20 Sep 2002, Julian Elischer wrote: > > > OK so I have 3 machines: > > > > > > A------router--------B-------router--------C > > > > > > if I send data from B to A I see 7MB/sec. > > if I send data from B to C I see 700KB/sec > > > > tcpdump shows some odd behaviour in the slow link: > > (tcpdump run from (B)) > > Could you repost with more of the timestamp intact? It's really hard to > read as is. > > > 000221 C.ssh > B.916: . [tcp sum ok] ack 66194 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18252, len 52) > > **why wait here**? > > 003030 C.ssh > B.916: . [tcp sum ok] ack 68930 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18253, len 52) > > 000279 C.ssh > B.916: P 3769:3813(44) ack 70298 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18254, len 96) > > Hm, the TCP stack doesn't look like it thinks that it's waiting... the > timestamps don't seem to be incrementing. Of course, since I can't see > the timestamp, I don't know what waiting means. :) > > Have you tried disabling delayed acks just to be doubly sure that the > delayed ack code isn't causing the problem somehow? > > Also, is C really a FreeBSD box? I didn't think we used window sizes > of 24K. > > Mike "Silby" Silbersack > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 19:20:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3DBF37B401 for ; Fri, 20 Sep 2002 19:20:20 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6919A43E6E for ; Fri, 20 Sep 2002 19:20:20 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020921022019.ZRMZ28420.sccrmhc03.attbi.com@InterJet.elischer.org>; Sat, 21 Sep 2002 02:20:19 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA22132; Fri, 20 Sep 2002 19:01:24 -0700 (PDT) Date: Fri, 20 Sep 2002 19:01:23 -0700 (PDT) From: Julian Elischer To: Mike Silbersack Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: <20020920204805.G6326-100000@patrocles.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org the timestaps are intact. I'm using -ttt that is the usecs delta from the previous line On Fri, 20 Sep 2002, Mike Silbersack wrote: > > On Fri, 20 Sep 2002, Julian Elischer wrote: > > > OK so I have 3 machines: > > > > > > A------router--------B-------router--------C > > > > > > if I send data from B to A I see 7MB/sec. > > if I send data from B to C I see 700KB/sec > > > > tcpdump shows some odd behaviour in the slow link: > > (tcpdump run from (B)) > > Could you repost with more of the timestamp intact? It's really hard to > read as is. > > > 000221 C.ssh > B.916: . [tcp sum ok] ack 66194 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18252, len 52) > > **why wait here**? > > 003030 C.ssh > B.916: . [tcp sum ok] ack 68930 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18253, len 52) > > 000279 C.ssh > B.916: P 3769:3813(44) ack 70298 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18254, len 96) > > Hm, the TCP stack doesn't look like it thinks that it's waiting... the > timestamps don't seem to be incrementing. Of course, since I can't see > the timestamp, I don't know what waiting means. :) > > Have you tried disabling delayed acks just to be doubly sure that the > delayed ack code isn't causing the problem somehow? > > Also, is C really a FreeBSD box? I didn't think we used window sizes > of 24K. > > Mike "Silby" Silbersack > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 19:20:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00AF437B401 for ; Fri, 20 Sep 2002 19:20:33 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BEAE43E4A for ; Fri, 20 Sep 2002 19:20:31 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020921022030.ZRQA28420.sccrmhc03.attbi.com@InterJet.elischer.org>; Sat, 21 Sep 2002 02:20:30 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA22134; Fri, 20 Sep 2002 19:03:19 -0700 (PDT) Date: Fri, 20 Sep 2002 19:03:19 -0700 (PDT) From: Julian Elischer To: Mike Silbersack Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: <20020920204805.G6326-100000@patrocles.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 20 Sep 2002, Mike Silbersack wrote: > > On Fri, 20 Sep 2002, Julian Elischer wrote: > > > OK so I have 3 machines: > > > > > > A------router--------B-------router--------C > > > > > > if I send data from B to A I see 7MB/sec. > > if I send data from B to C I see 700KB/sec > > > > tcpdump shows some odd behaviour in the slow link: > > (tcpdump run from (B)) > > Could you repost with more of the timestamp intact? It's really hard to > read as is. > > > 000221 C.ssh > B.916: . [tcp sum ok] ack 66194 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18252, len 52) > > **why wait here**? > > 003030 C.ssh > B.916: . [tcp sum ok] ack 68930 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18253, len 52) > > 000279 C.ssh > B.916: P 3769:3813(44) ack 70298 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18254, len 96) > > Hm, the TCP stack doesn't look like it thinks that it's waiting... the > timestamps don't seem to be incrementing. Of course, since I can't see > the timestamp, I don't know what waiting means. :) > > Have you tried disabling delayed acks just to be doubly sure that the > delayed ack code isn't causing the problem somehow? um how do I do that on B? (I have no access to control C) B (the machine that appears to be waiting for no reason) is FBSD 4.4++ > > Also, is C really a FreeBSD box? I didn't think we used window sizes > of 24K. No C is Solaris A and B are FreeBSD 4.4+patch > > Mike "Silby" Silbersack > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 19:20:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0772237B401 for ; Fri, 20 Sep 2002 19:20:43 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8004E43E4A for ; Fri, 20 Sep 2002 19:20:42 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020921022041.ZRSY28420.sccrmhc03.attbi.com@InterJet.elischer.org>; Sat, 21 Sep 2002 02:20:41 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA22185; Fri, 20 Sep 2002 19:11:42 -0700 (PDT) Date: Fri, 20 Sep 2002 19:11:40 -0700 (PDT) From: Julian Elischer To: Mike Silbersack Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: <20020920204805.G6326-100000@patrocles.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 20 Sep 2002, Mike Silbersack wrote: > > On Fri, 20 Sep 2002, Julian Elischer wrote: > > > OK so I have 3 machines: > > > > > > A------router--------B-------router--------C > > > > > > if I send data from B to A I see 7MB/sec. > > if I send data from B to C I see 700KB/sec > > > > tcpdump shows some odd behaviour in the slow link: > > (tcpdump run from (B)) > > Could you repost with more of the timestamp intact? It's really hard to > read as is. > > > 000221 C.ssh > B.916: . [tcp sum ok] ack 66194 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18252, len 52) > > **why wait here**? My question is: Why doesn't 'B' send more data here? > > 003030 C.ssh > B.916: . [tcp sum ok] ack 68930 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18253, len 52) > > 000279 C.ssh > B.916: P 3769:3813(44) ack 70298 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18254, len 96) > > Hm, the TCP stack doesn't look like it thinks that it's waiting... the > timestamps don't seem to be incrementing. Of course, since I can't see > the timestamp, I don't know what waiting means. :) timestamps have too high granularity to figgure out why a connection is only getting 700KB/sec I want to know why there is a 3030 uSec gap (3 whole milisecs) and tcp on B doesn't send more data. If you look it has had 4 packets ack'd and it should respond.. maybe the problem is that the netisr hasn't run the tcp stack yet? The machine isn't really doing anything else except user-space work. > > Have you tried disabling delayed acks just to be doubly sure that the > delayed ack code isn't causing the problem somehow? > > Also, is C really a FreeBSD box? I didn't think we used window sizes > of 24K. > > Mike "Silby" Silbersack > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 19:30:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03AEF37B401 for ; Fri, 20 Sep 2002 19:30:48 -0700 (PDT) Received: from tp.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 657C843E77 for ; Fri, 20 Sep 2002 19:30:47 -0700 (PDT) (envelope-from barney@tp.databus.com) Received: from tp.databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.6/8.12.6) with ESMTP id g8L2Uhxr091309; Fri, 20 Sep 2002 22:30:43 -0400 (EDT) (envelope-from barney@tp.databus.com) Received: (from barney@localhost) by tp.databus.com (8.12.6/8.12.6/Submit) id g8L2UhRb091308; Fri, 20 Sep 2002 22:30:43 -0400 (EDT) (envelope-from barney) Date: Fri, 20 Sep 2002 22:30:43 -0400 From: Barney Wolff To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: Tcp question. Message-ID: <20020921023043.GA90973@tp.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I think you need to separate out tcp behavior from ssh behavior. A & C are clearly not the same tcp/ssh implementation, and I'm not even sure B is consistent between the two runs - for example, B's window size is different, as is the amount of data it sends before setting the P bit. With ssh doing compression & encryption, cpu power becomes visible at lan speeds. The 1380 mss from C may also indicate extra proto layers we're not seeing. And are you sure there's not a 10 mbit link somewhere between B and C? On Fri, Sep 20, 2002 at 05:53:49PM -0700, Julian Elischer wrote: > > OK so I have 3 machines: > > > A------router--------B-------router--------C > > > if I send data from B to A I see 7MB/sec. > if I send data from B to C I see 700KB/sec -- Barney Wolff I'm available by contract or FT: http://www.databus.com/bwresume.pdf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 20: 9:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEDF937B401 for ; Fri, 20 Sep 2002 20:09:16 -0700 (PDT) Received: from out0.mx.nwbl.wi.voyager.net (out0.mx.nwbl.wi.voyager.net [169.207.3.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1572443E77 for ; Fri, 20 Sep 2002 20:08:56 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop4.nwbl.wi.voyager.net (pop4.nwbl.wi.voyager.net [169.207.2.83]) by out0.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id F167684399; Fri, 20 Sep 2002 22:08:53 -0500 (CDT) Received: from [10.1.1.6] (d177.as9.nwbl0.wi.voyager.net [169.207.133.243]) by pop4.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g8L38qo86162; Fri, 20 Sep 2002 22:08:53 -0500 (CDT) Date: Fri, 20 Sep 2002 22:12:47 -0500 (CDT) From: Mike Silbersack To: Julian Elischer Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: Message-ID: <20020920220909.G6684-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 20 Sep 2002, Julian Elischer wrote: > > > > Also, is C really a FreeBSD box? I didn't think we used window sizes > > of 24K. > > No C is Solaris > A and B are FreeBSD 4.4+patch Ah, that explains it. Yeah, there was a thread about this on -stable in the last month. Solaris is deferring acks, which is seriously broken. You're going to need to fix this by turning off Solaris's deferred acks option. (Find the thread, it was talking about poor NFS performance or something.) Either that, or we're going to need to somehow redo our stack to account for Solaris... which I'm sure would cause problems with _everything_ else. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 20:11:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B983437B401 for ; Fri, 20 Sep 2002 20:11:12 -0700 (PDT) Received: from out2.mx.nwbl.wi.voyager.net (out2.mx.nwbl.wi.voyager.net [169.207.3.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CC3443E65 for ; Fri, 20 Sep 2002 20:11:12 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop4.nwbl.wi.voyager.net (pop4.nwbl.wi.voyager.net [169.207.2.83]) by out2.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 3D50728144; Fri, 20 Sep 2002 22:11:11 -0500 (CDT) Received: from [10.1.1.6] (d177.as9.nwbl0.wi.voyager.net [169.207.133.243]) by pop4.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g8L3BAo86706; Fri, 20 Sep 2002 22:11:10 -0500 (CDT) Date: Fri, 20 Sep 2002 22:15:05 -0500 (CDT) From: Mike Silbersack To: Julian Elischer Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: <20020920220909.G6684-100000@patrocles.silby.com> Message-ID: <20020920221449.B6684-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 20 Sep 2002, Mike Silbersack wrote: > On Fri, 20 Sep 2002, Julian Elischer wrote: > > > > > > > Also, is C really a FreeBSD box? I didn't think we used window sizes > > > of 24K. > > > > No C is Solaris > > A and B are FreeBSD 4.4+patch > > Ah, that explains it. Yeah, there was a thread about this on -stable in > the last month. Solaris is deferring acks, which is seriously broken. > You're going to need to fix this by turning off Solaris's deferred acks > option. (Find the thread, it was talking about poor NFS performance or > something.) > > Either that, or we're going to need to somehow redo our stack to account > for Solaris... which I'm sure would cause problems with _everything_ else. > > Mike "Silby" Silbersack Crap, ignore that, I misread the tcpdump. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 20:17:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD5C437B401 for ; Fri, 20 Sep 2002 20:17:09 -0700 (PDT) Received: from out1.mx.nwbl.wi.voyager.net (out1.mx.nwbl.wi.voyager.net [169.207.3.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8989E43E42 for ; Fri, 20 Sep 2002 20:17:09 -0700 (PDT) (envelope-from silby@silby.com) Received: from pop1.nwbl.wi.voyager.net (pop1.nwbl.wi.voyager.net [169.207.2.115]) by out1.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id 2C970E2926; Fri, 20 Sep 2002 22:17:09 -0500 (CDT) Received: from [10.1.1.6] (d177.as9.nwbl0.wi.voyager.net [169.207.133.243]) by pop1.nwbl.wi.voyager.net (8.10.2/8.10.2) with ESMTP id g8L3H8U86898; Fri, 20 Sep 2002 22:17:08 -0500 (CDT) Date: Fri, 20 Sep 2002 22:21:02 -0500 (CDT) From: Mike Silbersack To: Julian Elischer Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: Message-ID: <20020920221735.Q6684-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 20 Sep 2002, Julian Elischer wrote: > 000221 C.ssh > B.916: . [tcp sum ok] ack 66194 win 24624 > nop,nop,timestamp 259781842 16260556> (DF) > (ttl 64, id 18252, len 52) > **why wait here**? > 003030 C.ssh > B.916: . [tcp sum ok] ack 68930 win 24624 > nop,nop,timestamp 259781842 16260556> (DF) > (ttl 64, id 18253, len 52) Ok, I now have a more constructive reply. (Having reread with an understanding of the timestamps... I hadn't used -ttt before.) tcp_output.c rev 1.53 sounds like it may be applicable to this case: Add a flag TF_LASTIDLE, that forces a previously idle connection to send all its data, especially when the data is less than one MSS. This fixes an issue where the stack was delaying the sending of data, eventhough there was enough window to send all the data and the sending of data was emptying the socket buffer. Problem found by Yoshihiro Tsuchiya (tsuchiya@flab.fujitsu.co.jp) Submitted by: Jayanth Vijayaraghavan Apply that to host B and see if it helps. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 20:20:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41D1537B401 for ; Fri, 20 Sep 2002 20:20:09 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B03E243E65 for ; Fri, 20 Sep 2002 20:20:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020921032007.MVU14454.sccrmhc02.attbi.com@InterJet.elischer.org>; Sat, 21 Sep 2002 03:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA22422; Fri, 20 Sep 2002 20:06:50 -0700 (PDT) Date: Fri, 20 Sep 2002 20:06:49 -0700 (PDT) From: Julian Elischer To: Barney Wolff Cc: net@FreeBSD.ORG Subject: Re: Tcp question. In-Reply-To: <20020921023043.GA90973@tp.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 20 Sep 2002, Barney Wolff wrote: > I think you need to separate out tcp behavior from ssh behavior. > A & C are clearly not the same tcp/ssh implementation, and I'm > not even sure B is consistent between the two runs - for example, > B's window size is different, as is the amount of data it sends > before setting the P bit. The problem is not that the far end is slow to respond, but that B, the freebsd box, doesn't send more data immediatly when the ACKs arrive for data it's already sent. It waits around for another 3mSecs before sending more data. > > With ssh doing compression & encryption, cpu power becomes visible > at lan speeds. The 1380 mss from C may also indicate extra proto > layers we're not seeing. And are you sure there's not a 10 mbit > link somewhere between B and C? It's a 100Mb link on both sides of the Cisco PIX firewall between B and C The link that gets 7MB/sec goes through 2 routers including firewall, but they are FreeBSD boxes. > > On Fri, Sep 20, 2002 at 05:53:49PM -0700, Julian Elischer wrote: > > > > OK so I have 3 machines: > > > > > > A------router--------B-------router--------C > > > > > > if I send data from B to A I see 7MB/sec. > > if I send data from B to C I see 700KB/sec > > -- > Barney Wolff > I'm available by contract or FT: http://www.databus.com/bwresume.pdf > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 20 21: 0:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85F7D37B401 for ; Fri, 20 Sep 2002 21:00:16 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 378CE43E42 for ; Fri, 20 Sep 2002 21:00:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020921040012.CSRN464.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sat, 21 Sep 2002 04:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA22551; Fri, 20 Sep 2002 20:44:19 -0700 (PDT) Date: Fri, 20 Sep 2002 20:44:18 -0700 (PDT) From: Julian Elischer To: Mike Silbersack Cc: net@freebsd.org Subject: Re: Tcp question. In-Reply-To: <20020920221735.Q6684-100000@patrocles.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 20 Sep 2002, Mike Silbersack wrote: > > On Fri, 20 Sep 2002, Julian Elischer wrote: > > > 000221 C.ssh > B.916: . [tcp sum ok] ack 66194 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18252, len 52) > > **why wait here**? > > 003030 C.ssh > B.916: . [tcp sum ok] ack 68930 win 24624 > > nop,nop,timestamp 259781842 16260556> (DF) > > (ttl 64, id 18253, len 52) > > Ok, I now have a more constructive reply. (Having reread with an > understanding of the timestamps... I hadn't used -ttt before.) > > tcp_output.c rev 1.53 sounds like it may be applicable to this case: > > Add a flag TF_LASTIDLE, that forces a previously idle connection > to send all its data, especially when the data is less than one MSS. > This fixes an issue where the stack was delaying the sending > of data, eventhough there was enough window to send all the data and > the sending of data was emptying the socket buffer. > > Problem found by Yoshihiro Tsuchiya (tsuchiya@flab.fujitsu.co.jp) > > Submitted by: Jayanth Vijayaraghavan > > Apply that to host B and see if it helps. Wow.. that certainly sounds liek it might apply.. (though why it wasn't a problem with the othe rsession I don't know.) l'll try that for certain > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 21 2: 3:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD7EF37B401 for ; Sat, 21 Sep 2002 02:03:36 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8512143E6A for ; Sat, 21 Sep 2002 02:03:35 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (localhost.he.iki.fi [127.0.0.1]) by silver.he.iki.fi (8.12.5/8.11.4) with ESMTP id g8L93V0x098624 for ; Sat, 21 Sep 2002 12:03:33 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <3D8C35E2.803199B3@he.iki.fi> Date: Sat, 21 Sep 2002 12:03:30 +0300 From: Petri Helenius X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.6-STABLE i386) X-Accept-Language: en,fi MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: pcap & bpf Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org (I'm sending a copy here since I'm running this on FreeBSD and got no reply so far from the tcpdump folks) Function pcap_open_live in pcap-bpf.c contains the code snippet below. To me, this does not make too much sense, because: - if v is too big to be accommodated (either by configuration or resources, BIOCSBLEN will fail. However the code ignores the return code - it then proceeds to BIOCSETIF which will succeed either with the bufsize of 32768 or whatever is default in the OS. Suggestions: - Do not touch the buffer size (at least without giving the option to specify the size) - If some operating systems really need touching the buffersize, do BIOCGBLEN first to figure out what you got and in any case don't make the bufsize smaller than it was (reason: doing highspeed capture with 32k buffer is futile) I staticly linked with patched library with large buffers and it works happily, before that the system dropped a few thousand packets a minute. Pete /* * Try finding a good size for the buffer; 32768 may be too * big, so keep cutting it in half until we find a size * that works, or run out of sizes to try. * * XXX - there should be a user-accessible hook to set the * initial buffer size. */ for (v = 32768; v != 0; v >>= 1) { /* Ignore the return value - this is because the call fails * on BPF systems that don't have kernel malloc. And if * the call fails, it's no big deal, we just continue to * use the standard buffer size. */ (void) ioctl(fd, BIOCSBLEN, (caddr_t)&v); (void)strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name)); if (ioctl(fd, BIOCSETIF, (caddr_t)&ifr) >= 0) break; /* that size worked; we're done */ if (errno != ENOBUFS) { snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCSETIF: %s: %s", device, pcap_strerror(errno)); goto bad; } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 21 4:52:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A33337B401 for ; Sat, 21 Sep 2002 04:52:51 -0700 (PDT) Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C7F343E75 for ; Sat, 21 Sep 2002 04:52:51 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id 6DB3915E47; Sat, 21 Sep 2002 07:52:45 -0400 (EDT) Date: Sat, 21 Sep 2002 07:52:45 -0400 From: Richard A Steenbergen To: Petri Helenius Cc: freebsd-net@freebsd.org Subject: Re: pcap & bpf Message-ID: <20020921115245.GA1123@overlord.e-gerbil.net> References: <3D8C35E2.803199B3@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8C35E2.803199B3@he.iki.fi> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Sep 21, 2002 at 12:03:30PM +0300, Petri Helenius wrote: > (I'm sending a copy here since I'm running this on FreeBSD and got > no reply so far from the tcpdump folks) > > Function pcap_open_live in pcap-bpf.c contains the code snippet below. > > To me, this does not make too much sense, because: > - if v is too big to be accommodated (either by configuration or > resources, BIOCSBLEN will fail. However the code ignores the return > code Read the comments and the rest of the code in the section you pasted. /* * Try finding a good size for the buffer; 32768 may be too * big, so keep cutting it in half until we find a size * that works, or run out of sizes to try. * * XXX - there should be a user-accessible hook to set the * initial buffer size. */ It couldn't get any blunter if they used a hammer. :) > - it then proceeds to BIOCSETIF which will succeed either with the > bufsize of 32768 or whatever is default in the OS. > > Suggestions: > - Do not touch the buffer size (at least without giving the option > to specify the size) debug.bpf_bufsize: 4096 debug.bpf_maxbufsize: 524288 32k is already a bump up from the default of 4k, which at the time that was set (and hard coded) probably seemed "good enough". Obviously as interfaces have gotten faster, that number has become out of date. Yes they SHOULD make it pcap-user tunable, the comment even says so, but until they do... Well it should be really really simple to add a hook for changing it, if you wanted to try submitting it to the pcap folks. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 21 10:29: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A105737B401 for ; Sat, 21 Sep 2002 10:29:06 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C3D843E65 for ; Sat, 21 Sep 2002 10:29:05 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PHE (silver.he.iki.fi [193.64.42.241]) by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g8LHStUW001161; Sat, 21 Sep 2002 20:29:02 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <000f01c26194$5d528b60$8c2a40c1@PHE> From: "Petri Helenius" To: "Richard A Steenbergen" Cc: References: <3D8C35E2.803199B3@he.iki.fi> <20020921115245.GA1123@overlord.e-gerbil.net> Subject: Re: pcap & bpf Date: Sat, 21 Sep 2002 20:28:55 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > 32k is already a bump up from the default of 4k, which at the time that > was set (and hard coded) probably seemed "good enough". Obviously as > interfaces have gotten faster, that number has become out of date. Yes > they SHOULD make it pcap-user tunable, the comment even says so, but until > they do... Well it should be really really simple to add a hook for > changing it, if you wanted to try submitting it to the pcap folks. :) > My hope was that (since I didn´t get a reply from the pcap folks) that this could be fixed in the FreeBSD repository, since that´s the only platform I care about :-) Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 21 13:17:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1DAA37B401 for ; Sat, 21 Sep 2002 13:17:08 -0700 (PDT) Received: from web14207.mail.yahoo.com (web14207.mail.yahoo.com [216.136.173.71]) by mx1.FreeBSD.org (Postfix) with SMTP id B51AB43E42 for ; Sat, 21 Sep 2002 13:17:08 -0700 (PDT) (envelope-from neelnatu@yahoo.com) Message-ID: <20020921201708.69253.qmail@web14207.mail.yahoo.com> Received: from [66.171.82.5] by web14207.mail.yahoo.com via HTTP; Sat, 21 Sep 2002 13:17:08 PDT Date: Sat, 21 Sep 2002 13:17:08 -0700 (PDT) From: Neelkanth Natu Subject: Re: pcap & bpf To: Petri Helenius , freebsd-net@freebsd.org In-Reply-To: <3D8C35E2.803199B3@he.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, --- Petri Helenius wrote: > (I'm sending a copy here since I'm running this on FreeBSD and got > no reply so far from the tcpdump folks) > > Function pcap_open_live in pcap-bpf.c contains the code snippet below. > > To me, this does not make too much sense, because: > - if v is too big to be accommodated (either by configuration or > resources, BIOCSBLEN will fail. However the code ignores the return > code BIOCSBLEN can fail only if the the bpf is already attached to an interface. Otherwise the code sandwiches the requested value of bufsize between bpf_maxbufsize and BPF_MINBUFSIZE. So there is no way this could really "fail". > - it then proceeds to BIOCSETIF which will succeed either with the > bufsize of 32768 or whatever is default in the OS. On the other hand it is possible for BIOCSETIF to fail in bpf_allocbufs(). And the pcap code does check for ENOBUFS. So what the code snippet is doing is entirely reasonably. Making the initial bufsize requested by pcap user-configurable, might be a solution to your problem. best Neel > > Suggestions: > - Do not touch the buffer size (at least without giving the option > to specify the size) > - If some operating systems really need touching the buffersize, > do BIOCGBLEN first to figure out what you got and in any case > don't make the bufsize smaller than it was > (reason: doing highspeed capture with 32k buffer is futile) > > I staticly linked with patched library with large buffers and > it works happily, before that the system dropped a few thousand > packets a minute. > > Pete > > > /* > * Try finding a good size for the buffer; 32768 may be too > * big, so keep cutting it in half until we find a size > * that works, or run out of sizes to try. > * > * XXX - there should be a user-accessible hook to set the > * initial buffer size. > */ > for (v = 32768; v != 0; v >>= 1) { > /* Ignore the return value - this is because the call fails > * on BPF systems that don't have kernel malloc. And if > * the call fails, it's no big deal, we just continue to > * use the standard buffer size. > */ > (void) ioctl(fd, BIOCSBLEN, (caddr_t)&v); > > (void)strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name)); > if (ioctl(fd, BIOCSETIF, (caddr_t)&ifr) >= 0) > break; /* that size worked; we're done */ > > if (errno != ENOBUFS) { > snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCSETIF: %s: %s", > device, pcap_strerror(errno)); > goto bad; > } > } > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 21 14:45:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89FD037B401 for ; Sat, 21 Sep 2002 14:45:14 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8DD443E77 for ; Sat, 21 Sep 2002 14:45:13 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA54557; Sat, 21 Sep 2002 14:34:36 -0700 (PDT) Received: from arch20m.dellroad.org (localhost [127.0.0.1]) by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g8LLXSrf073609; Sat, 21 Sep 2002 14:33:28 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g8LLXRR7073608; Sat, 21 Sep 2002 14:33:27 -0700 (PDT) From: Archie Cobbs Message-Id: <200209212133.g8LLXRR7073608@arch20m.dellroad.org> Subject: Re: ppp client-callback In-Reply-To: <3D8B588B.5080301@inode.at> "from Michael Bretterklieber at Sep 20, 2002 07:19:07 pm" To: Michael Bretterklieber Date: Sat, 21 Sep 2002 14:33:27 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Michael Bretterklieber writes: > do you have the intention to implement this in the near future? > > >>Does mpd support client-callback? > > > > No, sorry. No, sorry. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 21 18: 5:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B30B37B401 for ; Sat, 21 Sep 2002 18:05:43 -0700 (PDT) Received: from phalanx.trit.org (phalanx.trit.org [63.198.170.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB85C43E6A for ; Sat, 21 Sep 2002 18:05:42 -0700 (PDT) (envelope-from dima@trit.org) Received: from phalanx.trit.org (localhost [127.0.0.1]) by phalanx.trit.org (Postfix) with ESMTP id AB18ED576 for ; Sun, 22 Sep 2002 01:05:42 +0000 (UTC) To: net@freebsd.org Subject: Latency spike over VPN using SSH (delayed ack problem) Date: Sun, 22 Sep 2002 01:05:42 +0000 From: Dima Dorfman Message-Id: <20020922010542.AB18ED576@phalanx.trit.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a VPN setup where the client opens an SSH connection to the VPN router and runs "ppp -direct client-vpn" (i.e., I'm tunneling a PPP connection over SSH). My configuration looks very similar to the example of how to do this in share/examples/ppp/ppp.conf.sample. Now, there are three computers: C is the VPN client, R is the VPN router, and S is a server on the other side of the VPN. After establishing a VPN connection, if I SSH from C to S and run "ping C", the first response time will be ~190 ms more than it should be. Note that this *only* happens if I connected *from* C to S and *then* run ping; if I connect to S in another way and run ping, the latency spike isn't present (I'm not sure how or if this is relevant, but I thought I'd add it anyway). C and R are usually connected over 801.11b (wireless), but the symptoms are present regardless of how they're connected (I've tried fast ethernet and WAN (Internet)). Originally I suspected the "Secure" (CPU-intensive crypto) part of SSH and PPP compression, but neither of these helped; I turned off all PPP compression and replaced ssh with rsh, and the problem remained. Now, if I turned off delayed acks on C xor R, the latency spike drops to ~95 ms. If I turn it off on C *and* R, the latency spike disappears--hence the "delayed ack problem" part of the subject. Just for reference, here's what the symptom looks like *with* delayed acks: dima@SERVER% ping CLIENT PING CLIENT (192.168.4.193): 56 data bytes 64 bytes from 192.168.4.193: icmp_seq=0 ttl=63 time=193.025 ms 64 bytes from 192.168.4.193: icmp_seq=1 ttl=63 time=3.376 ms 64 bytes from 192.168.4.193: icmp_seq=2 ttl=63 time=3.420 ms 64 bytes from 192.168.4.193: icmp_seq=3 ttl=63 time=4.003 ms 64 bytes from 192.168.4.193: icmp_seq=4 ttl=63 time=5.393 ms ^C --- CLIENT ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.376/41.843/193.025/75.594 ms Note also that this isn't just for ICMP; the spike can occasionally be "felt" in interactive sessions. Now, my question is: Is this a known bug, and if it is, is there a fix? If someone wants tcpdumps, just let me know where (on which machine), on what (which interface--do you want to see the ICMP packets (inside the tunnel) or the SSH packets (outside the tunnel)), and when to run them. Thanks in advance, Dima. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 21 18:45:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF28637B401 for ; Sat, 21 Sep 2002 18:45:58 -0700 (PDT) Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EDD443E4A for ; Sat, 21 Sep 2002 18:45:58 -0700 (PDT) (envelope-from vince@oahu.WURLDLINK.NET) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id g8M1jtq28133 for ; Sat, 21 Sep 2002 15:45:55 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Sat, 21 Sep 2002 15:45:55 -1000 (HST) From: Vincent Poy To: FreeBSD-NET@FreeBSD.ORG Subject: Intel Gigabit NIC questions Message-ID: <20020921154534.I3782-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings everyone: I have a question on the Intel Gigabit NIC's. Other than price, is there any difference in performance (full wire speed) between the Pro/1000T and the Pro/1000MT. Thanks. Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message