From owner-freebsd-net Sun Jun 3 14:55:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from rhymer.cogsci.ed.ac.uk (rhymer.cogsci.ed.ac.uk [129.215.144.8]) by hub.freebsd.org (Postfix) with ESMTP id 4686737B403 for ; Sun, 3 Jun 2001 14:55:55 -0700 (PDT) (envelope-from richard@cogsci.ed.ac.uk) Received: from banks.cogsci.ed.ac.uk (banks [129.215.144.55]) by rhymer.cogsci.ed.ac.uk (8.9.3/8.9.3) with ESMTP id WAA19174 for ; Sun, 3 Jun 2001 22:55:54 +0100 (BST) Received: (from richard@localhost) by banks.cogsci.ed.ac.uk (8.9.3+Sun/8.9.3) id WAA26338 for freebsd-net@freebsd.org; Sun, 3 Jun 2001 22:55:53 +0100 (BST) Date: Sun, 3 Jun 2001 22:55:53 +0100 (BST) Message-Id: <200106032155.WAA26338@banks.cogsci.ed.ac.uk> From: Richard Tobin Subject: help with mbufs To: freebsd-net@freebsd.org Organization: just say no Sender: owner-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 working on a (user-mode) driver for the Alcatel Speedtouch USB ADSL modem. It works, but the process that relays PPP packets to the ppp program sometimes gets ENOBUFS when writing to the it (via a SOCK_DGRAM socketpair). I tried increasing kern.ipc.nmbclusters (from 1024 to 4096) and kern.ipc.nmbufs (from 4096 to 16384) but this doesn't help. Then I looked at the output of netstat -m: $ netstat -m 69/128/16384 mbufs in use (current/peak/max): 66 mbufs allocated to data 3 mbufs allocated to packet headers 64/94/4096 mbuf clusters in use (current/peak/max) 220 Kbytes allocated to network (1% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines I expected that after getting ENOBUFS, the peak value would be equal to the maximum. Does something else limit the number of mbufs available? -- Richard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 3 16:42:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from rhymer.cogsci.ed.ac.uk (rhymer.cogsci.ed.ac.uk [129.215.144.8]) by hub.freebsd.org (Postfix) with ESMTP id 29E7037B403 for ; Sun, 3 Jun 2001 16:42:16 -0700 (PDT) (envelope-from richard@cogsci.ed.ac.uk) Received: from banks.cogsci.ed.ac.uk (banks [129.215.144.55]) by rhymer.cogsci.ed.ac.uk (8.9.3/8.9.3) with ESMTP id AAA20249; Mon, 4 Jun 2001 00:42:14 +0100 (BST) Received: (from richard@localhost) by banks.cogsci.ed.ac.uk (8.9.3+Sun/8.9.3) id AAA26639; Mon, 4 Jun 2001 00:42:14 +0100 (BST) Date: Mon, 4 Jun 2001 00:42:14 +0100 (BST) Message-Id: <200106032342.AAA26639@banks.cogsci.ed.ac.uk> From: Richard Tobin Subject: Re: help with mbufs To: Richard Tobin , freebsd-net@FreeBSD.ORG In-Reply-To: Richard Tobin's message of Sun, 3 Jun 2001 22:55:53 +0100 (BST) Organization: just say no Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Answering my own question: > I expected that after getting ENOBUFS, the peak value would be equal > to the maximum. It seems that it wasn't actually a shortage of mbufs, but rather the socket's send or receive queue full, fixable with setsockopt. This possibility is mentioned on the man page for send(2), but not for write(2). -- Richard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 3 22:25:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.usask.ca (mail.usask.ca [128.233.3.34]) by hub.freebsd.org (Postfix) with ESMTP id E56CF37B403 for ; Sun, 3 Jun 2001 22:25:30 -0700 (PDT) (envelope-from kek971@mail.usask.ca) Received: from CONVERSION-DAEMON by mail.usask.ca (PMDF V5.2-32 #36834) id <0GEE00K014EHWJ@mail.usask.ca> for freebsd-net@FreeBSD.ORG; Sun, 3 Jun 2001 23:25:29 -0600 (CST) Received: from mail.usask.ca ([128.233.134.33]) by mail.usask.ca (PMDF V5.2-32 #36834) with ESMTP id <0GEE00OBB4EHBE@mail.usask.ca> for freebsd-net@FreeBSD.ORG; Sun, 03 Jun 2001 23:25:29 -0600 (CST) Date: Sun, 03 Jun 2001 23:22:25 -0600 From: Keunho Kim Subject: 2 IPs To: freebsd-net@FreeBSD.ORG Message-id: <3B1B1B11.BEEA83F@mail.usask.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (WinNT; U) Content-type: text/plain; charset=EUC-KR Content-transfer-encoding: 7BIT X-Accept-Language: en,ko Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ---|cable modem|--|hub|----A -with 2 NICs | | ---B - with 2 NICs i have 2 different real IPs assigned to 2 different computers. A=freebsd B=win i'd like to set up 2 computers with C class IP addresses(192.168.0.1 & 192.168.0.2) and real IPs are coming to each computers at the same time. How can i set up network to have 2 C-class IP adresses assigned to each computers, and then i can control one to the other through these virtual IPs not real IPS? cuz.. whenever i log on from one(win) to the other(freebsd) on a console, packets are traveling all over the world and sometimes taking a long time. Any comments or suggestions would make me feel better now... cuz i spent 2 days and 3 nights to solve this thing Thaks... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Jun 3 22:53:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 174C737B401 for ; Sun, 3 Jun 2001 22:53:21 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:10c1:f535:71c7:c903:471c]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA24356; Mon, 4 Jun 2001 14:53:21 +0900 (JST) Date: Mon, 04 Jun 2001 14:50:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: Display of prefixes in aperticular ifnet structure. In-Reply-To: <39199B3B.03898409.9513E96F@netscape.net> References: <39199B3B.03898409.9513E96F@netscape.net> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Sat, 02 Jun 2001 09:27:30 -0400, >>>>> raviprasad20@netscape.net said: > I configured some prefixes through the "prefix" command. I then tried to display them as itis by reading the "ifnet" structure's "if_prefixhead" member. The result is like this. > Prefix was set as > #prefix wb0 fec0:11::1 > the prefix displayed later by reading the ifnet structure is as follows. > The data is in 8bits. (Displayed by using the > printf(" %x\t",ifp->if_prefixhead.next->prefix.s6_addr8[0]); & etc till 15) > The output is like this. > 00 00 00 00 00 00 fe c0 00 11 00 00 > 00 00 00 00 > Can any body mail me if I had done some mistake & that's why iam getting the above result? > Or there is some other place where prefixes are stored & from that place we can get prefixes correctly? > Are prefixes stored in this way itself? I'm not sure, but we (the KAME project) would really recommend not to use the prefix command, but stick to legacy ifconfig(8). We've found many weird situations (including kernel panic) that the prefix manipulation cause, so the prefix command and the underling kernel has already been obsoleted in the KAME snaps, and the change will be merged into future releases of FreeBSD. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 4 3:22:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from light.imasy.or.jp (light.imasy.or.jp [202.227.24.4]) by hub.freebsd.org (Postfix) with ESMTP id 0EAAE37B403; Mon, 4 Jun 2001 03:22:45 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: (from uucp@localhost) by light.imasy.or.jp (8.11.3+3.4W/8.11.3/light) with UUCP id f54AMgf01075; Mon, 4 Jun 2001 19:22:42 +0900 (JST) (envelope-from ume@mahoroba.org) Received: from peace.mahoroba.org (IDENT:Bebe5k577e6Y7veT8Pp509LeJBAuqoSUf3AYPNTeWfEVm+bv3vaN5ri8y1nNtdFK@peace.mahoroba.org [3ffe:505:2:0:200:f8ff:fe05:3eae]) (authenticated as ume with CRAM-MD5) by mail.mahoroba.org (8.11.4/8.11.4/chaos) with ESMTP/inet6 id f54AKdc22435; Mon, 4 Jun 2001 19:20:40 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 04 Jun 2001 19:20:36 +0900 (JST) Message-Id: <20010604.192036.74727576.ume@mahoroba.org> To: current@freebsd.org, net@freebsd.org, snap-users@kame.net Subject: [CFR] latest KAME merge into FreeBSD From: Hajimu UMEMOTO X-Mailer: Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT 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, I just put the patch for merging latest KAME into FreeBSD: http://www.imasy.or.jp/~ume/ipv6/test/freebsd5-kame20010528-20010604.diff.gz This is based on KAME snap 20010528 and against 5-CURRENT of Jun 2. There are many many changes since last KAME merge (20000701). Please review it. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 4 8:37: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 107AB37B406; Mon, 4 Jun 2001 08:36:57 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C1D434B20; Tue, 5 Jun 2001 00:36:49 +0900 (JST) To: snap-users@kame.net Cc: current@freebsd.org, net@freebsd.org In-reply-to: ume's message of Mon, 04 Jun 2001 19:20:36 +0900. <20010604.192036.74727576.ume@mahoroba.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [CFR] latest KAME merge into FreeBSD From: itojun@iijlab.net Date: Tue, 05 Jun 2001 00:36:49 +0900 Message-ID: <22823.991669009@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >I just put the patch for merging latest KAME into FreeBSD: > http://www.imasy.or.jp/~ume/ipv6/test/freebsd5-kame20010528-20010604.diff.gz thanks! itojun sys/kern/uipc_mbuf2.c PULLDOWN_STAT cases are just for debugging and should be unnecessary for FreeBSD-current. i'm not sure what is the right thing to do about M_WRITABLE cases. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Jun 4 11:57: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from gateway.sequent.com (gateway.sequent.com [192.148.1.10]) by hub.freebsd.org (Postfix) with ESMTP id DAD7A37B403 for ; Mon, 4 Jun 2001 11:56:54 -0700 (PDT) (envelope-from nivedita@sequent.com) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.9.3/8.8.5) with ESMTP id LAA21637 for ; Mon, 4 Jun 2001 11:56:53 -0700 (PDT) Received: (from nivedita@localhost) by eng4.sequent.com (8.8.5/8.8.5/token.aware-1.2) id LAA21311 for freebsd-net@freebsd.org; Mon, 4 Jun 2001 11:56:52 -0700 (PDT) From: Nivedita Singhvi Message-Id: <200106041856.LAA21311@eng4.sequent.com> Subject: throughput drop at 8192 sends (fwd) To: freebsd-net@freebsd.org Date: Mon, 4 Jun 2001 11:56:52 -0700 (PDT) X-Mailer: ELM [version 2.5 PL3] 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 (Was asked to fwd to this list from freebsd-bugs) Sorry for the duplicate mail. I was running some tests and observed rather strange behaviour. TCP Request/Response tests showed a drastic fall at response sizes of 8192 bytes. This strange drop was also mirrored in UDP RR tests. Wondering if this is a known issue? (Smells like a VM problem). I'm afraid I cant upgrade and didnt have time to track down more info, but should be easily reproducible. Kernel: FreeBSD 4.2 Machines: 500MHz PIII / 333MHz PII (512MB each) Network: 100Mb Ethernet Test: netperf tcp_rr Request/Response Transaction Rate ---------------- ----------------- 1,1 5433 1,64 5061 1,4096 1067 1,8192 10 1,32767 287 1,65536 96 64,64 4753 64,4096 1042 64,8192 10 64,32768 290 64,65536 92 128,4096 1040 128,8192 10 128,32768 287 128,65536 93 thanks, Nivedita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 3: 8:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id B298137B405 for ; Tue, 5 Jun 2001 03:08:34 -0700 (PDT) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f55A8Ts52029 for ; Tue, 5 Jun 2001 11:08:29 +0100 (BST) X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 5 Jun 2001 11:08:28 +0100 (BST) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: freebsd-net@freebsd.org Subject: Interfaces config In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am configuring a GRF router using GateD. My main trouble is that I configured two 10/100B-T interfaces and logged on the machine I can ping just one of its two interfaces. ---------- # ifconfig -au lo0: loop flags=8009 inet 127.0.0.1 netmask 0xff000000 grit 0:0x48:0 ge030: gritether flags=140b043 inet 192.168.253.188 netmask 0xffffffc0 broadcast 194.207.253.191 ge031: gritether flags=140a043 inet 192.168.190.1 netmask 0xffffff00 broadcast 194.207.190.255 ---------- ping to 127.0.0.1 succeed. ping to 192.168.253.188 succedd. ping to 192.168.190.1 failed! Why I cannot ping 192.168.190.1 ? Thanks, Christophe. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 5:21:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id DAF0137B403; Tue, 5 Jun 2001 05:20:52 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f55CKSR14406; Tue, 5 Jun 2001 15:20:28 +0300 (EEST) (envelope-from ru) Date: Tue, 5 Jun 2001 15:20:28 +0300 From: Ruslan Ermilov To: Jesper Skriver , Jonathan Lemon Cc: freebsd-net@FreeBSD.org Subject: Re: control TCP send/recieve window size based on port numbers ? and a bug(?) in sendpipe/recvpipe handling ... Message-ID: <20010605152028.A12215@sunbay.com> Mail-Followup-To: Jesper Skriver , Jonathan Lemon , freebsd-net@FreeBSD.ORG References: <20010526213442.A95985@skriver.dk> <20010527000854.B98021@skriver.dk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010527000854.B98021@skriver.dk>; from jesper@skriver.dk on Sun, May 27, 2001 at 12:08:54AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, May 27, 2001 at 12:08:54AM +0200, Jesper Skriver wrote: > On Sat, May 26, 2001 at 09:34:42PM +0200, Jesper Skriver wrote: > > Hi, > > > > I'm currently looking at ways to tune a ftp server, and when > > tuning net.inet.tcp.sendspace/net.inet.tcp.recvspace and > > NMBCLUSTERS, I came to think that in a ftp server role, half the > > TCP sessions will be control sessions, which doesn't transfer much > > data, so there is no reason to reserve the same number of buffers > > for sendspace/recvspace for these, compared to the data sessions. > > > > I was thinking of adding 3 new sysctl's > > > > net.inet.tcp.override_sendspace > > net.inet.tcp.override_recvspace > > net.inet.tcp.override_ports > > > > The latter controls which (if any) src/dst ports, trigger the > > session to get the overridden send and recv-space applied. > > > > Does this make any sense ? > > As Mike Silbersack has educated me, the sendspace and recvspace is > only the upper limit pr. session, and it's not static allocated, > so this i not a problem, and thus this patch doesn't give us > anything. > > So the only thing remaining is the bug where the sendpipe/recvpipe > doesn't have any effect. > It does, but only if the pipesize from the rtentry is greater than the mss. IOW, buffer sizes never fall below MSS. I wonder if this was intentional though. The code for rmx_recvpipe suggests it was. : /* : * If there's a pipesize, change the socket buffer : * to that size. Make the socket buffers an integral : * number of mss units; if the mss is larger than : * the socket buffer, decrease the mss. : */ : #ifdef RTV_SPIPE : if ((bufsize = rt->rt_rmx.rmx_sendpipe) == 0) : #endif : bufsize = so->so_snd.sb_hiwat; : if (bufsize < mss) : mss = bufsize; : else { : bufsize = roundup(bufsize, mss); : if (bufsize > sb_max) : bufsize = sb_max; : (void)sbreserve(&so->so_snd, bufsize, so, NULL); : } : tp->t_maxseg = mss; : : #ifdef RTV_RPIPE : if ((bufsize = rt->rt_rmx.rmx_recvpipe) == 0) : #endif : bufsize = so->so_rcv.sb_hiwat; : if (bufsize > mss) { : bufsize = roundup(bufsize, mss); : if (bufsize > sb_max) : bufsize = sb_max; : (void)sbreserve(&so->so_rcv, bufsize, so, NULL); : } Also, there is the related PR kern/11966 which complains about this code overriding user-set buffer sizes. The problem could be demonstrated with the loopback connection (through lo0), for which lortrequest() always sets send and receive pipes to 3 * LOMTU = 49152: : # sysctl net.inet.tcp.recvspace net.inet.tcp.rfc1323 : net.inet.tcp.recvspace: 65535 : net.inet.tcp.rfc1323: 1 : : # route -n get 127.1 : route to: 127.0.0.1 : destination: 127.0.0.1 : interface: lo0 : flags: : recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire : 49152 49152 0 0 0 0 16384 0 : : # ./tcp : rcv. buffer size before connect(): 65535 bytes : rcv. buffer size after connect(): 57344 bytes where: mss = rounddown(mtu - 40, MCLBYTES) = rounddown(16384 - 40, 2048) = 14336 rcvbuf = roundup(recvpipe, mss) = roundup(49152, 14336) = 57344 In the rfc1323=1 case, this is even worse. The user initially sets the large receive buffer, this then gets announced via the window scale option, and this code then resets the receive buffer to the lower size. The attached patch fixes this by only changing the buffer size to the greater value. The impact of this patch should be low, as (by default) only routes through the loopback interface have these routing metrics set. Please review. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: tcp_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.107.2.8 diff -u -p -r1.107.2.8 tcp_input.c --- tcp_input.c 2001/04/18 17:55:23 1.107.2.8 +++ tcp_input.c 2001/06/05 11:55:03 @@ -2786,7 +2786,8 @@ tcp_mss(tp, offer) bufsize = roundup(bufsize, mss); if (bufsize > sb_max) bufsize = sb_max; - (void)sbreserve(&so->so_snd, bufsize, so, NULL); + if (bufsize > so->so_snd.sb_hiwat) + (void)sbreserve(&so->so_snd, bufsize, so, NULL); } tp->t_maxseg = mss; @@ -2798,7 +2799,8 @@ tcp_mss(tp, offer) bufsize = roundup(bufsize, mss); if (bufsize > sb_max) bufsize = sb_max; - (void)sbreserve(&so->so_rcv, bufsize, so, NULL); + if (bufsize > so->so_rcv.sb_hiwat) + (void)sbreserve(&so->so_rcv, bufsize, so, NULL); } /* --HcAYCG3uE/tztfnV-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 5:51:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 4C4F837B401 for ; Tue, 5 Jun 2001 05:51:05 -0700 (PDT) (envelope-from jesper@skriver.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 5A0415D84; Tue, 5 Jun 2001 14:51:04 +0200 (CEST) Date: Tue, 5 Jun 2001 14:51:04 +0200 From: Jesper Skriver To: freebsd-net@FreeBSD.org Subject: leaking route structures, please review Message-ID: <20010605145104.A68594@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I've been looking at PR kern/25421, where Mark Smith have found a problem where we're leaking route structure, his fix (http://people.FreeBSD.org/~jesper/pcb.diff) looks good to me, but could you please have a look, as I'm not too familiar with this part of the code. His reasoning: Since rt was the cached route of the pcb, the ref count is >= 1 since the pcb will have a ref count on it. In the case of a dynamic route, in_losing calls rtrequest to delete the route but not rtfree. rtrequest() only deletes the route from the routing table. It does not free the route structure unless rt_refcnt is 0. We know it won't be zero because the pcb has a ref count. As a result it appears that we leak a route structure since it will never be freed. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 7:17:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m09.mx.aol.com (imo-m09.mx.aol.com [64.12.136.164]) by hub.freebsd.org (Postfix) with ESMTP id 591E637B405 for ; Tue, 5 Jun 2001 07:17:17 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m09.mx.aol.com (mail_out_v30.22.) id n.ef.1748169 (16230) for ; Tue, 5 Jun 2001 10:17:13 -0400 (EDT) Received: from netscape.com (aimmail02.aim.aol.com [205.188.144.194]) by air-in02.mx.aol.com (v77_r1.37) with ESMTP; Tue, 05 Jun 2001 10:17:13 -0400 Date: Tue, 05 Jun 2001 10:17:13 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: source address Mime-Version: 1.0 Message-ID: <00FF2888.55AC4F09.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, My doubt is this. In case a user process is specifying the source & destination address. Whether any check is performed on the source address like, a) address is present on which interface? b) address is already formed? c) Scope of source & destination address are correct? I checked the code in rip6_output() i found a call to a function to select the source address. Whether any such thing is performed for the addresses sent by the TCP & UDP layers? Assume that a user has opened a socket & has specifed the source & destination address.If the user has specified the source address to be of a different scope compared to the destination ( consider the cases of heigher scope or lower scope) any error message is loged? Kindly reply. regards ravi prasad __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 7:28:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m10.mx.aol.com (imo-m10.mx.aol.com [64.12.136.165]) by hub.freebsd.org (Postfix) with ESMTP id 140F637B403 for ; Tue, 5 Jun 2001 07:28:32 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m10.mx.aol.com (mail_out_v30.22.) id n.101.16fb812 (16220) for ; Tue, 5 Jun 2001 10:28:25 -0400 (EDT) Received: from netscape.com (aimmail02.aim.aol.com [205.188.144.194]) by air-in01.mx.aol.com (v77_r1.37) with ESMTP; Tue, 05 Jun 2001 10:28:25 -0400 Date: Tue, 05 Jun 2001 10:28:25 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: prefixes configured for an interface. Mime-Version: 1.0 Message-ID: <17ED9798.13B9F8D9.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I gave two prefixes through the prefix command. My other machine formed addresses based on the prefixes. By seeing the addresses i got the following doubt. a)Whether there is any limit on the number prefixes that can be broadcast by a router on a perticular interface? b)Suppose the router broadcasts 4 site local prefixes can a host form four site local addresse? What i mean is Iam doing these things on my own simple 2 PC network. If suppose the same thing is done on a ipv6 internet does it violate any rules? c)can the host communicate with other hosts in a differnet subent through any of the four addresses? Kindly reply. regards ravi prasad __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 7:44:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id C5E6037B406 for ; Tue, 5 Jun 2001 07:44:14 -0700 (PDT) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f55EiD556071 for ; Tue, 5 Jun 2001 15:44:13 +0100 (BST) X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 5 Jun 2001 15:44:09 +0100 (BST) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: freebsd-net@freebsd.org Subject: Interfaces trouble Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I am working on a GRF400 Router, (Lucent, ex Ascend) My trouble is very simple, I configured two interfaces: ----- # ifconfig -au lo0: loop flags=8009 inet 127.0.0.1 netmask 0xff000000 grit 0:0x48:0 ge030: gritether flags=140b043 inet 192.168.253.188 netmask 0xffffffc0 broadcast 192.168.253.191 ge031: gritether flags=140a043 inet 192.168.190.1 netmask 0xffffff00 broadcast 192.168.190.255 ----- From this GRF400 Router, I can ping 192.168.253.188, but I cannot ping 192.168.190.1. Why ? Regards, Christophe. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 8:14: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 79B3937B405 for ; Tue, 5 Jun 2001 08:13:56 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA87829; Tue, 5 Jun 2001 11:13:27 -0400 (EDT) (envelope-from wollman) Date: Tue, 5 Jun 2001 11:13:27 -0400 (EDT) From: Garrett Wollman Message-Id: <200106051513.LAA87829@khavrinen.lcs.mit.edu> To: Jesper Skriver Cc: freebsd-net@FreeBSD.ORG Subject: leaking route structures, please review In-Reply-To: <20010605145104.A68594@skriver.dk> References: <20010605145104.A68594@skriver.dk> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > Since rt was the cached route of the pcb, the ref count is >= 1 > since the pcb will have a ref count on it. In the case of a dynamic > route, in_losing calls rtrequest to delete the route but not rtfree. > rtrequest() only deletes the route from the routing table. It does > not free the route structure unless rt_refcnt is 0. This is correct. We can't have it rip the route out from under any number of PCBs and other routes which may have it referenced. > We know it won't be zero because the pcb has a ref count. As a > result it appears that we leak a route structure since it will never > be freed. No, the next time that route structure is used, the lack of an RTF_UP flag on the route will be noted, and the reference will be dropped before rtalloc() is called to find the new correct route. If you want the references to be dropped sooner, either send more traffic or close your connections more frequently. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 8:27:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 90F6A37B405 for ; Tue, 5 Jun 2001 08:27:38 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA05702; Wed, 6 Jun 2001 00:27:45 +0900 (JST) Date: Wed, 06 Jun 2001 00:24:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: prefixes configured for an interface. In-Reply-To: <17ED9798.13B9F8D9.9513E96F@netscape.net> References: <17ED9798.13B9F8D9.9513E96F@netscape.net> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Tue, 05 Jun 2001 10:28:25 -0400, >>>>> raviprasad20@netscape.net said: > I gave two prefixes through the prefix command. My other machine formed addresses based on the prefixes. By seeing the addresses i got the following doubt. First of all, please forget the prefix(8) command, as I mentioned in a previous message. Instead, you should do all the operation using ifconfig(8). > a)Whether there is any limit on the number prefixes that can be broadcast by a router on a perticular interface? No, according to the spec. > b)Suppose the router broadcasts 4 site local prefixes can a host form four site local addresse? What i mean is Iam doing these things on my own simple 2 PC network. If suppose the same thing is done on a ipv6 internet does it violate any rules? No. > c)can the host communicate with other hosts in a differnet subent through any of the four addresses? Yes, it can. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 8:38: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id DAFE237B401 for ; Tue, 5 Jun 2001 08:38:03 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA05782; Wed, 6 Jun 2001 00:38:12 +0900 (JST) Date: Wed, 06 Jun 2001 00:35:21 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: source address In-Reply-To: <00FF2888.55AC4F09.9513E96F@netscape.net> References: <00FF2888.55AC4F09.9513E96F@netscape.net> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 16 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Tue, 05 Jun 2001 10:17:13 -0400, >>>>> raviprasad20@netscape.net said: > My doubt is this. In case a user process is specifying the source & destination address. Whether any check is performed on the source address like, > a) address is present on which interface? > b) address is already formed? > c) Scope of source & destination address are correct? If you mean the IPv6 source address selection, please see Section 1.3 of the IMPLEMENTATION file in the KAME kit, which can be grabbed at http://www.kame.net/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 8:39:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id E558037B405 for ; Tue, 5 Jun 2001 08:39:07 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA05792; Wed, 6 Jun 2001 00:39:17 +0900 (JST) Date: Wed, 06 Jun 2001 00:36:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: source address In-Reply-To: References: <00FF2888.55AC4F09.9513E96F@netscape.net> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 19 Sender: owner-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, 06 Jun 2001 00:35:21 +0900, >>>>> JINMEI Tatuya said: >> My doubt is this. In case a user process is specifying the source & destination address. Whether any check is performed on the source address like, >> a) address is present on which interface? >> b) address is already formed? >> c) Scope of source & destination address are correct? > If you mean the IPv6 source address selection, please see Section 1.3 ^^^^^^^^^^^ Oops, should be Section 1.6, sorry. > of the IMPLEMENTATION file in the KAME kit, which can be grabbed at > http://www.kame.net/ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 10:15:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from my.usask.ca (my.usask.ca [128.233.65.7]) by hub.freebsd.org (Postfix) with ESMTP id 8ABC937B406 for ; Tue, 5 Jun 2001 10:15:40 -0700 (PDT) (envelope-from kek971@mail.usask.ca) Received: (from nobody@localhost) by my.usask.ca (8.11.0/8.11.0) id f55HFbc22245 for freebsd-net@FreeBSD.ORG; Tue, 5 Jun 2001 11:15:37 -0600 To: Subject: lock in Netscape? Message-ID: <991761333.3b1d13b51447e@my.usask.ca> Date: Tue, 05 Jun 2001 11:15:33 -0600 (CST) From: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 2.3.6-cvs X-WebMail-Service: My.USask.CA X-Originating-IP: 24.71.108.209 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org everytime I run Netscape, I prompt (or error message) which says I sould check out 'lock' in ~/.netscape directory. it's little bit...cumbersome... so How can I make this normal? Thanks in advance To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 10:41:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 530DC37B437 for ; Tue, 5 Jun 2001 10:41:48 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f55HfLj49388; Tue, 5 Jun 2001 20:41:21 +0300 (EEST) (envelope-from ru) Date: Tue, 5 Jun 2001 20:41:21 +0300 From: Ruslan Ermilov To: Garrett Wollman Cc: Jesper Skriver , freebsd-net@FreeBSD.ORG Subject: Re: leaking route structures, please review Message-ID: <20010605204121.A49067@sunbay.com> Mail-Followup-To: Garrett Wollman , Jesper Skriver , freebsd-net@FreeBSD.ORG References: <20010605145104.A68594@skriver.dk> <200106051513.LAA87829@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106051513.LAA87829@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Jun 05, 2001 at 11:13:27AM -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 Tue, Jun 05, 2001 at 11:13:27AM -0400, Garrett Wollman wrote: > < said: > > > Since rt was the cached route of the pcb, the ref count is >= 1 > > since the pcb will have a ref count on it. In the case of a dynamic > > route, in_losing calls rtrequest to delete the route but not rtfree. > > rtrequest() only deletes the route from the routing table. It does > > not free the route structure unless rt_refcnt is 0. > > This is correct. We can't have it rip the route out from under any > number of PCBs and other routes which may have it referenced. > > > We know it won't be zero because the pcb has a ref count. As a > > result it appears that we leak a route structure since it will never > > be freed. > > No, the next time that route structure is used, the lack of an RTF_UP > flag on the route will be noted, and the reference will be dropped > before rtalloc() is called to find the new correct route. If you want > the references to be dropped sooner, either send more traffic or close > your connections more frequently. > Hmm, and what happens if the PCB is the only holder of this route? The refcnt will be 1 in this case, and the code drops the reference by setting inp->inp_route.ro_rt = 0. How this route can be reused (and deleted) later? Also, while I was playing with this, I noticed some strange things I don't understand, and would like a tip on. Why, when I add the `default' route, the rttrash variable increases? Who calls the rtfree() in this case? And why this is different from where I add the route to say `-net 10'? Note the difference: Script started on Tue Jun 5 20:38:47 2001 perl# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 1 6 lo0 192.168.4 link#1 UC 2 0 rl0 => perl# route add -net 10 192.168.4.65 add net 10: gateway 192.168.4.65 perl# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 10 192.168.4.65 UGSc 0 0 rl0 127.0.0.1 127.0.0.1 UH 1 6 lo0 192.168.4 link#1 UC 3 0 rl0 => 192.168.4.65 link#1 UHLW 1 0 rl0 => Script done on Tue Jun 5 20:39:10 2001 Script started on Tue Jun 5 20:39:28 2001 perl# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 1 6 lo0 192.168.4 link#1 UC 2 0 rl0 => perl# route add default 192.168.4.65 add net default: gateway 192.168.4.65 perl# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.4.65 UGSc 0 0 rl0 127.0.0.1 127.0.0.1 UH 1 6 lo0 192.168.4 link#1 UC 3 0 rl0 => Script done on Tue Jun 5 20:39:40 2001 Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 10:46:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id E2C8E37B406 for ; Tue, 5 Jun 2001 10:46:13 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f55HkBR06241; Tue, 5 Jun 2001 10:46:11 -0700 Date: Tue, 5 Jun 2001 10:46:11 -0700 From: Brooks Davis To: kek971@mail.usask.ca Cc: freebsd-net@FreeBSD.ORG Subject: Re: lock in Netscape? Message-ID: <20010605104611.A6024@Odin.AC.HMC.Edu> References: <991761333.3b1d13b51447e@my.usask.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <991761333.3b1d13b51447e@my.usask.ca>; from kek971@mail.usask.ca on Tue, Jun 05, 2001 at 11:15:33AM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 05, 2001 at 11:15:33AM -0600, kek971@mail.usask.ca wrote: > everytime I run Netscape, I prompt (or error message) which says I sould = check out 'lock' in ~/.netscape directory. >=20 > it's little bit...cumbersome... so How can I make this normal? Exit or kill all copies of netscape and the do: $ rm ~/.netscape/lock On my laptop I also have an entry in my .xinitrc which deletes it when X starts because there should be no netscapes running at that point. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7HRriXY6L6fI4GtQRAm7UAJ4pWEWcNF3QQNNFcclkpxDFV0sU/QCgh8Uk ekMDwKrYMzKzg1ptobaLPQI= =1jIs -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 10:50:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from kanga.honeypot.net (kanga.honeypot.net [216.224.193.50]) by hub.freebsd.org (Postfix) with ESMTP id 353BD37B406 for ; Tue, 5 Jun 2001 10:50:46 -0700 (PDT) (envelope-from kirk@honeypot.net) Received: from pooh.honeypot (mail@pooh.honeypot [10.0.1.2]) by kanga.honeypot.net (8.11.3/8.11.3) with ESMTP id f55HojM51467 for ; Tue, 5 Jun 2001 12:50:45 -0500 (CDT) (envelope-from kirk@honeypot.net) Received: from kirk by pooh.honeypot with local (Exim 3.22 #1 (Debian)) id 157KyY-0005ix-00 for ; Tue, 05 Jun 2001 12:50:42 -0500 To: freebsd-net@freebsd.org Subject: Re: lock in Netscape? References: <991761333.3b1d13b51447e@my.usask.ca> From: Kirk Strauser Date: 05 Jun 2001 12:50:42 -0500 In-Reply-To: <991761333.3b1d13b51447e@my.usask.ca> Message-ID: <871yoyn7d9.fsf@pooh.honeypot> Lines: 11 X-Mailer: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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 At 2001-06-05T17:15:33Z, writes: > everytime I run Netscape, I prompt (or error message) which says I sould > check out 'lock' in ~/.netscape directory. > > it's little bit...cumbersome... so How can I make this normal? What happens when you follow the directions you quoted above? -- Kirk Strauser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 11:40:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from munin.odin-corporation.com (munin.odin-corporation.com [216.233.173.18]) by hub.freebsd.org (Postfix) with ESMTP id 6A4EC37B407 for ; Tue, 5 Jun 2001 11:40:20 -0700 (PDT) (envelope-from lars@odin-corporation.com) Received: from odin-corporation.com (localhost [127.0.0.1]) by munin.odin-corporation.com (8.11.3/8.11.1) with ESMTP id f55IeHP33378; Tue, 5 Jun 2001 13:40:17 -0500 (CDT) (envelope-from lars@odin-corporation.com) Message-ID: <3B1D2790.8F1E9474@odin-corporation.com> Date: Tue, 05 Jun 2001 13:40:17 -0500 From: Lars Fredriksen Organization: Odin Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: no, en MIME-Version: 1.0 To: kek971@mail.usask.ca Cc: freebsd-net@FreeBSD.ORG Subject: Re: lock in Netscape? References: <991761333.3b1d13b51447e@my.usask.ca> 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, Remove the stale lock file. Lars kek971@mail.usask.ca wrote: > everytime I run Netscape, I prompt (or error message) which says I sould check out 'lock' in ~/.netscape directory. > > it's little bit...cumbersome... so How can I make this normal? > > Thanks in advance > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Jun 5 13:18:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4F07C37B407; Tue, 5 Jun 2001 13:18:29 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id QAA90495; Tue, 5 Jun 2001 16:18:24 -0400 (EDT) (envelope-from wollman) Date: Tue, 5 Jun 2001 16:18:24 -0400 (EDT) From: Garrett Wollman Message-Id: <200106052018.QAA90495@khavrinen.lcs.mit.edu> To: Ruslan Ermilov Cc: freebsd-net@FreeBSD.ORG Subject: Re: leaking route structures, please review In-Reply-To: <20010605204121.A49067@sunbay.com> References: <20010605145104.A68594@skriver.dk> <200106051513.LAA87829@khavrinen.lcs.mit.edu> <20010605204121.A49067@sunbay.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 < said: > Hmm, and what happens if the PCB is the only holder of this route? > The refcnt will be 1 in this case, and the code drops the reference > by setting inp->inp_route.ro_rt = 0. How this route can be reused > (and deleted) later? That would be a bug. rtfree() must always be called before forgetting a reference. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 2: 4:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 9CE5C37B403 for ; Wed, 6 Jun 2001 02:04:48 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 35841 invoked by uid 1000); 6 Jun 2001 09:03:37 -0000 Date: Wed, 6 Jun 2001 12:03:37 +0300 From: Peter Pentchev To: net@FreeBSD.org Subject: DHCP configured interface aliases? Message-ID: <20010606120337.D18735@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Is there a way to configure interface aliases using DHCP? I'm using RELENG_4, and dhclient(8) works fine; however, it only configures one IP address :) Is there a way, using the net/isc-dhcp3 port, and the stock FreeBSD dhclient(8), to configure (more than one) alias in addition to the fixed-address in the DHCP response? G'luck, Peter -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 3: 7:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 0377337B403 for ; Wed, 6 Jun 2001 03:07:14 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f56A6Ei56721; Wed, 6 Jun 2001 13:06:14 +0300 (EEST) (envelope-from ru) Date: Wed, 6 Jun 2001 13:06:14 +0300 From: Ruslan Ermilov To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: leaking route structures, please review Message-ID: <20010606130614.F37378@sunbay.com> Mail-Followup-To: Garrett Wollman , freebsd-net@FreeBSD.ORG References: <20010605145104.A68594@skriver.dk> <200106051513.LAA87829@khavrinen.lcs.mit.edu> <20010605204121.A49067@sunbay.com> <200106052018.QAA90495@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106052018.QAA90495@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Tue, Jun 05, 2001 at 04:18:24PM -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 Tue, Jun 05, 2001 at 04:18:24PM -0400, Garrett Wollman wrote: > < said: > > > Hmm, and what happens if the PCB is the only holder of this route? > > The refcnt will be 1 in this case, and the code drops the reference > > by setting inp->inp_route.ro_rt = 0. How this route can be reused > > (and deleted) later? > > That would be a bug. rtfree() must always be called before forgetting > a reference. > OTOH, here is the relevant CSRG record: D 7.22 92/07/22 17:08:47 sklower 83 82 00003/00002/00450 MRs: COMMENTS: if in_losing notices an RTF_DYNAMIC route, it got freed twice # sccs sccsdiff -up -r7.21 -r7.22 in_pcb.c SCCS/s.in_pcb.c: 7.21 vs. 7.22 --- /tmp/get.1058.7.21 Wed Jun 6 12:50:34 2001 +++ /tmp/get.1058.7.22 Wed Jun 6 12:50:34 2001 @@ -370,6 +370,7 @@ in_losing(inp) struct rt_addrinfo info; if ((rt = inp->inp_route.ro_rt)) { + inp->inp_route.ro_rt = 0; bzero((caddr_t)&info, sizeof(info)); info.rti_info[RTAX_DST] = (struct sockaddr *)&inp->inp_route.ro_dst; @@ -380,12 +381,12 @@ in_losing(inp) (void) rtrequest(RTM_DELETE, rt_key(rt), rt->rt_gateway, rt_mask(rt), rt->rt_flags, (struct rtentry **)0); - inp->inp_route.ro_rt = 0; - rtfree(rt); + else /* * A new route can be allocated * the next time output is attempted. */ + rtfree(rt); } } I personally don't see how RTF_DYNAMIC route could affect whether to call rtfree() or not in this case. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 5:33:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id C437637B406; Wed, 6 Jun 2001 05:33:01 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f56CWxN31166; Wed, 6 Jun 2001 15:32:59 +0300 (EEST) (envelope-from ru) Date: Wed, 6 Jun 2001 15:32:59 +0300 From: Ruslan Ermilov To: Garrett Wollman Cc: net@FreeBSD.org Subject: Cached socket routes problem Message-ID: <20010606153259.B15851@sunbay.com> Mail-Followup-To: Garrett Wollman , net@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ----- Forwarded message from Ruslan Ermilov ----- Date: Wed, 6 Jun 2001 15:32:05 +0300 From: Ruslan Ermilov To: Andre Albsmeier Cc: bug-followup@FreeBSD.org Subject: Re: kern/27890: FreeBSD not always seems to take the best route User-Agent: Mutt/1.2.5i In-Reply-To: <20010606122904.A81971@curry.mchp.siemens.de>; from andre.albsmeier@mchp.siemens.de on Wed, Jun 06, 2001 at 12:29:04PM +0200 On Wed, Jun 06, 2001 at 12:29:04PM +0200, Andre Albsmeier wrote: > Thanks for helping... > > On Wed, 06-Jun-2001 at 11:24:19 +0300, Ruslan Ermilov wrote: > > > > ... > > > > I can't reproduce this problem on my 4.3-STABLE box. > > > > Yes, the UDP socket has the reference to the protocol-cloned > > route to the destination host S through the router 1 initially, > > and UDP packets go through that router. > > > > In my tests, router 1 (192.168.1.1) was the host *not* configured > > to act as the router, so all "foreign" packets sent to it got > > OK, I have blocked packets coming from C on router 1. So > I think I got the same config as you. > > > > silently ignored. I used the ports/net/netcat utility to connect > > to the UDP `echo' port of the destination S (192.168.2.1): > > > > Fig.1: Initial state, before UDP socket is open. > > > > : # netstat -arn > > : Destination Gateway Flags Refs Use Netif Expire > > : default 192.168.1.1 UGSc 0 2 rl0 > > : 127.0.0.1 127.0.0.1 UH 1 6 lo0 > > : 192.168.1 link#1 UC 3 0 rl0 => > > > > > > Fig.2: We connect(2) UDP socket to the "echo" port on S (192.168.2.1). > > > > : # nc -u 192.168.2.1 echo > > : ping1 > > : ping2 > > : ping3 > > [...] > > > > As you can see, we receive no echos back. > > OK, same here. > > > > Fig.3: Routing table after UDP socket is open. > > > > : # netstat -arn > > : Destination Gateway Flags Refs Use Netif Expire > > : default 192.168.1.1 UGSc 1 2 rl0 > > : 127.0.0.1 127.0.0.1 UH 1 6 lo0 > > : 192.168.1 link#1 UC 4 0 rl0 => > > : 192.168.2.1 192.168.1.1 UGHW 1 14 rl0 > > > > The route to S (192.168.2.1) was cloned (W) from the `default' route. > > refcnt=1 on the 192.168.2.1 route indicates that the UDP socket holds > > a reference to this route. > > Same here: > > 192.168.2.1 192.168.1.1 UGHW 1 425 fxp0 > > > > Fig.4: I manually add the route to the 192.168.2 network. > > > > : # route add -net 192.168.2 192.168.1.2 > > : add net 192.168.2: gateway 192.168.1.2 > > OK, I don;t add it manually but wait until routed messages from > 192.168.1.2 brings it back. > > > > > > Fig.5: Routing table after the route to the 192.168.2 network was added. > > > > : # netstat -arn > > : Destination Gateway Flags Refs Use Netif Expire > > : default 192.168.1.1 UGSc 1 2 rl0 > > : 127.0.0.1 127.0.0.1 UH 1 6 lo0 > > : 192.168.1 link#1 UC 4 0 rl0 => > > : 192.168.2 192.168.1.2 UGSc 0 0 rl0 > > Yup, same here > > > > As you can see, the route to the 192.168.2.1 host is deleted from the routing > > table. It actually doesn't get freed completely, as it had non-zero reference > > count (UDP socket still holds on it), but instead it gets marked as DOWN, and > > will be freed and reallocated in ip_output() on the next use. > > > > Fig.6: We continue to send UDP datagrams. > > > > : # nc -u 192.168.2.1 echo (continued) > > : ping4 > > : ping4 > > : ping5 > > : ping5 > > : ping6 > > : ping6 > > > > As you can see, this time we get the echos back. > > Yes, same here :-( > > > > Fig.7: Routing table after we sent more UDP datagrams. > > > > : # netstat -arn -finet > > : Destination Gateway Flags Refs Use Netif Expire > > : default 192.168.1.1 UGSc 0 2 rl0 > > : 127.0.0.1 127.0.0.1 UH 1 6 lo0 > > : 192.168.1 link#1 UC 4 0 rl0 => > > : 192.168.2 192.168.1.2 UGSc 1 3 rl0 > > > > The refcount on 192.168.2 route has grown to 1, indicating that the > > UDP socket now holds on this route. The `Use' count of 3 corresponds > > to our three UDP datagrams (ping4, ping5, and ping6). > > > > Could you please repeat these steps in your environment, and try to > > detect where it behaved differently in your case. > > It doesn't behave differently, that's interesting. May I ask you to > try it using syslogd? > > - Let host C log to host S (with the route installed). > - Watch C's messages appear on S. > - Delete C's route to S (via router 2) > - Let host C log again (run tcpdump on router 1 to see the packets come in) > - Install the route to S (via router 2) again on C > - Log more stuff. If you don't see the packets go into router 1 anymore > I am really lost... > Yes, I have reproduced the problem here. My test misses one step. OK, now about what happens here. Initially, there is the route (cloned from the network route) to S (192.168.2.1) through the router 2 (192.168.1.2). UDP socket uses this route initially. When this (and the 192.168.2 network) routes disappear, on the next write (!), ip_output() detects that the S route is DOWN, and "allocates" (caches) another route, which happens to be the "default" route pointing to router 1 (192.168.1.1). Later, when the route to the 192.168.2 network gets installed again, it's not taken into account, as the cached ("default") route is still UP. Unfortunately, there is no easy way to fix this. Checking for the best-match route on every write may be too time consuming. As the workaround, you can delete and re-add your "default" route. This worked for me here. `route delete default' will delete the "default" route from the routing table, but because it has a refcnt>0 will not delete it immediately, but will mark it as DOWN. ip_output() for this UDP socket's write will detect that the cached route is DOWN, will free it, and allocate a new route, which will be the route to the 192.168.2 network through router 2 (192.168.1.2) this time. The actual fix would be to notify protocol (from within the routing code) whenever its routing table is modified. This notification could then be saved in a variable as timestamp, and every PCB-cached route could have a similar timestamp as well, indicating when this "caching" took place. Having that, ip_output() would "invalidate" cached route if it was cached before the last routing table modification was done. I could probably try to implement this, if no one else can come up with a better idea. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 5:38:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m06.mx.aol.com (imo-m06.mx.aol.com [64.12.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 3167C37B403 for ; Wed, 6 Jun 2001 05:38:37 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m06.mx.aol.com (mail_out_v30.22.) id n.2.1812ffd (16228) for ; Wed, 6 Jun 2001 08:38:32 -0400 (EDT) Received: from netscape.com (aimmail09.aim.aol.com [205.188.144.201]) by air-in02.mx.aol.com (v78_r3.8) with ESMTP; Wed, 06 Jun 2001 08:38:32 -0400 Date: Wed, 06 Jun 2001 08:38:32 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: Re: source address Mime-Version: 1.0 Message-ID: <2744C2C2.33E0A284.9513E96F@netscape.net> References: <00FF2888.55AC4F09.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 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 Hi, As you mentioned the source address selection section 1.6 in kame implementation. In this section in the last but one paragraph the following is mentioned. " there are some cases where we dodnot use the above rule. one example is connected TCP session, & we use the address kept in the TCP protocol control block(pcb) as the source." My question is with reference to this section.( It is possibe that the user may have specified un matchin source & destination addresses. eg link local source address for a global unicast destination address.) Kindly clear my doubt. regards ravi prasad JINMEI Tatuya / wrote: > > >>>>> On Wed, 06 Jun 2001 00:35:21 +0900, > >>>>> JINMEI Tatuya said: > > >> My doubt is this. In case a user process is specifying the source & destination address. Whether any check is performed on the source address like, > >> a) address is present on which interface? > >> b) address is already formed? > >> c) Scope of source & destination address are correct? > > > If you mean the IPv6 source address selection, please see Section 1.3 >                                                             ^^^^^^^^^^^ > Oops, should be Section 1.6, sorry. > > > of the IMPLEMENTATION file in the KAME kit, which can be grabbed at > > http://www.kame.net/ > >                     JINMEI, Tatuya >                     Communication Platform Lab. >                     Corporate R&D Center, Toshiba Corp. >                     jinmei@isl.rdc.toshiba.co.jp > __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 5:44: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m05.mx.aol.com (imo-m05.mx.aol.com [64.12.136.8]) by hub.freebsd.org (Postfix) with ESMTP id A40A637B406 for ; Wed, 6 Jun 2001 05:43:56 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m05.mx.aol.com (mail_out_v30.22.) id n.e9.17ce3f6 (16245) for ; Wed, 6 Jun 2001 08:43:51 -0400 (EDT) Received: from netscape.com (aimmail09.aim.aol.com [205.188.144.201]) by air-in03.mx.aol.com (v78_r3.8) with ESMTP; Wed, 06 Jun 2001 08:43:51 -0400 Date: Wed, 06 Jun 2001 08:43:51 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: Re: Display of prefixes in aperticular ifnet structure. Mime-Version: 1.0 Message-ID: <0BDE53AB.15B71EF0.9513E96F@netscape.net> References: <39199B3B.03898409.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 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 Hi, As per your advice i left the prefix command & gave prefixes in the configuration file /etc/defaults/rc.conf itself. Still my print is the one that that i have mentioned. Kindly reply. regards ravi prasad JINMEI Tatuya / wrote: > > >>>>> On Sat, 02 Jun 2001 09:27:30 -0400, > >>>>> raviprasad20@netscape.net said: > > > I configured some prefixes through the "prefix" command. I then tried to display them as itis by reading the "ifnet" structure's "if_prefixhead" member. The result is like this. > > > Prefix was set as > > #prefix wb0 fec0:11::1 > > > the prefix displayed later by reading the ifnet structure is as follows. > > The data is in 8bits. (Displayed by using the > > printf(" %x\t",ifp->if_prefixhead.next->prefix.s6_addr8[0]); & etc till 15) > > > The output is like this. > > 00     00     00     00     00     00     fe    c0    00    11   00    00 > > 00     00     00     00 > > > > Can any body mail me if I had done some mistake & that's why iam getting the above result? > >  Or there is some other place where prefixes are stored & from that place we can get prefixes correctly? > > Are prefixes stored in this way itself? > > I'm not sure, but we (the KAME project) would really recommend not to > use the prefix command, but stick to legacy ifconfig(8).  We've found > many weird situations (including kernel panic) that the prefix > manipulation cause, so the prefix command and the underling kernel has > already been obsoleted in the KAME snaps, and the change will be > merged into future releases of FreeBSD. > >                     JINMEI, Tatuya >                     Communication Platform Lab. >                     Corporate R&D Center, Toshiba Corp. >                     jinmei@isl.rdc.toshiba.co.jp > __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 5:44:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 34F5537B406 for ; Wed, 6 Jun 2001 05:44:40 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:10c1:e17a:f7da:e284:ccdc]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id VAA12822; Wed, 6 Jun 2001 21:44:51 +0900 (JST) Date: Wed, 06 Jun 2001 21:41:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: source address In-Reply-To: <2744C2C2.33E0A284.9513E96F@netscape.net> References: <00FF2888.55AC4F09.9513E96F@netscape.net> <2744C2C2.33E0A284.9513E96F@netscape.net> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 12 Sender: owner-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, 06 Jun 2001 08:38:32 -0400, >>>>> raviprasad20@netscape.net said: > My question is with reference to this section.( It is possibe that the user may have specified un matchin source & destination addresses. eg link local source address for a global unicast destination address.) Yes, they can. Use the IPV6_PKTINFO socket option or ancillary data, and see RFC 2292. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 5:54:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 8057637B401 for ; Wed, 6 Jun 2001 05:54:22 -0700 (PDT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from localhost ([3ffe:501:100f:10c1:f97e:f7df:fe8e:ecdf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id VAA12914; Wed, 6 Jun 2001 21:54:35 +0900 (JST) Date: Wed, 06 Jun 2001 21:51:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: Display of prefixes in aperticular ifnet structure. In-Reply-To: <0BDE53AB.15B71EF0.9513E96F@netscape.net> References: <39199B3B.03898409.9513E96F@netscape.net> <0BDE53AB.15B71EF0.9513E96F@netscape.net> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 15 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Wed, 06 Jun 2001 08:43:51 -0400, >>>>> raviprasad20@netscape.net said: > As per your advice i left the prefix command & gave prefixes in the configuration file /etc/defaults/rc.conf itself. Still my print is the one that that i have mentioned. Please show us the exact version of your system, send the entire diff to the kernel, and tell us the exact command line argument(s) that causes the kernel output. No one can diagnose problems with incomplete information. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 17:27:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by hub.freebsd.org (Postfix) with ESMTP id 54A9F37B401; Wed, 6 Jun 2001 17:27:22 -0700 (PDT) (envelope-from mi@aldan.algebra.com) Received: from misha.privatelabs.com (root@[66.9.25.166]) by corbulon.video-collage.com (8.11.3/8.11.3) with ESMTP id f570RIj16625; Wed, 6 Jun 2001 20:27:19 -0400 (EDT) (envelope-from mi@aldan.algebra.com) X-Relay-IP: 66.9.25.166 Received: from misha.privatelabs.com (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.3/8.11.1) with ESMTP id f570RDW07406; Wed, 6 Jun 2001 20:27:15 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Message-Id: <200106070027.f570RDW07406@misha.privatelabs.com> Date: Wed, 6 Jun 2001 20:27:12 -0400 (EDT) From: mi@aldan.algebra.com Reply-To: mi@aldan.algebra.com Subject: using ipfw's ``pipe'' to limit icmp traffic To: question@freebsd.org Cc: net@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Trying to protect our network from ICMP-based attacks, I added the following rules to the firewall: pipe 1 config bw 64Kbit/s add pipe 1 log icmp from any to any in via OIF add allow icmp from any to any (OIF is the Outside InterFace) The assumption is, there is not going to be _much_ of ICMP traffic, so if it ever needs more than 64Kbit/s, it is an attack... This seems to work, but when I try to ping something outised the network, the ping time is around 10 msec. Without the above piping, it is around 0.5 msec. It is the bandwidth, that I'm trying to limit, not the minimum latency! Even more bizarre is that the ping times are _higher_ when pings originate from the firewall itself, compared to those, that originate from inside the firewalled network... What am I doing wrong? Thanks! -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 22:18:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from poontang.schulte.org (poontang.schulte.org [209.134.156.197]) by hub.freebsd.org (Postfix) with ESMTP id C3EEA37B408 for ; Wed, 6 Jun 2001 22:18:50 -0700 (PDT) (envelope-from christopher@schulte.org) Received: from tarmap.schulte.org (tarmap.schulte.org [209.134.156.198]) by poontang.schulte.org (8.12.0.Beta10/8.12.0.Beta10) with ESMTP id f575IiQO082083; Thu, 7 Jun 2001 00:18:44 -0500 (CDT) Message-Id: <5.1.0.14.0.20010607000129.025e7820@pop.schulte.org> X-Sender: schulte@pop.schulte.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Jun 2001 00:17:47 -0500 To: stable@freesd.org, net@freebsd.org From: Christopher Schulte Subject: bdg_forward drop MULTICAST PKT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I upgraded a 4.2-RELEASE machine to RELENG_4_3 tonight. This box has 2 nics, uses ipfw and bridging to act as a firewall. I've been using this configuration with 4.2-RELEASE for ~200 days with superb results! Now with the reboot into 4.3-RELEASE (RELENG4_3) 2001-06-05, I see this message on console and in logs: Jun 6 21:20:21 xxxxxx bdg_forward drop MULTICAST PKT Jun 6 21:20:51 xxxxxx last message repeated 4 times Jun 6 21:22:51 xxxxxx last message repeated 13 times Jun 6 21:32:51 xxxxxx last message repeated 67 times Jun 6 21:42:51 xxxxxx last message repeated 66 times Jun 6 21:48:20 xxxxxx last message repeated 37 times ..etc.. Mind you, the bridging all appears to be working ok, at least from the hour or two that it's been running. This is more of an annoyance, which I was curious about. I managed to disable the log message by commenting line 462 of /usr/src/sys/net/if_ethersubr.c (1.70.2.15) and recompiling. Not the best solution, which is why I'm writing here today. My kernconf is quite basic, just these delta GENERIC: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options BRIDGE My firewall config in /etc/rc.firewall was not altered at all between 4.2-STABLE and 4.3-RELEASE. I tried searching the mailing list archives and bug database, but didn't come up with much. Thanks for the time, anyone, who looks at this. -- Christopher Schulte Finger for PGP key, or for UNIX impaired: http://noc.schulte.org/cgi-bin/noc/finger.cgi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 22:19:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from herbelot.dyndns.org (s108.dhcp212-28.cybercable.fr [212.198.28.108]) by hub.freebsd.org (Postfix) with ESMTP id 30EBE37B405; Wed, 6 Jun 2001 22:19:15 -0700 (PDT) (envelope-from thierry@herbelot.com) Received: from herbelot.com (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id HAA04956; Thu, 7 Jun 2001 07:45:39 +0200 (CEST) (envelope-from thierry@herbelot.com) Message-ID: <3B1F0EC3.28C7A21C@herbelot.com> Date: Thu, 07 Jun 2001 07:18:59 +0200 From: Thierry Herbelot X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: mi@aldan.algebra.com Cc: question@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: using ipfw's ``pipe'' to limit icmp traffic References: <200106070027.f570RDW07406@misha.privatelabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org mi@aldan.algebra.com wrote: > > Trying to protect our network from ICMP-based attacks, I added the > following rules to the firewall: > > pipe 1 config bw 64Kbit/s > add pipe 1 log icmp from any to any in via OIF > add allow icmp from any to any > > (OIF is the Outside InterFace) > > The assumption is, there is not going to be _much_ of ICMP traffic, so > if it ever needs more than 64Kbit/s, it is an attack... > > This seems to work, but when I try to ping something outised the > network, the ping time is around 10 msec. Without the above piping, it > is around 0.5 msec. It is the bandwidth, that I'm trying to limit, not > the minimum latency! the pipe facility is using the kernel clock, which has a default frequency of 100 Hz (thus the 10ms latency). the ipfw man page suggests : "it is a good practice to run kernels with ``options HZ=1000'' to reduce the granularity to 1ms or less" (HZ=1000 should work with computers as slow as pentium-75, I'm using HZ=5000 with P-III/450MHz) PS : the HZ option is not documented in the LINT kernel config as it should be > > Even more bizarre is that the ping times are _higher_ when pings > originate from the firewall itself, compared to those, that originate > from inside the firewalled network... USTL > > What am I doing wrong? Thanks! > > -mi > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 23:36:53 2001 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 4ED8437B406 for ; Wed, 6 Jun 2001 23:36:49 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id IAA39510; Thu, 7 Jun 2001 08:31:15 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106070631.IAA39510@info.iet.unipi.it> Subject: Re: bdg_forward drop MULTICAST PKT In-Reply-To: <5.1.0.14.0.20010607000129.025e7820@pop.schulte.org> from Christopher Schulte at "Jun 7, 2001 00:17:47 am" To: Christopher Schulte Date: Thu, 7 Jun 2001 08:31:15 +0200 (CEST) Cc: stable@freesd.org, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] 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 > Now with the reboot into 4.3-RELEASE (RELENG4_3) 2001-06-05, I see this > message on console and in logs: > > Jun 6 21:20:21 xxxxxx bdg_forward drop MULTICAST PKT ok, i think one can just remove the message with relatively little harm. The thing is, such multicast packets might be useful for the upper layers of the protocol stack, but the firewall does not have enough granularity to tell "do not forward this packet but still pass them up". With unicast there is not such a problem (a packet goes only to one place). The warning was there just to remind [me] what was going on. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Jun 6 23:54:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by hub.freebsd.org (Postfix) with ESMTP id E515037B401 for ; Wed, 6 Jun 2001 23:54:10 -0700 (PDT) (envelope-from Peter.Blok@inter.NL.net) Received: from ntpc by altrade.nijmegen.inter.nl.net via 1Cust139.tnt7.rtm1.nl.uu.net [213.116.108.139] with SMTP for id IAA26720 (8.8.8/1.3); Thu, 7 Jun 2001 08:54:09 +0200 (MET DST) Reply-To: From: "Peter Blok" To: Subject: mpd netgraph bridge Date: Thu, 7 Jun 2001 08:50:32 +0200 Message-ID: <002001c0ef1e$26140f00$8a02a8c0@ntpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: 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 Hi folks, I have a PPTP connection to my ADSL provider, using mpd-netgraph. It is available on ng0. I'd like to bridge this with netgraph to a separate ethernet interface sf3. Is this possible? I have looked at examples, but they don't work because ng0 is not of type ether. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 1:29:51 2001 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 2102537B406; Thu, 7 Jun 2001 01:29:48 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id KAA40095; Thu, 7 Jun 2001 10:25:35 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106070825.KAA40095@info.iet.unipi.it> Subject: Re: using ipfw's ``pipe'' to limit icmp traffic In-Reply-To: <3B1F0EC3.28C7A21C@herbelot.com> from Thierry Herbelot at "Jun 7, 2001 07:18:59 am" To: Thierry Herbelot Date: Thu, 7 Jun 2001 10:25:35 +0200 (CEST) Cc: mi@aldan.algebra.com, question@FreeBSD.ORG, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] 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 > > if it ever needs more than 64Kbit/s, it is an attack... > > > > This seems to work, but when I try to ping something outised the > > network, the ping time is around 10 msec. Without the above piping, it > > is around 0.5 msec. It is the bandwidth, that I'm trying to limit, not > > the minimum latency! > > the pipe facility is using the kernel clock, which has a default > frequency of 100 Hz (thus the 10ms latency). on top of this, 512 bit (64 bytes) take about 8ms to run through a 64Kbit/s pipe (transmission time) so even reducing the granularity will not change things much. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 3:22:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from alacran.it.uc3m.es (alacran.it.uc3m.es [163.117.139.44]) by hub.freebsd.org (Postfix) with ESMTP id 913F937B403 for ; Thu, 7 Jun 2001 03:22:26 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from it.uc3m.es (localhost [127.0.0.1]) by alacran.it.uc3m.es (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f57ANKc00908 for ; Thu, 7 Jun 2001 12:23:29 +0200 X-Authentication-Warning: alacran.it.uc3m.es: Host localhost [127.0.0.1] claimed to be it.uc3m.es Message-ID: <3B1F5618.4924F64C@it.uc3m.es> Date: Thu, 07 Jun 2001 12:23:20 +0200 From: Juan Fco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lista Subject: How to count frames transmitted through the ethernet card. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello: I am doing a program that sends udp packets. I have a counter and each time I send a packet with "sendto()", I increment the value of this variable. But I would like to count the frames that are being actually transmitted, through the ethernet card, some like the ifconfig/netstat. I would not like to run this commands with popen() or similar because I would have to parse the output, and this output have not always the same format. Does anyone knows some easy-function or an easy method to do this ? Best Regards. ***** JFRH ***** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 4: 1:50 2001 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 4E6BB37B401 for ; Thu, 7 Jun 2001 04:01:48 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id MAA40954; Thu, 7 Jun 2001 12:57:45 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106071057.MAA40954@info.iet.unipi.it> Subject: Re: How to count frames transmitted through the ethernet card. In-Reply-To: <3B1F5618.4924F64C@it.uc3m.es> from Juan Fco Rodriguez Hervella at "Jun 7, 2001 12:23:20 pm" To: Juan Fco Rodriguez Hervella Date: Thu, 7 Jun 2001 12:57:45 +0200 (CEST) Cc: Lista X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Hello: > > I am doing a program that sends udp packets. I have a counter > and each time I send a packet with "sendto()", I increment the value > of this variable. > > But I would like to count the frames that are being actually > transmitted, through the ethernet card, some like the ifconfig/netstat. In principle sendto() can return you an ENOBUFS error when the interface queue is full, but not always (depending on how the firewall plays with the packet). cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 4:37:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from alacran.it.uc3m.es (alacran.it.uc3m.es [163.117.139.44]) by hub.freebsd.org (Postfix) with ESMTP id E2FA637B407 for ; Thu, 7 Jun 2001 04:37:11 -0700 (PDT) (envelope-from jrh@it.uc3m.es) Received: from it.uc3m.es (localhost [127.0.0.1]) by alacran.it.uc3m.es (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f57BcGc01038 for ; Thu, 7 Jun 2001 13:38:19 +0200 X-Authentication-Warning: alacran.it.uc3m.es: Host localhost [127.0.0.1] claimed to be it.uc3m.es Message-ID: <3B1F67A8.2676289D@it.uc3m.es> Date: Thu, 07 Jun 2001 13:38:16 +0200 From: Juan Fco Rodriguez Hervella X-Mailer: Mozilla 4.74 [es] (X11; U; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Re: How to count frames transmitted through the ethernet card. 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 That is my problem, If sendto() *not* always returns ENOBUFS, I need to know the packets what are actually transmited... >> Hello: >> >> I am doing a program that sends udp packets. I have a counter >> and each time I send a packet with "sendto()", I increment the value >> of this variable. >> >> But I would like to count the frames that are being actually >> transmitted, through the ethernet card, some like the ifconfig/netstat. > > In principle sendto() can return you an ENOBUFS error when the > interface queue is full, but not always (depending on how the > firewall plays with the packet). > cheers > luigi ********************************* Juan F. Rodriguez Hervella Universidad Carlos III de Madrid ******************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 5:36:49 2001 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 0905637B407 for ; Thu, 7 Jun 2001 05:36:42 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id OAA41296; Thu, 7 Jun 2001 14:32:41 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200106071232.OAA41296@info.iet.unipi.it> Subject: Re: How to count frames transmitted through the ethernet card. In-Reply-To: <3B1F67A8.2676289D@it.uc3m.es> from Juan Fco Rodriguez Hervella at "Jun 7, 2001 01:38:16 pm" To: Juan Fco Rodriguez Hervella Date: Thu, 7 Jun 2001 14:32:41 +0200 (CEST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] 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 > That is my problem, If sendto() *not* always returns ENOBUFS, I > need to know the packets what are actually transmited... you don't have a way to know. The transmission can fail in the device driver (e.g. because of excessive collisions) and you only know it at a later time. cheers luigi > > >> Hello: > >> > >> I am doing a program that sends udp packets. I have a counter > >> and each time I send a packet with "sendto()", I increment the value > >> of this variable. > >> > >> But I would like to count the frames that are being actually > >> transmitted, through the ethernet card, some like the ifconfig/netstat. > > > > In principle sendto() can return you an ENOBUFS error when the > > interface queue is full, but not always (depending on how the > > firewall plays with the packet). > > > cheers > > luigi > > > ********************************* > Juan F. Rodriguez Hervella > Universidad Carlos III de Madrid > ******************************** > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 7: 4:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns.ktk.ru (ns.ktk.ru [195.161.51.5]) by hub.freebsd.org (Postfix) with ESMTP id EB8CE37B405 for ; Thu, 7 Jun 2001 07:04:31 -0700 (PDT) (envelope-from peps37@ktk.ru) Received: from gts1-13.dial.ktk.ru (gts1-13.dial.ktk.ru [195.161.51.140]) by ns.ktk.ru (8.9.3/8.9.1) with ESMTP id WAA34249 for ; Thu, 7 Jun 2001 22:04:16 +0800 (KRAST) Date: Thu, 7 Jun 2001 22:02:41 +0800 From: "Roman Y. Bogdanov" X-Mailer: The Bat! (v1.51) Personal Reply-To: "Roman Y. Bogdanov" Organization: http://peps37.ktk.ru/ X-Priority: 3 (Normal) Message-ID: <15387079653.20010607220241@ktk.ru> To: freebsd-net@FreeBSD.ORG Subject: I need help! MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ... np: Anabolic Frolic - Hubbalo 96 live [40:37] Please sorry me for poor English! I have network: Today: 1. Router with 3 logical interface and no default gateway. 192.168.2/24 - User workstation ( DNS & routing at 192.168.2.1 ) 192.168.3/24 - Dedicated admin workstation (ip 192.168.3.2/24) ( DNS & routing at 192.168.3.1 ) 192.168.55/24 - Dial In interface only. ( ip 192.168.55.2/24 for first dial in modem ) ( ip 192.168.55.1/24 at server, for routing ) Picture of Today: +-----------+ ¦192.168.3.2¦ +----T------+ +--------------+ +----+--------+ ¦192.168.2.*/24+------+192.168.3/24 ¦ +--------------+ ¦192.168.2/24 ¦ ¦192.168.55/24¦ ¦192.168.55.2 ¦ +-[ router ]--+ $ ifconfig -a ed0: flags=8943 mtu 1500 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 rl0: flags=8843 mtu 1500 inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255 inet 192.168.55.1 netmask 0xffffff00 broadcast 192.168.55.255 Need: Add new internet gateway and make routing in this new network. Today <- ¦ -> Tommorow ¦ +-----------+ ¦ ++++++++++++++ ¦192.168.3.2¦ ¦ + admin 2ws + +----T------+ ¦ ++++++++++++++ ¦ ¦ + ---------------+ -----+--------¬ ¦ + ¦192.168.2.*/24+------+192.168.3/24 ¦ ¦ +-------------+ +--------------+ ¦192.168.2/24 ¦-¦----|192.168.??/24| ¦192.168.55/24¦ ¦ +-[inetgw]----+ ¦192.168.55.2 ¦ ¦ + L-[ router ]--- ¦ + ¦ [ modem ] ---- > [ Internet ] Need to help in network logical organization. InetGW router have 3 interface: 1. To all LAN 2. To dedicated admin 2st workstation 3. To Internet dialup -------------- I need: 1. Setup for any 192.168.*/24 divert to internet in via inetgw router 2. Need "Amdin 2st workstation", connected on inetgw at dedicated NIC, see and browse all network. And all network can see and browse admin 2ws. 3. Need to setup dialin on inetgw and use 192.168.55/24 network. (ip 192.168.55.3 and 55.4) Waiting for you advice's. -- Roman Y. Bogdanov Email: peps37#ktk.ru, ICQ 5535950, http://peps37.ktk.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 17:31:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 2E1D237B401 for ; Thu, 7 Jun 2001 17:31:14 -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 RAA61082; Thu, 7 Jun 2001 17:16:37 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.3/8.11.3) id f580GdV03431; Thu, 7 Jun 2001 17:16:39 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200106080016.f580GdV03431@arch20m.dellroad.org> Subject: Re: mpd netgraph bridge In-Reply-To: <002001c0ef1e$26140f00$8a02a8c0@ntpc> "from Peter Blok at Jun 7, 2001 08:50:32 am" To: Peter.Blok@inter.NL.net Date: Thu, 7 Jun 2001 17:16:39 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (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 Peter Blok writes: > I have a PPTP connection to my ADSL provider, using mpd-netgraph. It is > available on ng0. I'd like to bridge this with netgraph to a separate > ethernet interface sf3. Is this possible? I have looked at examples, but > they don't work because ng0 is not of type ether. I don't understand.. how do you expect to bridge a point-to-point interface? Why not just have mpd assign the remote side an IP address on the Ethernet netrange using proxy ARP? Eg. "set iface enable proxy-arp"... -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 22:56:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 0274B37B405 for ; Thu, 7 Jun 2001 22:56:18 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 92211 invoked by uid 1000); 8 Jun 2001 05:56:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 05:56:16 -0000 Date: Fri, 8 Jun 2001 00:56:16 -0500 (CDT) From: Mike Silbersack To: , Subject: New TCP sequence number generation algorithm; review needed Message-ID: <20010608005234.W92206-200000@achilles.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-228414066-991979776=:92206" Sender: owner-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-228414066-991979776=:92206 Content-Type: TEXT/PLAIN; charset=US-ASCII The included patch implements what I believe to be a superior tcp sequence number generation algorithm. I'd appreciate comments on all aspects of the patch. If no objections are raised, I'd like to commit the patch to -current in a week or so, with -stable following two weeks after. I'm providing a quick FAQ to get people up to speed on what the patch does and its alternatives. But, as always, you'll obtain the best understanding of the code by reading it directly. Please do so before commenting. Q: How does this new patch generate sequence numbers? A: In short, the patch provides a seperate sequence number space for each host. These sequence spaces have no relation to the sequence spaces of other hosts, and are re-randomized whenever a host becomes idle. Q: How is this done? A: We are able to store a 16-bit variable which corresponds to the upper 16 bits of a host's sequence number in the cloned route entry for that host, thanks to extra space which exists in the routing metric structure. When we need a new sequence number for a host, we load in that value. If it is zero, as it is when the route is first cloned, we initialize it to a random value. Then, on this connection and every one after, we shift it left by 16 bits and increment it by a random value of up to 2^20. Subsequently, we store the upper 16 bits of the resulting value back in the cloned route entry, waiting for the next sequence number. Checks are present to make sure that the sequence number always increments by more than 2^16-1 and that the sequence number does not go to zero and cause a re-randomization. If a host is idle for a long period of time, the cloned route entry will be flushed and we will start the process over. Q: Doesn't looking up this extra data during every connection attempt take more time? A: No. The routing metric structure is accessed whenever a connection is established already. We are adding no additional searches, and the generation function is less time consuming than the one currently used. Q: How does all of this affect connections in the TIME_WAIT state? A: These changes positively affect the operation of sockets in the TIME_WAIT state. We are always monotonically incrementing the ISN within the context of a given host, which is what is required for proper operation. The re-randomization caused by a cloned route being flushed out and recreated is inconsequential; in the time it takes an entry to timeout and be flushed, any TIME_WAIT sockets would have expired. Q: How does all of this affect someone trying to spoof a connection? A: These changes make it very difficult to spoof connections. Since the ISN returned to the attacker has no relation to the ISN of the host he's trying to impersonate, he has no idea where to start. Even if he knew the starting point of the high 16-bits, he would be unable to guess the current state of the high 16-bits after a few random incrementations of the value. With this system in place, spoofing a connection should become a purely brute-force operation, requiring billions of attempts. Q: You're using arc4random() to get all random values. Is it random enough for this purpose? A: Mark Murray says that it is. So, yes. Q: What sequence number generation scheme is FreeBSD currently using? A: FreeBSD 4.3+ uses a tcp sequence number generation algorithm borrowed from OpenBSD. Roughly, this scheme uses a nonrepeating random number generator to provide the upper 16 bits for each ISN, while the lower 15 bits of data is drawn directly from the entropy pool. (The 16th bit is always 0.) Unless the nonrepeating random number generator is broken, spoofing this algorithm would be nearly as tough as spoofing against the new algorithm in this patch. The problem with the OpenBSD algorithm is that because the upper 16 bits of the sequence number are effectively random, monotonicity is broken. Hence, sockets in the TIME_WAIT state will act funky. Q: Ok, what's this RFC1948 sequence number generation scheme I keep hearing about? A: RFC1948 suggests segementing each hostA/portA/hostB/portB pair into a seperate sequence number space using a hash function of the form: ISN = timecounter + MD5(localhost, localport, remotehost, remoteport, shared secret) While clever, this algorithm has a major weakness. The shared secret is used in generating the ISN for all connections to the host in question. To ensure monotonicity for each connection, this implies that the shared secret must remain constant for the entire uptime of a machine. As a result, attackers may make a few connection attempts, store the IPs/ports used and the sequence number returned. This information can then be fed into a cracking program which will determine the shared secret. Once the shared secret is found, the attacker can perfectly spoof a connection to the machine from any host until the machine is rebooted and the shared secret changed. While not currently a threat, such an attack will most likely become possible if RFC1948 becomes widely used and attackers are sufficiently motivated. If you do not believe that this is possible, please read up on the history of RSA's DES challenges. Q: Do you really hate the RFC1948 algorithm that much? A: Yes. It's less secure than just random positive increments, IMHO. Q: Do you really think anyone read this far into the FAQ? A: I hope so. Q: Do you have anything more to add before I go off and read your code? A: Nope. Enjoy! Mike "Silby" Silbersack --0-228414066-991979776=:92206 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="silby_isn_generation.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20010608005616.L92206@achilles.silby.com> Content-Description: Content-Disposition: attachment; filename="silby_isn_generation.patch" ZGlmZiAtdSAtciBuZXRpbmV0Lm9sZC90Y3BfaW5wdXQuYyBuZXRpbmV0L3Rj cF9pbnB1dC5jDQotLS0gbmV0aW5ldC5vbGQvdGNwX2lucHV0LmMJVGh1IEp1 biAgNyAxNjowMjowMSAyMDAxDQorKysgbmV0aW5ldC90Y3BfaW5wdXQuYwlU aHUgSnVuICA3IDE2OjAyOjEzIDIwMDENCkBAIC0xMDkyLDcgKzEwOTIsNyBA QA0KIAkJaWYgKGlzcykNCiAJCQl0cC0+aXNzID0gaXNzOw0KIAkJZWxzZSB7 DQotCQkJdHAtPmlzcyA9IHRjcF9ybmRpc3NfbmV4dCgpOw0KKwkJCXRwLT5p c3MgPSB0Y3BfbmV4dF9pc24odGFvcCk7DQogIAkJfQ0KIAkJdHAtPmlycyA9 IHRoLT50aF9zZXE7DQogCQl0Y3Bfc2VuZHNlcWluaXQodHApOw0KQEAgLTE2 MjQsNyArMTYyNCw3IEBADQogCQkJaWYgKHRoZmxhZ3MgJiBUSF9TWU4gJiYN CiAJCQkgICAgdHAtPnRfc3RhdGUgPT0gVENQU19USU1FX1dBSVQgJiYNCiAJ CQkgICAgU0VRX0dUKHRoLT50aF9zZXEsIHRwLT5yY3Zfbnh0KSkgew0KLQkJ CQlpc3MgPSB0Y3Bfcm5kaXNzX25leHQoKTsNCisJCQkJaXNzID0gdGNwX25l eHRfaXNuKHRhb3ApOw0KIAkJCQl0cCA9IHRjcF9jbG9zZSh0cCk7DQogCQkJ CWdvdG8gZmluZHBjYjsNCiAJCQl9DQpPbmx5IGluIG5ldGluZXQvOiB0Y3Bf aW5wdXQuYy5vcmlnDQpkaWZmIC11IC1yIG5ldGluZXQub2xkL3RjcF9zdWJy LmMgbmV0aW5ldC90Y3Bfc3Vici5jDQotLS0gbmV0aW5ldC5vbGQvdGNwX3N1 YnIuYwlUaHUgSnVuICA3IDE2OjAyOjAxIDIwMDENCisrKyBuZXRpbmV0L3Rj cF9zdWJyLmMJVGh1IEp1biAgNyAxNzozOTo1MyAyMDAxDQpAQCAtMTA5Niw2 MyArMTA5Niw2IEBADQogfQ0KICNlbmRpZiAvKiBJTkVUNiAqLw0KIA0KLSNk ZWZpbmUgVENQX1JORElTU19ST1VORFMJMTYNCi0jZGVmaW5lIFRDUF9STkRJ U1NfT1VUCTcyMDANCi0jZGVmaW5lIFRDUF9STkRJU1NfTUFYCTMwMDAwDQot DQotdV9pbnQ4X3QgdGNwX3JuZGlzc19zYm94WzEyOF07DQotdV9pbnQxNl90 IHRjcF9ybmRpc3NfbXNiOw0KLXVfaW50MTZfdCB0Y3Bfcm5kaXNzX2NudDsN Ci1sb25nIHRjcF9ybmRpc3NfcmVzZWVkOw0KLQ0KLXVfaW50MTZfdA0KLXRj cF9ybmRpc3NfZW5jcnlwdCh2YWwpDQotCXVfaW50MTZfdCB2YWw7DQotew0K LQl1X2ludDE2X3Qgc3VtID0gMCwgaTsNCi0gIA0KLQlmb3IgKGkgPSAwOyBp IDwgVENQX1JORElTU19ST1VORFM7IGkrKykgew0KLQkJc3VtICs9IDB4Nzli OTsNCi0JCXZhbCBePSAoKHVfaW50MTZfdCl0Y3Bfcm5kaXNzX3Nib3hbKHZh bF5zdW0pICYgMHg3Zl0pIDw8IDc7DQotCQl2YWwgPSAoKHZhbCAmIDB4ZmYp IDw8IDcpIHwgKHZhbCA+PiA4KTsNCi0JfQ0KLQ0KLQlyZXR1cm4gdmFsOw0K LX0NCi0NCi12b2lkDQotdGNwX3JuZGlzc19pbml0KCkNCi17DQotCXN0cnVj dCB0aW1ldmFsIHRpbWU7DQotDQotCWdldG1pY3JvdGltZSgmdGltZSk7DQot CXJlYWRfcmFuZG9tKHRjcF9ybmRpc3Nfc2JveCwgc2l6ZW9mKHRjcF9ybmRp c3Nfc2JveCkpOw0KLQ0KLQl0Y3Bfcm5kaXNzX3Jlc2VlZCA9IHRpbWUudHZf c2VjICsgVENQX1JORElTU19PVVQ7DQotCXRjcF9ybmRpc3NfbXNiID0gdGNw X3JuZGlzc19tc2IgPT0gMHg4MDAwID8gMCA6IDB4ODAwMDsgDQotCXRjcF9y bmRpc3NfY250ID0gMDsNCi19DQotDQotdGNwX3NlcQ0KLXRjcF9ybmRpc3Nf bmV4dCgpDQotew0KLQl1X2ludDE2X3QgdG1wOw0KLQlzdHJ1Y3QgdGltZXZh bCB0aW1lOw0KLQ0KLQlnZXRtaWNyb3RpbWUoJnRpbWUpOw0KLQ0KLSAgICAg ICAgaWYgKHRjcF9ybmRpc3NfY250ID49IFRDUF9STkRJU1NfTUFYIHx8DQot CSAgICB0aW1lLnR2X3NlYyA+IHRjcF9ybmRpc3NfcmVzZWVkKQ0KLSAgICAg ICAgICAgICAgICB0Y3Bfcm5kaXNzX2luaXQoKTsNCi0JDQotCXJlYWRfcmFu ZG9tKCZ0bXAsIHNpemVvZih0bXApKTsNCi0NCi0JLyogKHRtcCAmIDB4N2Zm ZikgZW5zdXJlcyBhIDMyNzY4IGJ5dGUgZ2FwIGJldHdlZW4gSVNTICovDQot CXJldHVybiAoKHRjcF9ybmRpc3NfZW5jcnlwdCh0Y3Bfcm5kaXNzX2NudCsr KSB8IHRjcF9ybmRpc3NfbXNiKSA8PDE2KSB8DQotCQkodG1wICYgMHg3ZmZm KTsNCi19DQotDQotDQogLyoNCiAgKiBXaGVuIGEgc291cmNlIHF1ZW5jaCBp cyByZWNlaXZlZCwgY2xvc2UgY29uZ2VzdGlvbiB3aW5kb3cNCiAgKiB0byBv bmUgc2VnbWVudC4gIFdlIHdpbGwgZ3JhZHVhbGx5IG9wZW4gaXQgYWdhaW4g YXMgd2UgcHJvY2VlZC4NCkBAIC0xNDIxLDQgKzEzNjQsNDIgQEANCiBzdGF0 aWMgdm9pZA0KIHRjcF9jbGVhcnRhb2NhY2hlKCkNCiB7DQorfQ0KKw0KK3Rj cF9zZXEgdGNwX25leHRfaXNuKHRhb3ApDQorCXN0cnVjdCBybXhwX3RhbyAq dGFvcDsNCit7DQorCXRjcF9zZXEgaXNuOw0KKw0KKwkvKg0KKwkgKiBJZiB0 YW9faXNuIGVxdWFscyB6ZXJvLCBhcyBpdCBkb2VzIHdoZW4gYSByb3V0ZSBp cyBjcmVhdGVkLA0KKwkgKiB3ZSBtdXN0IGluaXRpYWxpemUgaXQgdG8gYSBy YW5kb20gdmFsdWUuICANCisJICovDQorCWlmICh0YW9wLT50YW9faXNuID09 IDApIHsNCisJCXRhb3AtPnRhb19pc24gPSAodV9zaG9ydCkgYXJjNHJhbmRv bSgpOw0KKwl9DQorDQorCS8qDQorCSAqIEluY3JlbWVudCBieSB1cCB0byAy XjIwLiAgQWx0aG91Z2ggd2UgaGF2ZSBubyB0aW1lIGRlcGVuZGVuY2UsDQor CSAqIHRoaXMgc2hvdWxkIGJlIGEgbGFyZ2UgZW5vdWdoIGp1bXAgdG8gaW5z dXJlIHRoYXQgdGhlcmUgYXJlDQorCSAqIG5vIFRJTUVfV0FJVCBwcm9ibGVt cy4NCisJICovDQorCWlzbiA9ICh0YW9wLT50YW9faXNuIDw8IDE2KSArIChh cmM0cmFuZG9tKCkgJiAweGZmZmZmKTsNCisNCisJLyoNCisJICogU2luY2Ug d2Ugb25seSBzdG9yZSB0aGUgdXBwZXIgMTYgYml0cywgd2UgbXVzdCBhbHdh eXMNCisJICogYWRkIG9uZSB0byBlbnN1cmUgdGhhdCBhIHJhbmRvbSBwb3Np dGl2ZSBpbmNyZW1lbnQNCisJICogbGVzcyB0aGFuIDJeMTYgZG9lcyBub3Qg Y2F1c2UgYSBzZXF1ZW5jZSBudW1iZXINCisJICogcmVncmVzc2lvbi4NCisJ ICovDQorCXRhb3AtPnRhb19pc24gPSAoaXNuID4+IDE2KSArIDE7DQorDQor CS8qDQorCSAqIFdlIG11c3QgY2hlY2sgdG8gbWFrZSBzdXJlIHRoYXQgdGFv X2lzbiBkb2VzIG5vdCBlcXVhbCB6ZXJvOw0KKwkgKiBpZiBpdCBkb2VzLCBh IGZhbHNlIHJlaW5pdGlhbGl6YXRpb24gb2YgaXRzIHZhbHVlIHdvdWxkIG9j Y3VyLg0KKwkgKi8NCisJaWYgKHRhb3AtPnRhb19pc24gPT0gMCkgDQorCQl0 YW9wLT50YW9faXNuID0gMTsNCisNCisJcmV0dXJuIGlzbjsNCiB9DQpPbmx5 IGluIG5ldGluZXQvOiB0Y3Bfc3Vici5jLm9yaWcNCmRpZmYgLXUgLXIgbmV0 aW5ldC5vbGQvdGNwX3VzcnJlcS5jIG5ldGluZXQvdGNwX3VzcnJlcS5jDQot LS0gbmV0aW5ldC5vbGQvdGNwX3VzcnJlcS5jCVRodSBKdW4gIDcgMTY6MDI6 MDEgMjAwMQ0KKysrIG5ldGluZXQvdGNwX3VzcnJlcS5jCVRodSBKdW4gIDcg MTY6MDI6MTMgMjAwMQ0KQEAgLTc2MSw4ICs3NjEsNiBAQA0KIAl0Y3BzdGF0 LnRjcHNfY29ubmF0dGVtcHQrKzsNCiAJdHAtPnRfc3RhdGUgPSBUQ1BTX1NZ Tl9TRU5UOw0KIAljYWxsb3V0X3Jlc2V0KHRwLT50dF9rZWVwLCB0Y3Bfa2Vl cGluaXQsIHRjcF90aW1lcl9rZWVwLCB0cCk7DQotCXRwLT5pc3MgPSB0Y3Bf cm5kaXNzX25leHQoKTsNCi0JdGNwX3NlbmRzZXFpbml0KHRwKTsNCiANCiAJ LyoNCiAJICogR2VuZXJhdGUgYSBDQyB2YWx1ZSBmb3IgdGhpcyBjb25uZWN0 aW9uIGFuZA0KQEAgLTc4Miw2ICs3ODAsOSBAQA0KIAkJdHAtPnRfZmxhZ3Mg fD0gVEZfU0VORENDTkVXOw0KIAl9DQogDQorCXRwLT5pc3MgPSB0Y3BfbmV4 dF9pc24odGFvcCk7DQorCXRjcF9zZW5kc2VxaW5pdCh0cCk7DQorDQogCXJl dHVybiAwOw0KIH0NCiANCkBAIC04NTMsOCArODU0LDYgQEANCiAJdGNwc3Rh dC50Y3BzX2Nvbm5hdHRlbXB0Kys7DQogCXRwLT50X3N0YXRlID0gVENQU19T WU5fU0VOVDsNCiAJY2FsbG91dF9yZXNldCh0cC0+dHRfa2VlcCwgdGNwX2tl ZXBpbml0LCB0Y3BfdGltZXJfa2VlcCwgdHApOw0KLQl0cC0+aXNzID0gdGNw X3JuZGlzc19uZXh0KCk7DQotCXRjcF9zZW5kc2VxaW5pdCh0cCk7DQogDQog CS8qDQogCSAqIEdlbmVyYXRlIGEgQ0MgdmFsdWUgZm9yIHRoaXMgY29ubmVj dGlvbiBhbmQNCkBAIC04NzMsNiArODcyLDkgQEANCiAJCXRhb3AtPnRhb19j Y3NlbnQgPSAwOw0KIAkJdHAtPnRfZmxhZ3MgfD0gVEZfU0VORENDTkVXOw0K IAl9DQorDQorCXRwLT5pc3MgPSB0Y3BfbmV4dF9pc24odGFvcCk7DQorCXRj cF9zZW5kc2VxaW5pdCh0cCk7DQogDQogCXJldHVybiAwOw0KIH0NCk9ubHkg aW4gbmV0aW5ldC86IHRjcF91c3JyZXEuYy5vcmlnDQpkaWZmIC11IC1yIG5l dGluZXQub2xkL3RjcF92YXIuaCBuZXRpbmV0L3RjcF92YXIuaA0KLS0tIG5l dGluZXQub2xkL3RjcF92YXIuaAlUaHUgSnVuICA3IDE2OjAyOjAxIDIwMDEN CisrKyBuZXRpbmV0L3RjcF92YXIuaAlUaHUgSnVuICA3IDE3OjQwOjE1IDIw MDENCkBAIC0xODksNiArMTg5LDcgQEANCiAJdGNwX2NjCXRhb19jYzsJCQkv KiBsYXRlc3QgQ0MgaW4gdmFsaWQgU1lOICovDQogCXRjcF9jYwl0YW9fY2Nz ZW50OwkJLyogbGF0ZXN0IENDIHNlbnQgdG8gcGVlciAqLw0KIAl1X3Nob3J0 CXRhb19tc3NvcHQ7CQkvKiBwZWVyJ3MgY2FjaGVkIE1TUyAqLw0KKwl1X3No b3J0IHRhb19pc247CQkvKiBpbml0aWFsIHNlZ21lbnQgbnVtYmVyIHRvIHNl bmQgdG8gcGVlciAqLw0KICNpZmRlZiBub3R5ZXQNCiAJdV9zaG9ydAl0YW9f ZmxhZ3M7CQkvKiBjYWNoZSBzdGF0dXMgZmxhZ3MgKi8NCiAjZGVmaW5lCVRB T0ZfRE9OVAkweDAwMDEJCS8qIHBlZXIgZG9lc24ndCB1bmRlcnN0YW5kIHJm YzE2NDQgKi8NCkBAIC00MDksMTAgKzQxMCw3IEBADQogZXh0ZXJuCXN0cnVj dCBwcl91c3JyZXFzIHRjcF91c3JyZXFzOw0KIGV4dGVybgl1X2xvbmcgdGNw X3NlbmRzcGFjZTsNCiBleHRlcm4JdV9sb25nIHRjcF9yZWN2c3BhY2U7DQot dm9pZAl0Y3Bfcm5kaXNzX2luaXQgX19QKCh2b2lkKSk7DQotdGNwX3NlcQl0 Y3Bfcm5kaXNzX25leHQgX19QKCh2b2lkKSk7DQotdV9pbnQxNl90DQotCXRj cF9ybmRpc3NfZW5jcnlwdCBfX1AoKHVfaW50MTZfdCkpOw0KK3RjcF9zZXEJ dGNwX25leHRfaXNuIF9fUCgoc3RydWN0IHJteHBfdGFvICopKTsNCiANCiAj ZW5kaWYgLyogX0tFUk5FTCAqLw0KIA0KT25seSBpbiBuZXRpbmV0LzogdGNw X3Zhci5oLm9yaWcNCg== --0-228414066-991979776=:92206-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Jun 7 23:29:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 9C31137B407 for ; Thu, 7 Jun 2001 23:29:40 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 92272 invoked by uid 1000); 8 Jun 2001 06:29:39 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 06:29:39 -0000 Date: Fri, 8 Jun 2001 01:29:39 -0500 (CDT) From: Mike Silbersack To: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <20010608005234.W92206-200000@achilles.silby.com> Message-ID: <20010608012844.T92270-100000@achilles.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 Those who were unable to use the attached patch for whatever reason may also access it at: http://www.silby.com/patches/silby_isn_generation.patch 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 Fri Jun 8 2:51:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by hub.freebsd.org (Postfix) with ESMTP id 83E0B37B401; Fri, 8 Jun 2001 02:51:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id FAA18005; Fri, 8 Jun 2001 05:51:14 -0400 (EDT) Message-ID: <3B20A02E.B1507A80@mindspring.com> Date: Fri, 08 Jun 2001 02:51:42 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed References: <20010608005234.W92206-200000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack wrote: > Q: How does this new patch generate sequence numbers? > > A: In short, the patch provides a seperate sequence number > space for each host. These sequence spaces have no > relation to the sequence spaces of other hosts, and > are re-randomized whenever a host becomes idle. > > Q: How is this done? > > A: We are able to store a 16-bit variable which corresponds > to the upper 16 bits of a host's sequence number in the > cloned route entry for that host, thanks to extra space > which exists in the routing metric structure. OK, I read the code. Not to poop the party, but off the top of my head, I have several major objections: 1) You stole the space reserved for the cache status flags; calling it 'tao_flags' would have been more honest. 2) This doesn't work right for cloned routes. 3) This blows up if you delete and re-add the default route, and the route in question is a clone of the default. 4) Your claim of "extra space" comes because you are allocating these things with a cruddy allocator; some of us aren't wasting the same space in our kernel that the rest of you are, and don't intend for that practice to continue for the rest of you very much longer. 5) This blows up for keepalive packet sends, which use preallocated tcptemplate structures, which get a copy of the first header in when setting up a connection; check the keepalive sequence numbers using your new scheme... 6) This adds per-connection state, which is evil when you want a lot of connections: the way to get a lot of connections is to remove as much per-connection state as possible, which in turn reduces your per-connection resource costs, and that in turn increases the number of connections you are capable of sustaining with a constant set of resources. 7) The "monotonicity in TIME_WAIT" problem you mention is not really a problem. It is the 2*MSL value of 30 seconds and a tcp_timer that controls that; the sequence number is irrelevent (if you can prove your claim of "funky" in a bit more detail than simply calling it that, I would be willing to withdraw this objection; but I think the other six stand on ther own, still). I'm sure anyone with an "IP failover" or "IP takeover" product could probably come up with several other major objections; I don't know if anyone has implemented NECP sevices on FreeBSD, or "Direct Server Return" switch hacking of packets with Apache on FreeBSD cooperation, but I would be surprised if people who have would not also have objections. Is there any way you could do this using the ip/port pair as the means of preterbation instead? That might not be as aggregious, though I suspect it would still cause problems in two of the cases... even if it did get rid of the per-connection state information. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 8 7:37:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id E76ED37B401 for ; Fri, 8 Jun 2001 07:37:16 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 93348 invoked by uid 1000); 8 Jun 2001 14:37:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 14:37:15 -0000 Date: Fri, 8 Jun 2001 09:37:15 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <3B20A02E.B1507A80@mindspring.com> Message-ID: <20010608080013.F93237-100000@achilles.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, 8 Jun 2001, Terry Lambert wrote: > OK, I read the code. Not to poop the party, but off the top > of my head, I have several major objections: > > 1) You stole the space reserved for the cache status > flags; calling it 'tao_flags' would have been more > honest. rmx_filler still has extra space in it, there's no problem fitting in tao_flags when and if it becomes used. > 2) This doesn't work right for cloned routes. On the contrary, it only works for cloned routes. > 3) This blows up if you delete and re-add the default > route, and the route in question is a clone of the > default. Yes, this will cause the cloned route to get blown away, and the ISN reset. This is only a minor issue, and can be ignored unless a host sees frequent route changes. Even if the cloned route is blown away frequently, this will simply cause the algorithm to revert to totally random ISNs, which isn't the end of the world. Can anyone who's familiar with FreeBSD boxes which serve as routers confirm how route changes affect their cloned routes? > 4) Your claim of "extra space" comes because you > are allocating these things with a cruddy > allocator; some of us aren't wasting the same > space in our kernel that the rest of you are, > and don't intend for that practice to continue > for the rest of you very much longer. I fail to see how basing a patch for FreeBSD on FreeBSD is a strike against it. If you have a new route table, please post information about it so that we can all see how it wll affect this patch and others. > 5) This blows up for keepalive packet sends, which > use preallocated tcptemplate structures, which > get a copy of the first header in when setting > up a connection; check the keepalive sequence > numbers using your new scheme... Why would changing ISN generation affect keepalive packets? I haven't changed how connection setup works whatsoever. > 6) This adds per-connection state, which is evil > when you want a lot of connections: the way to > get a lot of connections is to remove as much > per-connection state as possible, which in turn > reduces your per-connection resource costs, and > that in turn increases the number of connections > you are capable of sustaining with a constant > set of resources. This patch doesn't add per-connection state. The additional 16 bits added to the route structure were already present as unused space. > 7) The "monotonicity in TIME_WAIT" problem you mention > is not really a problem. It is the 2*MSL value of > 30 seconds and a tcp_timer that controls that; the > sequence number is irrelevent (if you can prove > your claim of "funky" in a bit more detail than > simply calling it that, I would be willing to > withdraw this objection; but I think the other six > stand on ther own, still). Go read RFC 793, or this chunk of code from tcp_input.c: /* * If a new connection request is received * while in TIME_WAIT, drop the old connection * and start over if the sequence numbers * are above the previous ones. */ if (thflags & TH_SYN && tp->t_state == TCPS_TIME_WAIT && SEQ_GT(th->th_seq, tp->rcv_nxt)) { iss = tcp_next_isn(taop); tp = tcp_close(tp); goto findpcb; } I didn't create this behavior; it's been part of *BSD for a very long time. We must respect it, as we cannot change it now. > I'm sure anyone with an "IP failover" or "IP takeover" > product could probably come up with several other major > objections; I don't know if anyone has implemented NECP > sevices on FreeBSD, or "Direct Server Return" switch > hacking of packets with Apache on FreeBSD cooperation, > but I would be surprised if people who have would not > also have objections. Any package that depended on predictable sequence numbers would've broken twice in the last 9 months already. If there were any complaints at those times, they didn't appear on the lists, and didn't lead to the ISN generation being changed then. If you're in one of the above classes of people, I'd like to hear from you to better understand the issue; the NECP RFC draft didn't appear to have any information on this topic, as far as I could tell. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 8 7:46: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 0577F37B403 for ; Fri, 8 Jun 2001 07:45:58 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 93366 invoked by uid 1000); 8 Jun 2001 14:45:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 14:45:57 -0000 Date: Fri, 8 Jun 2001 09:45:57 -0500 (CDT) From: Mike Silbersack To: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <20010608005234.W92206-200000@achilles.silby.com> Message-ID: <20010608094440.Q93237-100000@achilles.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 For those interested, I've put up a patch which will show you the ISNs used for outgoing connections with the new generation method at: http://www.silby.com/patches/silby_isn_generation_debug.patch Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 8 11:36:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp-server2.tampabay.rr.com (smtp-server2.cfl.rr.com [65.32.2.69]) by hub.freebsd.org (Postfix) with ESMTP id E827937B405 for ; Fri, 8 Jun 2001 11:36:52 -0700 (PDT) (envelope-from dananderson@cfl.rr.com) Received: from beastie (ubr-a-33.107.139.wintersprings.cfl.rr.com [65.33.107.139]) by smtp-server2.tampabay.rr.com (8.11.2/8.11.2) with SMTP id f58Iapv16308 for ; Fri, 8 Jun 2001 14:36:51 -0400 (EDT) From: "Dan Anderson" To: Subject: mpd and windows shares Date: Fri, 8 Jun 2001 14:32:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-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 trying to implement a way for remote users to gain access to a local office's windows shares. What I currently have is a FreeBSD box with mpd-netgraph installed, dc0 is connected to the isp via a static ip, ne0 is connected to the local net. +----------+ +---------------------+ | | dc0 -> 1.2.3.4 5.6.7.8 | | | FreeBSD |-------------------> internet <--------------| Win 98, NT via pptp | | | | | |----------+ +---------------------+ | | ne0 -> 192.168.1.90 | +---------------------------------------- ... etc | | | 192.168.1.101 | 192.168.1.102 | | +------+ +------+ | NT 1 | | NT 2 | +------+ +------+ mpd.conf -------- default: load pptp pptp: new -i ng0 pptp pptp set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle disable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set ipcp yes vjcomp set ipcp ranges 192.168.1.90/32 192.168.1.95/32 set ipcp dns 3.4.5.6 (my isp's dns) set ipcp nbns 192.168.1.90 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set bundle yes crypt-reqd mpd.links --------- pptp: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate When I connect with pptp I end up with ng0 being created and the following two commands are executed by mpd: /sbin/ifconfig ng0 192.168.1.90 192.168.1.95 netmask 0xffffffff -link0 /usr/sbin/arp -s 192.168.1.95 00:11:22:33:44:55 pub (changed my mac addr) My understanding is this makes the FreeBSD machine have an ip of 192.168.1.90 on ng0 and the traffic from the remote windows machine will be 192.168.1.95 on ng0. From the remote machine I can ping 192.168.1.95 as well as 192.168.1.90 but not any of the other machines. Also, I do not have a route from 192.168.1.95 out to the isp via 1.2.3.4. Any input as to what I'm doing incorrectly? I sense I'm close but am missing a key piece of information to put it all together. Most likely I just don't have any routing information or something like that. Thanks for your input, Dan Anderson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 8 12: 6:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from brisefer.cediti.be (brisefer.cediti.be [193.190.156.67]) by hub.freebsd.org (Postfix) with ESMTP id B1D2E37B406 for ; Fri, 8 Jun 2001 12:06:12 -0700 (PDT) (envelope-from Olivier.Cherrier@cediti.be) Received: by brisefer.cediti.be with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Jun 2001 21:03:15 +0200 Message-ID: From: Olivier Cherrier To: freebsd-net@FreeBSD.ORG Subject: RE: mpd and windows shares Date: Fri, 8 Jun 2001 21:03:07 +0200 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 >Hi, Hi > >I'm trying to implement a way for remote users to gain access >to a local >office's windows shares. What I currently have is a FreeBSD box with >mpd-netgraph installed, dc0 is connected to the isp via a >static ip, ne0 is >connected to the local net. > >+----------+ >+---------------------+ >| | dc0 -> 1.2.3.4 5.6.7.8 | >| >| FreeBSD |-------------------> internet <--------------| >Win 98, NT via >pptp | >| | | >| >|----------+ >+---------------------+ > | > | ne0 -> 192.168.1.90 > | > +---------------------------------------- ... etc > | | > | 192.168.1.101 | 192.168.1.102 > | | > +------+ +------+ > | NT 1 | | NT 2 | > +------+ +------+ > >mpd.conf >-------- >default: > load pptp > >pptp: > new -i ng0 pptp pptp > set iface disable on-demand > set iface enable proxy-arp > set iface idle 1800 > set bundle disable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 10 60 > set ipcp yes vjcomp > set ipcp ranges 192.168.1.90/32 192.168.1.95/32 > set ipcp dns 3.4.5.6 (my isp's dns) > set ipcp nbns 192.168.1.90 > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > set bundle yes crypt-reqd > >mpd.links >--------- >pptp: > set link type pptp > set pptp self 1.2.3.4 > set pptp enable incoming > set pptp disable originate Note that "set pptp self x.x.x.x" must be the network interface on which mpd waits connections. > > >When I connect with pptp I end up with ng0 being created and >the following >two commands are executed by mpd: > /sbin/ifconfig ng0 192.168.1.90 192.168.1.95 netmask >0xffffffff -link0 > /usr/sbin/arp -s 192.168.1.95 00:11:22:33:44:55 pub > (changed my >mac addr) Why don't you use the proxy-arp facility ? Mpd has proxy-arp integrated. The big Archie could correct me but, I think mpd can do the arp and network routing modification for you. > >My understanding is this makes the FreeBSD machine have an ip of >192.168.1.90 on ng0 and the traffic from the remote windows >machine will be >192.168.1.95 on ng0. From the remote machine I can ping >192.168.1.95 as >well as 192.168.1.90 but not any of the other machines. Also, >I do not have >a route from 192.168.1.95 out to the isp via 1.2.3.4. Haven't you got IPF rules activated ? oc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 8 17:56:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 563D537B405; Fri, 8 Jun 2001 17:56:11 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id RAA15083; Fri, 8 Jun 2001 17:56:09 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id RAA80976; Fri, 8 Jun 2001 17:56:08 -0700 (PDT) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id RAA16800; Fri, 8 Jun 2001 17:56:08 -0700 (PDT) From: Don Lewis Message-Id: <200106090056.RAA16800@salsa.gv.tsc.tdk.com> Date: Fri, 8 Jun 2001 17:56:07 -0700 In-Reply-To: <20010608005234.W92206-200000@achilles.silby.com> References: <20010608005234.W92206-200000@achilles.silby.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Mike Silbersack , , Subject: Re: New TCP sequence number generation algorithm; review needed Sender: owner-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 Jun 8, 12:56am, Mike Silbersack wrote: } Subject: New TCP sequence number generation algorithm; review needed [ snip ] } Q: How does this new patch generate sequence numbers? } } A: In short, the patch provides a seperate sequence number space for each } host. These sequence spaces have no relation to the sequence spaces of } other hosts, and are re-randomized whenever a host becomes idle. } } Q: How is this done? } } A: We are able to store a 16-bit variable which corresponds to the upper } 16 bits of a host's sequence number in the cloned route entry for that } host, thanks to extra space which exists in the routing metric structure. } When we need a new sequence number for a host, we load in that value. If } it is zero, as it is when the route is first cloned, we initialize it to a } random value. Then, on this connection and every one after, we shift it } left by 16 bits and increment it by a random value of up to 2^20. } Subsequently, we store the upper 16 bits of the resulting value back in } the cloned route entry, waiting for the next sequence number. Checks are } present to make sure that the sequence number always increments by more } than 2^16-1 and that the sequence number does not go to zero and cause a } re-randomization. If a host is idle for a long period of time, the cloned } route entry will be flushed and we will start the process over. [ snip ] } Q: Ok, what's this RFC1948 sequence number generation scheme I keep } hearing about? } } A: RFC1948 suggests segementing each hostA/portA/hostB/portB pair into a } seperate sequence number space using a hash function of the form: } } ISN = timecounter + MD5(localhost, localport, remotehost, remoteport, shared secret) } } While clever, this algorithm has a major weakness. The shared secret is } used in generating the ISN for all connections to the host in question. } To ensure monotonicity for each connection, this implies that the shared } secret must remain constant for the entire uptime of a machine. As a } result, attackers may make a few connection attempts, store the IPs/ports } used and the sequence number returned. This information can then be fed } into a cracking program which will determine the shared secret. Once the } shared secret is found, the attacker can perfectly spoof a connection to } the machine from any host until the machine is rebooted and the shared } secret changed. [ snip ] Why not combine the two schemes and feed the random per-host data from the cloned route entry into the RFC1948 algorithm? This doesn't solve Terry's objection, though. Another way of strengthening the RFC1948 would be to use some of the bits of MD5(remostehost, another secret) to extract the shared secret from a larger table. This increases the difficulty of discovering the shared secret needed to spoof the host in question, but it doesn't solve the problem of needing to keep the same shared secrets for the uptime of the machine. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Jun 8 19:56:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 156A637B405 for ; Fri, 8 Jun 2001 19:56:24 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 94617 invoked by uid 1000); 9 Jun 2001 02:56:22 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jun 2001 02:56:22 -0000 Date: Fri, 8 Jun 2001 21:56:22 -0500 (CDT) From: Mike Silbersack To: Don Lewis Cc: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <200106090056.RAA16800@salsa.gv.tsc.tdk.com> Message-ID: <20010608214621.V94603-100000@achilles.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, 8 Jun 2001, Don Lewis wrote: > Why not combine the two schemes and feed the random per-host data from > the cloned route entry into the RFC1948 algorithm? This doesn't solve > Terry's objection, though. That thought had occured to me, but I'm not sure it would actually add any security. I've been requested to pose the algorithm to people from outside the FreeBSD project and what they think about its strength. When I hear back from them, I'll post more details. Terry needs to clarify his objections. #3 is the only one which is definitely valid. 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 Jun 9 3:22:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 8606237B401; Sat, 9 Jun 2001 03:22:42 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f59AMRn87725; Sat, 9 Jun 2001 13:22:27 +0300 (EEST) (envelope-from ru) Date: Sat, 9 Jun 2001 13:22:27 +0300 From: Ruslan Ermilov To: Terry Lambert Cc: Mike Silbersack , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed Message-ID: <20010609132227.B87114@sunbay.com> Mail-Followup-To: Terry Lambert , Mike Silbersack , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG References: <20010608005234.W92206-200000@achilles.silby.com> <3B20A02E.B1507A80@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B20A02E.B1507A80@mindspring.com>; from tlambert2@mindspring.com on Fri, Jun 08, 2001 at 02:51:42AM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jun 08, 2001 at 02:51:42AM -0700, Terry Lambert wrote: [...] > > 6) This adds per-connection state, which is evil > when you want a lot of connections: the way to > get a lot of connections is to remove as much > per-connection state as possible, which in turn > reduces your per-connection resource costs, and > that in turn increases the number of connections > you are capable of sustaining with a constant > set of resources. > Umm, this adds a per-destination, not per-connection state. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 9 3:29:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 89A7B37B401; Sat, 9 Jun 2001 03:29:22 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f59AT6d88153; Sat, 9 Jun 2001 13:29:06 +0300 (EEST) (envelope-from ru) Date: Sat, 9 Jun 2001 13:29:06 +0300 From: Ruslan Ermilov To: Mike Silbersack Cc: Terry Lambert , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed Message-ID: <20010609132906.C87114@sunbay.com> Mail-Followup-To: Mike Silbersack , Terry Lambert , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG References: <3B20A02E.B1507A80@mindspring.com> <20010608080013.F93237-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010608080013.F93237-100000@achilles.silby.com>; from silby@silby.com on Fri, Jun 08, 2001 at 09:37:15AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jun 08, 2001 at 09:37:15AM -0500, Mike Silbersack wrote: > > On Fri, 8 Jun 2001, Terry Lambert wrote: > > > OK, I read the code. Not to poop the party, but off the top > > of my head, I have several major objections: > > > > 1) You stole the space reserved for the cache status > > flags; calling it 'tao_flags' would have been more > > honest. > > rmx_filler still has extra space in it, there's no problem fitting in > tao_flags when and if it becomes used. > > > 2) This doesn't work right for cloned routes. > > On the contrary, it only works for cloned routes. > > > 3) This blows up if you delete and re-add the default > > route, and the route in question is a clone of the > > default. > > Yes, this will cause the cloned route to get blown away, and the ISN > reset. This is only a minor issue, and can be ignored unless a host sees > frequent route changes. Even if the cloned route is blown away > frequently, this will simply cause the algorithm to revert to totally > random ISNs, which isn't the end of the world. > This still could be handled. When the parent (or even this particular) route is deleted, it is only deleted from the routing table and is marked as "down". TCP's PCB still holds on it. On the next socket write, ip_output() sees that the route is no longer "up", and reallocates the new route. tcp_output() could check that the cached route is still up before passing it to ip_output(), and reallocate the route preserving the old value of ISN (thus avoiding the re-randomization of the latter). Alternatively, ip_output() could probably do this. Just an untested idea. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 9 4:38:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by hub.freebsd.org (Postfix) with ESMTP id D877837B401 for ; Sat, 9 Jun 2001 04:38:24 -0700 (PDT) (envelope-from Peter.Blok@inter.NL.net) Received: from ntpc by altrade.nijmegen.inter.nl.net via 1Cust116.tnt30.rtm1.nl.uu.net [213.116.154.116] with SMTP id NAA17314 (8.8.8/1.3); Sat, 9 Jun 2001 13:38:20 +0200 (MET DST) Reply-To: From: "Peter Blok" To: "'Archie Cobbs'" Cc: Subject: RE: mpd netgraph bridge Date: Sat, 9 Jun 2001 13:34:41 +0200 Message-ID: <000201c0f0d8$2d436e90$8a02a8c0@ntpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200106080016.f580GdV03431@arch20m.dellroad.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Archie, Let me explain a little bit more. I use mpd-netgraph to establish a PPTP session to my ADSL provider. When the session is available, ng0 has the public IP address associated with it. ifconfig ng0 shows: public IP -> some IP All the traffic on the public IP address needs to be forwarded without translation to an another ethernet port which has a hardware VPN router that responds to the public IP address. In both directions there should be no translation. I don't think proxy arp will work here. I was hoping to use a set ng hook mpd-netgraph command to link it to another ethernet port. Peter -----Original Message----- From: Archie Cobbs [mailto:archie@dellroad.org] Sent: Friday, June 08, 2001 02:17 To: Peter.Blok@inter.NL.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: mpd netgraph bridge Peter Blok writes: > I have a PPTP connection to my ADSL provider, using mpd-netgraph. It is > available on ng0. I'd like to bridge this with netgraph to a separate > ethernet interface sf3. Is this possible? I have looked at examples, but > they don't work because ng0 is not of type ether. I don't understand.. how do you expect to bridge a point-to-point interface? Why not just have mpd assign the remote side an IP address on the Ethernet netrange using proxy ARP? Eg. "set iface enable proxy-arp"... -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 9 10:47:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id 9965937B401; Sat, 9 Jun 2001 10:47:22 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA17645; Sat, 9 Jun 2001 13:47:17 -0400 (EDT) Message-ID: <3B226142.59A48940@mindspring.com> Date: Sat, 09 Jun 2001 10:47:46 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Don Lewis , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed References: <20010608214621.V94603-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Silbersack wrote: > > On Fri, 8 Jun 2001, Don Lewis wrote: > > > Why not combine the two schemes and feed the random > > per-host data from the cloned route entry into the > > RFC1948 algorithm? This doesn't solve Terry's objection, > > though. > > That thought had occured to me, but I'm not sure it would > actually add any security. It would not. Big Number Theory(tm) tells us that multiplying or adding one random number to another actually ends up with the result being _less random_. > Terry needs to clarify his objections. #3 is the only one > which is definitely valid. I disagree (of course), but will clarify later in response to your response; I really don't have time for the hour or so of deep thinking necessary to refute your objections (feel flattered, if you like, for "stumping" me... not really that hard, since you seem to be on the ball 8-)), since the points you raise involve some significant subtleties that are not really obvious without a lot of careful thought. I can't really do justice to the concepts necessary to express the fundamental objections right now, as I have other demands on my time which take precedence right now (I'm just going through my email very quickly). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Jun 9 10:52:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by hub.freebsd.org (Postfix) with ESMTP id 31A7137B401; Sat, 9 Jun 2001 10:52:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA15183; Sat, 9 Jun 2001 13:52:05 -0400 (EDT) Message-ID: <3B226262.AF4858E2@mindspring.com> Date: Sat, 09 Jun 2001 10:52:34 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Mike Silbersack , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed References: <20010608005234.W92206-200000@achilles.silby.com> <3B20A02E.B1507A80@mindspring.com> <20010609132227.B87114@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ruslan Ermilov wrote: > > On Fri, Jun 08, 2001 at 02:51:42AM -0700, Terry Lambert wrote: > [...] > > > > 6) This adds per-connection state, which is evil > > when you want a lot of connections: the way to > > get a lot of connections is to remove as much > > per-connection state as possible, which in turn > > reduces your per-connection resource costs, and > > that in turn increases the number of connections > > you are capable of sustaining with a constant > > set of resources. > > > Umm, this adds a per-destination, not per-connection state. For things like web servers, where the destination is a client PC with a single user, the net effect is per-connection state, since magnitude(connection) == magnitude(destination). The only escape is an edge proxy for multiple clients at a single site. I agree that this is a possibility, but I think the majority of web site traffic is single client, no pedge proxy. Note that even if there _is_ an edge proxy, that the proxy itself will satisfy the request: the origin server will never see it. As a result, we are back to ther being a direct correlation,. i.e.: magnitude(connection) == magnitude(destination), from the point of view of the server. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message