From owner-freebsd-net Sun Oct 13 6:24: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 D8F1A37B401 for ; Sun, 13 Oct 2002 06:24:21 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4840543E75 for ; Sun, 13 Oct 2002 06:24:21 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9DDP1CK035991 for ; Sun, 13 Oct 2002 09:25:01 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9DDP1d3035987 for freebsd-net@freebsd.org; Sun, 13 Oct 2002 09:25:01 -0400 (EDT) Date: Sun, 13 Oct 2002 09:25:00 -0400 From: Craig Rodrigues To: freebsd-net@freebsd.org Subject: How to add bpf support to if_atmsubr.c? Message-ID: <20021013092500.A35284@attbi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline User-Agent: Mutt/1.2.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 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am on a -current system, using patches from Harti Brandt's Netgraph ATM work: http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/ I am trying to add bpf support to /src/sys/net/if_atmsubr.c so that I can use tcpdump when sending traffic over my ATM card. I've got things mostly working, but I think I'm using the wrong arguments in the bpfattach() call (I'm not familiar with bpf and just guessed, based on looking at files in the same directory). Here is the line I used: bpfattach(ifp, DLT_ATM_RFC1483, sizeof(u_int)); What should I really be using? I am attaching the patch I am using, which incorporates patches from Harti Brandt, and bpf fixes from me. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-if_atmsubr.c" --- if_atmsubr.c.orig Fri Jun 15 03:32:25 2001 +++ if_atmsubr.c Sun Oct 13 04:05:16 2002 @@ -57,6 +57,7 @@ #include #include +#include #include #include /* XXX: for ETHERTYPE_* */ #if defined(INET) || defined(INET6) @@ -66,6 +67,15 @@ #include #endif +void (*ng_atm_attach_p)(struct ifnet *); +void (*ng_atm_detach_p)(struct ifnet *); +int (*ng_atm_output_p)(struct ifnet *, struct mbuf **); +void (*ng_atm_input_p)(struct ifnet *, struct mbuf **, + struct atm_pseudohdr *, void *); +void (*ng_atm_input_orphan_p)(struct ifnet *, struct mbuf *, + struct atm_pseudohdr *, void *); +void (*ng_atm_message_p)(struct ifnet *, u_int32_t, u_int32_t); + #ifndef ETHERTYPE_IPV6 #define ETHERTYPE_IPV6 0x86dd #endif @@ -199,6 +209,16 @@ } } + if (ng_atm_output_p != NULL) { + if ((error = (*ng_atm_output_p)(ifp, &m)) != 0) { + if (m != NULL) + m_freem(m); + return (error); + } + if (m == NULL) + return (0); + } + /* * Queue message on interface, and start output if interface * not yet active. @@ -234,6 +254,16 @@ } ifp->if_ibytes += m->m_pkthdr.len; + if (ifp->if_bpf != NULL) { + bpf_mtap(ifp, m); + } + + if (ng_atm_input_p != NULL) { + (*ng_atm_input_p)(ifp, &m, ah, rxhand); + if (m == NULL) + return; + } + if (rxhand) { #ifdef NATM struct natmpcb *npcb = rxhand; @@ -244,9 +274,10 @@ inq = &natmintrq; m->m_pkthdr.rcvif = rxhand; /* XXX: overload */ #else +/* printf("atm_input: NATM detected but not configured in kernel\n"); - m_freem(m); - return; +*/ + goto dropit; #endif } else { /* @@ -287,7 +318,13 @@ break; #endif default: - m_freem(m); +#ifndef NATM + dropit: +#endif + if (ng_atm_input_orphan_p != NULL) + (*ng_atm_input_orphan_p)(ifp, m, ah, rxhand); + else + m_freem(m); return; } } @@ -330,4 +367,36 @@ break; } +} + +void +atm_ifdetach(ifp) + register struct ifnet *ifp; +{ + +} + +void +atm_ifattach1(struct ifnet *ifp) +{ + atm_ifattach(ifp); + bpfattach(ifp, DLT_ATM_RFC1483, sizeof(u_int)); + if(ng_atm_attach_p) + (*ng_atm_attach_p)(ifp); +} + +void +atm_ifdetach1(struct ifnet *ifp) +{ + if(ng_atm_detach_p) + (*ng_atm_detach_p)(ifp); + bpfdetach(ifp); + atm_ifdetach(ifp); +} + +void +atm_message(struct ifnet *ifp, u_int32_t msg, u_int32_t arg) +{ + if(ng_atm_message_p) + (*ng_atm_message_p)(ifp, msg, arg); } --LZvS9be/3tNcYl/X-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 13 11: 7:44 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 F3C7737B401 for ; Sun, 13 Oct 2002 11:07:42 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 6D0B343E6E for ; Sun, 13 Oct 2002 11:07:41 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: (qmail 15704 invoked from network); 13 Oct 2002 18:00:40 -0000 Received: from upnet-dialinpool-85.upnet.gr (HELO hades.hell.gr) (@150.140.128.169) by nic.upatras.gr with SMTP; 13 Oct 2002 18:00:40 -0000 Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.6/8.12.6) with ESMTP id g9DI7jaW011684; Sun, 13 Oct 2002 21:07:45 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by hades.hell.gr (8.12.6/8.12.6/Submit) id g9DHh97i011279; Sun, 13 Oct 2002 20:43:09 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 13 Oct 2002 20:43:08 +0300 From: Giorgos Keramidas To: soheil hassas yeganeh Cc: freebsd-net@FreeBSD.ORG Subject: Re: IP bad cksum (0!) Message-ID: <20021013174308.GD10829@hades.hell.gr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 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 2002-10-11 14:57, soheil hassas yeganeh wrote: > To recompute the checksum of the ip packets i wrote this lines in > the ip_input.c files : > > ip->ip_sum =0 ; > if(hlen == sizeof(struct ip)) > ip->ip_sum = in_cksum_hdr(ip); > else > ip->ip_sum = in_cksum(m,hlen); > > When i make a dump it says that it has bad cksum 0! > > 12:25:11.858759 62.217.112.165 > 66.201.71.98: icmp: echo reply (ttl 42, id 17879, len 84, bad cksum 0!) > > I don't know why this doesn't work ?????? Use diff(1) to show us exactly where those changes were made. Apart from a few stylistic bogons that the above fragment of source has, it's really impossible to understand why it fails without seeing exactly where the change was made. -- keramida@FreeBSD.org FreeBSD: The Power to Serve FreeBSD 5.0-CURRENT #12: Thu Oct 10 21:08:38 EEST 2002 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Oct 13 13:30:14 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 D6DDD37B401 for ; Sun, 13 Oct 2002 13:30:13 -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 4C16943E4A for ; Sun, 13 Oct 2002 13:30: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 NAA12265; Sun, 13 Oct 2002 13:24:35 -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 g9DKNFON074921; Sun, 13 Oct 2002 13:23:15 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9DKNF4C074920; Sun, 13 Oct 2002 13:23:15 -0700 (PDT) From: Archie Cobbs Message-Id: <200210132023.g9DKNF4C074920@arch20m.dellroad.org> Subject: Re: Comments Please In-Reply-To: <20021012.171809.93306957.imp@bsdimp.com> "from M. Warner Losh at Oct 12, 2002 05:18:09 pm" To: "M. Warner Losh" Date: Sun, 13 Oct 2002 13:23:15 -0700 (PDT) Cc: 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 M. Warner Losh writes: > > static int ether_resolvemulti(struct ifnet *, struct sockaddr **, > struct sockaddr *); > -u_char etherbroadcastaddr[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; > +u_char etherbroadcastaddr[ETHER_ADDR_LEN] = > + { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; 'etherbroadcastaddr' should really have type 'const u_char []' rather than 'u_char []'. -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 Sun Oct 13 22: 0: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 76A1637B401; Sun, 13 Oct 2002 22:00:36 -0700 (PDT) Received: from samwise.jobeus.net (samwise.jobeus.net [205.206.125.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 954C843EB2; Sun, 13 Oct 2002 22:00:35 -0700 (PDT) (envelope-from freebsd@jobeus.net) Received: (from root@localhost) by samwise.jobeus.net (8.12.6/8.12.3) id g9E50RwI095512; Sun, 13 Oct 2002 23:00:27 -0600 (MDT) (envelope-from freebsd@jobeus.net) Received: from localhost (freebsd@localhost [127.0.0.1]) by samwise.jobeus.net (8.12.6/8.12.3av) with ESMTP id g9E50QDo095504; Sun, 13 Oct 2002 23:00:26 -0600 (MDT) (envelope-from freebsd@jobeus.net) Date: Sun, 13 Oct 2002 23:00:26 -0600 (MDT) From: Scott Carmichael To: freebsd-net@freebsd.org, Subject: IP resolving Message-ID: <20021013225806.M95476-100000@samwise.jobeus.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 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 Can someone help me here? Is there a code change I can make somewhere? Please CC me on any replies, as I am not subscribed to -net or -hackers. Thanks, Scott ---------- Forwarded message ---------- Date: Fri, 11 Oct 2002 14:14:08 -0600 (MDT) From: Scott Carmichael To: freebsd-questions@FreeBSD.ORG Subject: IP resolving I would like to know two things... Why FreeBSD acts in the following way while OpenBSD does not, and if it's possible to fix this? It seems that if anyone connects to my FreeBSD server wish a hostname that does not match their IP, I get a console message about the mismatch, and then if they connect via rlogin or ssh, 'who', 'w', 'last', etc. all report that they are connected _from_ MY box, which they aren't. This is annoying for a few reasons... A. I don't know where people are connecting from, B. When I get a console message for every time a user connects to pop3 to check their email and they check it every 5 minutes, 24 hours a day, I miss good important messages, and C. It used to resolve to IPs instead of hostnames when this occurred when I ran OpenBSD last year. An example of what I mean about the 'unresolving IPs' is the following: At school, the Computer Science department runs a DNS server with two views, inside and outside. If you're off-campus, you can't resolve, say "zone34wb.cpsc.ucalgary.ca", but if you're on campus, this will resolve properly. When I connect to my computer at home from this computer, 'w' will instead report: 2:11PM up 1 day, 2:28, 1 user, load averages: 1.15, 1.06, 1.01 USER TTY FROM LOGIN@ IDLE WHAT jobe p0 samwise 1:53PM - w Where 'samwise' is the name of my computer. Temporarily, this is solvable by editing my /etc/hosts file to include all the Computers I know in the Computer Science department, but alas, it happens with other users as well that are on various ISPs around the country. Can I fix this? At least so that 'who' or 'w' will report the IP addresses instead of just giving up? And can I get rid of the console messages? Thanks a ton, Scott Carmichael http://jobeus.net/ 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 From owner-freebsd-net Mon Oct 14 0:10:24 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 914DC37B401 for ; Mon, 14 Oct 2002 00:10:23 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7791643E9E for ; Mon, 14 Oct 2002 00:10:22 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g9E7A4e25099; Mon, 14 Oct 2002 09:10:04 +0200 (MEST) Date: Mon, 14 Oct 2002 09:10:04 +0200 (CEST) From: Harti Brandt To: Luigi Rizzo Cc: "M. Warner Losh" , Subject: Re: Comments Please In-Reply-To: <20021012191709.B93684@carp.icir.org> Message-ID: <20021014090528.V19145-100000@beagle.fokus.gmd.de> 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 Sat, 12 Oct 2002, Luigi Rizzo wrote: LR>On Sat, Oct 12, 2002 at 08:07:47PM -0600, M. Warner Losh wrote: LR>... LR>> : reveals the use of an explicit constant (6) in net/if_arp.h and LR>> : netinet/if_ether.c; there is more of the same in net/bridge.c LR>> : (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c LR>> LR>> atmsubr? Doesn't ATM have its own constants? LR> LR>eh, that's the problem with explicit constants, you can never tell LR>whether "6" is english, german or italian... in any case the LR>relevant piece of code is: LR> LR> net/if_atmsubr.c: if (bcmp(alc, ATMLLC_HDR, 6)) { LR> LR>I have no idea if it has any relation with ethernet header sizes. No, this is the length of an LLC/SNAP header minus the type field. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 0:26: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 7F4D837B401 for ; Mon, 14 Oct 2002 00:26:34 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89C3043EAC for ; Mon, 14 Oct 2002 00:26:33 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g9E7QRe26753; Mon, 14 Oct 2002 09:26:27 +0200 (MEST) Date: Mon, 14 Oct 2002 09:26:27 +0200 (CEST) From: Harti Brandt To: Craig Rodrigues Cc: freebsd-net@FreeBSD.ORG Subject: Re: How to add bpf support to if_atmsubr.c? In-Reply-To: <20021013092500.A35284@attbi.com> Message-ID: <20021014092010.S19145-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20021014092010.B19145@beagle.fokus.gmd.de> Content-Disposition: INLINE 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 Sun, 13 Oct 2002, Craig Rodrigues wrote: CR>Hi, CR> CR>I am on a -current system, using patches from Harti Brandt's CR>Netgraph ATM work: CR>http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/ CR> CR>I am trying to add bpf support to /src/sys/net/if_atmsubr.c so that CR>I can use tcpdump when sending traffic over my ATM card. CR> CR>I've got things mostly working, but I think I'm using the CR>wrong arguments in the bpfattach() call (I'm not familiar with CR>bpf and just guessed, based on looking at files in the same directory). CR> CR>Here is the line I used: CR>bpfattach(ifp, DLT_ATM_RFC1483, sizeof(u_int)); CR> CR>What should I really be using? CR> CR>I am attaching the patch I am using, which incorporates CR>patches from Harti Brandt, and bpf fixes from me. You my look at dev/en. In revision 1.7 of if_atmsub.c bpf support was moved from the generic file to the ENI driver ('as it should be'????). Maybe its time to move it back. The problem is, that at attach time you don't know what link-level encapsulation is used, because this can be select when you establish the VCC (via the parameter 'z' (see en(4))). So BPF_DLC_RFC1483 will not work without LLC/SNAP encapsulation. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 2: 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 CB44337B401 for ; Mon, 14 Oct 2002 02:00:08 -0700 (PDT) Received: from chung.yikes.com (dsl-65-184-72-125.telocity.com [65.184.72.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 631E743EB2 for ; Mon, 14 Oct 2002 02:00:07 -0700 (PDT) (envelope-from leonardc@cs.berkeley.edu) Received: from feather (12-232-222-255.client.attbi.com [12.232.222.255]) by chung.yikes.com (8.12.3/8.11.6) with SMTP id g9E900ds028615 for ; Mon, 14 Oct 2002 02:00:02 -0700 (PDT) (envelope-from leonardc@cs.berkeley.edu) From: "Leonard Chung" To: Subject: MPD PPTP tunneling intermittantly fails Date: Mon, 14 Oct 2002 01:59:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20021012182849.X24791-100000@chung.yikes.com> 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 I'm trying to get MPD working reliably, but I've been having strange problems with it. I've gone through the mailing list archives, Google, and even copied Julian's MPD config files that he posted on the mailing list a while back with no success. The problem that I'm having is that MPD starts properly and I can successfully connect to the service using Windows clients. However, when I ping internal hosts, the first five or so work fine, and then beyond that packets start getting lost, with a loss rate of around 50%. These tests are run over a local network with two subnets, so packet loss shouldn't be a problem. So although I can currently connect and create a tunnel, it isn't very useful as beyond any initial DNS queries, file transfers, etc. fail completely. Also, is there any way to get DHCP to work with MPD rather than hard wire IPs directly into MPD's config files? I'm guessing this is probably just something easy that I'm missing. My config files and an MPD trace are below. Thanks, Leonard multipptp: load client1 load client2 load client3 load client4 client1: new -i ng0 pptp1 pptp1 set ipcp ranges 10.0.0.1/32 10.0.2.1/24 load client_standard client2: new -i ng1 pptp2 pptp2 set ipcp ranges 10.0.0.1/32 10.0.2.2/24 load client_standard client3: new -i ng2 pptp3 pptp3 set ipcp ranges 10.0.0.1/32 10.0.2.3/24 load client_standard client4: new -i ng3 pptp4 pptp4 set ipcp ranges 10.0.0.1/32 10.0.2.4/24 load client_standard client_standard: set iface disable on-demand set iface enable proxy-arp set iface idle 0 #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 10.0.0.1 set ipcp nbns 10.0.0.1 #set ipcp dns 192.168.1.3 #set ipcp nbns 192.168.1.4 set bundle enable compression set bundle yes crypt-reqd set ccp yes mppc #set ccp yes mpp-e40 set ccp no mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set pptp enable always-ack # # For our PPTP server # pptp1: set link type pptp #set pptp self 65.184.72.125 set pptp self 192.168.0.1 #set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate pptp2: set link type pptp #set pptp self 65.184.72.125 set pptp self 192.168.0.1 #set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate pptp3: set link type pptp #set pptp self 65.184.72.125 set pptp self 192.168.0.1 #set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate pptp4: set link type pptp #set pptp self 65.184.72.125 set pptp self 192.168.0.1 #set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate test1 "" 10.0.2.1 feather "" 10.0.2.2 sylvia "" 10.0.2.3 chung# ifconfig fxp0: flags=8943 mtu 1500 inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 inet6 fe80::2a0:c9ff:fe03:b454%fxp0 prefixlen 64 scopeid 0x1 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:a0:c9:03:b4:54 media: Ethernet autoselect (100baseTX ) status: active lp0: flags=8810 mtu 1500 ed0: flags=8843 mtu 1500 inet 65.184.72.125 netmask 0xfffffffc broadcast 65.184.72.127 inet6 fe80::280:adff:fe73:ebfe%ed0 prefixlen 64 scopeid 0x3 ether 00:80:ad:73:eb:fe lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 faith0: flags=8002 mtu 1500 chung# mpd Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 24745, version 3.9 (root@chung.yikes.com 20:13 11-Oct-2002) [pptp1] ppp node is "mpd24745-pptp1" mpd: local IP address for PPTP is 192.168.0.1 [pptp1] using interface ng0 [pptp2] ppp node is "mpd24745-pptp2" [pptp2] using interface ng1 [pptp3] ppp node is "mpd24745-pptp3" [pptp3] using interface ng2 [pptp4] ppp node is "mpd24745-pptp4" [pptp4] using interface ng3 [pptp4:pptp4] mpd: PPTP connection from 192.168.0.2:3068 pptp0: attached to connection with 192.168.0.2:3068 [pptp1] IFACE: Open event [pptp1] IPCP: Open event [pptp1] IPCP: state change Initial --> Starting [pptp1] IPCP: LayerStart [pptp1] IPCP: Open event [pptp1] bundle: OPEN event in state CLOSED [pptp1] opening link "pptp1"... [pptp1] link: OPEN event [pptp1] LCP: Open event [pptp1] LCP: state change Initial --> Starting [pptp1] LCP: LayerStart [pptp1] device: OPEN event in state DOWN [pptp1] attaching to peer's outgoing call [pptp1] device is now in state OPENING [pptp1] device: UP event in state OPENING [pptp1] device is now in state UP [pptp1] link: UP event [pptp1] link: origination is remote [pptp1] LCP: Up event [pptp1] LCP: state change Starting --> Req-Sent [pptp1] LCP: phase shift DEAD --> ESTABLISH [pptp1] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2f3117ec AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 00 a0 c9 03 b4 54 pptp0-0: ignoring SetLinkInfo [pptp1] LCP: rec'd Configure Request #0 link 0 (Req-Sent) MRU 1400 MAGICNUM 5aaa4632 PROTOCOMP ACFCOMP CALLBACK Not supported [pptp1] LCP: SendConfigRej #0 CALLBACK [pptp1] rec'd unknown ctrl message, cookie=942710669 cmd=4 [pptp1] LCP: rec'd Configure Request #1 link 0 (Req-Sent) MRU 1400 MAGICNUM 5aaa4632 PROTOCOMP ACFCOMP [pptp1] LCP: SendConfigAck #1 MRU 1400 MAGICNUM 5aaa4632 PROTOCOMP ACFCOMP [pptp1] LCP: state change Req-Sent --> Ack-Sent [pptp1] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2f3117ec AUTHPROTO CHAP MSOFTv2 MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 00 a0 c9 03 b4 54 [pptp1] LCP: rec'd Configure Reject #2 link 0 (Ack-Sent) MP MRRU 1600 MP SHORTSEQ ENDPOINTDISC [802.1] 00 a0 c9 03 b4 54 [pptp1] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2f3117ec AUTHPROTO CHAP MSOFTv2 [pptp1] LCP: rec'd Configure Ack #3 link 0 (Ack-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM 2f3117ec AUTHPROTO CHAP MSOFTv2 [pptp1] LCP: state change Ack-Sent --> Opened [pptp1] LCP: phase shift ESTABLISH --> AUTHENTICATE [pptp1] LCP: auth: peer wants nothing, I want CHAP [pptp1] CHAP: sending CHALLENGE [pptp1] LCP: LayerUp [pptp1] LCP: rec'd Ident #2 link 0 (Opened) MESG: MSRASV5.10 pptp0-0: ignoring SetLinkInfo [pptp1] LCP: rec'd Ident #3 link 0 (Opened) MESG: MSRAS-1-FEATHER [pptp1] CHAP: rec'd RESPONSE #1 Name: "feather" Peer name: "feather" Response is valid [pptp1] CHAP: sending SUCCESS [pptp1] LCP: authorization successful [pptp1] LCP: phase shift AUTHENTICATE --> NETWORK mpd: ioctl(SIOCSIFMTU): Invalid argument [pptp1] up: 1 link, total bandwidth 64000 bps [pptp1] IPCP: Up event [pptp1] IPCP: state change Starting --> Req-Sent [pptp1] IPCP: SendConfigReq #1 IPADDR 10.0.0.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [pptp1] CCP: Open event [pptp1] CCP: state change Initial --> Starting [pptp1] CCP: LayerStart [pptp1] CCP: Up event [pptp1] CCP: state change Starting --> Req-Sent [pptp1] CCP: SendConfigReq #1 MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: rec'd Configure Request #4 link 0 (Req-Sent) MPPC 0x010000e1: MPPC MPPE, 40 bit, 56 bit, 128 bit, stateless [pptp1] CCP: SendConfigNak #4 MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] IPCP: rec'd Configure Request #5 link 0 (Req-Sent) IPADDR 0.0.0.0 NAKing with 10.0.2.2 PRIDNS 0.0.0.0 NAKing with 10.0.0.1 PRINBNS 0.0.0.0 NAKing with 10.0.0.1 SECDNS 0.0.0.0 SECNBNS 0.0.0.0 [pptp1] IPCP: SendConfigRej #5 SECDNS 0.0.0.0 SECNBNS 0.0.0.0 [pptp1] IPCP: rec'd Configure Reject #1 link 0 (Req-Sent) COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [pptp1] IPCP: SendConfigReq #2 IPADDR 10.0.0.1 [pptp1] CCP: rec'd Configure Ack #1 link 0 (Req-Sent) MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: state change Req-Sent --> Ack-Rcvd [pptp1] CCP: rec'd Configure Request #6 link 0 (Ack-Rcvd) MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: SendConfigAck #6 MPPC 0x01000040: MPPE, 128 bit, stateless [pptp1] CCP: state change Ack-Rcvd --> Opened [pptp1] CCP: LayerUp Compress using: MPPE, 128 bit, stateless Decompress using: MPPE, 128 bit, stateless mpd: ioctl(SIOCSIFMTU): Invalid argument [pptp1] IPCP: rec'd Configure Request #7 link 0 (Req-Sent) IPADDR 0.0.0.0 NAKing with 10.0.2.2 PRIDNS 0.0.0.0 NAKing with 10.0.0.1 PRINBNS 0.0.0.0 NAKing with 10.0.0.1 [pptp1] IPCP: SendConfigNak #7 IPADDR 10.0.2.2 PRIDNS 10.0.0.1 PRINBNS 10.0.0.1 [pptp1] IPCP: rec'd Configure Ack #2 link 0 (Req-Sent) IPADDR 10.0.0.1 [pptp1] IPCP: state change Req-Sent --> Ack-Rcvd [pptp1] IPCP: rec'd Configure Request #8 link 0 (Ack-Rcvd) IPADDR 10.0.2.2 10.0.2.2 is OK PRIDNS 10.0.0.1 PRINBNS 10.0.0.1 [pptp1] IPCP: SendConfigAck #8 IPADDR 10.0.2.2 PRIDNS 10.0.0.1 PRINBNS 10.0.0.1 [pptp1] IPCP: state change Ack-Rcvd --> Opened [pptp1] IPCP: LayerUp 10.0.0.1 -> 10.0.2.2 [pptp1] IFACE: Up event [pptp1] exec: /sbin/ifconfig ng0 10.0.0.1 10.0.2.2 netmask 0xffffffff -link0 [pptp1] exec: /usr/sbin/arp -s 10.0.2.2 0:a0:c9:3:b4:54 pub [pptp1] IFACE: Up event ^Cmpd: caught fatal signal int mpd: fatal error, exiting [pptp1] IPCP: Down event [pptp1] IPCP: state change Opened --> Starting [pptp1] IPCP: LayerDown [pptp1] IFACE: Down event [pptp1] exec: /usr/sbin/arp -d 10.0.2.2 [pptp1] exec: /sbin/ifconfig ng0 down delete -link0 [pptp1] IFACE: Close event [pptp1] IPCP: Close event [pptp1] IPCP: state change Starting --> Initial [pptp1] IPCP: LayerFinish [pptp2] IPCP: Down event [pptp2] IFACE: Close event [pptp3] IPCP: Down event [pptp3] IFACE: Close event [pptp4] IPCP: Down event [pptp4] IFACE: Close event mpd: process 24745 terminated To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 3:25: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 9DB0137B401 for ; Mon, 14 Oct 2002 03:25:24 -0700 (PDT) Received: from office.LF.net (office.LF.net [212.9.190.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34F1943E8A for ; Mon, 14 Oct 2002 03:25:24 -0700 (PDT) (envelope-from krion@voodoo.oberon.net) Received: from voodoo.oberon.net ([212.118.165.100]) by office.LF.net with esmtp (Exim 4.04) id 1812PY-0006Xd-00 for freebsd-net@freebsd.org; Mon, 14 Oct 2002 12:25:20 +0200 Received: from krion by voodoo.oberon.net with local (Exim 4.10) id 1812Oy-000Dfq-00 for freebsd-net@freebsd.org; ÐÎ, 14 ÏËÔ 2002 12:24:44 +0200 Date: Mon, 14 Oct 2002 12:24:44 +0200 From: Kirill Ponomarew To: freebsd-net@freebsd.org Subject: delayed ACK Message-ID: <20021014102444.GA52491@krion> Mail-Followup-To: Kirill Ponomarew , freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Hi, is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with heavy network traffic ? -- MfG Kirill Nothing is ever so bad it can't be made worse by firing the coach. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 8:41:44 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 68B0737B401 for ; Mon, 14 Oct 2002 08:41:43 -0700 (PDT) Received: from csmail.commserv.ucsb.edu (cspdc.commserv.ucsb.edu [128.111.251.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A1D843EB2 for ; Mon, 14 Oct 2002 08:41:43 -0700 (PDT) (envelope-from steve@expertcity.com) Received: from expertcity.com ([68.6.35.15]) by csmail.commserv.ucsb.edu (Netscape Messaging Server 3.62) with ESMTP id 417; Mon, 14 Oct 2002 08:41:40 -0700 Message-ID: <3DAAE60E.3010708@expertcity.com> Date: Mon, 14 Oct 2002 08:43:10 -0700 From: Steve Francis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kirill Ponomarew Cc: freebsd-net@freebsd.org Subject: Re: delayed ACK References: <20021014102444.GA52491@krion> 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 Kirill Ponomarew wrote: > Hi, > > is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with > heavy network traffic ? > If you want to increase your network traffic for no particular reason, and increase load on your server, then yes. Otherwise no. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 11: 0: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 5918537B401 for ; Mon, 14 Oct 2002 11:00:47 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 294E543EAF for ; Mon, 14 Oct 2002 11:00:45 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 41005 invoked from network); 14 Oct 2002 17:57:42 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 14 Oct 2002 17:57:42 -0000 Message-ID: <3DAB0604.7E780B3B@pipeline.ch> Date: Mon, 14 Oct 2002 19:59:32 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-isp@freebsd.org Subject: Statistical Email Message Size Distribution 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 The first numbers of the Swiss Internet Analysis performed by Olivier Mueller and Daniel Graf are available. The whole study will be available in November 2002. Here is the statistical message size distribution of email messages observed in the analysis. These numbers are very important to find the right parameters for the filesystem the message store resides on. For example you have to tune the block size, fragment size and inode to block ratio to hold so many small files. We see that in total 49.3% of all messages are 4KB or smaller and that 80% are smaller than 16KB. 11% are between 17 and 64KB big. Almost 97% are smaller than 512KB. up to 2KB 23.53% up to 4KB 25.64% up to 8KB 18.43% up to 16KB 11.98% up to 32KB 5.78% up to 64KB 5.11% up to 128KB 2.83% up to 256KB 2.44% up to 512KB 1.50% up to 1MB 1.25% up to 10MB 1.47% more 10MB 0.0054% For these numbers 13.97 million messages flowing through the five largest Swiss ISPs in the first week of September 2002 have been analysed. So these numbers clearly apply to an ISP environment. -- Andre Oppermann To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 11:35: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 2F4A737B401 for ; Mon, 14 Oct 2002 11:35:45 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id F2C1343EAF for ; Mon, 14 Oct 2002 11:35:43 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 14 Oct 2002 19:35:42 +0100 (BST) To: freebsd-net@freebsd.org Subject: IP_SENDSRCADDR implementation Date: Mon, 14 Oct 2002 19:35:42 +0100 From: Ian Dowse Message-ID: <200210141935.aa83883@salmon.maths.tcd.ie> 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 It was discussed here some time ago that we should have an IP_SENDSRCADDR ancillary data type to match the IP_RECVDSTADDR socket option. This permits a server process binding to a wildcard UDP socket to select the IP address from which outgoing packets are sent on a per-datagram basis. When combined with IP_RECVDSTADDR, such server processes can guarantee to reply to a request using the same source IP address as the destination IP address of the request, without having to open one socket per server IP address. Thomas Moestl did an initial implementation of this feature, and the patch presented here is based on his work and some discussions that followed. One approach would be to add to mess in udp_output() where we temporarily block input and connect the wildcard-bound socket to the destination address while sending, and do something similar with binding the source address. The approach taken here was to instead separate each of in_pcbbind() and in_pcbconnect() into a *_setup() version of the function that only performs the port allocation (but does not change the PCB), and an outer wrapper with the original name that calls the *_setup() version and then commits the changes to the PCB. Now udp_output() can use the *_setup() versions to perform the port and address allocation, so it does not need the temporary connect() hack any more. The IP_SENDSRCADDR change consists of adding a control-message reading loop to udp_output(), and doing an in_pcbbind_setup() to determine what source address to use for the datagram. The patch is at: http://www.maths.tcd.ie/~iedowse/FreeBSD/sendsrcaddr.diff Unfortunately it is relatively extensive. I've been running it for about 4 months now, but that does not rule out the possibility of bugs and unintended side-effects. Any comments, reviews or suggestions welcome. Is this something that is useful enough to commit now, or should it be deferred until after 5.0? Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 12:28:44 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 C830137B401 for ; Mon, 14 Oct 2002 12:28:43 -0700 (PDT) Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 21C2043EBE for ; Mon, 14 Oct 2002 12:28:43 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 84168 invoked by uid 3193); 14 Oct 2002 19:28:37 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Oct 2002 19:28:37 -0000 Date: Mon, 14 Oct 2002 15:28:37 -0400 (EDT) From: Mike Silbersack X-X-Sender: silby@niwun.pair.com To: Ian Dowse Cc: freebsd-net@freebsd.org Subject: Re: IP_SENDSRCADDR implementation In-Reply-To: <200210141935.aa83883@salmon.maths.tcd.ie> 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 Mon, 14 Oct 2002, Ian Dowse wrote: > Unfortunately it is relatively extensive. I've been running it for > about 4 months now, but that does not rule out the possibility of > bugs and unintended side-effects. Any comments, reviews or suggestions > welcome. Is this something that is useful enough to commit now, or > should it be deferred until after 5.0? > > Ian I haven't looked at the implementation, but I think that it would be wise to include the patch before 5.0-release so that there's a clear cutoff where the feature became available. Have any patches been made to allow bind to use this feature yet? 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 Mon Oct 14 12:33:14 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 0B89E37B433; Mon, 14 Oct 2002 12:33:08 -0700 (PDT) Received: from maktoobchat.net (bareed3.maktoob.net [195.172.126.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69BF243EB7; Mon, 14 Oct 2002 12:33:05 -0700 (PDT) (envelope-from dmusa@maktoob.com) Received: from [195.172.126.106] (HELO maktoobchat.net) by maktoobchat.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 2201993; Mon, 14 Oct 2002 19:33:39 +0000 Received: from [195.172.126.113] (HELO webmail) by maktoobchat.net (CommuniGate Pro SMTP 3.4.7) with SMTP id 5081075; Mon, 14 Oct 2002 19:28:08 +0000 From: dmusa@maktoob.com (Dr.Dan Musa) To: dmusa@maktoob.com Subject: Business Proposal Comment: Maktoob By BOC X-Mailer: Maktoob 1.0 [Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt; YComp 5.0.2.5)] X-Originating-IP: [216.139.168.229] MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 7bit Date: Mon, 14 Oct 2002 19:28:08 +0000 Message-ID: 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 _________________________________________________________ Looking to be employed? We have an ocean of employers and employees waiting to be matched. Go to Maktoob Jobs NOW. http://www.maktoob.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 13:15:37 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 A300737B401 for ; Mon, 14 Oct 2002 13:15:36 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4276043EB2 for ; Mon, 14 Oct 2002 13:15:36 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4088 invoked from network); 14 Oct 2002 20:15:29 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Oct 2002 20:15:29 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id g9EKFBn5032068 for ; Mon, 14 Oct 2002 16:15:14 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 14 Oct 2002 16:15:12 -0400 (EDT) From: John Baldwin To: net@FreeBSD.org Subject: Rename of MSIZE kernel option.. 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 Would people be open to renaming the 'MSIZE' kernel option to something more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can break other places in the kernel. For example, ISA device ivars have an ivar for the size of a memory resource called 'MSIZE' and the kernel option causes breakage in src/sys/isa/isavar.h: ISA_ACCESSOR(msize, MSIZE, int) when ISA_ACCESSOR is properly defined via __BUS_ACCESSOR() rather than homerolling a private copy of __BUS_ACCESSOR(). For now I've fixed it to rename the ISA ivar to ISA_IVAR_MEMSIZE but MSIZE seems to be too generic a name for a kernel option and it would be nice to avoid this problem in the future. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 13:20: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 6D9C537B404; Mon, 14 Oct 2002 13:20:11 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9948743E9C; Mon, 14 Oct 2002 13:20:09 -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 <20021014202008.XZKJ24958.sccrmhc03.attbi.com@InterJet.elischer.org>; Mon, 14 Oct 2002 20:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA75356; Mon, 14 Oct 2002 13:18:31 -0700 (PDT) Date: Mon, 14 Oct 2002 13:18:30 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: net@FreeBSD.org Subject: Re: Rename of MSIZE kernel option.. In-Reply-To: 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 go for it.. On Mon, 14 Oct 2002, John Baldwin wrote: > Would people be open to renaming the 'MSIZE' kernel option to something > more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can > break other places in the kernel. For example, ISA device ivars have > an ivar for the size of a memory resource called 'MSIZE' and the kernel > option causes breakage in src/sys/isa/isavar.h: > > ISA_ACCESSOR(msize, MSIZE, int) > > when ISA_ACCESSOR is properly defined via __BUS_ACCESSOR() rather than > homerolling a private copy of __BUS_ACCESSOR(). For now I've fixed it > to rename the ISA ivar to ISA_IVAR_MEMSIZE but MSIZE seems to be too > generic a name for a kernel option and it would be nice to avoid this > problem in the future. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > 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 Oct 14 13:59: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 CA46D37B401 for ; Mon, 14 Oct 2002 13:59:11 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB1C843EA3 for ; Mon, 14 Oct 2002 13:59:10 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g9EKx3x08301; Mon, 14 Oct 2002 13:59:04 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id g9EKx0sY022550; Mon, 14 Oct 2002 13:59:00 -0700 (PDT) (envelope-from jdp) Date: Mon, 14 Oct 2002 13:59:00 -0700 (PDT) Message-Id: <200210142059.g9EKx0sY022550@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: hykim@cs.rice.edu Subject: Re: Tigon 3 bad checksums on TCP packets In-Reply-To: References: Organization: Polstra & Co., Seattle, WA 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 In article , Hyong-Youb Kim wrote: > > Thanks. I resolved the issue by forcing BGE_PCI_WRITE_BNDRY_16BYTES > in BGE_PCI_DMA_RW_CTL register. The linux driver apparently has a DMA test > code and sets this value depending on the test results. I have no clue as > to why this configuration messes up TCP receive packets and not UDP > packets. I notice that everybody who's reported this problem has an Athlon. I guess there must be a bad interaction with the Athlon chipsets. I don't know why you're seeing the problem only on TCP packets. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 14: 0:51 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 BF9B637B401 for ; Mon, 14 Oct 2002 14:00:50 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 061AA43EA3 for ; Mon, 14 Oct 2002 14:00:50 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g9EL0mx08322; Mon, 14 Oct 2002 14:00:48 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id g9EL0lnn022565; Mon, 14 Oct 2002 14:00:47 -0700 (PDT) (envelope-from jdp) Date: Mon, 14 Oct 2002 14:00:47 -0700 (PDT) Message-Id: <200210142100.g9EL0lnn022565@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: hykim@cs.rice.edu Subject: Re: Tigon 3 bad checksums on TCP packets In-Reply-To: References: Organization: Polstra & Co., Seattle, WA 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 In article , Hyong-Youb Kim wrote: > > BTW, setting BGE_PCI_WRITE_BNDRY_16BYTES limits receive throughput to > 540Mb/s. So it is not a solution. > I really like to find out what this config does. It works around a bug in the BCM570x chip, apparently. I noticed that the Linux driver only applies this workaround for 5700 and 5701 chips. If you want better performance you may have to wait until you can buy cards with the newer 5703 chips on them. Or, switch to a non-Athlon system. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 14:23: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 BEA2637B401; Mon, 14 Oct 2002 14:23:09 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D6643EAA; Mon, 14 Oct 2002 14:23:09 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA06015; Mon, 14 Oct 2002 17:23:08 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g9ELMcc54226; Mon, 14 Oct 2002 17:22:38 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15787.13726.246550.526201@grasshopper.cs.duke.edu> Date: Mon, 14 Oct 2002 17:22:38 -0400 (EDT) To: John Baldwin Cc: net@FreeBSD.org Subject: Re: Rename of MSIZE kernel option.. In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 John Baldwin writes: > Would people be open to renaming the 'MSIZE' kernel option to something > more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can No. MSIZE is a traditional BSDism. Everybody else still uses it. Even AIX and MacOS. I really don't like the idea of changing this. > break other places in the kernel. For example, ISA device ivars have > an ivar for the size of a memory resource called 'MSIZE' and the kernel > option causes breakage in src/sys/isa/isavar.h: > > ISA_ACCESSOR(msize, MSIZE, int) > > when ISA_ACCESSOR is properly defined via __BUS_ACCESSOR() rather than > homerolling a private copy of __BUS_ACCESSOR(). For now I've fixed it > to rename the ISA ivar to ISA_IVAR_MEMSIZE but MSIZE seems to be too > generic a name for a kernel option and it would be nice to avoid this > problem in the future. Renaming MSIZE to ISA_IVAR_MEMSIZE seems right to me. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 15: 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 0FAED37B404 for ; Mon, 14 Oct 2002 15:00:16 -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 2F95343EB2 for ; Mon, 14 Oct 2002 15:00:15 -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 OAA28294; Mon, 14 Oct 2002 14:45:26 -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 g9ELi3ON084596; Mon, 14 Oct 2002 14:44: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 g9ELi3AT084595; Mon, 14 Oct 2002 14:44:03 -0700 (PDT) From: Archie Cobbs Message-Id: <200210142144.g9ELi3AT084595@arch20m.dellroad.org> Subject: Re: MPD PPTP tunneling intermittantly fails In-Reply-To: "from Leonard Chung at Oct 14, 2002 01:59:58 am" To: Leonard Chung Date: Mon, 14 Oct 2002 14:44: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 Leonard Chung writes: > The problem that I'm having is that MPD starts properly and I can > successfully connect to the service using Windows clients. However, when I > ping internal hosts, the first five or so work fine, and then beyond that > packets start getting lost, with a loss rate of around 50%. These tests are > run over a local network with two subnets, so packet loss shouldn't be a > problem. So although I can currently connect and create a tunnel, it isn't > very useful as beyond any initial DNS queries, file transfers, etc. fail > completely. Are you using Mac OS X clients? If so, you may need the latest patch to ng_pptpgre(4) to work around a problem: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_pptpgre.c.diff?r1=1.25&r2=1.26 Otherwise, I haven't heard of anyone else having that particular problem.. See if you have errors reported by 'ngctl msg ng0:inet.ppp.link0 getstats' (replace 'ng0' with the appropriate inteface name). > Also, is there any way to get DHCP to work with MPD rather than hard wire > IPs directly into MPD's config files? Unfortunately not. > I'm guessing this is probably just something easy that I'm missing. My > config files and an MPD trace are below. These look reasonable. -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 Oct 14 17:46:36 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 42E5537B401 for ; Mon, 14 Oct 2002 17:46:35 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 1EAA543EAC for ; Mon, 14 Oct 2002 17:46:34 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Oct 2002 01:46:33 +0100 (BST) To: Mike Silbersack Cc: freebsd-net@freebsd.org Subject: Re: IP_SENDSRCADDR implementation In-Reply-To: Your message of "Mon, 14 Oct 2002 15:28:37 EDT." Date: Tue, 15 Oct 2002 01:46:31 +0100 From: Ian Dowse Message-ID: <200210150146.aa39010@salmon.maths.tcd.ie> 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 In message , Mike Silb ersack writes: > >I haven't looked at the implementation, but I think that it would be wise >to include the patch before 5.0-release so that there's a clear cutoff >where the feature became available. Ok - I'll see what the reaction here is first and then check with re@ before considering committing it. >Have any patches been made to allow >bind to use this feature yet? Bind as in named? No, I haven't looked into this, but it would be a very good candidate, as I think it would remove the issue of having to bind to new IP addresses while running as an unpriviledged user. The other thing that could be done here for improved compatibility is to implement the Linux IP_PKTINFO socket option and control message. Doing this should be fairly trivial once the IP_SENDSRCADDR code is in place. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 20:53:44 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 997B537B401; Mon, 14 Oct 2002 20:53:43 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C868443ECF; Mon, 14 Oct 2002 20:53:42 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g9F3uAI60012; Mon, 14 Oct 2002 23:56:10 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Mon, 14 Oct 2002 23:56:10 -0400 From: Bosko Milekic To: John Baldwin Cc: net@FreeBSD.org Subject: Re: Rename of MSIZE kernel option.. Message-ID: <20021014235610.A59973@unixdaemons.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jhb@FreeBSD.org on Mon, Oct 14, 2002 at 04:15:12PM -0400 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 Not that my opinion really holds much weight with you guys but for what it's worth, I think the change would be gratuitist. 1. MSIZE has been around forever. 2. The argument that sys/sys/mbuf.h should have MSIZE removed/changed because some other code may use it is fallacious. The "other code" should be careful not to use a constant that has been so named for the longest time I can recall. On Mon, Oct 14, 2002 at 04:15:12PM -0400, John Baldwin wrote: > Would people be open to renaming the 'MSIZE' kernel option to something > more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can > break other places in the kernel. For example, ISA device ivars have > an ivar for the size of a memory resource called 'MSIZE' and the kernel > option causes breakage in src/sys/isa/isavar.h: > > ISA_ACCESSOR(msize, MSIZE, int) > > when ISA_ACCESSOR is properly defined via __BUS_ACCESSOR() rather than > homerolling a private copy of __BUS_ACCESSOR(). For now I've fixed it > to rename the ISA ivar to ISA_IVAR_MEMSIZE but MSIZE seems to be too > generic a name for a kernel option and it would be nice to avoid this > problem in the future. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 21:12: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 021A837B404 for ; Mon, 14 Oct 2002 21:12:58 -0700 (PDT) Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.137.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01EE243E9E for ; Mon, 14 Oct 2002 21:12:57 -0700 (PDT) (envelope-from nicolas@cs.virginia.edu) Received: from arachnion.cs.Virginia.EDU (arachnion.cs.Virginia.EDU [128.143.136.20]) by ares.cs.Virginia.EDU (8.9.3+Sun/8.9.2/UVACS-2000040300) with ESMTP id AAA22191 for ; Tue, 15 Oct 2002 00:12:56 -0400 (EDT) Received: from localhost (nc2y@localhost) by arachnion.cs.Virginia.EDU (8.9.2/8.9.2) with ESMTP id AAA13140 for ; Tue, 15 Oct 2002 00:12:55 -0400 (EDT) X-Authentication-Warning: arachnion.cs.Virginia.EDU: nc2y owned process doing -bs Date: Tue, 15 Oct 2002 00:12:55 -0400 (EDT) From: Nicolas Christin X-X-Sender: nc2y@arachnion.cs.Virginia.EDU To: net@FreeBSD.ORG Subject: Re: Rename of MSIZE kernel option.. In-Reply-To: <15787.13726.246550.526201@grasshopper.cs.duke.edu> Message-ID: Organization: University of Virginia - CS Dept. 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 Note: I'm just a lurker here, but thought I'd give my 2 cents on this discussion as well. On Mon, 14 Oct 2002, Andrew Gallatin wrote: > > Would people be open to renaming the 'MSIZE' kernel option to something > > more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can > > No. > > MSIZE is a traditional BSDism. Everybody else still uses it. > Even AIX and MacOS. I really don't like the idea of changing this. True, but John is right, it's too generic a name. The argument "it's been forever so we can't change it" seems a bit fallacious to me: that's with that line of thinking that one ends up with breakages no one can figure out years down the road. You end up having to keep pieces of code no one really knows what they're doing anymore, but if you take them out, the whole thing crashes and burns. Not that I'm saying it would be the case for something as obvious as MSIZE, but still... > Renaming MSIZE to ISA_IVAR_MEMSIZE seems right to me. I agree. Don't use something like MSIZE at all. The name is not explicit enough. For a transition period, one could define both an MSIZE and an MBUF_SIZE equivalent to MSIZE for a couple of versions (say the whole 5.x series), clearly stating MSIZE is deprecated and shouldn't be used anymore, and then it could be completely removed in 6.x. -- Nicolas Christin Ph.D. Candidate, University of Virginia, Computer Science http://www.cs.virginia.edu/~nicolas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Oct 14 23:13: 9 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 70F1B37B401 for ; Mon, 14 Oct 2002 23:13:08 -0700 (PDT) Received: from a.smtp-out.sonic.net (a.smtp-out.sonic.net [208.201.224.38]) by mx1.FreeBSD.org (Postfix) with SMTP id E1AB343EAA for ; Mon, 14 Oct 2002 23:13:07 -0700 (PDT) (envelope-from gharris@sonic.net) Received: (qmail 15087 invoked from network); 15 Oct 2002 06:13:06 -0000 Received: from ultra.sonic.net (208.201.224.22) by a.smtp-out.sonic.net with SMTP; 15 Oct 2002 06:13:06 -0000 Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65]) by ultra.sonic.net (8.11.6/8.8.5) with ESMTP id g9F6D6r10999; Mon, 14 Oct 2002 23:13:06 -0700 X-envelope-info: Received: (from guy@localhost) by quadrajet.sonic.net (8.9.3/8.9.3) id XAA88478; Mon, 14 Oct 2002 23:13:05 -0700 (PDT) (envelope-from gharris) Date: Mon, 14 Oct 2002 23:13:05 -0700 From: Guy Harris To: Harti Brandt Cc: Craig Rodrigues , freebsd-net@FreeBSD.ORG Subject: Re: How to add bpf support to if_atmsubr.c? Message-ID: <20021014231305.H332@quadrajet.sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.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 > The problem is, that at attach time you > don't know what link-level encapsulation is used, because this can be > select when you establish the VCC (via the parameter 'z' (see en(4))). > So BPF_DLC_RFC1483 will not work without LLC/SNAP encapsulation. The current CVS versions of libpcap and tcpdump, and the current released version of Ethereal, support a DLT_SUNATM DLT_ type. SunATM's DLPI interface supplies packets with a 4-byte pseudo-header, consisting of: a 1-byte flag byte; a 1-byte VPI value; a 2-byte (big-endian) VCI value; where the flag byte contains a one-bit "direction" flag (indicating whether the packet was sent or received) and a 4-bit packet type. After that comes the raw reassembled PDU. The packet type can be one of "raw" - meaning "other"? LANE LLC-multiplexed MARS IFMP ILMI Q.2931 A similar thing could perhaps be done here; that'd allow the driver to supply signalling traffic to BPF, for example. That way, the encapsulation type - DLT_BPFATM, or something such as that - wouldn't depend on the circuit type; it'd be supplied to the application as part of the packet pseudo-header. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 1:47: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 3B72437B401 for ; Tue, 15 Oct 2002 01:47:22 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 76BE143EB1 for ; Tue, 15 Oct 2002 01:47:20 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: (qmail 27036 invoked from network); 15 Oct 2002 08:40:16 -0000 Received: from upnet-dialinpool-83.upnet.gr (HELO hades.hell.gr) (@150.140.128.171) by nic.upatras.gr with SMTP; 15 Oct 2002 08:40:16 -0000 Received: by hades.hell.gr (Postfix, from userid 1001) id 7F597B60D; Tue, 15 Oct 2002 08:01:03 +0300 (EEST) Date: Tue, 15 Oct 2002 08:01:03 +0300 From: Giorgos Keramidas To: Nicolas Christin Cc: net@FreeBSD.ORG Subject: Re: Rename of MSIZE kernel option.. Message-ID: <20021015050103.GD14604@hades.hell.gr> References: <15787.13726.246550.526201@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 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 2002-10-15 00:12, Nicolas Christin wrote: > On Mon, 14 Oct 2002, Andrew Gallatin wrote: > > > Would people be open to renaming the 'MSIZE' kernel option to something > > > more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can > > > > No. > > > > MSIZE is a traditional BSDism. Everybody else still uses it. > > Even AIX and MacOS. I really don't like the idea of changing this. > > True, but John is right, it's too generic a name. The argument "it's > been forever so we can't change it" seems a bit fallacious to me: True. But that sort of reasoning might lead us one day to rename macros and functions like m_get() to mbuf_get() or similar. That doesn't seem like a good idea :-/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 4: 1: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 6B60B37B401 for ; Tue, 15 Oct 2002 04:01:11 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 551C643E7B for ; Tue, 15 Oct 2002 04:01:10 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g9FB15e14694; Tue, 15 Oct 2002 13:01:05 +0200 (MEST) Date: Tue, 15 Oct 2002 13:01:05 +0200 (CEST) From: Harti Brandt To: Bruce M Simpson Cc: Guy Harris , Craig Rodrigues , Subject: Re: How to add bpf support to if_atmsubr.c? In-Reply-To: <20021015105452.GH6089@spc.org> Message-ID: <20021015125732.K54193-100000@beagle.fokus.gmd.de> 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 Tue, 15 Oct 2002, Bruce M Simpson wrote: BMS>On Mon, Oct 14, 2002 at 11:13:05PM -0700, Guy Harris wrote: BMS>> The current CVS versions of libpcap and tcpdump, and the current BMS>> released version of Ethereal, support a DLT_SUNATM DLT_ type. SunATM's BMS>> DLPI interface supplies packets with a 4-byte pseudo-header, consisting of: BMS>[snip] BMS> BMS>Just FYI... BMS> BMS>This sounds very similar to the promiscuous cell receive option on ENI's BMS>SpeedStream 5861 router. I found the raw hex cell output was essentially BMS>a 4 byte ATM UNI header omitting the CRC byte, and the 48 bytes of the raw BMS>AAL5 cell payload. The marconi HE cards have the same format although they have no promiscous mode (although it would be easy to configure all unused connections to receveive to a free receive group, the question is whether you want this (350000/packets per second for OC3)). My driver allows you to receive cells (i.e. AAL0) on any of the supported connections. BMS>Is there any open source support for the SunATM PCI cards? I see a few of BMS>them cropping up on eBay from time to time. It might be worth finding out BMS>which ASICs they use, I doubt Sun would engineer their own. Does Sun still make ATM cards? As far as I remember I saw the last SBUS cards a couple of years ago. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 5:16: 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 02D6337B401 for ; Tue, 15 Oct 2002 05:16:03 -0700 (PDT) Received: from mail.dada.it (mail4.dada.it [195.110.100.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 29DF743EAA for ; Tue, 15 Oct 2002 05:15:58 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 3039 invoked from network); 15 Oct 2002 12:15:49 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 15 Oct 2002 12:15:49 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id D6CF2602F; Tue, 15 Oct 2002 14:15:50 +0200 (CEST) Date: Tue, 15 Oct 2002 14:15:50 +0200 From: Alessandro de Manzano To: net@freebsd.org Subject: which L2TP server ? Message-ID: <20021015141550.A24823@libero.sunshine.ale> Reply-To: Alessandro de Manzano Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: FreeBSD 4.7-STABLE 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'm looking for a good L2TP server for FreeBSD, someone knows it ? If I'm right MPD does not (yet?) support L2TP. Thanks in advance! -- bye! Ale To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 5:41: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 BE69937B401 for ; Tue, 15 Oct 2002 05:41:07 -0700 (PDT) Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 805F843E9C for ; Tue, 15 Oct 2002 05:41:06 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.6/8.11.6) with ESMTP id g9FCf4Z1183732 for ; Tue, 15 Oct 2002 16:41:05 +0400 (MSD) Date: Tue, 15 Oct 2002 16:41:04 +0400 (MSD) From: Maxim Konovalov X-X-Sender: Maxim Konovalov To: net@freebsd.org Subject: RFR: ping(8) patches: do not fragment, TOS, maximum payload Message-ID: <20021015162242.J54875-100000@news1.macomnet.ru> 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 Hello, I have made a patch set for ping(8). I'll appreciate your comments. I did not include patches #3 and #4, they are stylistic mostly (based on BDE's style patch). A cumulative patch is there: http://people.freebsd.org/~maxim/p.cumulative #1, Print strict source routing option. Requested by David Wang . Index: ping.c =================================================================== RCS file: /home/maxim/cvs/ping/ping.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ping.c 15 Oct 2002 11:56:58 -0000 1.1 +++ ping.c 15 Oct 2002 11:57:53 -0000 1.2 @@ -953,7 +953,9 @@ hlen = 0; break; case IPOPT_LSRR: - (void)printf("\nLSRR: "); + case IPOPT_SSRR: + (void)printf(*cp == IPOPT_LSRR ? + "\nLSRR: " : "\nSSRR: "); j = cp[IPOPT_OLEN] - IPOPT_MINOFF + 1; hlen -= 2; cp += 2; %%% #2, Implement -D (do not fragment) and -z (TOS) options. Obtained from OpenBSD, bin/35843. Index: ping.c =================================================================== RCS file: /home/maxim/cvs/ping/ping.c,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ping.c 15 Oct 2002 11:57:53 -0000 1.2 +++ ping.c 15 Oct 2002 12:04:10 -0000 1.3 @@ -67,6 +67,7 @@ */ #include /* NB: we rely on this for */ +#include #include #include @@ -107,6 +108,7 @@ #define MAXPAYLOAD (IP_MAXPACKET - MAXIPLEN - MINICMPLEN) #define MAXWAIT 10 /* max seconds to wait for response */ #define MAXALARM (60 * 60) /* max seconds for alarm timeout */ +#define MAXTOS 255 #define A(bit) rcvd_tbl[(bit)>>3] /* identify byte in array */ #define B(bit) (1 << ((bit) & 0x07)) /* identify bit in byte */ @@ -138,6 +140,7 @@ #define F_TTL 0x8000 #define F_MISSED 0x10000 #define F_ONCE 0x20000 +#define F_HDRINCL 0x40000 /* * MAX_DUP_CHK is the number of bits in received table, i.e. the maximum @@ -151,7 +154,7 @@ struct sockaddr_in whereto; /* who to ping */ int datalen = DEFDATALEN; int s; /* socket file descriptor */ -u_char outpack[MINICMPLEN + MAXPAYLOAD]; +u_char outpackhdr[IP_MAXPACKET], *outpack; char BSPACE = '\b'; /* characters written for flood */ char BBELL = '\a'; /* characters written for MISSED and AUDIBLE */ char DOT = '.'; @@ -201,6 +204,7 @@ { struct in_addr ifaddr; struct iovec iov; + struct ip *ip; struct msghdr msg; struct sigaction si_sa; struct sockaddr_in from, sin; @@ -209,13 +213,15 @@ struct hostent *hp; struct sockaddr_in *to; double t; + size_t sz; u_char *datap, packet[IP_MAXPACKET]; char *ep, *source, *target; #ifdef IPSEC_POLICY_IPSEC char *policy_in, *policy_out; #endif u_long alarmtimeout, ultmp; - int ch, hold, i, packlen, preload, sockerrno, almost_done = 0, ttl; + int ch, df, hold, i, mib[4], packlen, preload, sockerrno, + almost_done = 0, tos, ttl; char ctrl[CMSG_SPACE(sizeof(struct timeval))]; char hnamebuf[MAXHOSTNAMELEN], snamebuf[MAXHOSTNAMELEN]; #ifdef IP_OPTIONS @@ -239,11 +245,12 @@ setuid(getuid()); uid = getuid(); - alarmtimeout = preload = 0; + alarmtimeout = df = preload = tos = 0; + outpack = outpackhdr + sizeof(struct ip); datap = &outpack[MINICMPLEN + PHDR_LEN]; while ((ch = getopt(argc, argv, - "AI:LQRS:T:c:adfi:l:m:nop:qrs:t:v" + "ADI:LQRS:T:c:adfi:l:m:nop:qrs:t:vz:" #ifdef IPSEC #ifdef IPSEC_POLICY_IPSEC "P:" @@ -266,6 +273,10 @@ optarg); npackets = ultmp; break; + case 'D': + options |= F_HDRINCL; + df = 1; + break; case 'd': options |= F_SO_DEBUG; break; @@ -390,6 +401,13 @@ else errx(1, "invalid security policy"); break; + case 'z': + options |= F_HDRINCL; + ultmp = strtoul(optarg, &ep, 0); + if (*ep || ep == optarg || ultmp > MAXTOS) + errx(EX_USAGE, "invalid TOS: `%s'", optarg); + tos = ultmp; + break; #endif /*IPSEC_POLICY_IPSEC*/ #endif /*IPSEC*/ default: @@ -509,6 +527,28 @@ #endif /*IPSEC_POLICY_IPSEC*/ #endif /*IPSEC*/ + if (options & F_HDRINCL) { + ip = (struct ip*)outpackhdr; + if (!(options & (F_TTL | F_MTTL))) { + mib[0] = CTL_NET; + mib[1] = PF_INET; + mib[2] = IPPROTO_IP; + mib[3] = IPCTL_DEFTTL; + sz = sizeof(ttl); + if (sysctl(mib, 4, &ttl, &sz, NULL, 0) == -1) + err(1, "sysctl(net.inet.ip.ttl)"); + } + setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hold, sizeof(hold)); + ip->ip_v = IPVERSION; + ip->ip_hl = sizeof(struct ip) >> 2; + ip->ip_tos = tos; + ip->ip_id = 0; + ip->ip_off = df ? IP_DF : 0; + ip->ip_ttl = ttl; + ip->ip_p = IPPROTO_ICMP; + ip->ip_src.s_addr = source ? sin.sin_addr.s_addr : INADDR_ANY; + ip->ip_dst = to->sin_addr; + } /* record route option */ if (options & F_RROUTE) { #ifdef IP_OPTIONS @@ -758,9 +798,12 @@ static void pinger(void) { + struct ip *ip; struct icmp *icp; int cc, i; + u_char *packet; + packet = outpack; icp = (struct icmp *)outpack; icp->icmp_type = ICMP_ECHO; icp->icmp_code = 0; @@ -779,7 +822,14 @@ /* compute ICMP checksum here */ icp->icmp_cksum = in_cksum((u_short *)icp, cc); - i = sendto(s, (char *)outpack, cc, 0, (struct sockaddr *)&whereto, + if (options & F_HDRINCL) { + cc += sizeof(struct ip); + ip = (struct ip *)outpackhdr; + ip->ip_len = cc; + ip->ip_sum = in_cksum((u_short *)outpackhdr, cc); + packet = outpackhdr; + } + i = sendto(s, (char *)packet, cc, 0, (struct sockaddr *)&whereto, sizeof(whereto)); if (i < 0 || i != cc) { @@ -1448,7 +1498,7 @@ usage() { (void)fprintf(stderr, "%s\n%s\n%s\n", -"usage: ping [-AQRadfnoqrv] [-c count] [-i wait] [-l preload] [-m ttl]", +"usage: ping [-ADQRadfnoqrv] [-c count] [-i wait] [-l preload] [-m ttl]", " [-p pattern] " #ifdef IPSEC #ifdef IPSEC_POLICY_IPSEC @@ -1456,6 +1506,6 @@ #endif #endif "[-s packetsize] [-S src_addr] [-t timeout]", -" [host | [-L] [-I iface] [-T ttl] mcast-group]"); +" [-z tos ] [host | [-L] [-I iface] [-T ttl] mcast-group]"); exit(EX_USAGE); } Index: ping.8 =================================================================== RCS file: /home/maxim/cvs/ping/ping.8,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ping.8 15 Oct 2002 11:56:58 -0000 1.1 +++ ping.8 15 Oct 2002 12:04:10 -0000 1.2 @@ -42,7 +42,7 @@ packets to network hosts .Sh SYNOPSIS .Nm -.Op Fl AQRadfnoqrv +.Op Fl ADQRadfnoqrv .Op Fl c Ar count .Op Fl i Ar wait .Op Fl l Ar preload @@ -52,6 +52,7 @@ .Op Fl s Ar packetsize .Op Fl S Ar src_addr .Op Fl t Ar timeout +.Op Fl z Ar tos .Bo .Ar host | .Op Fl L @@ -111,6 +112,8 @@ Set the .Dv SO_DEBUG option on the socket being used. +.It Fl D +Set the Don't Fragment bit. .It Fl f Flood ping. Outputs packets as fast as they come back or one hundred times per second, @@ -252,6 +255,8 @@ packets other than .Tn ECHO_RESPONSE that are received are listed. +.It Fl z Ar tos +Use the specified type of service. .El .Pp When using %%% #5 Do not constantify maximum payload size. It is 65467 with -R (record route), and 65507 without it. Index: ping.c =================================================================== RCS file: /home/maxim/cvs/ping/ping.c,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- ping.c 15 Oct 2002 12:04:40 -0000 1.5 +++ ping.c 15 Oct 2002 12:04:59 -0000 1.6 @@ -104,7 +104,6 @@ #define MAXIPLEN (sizeof(struct ip) + MAX_IPOPTLEN) #define MAXICMPLEN (ICMP_ADVLENMIN + MAX_IPOPTLEN) #define MINICMPLEN ICMP_MINLEN -#define MAXPAYLOAD (IP_MAXPACKET - MAXIPLEN - MINICMPLEN) #define MAXWAIT 10 /* max seconds to wait for response */ #define MAXALARM (60 * 60) /* max seconds for alarm timeout */ #define MAXTOS 255 @@ -151,6 +150,7 @@ char rcvd_tbl[MAX_DUP_CHK / 8]; struct sockaddr_in whereto; /* who to ping */ +long maxpayload; int datalen = DEFDATALEN; int s; /* socket file descriptor */ u_char outpackhdr[IP_MAXPACKET], *outpack; @@ -351,18 +351,16 @@ options |= F_SO_DONTROUTE; break; case 's': /* size of packet to send */ - if (uid) { - errno = EPERM; - err(EX_NOPERM, "-s flag"); - } ultmp = strtoul(optarg, &ep, 0); - if (ultmp > MAXPAYLOAD) - errx(EX_USAGE, - "packet size too large: %lu > %u", - ultmp, MAXPAYLOAD); if (*ep || ep == optarg) errx(EX_USAGE, "invalid packet size: `%s'", optarg); + if (uid != 0 && ultmp > DEFDATALEN) { + errno = EPERM; + err(EX_NOPERM, + "packet size too large: %lu > %u", + ultmp, DEFDATALEN); + } datalen = ultmp; break; case 'S': @@ -418,6 +416,12 @@ usage(); target = argv[optind]; + maxpayload = IP_MAXPACKET - sizeof(struct ip) - MINICMPLEN; + if (options & F_RROUTE) + maxpayload -= MAX_IPOPTLEN; + if (datalen > maxpayload) + errx(EX_USAGE, "packet size too large: %lu > %u", datalen, + maxpayload); if (source) { bzero((char *)&sin, sizeof(sin)); sin.sin_family = AF_INET; @@ -1476,7 +1480,7 @@ &pat[13], &pat[14], &pat[15]); if (ii > 0) - for (kk = 0; kk <= MAXPAYLOAD - (PHDR_LEN + ii); kk += ii) + for (kk = 0; kk <= maxpayload - (PHDR_LEN + ii); kk += ii) for (jj = 0; jj < ii; ++jj) bp[jj + kk] = pat[jj]; if (!(options & F_QUIET)) { Index: ping.8 =================================================================== RCS file: /home/maxim/cvs/ping/ping.8,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ping.8 15 Oct 2002 12:04:10 -0000 1.2 +++ ping.8 15 Oct 2002 12:04:59 -0000 1.3 @@ -235,7 +235,7 @@ with the 8 bytes of .Tn ICMP header data. -Only the super-user may use this option. +Only the super-user may specify values more then default. .It Fl S Ar src_addr Use the following IP address as the source address in outgoing packets. On hosts with more than one IP address, this option can be used to %%% Thank you very much. -- Maxim Konovalov, MAcomnet, Internet Dept., system engineer phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 7:10: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 B6DCB37B401 for ; Tue, 15 Oct 2002 07:10:31 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D56343E9E for ; Tue, 15 Oct 2002 07:10:31 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 27395 invoked from network); 15 Oct 2002 14:10:29 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 15 Oct 2002 14:10:29 -0000 Message-ID: <3DAC21D5.1080006@tenebras.com> Date: Tue, 15 Oct 2002 07:10:29 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, fr-fr, ru MIME-Version: 1.0 To: Alessandro de Manzano Cc: net@freebsd.org Subject: Re: which L2TP server ? References: <20021015141550.A24823@libero.sunshine.ale> 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 Alessandro de Manzano wrote: > Hello! > > I'm looking for a good L2TP server for FreeBSD, someone knows it ? > > If I'm right MPD does not (yet?) support L2TP. > > > Thanks in advance! > > man ng_l2tp DESCRIPTION The ng_l2tp node type implements the encapsulation layer of the L2TP pro- tocol as described in RFC 2661. This includes adding the L2TP packet header for outgoing packets and verifying and removing it for incoming packets. The node maintains the L2TP sequence number state and handles control session packet acknowledgment and retransmission. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 7:17: 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 98E9A37B401 for ; Tue, 15 Oct 2002 07:17:05 -0700 (PDT) Received: from mail.dada.it (mail3.dada.it [195.110.100.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 517DE43EAA for ; Tue, 15 Oct 2002 07:17:03 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 10065 invoked from network); 15 Oct 2002 14:17:00 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 15 Oct 2002 14:17:00 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id 5E393602F; Tue, 15 Oct 2002 16:17:00 +0200 (CEST) Date: Tue, 15 Oct 2002 16:17:00 +0200 From: Alessandro de Manzano To: Michael Sierchio Cc: net@freebsd.org Subject: Re: which L2TP server ? Message-ID: <20021015161700.A25444@libero.sunshine.ale> Reply-To: Alessandro de Manzano References: <20021015141550.A24823@libero.sunshine.ale> <3DAC21D5.1080006@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DAC21D5.1080006@tenebras.com>; from kudzu@tenebras.com on Tue, Oct 15, 2002 at 07:10:29AM -0700 X-Operating-System: FreeBSD 4.7-STABLE 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 Tue, Oct 15, 2002 at 07:10:29AM -0700, Michael Sierchio wrote: > man ng_l2tp > > DESCRIPTION > The ng_l2tp node type implements the encapsulation layer of the L2TP pro- > tocol as described in RFC 2661. This includes adding the L2TP packet thanks, but I'm looking for something at higher level, also easier to setup. As MPD (actually it use ng_ppp and others), for example. tnx! -- bye! Ale To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 7:32: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 E008D37B401 for ; Tue, 15 Oct 2002 07:32:52 -0700 (PDT) Received: from 21322530218.direct.eti.at (21322530218.direct.eti.at [213.225.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AEA643E91 for ; Tue, 15 Oct 2002 07:32:46 -0700 (PDT) (envelope-from tilman@arved.de) Received: from huckfinn.arved.de (localhost [127.0.0.1]) by 21322530218.direct.eti.at (8.12.5/8.12.5) with ESMTP id g9FEg4UF056609; Tue, 15 Oct 2002 16:42:04 +0200 (CEST) (envelope-from tilman@arved.de) Received: (from tilman@localhost) by huckfinn.arved.de (8.12.5/8.12.5/Submit) id g9FEg3JT056608; Tue, 15 Oct 2002 16:42:03 +0200 (CEST) X-Authentication-Warning: huckfinn.arved.de: tilman set sender to tilman@arved.de using -f Date: Tue, 15 Oct 2002 16:42:03 +0200 From: Tilman Linneweh To: Alessandro de Manzano Cc: freebsd-net@FreeBSD.org Subject: Re: which L2TP server ? Message-ID: <20021015144203.GA56390@huckfinn.arved.de> Reply-To: e0025974@student.tuwien.ac.at References: <20021015141550.A24823@libero.sunshine.ale> <3DAC21D5.1080006@tenebras.com> <20021015161700.A25444@libero.sunshine.ale> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <20021015161700.A25444@libero.sunshine.ale> 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 --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In arved.freebsd.net, you wrote: > On Tue, Oct 15, 2002 at 07:10:29AM -0700, Michael Sierchio wrote: >=20 >> man ng_l2tp >>=20 >> DESCRIPTION >> The ng_l2tp node type implements the encapsulation layer of the L2= TP pro- >> tocol as described in RFC 2661. This includes adding the L2TP pac= ket >=20 > thanks, but I'm looking for something at higher level, also easier to > setup. >=20 > As MPD (actually it use ng_ppp and others), for example. I once compiled the Linux one from www.l2tpd.org (port at http://stud3.tuwien.ac.at/~e0025974/bsdsrc/l2tpd.shar), but never tested, if it really worked on FreeBSD. regards arved --1yeeQ81UyVL57Vl7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9rCk5fCLDn4B6xToRAvK2AJ9uTmJqmL4ILXlrzjdNYwpFgRwnHACfVQGG 7PG2dAf5rGcnCHw9wa0jme4= =1s6r -----END PGP SIGNATURE----- --1yeeQ81UyVL57Vl7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 9:58:37 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 6FAF837B404 for ; Tue, 15 Oct 2002 09:58:36 -0700 (PDT) Received: from b.smtp-out.sonic.net (b.smtp-out.sonic.net [208.201.224.39]) by mx1.FreeBSD.org (Postfix) with SMTP id 83AC343EAF for ; Tue, 15 Oct 2002 09:58:34 -0700 (PDT) (envelope-from gharris@sonic.net) Received: (qmail 26644 invoked from network); 15 Oct 2002 16:58:34 -0000 Received: from turbo.sonic.net (208.201.224.26) by b.smtp-out.sonic.net with SMTP; 15 Oct 2002 16:58:34 -0000 Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65]) by turbo.sonic.net (8.11.6/8.8.5) with ESMTP id g9FGwXR08989; Tue, 15 Oct 2002 09:58:33 -0700 X-envelope-info: Received: (from guy@localhost) by quadrajet.sonic.net (8.9.3/8.9.3) id JAA00393; Tue, 15 Oct 2002 09:58:32 -0700 (PDT) (envelope-from gharris) Date: Tue, 15 Oct 2002 09:58:32 -0700 From: Guy Harris To: Bruce M Simpson , Harti Brandt , Craig Rodrigues , freebsd-net@FreeBSD.ORG Subject: Re: How to add bpf support to if_atmsubr.c? Message-ID: <20021015095832.B332@quadrajet.sonic.net> References: <20021014231305.H332@quadrajet.sonic.net> <20021015105452.GH6089@spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20021015105452.GH6089@spc.org>; from bms@spc.org on Tue, Oct 15, 2002 at 11:54:52AM +0100 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 Tue, Oct 15, 2002 at 11:54:52AM +0100, Bruce M Simpson wrote: > This sounds very similar to the promiscuous cell receive option on ENI's > SpeedStream 5861 router. I found the raw hex cell output was essentially > a 4 byte ATM UNI header omitting the CRC byte, and the 48 bytes of the raw > AAL5 cell payload. Similar, but not the same; I doubt there's any hardware significance to the VPI/VCI part of the header, and the type field is probably put there by the driver. (Also, the DLPI interface supplies reassembled AAL5 PDUs, not raw cells; I don't know what it does for other AALs, except for the signalling AAL where it again supplies reassembled packets.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 10: 0: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 249F437B401 for ; Tue, 15 Oct 2002 10:00:12 -0700 (PDT) Received: from a.smtp-out.sonic.net (a.smtp-out.sonic.net [208.201.224.38]) by mx1.FreeBSD.org (Postfix) with SMTP id 72AFD43E75 for ; Tue, 15 Oct 2002 10:00:11 -0700 (PDT) (envelope-from gharris@sonic.net) Received: (qmail 31564 invoked from network); 15 Oct 2002 17:00:11 -0000 Received: from turbo.sonic.net (208.201.224.26) by a.smtp-out.sonic.net with SMTP; 15 Oct 2002 17:00:11 -0000 Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65]) by turbo.sonic.net (8.11.6/8.8.5) with ESMTP id g9FH0AR10697; Tue, 15 Oct 2002 10:00:11 -0700 X-envelope-info: Received: (from guy@localhost) by quadrajet.sonic.net (8.9.3/8.9.3) id KAA00405; Tue, 15 Oct 2002 10:00:09 -0700 (PDT) (envelope-from gharris) Date: Tue, 15 Oct 2002 10:00:09 -0700 From: Guy Harris To: Harti Brandt Cc: Bruce M Simpson , Craig Rodrigues , freebsd-net@FreeBSD.ORG Subject: Re: How to add bpf support to if_atmsubr.c? Message-ID: <20021015100009.C332@quadrajet.sonic.net> References: <20021015105452.GH6089@spc.org> <20021015125732.K54193-100000@beagle.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20021015125732.K54193-100000@beagle.fokus.gmd.de>; from brandt@fokus.gmd.de on Tue, Oct 15, 2002 at 01:01:05PM +0200 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 Tue, Oct 15, 2002 at 01:01:05PM +0200, Harti Brandt wrote: > Does Sun still make ATM cards? As far as I remember I saw the last SBUS > cards a couple of years ago. They still have a Web page for SunATM: http://www.sun.com/products-n-solutions/hw/networking/connectivity/sunatm/index.html and say that they've introduced a 4.0 version of SunATM (which runs in 64-bit mode on Solaris 7) and also list PCI adapters in addition to the SBus adapters. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 10:10: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 85D9437B401 for ; Tue, 15 Oct 2002 10:10:29 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14B2243E88 for ; Tue, 15 Oct 2002 10:10:29 -0700 (PDT) (envelope-from bbaumann@isilon.com) Received: from localhost (localhost [127.0.0.1]) by isilon.com (8.12.2/8.11.1) with ESMTP id g9FHAR3C077453; Tue, 15 Oct 2002 10:10:27 -0700 (PDT) (envelope-from bbaumann@isilon.com) Date: Tue, 15 Oct 2002 10:10:27 -0700 (PDT) From: Bill Baumann To: e0025974@student.tuwien.ac.at Cc: Alessandro de Manzano , freebsd-net@FreeBSD.ORG Subject: Re: which L2TP server ? In-Reply-To: <20021015144203.GA56390@huckfinn.arved.de> 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 A year & a half ago, the l2tpd interface and code was still in its infancy. If all you seek is to create tunnels/sessions, and don't care about security or other more complex l2tp issues, it should work ok. I developed my own L2TP stack for Linux with much higher level of functionality. It would take some porting effort. Only a small effort was made on usability, so that could be an issue too. http://sourceforge.net/projects/l2tp/ I would also suggest going to http://sourceforge.net and search for l2tp. There are a few other projects out there besides these two. Regards, Bill Baumann On Tue, 15 Oct 2002, Tilman Linneweh wrote: > In arved.freebsd.net, you wrote: > > On Tue, Oct 15, 2002 at 07:10:29AM -0700, Michael Sierchio wrote: > > > >> man ng_l2tp > >> > >> DESCRIPTION > >> The ng_l2tp node type implements the encapsulation layer of the L2TP pro- > >> tocol as described in RFC 2661. This includes adding the L2TP packet > > > > thanks, but I'm looking for something at higher level, also easier to > > setup. > > > > As MPD (actually it use ng_ppp and others), for example. > > I once compiled the Linux one from www.l2tpd.org (port at > http://stud3.tuwien.ac.at/~e0025974/bsdsrc/l2tpd.shar), but never > tested, if it really worked on FreeBSD. > > regards > arved > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 12:18: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 9235537B401 for ; Tue, 15 Oct 2002 12:18:29 -0700 (PDT) Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCC6843EAC for ; Tue, 15 Oct 2002 12:18:28 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from mammoth.eat.frenchfries.net (da001d0461.lax-ca.osd.concentric.net [64.0.145.206]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g9FIvac07389 for ; Tue, 15 Oct 2002 11:57:38 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id 314184A22; Tue, 15 Oct 2002 12:16:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id 2A8794A20; Tue, 15 Oct 2002 12:16:31 -0700 (PDT) Date: Tue, 15 Oct 2002 12:16:31 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: Steve Francis Cc: Kirill Ponomarew , Subject: Re: delayed ACK In-Reply-To: <3DAAE60E.3010708@expertcity.com> Message-ID: <20021015115315.U7412-100000@mammoth.eat.frenchfries.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 On Mon, 14 Oct 2002, Steve Francis wrote: > Kirill Ponomarew wrote: > > > > is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with > > heavy network traffic ? > > > If you want to increase your network traffic for no particular reason, > and increase load on your server, then yes. > > Otherwise no. Not true. Although some bugs have been fixed in 4.3, FreeBSD's delayed ACKs will still degrade your performance dramatically in some cases. For now, the best advice I could give is to benchmark your client machine with and without delayed ACKs and see which works best for your environment. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 12:28: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 D34EA37B401 for ; Tue, 15 Oct 2002 12:28:54 -0700 (PDT) Received: from venus.vincentjardin.net (AVelizy-102-1-3-234.abo.wanadoo.fr [217.128.244.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39CF643EA3 for ; Tue, 15 Oct 2002 12:28:54 -0700 (PDT) (envelope-from jardin@venus.vincentjardin.net) Received: by venus.vincentjardin.net (Postfix, from userid 501) id A5AF51503A0; Tue, 15 Oct 2002 21:44:44 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Alessandro de Manzano , net@freebsd.org Subject: Re: which L2TP server ? Date: Tue, 15 Oct 2002 21:44:44 +0200 X-Mailer: KMail [version 1.3.1] References: <20021015141550.A24823@libero.sunshine.ale> In-Reply-To: <20021015141550.A24823@libero.sunshine.ale> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20021015194444.A5AF51503A0@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 There is a new L2TP project from Roaring Penguin. It supports both LAC and LNS features: http://sourceforge.net/projects/rp-l2tp It requires pppd. It has been written for Linux, however it should support FreeBSD easily. Vincent Le Mardi 15 Octobre 2002 14:15, Alessandro de Manzano a écrit : > Hello! > > I'm looking for a good L2TP server for FreeBSD, someone knows it ? > > If I'm right MPD does not (yet?) support L2TP. > > > Thanks in advance! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 13: 5:51 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 3EA3637B401 for ; Tue, 15 Oct 2002 13:05:50 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEA0543EB3 for ; Tue, 15 Oct 2002 13:05:49 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S946S8>; Tue, 15 Oct 2002 16:05:44 -0400 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Subject: dynamic load of em/fxp/bge Date: Tue, 15 Oct 2002 16:05:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 trying to load the if_em, if_fxp, if_bge drivers via /boot/loader.conf. I've added if_fxp_load="YES" if_bge_load="YES" if_em_load="YES" The problem is that the bge driver doesn't load. It will if I manually load it after startup with kldload. The issue seems to be a dependency on miibus, both fxp and bge want to load it, bge gets an error that its already loaded. I tried putting 'miibus_load="YES"' in loader.conf, but the same affect is seen. I've tried from the boot prompt doing an explicit load of these manually in each order, but to no avail. As a work-around, I've placed an kldload if_bge in rc.network before the 'ifconfig -l'. Any suggestions on why the fxp/bge don't play nice when loaded automatically, but will work if run manually? Is there a timing thing that the fxp hasn't initialised its miibus yet? I have: fxp0 fxp1 bge0 in this particular machine. The bge will get miibus2 (eventually), leaving fxp0 to have miibus0, fxp1 to have miibus1 I think. Suggestions? --don To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 14: 1: 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 320AA37B401 for ; Tue, 15 Oct 2002 14:01:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FF4543EAC for ; Tue, 15 Oct 2002 14:00:59 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9FL0sC05962; Tue, 15 Oct 2002 14:00:54 -0700 (PDT) Message-ID: <3DAC8206.1080604@isi.edu> Date: Tue, 15 Oct 2002 14:00:54 -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: Paul Herman Cc: Steve Francis , Kirill Ponomarew , freebsd-net@FreeBSD.ORG Subject: Re: delayed ACK References: <20021015115315.U7412-100000@mammoth.eat.frenchfries.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060106040804030107080102" 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. --------------ms060106040804030107080102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Paul Herman wrote: > > Not true. Although some bugs have been fixed in 4.3, FreeBSD's > delayed ACKs will still degrade your performance dramatically in > some cases. I'm sorry, but such statements without a packet trace that exhibits the problem are just not useful. Lars -- Lars Eggert USC Information Sciences Institute --------------ms060106040804030107080102 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 hvcNAQkFMQ8XDTAyMTAxNTIxMDA1NFowIwYJKoZIhvcNAQkEMRYEFC1rn5aoAj1/wSqRItGM x/+ycHV9MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAbPlZAlegWsdWbgki5wmbzpESWHUjADkSxLtxYBY9LwkT0RUeNwvE fBZ4ChQJMqRhaMOKVpORKuSGpkY1inSqfTVpDhqntsw6qxa6IBh+4gnG+f51csdejHUBHHSN V9RC7y1CNujmZzxVSlNTbCcIiunYiSg99937UQIciPe2x1cEQsC+WLHK6giSIKGXSm5mSv9G zzZER0DlJxTo3H+GzBU11Lp+u+yBYvRXiQjxvDraW3rgoBTIpxdXbj6O9/tI7NlF9CfAv8cm S2nz6i4PvEH4COVHH+xMOrqcsinkOLt97r3KTV0KGMaPT1a/vnrW+983PNYDqizBbywRkiGS dAAAAAAAAA== --------------ms060106040804030107080102-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 14:53: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 9C46A37B401 for ; Tue, 15 Oct 2002 14:53:21 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7783943E4A for ; Tue, 15 Oct 2002 14:53:20 -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 g9FLrGYj053179 for ; Wed, 16 Oct 2002 00:53:19 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <065901c27495$56a94c40$8c2a40c1@PHE> From: "Petri Helenius" To: Subject: ENOBUFS Date: Wed, 16 Oct 2002 00:53:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 My processes writing to SOCK_DGRAM sockets are getting ENOBUFS while netstat -s counter under the heading of "ip" is incrementing: 7565828 output packets dropped due to no bufs, etc. but netstat -m shows: > netstat -m 579/1440/131072 mbufs in use (current/peak/max): 578 mbufs allocated to data 1 mbufs allocated to packet headers 576/970/32768 mbuf clusters in use (current/peak/max) 2300 Kbytes allocated to network (2% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Where should I start looking? The interface is em Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 14:59: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 C92C237B401 for ; Tue, 15 Oct 2002 14:59:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B6D943E75 for ; Tue, 15 Oct 2002 14:59:13 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9FLx9C23893; Tue, 15 Oct 2002 14:59:09 -0700 (PDT) Message-ID: <3DAC8FAD.30601@isi.edu> Date: Tue, 15 Oct 2002 14:59:09 -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: Petri Helenius Cc: freebsd-net@freebsd.org Subject: Re: ENOBUFS References: <065901c27495$56a94c40$8c2a40c1@PHE> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020907070109000802030402" 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. --------------ms020907070109000802030402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Petri Helenius wrote: > My processes writing to SOCK_DGRAM sockets are getting ENOBUFS > while netstat -s counter under the heading of "ip" is incrementing: > 7565828 output packets dropped due to no bufs, etc. What rate are you sending these packets at? A standard interface queue length is 50 packets, you get ENOBUFS when it's full. Lars -- Lars Eggert USC Information Sciences Institute --------------ms020907070109000802030402 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 hvcNAQkFMQ8XDTAyMTAxNTIxNTkwOVowIwYJKoZIhvcNAQkEMRYEFL4QAOq8SEF2HTsTHYE1 qr9bC3D/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAm6hZaSEb6/o7UJav5hj23gTrWFEIjZz48xCHnhcVzTHyTGq+FpHu +/aHYRJxDWhpCcyp1yZ1xMxQkm+mDuZmFGBBregElXPag6uz2H7+bdcEOZKLMVbK2gbdSuG/ fSqjBFnxRoXBGx8RbwXjeDITyrlaYqNU74laeMHWukuiEI0LWhYUI1e1NUvnh8WR3euNfdkt aw6xLWTLATvOZ3cJbYEjH/C3iZSUXjVwZNyp53REKdhootraKKNHNS71flLBoocdEmGTkk1p O2qs2TS//LQiGY7KBmzLSG36D+vwjI2gvEnwznxP/KyuiTwFWapku714ATyOHhtrpurzlYyT XAAAAAAAAA== --------------ms020907070109000802030402-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 15:17: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 E27BC37B401; Tue, 15 Oct 2002 15:17:18 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF67643E6A; Tue, 15 Oct 2002 15:17:17 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9FMHDIw060638; Wed, 16 Oct 2002 00:17:13 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: net@freebsd.org, arch@freebsd.org Subject: RFC: eliminating the _IP_VHL hack. From: Poul-Henning Kamp Date: Wed, 16 Oct 2002 00:17:13 +0200 Message-ID: <60637.1034720233@critter.freebsd.dk> 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 almost 7 years ago, this commit introduced the _IP_VHL hack in our IP-stack: ] revision 1.7 ] date: 1995/12/21 21:20:27; author: wollman; state: Exp; lines: +5 -1 ] If _IP_VHL is defined, declare a single ip_vhl member in struct ip rather ] than separate ip_v and ip_hl members. Should have no effect on current code, ] but I'd eventually like to get rid of those obnoxious bitfields completely. We can argue a lot about how long time we should wait for "eventually", but I would say that 7 years is far too long, considering the status: In the meantime absolutely no code has picked up on this idea, and source files using the _IP_VHL hack in in the minority in our tree. The side effect of having some source-files using the _IP_VHL hack and some not is that sizeof(struct ip) varies from file to file, which at best is confusing an at worst the source of some really evil bugs. I would therefore propose to eliminate the _IP_VHL hack from the kernel to end this state of (potential) confusion, and invite comments to the following patch: Index: ip.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip.h,v retrieving revision 1.19 diff -u -r1.19 ip.h --- ip.h 14 Dec 2001 19:37:32 -0000 1.19 +++ ip.h 15 Oct 2002 22:02:26 -0000 @@ -47,9 +47,6 @@ * Structure of an internet header, naked of options. */ struct ip { -#ifdef _IP_VHL - u_char ip_vhl; /* version << 4 | header length >> 2 */ -#else #if BYTE_ORDER == LITTLE_ENDIAN u_int ip_hl:4, /* header length */ ip_v:4; /* version */ @@ -58,7 +55,6 @@ u_int ip_v:4, /* version */ ip_hl:4; /* header length */ #endif -#endif /* not _IP_VHL */ u_char ip_tos; /* type of service */ u_short ip_len; /* total length */ u_short ip_id; /* identification */ @@ -72,13 +68,6 @@ u_short ip_sum; /* checksum */ struct in_addr ip_src,ip_dst; /* source and dest address */ }; - -#ifdef _IP_VHL -#define IP_MAKE_VHL(v, hl) ((v) << 4 | (hl)) -#define IP_VHL_HL(vhl) ((vhl) & 0x0f) -#define IP_VHL_V(vhl) ((vhl) >> 4) -#define IP_VHL_BORING 0x45 -#endif #define IP_MAXPACKET 65535 /* maximum packet size */ Index: ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.70 diff -u -r1.70 ip_icmp.c --- ip_icmp.c 1 Aug 2002 03:53:04 -0000 1.70 +++ ip_icmp.c 15 Oct 2002 22:05:23 -0000 @@ -51,7 +51,6 @@ #include #include -#define _IP_VHL #include #include #include @@ -128,7 +127,7 @@ struct ifnet *destifp; { register struct ip *oip = mtod(n, struct ip *), *nip; - register unsigned oiplen = IP_VHL_HL(oip->ip_vhl) << 2; + register unsigned oiplen = oip->ip_hl << 2; register struct icmp *icp; register struct mbuf *m; unsigned icmplen; @@ -214,7 +213,8 @@ nip = mtod(m, struct ip *); bcopy((caddr_t)oip, (caddr_t)nip, sizeof(struct ip)); nip->ip_len = m->m_len; - nip->ip_vhl = IP_VHL_BORING; + nip->ip_v = IPVERSION; + nip->ip_hl = 5; nip->ip_p = IPPROTO_ICMP; nip->ip_tos = 0; icmp_reflect(m); @@ -364,7 +364,7 @@ * Problem with datagram; advise higher level routines. */ if (icmplen < ICMP_ADVLENMIN || icmplen < ICMP_ADVLEN(icp) || - IP_VHL_HL(icp->icmp_ip.ip_vhl) < (sizeof(struct ip) >> 2)) { + icp->icmp_ip.ip_hl < (sizeof(struct ip) >> 2)) { icmpstat.icps_badlen++; goto freeit; } @@ -526,7 +526,7 @@ if (code > 3) goto badcode; if (icmplen < ICMP_ADVLENMIN || icmplen < ICMP_ADVLEN(icp) || - IP_VHL_HL(icp->icmp_ip.ip_vhl) < (sizeof(struct ip) >> 2)) { + icp->icmp_ip.ip_hl < (sizeof(struct ip) >> 2)) { icmpstat.icps_badlen++; break; } @@ -593,7 +593,7 @@ struct in_ifaddr *ia; struct in_addr t; struct mbuf *opts = 0; - int optlen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof(struct ip); + int optlen = (ip->ip_hl << 2) - sizeof(struct ip); struct route *ro = NULL, rt; if (!in_canforward(ip->ip_src) && @@ -703,7 +703,8 @@ * mbuf's data back, and adjust the IP length. */ ip->ip_len -= optlen; - ip->ip_vhl = IP_VHL_BORING; + ip->ip_v = IPVERSION; + ip->ip_hl = 5; m->m_len -= optlen; if (m->m_flags & M_PKTHDR) m->m_pkthdr.len -= optlen; @@ -734,7 +735,7 @@ register int hlen; register struct icmp *icp; - hlen = IP_VHL_HL(ip->ip_vhl) << 2; + hlen = ip->ip_hl << 2; m->m_data += hlen; m->m_len -= hlen; icp = mtod(m, struct icmp *); Index: ip_icmp.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.h,v retrieving revision 1.18 diff -u -r1.18 ip_icmp.h --- ip_icmp.h 19 Mar 2002 21:25:46 -0000 1.18 +++ ip_icmp.h 15 Oct 2002 22:02:52 -0000 @@ -123,13 +123,8 @@ #define ICMP_TSLEN (8 + 3 * sizeof (n_time)) /* timestamp */ #define ICMP_MASKLEN 12 /* address mask */ #define ICMP_ADVLENMIN (8 + sizeof (struct ip) + 8) /* min */ -#ifndef _IP_VHL #define ICMP_ADVLEN(p) (8 + ((p)->icmp_ip.ip_hl << 2) + 8) /* N.B.: must separately check that ip_hl >= 5 */ -#else -#define ICMP_ADVLEN(p) (8 + (IP_VHL_HL((p)->icmp_ip.ip_vhl) << 2) + 8) - /* N.B.: must separately check that header length >= 5 */ -#endif /* * Definition of type and code field values. Index: ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.211 diff -u -r1.211 ip_input.c --- ip_input.c 10 Oct 2002 12:03:36 -0000 1.211 +++ ip_input.c 15 Oct 2002 22:02:57 -0000 @@ -34,8 +34,6 @@ * $FreeBSD: src/sys/netinet/ip_input.c,v 1.211 2002/10/10 12:03:36 maxim Exp $ */ -#define _IP_VHL - #include "opt_bootp.h" #include "opt_ipfw.h" #include "opt_ipdn.h" @@ -324,7 +322,7 @@ if (args.rule) { /* dummynet already filtered us */ ip = mtod(m, struct ip *); - hlen = IP_VHL_HL(ip->ip_vhl) << 2; + hlen = ip->ip_hl << 2; goto iphack ; } @@ -340,12 +338,12 @@ } ip = mtod(m, struct ip *); - if (IP_VHL_V(ip->ip_vhl) != IPVERSION) { + if (ip->ip_v != IPVERSION) { ipstat.ips_badvers++; goto bad; } - hlen = IP_VHL_HL(ip->ip_vhl) << 2; + hlen = ip->ip_hl << 2; if (hlen < sizeof(struct ip)) { /* minimum header length */ ipstat.ips_badhlen++; goto bad; @@ -755,7 +753,7 @@ ipstat.ips_reassembled++; ip = mtod(m, struct ip *); /* Get the header length of the reassembled packet */ - hlen = IP_VHL_HL(ip->ip_vhl) << 2; + hlen = ip->ip_hl << 2; #ifdef IPDIVERT /* Restore original checksum before diverting packet */ if (divert_info != 0) { @@ -882,7 +880,7 @@ struct ip *ip = mtod(m, struct ip *); register struct mbuf *p, *q, *nq; struct mbuf *t; - int hlen = IP_VHL_HL(ip->ip_vhl) << 2; + int hlen = ip->ip_hl << 2; int i, next; /* @@ -1020,7 +1018,7 @@ */ q = fp->ipq_frags; ip = GETIP(q); - if (next + (IP_VHL_HL(ip->ip_vhl) << 2) > IP_MAXPACKET) { + if (next + (ip->ip_hl << 2) > IP_MAXPACKET) { ipstat.ips_toolong++; ip_freef(head, fp); return (0); @@ -1068,8 +1066,8 @@ nipq--; (void) m_free(dtom(fp)); ip_nfragpackets--; - m->m_len += (IP_VHL_HL(ip->ip_vhl) << 2); - m->m_data -= (IP_VHL_HL(ip->ip_vhl) << 2); + m->m_len += (ip->ip_hl << 2); + m->m_data -= (ip->ip_hl << 2); /* some debugging cruft by sklower, below, will go away soon */ if (m->m_flags & M_PKTHDR) /* XXX this should be done elsewhere */ m_fixhdr(m); @@ -1193,7 +1191,7 @@ dst = ip->ip_dst; cp = (u_char *)(ip + 1); - cnt = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof (struct ip); + cnt = (ip->ip_hl << 2) - sizeof (struct ip); for (; cnt > 0; cnt -= optlen, cp += optlen) { opt = cp[IPOPT_OPTVAL]; if (opt == IPOPT_EOL) @@ -1582,14 +1580,15 @@ register caddr_t opts; int olen; - olen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof (struct ip); + olen = (ip->ip_hl << 2) - sizeof (struct ip); opts = (caddr_t)(ip + 1); i = m->m_len - (sizeof (struct ip) + olen); bcopy(opts + olen, opts, (unsigned)i); m->m_len -= olen; if (m->m_flags & M_PKTHDR) m->m_pkthdr.len -= olen; - ip->ip_vhl = IP_MAKE_VHL(IPVERSION, sizeof(struct ip) >> 2); + ip->ip_v = IPVERSION; + ip->ip_hl = sizeof(struct ip) >> 2; } u_char inetctlerrmap[PRC_NCMDS] = { @@ -1686,7 +1685,7 @@ MGET(mcopy, M_DONTWAIT, m->m_type); if (mcopy != NULL) { M_COPY_PKTHDR(mcopy, m); - mcopy->m_len = imin((IP_VHL_HL(ip->ip_vhl) << 2) + 8, + mcopy->m_len = imin((ip->ip_hl << 2) + 8, (int)ip->ip_len); m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t)); #ifdef MAC Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.165 diff -u -r1.165 ip_output.c --- ip_output.c 23 Sep 2002 08:56:24 -0000 1.165 +++ ip_output.c 15 Oct 2002 22:03:41 -0000 @@ -34,8 +34,6 @@ * $FreeBSD: src/sys/netinet/ip_output.c,v 1.165 2002/09/23 08:56:24 maxim Exp $ */ -#define _IP_VHL - #include "opt_ipfw.h" #include "opt_ipdn.h" #include "opt_ipdivert.h" @@ -191,7 +189,7 @@ #endif if (args.rule != NULL) { /* dummynet already saw us */ ip = mtod(m, struct ip *); - hlen = IP_VHL_HL(ip->ip_vhl) << 2 ; + hlen = ip->ip_hl << 2 ; if (ro->ro_rt) ia = ifatoia(ro->ro_rt->rt_ifa); goto sendit; @@ -210,7 +208,8 @@ * Fill in IP header. */ if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) { - ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); + ip->ip_v = IPVERSION; + ip->ip_hl = hlen >> 2; ip->ip_off &= IP_DF; #ifdef RANDOM_IP_ID ip->ip_id = ip_randomid(); @@ -219,7 +218,7 @@ #endif ipstat.ips_localout++; } else { - hlen = IP_VHL_HL(ip->ip_vhl) << 2; + hlen = ip->ip_hl << 2; } dst = (struct sockaddr_in *)&ro->ro_dst; @@ -553,11 +552,7 @@ /* be sure to update variables that are affected by ipsec4_output() */ ip = mtod(m, struct ip *); -#ifdef _IP_VHL - hlen = IP_VHL_HL(ip->ip_vhl) << 2; -#else hlen = ip->ip_hl << 2; -#endif if (ro->ro_rt == NULL) { if ((flags & IP_ROUTETOIF) == 0) { printf("ip_output: " @@ -862,13 +857,8 @@ ip->ip_len = htons(ip->ip_len); ip->ip_off = htons(ip->ip_off); ip->ip_sum = 0; - if (sw_csum & CSUM_DELAY_IP) { - if (ip->ip_vhl == IP_VHL_BORING) { - ip->ip_sum = in_cksum_hdr(ip); - } else { - ip->ip_sum = in_cksum(m, hlen); - } - } + if (sw_csum & CSUM_DELAY_IP) + ip->ip_sum = in_cksum(m, hlen); /* Record statistics for this interface address. */ if (!(flags & IP_FORWARDING) && ia) { @@ -988,7 +978,8 @@ *mhip = *ip; if (hlen > sizeof (struct ip)) { mhlen = ip_optcopy(ip, mhip) + sizeof (struct ip); - mhip->ip_vhl = IP_MAKE_VHL(IPVERSION, mhlen >> 2); + mhip->ip_v = IPVERSION; + mhip->ip_hl = mhlen >> 2; } m->m_len = mhlen; mhip->ip_off = ((off - hlen) >> 3) + ip->ip_off; @@ -1012,13 +1003,8 @@ m->m_pkthdr.csum_flags = m0->m_pkthdr.csum_flags; mhip->ip_off = htons(mhip->ip_off); mhip->ip_sum = 0; - if (sw_csum & CSUM_DELAY_IP) { - if (mhip->ip_vhl == IP_VHL_BORING) { - mhip->ip_sum = in_cksum_hdr(mhip); - } else { - mhip->ip_sum = in_cksum(m, mhlen); - } - } + if (sw_csum & CSUM_DELAY_IP) + mhip->ip_sum = in_cksum(m, mhlen); *mnext = m; mnext = &m->m_nextpkt; nfrags++; @@ -1041,13 +1027,8 @@ ip->ip_off |= IP_MF; ip->ip_off = htons(ip->ip_off); ip->ip_sum = 0; - if (sw_csum & CSUM_DELAY_IP) { - if (ip->ip_vhl == IP_VHL_BORING) { - ip->ip_sum = in_cksum_hdr(ip); - } else { - ip->ip_sum = in_cksum(m, hlen); - } - } + if (sw_csum & CSUM_DELAY_IP) + ip->ip_sum = in_cksum(m, hlen); sendorfree: for (m = m0; m; m = m0) { m0 = m->m_nextpkt; @@ -1097,7 +1078,7 @@ u_short csum, offset; ip = mtod(m, struct ip *); - offset = IP_VHL_HL(ip->ip_vhl) << 2 ; + offset = ip->ip_hl << 2 ; csum = in_cksum_skip(m, ip->ip_len, offset); if (m->m_pkthdr.csum_flags & CSUM_UDP && csum == 0) csum = 0xffff; @@ -1169,7 +1150,8 @@ ip = mtod(m, struct ip *); bcopy(p->ipopt_list, ip + 1, optlen); *phlen = sizeof(struct ip) + optlen; - ip->ip_vhl = IP_MAKE_VHL(IPVERSION, *phlen >> 2); + ip->ip_v = IPVERSION; + ip->ip_hl = *phlen >> 2; ip->ip_len += optlen; return (m); } @@ -1187,7 +1169,7 @@ cp = (u_char *)(ip + 1); dp = (u_char *)(jp + 1); - cnt = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof (struct ip); + cnt = (ip->ip_hl << 2) - sizeof (struct ip); for (; cnt > 0; cnt -= optlen, cp += optlen) { opt = cp[0]; if (opt == IPOPT_EOL) @@ -2025,11 +2007,7 @@ ip->ip_len = htons(ip->ip_len); ip->ip_off = htons(ip->ip_off); ip->ip_sum = 0; - if (ip->ip_vhl == IP_VHL_BORING) { - ip->ip_sum = in_cksum_hdr(ip); - } else { - ip->ip_sum = in_cksum(copym, hlen); - } + ip->ip_sum = in_cksum(copym, hlen); /* * NB: * It's not clear whether there are any lingering Index: raw_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.100 diff -u -r1.100 raw_ip.c --- raw_ip.c 15 Aug 2002 18:51:26 -0000 1.100 +++ raw_ip.c 15 Oct 2002 22:06:09 -0000 @@ -59,7 +59,6 @@ #include #include -#define _IP_VHL #include #include #include @@ -263,10 +262,10 @@ ip = mtod(m, struct ip *); /* don't allow both user specified and setsockopt options, and don't allow packet length sizes that will crash */ - if (((IP_VHL_HL(ip->ip_vhl) != (sizeof (*ip) >> 2)) + if (((ip->ip_hl != (sizeof (*ip) >> 2)) && inp->inp_options) || (ip->ip_len > m->m_pkthdr.len) - || (ip->ip_len < (IP_VHL_HL(ip->ip_vhl) << 2))) { + || (ip->ip_len < (ip->ip_hl << 2))) { m_freem(m); return EINVAL; } Index: tcp_subr.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.143 diff -u -r1.143 tcp_subr.c --- tcp_subr.c 10 Oct 2002 21:41:30 -0000 1.143 +++ tcp_subr.c 15 Oct 2002 22:06:27 -0000 @@ -62,7 +62,6 @@ #include #include -#define _IP_VHL #include #include #include @@ -284,7 +283,8 @@ { struct ip *ip = (struct ip *) ip_ptr; - ip->ip_vhl = IP_VHL_BORING; + ip->ip_v = IPVERSION; + ip->ip_hl = 5; ip->ip_tos = 0; ip->ip_len = 0; ip->ip_id = 0; @@ -371,7 +371,7 @@ KASSERT(tp != NULL || m != NULL, ("tcp_respond: tp and m both NULL")); #ifdef INET6 - isipv6 = IP_VHL_V(((struct ip *)ipgen)->ip_vhl) == 6; + isipv6 = ((struct ip *)ipgen)->ip_v == 6; ip6 = ipgen; #endif /* INET6 */ ip = ipgen; @@ -1102,7 +1102,7 @@ if (ip) { s = splnet(); th = (struct tcphdr *)((caddr_t)ip - + (IP_VHL_HL(ip->ip_vhl) << 2)); + + (ip->ip_hl << 2)); INP_INFO_WLOCK(&tcbinfo); inp = in_pcblookup_hash(&tcbinfo, faddr, th->th_dport, ip->ip_src, th->th_sport, 0, NULL); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 15: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 E992337B401 for ; Tue, 15 Oct 2002 15:20:10 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 688F343E6E for ; Tue, 15 Oct 2002 15: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 <20021015222009.PLAG24958.sccrmhc03.attbi.com@InterJet.elischer.org>; Tue, 15 Oct 2002 22: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 PAA81728; Tue, 15 Oct 2002 15:18:03 -0700 (PDT) Date: Tue, 15 Oct 2002 15:18:02 -0700 (PDT) From: Julian Elischer To: Petri Helenius Cc: freebsd-net@freebsd.org Subject: Re: ENOBUFS In-Reply-To: <065901c27495$56a94c40$8c2a40c1@PHE> 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 Wed, 16 Oct 2002, Petri Helenius wrote: > > My processes writing to SOCK_DGRAM sockets are getting ENOBUFS > while netstat -s counter under the heading of "ip" is incrementing: > 7565828 output packets dropped due to no bufs, etc. > but netstat -m shows: my guess is that the interface has no more room in it's output queue.. when you get the error, back off a bit.. > > netstat -m > 579/1440/131072 mbufs in use (current/peak/max): > 578 mbufs allocated to data > 1 mbufs allocated to packet headers > 576/970/32768 mbuf clusters in use (current/peak/max) > 2300 Kbytes allocated to network (2% of mb_map in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > > Where should I start looking? The interface is em > > Pete > > > > 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 Tue Oct 15 15:26: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 BB40237B401; Tue, 15 Oct 2002 15:26:24 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F4D43E6A; Tue, 15 Oct 2002 15:26:24 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9FMQOpJ027014; Tue, 15 Oct 2002 15:26:24 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9FMQOAH027013; Tue, 15 Oct 2002 15:26:24 -0700 (PDT) (envelope-from rizzo) Date: Tue, 15 Oct 2002 15:26:24 -0700 From: Luigi Rizzo To: Poul-Henning Kamp Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: eliminating the _IP_VHL hack. Message-ID: <20021015152624.A26977@carp.icir.org> References: <60637.1034720233@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <60637.1034720233@critter.freebsd.dk>; from phk@FreeBSD.ORG on Wed, Oct 16, 2002 at 12:17:13AM +0200 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, Oct 16, 2002 at 12:17:13AM +0200, Poul-Henning Kamp wrote: ... > I would therefore propose to eliminate the _IP_VHL hack from the kernel yes, go for it. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 15:46:40 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 F3DC237B401; Tue, 15 Oct 2002 15:46:38 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CB8D43E65; Tue, 15 Oct 2002 15:46:38 -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 g9FMkagQ007724 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 15 Oct 2002 18:46:37 -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 g9FMka0o007721; Tue, 15 Oct 2002 18:46:36 -0400 (EDT) (envelope-from wollman) Date: Tue, 15 Oct 2002 18:46:36 -0400 (EDT) From: Garrett Wollman Message-Id: <200210152246.g9FMka0o007721@khavrinen.lcs.mit.edu> To: Poul-Henning Kamp Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: RFC: eliminating the _IP_VHL hack. In-Reply-To: <60637.1034720233@critter.freebsd.dk> References: <60637.1034720233@critter.freebsd.dk> 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: > In the meantime absolutely no code has picked up on this idea, It was copied in spirit from OSF/1. > The side effect of having some source-files using the _IP_VHL hack and > some not is that sizeof(struct ip) varies from file to file, Not so. Any compiler which allocates different amounts of storage to one eight-bit member versus two four-bit bitfield members is seriously broken (and would defeat the whole purpose). > I would therefore propose to eliminate the _IP_VHL hack from the kernel > to end this state of (potential) confusion, and invite comments to the > following patch: Much better to delete the bogus BYTE_ORDER kluge from ip.h. (Note that the definition of the bitfields in question has nothing whatsoever to do with the actual byte order in use; it simply relies on the historical behavior of compilers which allocated space for bitfields in BYTE_ORDER order.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 15:47: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 8B11437B401 for ; Tue, 15 Oct 2002 15:47:47 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEAB943E4A for ; Tue, 15 Oct 2002 15:47:46 -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 g9FMlkgQ007751 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 15 Oct 2002 18:47:46 -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 g9FMlkH7007748; Tue, 15 Oct 2002 18:47:46 -0400 (EDT) (envelope-from wollman) Date: Tue, 15 Oct 2002 18:47:46 -0400 (EDT) From: Garrett Wollman Message-Id: <200210152247.g9FMlkH7007748@khavrinen.lcs.mit.edu> To: "Petri Helenius" Cc: Subject: ENOBUFS In-Reply-To: <065901c27495$56a94c40$8c2a40c1@PHE> References: <065901c27495$56a94c40$8c2a40c1@PHE> 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: > My processes writing to SOCK_DGRAM sockets are getting ENOBUFS Probably means that your outgoing interface queue is filling up. ENOBUFS is the only way the kernel has to tell you ``slow down!''. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 15:56: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 6725337B401 for ; Tue, 15 Oct 2002 15:56:56 -0700 (PDT) Received: from 66-162-33-178.gen.twtelecom.net (66-162-33-178.gen.twtelecom.net [66.162.33.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E21243E4A for ; Tue, 15 Oct 2002 15:56:56 -0700 (PDT) (envelope-from steve@expertcity.com) Received: from [10.4.2.41] (helo=expertcity.com) by 66-162-33-178.gen.twtelecom.net with esmtp (Exim 3.22 #4) id 181acR-0005fG-00; Tue, 15 Oct 2002 15:56:55 -0700 Message-ID: <3DAC9D37.7060701@expertcity.com> Date: Tue, 15 Oct 2002 15:56:55 -0700 From: Steve Francis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Eggert Cc: Paul Herman , Kirill Ponomarew , freebsd-net@FreeBSD.ORG Subject: Re: delayed ACK References: <3DAC8206.1080604@isi.edu> 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 Lars Eggert wrote: >Paul Herman wrote: > > >>Not true. Although some bugs have been fixed in 4.3, FreeBSD's >>delayed ACKs will still degrade your performance dramatically in >>some cases. >> >> > >I'm sorry, but such statements without a packet trace that exhibits the >problem are just not useful. > >Lars > > He's probably referring to poorly behaved windows clients, on certain applications, if you leave net.inet.tcp.slowstart_flightsize at default. Incidentally, why are not the defaults on net.inet.tcp.slowstart_flightsize higher? RFC2414 seems to indicate it should be higher. Solaris in version 8 and later default to 4 for this value. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 16: 0: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 AB84837B401 for ; Tue, 15 Oct 2002 16:00:24 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35F5E43E6E for ; Tue, 15 Oct 2002 16:00:24 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9FN0JC03935; Tue, 15 Oct 2002 16:00:19 -0700 (PDT) Message-ID: <3DAC9E03.5070402@isi.edu> Date: Tue, 15 Oct 2002 16:00:19 -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: Steve Francis Cc: Paul Herman , Kirill Ponomarew , freebsd-net@FreeBSD.ORG Subject: Re: delayed ACK References: <3DAC8206.1080604@isi.edu> <3DAC9D37.7060701@expertcity.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060205080205030005080508" 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. --------------ms060205080205030005080508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Steve Francis wrote: >> > He's probably referring to poorly behaved windows clients, on certain > applications, if you leave net.inet.tcp.slowstart_flightsize at default. Ah. Well, that's a Windows problem :-) > Incidentally, why are not the defaults on > net.inet.tcp.slowstart_flightsize higher? > RFC2414 seems to indicate it should be higher. Solaris in version 8 and > later default to 4 for this value. I've been running with 4 for years w/o problems. so i'm all for the change. Lars -- Lars Eggert USC Information Sciences Institute --------------ms060205080205030005080508 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 hvcNAQkFMQ8XDTAyMTAxNTIzMDAxOVowIwYJKoZIhvcNAQkEMRYEFCX1IPVur/V/WozpDM2v RpK+gexmMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAJObheHHNLZYLyEJrOobZDVVvzMVReQHZ5yx1gFyLnsYq73SBNwmt nftn5/RjDo2D6NfwH5PUQ0jALOTxWN3jeE9S40aKDn65ALNKpaJPG1wpNFZgu3jf+GdiGpEU JE3EPbSJbRYRgk0TRADrhATsQWLHSivyVyf6Xa3q4KkWLGX2E4tHGMr/3x1niEo7d28BPfl4 7+TPvHea/SSybEfh7E6tkNQar12vC7s+r2PbEmdj93u0EXVoaHr95VR7CZozvMJMjA72Z3Nj PLL6F3pA7xaAusxFeoNPA3ycu/E8bMFvwtufIiwhLszIDm7vvXMOQRIUP/7R7VIE//8phB9F ggAAAAAAAA== --------------ms060205080205030005080508-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 16: 3: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 EBB9F37B401 for ; Tue, 15 Oct 2002 16:03:56 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15C8243E65 for ; Tue, 15 Oct 2002 16:03:56 -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 g9FN3pYj053715; Wed, 16 Oct 2002 02:03:55 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <068b01c2749f$32e7cf70$8c2a40c1@PHE> From: "Petri Helenius" To: "Lars Eggert" Cc: References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> Subject: Re: ENOBUFS Date: Wed, 16 Oct 2002 02:04:11 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 > > What rate are you sending these packets at? A standard interface queue > length is 50 packets, you get ENOBUFS when it's full. > This might explain the phenomenan. (packets are going out bursty, with average hovering at ~500Mbps:ish) I recomplied kernel with IFQ_MAXLEN of 5000 but there seems to be no change in the behaviour. How do I make sure that em-interface is running 66/64 and is there a way to see interface queue depth? em0: port 0x3040-0x307f mem 0xfc220000-0xfc23ffff irq 17 at device 3.0 on pci2 em0: Speed:1000 Mbps Duplex:Full pcib2: at device 29.0 on pci1 IOAPIC #2 intpin 0 -> irq 16 IOAPIC #2 intpin 6 -> irq 17 IOAPIC #2 intpin 7 -> irq 18 pci2: on pcib2 The OS is 4.7-RELEASE. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 16: 8: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 418F837B404 for ; Tue, 15 Oct 2002 16:08:15 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B72043E4A for ; Tue, 15 Oct 2002 16:08:14 -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 g9FN8CYj053735; Wed, 16 Oct 2002 02:08:13 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <06bb01c2749f$ce73e8c0$8c2a40c1@PHE> From: "Petri Helenius" To: "Garrett Wollman" Cc: References: <065901c27495$56a94c40$8c2a40c1@PHE> <200210152247.g9FMlkH7007748@khavrinen.lcs.mit.edu> Subject: Re: ENOBUFS Date: Wed, 16 Oct 2002 02:08:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 > > Probably means that your outgoing interface queue is filling up. > ENOBUFS is the only way the kernel has to tell you ``slow down!''. > How much should I be able to send to two em interfaces on one 66/64 PCI ? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 16:10: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 80F0437B401 for ; Tue, 15 Oct 2002 16:10:56 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A48443E7B for ; Tue, 15 Oct 2002 16:10:56 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9FNAupJ027482; Tue, 15 Oct 2002 16:10:56 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9FNAtmQ027481; Tue, 15 Oct 2002 16:10:55 -0700 (PDT) (envelope-from rizzo) Date: Tue, 15 Oct 2002 16:10:55 -0700 From: Luigi Rizzo To: Petri Helenius Cc: Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021015161055.A27443@carp.icir.org> References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <068b01c2749f$32e7cf70$8c2a40c1@PHE>; from pete@he.iki.fi on Wed, Oct 16, 2002 at 02:04:11AM +0300 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, Oct 16, 2002 at 02:04:11AM +0300, Petri Helenius wrote: > > > > What rate are you sending these packets at? A standard interface queue > > length is 50 packets, you get ENOBUFS when it's full. > > > This might explain the phenomenan. (packets are going out bursty, with average > hovering at ~500Mbps:ish) I recomplied kernel with IFQ_MAXLEN of 5000 > but there seems to be no change in the behaviour. How do I make sure that how large are the packets and how fast is the box ? on a fast box you should be able to generate packets faster than wire speed for sizes around 500bytes, meaning that you are going to saturate the queue no matter how large it is. cheers luigi > em-interface is running 66/64 and is there a way to see interface queue depth? > em0: port 0x3040-0x307f > mem 0xfc220000-0xfc23ffff irq 17 at device 3.0 on pci2 > em0: Speed:1000 Mbps Duplex:Full > pcib2: at device 29.0 on pci1 > IOAPIC #2 intpin 0 -> irq 16 > IOAPIC #2 intpin 6 -> irq 17 > IOAPIC #2 intpin 7 -> irq 18 > pci2: on pcib2 > > The OS is 4.7-RELEASE. > > Pete > > > > 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 Tue Oct 15 16:15: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 5DCA637B401 for ; Tue, 15 Oct 2002 16:15:28 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCC9843E6E for ; Tue, 15 Oct 2002 16:15:27 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9FNFMC13950; Tue, 15 Oct 2002 16:15:22 -0700 (PDT) Message-ID: <3DACA189.4030107@isi.edu> Date: Tue, 15 Oct 2002 16:15:21 -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: Petri Helenius Cc: Garrett Wollman , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS References: <065901c27495$56a94c40$8c2a40c1@PHE> <200210152247.g9FMlkH7007748@khavrinen.lcs.mit.edu> <06bb01c2749f$ce73e8c0$8c2a40c1@PHE> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050706080208040209060404" 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. --------------ms050706080208040209060404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Petri Helenius wrote: >>Probably means that your outgoing interface queue is filling up. >>ENOBUFS is the only way the kernel has to tell you ``slow down!''. >> > > How much should I be able to send to two em interfaces on one > 66/64 PCI ? I've seen netperf UDP throughputs of ~950Mpbs with a fiber em card and 4K datagrams on a 2.4Ghz P4. Lars -- Lars Eggert USC Information Sciences Institute --------------ms050706080208040209060404 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 hvcNAQkFMQ8XDTAyMTAxNTIzMTUyMVowIwYJKoZIhvcNAQkEMRYEFO8H3vbRhFb8XK+SenMv KNDD8JTWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAPbwyR/9sFFgnzT0709cBnyKrOsxHYwDYP6lcpzxV7kHEd0Q4Z+EO Flws+DkDvPtXRyvxW3dc8LfH5otaALNlo2iKr+ExwjLeKTnZfFhvhmfWHZ1PYY9I/qwKNaYk 2+fNEYhlHNjcqsdftnMlw54XLM5O9mF4Jk9ObJYxCG+v3t4mzXmDp9uzfYLwUJ4MMbnDdCrF x4L02z7MjTR+HNZ0Qfn/JslirHLHcfQtlGt4J483UEEV+NQOafWGLmJiyzTZccs4CtUhMXKD dmOr1nqJxdxSpn+YDBdP08W1FKWYz7t8g1iXYOBFy3VQAtpgVt3TA/A2uOXRxGwNptAvobmb gwAAAAAAAA== --------------ms050706080208040209060404-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 16:22: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 D28B637B404 for ; Tue, 15 Oct 2002 16:22:55 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 00DA143E6A for ; Tue, 15 Oct 2002 16:22:55 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 37692 invoked by uid 1000); 15 Oct 2002 23:22:56 -0000 Date: Tue, 15 Oct 2002 16:22:56 -0700 (PDT) From: Nate Lawson To: Poul-Henning Kamp Cc: net@freebsd.org, arch@freebsd.org Subject: Re: RFC: eliminating the _IP_VHL hack. In-Reply-To: <60637.1034720233@critter.freebsd.dk> 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 Wed, 16 Oct 2002, Poul-Henning Kamp wrote: > almost 7 years ago, this commit introduced the _IP_VHL hack in our > IP-stack: > > ] revision 1.7 > ] date: 1995/12/21 21:20:27; author: wollman; state: Exp; lines: +5 -1 > ] If _IP_VHL is defined, declare a single ip_vhl member in struct ip rather > ] than separate ip_v and ip_hl members. Should have no effect on current code, > ] but I'd eventually like to get rid of those obnoxious bitfields completely. > > We can argue a lot about how long time we should wait for "eventually", > but I would say that 7 years is far too long, considering the status: Fine by me. > RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v > retrieving revision 1.70 > diff -u -r1.70 ip_icmp.c > --- ip_icmp.c 1 Aug 2002 03:53:04 -0000 1.70 > +++ ip_icmp.c 15 Oct 2002 22:05:23 -0000 > @@ -51,7 +51,6 @@ > #include > #include > > -#define _IP_VHL > #include > #include > #include > @@ -128,7 +127,7 @@ > struct ifnet *destifp; > { > register struct ip *oip = mtod(n, struct ip *), *nip; > - register unsigned oiplen = IP_VHL_HL(oip->ip_vhl) << 2; > + register unsigned oiplen = oip->ip_hl << 2; > register struct icmp *icp; > register struct mbuf *m; > unsigned icmplen; > @@ -214,7 +213,8 @@ > nip = mtod(m, struct ip *); > bcopy((caddr_t)oip, (caddr_t)nip, sizeof(struct ip)); > nip->ip_len = m->m_len; > - nip->ip_vhl = IP_VHL_BORING; > + nip->ip_v = IPVERSION; > + nip->ip_hl = 5; I think there is a manifest constant for the default ipv4 header size but can't remember it right now. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 18:17: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 6A06C37B401 for ; Tue, 15 Oct 2002 18:17:57 -0700 (PDT) Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id F284543E77 for ; Tue, 15 Oct 2002 18:17:56 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from mammoth.eat.frenchfries.net (da001d0174.lax-ca.osd.concentric.net [64.0.144.175]) by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g9G065c04297 for ; Tue, 15 Oct 2002 17:06:06 -0700 Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000) id E22644A22; Tue, 15 Oct 2002 17:25:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mammoth.eat.frenchfries.net (Postfix) with ESMTP id DE3764A20; Tue, 15 Oct 2002 17:25:42 -0700 (PDT) Date: Tue, 15 Oct 2002 17:25:42 -0700 (PDT) From: Paul Herman X-X-Sender: pherman@mammoth.eat.frenchfries.net To: Lars Eggert Cc: Steve Francis , Kirill Ponomarew , Subject: Re: delayed ACK In-Reply-To: <3DAC8206.1080604@isi.edu> Message-ID: <20021015162359.B8363-100000@mammoth.eat.frenchfries.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 On Tue, 15 Oct 2002, Lars Eggert wrote: > Paul Herman wrote: > > > > Not true. Although some bugs have been fixed in 4.3, FreeBSD's > > delayed ACKs will still degrade your performance dramatically in > > some cases. > > I'm sorry, but such statements without a packet trace that exhibits the > problem are just not useful. Aha! Another victim who is willing to take a look at this! :-) It's an issue that was left unresolved in kern/24645. Bruce Evans brought this to my attention back during the unrelated "I have delayed ACK problems" thread on -net in January of 2001 and I then passed it on to jlemon. If you need a packet trace, let me know, but you should be able to reproduce it yourself. Even today on my 4.7-PRERELEASE I still get: mammoth# sysctl net.inet.tcp.delayed_ack=0 net.inet.tcp.delayed_ack: 1 -> 0 mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel 0.000u 0.041s 0:00.33 12.1% 350+300k 0+0io 0pf+0w mammoth# sysctl net.inet.tcp.delayed_ack=1 net.inet.tcp.delayed_ack: 0 -> 1 mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel 0.014u 0.033s 0:45.90 0.0% 700+600k 0+0io 0pf+0w ^^^^^^^ It seems that lowering lo0 mtu to 1500 makes this particular problem go away. The magic mtu size is 2100. This makes me think that this is a big problem across GigE using 8K jumbo frames, not sure. Also, taring over the IPv6 lo0 interface seems to work OK. No idea what causes this. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 18:22: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 C635437B401; Tue, 15 Oct 2002 18:22:54 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 819B643E7B; Tue, 15 Oct 2002 18:22:54 -0700 (PDT) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H41001UMVU5KX@mta5.snfc21.pbi.net>; Tue, 15 Oct 2002 18:22:54 -0700 (PDT) Date: Tue, 15 Oct 2002 18:23:22 -0700 From: Jeffrey Hsu Subject: Re: RFC: eliminating the _IP_VHL hack. In-reply-to: Message from Poul-Henning Kamp "of Wed, 16 Oct 2002 00:17:13 +0200." <60637.1034720233@critter.freebsd.dk> To: Poul-Henning Kamp Cc: net@freebsd.org, arch@freebsd.org Message-id: <0H41001UNVU5KX@mta5.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 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 > The side effect of having some source-files using the _IP_VHL hack and > some not is that sizeof(struct ip) varies from file to file, which at > best is confusing an at worst the source of some really evil bugs. > I would therefore propose to eliminate the _IP_VHL hack from the kernel > to end this state of (potential) confusion This problem could be solved more easily by changing the u_int back to an u_char, as it used to be before rev 1.15: Index: ip.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip.h,v retrieving revision 1.19 diff -u -r1.19 ip.h --- ip.h 14 Dec 2001 19:37:32 -0000 1.19 +++ ip.h 16 Oct 2002 01:15:48 -0000 @@ -51,11 +51,11 @@ u_char ip_vhl; /* version << 4 | header length >> 2 */ #else #if BYTE_ORDER == LITTLE_ENDIAN - u_int ip_hl:4, /* header length */ + u_char ip_hl:4, /* header length */ ip_v:4; /* version */ #endif #if BYTE_ORDER == BIG_ENDIAN - u_int ip_v:4, /* version */ + u_char ip_v:4, /* version */ ip_hl:4; /* header length */ #endif #endif /* not _IP_VHL */ But, if we were to pick one or the other to discard, I would keep the IP_VHL because that field really is a byte in the IP header To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 18:30: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 ABB1F37B401 for ; Tue, 15 Oct 2002 18:30:46 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F0E343E7B for ; Tue, 15 Oct 2002 18:30:46 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9G1UipJ029135; Tue, 15 Oct 2002 18:30:44 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9G1Ui2C029134; Tue, 15 Oct 2002 18:30:44 -0700 (PDT) (envelope-from rizzo) Date: Tue, 15 Oct 2002 18:30:44 -0700 From: Luigi Rizzo To: Paul Herman Cc: Lars Eggert , Steve Francis , Kirill Ponomarew , freebsd-net@FreeBSD.ORG Subject: Re: delayed ACK Message-ID: <20021015183044.A29061@carp.icir.org> References: <3DAC8206.1080604@isi.edu> <20021015162359.B8363-100000@mammoth.eat.frenchfries.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021015162359.B8363-100000@mammoth.eat.frenchfries.net>; from pherman@frenchfries.net on Tue, Oct 15, 2002 at 05:25:42PM -0700 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 smells a lot as a bad interaction between default window size and mtu -- loopback has 16k default, maybe tar uses a smallish window (32k is default now for net.inet.tcp.sendspace, but used to be 16k at the time), which means only 1 or 2 packets in flight at once, meaning that many times you get the 200ms delay and your throughput goes way down. cheers luigi On Tue, Oct 15, 2002 at 05:25:42PM -0700, Paul Herman wrote: ... > Aha! Another victim who is willing to take a look at this! :-) > > It's an issue that was left unresolved in kern/24645. Bruce Evans > brought this to my attention back during the unrelated "I have > delayed ACK problems" thread on -net in January of 2001 and I then > passed it on to jlemon. If you need a packet trace, let me know, > but you should be able to reproduce it yourself. Even today on my > 4.7-PRERELEASE I still get: > > mammoth# sysctl net.inet.tcp.delayed_ack=0 > net.inet.tcp.delayed_ack: 1 -> 0 > mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel > 0.000u 0.041s 0:00.33 12.1% 350+300k 0+0io 0pf+0w > > mammoth# sysctl net.inet.tcp.delayed_ack=1 > net.inet.tcp.delayed_ack: 0 -> 1 > mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel > 0.014u 0.033s 0:45.90 0.0% 700+600k 0+0io 0pf+0w > ^^^^^^^ > > It seems that lowering lo0 mtu to 1500 makes this particular > problem go away. The magic mtu size is 2100. This makes me think > that this is a big problem across GigE using 8K jumbo frames, not > sure. Also, taring over the IPv6 lo0 interface seems to work OK. > > No idea what causes this. > > -Paul. > > > 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 Tue Oct 15 18:48:28 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 C84AC37B404 for ; Tue, 15 Oct 2002 18:48:23 -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 5F5AD43E88 for ; Tue, 15 Oct 2002 18:48:23 -0700 (PDT) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d163.as28.nwbl0.wi.voyager.net [169.207.71.229]) by out1.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id BEE25E3FC2; Tue, 15 Oct 2002 20:48:02 -0500 (CDT) Date: Tue, 15 Oct 2002 20:52:49 -0500 (CDT) From: Mike Silbersack To: Luigi Rizzo Cc: Paul Herman , Lars Eggert , Steve Francis , Kirill Ponomarew , Subject: Re: delayed ACK In-Reply-To: <20021015183044.A29061@carp.icir.org> Message-ID: <20021015204614.L21041-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 Tue, 15 Oct 2002, Luigi Rizzo wrote: > this smells a lot as a bad interaction between default window > size and mtu -- loopback has 16k default, maybe tar uses a > smallish window (32k is default now for net.inet.tcp.sendspace, > but used to be 16k at the time), which means only 1 or 2 packets in > flight at once, meaning that many times you get the 200ms delay > and your throughput goes way down. > > cheers > luigi NetBSD introduced a "fix" for this recently, it seems sorta hackish, but maybe we need to do something similar. The diff reminds me why FreeBSD has a policy of seperating style and functional commits, fwiw. :) http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/netinet/tcp_output.c.diff?r1=1.84&r2=1.85 Revision 1.85 / (download) - annotate - [select for diffs], Tue Aug 20 16:29:42 2002 UTC (8 weeks ago) by thorpej Branch: MAIN CVS Tags: gehenna-devsw-base Changes since 1.84: +18 -4 lines Diff to previous 1.84 (colored) Never send more than half a socket buffer of data. This insures that we can always keep 2 packets on the wire, no matter what SO_SNDBUF is, and therefore ACKs will never be delayed unless we run out of data to transmit. The problem is quite easy to tickle when the MTU of the outgoing interface is larger than the socket buffer size (e.g. loopback). Fix from Charles Hannum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 18:53:44 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 14D9B37B408 for ; Tue, 15 Oct 2002 18:53:43 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4EF043E9E for ; Tue, 15 Oct 2002 18:53:39 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9G1rcpJ029422; Tue, 15 Oct 2002 18:53:38 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9G1rcj6029421; Tue, 15 Oct 2002 18:53:38 -0700 (PDT) (envelope-from rizzo) Date: Tue, 15 Oct 2002 18:53:38 -0700 From: Luigi Rizzo To: Mike Silbersack Cc: Paul Herman , Lars Eggert , Steve Francis , Kirill Ponomarew , freebsd-net@FreeBSD.ORG Subject: Re: delayed ACK Message-ID: <20021015185338.A29388@carp.icir.org> References: <20021015183044.A29061@carp.icir.org> <20021015204614.L21041-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021015204614.L21041-100000@patrocles.silby.com>; from silby@silby.com on Tue, Oct 15, 2002 at 08:52:49PM -0500 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 Tue, Oct 15, 2002 at 08:52:49PM -0500, Mike Silbersack wrote: ... > NetBSD introduced a "fix" for this recently, it seems sorta hackish, but > maybe we need to do something similar. this helps you if the other side has delayed acks, but halves the throughput if you are being window limited and the other side does not use delayed acks (can you force immediate acks by setting the PUSH flag in the tcp header ?) cheers luigi > > http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/netinet/tcp_output.c.diff?r1=1.84&r2=1.85 > > Revision 1.85 / (download) - annotate - [select for diffs], Tue Aug 20 > 16:29:42 2002 UTC (8 weeks ago) by thorpej > Branch: MAIN > CVS Tags: gehenna-devsw-base > Changes since 1.84: +18 -4 lines > Diff to previous 1.84 (colored) > > Never send more than half a socket buffer of data. This insures that > we can always keep 2 packets on the wire, no matter what SO_SNDBUF is, > and therefore ACKs will never be delayed unless we run out of data to > transmit. The problem is quite easy to tickle when the MTU of the > outgoing interface is larger than the socket buffer size (e.g. loopback). > > Fix from Charles Hannum. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 20:31: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 AF3DA37B401 for ; Tue, 15 Oct 2002 20:31:47 -0700 (PDT) Received: from out5.mx.nwbl.wi.voyager.net (out5.mx.nwbl.wi.voyager.net [169.207.3.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4370043E91 for ; Tue, 15 Oct 2002 20:31:47 -0700 (PDT) (envelope-from silby@silby.com) Received: from [10.1.1.6] (d163.as28.nwbl0.wi.voyager.net [169.207.71.229]) by out5.mx.nwbl.wi.voyager.net (Postfix) with ESMTP id E596DC6D1A; Tue, 15 Oct 2002 22:31:44 -0500 (CDT) Date: Tue, 15 Oct 2002 22:36:32 -0500 (CDT) From: Mike Silbersack To: Luigi Rizzo Cc: Paul Herman , Lars Eggert , Steve Francis , Kirill Ponomarew , Subject: Re: delayed ACK In-Reply-To: <20021015185338.A29388@carp.icir.org> Message-ID: <20021015222156.F21041-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 Tue, 15 Oct 2002, Luigi Rizzo wrote: > On Tue, Oct 15, 2002 at 08:52:49PM -0500, Mike Silbersack wrote: > ... > > NetBSD introduced a "fix" for this recently, it seems sorta hackish, but > > maybe we need to do something similar. > > this helps you if the other side has delayed acks, but halves the > throughput if you are being window limited and the other side does not > use delayed acks (can you force immediate acks by setting the PUSH flag > in the tcp header ?) > > cheers > luigi I think the comment is slightly misleading, and that it won't actually cause any performance problems as you suggest. From what I recall, immediate acking of PUSH packets varies... Linux appears to have changed back and forth on whether it does so or not. I also seem to recall Windows making a change too. Either way, we probably shouldn't rely on that behavior alone. > > Never send more than half a socket buffer of data. This insures that > > we can always keep 2 packets on the wire, no matter what SO_SNDBUF is, > > and therefore ACKs will never be delayed unless we run out of data to > > transmit. The problem is quite easy to tickle when the MTU of the > > outgoing interface is larger than the socket buffer size (e.g. loopback). If I'm reading the implementation correctly, what this means is that if you have a single packet > .5*socketbuffer, you reduce the maximum *segment* size, causing two smaller packets to be sent instead of one large packet. (Smaller still being 8K in size.) While such a change might help with localhost, I have this sneaky suspicion that it falls apart when applied to jumbo frames and 32K send buffers. Someone well motivated should be able to come up with a more general heuristic. 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 Tue Oct 15 22:56: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 5F0A837B401 for ; Tue, 15 Oct 2002 22:56:57 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08F2843E77 for ; Tue, 15 Oct 2002 22:56:56 -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 g9G5unYj056127; Wed, 16 Oct 2002 08:56:54 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <06c901c274d8$e5280b80$8c2a40c1@PHE> From: "Petri Helenius" To: "Luigi Rizzo" Cc: "Lars Eggert" , References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> Subject: Re: ENOBUFS Date: Wed, 16 Oct 2002 08:57:19 +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 > > how large are the packets and how fast is the box ? Packets go out at an average size of 1024 bytes. The box is dual P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled hyperthreading to figure out if it was causing problems. I seem to be able to send packets at a rate in the 900Mbps when just sending them out with a process. If I do similar sending on two interfaces at same time, it tops out at 600Mbps. The information I´m looking for is how to instrument where the bottleneck is to either tune the parameters or report a bug in PCI or em code. (or just simply swap the GE hardware to something that works better) Pete > on a fast box you should be able to generate packets faster than wire > speed for sizes around 500bytes, meaning that you are going to saturate > the queue no matter how large it is. > > cheers > luigi > > > em-interface is running 66/64 and is there a way to see interface queue depth? > > em0: port 0x3040-0x307f > > mem 0xfc220000-0xfc23ffff irq 17 at device 3.0 on pci2 > > em0: Speed:1000 Mbps Duplex:Full > > pcib2: at device 29.0 on pci1 > > IOAPIC #2 intpin 0 -> irq 16 > > IOAPIC #2 intpin 6 -> irq 17 > > IOAPIC #2 intpin 7 -> irq 18 > > pci2: on pcib2 > > > > The OS is 4.7-RELEASE. > > > > Pete > > > > > > > > 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 Tue Oct 15 23: 5:36 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 DACB337B401 for ; Tue, 15 Oct 2002 23:05:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C45543E75 for ; Tue, 15 Oct 2002 23:05:33 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-157.we.client2.attbi.com [24.130.112.157]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9G65UC18513; Tue, 15 Oct 2002 23:05:30 -0700 (PDT) Message-ID: <3DAD01A7.3020807@isi.edu> Date: Tue, 15 Oct 2002 23:05:27 -0700 From: Lars Eggert Organization: USC Information Sciences Institute 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: Petri Helenius Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040303050100000105070307" 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. --------------ms040303050100000105070307 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Petri Helenius wrote: >>how large are the packets and how fast is the box ? > > > Packets go out at an average size of 1024 bytes. The box is dual > P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled > hyperthreading to figure out if it was causing problems. I seem to > be able to send packets at a rate in the 900Mbps when just sending > them out with a process. If I do similar sending on two interfaces at > same time, it tops out at 600Mbps. The 900Mbps are similar to what I see here on similar hardware. For your two-interface setup, are the 600Mbps aggregate send rate on both interfaces, or do you see 600Mbps per interface? In the latter case, is your CPU maxed out? Only one can be in the kernel under -stable, so the second one won't help much. With small packets like that, you may be interrupt-bound. (Until Luigi releases polling for em interfaces... :-) Lars -- Lars Eggert USC Information Sciences Institute --------------ms040303050100000105070307 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 hvcNAQkFMQ8XDTAyMTAxNjA2MDUyN1owIwYJKoZIhvcNAQkEMRYEFO6Ne28+iM5256TSEwNx DpvH8TxvMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEACFCOwDT/U6KEjz/8B0lcL2e6ps4RpfjK+Hl0NrDpnh5yAsMexPNE O5N54Z4f24OoBFvahERHiOxFkZoqrZURZMjVISgvBnymc9njzrXQDCyRS1lXUI7+iPJs8PlH 8xgUU4Fr1WVS9P8m6IvU9oh1GcMyFzsbqrwyG4Abw4ZQXzU/dCPculzyh+VOvkIEP0gNtTgM pDow5QkttKYs7+pRVaP9lQIMqk8tjcuJLF/Zoao+G6roMgVw7B11QsyKodx6s4+XyThJt1WW uDtE+AjLaDQ7BUsAlSXskhix3kdyJ+tRdelzDyb/KgYsp2v6WqteXO2GAiH3zu24ZsoppaTs DwAAAAAAAA== --------------ms040303050100000105070307-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 23:13: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 6D05237B401 for ; Tue, 15 Oct 2002 23:13:08 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E9C543E75 for ; Tue, 15 Oct 2002 23:13:07 -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 g9G6CpYj056250; Wed, 16 Oct 2002 09:13:06 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <071501c274db$222c3ea0$8c2a40c1@PHE> From: "Petri Helenius" To: "Lars Eggert" Cc: "Luigi Rizzo" , References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> Subject: Re: ENOBUFS Date: Wed, 16 Oct 2002 09:13:20 +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 > The 900Mbps are similar to what I see here on similar hardware. What kind of receive performance do you observe? I haven´t got that far yet. > > For your two-interface setup, are the 600Mbps aggregate send rate on > both interfaces, or do you see 600Mbps per interface? In the latter 600Mbps per interface. I´m going to try this out also on -CURRENT to see if it changes anything. Interrupts do not seem to pose a big problem because I´m seeing only a few thousand em interrupts a second but since every packet involves a write call there are >100k syscalls a second. > case, is your CPU maxed out? Only one can be in the kernel under > -stable, so the second one won't help much. With small packets like > that, you may be interrupt-bound. (Until Luigi releases polling for em > interfaces... :-) > I´ll try changing the packet sizes to figure out optimum. Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 23:27: 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 5242F37B401 for ; Tue, 15 Oct 2002 23:27:02 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id C392A43E7B for ; Tue, 15 Oct 2002 23:27:01 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-157.we.client2.attbi.com [24.130.112.157]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9G6QwC27173; Tue, 15 Oct 2002 23:26:58 -0700 (PDT) Message-ID: <3DAD06AF.7060701@isi.edu> Date: Tue, 15 Oct 2002 23:26:55 -0700 From: Lars Eggert Organization: USC Information Sciences Institute 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: Petri Helenius Cc: Luigi Rizzo , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030403000307050700010406" 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. --------------ms030403000307050700010406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Petri Helenius wrote: >>The 900Mbps are similar to what I see here on similar hardware. > > What kind of receive performance do you observe? I haven´t got that > far yet. Less :-) Let me tell you tomorrow, don't have the numbers here right now. > 600Mbps per interface. I´m going to try this out also on -CURRENT > to see if it changes anything. Interrupts do not seem to pose a big > problem because I´m seeing only a few thousand em interrupts > a second but since every packet involves a write call there are >100k > syscalls a second. So maybe syscalls/second are the bottleneck. On -current, try enabling zero copy sockets, it seems to help somewhat. Other than that, I've not found -current to be much different in terms of performance. If you're just interested in maxing throughput, try sending over TCP with large write sizes. In that case, syscall overhead is less, since you amortize it over multiple packets. (But there are different issues that can limit TCP throughput.) > I´ll try changing the packet sizes to figure out optimum. I think I remember that 4K packets were fastest with the em hardware in our case. Lars -- Lars Eggert USC Information Sciences Institute --------------ms030403000307050700010406 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 hvcNAQkFMQ8XDTAyMTAxNjA2MjY1NlowIwYJKoZIhvcNAQkEMRYEFD36vhZZkvEWWBaPtx6C bYmG5FwGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAgb7brqshaM0ANtPz5lLGDYZfzjnHLv+UyQGn5mnFpmQnL9YDMfiL xJnhfFT+nzIo9s5r+pE/c/InovmCyVvlPxNeQw8kGi98e4KAGMcvaEfdOrcS8R3+7Tjgeqoj TPXWtEe/fjXVdQj/GfYh7/sNEc5QZLhjuYV5KBymAeqAWNSLTaVjrI5T4YinqmMC3JpyqUf0 AqR0Kq3BK6QAZ62pUZs3AqIGcTXCIyxvT0C7aYDHWMBrd05G6L5J5qdp1u24dctNZRjA/VNp +zk29jttkZ1p+7M8/BouAnL2C9e9lq55lanlear9HRpMyvcLR4oX/zPjfnV3U3r5vaPL6MNs IQAAAAAAAA== --------------ms030403000307050700010406-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Oct 15 23:39: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 04E3137B401; Tue, 15 Oct 2002 23:39:48 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 278AC43E6E; Tue, 15 Oct 2002 23:39:47 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9G6deIw051939; Wed, 16 Oct 2002 08:39:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Garrett Wollman Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: eliminating the _IP_VHL hack. In-Reply-To: Your message of "Tue, 15 Oct 2002 18:46:36 EDT." <200210152246.g9FMka0o007721@khavrinen.lcs.mit.edu> Date: Wed, 16 Oct 2002 08:39:40 +0200 Message-ID: <51938.1034750380@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <200210152246.g9FMka0o007721@khavrinen.lcs.mit.edu>, Garrett Wollman writes: >Much better to delete the bogus BYTE_ORDER kluge from ip.h. (Note >that the definition of the bitfields in question has nothing >whatsoever to do with the actual byte order in use; it simply relies >on the historical behavior of compilers which allocated space for >bitfields in BYTE_ORDER order.) Do you intend to complete the task you originally started ? What is your plan for 3rd party software ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 0: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 03A5437B401; Wed, 16 Oct 2002 00:52:53 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6747B43EAF; Wed, 16 Oct 2002 00:52:51 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA05653; Wed, 16 Oct 2002 17:52:48 +1000 Date: Wed, 16 Oct 2002 18:03:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Jeffrey Hsu Cc: Poul-Henning Kamp , , Subject: Re: RFC: eliminating the _IP_VHL hack. In-Reply-To: <0H41001UNVU5KX@mta5.snfc21.pbi.net> Message-ID: <20021016172019.W4358-100000@gamplex.bde.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 On Tue, 15 Oct 2002, Jeffrey Hsu wrote: > > The side effect of having some source-files using the _IP_VHL hack and > > some not is that sizeof(struct ip) varies from file to file, which at > > best is confusing an at worst the source of some really evil bugs. There is no such effect, or ip would not work. Bitfields are inherently unportable, but here everything is carefully packed so that there is a good chance that both versions give the same struct layout for all non-broken compilers (the layout needs to be compiler-independent too). > > I would therefore propose to eliminate the _IP_VHL hack from the kernel > > to end this state of (potential) confusion This would remove the least unportable version. > This problem could be solved more easily by changing the u_int back > to an u_char, as it used to be before rev 1.15: > > Index: ip.h > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip.h,v > retrieving revision 1.19 > diff -u -r1.19 ip.h > --- ip.h 14 Dec 2001 19:37:32 -0000 1.19 > +++ ip.h 16 Oct 2002 01:15:48 -0000 > @@ -51,11 +51,11 @@ > u_char ip_vhl; /* version << 4 | header length >> 2 */ > #else > #if BYTE_ORDER == LITTLE_ENDIAN > - u_int ip_hl:4, /* header length */ > + u_char ip_hl:4, /* header length */ > ip_v:4; /* version */ > #endif > #if BYTE_ORDER == BIG_ENDIAN > - u_int ip_v:4, /* version */ > + u_char ip_v:4, /* version */ > ip_hl:4; /* header length */ > #endif > #endif /* not _IP_VHL */ > > But, if we were to pick one or the other to discard, I would keep the > IP_VHL because that field really is a byte in the IP header This would just guarantee unportable behaviour by untranslating from C. C compilers reject bit-fields that are declared to have u_char, since u_char is not a permitted type for a bit-field. E.g., from the C99 draft n869.txt: 6.7.2.1 Language 6.7.2.1 WG14/N869 Committee Draft -- January 18, 1999 115 [#8] A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, or unsigned int. ... Little is lost by restricting the type of a bitfield in this way, since the width of a bitfield can be determined without lokking at its type. Bit-fields that are declared to have types other than the standard types for them are a poorly documented gcc extension. The type of a bit-field has little or no affect on packing of bits near the bitfield, at least if everything is packed manually. However, the types of bit-fields within a struct affects padding at the end of a struct in a (usually) less than useful way: if a standard standard type is used, then structs get padded if necessary to give alignment of that type. E.g., on i386's the following structs have size 4 although you probably want them to have size 1: struct foo1 { int bar: 1; }; struct foo2 { int bar: 8; }; TenDRA is bug-for-bug compatible with gcc here. This can be worked around if the compiler is gcc by declaring the struct as __packed (__aligned(1) doesn't seem to work), or by declaring the bit-field type as char, or on some systems by using -mno-bit-align. These workarounds are even more unportable than bit-fields. However, there is no problem with struct ip yet, because everything is manually packed to work with "all" C compilers on "all" systems. This will break on systems with 64-bit ints, since sizeof(struct ip) == 20 is not a multiple of 8. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 1:16: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 4FA1737B401; Wed, 16 Oct 2002 01:16:54 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81E3C43E77; Wed, 16 Oct 2002 01:16:53 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9G8GeIw069414; Wed, 16 Oct 2002 10:16:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: Jeffrey Hsu , net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: eliminating the _IP_VHL hack. In-Reply-To: Your message of "Wed, 16 Oct 2002 18:03:24 +1000." <20021016172019.W4358-100000@gamplex.bde.org> Date: Wed, 16 Oct 2002 10:16:40 +0200 Message-ID: <69413.1034756200@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <20021016172019.W4358-100000@gamplex.bde.org>, Bruce Evans writes: >On Tue, 15 Oct 2002, Jeffrey Hsu wrote: > >> > The side effect of having some source-files using the _IP_VHL hack and >> > some not is that sizeof(struct ip) varies from file to file, which at >> > best is confusing an at worst the source of some really evil bugs. > >There is no such effect, or ip would not work. s/,/ with our current compilers and architectures,/ >> > I would therefore propose to eliminate the _IP_VHL hack from the kernel >> > to end this state of (potential) confusion > >This would remove the least unportable version. Could be, but there is no point in us having two different versions, neither of which is guaranteed to be portable, in particular when one of the two is private to FreeBSD and not even consistently used there. For reference: NetBSD hasn't got the _IP_VHL but has a __packed__ on the structure. OpenBSD hasn't got the _IP_VHL either, but hasn't adopted the __packed__ from NetBSD. Linux also uses bitfields and endianess #ifdefs. >These workarounds are even more unportable than bit-fields. However, >there is no problem with struct ip yet, because everything is manually >packed to work with "all" C compilers on "all" systems. This will >break on systems with 64-bit ints, since sizeof(struct ip) == 20 is >not a multiple of 8. Good point. I'll ammend my proposal to include a __packed__ and a CTASSERT on the size of struct ip == 20. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 2:31: 0 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 6A8D937B401 for ; Wed, 16 Oct 2002 02:30:57 -0700 (PDT) Received: from chung.yikes.com (dsl-65-184-72-125.telocity.com [65.184.72.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABDCE43EAC for ; Wed, 16 Oct 2002 02:30:56 -0700 (PDT) (envelope-from leonardc@cs.berkeley.edu) Received: from feather ([10.0.1.250]) by chung.yikes.com (8.12.3/8.11.6) with SMTP id g9G9Uods035690; Wed, 16 Oct 2002 02:30:51 -0700 (PDT) (envelope-from leonardc@cs.berkeley.edu) From: "Leonard Chung" To: "Archie Cobbs" Cc: Subject: RE: MPD PPTP tunneling intermittantly fails Date: Wed, 16 Oct 2002 02:30:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200210142144.g9ELi3AT084595@arch20m.dellroad.org> 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 I'm just using Windows clients, so there are no OS X clients. Here's the ngctl output: chung# ngctl msg ng0:inet.ppp.link0 getstats Rec'd response "getstats" (3) from "ng0:inet.ppp.link0": Args: { xmitPackets=1967 xmitOctets=209321 xmitLoneAcks=395 xmitDrops=345 recvPackets=1590 recvOctets=248518 recvAckTimeouts=55 } As you can tell, the connection hasn't transmitted much data before it's already become problematic. The drop count to packet count on transmits and timeouts on recv's seems awfully high given everything is just on a local area network. Here's my physical topology: Inside 10.0.0.0/8 <--------> {10.0.0.1 - MPD Machine - 192.168.0.1} <-------> 192.168.0.0/24 Protected clients | | Outside Internet IP -> Each net address on the MPD machine has its own Ethernet card. In addition, pinging the MPD machine from either side results in no packet loss and <1ms latency. Here's some more information if that helps: chung# kldstat Id Refs Address Size Name 1 10 0xc0100000 2bce78 kernel 2 9 0xc0b71000 9000 netgraph.ko 3 1 0xc0b7a000 3000 ng_socket.ko 4 1 0xc0b7d000 3000 ng_iface.ko 5 1 0xc0b80000 6000 ng_ppp.ko 6 1 0xc0b86000 4000 ng_bpf.ko 7 1 0xc0b8a000 4000 ng_vjc.ko 8 1 0xc0b8e000 4000 ng_pptpgre.ko 9 1 0xc0b93000 4000 ng_ksocket.ko 10 1 0xc0b98000 3000 ng_mppc.ko chung# uname -a FreeBSD chung.yikes.com 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Wed Aug 28 00:07:12 PDT 2002 leonard@chung.yikes.com:/usr/obj/usr/src/sys/CHUNG_KERN_FW i386 Thanks for your help, Leonard -----Original Message----- From: Archie Cobbs [mailto:archie@dellroad.org] Sent: Monday, October 14, 2002 2:44 PM To: Leonard Chung Cc: freebsd-net@FreeBSD.ORG Subject: Re: MPD PPTP tunneling intermittantly fails Leonard Chung writes: > The problem that I'm having is that MPD starts properly and I can > successfully connect to the service using Windows clients. However, when I > ping internal hosts, the first five or so work fine, and then beyond that > packets start getting lost, with a loss rate of around 50%. These tests are > run over a local network with two subnets, so packet loss shouldn't be a > problem. So although I can currently connect and create a tunnel, it isn't > very useful as beyond any initial DNS queries, file transfers, etc. fail > completely. Are you using Mac OS X clients? If so, you may need the latest patch to ng_pptpgre(4) to work around a problem: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_pptpgre.c.diff?r1= 1.25&r2=1.26 Otherwise, I haven't heard of anyone else having that particular problem.. See if you have errors reported by 'ngctl msg ng0:inet.ppp.link0 getstats' (replace 'ng0' with the appropriate inteface name). > Also, is there any way to get DHCP to work with MPD rather than hard wire > IPs directly into MPD's config files? Unfortunately not. > I'm guessing this is probably just something easy that I'm missing. My > config files and an MPD trace are below. These look reasonable. -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 Wed Oct 16 3: 3: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 8D06B37B404; Wed, 16 Oct 2002 03:03:27 -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 2437F43EAA; Wed, 16 Oct 2002 03:03:26 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:14e:a4d1:f898:6ed5]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9GA2mt66864; Wed, 16 Oct 2002 19:02:48 +0900 (JST) Date: Wed, 16 Oct 2002 19:03:33 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Sam Leffler" Cc: "Julian Elischer" , , Subject: Re: CFR: m_tag patch In-Reply-To: <080101c27151$b2e92a30$52557f42@errno.com> References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> <080101c27151$b2e92a30$52557f42@errno.com> 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: 59 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, 11 Oct 2002 11:12:02 -0700, >>>>> "Sam Leffler" said: >> > struct m_tag { >> > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags > */ >> > u_int16_t m_tag_id; /* Tag ID */ >> > u_int16_t m_tag_len; /* Length of data */ >> > u_int32_t m_tag_cookie; /* Module/ABI */ >> > }; (snip) >> Sorry for interrupting, but please let me make it sure. Do you intend >> to hide the additional member from other modules than the m_tag >> internal? I'm afraid a story that (e.g.) some code fragments in the >> network layer directly refers to m_tag_cookie, which will break source >> level compatibility with other BSDs (when the code fragments are >> shared with others). As suz said before, we (KAME) are very much >> afraid of this kind of story. > The changes I'm proposing for KAME code make no references to m_tag_cookie. > Things should be clear when you have a patch to look at. I know that, but what I'm worrying about is a story that *.c under netinet[6] will have a direct reference to m_tag_cookie *in the future". Then we'll need to separate the code fragments like this: #if defined(__FreeBSD__) && && __FreeBSD__ >= 5 if (mtag->m_tag_cookie != PACKET_TAG_IPSEC_OUT_DONE && mtag->m_tag_cookie != PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED) continue; #else if (mtag->m_tag_id != PACKET_TAG_IPSEC_OUT_DONE && mtag->m_tag_id != PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED) continue; #endif (derived from the current KAME's ip6_output.c) We've experienced a lot of headaches due to this type of incompatibility. I fully understand that once some changes are incorporated to a particular BSD, the BSD developers are free to modify the code based on their local policy, even if the result introduces the incompatibility with other BSDs. Of course, there should be a reason for the modification, and the change may provide a better behavior. So, I can only ask, "please understand our position (that needs to handle all *BSDs) and consider a compromise." > I'm working on > getting that to you. Yes, I noticed that, thanks. I'll take a closer look at it later. 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 Oct 16 3:19: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 9F65C37B401 for ; Wed, 16 Oct 2002 03:19: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 D696F43E88 for ; Wed, 16 Oct 2002 03:19:54 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:4819:2000:14e:a4d1:f898:6ed5]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9GAJnt67022; Wed, 16 Oct 2002 19:19:50 +0900 (JST) Date: Wed, 16 Oct 2002 19:20:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: drogoh Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPv6 tunnel with PPPoE In-Reply-To: <20021012010103.649ada4a.drogoh@necessary-evil.org> References: <20021012010103.649ada4a.drogoh@necessary-evil.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: 14 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, 12 Oct 2002 01:01:03 -0500, >>>>> drogoh said: > I am wondering if anyone has used an IPv6 tunnel with something like freenet6 using PPPoE with userland PPP. I've tried to use one myself, but my problem APPEARS to be with PPP, because in the ppp.log I see lines like this: IPV6CP: deflink: State change Closed --> Req-Sent and Phase: deflink: IPV6CP protocol reject closes IPV6CP ! > However, if this is not the reason for not being able to get a route with PPPoE, I'd appreciate any help to get it working. If you're trying to establish the tunnel as your external link to the IPv6 Internet, you don't need ipv6cp. Just disable it: disable ipv6cp 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 Oct 16 5:29:37 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 4324137B401; Wed, 16 Oct 2002 05:29:35 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2661843EB1; Wed, 16 Oct 2002 05:29:33 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9GCTMIw014911; Wed, 16 Oct 2002 14:29:24 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: net@freebsd.org, arch@freebsd.org Subject: Re: cvs commit: src/sys/dev/kbd atkbdcreg.h In-Reply-To: Your message of "Wed, 16 Oct 2002 22:23:18 +1000." <20021016221657.I5365-100000@gamplex.bde.org> Date: Wed, 16 Oct 2002 14:29:22 +0200 Message-ID: <14910.1034771362@critter.freebsd.dk> From: Poul-Henning Kamp 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 In message <20021016221657.I5365-100000@gamplex.bde.org>, Bruce Evans writes: >> This kind of bug is a _really_ horribly thing as we end up with one bit >> of code thinking a particular structure is 136 bytes and another that it >> is only 112 bytes. >> >> Ideally all places would remember to #include the right "opt_foo.h" file, >> but I think in practice file containing the variable sized struct should >> #include it explicitly as a precaution. > >Ideally, header files wouldn't have any "variable sized structs" or >anything else that depends on options. Core headers have to be much >more careful about this because including an options header nested >would break most modules and everything outside of the kernel (apart >from the bug that modules and things outside of the kernel have no >way to determine the correct value for the option). I agree. Suggestions for the best way of fixing "struct ipq" in ip_var.h hereby solicited. I can see that MAC just unceremonously put their own field in there, and I guess that is the most sensible thing to do, despite the RAM this may cost during a DoS attack. Objections to this patch: Index: ip_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v retrieving revision 1.66 diff -u -r1.66 ip_var.h --- ip_var.h 16 Oct 2002 01:54:44 -0000 1.66 +++ ip_var.h 16 Oct 2002 07:35:44 -0000 @@ -68,10 +68,8 @@ u_short ipq_id; /* sequence id for reassembly */ struct mbuf *ipq_frags; /* to ip headers of fragments */ struct in_addr ipq_src,ipq_dst; -#ifdef IPDIVERT u_int32_t ipq_div_info; /* ipfw divert port & flags */ u_int16_t ipq_div_cookie; /* ipfw divert cookie */ -#endif struct label ipq_label; /* MAC label */ }; #endif /* _KERNEL */ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 6:45: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 7F1E937B401 for ; Wed, 16 Oct 2002 06:45:08 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3A9443EA3 for ; Wed, 16 Oct 2002 06:45:07 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S947QM>; Wed, 16 Oct 2002 09:45:07 -0400 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Subject: dynamic load of em/fxp/bge Date: Wed, 16 Oct 2002 09:45:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 trying to load the if_em, if_fxp, if_bge drivers via /boot/loader.conf. I've added if_fxp_load="YES" if_bge_load="YES" if_em_load="YES" The problem is that the bge driver doesn't load. It will if I manually load it after startup with kldload. The issue seems to be a dependency on miibus, both fxp and bge want to load it, bge gets an error that its already loaded. I tried putting 'miibus_load="YES"' in loader.conf, but the same affect is seen. I've tried from the boot prompt doing an explicit load of these manually in each order, but to no avail. As a work-around, I've placed an kldload if_bge in rc.network before the 'ifconfig -l'. Any suggestions on why the fxp/bge don't play nice when loaded automatically, but will work if run manually? Is there a timing thing that the fxp hasn't initialised its miibus yet? I have: fxp0 fxp1 bge0 in this particular machine. The bge will get miibus2 (eventually), leaving fxp0 to have miibus0, fxp1 to have miibus1 I think. Suggestions? --don To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 7:39: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 69B5C37B401 for ; Wed, 16 Oct 2002 07:39:17 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id E699F43E6A for ; Wed, 16 Oct 2002 07:39:16 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9GEdGpJ034796; Wed, 16 Oct 2002 07:39:16 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9GEdGCo034795; Wed, 16 Oct 2002 07:39:16 -0700 (PDT) (envelope-from rizzo) Date: Wed, 16 Oct 2002 07:39:16 -0700 From: Luigi Rizzo To: Petri Helenius Cc: Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021016073916.A34626@carp.icir.org> References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <06c901c274d8$e5280b80$8c2a40c1@PHE>; from pete@he.iki.fi on Wed, Oct 16, 2002 at 08:57:19AM +0300 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, Oct 16, 2002 at 08:57:19AM +0300, Petri Helenius wrote: > > > > how large are the packets and how fast is the box ? > > Packets go out at an average size of 1024 bytes. The box is dual > P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled yes, it qualifies as fast. With this kind of box, a trivial program can send short (18 byte payload, 64 byte total) UDP frames at 5-600kpps, with quite a bit of time i suspect is being spent in the userland-kernel transition (with some tricks to skip that i went up to ~680kpps). > The information I´m looking for is how to instrument where the hard to tell -- see if short packets you get the same performance i mention above, then maybe try some tricks such as sending short bursts (5-10 pkts at a time) on each of the interfaces. Maybe using a UP kernel as opposed to an SMP one might give you slightly better performance, i am not sure though. There might be some minor optimizations here and there which could possibly help (e.g. make th em driver use m_getcl(), remove IPSEC from the kernel if you have it) but you are essentially close to the speed you can get with that box (within a factor of 2, probably). cheers luigi > > on a fast box you should be able to generate packets faster than wire > > speed for sizes around 500bytes, meaning that you are going to saturate > > the queue no matter how large it is. > > > > cheers > > luigi > > > > > em-interface is running 66/64 and is there a way to see interface queue > depth? > > > em0: port > 0x3040-0x307f > > > mem 0xfc220000-0xfc23ffff irq 17 at device 3.0 on pci2 > > > em0: Speed:1000 Mbps Duplex:Full > > > pcib2: at device 29.0 on pci1 > > > IOAPIC #2 intpin 0 -> irq 16 > > > IOAPIC #2 intpin 6 -> irq 17 > > > IOAPIC #2 intpin 7 -> irq 18 > > > pci2: on pcib2 > > > > > > The OS is 4.7-RELEASE. > > > > > > Pete > > > > > > > > > > > > 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 Wed Oct 16 7:46: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 88ECB37B401; Wed, 16 Oct 2002 07:46:15 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F26543E8A; Wed, 16 Oct 2002 07:46:15 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9GEkBpJ034883; Wed, 16 Oct 2002 07:46:11 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9GEkAG2034882; Wed, 16 Oct 2002 07:46:10 -0700 (PDT) (envelope-from rizzo) Date: Wed, 16 Oct 2002 07:46:10 -0700 From: Luigi Rizzo To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: Sam Leffler , Julian Elischer , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <20021016074610.C34626@carp.icir.org> References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> <080101c27151$b2e92a30$52557f42@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Wed, Oct 16, 2002 at 07:03:33PM +0900 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 Actually from what i have read on previous postings on this thread, the only additional check that you might/will need is to make sure that m_tag_cookie corresponds to the GENERIC ABI. Also note that in your example the code should be conditional on __FreeBSD_version and not on __FreeBSD__ cheers luigi On Wed, Oct 16, 2002 at 07:03:33PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: ... > >>>>> "Sam Leffler" said: > > >> > struct m_tag { > >> > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags > > */ > >> > u_int16_t m_tag_id; /* Tag ID */ > >> > u_int16_t m_tag_len; /* Length of data */ > >> > u_int32_t m_tag_cookie; /* Module/ABI */ > >> > }; > > (snip) > > >> Sorry for interrupting, but please let me make it sure. Do you intend > >> to hide the additional member from other modules than the m_tag > >> internal? I'm afraid a story that (e.g.) some code fragments in the > >> network layer directly refers to m_tag_cookie, which will break source > >> level compatibility with other BSDs (when the code fragments are > >> shared with others). As suz said before, we (KAME) are very much > >> afraid of this kind of story. > > > The changes I'm proposing for KAME code make no references to m_tag_cookie. > > Things should be clear when you have a patch to look at. > > I know that, but what I'm worrying about is a story that *.c under > netinet[6] will have a direct reference to m_tag_cookie *in the > future". Then we'll need to separate the code fragments like this: > > #if defined(__FreeBSD__) && && __FreeBSD__ >= 5 > if (mtag->m_tag_cookie != PACKET_TAG_IPSEC_OUT_DONE && > mtag->m_tag_cookie != > PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED) > continue; > #else > if (mtag->m_tag_id != PACKET_TAG_IPSEC_OUT_DONE && > mtag->m_tag_id != > PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED) > continue; > #endif > (derived from the current KAME's ip6_output.c) > > We've experienced a lot of headaches due to this type of > incompatibility. I fully understand that once some changes are > incorporated to a particular BSD, the BSD developers are free to > modify the code based on their local policy, even if the result > introduces the incompatibility with other BSDs. Of course, there > should be a reason for the modification, and the change may provide a > better behavior. So, I can only ask, "please understand our position > (that needs to handle all *BSDs) and consider a compromise." > > > I'm working on > > getting that to you. > > Yes, I noticed that, thanks. I'll take a closer look at it later. > > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 7:52: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 7494537B401; Wed, 16 Oct 2002 07:52:57 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3712543EAA; Wed, 16 Oct 2002 07:52:56 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA13232; Thu, 17 Oct 2002 00:52:43 +1000 Date: Thu, 17 Oct 2002 01:03:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Poul-Henning Kamp Cc: Jeffrey Hsu , , Subject: Re: RFC: eliminating the _IP_VHL hack. In-Reply-To: <69413.1034756200@critter.freebsd.dk> Message-ID: <20021017004627.O5865-100000@gamplex.bde.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 On Wed, 16 Oct 2002, Poul-Henning Kamp wrote: > In message <20021016172019.W4358-100000@gamplex.bde.org>, Bruce Evans writes: > >On Tue, 15 Oct 2002, Jeffrey Hsu wrote: > > > >> > The side effect of having some source-files using the _IP_VHL hack and > >> > some not is that sizeof(struct ip) varies from file to file, which at > >> > best is confusing an at worst the source of some really evil bugs. > > > >There is no such effect, or ip would not work. > > s/,/ with our current compilers and architectures,/ It is the non-_IP_VHL case that will break. The _IP_VHL case requires little more than the existence of uint8_t, which is now required by POSIX. > >> > I would therefore propose to eliminate the _IP_VHL hack from the kernel > >> > to end this state of (potential) confusion > > > >This would remove the least unportable version. > > Could be, but there is no point in us having two different versions, > neither of which is guaranteed to be portable, in particular when > one of the two is private to FreeBSD and not even consistently used > there. I agree that source oce portability is a problem and wasn't helped by not completing this change. > For reference: > > NetBSD hasn't got the _IP_VHL but has a __packed__ on the > structure. As you may know, I don't like gccisms like __packed__. NetBSD actually uses __attribute__(__packed__) like we used to in other places. Our __packed doesn't exactly help portability, since it is a syntax error on systems that don't #define it. > OpenBSD hasn't got the _IP_VHL either, but hasn't adopted > the __packed__ from NetBSD. > > Linux also uses bitfields and endianess #ifdefs. There are also an amazing number of unportable bit-fields in , and . The declarations of these don't even use endianness #ifdefs or __packed in most cases. Some unportabilities are avoided using the gcc extension of small bit-field types. > I'll ammend my proposal to include a __packed__ and a CTASSERT on > the size of struct ip == 20. I prefer just the CTASSERT until __packed is found to be necessary. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 9: 9:47 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 02EDD37B401 for ; Wed, 16 Oct 2002 09:09:46 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C88343E9C for ; Wed, 16 Oct 2002 09:09:45 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g9GG9f1H004556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 16 Oct 2002 09:09:45 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <22e001c2752e$7179d370$52557f42@errno.com> From: "Sam Leffler" To: "Petri Helenius" , "Lars Eggert" Cc: "Luigi Rizzo" , References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> Subject: Re: ENOBUFS Date: Wed, 16 Oct 2002 09:09:41 -0700 Organization: Errno Consulting 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 900Mbps are similar to what I see here on similar hardware. > > What kind of receive performance do you observe? I haven´t got that > far yet. > > > > For your two-interface setup, are the 600Mbps aggregate send rate on > > both interfaces, or do you see 600Mbps per interface? In the latter > > 600Mbps per interface. I´m going to try this out also on -CURRENT > to see if it changes anything. Interrupts do not seem to pose a big > problem because I´m seeing only a few thousand em interrupts > a second but since every packet involves a write call there are >100k > syscalls a second. > > > case, is your CPU maxed out? Only one can be in the kernel under > > -stable, so the second one won't help much. With small packets like > > that, you may be interrupt-bound. (Until Luigi releases polling for em > > interfaces... :-) > > > I´ll try changing the packet sizes to figure out optimum. > Try my port of the netbsd kttcp kernel module. You can find it at http://www.freebsd.org/~sam It will eliminate the system calls. Don't recall if you said your system is a dual-processor; I never tried it on SMP hardware. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 10: 5: 0 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 44F7337B401; Wed, 16 Oct 2002 10:04:59 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id D887C43E8A; Wed, 16 Oct 2002 10:04:58 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0308.cvx40-bradley.dialup.earthlink.net ([216.244.43.53] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 181rbC-00027m-00; Wed, 16 Oct 2002 10:04:46 -0700 Message-ID: <3DAD9BE6.530F8466@mindspring.com> Date: Wed, 16 Oct 2002 10:03:34 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Bruce Evans , net@freebsd.org, arch@freebsd.org Subject: Re: cvs commit: src/sys/dev/kbd atkbdcreg.h References: <14910.1034771362@critter.freebsd.dk> 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 Poul-Henning Kamp wrote: > In message <20021016221657.I5365-100000@gamplex.bde.org>, Bruce Evans writes: > >Ideally, header files wouldn't have any "variable sized structs" or > >anything else that depends on options. Core headers have to be much > >more careful about this because including an options header nested > >would break most modules and everything outside of the kernel (apart > >from the bug that modules and things outside of the kernel have no > >way to determine the correct value for the option). > > I agree. > > Suggestions for the best way of fixing "struct ipq" in ip_var.h > hereby solicited. Please use a union; things like diversion information result in other information not being used. It makes no sense to uniformly bloat all memory allocations for minority features, merely for the sake of uniformity. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 10:29: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 B7F5237B404 for ; Wed, 16 Oct 2002 10:29:29 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 917BE43EBE for ; Wed, 16 Oct 2002 10:29:28 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9479X>; Wed, 16 Oct 2002 13:29:27 -0400 Message-ID: From: Don Bowman To: 'Sam Leffler' , freebsd-net@FreeBSD.ORG Subject: RE: ENOBUFS Date: Wed, 16 Oct 2002 13:29:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 Sam Leffler wrote: > Try my port of the netbsd kttcp kernel module. You can find it at > > http://www.freebsd.org/~sam this seems to use some things from netbsd like so_rcv.sb_lastrecord and SBLASTRECORDCHK/SBLASTMBUFCHK. Is there something else I need to apply to build it on freebsd -STABLE? --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 10:33: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 C3F8E37B401 for ; Wed, 16 Oct 2002 10:33:25 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id C37D443ECD for ; Wed, 16 Oct 2002 10:33:22 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g9GHXL1H005244 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 16 Oct 2002 10:33:22 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <243a01c2753a$1ff8b0a0$52557f42@errno.com> From: "Sam Leffler" To: "Don Bowman" , References: Subject: Re: ENOBUFS Date: Wed, 16 Oct 2002 10:33:21 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 > Sam Leffler wrote: > > Try my port of the netbsd kttcp kernel module. You can find it at > > > > http://www.freebsd.org/~sam > > this seems to use some things from netbsd like > so_rcv.sb_lastrecord and SBLASTRECORDCHK/SBLASTMBUFCHK. > Is there something else I need to apply to build it on > freebsd -STABLE? > Sorry, I ported Jason's tail pointer stuff to -stable before kttcp so it assumes that's installed. If you don't want to redo kttcp you might try applying thorpe-stable.patch from the same directory. FWIW I've been running with that patch in my production systems for many months w/o incident. I never committed it because I didn't see noticeable performance improvements. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 10:49:41 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 4F8E837B401 for ; Wed, 16 Oct 2002 10:49:40 -0700 (PDT) Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4070043EBE for ; Wed, 16 Oct 2002 10:49:35 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from line-c-227.adsl-dynamic.inode.at ([62.99.151.227]:1027 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 181sEK-0003xM-00 for freebsd-net@freebsd.org; Wed, 16 Oct 2002 19:45:12 +0200 Message-ID: <3DADA600.7090707@inode.at> Date: Wed, 16 Oct 2002 19:46:40 +0200 From: Michael Bretterklieber Organization: JAWA Management Software GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: mpd - Radius 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'm now evaluating if its difficult to extend mpd with radius authentication (with libradius). I have some questions: 1. Will be in auth.c the function AuthGetData() the right place to put Radius stuff? 2. What was the intention behind the function CustomAuthData()? 3. How should radius configured in the mpd.conf, is something like: set bundle radius /etc/radius.conf ok? 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 Wed Oct 16 11: 7:41 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 A1FFA37B401; Wed, 16 Oct 2002 11:07:39 -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 34E5843EB2; Wed, 16 Oct 2002 11:07:37 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9GI7Ht70328; Thu, 17 Oct 2002 03:07:18 +0900 (JST) Date: Thu, 17 Oct 2002 03:07:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Luigi Rizzo Cc: Sam Leffler , Julian Elischer , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <20021016074610.C34626@carp.icir.org> References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> <080101c27151$b2e92a30$52557f42@errno.com> <20021016074610.C34626@carp.icir.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: 33 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, 16 Oct 2002 07:46:10 -0700, >>>>> Luigi Rizzo said: > Actually from what i have read on previous postings on this thread, > the only additional check that you might/will need is to make sure > that m_tag_cookie corresponds to the GENERIC ABI. (I re-read the thread) perhaps the example in my previous message wasn't good (and it was at least incorrect). According to the discussion on the thread, we'll probably keep m_tag_cookie being 0 and use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this convention is kept (and will be kept) at least under netinet6. It would be good to make more explicit comments on the intended usage, not just a single comment for the m_tag_cookie member: u_int32_t m_tag_cookie; /* Module/ABI */ > Also note that in your example the code should be conditional > on __FreeBSD_version and not on __FreeBSD__ We (KAME) actually need __FreeBSD__, because we want to keep a single code base for all *BSDs (again, I know this is our local issue). But, whether or not we need __FreeBSD__ (in addition to __FreeBSD_version) is a minor point. From our point view, we do want to avoid any ifdef for separating different *BSDs. Thanks, 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 Oct 16 11:19: 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 BB0E137B401; Wed, 16 Oct 2002 11:19:04 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD80343E8A; Wed, 16 Oct 2002 11:19:03 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9GIIvpJ038254; Wed, 16 Oct 2002 11:18:57 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9GIIvl8038253; Wed, 16 Oct 2002 11:18:57 -0700 (PDT) (envelope-from rizzo) Date: Wed, 16 Oct 2002 11:18:57 -0700 From: Luigi Rizzo To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: Sam Leffler , Julian Elischer , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch Message-ID: <20021016111857.A38181@carp.icir.org> References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> <080101c27151$b2e92a30$52557f42@errno.com> <20021016074610.C34626@carp.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Thu, Oct 17, 2002 at 03:07:07AM +0900 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, Oct 17, 2002 at 03:07:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: ... > (I re-read the thread) perhaps the example in my previous message > wasn't good (and it was at least incorrect). According to the > discussion on the thread, we'll probably keep m_tag_cookie being 0 and > use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this > convention is kept (and will be kept) at least under netinet6. unfortunately this will not prevent code from having to check that the m_tag_cookie actually corresponds to the value you want, to make sure that your code does not misinterpret as own tags generated/destined to other clients. Am I correct, Sam ? > > Also note that in your example the code should be conditional > > on __FreeBSD_version and not on __FreeBSD__ > > We (KAME) actually need __FreeBSD__, because we want to keep a single > code base for all *BSDs (again, I know this is our local issue). But, i know it is a minor point, but we had this discussion before (and hit related bugs during cross builds). __FreeBSD__ refers to the build environment, whereas __FreeBSD_version matches the source tree you are building, and it is #defined on all versions of FreeBSD that you care about. So, should you have FreeBSD-specific code (hopefully as little as possible), you should *never* use __FreeBSD__ but instead use only __FreeBSD_version. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 11:29: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 E9E5337B404; Wed, 16 Oct 2002 11:29:53 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 500B943EE8; Wed, 16 Oct 2002 11:29:29 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g9GITP1H005622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 16 Oct 2002 11:29:26 -0700 (PDT)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <24db01c27541$f529da40$52557f42@errno.com> From: "Sam Leffler" To: "JINMEI Tatuya" , "Luigi Rizzo" Cc: , , "Julian Elischer" References: <18d301c26e5e$8b5c7a30$52557f42@errno.com> <080101c27151$b2e92a30$52557f42@errno.com> <20021016074610.C34626@carp.icir.org> <20021016111857.A38181@carp.icir.org> Subject: Re: CFR: m_tag patch Date: Wed, 16 Oct 2002 11:29:25 -0700 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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, Oct 17, 2002 at 03:07:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > ... > > (I re-read the thread) perhaps the example in my previous message > > wasn't good (and it was at least incorrect). According to the > > discussion on the thread, we'll probably keep m_tag_cookie being 0 and > > use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this > > convention is kept (and will be kept) at least under netinet6. > > unfortunately this will not prevent code from having to check that > the m_tag_cookie actually corresponds to the value you want, to > make sure that your code does not misinterpret as own tags > generated/destined to other clients. > > Am I correct, Sam ? > Correct. If you explicitly look inside the m_tag structure instead of using one of the m_tag_* routines to search then you will need to validate m_tag_cookie to avoid interpreting tags created by other modules. The comments I wrote in mbuf.h for this stuff describe this and say that when writing code that is to be compatible with other systems one should always use MTAG_ABI_COMPAT and the openbsd-compatible m_tag_get and m_tag_find routines. m_tag_cookie was mainly added so that netgraph could piggyback on top of the facility and remove it's private code. At some point it may be worthwhile to talk with the openbsd+netbsd folks about adopting this new m_tag facility. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 11:41: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 7044037B404 for ; Wed, 16 Oct 2002 11:41:15 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16D0943E88 for ; Wed, 16 Oct 2002 11:41:15 -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 <20021016184018.ZPRG11063.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 16 Oct 2002 18:40:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA86830; Wed, 16 Oct 2002 11:21:32 -0700 (PDT) Date: Wed, 16 Oct 2002 11:21:31 -0700 (PDT) From: Julian Elischer To: Michael Bretterklieber Cc: freebsd-net@freebsd.org Subject: Re: mpd - Radius In-Reply-To: <3DADA600.7090707@inode.at> 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 Wed, 16 Oct 2002, Michael Bretterklieber wrote: > Hi, > > I'm now evaluating if its difficult to extend mpd with radius > authentication (with libradius). > I have some questions: > > 1. Will be in auth.c the function AuthGetData() the right place to put > Radius stuff? > 2. What was the intention behind the function CustomAuthData()? mpd was written for use in the InterJet, which had a separate database controlling "everything". you could hook in to that database using that (from memory) Archie wil answer I'm sure and give more info.. also check how 'ppp' does it's radius stuff. > 3. How should radius configured in the mpd.conf, is something like: set > bundle radius /etc/radius.conf ok? > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 11:41: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 D4B9737B401; Wed, 16 Oct 2002 11:41:20 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72E3A43E9C; Wed, 16 Oct 2002 11:41:20 -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 <20021016184028.ZPUO11063.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 16 Oct 2002 18:40:28 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA86833; Wed, 16 Oct 2002 11:24:35 -0700 (PDT) Date: Wed, 16 Oct 2002 11:24:34 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: "JINMEI Tatuya / ?$B?@L@C#:H?(B" , Sam Leffler , freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: CFR: m_tag patch In-Reply-To: <20021016111857.A38181@carp.icir.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 On Wed, 16 Oct 2002, Luigi Rizzo wrote: > On Thu, Oct 17, 2002 at 03:07:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > ... > > (I re-read the thread) perhaps the example in my previous message > > wasn't good (and it was at least incorrect). According to the > > discussion on the thread, we'll probably keep m_tag_cookie being 0 and > > use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this > > convention is kept (and will be kept) at least under netinet6. > > unfortunately this will not prevent code from having to check that > the m_tag_cookie actually corresponds to the value you want, to > make sure that your code does not misinterpret as own tags > generated/destined to other clients. > > Am I correct, Sam ? yes but this is always done with macros, and the OpenBSD compatible macros also check for the correct cookie value. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 13:18:33 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 AFF8D37B401 for ; Wed, 16 Oct 2002 13:18:30 -0700 (PDT) Received: from smtp.inode.at (smtp-01.inode.at [62.99.194.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id D478343EAA for ; Wed, 16 Oct 2002 13:18:29 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from line-c-227.adsl-dynamic.inode.at ([62.99.151.227]:1190 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 181ucd-0000ql-00 for freebsd-net@freebsd.org; Wed, 16 Oct 2002 22:18:28 +0200 Message-ID: <3DADC8EB.4000603@inode.at> Date: Wed, 16 Oct 2002 22:15:39 +0200 From: Michael Bretterklieber Organization: JAWA Management Software GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: mpd - Radius 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 Hi, Julian Elischer wrote: >On Wed, 16 Oct 2002, Michael Bretterklieber wrote: > > > >>Hi, >> >>I'm now evaluating if its difficult to extend mpd with radius >>authentication (with libradius). >>I have some questions: >> >>1. Will be in auth.c the function AuthGetData() the right place to put >>Radius stuff? >> No. I wrote a small program wich is able to make radius-auth. Now I'm integrating it into mpd and auth.c is the wrong place. The right place will be pap.c or chap.c or ... >>2. What was the intention behind the function CustomAuthData()? >> >> > >mpd was written for use in the InterJet, which had >a separate database controlling "everything". >you could hook in to that database using that (from memory) >Archie wil answer I'm sure and give more info.. >also check how 'ppp' does it's radius stuff. > yes, I took many things from ppp. No I'm trying for the first shot only to make pap-auth with radius. > > > > > >>3. How should radius configured in the mpd.conf, is something like: set >>bundle radius /etc/radius.conf ok? >> >>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 >> >> >> > > > > > -- -- -------------------------------------- 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 Wed Oct 16 13:54: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 D30BF37B401 for ; Wed, 16 Oct 2002 13:54:27 -0700 (PDT) Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DF7B43E9E for ; Wed, 16 Oct 2002 13:54:27 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from line-c-227.adsl-dynamic.inode.at ([62.99.151.227]:1201 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 181v7G-0003G8-00; Wed, 16 Oct 2002 22:50:06 +0200 Message-ID: <3DADD157.5060709@inode.at> Date: Wed, 16 Oct 2002 22:51:35 +0200 From: Michael Bretterklieber Organization: JAWA Management Software GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Cc: Archie Cobbs Subject: Re: mpd - Radius 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 Hi, Now I got pap-radius-auth with mpd to work :-) I made it now with a static define. The next step will be to add the appropriate config-param for mpd.conf. Are there any hints, a small howto would be great? Something like: - naming conventions of param - where to add param - how to access param bye, Julian Elischer wrote: >On Wed, 16 Oct 2002, Michael Bretterklieber wrote: > > > >>Hi, >> >>I'm now evaluating if its difficult to extend mpd with radius >>authentication (with libradius). >>I have some questions: >> >>1. Will be in auth.c the function AuthGetData() the right place to put >>Radius stuff? >>2. What was the intention behind the function CustomAuthData()? >> >> > >mpd was written for use in the InterJet, which had >a separate database controlling "everything". >you could hook in to that database using that (from memory) >Archie wil answer I'm sure and give more info.. >also check how 'ppp' does it's radius stuff. > > > > > >>3. How should radius configured in the mpd.conf, is something like: set >>bundle radius /etc/radius.conf ok? >> >>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 >> >> >> > > > > > -- -- -------------------------------------- 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 Wed Oct 16 14:21: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 3E11C37B401; Wed, 16 Oct 2002 14:21:37 -0700 (PDT) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A14BC43E6A; Wed, 16 Oct 2002 14:21:35 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (zg04-123.dialin.iskon.hr [213.191.137.124]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g9GLL2x02073; Wed, 16 Oct 2002 23:21:03 +0200 (MEST) Message-ID: <3DADD864.15757E4E@tel.fer.hr> Date: Wed, 16 Oct 2002 23:21:40 +0200 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: RFC: BSD network stack virtualization 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 all, on http://www.tel.fer.hr/zec/BSD/vimage/ you can find the patches against 4.7-RELEASE kernel sources, which provide the functionality of maintaining multiple independent network stack images within a single operating system kernel. No userland patches are necessary, except an additional virtual image management utility. Within a patched kernel, every process and network interface belongs to an unique virtual image, which provides the independent: - set of network interfaces and userland processes; - interface addresses and routing tables; - TCP, UDP, raw protocol control blocks; - network traffic counters / statistics; - set of net.inet tunable sysctl variables; - ipfw and dummynet instance; - system load and CPU usage accounting and scheduling From the userland perspective, all the virtualization modifications within the kernel have been designed to preserve the complete API/ABI compatibility, so absolutely all existing userland binaries should be able to run unmodified on the virtualized kernel. There are many possible applications of having multiple independent instances of the network stack within a single kernel, just to mention VPN provisioning, virtual hosting, and network simulation... I'd be glad to hear your comments on the code and suggestions for the further development. Have fun! Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 14:31: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 E1D3237B401 for ; Wed, 16 Oct 2002 14:31:51 -0700 (PDT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 5A3AE43E6A for ; Wed, 16 Oct 2002 14:31:51 -0700 (PDT) (envelope-from darcy@wavefire.com) Received: (qmail 21948 invoked from network); 16 Oct 2002 21:53:02 -0000 Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 16 Oct 2002 21:53:02 -0000 Content-Type: text/plain; charset="us-ascii" From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: freebsd-net@freebsd.org Subject: xl driver and POLLING Date: Wed, 16 Oct 2002 14:31:44 -0700 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200210161431.44288.darcy@wavefire.com> 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 Has there been any work done on adding POLLING support to the xl driver? --=20 Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 14:42: 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 AD9A337B401 for ; Wed, 16 Oct 2002 14:42:05 -0700 (PDT) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 7F47443E77 for ; Wed, 16 Oct 2002 14:42:02 -0700 (PDT) (envelope-from misho@interbgc.com) Received: (qmail 74707 invoked by uid 1005); 16 Oct 2002 21:41:52 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.1.60/v4228. Clear:. Processed in 0.48539 secs); 16 Oct 2002 21:41:52 -0000 Received: from unknown (HELO misho) (217.9.231.229) by mail.interbgc.com with SMTP; 16 Oct 2002 21:41:52 -0000 Message-ID: <000d01c2755c$d6d01f80$e5e709d9@interbgc.com> Reply-To: "Mihail Balikov" From: "Mihail Balikov" To: "Darcy Buskermolen" Cc: References: <200210161431.44288.darcy@wavefire.com> Subject: Re: xl driver and POLLING Date: Thu, 17 Oct 2002 00:41:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 http://gosho.interbgc.com/if_xl.c.diff ----- Original Message ----- From: "Darcy Buskermolen" To: Sent: Thursday, October 17, 2002 12:31 AM Subject: xl driver and POLLING Has there been any work done on adding POLLING support to the xl driver? -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com 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 Wed Oct 16 14:45:28 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 B307637B401 for ; Wed, 16 Oct 2002 14:45:26 -0700 (PDT) Received: from bricore.com (adsl-66-124-255-252.dsl.snfc21.pacbell.net [66.124.255.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id E023043E3B for ; Wed, 16 Oct 2002 14:45:25 -0700 (PDT) (envelope-from lchen@briontech.com) Received: from luoqi (luoqi.bricore.com [192.168.1.63]) by bricore.com (8.11.6/8.11.6) with SMTP id g9GLjPP19215 for ; Wed, 16 Oct 2002 14:45:25 -0700 (PDT) (envelope-from lchen@briontech.com) From: "Luoqi Chen" To: Subject: possible routed bug Date: Wed, 16 Oct 2002 14:46:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) 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, I've encountered a possible bug in routed code that's interfering with path mtu discovery mechanism. Routed deletes any cloned route as soon as it sees one (with exception of arp routes in the local ethernet), including protocol cloned routes served as holders for path mtu information. Could anyone confirm this is not an intended behavior? This symptom of this bug is the breakdown of the pmtu discovery process. It is easily reproduced with a machine behind a PPPoE router (or any router limits MTU to below 1500) and running routed. With this seutp, send an email larger than 1500 to your friend at stanford or mit, you will find the email couldn't be delivered. Start tcpdump and watch your email and icmp traffic, you will see an icmp response ICMP_NEEDFRAG for the first 1500-byte tcp packet, but *NO* immediate retransmission with reduced packet size in response to the icmp message, the next retransmission will occur 10ms later when the retransmit timer expires and with the same 1500 byte packet. Following is my proposed fix. Basically treat the protocol cloned routes the same way as we treat arp routes (in fact also cloned), that is, ignore them. Index: table.c =================================================================== RCS file: /home/ncvs/src/sbin/routed/table.c,v retrieving revision 1.16 diff -u -r1.16 table.c --- table.c 18 Feb 2002 20:35:19 -0000 1.16 +++ table.c 16 Oct 2002 18:33:53 -0000 @@ -1111,9 +1111,9 @@ continue; /* ignore ARP table entries on systems with a merged route - * and ARP table. + * and ARP table, or any other cloned routes */ - if (rtm->rtm_flags & RTF_LLINFO) + if (rtm->rtm_flags & (RTF_LLINFO | RTF_WASCLONED)) continue; /* ignore multicast addresses @@ -1259,6 +1259,11 @@ if (m.r.rtm.rtm_flags & RTF_LLINFO) { trace_act("ignore ARP %s", str); + continue; + } + + if (m.r.rtm.rtm_flags & RTF_WASCLONED) { + trace_act("ignore clone %s", str); continue; } Thanks -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 15:17: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 CE9E137B401 for ; Wed, 16 Oct 2002 15:17:54 -0700 (PDT) Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69C2343E6E for ; Wed, 16 Oct 2002 15:17:52 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from line-c-227.adsl-dynamic.inode.at ([62.99.151.227]:1231 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 181wPs-00022W-00; Thu, 17 Oct 2002 00:13:24 +0200 Message-ID: <3DADE4DE.1080205@inode.at> Date: Thu, 17 Oct 2002 00:14:54 +0200 From: Michael Bretterklieber Organization: JAWA Management Software GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org, Archie Cobbs Cc: Michael Bretterklieber Subject: Re: mpd - Radius References: <3DADD157.5060709@inode.at> Content-Type: multipart/mixed; boundary="------------080308070009060802010907" 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 multi-part message in MIME format. --------------080308070009060802010907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, mpd - basic radius (pap only) support now finished, see attachements. two new files: radius.h radius.c four modified files: Makefile bund.h bund.c pap.c (I hope I got all changes files) You can activate radius by adding this config-param: set bundle radius /etc/radius.conf you have to remove the comment in the Makefile from RADIUS_AUTH=yes. bye, Michael Bretterklieber wrote: > Hi, > > Now I got pap-radius-auth with mpd to work :-) > > I made it now with a static define. The next step will be to add the > appropriate config-param for mpd.conf. > > Are there any hints, a small howto would be great? > Something like: > - naming conventions of param > - where to add param > - how to access param > > bye, > > Julian Elischer wrote: > >> On Wed, 16 Oct 2002, Michael Bretterklieber wrote: >> >> >> >>> Hi, >>> >>> I'm now evaluating if its difficult to extend mpd with radius >>> authentication (with libradius). >>> I have some questions: >>> >>> 1. Will be in auth.c the function AuthGetData() the right place to >>> put Radius stuff? >>> 2. What was the intention behind the function CustomAuthData()? >>> >> >> >> mpd was written for use in the InterJet, which had >> a separate database controlling "everything". >> you could hook in to that database using that (from memory) >> Archie wil answer I'm sure and give more info.. >> also check how 'ppp' does it's radius stuff. >> >> >> >> >> >>> 3. How should radius configured in the mpd.conf, is something like: >>> set bundle radius /etc/radius.conf ok? >>> >>> 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 >>> >>> >> >> >> >> >> >> > -- -- -------------------------------------- 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 -------------------------------------- --------------080308070009060802010907 Content-Type: application/gzip; name="mpd_radius.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mpd_radius.tar.gz" H4sIAFXkrT0AA+0aa3PaSDJf4Vf0kt0EYoF5+BHjdS4yCFu3vE4SSVzZFCtLg9FFSDpJxOdL 8t+ve0YC2cGxvbvJXl2pU8Fi1O/p7ukZJjCDmlWzndns0TeDeqNe39vZeVQXcPNva29v91F9 f3e31dpr7O/vIX5jd2/vEdS/nUprWEaxGQI8Cn0//hre5Zwx93so9H2hWq3CdrwItheBXW3V Draj0NoOKCgKxnwJOgsAdqHeajd32rstaNbrzeLW1hYIlNfMhpEVQ2MPmi18324lKC9fQrWx J+3BFn426vDyZREeO57lLm0GJXMZz2vzUnbIu5gtPYsPFrceOzObzUCTu+pEn8oT45TGUtTQ tJ1lRKhbj5mHoVvcKsL2syLAM+gqPXWoGupoqNP3baFIsyntoybNPfxDmgA4XlwoFFzmHdI3 GfXBr5bvRTGYcARPXO999YVrBTVSleOMzUD1Zn6KhfYTnll9gU+HxWpxq0BY289ANz0nvgJr zqz3pAFJm0F5xTGYmxGDH45gfCrrCrdOGRpqRzYUePIEbsMbKsbrkfZLBT4SR4C+f1Hun3By Ccqltz9F72Asj9sQMuupDVEcmleopfWexSVJcPXMBatUDoVPnh9IzQY65aAltfa4V4pQQPVP GLoAjQbbjE2Y+SHEcyeC6CqK2YLbU7ghGsaMhUDM2/Br6afo1xIKTGVVC2Q8ORgZd5Flmd5I 6DkckqCBT5fzq57puBX4GepkXrXwhXXQMb2nMVygblbIbObFjulGXLsNEgEu/NiHc9PW2L+W LIpp8DMaWCUDuz5HhSfonSi69EMbFmZszf9Gxgl10XnWIijzMKUPoTIXAJ8+QfZ1ykPi3Cq3 6a96H0zXsXFyogDjh5VSTRPjMZYId9qT1f5UHb6S+2p32h+dqENEWxvS5jQzJBiw6IKIUAei H0QX5bE2MkZTjAEJ6lLKOBGD0TtaxsEyLuP76VD+BfWdBzUH9U65SWQXZkQ5Hajg9CTkXIzj OdG8zNUcK4o2RWG60u9J0JP7uiLBcNLvJ/jnITPfH25O5NTDJOp86dnVF5hRs5rIau7ALUTi WD+IwSl5eop5lsQOeRq1df7D/FlZuJ2TYQrf9LuQ3OYGcEuZzV1PuPdwPaF9EUs4+Jnr+BmY iyn6cV2HCg+P9k1aPyDav67hnfGeaPzHAn6TCRsD/t5ez0Y8ET0w4onkD0Q8kT8k4gk/jXju +Q1hD3xchElSadFljgemZbEgxnV0Y2nVEvcBlmDuUO7HP3H9pwz81g3gHf1fY6++n/Z/zXpj h/q//UYz7/++B2zs/0RQfL0BTHCud4Ct/Xa9ue4Ad1rUAeJn2nYB6IoxHajDaVfVO6PhUOkY 0voFhf1QHiiZobGs69j3dCVKLRoQSZXB0BRDO8sy6XSUcZZrVxnie9Ln4Dnpc3AgPef6FI7R Bp3FHX+xMD1b5DOm3QcfC9ezyjWV4HPC8SOUVnWUHkoSZn+JygXVacuMHd9bVdqSdD8pqZUk Be38mDa5IP4IGZoYipZB4IfY1CHmPVgLf2XVD1kcXkHEcNm1E9Y9fQBiOHYWzF/G91WcOz/L XJQzeOvjR61We0f8S7IYxDF0TknMRaO+L/YH9f2DdIcguFjU92a90hbjAJEXhNi5z7J9w3o9 ShqCDe+wruO6iavmM/MD1WvBLS3Z5PGVzKRhSHE2SRRzskle0sNclwbXpN20kTuw/WdW9IcB T+P5X1r/8V19Xf+bzbz+f0e4vf7P71H/5zfqf/N5u/58Xf+x0op6u67/YuO9CMPlYYG3pyru lrG9hYE2oQ5nyZI9M+bI3AwLhbQdfcvbsIH8ZlWS3x1m8dJcX+Ol5eMdb8sElsjQt83d3XeH tFl/8+YNLDA145iFbTB8bJY/OCZg9+Z4a02iORZcJKYKOU0q5CHX3hBfeG9Orx0WraiW04Tu fDHVE2uPsZBeOjZuRhYXC2zv6SzB9OLNRKfOn9rqbYSB+R5tddm3rAB35f9+q7k+/9vBXrDR bO7X8/z/HrAx/9Og+HoFWGHdOAXcwTZwXQN261QD8PN5ssTrZzru83Dj11H7qnF2VKBvXVkZ jIZ09pfZNB0VrlhEh3uPAXuQAEWFuIt1He89Psxc8yIifv2u3O1uHRUKVXdhc5H7vM17Xpca jUTmY5BtGyJ/GVqYoJiDgjw53mJYeELHx94qmF9F2MO54JpXKCO+ChjJ2KrhJlnUBBvK2X0d VIpbutbRSX5yLmkVtzIqicHiVmc0NjhWtXvtNKSWbAmvSxifnunG2ViZDkZdZYBCIBWy8G22 qFlU9GIUBRm+14nuWTnSw9RvGWOZ/G/s735RB1qtnfX5f7Oxy/O/tfOd8z9dBW7D+z/N/+1n RfyH+RVchc7FHJP44GCnStkLvZCxY70r4RJt1UB2XeAYEZ3psPADs2ucVGO2E+HKd77kWx9K riUdWHhJvvGRc8czcXeB+bbAzvnSwQUQU4/+0uqJQe3Mkr2ThCzNkEHAwoUT08FIEPofHBsf Yox5nq4z33X9S8e7oAXUdogs4kQLFre5UgCN2g3NIvBnqUoWZhEscOpp0TZRVeJqnvsf6FXq Cc/H/RyTODcEfgzuIkPik5Xr2TeUQqmWa2JnENY4cfNLVVBkxiWpKmipvUT1vpE2kBhq+9Zy gbtVsVdNOSLlNs6JjxghnRCykJ86rrzPJ42TZywRIWCcqjroo57xWtYUwOexNnqldpUuHJ/h SwV6mqJgKNH433HLD7/9JuuI9/QpyMMu/j8D5c1YU3QdRhryUwfjvorUyE6Th4aq6BiEw05/ 0lWHJxIcTwwYjgzoqwPVQDRjJHEpX5LBqIfsBorWOcUB+ZivOFxmTzWGJK830kCGsawZamfS lzUYT7TxSFeALKFDir6sDpRuDeWjTFBeKUMDWeqncr+/0TTk1xkNDU1FLUeaDscK6ikf9xUh Ck3tqhodeyDH5IksHnbQX6gibrD1sdJR6UF5o6BFsnYmJVx15R8T+q1I7kNXHsgnaGD5S78g u6xnULHORFMGSIjuAH1yrBuqMTEUOBmNuuRx3Ihqr9SOoh9Cf0Rz0IMJHW92ZUOWxIwgE/QY IiD28URXue/UoaFo2mRMP7dV4HT0Gr2DespI3OVOHg25weimkXYm5oJ8wWdBgtenCr7RyLPc YzI5RUfPdYwsGkpERxoZS2GonPTVE2XYUZAjvh8Rn9eqrlRw2lSdUFQh+rWMcifccJos1Ew8 ZuJV4pMKKmknd1+ppHyCjoGgq0nQcNd1ThPHJ3FPrYPDLkXaYRZa7jLiaYjPVFcwbZKci/xZ fEklijCvJyCNYh2MGHLEZObJj5sePxRscT+wdG3KfzinsoqJGWDVQtZmxGsGVmMvpkz3Z1hE aS8V+C4+sIgiizk8odm/CTFCKsxxZxG4DrOlVFxS6WEc+v9k2MghyrXiz439MRn6sYh7leLq 59ifsYNwnfPa/EWxiMpB9icbWlpj+nFhafEX0zka5OK+6hlUDq9hW5a/9DaiSnx/l/1LdDfI 09+HbkH9qxfZ/2FIm9ZvKeOO/m+/udta9X8Nfv8D+7/9vP/7HpD3f3n/l/d/ef+X9395//e7 +r9SEAR0F2/T/bwHNIThnG6SFAv4AEf8FSfwA+aVsYPjt1T4uyNx6wKRb7/tw8ktK+bkbeA/ xtEYCmZh6IfEqUIXKfiZ/jL0oI7Pn1H8bRxxWtHBnNGGO0uJfiSCxp0LErAJk67z1e/WXTC5 Q3HCczFq+NgGU5KvjcPi5+I9e21SWrTOuIKH4hKQ+C6uXBGXIj32mcet4C8xdGP+Cw3/VQVd QbJYdFjMeCVkuKBMQ3Gnp0xy0F7+U72uTzUqa7pxb+9cY7bJS7fNbqpOsIwJGad0pQpWBm3K 7x5AarvQBz59SrxNVGjbiiSpmlM6cxUjPQ0ZdO+iE1hTfnmpM+qLwfF4vLb/Dges1f+9xptx HF43fXXPIrldt5rl+81JyvShCl2wOA2fcvqw+mU9HajcR4sspwqpAdUka13fMl16h4oVV1rh p+cnitH9tuAqo0BpTVNJtN3eBqyz9iraqfoOZb2q8vt5M4eFX40vRJ3yFV7tqYomrdg8xMEP mnNq6UQZiJKCSupnUnBVtQjhCKqNu5XIcnigGhG2j9achAkx/AJEpgaIWzvt4lfucH6BXRLC MpVufRFvgwhNoQbtviIE9g0R9TtEdKgtVIYnyn2lrAgwWmmFTy73JLdUbxGM8VgoZt7cLPDX T0NuL+XZSr5xNdhYzG8s5k9o5T7iMZzRdRV12RWHcmGtzfU6QzSrFY0H58pCIf5zfoqTQw45 5JBDDjnkkEMOOeSQQw455JBDDjnkkEMOOeSQQw455PA1+C+0l6YVAFAAAA== --------------080308070009060802010907-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 16:45: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 24B5337B401 for ; Wed, 16 Oct 2002 16:45:17 -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 5E61543E42 for ; Wed, 16 Oct 2002 16:45:16 -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 QAA64434; Wed, 16 Oct 2002 16:43:25 -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 g9GNhPON008141; Wed, 16 Oct 2002 16:43: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 g9GNhNQY008140; Wed, 16 Oct 2002 16:43:23 -0700 (PDT) From: Archie Cobbs Message-Id: <200210162343.g9GNhNQY008140@arch20m.dellroad.org> Subject: Re: mpd - Radius In-Reply-To: <3DADD157.5060709@inode.at> "from Michael Bretterklieber at Oct 16, 2002 10:51:35 pm" To: Michael Bretterklieber Date: Wed, 16 Oct 2002 16:43:23 -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: > Now I got pap-radius-auth with mpd to work :-) Cool! You may want to contact Brendan Bank because he's also working on mpd+RADIUS. It would be nice if you two could coordinate and maybe review each other's code... > I made it now with a static define. The next step will be to add the > appropriate config-param for mpd.conf. > > Are there any hints, a small howto would be great? > Something like: > - naming conventions of param > - where to add param > - how to access param Probably these should be bundle-level commands, right? You can use the examples that already exist as a starting point. Cheers, -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 Wed Oct 16 17:15: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 A34CA37B401 for ; Wed, 16 Oct 2002 17:15:11 -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 0C8C943E88 for ; Wed, 16 Oct 2002 17:15:11 -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 RAA64737; Wed, 16 Oct 2002 17:02:00 -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 g9H01xON008366; Wed, 16 Oct 2002 17:01:59 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9H01xOU008365; Wed, 16 Oct 2002 17:01:59 -0700 (PDT) From: Archie Cobbs Message-Id: <200210170001.g9H01xOU008365@arch20m.dellroad.org> Subject: Re: MPD PPTP tunneling intermittantly fails In-Reply-To: "from Leonard Chung at Oct 16, 2002 02:30:50 am" To: Leonard Chung Date: Wed, 16 Oct 2002 17:01:59 -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 Leonard Chung writes: > I'm just using Windows clients, so there are no OS X clients. > > Here's the ngctl output: > > chung# ngctl msg ng0:inet.ppp.link0 getstats > Rec'd response "getstats" (3) from "ng0:inet.ppp.link0": > Args: { xmitPackets=1967 xmitOctets=209321 xmitLoneAcks=395 xmitDrops=345 > recvPackets=1590 recvOctets=248518 recvAckTimeouts=55 } That doesn't look so good. But it doesn't look "crazy" from the netgraph side, just like a lot of packets are being dropped. There must be something specific about your setup that causes this. You're using 4.6.2? Try applying all of the patches in sys/netgraph that are in 4.7-REL that you don't have in 4.6.2... ? -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 Wed Oct 16 17:54: 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 B947E37B401 for ; Wed, 16 Oct 2002 17:53:59 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C6CA43E6A for ; Wed, 16 Oct 2002 17:53:59 -0700 (PDT) (envelope-from kelly@alicia.nttmcl.com) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id g9H0s9vm012618 for ; Wed, 16 Oct 2002 17:54:09 -0700 (PDT) (envelope-from kelly@alicia.nttmcl.com) Received: from localhost (kelly@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) with ESMTP id g9H0s99m012615 for ; Wed, 16 Oct 2002 17:54:09 -0700 (PDT) Date: Wed, 16 Oct 2002 17:54:09 -0700 (PDT) From: Kelly Yancey To: net@freebsd.org Subject: Patch for review: only report protocol data via EVFILT_READ filter Message-ID: <20021016172902.E11940-200000@alicia.nttmcl.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-756964737-1034816049=:11940" 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-756964737-1034816049=:11940 Content-Type: TEXT/PLAIN; charset=US-ASCII Currently, the value returned in a kevent's data member by the EVFILT_READ filter is "number of bytes in the socket buffer" which includes control and out-of-band data. However, this isn't particularly useful as any read(), readv(), or readmsg() for the amount of data reported may block if there is any non-protocol data in the buffer. And being that there is no way for userland applications to determine if, and if so how much, non-protocol data is in the buffer, the reported value cannot be trusted for anything useful. PR 30634 touches on this issue; UDP sockets are particularly visible examples since they always include 16 bytes of address information in addition to the datagram received. However, from reading the code it would appear that OOB data can cause a similar problem for TCP sockets. It seems that the overriding issue is that the read* API takes the number of bytes of protocol data to read whereas kevent() reports the total number of bytes available (protocol or administrative). The attached patch, which I would appreciate your comments on, modifies kevent() to report just the number of bytes of protocol data. As an aside, it appears that the FIONREAD ioctl (sys_socket.c:soo_ioctl) and stat(2) on a socket (sys_socket.c:soo_stat) also return the total number of bytes (protocol data other otherwise) in the socket buffer. For similar reasons as described above, I suspect that these should be also modified to return just the number of bytes of actual data. Unless someone knows of an explicit example otherwise, I don't think changing the value reported via these interfaces would break any existing applications as they are probably expecting the new behaviour anyway. Thanks, Kelly (P.S. I've already sent a version of this patch, made against -stable, to Jonathan, but I haven't heard anything from him in almost a week) -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} --0-756964737-1034816049=:11940 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fix-pr30634.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20021016175409.M11940@alicia.nttmcl.com> Content-Description: Content-Disposition: attachment; filename="fix-pr30634.diff" SW5kZXg6IHN5cy9zb2NrZXR2YXIuaA0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9zeXMvc29ja2V0dmFy Lmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjk0DQpkaWZmIC11IC1wIC1y MS45NCBzb2NrZXR2YXIuaA0KLS0tIHN5cy9zb2NrZXR2YXIuaAkxNyBBdWcg MjAwMiAwMjozNjoxNiAtMDAwMAkxLjk0DQorKysgc3lzL3NvY2tldHZhci5o CTE2IE9jdCAyMDAyIDIxOjM0OjEzIC0wMDAwDQpAQCAtMTA1LDYgKzEwNSw3 IEBAIHN0cnVjdCBzb2NrZXQgew0KIAkJdV9pbnQJc2JfaGl3YXQ7CS8qIG1h eCBhY3R1YWwgY2hhciBjb3VudCAqLw0KIAkJdV9pbnQJc2JfbWJjbnQ7CS8q IGNoYXJzIG9mIG1idWZzIHVzZWQgKi8NCiAJCXVfaW50CXNiX21ibWF4Owkv KiBtYXggY2hhcnMgb2YgbWJ1ZnMgdG8gdXNlICovDQorCQl1X2ludAlzYl9j dGw7CQkvKiBub24tZGF0YSBjaGFycyBpbiBidWZmZXIgKi8NCiAJCWludAlz Yl9sb3dhdDsJLyogbG93IHdhdGVyIG1hcmsgKi8NCiAJCWludAlzYl90aW1l bzsJLyogdGltZW91dCBmb3IgcmVhZC93cml0ZSAqLw0KIAkJc2hvcnQJc2Jf ZmxhZ3M7CS8qIGZsYWdzLCBzZWUgYmVsb3cgKi8NCkBAIC0yMjcsNiArMjI4 LDggQEAgc3RydWN0IHhzb2NrZXQgew0KIC8qIGFkanVzdCBjb3VudGVycyBp biBzYiByZWZsZWN0aW5nIGFsbG9jYXRpb24gb2YgbSAqLw0KICNkZWZpbmUJ c2JhbGxvYyhzYiwgbSkgeyBcDQogCShzYiktPnNiX2NjICs9IChtKS0+bV9s ZW47IFwNCisJaWYgKChtKS0+bV90eXBlICE9IE1UX0RBVEEpIFwNCisJCShz YiktPnNiX2N0bCArPSAobSktPm1fbGVuOyBcDQogCShzYiktPnNiX21iY250 ICs9IE1TSVpFOyBcDQogCWlmICgobSktPm1fZmxhZ3MgJiBNX0VYVCkgXA0K IAkJKHNiKS0+c2JfbWJjbnQgKz0gKG0pLT5tX2V4dC5leHRfc2l6ZTsgXA0K QEAgLTIzNSw2ICsyMzgsOCBAQCBzdHJ1Y3QgeHNvY2tldCB7DQogLyogYWRq dXN0IGNvdW50ZXJzIGluIHNiIHJlZmxlY3RpbmcgZnJlZWluZyBvZiBtICov DQogI2RlZmluZQlzYmZyZWUoc2IsIG0pIHsgXA0KIAkoc2IpLT5zYl9jYyAt PSAobSktPm1fbGVuOyBcDQorCWlmICgobSktPm1fdHlwZSAhPSBNVF9EQVRB KSBcDQorCQkoc2IpLT5zYl9jdGwgLT0gKG0pLT5tX2xlbjsgXA0KIAkoc2Ip LT5zYl9tYmNudCAtPSBNU0laRTsgXA0KIAlpZiAoKG0pLT5tX2ZsYWdzICYg TV9FWFQpIFwNCiAJCShzYiktPnNiX21iY250IC09IChtKS0+bV9leHQuZXh0 X3NpemU7IFwNCkluZGV4OiBrZXJuL3VpcGNfc29ja2V0LmMNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMv a2Vybi91aXBjX3NvY2tldC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4x MzINCmRpZmYgLXUgLXAgLXIxLjEzMiB1aXBjX3NvY2tldC5jDQotLS0ga2Vy bi91aXBjX3NvY2tldC5jCTUgT2N0IDIwMDIgMjE6MjM6NDYgLTAwMDAJMS4x MzINCisrKyBrZXJuL3VpcGNfc29ja2V0LmMJMTYgT2N0IDIwMDIgMjE6MzI6 MDEgLTAwMDANCkBAIC0xNzg1LDYgKzE3ODUsNyBAQCBmaWx0X3NvcmVhZChz dHJ1Y3Qga25vdGUgKmtuLCBsb25nIGhpbnQpDQogCXN0cnVjdCBzb2NrZXQg KnNvID0gKHN0cnVjdCBzb2NrZXQgKilrbi0+a25fZnAtPmZfZGF0YTsNCiAN CiAJa24tPmtuX2RhdGEgPSBzby0+c29fcmN2LnNiX2NjOw0KKwlrbi0+a25f ZGF0YSAtPSBzby0+c29fcmN2LnNiX2N0bDsNCiAJaWYgKHNvLT5zb19zdGF0 ZSAmIFNTX0NBTlRSQ1ZNT1JFKSB7DQogCQlrbi0+a25fZmxhZ3MgfD0gRVZf RU9GOw0KIAkJa24tPmtuX2ZmbGFncyA9IHNvLT5zb19lcnJvcjsNCg== --0-756964737-1034816049=:11940-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 19:18: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 828FE37B401 for ; Wed, 16 Oct 2002 19:18:55 -0700 (PDT) Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D2543E6E for ; Wed, 16 Oct 2002 19:18:54 -0700 (PDT) (envelope-from bsd#nms@otdel-1.org) Received: by otdel-1.org (CommuniGate Pro PIPE 4.0b9) with PIPE id 2170121; Thu, 17 Oct 2002 06:18:53 +0400 Date: Thu, 17 Oct 2002 06:18:49 +0400 From: Nikolai Saoukh To: freebsd-net@FreeBSD.ORG Subject: Re: MPD PPTP tunneling intermittantly fails Message-ID: <20021017021849.GA1354@otdel1.org> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <200210170001.g9H01xOU008365@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210170001.g9H01xOU008365@arch20m.dellroad.org> User-Agent: Mutt/1.5.1i X-Mailer: CommuniGate Pro CLI mailer 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, Oct 16, 2002 at 05:01:59PM -0700, Archie Cobbs wrote: | That doesn't look so good. But it doesn't look "crazy" from the | netgraph side, just like a lot of packets are being dropped. | There must be something specific about your setup that causes this. Specific is MPPE. I have the same problem here. I am digging the problem at slow pace. So far I discoverd that mpd set mtu on interface too early, thus without MPPE header size. But the real problem, is the huge amount of CCP Reset Requests from win client. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 19:51: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 AAB4237B401 for ; Wed, 16 Oct 2002 19:51:44 -0700 (PDT) Received: from dominion.1my.net (dominion.1my.net [202.56.152.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90F5743E65 for ; Wed, 16 Oct 2002 19:51:43 -0700 (PDT) (envelope-from mikechoo@opensos.net) Received: from lifebook ([219.93.215.151]) (authenticated bits=0) by dominion.1my.net (8.12.5/8.12.5) with ESMTP id g9GFLpGK066727 for ; Wed, 16 Oct 2002 23:21:55 +0800 (MYT) (envelope-from mikechoo@opensos.net) Date: Wed, 16 Oct 2002 23:21:40 +0800 From: Michael Choo X-Mailer: The Bat! (v1.60) Personal Reply-To: Michael Choo Organization: OpenSOS Sdn Bhd X-Priority: 3 (Normal) Message-ID: <1319077331.20021016232140@opensos.net> To: freebsd-net@freebsd.org Subject: Realtek 8150 support 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, Are there any development on a Realtek 8150 USB NIC driver? Been searching all over and all I can find are Linux drivers. -- Best regards, Michael mailto:mikechoo@opensos.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Oct 16 23:14: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 DAF2B37B401 for ; Wed, 16 Oct 2002 23:14:32 -0700 (PDT) Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CE6943E4A for ; Wed, 16 Oct 2002 23:14:27 -0700 (PDT) (envelope-from mbretter@inode.at) Received: from line-c-62.adsl-dynamic.inode.at ([62.99.151.62]:1037 helo=inode.at) by smtp.inode.at with esmtp (Exim 4.05) id 1823r8-00076d-00; Thu, 17 Oct 2002 08:10:02 +0200 Message-ID: <3DAE5495.1040409@inode.at> Date: Thu, 17 Oct 2002 08:11:33 +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-at, de-de, de, en, en-us MIME-Version: 1.0 To: Archie Cobbs Cc: freebsd-net@FreeBSD.org, brendan@gnarst.net Subject: Re: mpd - Radius References: <200210162343.g9GNhNQY008140@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, Archie Cobbs schrieb: > Michael Bretterklieber writes: > >>Now I got pap-radius-auth with mpd to work :-) > > > Cool! > > You may want to contact Brendan Bank because he's > also working on mpd+RADIUS. > > It would be nice if you two could coordinate and maybe review > each other's code... > > >>I made it now with a static define. The next step will be to add the >>appropriate config-param for mpd.conf. >> >>Are there any hints, a small howto would be great? >>Something like: >>- naming conventions of param >>- where to add param >>- how to access param > > > Probably these should be bundle-level commands, right? You can > use the examples that already exist as a starting point. yes. I implemented it at bundle level. But I think it will better to have something like this in the mpd.conf: - gobal switch to enable radius support. - switches for the different layers (link, bundle) where radius can be used (because Radius can more the Authentication) bye, > > Cheers, > -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 Wed Oct 16 23:59: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 BAE1537B401; Wed, 16 Oct 2002 23:59:09 -0700 (PDT) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CC4D43E65; Wed, 16 Oct 2002 23:59:08 -0700 (PDT) (envelope-from ruben@erg.verweg.com) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by erg.verweg.com (8.12.5/8.12.5) with ESMTP id g9H6x5iV016429 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 17 Oct 2002 08:59:05 +0200 (CEST) (envelope-from ruben@erg.verweg.com) Received: (from ruben@localhost) by erg.verweg.com (8.12.5/8.12.5/Submit) id g9H6x4mR016428; Thu, 17 Oct 2002 08:59:04 +0200 (CEST) (envelope-from ruben) Date: Thu, 17 Oct 2002 08:59:04 +0200 From: Ruben van Staveren To: Marko Zec Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: RFC: BSD network stack virtualization Message-ID: <20021017065904.GA16310@erg.verweg.com> References: <3DADD864.15757E4E@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DADD864.15757E4E@tel.fer.hr> X-LeerQuoten: http://leerquoten.verweg.com Organisation: Verweg Dot Com X-message: Zeker Outlook ? User-Agent: Mutt/1.5.1i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-9.9 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.41 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 Isn't this something that can overcome the current shortcomings of jail(2) ? (the no other stacks/no raw sockets problem) - Ruben -- ,-_ .----------------------------------------------------------------. /() ) | Ruben van Staveren http://ruben.is.verweg.com/ |_o (__ ( |Men are from Mars. Women are from Venus. Computers are from hell| #> =/ () `----------------------------------------------------------------' 4 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 1: 8:36 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 C167D37B401 for ; Thu, 17 Oct 2002 01:08:34 -0700 (PDT) Received: from web10412.mail.yahoo.com (web10412.mail.yahoo.com [216.136.128.126]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C3C343E88 for ; Thu, 17 Oct 2002 01:08:34 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20021017080834.24087.qmail@web10412.mail.yahoo.com> Received: from [12.236.91.184] by web10412.mail.yahoo.com via HTTP; Thu, 17 Oct 2002 01:08:34 PDT Date: Thu, 17 Oct 2002 01:08:34 -0700 (PDT) From: Oleg Polyakov Subject: Re: delayed ACK To: freebsd-net@FreeBSD.ORG In-Reply-To: <3DAC9D37.7060701@expertcity.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 --- Steve Francis wrote: > Lars Eggert wrote: > > >Paul Herman wrote: > > > > > >>Not true. Although some bugs have been fixed in 4.3, FreeBSD's > >>delayed ACKs will still degrade your performance dramatically in > >>some cases. > >> > >> > > > >I'm sorry, but such statements without a packet trace that exhibits the > >problem are just not useful. > > > >Lars > > > > > He's probably referring to poorly behaved windows clients, on certain > applications, if you leave net.inet.tcp.slowstart_flightsize at default. > > Incidentally, why are not the defaults on > net.inet.tcp.slowstart_flightsize higher? > RFC2414 seems to indicate it should be higher. Solaris in version 8 and > later default to 4 for this value. As you may know there is RFC draft which will replace RFC2414 (draft-ietf-tsvwg-initwin-04). It also require to decrease cwnd in case we decreasing MSS because of PMTU Discovery to prevent small packet bursts. I've got patches, they are pretty trvial - somebody with commit bit has to take a look and put them in a tree. ---- Oleg __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.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 Oct 17 1:56: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 D8DA937B401 for ; Thu, 17 Oct 2002 01:56:21 -0700 (PDT) Received: from helios.earthmagic.org (helios.earthmagic.org [198.78.66.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BE6C43E7B for ; Thu, 17 Oct 2002 01:56:21 -0700 (PDT) (envelope-from lonewolf-freebsd@earthmagic.org) Received: (qmail 65902 invoked from network); 17 Oct 2002 08:56:16 -0000 Received: from ppp751.vic.padsl.internode.on.net (HELO Lara.earthmagic.org) (eo-lonewolf@150.101.210.238) by helios.earthmagic.org with DES-CBC3-SHA encrypted SMTP; 17 Oct 2002 08:56:16 -0000 Message-Id: <5.1.0.14.2.20021017184945.02958380@helios.earthmagic.org> X-Sender: eo-lonewolf@helios.earthmagic.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Oct 2002 18:55:26 +1000 To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org From: "J. 'LoneWolf' Mattsson" Subject: Re: RFC: BSD network stack virtualization In-Reply-To: <20021017065904.GA16310@erg.verweg.com> References: <3DADD864.15757E4E@tel.fer.hr> <3DADD864.15757E4E@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 08:59 17/10/2002 +0200, Ruben van Staveren wrote: >Isn't this something that can overcome the current shortcomings of jail(2) ? >(the no other stacks/no raw sockets problem) I've been tempted at looking into jail-ifying raw sockets as well, but time has precluded me from doing so (and from tracking -stable regularly). I must say that this virtualization sounds very promising in making the jail even more useful! And of course all the other avenues that are made possible with this. I guess the main/traditional question to ask first would be: This change adds abstraction, therefore it probably reduces performance - by how much? Thanks for the initiative Marko, I hope this will be seriously considered for inclusion (barring any negative side-effects of it). And I hope I'll have a chance to give it a test-drive soon! :) Cheers, /Johny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 3:20: 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 2D89537B401 for ; Thu, 17 Oct 2002 03:20:07 -0700 (PDT) Received: from firmlai.bal.ru (firmlai.bal.ru [195.42.138.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ED1943E6A for ; Thu, 17 Oct 2002 03:20:00 -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 g9HAJl661870 for ; Thu, 17 Oct 2002 14:19:49 +0400 (MSD) Date: Thu, 17 Oct 2002 14:20:04 +0400 From: Oleg Borowkov X-Mailer: The Bat! (v1.61) Reply-To: Oleg Borowkov Organization: LAI Firm X-Priority: 3 (Normal) Message-ID: <1317582544.20021017142004@firmlai.bal.ru> Disposition-Notification-To: oleg@firmlai.bal.ru To: freebsd-net@FreeBSD.ORG Subject: trouble with wireless link 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! Help me fix trouble with wireless link: /sbin/ifconfig wi0 inet 192.168.1.1/24 channel 7 nwkey secret ssid mynet /var/log/messages: Oct 17 16:57:28 dom1 /kernel: pccard: card inserted, slot 0 Oct 17 16:57:28 dom1 pccardd[41]: Card "Lucent Technologies"("WaveLAN/IEEE") [Ve rsion 01.01] [] matched "Lucent Technologies" ("WaveLAN/IEEE") [(null)] [(null)] Oct 17 16:57:33 dom1 /kernel: wi0 at port 0x240-0x27f irq 3 slot 0 on pccard0 Oct 17 16:57:33 dom1 /kernel: wi0: 802.11 address: 00:02:2d:3a:d3:97 Oct 17 16:57:33 dom1 /kernel: wi0: using Lucent Technologies, WaveLAN/IEEE Oct 17 16:57:33 dom1 /kernel: wi0: Lucent Firmware: Station 8.10.01 Oct 17 16:57:33 dom1 pccardd[41]: wi0: Lucent Technologies (WaveLAN/IEEE) inserted. link ~30km long: # ping -c3 192.168.1.2 PING 192.168.1.2 (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=128 time=7.465 ms 64 bytes from 192.168.1.2: icmp_seq=0 ttl=128 time=18.968 ms (DUP!) 64 bytes from 192.168.1.2: icmp_seq=0 ttl=128 time=28.423 ms (DUP!) 64 bytes from 192.168.1.2: icmp_seq=0 ttl=128 time=30.504 ms (DUP!) 64 bytes from 192.168.1.2: icmp_seq=1 ttl=128 time=10.231 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=128 time=32.439 ms (DUP!) 64 bytes from 192.168.1.2: icmp_seq=2 ttl=128 time=9.234 ms --- 192.168.1.2 ping statistics --- 3 packets transmitted, 3 packets received, +4 duplicates, 0% packet loss round-trip min/avg/max/stddev = 7.465/19.609/32.439/10.032 ms AP - freebsd 4.6 + linksys wmp11 Client - freebsd 4.6 + orinoco silver all work fine, but duplicated paket's degrade speed... help me fix this... Big thnk -- 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 Thu Oct 17 4: 2:20 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 9894437B401; Thu, 17 Oct 2002 04:02:18 -0700 (PDT) Received: from premijer.tel.fer.hr (premijer.tel.fer.hr [161.53.19.221]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D55D43E97; Thu, 17 Oct 2002 04:02:13 -0700 (PDT) (envelope-from zec@tel.fer.hr) Received: from tel.fer.hr (zec-laptop.tel.fer.hr [161.53.19.8]) by premijer.tel.fer.hr (Postfix) with ESMTP id F1F681380; Thu, 17 Oct 2002 13:01:44 +0200 (MET DST) Message-ID: <3DAE98B4.4058023A@tel.fer.hr> Date: Thu, 17 Oct 2002 13:02:13 +0200 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "J. 'LoneWolf' Mattsson" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: RFC: BSD network stack virtualization References: <3DADD864.15757E4E@tel.fer.hr> <3DADD864.15757E4E@tel.fer.hr> <5.1.0.14.2.20021017184945.02958380@helios.earthmagic.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 "J. 'LoneWolf' Mattsson" wrote: > At 08:59 17/10/2002 +0200, Ruben van Staveren wrote: > >Isn't this something that can overcome the current shortcomings of jail(2) ? > >(the no other stacks/no raw sockets problem) It should be possible even to run multiple jails within each virtual image, if one wishes to do so :) Actually, my code reuses the jail framework for providing separation (hiding) between the user processes, therefore the behavior in that area will be very similar. Everything else done on the networking layer is free of "jail" legacy, as my concept is completely different: providing multiple truly independent network stacks, instead of hiding parts of the monolithic one, which was the approach taken by jail implementation. An additional goodie is the introduction of soft limit option on average CPU usage per each virtual image. This can be very useful in virtual hosting applications, to prevent starving of CPU resources from runaway or malicious processes running in a single virtual image. > I've been tempted at looking into jail-ifying raw sockets as well, but time > has precluded me from doing so (and from tracking -stable regularly). I > must say that this virtualization sounds very promising in making the jail > even more useful! And of course all the other avenues that are made > possible with this. I guess the main/traditional question to ask first > would be: > This change adds abstraction, therefore it probably reduces performance - > by how much? In most parts of the code the virtualization is achieved via introduction of a single additional level of indirection for all virtualized symbols/variables, which are now contained in the new struct vimage, unique for each virtual image. Therefore the calls to most of the networking functions within the kernel had to be extended with an additional argument, which passes the pointer to the current vimage struct. This additional overhead shouldn't present a to significant problem, particularly not for the current 1+ GHz CPUs with fast memory. Some preliminary tests (netperf on TCP flows) show that the performance penalty is generally minimal, somewhere around 1-2%, compared to normal maximum throughputs (not limited by the media speed). As I perform more systematic and accurate measurements, I'll post them on my web page. Best regards, Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 5: 7: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 D522337B401 for ; Thu, 17 Oct 2002 05:07:33 -0700 (PDT) Received: from mail1.ugr.es (mail1.ugr.es [150.214.20.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D1C843E77 for ; Thu, 17 Oct 2002 05:07:25 -0700 (PDT) (envelope-from fran@ugr.es) Received: from mail1.ugr.es (localhost [127.0.0.1]) by mail1.ugr.es (8.9.3/8.9.3) with ESMTP id OAA09651 for ; Thu, 17 Oct 2002 14:07:19 +0200 (MEST) Received: from goliat.ugr.es (goliat.ugr.es [150.214.20.3]) by mail1.ugr.es (8.9.3/8.9.3) with ESMTP id OAA09642 for ; Thu, 17 Oct 2002 14:07:18 +0200 (MEST) Received: from pcb2bis (pcb2bis.ugr.es [150.214.35.65]) by goliat.ugr.es (8.9.3/8.9.1) with SMTP id OAA17450 for ; Thu, 17 Oct 2002 14:07:16 +0200 (MEST) Message-ID: <002901c275d5$fe4e8dc0$4123d696@ugr.es> Reply-To: "Francisco J. Medina Jimenez" From: "Francisco J. Medina Jimenez" To: Subject: performance of pptp with mpd Date: Thu, 17 Oct 2002 14:09:05 +0200 Organization: Servicios de Informatica y Redes de Comunicaciones. Universidad de Granada MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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'm testing mpd 3.9 with FreeBSD 4.6.2. The performance of transfers using W2k clients is much better than using XP or Win9x (in same conditions). Are there any parameters to adjust or it's problem of pptp client implementation? Thanks in advance. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 5:14: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 B46CA37B401 for ; Thu, 17 Oct 2002 05:14:25 -0700 (PDT) Received: from jawa.at (inforum.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id C183D43E65 for ; Thu, 17 Oct 2002 05:14:08 -0700 (PDT) (envelope-from mbretter@inode.at) Received: (from root@localhost) by jawa.at (8.11.6/8.11.6) id g9HCDl584238 for freebsd-net@freebsd.org; Thu, 17 Oct 2002 14:13:47 +0200 (CEST) (envelope-from mbretter@inode.at) Received: from inode.at (dings.jawa.at [192.168.200.60]) by jawa.at (8.11.6/8.11.6av) with ESMTP id g9HCDj284230 for ; Thu, 17 Oct 2002 14:13:45 +0200 (CEST) (envelope-from mbretter@inode.at) Message-ID: <3DAEA97A.4050907@inode.at> Date: Thu, 17 Oct 2002 14:13:46 +0200 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: de-at, de, en, en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: performance of pptp with mpd References: <002901c275d5$fe4e8dc0$4123d696@ugr.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 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, you can try: set ccp yes mpp-stateless or you can try to comment out this line. I had similar problems some weeks ago with this option. bye, Francisco J. Medina Jimenez schrieb: > Hi. > > I'm testing mpd 3.9 with FreeBSD 4.6.2. The performance of transfers > using W2k clients is much better than using XP or Win9x (in same > conditions). Are there any parameters to adjust or it's problem of pptp > client implementation? > > Thanks in advance. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > -- ------------------------------- ---------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat ------------ A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: mbretter@inode.at Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 8: 4: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 14F0837B401; Thu, 17 Oct 2002 08:04:59 -0700 (PDT) Received: from cisco.com (sword.cisco.com [161.44.208.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14D6143E42; Thu, 17 Oct 2002 08:04:58 -0700 (PDT) (envelope-from sjt@cisco.com) Received: from sjt-u10.cisco.com (sjt-u10.cisco.com [10.85.30.63]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA26633; Thu, 17 Oct 2002 11:04:56 -0400 (EDT) Received: (sjt@localhost) by sjt-u10.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id LAA15828; Thu, 17 Oct 2002 11:04:56 -0400 (EDT) Date: Thu, 17 Oct 2002 11:04:56 -0400 From: Steve Tremblett To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Netgraph TCP/IP Message-ID: <20021017110456.G15035@sjt-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 A while back someone was fishing for a project to take on and someone suggested a complete TCP/IP implementation in netgraph. I found the idea interesting and am considering taking a shot at it. My main goal in all this is to learn as much as possible and at this point I'm just reading. While this is a personal educational project, I figure I should propose it here and solicit comments/thoughts/suggestions on such a venture so that maybe the results might be usable by someone else. Thanks -- Steve Tremblett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 12: 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 EBCAA37B401; Thu, 17 Oct 2002 12:00:31 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2F7143E6A; Thu, 17 Oct 2002 12:00:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0289.cvx22-bradley.dialup.earthlink.net ([209.179.199.34] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 182FsZ-0004f7-00; Thu, 17 Oct 2002 12:00:20 -0700 Message-ID: <3DAF087C.7B148341@mindspring.com> Date: Thu, 17 Oct 2002 11:59:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Tremblett Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Netgraph TCP/IP References: <20021017110456.G15035@sjt-u10.cisco.com> 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 Steve Tremblett wrote: > A while back someone was fishing for a project to take on and someone > suggested a complete TCP/IP implementation in netgraph. I found the > idea interesting and am considering taking a shot at it. My main goal > in all this is to learn as much as possible and at this point I'm just > reading. > > While this is a personal educational project, I figure I should propose > it here and solicit comments/thoughts/suggestions on such a venture so > that maybe the results might be usable by someone else. Start with just a TCP implementation, after exposing a raw IP interface as a netgraph node. This will make your life much easier. There is a lot of promiscuous knowledge in the code, both for packets on the way in, and packets on the way out. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 13: 9: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 E989537B401; Thu, 17 Oct 2002 13:09:14 -0700 (PDT) Received: from venus.vincentjardin.net (AVelizy-102-1-4-2.abo.wanadoo.fr [80.11.204.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E362C43E42; Thu, 17 Oct 2002 13:09:13 -0700 (PDT) (envelope-from jardin@venus.vincentjardin.net) Received: by venus.vincentjardin.net (Postfix, from userid 501) id E98171503A0; Thu, 17 Oct 2002 22:01:11 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: Terry Lambert Subject: Re: Netgraph TCP/IP Date: Thu, 17 Oct 2002 22:01:11 +0200 X-Mailer: KMail [version 1.3.1] References: <20021017110456.G15035@sjt-u10.cisco.com> <3DAF087C.7B148341@mindspring.com> In-Reply-To: <3DAF087C.7B148341@mindspring.com> Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20021017200111.E98171503A0@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 I do not think that you need a raw IP netgraph node. Something similar already exists. Why not use the ng_ksocket in order to open a raw IP socket under your TCP node ? Vincent Le Jeudi 17 Octobre 2002 20:59, vous avez écrit : > Steve Tremblett wrote: > > A while back someone was fishing for a project to take on and someone > > suggested a complete TCP/IP implementation in netgraph. I found the > > idea interesting and am considering taking a shot at it. My main goal > > in all this is to learn as much as possible and at this point I'm just > > reading. > > > > While this is a personal educational project, I figure I should propose > > it here and solicit comments/thoughts/suggestions on such a venture so > > that maybe the results might be usable by someone else. > > Start with just a TCP implementation, after exposing a raw IP > interface as a netgraph node. This will make your life much > easier. There is a lot of promiscuous knowledge in the code, > both for packets on the way in, and packets on the way out. > > -- Terry > > 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 Thu Oct 17 13:11: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 A174A37B404 for ; Thu, 17 Oct 2002 13:11:20 -0700 (PDT) Received: from chimie.u-strasbg.fr (chimie.u-strasbg.fr [130.79.34.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id E86C443E88 for ; Thu, 17 Oct 2002 13:11:19 -0700 (PDT) (envelope-from guybrand@chimie.u-strasbg.fr) Received: from localhost (localhost.u-strasbg.fr [127.0.0.1]) by chimie.u-strasbg.fr (Postfix) with ESMTP id ECE69FB84F; Thu, 17 Oct 2002 22:11:10 +0200 (CEST) Received: from mathilda.u-strasbg.fr (chimie.u-strasbg.fr [130.79.34.77]) by chimie.u-strasbg.fr (Postfix) with ESMTP id 4B750FB849 for ; Thu, 17 Oct 2002 22:11:10 +0200 (CEST) Received: by mathilda.u-strasbg.fr (Postfix, from userid 1001) id 8B1F634501; Thu, 17 Oct 2002 22:11:09 +0200 (CEST) Date: Thu, 17 Oct 2002 22:11:09 +0200 From: Guy Brand To: freebsd-net@FreeBSD.ORG Subject: No bridge with Ifs and Vlans Message-ID: <20021017201109.GQ43318@chimie.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Organization: ISIS ULP, Strasbourg, France X-Virus-Scanned: by AMaViS snapshot-20010714 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 setting up a 3 NICs bridge using Intel cards under FreeBSD 4.7. The trunk has traffic with three different VLAN tags (111,222,800). I have 802.1q aware switches behind my two internal interfaces and they should only get some tagged frames (ipfw use planned to get rid of unwanted VLAN traffic) : ___ fxp1 --- switch1 of VLAN 111,222,800 / / VLANs 111,222,800 ===== em0 \ \___ fxp2 --- switch2 of VLAN 111 After bridging the three interfaces (sysctl), a dump at em0 shows all tagged frames coming from the trunk but a dump at fxp1 or fxp2 show nothing (dump with "tcpdump -nle -i..."), bridge dysfunction ? Setting up VLAN interfaces for VLAN ID 111 : ifconfig vlan0 vlan 111 vlandev em0 ifconfig vlan1 vlan 111 vlandev fxp1 ifconfig vlan2 vlan 111 vlandev fxp2 and bridging them (vlanX) together doesn't change anything. What have I missed ? -- bug sleepless To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 13:48: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 617DB37B401; Thu, 17 Oct 2002 13:48:23 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4D9743E8A; Thu, 17 Oct 2002 13:48:22 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0289.cvx22-bradley.dialup.earthlink.net ([209.179.199.34] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 182HZ5-0002TA-00; Thu, 17 Oct 2002 13:48:19 -0700 Message-ID: <3DAF21CA.60031059@mindspring.com> Date: Thu, 17 Oct 2002 13:47:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Jardin Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Netgraph TCP/IP References: <20021017110456.G15035@sjt-u10.cisco.com> <3DAF087C.7B148341@mindspring.com> <20021017200111.E98171503A0@venus.vincentjardin.net> 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 Vincent Jardin wrote: > I do not think that you need a raw IP netgraph node. Something similar > already exists. Why not use the ng_ksocket in order to open a raw IP socket > under your TCP node ? Because the packet will never get to your protocol processing, unless you turn of standard TCP altogether, and even then, the pr_input will not do the right thing for chaining the data up to a Netgraph node. ip_input.c: ... if (args.next_hop && ip->ip_p == IPPROTO_TCP) { /* TCP needs IPFORWARD info if available */ struct m_hdr tag; tag.mh_type = MT_TAG; tag.mh_flags = PACKET_TAG_IPFORWARD; tag.mh_data = (caddr_t)args.next_hop; tag.mh_next = m; (*inetsw[ip_protox[ip->ip_p]].pr_input)( (struct mbuf *)&tag, hlen); } else (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); ... For this to work, you have to have a pr_input that glues into a Netgraph entry point, so that IP packets of a specific protocol type captured by the Netgraph node get passed to it. There is also the m_pullup() issue of the TCP protocol that is being passed IP datagrams which may be frags of TCP packets, in order to get the full TCP header, with options. Minimally, the approach has to be a seperate TCP stack, which is given a different protocol number for the purposes of experiment, so that you can have a duplicate TCP stack on both sides using the normal mechanism, and replace it on one side with the Netgraph version equivalen. See the LRP implementation from Rice University, or the updated port by Duke University. They both use this approach to run a stack, and other primitives, in paralell on the system. That is also why the code, as it sits in their source bases, would take some work to integrate fully into FreeBSD (license issues aside) as the default protocol processing path. Actually, it would take much longer now that the SYN cache and the polling code has obfuscated things. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 13:55: 9 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 ECD8437B401 for ; Thu, 17 Oct 2002 13:55:08 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA95343E97 for ; Thu, 17 Oct 2002 13:55:04 -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 g9HKsuYj077213; Thu, 17 Oct 2002 23:55:02 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <0be401c2761f$855af670$8c2a40c1@PHE> From: "Petri Helenius" To: "Lars Eggert" Cc: "Luigi Rizzo" , References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> Subject: Re: ENOBUFS Date: Thu, 17 Oct 2002 23:55:24 +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 > > Less :-) Let me tell you tomorrow, don't have the numbers here right now. I seem to get about 5-6 packets on an interrupt. Is this tunable? At 50kpps the card generates 10k interrupts a second. Sending generates way less. This is about 300Mbps so with the average packet size of 750 there should be room for more packets on the interface queue before needing to service an interrupt? What´s the way to access kernel adapter-structure? Is there an utility that can view the values there? > Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 16:20: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 07A5837B401; Thu, 17 Oct 2002 16:20:10 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6534C43E75; Thu, 17 Oct 2002 16:20:09 -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 <20021017232008.HORB26432.sccrmhc02.attbi.com@InterJet.elischer.org>; Thu, 17 Oct 2002 23:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA03531; Thu, 17 Oct 2002 16:03:13 -0700 (PDT) Date: Thu, 17 Oct 2002 16:03:12 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Vincent Jardin , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Netgraph TCP/IP In-Reply-To: <3DAF21CA.60031059@mindspring.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 Thu, 17 Oct 2002, Terry Lambert wrote: > Vincent Jardin wrote: > > I do not think that you need a raw IP netgraph node. Something similar > > already exists. Why not use the ng_ksocket in order to open a raw IP socket > > under your TCP node ? > > Because the packet will never get to your protocol processing, unless > you turn of standard TCP altogether, and even then, the pr_input will > not do the right thing for chaining the data up to a Netgraph node. > > ip_input.c: > ... > if (args.next_hop && ip->ip_p == IPPROTO_TCP) { > /* TCP needs IPFORWARD info if available */ > struct m_hdr tag; > > tag.mh_type = MT_TAG; > tag.mh_flags = PACKET_TAG_IPFORWARD; > tag.mh_data = (caddr_t)args.next_hop; > tag.mh_next = m; > > (*inetsw[ip_protox[ip->ip_p]].pr_input)( > (struct mbuf *)&tag, hlen); > } else > (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); > > ... This has been changed with the addition of the new OOB tag metadata methods committed by sam Leffler a few days ago. This were specifically designed to co-operate with the netgraph OOB data requirements. I will be modifying netgraph over the next few weeks (I hope) to use the new scheme. This will allow seamless flow of metadata between netgaph and other networking components. (e.g. the 'fwd' info above) > > For this to work, you have to have a pr_input that glues into a > Netgraph entry point, so that IP packets of a specific protocol > type captured by the Netgraph node get passed to it. it will all "fall into place" with the new scheme, once I have converted netgraph to use it. > > There is also the m_pullup() issue of the TCP protocol that is > being passed IP datagrams which may be frags of TCP packets, in > order to get the full TCP header, with options. The tcp code should handle this anyway. > > Minimally, the approach has to be a seperate TCP stack, which is > given a different protocol number for the purposes of experiment, > so that you can have a duplicate TCP stack on both sides using > the normal mechanism, and replace it on one side with the Netgraph > version equivalen. Not necessarily.. if each stack can 'reject' a packet.. ("not mine"). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 16:22: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 1273F37B401 for ; Thu, 17 Oct 2002 16:22:45 -0700 (PDT) Received: from sigbus.com (c-24-126-10-97.we.client2.attbi.com [24.126.10.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E1CC43E6A for ; Thu, 17 Oct 2002 16:22:44 -0700 (PDT) (envelope-from henrich@sigbus.com) Received: (from henrich@localhost) by sigbus.com (8.11.1/8.11.1) id g9HNMhq90134 for freebsd-net@freebsd.org; Thu, 17 Oct 2002 16:22:43 -0700 (PDT) (envelope-from henrich) Date: Thu, 17 Oct 2002 16:22:43 -0700 From: Charles Henrich To: freebsd-net@freebsd.org Subject: IPSEC/NAT issues Message-ID: <20021017162243.B89519@sigbus.com> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F X-GPG-Fingerprint: EA4C AB9B 0C38 17C0 AB3F 11DE 41F6 5883 41E7 4F49 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 apologize for not CC'ing originally! I have a network/firewall where I want to nat an entire network. However, I also want nat traffic to one remote host in particular out on the internet to be IPsec'd as well. [A] (10.x) [B] (Nat) [C] (Real IP) I've setup IPsec on both machines, and from either machine (B,C) I can ssh to the other, with ipsec packets all happening happy as a clam. However if try a connection from behind the nat box to the remote host (A,C) the key exchange works fine (between B&C), but then no data flows back and forth. Anyone have any suggestions on this? Thanks! -Crh Charles Henrich henrich@msu.edu http://www.sigbus.com/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 17: 6: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 021B237B401 for ; Thu, 17 Oct 2002 17:06:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AAAF43E77 for ; Thu, 17 Oct 2002 17:06:54 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9I06qC11308; Thu, 17 Oct 2002 17:06:52 -0700 (PDT) Message-ID: <3DAF509C.6030002@isi.edu> Date: Thu, 17 Oct 2002 17:06:52 -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: Charles Henrich Cc: freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues References: <20021017162243.B89519@sigbus.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060803050607000600040702" 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. --------------ms060803050607000600040702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Charles Henrich wrote: > > I have a network/firewall where I want to nat an entire network. However, I > also want nat traffic to one remote host in particular out on the internet to > be IPsec'd as well. > > [A] (10.x) [B] (Nat) [C] (Real IP) There was a thread on -hackers named "VPN Routing through gif (4) tunnel" a few weeks ago that dealt with a very similar issue. Lars -- Lars Eggert USC Information Sciences Institute --------------ms060803050607000600040702 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 hvcNAQkFMQ8XDTAyMTAxODAwMDY1MlowIwYJKoZIhvcNAQkEMRYEFL7xv454gZRvFs6NOi2P QSBap729MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEADojR5Y8gGgJI35SXZuR9mG8h0SN1zn0DbvV61DByXUzhDkkDbkPw /Uw4OKTKQWBib1k2r0XBze+JeW8OSJ6beN9mohsKQbX7IfMtufQKVrozVERa/te9YyLZGb/l 6dM9L6emCJ6edWOBffmpsax2DfTSYwVPJLpeyIn6mVyCWVegc57W6A70rMB0gVQm9Doe3Rnl hLtkRqkvZ73RUS7xIxug6ClXQObHL7x99w2pF0S01bJE+9vdTTDWPgTMq11X6f3K8uUxuUDA oeUOEX6UNgk7NN6mjTe0nk1nUm4JCbFANesVutyGeE3slKlXQSvxoBqxC2d446IrFORQXKSr SwAAAAAAAA== --------------ms060803050607000600040702-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 17:29: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 C3BBD37B401 for ; Thu, 17 Oct 2002 17:29:08 -0700 (PDT) Received: from sigbus.com (c-24-126-10-97.we.client2.attbi.com [24.126.10.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECB6943EA9 for ; Thu, 17 Oct 2002 17:29:07 -0700 (PDT) (envelope-from henrich@sigbus.com) Received: (from henrich@localhost) by sigbus.com (8.11.1/8.11.1) id g9I0T5j92007; Thu, 17 Oct 2002 17:29:05 -0700 (PDT) (envelope-from henrich) Date: Thu, 17 Oct 2002 17:29:05 -0700 From: Charles Henrich To: Lars Eggert Cc: freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues Message-ID: <20021017172905.A91625@sigbus.com> Mail-Followup-To: Lars Eggert , freebsd-net@freebsd.org References: <20021017162243.B89519@sigbus.com> <3DAF509C.6030002@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DAF509C.6030002@isi.edu>; from larse@ISI.EDU on Thu, Oct 17, 2002 at 05:06:52PM -0700 X-Operating-System: FreeBSD 4.2-RELEASE X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F X-GPG-Fingerprint: EA4C AB9B 0C38 17C0 AB3F 11DE 41F6 5883 41E7 4F49 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 network/firewall where I want to nat an entire network. However, > > I also want nat traffic to one remote host in particular out on the > > internet to be IPsec'd as well. > > > > [A] (10.x) [B] (Nat) [C] (Real IP) > > There was a thread on -hackers named "VPN Routing through gif (4) tunnel" a > few weeks ago that dealt with a very similar issue. I've looked through those, and it doesnt quite seem to apply? What im doing is transport mode ESP between my nat gateway and the remote host. this works properly. in my firewall rules I have allow esp packets to and from remote host divert to nat Now from host A, if I try a connection to IP C, then on the gateway I see racoon fire up and establish a working IPSEC path between B&C. Further it looks like it properly encapsulates the packets and forwards them on to host C, which appears to properly respond to them. On host B, they are unencrypted and for some reason they do not make a path into natd for un-natting. The nat daemon does not log any rejections of the packet, however in my kernel log, I see a Oct 17 17:23:51 dmz /kernel: Connection attempt to TCP B:3283 from C:22 Is the esp mucking with the in/out interface perhaps? If Im logged into host B, I can connect to Host C succesfully using the transport mode connection no problem. Its just this last little bit of natd not processing the packets. Im thinking im doing something silly. but I cant see what. -Crh Charles Henrich henrich@msu.edu http://www.sigbus.com/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 17:48: 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 8193837B401; Thu, 17 Oct 2002 17:47:59 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F84343E6A; Thu, 17 Oct 2002 17:47:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0180.cvx40-bradley.dialup.earthlink.net ([216.244.42.180] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 182LIr-0000tA-00; Thu, 17 Oct 2002 17:47:49 -0700 Message-ID: <3DAF59ED.D14BD089@mindspring.com> Date: Thu, 17 Oct 2002 17:46:37 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Vincent Jardin , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Netgraph TCP/IP References: 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 Julian Elischer wrote: > > There is also the m_pullup() issue of the TCP protocol that is > > being passed IP datagrams which may be frags of TCP packets, in > > order to get the full TCP header, with options. > > The tcp code should handle this anyway. It should, but it won't. The issue is when you need to make a decision based on TCP packet contents, but you don't have a complete packet. The expected behaviour is to call m_pullup. For a Netgraph version of this, you will either need a context (there isn't one at that point -- it runs at NETISR), or you will need to be able to restart tcp_input(). The problem with that is that it's expensive. Effectively, you almost need to seperate out the frag code before, and assemble whole packets before going into the traditional tcp_input(). Lemon has some good idea in this area; so do I. I've got code here, where I've moved around some of the operations to delay computations until fill data is available (which would avoid recomputation). > > Minimally, the approach has to be a seperate TCP stack, which is > > given a different protocol number for the purposes of experiment, > > so that you can have a duplicate TCP stack on both sides using > > the normal mechanism, and replace it on one side with the Netgraph > > version equivalen. > > Not necessarily.. if each stack can 'reject' a packet.. ("not mine"). The problem with this one is that the packet in this case is TCP. Ideally, what you would like for the developement case is to be able to tag particular flows as going to one TCP stack vs. the other; then by examining the flow tag, youy would be able to decide where to handle the packet (this also implies moving the frag reassembly to a seperate "layer"). Then you could flag a flow, and have it dealt with that way. In FreeBSD's lower level code, though, IP flows aren't really treated as flows; this is partly an artifact of the routing code, itself, and partly an artifact if inpcbhash(), which is actually broken. The hash on iput for a flow vs. output on a flow allocation is also broken; consider, that you can make a connection on an outbound socket which is not bound, from a specific source IP address, with no specific source port, and the source port contention is handled globally, rather than locally -- thus limiting you to 65535 maximum outbound connections on a single machine (the number of ports in a single globally contended IP address space, despite the fact that your source IP was specified). What this adss up to is that if you want to run stacks in parallel, they can't share protocol numbers, because the code does not really distinguish them at the proper layer, but instead, distinguishes them off-by-one. This actually makes processing slower overall, as well; consider that the fast forwarding code does a lookup, which, on a miss, is then passed up to the TCP to do another lookup, rather than passing the lookup result as part of the context. What this basically means is that the hash entries for the values are not shared, with a single hit-per-flow, and the more "fast forwarding" you do, the slower normal processing goes. The same happens for the SYN cache context lookup. It basically really slows down the code, to not do the hash lower down, and then make the decision on the basis of the result of identifying the flow. In a general sense, what you would need to do to do what you suggest is to pass all packets through all possible stacks, until you hit the "default" one -- the standard TCP -- and rely on all the other stacks to not eat the packet. In practice, this means that every IP protocol, except TCP, ends up getting rewritten for Netgraph use, until TCP gets rewritten, and then your lookup is O(N*MAX(1,flow_count/hash_size)), where N is the number of IP protocols (TCP, UDP, RTP, etc.). Also, in practice, this still doubles the overhead for things that need to be pre-decided (flow identification for IP fast forwarding, DSR, splicing, etc.), and that none of these things can really be safely implemented as Netgraph modules. Yeah, it can be made to function correctly that way, but it won't function quickly. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 17:56: 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 EBD2137B401 for ; Thu, 17 Oct 2002 17:56:03 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B5F143E88 for ; Thu, 17 Oct 2002 17:56:03 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9I0u2C21626; Thu, 17 Oct 2002 17:56:02 -0700 (PDT) Message-ID: <3DAF5C21.6000108@isi.edu> Date: Thu, 17 Oct 2002 17:56:01 -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: Charles Henrich Cc: freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues References: <20021017162243.B89519@sigbus.com> <3DAF509C.6030002@isi.edu> <20021017172905.A91625@sigbus.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090601060501040507040902" 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. --------------ms090601060501040507040902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Charles Henrich wrote: > The nat daemon does not log any rejections of the packet, however in my kernel > log, I see a > > Oct 17 17:23:51 dmz /kernel: Connection attempt to TCP B:3283 from C:22 Your packets don't seem to reach natd after IPsec inbound processing. Looks like ipfw processing happens before IPsec (so natd sees the IPsec'ed packets, but doesn't know anything about them), and gets thems them after IPsec inbound processing. What you want is a way to do IPsec first, and then ipfw processing, but I don't know if that can be done. Try configuring an IPIP tunnel between B and C, and transport-mode IPsec that. That way, your NAT packets get tunneled, and the tunneled packets secured. On inbound, security processing comes first, then decapsulation, then ipfw. Lars -- Lars Eggert USC Information Sciences Institute --------------ms090601060501040507040902 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 hvcNAQkFMQ8XDTAyMTAxODAwNTYwMlowIwYJKoZIhvcNAQkEMRYEFO35qziQ1Yg/0LZyppEx Rvrz2Mv4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAjpeBPwrbYeytluGzq7basyM8Mi2AjApNvDr8n1wAqjjjFpf6AeWr leatF4j4m3f7bAGSlpnDfuNOSsUMh5/iLtGl6So2z0ntcV4AkyX9UjZIicoH2dSI3l/RLIz7 Rj/nHCLQzm1fOer4HdcjpIgOF+FhGkzPKw3Ca19GUp1ehZqkoFNNCfLkxQXgLr6dorV5iIV1 qGiwIWK1MWHD+yG3uwsOdBpZB9oD2wWR2b3fr+tDhdvL9s7aOkJoOJeCboSaizvBKuvPL95k KvnDn+3VSMTTEPrMdjmgAZnGWZc5nkpnUZc0SN0/d76cnDVkD5ghr36vri9tSArfamFDWgfH ewAAAAAAAA== --------------ms090601060501040507040902-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 20:12: 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 EDFDE37B401 for ; Thu, 17 Oct 2002 20:11:59 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 933C843E6E for ; Thu, 17 Oct 2002 20:11:59 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9I3BxpJ075516; Thu, 17 Oct 2002 20:11:59 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9I3BwUm075515; Thu, 17 Oct 2002 20:11:58 -0700 (PDT) (envelope-from rizzo) Date: Thu, 17 Oct 2002 20:11:58 -0700 From: Luigi Rizzo To: Petri Helenius Cc: Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021017201158.A75351@carp.icir.org> References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> <0be401c2761f$855af670$8c2a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <0be401c2761f$855af670$8c2a40c1@PHE>; from pete@he.iki.fi on Thu, Oct 17, 2002 at 11:55:24PM +0300 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, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: ... > I seem to get about 5-6 packets on an interrupt. Is this tunable? At just reading the source code, yes, it appears that the card has support for delayed rx/tx interrupts -- see RIDV and TIDV definitions and usage in sys/dev/em/* . I don't know in what units are the values (28 and 128, respectively), but it does appear that tx interrupts are delayed a bit more than rx interrupts. They are not user-configurable at the moment though, you need to rebuild the kernel. cheers luigi > 50kpps the card generates 10k interrupts a second. Sending generates > way less. This is about 300Mbps so with the average packet size of > 750 there should be room for more packets on the interface queue > before needing to service an interrupt? > > What´s the way to access kernel adapter-structure? Is there an utility > that can view the values there? > > > Pete > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 21:15: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 466D637B401 for ; Thu, 17 Oct 2002 21:15:37 -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 3793D43E77 for ; Thu, 17 Oct 2002 21:15:36 -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 VAA85147; Thu, 17 Oct 2002 21:10:56 -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 g9I4AuON020821; Thu, 17 Oct 2002 21:10:56 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9I4AsvJ020820; Thu, 17 Oct 2002 21:10:54 -0700 (PDT) From: Archie Cobbs Message-Id: <200210180410.g9I4AsvJ020820@arch20m.dellroad.org> Subject: Re: MPD PPTP tunneling intermittantly fails In-Reply-To: <20021017021849.GA1354@otdel1.org> "from Nikolai Saoukh at Oct 17, 2002 06:18:49 am" To: Nikolai Saoukh Date: Thu, 17 Oct 2002 21:10:54 -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 Nikolai Saoukh writes: > | That doesn't look so good. But it doesn't look "crazy" from the > | netgraph side, just like a lot of packets are being dropped. > | There must be something specific about your setup that causes this. > > Specific is MPPE. I have the same problem here. > I am digging the problem at slow pace. So far > I discoverd that mpd set mtu on interface too early, > thus without MPPE header size. But the real problem, > is the huge amount of CCP Reset Requests from win client. Hmm, try enabling the mpp-stateless option. -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 Oct 17 21:30: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 0068337B401 for ; Thu, 17 Oct 2002 21:30:12 -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 6F4F543E75 for ; Thu, 17 Oct 2002 21:30:11 -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 VAA85347; Thu, 17 Oct 2002 21:26:16 -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 g9I4QGON021047; Thu, 17 Oct 2002 21:26:16 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9I4QFxo021046; Thu, 17 Oct 2002 21:26:15 -0700 (PDT) From: Archie Cobbs Message-Id: <200210180426.g9I4QFxo021046@arch20m.dellroad.org> Subject: Re: performance of pptp with mpd In-Reply-To: <002901c275d5$fe4e8dc0$4123d696@ugr.es> "from Francisco J. Medina Jimenez at Oct 17, 2002 02:09:05 pm" To: "Francisco J. Medina Jimenez" Date: Thu, 17 Oct 2002 21:26:15 -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 Francisco J. Medina Jimenez writes: > I'm testing mpd 3.9 with FreeBSD 4.6.2. The performance of transfers > using W2k clients is much better than using XP or Win9x (in same > conditions). Are there any parameters to adjust or it's problem of pptp > client implementation? The different Windowses have different PPP characteristics. For Win9x, make sure you have the latest MS updates. Try playing with 'set link mtu ...', mpp-stateless, and enabling multilink. -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 Oct 17 21:30: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 1C61937B401; Thu, 17 Oct 2002 21:30:18 -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 043E843E91; Thu, 17 Oct 2002 21:30:16 -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 VAA85269; Thu, 17 Oct 2002 21:16:53 -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 g9I4GrON020889; Thu, 17 Oct 2002 21:16:53 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9I4GrmL020888; Thu, 17 Oct 2002 21:16:53 -0700 (PDT) From: Archie Cobbs Message-Id: <200210180416.g9I4GrmL020888@arch20m.dellroad.org> Subject: Re: Netgraph TCP/IP In-Reply-To: <20021017110456.G15035@sjt-u10.cisco.com> "from Steve Tremblett at Oct 17, 2002 11:04:56 am" To: Steve Tremblett Date: Thu, 17 Oct 2002 21:16:53 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@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 Steve Tremblett writes: > A while back someone was fishing for a project to take on and someone > suggested a complete TCP/IP implementation in netgraph. I found the > idea interesting and am considering taking a shot at it. My main goal > in all this is to learn as much as possible and at this point I'm just > reading. > > While this is a personal educational project, I figure I should propose > it here and solicit comments/thoughts/suggestions on such a venture so > that maybe the results might be usable by someone else. Are you intending to have this hook into the normal FreeBSD TCP/IP stack or be truly standalone? I read your question as the latter but others seem to read it as the former. If the latter, I'd suggest splitting it up into several netgraph nodes, eg.: | | | | | | ng_udp ng_tcp \ / \ / ng_ip | | ng_arp | | | | ng_ether -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 Oct 17 21:30: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 CC1BB37B408 for ; Thu, 17 Oct 2002 21:30:20 -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 DFB3F43E65 for ; Thu, 17 Oct 2002 21:30:19 -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 VAA85332; Thu, 17 Oct 2002 21:24:30 -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 g9I4OTON021011; Thu, 17 Oct 2002 21:24:30 -0700 (PDT) (envelope-from archie@arch20m.dellroad.org) Received: (from archie@localhost) by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9I4OTrO021010; Thu, 17 Oct 2002 21:24:29 -0700 (PDT) From: Archie Cobbs Message-Id: <200210180424.g9I4OTrO021010@arch20m.dellroad.org> Subject: Re: mpd - Radius In-Reply-To: <3DAE5495.1040409@inode.at> "from Michael Bretterklieber at Oct 17, 2002 08:11:33 am" To: Michael Bretterklieber Date: Thu, 17 Oct 2002 21:24:28 -0700 (PDT) Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG, brendan@gnarst.net 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: > But I think it will better to have something like this in the mpd.conf: > - gobal switch to enable radius support. > - switches for the different layers (link, bundle) where radius can be > used (because Radius can more the Authentication) That makes sense :-) -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 Oct 17 21:48:42 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 8F59C37B401 for ; Thu, 17 Oct 2002 21:48:40 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC1543E6A for ; Thu, 17 Oct 2002 21:48:39 -0700 (PDT) (envelope-from jimmcgra@bellatlantic.net) Received: from Default ([141.154.237.113]) by pop016.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021018044839.LNKQ1630.pop016.verizon.net@Default>; Thu, 17 Oct 2002 23:48:39 -0500 From: "Jim McGrath" To: "Luigi Rizzo" , "Petri Helenius" Cc: "Lars Eggert" , Subject: RE: ENOBUFS Date: Fri, 18 Oct 2002 00:49:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021017201158.A75351@carp.icir.org> Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop016.verizon.net from [141.154.237.113] at Thu, 17 Oct 2002 23:48:38 -0500 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 Careful here. Read the errata sheet!! I do not believe the em driver uses these parameters, and possibly for a good reason. Jim > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > Sent: Thursday, October 17, 2002 11:12 PM > To: Petri Helenius > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG > Subject: Re: ENOBUFS > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > ... > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > just reading the source code, yes, it appears that the card has > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > and usage in sys/dev/em/* . I don't know in what units are the values > (28 and 128, respectively), but it does appear that tx interrupts are > delayed a bit more than rx interrupts. > > They are not user-configurable at the moment though, you need to rebuild > the kernel. > > cheers > luigi > > > 50kpps the card generates 10k interrupts a second. Sending generates > > way less. This is about 300Mbps so with the average packet size of > > 750 there should be room for more packets on the interface queue > > before needing to service an interrupt? > > > > What´s the way to access kernel adapter-structure? Is there an utility > > that can view the values there? > > > > > Pete > > > > > > 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 Thu Oct 17 21:55:47 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 56B8737B401 for ; Thu, 17 Oct 2002 21:55:46 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99F1143E9E for ; Thu, 17 Oct 2002 21:55:45 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9I4thpJ076389; Thu, 17 Oct 2002 21:55:43 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9I4thFp076388; Thu, 17 Oct 2002 21:55:43 -0700 (PDT) (envelope-from rizzo) Date: Thu, 17 Oct 2002 21:55:43 -0700 From: Luigi Rizzo To: Jim McGrath Cc: Petri Helenius , Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021017215543.B76232@carp.icir.org> References: <20021017201158.A75351@carp.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jimmcgra@bellatlantic.net on Fri, Oct 18, 2002 at 12:49:04AM -0400 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, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote: > Careful here. Read the errata sheet!! I do not believe the em driver uses > these parameters, and possibly for a good reason. as if i had access to the data sheets :) cheers luigi > Jim > > > -----Original Message----- > > From: owner-freebsd-net@FreeBSD.ORG > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > > Sent: Thursday, October 17, 2002 11:12 PM > > To: Petri Helenius > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG > > Subject: Re: ENOBUFS > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > ... > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > just reading the source code, yes, it appears that the card has > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > and usage in sys/dev/em/* . I don't know in what units are the values > > (28 and 128, respectively), but it does appear that tx interrupts are > > delayed a bit more than rx interrupts. > > > > They are not user-configurable at the moment though, you need to rebuild > > the kernel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Oct 17 21:58: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 6BA9137B401 for ; Thu, 17 Oct 2002 21:58:58 -0700 (PDT) Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 860DF43E7B for ; Thu, 17 Oct 2002 21:58:57 -0700 (PDT) (envelope-from bsd#nms@otdel-1.org) Received: by otdel-1.org (CommuniGate Pro PIPE 4.0b9) with PIPE id 2200010; Fri, 18 Oct 2002 08:58:56 +0400 Date: Fri, 18 Oct 2002 08:58:53 +0400 From: Nikolai Saoukh To: freebsd-net@FreeBSD.ORG Subject: Re: MPD PPTP tunneling intermittantly fails Message-ID: <20021018045853.GA329@otdel1.org> Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <20021017021849.GA1354@otdel1.org> <200210180410.g9I4AsvJ020820@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200210180410.g9I4AsvJ020820@arch20m.dellroad.org> User-Agent: Mutt/1.5.1i X-Mailer: CommuniGate Pro CLI mailer 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, Oct 17, 2002 at 09:10:54PM -0700, Archie Cobbs wrote: | > is the huge amount of CCP Reset Requests from win client. | | Hmm, try enabling the mpp-stateless option. When on direct modem link the win client refuses mpp-stateless. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 0:39: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 4870437B401 for ; Fri, 18 Oct 2002 00:39:51 -0700 (PDT) Received: from mail.allcaps.org (h-66-166-142-198.SNDACAGL.covad.net [66.166.142.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C6A243E7B for ; Fri, 18 Oct 2002 00:39:50 -0700 (PDT) (envelope-from bsder@mail.allcaps.org) Received: by mail.allcaps.org (Postfix, from userid 501) id 4D1051550C; Fri, 18 Oct 2002 00:39:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id 423FB1550B; Fri, 18 Oct 2002 00:39:49 -0700 (PDT) Date: Fri, 18 Oct 2002 00:39:49 -0700 (PDT) From: "Andrew P. Lentvorski" To: Charles Henrich Cc: freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues In-Reply-To: <20021017162243.B89519@sigbus.com> Message-ID: <20021018002729.T66900-100000@mail.allcaps.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 You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the packet will get rejected when it reaches the other IPSEC node. You can create forwarding rules which NAT packets destined for other hosts and leave the IPSEC packets alone. You'll have to create an ipfw ruleset. You also probably need to understand the difference between tunnel mode and transport mode in IPSEC. Transport mode is host-to-host. Tunnel mode is network-to-network. (I may have those two backwards) You are trying to do a hybrid; I don't think that is allowed in IPSEC. One of the hardest things for me to get used to in IPSEC was the fact that two machines could actually not talk to one another normally, but could create an IPSEC tunnel. Also, two machines that could actually talk to one another was not sufficient to guarantee that they could set up a tunnel. Good luck, -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 1:18: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 E25C337B401 for ; Fri, 18 Oct 2002 01:18:25 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95A1143EAF for ; Fri, 18 Oct 2002 01:18:24 -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 g9I8IEYj081941; Fri, 18 Oct 2002 11:18:17 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <0cf301c2767e$fb192080$8c2a40c1@PHE> From: "Petri Helenius" To: "Jim McGrath" , "Luigi Rizzo" Cc: "Lars Eggert" , References: Subject: Re: ENOBUFS Date: Fri, 18 Oct 2002 11:18:45 +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 Where could I get the errata sheet? Could the numbers be packet thresholds? 28 and 128 packets respectively? Anything else that can be done? Does PCI width/speed affect the amount of time spent in the kernel interrupt or are the PCI transfers asynchronous? Pete ----- Original Message ----- From: "Jim McGrath" To: "Luigi Rizzo" ; "Petri Helenius" Cc: "Lars Eggert" ; Sent: Friday, October 18, 2002 7:49 AM Subject: RE: ENOBUFS > Careful here. Read the errata sheet!! I do not believe the em driver uses > these parameters, and possibly for a good reason. > > Jim > > > -----Original Message----- > > From: owner-freebsd-net@FreeBSD.ORG > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > > Sent: Thursday, October 17, 2002 11:12 PM > > To: Petri Helenius > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG > > Subject: Re: ENOBUFS > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > ... > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > just reading the source code, yes, it appears that the card has > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > and usage in sys/dev/em/* . I don't know in what units are the values > > (28 and 128, respectively), but it does appear that tx interrupts are > > delayed a bit more than rx interrupts. > > > > They are not user-configurable at the moment though, you need to rebuild > > the kernel. > > > > cheers > > luigi > > > > > 50kpps the card generates 10k interrupts a second. Sending generates > > > way less. This is about 300Mbps so with the average packet size of > > > 750 there should be room for more packets on the interface queue > > > before needing to service an interrupt? > > > > > > What´s the way to access kernel adapter-structure? Is there an utility > > > that can view the values there? > > > > > > > Pete > > > > > > > > > > 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 Oct 18 1:30:42 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 6679737B401 for ; Fri, 18 Oct 2002 01:30:41 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BD3543EAF for ; Fri, 18 Oct 2002 01:30:40 -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 g9I8UbYj082020; Fri, 18 Oct 2002 11:30:39 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <0d0b01c27680$b553ba90$8c2a40c1@PHE> From: "Petri Helenius" To: "Luigi Rizzo" Cc: "Lars Eggert" , References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> <0be401c2761f$855af670$8c2a40c1@PHE> <20021017201158.A75351@carp.icir.org> Subject: Re: ENOBUFS Date: Fri, 18 Oct 2002 11:31:08 +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 > > just reading the source code, yes, it appears that the card has > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > and usage in sys/dev/em/* . I don't know in what units are the values > (28 and 128, respectively), but it does appear that tx interrupts are > delayed a bit more than rx interrupts. > The thing what is looking suspect is also the "small packet interrupt" feature which does not seem to get modified in the em driver but is on the defines. If that would be on by default, we´d probably see interrupts "too often" because it tries to optimize interrupts for good throughput on small number of TCP streams. Should these questions be posted to the authors of the driver? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 1:36: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 EF80937B401 for ; Fri, 18 Oct 2002 01:36:30 -0700 (PDT) Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C64043E42 for ; Fri, 18 Oct 2002 01:36:30 -0700 (PDT) (envelope-from vulture@consult-scs.com) Received: from consult-scs.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) (authenticated bits=0) by consult-scs.com (8.12.6/8.12.6) with ESMTP id g9I2dOIB064440 for ; Thu, 17 Oct 2002 19:39:25 -0700 (PDT) Message-ID: <3DAF7470.8040103@consult-scs.com> Date: Thu, 17 Oct 2002 19:39:44 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: RE: IPSEC/NAT issues 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 On a side note: For whoever tackles this project - a sysctl variable would be nice to turn the second ipsec processing(pre ipfw/ipf) on or off. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 1:36:33 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 6D8B737B404 for ; Fri, 18 Oct 2002 01:36:31 -0700 (PDT) Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0005F43EA9 for ; Fri, 18 Oct 2002 01:36:30 -0700 (PDT) (envelope-from vulture@consult-scs.com) Received: from consult-scs.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) (authenticated bits=0) by consult-scs.com (8.12.6/8.12.6) with ESMTP id g9I2axIB060983; Thu, 17 Oct 2002 19:37:03 -0700 (PDT) Message-ID: <3DAF73DE.1080307@consult-scs.com> Date: Thu, 17 Oct 2002 19:37:18 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Henrich Cc: freebsd-net@freebsd.org Subject: Re: IPsec/NAT FreeBSD References: <20021017161013.A89519@sigbus.com> 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 was just looking at the latest postings from the net list and was reading yours when I found this e-mail you sent directly to me. I've had some success with IPSEC/IPFW and NATD. The problem lies in the kernel, ipsec and ipfw ordering of where the packets flow. What you are trying to do - makes perfect sense. But the kerenl is screwing you up. I took and duplicated your problem using a 4.6.2-R Machine with a Lan behind it and a 4.4-R machine. So here lies the problem: The outgoing packets from the lan get nat-ed and then ipsec-ed. The incoming packets are ipsec-ed but don't pass to natd as a regular packet. because ipsec takes place after ipfw. I think a solution to the problem would be to have ipsec processing take place both before and after ipfw(or ipf). Somebody else though will have to figure out how to make a custom kernel to do double ipsec processing because I'm not a C programmer. Hope somebody can make it happen, for both of us. - Jonathan Charles Henrich wrote: >I've run across your postings in the FreeBSD mailing lists, and it looks like >your trying to do what I am trying to do. I was wondering if you had solved >it? That is, I have a nat'd network, and I want packets from any host on the >inside of the network to be ESP encapsilated after nat translation to one >particular host outside the network. It looks like it works, kinda. Packets >hit the gateway, are nat'd, are ESP encapsilated, and sent on their merry way. >Racoon even does a proper key exchange. On the return path however, the >packed is unencapsilated, but nat seems to refuse to reverse the natting? >Were you able to solve this problem? > >Thanks for any advice! > >-Crh > > Charles Henrich Eon Entertainment henrich@msu.edu > > http://www.sigbus.com/~henrich > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 3:48: 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 BDC1B37B401 for ; Fri, 18 Oct 2002 03:47:59 -0700 (PDT) Received: from femme.sapphite.org (pcp02268182pcs.longhl01.md.comcast.net [68.50.99.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3215A43E9E for ; Fri, 18 Oct 2002 03:47: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 g9IAm1hG002453; Fri, 18 Oct 2002 06:48:06 -0400 (EDT) (envelope-from trish@bsdunix.net) Date: Fri, 18 Oct 2002 06:48:01 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Jonathan Feally Cc: Charles Henrich , Subject: Re: IPsec/NAT FreeBSD In-Reply-To: <3DAF73DE.1080307@consult-scs.com> Message-ID: <20021018064542.X491-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 On Thu, 17 Oct 2002, Jonathan Feally wrote: > > I think a solution to the problem would be to have ipsec processing take > place both before and after ipfw(or ipf). > Somebody else though will have to figure out how to make a custom kernel > to do double ipsec processing because I'm not a C programmer. > > Hope somebody can make it happen, for both of us. > - Jonathan > > Charles Henrich wrote: > > >I've run across your postings in the FreeBSD mailing lists, and it looks like > >your trying to do what I am trying to do. I was wondering if you had solved > >it? That is, I have a nat'd network, and I want packets from any host on the > >inside of the network to be ESP encapsilated after nat translation to one > >particular host outside the network. It looks like it works, kinda. Packets > >hit the gateway, are nat'd, are ESP encapsilated, and sent on their merry way. > >Racoon even does a proper key exchange. On the return path however, the > >packed is unencapsilated, but nat seems to refuse to reverse the natting? > >Were you able to solve this problem? > > > >Thanks for any advice! > > I don't let IPSEC packets be processed by natd through the divert socket, in fact I use ipfw skipto rules: 00100 skipto 65535 ip from 66.80.117.2 to 64.14.48.150 00200 skipto 65535 ip from 64.14.48.150 to 66.80.117.2 00300 skipto 65535 ip from 10.80.116.0/23 to 10.0.0.0/24 00400 skipto 65535 ip from 10.0.0.0/24 to 10.80.116.0/23 00500 divert 8668 ip from any to any via fxp0 65535 allow ip from any to any It works well. -Trish -- Trish Lynch trish@bsdunix.net Ecartis Core Team trish@listmistress.org EFNet IRC Oper @ efnet.dkom.at AilleCat@EFNet UNIXNet IRC Admin @ femme.ipv6.sapphite.org AilleCat@UNIXNet 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 Fri Oct 18 5:53: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 43A3137B401 for ; Fri, 18 Oct 2002 05:53:15 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5011C43EB2 for ; Fri, 18 Oct 2002 05:53:14 -0700 (PDT) (envelope-from jimmcgra@bellatlantic.net) Received: from Default ([141.154.237.113]) by out001.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021018125313.ZIWQ3265.out001.verizon.net@Default>; Fri, 18 Oct 2002 07:53:13 -0500 From: "Jim McGrath" To: "Luigi Rizzo" Cc: "Petri Helenius" , "Lars Eggert" , Subject: RE: ENOBUFS Date: Fri, 18 Oct 2002 08:53:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021017215543.B76232@carp.icir.org> Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at out001.verizon.net from [141.154.237.113] at Fri, 18 Oct 2002 07:53:13 -0500 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 to tread carefully here because I was under NDA at my previous company. My work was with the wx driver, but hardware problems are hardware problems. There are a lot of performance enhancing features in the 82544. You will notice that the em driver does not use them. This may be for a reason :-( Our implementation ran with transmit interrupts disabled, so I can't comment on TIDV and am not allowed to comment on RIDV. The Receive Descriptor Threshold interrupt showed promise under high load (Rx interrupts disabled) but you would need to add a timeout function, 1 msec. or faster, to process receive descriptors under low load. Jim > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > Sent: Friday, October 18, 2002 12:56 AM > To: Jim McGrath > Cc: Petri Helenius; Lars Eggert; freebsd-net@FreeBSD.ORG > Subject: Re: ENOBUFS > > > On Fri, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote: > > Careful here. Read the errata sheet!! I do not believe the em > driver uses > > these parameters, and possibly for a good reason. > > as if i had access to the data sheets :) > > cheers > luigi > > Jim > > > > > -----Original Message----- > > > From: owner-freebsd-net@FreeBSD.ORG > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > > > Sent: Thursday, October 17, 2002 11:12 PM > > > To: Petri Helenius > > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG > > > Subject: Re: ENOBUFS > > > > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > > ... > > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > > > just reading the source code, yes, it appears that the card has > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > > and usage in sys/dev/em/* . I don't know in what units are the values > > > (28 and 128, respectively), but it does appear that tx interrupts are > > > delayed a bit more than rx interrupts. > > > > > > They are not user-configurable at the moment though, you need > to rebuild > > > the kernel. > > 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 Oct 18 6:16: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 E41F537B401; Fri, 18 Oct 2002 06:16:41 -0700 (PDT) Received: from cisco.com (sword.cisco.com [161.44.208.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F78D43E91; Fri, 18 Oct 2002 06:16:41 -0700 (PDT) (envelope-from sjt@cisco.com) Received: from sjt-u10.cisco.com (sjt-u10.cisco.com [10.85.30.63]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA23856; Fri, 18 Oct 2002 09:16:40 -0400 (EDT) Received: (sjt@localhost) by sjt-u10.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id JAA20857; Fri, 18 Oct 2002 09:16:39 -0400 (EDT) Date: Fri, 18 Oct 2002 09:16:39 -0400 From: Steve Tremblett To: Archie Cobbs Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Netgraph TCP/IP Message-ID: <20021018091639.W15035@sjt-u10.cisco.com> References: <20021017110456.G15035@sjt-u10.cisco.com> <200210180416.g9I4GrmL020888@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200210180416.g9I4GrmL020888@arch20m.dellroad.org>; from archie@dellroad.org on Thu, Oct 17, 2002 at 09:16:53PM -0700 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 +---- Archie Cobbs wrote: | Are you intending to have this hook into the normal FreeBSD TCP/IP | stack or be truly standalone? I read your question as the latter but | others seem to read it as the former. I am very much a babe in the woods at this point. I have no plan aside from reading as much as possible. My original idea was for it to be completely separate, so individual nodes could be replaced easily to try new algorithms. The subsequent discussion has been valuable nonetheless, and my plans certainly aren't written in stone. | If the latter, I'd suggest splitting it up into several netgraph | nodes, eg.: | | | | | | | | | ng_udp ng_tcp | \ / | \ / | ng_ip | | | | | ng_arp | | | | | | | ng_ether That was how I pictured it as well (well before your diagram got munged by my editor that is) - thanks :) -- Steve Tremblett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 6:21: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 B6C6137B401 for ; Fri, 18 Oct 2002 06:21:15 -0700 (PDT) Received: from pop017.verizon.net (pop017pub.verizon.net [206.46.170.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id F307843E42 for ; Fri, 18 Oct 2002 06:21:14 -0700 (PDT) (envelope-from jimmcgra@bellatlantic.net) Received: from Default ([141.154.237.113]) by pop017.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021018132114.MLNH1423.pop017.verizon.net@Default>; Fri, 18 Oct 2002 08:21:14 -0500 From: "Jim McGrath" To: "Petri Helenius" , "Luigi Rizzo" Cc: "Lars Eggert" , Subject: RE: ENOBUFS Date: Fri, 18 Oct 2002 09:21:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <0cf301c2767e$fb192080$8c2a40c1@PHE> Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop017.verizon.net from [141.154.237.113] at Fri, 18 Oct 2002 08:21:13 -0500 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 > Where could I get the errata sheet? Product Specification Updates i.e. errata, and the Product Specification itself are available from Intel under a Non Disclosure Agreement. Unless you work for a company that is doing business with Intel, they are probably not obtainable. > > Could the numbers be packet thresholds? 28 and 128 packets respectively? > I can't answer that directly because of NDA. Let us apply some logic here. If they were packet counts, under very low load conditions e.g. a single telnet session, the telnet link would be unusable. This leads us to the conclusion that they must be time values. Jim > Anything else that can be done? Does PCI width/speed affect the amount of > time spent in the kernel interrupt or are the PCI transfers asynchronous? > > Pete > > ----- Original Message ----- > From: "Jim McGrath" > To: "Luigi Rizzo" ; "Petri Helenius" > Cc: "Lars Eggert" ; > Sent: Friday, October 18, 2002 7:49 AM > Subject: RE: ENOBUFS > > > > Careful here. Read the errata sheet!! I do not believe the em > driver uses > > these parameters, and possibly for a good reason. > > > > Jim > > > > > -----Original Message----- > > > From: owner-freebsd-net@FreeBSD.ORG > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > > > Sent: Thursday, October 17, 2002 11:12 PM > > > To: Petri Helenius > > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG > > > Subject: Re: ENOBUFS > > > > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > > ... > > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > > > just reading the source code, yes, it appears that the card has > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > > and usage in sys/dev/em/* . I don't know in what units are the values > > > (28 and 128, respectively), but it does appear that tx interrupts are > > > delayed a bit more than rx interrupts. > > > > > > They are not user-configurable at the moment though, you need > to rebuild > > > the kernel. > > > > > > cheers > > > luigi > > > > > > > 50kpps the card generates 10k interrupts a second. Sending generates > > > > way less. This is about 300Mbps so with the average packet size of > > > > 750 there should be room for more packets on the interface queue > > > > before needing to service an interrupt? > > > > > > > > What´s the way to access kernel adapter-structure? Is there > an utility > > > > that can view the values there? > > > > > > > > > Pete > > > > > > > > > > > > > > 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 Oct 18 6:27: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 D2C4037B401 for ; Fri, 18 Oct 2002 06:27:53 -0700 (PDT) Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B15E43E7B for ; Fri, 18 Oct 2002 06:27:51 -0700 (PDT) (envelope-from bsd#nms@otdel-1.org) Received: by otdel-1.org (CommuniGate Pro PIPE 4.0b9) with PIPE id 2220061; Fri, 18 Oct 2002 17:27:47 +0400 Date: Fri, 18 Oct 2002 17:27:32 +0400 From: Nikolai Saoukh To: freebsd-net@FreeBSD.ORG Subject: For those who had problems with MPD server and win clients Message-ID: <20021018132732.GA27692@otdel1.org> Mail-Followup-To: freebsd-net@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-Mailer: CommuniGate Pro CLI mailer 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 IMHO, there is a combination of two bugs. 1) MPD (3.9, at least) calculates and sets mtu (bund.c/BundUpdateParams()) at wrong time -- when one of MIN() args is still zero. ioctl with bizzare mtu value rejected, thus leaving the default (1500), which in turn is above MRU requested from win client (1400 for multilink). [at the same time on other end of connection] 2) MS clients has setting 'Negotiate multi-link for single link connections'. Even when this option is negotiated, ms client does not understand partial MP (RFC1990) fragments. When both (begin, end) flags set, then everything is fine, as long as everything fits MRU. Would anyone review and test this patches? (bund.c patches a kind of nitpicking -- enabled is not negotiated :-)) --- bund.c.orig Tue Oct 8 13:40:15 2002 +++ bund.c Fri Oct 18 17:17:23 2002 @@ -548,22 +548,20 @@ mtu = NG_IFACE_MTU_DEFAULT; /* Reset to default settings */ break; case 1: - if (!Enabled(&bund->conf.options, BUND_CONF_MULTILINK)) { - mtu = MIN(bund->links[the_link]->lcp.peer_mru, - bund->links[the_link]->phys->type->mtu); - break; - } - /* FALLTHROUGH */ + mtu = bund->links[the_link]->lcp.peer_mru; + break; default: /* We fragment everything, use bundle MRRU */ mtu = bund->mp.peer_mrru; break; } - /* Subtract to make room for various frame-bloating protocols */ - if (Enabled(&bund->conf.options, BUND_CONF_COMPRESSION)) - mtu = CcpSubtractBloat(mtu); - if (Enabled(&bund->conf.options, BUND_CONF_ENCRYPTION)) - mtu = EcpSubtractBloat(mtu); + if (bm->n_up > 0) { + /* Subtract to make room for various frame-bloating protocols */ + if (bund->ccp.xmit != NULL) + mtu = CcpSubtractBloat(mtu); + if (bund->ecp.xmit != NULL) + mtu = EcpSubtractBloat(mtu); + } /* Update interface MTU */ if (mtu > BUND_MAX_MTU) --- iface.c.orig Tue Oct 8 14:28:09 2002 +++ iface.c Sat Oct 12 11:54:36 2002 @@ -346,6 +346,8 @@ /* Sanity */ assert(!iface->ip_up); + BundUpdateParams(); + /* Set addresses and bring interface up */ snprintf(hisaddr, sizeof(hisaddr), "%s", inet_ntoa(iface->peer_addr)); ExecCmd(LG_IFACE, "%s %s %s %s netmask 0xffffffff %slink0", To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 6:41: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 B419C37B406 for ; Fri, 18 Oct 2002 06:41:25 -0700 (PDT) Received: from hottub.hottub.org (hottub.org [66.60.164.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5023F43E8A for ; Fri, 18 Oct 2002 06:41:25 -0700 (PDT) (envelope-from matt@hottub.org) Received: by hottub.hottub.org (Postfix, from userid 1100) id BE1EC213BF; Fri, 18 Oct 2002 06:39:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hottub.hottub.org (Postfix) with ESMTP id B7A97213BB for ; Fri, 18 Oct 2002 06:39:51 -0700 (PDT) Date: Fri, 18 Oct 2002 06:39:51 -0700 (PDT) From: Matthew Zahorik X-X-Sender: matt@hottub To: freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues In-Reply-To: <20021018002729.T66900-100000@mail.allcaps.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 On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote: > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the > packet will get rejected when it reaches the other IPSEC node. Not exactly true. I use a Windows Nortel Contivity client behind NAT just fine. If you're using an AH association (header authentication) that will not pass through NAT. I'm sure someone on this list may come up with a fancy trick for FreeBSD, but generally the statement is true. AH detects the NAT changes as header corruption. But if you're only using ESP (encryption of payload) that will work fine. Most turn on both AH and ESP by default, but that isn't always the case as in the Nortel boxes. On another note, I'd *love* to use my FreeBSD NAT box as a VPN tunnel endpoint rather than my windows boxes. It's a dynamic IP, so it's catch-22 right now. I can't create a tunnel or SPD policy entry before I know the IP addresses, and IKE/racoon can't start without those things. So, if someone happens to be ripping the IPsec processing apart, something to eliminate this catch-22 would be nice (: (spd entries pointing to an unconfigured or dummy tunnel, for example) Thanks! - Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 7:12: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 7678437B401; Fri, 18 Oct 2002 07:12:22 -0700 (PDT) Received: from dominion.1my.net (dominion.1my.net [202.56.152.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44B9943E97; Fri, 18 Oct 2002 07:12:21 -0700 (PDT) (envelope-from mikechoo@opensos.net) Received: from lifebook ([219.93.84.169]) (authenticated bits=0) by dominion.1my.net (8.12.5/8.12.5) with ESMTP id g9IECCGK070737; Fri, 18 Oct 2002 22:12:17 +0800 (MYT) (envelope-from mikechoo@opensos.net) Date: Fri, 18 Oct 2002 22:11:55 +0800 From: Michael Choo X-Mailer: The Bat! (v1.60) Personal Reply-To: Michael Choo Organization: OpenSOS Sdn Bhd X-Priority: 3 (Normal) Message-ID: <4510281043.20021018221155@opensos.net> To: owner-freebsd-net@FreeBSD.ORG, Matthew Zahorik Cc: freebsd-net@FreeBSD.ORG Subject: Re[2]: IPSEC/NAT issues In-Reply-To: References: 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 Hello Matthew, Friday, October 18, 2002, 9:39:51 PM, you wrote: MZ> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote: >> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the >> packet will get rejected when it reaches the other IPSEC node. MZ> Not exactly true. I use a Windows Nortel Contivity client behind NAT just MZ> fine. Yup, I use a Windows Nortel Contivity client behind a FreeBSD userland PPP NAT just fine too. -- Best regards, Michael mailto:mikechoo@opensos.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 7:29: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 BA16437B401 for ; Fri, 18 Oct 2002 07:29:23 -0700 (PDT) Received: from zelax.ru (rosa.zelax.ru [212.188.91.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52DE543E9E for ; Fri, 18 Oct 2002 07:29:22 -0700 (PDT) (envelope-from wr@zelax.ru) Received: (from root@localhost) by zelax.ru (8.9.3/8.9.3) id SAA37542 for freebsd-net@FreeBSD.ORG.KAV; Fri, 18 Oct 2002 18:29:19 +0400 (MSD) (envelope-from wr@zelax.ru) Received: from zelax.ru (slava.local [192.168.11.152]) by zelax.ru (8.9.3/8.9.3) with ESMTP id SAA37534 for ; Fri, 18 Oct 2002 18:29:19 +0400 (MSD) (envelope-from wr@zelax.ru) Message-ID: <3DB07D78.4080306@zelax.ru> Date: Fri, 18 Oct 2002 17:30:32 -0400 From: "Vyacheslav V. Burdjanadze" Organization: ZELAX User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: ru, en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: pppd rechallenge bug? 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. Sorry for off-topic, but maybe authors of pppd reads this mail-list.. When porting latest pppd (2.4.1) to RTEMS OS I noticed that auth_withpeer_success() does not check current operation phase thus if we enable CHAP rechallenge , each rechallenge will bring us to network phase (by calling auth_withpeer_success()). Is this intent? -- - " Why do you call this software 'beta' ? " - " Cuz it beta than nothin' ! " To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 7:36:36 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 197B537B401 for ; Fri, 18 Oct 2002 07:36:34 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 864C643E7B for ; Fri, 18 Oct 2002 07:36:33 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (c-24-130-112-157.we.client2.attbi.com [24.130.112.157]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9IEaVC15122; Fri, 18 Oct 2002 07:36:31 -0700 (PDT) Message-ID: <3DB01C6E.7030308@isi.edu> Date: Fri, 18 Oct 2002 07:36:30 -0700 From: Lars Eggert Organization: USC Information Sciences Institute 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: Matthew Zahorik Cc: freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010407010507060506030101" 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. --------------ms010407010507060506030101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Matthew Zahorik wrote: > On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote: > >>You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the >>packet will get rejected when it reaches the other IPSEC node. > > Not exactly true. I use a Windows Nortel Contivity client behind NAT just > fine. Reading his first post, the original poster wants to IPsec NAT'ed packets, not vice versa. Lars -- Lars Eggert USC Information Sciences Institute --------------ms010407010507060506030101 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 hvcNAQkFMQ8XDTAyMTAxODE0MzYzMVowIwYJKoZIhvcNAQkEMRYEFAe5eS5bDgNlhvt9NIE4 dqMh8dLbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ KoZIhvcNAQEBBQAEggEAqZim2udsakGyFMe/KstPLzuwgQSDOUS7kywODWf2V7cRnqwNIsGL JbLgyGSO/XPDfWxXoe1CV7R6gFeVB24WdLNevcBwOKNyhbZi8NsREnuxNgMf3UcWPfzn0MpH gEfBBj8u3JUAN2DGzEJplqMm5oKb7D6NLuKSMYI/qaG6ZkVpiVkkHxfHpJhwkIHPdGN5Jfpn C6z200VAtCllAc9D2p1/3TUx2tnjWPESy7Mz6m3t0fOuqtdausepoZ7IrLO1225FonyjoiJJ QvMQxUa7651Xrk63SHshGQdm+swZvZziF5sLmr6eFBtSHRmh4nvywZfu9Vejni8XV/beB5VJ igAAAAAAAA== --------------ms010407010507060506030101-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 8:21: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 8143437B401 for ; Fri, 18 Oct 2002 08:21:43 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3127843E65 for ; Fri, 18 Oct 2002 08:21:42 -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 g9IFL8Yj085103; Fri, 18 Oct 2002 18:21:25 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <00b001c276ba$1533dbf0$3500080a@PHE> From: "Petri Helenius" To: "Jim McGrath" , "Luigi Rizzo" Cc: "Lars Eggert" , , References: Subject: Re: ENOBUFS Date: Fri, 18 Oct 2002 18:21:37 +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 (I´ll throw in the address found in the README of the driver, maybe somebody there has access to appropriate documentation / is willing to work on documenting tunables and optimizing the performance) > I have to tread carefully here because I was under NDA at my previous > company. My work was with the wx driver, but hardware problems are hardware > problems. There are a lot of performance enhancing features in the 82544. The chips I have are 82546. Is your recommendation to steer away from Intel Gigabit Ethernet chips? What would be more optimal alternative? > You will notice that the em driver does not use them. This may be for a > reason :-( Our implementation ran with transmit interrupts disabled, so I > can't comment on TIDV and am not allowed to comment on RIDV. > Maybe I´ll play with the value and see what happens. Any comments on the question how to access the adapter structure from userland? > The Receive Descriptor Threshold interrupt showed promise under high load > (Rx interrupts disabled) but you would need to add a timeout function, 1 > msec. or faster, to process receive descriptors under low load. > Luigi´s polling work would be useful here. That would lead to incorrect timestamps on the packets, though? Pete > > > -----Original Message----- > > From: owner-freebsd-net@FreeBSD.ORG > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > > Sent: Friday, October 18, 2002 12:56 AM > > To: Jim McGrath > > Cc: Petri Helenius; Lars Eggert; freebsd-net@FreeBSD.ORG > > Subject: Re: ENOBUFS > > > > > > On Fri, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote: > > > Careful here. Read the errata sheet!! I do not believe the em > > driver uses > > > these parameters, and possibly for a good reason. > > > > as if i had access to the data sheets :) > > > > cheers > > luigi > > > Jim > > > > > > > -----Original Message----- > > > > From: owner-freebsd-net@FreeBSD.ORG > > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > > > > Sent: Thursday, October 17, 2002 11:12 PM > > > > To: Petri Helenius > > > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG > > > > Subject: Re: ENOBUFS > > > > > > > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > > > ... > > > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At > > > > > > > > just reading the source code, yes, it appears that the card has > > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > > > and usage in sys/dev/em/* . I don't know in what units are the values > > > > (28 and 128, respectively), but it does appear that tx interrupts are > > > > delayed a bit more than rx interrupts. > > > > > > > > They are not user-configurable at the moment though, you need > > to rebuild > > > > the kernel. > > > > 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 Oct 18 9:19: 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 D7CC537B401 for ; Fri, 18 Oct 2002 09:19:00 -0700 (PDT) Received: from pop017.verizon.net (pop017pub.verizon.net [206.46.170.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1617F43EEC for ; Fri, 18 Oct 2002 09:19:00 -0700 (PDT) (envelope-from jimmcgra@bellatlantic.net) Received: from Default ([141.154.237.113]) by pop017.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021018161859.NYOR1423.pop017.verizon.net@Default>; Fri, 18 Oct 2002 11:18:59 -0500 From: "Jim McGrath" To: "Petri Helenius" , "Luigi Rizzo" Cc: "Lars Eggert" , , Subject: RE: ENOBUFS Date: Fri, 18 Oct 2002 12:19:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <00b001c276ba$1533dbf0$3500080a@PHE> Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop017.verizon.net from [141.154.237.113] at Fri, 18 Oct 2002 11:18:58 -0500 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 chips I have are 82546. Is your recommendation to steer away > from Intel > Gigabit Ethernet chips? What would be more optimal alternative? > The 82543/82544 chips worked well in vanilla configurations. I never played with an 82546. The em driver is supported by Intel, so any chip features it uses should be safe. When testing with a SmartBits, 64 byte packets and high line utilization, I ran into problems when RIDV was enabled. This may be fixed with the 82546, but I have no way of verifying this. > Maybe I´ll play with the value and see what happens. Any comments on > the question how to access the adapter structure from userland? > We added sysctls to the wx driver to allow tuning/testing of various parameters. The same could be done to the em driver. You will likely need to do more than just modify fields in the adapter structure. The control register you are targeting will need to be rewritten by the sysctl. Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 9:53: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 25ED137B401 for ; Fri, 18 Oct 2002 09:53:30 -0700 (PDT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD06143E88 for ; Fri, 18 Oct 2002 09:53:28 -0700 (PDT) (envelope-from dart@nersc.gov) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id 1EA61593E; Fri, 18 Oct 2002 09:53:28 -0700 (PDT) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id 9F4D6593C; Fri, 18 Oct 2002 09:53:27 -0700 (PDT) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id 559193B1AE; Fri, 18 Oct 2002 09:53:27 -0700 (PDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Jim McGrath" Cc: "Petri Helenius" , "Luigi Rizzo" , "Lars Eggert" , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS In-Reply-To: Message from "Jim McGrath" of "Fri, 18 Oct 2002 09:21:37 EDT." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_128925830P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 18 Oct 2002 09:53:27 -0700 From: Eli Dart Message-Id: <20021018165327.559193B1AE@gemini.nersc.gov> 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 --==_Exmh_128925830P Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In reply to "Jim McGrath" : > = > > Where could I get the errata sheet? > = > Product Specification Updates i.e. errata, and the Product Specificatio= n > itself are available from Intel under a Non Disclosure Agreement. Unle= ss > you work for a company that is doing business with Intel, they are prob= ably > not obtainable. > > > > Could the numbers be packet thresholds? 28 and 128 packets respective= ly? > > > I can't answer that directly because of NDA. Let us apply some logic h= ere. > If they were packet counts, under very low load conditions e.g. a singl= e > telnet session, the telnet link would be unusable. This leads us to th= e > conclusion that they must be time values. Based on the source code for the sk driver (look for "interrupt = moderation" in if_sk.c) I would suspect that those values represent = time in microseconds. My guess (based on no privileged information = whatsoever) is that if we've not interrupted in = microseconds and we have something to send (or we've received = something) go ahead and raise an interrupt..... Just a guess. I'm perfectly willing to be wrong about this.... --eli > = > Jim > > Anything else that can be done? Does PCI width/speed affect the amoun= t of > > time spent in the kernel interrupt or are the PCI transfers asynchron= ous? > > > > Pete > > > > ----- Original Message ----- > > From: "Jim McGrath" > > To: "Luigi Rizzo" ; "Petri Helenius" = > > Cc: "Lars Eggert" ; > > Sent: Friday, October 18, 2002 7:49 AM > > Subject: RE: ENOBUFS > > > > > > > Careful here. Read the errata sheet!! I do not believe the em > > driver uses > > > these parameters, and possibly for a good reason. > > > > > > Jim > > > > > > > -----Original Message----- > > > > From: owner-freebsd-net@FreeBSD.ORG > > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo > > > > Sent: Thursday, October 17, 2002 11:12 PM > > > > To: Petri Helenius > > > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG > > > > Subject: Re: ENOBUFS > > > > > > > > > > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote: > > > > ... > > > > > I seem to get about 5-6 packets on an interrupt. Is this tunabl= e? At > > > > > > > > just reading the source code, yes, it appears that the card has > > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definit= ions > > > > and usage in sys/dev/em/* . I don't know in what units are the va= lues > > > > (28 and 128, respectively), but it does appear that tx interrupts= are > > > > delayed a bit more than rx interrupts. > > > > > > > > They are not user-configurable at the moment though, you need > > to rebuild > > > > the kernel. > > > > > > > > cheers > > > > luigi > > > > > > > > > 50kpps the card generates 10k interrupts a second. Sending gene= rates > > > > > way less. This is about 300Mbps so with the average packet size= of > > > > > 750 there should be room for more packets on the interface queu= e > > > > > before needing to service an interrupt? > > > > > > > > > > What=B4s the way to access kernel adapter-structure? Is there > > an utility > > > > > that can view the values there? > > > > > > > > > > > Pete > > > > > > > > > > > > > > > > > > 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 --==_Exmh_128925830P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: This is a comment. iD8DBQE9sDyHLTFEeF+CsrMRAj3SAKDnmZM7GH1u8JAajyz6boZB7oeLEQCgiQJJ 5jP8QSLOwQE2OcI/xd9xbuo= =PgrR -----END PGP SIGNATURE----- --==_Exmh_128925830P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 10: 5: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 5BFA337B401; Fri, 18 Oct 2002 10:05:50 -0700 (PDT) Received: from search.sparks.net (d-207-5-180-136.gwi.net [207.5.180.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE45843E9C; Fri, 18 Oct 2002 10:05:49 -0700 (PDT) (envelope-from dmiller@search.sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id D7197D999; Fri, 18 Oct 2002 12:59:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with ESMTP id D1CADD98C; Fri, 18 Oct 2002 12:59:27 -0400 (EDT) Date: Fri, 18 Oct 2002 12:59:27 -0400 (EDT) From: David Miller To: Attila Nagy Cc: "Kenneth D. Merry" , Christopher Smith , hardware@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: High interrupt load on firewalls In-Reply-To: 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 Wed, 9 Oct 2002, Attila Nagy wrote: With a dc ethernet card and ~45K packets per second, an XP1700 system went from > 50% interrupt to < 1%. I was astounded at the change! If all it takes to get Gb interfaces polling is to send Luigi a card then he needs to send me his shipping address:) --- David > Hello, > > > You might want to try out some of the Intel gigabit boards. At least > > we've got an engineer from Intel who maintains the driver. > I'm far from being a FreeBSD expert, but Luigi Rizzo's polling patch > helped me a lot in similar cases to get better performance. > > >From POLLING(4): > DESCRIPTION > "Device polling" (polling for brevity) refers to a technique to handle > devices that does not rely on the latter to generate interrupts when they > need attention, but rather lets the CPU poll devices to service their > needs. This might seem inefficient and counterintuitive, but when done > properly, polling gives more control to the operating system on when and > how to handle devices, with a number of advantages in terms of system > responsivity and performance. > > AFAIK there are only two problems about that: > SUPPORTED DEVICES > Polling requires explicit modifications to the device drivers. As of > this writing, the dc, fxp, rl and sis devices are supported, with other > in the works. > > (no Gigabit cards) > > and > sys/kern/kern_poll.c: > [...] > #ifdef SMP > #include "opt_lint.h" > #ifndef COMPILING_LINT > #error DEVICE_POLLING is not compatible with SMP > #endif > #endif > [...] > > (no SMP support) > > As stated above, I'm not an expert, but my opinion is that polling would > be the best on the Gigabit cards (due to their capacity) and not the Fast > Ethernet ones. > > Maybe we could start sending GE hardware to Luigi :) > > ----------[ Free Software ISOs - http://www.fsn.hu/?f=download ]---------- > Attila Nagy e-mail: Attila.Nagy@fsn.hu > Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) > cell.: +3630 306 6758 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hardware" 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 Oct 18 10:11: 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 788EE37B401 for ; Fri, 18 Oct 2002 10:10:59 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4B6043EAF for ; Fri, 18 Oct 2002 10:10:58 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021018171057.DCL18217.rwcrmhc51.attbi.com@blossom.cjclark.org> for ; Fri, 18 Oct 2002 17:10:57 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g9IHAvWn045491 for ; Fri, 18 Oct 2002 10:10:57 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g9IHAuB5045490 for net@freebsd.org; Fri, 18 Oct 2002 10:10:56 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 18 Oct 2002 10:10:55 -0700 From: "Crist J. Clark" To: net@freebsd.org Subject: Strange FTP TCP Window Problem Message-ID: <20021018171055.GA45449@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 This has got me stumped. I must be missing something obvious. I am trying to download some files via FTP. There are four files. Three download just fine, one just won't go. Since the three work fine, I assume it's not PORT vs. PASV, NAT, or other firewall issues, that is, the usual suspects have been eliminated. But what is really strange is that it looks like _my client_ is the one causing the headaches. Here is a tcpdump(8) of the data connection. Keep an eye on the window values my client is sending back, 09:15:11.097800 a.b.c.136.29826 > d.e.f.17.18747: S [tcp sum ok] 2410623756:2410623756(0) win 16384 (ttl 64, id 50031, len 64) 09:15:11.118335 d.e.f.17.18747 > a.b.c.136.29826: S [tcp sum ok] 2932757104:2932757104(0) ack 2410623757 win 16384 (ttl 56, id 24108, len 60) 09:15:11.118443 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1 win 16500 (ttl 64, id 43640, len 52) 09:15:11.156424 d.e.f.17.18747 > a.b.c.136.29826: . 1:501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24111, len 552) 09:15:11.159468 d.e.f.17.18747 > a.b.c.136.29826: . 501:1001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24112, len 552) 09:15:11.227371 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1001 win 15500 [tos 0x8] (ttl 64, id 61006, len 52) 09:15:11.258205 d.e.f.17.18747 > a.b.c.136.29826: . 1001:1501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24113, len 552) 09:15:11.261225 d.e.f.17.18747 > a.b.c.136.29826: . 1501:2001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24114, len 552) 09:15:11.279923 d.e.f.17.18747 > a.b.c.136.29826: . 2001:2501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24115, len 552) 09:15:11.427395 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 2501 win 14000 [tos 0x8] (ttl 64, id 40196, len 52) 09:15:11.457865 d.e.f.17.18747 > a.b.c.136.29826: . 2501:3001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24116, len 552) 09:15:11.461105 d.e.f.17.18747 > a.b.c.136.29826: . 3001:3501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24117, len 552) 09:15:11.480485 d.e.f.17.18747 > a.b.c.136.29826: . 3501:4001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24118, len 552) 09:15:11.483702 d.e.f.17.18747 > a.b.c.136.29826: . 4001:4501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24119, len 552) 09:15:11.627707 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 4501 win 12000 [tos 0x8] (ttl 64, id 44302, len 52) 09:15:11.648692 d.e.f.17.18747 > a.b.c.136.29826: . 4501:5001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24120, len 552) 09:15:11.659731 d.e.f.17.18747 > a.b.c.136.29826: . 5001:5501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24121, len 552) 09:15:11.670448 d.e.f.17.18747 > a.b.c.136.29826: . 5501:6001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24122, len 552) 09:15:11.673581 d.e.f.17.18747 > a.b.c.136.29826: . 6001:6501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24123, len 552) 09:15:11.692780 d.e.f.17.18747 > a.b.c.136.29826: . 6501:7001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24124, len 552) 09:15:11.827393 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 7001 win 9500 [tos 0x8] (ttl 64, id 38068, len 52) 09:15:11.855900 d.e.f.17.18747 > a.b.c.136.29826: . 7001:7501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24125, len 552) 09:15:11.860077 d.e.f.17.18747 > a.b.c.136.29826: . 7501:8001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24126, len 552) 09:15:11.878834 d.e.f.17.18747 > a.b.c.136.29826: . 8001:8501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24127, len 552) 09:15:11.881856 d.e.f.17.18747 > a.b.c.136.29826: . 8501:9001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24128, len 552) 09:15:11.892382 d.e.f.17.18747 > a.b.c.136.29826: . 9001:9501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24129, len 552) 09:15:11.903415 d.e.f.17.18747 > a.b.c.136.29826: . 9501:10001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24130, len 552) 09:15:12.027385 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 10001 win 6500 [tos 0x8] (ttl 64, id 60342, len 52) 09:15:12.052757 d.e.f.17.18747 > a.b.c.136.29826: . 10001:10501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24131, len 552) 09:15:12.063589 d.e.f.17.18747 > a.b.c.136.29826: . 10501:11001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24132, len 552) 09:15:12.074515 d.e.f.17.18747 > a.b.c.136.29826: . 11001:11501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24133, len 552) 09:15:12.078151 d.e.f.17.18747 > a.b.c.136.29826: . 11501:12001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24134, len 552) 09:15:12.096930 d.e.f.17.18747 > a.b.c.136.29826: . 12001:12501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24135, len 552) 09:15:12.099980 d.e.f.17.18747 > a.b.c.136.29826: . 12501:13001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24136, len 552) 09:15:12.110647 d.e.f.17.18747 > a.b.c.136.29826: . 13001:13501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24137, len 552) 09:15:12.227383 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 13501 win 3000 [tos 0x8] (ttl 64, id 51576, len 52) 09:15:12.264837 d.e.f.17.18747 > a.b.c.136.29826: . 13501:14001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24138, len 552) 09:15:12.268095 d.e.f.17.18747 > a.b.c.136.29826: . 14001:14501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24139, len 552) 09:15:12.278653 d.e.f.17.18747 > a.b.c.136.29826: . 14501:15001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24140, len 552) 09:15:12.289849 d.e.f.17.18747 > a.b.c.136.29826: . 15001:15501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24141, len 552) 09:15:12.293592 d.e.f.17.18747 > a.b.c.136.29826: . 15501:16001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24142, len 552) 09:15:12.427402 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16001 win 500 [tos 0x8] (ttl 64, id 41001, len 52) 09:15:17.202100 d.e.f.17.18747 > a.b.c.136.29826: . 16001:16501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24157, len 552) 09:15:17.227476 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 59052, len 52) 09:15:22.186435 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 24183, len 53) 09:15:22.186625 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 55942, len 52) 09:15:30.194393 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 24221, len 53) 09:15:30.195913 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 14020, len 52) 09:15:46.198335 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 24333, len 53) 09:15:46.198583 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 16087, len 52) 09:16:18.201164 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 24500, len 53) 09:16:18.201409 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 30338, len 52) 09:17:18.194176 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 25061, len 53) 09:17:18.194430 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 20615, len 52) 09:18:18.193763 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 25447, len 53) 09:18:18.194005 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 12107, len 52) 09:19:18.186418 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 25862, len 53) 09:19:18.187970 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 51084, len 52) And this just hangs here forever. I can't see why the client is refusing to accept more data. Like I said, I'll bet I'm not seeing something obvious, but all of the SEQ and ACK numbers look good to me. I should note that this isn't just an issue with the FreeBSD ftp client. I get the same result with Windows, Solaris, Cygwin, and OpenBSD too. Why is it happening and how do I get around this? -- 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 Fri Oct 18 10:18: 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 4806737B401; Fri, 18 Oct 2002 10:18:03 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFEC943EAC; Fri, 18 Oct 2002 10:18:02 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IHI2pJ082828; Fri, 18 Oct 2002 10:18:02 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9IHI2tO082827; Fri, 18 Oct 2002 10:18:02 -0700 (PDT) (envelope-from rizzo) Date: Fri, 18 Oct 2002 10:18:02 -0700 From: Luigi Rizzo To: David Miller Cc: Attila Nagy , "Kenneth D. Merry" , Christopher Smith , hardware@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: High interrupt load on firewalls Message-ID: <20021018101802.A82792@carp.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from dmiller@search.sparks.net on Fri, Oct 18, 2002 at 12:59:27PM -0400 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, Oct 18, 2002 at 12:59:27PM -0400, David Miller wrote: > On Wed, 9 Oct 2002, Attila Nagy wrote: > > With a dc ethernet card and ~45K packets per second, an XP1700 system went > from > 50% interrupt to < 1%. I was astounded at the change! that is partly cheating, because with polling, some of the work which was done in an interrupt context is done elsewere. Still you might have some significant load reduction, i admit :) > If all it takes to get Gb interfaces polling is to send Luigi a card then > he needs to send me his shipping address:) all it takes is to look at the source code in some of the supported cards -- the changes are clearly marked by #ifdef DEVICE_POLLING/#endif blocks and are rather trivial in most cases (not all of them, 'fxp' was particularly tricky to get right!). cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 10:22: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 916) id C553937B401; Fri, 18 Oct 2002 10:22:03 -0700 (PDT) Date: Fri, 18 Oct 2002 10:22:03 -0700 From: Prafulla Deuskar To: Petri Helenius Cc: Luigi Rizzo , Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021018102203.A86452@hub.freebsd.org> References: <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> <0be401c2761f$855af670$8c2a40c1@PHE> <20021017201158.A75351@carp.icir.org> <0d0b01c27680$b553ba90$8c2a40c1@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0d0b01c27680$b553ba90$8c2a40c1@PHE>; from pete@he.iki.fi on Fri, Oct 18, 2002 at 11:31:08AM +0300 X-Operating-System: FreeBSD 4.7-RC on an i386 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 Transmit/Receive Interrupt Delay values are in units of 1.024 microseconds. The em driver currently uses these to enable interrupt coalescing on the cards. Thanks, Prafulla To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 10:27:29 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 EDB5337B401 for ; Fri, 18 Oct 2002 10:27:27 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 422C543E9C for ; Fri, 18 Oct 2002 10:27:27 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IHR5LE362954; Fri, 18 Oct 2002 13:27:05 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IHR4OQ001632; Fri, 18 Oct 2002 10:27:04 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 18 Oct 2002 10:27:04 -0700 (PDT) From: Kelly Yancey To: Petri Helenius Cc: Luigi Rizzo , Lars Eggert , Subject: Re: ENOBUFS In-Reply-To: <0d0b01c27680$b553ba90$8c2a40c1@PHE> Message-ID: <20021018102515.V1611-100000@gateway.posi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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, 18 Oct 2002, Petri Helenius wrote: > > > > just reading the source code, yes, it appears that the card has > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions > > and usage in sys/dev/em/* . I don't know in what units are the values > > (28 and 128, respectively), but it does appear that tx interrupts are > > delayed a bit more than rx interrupts. > > > The thing what is looking suspect is also the "small packet interrupt" fe= ature > which does not seem to get modified in the em driver but is on the define= s. > > If that would be on by default, we=B4d probably see interrupts "too often= " > because it tries to optimize interrupts for good throughput on small numb= er > of TCP streams. > Hmm. Might that explain the abysmal performance of the em driver with packets smaller than 333 bytes? Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} FreeBSD, The Power To Serve: http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 10:33: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 711DB37B404 for ; Fri, 18 Oct 2002 10:33:20 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5CF343E88 for ; Fri, 18 Oct 2002 10:33:19 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IHXJpJ082999; Fri, 18 Oct 2002 10:33:19 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9IHXJ46082998; Fri, 18 Oct 2002 10:33:19 -0700 (PDT) (envelope-from rizzo) Date: Fri, 18 Oct 2002 10:33:19 -0700 From: Luigi Rizzo To: Kelly Yancey Cc: Petri Helenius , Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021018103319.A82982@carp.icir.org> References: <0d0b01c27680$b553ba90$8c2a40c1@PHE> <20021018102515.V1611-100000@gateway.posi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021018102515.V1611-100000@gateway.posi.net>; from kbyanc@posi.net on Fri, Oct 18, 2002 at 10:27:04AM -0700 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, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote: ... > Hmm. Might that explain the abysmal performance of the em driver with > packets smaller than 333 bytes? what do you mean ? it works great for me. even on -current i can push out over 400kpps (64byte frames) on a 2.4GHz box. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 10:36:41 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 7F5A837B401; Fri, 18 Oct 2002 10:36:40 -0700 (PDT) Received: from search.sparks.net (d-207-5-180-136.gwi.net [207.5.180.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2662D43E9E; Fri, 18 Oct 2002 10:36:40 -0700 (PDT) (envelope-from dmiller@search.sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id 4CE53D999; Fri, 18 Oct 2002 13:30:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with ESMTP id 3D224D98C; Fri, 18 Oct 2002 13:30:18 -0400 (EDT) Date: Fri, 18 Oct 2002 13:30:18 -0400 (EDT) From: David Miller To: Luigi Rizzo Cc: Attila Nagy , "Kenneth D. Merry" , Christopher Smith , hardware@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: High interrupt load on firewalls In-Reply-To: <20021018101802.A82792@carp.icir.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 On Fri, 18 Oct 2002, Luigi Rizzo wrote: > On Fri, Oct 18, 2002 at 12:59:27PM -0400, David Miller wrote: > > On Wed, 9 Oct 2002, Attila Nagy wrote: > > > > With a dc ethernet card and ~45K packets per second, an XP1700 system went > > from > 50% interrupt to < 1%. I was astounded at the change! > > that is partly cheating, because with polling, some of the work which > was done in an interrupt context is done elsewere. Still you might > have some significant load reduction, i admit :) Very significant. The system went from maxed out at 30K pps to 35% idle at > 40K pps. I suspect it's an extreme case with the dc card. I've observed less with the fxp. Thanks for all the work Luigi:) --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 10:38:28 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 2B5CA37B412 for ; Fri, 18 Oct 2002 10:38:27 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6BAD43E9E for ; Fri, 18 Oct 2002 10:38:26 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IHcPpJ083056; Fri, 18 Oct 2002 10:38:25 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9IHcP8T083055; Fri, 18 Oct 2002 10:38:25 -0700 (PDT) (envelope-from rizzo) Date: Fri, 18 Oct 2002 10:38:25 -0700 From: Luigi Rizzo To: Petri Helenius Cc: Jim McGrath , Lars Eggert , freebsd-net@FreeBSD.ORG, freebsdnic@mailbox.cps.intel.com Subject: Re: ENOBUFS Message-ID: <20021018103825.B82982@carp.icir.org> References: <00b001c276ba$1533dbf0$3500080a@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <00b001c276ba$1533dbf0$3500080a@PHE>; from pete@he.iki.fi on Fri, Oct 18, 2002 at 06:21:37PM +0300 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, Oct 18, 2002 at 06:21:37PM +0300, Petri Helenius wrote: ... > Luigi´s polling work would be useful here. That would lead to incorrect > timestamps > on the packets, though? polling introduce an extra uncertainty which might be as large as an entire clock tick, yes. But even with interrupts, you cannot trust the time when the interrupt driver is run -- there are cases where an ISR is delayed by 10ms or more. And even when it runs, it might take quite a bit of time (up to a few 100's of microseconds) to drain the receive queue from packets received earlier. in normal cases, timestamps are reasonably accurate in both cases. In special cases, the error induced by having interrupts blocked causes errors which are much larger than polling alone. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 10:45:20 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 4E3E137B401 for ; Fri, 18 Oct 2002 10:45:19 -0700 (PDT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 503C243EB2 for ; Fri, 18 Oct 2002 10:45:18 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224]) by pimout2-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IHjEcK036722; Fri, 18 Oct 2002 13:45:15 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IHjDOQ001677; Fri, 18 Oct 2002 10:45:13 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 18 Oct 2002 10:45:13 -0700 (PDT) From: Kelly Yancey To: Luigi Rizzo Cc: Petri Helenius , Lars Eggert , Subject: Re: ENOBUFS In-Reply-To: <20021018103319.A82982@carp.icir.org> Message-ID: <20021018103653.V1611-100000@gateway.posi.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 On Fri, 18 Oct 2002, Luigi Rizzo wrote: > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote: > ... > > Hmm. Might that explain the abysmal performance of the em driver with > > packets smaller than 333 bytes? > > what do you mean ? it works great for me. even on -current i > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > luigi > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card plugged into PCI-X bus: FrameSize TxFrames RxFrames LostFrames Lost (%) 330 249984 129518 120466 48.19 331 249144 127726 121418 48.73 332 248472 140817 107655 43.33 333 247800 247800 0 0 It has no trouble handling frames 333 bytes or larger. But for any frame 332 bytes or smaller we consistently see ~50% packet loss. This same machine easily pushes ~100Mps with the very same frame sizes using a bge card rather than em. I've gotten the same results with both em driver version 1.3.14 and 1.3.15 on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is). Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} FreeBSD, The Power To Serve: http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 10:59:24 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 10E1C37B401 for ; Fri, 18 Oct 2002 10:59:23 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB78043EA3 for ; Fri, 18 Oct 2002 10:59:22 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IHxMpJ083285; Fri, 18 Oct 2002 10:59:22 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9IHxMFR083284; Fri, 18 Oct 2002 10:59:22 -0700 (PDT) (envelope-from rizzo) Date: Fri, 18 Oct 2002 10:59:22 -0700 From: Luigi Rizzo To: Kelly Yancey Cc: Petri Helenius , Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021018105922.E82982@carp.icir.org> References: <20021018103319.A82982@carp.icir.org> <20021018103653.V1611-100000@gateway.posi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021018103653.V1611-100000@gateway.posi.net>; from kbyanc@posi.net on Fri, Oct 18, 2002 at 10:45:13AM -0700 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 How is the measurement done, does the box under test act as a router with the smartbit pushing traffic in and expecting it back ? The numbers are strange, anyways. A frame of N bytes takes (N*8+160) nanoseconds on the wire, which for 330-byte frames should amount to 1000000/(330*8+160) ~= 357kpps, not the 249 or so you are seeing. Looks as if the times were 40% off. cheers luigi On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote: ... > > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > > > luigi > > > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card > plugged into PCI-X bus: > > FrameSize TxFrames RxFrames LostFrames Lost (%) > 330 249984 129518 120466 48.19 > 331 249144 127726 121418 48.73 > 332 248472 140817 107655 43.33 > 333 247800 247800 0 0 > > It has no trouble handling frames 333 bytes or larger. But for any frame > 332 bytes or smaller we consistently see ~50% packet loss. This same machine > easily pushes ~100Mps with the very same frame sizes using a bge card rather > than em. > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15 > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is). > > Kelly > > -- > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > FreeBSD, The Power To Serve: http://www.freebsd.org/ > > > 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 Oct 18 11:11:49 2002 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 916) id 0B7C837B401; Fri, 18 Oct 2002 11:11:48 -0700 (PDT) Date: Fri, 18 Oct 2002 11:11:48 -0700 From: Prafulla Deuskar To: Kelly Yancey Cc: Luigi Rizzo , Petri Helenius , Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021018111147.A91108@hub.freebsd.org> References: <20021018103319.A82982@carp.icir.org> <20021018103653.V1611-100000@gateway.posi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021018103653.V1611-100000@gateway.posi.net>; from kbyanc@posi.net on Fri, Oct 18, 2002 at 10:45:13AM -0700 X-Operating-System: FreeBSD 4.7-RC on an i386 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 FYI. 82543 doesn't support PCI-X protocol. For PCI-X support use 82544, 82545 or 82546 based cards. -Prafulla Kelly Yancey [kbyanc@posi.net] wrote: > On Fri, 18 Oct 2002, Luigi Rizzo wrote: > > > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote: > > ... > > > Hmm. Might that explain the abysmal performance of the em driver with > > > packets smaller than 333 bytes? > > > > what do you mean ? it works great for me. even on -current i > > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > > > luigi > > > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card > plugged into PCI-X bus: > > FrameSize TxFrames RxFrames LostFrames Lost (%) > 330 249984 129518 120466 48.19 > 331 249144 127726 121418 48.73 > 332 248472 140817 107655 43.33 > 333 247800 247800 0 0 > > It has no trouble handling frames 333 bytes or larger. But for any frame > 332 bytes or smaller we consistently see ~50% packet loss. This same machine > easily pushes ~100Mps with the very same frame sizes using a bge card rather > than em. > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15 > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is). > > Kelly > > -- > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > FreeBSD, The Power To Serve: http://www.freebsd.org/ > > > 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 Oct 18 11:14: 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 5EA8E37B401 for ; Fri, 18 Oct 2002 11:14:00 -0700 (PDT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BE6143E7B for ; Fri, 18 Oct 2002 11:13:59 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224]) by pimout4-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IIDtoi270898; Fri, 18 Oct 2002 14:13:56 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IIDtOQ001720; Fri, 18 Oct 2002 11:13:55 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 18 Oct 2002 11:13:54 -0700 (PDT) From: Kelly Yancey To: Luigi Rizzo Cc: Petri Helenius , Lars Eggert , Subject: Re: ENOBUFS In-Reply-To: <20021018105922.E82982@carp.icir.org> Message-ID: <20021018110238.T1611-100000@gateway.posi.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 On Fri, 18 Oct 2002, Luigi Rizzo wrote: > How is the measurement done, does the box under test act as a router > with the smartbit pushing traffic in and expecting it back ? > The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go through a Foundry ServerIron switch for VLAN tagging and then to the GigE interface (where they are untagged). The box is acting as a router and all traffic is directed out the fxp interface where it returns to the SmartBit. > The numbers are strange, anyways. > > A frame of N bytes takes (N*8+160) nanoseconds on the wire, which > for 330-byte frames should amount to 1000000/(330*8+160) ~= 357kpps, > not the 249 or so you are seeing. Looks as if the times were 40% off. > Yeah, I've never made to much sense of the actual numbers myself. Our resident SmartBit expert runs the tests and provides me with the results. I use them more for getting an idea of the relative performance of one configuration over another and not as absolute numbers themselves. I'll check with our resident expert and see if he can explain how it calculates those numbers. The point being, though, that there is an undeniable drop-off with 332 byte or smaller packets. We have never seen any such drop-off using the bge driver. Thanks, Kelly > cheers > luigi > > On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote: > ... > > > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > > > > > luigi > > > > > > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card > > plugged into PCI-X bus: > > > > FrameSize TxFrames RxFrames LostFrames Lost (%) > > 330 249984 129518 120466 48.19 > > 331 249144 127726 121418 48.73 > > 332 248472 140817 107655 43.33 > > 333 247800 247800 0 0 > > > > It has no trouble handling frames 333 bytes or larger. But for any frame > > 332 bytes or smaller we consistently see ~50% packet loss. This same machine > > easily pushes ~100Mps with the very same frame sizes using a bge card rather > > than em. > > > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15 > > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is). > > > > Kelly > > > > -- > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > > FreeBSD, The Power To Serve: http://www.freebsd.org/ > > > > > > 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 > -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 11:25:29 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 6084A37B401 for ; Fri, 18 Oct 2002 11:25:27 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id E37A843E77 for ; Fri, 18 Oct 2002 11:25:26 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021018182526.CAJZ11892.rwcrmhc52.attbi.com@blossom.cjclark.org>; Fri, 18 Oct 2002 18:25:26 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g9IIPNWn045992; Fri, 18 Oct 2002 11:25:23 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g9IIPM4w045991; Fri, 18 Oct 2002 11:25:22 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 18 Oct 2002 11:25:22 -0700 From: "Crist J. Clark" To: Matthew Zahorik Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPSEC/NAT issues Message-ID: <20021018182522.GC45449@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <20021018002729.T66900-100000@mail.allcaps.org> 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 Fri, Oct 18, 2002 at 06:39:51AM -0700, Matthew Zahorik wrote: > On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote: > > > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the > > packet will get rejected when it reaches the other IPSEC node. > > Not exactly true. I use a Windows Nortel Contivity client behind NAT just > fine. > > If you're using an AH association (header authentication) that will not > pass through NAT. I'm sure someone on this list may come up with a fancy > trick for FreeBSD, but generally the statement is true. AH detects the > NAT changes as header corruption. > > But if you're only using ESP (encryption of payload) that will work fine. > > Most turn on both AH and ESP by default, but that isn't always the case as > in the Nortel boxes. Not exactly true. The current ESP standard has its own header authentification mechanism. To verify end-to-end header integrity, you need only use ESP with this option turned on (excuse me if I don't go to the RFC to remind myself of the formal name of the option). And as another data point, the Cisco VPN Concentrator (formerly Altiga) run just fine through NAT by default. They do ESP without header integrity checks and UDP encapsulation of the ESP to make it easier to run it through NAT (although that isn't "real" IPsec anymore). > On another note, I'd *love* to use my FreeBSD NAT box as a VPN tunnel > endpoint rather than my windows boxes. It's a dynamic IP, so it's > catch-22 right now. I can't create a tunnel or SPD policy entry before I > know the IP addresses, and IKE/racoon can't start without those things. > > So, if someone happens to be ripping the IPsec processing apart, something > to eliminate this catch-22 would be nice (: (spd entries pointing to an > unconfigured or dummy tunnel, for example) What's the problem with just having the script that builds the SPD discover the IP address on its own? -- 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 Fri Oct 18 11:26: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 0110537B401 for ; Fri, 18 Oct 2002 11:26:53 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CFAF43EAC for ; Fri, 18 Oct 2002 11:26:52 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IIQqpJ083507; Fri, 18 Oct 2002 11:26:52 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9IIQqLh083506; Fri, 18 Oct 2002 11:26:52 -0700 (PDT) (envelope-from rizzo) Date: Fri, 18 Oct 2002 11:26:52 -0700 From: Luigi Rizzo To: Kelly Yancey Cc: Petri Helenius , Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021018112652.A83405@carp.icir.org> References: <20021018105922.E82982@carp.icir.org> <20021018110238.T1611-100000@gateway.posi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021018110238.T1611-100000@gateway.posi.net>; from kbyanc@posi.net on Fri, Oct 18, 2002 at 11:13:54AM -0700 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 Oh, I *thought* the numbers you reported were pps but now i see that nowhere you mentioned that. But if things are as you say, i am seriously puzzled on what you are trying to measure -- the output interface (fxp) is a 100Mbit/s card which cannot possibly support the load you are trying to offer to saturate the input link. You should definitely clarify how fast the smartbits unit is pushing out traffic, and whether its speed depends on the measured RTT. It might well be that what you are seeing is saturation of ipintrq, which happens because of some strange timing issue -- nothing to do with the board. In any case, at least in my experience, a 1GHz box with two em cards can easily forward between 350 and 400kpps (64-byte frames) with a 4.6-ish kernel, and a 2.4GHz box goes above 650kpps. cheers luigi On Fri, Oct 18, 2002 at 11:13:54AM -0700, Kelly Yancey wrote: > On Fri, 18 Oct 2002, Luigi Rizzo wrote: > > > How is the measurement done, does the box under test act as a router > > with the smartbit pushing traffic in and expecting it back ? > > > The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is > configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go > through a Foundry ServerIron switch for VLAN tagging and then to the GigE > interface (where they are untagged). The box is acting as a router and all > traffic is directed out the fxp interface where it returns to the SmartBit. > > > The numbers are strange, anyways. > > > > A frame of N bytes takes (N*8+160) nanoseconds on the wire, which > > for 330-byte frames should amount to 1000000/(330*8+160) ~= 357kpps, > > not the 249 or so you are seeing. Looks as if the times were 40% off. > > > > Yeah, I've never made to much sense of the actual numbers myself. Our > resident SmartBit expert runs the tests and provides me with the results. I > use them more for getting an idea of the relative performance of one > configuration over another and not as absolute numbers themselves. I'll check > with our resident expert and see if he can explain how it calculates those > numbers. The point being, though, that there is an undeniable drop-off with > 332 byte or smaller packets. We have never seen any such drop-off using the > bge driver. > > Thanks, > > Kelly > > > cheers > > luigi > > > > On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote: > > ... > > > > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > > > > > > > luigi > > > > > > > > > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card > > > plugged into PCI-X bus: > > > > > > FrameSize TxFrames RxFrames LostFrames Lost (%) > > > 330 249984 129518 120466 48.19 > > > 331 249144 127726 121418 48.73 > > > 332 248472 140817 107655 43.33 > > > 333 247800 247800 0 0 > > > > > > It has no trouble handling frames 333 bytes or larger. But for any frame > > > 332 bytes or smaller we consistently see ~50% packet loss. This same machine > > > easily pushes ~100Mps with the very same frame sizes using a bge card rather > > > than em. > > > > > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15 > > > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is). > > > > > > Kelly > > > > > > -- > > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > > > FreeBSD, The Power To Serve: http://www.freebsd.org/ > > > > > > > > > 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 > > > > -- > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/ > > > 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 Oct 18 11:46:33 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 C2E4A37B413 for ; Fri, 18 Oct 2002 11:46:31 -0700 (PDT) Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7333343E9E for ; Fri, 18 Oct 2002 11:46:31 -0700 (PDT) (envelope-from vulture@consult-scs.com) Received: from consult-scs.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60]) (authenticated bits=0) by consult-scs.com (8.12.6/8.12.6) with ESMTP id g9IIkQIB032135; Fri, 18 Oct 2002 11:46:26 -0700 (PDT) Message-ID: <3DB05716.8080806@consult-scs.com> Date: Fri, 18 Oct 2002 11:46:46 -0700 From: Jonathan Feally User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Henrich , freebsd-net@freebsd.org Subject: Re: IPSEC/NAT issues References: <20021017162243.B89519@sigbus.com> 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 As I think about it, it isn't IPSEC that needs to process twice once before and once after ipfw. Its the other way around. IPFW should first allow the ESP packets into the machine, then IPSEC extracted the secured packet, and then IPFW will process the normal packet again, thus allowing the divert to natd to acutally recieve the non-ipsec version of the packet. I did some poking around with the kernel code last night, but can't seem to figure out where to cause a packet that was recieved as IPSEC to go back though ipfw. I'll keep trying. The files I've been looking though are sys/netinet/ip_input.c and sys/netinet/ip_outpuit.c Charles Henrich wrote: >I apologize for not CC'ing originally! > >I have a network/firewall where I want to nat an entire network. However, I >also want nat traffic to one remote host in particular out on the internet to >be IPsec'd as well. > >[A] (10.x) [B] (Nat) [C] (Real IP) > >I've setup IPsec on both machines, and from either machine (B,C) I can ssh to >the other, with ipsec packets all happening happy as a clam. However if try a >connection from behind the nat box to the remote host (A,C) the key exchange >works fine (between B&C), but then no data flows back and forth. Anyone have >any suggestions on this? Thanks! > >-Crh > > Charles Henrich henrich@msu.edu > > http://www.sigbus.com/~henrich > > >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 Oct 18 11:48: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 CDEB837B401; Fri, 18 Oct 2002 11:48:14 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2072E43EA3; Fri, 18 Oct 2002 11:48:14 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IImCLE599274; Fri, 18 Oct 2002 14:48:13 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IImBOQ001782; Fri, 18 Oct 2002 11:48:11 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 18 Oct 2002 11:48:11 -0700 (PDT) From: Kelly Yancey To: Prafulla Deuskar Cc: Luigi Rizzo , Petri Helenius , Lars Eggert , Subject: Re: ENOBUFS In-Reply-To: <20021018111147.A91108@hub.freebsd.org> Message-ID: <20021018113427.Y1611-100000@gateway.posi.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 On Fri, 18 Oct 2002, Prafulla Deuskar wrote: > FYI. 82543 doesn't support PCI-X protocol. > For PCI-X support use 82544, 82545 or 82546 based cards. > > -Prafulla > That is alright, we aren't expecting PCI-X speeds. It is just that our only PCI slot on the motherboard (1U rack-mount system) is a PCI-X slot. Shouldn't the 82543 still function normally but only as at PCI speeds? Thanks, Kelly > > Kelly Yancey [kbyanc@posi.net] wrote: > > On Fri, 18 Oct 2002, Luigi Rizzo wrote: > > > > > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote: > > > ... > > > > Hmm. Might that explain the abysmal performance of the em driver with > > > > packets smaller than 333 bytes? > > > > > > what do you mean ? it works great for me. even on -current i > > > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > > > > > luigi > > > > > > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card > > plugged into PCI-X bus: > > > > FrameSize TxFrames RxFrames LostFrames Lost (%) > > 330 249984 129518 120466 48.19 > > 331 249144 127726 121418 48.73 > > 332 248472 140817 107655 43.33 > > 333 247800 247800 0 0 > > > > It has no trouble handling frames 333 bytes or larger. But for any frame > > 332 bytes or smaller we consistently see ~50% packet loss. This same machine > > easily pushes ~100Mps with the very same frame sizes using a bge card rather > > than em. > > > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15 > > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is). > > > > Kelly > > > > -- > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > > FreeBSD, The Power To Serve: http://www.freebsd.org/ > > > > > > 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 > -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} "No nation is permitted to live in ignorance with impunity." -- Thomas Jefferson, 1821. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 12:17: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 612CF37B401 for ; Fri, 18 Oct 2002 12:17:44 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B43F43E6A for ; Fri, 18 Oct 2002 12:17:43 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IJHcLE322542; Fri, 18 Oct 2002 15:17:39 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IJHXOQ001827; Fri, 18 Oct 2002 12:17:38 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 18 Oct 2002 12:17:33 -0700 (PDT) From: Kelly Yancey To: Luigi Rizzo Cc: Petri Helenius , Lars Eggert , Subject: Re: ENOBUFS In-Reply-To: <20021018112652.A83405@carp.icir.org> Message-ID: <20021018114829.Y1611-100000@gateway.posi.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 On Fri, 18 Oct 2002, Luigi Rizzo wrote: > Oh, I *thought* the numbers you reported were pps but now i see that > nowhere you mentioned that. > Sorry. I just checked with our tester. Those are the total number of packets sent during the test. Each test lasted 10 seconds, so divde by 10 to get pps. > But if things are as you say, i am seriously puzzled on what you > are trying to measure -- the output interface (fxp) is a 100Mbit/s > card which cannot possibly support the load you are trying to offer > to saturate the input link. > We don't want to saturate the input link, only saturate the outbound link (100Mps). Oddly enough, the em card cannot do this with any packets less than 333 bytes and drops ~50% of the packets. But clearly this isn't a bottlenext issue because the drop-off isn't smooth. 332 byte backs cause ~50% packet loss; 333 byte packets cause 0% packet loss. > You should definitely clarify how fast the smartbits unit is pushing > out traffic, and whether its speed depends on the measured RTT. > It doesn't sound like the box is that smart. As it was explained to me, the test setup includes a desired 'load' to put on the wire: it is measured as a percentage of the wire speed. Since our SmartBit unit only supports 100base-T and doesn't understand vlans, we have to use 7 separate outbound ports, each configured for 14.25% load. To the GigE interface, this should appear as 99.75 megabits of data (including all headers/framing). > It might well be that what you are > seeing is saturation of ipintrq, which happens because of some > strange timing issue -- nothing to do with the board. > I don't understand why it would only happen with the em card and not with the bge under the exact same traffic (or even more demanding traffic, i.e. 64byte frames). Also, wouldn't packet gradually subside as we approached the 333 byte magic limit rather than the sudden drop-off we are seeing? > In any case, at least in my experience, a 1GHz box with two em > cards can easily forward between 350 and 400kpps (64-byte frames) with a > 4.6-ish kernel, and a 2.4GHz box goes above 650kpps. > We expect our kernel to be slower than that (we typically see ~120kpps for 64-byte frames using the bge driver and a 5701-based card) because we are using an fxp card for outbound traffic and have added additional code to the ip_input() processing. The point isn't absolute numbers, though, but trying to figure out why when using the em driver (and only with the em driver!) we see ~50% packet loss with packets smaller than 333 bytes (no matter what size, just that it is smaller). That is, 64 byte frames: ~50% packet loss; 332 byte frames: ~50% packet loss; 333 byte frames: 0% packet loss. That sort of sudden drop doesn't look like a bottleneck to me. We've mostly written the em driver off because of this. The bge driver works just fine performance wise; it was the sporadic watchdog timeouts that led us to investigate the Intel cards to begin with. I only mentioned it on-list because earlier Jim McGrath alluded to similar performance issues with the Intel GigE cards and small frames. Actually, at this point, I'm hoping that your polling patches for the em driver workaround whatever problem is causing the packet loss and am eagerly awaiting them to be committed. :) Thanks, Kelly > > On Fri, Oct 18, 2002 at 11:13:54AM -0700, Kelly Yancey wrote: > > On Fri, 18 Oct 2002, Luigi Rizzo wrote: > > > > > How is the measurement done, does the box under test act as a router > > > with the smartbit pushing traffic in and expecting it back ? > > > > > The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is > > configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go > > through a Foundry ServerIron switch for VLAN tagging and then to the GigE > > interface (where they are untagged). The box is acting as a router and all > > traffic is directed out the fxp interface where it returns to the SmartBit. > > > > > The numbers are strange, anyways. > > > > > > A frame of N bytes takes (N*8+160) nanoseconds on the wire, which > > > for 330-byte frames should amount to 1000000/(330*8+160) ~= 357kpps, > > > not the 249 or so you are seeing. Looks as if the times were 40% off. > > > > > > > Yeah, I've never made to much sense of the actual numbers myself. Our > > resident SmartBit expert runs the tests and provides me with the results. I > > use them more for getting an idea of the relative performance of one > > configuration over another and not as absolute numbers themselves. I'll check > > with our resident expert and see if he can explain how it calculates those > > numbers. The point being, though, that there is an undeniable drop-off with > > 332 byte or smaller packets. We have never seen any such drop-off using the > > bge driver. > > > > Thanks, > > > > Kelly > > > > > cheers > > > luigi > > > > > > On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote: > > > ... > > > > > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > > > > > > > > > luigi > > > > > > > > > > > > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card > > > > plugged into PCI-X bus: > > > > > > > > FrameSize TxFrames RxFrames LostFrames Lost (%) > > > > 330 249984 129518 120466 48.19 > > > > 331 249144 127726 121418 48.73 > > > > 332 248472 140817 107655 43.33 > > > > 333 247800 247800 0 0 > > > > > > > > It has no trouble handling frames 333 bytes or larger. But for any frame > > > > 332 bytes or smaller we consistently see ~50% packet loss. This same machine > > > > easily pushes ~100Mps with the very same frame sizes using a bge card rather > > > > than em. > > > > > > > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15 > > > > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is). > > > > > > > > Kelly > > > > > > > > -- > > > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > > > > FreeBSD, The Power To Serve: http://www.freebsd.org/ > > > > > > > > > > > > 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 > > > > > > > -- > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} > > Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/ > > > > > > 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 > -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 12:26: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 21E5B37B401 for ; Fri, 18 Oct 2002 12:26:30 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8496743EAC for ; Fri, 18 Oct 2002 12:26:29 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224]) by pimout3-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IJQOne512386; Fri, 18 Oct 2002 15:26:25 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IJQJOQ001849; Fri, 18 Oct 2002 12:26:20 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 18 Oct 2002 12:26:19 -0700 (PDT) From: Kelly Yancey To: Luigi Rizzo Cc: Petri Helenius , Lars Eggert , Subject: Re: ENOBUFS In-Reply-To: <20021018114829.Y1611-100000@gateway.posi.net> Message-ID: <20021018122321.G1611-100000@gateway.posi.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 On Fri, 18 Oct 2002, Kelly Yancey wrote: > > You should definitely clarify how fast the smartbits unit is pushing > > out traffic, and whether its speed depends on the measured RTT. > > > > It doesn't sound like the box is that smart. As it was explained to me, the > test setup includes a desired 'load' to put on the wire: it is measured as a > percentage of the wire speed. Since our SmartBit unit only supports > 100base-T and doesn't understand vlans, we have to use 7 separate outbound > ports, each configured for 14.25% load. To the GigE interface, this should > appear as 99.75 megabits of data (including all headers/framing). > Oops. That was actually the explanation of the SmartBits 'desired ILoad' which I didn't quote in the posted numbers. The actual number of packets transmitted is based on RTT. Sorry for the confusion, Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} "No nation is permitted to live in ignorance with impunity." -- Thomas Jefferson, 1821. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 13:16: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 04E2537B401 for ; Fri, 18 Oct 2002 13:16:31 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 0E96D43EA9 for ; Fri, 18 Oct 2002 13:16:30 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 42728 invoked from network); 18 Oct 2002 20:16:28 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 18 Oct 2002 20:16:28 -0000 Message-ID: <3DB06C1C.8070502@tenebras.com> Date: Fri, 18 Oct 2002 13:16:28 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, fr-fr, ru MIME-Version: 1.0 To: "Crist J. Clark" Cc: Matthew Zahorik , freebsd-net@FreeBSD.ORG Subject: Re: IPSEC/NAT issues References: <20021018002729.T66900-100000@mail.allcaps.org> <20021018182522.GC45449@blossom.cjclark.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 Crist J. Clark wrote: > ...The current ESP standard has its own header > authentification mechanism. To verify end-to-end header integrity, you > need only use ESP with this option turned on (excuse me if I don't go > to the RFC to remind myself of the formal name of the option). I just happened to be looking at it, so... RFC 2406 IP Encapsulating Security Payload (ESP) ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. 2.7 Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field is specified by the authentication function selected. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation. BEFORE APPLYING ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | TCP | Data | Trailer |Auth| ------------------------------------------------- |<----- encrypted ---->| |<------ authenticated ----->| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 13:41: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 1A00737B401 for ; Fri, 18 Oct 2002 13:41:48 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79C6143E91 for ; Fri, 18 Oct 2002 13:41:47 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VAXG>; Fri, 18 Oct 2002 15:53:43 -0400 Message-ID: From: Don Bowman To: 'Luigi Rizzo' , Kelly Yancey Cc: Petri Helenius , Lars Eggert , freebsd-net@FreeBSD.ORG Subject: RE: ENOBUFS Date: Fri, 18 Oct 2002 15:53:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 > From: Luigi Rizzo [mailto:rizzo@icir.org] > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote: > ... > > Hmm. Might that explain the abysmal performance of the > em driver with > > packets smaller than 333 bytes? > > what do you mean ? it works great for me. even on -current i > can push out over 400kpps (64byte frames) on a 2.4GHz box. 400kpps seems like very poor performance. Unless I do the math wrong, this is only ~200Mbps, the nic should be able to allow ~2-3Mpps (GE bidirectional). The performance tests I've been doing have also shown that the broadcom chip (with the bge driver) outperforms the intel chip (with the em driver) for small packets. This could be due to tuning in the driver (there are different tunables in both cases) or due to erroneous/over-aggressive workarounds. For example, in the broadcom GE chip, the driver blindly turns off hardware acceleration for checksums, when it really only needs to do this for certain early rev silicon. This had a negligible performance improvement @ any rate owing to the high speed of the processor :) The linux driver (avail from broadcom) provides some hints here. The most pressing limit I ran into was the user->kernel up/down stack interface. Using 'iperf' with UDP, the transmitter runs out of gas just going up and down the stack, in and out of kernel, over the sysctl, etc long before the nic runs out of speed (for small packets). Seems like there's some interest in a bakeoff :) I'm willing to post some results when I have them avail. My $0.02 is that there is likely some outdated 'war stories' on all silicon that tends to end up implemented as work-arounds in the driver long after they are fixed in silicon. The (insert negative opinion) strategy of the silicon vendors of hiding their errata and datasheets makes for much poorer utilisation of their product. At least intel has had the good sense to release their driver. --don To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 13:48: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 5A5C437B401 for ; Fri, 18 Oct 2002 13:48:58 -0700 (PDT) Received: from wheeljack.redlamb.net (wheeljack.redlamb.net [65.240.12.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B9FD43EAC for ; Fri, 18 Oct 2002 13:48:57 -0700 (PDT) (envelope-from redlamb@redlamb.net) Received: from mirage.redlamb.net (optimusprime.redlamb.net [208.210.151.74]) by wheeljack.redlamb.net (Postfix) with ESMTP id 354F73FEB2 for ; Fri, 18 Oct 2002 11:17:48 -0500 (CDT) Received: by mirage.redlamb.net (Postfix, from userid 1000) id 6CE0D248; Fri, 18 Oct 2002 11:17:48 -0500 (CDT) Date: Fri, 18 Oct 2002 11:17:48 -0500 From: Peter Erickson To: FreeBSD-Net List Subject: Ethernet bonding with netgraph Message-ID: <20021018161748.GA16899@redlamb.net> Mail-Followup-To: FreeBSD-Net List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Could someone please explain to me how to setup a channel-bond between two ethernet cards? I am VERY new to the whole idea of netgraph and I am not too sure how to go about setting one up. After searching on google, I found something about using ng_fec, but I am still unsure about which node types I need to connect and how to connect them. I'm also unsure of what kernel options that I need to add. If it matters, I am running FBSD 4.6 and I am trying to setup Snort to listen to two ethernet cards that are connected to a Finisar UTP/1L network tap. Please help. Thanks in advance for any help. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 13:52:39 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 77BF437B401 for ; Fri, 18 Oct 2002 13:52:38 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 773DE43E8A for ; Fri, 18 Oct 2002 13:52:37 -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 g9IKqTYj087581; Fri, 18 Oct 2002 23:52:31 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <017201c276e8$58e4b8f0$3500080a@PHE> From: "Petri Helenius" To: "Luigi Rizzo" Cc: "Jim McGrath" , "Lars Eggert" , References: <00b001c276ba$1533dbf0$3500080a@PHE> <20021018103825.B82982@carp.icir.org> Subject: Re: ENOBUFS Date: Fri, 18 Oct 2002 23:53:00 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 > In special cases, the error induced by having interrupts blocked > causes errors which are much larger than polling alone. Which conditions block interrupts for longer than, say, a millisecond? Disk errors / wakeups? Anything occurring in "normal" conditions? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 13:53:24 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 BFB5637B401 for ; Fri, 18 Oct 2002 13:53:23 -0700 (PDT) Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1A9C43E9E for ; Fri, 18 Oct 2002 13:53:22 -0700 (PDT) (envelope-from jimmcgra@bellatlantic.net) Received: from Default ([141.154.237.113]) by out002.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20021018205322.XXVC2867.out002.verizon.net@Default>; Fri, 18 Oct 2002 15:53:22 -0500 From: "Jim McGrath" To: "Kelly Yancey" , "Luigi Rizzo" Cc: "Petri Helenius" , "Lars Eggert" , Subject: RE: ENOBUFS Date: Fri, 18 Oct 2002 16:53:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20021018114829.Y1611-100000@gateway.posi.net> Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at out002.verizon.net from [141.154.237.113] at Fri, 18 Oct 2002 15:53:21 -0500 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 was testing the wx driver with an 82544 based NIC. Small packets were used to allow very high packet rates. I was experimenting with various values of RIDV. The problem I experienced was 82544 chip lockup when RIDV was nonzero and packet rate was high. Small packets were never a problem by themselves. Jim > We've mostly written the em driver off because of this. The bge driver > works just fine performance wise; it was the sporadic watchdog timeouts > that led us to investigate the Intel cards to begin with. I only > mentioned it > on-list because earlier Jim McGrath alluded to similar > performance issues with > the Intel GigE cards and small frames. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 13:57:39 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 60C9D37B401; Fri, 18 Oct 2002 13:57:37 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9FB43E97; Fri, 18 Oct 2002 13:57:35 -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 g9IKvXYj087664; Fri, 18 Oct 2002 23:57:34 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <018001c276e9$0d6a4100$3500080a@PHE> From: "Petri Helenius" To: "Prafulla Deuskar" Cc: "Luigi Rizzo" , "Lars Eggert" , References: <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> <0be401c2761f$855af670$8c2a40c1@PHE> <20021017201158.A75351@carp.icir.org> <0d0b01c27680$b553ba90$8c2a40c1@PHE> <20021018102203.A86452@hub.freebsd.org> Subject: Re: ENOBUFS Date: Fri, 18 Oct 2002 23:58:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 > Transmit/Receive Interrupt Delay values are in units of 1.024 microseconds. > The em driver currently uses these to enable interrupt coalescing on the cards. > Is this one and 24 one thousandth of microseconds or 1024 microseconds which equals to about one millisecond and sounds quite a lot? With former, em would "top out" at about 35000 interrupts a second. (times two for two interfaces) With 256 receive descriptors available this would translate to about 9Mpps :-) Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 14: 4: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 1CA6C37B401 for ; Fri, 18 Oct 2002 14:04:47 -0700 (PDT) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9C743E8A for ; Fri, 18 Oct 2002 14:04:45 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Received: from babelfish (babelfish [192.168.168.42]) by pursued-with.net (8.12.6/8.12.5) with ESMTP id g9IL4iFv040054; Fri, 18 Oct 2002 14:04:44 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Date: Fri, 18 Oct 2002 14:04:44 -0700 (PDT) From: Kevin Stevens Reply-To: Kevin_Stevens@pursued-with.net To: Don Bowman Cc: freebsd-net@FreeBSD.ORG Subject: RE: ENOBUFS In-Reply-To: Message-ID: <20021018135434.Y40012-100000@babelfish.pursued-with.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 On Fri, 18 Oct 2002, Don Bowman wrote: > > what do you mean ? it works great for me. even on -current i > > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > 400kpps seems like very poor performance. > Unless I do the math wrong, this is only ~200Mbps, > the nic should be able to allow ~2-3Mpps (GE bidirectional). First, you're only pushing packets, so you are only talking a potential 1GB, not two. Second, sending minimum-size packets, while a best-case metric for pps, is a worst-case metric for throughput. I don't think that you can conclude that 20% theoretical bandwidth utilization at minimum packet size is poor performance; in fact it seems pretty good to me. Extrapolating from those numbers, if the packets were five times larger (320b), you'd hit theoretical maximum throughput. Obviously that won't happen, your pps numbers will go down as the packet size goes up, but it does indicate you have some headroom, even without going to jumbo frames if the card pushed five times fewer pps at 1500 byte frames you'd max out the throughput. You can't tell very much from a single data point like that, but what you can infer doesn't seem to me to be bad at all. KeS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 14: 5:37 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 61BDE37B401 for ; Fri, 18 Oct 2002 14:05:36 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7AB443EA9 for ; Fri, 18 Oct 2002 14:05:35 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IL5YpJ084818; Fri, 18 Oct 2002 14:05:34 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9IL5YSo084817; Fri, 18 Oct 2002 14:05:34 -0700 (PDT) (envelope-from rizzo) Date: Fri, 18 Oct 2002 14:05:34 -0700 From: Luigi Rizzo To: Petri Helenius Cc: Jim McGrath , Lars Eggert , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021018140534.A84731@carp.icir.org> References: <00b001c276ba$1533dbf0$3500080a@PHE> <20021018103825.B82982@carp.icir.org> <017201c276e8$58e4b8f0$3500080a@PHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <017201c276e8$58e4b8f0$3500080a@PHE>; from pete@he.iki.fi on Fri, Oct 18, 2002 at 11:53:00PM +0300 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, Oct 18, 2002 at 11:53:00PM +0300, Petri Helenius wrote: > > In special cases, the error induced by having interrupts blocked > > causes errors which are much larger than polling alone. > > Which conditions block interrupts for longer than, say, a millisecond? changes in link status in several ethernet drivers will cause their interrupt service routine (ISR) to loop polling for some event. A similar thing used to happen in the xl driver when fetching statistics, once per second (hopefully fixed now). Even in "normal" condition, the ISR for a network card has to loop around the status bit until no interrupts are pending, and because (typically) the receive ring is replenished while you process it, and packets come in without explicitly requesting them, there is no upper bound on how long you will loop. I wouldn't be surprised if there were other drivers doing busy-wait cycles in the interrupt service routine, because sometimes the driver detects an error condition and calls some generic routine to reinitialize the hardware, but that routine has been written for use at attach time, not at runtime. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 14:20:24 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 060B937B401 for ; Fri, 18 Oct 2002 14:20:18 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 107A043E6A for ; Fri, 18 Oct 2002 14:20:17 -0700 (PDT) (envelope-from stephenm@windriver.com) Received: from brisbane (brisbane [147.11.38.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA25087; Fri, 18 Oct 2002 14:19:16 -0700 (PDT) Message-Id: <200210182119.OAA25087@mail.wrs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: cjclark@alum.mit.edu Cc: net@freebsd.org, stephenm@mail.wrs.com Subject: Re: Strange FTP TCP Window Problem In-reply-to: Your message of "Fri, 18 Oct 2002 10:10:55 PDT." <20021018171055.GA45449@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Oct 2002 14:20:07 -0700 From: Stephen Macmanus 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 type of behavior typically indicates a problem with the application itself, above the socket layer, not TCP or the other protocols. The window size continually decreases as data arrives since TCP is storing the incoming data in the receive buffer, but the target application is not reading it. I have seen cases where this behavior occurs due to subtle failures like CPU starvation due to scheduling priorities or incorrect mutual exclusion. I have also encountered simpler causes, such as creating a socket for the purpose of sending data that uses a port which also matches incoming data. In that case, the application simply never read the unexpected data from the socket. Setting the receive buffer to zero allowed TCP to discard the data and avoid the problem. This possibility may not apply in your case, since the client successfully handles other file transfers, but in my experience the application is the most likely cause of the problem. Stephen -- ------------------ Stephen Macmanus #include Technical Staff Wind River Networks stephenm@wrs.com > This has got me stumped. I must be missing something obvious. I am > trying to download some files via FTP. There are four files. Three > download just fine, one just won't go. Since the three work fine, I > assume it's not PORT vs. PASV, NAT, or other firewall issues, that is, > the usual suspects have been eliminated. But what is really strange is > that it looks like _my client_ is the one causing the headaches. > > Here is a tcpdump(8) of the data connection. Keep an eye on the window > values my client is sending back, > > 09:15:11.097800 a.b.c.136.29826 > d.e.f.17.18747: S [tcp sum ok] 2410623756:2410623756(0) win 16384 (ttl 64, id 50031, len 64) > 09:15:11.118335 d.e.f.17.18747 > a.b.c.136.29826: S [tcp sum ok] 2932757104:2932757104(0) ack 2410623757 win 16384 (ttl 56, id 24108, len 60) > 09:15:11.118443 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1 win 16500 (ttl 64, id 43640, len 52) > 09:15:11.156424 d.e.f.17.18747 > a.b.c.136.29826: . 1:501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24111, len 552) > 09:15:11.159468 d.e.f.17.18747 > a.b.c.136.29826: . 501:1001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24112, len 552) > 09:15:11.227371 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1001 win 15500 [tos 0x8] (ttl 64, id 61006, len 52) > 09:15:11.258205 d.e.f.17.18747 > a.b.c.136.29826: . 1001:1501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24113, len 552) > 09:15:11.261225 d.e.f.17.18747 > a.b.c.136.29826: . 1501:2001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24114, len 552) > 09:15:11.279923 d.e.f.17.18747 > a.b.c.136.29826: . 2001:2501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24115, len 552) > 09:15:11.427395 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 2501 win 14000 [tos 0x8] (ttl 64, id 40196, len 52) > 09:15:11.457865 d.e.f.17.18747 > a.b.c.136.29826: . 2501:3001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24116, len 552) > 09:15:11.461105 d.e.f.17.18747 > a.b.c.136.29826: . 3001:3501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24117, len 552) > 09:15:11.480485 d.e.f.17.18747 > a.b.c.136.29826: . 3501:4001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24118, len 552) > 09:15:11.483702 d.e.f.17.18747 > a.b.c.136.29826: . 4001:4501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24119, len 552) > 09:15:11.627707 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 4501 win 12000 [tos 0x8] (ttl 64, id 44302, len 52) > 09:15:11.648692 d.e.f.17.18747 > a.b.c.136.29826: . 4501:5001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24120, len 552) > 09:15:11.659731 d.e.f.17.18747 > a.b.c.136.29826: . 5001:5501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24121, len 552) > 09:15:11.670448 d.e.f.17.18747 > a.b.c.136.29826: . 5501:6001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24122, len 552) > 09:15:11.673581 d.e.f.17.18747 > a.b.c.136.29826: . 6001:6501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24123, len 552) > 09:15:11.692780 d.e.f.17.18747 > a.b.c.136.29826: . 6501:7001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24124, len 552) > 09:15:11.827393 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 7001 win 9500 [tos 0x8] (ttl 64, id 38068, len 52) > 09:15:11.855900 d.e.f.17.18747 > a.b.c.136.29826: . 7001:7501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24125, len 552) > 09:15:11.860077 d.e.f.17.18747 > a.b.c.136.29826: . 7501:8001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24126, len 552) > 09:15:11.878834 d.e.f.17.18747 > a.b.c.136.29826: . 8001:8501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24127, len 552) > 09:15:11.881856 d.e.f.17.18747 > a.b.c.136.29826: . 8501:9001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24128, len 552) > 09:15:11.892382 d.e.f.17.18747 > a.b.c.136.29826: . 9001:9501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24129, len 552) > 09:15:11.903415 d.e.f.17.18747 > a.b.c.136.29826: . 9501:10001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24130, len 552) > 09:15:12.027385 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 10001 win 6500 [tos 0x8] (ttl 64, id 60342, len 52) > 09:15:12.052757 d.e.f.17.18747 > a.b.c.136.29826: . 10001:10501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24131, len 552) > 09:15:12.063589 d.e.f.17.18747 > a.b.c.136.29826: . 10501:11001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24132, len 552) > 09:15:12.074515 d.e.f.17.18747 > a.b.c.136.29826: . 11001:11501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24133, len 552) > 09:15:12.078151 d.e.f.17.18747 > a.b.c.136.29826: . 11501:12001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24134, len 552) > 09:15:12.096930 d.e.f.17.18747 > a.b.c.136.29826: . 12001:12501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24135, len 552) > 09:15:12.099980 d.e.f.17.18747 > a.b.c.136.29826: . 12501:13001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24136, len 552) > 09:15:12.110647 d.e.f.17.18747 > a.b.c.136.29826: . 13001:13501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24137, len 552) > 09:15:12.227383 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 13501 win 3000 [tos 0x8] (ttl 64, id 51576, len 52) > 09:15:12.264837 d.e.f.17.18747 > a.b.c.136.29826: . 13501:14001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24138, len 552) > 09:15:12.268095 d.e.f.17.18747 > a.b.c.136.29826: . 14001:14501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24139, len 552) > 09:15:12.278653 d.e.f.17.18747 > a.b.c.136.29826: . 14501:15001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24140, len 552) > 09:15:12.289849 d.e.f.17.18747 > a.b.c.136.29826: . 15001:15501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24141, len 552) > 09:15:12.293592 d.e.f.17.18747 > a.b.c.136.29826: . 15501:16001(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24142, len 552) > 09:15:12.427402 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16001 win 500 [tos 0x8] (ttl 64, id 41001, len 52) > 09:15:17.202100 d.e.f.17.18747 > a.b.c.136.29826: . 16001:16501(500) ack 1 win 16384 [tos 0x8] (ttl 56, id 24157, len 552) > 09:15:17.227476 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 59052, len 52) > 09:15:22.186435 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 24183, len 53) > 09:15:22.186625 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 55942, len 52) > 09:15:30.194393 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 24221, len 53) > 09:15:30.195913 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 14020, len 52) > 09:15:46.198335 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 24333, len 53) > 09:15:46.198583 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 16087, len 52) > 09:16:18.201164 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 24500, len 53) > 09:16:18.201409 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 30338, len 52) > 09:17:18.194176 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 25061, len 53) > 09:17:18.194430 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 20615, len 52) > 09:18:18.193763 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 25447, len 53) > 09:18:18.194005 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 12107, len 52) > 09:19:18.186418 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 [tos 0x8] (ttl 56, id 25862, len 53) > 09:19:18.187970 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 [tos 0x8] (ttl 64, id 51084, len 52) > > And this just hangs here forever. > > I can't see why the client is refusing to accept more data. Like I > said, I'll bet I'm not seeing something obvious, but all of the SEQ > and ACK numbers look good to me. I should note that this isn't just an > issue with the FreeBSD ftp client. I get the same result with Windows, > Solaris, Cygwin, and OpenBSD too. > > Why is it happening and how do I get around this? > -- > 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 -- ------------------ Stephen Macmanus #include Technical Staff Wind River Networks stephenm@wrs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 14:32: 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 837C837B401 for ; Fri, 18 Oct 2002 14:32:01 -0700 (PDT) Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2635443E88 for ; Fri, 18 Oct 2002 14:32:01 -0700 (PDT) (envelope-from ras@e-gerbil.net) Received: by overlord.e-gerbil.net (Postfix, from userid 1000) id 961FA15E4B; Fri, 18 Oct 2002 17:31:54 -0400 (EDT) Date: Fri, 18 Oct 2002 17:31:54 -0400 From: Richard A Steenbergen To: Kevin Stevens Cc: Don Bowman , freebsd-net@FreeBSD.ORG Subject: Re: ENOBUFS Message-ID: <20021018213154.GO26000@overlord.e-gerbil.net> References: <20021018135434.Y40012-100000@babelfish.pursued-with.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021018135434.Y40012-100000@babelfish.pursued-with.net> 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 Fri, Oct 18, 2002 at 02:04:44PM -0700, Kevin Stevens wrote: > > First, you're only pushing packets, so you are only talking a potential > 1GB, not two. > > Second, sending minimum-size packets, while a best-case metric for pps, is > a worst-case metric for throughput. I don't think that you can conclude > that 20% theoretical bandwidth utilization at minimum packet size is poor > performance; in fact it seems pretty good to me. Extrapolating from those > numbers, if the packets were five times larger (320b), you'd hit > theoretical maximum throughput. Obviously that won't happen, your pps > numbers will go down as the packet size goes up, but it does indicate you > have some headroom, even without going to jumbo frames if the card pushed > five times fewer pps at 1500 byte frames you'd max out the throughput. > > You can't tell very much from a single data point like that, but what you > can infer doesn't seem to me to be bad at all. Counting overhead for the preamble, SFD, the ethernet headers, the checksum, the interframe gap, and the padding required to produce a minimum sized ethernet frame, the equivalent of no less than 84 bytes is transmitted for any frame. That makes the maximum unidirectional packets/sec on GigE 1.488Mpps. 400kpps is a little under 27% of this. In "normal" use that's probably good enough, but it's hardly what I'd call line rate. :) -- 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 Fri Oct 18 14:41: 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 082B937B401 for ; Fri, 18 Oct 2002 14:41:07 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7511D43EA9 for ; Fri, 18 Oct 2002 14:41:06 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <42S9VA79>; Fri, 18 Oct 2002 17:41:05 -0400 Message-ID: From: Don Bowman To: "'Kevin_Stevens@pursued-with.net'" , Don Bowman Cc: freebsd-net@FreeBSD.ORG Subject: RE: ENOBUFS Date: Fri, 18 Oct 2002 17:40:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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 From: Kevin Stevens [mailto:Kevin_Stevens@pursued-with.net] > On Fri, 18 Oct 2002, Don Bowman wrote: > > > > what do you mean ? it works great for me. even on -current i > > > can push out over 400kpps (64byte frames) on a 2.4GHz box. > > > > 400kpps seems like very poor performance. > > Unless I do the math wrong, this is only ~200Mbps, > > the nic should be able to allow ~2-3Mpps (GE bidirectional). > > First, you're only pushing packets, so you are only talking a > potential 1GB, not two. > > Second, sending minimum-size packets, while a best-case > metric for pps, is a worst-case metric for throughput. > I don't think that you can conclude that 20% theoretical > bandwidth utilization at minimum packet size is poor > performance; in fact it seems pretty good to me. Problem is, I'm making a bridge application which operates in a network similar to a router, not an endpoint server which receives TCP packets. There's a huge number of small packets on the internet due to TCP ACK's etc. I need to be able to do ~1.5Mpps x 2 for a single interface (both directions), which becomes ~1.5Mpps x 4 for an 'in' and an 'out' interface. Clearly you are correct that for most client/server applications 64-byte pps are not the interesting stat. Clearly I will have some tuning ahead, and likely I will not succeed, but for sure my 1U XEON with 6 gigabit nics will work very hard for its living :) --don (don@sandvine.com www.sandvine.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 15:41:28 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 0B1F237B401 for ; Fri, 18 Oct 2002 15:41:27 -0700 (PDT) Received: from nyvw02.kddia.com (ny.kdd.com [209.137.139.35]) by mx1.FreeBSD.org (Postfix) with SMTP id C85A343E65 for ; Fri, 18 Oct 2002 15:41:25 -0700 (PDT) (envelope-from fengli@kddia.com) Received: from 192.168.11.1 by nyvw02.kddia.com (InterScan E-Mail VirusWall NT); Fri, 18 Oct 2002 18:41:55 -0400 Received: from nypc147 (375pc131.ny.kdd.com [192.168.18.131]) by ny.kdd.com (8.9.3/3.7W-0.1) with ESMTP id SAA45608 for ; Fri, 18 Oct 2002 18:41:18 -0400 (EDT) Date: Fri, 18 Oct 2002 18:40:13 -0400 From: Feng Li To: freebsd-net@freebsd.org Subject: Is anyone can help this ? Message-Id: <20021018183544.581C.FENGLI@kddia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.11 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, Friends Could anyone advise me how to configure the Ethernet Card on my PC with speed=100Mbps, duplex=Full parameters ? My PC is running FreeBSD 3.1-Relase, the interface name is fxp0. The config example will be appreciated greatly ! Thanks a lot in advnace ! Feng To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 16:25: 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 67F9937B401 for ; Fri, 18 Oct 2002 16:25:00 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FCF243ECD for ; Fri, 18 Oct 2002 16:24:59 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224]) by pimout3-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9INOvne654452; Fri, 18 Oct 2002 19:24:58 -0400 Received: from localhost (localhost [127.0.0.1]) by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9INOuOQ002264; Fri, 18 Oct 2002 16:24:56 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Fri, 18 Oct 2002 16:24:56 -0700 (PDT) From: Kelly Yancey To: Feng Li Cc: freebsd-net@FreeBSD.ORG Subject: Re: Is anyone can help this ? In-Reply-To: <20021018183544.581C.FENGLI@kddia.com> Message-ID: <20021018162040.K1874-100000@gateway.posi.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 On Fri, 18 Oct 2002, Feng Li wrote: > > Hi, Friends > > Could anyone advise me how to configure the Ethernet > Card on my PC with speed=100Mbps, duplex=Full parameters ? > > My PC is running FreeBSD 3.1-Relase, the interface name > is fxp0. > > The config example will be appreciated greatly ! > > Thanks a lot in advnace ! > I don't remember if it is the same in 3.1, but per `man ifconfig` and `man fxp`: ifconfig fxp0 media 100baseTX mediaopt full-duplex ifconfig fxp0 media 100BaseT mediaopt full-duplex By the way, this sort of question belongs on -questions. Thanks, Kelly -- Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org} Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 18:45: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 D189437B401 for ; Fri, 18 Oct 2002 18:45:22 -0700 (PDT) Received: from web21408.mail.yahoo.com (web21408.mail.yahoo.com [216.136.232.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 6D11043E7B for ; Fri, 18 Oct 2002 18:45:22 -0700 (PDT) (envelope-from zopewiz@yahoo.com) Message-ID: <20021019014522.4446.qmail@web21408.mail.yahoo.com> Received: from [63.170.174.190] by web21408.mail.yahoo.com via HTTP; Fri, 18 Oct 2002 18:45:22 PDT Date: Fri, 18 Oct 2002 18:45:22 -0700 (PDT) From: Carlos Carnero Subject: mpd PPTP server; client gateway 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've succesfully configured mpd as PPTP server for VPNs. But I have one stumbling block: when I connect to the server from a Windows XP client, the new connection gets assigned the same IP address as the default gateway. For instance: Client IP address: 192.168.250.240 Client netmask: 255.255.255.0 Client gateway: 192.168.250.240 the latter _should_ be 192.168.250.1. I can't ping to any other IP addresses inside the VPN. Has any one been there? Best regards, Carlos. __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Oct 18 22:58: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 591F737B401; Fri, 18 Oct 2002 22:58:26 -0700 (PDT) Received: from mail.allcaps.org (h-66-166-142-198.SNDACAGL.covad.net [66.166.142.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD1B43E7B; Fri, 18 Oct 2002 22:58:25 -0700 (PDT) (envelope-from bsder@mail.allcaps.org) Received: by mail.allcaps.org (Postfix, from userid 501) id 785751550C; Fri, 18 Oct 2002 22:58:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id 6C8DA1550B; Fri, 18 Oct 2002 22:58:22 -0700 (PDT) Date: Fri, 18 Oct 2002 22:58:22 -0700 (PDT) From: "Andrew P. Lentvorski" To: "Crist J. Clark" Cc: Matthew Zahorik , Subject: Re: IPSEC/NAT issues In-Reply-To: <20021018182522.GC45449@blossom.cjclark.org> Message-ID: <20021018222132.P68535-100000@mail.allcaps.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 On Fri, 18 Oct 2002, Me, Myself, and I blathered: > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the > packet will get rejected when it reaches the other IPSEC node. I still stand by my original statement. However, it won't be true for much longer. There is now a draft document (as of August 18, 2002) for dealing with NAT traversal. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-02.txt a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header incorporates the IP source and destination addresses in the keyed message integrity check, NAT or reverse NAT devices making changes to address fields will invalidate the message integrity check. Since IPsec ESP [4] does not incorporate the IP source and destination addresses in its keyed message integrity check, this issue does not arise for ESP. b) Incompatibility between checksums and NAT. TCP/UDP/SCTP checksums have a dependency on the IP source and destination addresses through inclusion of the "pseudo-header" in the calculation. As a result, where checksums are calculated and checked on receipt, they will be invalidated by passage through a NAT or reverse NAT device. As a result, IPsec ESP will only pass unimpeded through a NAT if TCP/UDP/SCTP protocols are not involved (as in IPsec tunnel mode or IPsec/GRE), or checksums are not calculated (as is possible with IPv4 UDP) -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Oct 19 16:28:47 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 4034F37B401 for ; Sat, 19 Oct 2002 16:28:46 -0700 (PDT) Received: from carp.icir.org (carp.icir.org [192.150.187.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7CE343E6A for ; Sat, 19 Oct 2002 16:28:45 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: from carp.icir.org (localhost [127.0.0.1]) by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9JNSjpJ099097; Sat, 19 Oct 2002 16:28:45 -0700 (PDT) (envelope-from rizzo@carp.icir.org) Received: (from rizzo@localhost) by carp.icir.org (8.12.3/8.12.3/Submit) id g9JNSjG4099096; Sat, 19 Oct 2002 16:28:45 -0700 (PDT) (envelope-from rizzo) Date: Sat, 19 Oct 2002 16:28:45 -0700 From: Luigi Rizzo To: net@freebsd.org Subject: supported USB-wireless adapters ? Message-ID: <20021019162845.A99077@carp.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.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 as the subject syas, can anyone suggest wireless (802.11b) usb-adapters which are supported by FreeBSD ? thanks luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2988 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message