From owner-freebsd-net Wed Nov 10 5:57:26 1999 Delivered-To: freebsd-net@freebsd.org Received: from dwarpal.wipsys.soft.net (dwarpal.wipsys.soft.net [164.164.127.8]) by hub.freebsd.org (Postfix) with SMTP id B131D1525B for ; Wed, 10 Nov 1999 05:57:11 -0800 (PST) (envelope-from muthu@wipro.wipsys.soft.net) Received: by dwarpal.wipsys.soft.net (SMI-8.6/SMI-SVR4) id TAA14991; Wed, 10 Nov 1999 19:22:56 +0530 Received: from ace.wipsys.soft.net(164.164.29.18) by dwarpal.wipsys.soft.net via smap (V2.1) id xma014974; Wed, 10 Nov 99 19:22:52 +0530 Received: from benz.wipsys.soft.net ([164.164.27.140]) by ace.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA3DEE for ; Wed, 10 Nov 1999 19:26:09 +0530 Received: from sidcgw.wipsys.soft.net ([164.164.27.8]) by benz.wipsys.soft.net (Netscape Messaging Server 3.6) with ESMTP id AAA216D for ; Wed, 10 Nov 1999 19:32:44 +0530 Received: from wipro.wipsys.sequent.com (wipro.wipsys.sequent.com [192.84.36.6]) by sidcgw.wipsys.soft.net (8.8.5/8.8.5) with ESMTP id TAA18183 for ; Wed, 10 Nov 1999 19:20:01 +0530 Received: (from muthu@localhost) by wipro.wipsys.sequent.com (8.8.5/8.8.5) id TAA03656; Wed, 10 Nov 1999 19:26:54 +0530 (IST) From: G Muthukumar Message-Id: <199911101356.TAA03656@wipro.wipsys.sequent.com> Subject: BIND 8.2.x - IRS, newer resolver functions To: freebsd-net@freebsd.org Date: Wed, 10 Nov 1999 19:26:54 +0530 (IST) Cc: muthu@wipro.wipsys.soft.net (G Muthukumar) X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, With the availability of BIND 8.2.x, is there any plan of integrating the newer resolver functions (e.g.: res_nquery as against the deprecated res_query) & name resolution through IRS (instead of/in addition to /etc/host.conf) into the standard library? If this is not considered due to some valid reasons, would it be possible for me to get those reasons? Any pointers are also welcome. Thanks, Muthu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 10 7: 4:28 1999 Delivered-To: freebsd-net@freebsd.org Received: from isite.voyagertec.com (isite.voyagertec.com [206.125.235.10]) by hub.freebsd.org (Postfix) with ESMTP id 6E51D14E1F for ; Wed, 10 Nov 1999 07:04:23 -0800 (PST) (envelope-from vkosmac@voyagertec.com) Received: from vince_svr ([206.125.235.30]) by isite.voyagertec.com (8.9.1/8.9.1) with SMTP id KAA19898 for ; Wed, 10 Nov 1999 10:04:15 -0500 Message-ID: <002d01bf2b8e$ee857fa0$1eea6bce@vince_svr.travauto.com> From: "Vince Kosmac" To: Subject: Help with MAX sockets Date: Wed, 10 Nov 1999 10:19:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01BF2B65.058AB190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_002A_01BF2B65.058AB190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know the resource requirements for a single BSD=20 socket ? I am tring to open 2,000 sockets on a single machine with=20 512meg of ram. I can only get 648 sockets before it locks up. I did a = "top' command while running a few sockets and noticed the socket=20 program used 888k of space with 400k resident. It there any place=20 to configure the kernel (header files) to get this size down. I set the = MAXUSERS to 2,000 on a kernel rebuild with no luck. Can anyone=20 help ? Thankx, Vince Kosmac vkosmac@voyagertec.com 407-261-8515 ------=_NextPart_000_002A_01BF2B65.058AB190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
   Does anyone know the resource requirements for a = single BSD=20
socket ?   I am tring to open 2,000 sockets on a single = machine=20 with
512meg of ram.   I can only get 648 sockets before it = locks=20 up.  I did a
"top' command  while running a few sockets and noticed = the socket=20
program used 888k of space with 400k resident.   It there = any=20 place
to configure the kernel (header files) to get this size down.  = I set=20 the
MAXUSERS to 2,000 on a kernel rebuild with no luck.  Can = anyone
help ?
 
