From owner-freebsd-net@FreeBSD.ORG Mon Aug 23 11:02:04 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A48316A516 for ; Mon, 23 Aug 2004 11:02:04 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27D0E43D5A for ; Mon, 23 Aug 2004 11:02:04 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i7NB24Q0029823 for ; Mon, 23 Aug 2004 11:02:04 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7NB23R3029817 for freebsd-net@freebsd.org; Mon, 23 Aug 2004 11:02:03 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 23 Aug 2004 11:02:03 GMT Message-Id: <200408231102.i7NB23R3029817@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 11:02:04 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [1999/11/26] kern/15095 net TCP's advertised window is not scaled imm o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 3 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 23 16:56:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77D3816A4CE for ; Mon, 23 Aug 2004 16:56:53 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 554D343D45 for ; Mon, 23 Aug 2004 16:56:53 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id D84542FA7D; Mon, 23 Aug 2004 12:56:52 -0400 (EDT) Date: Mon, 23 Aug 2004 12:56:52 -0400 From: James To: freebsd-net@freebsd.org Message-ID: <20040823165652.GA66643@scylla.towardex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: newbie question: What is the purpose of PRCLONING? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 16:56:53 -0000 Hi, I am aware that prcloning is removed in current-5, but do have a question as I still have some boxes running 4.x custom code. My assumption of PRCLONING existance is to assist TCP applications (i.e. host cache) to use routing table as its caching mechanism.. Is this a correct assumption? And, if that is true, would it hurt to remove prcloning feature off of the 4.x routing code? What kind of breakage would I expect in doing so with tcp apps? I'd figure as long as they can find a prefix to get out to the world, and doesn't have to be a /32 prcloned route, it would be ok, no? Thanks for the tips :) -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-net@FreeBSD.ORG Mon Aug 23 19:19:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF4AA16A4CE for ; Mon, 23 Aug 2004 19:19:00 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABF943D2D for ; Mon, 23 Aug 2004 19:19:00 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.179] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BzKLL-0004GB-00 for freebsd-net@freebsd.org; Mon, 23 Aug 2004 21:18:59 +0200 Received: from [217.227.151.181] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BzKLL-0005gR-00 for freebsd-net@freebsd.org; Mon, 23 Aug 2004 21:18:59 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 23 Aug 2004 21:17:22 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_DLkKBFQvqJ4kne2"; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408232117.23578.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: RELENG_5 material? ip_output.c#rev.1.227 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 19:19:00 -0000 --Boundary-02=_DLkKBFQvqJ4kne2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I'd like to merge the following diff to RELENG_5 in order to gain performan= ce=20 for the most common ALTQ setups (huge, unALTQed LAN-if and small(er), ALTQe= d=20 WAN-uplink). It is really straight forward, please look at the diff and tel= l=20 me what you think: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1= =3D1.226&r2=3D1.227&f=3Dh Thanks in advance! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_DLkKBFQvqJ4kne2 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBKkLDXyyEoT62BG0RAr30AJ45pwljWUaMBzRYCN4cej+sQOmORACfWj+D cgapnQOQImRh1uGgtlhAHA4= =PkbQ -----END PGP SIGNATURE----- --Boundary-02=_DLkKBFQvqJ4kne2-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 23 20:29:06 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 636F216A52D for ; Mon, 23 Aug 2004 20:29:05 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id A620C43D2F for ; Mon, 23 Aug 2004 20:29:04 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BzLRA-0003qu-00 for freebsd-net@freebsd.org; Mon, 23 Aug 2004 22:29:04 +0200 Received: from [217.227.151.181] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BzLR9-0005Pl-00 for freebsd-net@freebsd.org; Mon, 23 Aug 2004 22:29:03 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 23 Aug 2004 22:27:26 +0200 User-Agent: KMail/1.6.2 References: <200408232117.23578.max@love2party.net> <412A4742.5020502@elischer.org> In-Reply-To: <412A4742.5020502@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_vMlKBJ/yJhgYksT"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408232227.27474.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: RELENG_5 material? ip_output.c#rev.1.227 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2004 20:29:06 -0000 --Boundary-02=_vMlKBJ/yJhgYksT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 23 August 2004 21:36, Julian Elischer wrote: > what's the result of this..? Uhg ... I knew I was missing something. This will re-enable the so called "early drop hack" that checks early in th= e=20 output path whether or not there is room left in the interface queue. This= =20 reduces the workload and the network lock contention as it avoids unnecessa= ry=20 progressing of packets that can't be queued (and later sent out) anyway. =46or ALTQ enabled queues the check is disabled. Before this change it was= =20 disabled for *all* queues once you put in "options ALTQ". > Max Laier wrote: > >Hi, > > > >I'd like to merge the following diff to RELENG_5 in order to gain > > performance for the most common ALTQ setups (huge, unALTQed LAN-if and > > small(er), ALTQed WAN-uplink). It is really straight forward, please lo= ok > > at the diff and tell me what you think: > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r= 1=3D > >1.226&r2=3D1.227&f=3Dh > > > >Thanks in advance! =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_vMlKBJ/yJhgYksT Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD4DBQBBKlMvXyyEoT62BG0RAq3EAJiPVLVAUhrNGJ4mVfSDxfa6pdwvAJsGRXgR MhPtB5qN0eRFgjJLhwLU6A== =XyKz -----END PGP SIGNATURE----- --Boundary-02=_vMlKBJ/yJhgYksT-- From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 04:21:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E50DC16A4CE for ; Tue, 24 Aug 2004 04:21:23 +0000 (GMT) Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A64243D62 for ; Tue, 24 Aug 2004 04:21:23 +0000 (GMT) (envelope-from ababurko@adelphia.net) Received: from ample.adelphia.net ([24.52.224.96]) by mta13.adelphia.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20040824042122.WWAJ24693.mta13.adelphia.net@ample.adelphia.net> for ; Tue, 24 Aug 2004 00:21:22 -0400 Message-Id: <5.2.1.1.0.20040824002044.00aded88@mail.dc2.adelphia.net> X-Sender: ababurko@mail.dc2.adelphia.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 24 Aug 2004 00:21:22 -0400 To: freebsd-net@freebsd.org From: Bob Ababurko Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: portscan looks like..... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 04:21:24 -0000 Hello- I have just done a portscan on my FreeBSD box running 5.2.1 and got : PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 1023/tcp open netvenuechat now, i made a faux pas when i configured this machine and had made this a nfs client...i belive that was the case. I am now interested in turning this off, and will be able to do that with rpcbind_enable="NO" in rc.conf. Then there is the case of the port 1023. I have no idea how to turn this off or how it got turned on. Could the rpcbind allowed someone into my computer to hack it up? I am pretty scared at this point. Can somone help me? thanks, Bob From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 04:37:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB7C16A4CE for ; Tue, 24 Aug 2004 04:37:56 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BBEEC43D3F for ; Tue, 24 Aug 2004 04:37:55 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 24625 invoked from network); 24 Aug 2004 04:37:54 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 24 Aug 2004 04:37:54 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 23 Aug 2004 23:37:53 -0500 (CDT) From: Mike Silbersack To: Bob Ababurko In-Reply-To: <5.2.1.1.0.20040824002044.00aded88@mail.dc2.adelphia.net> Message-ID: <20040823233645.D1165@odysseus.silby.com> References: <5.2.1.1.0.20040824002044.00aded88@mail.dc2.adelphia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: portscan looks like..... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 04:37:56 -0000 On Tue, 24 Aug 2004, Bob Ababurko wrote: > Hello- > > I have just done a portscan on my FreeBSD box running 5.2.1 and got : > > PORT STATE SERVICE > 22/tcp open ssh > 25/tcp open smtp > 80/tcp open http > 111/tcp open rpcbind > 1023/tcp open netvenuechat > > now, i made a faux pas when i configured this machine and had made this a nfs > client...i belive that was the case. I am now interested in turning this > off, and will be able to do that with rpcbind_enable="NO" in rc.conf. > Then there is the case of the port 1023. I have no idea how to turn this > off or how it got turned on. Could the rpcbind allowed someone into my > computer to hack it up? I am pretty scared at this point. Can somone help > me? > > thanks, > Bob Use sockstat to see which program is attached to which socket. IIRC, RPC services are assigned semi-random ports, so 1023 might be what one of the NFS services was assigned that time. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 09:16:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D97C16A4CE for ; Tue, 24 Aug 2004 09:16:43 +0000 (GMT) Received: from happy.kiev.ua (happy.kiev.ua [193.109.241.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 977E543D2D for ; Tue, 24 Aug 2004 09:16:42 +0000 (GMT) (envelope-from gul@happy.kiev.ua) Received: from gul by happy.kiev.ua with local (Exim 4.41) id 1BzXPz-0003DA-3c for freebsd-net@freebsd.org; Tue, 24 Aug 2004 12:16:39 +0300 Date: Tue, 24 Aug 2004 12:16:38 +0300 From: Pavel Gulchouck To: freebsd-net@freebsd.org Message-ID: <20040824091638.GE27112@happy.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Linux X-FTN-Address: 2:463/68 X-Flames-To: /dev/null X-GC: GCC d- s+: a33 C+++ UL++++ UB++++ P+ L++ E--- W++ N++ o-- K- w--- O++ X-GC: M? V- PS PE+ Y+ PGP+ t? 5? X? R? !tv b+ DI? D? G e h--- r+++ y+++ User-Agent: Mutt/1.5.6i Subject: FIN_WAIT_2 timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gul@gul.kiev.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 09:16:43 -0000 Hi. I have hangs tcp-sessions in the FIN_WAIT_2 state, in which packets sends to remote for several days. Sockstate tells none aboute its, restart httpd has no effect. http://httpd.apache.org/docs/misc/fin_wait_2.html says that FreeBSD has a timeout for FIN_WAIT_2 state, but I don't see it. Number of such sessions grows according to uptime. FreeBSD 5.2.1-RELEASE-p9. Any suggestions? root@racoon:~>netstat -na | fgrep 195.248.160.78 tcp4 0 0 193.109.240.55.80 195.248.160.78.59843 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.56084 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.37466 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.31848 FIN_WAIT_2 [...] root@racoon:~>sockstat | fgrep 195.248.160.78 root@racoon:~>netstat -na | grep -c FIN_WAIT_2 419 tcpdump shows: 20:43:54.922521 hosting.itpark.com.ua.http > 195.248.160.78.48714: . ack 3765418226 win 0 20:43:54.923546 hosting.itpark.com.ua.http > 195.248.160.78.48714: . ack 1 win 65535 (DF) 20:44:09.920818 hosting.itpark.com.ua.http > 195.248.160.78.31848: . ack 3792205062 win 0 20:44:09.921773 hosting.itpark.com.ua.http > 195.248.160.78.31848: . ack 1 win 65535 (DF) -- Lucky carrier, Pavel. From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 10:29:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34F4016A4CF for ; Tue, 24 Aug 2004 10:29:23 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 698E443D2F for ; Tue, 24 Aug 2004 10:29:22 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 31828 invoked from network); 24 Aug 2004 10:28:34 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Aug 2004 10:28:34 -0000 Message-ID: <412B1883.9C3E38C2@freebsd.org> Date: Tue, 24 Aug 2004 12:29:23 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: gul@gul.kiev.ua References: <20040824091638.GE27112@happy.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_2 timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 10:29:23 -0000 Pavel Gulchouck wrote: > > Hi. > > I have hangs tcp-sessions in the FIN_WAIT_2 state, in which packets > sends to remote for several days. Sockstate tells none aboute its, > restart httpd has no effect. > http://httpd.apache.org/docs/misc/fin_wait_2.html says that FreeBSD > has a timeout for FIN_WAIT_2 state, but I don't see it. > Number of such sessions grows according to uptime. > FreeBSD 5.2.1-RELEASE-p9. > Any suggestions? Very strange... Could you send the output of "sysctl -a net.inet.tcp" as well? > root@racoon:~>netstat -na | fgrep 195.248.160.78 > tcp4 0 0 193.109.240.55.80 195.248.160.78.59843 FIN_WAIT_2 > tcp4 0 0 193.109.240.55.80 195.248.160.78.56084 FIN_WAIT_2 > tcp4 0 0 193.109.240.55.80 195.248.160.78.37466 FIN_WAIT_2 > tcp4 0 0 193.109.240.55.80 195.248.160.78.31848 FIN_WAIT_2 > [...] > root@racoon:~>sockstat | fgrep 195.248.160.78 > root@racoon:~>netstat -na | grep -c FIN_WAIT_2 > 419 > > tcpdump shows: > > 20:43:54.922521 hosting.itpark.com.ua.http > 195.248.160.78.48714: . ack > 3765418226 win 0 It (re-)tries to ACK the FIN probably. > 20:43:54.923546 hosting.itpark.com.ua.http > 195.248.160.78.48714: . ack 1 win > 65535 (DF) And it tries to open the window again to get out of persistent mode!? > 20:44:09.920818 hosting.itpark.com.ua.http > 195.248.160.78.31848: . ack > 3792205062 win 0 > 20:44:09.921773 hosting.itpark.com.ua.http > 195.248.160.78.31848: . ack 1 win > 65535 (DF) Any chance of finding out what kind of Operating System 195.248.160.78 is? -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 10:55:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50B4016A4CE; Tue, 24 Aug 2004 10:55:12 +0000 (GMT) Received: from happy.kiev.ua (happy.kiev.ua [193.109.241.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FFEC43D2D; Tue, 24 Aug 2004 10:55:10 +0000 (GMT) (envelope-from gul@happy.kiev.ua) Received: from gul by happy.kiev.ua with local (Exim 4.41) id 1BzYxI-0000Ab-Ig; Tue, 24 Aug 2004 13:55:08 +0300 Date: Tue, 24 Aug 2004 13:55:08 +0300 From: Pavel Gulchouck To: Andre Oppermann Message-ID: <20040824105508.GG27112@happy.kiev.ua> References: <20040824091638.GE27112@happy.kiev.ua> <412B1883.9C3E38C2@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412B1883.9C3E38C2@freebsd.org> X-Operating-System: Linux X-FTN-Address: 2:463/68 X-Flames-To: /dev/null X-GC: GCC d- s+: a33 C+++ UL++++ UB++++ P+ L++ E--- W++ N++ o-- K- w--- O++ X-GC: M? V- PS PE+ Y+ PGP+ t? 5? X? R? !tv b+ DI? D? G e h--- r+++ y+++ User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_2 timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gul@gul.kiev.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 10:55:12 -0000 On Tue, Aug 24, 2004 at 12:29:23PM +0200, Andre Oppermann writes: >> I have hangs tcp-sessions in the FIN_WAIT_2 state, in which packets >> sends to remote for several days. Sockstate tells none aboute its, >> restart httpd has no effect. >> http://httpd.apache.org/docs/misc/fin_wait_2.html says that FreeBSD >> has a timeout for FIN_WAIT_2 state, but I don't see it. >> Number of such sessions grows according to uptime. >> FreeBSD 5.2.1-RELEASE-p9. >> Any suggestions? AO> Very strange... AO> Could you send the output of "sysctl -a net.inet.tcp" as well? net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.count: 319 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.rfc3042: 0 net.inet.tcp.rfc3390: 0 net.inet.tcp.reass.maxsegments: 428 net.inet.tcp.reass.cursegments: 5 net.inet.tcp.reass.overflows: 3608 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.newreno: 1 net.inet.tcp.minmss: 216 net.inet.tcp.minmssoverload: 0 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 474 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.inflight_enable: 0 net.inet.tcp.inflight_debug: 0 net.inet.tcp.inflight_min: 6144 net.inet.tcp.inflight_max: 1073725440 net.inet.tcp.inflight_stab: 20 net.inet.tcp.syncookies: 1 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.msl: 30000 net.inet.tcp.rexmit_min: 30 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.always_keepalive: 1 >> root@racoon:~>netstat -na | fgrep 195.248.160.78 >> tcp4 0 0 193.109.240.55.80 195.248.160.78.59843 FIN_WAIT_2 >> tcp4 0 0 193.109.240.55.80 195.248.160.78.56084 FIN_WAIT_2 >> tcp4 0 0 193.109.240.55.80 195.248.160.78.37466 FIN_WAIT_2 >> tcp4 0 0 193.109.240.55.80 195.248.160.78.31848 FIN_WAIT_2 >> [...] >> root@racoon:~>sockstat | fgrep 195.248.160.78 >> root@racoon:~>netstat -na | grep -c FIN_WAIT_2 >> 419 >> >> tcpdump shows: >> >> 20:43:54.922521 hosting.itpark.com.ua.http > 195.248.160.78.48714: . ack >> 3765418226 win 0 AO> It (re-)tries to ACK the FIN probably. >> 20:43:54.923546 hosting.itpark.com.ua.http > 195.248.160.78.48714: . ack 1 win >> 65535 (DF) AO> And it tries to open the window again to get out of persistent mode!? >> 20:44:09.920818 hosting.itpark.com.ua.http > 195.248.160.78.31848: . ack >> 3792205062 win 0 >> 20:44:09.921773 hosting.itpark.com.ua.http > 195.248.160.78.31848: . ack 1 win >> 65535 (DF) AO> Any chance of finding out what kind of Operating System 195.248.160.78 is? Yes, there're live sysadmin, reported me about this problem. Waiting for reply from he. But I have the same situation with many other IP, not only with 195.248.160.78: root@racoon:~>netstat -na | grep FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.68.169.9.64752 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63821 222.8.120.61.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.186.219.3.25883 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63787 202.155.116.177.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.209.202.10.4647 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.209.202.10.4623 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63633 217.88.213.133.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63608 80.138.84.41.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.219.160.3240 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.219.160.3234 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.219.160.3226 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.219.160.3216 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63456 218.111.163.59.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.137.42.74.2614 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63112 217.224.143.224.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.62918 218.238.90.203.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.219.160.3065 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.151.96.131.30057 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.151.96.131.30042 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.219.160.3054 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.219.160.3053 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.219.160.3042 FIN_WAIT_2 tcp4 0 0 193.109.240.59.62429 82.254.102.24.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.62235 218.71.41.243.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3201 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3202 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3200 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3199 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3197 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3198 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3196 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3192 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3191 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3189 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3182 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3181 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3179 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3178 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3177 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3175 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3176 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3172 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3163 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3164 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3162 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3161 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3160 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3158 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3157 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3156 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3146 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3144 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3142 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3141 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3140 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.235.118.62.3139 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61878 81.84.12.38.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61551 219.82.166.129.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61534 220.255.171.206.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61204 69.47.139.216.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61195 218.95.17.69.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.60775 80.182.31.95.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 62.217.139.197.3500 FIN_WAIT_2 tcp4 0 0 193.109.240.57.59882 81.152.58.124.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.59801 211.92.41.218.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.59753 211.202.130.22.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.59664 4.14.113.22.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.59293 61.255.184.54.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.58947 218.18.41.103.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.58824 219.160.47.161.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.58670 211.107.111.99.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.58623 141.158.213.100.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.58414 218.88.195.155.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.58328 61.39.97.151.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.58177 62.251.16.133.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.56996 220.127.88.152.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.56965 66.214.40.43.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.56751 211.200.183.62.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.56687 82.50.143.61.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.56600 82.50.143.61.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.55784 82.224.242.155.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.55750 200.24.110.84.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.55624 80.232.64.142.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.55607 201.135.165.66.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.55405 83.29.236.110.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.54881 200.89.61.162.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.54724 217.224.60.225.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.53409 201.128.214.55.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.52512 217.159.162.38.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.52451 62.248.231.91.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.52196 210.223.92.93.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 200.31.21.186.38353 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.137.42.74.1322 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.137.42.74.1321 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.137.42.74.1160 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 83.219.132.163.2509 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.234.16.209.1481 FIN_WAIT_2 tcp4 0 0 193.109.240.57.64748 82.226.198.138.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.62611 221.226.81.11.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61460 218.39.101.208.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.195.71.67.4961 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63761 61.199.105.127.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63717 219.164.108.216.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.62666 4.27.197.238.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61277 82.143.155.80.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 220.111.221.234.1472 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 220.111.221.234.1471 FIN_WAIT_2 tcp4 0 0 193.109.240.57.53406 80.183.0.187.113 FIN_WAIT_2 tcp4 0 0 193.109.240.59.50510 65.2.113.233.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.62673 68.236.160.96.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.1.225.119.2703 FIN_WAIT_2 tcp4 0 0 193.109.240.57.56444 81.218.15.199.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.2387 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.2385 FIN_WAIT_2 tcp4 0 0 193.109.240.57.50164 206.45.184.250.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.1653 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.82.222.170.2272 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.82.222.170.1720 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.1299 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.82.222.170.1422 FIN_WAIT_2 tcp4 0 0 193.109.240.7.55666 62.244.31.230.25 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.40.39.214.1878 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63692 222.2.143.29.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.110.162.29077 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.38.18.120.1506 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.38.18.120.1505 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.38.18.120.1503 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.38.18.120.1502 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 64.241.242.18.56392 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.174.99.73.7144 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 203.134.125.150.8960 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.109.57.31.1731 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.109.57.31.1730 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 203.134.125.150.59810 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.174.99.73.62781 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.1090 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.1089 FIN_WAIT_2 tcp4 0 0 193.109.240.57.59702 81.225.66.192.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.117.187.3.7910 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 192.118.124.9.24764 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.220.219.85.60887 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 80.127.89.121.34517 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 62.118.204.14.39112 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 210.3.7.150.42955 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.40.44.198.1289 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.193.112.127.3663 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.117.187.3.6024 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 200.131.187.33.1608 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.46.17.186.1777 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.98.173.2.2090 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.98.173.2.2089 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.119.39.178.3518 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.57.150.10.65125 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.13.253.246.3716 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.208.201.17689 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.208.201.17688 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.208.201.17687 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.208.201.17684 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.140.75.62.1031 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.1698 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.57.150.10.16734 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.243.114.94.41001 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.23.109.46.33721 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.23.109.46.33605 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.59843 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.56084 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.109.34.94.15848 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.37466 FIN_WAIT_2 tcp4 0 0 193.109.240.57.62066 82.38.178.242.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.31848 FIN_WAIT_2 tcp4 0 0 193.109.240.57.60363 218.11.0.62.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.63069 68.93.102.74.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.40432 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.109.56.194.51941 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.179.237.15.1381 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.179.237.15.1380 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.21.32.134.2914 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.142.129.12.8962 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 67.92.168.235.17516 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.135.58.64.4050 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.26.151.54.52460 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.26.151.54.52455 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.26.151.54.51309 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.26.151.54.51307 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.26.151.54.46959 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.26.151.54.46937 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 69.164.188.39.20325 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.120.184.242.27303 FIN_WAIT_2 tcp4 0 0 193.109.240.57.55466 67.127.69.119.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.46.118.108.16690 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.109.240.46.1594 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.9.220.254.43860 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.37.132.1162 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.37.132.1160 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2873 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2806 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2816 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2813 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2808 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2800 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2799 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2775 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2762 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2749 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2732 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2750 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2746 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2743 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2751 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2742 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2738 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.29.99.2740 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.66.206.146.22395 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.5.90.15.42462 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.179.252.2.4199 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.90.152.202.43735 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.9814 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.7347 FIN_WAIT_2 tcp4 0 0 193.109.240.57.59480 68.93.102.74.113 FIN_WAIT_2 tcp4 0 0 193.109.240.57.49170 218.128.242.3.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.210.50.235.21747 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.122.70.74.13587 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.14.48.125.42324 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 53.122.156.3.47401 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.251.21.1.39419 FIN_WAIT_2 tcp4 0 0 193.109.240.55.25 83.70.51.146.54413 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 61.246.193.66.44890 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.190.207.155.17120 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.201.231.126.29052 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.98.162.74.16445 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.69.206.201.45778 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.15381 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.13761 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.213.109.11.3043 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 210.176.112.190.30414 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.17.8989 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.18.17360 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.21.10324 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.20.22742 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.20.14605 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.19.17691 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.15.19115 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.21.6494 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.66.22.93.3187 FIN_WAIT_2 tcp4 0 0 193.109.240.7.62637 213.163.128.200.25 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.15.19396 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.15.9370 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.180.210.17.2824 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.18.15922 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.21.18525 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.17.19481 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.27.8711 FIN_WAIT_2 tcp4 0 0 193.109.240.7.61496 212.9.92.172.25 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.171.38.100.35101 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.196.160.110.1157 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 213.46.243.20.16924 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.128.75.1.3337 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 80.240.7.100.3812 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 80.60.226.202.10303 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.135.35.1.1527 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.111.248.74.1630 FIN_WAIT_2 tcp4 0 0 193.109.240.57.60677 24.237.77.236.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.33.160.51.1454 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.64.141.181.4733 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.142.201.49.10605 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.1164 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.176.14.66.1423 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.42.72.250.43453 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.42.72.250.43131 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.109.160.191.33208 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.98.60.66.50110 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.235.81.93.56456 FIN_WAIT_2 tcp4 0 0 193.109.240.59.25 69.6.60.212.3812 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 212.42.72.250.56181 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 212.42.72.250.55136 FIN_WAIT_2 tcp4 0 0 193.109.240.55.21 193.109.240.46.4926 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.14.24.19.15403 FIN_WAIT_2 tcp4 0 0 193.109.240.55.21 193.109.240.46.3832 FIN_WAIT_2 tcp4 0 0 193.109.240.55.21 193.109.240.46.2931 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.117.187.3.7196 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.117.187.3.6120 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.117.187.3.6086 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 12.0.45.199.1634 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 65.248.232.253.23585 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.42.169.146.9439 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 80.86.225.6.41431 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.151.131.51.15399 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.30.178.146.1776 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.30.178.146.1775 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.208.202.10987 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 212.35.172.169.1612 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.51787 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.234.214.126.46210 FIN_WAIT_2 tcp4 0 0 193.109.240.7.49938 12.129.251.163.25 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.40.6.5.1344 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.208.243.46.4924 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 57.66.46.207.21368 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 57.66.46.207.21128 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 209.251.39.179.57458 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 209.251.39.179.57361 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 61.125.89.182.3382 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 80.92.96.28.2299 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 219.101.215.2.27442 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 209.251.39.179.56148 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.200.8.10.3636 FIN_WAIT_2 tcp4 0 0 193.109.240.7.58774 194.190.240.43.25 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.180.210.17.4056 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 62.5.181.162.45669 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.86.104.135.1343 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.3.189.30.17123 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.3.189.30.17117 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.9.220.254.21009 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 193.192.142.5.42656 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.67.181.157.10293 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.109.56.194.46039 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.248.50.12.50711 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.106.70.47.21095 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.44.240.147.3530 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.44.240.147.3248 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.44.240.147.1622 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 211.23.197.197.6241 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.106.124.214.1283 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.30.251.38.2799 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.20.174.131.1032 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 62.105.142.146.4839 FIN_WAIT_2 tcp4 0 0 193.109.240.7.62851 80.160.77.109.25 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 211.23.197.197.63948 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.133.232.100.27855 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.133.232.100.27418 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.133.232.100.27387 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.211.58.30.4669 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 62.205.176.130.64811 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 217.106.58.235.25067 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.151.126.101.4897 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.151.126.101.4896 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.151.126.101.4895 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.151.126.101.4878 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.151.126.101.4793 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.42.72.250.35061 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.194.153.251.44556 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 195.161.118.181.1496 FIN_WAIT_2 tcp4 0 0 193.109.240.7.59220 148.223.251.123.25 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 164.114.145.54.3280 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 210.113.255.103.4422 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 83.16.179.50.4551 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 192.117.118.118.3251 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61561 141.149.244.161.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.21 195.26.18.1.4151 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.179.252.2.33651 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.5.131.20.44443 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.208.208.18153 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 63.250.134.34.17893 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 82.207.76.132.3730 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.227.201.3.47198 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.227.201.3.47193 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.171.63.51.4103 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.171.63.51.4098 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 24.132.233.155.3541 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 24.132.233.155.3507 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 24.132.233.155.3504 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 24.132.233.155.3485 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.176.23.34.54191 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.176.23.34.54190 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.176.23.34.54180 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.68.240.170.43582 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.135.50.63.1468 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.133.232.100.56270 FIN_WAIT_2 tcp4 0 0 193.109.240.57.58357 81.225.99.130.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 80.81.62.163.4332 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.49485 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.49478 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.49316 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.49313 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.49169 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.48714 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.66.206.146.32456 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.44637 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.44517 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.33.187.131.2830 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.33.187.131.2829 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.109.80.220.3184 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 193.109.80.220.3183 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.41788 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.248.160.78.40341 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.179.252.2.3216 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.176.209.66.21454 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 81.176.209.66.21335 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 129.240.105.35.4450 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.133.232.100.33528 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.133.232.100.33423 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 203.115.24.229.37884 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.98.76.18.64849 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.133.232.100.4146 FIN_WAIT_2 tcp4 0 0 193.109.240.54.21 212.40.47.14.4283 FIN_WAIT_2 tcp4 0 0 193.109.240.54.21 212.40.47.14.4247 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.58.40.67.2631 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.58.40.67.2623 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.45.19.58.39543 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 212.1.70.93.3288 FIN_WAIT_2 tcp4 0 0 193.109.240.57.61055 61.128.98.31.113 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 207.46.238.133.45349 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 80.82.190.118.5996 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.44.240.147.1569 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 210.116.103.73.3755 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 194.44.240.147.3074 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.54.201.98.21527 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 195.54.201.98.21440 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.184.233.18.1291 FIN_WAIT_2 tcp4 0 0 193.109.240.7.59446 216.83.238.226.25 FIN_WAIT_2 tcp4 0 0 193.109.240.57.25 212.42.72.250.35560 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.177.106.106.15373 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.179.252.2.3847 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.243.84.38.18627 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.212.2.1856 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.212.2.1860 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.212.2.1859 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.212.2.1858 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.186.212.2.1857 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.167.48.27.29437 FIN_WAIT_2 tcp4 0 0 193.109.240.55.80 213.167.48.27.29411 FIN_WAIT_2 tcp4 0 0 193.109.240.7.57446 148.223.251.123.25 FIN_WAIT_2 tcp4 0 0 193.109.240.7.57435 148.243.150.77.25 FIN_WAIT_2 -- Lucky carrier, Pavel. From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 12:12:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E933416A4D2; Tue, 24 Aug 2004 12:12:03 +0000 (GMT) Received: from starburst.demon.co.uk (starburst.demon.co.uk [80.176.229.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1DDB43D45; Tue, 24 Aug 2004 12:11:11 +0000 (GMT) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.11.6/8.11.6) id i7OBTg917650; Tue, 24 Aug 2004 12:29:42 +0100 From: Richard Wendland Message-Id: <200408241129.i7OBTg917650@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Date: Tue, 24 Aug 2004 12:29:42 +0100 (BST) In-Reply-To: <412B1883.9C3E38C2@freebsd.org> from "Andre Oppermann" at Aug 24, 2004 12:29:23 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: gul@gul.kiev.ua Subject: Re: FIN_WAIT_2 timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richard@codeburst.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 12:12:04 -0000 > > http://httpd.apache.org/docs/misc/fin_wait_2.html says that FreeBSD > > has a timeout for FIN_WAIT_2 state, but I don't see it. > > Very strange... This is somewhat similar to a problem I explained a few months back: http://www.mail-archive.com/freebsd-net@freebsd.org/msg11857.html where a 10 minute keepalive from a Novell system defeated the FreeBSD 11min 15 sec FIN_WAIT timeout. This situation is a bit different as FreeBSD is the server rather than the client. I wonder if 195.248.160.78 is a Novell system? If it is similar, there's no real bug in the FreeBSD TCP stack, but the far end is acting strangely with an abnormally fast keepalive. It would be worth tcpdumping 195.248.160.78 traffic on those ports for 30 mins or so to see if it is simply doing keepalives more frequently that 12 mins. Richard -- Richard Wendland richard@codeburst.co.uk From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 13:15:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32B1616A4CF for ; Tue, 24 Aug 2004 13:15:34 +0000 (GMT) Received: from happy.kiev.ua (happy.kiev.ua [193.109.241.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDD9F43D1D for ; Tue, 24 Aug 2004 13:15:33 +0000 (GMT) (envelope-from gul@happy.kiev.ua) Received: from gul by happy.kiev.ua with local (Exim 4.41) id 1Bzb9A-0007wW-BY; Tue, 24 Aug 2004 16:15:32 +0300 Date: Tue, 24 Aug 2004 16:15:32 +0300 From: Pavel Gulchouck To: Richard Wendland Message-ID: <20040824131532.GA20828@happy.kiev.ua> References: <412B1883.9C3E38C2@freebsd.org> <200408241129.i7OBTg917650@starburst.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408241129.i7OBTg917650@starburst.demon.co.uk> X-Operating-System: Linux X-FTN-Address: 2:463/68 X-Flames-To: /dev/null X-GC: GCC d- s+: a33 C+++ UL++++ UB++++ P+ L++ E--- W++ N++ o-- K- w--- O++ X-GC: M? V- PS PE+ Y+ PGP+ t? 5? X? R? !tv b+ DI? D? G e h--- r+++ y+++ User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_2 timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gul@gul.kiev.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 13:15:34 -0000 On Tue, Aug 24, 2004 at 12:29:42PM +0100, Richard Wendland writes: > >> http://httpd.apache.org/docs/misc/fin_wait_2.html says that FreeBSD > >> has a timeout for FIN_WAIT_2 state, but I don't see it. >> >> Very strange... RW> This is somewhat similar to a problem I explained a few months back: RW> http://www.mail-archive.com/freebsd-net@freebsd.org/msg11857.html RW> where a 10 minute keepalive from a Novell system defeated the FreeBSD RW> 11min 15 sec FIN_WAIT timeout. This situation is a bit different as RW> FreeBSD is the server rather than the client. I wonder if 195.248.160.78 RW> is a Novell system? RW> If it is similar, there's no real bug in the FreeBSD TCP stack, but the RW> far end is acting strangely with an abnormally fast keepalive. RW> It would be worth tcpdumping 195.248.160.78 traffic on those ports for RW> 30 mins or so to see if it is simply doing keepalives more frequently RW> that 12 mins. tcpdumping for 30 min shows now traffic from 195.248.160.78, only traffic to this host. -- Lucky carrier, Pavel. From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 19:43:42 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E43116A4CE; Tue, 24 Aug 2004 19:43:42 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC0543D31; Tue, 24 Aug 2004 19:43:42 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) i7OJhgh1056644; Tue, 24 Aug 2004 19:43:42 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7OJhgua056640; Tue, 24 Aug 2004 19:43:42 GMT (envelope-from andre) Date: Tue, 24 Aug 2004 19:43:42 GMT From: Andre Oppermann Message-Id: <200408241943.i7OJhgua056640@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: kern/15095: TCP's advertised window is not scaled immediately upon discovering use of Window scale option X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 19:43:42 -0000 Synopsis: TCP's advertised window is not scaled immediately upon discovering use of Window scale option Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 24 19:43:24 GMT 2004 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=15095 From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 21:16:38 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43D7316A4CE; Tue, 24 Aug 2004 21:16:38 +0000 (GMT) Received: from marko-tp.zavod.tel.fer.hr (marko-tp.zavod.tel.fer.hr [161.53.19.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5696643D46; Tue, 24 Aug 2004 21:16:35 +0000 (GMT) (envelope-from zec@icir.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by tpx30 (8.12.11/8.12.11) with ESMTP id i7OLE2Os009920; Tue, 24 Aug 2004 23:14:15 +0200 (CEST) (envelope-from zec@icir.org) From: Marko Zec To: stable@freebsd.org Date: Tue, 24 Aug 2004 23:14:01 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408242314.01915.zec@icir.org> cc: net@freebsd.org Subject: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 21:16:38 -0000 I've prepared a more or less blind backport of the TCP SACK code which was recently introduced in -CURRENT. Didn't put the patch through lots of testing, but it just seems to work... The patch is available from the URL bellow and should apply cleanly against both 4.10-RELEASE and -STABLE. http://tel.fer.hr/zec/BSD/4.10-sack.diff Cheers, Marko From owner-freebsd-net@FreeBSD.ORG Tue Aug 24 22:15:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A78E016A4DE; Tue, 24 Aug 2004 22:15:23 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD0C943D2D; Tue, 24 Aug 2004 22:15:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 62CB57A41E; Tue, 24 Aug 2004 15:15:22 -0700 (PDT) Message-ID: <412BBDFA.5080508@elischer.org> Date: Tue, 24 Aug 2004 15:15:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Marko Zec References: <200408242314.01915.zec@icir.org> In-Reply-To: <200408242314.01915.zec@icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: stable@freebsd.org cc: net@freebsd.org Subject: Re: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 22:15:23 -0000 You do know don't you, that if you continue to do these things, you will be punnished by getting a CVS commit bit..? Marko Zec wrote: >I've prepared a more or less blind backport of the TCP SACK code which was >recently introduced in -CURRENT. Didn't put the patch through lots of >testing, but it just seems to work... The patch is available from the URL >bellow and should apply cleanly against both 4.10-RELEASE and -STABLE. > >http://tel.fer.hr/zec/BSD/4.10-sack.diff > >Cheers, > >Marko >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 04:07:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF64216A4CE; Wed, 25 Aug 2004 04:07:22 +0000 (GMT) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C13D43D31; Wed, 25 Aug 2004 04:07:22 +0000 (GMT) (envelope-from Helge.Oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])i7P479Op011949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2004 06:07:09 +0200 (CEST) (envelope-from Helge.Oldach@atosorigin.com) Received: from dehhx004.hbg.de.int.atosorigin.com (dehhx004.hbg.de.int.atosorigin.com [161.90.164.40]) ESMTP id i7P479iU068244; Wed, 25 Aug 2004 06:07:09 +0200 (CEST) (envelope-from Helge.Oldach@atosorigin.com) Received: by dehhx004.hbg.de.int.atosorigin.com with Internet Mail Service (5.5.2657.72) id ; Wed, 25 Aug 2004 06:07:09 +0200 Message-ID: From: "Oldach, Helge" To: "'Julian Elischer'" , Marko Zec Date: Wed, 25 Aug 2004 06:06:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: stable@freebsd.org cc: net@freebsd.org Subject: RE: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 04:07:22 -0000 So please go ahead, give Marko that bit and let him commit this decent work! Helge > -----Original Message----- > From: owner-freebsd-stable@freebsd.org > [mailto:owner-freebsd-stable@freebsd.org]On Behalf Of Julian Elischer > Sent: Wednesday, August 25, 2004 12:15 AM > To: Marko Zec > Cc: stable@freebsd.org; net@freebsd.org > Subject: Re: TCP SACK backport to -STABLE > > > You do know don't you, that if you continue to do these > things, you will > be punnished by > getting a CVS commit bit..? > > > Marko Zec wrote: > > >I've prepared a more or less blind backport of the TCP SACK > code which was > >recently introduced in -CURRENT. Didn't put the patch > through lots of > >testing, but it just seems to work... The patch is > available from the URL > >bellow and should apply cleanly against both 4.10-RELEASE > and -STABLE. > > > >http://tel.fer.hr/zec/BSD/4.10-sack.diff > > > >Cheers, > > > >Marko > >_______________________________________________ > >freebsd-net@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-net > >To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 04:36:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 312CC16A4CE; Wed, 25 Aug 2004 04:36:34 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24E0943D2D; Wed, 25 Aug 2004 04:36:34 +0000 (GMT) (envelope-from ps@freebsd.org) Received: from [192.168.1.150] (adsl-69-107-116-55.dsl.pltn13.pacbell.net [69.107.116.55]) by elvis.mu.org (Postfix) with ESMTP id DDF285C9E7; Tue, 24 Aug 2004 21:36:33 -0700 (PDT) Message-ID: <412C174F.3000301@freebsd.org> Date: Tue, 24 Aug 2004 21:36:31 -0700 From: Paul Saab User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marko Zec References: <200408242314.01915.zec@icir.org> In-Reply-To: <200408242314.01915.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: stable@freebsd.org cc: net@freebsd.org Subject: Re: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 04:36:34 -0000 Marko Zec wrote: >I've prepared a more or less blind backport of the TCP SACK code which was >recently introduced in -CURRENT. Didn't put the patch through lots of >testing, but it just seems to work... The patch is available from the URL >bellow and should apply cleanly against both 4.10-RELEASE and -STABLE. > >http://tel.fer.hr/zec/BSD/4.10-sack.diff > > > Not to put this great work done, but Yahoo actually have all this done, but are waiting for more testing to be done. We've found more bugs and will be fixing them in -current first. From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 06:58:53 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCBE616A4CE; Wed, 25 Aug 2004 06:58:53 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0274843D58; Wed, 25 Aug 2004 06:58:53 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (hdsl1p0y@localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id i7P6wjug056131; Wed, 25 Aug 2004 10:58:45 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 25 Aug 2004 10:58:45 +0400 (MSD) From: Maxim Konovalov To: "Oldach, Helge" In-Reply-To: Message-ID: <20040825105815.U56082@mp2.macomnet.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: stable@freebsd.org cc: Marko Zec cc: 'Julian Elischer' cc: net@freebsd.org Subject: RE: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 06:58:53 -0000 On Wed, 25 Aug 2004, 06:06+0200, Oldach, Helge wrote: > So please go ahead, give Marko that bit and let him commit this decent work! Please don't touch RELENG_4. > Helge > > > > -----Original Message----- > > From: owner-freebsd-stable@freebsd.org > > [mailto:owner-freebsd-stable@freebsd.org]On Behalf Of Julian Elischer > > Sent: Wednesday, August 25, 2004 12:15 AM > > To: Marko Zec > > Cc: stable@freebsd.org; net@freebsd.org > > Subject: Re: TCP SACK backport to -STABLE > > > > > > You do know don't you, that if you continue to do these > > things, you will > > be punnished by > > getting a CVS commit bit..? > > > > > > Marko Zec wrote: > > > > >I've prepared a more or less blind backport of the TCP SACK > > code which was > > >recently introduced in -CURRENT. Didn't put the patch > > through lots of > > >testing, but it just seems to work... The patch is > > available from the URL > > >bellow and should apply cleanly against both 4.10-RELEASE > > and -STABLE. > > > > > >http://tel.fer.hr/zec/BSD/4.10-sack.diff > > > > > >Cheers, > > > > > >Marko > > >_______________________________________________ > > >freebsd-net@freebsd.org mailing list > > >http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > > > > > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 13:31:18 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 253C916A4FD; Wed, 25 Aug 2004 13:31:18 +0000 (GMT) Received: from happy.kiev.ua (happy.kiev.ua [193.109.241.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F43443D2D; Wed, 25 Aug 2004 13:31:14 +0000 (GMT) (envelope-from gul@happy.kiev.ua) Received: from gul by happy.kiev.ua with local (Exim 4.41) id 1Bzxrl-0008FG-4n; Wed, 25 Aug 2004 16:31:05 +0300 Date: Wed, 25 Aug 2004 16:31:04 +0300 From: Pavel Gulchouck To: Andre Oppermann Message-ID: <20040825133104.GG8468@happy.kiev.ua> References: <20040824091638.GE27112@happy.kiev.ua> <412B1883.9C3E38C2@freebsd.org> <20040824105508.GG27112@happy.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040824105508.GG27112@happy.kiev.ua> X-Operating-System: Linux X-FTN-Address: 2:463/68 X-Flames-To: /dev/null X-GC: GCC d- s+: a33 C+++ UL++++ UB++++ P+ L++ E--- W++ N++ o-- K- w--- O++ X-GC: M? V- PS PE+ Y+ PGP+ t? 5? X? R? !tv b+ DI? D? G e h--- r+++ y+++ User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_2 timeout X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: gul@gul.kiev.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 13:31:18 -0000 On Tue, Aug 24, 2004 at 01:55:08PM +0300, Pavel Gulchouck writes: PG> On Tue, Aug 24, 2004 at 12:29:23PM +0200, Andre Oppermann writes: >>> I have hangs tcp-sessions in the FIN_WAIT_2 state, in which packets >>> sends to remote for several days. Sockstate tells none aboute its, >>> restart httpd has no effect. >>> http://httpd.apache.org/docs/misc/fin_wait_2.html says that FreeBSD >>> has a timeout for FIN_WAIT_2 state, but I don't see it. >>> Number of such sessions grows according to uptime. >>> FreeBSD 5.2.1-RELEASE-p9. [...] AO>> Any chance of finding out what kind of Operating System 195.248.160.78 is? PG> Yes, there're live sysadmin, reported me about this problem. PG> Waiting for reply from he. There is Win 2000 Server SP4 plus ISA Server 2000 SP2. PG> But I have the same situation with many other IP, not only with PG> 195.248.160.78 -- Lucky carrier, Pavel. From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 13:44:25 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B77A216A4CE for ; Wed, 25 Aug 2004 13:44:25 +0000 (GMT) Received: from marko-tp.zavod.tel.fer.hr (marko-tp.zavod.tel.fer.hr [161.53.19.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2F2543D54 for ; Wed, 25 Aug 2004 13:44:24 +0000 (GMT) (envelope-from zec@icir.org) Received: from [127.0.0.1] (localhost [127.0.0.1])i7PDiIqM011578 for ; Wed, 25 Aug 2004 15:44:19 +0200 (CEST) (envelope-from zec@icir.org) From: Marko Zec To: freebsd-net@freebsd.org Date: Wed, 25 Aug 2004 15:44:18 +0200 User-Agent: KMail/1.6.2 References: <200408242314.01915.zec@icir.org> <412BBDFA.5080508@elischer.org> In-Reply-To: <412BBDFA.5080508@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408251544.18759.zec@icir.org> Subject: Re: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 13:44:25 -0000 On Wednesday 25 August 2004 00:15, Julian Elischer wrote: > You do know don't you, that if you continue to do these things, you will > be punnished by > getting a CVS commit bit..? Well, I didn't write the code myself, just ported it from -CURRENT. Anyhow, glad to see that people still care about the 4.x branch. Re that commit bit, what kind of commiter would that be who only likes to work on -STABLE? :) Cheers, Marko From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 15:32:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EB7316A4CE for ; Wed, 25 Aug 2004 15:32:41 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id D0DFC43D48 for ; Wed, 25 Aug 2004 15:32:39 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 11334 invoked from network); 25 Aug 2004 15:31:43 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 25 Aug 2004 15:31:43 -0000 Received: (qmail 19880 invoked by uid 1000); 25 Aug 2004 15:32:47 -0000 Date: Wed, 25 Aug 2004 18:32:47 +0300 From: Peter Pentchev To: net@FreeBSD.org Message-ID: <20040825153247.GI1009@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pE2VAHO2njSJCslu" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: [CFR] Fix sockstat's handling of closed connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 15:32:41 -0000 --pE2VAHO2njSJCslu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I first came across this a couple of months ago, but today I finally took the time to look into it. Basically, if a program has recently closed a TCP connection or three and they are currently in CLOSED or TIME_WAIT state, sockstat(1) will report them as active connected sockets and link them to completely bogus programs and file descriptors. Here's a demonstration, taken immediately after a completed fetchmail poll of three POP3 servers: [roam@straylight ~/fbsd/r/src/usr.bin/sockstat]> sockstat -4c USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS www httpd 5408 3 tcp4 217.75.134.254:58889 217.75.134.1:110 roam ssh 939 3 tcp4 192.168.11.36:55794 192.168.9.48:22 www httpd 604 3 tcp4 217.75.134.254:58889 217.75.134.1:110 nobody dictd 596 26 tcp4 217.75.134.254:58889 217.75.134.1:110 qmails tcpserver 548 0 tcp4 217.75.134.254:58889 217.75.134.1:110 [roam@straylight ~/fbsd/r/src/usr.bin/sockstat]> ./sockstat -4c USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS roam ssh 939 3 tcp4 192.168.11.36:55794 192.168.9.48:22 [roam@straylight ~/fbsd/r/src/usr.bin/sockstat]> netstat -n | egrep '^tcp.*= 110' tcp4 0 0 217.75.134.254.49857 195.24.32.2.110 TIME_WAIT tcp4 0 0 217.75.134.254.54159 217.75.128.9.110 TIME_WAIT tcp4 0 0 217.75.134.254.58889 217.75.134.1.110 TIME_WAIT [roam@straylight ~/fbsd/r/src/usr.bin/sockstat]> The first 'sockstat' run was the "real" sockstat(1) from FreeBSD 5.3-BETA1 as of today; as you can see, it reports the three TIME_WAIT sockets as very much active and attributes them to totally unrelated processes. I must admit this gave me quite a scare the first time I saw this: what in the name of $DEITY are all those servers doing opening *outgoing* connections, or, alternatively and even worse, why are they listening on high ports? Luckily, the fix is simple, or at least so it seems to me. It turns out that those connections have a xt_socket->xso_so set to NULL, and the false positive comes from sockstat's matching them to a similarly NULL xf_data members of 'kern.files'. What do people think about the following patch? I could commit it if nobody has any objections, but being a ports/doc committer, I would need an explicit approval to do that :) G'luck, Peter Index: src/usr.bin/sockstat/sockstat.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/sockstat/sockstat.c,v retrieving revision 1.9 diff -u -r1.9 sockstat.c --- src/usr.bin/sockstat/sockstat.c 19 Jul 2003 06:23:56 -0000 1.9 +++ src/usr.bin/sockstat/sockstat.c 25 Aug 2004 15:14:24 -0000 @@ -494,6 +494,8 @@ "LOCAL ADDRESS", "FOREIGN ADDRESS"); setpassent(1); for (xf =3D xfiles, n =3D 0; n < nxfiles; ++n, ++xf) { + if (xf->xf_data =3D=3D NULL) + continue; hash =3D (int)((uintptr_t)xf->xf_data % HASHSIZE); for (s =3D sockhash[hash]; s !=3D NULL; s =3D s->next) if ((void *)s->socket =3D=3D xf->xf_data) --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 =2Esiht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI --pE2VAHO2njSJCslu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBLLEf7Ri2jRYZRVMRArJ/AJ9jrkruiudcS2hY6tuOTyAJ3j7+qQCfcubV UDh4h8p4RjUeZrWQ3Cf4c0c= =UYw9 -----END PGP SIGNATURE----- --pE2VAHO2njSJCslu-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 15:48:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA22A16A4CE for ; Wed, 25 Aug 2004 15:48:37 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B05F243D39 for ; Wed, 25 Aug 2004 15:48:36 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 41913 invoked from network); 25 Aug 2004 15:47:36 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Aug 2004 15:47:36 -0000 Message-ID: <412CB4D6.5F33FDD@freebsd.org> Date: Wed, 25 Aug 2004 17:48:38 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev References: <20040825153247.GI1009@straylight.m.ringlet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@FreeBSD.org Subject: Re: [CFR] Fix sockstat's handling of closed connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 15:48:37 -0000 Peter Pentchev wrote: > > Hi, > > I first came across this a couple of months ago, but today I finally > took the time to look into it. > > Basically, if a program has recently closed a TCP connection or three > and they are currently in CLOSED or TIME_WAIT state, sockstat(1) will > report them as active connected sockets and link them to completely > bogus programs and file descriptors. Here's a demonstration, taken > immediately after a completed fetchmail poll of three POP3 servers: This has got me freaked out more than once alreay but I never found time to look into it. Good catch! > [roam@straylight ~/fbsd/r/src/usr.bin/sockstat]> sockstat -4c > USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > www httpd 5408 3 tcp4 217.75.134.254:58889 217.75.134.1:110 > roam ssh 939 3 tcp4 192.168.11.36:55794 192.168.9.48:22 > www httpd 604 3 tcp4 217.75.134.254:58889 217.75.134.1:110 > nobody dictd 596 26 tcp4 217.75.134.254:58889 217.75.134.1:110 > qmails tcpserver 548 0 tcp4 217.75.134.254:58889 217.75.134.1:110 > [roam@straylight ~/fbsd/r/src/usr.bin/sockstat]> ./sockstat -4c > USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > roam ssh 939 3 tcp4 192.168.11.36:55794 192.168.9.48:22 > [roam@straylight ~/fbsd/r/src/usr.bin/sockstat]> netstat -n | egrep '^tcp.*110' > tcp4 0 0 217.75.134.254.49857 195.24.32.2.110 TIME_WAIT > tcp4 0 0 217.75.134.254.54159 217.75.128.9.110 TIME_WAIT > tcp4 0 0 217.75.134.254.58889 217.75.134.1.110 TIME_WAIT > [roam@straylight ~/fbsd/r/src/usr.bin/sockstat]> > > The first 'sockstat' run was the "real" sockstat(1) from FreeBSD > 5.3-BETA1 as of today; as you can see, it reports the three TIME_WAIT > sockets as very much active and attributes them to totally unrelated > processes. I must admit this gave me quite a scare the first time I saw > this: what in the name of $DEITY are all those servers doing opening > *outgoing* connections, or, alternatively and even worse, why are they > listening on high ports? > > Luckily, the fix is simple, or at least so it seems to me. It turns out > that those connections have a xt_socket->xso_so set to NULL, and the > false positive comes from sockstat's matching them to a similarly NULL > xf_data members of 'kern.files'. What do people think about the > following patch? I could commit it if nobody has any objections, but > being a ports/doc committer, I would need an explicit approval to do > that :) The fix looks good to me. It seems small enough so I think I can give you the direct go-ahead to commit it. Could you also put a comment into the sockstat man page describing that TCP connections in TIME_WAIT state can be looked up with netstat? -- Andre > G'luck, > Peter > > Index: src/usr.bin/sockstat/sockstat.c > =================================================================== > RCS file: /home/ncvs/src/usr.bin/sockstat/sockstat.c,v > retrieving revision 1.9 > diff -u -r1.9 sockstat.c > --- src/usr.bin/sockstat/sockstat.c 19 Jul 2003 06:23:56 -0000 1.9 > +++ src/usr.bin/sockstat/sockstat.c 25 Aug 2004 15:14:24 -0000 > @@ -494,6 +494,8 @@ > "LOCAL ADDRESS", "FOREIGN ADDRESS"); > setpassent(1); > for (xf = xfiles, n = 0; n < nxfiles; ++n, ++xf) { > + if (xf->xf_data == NULL) > + continue; > hash = (int)((uintptr_t)xf->xf_data % HASHSIZE); > for (s = sockhash[hash]; s != NULL; s = s->next) > if ((void *)s->socket == xf->xf_data) > > -- > Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 > .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI > > -------------------------------------------------------------------------------- > Part 1.2Type: application/pgp-signature From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 15:57:14 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A37316A4CE for ; Wed, 25 Aug 2004 15:57:14 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 7A9C643D48 for ; Wed, 25 Aug 2004 15:57:13 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 24289 invoked from network); 25 Aug 2004 15:56:19 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 25 Aug 2004 15:56:19 -0000 Received: (qmail 20927 invoked by uid 1000); 25 Aug 2004 15:57:24 -0000 Date: Wed, 25 Aug 2004 18:57:24 +0300 From: Peter Pentchev To: Andre Oppermann Message-ID: <20040825155723.GK1009@straylight.m.ringlet.net> References: <20040825153247.GI1009@straylight.m.ringlet.net> <412CB4D6.5F33FDD@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VaKJWhUROU/xPxjb" Content-Disposition: inline In-Reply-To: <412CB4D6.5F33FDD@freebsd.org> User-Agent: Mutt/1.5.6i cc: net@FreeBSD.org Subject: Re: [CFR] Fix sockstat's handling of closed connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 15:57:14 -0000 --VaKJWhUROU/xPxjb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 25, 2004 at 05:48:38PM +0200, Andre Oppermann wrote: > Peter Pentchev wrote: [snip] > > Luckily, the fix is simple, or at least so it seems to me. It turns out > > that those connections have a xt_socket->xso_so set to NULL, and the > > false positive comes from sockstat's matching them to a similarly NULL > > xf_data members of 'kern.files'. What do people think about the > > following patch? I could commit it if nobody has any objections, but > > being a ports/doc committer, I would need an explicit approval to do > > that :) >=20 > The fix looks good to me. It seems small enough so I think I can give > you the direct go-ahead to commit it. Could you also put a comment into > the sockstat man page describing that TCP connections in TIME_WAIT state > can be looked up with netstat? Thanks! I could easily fix the manpage, too, but is TIME_WAIT the only state when xt_socket->xso_so is null? Someone with better knowledge of the TCP/IP stack than me needs to either confirm that, or point out which of the CLOSED, CLOSE_WAIT, FIN_WAIT_1, CLOSING, and FIN_WAIT_2 states also have a null xso_so - or is it just TIME_WAIT, because all the others still mean that the socket is still somewhat active? G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence no verb. --VaKJWhUROU/xPxjb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBLLbj7Ri2jRYZRVMRAv32AJwJ3nglFOc0RE6e/URrgECbO36dcgCgmmAu NNG8slNd3vjOecwY8LjvvDU= =yPfh -----END PGP SIGNATURE----- --VaKJWhUROU/xPxjb-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 16:21:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA6B916A4CE for ; Wed, 25 Aug 2004 16:21:26 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3695843D2D for ; Wed, 25 Aug 2004 16:21:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 42188 invoked from network); 25 Aug 2004 16:20:25 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 25 Aug 2004 16:20:25 -0000 Message-ID: <412CBC87.BFFA18E0@freebsd.org> Date: Wed, 25 Aug 2004 18:21:27 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev References: <20040825153247.GI1009@straylight.m.ringlet.net> <20040825155723.GK1009@straylight.m.ringlet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@FreeBSD.org Subject: Re: [CFR] Fix sockstat's handling of closed connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 16:21:27 -0000 Peter Pentchev wrote: > > On Wed, Aug 25, 2004 at 05:48:38PM +0200, Andre Oppermann wrote: > > Peter Pentchev wrote: > [snip] > > > Luckily, the fix is simple, or at least so it seems to me. It turns out > > > that those connections have a xt_socket->xso_so set to NULL, and the > > > false positive comes from sockstat's matching them to a similarly NULL > > > xf_data members of 'kern.files'. What do people think about the > > > following patch? I could commit it if nobody has any objections, but > > > being a ports/doc committer, I would need an explicit approval to do > > > that :) > > > > The fix looks good to me. It seems small enough so I think I can give > > you the direct go-ahead to commit it. Could you also put a comment into > > the sockstat man page describing that TCP connections in TIME_WAIT state > > can be looked up with netstat? > > Thanks! I could easily fix the manpage, too, but is TIME_WAIT the only > state when xt_socket->xso_so is null? Someone with better knowledge of > the TCP/IP stack than me needs to either confirm that, or point out > which of the CLOSED, CLOSE_WAIT, FIN_WAIT_1, CLOSING, and FIN_WAIT_2 > states also have a null xso_so - or is it just TIME_WAIT, because all > the others still mean that the socket is still somewhat active? Good question. Maybe it's easier to phrase it the other way around. "TCP sockets not in LISTEN, SYN_SENT or ESTABLISHED state can be looked up with netstat." These are the ones that certainly have a file descriptor associated with them and thus show up in sockstat. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 17:26:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C643916A4CE for ; Wed, 25 Aug 2004 17:26:43 +0000 (GMT) Received: from gawab.com (v2.gawab.com [204.97.230.42]) by mx1.FreeBSD.org (Postfix) with SMTP id 6AB6043D1D for ; Wed, 25 Aug 2004 17:26:43 +0000 (GMT) (envelope-from tdamas@gawab.com) Received: (qmail 28597 invoked by uid 1004); 25 Aug 2004 17:26:42 -0000 Message-ID: <20040825172642.28596.qmail@gawab.com> Received: from 143.54.11.131 by www.gawab.com with HTTP; Wed, 25 Aug 2004 17:26:42 GMT From: "Thiago Pinto Damas" To: freebsd-net@freebsd.org Date: Wed, 25 Aug 2004 17:26:42 GMT Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [143.54.11.131] Subject: IPCOMP on IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 17:26:43 -0000 Hi, I configured a tunnel between two FreeBSD machines with IPSEC, for just using the IPCOMP (without ESP and AH), but the performance wasn't good. Has someone configured a tunnel for only compressing data? Sorry for the bad english! Thiago From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 19:55:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D10116A4CE for ; Wed, 25 Aug 2004 19:55:56 +0000 (GMT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id B58E343D67 for ; Wed, 25 Aug 2004 19:55:55 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: (qmail 12779 invoked from network); 25 Aug 2004 20:38:36 -0000 Received: from dbitech.wavefire.com (HELO ?64.141.15.253?) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 25 Aug 2004 20:38:36 -0000 From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: freebsd-net@freebsd.org Date: Wed, 25 Aug 2004 12:55:53 -0700 User-Agent: KMail/1.6.2 References: <200408242314.01915.zec@icir.org> <412BBDFA.5080508@elischer.org> <200408251544.18759.zec@icir.org> In-Reply-To: <200408251544.18759.zec@icir.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408251255.53472.darcy@wavefire.com> Subject: Re: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 19:55:56 -0000 On August 25, 2004 06:44 am, Marko Zec wrote: > On Wednesday 25 August 2004 00:15, Julian Elischer wrote: > > You do know don't you, that if you continue to do these things, you will > > be punnished by > > getting a CVS commit bit..? > > Well, I didn't write the code myself, just ported it from -CURRENT. Anyhow, > glad to see that people still care about the 4.x branch. > > Re that commit bit, what kind of commiter would that be who only likes to > work on -STABLE? :) The kind that would be liked by those who like some of the features of -CURRENT, but policy won't allow them to put them into production... -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 20:45:36 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1110E16A4CE for ; Wed, 25 Aug 2004 20:45:36 +0000 (GMT) Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECF0043D6E for ; Wed, 25 Aug 2004 20:45:35 +0000 (GMT) (envelope-from dart@nersc.gov) Received: by mx2.nersc.gov (Postfix, from userid 4002) id B6E0C7781; Wed, 25 Aug 2004 13:45:35 -0700 (PDT) Received: from mx2.nersc.gov (localhost [127.0.0.1]) by localhost.nersc.gov (Postfix) with ESMTP id D06167785; Wed, 25 Aug 2004 13:45:31 -0700 (PDT) Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111]) by mx2.nersc.gov (Postfix) with ESMTP id 876B67781; Wed, 25 Aug 2004 13:45:31 -0700 (PDT) Received: from gemini.nersc.gov (localhost [127.0.0.1]) by gemini.nersc.gov (Postfix) with ESMTP id 75239F987; Wed, 25 Aug 2004 13:45:31 -0700 (PDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Darcy Buskermolen In-Reply-To: Message from Darcy Buskermolen <200408251255.53472.darcy@wavefire.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_499819802P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 25 Aug 2004 13:45:31 -0700 From: Eli Dart Message-Id: <20040825204531.75239F987@gemini.nersc.gov> X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mx2.nersc.gov cc: freebsd-net@freebsd.org Subject: Re: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 20:45:36 -0000 --==_Exmh_499819802P Content-Type: text/plain; charset=us-ascii In reply to Darcy Buskermolen : > On August 25, 2004 06:44 am, Marko Zec wrote: > > On Wednesday 25 August 2004 00:15, Julian Elischer wrote: > > > You do know don't you, that if you continue to do these things, you will > > > be punnished by > > > getting a CVS commit bit..? > > > > Well, I didn't write the code myself, just ported it from -CURRENT. Anyhow, > > glad to see that people still care about the 4.x branch. > > > > Re that commit bit, what kind of commiter would that be who only likes to > > work on -STABLE? :) > > The kind that would be liked by those who like some of the features of > -CURRENT, but policy won't allow them to put them into production... Careful there.....one major reason I use FreeBSD is that, compared with the other operating systems I can use, major breakages are rare. I expect the policy that prevents you from deploying the most featureful OS available is there to avoid the late-night pain required to run the latest and greatest features in production. It would be a shame if stability were lost in a rush for new features. If smarter people than I feel that SACK should be backported, great. However, I for one greatly appreciate the commitments to stability and POLA that are so much a part of FreeBSD. --eli > > > -- > Darcy Buskermolen > Wavefire Technologies Corp. > ph: 250.717.0200 > fx: 250.763.1759 > http://www.wavefire.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --==_Exmh_499819802P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQFBLPprLTFEeF+CsrMRAlbNAJ4xYndu6Rj4md7nZmn1mvFnDUauTACgkKiX 8vdAgnevBrkK0AxND8z1IkA= =csvP -----END PGP SIGNATURE----- --==_Exmh_499819802P-- From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 22:00:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60EE716A4CE for ; Wed, 25 Aug 2004 22:00:49 +0000 (GMT) Received: from smtp002.bizmail.yahoo.com (smtp002.bizmail.yahoo.com [216.136.172.126]) by mx1.FreeBSD.org (Postfix) with SMTP id E469143D3F for ; Wed, 25 Aug 2004 22:00:46 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@70.240.199.245 with login) by smtp002.bizmail.yahoo.com with SMTP; 25 Aug 2004 22:00:46 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 9AAC561B7; Wed, 25 Aug 2004 17:00:45 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 72278-07; Wed, 25 Aug 2004 17:00:44 -0500 (CDT) Received: from www.noacks.org (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 5CCBE6193; Wed, 25 Aug 2004 17:00:44 -0500 (CDT) Received: from 69.53.57.66 (SquirrelMail authenticated user noackjr); by www.noacks.org with HTTP; Wed, 25 Aug 2004 17:00:44 -0500 (CDT) Message-ID: <17337.69.53.57.66.1093471244.squirrel@69.53.57.66> In-Reply-To: <20040825204531.75239F987@gemini.nersc.gov> References: Message from Darcy Buskermolen <200408251255.53472.darcy@wavefire.com> <20040825204531.75239F987@gemini.nersc.gov> Date: Wed, 25 Aug 2004 17:00:44 -0500 (CDT) From: "Jon Noack" To: "Eli Dart" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at noacks.org cc: freebsd-net@freebsd.org cc: Darcy Buskermolen Subject: Re: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 22:00:49 -0000 Eli Dart wrote: > Careful there.....one major reason I use FreeBSD is that, compared > with the other operating systems I can use, major breakages are rare. > > I expect the policy that prevents you from deploying the most > featureful OS available is there to avoid the late-night pain > required to run the latest and greatest features in production. > > It would be a shame if stability were lost in a rush for new > features. If smarter people than I feel that SACK should be > backported, great. However, I for one greatly appreciate the > commitments to stability and POLA that are so much a part of FreeBSD. >From the Release Engineering document: FreeBSD-CURRENT is the "bleeding-edge" of FreeBSD development where all new changes first enter the system. FreeBSD-STABLE is the development branch from which major releases are made. Changes go into this branch at a different pace, and with general assumption that they have first gone into FreeBSD-CURRENT and have been thoroughly tested by our user community. These types of backports happen all the time, and having another person to share the load is not a bad thing. Active maintenance of RELENG_4 is good for everyone, and those interested most likely have stability as their first priority anyway (because otherwise they wouldn't be using RELENG_4). Regardless, the original work was done on RELENG_4 and ported to -CURRENT: http://lists.freebsd.org/pipermail/cvs-src/2004-June/025956.html Jon From owner-freebsd-net@FreeBSD.ORG Wed Aug 25 22:10:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9049516A4CE for ; Wed, 25 Aug 2004 22:10:26 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EB4B43D1F for ; Wed, 25 Aug 2004 22:10:26 +0000 (GMT) (envelope-from ps@freebsd.org) Received: from [192.168.1.150] (adsl-69-107-104-20.dsl.pltn13.pacbell.net [69.107.104.20]) by elvis.mu.org (Postfix) with ESMTP id 51DEE5C8E7; Wed, 25 Aug 2004 15:10:26 -0700 (PDT) Message-ID: <412D0E4E.5040000@freebsd.org> Date: Wed, 25 Aug 2004 15:10:22 -0700 From: Paul Saab User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: noackjr@alumni.rice.edu References: Message from Darcy Buskermolen <200408251255.53472.darcy@wavefire.com> <20040825204531.75239F987@gemini.nersc.gov> <17337.69.53.57.66.1093471244.squirrel@69.53.57.66> In-Reply-To: <17337.69.53.57.66.1093471244.squirrel@69.53.57.66> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Darcy Buskermolen Subject: Re: TCP SACK backport to -STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2004 22:10:26 -0000 Jon Noack wrote: >Eli Dart wrote: > > >>Careful there.....one major reason I use FreeBSD is that, compared >>with the other operating systems I can use, major breakages are rare. >> >>I expect the policy that prevents you from deploying the most >>featureful OS available is there to avoid the late-night pain >>required to run the latest and greatest features in production. >> >>It would be a shame if stability were lost in a rush for new >>features. If smarter people than I feel that SACK should be >>backported, great. However, I for one greatly appreciate the >>commitments to stability and POLA that are so much a part of FreeBSD. >> >> > >>From the Release Engineering document: >FreeBSD-CURRENT is the "bleeding-edge" of FreeBSD development where all >new changes first enter the system. FreeBSD-STABLE is the development >branch from which major releases are made. Changes go into this branch at >a different pace, and with general assumption that they have first gone >into FreeBSD-CURRENT and have been thoroughly tested by our user >community. > >These types of backports happen all the time, and having another person to >share the load is not a bad thing. Active maintenance of RELENG_4 is good >for everyone, and those interested most likely have stability as their >first priority anyway (because otherwise they wouldn't be using RELENG_4). > >Regardless, the original work was done on RELENG_4 and ported to -CURRENT: >http://lists.freebsd.org/pipermail/cvs-src/2004-June/025956.html > > And bugs have been found since that time. We need more time and testing before anything should be backported to -stable. From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 03:31:15 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF32A16A4CE for ; Thu, 26 Aug 2004 03:31:15 +0000 (GMT) Received: from mx3.mra.co.id (mx3.mra.co.id [202.138.254.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 253AC43D49 for ; Thu, 26 Aug 2004 03:31:08 +0000 (GMT) (envelope-from reza@it.mra.co.id) Received: from localhost (localhost.mra.co.id [127.0.0.1]) by mx3.mra.co.id (Postfix) with ESMTP id DBF542E097 for ; Thu, 26 Aug 2004 09:50:33 +0700 (WIT) Received: from mx3.mra.co.id ([127.0.0.1]) by localhost (mx3.mra.co.id [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24151-13 for ; Thu, 26 Aug 2004 09:50:33 +0700 (WIT) Received: from mail.mra.co.id (unknown [172.16.0.25]) by mx3.mra.co.id (Postfix) with ESMTP id 3B6012E092 for ; Thu, 26 Aug 2004 09:50:33 +0700 (WIT) Received: from it.mra.co.id ([172.16.0.228]) by mail.mra.co.id with Microsoft SMTPSVC(5.0.2195.3779); Thu, 26 Aug 2004 09:24:47 +0700 Message-ID: <412C8637.1070702@it.mra.co.id> Date: Wed, 25 Aug 2004 19:29:43 +0700 From: Muhammad Reza User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Aug 2004 02:24:47.0433 (UTC) FILETIME=[DB5F9390:01C48B13] X-Virus-Scanned: by amavisd-new at mra.co.id Subject: pf load balancing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 03:31:16 -0000 Dear List I have one simple question regarding pf. Does pf load balancing outgoing internet conenction from LAN rules can work together with pf redirection rules are used to forward incoming connections from the Internet to a local server with a private address ? Please enlight me regards Reza From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 14:03:23 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EA5A16A54A for ; Thu, 26 Aug 2004 14:03:23 +0000 (GMT) Received: from sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7F8B43D79 for ; Thu, 26 Aug 2004 14:03:22 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: by sun-fish.com (Postfix, from userid 1008) id 5BF5114A51; Thu, 26 Aug 2004 16:03:20 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id C4BDC14A04 for ; Thu, 26 Aug 2004 16:03:19 +0200 (CEST) Date: Thu, 26 Aug 2004 17:03:20 +0300 From: Vladimir Terziev To: freebsd-net@freebsd.org Message-Id: <20040826170320.51299992@daemon.cmotd.com> Organization: SunFish Ltd. X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-unknown-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Buildng internetworking routers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 14:03:23 -0000 Hi all, i need to build internetworking routers on FreeBSD, OpenBSD and Linux platforms servers. Becasue of this i need a multiplatform software implementation of routing protocols. I tryed routed(8), but there are differences between the *BSD and the Linux versions which break my aims. I also know about zebra, but it's current version is 0.94 and this lead me to think it's not good enough. Could someone point me to a good multiplatform implementation of routing protocols ? Thanks in advance! Vladmir From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 14:38:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48AA916A4CE for ; Thu, 26 Aug 2004 14:38:51 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D9C343D60 for ; Thu, 26 Aug 2004 14:38:51 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 395F465292; Thu, 26 Aug 2004 15:18:28 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 40040-04-5; Thu, 26 Aug 2004 15:18:27 +0100 (BST) Received: from empiric.dek.spc.org (dhcp113.icir.org [192.150.187.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 6D17665219; Thu, 26 Aug 2004 15:18:27 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 3B75662FD; Thu, 26 Aug 2004 07:18:25 -0700 (PDT) Date: Thu, 26 Aug 2004 07:18:25 -0700 From: Bruce M Simpson To: Vladimir Terziev Message-ID: <20040826141825.GE91073@dhcp113.icir.org> Mail-Followup-To: Vladimir Terziev , freebsd-net@freebsd.org References: <20040826170320.51299992@daemon.cmotd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040826170320.51299992@daemon.cmotd.com> cc: freebsd-net@freebsd.org Subject: Re: Buildng internetworking routers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 14:38:51 -0000 On Thu, Aug 26, 2004 at 05:03:20PM +0300, Vladimir Terziev wrote: > Could someone point me to a good multiplatform implementation of routing protocols ? http://www.xorp.org/ (This is a biased opinion as I'm a core team member, but you may want to try Quagga which is a more actively maintained fork of Zebra....) From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 19:37:26 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18C3116A4FC for ; Thu, 26 Aug 2004 19:37:26 +0000 (GMT) Received: from techno.sub.ru (webmail.sub.ru [213.247.139.22]) by mx1.FreeBSD.org (Postfix) with SMTP id 6DEB543D2D for ; Thu, 26 Aug 2004 19:37:25 +0000 (GMT) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 50025 invoked by uid 0); 26 Aug 2004 19:35:20 -0000 Received: from webmail.sub.ru (HELO tarkhil.over.ru) (213.247.139.22) by techno.sub.ru with SMTP; 26 Aug 2004 19:35:20 -0000 Date: Thu, 26 Aug 2004 23:38:44 +0400 From: Alex Povolotsky To: net@freebsd.org Message-Id: <20040826233844.27c55b32@tarkhil.over.ru> Organization: sub.ru X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: altq in current: where? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 19:37:26 -0000 Hello! I'm trying to find out how to set up altq in 5.2.1-release and simply cannot understand where to start from. There is an rc.d script, and node for altq; but nothing more, no docs, no daemons. On altq page, the latest release is about stoneage time. Is it dead? Or I'm just cannot find the starting point for searching? -- Alex. From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 19:43:01 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4A9C16A4CE for ; Thu, 26 Aug 2004 19:43:01 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A567C43D31 for ; Thu, 26 Aug 2004 19:43:01 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7QJis0W007336; Thu, 26 Aug 2004 12:44:54 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7QJis9r007335; Thu, 26 Aug 2004 12:44:54 -0700 Date: Thu, 26 Aug 2004 12:44:54 -0700 From: Brooks Davis To: Alex Povolotsky Message-ID: <20040826194454.GC14825@odin.ac.hmc.edu> References: <20040826233844.27c55b32@tarkhil.over.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xo44VMWPx7vlQ2+2" Content-Disposition: inline In-Reply-To: <20040826233844.27c55b32@tarkhil.over.ru> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: net@freebsd.org Subject: Re: altq in current: where? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 19:43:01 -0000 --xo44VMWPx7vlQ2+2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 26, 2004 at 11:38:44PM +0400, Alex Povolotsky wrote: > Hello! >=20 > I'm trying to find out how to set up altq in 5.2.1-release and simply > cannot understand where to start from. > > There is an rc.d script, and node for altq; but nothing more, no docs, > no daemons. On altq page, the latest release is about stoneage time. ALTQ was merged after 5.2.1. You need to upgrade to a recent current or 5.3-BETA. -- Brooks -- 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 --xo44VMWPx7vlQ2+2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBLj21XY6L6fI4GtQRAs+JAJ9P3nqpmhb8f48QMIf1INy1P4dhGACfWS8I s04PEZvt0v51l1OceW4zsmU= =+NcG -----END PGP SIGNATURE----- --xo44VMWPx7vlQ2+2-- From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 20:23:58 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 303DB16A4CE; Thu, 26 Aug 2004 20:23:58 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1461E43D3F; Thu, 26 Aug 2004 20:23:58 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) i7QKNvh4077625; Thu, 26 Aug 2004 20:23:57 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7QKNvN6077621; Thu, 26 Aug 2004 20:23:57 GMT (envelope-from arved) Date: Thu, 26 Aug 2004 20:23:57 GMT From: Tilman Linneweh Message-Id: <200408262023.i7QKNvN6077621@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/38752: rn_walktree_from not halting at the right node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 20:23:58 -0000 Synopsis: rn_walktree_from not halting at the right node Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arved Responsible-Changed-When: Thu Aug 26 20:23:36 GMT 2004 Responsible-Changed-Why: Over to freebsd-net for review. http://www.freebsd.org/cgi/query-pr.cgi?pr=38752 From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 21:31:25 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A0F716A4CE; Thu, 26 Aug 2004 21:31:25 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E56C43D1D; Thu, 26 Aug 2004 21:31:25 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) i7QLVPCO088056; Thu, 26 Aug 2004 21:31:25 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7QLVP9i088052; Thu, 26 Aug 2004 21:31:25 GMT (envelope-from arved) Date: Thu, 26 Aug 2004 21:31:25 GMT From: Tilman Linneweh Message-Id: <200408262131.i7QLVP9i088052@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/70988: Bug in netisr_queue() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 21:31:25 -0000 Synopsis: Bug in netisr_queue() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arved Responsible-Changed-When: Thu Aug 26 21:30:57 GMT 2004 Responsible-Changed-Why: Over to freebsd-net for review http://www.freebsd.org/cgi/query-pr.cgi?pr=70988 From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 21:37:52 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E331716A4D0; Thu, 26 Aug 2004 21:37:52 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6BCF43D6A; Thu, 26 Aug 2004 21:37:52 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) i7QLbqAR089141; Thu, 26 Aug 2004 21:37:52 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7QLbq02089137; Thu, 26 Aug 2004 21:37:52 GMT (envelope-from andre) Date: Thu, 26 Aug 2004 21:37:52 GMT From: Andre Oppermann Message-Id: <200408262137.i7QLbq02089137@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: kern/70988: Bug in netisr_queue() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 21:37:53 -0000 Synopsis: Bug in netisr_queue() Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Thu Aug 26 21:36:44 GMT 2004 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=70988 From owner-freebsd-net@FreeBSD.ORG Thu Aug 26 21:40:46 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DF7C16A4CE; Thu, 26 Aug 2004 21:40:46 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6127643D46; Thu, 26 Aug 2004 21:40:46 +0000 (GMT) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (andre@localhost [127.0.0.1]) i7QLekR3089422; Thu, 26 Aug 2004 21:40:46 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7QLekEQ089418; Thu, 26 Aug 2004 21:40:46 GMT (envelope-from andre) Date: Thu, 26 Aug 2004 21:40:46 GMT From: Andre Oppermann Message-Id: <200408262140.i7QLekEQ089418@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: kern/38752: rn_walktree_from not halting at the right node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 21:40:46 -0000 Synopsis: rn_walktree_from not halting at the right node Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Thu Aug 26 21:40:24 GMT 2004 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=38752 From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 01:26:11 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B206716A4CE for ; Fri, 27 Aug 2004 01:26:11 +0000 (GMT) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F97A43D1F for ; Fri, 27 Aug 2004 01:26:10 +0000 (GMT) (envelope-from on@banyan.cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (mailnull@banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id i7R1Q7k6078386; Fri, 27 Aug 2004 08:26:07 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.12.11/8.12.11) id i7R1Q4LH005123; Fri, 27 Aug 2004 08:26:04 +0700 (ICT) Date: Fri, 27 Aug 2004 08:26:04 +0700 (ICT) Message-Id: <200408270126.i7R1Q4LH005123@banyan.cs.ait.ac.th> From: Olivier Nicole To: vladimir.terziev@sun-fish.com In-reply-to: <20040826170320.51299992@daemon.cmotd.com> (message from Vladimir Terziev on Thu, 26 Aug 2004 17:03:20 +0300) References: <20040826170320.51299992@daemon.cmotd.com> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) cc: freebsd-net@freebsd.org Subject: Re: Buildng internetworking routers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 01:26:11 -0000 Vladimir, We have been running a piece of international network with Zebra for many years (www.ai3.net). Olivier From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 11:06:36 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C09C616A4CE; Fri, 27 Aug 2004 11:06:36 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A383C43D2D; Fri, 27 Aug 2004 11:06:36 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) i7RB6aEu047087; Fri, 27 Aug 2004 11:06:36 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7RB6aYT047083; Fri, 27 Aug 2004 11:06:36 GMT (envelope-from arved) Date: Fri, 27 Aug 2004 11:06:36 GMT From: Tilman Linneweh Message-Id: <200408271106.i7RB6aYT047083@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/41007: overfull traffic on third and fourth adaptors at a promiscuous mode on FreeBSD 4.6-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 11:06:36 -0000 Synopsis: overfull traffic on third and fourth adaptors at a promiscuous mode on FreeBSD 4.6-STABLE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arved Responsible-Changed-When: Fri Aug 27 11:06:06 GMT 2004 Responsible-Changed-Why: over to freebsd-net for review http://www.freebsd.org/cgi/query-pr.cgi?pr=41007 From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 12:39:40 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DBCF16A4CE; Fri, 27 Aug 2004 12:39:40 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC0B543D1F; Fri, 27 Aug 2004 12:39:39 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) i7RCddGT057561; Fri, 27 Aug 2004 12:39:39 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7RCddX9057557; Fri, 27 Aug 2004 12:39:39 GMT (envelope-from arved) Date: Fri, 27 Aug 2004 12:39:39 GMT From: Tilman Linneweh Message-Id: <200408271239.i7RCddX9057557@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/44355: After deletion of an IPv6 alias, the route to the whole subnet is removed too. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 12:39:40 -0000 Synopsis: After deletion of an IPv6 alias, the route to the whole subnet is removed too. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arved Responsible-Changed-When: Fri Aug 27 12:38:53 GMT 2004 Responsible-Changed-Why: Old patches against IPv6, over to freebsd-net to decide if this PR is still relevant http://www.freebsd.org/cgi/query-pr.cgi?pr=44355 From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 15:57:52 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 801D616A4CE; Fri, 27 Aug 2004 15:57:52 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EC7C43D77; Fri, 27 Aug 2004 15:57:52 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) i7RFvqFg080865; Fri, 27 Aug 2004 15:57:52 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7RFvqkT080861; Fri, 27 Aug 2004 15:57:52 GMT (envelope-from arved) Date: Fri, 27 Aug 2004 15:57:52 GMT From: Tilman Linneweh Message-Id: <200408271557.i7RFvqkT080861@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/52260: sys/net/if.c:if_detach in FreeBSD4 forgets resetting the ifindex2ifnet array X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 15:57:52 -0000 Synopsis: sys/net/if.c:if_detach in FreeBSD4 forgets resetting the ifindex2ifnet array Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arved Responsible-Changed-When: Fri Aug 27 15:57:32 GMT 2004 Responsible-Changed-Why: Over to freebsd-net for review http://www.freebsd.org/cgi/query-pr.cgi?pr=52260 From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 17:11:44 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3466E16A4CE; Fri, 27 Aug 2004 17:11:44 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 154B243D41; Fri, 27 Aug 2004 17:11:44 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) i7RHBh6Z099164; Fri, 27 Aug 2004 17:11:43 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7RHBhnt099159; Fri, 27 Aug 2004 17:11:43 GMT (envelope-from arved) Date: Fri, 27 Aug 2004 17:11:43 GMT From: Tilman Linneweh Message-Id: <200408271711.i7RHBhnt099159@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/57985: [patch] Missing splx in ether_output_frame (-stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 17:11:44 -0000 Synopsis: [patch] Missing splx in ether_output_frame (-stable) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arved Responsible-Changed-When: Fri Aug 27 17:11:23 GMT 2004 Responsible-Changed-Why: Over to freebsd-net for review. http://www.freebsd.org/cgi/query-pr.cgi?pr=57985 From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 19:44:32 2004 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB5416A4CE; Fri, 27 Aug 2004 19:44:32 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F2F43D39; Fri, 27 Aug 2004 19:44:32 +0000 (GMT) (envelope-from brooks@FreeBSD.org) Received: from freefall.freebsd.org (brooks@localhost [127.0.0.1]) i7RJiWJp027195; Fri, 27 Aug 2004 19:44:32 GMT (envelope-from brooks@freefall.freebsd.org) Received: (from brooks@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i7RJiVbw027190; Fri, 27 Aug 2004 19:44:32 GMT (envelope-from brooks) Date: Fri, 27 Aug 2004 19:44:32 GMT From: Brooks Davis Message-Id: <200408271944.i7RJiVbw027190@freefall.freebsd.org> To: jinmei@isl.rdc.toshiba.co.jp, brooks@FreeBSD.org, freebsd-net@FreeBSD.org, brooks@FreeBSD.org Subject: Re: kern/52260: sys/net/if.c:if_detach in FreeBSD4 forgets resetting the ifindex2ifnet array X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 19:44:32 -0000 Synopsis: sys/net/if.c:if_detach in FreeBSD4 forgets resetting the ifindex2ifnet array State-Changed-From-To: open->patched State-Changed-By: brooks State-Changed-When: Fri Aug 27 19:42:47 GMT 2004 State-Changed-Why: I've patched 6-CURRENT and will MFC to RELENG_4 and RELENG_5 (subject to re@ approval) soon. Responsible-Changed-From-To: freebsd-net->brooks Responsible-Changed-By: brooks Responsible-Changed-When: Fri Aug 27 19:42:47 GMT 2004 Responsible-Changed-Why: I've patched 6-CURRENT and will MFC to RELENG_4 and RELENG_5 (subject to re@ approval) soon. http://www.freebsd.org/cgi/query-pr.cgi?pr=52260 From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 20:03:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B42516A4CE for ; Fri, 27 Aug 2004 20:03:28 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC1C43D31 for ; Fri, 27 Aug 2004 20:03:27 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7RK5WSo020613 for ; Fri, 27 Aug 2004 13:05:32 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7RK5WOF020612 for net@freebsd.org; Fri, 27 Aug 2004 13:05:32 -0700 Date: Fri, 27 Aug 2004 13:05:32 -0700 From: Brooks Davis To: net@freebsd.org Message-ID: <20040827200532.GE22253@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: proposed new if_data variable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 20:03:28 -0000 --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to proposed adding a new variable, ifi_epoch, to struct if_data. It will be set to the time the counters were zeroed, currently, the time if_attach was called. The intent is to provide a correct value for RFC2233's ifCounterDiscontinuityTime and to make it easier for applications to verify that the interface they are looking at is the same one that had this index last time. Since this will increase the size of struct if_data and thus struct ifnet, the change needs to be made now if it's going to be made for 5-STABLE. Any comments on this idea? -- Brooks ----- Forwarded message from Brooks Davis ----- From: Brooks Davis Date: Wed, 25 Aug 2004 19:46:15 GMT To: Perforce Change Reviews X-Virus-Status: No Subject: PERFORCE change 60419 for review http://perforce.freebsd.org/chv.cgi?CH=3D60419 Change 60419 by brooks@brooks_minya on 2004/08/25 19:45:20 Add a new member to if_data, ifi_epoch (aka ifp->if_epoch). if_epoch is indended to be set to the time the interface was attached or the last time the stats were reset (we don't currently support that, but it is a potentialy useful concept and I've got plans to cause resets to happen in certain circumstances). if_epoch is indended to always be a valid value for ifCounterDiscontinuityTime in RFC2233. Affected files ... =2E. //depot/user/brooks/cleanup/sys/net/if.c#28 edit =2E. //depot/user/brooks/cleanup/sys/net/if.h#7 edit =2E. //depot/user/brooks/cleanup/sys/net/if_var.h#19 edit Differences ... =3D=3D=3D=3D //depot/user/brooks/cleanup/sys/net/if.c#28 (text+ko) =3D=3D= =3D=3D @@ -387,6 +387,7 @@ TAILQ_INIT(&ifp->if_multiaddrs); knlist_init(&ifp->if_klist, NULL); getmicrotime(&ifp->if_lastchange); + getmicrotime(&ifp->if_epoch); =20 #ifdef MAC mac_init_ifnet(ifp); =3D=3D=3D=3D //depot/user/brooks/cleanup/sys/net/if.h#7 (text+ko) =3D=3D=3D= =3D @@ -103,6 +103,7 @@ u_long ifi_hwassist; /* HW offload capabilities */ u_long ifi_unused; /* XXX was ifi_xmittiming */ struct timeval ifi_lastchange; /* time of last administrative change */ + struct timeval ifi_epoch; /* time of creation or stat reset */ }; =20 #define IFF_UP 0x1 /* interface is up */ =3D=3D=3D=3D //depot/user/brooks/cleanup/sys/net/if_var.h#19 (text+ko) =3D= =3D=3D=3D @@ -227,6 +227,7 @@ #define if_iqdrops if_data.ifi_iqdrops #define if_noproto if_data.ifi_noproto #define if_lastchange if_data.ifi_lastchange +#define if_epoch if_data.ifi_epoch #define if_recvquota if_data.ifi_recvquota #define if_xmitquota if_data.ifi_xmitquota #define if_rawoutput(if, m, sa) if_output(if, m, sa, (struct rtentry *)0) ----- End forwarded message ----- --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBL5QLXY6L6fI4GtQRAkWhAJ9Uqcsr4JhibUfNNM8G9tiGzleazwCgzmEc QLi3KXkgN671xngGZxjTj44= =LWRj -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 20:08:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4500A16A4CE for ; Fri, 27 Aug 2004 20:08:27 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82AA143D5A for ; Fri, 27 Aug 2004 20:08:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 60043 invoked from network); 27 Aug 2004 20:07:02 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2004 20:07:02 -0000 Message-ID: <412F94BC.6360DC17@freebsd.org> Date: Fri, 27 Aug 2004 22:08:28 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brooks Davis References: <20040827200532.GE22253@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: proposed new if_data variable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 20:08:27 -0000 Brooks Davis wrote: > > I'd like to proposed adding a new variable, ifi_epoch, to struct > if_data. It will be set to the time the counters were zeroed, > currently, the time if_attach was called. The intent is to provide a > correct value for RFC2233's ifCounterDiscontinuityTime and to make it > easier for applications to verify that the interface they are looking at > is the same one that had this index last time. > > Since this will increase the size of struct if_data and thus struct > ifnet, the change needs to be made now if it's going to be made for > 5-STABLE. Any comments on this idea? I'm all for it! Very useful. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 21:09:35 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38F3F16A4CE for ; Fri, 27 Aug 2004 21:09:35 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04A3743D53 for ; Fri, 27 Aug 2004 21:09:35 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7RL9YkN016993; Fri, 27 Aug 2004 14:09:34 -0700 (PDT) Received: from [10.1.1.245] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)i7RL9Wd2005065; Fri, 27 Aug 2004 14:09:33 -0700 (PDT) In-Reply-To: <20040827200532.GE22253@odin.ac.hmc.edu> References: <20040827200532.GE22253@odin.ac.hmc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6425FE0A-F86D-11D8-896C-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Fri, 27 Aug 2004 17:09:32 -0400 To: Brooks Davis X-Mailer: Apple Mail (2.619) cc: net@freebsd.org Subject: Re: proposed new if_data variable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 21:09:35 -0000 On Aug 27, 2004, at 4:05 PM, Brooks Davis wrote: > Since this will increase the size of struct if_data and thus struct > ifnet, the change needs to be made now if it's going to be made for > 5-STABLE. Any comments on this idea? I think the change is useful, by all means. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 22:26:12 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF18E16A4CE for ; Fri, 27 Aug 2004 22:26:12 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AAE743D5A for ; Fri, 27 Aug 2004 22:26:12 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i7RMNBGH073499 for net@freebsd.org.checked; (8.12.8/vak/2.1) Sat, 28 Aug 2004 02:23:11 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hanoi.cronyx.ru with ESMTP id i7RMM8Cj073427; (8.12.8/vak/2.1) Sat, 28 Aug 2004 02:22:08 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <412FB259.5000200@cronyx.ru> Date: Sat, 28 Aug 2004 02:14:49 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Andre Oppermann References: <20040827200532.GE22253@odin.ac.hmc.edu> <412F94BC.6360DC17@freebsd.org> In-Reply-To: <412F94BC.6360DC17@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: proposed new if_data variable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 22:26:13 -0000 Andre Oppermann: >Brooks Davis wrote: > > >>I'd like to proposed adding a new variable, ifi_epoch, to struct >>if_data. It will be set to the time the counters were zeroed, >>currently, the time if_attach was called. The intent is to provide a >>correct value for RFC2233's ifCounterDiscontinuityTime and to make it >>easier for applications to verify that the interface they are looking at >>is the same one that had this index last time. >> >>Since this will increase the size of struct if_data and thus struct >>ifnet, the change needs to be made now if it's going to be made for >>5-STABLE. Any comments on this idea? >> >> > >I'm all for it! Very useful. > This could be other reason to bump version ... rik > > > From owner-freebsd-net@FreeBSD.ORG Fri Aug 27 22:37:19 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F32C416A4CE for ; Fri, 27 Aug 2004 22:37:18 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3601643D39 for ; Fri, 27 Aug 2004 22:37:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 60976 invoked from network); 27 Aug 2004 22:35:52 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2004 22:35:52 -0000 Message-ID: <412FB7A0.E6801EA6@freebsd.org> Date: Sat, 28 Aug 2004 00:37:20 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Kurakin References: <20040827200532.GE22253@odin.ac.hmc.edu> <412F94BC.6360DC17@freebsd.org> <412FB259.5000200@cronyx.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: proposed new if_data variable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 22:37:19 -0000 Roman Kurakin wrote: > > Andre Oppermann: > > >Brooks Davis wrote: > > > > > >>I'd like to proposed adding a new variable, ifi_epoch, to struct > >>if_data. It will be set to the time the counters were zeroed, > >>currently, the time if_attach was called. The intent is to provide a > >>correct value for RFC2233's ifCounterDiscontinuityTime and to make it > >>easier for applications to verify that the interface they are looking at > >>is the same one that had this index last time. > >> > >>Since this will increase the size of struct if_data and thus struct > >>ifnet, the change needs to be made now if it's going to be made for > >>5-STABLE. Any comments on this idea? > >> > >> > > > >I'm all for it! Very useful. > > > This could be other reason to bump version ... I have bumped version to 600001 today due to the permanent pfil_hooks. You can use that if you wish. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Aug 28 15:11:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4121A16A4CE for ; Sat, 28 Aug 2004 15:11:21 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id B015043D3F for ; Sat, 28 Aug 2004 15:11:20 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id C1BF4651FC; Sat, 28 Aug 2004 16:11:18 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74407-02-7; Sat, 28 Aug 2004 16:11:17 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-167-148-26.dsl.snfc21.pacbell.net [64.167.148.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id E4B43651EE; Sat, 28 Aug 2004 16:11:16 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id DD89762E2; Sat, 28 Aug 2004 08:11:13 -0700 (PDT) Date: Sat, 28 Aug 2004 08:11:13 -0700 From: Bruce M Simpson To: Brooks Davis Message-ID: <20040828151113.GA773@empiric.icir.org> Mail-Followup-To: Brooks Davis , freebsd-net@FreeBSD.org References: <20040827200532.GE22253@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20040827200532.GE22253@odin.ac.hmc.edu> cc: freebsd-net@FreeBSD.org Subject: Re: proposed new if_data variable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2004 15:11:21 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 27, 2004 at 01:05:32PM -0700, Brooks Davis wrote: > I'd like to proposed adding a new variable, ifi_epoch, to struct > if_data. It will be set to the time the counters were zeroed, > currently, the time if_attach was called. The intent is to provide a > correct value for RFC2233's ifCounterDiscontinuityTime and to make it > easier for applications to verify that the interface they are looking at > is the same one that had this index last time. Please make this change. A merge to RELENG_5 would be highly desirable. BMS --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFBMKCQueUpAYYNtTsRAlMwAKCFIeE5UtX1NXT0QB1WemVpToPfQgCfcc4b 8uX5Tmb5/1BLNK54UiiW8DQ= =/IkU -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua--