From owner-freebsd-net Sun Aug 4 19:50: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 E0E8337B400; Sun, 4 Aug 2002 19:50:47 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7278043E42; Sun, 4 Aug 2002 19:50:47 -0700 (PDT) (envelope-from bvagnoni@comcast.net) Disposition-notification-to: bvagnoni@comcast.net Received: from system1 (pcp01324700pcs.pwayne01.pa.comcast.net [68.81.17.19]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with SMTP id <0H0C00FF0NV182@mtaout02.icomcast.net>; Sun, 04 Aug 2002 22:49:50 -0400 (EDT) Date: Sun, 04 Aug 2002 22:49:48 -0400 From: bvagnoni@comcast.net Subject: FW: Trying To Get My Server To Connect To The Net To: "freebsd-questions@FreeBSD. ORG" , freebsd-net@freebsd.org, freebsd-newbies@freebsd.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Dear All; I'm trying to get the server to connect to the internet. There error message I get when I try and ping my gateway is "ping: send to: host is down" In my host file I have the following: host file 127.0.0.1 localhost.mydomain localhost ipaddresofserver mydomain.myhost myhost ipaddresofserver mydomain.myhost host.conf file hosts bind networks file your-net 127. your-network 255.255.255 subnet1 127.0.1 alais1 subnet2 127.0.2 alais2 rc.conf file #I have 2 Ethernet interfaces though I'm not using this machine as a gateway #The fxp0 is an Intel 82559 built in Ethernet controller #The sf0 is an Adaptec 64 bit 66mhz Ethernet controller in a 64 bit 66mhz slot defaultrouter="mygatewayip" ifconfig_fxp0="inet myipaddress netmask 255.255.255.248" ifconfig_sf0="inet myipaddress netmask 255.255.255.248" inetd_enable="YES" kern_securelevel_enable="NO" linux_enable="YES" moused_enable="YES" nfs_reserverd_port_only="YES" portmap_enable="YES" router_enable="YEs" sendmail_enable="YES" sshd_enable="YES" resolve.conf domain mydomain nameserver 207.155.183.72 nameserver 206.173.119.72 nameserver 207.228.252.180 I think that's everything that someone will need to help me fix my problem. Both interfaces are up, and I'm able to ping the ipaddresofserver. Also, the log keeps displaying itself at the console prompt, how do I turn that off, it's very annoying. In other words system messages keep coming up, making it very difficult to keep track of what you are typing at the system prompt. Sincerely Brian PS Thanks In advance 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 Aug 5 15:40: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 9880F37B400 for ; Mon, 5 Aug 2002 15:40:09 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11E6D43E6A for ; Mon, 5 Aug 2002 15:40: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 <20020805224008.OKGF221.sccrmhc02.attbi.com@InterJet.elischer.org> for ; Mon, 5 Aug 2002 22:40: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 PAA66191 for ; Mon, 5 Aug 2002 15:36:35 -0700 (PDT) Date: Mon, 5 Aug 2002 15:36:34 -0700 (PDT) From: Julian Elischer To: net@freebsd.org Subject: ipfw and ipf start times.. 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 I notice that ipf is started very early in rc.network and ipfw is started somewhat later. Specifically ipfw is done after the interfaces are ifconfig'd up and ipf is done before. Does anyone know if there is a specific reason for this? (in 4.x) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 4:25: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 9AB9A37B400 for ; Tue, 6 Aug 2002 04:25:42 -0700 (PDT) Received: from hotmail.com (f268.law9.hotmail.com [64.4.8.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64E4F43E6E for ; Tue, 6 Aug 2002 04:25:42 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Aug 2002 04:25:42 -0700 Received: from 62.217.112.191 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 06 Aug 2002 11:25:42 GMT X-Originating-IP: [62.217.112.191] From: "soheil h" To: freebsd-net@FreeBSD.ORG Date: Tue, 06 Aug 2002 15:55:42 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Aug 2002 11:25:42.0363 (UTC) FILETIME=[FFCAA2B0:01C23D3B] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi list which of these cast is true for accessing the tcphdr outof the 'struct mbuf' in the ip_input function of ip_input.c ? struct mbuf m; struct ip * ip = mtod(m, ip); int iphlen; struct tcpShdr* th; /* it is a copy of the tcphdr struct i made the definition is type at the bottom*/ hlen = IP_VHL_HL(ip->ip_vhl) < 2; 1. th = (struct tcpShdr *)(ip + 1); 2. th = (struct tcpShdr *)((caddr_t)ip + hlen); PLEASE HELP ME I THINK THE SECOND ONE IS TRUE BUT IT DOESN' Work . struct tcpShdr { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcpS_seq th_seq; /* sequence number */ tcpS_seq th_ack; /* acknowledgement number */ u_short th_soheil; u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ }; _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 5: 2:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBA0737B405; Tue, 6 Aug 2002 05:02:38 -0700 (PDT) Received: from hotmail.com (f162.law9.hotmail.com [64.4.9.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 316A243E72; Tue, 6 Aug 2002 05:02:33 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Aug 2002 04:57:18 -0700 Received: from 62.217.112.191 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 06 Aug 2002 11:57:17 GMT X-Originating-IP: [62.217.112.191] From: "soheil h" To: freebsd-net@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Subject: TCP HEADER Date: Tue, 06 Aug 2002 16:27:17 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Aug 2002 11:57:18.0079 (UTC) FILETIME=[69B9F0F0:01C23D40] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi list please ignore my last message it works by option 2 now i want to know if i duplicate the TCP window size in the packets the ip_sum an th_sum will be violated. and if they will be violated how can i solve that _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 11:42: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 A61B537B400; Tue, 6 Aug 2002 11:42:26 -0700 (PDT) Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CA3243E77; Tue, 6 Aug 2002 11:42:26 -0700 (PDT) (envelope-from pavan.balaji@intel.com) Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g76Bicr10696; Tue, 6 Aug 2002 11:44:38 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002080611410813277 ; Tue, 06 Aug 2002 11:41:08 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 11:42:24 -0700 Message-ID: <3D386AED1B47D411A94300508B11F18704AD69A1@fmsmsx116.fm.intel.com> From: "Balaji, Pavan" To: "'soheil h'" , freebsd-net@FreeBSD.ORG Cc: freebsd-questions@FreeBSD.ORG Subject: RE: TCP HEADER Date: Tue, 6 Aug 2002 11:41:58 -0700 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 You cannot add anymore payload at the IP layer. Why don't you duplicate the window size at the TCP layer, that might work. Btw, why on earth would you want to duplicate the window size? Pavan Balaji, Intel Corporation Email: pavan.balaji@intel.com "Only the Paranoid Survive" -- Andy Grove > -----Original Message----- > From: soheil h [mailto:soheil_h_y@hotmail.com] > Sent: Tuesday, August 06, 2002 6:57 AM > To: freebsd-net@FreeBSD.ORG > Cc: freebsd-questions@FreeBSD.ORG > Subject: TCP HEADER > > > > Hi list > > please ignore my last message > it works by option 2 > > now i want to know if i duplicate the TCP window size in the > packets the > ip_sum an th_sum will be violated. > and if they will be violated how can i solve that > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > 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 Tue Aug 6 11:57: 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 17F4D37B400 for ; Tue, 6 Aug 2002 11:57:05 -0700 (PDT) Received: from hotmail.com (f79.law9.hotmail.com [64.4.9.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id C965543E77 for ; Tue, 6 Aug 2002 11:57:04 -0700 (PDT) (envelope-from soheil_h_y@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Aug 2002 11:57:04 -0700 Received: from 80.78.135.8 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 06 Aug 2002 18:57:04 GMT X-Originating-IP: [80.78.135.8] From: "soheil h" To: freebsd-net@FreeBSD.ORG Subject: Re: TCP HEADER Date: Tue, 06 Aug 2002 23:27:04 +0430 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Aug 2002 18:57:04.0651 (UTC) FILETIME=[0E17D5B0:01C23D7B] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi list In any tcp/ip packet pass through my FreeBSD gateway i duplicate the tcp window by changing /usr/src/sys/netinet/ip_input.c . The clients just stay at SYN-SENT state ( the ACK of their SYN ) is not recieved . when i run tcpdump on the gateway it show something like this: time x.x.x.x.p > y.y.y.y.80 : S seq1:seq1(0) win x < options > /in time x.x.x.x.p > y.y.y.y.80 : S seq1:seq1(0) win 2*x /out (no SYN|ACK recieved ) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (just for test when the y.y.y.y is a site that i can access and no packet from x.x.x.x recieved showed by the tcpdump at y.y.y.y;) it shows when the tcp/ip packet pass through me the window size is duplicated . ( no change in any other members ). as stated in Stevens' TCP/IP Illustrated the window size is just for date transition not for the connection stablishment. i think some host between drop my packet but i correct the cksums : in my code ,after the change, the checksums are treated as ip->ip_sum = in_cksum(m, hlen); th stands for the TCP header : len = ip->ip_len; th->th_sum = in_cksum(m, len); but i don't know what is the problem with my algorithm ? Please verify me if the cksum calculation is not true , or any other errors might be occured this is so emergency for me; Please help me! S.H.Y _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 12: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 C4D9C37B401; Tue, 6 Aug 2002 12:30:15 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC6C43E4A; Tue, 6 Aug 2002 12:30:14 -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 g76JUDls091465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 6 Aug 2002 15:30:14 -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 g76JUDed091462; Tue, 6 Aug 2002 15:30:13 -0400 (EDT) (envelope-from wollman) Date: Tue, 6 Aug 2002 15:30:13 -0400 (EDT) From: Garrett Wollman Message-Id: <200208061930.g76JUDed091462@khavrinen.lcs.mit.edu> To: Luigi Rizzo Cc: net@FreeBSD.org Subject: cvs commit: src/sys/net if_ethersubr.c In-Reply-To: <200208042355.g74Nt6lj046576@freefall.freebsd.org> References: <200208042355.g74Nt6lj046576@freefall.freebsd.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Extend the interface to ether_input(): a NULL eh pointer means that > the mbuf contains the ethernet header (eh) as well, which ether_input() > will strip off as needed. The original reason ether_input() worked like it did was that many older interfaces siphoned off the Ethernet header to a separate buffer. I agree that it's long since time to make this change. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 14: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 BE57F37B400 for ; Tue, 6 Aug 2002 14:15:11 -0700 (PDT) Received: from exchange.epx.com (exchange.epx.com [128.121.22.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2786A43E4A for ; Tue, 6 Aug 2002 14:15:11 -0700 (PDT) (envelope-from freebsd@epx.com) Received: from ux340prd.epx.com (ux340prd.epx.com [192.168.12.94]) by ux340prd.epx.com (8.12.3/8.12.3) with ESMTP id g76L3wVQ001150 for ; Tue, 6 Aug 2002 17:03:58 -0400 (EDT) (envelope-from freebsd@epx.com) Content-Type: text/plain; charset="iso-8859-1" From: freebsd Organization: epx.com Subject: SNMP consoles? Date: Tue, 6 Aug 2002 17:03:57 -0400 X-Mailer: KMail [version 1.4] To: net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208061703.57419.freebsd@epx.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 Can anyone tell me if (and the name/source/location if yes) of an snmp console, preferably one that runs under X fro Freebsd? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 14:15: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 96FAE37B405 for ; Tue, 6 Aug 2002 14:15:12 -0700 (PDT) Received: from exchange.epx.com (exchange.epx.com [128.121.22.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA86D43E4A for ; Tue, 6 Aug 2002 14:15:11 -0700 (PDT) (envelope-from freebsd@epx.com) Received: from ux340prd.epx.com (ux340prd.epx.com [192.168.12.94]) by ux340prd.epx.com (8.12.3/8.12.3) with ESMTP id g76JbhIx000759 for ; Tue, 6 Aug 2002 15:37:44 -0400 (EDT) (envelope-from freebsd@epx.com) Content-Type: text/plain; charset="iso-8859-1" From: freebsd Organization: epx.com Subject: SNMP consoles? Date: Tue, 6 Aug 2002 15:37:43 -0400 X-Mailer: KMail [version 1.4] To: net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208061534.27432.freebsd@epx.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 Can anyone tell me if (and the name/source/location if yes) of an snmp console, preferably one that runs under X fro Freebsd? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 14:15: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 58FF937B400 for ; Tue, 6 Aug 2002 14:15:13 -0700 (PDT) Received: from exchange.epx.com (exchange.epx.com [128.121.22.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id C353243E4A for ; Tue, 6 Aug 2002 14:15:12 -0700 (PDT) (envelope-from freebsd@epx.com) Received: from ux340prd.epx.com (ux340prd.epx.com [192.168.12.94]) by ux340prd.epx.com (8.12.3/8.12.3) with ESMTP id g76Ja0Ix000748 for ; Tue, 6 Aug 2002 15:36:01 -0400 (EDT) (envelope-from freebsd@epx.com) Content-Type: text/plain; charset="iso-8859-1" From: freebsd Organization: epx.com Subject: SNMP consoles? Date: Tue, 6 Aug 2002 15:34:27 -0400 X-Mailer: KMail [version 1.4] To: net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200208061534.27432.freebsd@epx.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 Can anyone tell me if (and the name/source/location if yes) of an snmp console, preferably one that runs under X fro Freebsd? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 18:40: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 157D937B400 for ; Tue, 6 Aug 2002 18:40:08 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 911C243E4A for ; Tue, 6 Aug 2002 18:40:07 -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 <20020807014006.BRWJ221.sccrmhc02.attbi.com@InterJet.elischer.org> for ; Wed, 7 Aug 2002 01:40:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA71544 for ; Tue, 6 Aug 2002 18:27:26 -0700 (PDT) Date: Tue, 6 Aug 2002 18:27:25 -0700 (PDT) From: Julian Elischer To: net@freebsd.org Subject: racoon and transport mode... 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 I am probably confused here but is it possible to use IKE via racoon on a tranport mode ipsec connection? how does racoon communicate across the transport connection to set the key if there is no key to start with..? (seems like a catch 22, and I certainly can't make it work here..) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Aug 6 18:49: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 B62EC37B400 for ; Tue, 6 Aug 2002 18:49:47 -0700 (PDT) Received: from bastion.internal.lustygrapes.net (dhcp065-024-083-096.columbus.rr.com [65.24.83.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A37F43E77 for ; Tue, 6 Aug 2002 18:49:47 -0700 (PDT) (envelope-from brianmcd@columbus.rr.com) Received: from nivomede.internal.lustygrapes.net (nivomede.internal.lustygrapes.net [192.168.10.65]) by bastion.internal.lustygrapes.net (Postfix) with ESMTP id 8FA5A5A1B; Tue, 6 Aug 2002 21:49:43 -0400 (EDT) Subject: Re: racoon and transport mode... From: Brian McDonald To: Julian Elischer Cc: net@FreeBSD.ORG In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Aug 2002 21:49:42 -0400 Message-Id: <1028684984.73196.17.camel@nivomede.internal.lustygrapes.net> Mime-Version: 1.0 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 IKE works over UDP port 500, using it's own crypto for authentication of the remote peer. Once they've decided they like each other, they can exchange a key and use the kernel interfaces to install it in the IPSEC stack and allow ESP or AH traffic. Brian On Tue, 2002-08-06 at 21:27, Julian Elischer wrote: > > I am probably confused here but is it > possible to use IKE via racoon on a tranport mode ipsec > connection? > > > how does racoon communicate across the transport connection > to set the key if there is no key to start with..? > > (seems like a catch 22, and I certainly can't make it work here..) > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Brian McDonald CCNA(tm) Certified Tandemedia, Inc. http://www.tandemedia.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Aug 7 0:30: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 B3B6E37B400 for ; Wed, 7 Aug 2002 00:30:50 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D82C43E42 for ; Wed, 7 Aug 2002 00:30:50 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020807073049.PNIF221.sccrmhc02.attbi.com@blossom.cjclark.org>; Wed, 7 Aug 2002 07:30:49 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g777UmJK070520; Wed, 7 Aug 2002 00:30:48 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g777UisF070519; Wed, 7 Aug 2002 00:30:44 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 7 Aug 2002 00:30:43 -0700 From: "Crist J. Clark" To: Julian Elischer Cc: net@FreeBSD.ORG Subject: Re: ipfw and ipf start times.. Message-ID: <20020807073043.GA69787@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Aug 05, 2002 at 03:36:34PM -0700, Julian Elischer wrote: > > > I notice that ipf is started very early in rc.network > and ipfw is started somewhat later. > > Specifically ipfw is done after the interfaces are ifconfig'd up > and ipf is done before. > > Does anyone know if there is a specific reason for this? > (in 4.x) I'm not sure if there is any reason, but historically, ipfw(8) has defaulted to being closed when not configured and ipf(8) to being open. This is seen in the kernel configuration options, options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPFILTER_DEFAULT_BLOCK #block all packets by default The defaults are the opposite. Thus, from a security standpoint you want to configure ipf(8) before you setup the interfaces, while ipfw(8) can wait. -- 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 Wed Aug 7 12:43: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 DAF8437B400 for ; Wed, 7 Aug 2002 12:43:17 -0700 (PDT) Received: from mail.dada.it (mail3.dada.it [195.110.100.3]) by mx1.FreeBSD.org (Postfix) with SMTP id D5BDF43E3B for ; Wed, 7 Aug 2002 12:43:11 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 10908 invoked from network); 7 Aug 2002 19:43:03 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 7 Aug 2002 19:43:03 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id 4330C5FA7; Wed, 7 Aug 2002 21:43:04 +0200 (CEST) Date: Wed, 7 Aug 2002 21:43:04 +0200 From: Alessandro de Manzano To: net@freebsd.org Subject: MPD with WinXP clients Message-ID: <20020807214304.A67338@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.6-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 Hi! I'm experiencing a strange problem with mpd 3.8. I've installed it on a FreeBSD 4.6-p1 box as a pptp MS compatible server to allow Windows clients to connect to our internal LAN. Connection and authentication seems ok, but when I do some "big" transfer the session locks. Client is a WinXP Pro machine. (I'll try also with a W2K and W98 boxes a.s.a.p.) Example, using WinXP's telnet client I successfully telnet into the above FreeBSD, but if I do "ls" into a "big" directory, or a simple "ps ax" or "top" the telnet session hangs. It works if I do a "w" or "ls" into short directories. I guess is not a telnet client issue since I tried also with PuTTY and Telnet98 and both have the problem. Interface ng0 on server reports a MTU of 1498 but I think this problem is symptom of a MTU/MRU discrepancy problem... If I connect to the server from another FreeBSD with "pptpclient" it works fine. Is this a FAQ ? Have someone an hint ? much-detailed mpd log file available on request ;) Hoping in your kind answer :-) Many many 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 Wed Aug 7 19:30: 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 0238A37B400 for ; Wed, 7 Aug 2002 19:30:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62B4743E4A for ; Wed, 7 Aug 2002 19:30:02 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id TAA91476; Wed, 7 Aug 2002 19:29:44 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g782S2o00502; Wed, 7 Aug 2002 19:28:02 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208080228.g782S2o00502@arch20m.dellroad.org> Subject: Re: MPD with WinXP clients In-Reply-To: <20020807214304.A67338@libero.sunshine.ale> "from Alessandro de Manzano at Aug 7, 2002 09:43:04 pm" To: Alessandro de Manzano Date: Wed, 7 Aug 2002 19:28:02 -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 Alessandro de Manzano writes: > I've installed it on a FreeBSD 4.6-p1 box as a pptp MS compatible > server to allow Windows clients to connect to our internal LAN. > > Connection and authentication seems ok, but when I do some "big" > transfer the session locks. Sounds like an MTU problem.. try lowering the MTU on ng0 manually (e.g., "ifconfig ng0 mtu 1440") and or installing the tcp MSS fixup program (can't remember the name). -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 Aug 7 20:51: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 7AA6937B405 for ; Wed, 7 Aug 2002 20:51:28 -0700 (PDT) Received: from patrocles.silby.com (d110.as15.nwbl0.wi.voyager.net [169.207.134.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D95E43E6E for ; Wed, 7 Aug 2002 20:47:01 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.5/8.12.5) with ESMTP id g783oCB1049776; Wed, 7 Aug 2002 22:50:13 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g783oAfs049773; Wed, 7 Aug 2002 22:50:12 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Wed, 7 Aug 2002 22:50:07 -0500 (CDT) From: Mike Silbersack To: freebsd-current@freebsd.org, Subject: [patch] Possible newreno fix, please test Message-ID: <20020807224520.U47882-200000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1841789917-1028778607=:47882" 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-1841789917-1028778607=:47882 Content-Type: TEXT/PLAIN; charset=US-ASCII If you are one of the people who have found that disabling newreno increases performance on your network, please apply this patch and see if newreno performance increases. The attached patch comes from an obscurely documented change applied to OpenBSD back in 2000, originating from one of the people responsible for the original BSD newreno implementation. As far as I can tell, it fixes the handling of multiple fast retransmits, and inflates the window less upon completion of fast recovery. I haven't done any actual testing myself, but it sure looks like a step in the right direction. Please test if you had noticed newreno problems in the past. Thanks, Mike "Silby" Silbersack --0-1841789917-1028778607=:47882 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="newrenofix.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20020807225007.U47882@patrocles.silby.com> Content-Description: Content-Disposition: attachment; filename="newrenofix.patch" LS0tIC91c3Ivc3JjL3N5cy5vbGQvbmV0aW5ldC90Y3BfaW5wdXQuYwlXZWQg QXVnICA3IDIyOjU2OjI2IDIwMDINCisrKyB0Y3BfaW5wdXQuYwlXZWQgQXVn ICA3IDIzOjAzOjM4IDIwMDINCkBAIC0xNjYyLDkgKzE2NjIsNyBAQA0KIAkJ CQkJCS8qIEZhbHNlIHJldHJhbnNtaXQsIHNob3VsZCBub3QNCiAJCQkJCQkg KiBjdXQgd2luZG93DQogCQkJCQkJICovDQotCQkJCQkJdHAtPnNuZF9jd25k ICs9IHRwLT50X21heHNlZzsNCiAJCQkJCQl0cC0+dF9kdXBhY2tzID0gMDsN Ci0JCQkJCQkodm9pZCkgdGNwX291dHB1dCh0cCk7DQogCQkJCQkJZ290byBk cm9wOw0KIAkJCQkJfQ0KIAkJCQkJaWYgKHdpbiA8IDIpDQpAQCAtMTcwOCw4 ICsxNzA2LDcgQEANCiAgICAgICAgICAgICAgICAgICAgICAgICAgKiBpdCB2 aWEgdGhlIHNsb3cgc3RhcnQgbWVjaGFuaXNtLg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAqLw0KIAkJCWlmIChTRVFfR1QodGgtPnRoX2FjayArIHRw LT5zbmRfc3N0aHJlc2gsIHRwLT5zbmRfbWF4KSkNCi0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRwLT5zbmRfY3duZCA9DQotCQkJCSAgICB0 cC0+c25kX21heCAtIHRoLT50aF9hY2sgKyB0cC0+dF9tYXhzZWc7DQorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0cC0+c25kX2N3bmQgPSB0 cC0+c25kX21heCAtIHRoLT50aF9hY2s7DQogCQkJZWxzZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgIAl0cC0+c25kX2N3bmQgPSB0cC0+c25kX3NzdGhy ZXNoOw0KICAgICAgICAgICAgICAgICAgICAgICAgIHRwLT50X2R1cGFja3Mg PSAwOw0K --0-1841789917-1028778607=:47882-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 8 7:43: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DF2437B400 for ; Thu, 8 Aug 2002 07:43:05 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51A9F43E4A for ; Thu, 8 Aug 2002 07:43:04 -0700 (PDT) (envelope-from thomas.r.henderson@boeing.com) Received: from stl-av-02.boeing.com ([192.76.190.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA03944 for ; Thu, 8 Aug 2002 07:42:59 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA13597 for ; Thu, 8 Aug 2002 09:42:41 -0500 (CDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g78Egvm09209 for ; Thu, 8 Aug 2002 07:42:57 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Aug 2002 07:42:20 -0700 Message-ID: <00EBC850E752CC46B8509DAB4D0D2CB910691A@xch-nw-29.nw.nos.boeing.com> From: "Henderson, Thomas R" To: freebsd-net@freebsd.org Subject: RE: [patch] Possible newreno fix, please test Date: Thu, 8 Aug 2002 07:42:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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'm curious to the motivation behind this patch. What have people experienced that this patch corrects? The first fix appears to disable the artificial window inflation that occurs during the recovery period-- intended to keep data flowing in the pipe so ack clocking doesn't break down. The second fix should not have much of an impact (difference of one segment in cwnd when you leave fast recovery)-- but does have a possible side effect of leaving you with a cwnd of zero. Tom > -----Original Message----- > From: Mike Silbersack [mailto:silby@silby.com] > Sent: Wednesday, August 07, 2002 8:50 PM > To: freebsd-current@freebsd.org; freebsd-net@freebsd.org > Subject: [patch] Possible newreno fix, please test > > > > If you are one of the people who have found that disabling newreno > increases performance on your network, please apply this > patch and see if > newreno performance increases. > > The attached patch comes from an obscurely documented change > applied to > OpenBSD back in 2000, originating from one of the people > responsible for > the original BSD newreno implementation. As far as I can > tell, it fixes > the handling of multiple fast retransmits, and inflates the > window less > upon completion of fast recovery. I haven't done any actual testing > myself, but it sure looks like a step in the right direction. > > Please test if you had noticed newreno problems in the past. > > Thanks, > > 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 Thu Aug 8 8: 9: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 CE5D237B400 for ; Thu, 8 Aug 2002 08:09:42 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBBAD43E88 for ; Thu, 8 Aug 2002 08:09:41 -0700 (PDT) (envelope-from maillists@euteneuer.com) Received: from [212.227.126.155] (helo=mrelayng1.kundenserver.de) by moutng6.kundenserver.de with esmtp (Exim 3.35 #2) id 17couy-00089V-00 for freebsd-net@freebsd.org; Thu, 08 Aug 2002 17:09:40 +0200 Received: from [80.133.11.63] (helo=amd2000xp) by mrelayng1.kundenserver.de with asmtp (Exim 3.35 #2) id 17couy-00030L-00 for freebsd-net@FreeBSD.ORG; Thu, 08 Aug 2002 17:09:40 +0200 From: "Sven Euteneuer" To: Subject: PPTP connections breaking down Date: Thu, 8 Aug 2002 17:09:37 +0200 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.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 Hi guys, it looks like I have an issue with the way PPP/PPTP is implemented in FreeBSD 4.6. I'm using an old Cyrix166 box to serve as a tunnel gateway for WLAN devices to our standard 100BaseTx Ethernet LAN. The box has run a very similar configuration under Linux 2.4.4 (the SuSE variety) before without any issues, but after converting it to FreeBSD, PPTP tunnels into the LAN (e.g. to get a file from an SMB server) break down after a small amount of data has been transferred (~4-6MB). The logs suggest that client and gateway completely lose sync (see below for a short excerpt of the logs). The tunnel stays open after both sides have lost sync until LQM detects the problem and closes the connection, but no packet makes it thru from either side. I've tried the PoPToP daemon v1.1.2 from the ports collection (which I've used under Linux as well), as well as the mpd daemon v3.8 & netgraph to serve as PPTP entry points, but both exhibit the exact same behavior. The PPTP clients are usually running Windows 2000 and Belkin 802.11b cards and connect to the PPTP server using the standard Windows RAS PPTP client. Connection and authentication work like a charm and both sides negotiate MSCHAPv2 for authentication and MPPE128 stateless for compression&encryption. Thru trial and error I was able to track down the problem to somewhere between the WLAN card & the PPP daemon. However, since the WLAN cards have worked with the Linux incarnation of the gateway I'm tempted to believe that the issue *might* (I've no reason to believe that this is actually true) be with the PPP userland implementation. Any insight from someone more knowledgeable than me? Thanks, Sven --- /var/log/messages: Aug 6 18:11:32 router1 ppp[235]: tun1: Warning: deflink: Reducing configured MRU from 1500 to 1492 Aug 6 18:11:32 router1 pptpd[234]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! Aug 6 18:12:00 router1 ppp[235]: tun1: Error: MPPE: Input: Invalid packet (flags = 0x3000) Aug 6 18:12:07 router1 pptpd[234]: GRE: Bad packet flags 30 ver 81 proto 8800 Aug 6 18:12:38 router1 pptpd[234]: Discarding out-of-order packet 4467, already have 12340 Aug 6 18:12:38 router1 pptpd[234]: Discarding out-of-order packet 4468, already have 12340 Aug 6 18:12:38 router1 pptpd[234]: Discarding out-of-order packet 4469, already have 12340 ... Aug 6 18:13:04 router1 pptpd[234]: EOF reading from pppd /var/log/ppp.log: Aug 6 18:11:36 router1 ppp[235]: tun1: LCP: Reducing MTU from 1492 to 1490 (CCP requirement) Aug 6 18:11:36 router1 ppp[235]: tun1: ID0: 0 = ioctl(7, 2148037723, 0xbfbfefb8) Aug 6 18:11:36 router1 ppp[235]: tun1: ID0: 1 = socket(17, 3, 0) Aug 6 18:11:36 router1 ppp[235]: tun1: ID0: 108 = write(1, data, 108) Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query IN SOA inspiron8000.xxxxxx.xxx. Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query IN A router1..xxxxxx.xxx. Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query <0x97 <0xc0 .xxxxxx.xxx... Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query IN SOA 0.168.192.in-addr.arpa. Aug 6 18:11:36 router1 ppp[235]: tun1: DNS: INbound query <0x65 <0x26 0.168.192.in-addr.arpa... Aug 6 18:11:37 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(1) state = Opened Aug 6 18:11:42 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(1) state = Opened Aug 6 18:11:43 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(2) state = Opened Aug 6 18:11:43 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(2) state = Opened Aug 6 18:11:48 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(3) state = Opened Aug 6 18:11:48 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(3) state = Opened Aug 6 18:11:48 router1 ppp[235]: tun1: DNS: INbound query IN A amd2000xp.xxxx.xxx. Aug 6 18:11:53 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(4) state = Opened Aug 6 18:11:53 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(4) state = Opened Aug 6 18:11:58 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(5) state = Opened Aug 6 18:11:58 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(5) state = Opened Aug 6 18:12:00 router1 ppp[235]: tun1: Error: MPPE: Input: Invalid packet (flags = 0x3000) Aug 6 18:12:03 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(6) state = Opened Aug 6 18:12:03 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(6) state = Opened Aug 6 18:12:07 router1 ppp[235]: tun1: Phase: Unknown protocol 0x0068 (unrecognised protocol) ... Aug 6 18:12:34 router1 ppp[235]: tun1: Phase: deflink: HDLC errors -> FCS: 0, ADDR: 0, COMD: 0, PROTO: 1 Aug 6 18:12:34 router1 ppp[235]: tun1: LCP: deflink: SendEchoRequest(12) state = Opened Aug 6 18:12:34 router1 ppp[235]: tun1: LCP: deflink: RecvEchoReply(12) state = Opened Aug 6 18:12:38 router1 ppp[235]: tun1: Phase: Unknown protocol 0x3434 (unrecognised protocol) ... Aug 6 18:13:04 router1 ppp[235]: tun1: Phase: deflink: ** Too many ECHO LQR packets lost ** Aug 6 18:13:04 router1 ppp[235]: tun1: LQM: deflink: Too many ECHO LQR packets lost Aug 6 18:13:04 router1 ppp[235]: tun1: CCP: deflink: LayerDown. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 8 15:33: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 43C8537B400 for ; Thu, 8 Aug 2002 15:33:41 -0700 (PDT) Received: from patrocles.silby.com (d110.as14.nwbl0.wi.voyager.net [169.207.134.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id F326043E6E for ; Thu, 8 Aug 2002 15:33:39 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.5/8.12.5) with ESMTP id g78MavB1053647; Thu, 8 Aug 2002 17:36:57 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g78Mas1U053644; Thu, 8 Aug 2002 17:36:55 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 8 Aug 2002 17:36:54 -0500 (CDT) From: Mike Silbersack To: "Henderson, Thomas R" Cc: freebsd-net@freebsd.org Subject: RE: [patch] Possible newreno fix, please test In-Reply-To: <00EBC850E752CC46B8509DAB4D0D2CB910691A@xch-nw-29.nw.nos.boeing.com> Message-ID: <20020808173357.N52867-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 Thu, 8 Aug 2002, Henderson, Thomas R wrote: > I'm curious to the motivation behind this patch. What have people > experienced that this patch corrects? > > The first fix appears to disable the artificial window inflation > that occurs during the recovery period-- intended to keep data > flowing in the pipe so ack clocking doesn't break down. > > The second fix should not have much of an impact (difference > of one segment in cwnd when you leave fast recovery)-- but > does have a possible side effect of leaving you with a cwnd > of zero. > > Tom Ruh roh, now I'm confused. From the comment at this url: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c?rev=1.69&content-type=text/x-cvsweb-markup&cvsroot=openbsd&f=h I assumed that you submitted the newreno parts, but I guess that was _not_ the case. Were your fixes more related to SACK/FACK? 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 Thu Aug 8 16: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 3493D37B400 for ; Thu, 8 Aug 2002 16:18:23 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id C020443E6E for ; Thu, 8 Aug 2002 16:18:22 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (hrtgypdzzokhxdfr@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g78NIMr24948; Thu, 8 Aug 2002 16:18:22 -0700 (PDT) Message-ID: <3D52FC3D.9010904@isi.edu> Date: Thu, 08 Aug 2002 16:18:21 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: freebsd-net@freebsd.org, snap-users@kame.net Subject: IPv6, hostap and bridging Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090505000602060400000101" 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. --------------ms090505000602060400000101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm configuring a hostap-based FreeBSD-4.6-RELEASE access point, bridging together wi0 and sis1 interfaces (using Luigi's bridge code, not netgraph). IPv4 connectivity works great, kudos all around! IPv6 is a different matter. Router solicitation works, i.e. the AP (it's also a real router) announces itself and hands out IPv6 addresses over the wireless link. However, connectivity is broken. Using the canonical "ping6 www.kame.net" on the client makes it send out neighbor solicitations for the router address over the wireless link, and they arrive on wi0 on the router/AP: 16:15:56.407151 3ffe:825:27:0:202:2dff:fe5e:870c > ff02::1:ffc0:3edd: icmp6: neighbor sol: who has fe80::200:24ff:fec0:3edd but the router/AP doesn't generate replies to the client, it bridges the message and sends them out via sis1: 16:15:56.407238 3ffe:825:27:0:202:2dff:fe5e:870c > ff02::1:ffc0:3edd: icmp6: neighbor sol: who has fe80::200:24ff:fec0:3edd However, the router *is* fe80::200:24ff:fec0:3edd%sis1! Any clues on how to make it do the right thing? Thanks, Lars -- Lars Eggert USC Information Sciences Institute --------------ms090505000602060400000101 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgwODIzMTgyMVowIwYJKoZIhvcNAQkEMRYEFOelt2o92O/s 9tmZsNQzG5xeoun4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYAWBCY4UPiCBOq0OvLi3Ox5EWLtChzJSZJZ3jlG8gZkCKdg PTVeaJX6O1WQeokQ0ucoZafRUNUiF1OpbnAkKuunyEnDK10s+UOyGnqYgXuR6PfUxrqr7Vj2 7k18hAr7Mv1+5Se3l5zOjU6b2WQlpL/nmHp2MjKESksTn2KmWWx56gAAAAAAAA== --------------ms090505000602060400000101-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 8 16:33: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 AC36037B400 for ; Thu, 8 Aug 2002 16:33:54 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id E97E743E5E for ; Thu, 8 Aug 2002 16:33:53 -0700 (PDT) (envelope-from thomas.r.henderson@boeing.com) Received: from slb-av-02.boeing.com ([129.172.13.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id QAA07080; Thu, 8 Aug 2002 16:33:51 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id QAA14119; Thu, 8 Aug 2002 16:33:50 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g78NXnm23985; Thu, 8 Aug 2002 16:33:49 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Aug 2002 16:33:50 -0700 Message-ID: <00EBC850E752CC46B8509DAB4D0D2CB910692C@xch-nw-29.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "'Mike Silbersack'" Cc: "'freebsd-net@freebsd.org'" Subject: RE: [patch] Possible newreno fix, please test Date: Thu, 8 Aug 2002 16:33:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 > > Ruh roh, now I'm confused. From the comment at this url: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_inpu t.c?rev=1.69&content-type=text/x-cvsweb-markup&cvsroot=openbsd&f=h > > I assumed that you submitted the newreno parts, but I guess that was _not_ > the case. Were your fixes more related to SACK/FACK? > > Mike "Silby" Silbersack A couple of years ago I helped Niels Provos port our Berkeley Daedalus project SACK/FACK/NewReno code (for BSDi) to OpenBSD. I did contribute the newreno piece originally to the Berkeley code. (ftp://daedalus.cs.berkeley.edu/pub/tcpsack/bsdi-3.0) Someone ported that newreno code into freebsd (looks like 1.107.2.6 on tcp_input.c-- jlemon) but not the sack code. My question was due to the fact that the proposed patch diverged from the NewReno RFC and Berkeley code-- I was curious to find out why and what problems people found to motivate that patch. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Aug 8 17: 7: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 4DAB237B400 for ; Thu, 8 Aug 2002 17:07:41 -0700 (PDT) Received: from patrocles.silby.com (d110.as14.nwbl0.wi.voyager.net [169.207.134.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92CF343E86 for ; Thu, 8 Aug 2002 17:07:39 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.5/8.12.5) with ESMTP id g790AvB1053965; Thu, 8 Aug 2002 19:10:57 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g790Auqw053962; Thu, 8 Aug 2002 19:10:56 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 8 Aug 2002 19:10:56 -0500 (CDT) From: Mike Silbersack To: "Henderson, Thomas R" Cc: "'freebsd-net@freebsd.org'" Subject: RE: [patch] Possible newreno fix, please test In-Reply-To: <00EBC850E752CC46B8509DAB4D0D2CB910692C@xch-nw-29.nw.nos.boeing.com> Message-ID: <20020808185959.Q52867-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 Thu, 8 Aug 2002, Henderson, Thomas R wrote: > A couple of years ago I helped Niels Provos port our Berkeley Daedalus > project SACK/FACK/NewReno code (for BSDi) to OpenBSD. I did contribute the > newreno piece originally to the Berkeley code. > (ftp://daedalus.cs.berkeley.edu/pub/tcpsack/bsdi-3.0) Someone ported that > newreno code into freebsd (looks like 1.107.2.6 on tcp_input.c-- jlemon) but > not the sack code. I understand that. However, you're one of the attributed people in the OpenBSD commit message which is apparently of a later vintage. I'm curious what was submitted as part of that change. > My question was due to the fact that the proposed patch diverged from the > NewReno RFC and Berkeley code-- I was curious to find out why and what > problems people found to motivate that patch. > > Tom There have been a few solid reports of newreno actually decreasing performance greatly in some network environments. Matt Dillon helped reduce this somewhat by removing the maxburst limit, but some other gremlins still seem to inhabit the newreno code. I posted this patch because I found it in the OpenBSD repository, with your name among those credited for the changes. I was unable to find any messages on openbsd mailing lists talking about the patch in question, so I'm short on information here. Personally, I don't believe that the code in question was correct in the first place. Isn't the congestion window supposed to be increased for every dupack received, not just every third? In short, I'm not sure that the patch is entirely correct, but I wanted to see if it provided any noticeable improvements for those who had complained of poor performance in the past. Unfortunately, none of those people have responded 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 Thu Aug 8 17:40: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 E82D837B400 for ; Thu, 8 Aug 2002 17:40:40 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E40F43E65 for ; Thu, 8 Aug 2002 17:40:40 -0700 (PDT) (envelope-from thomas.r.henderson@boeing.com) Received: from slb-av-02.boeing.com ([129.172.13.7]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA26919; Thu, 8 Aug 2002 17:40:38 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id RAA22086; Thu, 8 Aug 2002 17:40:37 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g790eam18833; Thu, 8 Aug 2002 17:40:36 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Aug 2002 17:40:38 -0700 Message-ID: <00EBC850E752CC46B8509DAB4D0D2CB910692D@xch-nw-29.nw.nos.boeing.com> From: "Henderson, Thomas R" To: "'Mike Silbersack'" Cc: "'freebsd-net@freebsd.org'" Subject: RE: [patch] Possible newreno fix, please test Date: Thu, 8 Aug 2002 17:40:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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 > Personally, I don't believe that the code in question was > correct in the > first place. Isn't the congestion window supposed to be increased for > every dupack received, not just every third? > I agree-- but it seems to me that the problem line in there is t_dupacks = 0; which causes two possible problems i) cwnd incremented for every third dupack ii) (more serious) you never do the window deflation in certain loss scenarios, because your dupack counter doesn't indicate that you were previously in fast retransmission. I wonder if the patch should be instead: +++ tcp_input.c Wed Aug 7 23:03:38 2002 @@ -1662,9 +1662,7 @@ /* False retransmit, should not * cut window */ tp->snd_cwnd += tp->t_maxseg; - tp->t_dupacks = 0; (void) tcp_output(tp); goto drop; } if (win < 2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 10:20: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 E3E7337B400 for ; Fri, 9 Aug 2002 10:20:31 -0700 (PDT) Received: from www.opentrade.cl (50-126-141.leased.cust.tie.cl [200.50.126.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B2AF43E6E for ; Fri, 9 Aug 2002 10:20:30 -0700 (PDT) (envelope-from jseverino@fritz.cl) Received: from pc ([192.168.1.10]) by www.opentrade.cl (8.12.2/8.12.2) with SMTP id g79HNTQU012272 for ; Fri, 9 Aug 2002 10:23:30 -0700 (PDT) Message-ID: <005301c23fc9$76d2d460$0a01a8c0@opentrade.cl> Reply-To: "Jorge Severino Diaz" From: "Jorge Severino Diaz" To: References: Subject: unsubscribe Date: Fri, 9 Aug 2002 13:23:22 -0400 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 unsubscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 12:15: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 AAF8937B400; Fri, 9 Aug 2002 12:15:19 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2327543E4A; Fri, 9 Aug 2002 12:15:19 -0700 (PDT) (envelope-from Qing.Li@windriver.com) Received: from heavygear (qing3.isi.com [192.103.54.234]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA16843; Fri, 9 Aug 2002 12:15:08 -0700 (PDT) From: "Qing Li" To: "FreeBSD Net" , "FreeBSD Hackers" Subject: problems with "route add -host" Date: Fri, 9 Aug 2002 12:14:21 -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.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 My interface xl0 is assigned 147.11.38.218. ========== Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 147.11.38.1 UGSc 4 0 xl0 127.0.0.1 127.0.0.1 UH 1 22 lo0 147.11.38/24 link#5 UC 2 0 xl0 147.11.38.1 00:00:0c:07:ac:26 UHLW 5 0 xl0 783 147.11.38.15 147.11.38.218 UGHS 0 3 xl0 147.11.38.218 127.0.0.1 UGHS 1 0 lo0 147.11.38.254 00:02:7e:23:fa:80 UHLW 0 0 xl0 49 ========== Now I add a host route: "route add -host 147.11.38.15 147.11.38.218" Then ping> "ping 147.11.38.15" fails. This is due to the "G" flag in that static route entry. This route addition should be allowed as a place holder to be filled in later, similar to of an entry with RTF_LLINFO flag. I put in the fixes, here is what the routing table shows after the fix using the same route command, =========== 147.11.38.15 link#5 UHLS 0 3 xl0 =========== "ping 147.11.38.15" now succeeds, that route entry is modified to be =========== 147.11.38.15 8:0:20:d1:64:c6 UHLS 0 3 xl0 =========== This problem exists for IPv6, too. But the fix there is slightly different than the v4 fix. Unlike "ping", "ping6" returns -1 with an error message of "No route to host". I am ready to submit a couple of bug reports with my fixes. I'd like to know if anyone had any comments. My version is: FreeBSD 4.6 compiled on June 17, 2002. -- Qing To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 12:16: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 4A90237B400; Fri, 9 Aug 2002 12:16:27 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 658E343E65; Fri, 9 Aug 2002 12:16:26 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g79JGS888200; Fri, 9 Aug 2002 15:16:28 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 9 Aug 2002 15:16:27 -0400 From: Bosko Milekic To: gallatin@freebsd.org, ken@freebsd.org Cc: freebsd-net@freebsd.org Subject: Jumbo Clusters in mb_alloc Message-ID: <20020809151627.A88180@unixdaemons.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" 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 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi guys, Can you put this (the attached) to use? It's the implementation of jumbo clusters within mb_alloc, as discussed on -net not too long ago. I have not written the allocation interface yet as I would like to know if you could put them to use in some of the drivers, and also what you would need from the interface. On a parallel note, I've been thinking about [not now, but eventually] moving the virtual address "sf_buf" allocations to mb_alloc. I have an idea of how to do this easily but have not bothered yet because -CURRENT is still largely under Giant and I cannot accurately measure potential performance benefits yet. I've been thinking the same about the uipc_jumbo stuff, because they look a lot like sf_bufs. The trick would be to set map_starved for their address space map in mb_alloc to 1 and then mb_alloc would think that the map is "starved" and never try to kmem_malloc() from it (in fact, it doesn't even have to be a "map," it just has to be some sort of pre-allocated space, for example, with kmem_alloc_pageable()). Then, mb_alloc would populate the per-CPU caches and the general cache with the virtual address PAGE_SIZE "buffers" (they have no ptes in pmap so they're not really "buffers" as they don't have physical memory associated with them at this point). Anyway, I think this would work but am delaying it until a while after 5.0, when I can really measure stuff on SMP. Anyway, see the attached patch and let me know if this is useful to you. Thanks! Cheers, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="jumbo.diff" Index: src/sys/conf/NOTES =================================================================== RCS file: /home/ncvs/src/sys/conf/NOTES,v retrieving revision 1.1061 diff -u -r1.1061 NOTES --- src/sys/conf/NOTES 9 Aug 2002 15:30:47 -0000 1.1061 +++ src/sys/conf/NOTES 9 Aug 2002 19:05:39 -0000 @@ -2252,6 +2252,7 @@ options NBUF=512 # Number of buffer headers options NMBCLUSTERS=1024 # Number of mbuf clusters +options NMBJUMBOBUFS=128 # Number of jumbo clusters options SCSI_NCR_DEBUG options SCSI_NCR_MAX_SYNC=10000 Index: src/sys/conf/options =================================================================== RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.341 diff -u -r1.341 options --- src/sys/conf/options 3 Aug 2002 00:19:58 -0000 1.341 +++ src/sys/conf/options 9 Aug 2002 19:05:45 -0000 @@ -197,6 +197,7 @@ MAXFILES opt_param.h NBUF opt_param.h NMBCLUSTERS opt_param.h +NMBJUMBOBUFS opt_param.h NSFBUFS opt_param.h VM_BCACHE_SIZE_MAX opt_param.h VM_SWZONE_SIZE_MAX opt_param.h Index: src/sys/kern/kern_malloc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v retrieving revision 1.111 diff -u -r1.111 kern_malloc.c --- src/sys/kern/kern_malloc.c 31 May 2002 09:41:09 -0000 1.111 +++ src/sys/kern/kern_malloc.c 9 Aug 2002 19:05:52 -0000 @@ -335,6 +335,7 @@ u_long mem_size; void *hashmem; u_long hashsize; + u_int mb_size; int highbit; int bits; int i; @@ -385,9 +386,12 @@ * amount to slightly more address space than we need for the submaps, * but it never hurts to have an extra page in kmem_map. */ - npg = (nmbufs * MSIZE + nmbclusters * MCLBYTES + nmbcnt * - sizeof(u_int) + vm_kmem_size) / PAGE_SIZE; - + mb_size = nmbufs * MSIZE + nmbclusters * MCLBYTES + nmbcnt * + sizeof(u_int); +#ifdef NMBJUMBOBUFS + mb_size += nmbjumbobufs * MJUMBOSIZE; +#endif + npg = (mb_size + vm_kmem_size) / PAGE_SIZE; kmem_map = kmem_suballoc(kernel_map, (vm_offset_t *)&kmembase, (vm_offset_t *)&kmemlimit, (vm_size_t)(npg * PAGE_SIZE)); kmem_map->system_map = 1; Index: src/sys/kern/subr_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_mbuf.c,v retrieving revision 1.29 diff -u -r1.29 subr_mbuf.c --- src/sys/kern/subr_mbuf.c 8 Aug 2002 13:31:57 -0000 1.29 +++ src/sys/kern/subr_mbuf.c 9 Aug 2002 19:05:59 -0000 @@ -151,6 +151,9 @@ int nmbclusters; int nmbcnt; int nsfbufs; +#ifdef NMBJUMBOBUFS +int nmbjumbobufs; +#endif /* * Perform sanity checks of tunables declared above. @@ -170,6 +173,10 @@ TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); nmbcnt = NMBCNTS; TUNABLE_INT_FETCH("kern.ipc.nmbcnt", &nmbcnt); +#ifdef NMBJUMBOBUFS + nmbjumbobufs = NMBJUMBOBUFS; + TUNABLE_INT_FETCH("kern.ipc.nmbjumbobufs", &nmbjumbobufs); +#endif /* Sanity checks */ if (nmbufs < nmbclusters * 2) nmbufs = nmbclusters * 2; @@ -197,11 +204,15 @@ vm_offset_t ml_maptop; int ml_mapfull; u_int ml_objsize; + u_int ml_bucksize; u_int *ml_wmhigh; }; static struct mb_lstmngr mb_list_mbuf, mb_list_clust; static struct mtx mbuf_gen, mbuf_pcpu[NCPU]; u_int *cl_refcntmap; +#ifdef NMBJUMBOBUFS +static struct mb_lstmngr mb_list_jumbo; +#endif /* * Local macros for internal allocator structure manipulations. @@ -221,8 +232,8 @@ #define MB_GET_PCPU_LIST_NUM(mb_lst, num) \ (mb_lst)->ml_cntlst[(num)] -#define MB_BUCKET_INDX(mb_obj, mb_lst) \ - (int)(((caddr_t)(mb_obj) - (caddr_t)(mb_lst)->ml_mapbase) / PAGE_SIZE) +#define MB_BUCKET_INDX(mb_obj, mb_lst, mb_div) \ + (int)(((caddr_t)(mb_obj) - (caddr_t)(mb_lst)->ml_mapbase) / (mb_div)) #define MB_GET_OBJECT(mb_objp, mb_bckt, mb_lst) \ { \ @@ -271,6 +282,9 @@ static u_int mbuf_limit = 512; /* Upper limit on # of mbufs per CPU. */ static u_int clust_limit = 128; /* Upper limit on # of clusters per CPU. */ +#ifdef NMBJUMBOBUFS +static u_int jumbo_limit = 32; /* Upper limit on # of jumboclusts per CPU. */ +#endif /* * Objects exported by sysctl(8). @@ -294,6 +308,12 @@ "Mbuf general information and statistics"); SYSCTL_OPAQUE(_kern_ipc, OID_AUTO, mb_statpcpu, CTLFLAG_RD, mb_statpcpu, sizeof(mb_statpcpu), "S,", "Mbuf allocator per CPU statistics"); +#ifdef NMBJUMBOBUFS +SYSCTL_INT(_kern_ipc, OID_AUTO, nmbjumbobufs, CTLFLAG_RD, &nmbjumbobufs, 0, + "Maximum number of jumbo clusters available"); +SYSCTL_UINT(_kern_ipc, OID_AUTO, jumbo_limit, CTLFLAG_RW, &jumbo_limit, 0, + "Upper limit on number of jumbo clusters allowed on each PCPU list"); +#endif /* * Prototypes of local allocator routines. @@ -311,6 +331,32 @@ */ #define NMB_MBUF_INIT 4 #define NMB_CLUST_INIT 16 +#ifdef NMBJUMBOBUFS +#define NMB_JUMBO_INIT 1 + +/* + * Do not change this unless you know EXACTLY what you're doing. This is + * the pre-calculated number of pages of jumbo clusters to allocate per + * "bucket." Here's how it works: + * + * - MJUMBOSIZE is a constant, and we picked it to be 9216 bytes. This should + * be enough to accomodate large 9K frames, and a reference counter for them. + * - 'n' is the number of jumbo clusters per bucket. + * + * For minimum space wastage to occur, we need: + * (MJUMBOSIZE * n) % PAGE_SIZE == 0. + * We want to pick the smallest possible 'n' so that our buckets don't span + * too much space. For smallest PAGE_SIZE of 4K (like on i386, for example), + * 'n' is 4, and this means that we will need: + * (MJUMBOSIZE * 4 / PAGE_SIZE) = JMB_PG_BUCKET = 9 pages per bucket. + * This corresponds to the smallest 'n' that we can find for a 4K page size. + * For a larger page size (e.g., 8K), we just have PAGE_SIZE = 2 * 4096, + * so n = 2 * 4 = 8. We can calculate 'n' at runtime for our page size, + * as long as PAGE_SIZE is a multiple of 2, and as long as we define + * JMB_PG_BUCKET here appropriately. + */ +#define JMB_PG_BUCKET 9 +#endif /* * Internal flags that allow for cache locks to remain "persistent" across @@ -357,6 +403,7 @@ mb_list_mbuf.ml_mapfull = 0; mb_list_mbuf.ml_objsize = MSIZE; mb_list_mbuf.ml_wmhigh = &mbuf_limit; + mb_list_mbuf.ml_bucksize = PAGE_SIZE; mb_map_size = (vm_size_t)(nmbclusters * MCLBYTES); mb_map_size = rounddown(mb_map_size, PAGE_SIZE); @@ -371,6 +418,7 @@ mb_list_clust.ml_mapfull = 0; mb_list_clust.ml_objsize = MCLBYTES; mb_list_clust.ml_wmhigh = &clust_limit; + mb_list_clust.ml_bucksize = PAGE_SIZE; /* * Allocate required general (global) containers for each object type. @@ -428,11 +476,45 @@ */ mbstat.m_msize = MSIZE; mbstat.m_mclbytes = MCLBYTES; + mbstat.m_mjumbobytes = MJUMBOBYTES; mbstat.m_minclsize = MINCLSIZE; mbstat.m_mlen = MLEN; mbstat.m_mhlen = MHLEN; mbstat.m_numtypes = MT_NTYPES; +#ifdef NMBJUMBOBUFS + mb_map_size = (vm_size_t)(nmbjumbobufs * MJUMBOSIZE); + mb_map_size = roundup(mb_map_size, JMB_PG_BUCKET * PAGE_SIZE); + mb_list_jumbo.ml_btable = malloc((unsigned long)mb_map_size / + (JMB_PG_BUCKET * PAGE_SIZE) * sizeof(struct mb_bucket *), + M_MBUF, M_NOWAIT); + if (mb_list_jumbo.ml_btable == NULL) + goto bad; + mb_list_jumbo.ml_map = kmem_suballoc(kmem_map, + &(mb_list_jumbo.ml_mapbase), &(mb_list_jumbo.ml_maptop), + mb_map_size); + mb_list_jumbo.ml_map->system_map = 1; + mb_list_jumbo.ml_mapfull = 0; + mb_list_jumbo.ml_objsize = MJUMBOSIZE; + mb_list_jumbo.ml_wmhigh = &jumbo_limit; + mb_list_jumbo.ml_bucksize = JMB_PG_BUCKET * PAGE_SIZE; + mb_list_jumbo.ml_genlist = malloc(sizeof(struct mb_gen_list), + M_MBUF, M_NOWAIT); + if (mb_list_jumbo.ml_genlist == NULL) + goto bad; + cv_init(&(mb_list_jumbo.ml_genlist->mgl_mstarved), + "jumbo cluster pool starved"); + mb_list_jumbo.ml_genlist->mb_cont.mc_lock = &mbuf_gen; + mb_list_jumbo.ml_genlist->mb_cont.mc_numowner = MB_GENLIST_OWNER; + mb_list_jumbo.ml_genlist->mb_cont.mc_starved = 0; + mb_list_jumbo.ml_genlist->mb_cont.mc_objcount = + &(mb_statpcpu[MB_GENLIST_OWNER].mb_clfree); + mb_list_jumbo.ml_genlist->mb_cont.mc_numpgs = + &(mb_statpcpu[MB_GENLIST_OWNER].mb_clpgs); + mb_list_jumbo.ml_genlist->mb_cont.mc_types = NULL; + SLIST_INIT(&(mb_list_jumbo.ml_genlist->mb_cont.mc_bhead)); +#endif + /* * Allocate and initialize PCPU containers. */ @@ -492,6 +574,30 @@ goto bad; } MB_UNLOCK_CONT(pcpu_cnt); + +#ifdef NMBJUMBOBUFS + mb_list_jumbo.ml_cntlst[i] = malloc(sizeof(struct mb_pcpu_list), + M_MBUF, M_NOWAIT); + if (mb_list_jumbo.ml_cntlst[i] == NULL) + goto bad; + mb_list_jumbo.ml_cntlst[i]->mb_cont.mc_lock = &mbuf_pcpu[i]; + mb_list_jumbo.ml_cntlst[i]->mb_cont.mc_numowner = i; + mb_list_jumbo.ml_cntlst[i]->mb_cont.mc_starved = 0; + mb_list_jumbo.ml_cntlst[i]->mb_cont.mc_objcount = + &(mb_statpcpu[i].mb_jbfree); + mb_list_jumbo.ml_cntlst[i]->mb_cont.mc_numpgs = + &(mb_statpcpu[i].mb_jbpgs); + mb_list_jumbo.ml_cntlst[i]->mb_cont.mc_types = NULL; + SLIST_INIT(&(mb_list_mbuf.ml_cntlst[i]->mb_cont.mc_bhead)); + pcpu_cnt = MB_GET_PCPU_LIST_NUM(&mb_list_jumbo, i); + MB_LOCK_CONT(pcpu_cnt); + for (j = 0; j < NMB_MBUF_INIT; j++) { + if (mb_pop_cont(&mb_list_jumbo, M_DONTWAIT, pcpu_cnt) + == NULL) + goto bad; + } + MB_UNLOCK_CONT(pcpu_cnt); +#endif } return; @@ -527,12 +633,12 @@ return (NULL); bucket = malloc(sizeof(struct mb_bucket) + - PAGE_SIZE / mb_list->ml_objsize * sizeof(void *), M_MBUF, + mb_list->ml_bucksize / mb_list->ml_objsize * sizeof(void *), M_MBUF, how == M_TRYWAIT ? M_WAITOK : M_NOWAIT); if (bucket == NULL) return (NULL); - p = (caddr_t)kmem_malloc(mb_list->ml_map, PAGE_SIZE, + p = (caddr_t)kmem_malloc(mb_list->ml_map, mb_list->ml_bucksize, how == M_TRYWAIT ? M_WAITOK : M_NOWAIT); if (p == NULL) { free(bucket, M_MBUF); @@ -542,8 +648,9 @@ } bucket->mb_numfree = 0; - mb_list->ml_btable[MB_BUCKET_INDX(p, mb_list)] = bucket; - for (i = 0; i < (PAGE_SIZE / mb_list->ml_objsize); i++) { + mb_list->ml_btable[MB_BUCKET_INDX(p, mb_list, + mb_list->ml_bucksize)] = bucket; + for (i = 0; i < (mb_list->ml_bucksize / mb_list->ml_objsize); i++) { bucket->mb_free[i] = p; bucket->mb_numfree++; p += mb_list->ml_objsize; @@ -805,7 +912,8 @@ struct mb_bucket *bucket; u_int owner; - bucket = mb_list->ml_btable[MB_BUCKET_INDX(m, mb_list)]; + bucket = mb_list->ml_btable[MB_BUCKET_INDX(m, mb_list, + mb_list->ml_bucksize)]; /* * Make sure that if after we lock the bucket's present container the @@ -957,9 +1065,9 @@ * being freed in an effort to keep the mbtypes * counters approximately balanced across all lists. */ - MB_MBTYPES_DEC(cnt_lst, type, (PAGE_SIZE / + MB_MBTYPES_DEC(cnt_lst, type, (mb_list->ml_bucksize / mb_list->ml_objsize) - bucket->mb_numfree); - MB_MBTYPES_INC(gen_list, type, (PAGE_SIZE / + MB_MBTYPES_INC(gen_list, type, (mb_list->ml_bucksize / mb_list->ml_objsize) - bucket->mb_numfree); MB_UNLOCK_CONT(gen_list); Index: src/sys/sys/mbuf.h =================================================================== RCS file: /home/ncvs/src/sys/sys/mbuf.h,v retrieving revision 1.98 diff -u -r1.98 mbuf.h --- src/sys/sys/mbuf.h 30 Jul 2002 22:03:57 -0000 1.98 +++ src/sys/sys/mbuf.h 9 Aug 2002 19:06:05 -0000 @@ -44,9 +44,9 @@ #include /* - * Mbufs are of a single size, MSIZE (machine/param.h), which + * Mbufs are of a single size, MSIZE (sys/param.h), which * includes overhead. An mbuf may add a single "mbuf cluster" of size - * MCLBYTES (also in machine/param.h), which has no additional overhead + * MCLBYTES (also in sys/param.h), which has no additional overhead * and is used instead of the internal data area; this is done when * at least MINCLSIZE of data must be stored. Additionally, it is possible * to allocate a separate buffer externally and attach it to the mbuf in @@ -57,6 +57,16 @@ #define MINCLSIZE (MHLEN + 1) /* smallest amount to put in cluster */ #define M_MAXCOMPRESS (MHLEN / 2) /* max amount to copy for compression */ +/* + * Jumbo clusters/buffers are (9216 - sizeof(u_int)) bytes in size (the + * trailing u_int is used as a ref. count). They are _virtually_ + * contiguous data regions that can be attached to mbufs. They are + * typically used for large >9K frames with devices that can do + * scatter/gather. MJUMBOBYTES is the size of the actual data region. + */ +#define MJUMBOSIZE 9216 +#define MJUMBOBYTES (MJUMBOSIZE - sizeof(u_int)) + #ifdef _KERNEL /*- * Macros for type conversion: @@ -225,6 +235,8 @@ u_long mb_mbpgs; u_long mb_clfree; u_long mb_clpgs; + u_long mb_jbfree; + u_long mb_jbpgs; long mb_mbtypes[MT_NTYPES]; short mb_active; }; @@ -245,6 +257,7 @@ u_long m_mpfail; /* XXX: times m_pullup failed */ u_long m_msize; /* length of an mbuf */ u_long m_mclbytes; /* length of an mbuf cluster */ + u_long m_mjumbobytes; /* length of a jumbo cluster */ u_long m_minclsize; /* min length of data to allocate a cluster */ u_long m_mlen; /* length of data in an mbuf */ u_long m_mhlen; /* length of data in a header mbuf */ @@ -462,6 +475,7 @@ extern int nmbclusters; /* Maximum number of clusters */ extern int nmbcnt; /* Scale kmem_map for counter space */ extern int nmbufs; /* Maximum number of mbufs */ +extern int nmbjumbobufs; /* Maximum number of jumbo clusters */ extern int nsfbufs; /* Number of sendfile(2) bufs */ void _mext_free(struct mbuf *); --X1bOJ3K7DJ5YkBrT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 12:45: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 DB13737B67E; Fri, 9 Aug 2002 12:45:39 -0700 (PDT) Received: from tesla.distributel.net (unknown [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9987E43E6E; Fri, 9 Aug 2002 12:45:23 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g79Ji5G88345; Fri, 9 Aug 2002 15:44:05 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 9 Aug 2002 15:44:05 -0400 From: Bosko Milekic To: gallatin@FreeBSD.ORG, ken@FreeBSD.ORG Cc: freebsd-net@FreeBSD.ORG Subject: Re: Jumbo Clusters in mb_alloc Message-ID: <20020809154405.A88323@unixdaemons.com> References: <20020809151627.A88180@unixdaemons.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: <20020809151627.A88180@unixdaemons.com>; from bmilekic@unixdaemons.com on Fri, Aug 09, 2002 at 03:16: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, Aug 09, 2002 at 03:16:27PM -0400, Bosko Milekic wrote: > > Hi guys, > > Can you put this (the attached) to use? > > It's the implementation of jumbo clusters within mb_alloc, as > discussed on -net not too long ago. I should also just point out that the patch needs a few things added (some additional ifdef NMBJUMBOBUFS in mbuf.h) along with the actual interface addition before it is committed. Regardless, it should be enough to give you an idea of what it looks like and to also perform some initial per-CPU cache population (and it does, I've tested it). > I have not written the allocation interface yet as I would like to > know if you could put them to use in some of the drivers, and also > what you would need from the interface. [...] > Anyway, see the attached patch and let me know if this is useful to > you. Thanks! > > Cheers, > -- > Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org [...patch snipped...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 13:14: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 8347337B400 for ; Fri, 9 Aug 2002 13:14:30 -0700 (PDT) Received: from web10407.mail.yahoo.com (web10407.mail.yahoo.com [216.136.130.99]) by mx1.FreeBSD.org (Postfix) with SMTP id 37CB543E65 for ; Fri, 9 Aug 2002 13:14:30 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20020809201429.56558.qmail@web10407.mail.yahoo.com> Received: from [67.112.212.200] by web10407.mail.yahoo.com via HTTP; Fri, 09 Aug 2002 13:14:29 PDT Date: Fri, 9 Aug 2002 13:14:29 -0700 (PDT) From: Oleg Polyakov Subject: Initial congestion window increase To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-323828219-1028924069=:56365" 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 --0-323828219-1028924069=:56365 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is a patch allowing to increase TCP's initial congestion window up to 4 mss but less then 4380 bytes as specified in experimental RFC 2414 and draft-ietf-tsvwg-initwin-04.txt. It doesn't touch idle congestion window as per draft. Sysctl variable net.inet.tcp.increased_initial_window allows to turn on/off increased initial window. In case it turned off initial window would be defined by slowstart_flightsize. In case of local network it doesn't change anything. We could eliminate local_slowstart_flightsize for good as too optimistic when increased_initial_window'll be turned on by default. FYI NetBSD implemented RFC 2414 in 1998. The patch is applicable to CURRENT and should work on STABLE as well. ---- Oleg __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com --0-323828219-1028924069=:56365 Content-Type: text/plain; name="patch01.5a.txt" Content-Description: patch01.5a.txt Content-Disposition: inline; filename="patch01.5a.txt" --- tcp_input.c.orig Sat Apr 6 05:15:47 2002 +++ tcp_input.c Wed Aug 7 12:30:24 2002 @@ -121,6 +121,10 @@ &tcp_delack_enabled, 0, "Delay ACK to try and piggyback it onto a data packet"); +int inc_init_win = 0; +SYSCTL_INT(_net_inet_tcp, OID_AUTO, increased_initial_window, CTLFLAG_RW, + &inc_init_win, 1, "Increased initial window"); + #ifdef TCP_DROP_SYNFIN static int drop_synfin = 0; SYSCTL_INT(_net_inet_tcp, OID_AUTO, drop_synfin, CTLFLAG_RW, @@ -2492,6 +2496,7 @@ * of the interface), as we can't discover anything about intervening * gateways or networks. We also initialize the congestion/slow start * window to be a single segment if the destination isn't local. + * We may increase the congestion/slow start window in accordance with RFC2414. * While looking at the routing entry, we also initialize other path-dependent * parameters from pre-set or cached values in the routing entry. * @@ -2710,7 +2715,9 @@ #endif ) tp->snd_cwnd = mss * ss_fltsz_local; - else + else if (inc_init_win) + tp->snd_cwnd = min(4*mss, max(2*mss,4380)); + else tp->snd_cwnd = mss * ss_fltsz; if (rt->rt_rmx.rmx_ssthresh) { --0-323828219-1028924069=:56365-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 13:28: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 C778B37B400; Fri, 9 Aug 2002 13:28:30 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C022F43E70; Fri, 9 Aug 2002 13:28:26 -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 QAA10118; Fri, 9 Aug 2002 16:28:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g79KRoE05324; Fri, 9 Aug 2002 16:27:50 -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: <15700.9669.885383.727182@grasshopper.cs.duke.edu> Date: Fri, 9 Aug 2002 16:27:49 -0400 (EDT) To: Bosko Milekic Cc: ken@freebsd.org, freebsd-net@freebsd.org Subject: Re: Jumbo Clusters in mb_alloc In-Reply-To: <20020809151627.A88180@unixdaemons.com> References: <20020809151627.A88180@unixdaemons.com> 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 Bosko Milekic writes: > > Hi guys, > > Can you put this (the attached) to use? > > It's the implementation of jumbo clusters within mb_alloc, as > discussed on -net not too long ago. > > I have not written the allocation interface yet as I would like to > know if you could put them to use in some of the drivers, and also > what you would need from the interface. I can certainly use this in my (3rd party) GM Myrinet driver. I think the tigon driver can be made to use this, but I have no tigon hardware anymore. I also think bge could be made to use this, but again, no hardware to play with it on. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 13:41: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 B6D0E37B400; Fri, 9 Aug 2002 13:41:36 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B90243E7B; Fri, 9 Aug 2002 13:41:36 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g79KfaC88818; Fri, 9 Aug 2002 16:41:36 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Fri, 9 Aug 2002 16:41:36 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: ken@freebsd.org, freebsd-net@freebsd.org Subject: Re: Jumbo Clusters in mb_alloc Message-ID: <20020809164136.A88798@unixdaemons.com> References: <20020809151627.A88180@unixdaemons.com> <15700.9669.885383.727182@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15700.9669.885383.727182@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Aug 09, 2002 at 04:27:49PM -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, Aug 09, 2002 at 04:27:49PM -0400, Andrew Gallatin wrote: > > Bosko Milekic writes: > > > > Hi guys, > > > > Can you put this (the attached) to use? > > > > It's the implementation of jumbo clusters within mb_alloc, as > > discussed on -net not too long ago. > > > > I have not written the allocation interface yet as I would like to > > know if you could put them to use in some of the drivers, and also > > what you would need from the interface. > > I can certainly use this in my (3rd party) GM Myrinet driver. > > I think the tigon driver can be made to use this, but I have no tigon > hardware anymore. I also think bge could be made to use this, but > again, no hardware to play with it on. Excellent. So the question is what do you think would be a convenient interface? This really boils down to how you plan to use it. I'm assuming that, for example, you can do scatter DMA to each page (each buffer spans /at most/ 3 pages, and only 2 pages on alpha) in the driver receive code. So, assuming that's the case, we can provide an allocation routine, something like m_getjmb() that will give you an mbuf and a jumbo buf in one shot. Then you can extract the physical addresses from the parts of the data region and scatter DMA to it. The buffers with the mbuf would be easily freed with m_freem(). What about the send case, though? How do you want to determine whether or not to use a jumbo cluster or a regular cluster? Do you plan to do zero-copy with these things? I don't think this would be possible because, as discussed, not all of them start at page-boundaries. Nonetheless, they will allow you to do scatter/gather and provide you with a consistent interface for it. I guess what I'm trying to get is an idea of what kind of interface you would like to have, as you probably know what you need/what would be useful much better than I do. Getting mb_alloc to allocate them was fairly trivial, as you can see. > Drew Cheers, -- 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 Fri Aug 9 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 9ED0537B412 for ; Fri, 9 Aug 2002 13:52:35 -0700 (PDT) Received: from mail.dada.it (mail2.dada.it [195.110.100.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 8E68143E9E for ; Fri, 9 Aug 2002 13:52:34 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 14591 invoked from network); 9 Aug 2002 20:52:29 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 9 Aug 2002 20:52:29 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id C53105FA7; Fri, 9 Aug 2002 22:52:30 +0200 (CEST) Date: Fri, 9 Aug 2002 22:52:30 +0200 From: Alessandro de Manzano To: Archie Cobbs Cc: net@FreeBSD.ORG Subject: Re: MPD with WinXP clients Message-ID: <20020809225230.A76420@libero.sunshine.ale> Reply-To: Alessandro de Manzano References: <20020807214304.A67338@libero.sunshine.ale> <200208080228.g782S2o00502@arch20m.dellroad.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: <200208080228.g782S2o00502@arch20m.dellroad.org>; from archie@dellroad.org on Wed, Aug 07, 2002 at 07:28:02PM -0700 X-Operating-System: FreeBSD 4.6-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 Wed, Aug 07, 2002 at 07:28:02PM -0700, Archie Cobbs wrote: > > Connection and authentication seems ok, but when I do some "big" > > transfer the session locks. > > Sounds like an MTU problem.. try lowering the MTU on ng0 manually > (e.g., "ifconfig ng0 mtu 1440") and or installing the tcp MSS fixup > program (can't remember the name). I tried lowering ng0's MTU as you suggested but unfortunately it does not works. Seems that the only way is enabling multilink framing negotiation on WinXP clients. Doing so it seems to work ok, also if still reports an ioctl() error about setting MTU in the mpd log file. I privately sent you my config and logs, hoping you've time and will to help me :)) Many thanks anyway! -- bye! Ale To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 14:33: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 D4B3937B400; Fri, 9 Aug 2002 14:33:26 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15E4A43E6A; Fri, 9 Aug 2002 14:33:26 -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 RAA11900; Fri, 9 Aug 2002 17:33:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g79LWtw05379; Fri, 9 Aug 2002 17:32:55 -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: <15700.13575.470677.723138@grasshopper.cs.duke.edu> Date: Fri, 9 Aug 2002 17:32:55 -0400 (EDT) To: Bosko Milekic Cc: ken@freebsd.org, freebsd-net@freebsd.org Subject: Re: Jumbo Clusters in mb_alloc In-Reply-To: <20020809164136.A88798@unixdaemons.com> References: <20020809151627.A88180@unixdaemons.com> <15700.9669.885383.727182@grasshopper.cs.duke.edu> <20020809164136.A88798@unixdaemons.com> 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 Bosko Milekic writes: > > On Fri, Aug 09, 2002 at 04:27:49PM -0400, Andrew Gallatin wrote: > > > > Bosko Milekic writes: > > > > > > Hi guys, > > > > > > Can you put this (the attached) to use? > > > > > > It's the implementation of jumbo clusters within mb_alloc, as > > > discussed on -net not too long ago. > > > > > > I have not written the allocation interface yet as I would like to > > > know if you could put them to use in some of the drivers, and also > > > what you would need from the interface. > > > > I can certainly use this in my (3rd party) GM Myrinet driver. > > > > I think the tigon driver can be made to use this, but I have no tigon > > hardware anymore. I also think bge could be made to use this, but > > again, no hardware to play with it on. > > Excellent. > > So the question is what do you think would be a convenient interface? > This really boils down to how you plan to use it. I'm assuming that, > for example, you can do scatter DMA to each page (each buffer spans > /at most/ 3 pages, and only 2 pages on alpha) in the driver receive > code. So, assuming that's the case, we can provide an allocation > routine, something like m_getjmb() that will give you an mbuf and a > jumbo buf in one shot. Then you can extract the physical addresses > from the parts of the data region and scatter DMA to it. The buffers > with the mbuf would be easily freed with m_freem(). I already have code to extract physical address from an mbuf in such a way as to make sure that DMA does not cross page boundaries, but I'd hate to see this code replicated everywhere. Ideally, I'd love to see an interface where I call a function dma_map_mbuf_chain (m, ...) and get back an array of DMA addresses. Hmm.. WWNBD (what would NetBSD do..). Ah, yes: bus_dmamap_load_mbuf(sc->sc_dmat, dmamap, m0, BUS_DMA_WRITE|BUS_DMA_NOWAIT) != 0) { MGETHDR(m, M_DONTWAIT, MT_DATA); Methinks its high time we adopted this interface. > What about the send case, though? How do you want to determine The send case opens a huge can-of-worms. Lets say that somebody is forwarding between myrinet & GigE using FreeBSD, with myri0 on the myrinet network, and em0 on GigE. Let's assume that myri0 is using jumbo buffers, but em0 isn't jumbo aware & cannot accept them & the forwarded packets end up as garbage. Perhaps we need to add an IFCAP_JUMBOAWARE flag and somwhere (IF_DEQUE?) add a KASSERT to catch situaions like this. Or even.. ick, add code to copy to a normal mbuf chain. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 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 CBEDE37B400; Fri, 9 Aug 2002 14:42:03 -0700 (PDT) Received: from usenix.org (voyager.usenix.org [131.106.3.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66A0F43E70; Fri, 9 Aug 2002 14:42:03 -0700 (PDT) (envelope-from sam@usenix.org) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated (0 bits)) by usenix.org (Switch-2.1.3/Switch-2.1.0) with ESMTP id g79LflS04462 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Fri, 9 Aug 2002 14:41:53 -0700 (PDT) Message-ID: <016001c23fed$93832640$52557f42@errno.com> From: "Sam Leffler (at Usenix)" To: "Andrew Gallatin" , "Bosko Milekic" Cc: , References: <20020809151627.A88180@unixdaemons.com><15700.9669.885383.727182@grasshopper.cs.duke.edu><20020809164136.A88798@unixdaemons.com> <15700.13575.470677.723138@grasshopper.cs.duke.edu> Subject: Re: Jumbo Clusters in mb_alloc Date: Fri, 9 Aug 2002 14:41:47 -0700 Organization: Usenix Association 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 X-DCC-Usenix-Metrics: voyager 1010; Body=4 Fuz1=4 Fuz2=4 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 > Ideally, I'd love to see an interface where I call a function > dma_map_mbuf_chain (m, ...) and get back an array of DMA addresses. > Hmm.. WWNBD (what would NetBSD do..). > > Ah, yes: > > bus_dmamap_load_mbuf(sc->sc_dmat, dmamap, m0, > BUS_DMA_WRITE|BUS_DMA_NOWAIT) != 0) { > MGETHDR(m, M_DONTWAIT, MT_DATA); > > Methinks its high time we adopted this interface. I use bus_dmamap_load_mbuf (and _uio) in the crypto drivers I import from openbsd. I think it would be good to adopt this interface. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 17: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 6538737B400 for ; Fri, 9 Aug 2002 17:12:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9FE943E6A for ; Fri, 9 Aug 2002 17:12:54 -0700 (PDT) (envelope-from larse@ISI.EDU) Received: from isi.edu (pjz4kmu1r5u7bo59@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g7A0Cmr27501; Fri, 9 Aug 2002 17:12:48 -0700 (PDT) Message-ID: <3D545A7F.6020809@isi.edu> Date: Fri, 09 Aug 2002 17:12:47 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Lars Eggert Cc: freebsd-net@freebsd.org, snap-users@kame.net Subject: Re: IPv6, hostap and bridging References: <3D52FC3D.9010904@isi.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010900060401040905040804" 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. --------------ms010900060401040905040804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lars Eggert wrote: > However, connectivity is broken. Using the canonical "ping6 > www.kame.net" on the client makes it send out neighbor solicitations for > the router address over the wireless link, and they arrive on wi0 on the > router/AP: > > 16:15:56.407151 3ffe:825:27:0:202:2dff:fe5e:870c > ff02::1:ffc0:3edd: > icmp6: neighbor sol: who has fe80::200:24ff:fec0:3edd > > but the router/AP doesn't generate replies to the client, it bridges the > message and sends them out via sis1: > > 16:15:56.407238 3ffe:825:27:0:202:2dff:fe5e:870c > ff02::1:ffc0:3edd: > icmp6: neighbor sol: who has fe80::200:24ff:fec0:3edd > > However, the router *is* fe80::200:24ff:fec0:3edd%sis1! I'm not sure if this is related, but another bridging oddity seems to be that bridged packets addressed to the bridge itself (or broadcast) are not received by processes on the bridge if one of the two (in my case) bridged interfaces has no carrier. Lars -- Lars Eggert USC Information Sciences Institute --------------ms010900060401040905040804 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDgxMDAwMTI0OFowIwYJKoZIhvcNAQkEMRYEFOJ/OpluQrbL eL8ECviZlGT/rOynMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF gUcwDQYJKoZIhvcNAQEBBQAEgYC7h5WZhmZUFqNX+bfM1Y0Do0eCTf+TGeT1yediWJKg29o0 W2hr9CJZf/dtgj5jSLGD1NYHw/YKAfydJ/V9jzTOh5sRzHww8sd6vzzqE+VS3bKsyIpMNrxd yXVsj5D0RRBkdXpGbgdVpx6lhxDAvZEmI4LEHUWtUnz2F379kqfaNAAAAAAAAA== --------------ms010900060401040905040804-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Aug 9 23:54: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 86B9237B400 for ; Fri, 9 Aug 2002 23:54:20 -0700 (PDT) Received: from lancer.sasktel.net (lancer.sasktel.net [142.165.19.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0673E43E3B for ; Fri, 9 Aug 2002 23:54:20 -0700 (PDT) (envelope-from topcat@sk.sympatico.ca) Received: from sk.sympatico.ca (regnsk01d050101224.sk.sympatico.ca [142.165.24.224]) by lancer.sasktel.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H0M003VX8IDZE@lancer.sasktel.net> for freebsd-net@freebsd.org; Sat, 10 Aug 2002 00:54:14 -0600 (CST) Content-return: allowed Date: Sat, 10 Aug 2002 00:54:15 -0600 From: TOPCAT CONSULTING Subject: ppp to ethernet routing problem To: freebsd-net@freebsd.org Message-id: <3D54B897.BE7E09A8@sk.sympatico.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 3.1-RELEASE i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a dial-up ppp connection from PC_1 to PC_2 set up and working good. PC_2 has an ethernet network connection as well, connecting to PC_3 on a different network address The ppp connection is from 192.168.0.2 --> 192.168.0.1 I need to route as follows: from 192.168.0.2 --> 192.168.0.1 --> 10.0.0.1 in other words from PC_1 --> PC_2 --> PC_3 where 1-->2 is ppp and 2 -->3 is ethernet After the ppp connection from 1 --> 2 is established the route table on PC_1 is as follows: DEST GATEWAY GENMASK FLAGS IFACE 192.168.0.1 * 255.0.0.0 UH ppp0 127.0.0.0 * 255.0.0.0 U lo default 192.168.0.1 0.0.0.0 UG ppp0 pppd is enabled with option "defaultroute" I can't get from 1 -->3 What might I be missing? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 10 7:56: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 E829037B400; Sat, 10 Aug 2002 07:56:47 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3840643E3B; Sat, 10 Aug 2002 07:56:47 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g7AEui092869; Sat, 10 Aug 2002 10:56:44 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Sat, 10 Aug 2002 10:56:44 -0400 From: Bosko Milekic To: Andrew Gallatin Cc: ken@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Jumbo Clusters in mb_alloc Message-ID: <20020810105644.A92823@unixdaemons.com> References: <20020809151627.A88180@unixdaemons.com> <15700.9669.885383.727182@grasshopper.cs.duke.edu> <20020809164136.A88798@unixdaemons.com> <15700.13575.470677.723138@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <15700.13575.470677.723138@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Aug 09, 2002 at 05:32:55PM -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, Aug 09, 2002 at 05:32:55PM -0400, Andrew Gallatin wrote: [...] > bus_dmamap_load_mbuf(sc->sc_dmat, dmamap, m0, > BUS_DMA_WRITE|BUS_DMA_NOWAIT) != 0) { > MGETHDR(m, M_DONTWAIT, MT_DATA); > > Methinks its high time we adopted this interface. It's really funny that I remember implementing this for Mark Murray quite a while ago for crypto stuff he was then working on, and now just recently Sam Leffler - who's doing all the cool crypto work these days - also mentionned he's already ported it and using it - and on top of it, you've ported it and are using it! - yet, we still haven't really merged our efforts. :-) I agree that we absolutely need this interface and it should know how to deal with both a chain of mbufs with regular clusters as well as a chain/or single mbuf with [a] jumbo cluster[s]. > > What about the send case, though? How do you want to determine > > The send case opens a huge can-of-worms. Lets say that somebody is > forwarding between myrinet & GigE using FreeBSD, with myri0 on the > myrinet network, and em0 on GigE. Let's assume that myri0 is using > jumbo buffers, but em0 isn't jumbo aware & cannot accept them & the > forwarded packets end up as garbage. > > Perhaps we need to add an IFCAP_JUMBOAWARE flag and somwhere > (IF_DEQUE?) add a KASSERT to catch situaions like this. > Or even.. ick, add code to copy to a normal mbuf chain. Wow, I had not even thought of that, actually. My concern was how we were going to deal with things like sendto() which currently allocate regular clusters. In some cases, it would be advantageous for them to allocate the jumbo clusters if the outgoing interface supports them. Anyway, the forwarding example you bring up is at least equally interesting. I suppose that for these [hopefully rare] cases we could perform a copy. Although, I have a question: is it possible to somehow "peek" at the data to see if it is a packet that we're forwarding to an interface that isn't IFCAP_JUMBOAWARE and, if so, just DMA into a chain of mbufs with regular clusters? > Drew Cheers, -- 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 Sat Aug 10 10: 9: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 2A66C37B400; Sat, 10 Aug 2002 10:09:16 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E619E43E65; Sat, 10 Aug 2002 10:09:14 -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 NAA01852; Sat, 10 Aug 2002 13:09:14 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7AH8iF09254; Sat, 10 Aug 2002 13:08:44 -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: <15701.18588.40682.896343@grasshopper.cs.duke.edu> Date: Sat, 10 Aug 2002 13:08:44 -0400 (EDT) To: Bosko Milekic Cc: ken@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Jumbo Clusters in mb_alloc In-Reply-To: <20020810105644.A92823@unixdaemons.com> References: <20020809151627.A88180@unixdaemons.com> <15700.9669.885383.727182@grasshopper.cs.duke.edu> <20020809164136.A88798@unixdaemons.com> <15700.13575.470677.723138@grasshopper.cs.duke.edu> <20020810105644.A92823@unixdaemons.com> 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 Bosko Milekic writes: > > On Fri, Aug 09, 2002 at 05:32:55PM -0400, Andrew Gallatin wrote: > [...] > > bus_dmamap_load_mbuf(sc->sc_dmat, dmamap, m0, > > BUS_DMA_WRITE|BUS_DMA_NOWAIT) != 0) { > > MGETHDR(m, M_DONTWAIT, MT_DATA); > > > > Methinks its high time we adopted this interface. > > It's really funny that I remember implementing this for Mark Murray > quite a while ago for crypto stuff he was then working on, and now > just recently Sam Leffler - who's doing all the cool crypto work these > days - also mentionned he's already ported it and using it - and on > top of it, you've ported it and are using it! - yet, we still haven't I've not ported it... I just have some similar code which does roughly the same thing. If I'd have thought to look at NetBSD, I'd have "ported" it, but I didn't ;) Note that the if_gem driver, used on the sparc64 port has its own copy of this code that it uses. > really merged our efforts. :-) I agree that we absolutely need this > interface and it should know how to deal with both a chain of mbufs > with regular clusters as well as a chain/or single mbuf with [a] jumbo > cluster[s]. I think a good first step would be to import something ASAP and default it to the direct interface (assume dma_addr == vtop(vaddr), and let the various platforms adopt it as they will. I'd certainly be happy to help with alpha, and a few drivers. > > > What about the send case, though? How do you want to determine > > > > The send case opens a huge can-of-worms. Lets say that somebody is > > forwarding between myrinet & GigE using FreeBSD, with myri0 on the > > myrinet network, and em0 on GigE. Let's assume that myri0 is using > > jumbo buffers, but em0 isn't jumbo aware & cannot accept them & the > > forwarded packets end up as garbage. > > > > Perhaps we need to add an IFCAP_JUMBOAWARE flag and somwhere > > (IF_DEQUE?) add a KASSERT to catch situaions like this. > > Or even.. ick, add code to copy to a normal mbuf chain. > > Wow, I had not even thought of that, actually. My concern was how we > were going to deal with things like sendto() which currently allocate > regular clusters. In some cases, it would be advantageous for them to > allocate the jumbo clusters if the outgoing interface supports them. I absolutely agree. > Anyway, the forwarding example you bring up is at least equally > interesting. I suppose that for these [hopefully rare] cases we could > perform a copy. Although, I have a question: is it possible to > somehow "peek" at the data to see if it is a packet that we're > forwarding to an interface that isn't IFCAP_JUMBOAWARE and, if so, > just DMA into a chain of mbufs with regular clusters? No, because by the time you can read header & see where the packet is going, you've already setup the DMA into the jumbobuf. Heck, you've already finished it. Besides, routes can change. What might work, aside from data-copying, is aliasing a normal mbuf chain (where nothing crosses a page boundary) to the jumbo buf. If you're headed out a non IFCAP_JUMBOAWARE interface, then use the normal alias. Otherwise, use the jumbo buf. I'm not sure how to do this alias though.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 10 12: 8: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 4E12337B400; Sat, 10 Aug 2002 12:08:16 -0700 (PDT) Received: from gate.soum.co.jp (gate.soum.co.jp [202.221.40.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB31943E6A; Sat, 10 Aug 2002 12:08:13 -0700 (PDT) (envelope-from fujita@soum.co.jp) Received: from force.soum.co.jp (force.soum.co.jp [IPv6:3ffe:501:80a:1:a00:20ff:fef0:4c9c]) by gate.soum.co.jp (8.12.5/8.12.5) with ESMTP id g7AJ8AwP078838; Sun, 11 Aug 2002 04:08:10 +0900 (JST) (envelope-from fujita@soum.co.jp) Received: from vanilla.soum.co.jp (vanilla.soum.co.jp [3ffe:501:80a:1:202:b3ff:fe98:8115]) by force.soum.co.jp (8.11.6/3.7W-2001122804) with ESMTP id g7AJ88F19297; Sun, 11 Aug 2002 04:08:08 +0900 (JST) Received: from localhost (localhost [::1]) by vanilla.soum.co.jp (Postfix) with ESMTP id 7030C5323; Sun, 11 Aug 2002 04:08:08 +0900 (JST) Date: Sun, 11 Aug 2002 04:08:08 +0900 (JST) Message-Id: <20020811.040808.74720123.fujita@soum.co.jp> To: freebsd-net@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: m_freem() in tcp_respond() From: FUJITA Kazutoshi X-PGP-PublicKey: http://www.soum.co.jp/~fujita/fujita-GnuPG-publickey.txt X-PGP-FingerPrint: 9956 2ECE 7E7D B425 EC2D D49E FEBB 3C5F 2C34 1ECA Organization: SOUM Corporation, JAPAN X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 =?iso-2022-jp?B?KBskQjgtTFobKEIp?= 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, there. In tcp_respond() from /sys/netinet/tcp_subr.c, m_freem(m->m_next) is called without any checks. I think it's better to check m->m_next is not NULL, at least. --- /sys/netinet/tcp_subr.c.ORG Thu Jul 18 19:47:04 2002 +++ /sys/netinet/tcp_subr.c Sun Aug 11 04:00:09 2002 @@ -393,7 +393,8 @@ bcopy((caddr_t)th, (caddr_t)nth, sizeof(struct tcphdr)); flags = TH_ACK; } else { - m_freem(m->m_next); + if (m->m_next) + m_freem(m->m_next); m->m_next = 0; m->m_data = (caddr_t)ipgen; /* m_len is set later */ Regards, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 10 12:34: 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 D2F1B37B400 for ; Sat, 10 Aug 2002 12:33:57 -0700 (PDT) Received: from balin.ap.univie.ac.at (balin.ap.univie.ac.at [131.130.11.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98EA043E70 for ; Sat, 10 Aug 2002 12:33:56 -0700 (PDT) (envelope-from ulrich.kiermayr@ap.univie.ac.at) Received: (from uk@localhost) by balin.ap.univie.ac.at (8.11.1/8.11.1/0.0.0) id g7AJXtv1085025 for freebsd-net@FreeBSD.ORG; Sat, 10 Aug 2002 21:33:55 +0200 (CEST) Date: Sat, 10 Aug 2002 21:33:54 +0200 From: Ulrich Kiermayr To: freebsd-net@FreeBSD.ORG Subject: Source Based Routing of locally originated connections Message-ID: <20020810213354.A1086673@ap.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.19i 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 list, I have the following Question: I know that i can use either ipfinler (fastroute) or ipfw (fwd) to acomplish source based touting of packets going through my machine. Now I have a machine with several ip-Addresses, and i want to route packets differenly depending on which of the local addresses is the source address of the packet. Is this possible, and if yes how? lG uk -- --------------------------------------------------------------------------- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network Security Universitaetsstrasse 7, 1010 Wien, Austria --------------------------------------------------------------------------- eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Hotline: security.zid@univie.ac.at Fax: (+43 1) 4277 / 9140 Web: http://www.univie.ac.at/zid/security.html --------------------------------------------------------------------------- GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 10 13:21: 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 777BE37B400; Sat, 10 Aug 2002 13:21:05 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2422143E65; Sat, 10 Aug 2002 13:21:05 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0086.cvx21-bradley.dialup.earthlink.net ([209.179.192.86] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17dcj7-0003hr-00; Sat, 10 Aug 2002 13:20:46 -0700 Message-ID: <3D557563.D1FC72B8@mindspring.com> Date: Sat, 10 Aug 2002 13:19:47 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: FUJITA Kazutoshi Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: m_freem() in tcp_respond() References: <20020811.040808.74720123.fujita@soum.co.jp> 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 FUJITA Kazutoshi wrote: > --- /sys/netinet/tcp_subr.c.ORG Thu Jul 18 19:47:04 2002 > +++ /sys/netinet/tcp_subr.c Sun Aug 11 04:00:09 2002 > @@ -393,7 +393,8 @@ > bcopy((caddr_t)th, (caddr_t)nth, sizeof(struct tcphdr)); > flags = TH_ACK; > } else { > - m_freem(m->m_next); > + if (m->m_next) > + m_freem(m->m_next); > m->m_next = 0; > m->m_data = (caddr_t)ipgen; > /* m_len is set later */ NO. It is better to know that it's not NULL before it gets there. If you check everything everywhere to see if it's NULL before you do anything, then you are going to speen all your time comparing things to NULL, rather than doing real work. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 10 14:52: 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 717F037B400; Sat, 10 Aug 2002 14:52:03 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34A1D43E6A; Sat, 10 Aug 2002 14:52:03 -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 <0H0N00C04E2QUK@mta5.snfc21.pbi.net>; Sat, 10 Aug 2002 14:52:03 -0700 (PDT) Date: Sat, 10 Aug 2002 14:53:34 -0700 From: Jeffrey Hsu Subject: Re: m_freem() in tcp_respond() In-reply-to: Message from FUJITA Kazutoshi "of Sun, 11 Aug 2002 04:08:08 +0900." <20020811.040808.74720123.fujita@soum.co.jp> To: FUJITA Kazutoshi Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Message-id: <0H0N00C05E2QUK@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 m_freem() already checks to see if it gets passed in a NULL pointer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 10 16:23: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 26A5237B400; Sat, 10 Aug 2002 16:23:06 -0700 (PDT) Received: from gate.soum.co.jp (gate.soum.co.jp [202.221.40.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55DB243E81; Sat, 10 Aug 2002 16:23:03 -0700 (PDT) (envelope-from fujita@soum.co.jp) Received: from force.soum.co.jp (force.soum.co.jp [IPv6:3ffe:501:80a:1:a00:20ff:fef0:4c9c]) by gate.soum.co.jp (8.12.5/8.12.5) with ESMTP id g7ANN1wP080584; Sun, 11 Aug 2002 08:23:02 +0900 (JST) (envelope-from fujita@soum.co.jp) Received: from vanilla.soum.co.jp (vanilla.soum.co.jp [3ffe:501:80a:1:202:b3ff:fe98:8115]) by force.soum.co.jp (8.11.6/3.7W-2001122804) with ESMTP id g7ANN0F24358; Sun, 11 Aug 2002 08:23:00 +0900 (JST) Received: from localhost (localhost [::1]) by vanilla.soum.co.jp (Postfix) with ESMTP id CC0B35306; Sun, 11 Aug 2002 08:22:59 +0900 (JST) Date: Sun, 11 Aug 2002 08:22:59 +0900 (JST) Message-Id: <20020811.082259.74720252.fujita@soum.co.jp> To: tlambert2@mindspring.com Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: m_freem() in tcp_respond() From: FUJITA Kazutoshi In-Reply-To: <3D557563.D1FC72B8@mindspring.com> References: <20020811.040808.74720123.fujita@soum.co.jp> <3D557563.D1FC72B8@mindspring.com> X-PGP-PublicKey: http://www.soum.co.jp/~fujita/fujita-GnuPG-publickey.txt X-PGP-FingerPrint: 9956 2ECE 7E7D B425 EC2D D49E FEBB 3C5F 2C34 1ECA Organization: SOUM Corporation, JAPAN X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 =?iso-2022-jp?B?KBskQjgtTFobKEIp?= 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 From: Terry Lambert Subject: Re: m_freem() in tcp_respond() Date: Sat, 10 Aug 2002 13:19:47 -0700 Message-ID: <3D557563.D1FC72B8@mindspring.com> > It is better to know that it's not NULL before it gets there. > > If you check everything everywhere to see if it's NULL before > you do anything, then you are going to speen all your time > comparing things to NULL, rather than doing real work. Hmmm... But my -STABLE box crashes at here when boot. # gdb -k kernel.debug vmcore.0 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD at phsyical address 0x005d2000 initial pcb at physical address 0x004e2880 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc021ef9c stack pointer = 0x10:0xdc319cd0 frame pointer = 0x10:0xdc319cd8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 197 (wnnstat) interrupt mask = net tty panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc03b872c stack pointer = 0x10:0xdc319ae4 frame pointer = 0x10:0xdc319aec code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 197 (wnnstat) interrupt mask = net tty panic: from debugger Uptime: 38s dumping to dev #ad/0x30001, offset 1311872 dump ata0: resetting devices .. done 639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 621 620 619 618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600 599 598 597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 581 580 579 578 577 576 575 574 573 572 571 570 569 568 567 566 565 564 563 562 561 560 559 558 557 556 555 554 553 552 551 550 549 548 547 546 545 544 543 542 541 540 539 538 537 536 535 534 533 532 531 530 529 528 527 526 525 524 523 522 521 520 519 518 517 516 515 514 513 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 39 2 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 487 if (dumping++) { (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc0202e73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc02032b1 in panic (fmt=0xc03edd84 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc014cbb9 in db_panic (addr=-1071517796, have_addr=0, count=-1, modif=0xdc319b3c "") at /usr/src/sys/ddb/db_command.c:435 #4 0xc014cb59 in db_command (last_cmdp=0xc0463918, cmd_table=0xc0463758, aux_cmd_tablep=0xc04c0cb8) at /usr/src/sys/ddb/db_command.c:333 #5 0xc014cc1e in db_command_loop () at /usr/src/sys/ddb/db_command.c:457 #6 0xc014ed5b in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:71 #7 0xc03b84ce in kdb_trap (type=12, code=0, regs=0xdc319c90) at /usr/src/sys/i386/i386/db_interface.c:158 #8 0xc03c8e14 in trap_fatal (frame=0xdc319c90, eva=0) at /usr/src/sys/i386/i386/trap.c:969 #9 0xc03c8aed in trap_pfault (frame=0xdc319c90, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:867 #10 0xc03c8667 in trap (frame={tf_fs = 16, tf_es = -600768496, tf_ds = 16, tf_edi = -1048332032, tf_esi = 6422528, tf_ebp = -600728360, tf_isp = -600728388, tf_ebx = 0, tf_edx = 6756410, tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071517796, tf_cs = 8, tf_eflags = 66199, tf_esp = -1048331972, tf_ss = -1048331972}) at /usr/src/sys/i386/i386/trap.c:466 #11 0xc021ef9c in m_freem (m=0x0) at /usr/src/sys/kern/uipc_mbuf.c:706 ---Type to continue, or q to quit--- #12 0xc0273a0f in tcp_respond (tp=0x0, ipgen=0xc183b93c, th=0xc183b950, m=0xc183b900, ack=2100704027, seq=0, flags=20) at /usr/src/sys/netinet/tcp_subr.c:396 #13 0xc0271eff in tcp_input (m=0xc183b900, off0=20, proto=6) at /usr/src/sys/netinet/tcp_input.c:2204 #14 0xc026b874 in ip_input (m=0xc183b900) at /usr/src/sys/netinet/ip_input.c:821 #15 0xc026b8d3 in ipintr () at /usr/src/sys/netinet/ip_input.c:842 #16 0xc03ba809 in swi_net_next () #17 0xc0224929 in connect (p=0xd86e1f20, uap=0xdc319f80) at /usr/src/sys/kern/uipc_syscalls.c:396 #18 0xc03c90f5 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 22273, tf_esi = 3, tf_ebp = -1077938064, tf_isp = -600727596, tf_ebx = 671650276, tf_edx = -1077938288, tf_ecx = 13, tf_eax = 98, tf_trapno = 12, tf_err = 2, tf_eip = 672133692, tf_cs = 31, tf_eflags = 659, tf_esp = -1077938252, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175 #19 0xc03b93a5 in Xint0x80_syscall () #20 0x2806fcbd in ?? () #21 0x8048d88 in ?? () #22 0x8048add in ?? () (kgdb) frame 12 #12 0xc0273a0f in tcp_respond (tp=0x0, ipgen=0xc183b93c, th=0xc183b950, m=0xc183b900, ack=2100704027, seq=0, flags=20) at /usr/src/sys/netinet/tcp_subr.c:396 396 m_freem(m->m_next); (kgdb) print m $1 = (struct mbuf *) 0xc183b900 (kgdb) print m->m_hdr.mh_next $2 = (struct mbuf *) 0x0 (kgdb) frame 11 #11 0xc021ef9c in m_freem (m=0x0) at /usr/src/sys/kern/uipc_mbuf.c:706 706 if (mcl_pool_now < mcl_pool_max && m->m_next == NULL && (kgdb) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 10 16:28:53 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 9406737B400; Sat, 10 Aug 2002 16:28:39 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C958943E3B; Sat, 10 Aug 2002 16:28:38 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g7ANSNf94039; Sat, 10 Aug 2002 19:28:23 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Sat, 10 Aug 2002 19:28:22 -0400 From: Bosko Milekic To: FUJITA Kazutoshi Cc: tlambert2@mindspring.com, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: m_freem() in tcp_respond() Message-ID: <20020810192822.A94017@unixdaemons.com> References: <20020811.040808.74720123.fujita@soum.co.jp> <3D557563.D1FC72B8@mindspring.com> <20020811.082259.74720252.fujita@soum.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020811.082259.74720252.fujita@soum.co.jp>; from fujita@soum.co.jp on Sun, Aug 11, 2002 at 08:22:59AM +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 Ian Dowse just fixed this. Please upgrade. On Sun, Aug 11, 2002 at 08:22:59AM +0900, FUJITA Kazutoshi wrote: > From: Terry Lambert > Subject: Re: m_freem() in tcp_respond() > Date: Sat, 10 Aug 2002 13:19:47 -0700 > Message-ID: <3D557563.D1FC72B8@mindspring.com> >=20 > > It is better to know that it's not NULL before it gets there. > >=20 > > If you check everything everywhere to see if it's NULL before > > you do anything, then you are going to speen all your time > > comparing things to NULL, rather than doing real work. >=20 > Hmmm... > But my -STABLE box crashes at here when boot. >=20 >=20 > # gdb -k kernel.debug vmcore.0 > GNU gdb 4.18 (FreeBSD) > Copyright 1998 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-unknown-freebsd"... > IdlePTD at phsyical address 0x005d2000 > initial pcb at physical address 0x004e2880 > panicstr: from debugger > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x0 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x8:0xc021ef9c > stack pointer =3D 0x10:0xdc319cd0 > frame pointer =3D 0x10:0xdc319cd8 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 197 (wnnstat) > interrupt mask =3D net tty=20 > panic: from debugger >=20 >=20 > Fatal trap 3: breakpoint instruction fault while in kernel mode > instruction pointer =3D 0x8:0xc03b872c > stack pointer =3D 0x10:0xdc319ae4 > frame pointer =3D 0x10:0xdc319aec > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, IOPL =3D 0 > current process =3D 197 (wnnstat) > interrupt mask =3D net tty=20 > panic: from debugger > Uptime: 38s >=20 > dumping to dev #ad/0x30001, offset 1311872 > dump ata0: resetting devices .. done > 639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 624 623 622 6= 21 620 619 618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 = 602 601 600 599 598 597 596 595 594 593 592 591 590 589 588 587 586 585 584= 583 582 581 580 579 578 577 576 575 574 573 572 571 570 569 568 567 566 56= 5 564 563 562 561 560 559 558 557 556 555 554 553 552 551 550 549 548 547 5= 46 545 544 543 542 541 540 539 538 537 536 535 534 533 532 531 530 529 528 = 527 526 525 524 523 522 521 520 519 518 517 516 515 514 513 512 511 510 509= 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 49= 0 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 4= 71 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 = 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434= 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 41= 5 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 3= 96 395 394 393 39 > 2 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 37= 4 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 3= 55 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 = 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318= 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 29= 9 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 2= 80 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 = 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243= 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 22= 4 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 2= 05 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 = 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168= 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 14= 9 148 147 146 145 > 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127= 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 10= 8 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86= 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61= 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36= 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11= 10 9 8 7 6 5 4 3 2 1 0=20 > --- > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 > 487 if (dumping++) { > (kgdb) bt > #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 > #1 0xc0202e73 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :316 > #2 0xc02032b1 in panic (fmt=3D0xc03edd84 "from debugger") > at /usr/src/sys/kern/kern_shutdown.c:595 > #3 0xc014cbb9 in db_panic (addr=3D-1071517796, have_addr=3D0, count=3D-1= ,=20 > modif=3D0xdc319b3c "") at /usr/src/sys/ddb/db_command.c:435 > #4 0xc014cb59 in db_command (last_cmdp=3D0xc0463918, cmd_table=3D0xc0463= 758,=20 > aux_cmd_tablep=3D0xc04c0cb8) at /usr/src/sys/ddb/db_command.c:333 > #5 0xc014cc1e in db_command_loop () at /usr/src/sys/ddb/db_command.c:457 > #6 0xc014ed5b in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_tr= ap.c:71 > #7 0xc03b84ce in kdb_trap (type=3D12, code=3D0, regs=3D0xdc319c90) > at /usr/src/sys/i386/i386/db_interface.c:158 > #8 0xc03c8e14 in trap_fatal (frame=3D0xdc319c90, eva=3D0) > at /usr/src/sys/i386/i386/trap.c:969 > #9 0xc03c8aed in trap_pfault (frame=3D0xdc319c90, usermode=3D0, eva=3D0) > at /usr/src/sys/i386/i386/trap.c:867 > #10 0xc03c8667 in trap (frame=3D{tf_fs =3D 16, tf_es =3D -600768496, tf_d= s =3D 16,=20 > tf_edi =3D -1048332032, tf_esi =3D 6422528, tf_ebp =3D -600728360,= =20 > tf_isp =3D -600728388, tf_ebx =3D 0, tf_edx =3D 6756410, tf_ecx =3D= 0,=20 > tf_eax =3D 0, tf_trapno =3D 12, tf_err =3D 0, tf_eip =3D -107151779= 6, tf_cs =3D 8,=20 > tf_eflags =3D 66199, tf_esp =3D -1048331972, tf_ss =3D -1048331972}) > at /usr/src/sys/i386/i386/trap.c:466 > #11 0xc021ef9c in m_freem (m=3D0x0) at /usr/src/sys/kern/uipc_mbuf.c:706 > ---Type to continue, or q to quit--- > #12 0xc0273a0f in tcp_respond (tp=3D0x0, ipgen=3D0xc183b93c, th=3D0xc183b= 950,=20 > m=3D0xc183b900, ack=3D2100704027, seq=3D0, flags=3D20) > at /usr/src/sys/netinet/tcp_subr.c:396 > #13 0xc0271eff in tcp_input (m=3D0xc183b900, off0=3D20, proto=3D6) > at /usr/src/sys/netinet/tcp_input.c:2204 > #14 0xc026b874 in ip_input (m=3D0xc183b900) > at /usr/src/sys/netinet/ip_input.c:821 > #15 0xc026b8d3 in ipintr () at /usr/src/sys/netinet/ip_input.c:842 > #16 0xc03ba809 in swi_net_next () > #17 0xc0224929 in connect (p=3D0xd86e1f20, uap=3D0xdc319f80) > at /usr/src/sys/kern/uipc_syscalls.c:396 > #18 0xc03c90f5 in syscall2 (frame=3D{tf_fs =3D 47, tf_es =3D 47, tf_ds = =3D 47,=20 > tf_edi =3D 22273, tf_esi =3D 3, tf_ebp =3D -1077938064, tf_isp =3D = -600727596,=20 > tf_ebx =3D 671650276, tf_edx =3D -1077938288, tf_ecx =3D 13, tf_eax= =3D 98,=20 > tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D 672133692, tf_cs =3D 31,= =20 > tf_eflags =3D 659, tf_esp =3D -1077938252, tf_ss =3D 47}) > at /usr/src/sys/i386/i386/trap.c:1175 > #19 0xc03b93a5 in Xint0x80_syscall () > #20 0x2806fcbd in ?? () > #21 0x8048d88 in ?? () > #22 0x8048add in ?? () > (kgdb) frame 12 > #12 0xc0273a0f in tcp_respond (tp=3D0x0, ipgen=3D0xc183b93c, th=3D0xc183b= 950,=20 > m=3D0xc183b900, ack=3D2100704027, seq=3D0, flags=3D20) > at /usr/src/sys/netinet/tcp_subr.c:396 > 396 m_freem(m->m_next); > (kgdb) print m > $1 =3D (struct mbuf *) 0xc183b900 > (kgdb) print m->m_hdr.mh_next > $2 =3D (struct mbuf *) 0x0 > (kgdb) frame 11 > #11 0xc021ef9c in m_freem (m=3D0x0) at /usr/src/sys/kern/uipc_mbuf.c:706 > 706 if (mcl_pool_now < mcl_pool_max && m->m_next =3D=3D NULL = && > (kgdb)=20 >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message >=20 --=20 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 Sat Aug 10 19:55: 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 C533837B400 for ; Sat, 10 Aug 2002 19:54:58 -0700 (PDT) Received: from patrocles.silby.com (d161.as14.nwbl0.wi.voyager.net [169.207.136.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5939443E6A for ; Sat, 10 Aug 2002 19:54:57 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.5/8.12.5) with ESMTP id g7B2wUB1062980; Sat, 10 Aug 2002 21:58:30 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.5/8.12.5/Submit) with ESMTP id g7B2wROX062977; Sat, 10 Aug 2002 21:58:28 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Sat, 10 Aug 2002 21:58:27 -0500 (CDT) From: Mike Silbersack To: Oleg Polyakov Cc: freebsd-net@freebsd.org Subject: Re: Initial congestion window increase In-Reply-To: <20020809201429.56558.qmail@web10407.mail.yahoo.com> Message-ID: <20020810215044.O62906-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 9 Aug 2002, Oleg Polyakov wrote: > Here is a patch allowing to increase TCP's initial congestion > window up to 4 mss but less then 4380 bytes as specified in > experimental RFC 2414 and draft-ietf-tsvwg-initwin-04.txt. > It doesn't touch idle congestion window as per draft. Despite this change being in an RFC, I'm not sure that it's really worth implementing. While increasing the slowstart flightsize might do wonders for benchmarks of short connections, the actual effect on real world tests seems much more murky. I believe that there _is_ an argument for using mss * 2 as the default flightsize, however. Supposedly, some OSes using delayed ACKs will delay the first ack, causing a 200ms delay which can really slow down the transfer of small web pages / etc. If you can find (tcpdump) evidence to back this up, I could agree with raising the value to 2 * mss. Beyond that, however, seems like a cheap way to inflate benchmarks and cause congestion. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Aug 10 21:37: 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 074B037B400 for ; Sat, 10 Aug 2002 21:36:59 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD79543E3B for ; Sat, 10 Aug 2002 21:36:58 -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 <0H0N0076AWTMDO@mta5.snfc21.pbi.net> for freebsd-net@freebsd.org; Sat, 10 Aug 2002 21:36:58 -0700 (PDT) Date: Sat, 10 Aug 2002 21:38:36 -0700 From: Jeffrey Hsu Subject: Re: Initial congestion window increase In-reply-to: Message from Mike Silbersack "of Sat, 10 Aug 2002 21:58:27 CDT." <20020810215044.O62906-100000@patrocles.silby.com> To: Mike Silbersack Cc: Oleg Polyakov , freebsd-net@freebsd.org Message-id: <0H0N0076BWTMDO@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 There are a couple more places you have to change if you really want to implement that RFC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message