Thankx,
Vince Kosmac
407-261-8515
------=_NextPart_000_002A_01BF2B65.058AB190-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 10 7:34:24 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 57F1414DDA for ; Wed, 10 Nov 1999 07:34:17 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11lZl5-0001ep-00; Wed, 10 Nov 1999 08:34:04 -0700 Message-ID: <3829906B.30933903@softweyr.com> Date: Wed, 10 Nov 1999 08:34:03 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: G Muthukumar Cc: freebsd-net@FreeBSD.ORG Subject: Re: BIND 8.2.x - IRS, newer resolver functions References: <199911101356.TAA03656@wipro.wipsys.sequent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org G Muthukumar wrote: > > Hi all, > > With the availability of BIND 8.2.x, is there any plan of integrating > the newer resolver functions (e.g.: res_nquery as against the deprecated > res_query) & name resolution through IRS (instead of/in addition to > /etc/host.conf) into the standard library? Standard answer #1: we await your patches. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 10 14:12: 3 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id A9DC8153CD; Wed, 10 Nov 1999 14:11:51 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id QAA12891; Wed, 10 Nov 1999 16:11:50 -0600 (CST) From: Mohit Aron Message-Id: <199911102211.QAA12891@cs.rice.edu> Subject: FreeBSD networking problems To: freebsd-net@freebsd.org, wollman@freebsd.org, jlemon@freebsd.org, julian@freebsd.org, ee@freebsd.org, bright@wintelcom.net Date: Wed, 10 Nov 1999 16:11:49 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I've noticed several problems in networking performance in FreeBSD wrt WAN conditions in the course of my experiments. I mailed them to Alfred Perlstein who suggested that I post them to this list. I'm listing them below. Problems with WAN emulation in lab environments: 1) FreeBSD tries to determine the max size of socket buffers from cached routing information. This is done even after an application wants to set the application buffer to a large value. The result is that you usually end up having a socket buffer size that you got from an earlier TCP connection (say telnet) which is usually very small. The code is related to the 'ifdef RTV_SPIPE' and 'ifdef RTV_RPIPE' in sys/netinet/tcp_input.c. For my experiments, I usually undefine RTV_SPIPE and RTV_RPIPE in tcp_input.c. A more complete discussion is given in a PR that I filed a while back and can be viewed from: http://www.freebsd.org/cgi/query-pr.cgi?pr=11966 2) TCP Bug - the FreeBSD implementation does not scale the advertised window immediately when it discovers that window scaling is being used. The result is that irrespective of advertised window, in the first round-trip after connection establishment, a FreeBSD TCP sender cannot send more data than the unscaled value of advertised window. The fix is the following patch to tcp_input.c (taken from FreeBSD-3.3-RELEASE): --- /sys/netinet/tcp_input.c Sun Aug 29 11:29:54 1999 +++ tcp_input.c Wed Nov 10 15:39:49 1999 @@ -857,6 +857,9 @@ (TF_RCVD_SCALE|TF_REQ_SCALE)) { tp->snd_scale = tp->requested_s_scale; tp->rcv_scale = tp->request_r_scale; + + tp->snd_wnd <<= tp->snd_scale; + tiwin = tp->snd_wnd; } /* Segment is acceptable, update cache if undefined. */ if (taop->tao_ccsent == 0) One can argue that this is not important given that TCP does slow-start in the first round-trip. Well, people are looking at rate-based pacing where you don't have to do slow-start. Also the above is important in LANs where FreeBSD doesn't use slow-start. In my case, I'm emulating a WAN to see the benefits of rate-based pacing and so is extremely important. 3) sbappend is unscalable. I've earlier posted this on freebsd-net and can be obtained from the archive from: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=58270+0+archive/1999/freebsd-net/19991010.freebsd-net Here's a suggested fix. Maintain one additional pointer to the last pkt in the send socket buffer (Alfred alreay has a patch for this available from http://www.freebsd.org/~alfred/sockbuf-3.3-release.diff). However, this is not sufficient because for TCP, the data is maintained in a single chain of mbufs headed by a single packet header mbuf. Thus an additional pointer in each packet header mbuf is needed. Perhaps the m_pkthdr.rcvif field can be used for this purpose - this field is not used for outbound packets. One can modify the mbuf data structure to replace this field with a union whose other element has a name like m_pkttail. Otherwise if increasing the length of the data structure is not a concern, then perhaps a completely new field can be added that can perhaps allow mbufs to be mainted in a Tailq. 4) FreeBSD-3.x onwards introduced a limit on the maximum number of sockets (can be viewed with 'sysctl kern.ipc.maxsockets' - its typically less than 5000 and depends upon MAXUSERS). The reason for this limit was the new zone allocator scheme introduced in FreeBSD-3.x. I've shown in a prior paper (http://www.cs.rice.edu/~aron/papers/rice-TR99-335.ps.gz) that a busy webserver can have upto 50000 open connections and so having just 5000 sockets is going to have dismal performance with servers. The big number is due to connections in TCP TIME_WAIT state. The paper above also proposes an alternate fix where the TIME_WAIT state operates with minimal amount of state. 5) The interface queues need to be increased from the default of 50 packets (defined as IFQ_MAXLEN in sys/net/if.h). I normally increase this value to 1000. A busy webserver can easily overflow the default of 50. It is also important for my lab tests with WAN conditions (although this is not a case for increasing it in the general FreeBSD distribution). Consider a 100Mbps link with a round-trip delay of 100ms. It can hold upto 833 packets. In a lab environment, these can be queued up in the driver and thus the need for higher interface queue. Additionally FreeBSD-3.x introduced a change to the fxp driver (in sys/pci/if_fxp.c) where it ignores the IFQ_MAXLEN setting for the output driver queue and instead sets it to the number of its own transmit buffers (127 by default). I think this feature should be removed - the older FreeBSD-2.2.x used to only put more pkts (> 127) in the driver once there was room - all others were queued up in the interface queue whose length was determined by IFQ_MAXLEN. 6) The value of SB_MAX (defined in sys/sys/socketvar.h) needs to be increased from the default of 256K. In my WAN experiments, the bandwidth-delay product was 1250K - I think SB_MAX should be increased to at least this value because high bandwidths in WANs are just around the corner. Moreover, having this value of SB_MAX doesn't mean that this memory is going to be reserved for each socket - only that applications that need such memory can use it. I earlier posted some additional tuning parameters wrt running webservers on FreeBSD. These are available from: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=131178+0+archive/1999/freebsd-net/19990725.freebsd-net - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Nov 10 14:47:40 1999 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8292B14DCA for ; Wed, 10 Nov 1999 14:47:33 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id QAA28991; Wed, 10 Nov 1999 16:14:10 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Wed, 10 Nov 1999 16:14:10 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: G Muthukumar Cc: freebsd-net@freebsd.org Subject: Re: BIND 8.2.x - IRS, newer resolver functions In-Reply-To: <199911101356.TAA03656@wipro.wipsys.sequent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We should wait for BIND9, which will have quite a big change in resolver interface (asynchronous support, threading, DNSsec, etc). Jan 31 is the date for the beta release. On Wed, 10 Nov 1999, G Muthukumar wrote: > Hi all, > > With the availability of BIND 8.2.x, is there any plan of integrating > the newer resolver functions (e.g.: res_nquery as against the deprecated > res_query) & name resolution through IRS (instead of/in addition to > /etc/host.conf) into the standard library? > > If this is not considered due to some valid reasons, would it be > possible for me to get those reasons? Any pointers are also welcome. > > Thanks, > Muthu > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 6:34:51 1999 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id C076514E49; Fri, 12 Nov 1999 06:34:40 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.2/8.9.2) id PAA05210; Fri, 12 Nov 1999 15:35:01 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <199911121435.PAA05210@info.iet.unipi.it> Subject: Re: FreeBSD networking problems In-Reply-To: <199911102211.QAA12891@cs.rice.edu> from Mohit Aron at "Nov 10, 1999 4:11:49 pm" To: aron@cs.rice.edu (Mohit Aron) Date: Fri, 12 Nov 1999 15:35:00 +0100 (CET) Cc: freebsd-net@FreeBSD.ORG, wollman@FreeBSD.ORG, jlemon@FreeBSD.ORG, julian@FreeBSD.ORG, ee@FreeBSD.ORG, bright@wintelcom.net X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To respond to some interesting points: > I've noticed several problems in networking performance in FreeBSD wrt > WAN conditions in the course of my experiments. I mailed them to Alfred ... > Problems with WAN emulation in lab environments: > > 1) FreeBSD tries to determine the max size of socket buffers from cached related issue -- kern.ipc.maxsockbuf can also be a source of problem. It bounds the gross amount of buffer space used by a socket -- this means if you allocate a 2KB cluster and only use it to hold a small packet (e.g. 512 bytes) your gross amount of buffer space is charged the full 2KB and the kern.ipc.maxsockbuf limit might hit before net.inet.tcp.sendspace (or however you override it with the setsockopt() calls) > 5) The interface queues need to be increased from the default of 50 packets > (defined as IFQ_MAXLEN in sys/net/if.h). I normally increase this value to > 1000. A busy webserver can easily overflow the default of 50. i think the two of us already discussed this. I don't think this is a particularly good idea, especially: > It is also important for my lab tests with WAN conditions (although this is > not a case for increasing it in the general FreeBSD distribution). Consider > a 100Mbps link with a round-trip delay of 100ms. It can hold upto 833 > packets. In a lab environment, these can be queued up in the driver and thus the RTT has nothing to do with the device driver queue. If a packet is held in the device driver queue, it means that the device is temporarily unable to transmit for some time, this is a local problem, and the driver itself should immediately report a failure upstream (e.g. in ip_output(), i think this is already implemented by checking IF_QFULL The 833 pkts you mention do need to be stored somewhere, but this is in the socket buffer, not on the device queue. > change to the fxp driver (in sys/pci/if_fxp.c) where it ignores the > IFQ_MAXLEN setting for the output driver queue and instead sets it to the > number of its own transmit buffers (127 by default). I think this feature > should be removed - the older FreeBSD-2.2.x used to only put more pkts (> agreed -- probably, at least if you want to use ALTQ or other forms of active queue management, this is an annoying feature. > 6) The value of SB_MAX (defined in sys/sys/socketvar.h) needs to be > increased from the default of 256K. In my WAN experiments, the this is controlled by sysctl kern.ipc.maxsockbuf -- so easily customizable that you don't really need to change the source. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 6:49:12 1999 Delivered-To: freebsd-net@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id ACE7614EB3 for ; Fri, 12 Nov 1999 06:48:49 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id CF6271C6D; Fri, 12 Nov 1999 22:48:47 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Robert Watson Cc: G Muthukumar , freebsd-net@freebsd.org Subject: Re: BIND 8.2.x - IRS, newer resolver functions In-reply-to: Your message of "Wed, 10 Nov 1999 16:14:10 EST." Date: Fri, 12 Nov 1999 22:48:47 +0800 From: Peter Wemm Message-Id: <19991112144847.CF6271C6D@overcee.netplex.com.au> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson wrote: > > We should wait for BIND9, which will have quite a big change in resolver > interface (asynchronous support, threading, DNSsec, etc). Jan 31 is the > date for the beta release. I'm really frightened by 8.2.2.x - the inbuilt crypto used by res_*() in libc, the root exploit rate, etc don't exactly give me the warm fuzzies. 8.1.2 has known DoS's, but that's not as bad as known root exploits. I've attempted to do an update to 8.2.2 a few times and run into trouble with the crypto code and libc. How would people react to libc supporting *only* "files" and "irpd" (ie: no dns or yp). The IRP lookup method asks a local parallel caching daemon to do the lookups on it's behalf, be they DNS, NIS, NISPLUS, etc. It also means we could confine the crypto to userland programs and get a fair amount of stuff out of libc. It also means we can do resolver plugins (irpd is dynamic) even in static binaries (since they don't use dlopen). Don't panic, I'm just asking aloud to get some feel for what folks want. > On Wed, 10 Nov 1999, G Muthukumar wrote: > > > Hi all, > > > > With the availability of BIND 8.2.x, is there any plan of integrating > > the newer resolver functions (e.g.: res_nquery as against the deprecated > > res_query) & name resolution through IRS (instead of/in addition to > > /etc/host.conf) into the standard library? > > > > If this is not considered due to some valid reasons, would it be > > possible for me to get those reasons? Any pointers are also welcome. > > > > Thanks, > > Muthu > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > Robert N M Watson Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 8:42:24 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 13A0214D57; Fri, 12 Nov 1999 08:42:11 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id KAA29642; Fri, 12 Nov 1999 10:42:07 -0600 (CST) From: Mohit Aron Message-Id: <199911121642.KAA29642@cs.rice.edu> Subject: Re: FreeBSD networking problems To: luigi@info.iet.unipi.it (Luigi Rizzo) Date: Fri, 12 Nov 1999 10:42:07 -0600 (CST) Cc: freebsd-net@freebsd.org, wollman@freebsd.org, jlemon@freebsd.org, julian@freebsd.org, bright@wintelcom.net In-Reply-To: <199911121435.PAA05210@info.iet.unipi.it> from "Luigi Rizzo" at Nov 12, 99 03:35:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > i think the two of us already discussed this. I don't think this is a > particularly good idea, especially: > Well, 50 is too small. I needed 1000 for my WAN experiments, but the number should be increased nevertheless. It overflows even in my regular tests with the apache server. I think we agreed earlier that some testing might be needed to determine what the increment should be. > > It is also important for my lab tests with WAN conditions (although this is > > not a case for increasing it in the general FreeBSD distribution). Consider > > a 100Mbps link with a round-trip delay of 100ms. It can hold upto 833 > > packets. In a lab environment, these can be queued up in the driver and thus > > the RTT has nothing to do with the device driver queue. > As you said, the 833 packets need to be stored somewhere and you're also right that the place is the socket buffer queue. But TCP can be bursty during its operating specially when it gets big ACKs (or closely spaced ACKs that don't allow enough time to execute application code that can put more data in the socket buffers - see the paper http://www.cs.rice.edu/~aron/papers/soft-timers.ps.gz). This means occasionally, TCP would send a burst and there will be temporary queuing needed in the drivers. In one of my experiments, slow-start was turned off and thus there was a burst even in the first round-trip - driver queuing was needed here. > > 6) The value of SB_MAX (defined in sys/sys/socketvar.h) needs to be > > increased from the default of 256K. In my WAN experiments, the > > this is controlled by sysctl kern.ipc.maxsockbuf -- so easily customizable > that you don't really need to change the source. Well, I'm asking for the default to be increased. People who know enough about FreeBSD can anyway tune it up. The default is useful for those who don't know much about FreeBSD or tuning it for networking. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 8:56:55 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (snickers.org [216.126.90.2]) by hub.freebsd.org (Postfix) with ESMTP id A625414C90 for ; Fri, 12 Nov 1999 08:56:39 -0800 (PST) (envelope-from josh@snickers.org) Received: by mail.snickers.org (Postfix, from userid 1037) id B0B433D15; Fri, 12 Nov 1999 11:56:35 -0500 (EST) Date: Fri, 12 Nov 1999 11:56:35 -0500 From: Josh Tiefenbach To: freebsd-net@freebsd.org Subject: Problems using ppp(8) and PPPoE Message-ID: <19991112115635.B88559@snickers.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm having some problems using the newly integrated PPPoE features of ppp(8). Essentially, when I fire up ppp(8) in interactive mode, and try to enter the command 'dial' (after reading the default profile), I get the message: Cannot create PPPoE netgraph node: no such file or directory which I note is in ether.c:ether_Create() I've compiled in netgraph support to my kernel via the following config options: options NETGRAPH options NETGRAPH_SOCKET options NETGRAPH_PPPOE I previously tried running with just the netgraph kld's, but I got "cannot send netgraph message" errors, so I just compiled the thing into the kernel. Since my -current source tree dates from ~Nov 7ish, I wonder if a fix has gone in since. However, since I need PPPoE support to get that particular machine online, I havent had a chance to jump through various hoops to get it up to date. Any suggestions? josh -- "To succeed in the world, it is not enough to be stupid, you must also be well-mannered" -- Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 9:33:35 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 4EE8D14F8B for ; Fri, 12 Nov 1999 09:33:19 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id JAA17111; Fri, 12 Nov 1999 09:33:07 -0800 (PST) Date: Fri, 12 Nov 1999 09:33:06 -0800 (PST) From: Julian Elischer To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re: Problems using ppp(8) and PPPoE In-Reply-To: <19991112115635.B88559@snickers.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org you need today's if_ethersubr.c you also need a new ng_base.c and ng_pppoe.c and ng_socket.c (I think) On Fri, 12 Nov 1999, Josh Tiefenbach wrote: > I'm having some problems using the newly integrated PPPoE features of ppp(8). > Essentially, when I fire up ppp(8) in interactive mode, and try to enter the > command 'dial' (after reading the default profile), I get the message: > > Cannot create PPPoE netgraph node: no such file or directory > > which I note is in ether.c:ether_Create() > > I've compiled in netgraph support to my kernel via the following config > options: > > options NETGRAPH > options NETGRAPH_SOCKET > options NETGRAPH_PPPOE this is good, but you may need newer versions of those files. > > I previously tried running with just the netgraph kld's, but I got "cannot > send netgraph message" errors, so I just compiled the thing into the kernel. > > Since my -current source tree dates from ~Nov 7ish, I wonder if a fix has gone > in since. However, since I need PPPoE support to get that particular machine > online, I havent had a chance to jump through various hoops to get it up to > date. > > Any suggestions? > > josh > > -- > "To succeed in the world, it is not enough to be stupid, you must also be > well-mannered" -- Voltaire > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 17:57:36 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (snickers.org [216.126.90.2]) by hub.freebsd.org (Postfix) with ESMTP id 6CB21150D7 for ; Fri, 12 Nov 1999 17:57:31 -0800 (PST) (envelope-from josh@snickers.org) Received: by mail.snickers.org (Postfix, from userid 1037) id 16BF73D16; Fri, 12 Nov 1999 20:57:30 -0500 (EST) Date: Fri, 12 Nov 1999 20:57:29 -0500 From: Josh Tiefenbach To: Julian Elischer Cc: freebsd-net@freebsd.org Subject: Re: Problems using ppp(8) and PPPoE Message-ID: <19991112205729.A5549@snickers.org> References: <19991112115635.B88559@snickers.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Nov 12, 1999 at 09:33:06AM -0800, Julian Elischer wrote: > you need today's if_ethersubr.c > you also need a new ng_base.c and ng_pppoe.c and ng_socket.c > (I think) Hrmm. That seems to have solved the "Cant create PPPoE node" problem, but now I got another one. ppp(8) never seems to do any PPPoE discovery negotiation. This snippet from /var/log/ppp.log is quite descriptive: (results after typing in dial at ppp interactive prompt. Other than the set log line, I'm using: set device PPPoE:de0 set authname bar set authkey foo add default HISADDR ) Nov 12 20:49:31 cerebus ppp[2096]: tun0: Command: /dev/tty: dial Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: bundle: Establish Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: deflink: closed -> opening Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: List of netgraph node ``de0:'' ( id 1) hooks: Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: Creating PPPoE netgraph node [1] :orphans -> ethernet Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: Connecting netgraph socket .:tun 0 -> de0:orphans:tun0 Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: deflink: Connected! Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: deflink: opening -> dial Nov 12 20:49:31 cerebus ppp[2096]: tun0: Chat: deflink: Dial attempt 1 of 1 Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: deflink: dial -> carrier Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: Waiting for carrier Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: deflink: Disconnected! Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: deflink: carrier -> hangup Nov 12 20:49:32 cerebus ppp[2096]: tun0: Debug: deflink: Close Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: deflink: Connect time: 1 secs: 0 octets in, 0 octets out Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: total 0 bytes/sec, peak 0 bytes /sec on Fri Nov 12 20:49:32 1999 Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: deflink: hangup -> closed I'm using a snapshot of /usr/src/usr.sbin/ppp from ~1800EDT today, but specific version numbers avail on request. Any more suggestions? josh -- "To succeed in the world, it is not enough to be stupid, you must also be well-mannered" -- Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 19:12:43 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8BCB414D4D for ; Fri, 12 Nov 1999 19:12:36 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA33087; Fri, 12 Nov 1999 19:12:34 -0800 (PST) Date: Fri, 12 Nov 1999 19:12:33 -0800 (PST) From: Julian Elischer To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re: Problems using ppp(8) and PPPoE In-Reply-To: <19991112205729.A5549@snickers.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, While you are running it, try having the following run as well and send me the result.. tcpdump -nev -s 256 ether proto 0x8863 or ether proto 0x8864 this should be in the documentation I think.... The pppoe negotiation occurs entirely within the pppoe netgraph node so the ppp log can't give too much info.... What service does your ISP want you to request on the wire? (You have a null service, that is legal but some ISPs want you to actually ask for a particular one.) it's PPPoE:de0:service julian On Fri, 12 Nov 1999, Josh Tiefenbach wrote: > On Fri, Nov 12, 1999 at 09:33:06AM -0800, Julian Elischer wrote: > > you need today's if_ethersubr.c > > you also need a new ng_base.c and ng_pppoe.c and ng_socket.c > > (I think) > > Hrmm. That seems to have solved the "Cant create PPPoE node" problem, but now > I got another one. ppp(8) never seems to do any PPPoE discovery negotiation. > This snippet from /var/log/ppp.log is quite descriptive: > > (results after typing in dial at ppp interactive prompt. Other than the set > log line, I'm using: > > set device PPPoE:de0 > set authname bar > set authkey foo > add default HISADDR > > ) > > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Command: /dev/tty: dial > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: bundle: Establish > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: deflink: closed -> opening > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: List of netgraph node ``de0:'' ( > id 1) hooks: > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: Creating PPPoE netgraph node [1] > :orphans -> ethernet > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: Connecting netgraph socket .:tun > 0 -> de0:orphans:tun0 > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: deflink: Connected! > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: deflink: opening -> dial > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Chat: deflink: Dial attempt 1 of 1 > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Phase: deflink: dial -> carrier > Nov 12 20:49:31 cerebus ppp[2096]: tun0: Debug: Waiting for carrier > Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: deflink: Disconnected! > Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: deflink: carrier -> hangup > Nov 12 20:49:32 cerebus ppp[2096]: tun0: Debug: deflink: Close > Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: deflink: Connect time: 1 secs: 0 > octets in, 0 octets out > Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: total 0 bytes/sec, peak 0 bytes > /sec on Fri Nov 12 20:49:32 1999 > Nov 12 20:49:32 cerebus ppp[2096]: tun0: Phase: deflink: hangup -> closed > > I'm using a snapshot of /usr/src/usr.sbin/ppp from ~1800EDT today, but > specific version numbers avail on request. > > Any more suggestions? > > josh > > -- > "To succeed in the world, it is not enough to be stupid, you must also be > well-mannered" -- Voltaire > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 20:19:34 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (snickers.org [216.126.90.2]) by hub.freebsd.org (Postfix) with ESMTP id 6BB4714C8A for ; Fri, 12 Nov 1999 20:19:31 -0800 (PST) (envelope-from josh@snickers.org) Received: by mail.snickers.org (Postfix, from userid 1037) id 7774B3D16; Fri, 12 Nov 1999 23:19:30 -0500 (EST) Date: Fri, 12 Nov 1999 23:19:30 -0500 From: Josh Tiefenbach To: Julian Elischer Cc: Josh Tiefenbach , freebsd-net@FreeBSD.ORG Subject: Re: Problems using ppp(8) and PPPoE Message-ID: <19991112231930.A8235@snickers.org> References: <19991112205729.A5549@snickers.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Nov 12, 1999 at 07:12:33PM -0800, Julian Elischer wrote: > Well, While you are running it, > try having the following run as well and send me the result.. > > tcpdump -nev -s 256 ether proto 0x8863 or ether proto 0x8864 Your command is my command: cerebus:~# tcpdump -nev -s 256 -i de0 ether proto 0x8863 or ether proto 0x8864 tcpdump: listening on de0 22:54:10.981103 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 32: 1109 0000 000c 0103 0004 006b aac0 0101 0000 22:54:12.024914 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 32: 1109 0000 000c 0103 0004 006b aac0 0101 0000 I think I may have an idea. You are sending a Host-Uniq tag in the PADI. I have this funny feeling that my ISP doesnt like that. I'm in the middle of running some tests to see what happens when I change pppoe_start() to not insert that tag in the PADI. (Yes. I know that this might break some things, but I want to see if my ISP actually emits a PADO in response to the modified PADI) > What service does your ISP want you to request on the wire? You know, I havent a clue. I'm currently not set up to sniff the windows client when it operating. > (You have a null service, that is legal but some ISPs want you to actually > ask for a particular one.) I know. However, based on some code I had written before, my ISP responds quite happily to a PADI containing a NULL Service-Name. Rumor has it, that my ISP (Sympatico in Canada) isn't quite on the ball when it comes to a compliant PPPoE implementation. I'll let you know what I find out. Presuming that Sympatico continues to barf on the Host-Uniq tag, are there any workarounds? josh -- "To succeed in the world, it is not enough to be stupid, you must also be well-mannered" -- Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 20:33: 7 1999 Delivered-To: freebsd-net@freebsd.org Received: from mail.snickers.org (snickers.org [216.126.90.2]) by hub.freebsd.org (Postfix) with ESMTP id 1FA9514C8A for ; Fri, 12 Nov 1999 20:33:05 -0800 (PST) (envelope-from josh@snickers.org) Received: by mail.snickers.org (Postfix, from userid 1037) id 503053D16; Fri, 12 Nov 1999 23:33:05 -0500 (EST) Date: Fri, 12 Nov 1999 23:33:05 -0500 From: Josh Tiefenbach To: Josh Tiefenbach Cc: Julian Elischer , freebsd-net@FreeBSD.ORG Subject: Re: Problems using ppp(8) and PPPoE Message-ID: <19991112233305.C8235@snickers.org> References: <19991112205729.A5549@snickers.org> <19991112231930.A8235@snickers.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <19991112231930.A8235@snickers.org> Organization: Hah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I think I may have an idea. You are sending a Host-Uniq tag in the PADI. I > have this funny feeling that my ISP doesnt like that. I'm in the middle of > running some tests to see what happens when I change pppoe_start() to not > insert that tag in the PADI. > > (Yes. I know that this might break some things, but I want to see if my ISP > actually emits a PADO in response to the modified PADI) Following up to myself, it looks like I was right on both counts. In removing the Host-Uniq tag, I see the following on the wire: cerebus:~# tcpdump -nev -s 256 ether proto 0x8863 or ether proto 0x8864 tcpdump: listening on de0 23:23:18.010000 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 24: 1109 0000 0004 0101 0000 23:23:18.728783 0:10:67:0:3c:ee 0:c0:f0:22:35:e1 8863 61: 1107 0000 0029 0101 0000 0102 001d 3133 3034 3130 3439 3931 3833 3632 2d73 6d73 322d 746f 726f 6e74 6f36 3301 0100 00 23:23:19.005733 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 24: 1109 0000 0004 0101 0000 23:23:19.728640 0:10:67:0:3c:ee 0:c0:f0:22:35:e1 8863 61: 1107 0000 0029 0101 0000 0102 001d 3133 3034 3130 3439 3931 3833 3632 2d73 6d73 322d 746f 726f 6e74 6f36 3301 0100 00 As you can see, I can now elicit a PADO from Sympatico. Unfortunately, it looks like removing the Host-Uniq tag breaks all that code which uses the Host-Uniq identifier to match which flow belongs to which node. Comments? josh -- "To succeed in the world, it is not enough to be stupid, you must also be well-mannered" -- Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 23: 4: 7 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 066BE14EEE for ; Fri, 12 Nov 1999 23:03:58 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA36425; Fri, 12 Nov 1999 23:03:56 -0800 (PST) Date: Fri, 12 Nov 1999 23:03:55 -0800 (PST) From: Julian Elischer To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re: Problems using ppp(8) and PPPoE In-Reply-To: <19991112231930.A8235@snickers.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ahhhh I think that isp will only ever respond to one MAC address on that line once you've done it once. so now it will onlyu respond to your WIndows machine. We had this problem in the test setup.. we had to 1/ power down the modem 2/ swap teh ethernet card from the windows machine to the Unic machine so that the MAC address moved.. (!) (BLEAH!) COmplain to your ISP LOUDLY if this is the case.... On Fri, 12 Nov 1999, Josh Tiefenbach wrote: > On Fri, Nov 12, 1999 at 07:12:33PM -0800, Julian Elischer wrote: > > Well, While you are running it, > > try having the following run as well and send me the result.. > > > > tcpdump -nev -s 256 ether proto 0x8863 or ether proto 0x8864 > > Your command is my command: > > cerebus:~# tcpdump -nev -s 256 -i de0 ether proto 0x8863 or ether proto 0x8864 > tcpdump: listening on de0 > 22:54:10.981103 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 32: > 1109 0000 000c 0103 0004 006b aac0 0101 > 0000 > 22:54:12.024914 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 32: > 1109 0000 000c 0103 0004 006b aac0 0101 > 0000 > > I think I may have an idea. You are sending a Host-Uniq tag in the PADI. I > have this funny feeling that my ISP doesnt like that. I'm in the middle of > running some tests to see what happens when I change pppoe_start() to not > insert that tag in the PADI. > > (Yes. I know that this might break some things, but I want to see if my ISP > actually emits a PADO in response to the modified PADI) > > > What service does your ISP want you to request on the wire? > > You know, I havent a clue. I'm currently not set up to sniff the windows > client when it operating. > > > (You have a null service, that is legal but some ISPs want you to actually > > ask for a particular one.) > > I know. However, based on some code I had written before, my ISP responds > quite happily to a PADI containing a NULL Service-Name. Rumor has it, that my > ISP (Sympatico in Canada) isn't quite on the ball when it comes to a compliant > PPPoE implementation. > > I'll let you know what I find out. Presuming that Sympatico continues to barf > on the Host-Uniq tag, are there any workarounds? > > josh > > -- > "To succeed in the world, it is not enough to be stupid, you must also be > well-mannered" -- Voltaire > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Nov 12 23: 7:53 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 469F714D21 for ; Fri, 12 Nov 1999 23:07:43 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA36489; Fri, 12 Nov 1999 23:07:42 -0800 (PST) Date: Fri, 12 Nov 1999 23:07:40 -0800 (PST) From: Julian Elischer To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re: Problems using ppp(8) and PPPoE In-Reply-To: <19991112233305.C8235@snickers.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 12 Nov 1999, Josh Tiefenbach wrote: > > I think I may have an idea. You are sending a Host-Uniq tag in the PADI. I > > have this funny feeling that my ISP doesnt like that. I'm in the middle of > > running some tests to see what happens when I change pppoe_start() to not > > insert that tag in the PADI. > > > > (Yes. I know that this might break some things, but I want to see if my ISP > > actually emits a PADO in response to the modified PADI) > > Following up to myself, it looks like I was right on both counts. In removing > the Host-Uniq tag, I see the following on the wire: > > cerebus:~# tcpdump -nev -s 256 ether proto 0x8863 or ether proto 0x8864 > tcpdump: listening on de0 > 23:23:18.010000 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 24: > 1109 0000 0004 0101 0000 > 23:23:18.728783 0:10:67:0:3c:ee 0:c0:f0:22:35:e1 8863 61: > 1107 0000 0029 0101 0000 0102 001d 3133 > 3034 3130 3439 3931 3833 3632 2d73 6d73 > 322d 746f 726f 6e74 6f36 3301 0100 00 > 23:23:19.005733 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 24: > 1109 0000 0004 0101 0000 > 23:23:19.728640 0:10:67:0:3c:ee 0:c0:f0:22:35:e1 8863 61: > 1107 0000 0029 0101 0000 0102 001d 3133 > 3034 3130 3439 3931 3833 3632 2d73 6d73 > 322d 746f 726f 6e74 6f36 3301 0100 00 > > As you can see, I can now elicit a PADO from Sympatico. Unfortunately, it > looks like removing the Host-Uniq tag breaks all that code which uses the > Host-Uniq identifier to match which flow belongs to which node. > > Comments? Get an ISP that follows the spec? complain loudly? since you only have one flow, you could hide the host unique in a global and pretend you found it in the PADO packet. .... If you add it back (and don't touch the windows machine, does it fail again?) > > josh > > -- > "To succeed in the world, it is not enough to be stupid, you must also be > well-mannered" -- Voltaire > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 13 0: 9: 1 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5E7B314E29 for ; Sat, 13 Nov 1999 00:08:52 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id AAA37349; Sat, 13 Nov 1999 00:08:51 -0800 (PST) Date: Sat, 13 Nov 1999 00:08:50 -0800 (PST) From: Julian Elischer To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re: Problems using ppp(8) and PPPoE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 12 Nov 1999, Julian Elischer wrote: > > > On Fri, 12 Nov 1999, Josh Tiefenbach wrote: > > > > I think I may have an idea. You are sending a Host-Uniq tag in the PADI. I > > > have this funny feeling that my ISP doesnt like that. I'm in the middle of > > > running some tests to see what happens when I change pppoe_start() to not > > > insert that tag in the PADI. > > > > > > (Yes. I know that this might break some things, but I want to see if my ISP > > > actually emits a PADO in response to the modified PADI) > > > > Following up to myself, it looks like I was right on both counts. In removing > > the Host-Uniq tag, I see the following on the wire: > > > > cerebus:~# tcpdump -nev -s 256 ether proto 0x8863 or ether proto 0x8864 > > tcpdump: listening on de0 > > 23:23:18.010000 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 24: > > 1109 0000 0004 0101 0000 > > 23:23:18.728783 0:10:67:0:3c:ee 0:c0:f0:22:35:e1 8863 61: > > 1107 0000 0029 0101 0000 0102 001d 3133 > > 3034 3130 3439 3931 3833 3632 2d73 6d73 > > 322d 746f 726f 6e74 6f36 3301 0100 00 This is the same response that the test system gave except the test system said "montreal02" instead of "toronto63". So it SHOULD work with the HOST-UNIQUE tag, especially if they are teh same router type. the SPEC says it "MUST" support and return that tag.. Maybe the system was just down at the time you first tested.. did you try the old ng_pppoe again? The test system in Montreal was down for hours (in some cases days) at a time. if you compile the base netgraph (and the socket type) into the system, then you can use kldload and kldunload to load and unload the pppoe node (but remove the 'dependency' line fom the pppoe module's makefile. it triggers a bug in the module code) > > 23:23:19.005733 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 24: > > 1109 0000 0004 0101 0000 > > 23:23:19.728640 0:10:67:0:3c:ee 0:c0:f0:22:35:e1 8863 61: > > 1107 0000 0029 0101 0000 0102 001d 3133 > > 3034 3130 3439 3931 3833 3632 2d73 6d73 > > 322d 746f 726f 6e74 6f36 3301 0100 00 > > > > As you can see, I can now elicit a PADO from Sympatico. Unfortunately, it > > looks like removing the Host-Uniq tag breaks all that code which uses the > > Host-Uniq identifier to match which flow belongs to which node. > > > > Comments? > Get an ISP that follows the spec? > > complain loudly? > > since you only have one flow, you could hide the host unique in a global > and pretend you found it in the PADO packet. .... > > If you add it back (and don't touch the windows machine, does it fail > again?) > > > > > > josh > > > > -- > > "To succeed in the world, it is not enough to be stupid, you must also be > > well-mannered" -- Voltaire > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 13 6:31:13 1999 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 32508150FE; Sat, 13 Nov 1999 06:31:02 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.2/8.9.2) id PAA12855; Sat, 13 Nov 1999 15:31:24 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <199911131431.PAA12855@info.iet.unipi.it> Subject: Re: FreeBSD networking problems In-Reply-To: <199911121642.KAA29642@cs.rice.edu> from Mohit Aron at "Nov 12, 1999 10:42: 7 am" To: aron@cs.rice.edu (Mohit Aron) Date: Sat, 13 Nov 1999 15:31:23 +0100 (CET) Cc: freebsd-net@FreeBSD.ORG, wollman@FreeBSD.ORG, jlemon@FreeBSD.ORG, julian@FreeBSD.ORG, bright@wintelcom.net X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > i think the two of us already discussed this. I don't think this is a > > particularly good idea, especially: > > Well, 50 is too small. I needed 1000 for my WAN experiments, but the number what you are saying is "i can blast packets to the interface faster than it can drain them". Which means that you are causing _congestion_ on the local interface rather than somewhere in the middle of the net (and, your burst of 1000 packets might as well go to your next-hop router where you probably won't have as much queue space for your flows). You don't solve the problem by raising the queue to 1000, because in one year your gigahertz processor will need a queue of 2000, and so on. You solve the problem by noticing that you are pumping data too fast (ip_output fails, so you do know) and pacing the output appropriately. > As you said, the 833 packets need to be stored somewhere and you're also > right that the place is the socket buffer queue. But TCP can be bursty > during its operating specially when it gets big ACKs (or closely spaced ACKs so, fix TCP, the problem is there, not elsewhere (possible fix, not terribly complex: on overflow don't cut the window as done now, just schedule a call to the output loop after 1/HZ seconds). cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 13 11:56:10 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 9E16514E57; Sat, 13 Nov 1999 11:56:07 -0800 (PST) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id NAA23932; Sat, 13 Nov 1999 13:56:03 -0600 (CST) From: Mohit Aron Message-Id: <199911131956.NAA23932@cs.rice.edu> Subject: Re: FreeBSD networking problems To: luigi@info.iet.unipi.it (Luigi Rizzo) Date: Sat, 13 Nov 1999 13:56:03 -0600 (CST) Cc: freebsd-net@freebsd.org, wollman@freebsd.org, jlemon@freebsd.org, julian@freebsd.org, bright@wintelcom.net In-Reply-To: <199911131431.PAA12855@info.iet.unipi.it> from "Luigi Rizzo" at Nov 13, 99 03:31:23 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > what you are saying is "i can blast packets to the interface faster > than it can drain them". Which means that you are causing _congestion_ > on the local interface rather than somewhere in the > middle of the net (and, your burst of 1000 packets might as well go > to your next-hop router where you probably won't have as much queue > space for your flows). No, once the interface has spaced out the packets (because of the b/w of the output link), they don't queue up at the next hop router unless the outgoing b/w is lesser than the incoming one. > so, fix TCP, the problem is there, not elsewhere (possible fix, > not terribly complex: on overflow don't cut the window as done > now, just schedule a call to the output loop after 1/HZ seconds). > I'm not disagreeing with you that TCP should never pump packets at a faster rate than the interface can handle them. Hoever, the mechanism for this is not yet in place. For example, HZ currently is 100 by default - which means you can pump packets spaced by a minimum of 10ms - you can pretty much forget about getting decent b/w at this rate (a 100Mbps link requires 120usec spacing 1500 byte packets for full utilization). You can argue that HZ can be increased, but then the overhead of hardware timer interrupts gets prohibitively large. I've proposed a software technique for achieving low overhead fine-grained timers in my SOSP '99 paper - http://www.cs.rice.edu/~aron/papers/soft-timers.ps.gz. But the default FreeBSD distribution doesn't yet have that of course. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Nov 13 23:27:58 1999 Delivered-To: freebsd-net@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7768714C83 for ; Sat, 13 Nov 1999 23:27:54 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id XAA57101; Sat, 13 Nov 1999 23:27:52 -0800 (PST) Date: Sat, 13 Nov 1999 23:27:51 -0800 (PST) From: Julian Elischer To: Josh Tiefenbach Cc: freebsd-net@FreeBSD.ORG Subject: Re: Problems using ppp(8) and PPPoE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Any news? On Sat, 13 Nov 1999, Julian Elischer wrote: > > > On Fri, 12 Nov 1999, Julian Elischer wrote: > > > > > > > On Fri, 12 Nov 1999, Josh Tiefenbach wrote: > > > > > > I think I may have an idea. You are sending a Host-Uniq tag in the PADI. I > > > > have this funny feeling that my ISP doesnt like that. I'm in the middle of > > > > running some tests to see what happens when I change pppoe_start() to not > > > > insert that tag in the PADI. > > > > > > > > (Yes. I know that this might break some things, but I want to see if my ISP > > > > actually emits a PADO in response to the modified PADI) > > > > > > Following up to myself, it looks like I was right on both counts. In removing > > > the Host-Uniq tag, I see the following on the wire: > > > > > > cerebus:~# tcpdump -nev -s 256 ether proto 0x8863 or ether proto 0x8864 > > > tcpdump: listening on de0 > > > 23:23:18.010000 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 24: > > > 1109 0000 0004 0101 0000 > > > 23:23:18.728783 0:10:67:0:3c:ee 0:c0:f0:22:35:e1 8863 61: > > > 1107 0000 0029 0101 0000 0102 001d 3133 > > > 3034 3130 3439 3931 3833 3632 2d73 6d73 > > > 322d 746f 726f 6e74 6f36 3301 0100 00 > > This is the same response that the test system gave except the test > system said "montreal02" instead of "toronto63". So it SHOULD work with > the HOST-UNIQUE tag, especially if they are teh same router type. > the SPEC says it "MUST" support and return that tag.. > > Maybe the system was just down at the time you first tested.. > did you try the old ng_pppoe again? The test system in Montreal > was down for hours (in some cases days) at a time. > > if you compile the base netgraph (and the socket type) into the system, > then you can use kldload and kldunload to load and unload the pppoe node > (but remove the 'dependency' line fom the pppoe module's makefile. it > triggers a bug in the module code) > > > > > 23:23:19.005733 0:c0:f0:22:35:e1 ff:ff:ff:ff:ff:ff 8863 24: > > > 1109 0000 0004 0101 0000 > > > 23:23:19.728640 0:10:67:0:3c:ee 0:c0:f0:22:35:e1 8863 61: > > > 1107 0000 0029 0101 0000 0102 001d 3133 > > > 3034 3130 3439 3931 3833 3632 2d73 6d73 > > > 322d 746f 726f 6e74 6f36 3301 0100 00 > > > > > > As you can see, I can now elicit a PADO from Sympatico. Unfortunately, it > > > looks like removing the Host-Uniq tag breaks all that code which uses the > > > Host-Uniq identifier to match which flow belongs to which node. > > > > > > Comments? > > Get an ISP that follows the spec? > > > > complain loudly? > > > > since you only have one flow, you could hide the host unique in a global > > and pretend you found it in the PADO packet. .... > > > > If you add it back (and don't touch the windows machine, does it fail > > again?) > > > > > > > > > > josh > > > > > > -- > > > "To succeed in the world, it is not enough to be stupid, you must also be > > > well-mannered" -- Voltaire > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message