From owner-freebsd-hackers Sat Nov 18 11:48:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA15275 for hackers-outgoing; Sat, 18 Nov 1995 11:48:59 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA15268 ; Sat, 18 Nov 1995 11:48:49 -0800 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id LAA02074; Sat, 18 Nov 1995 11:48:19 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id LAA00714; Sat, 18 Nov 1995 11:44:07 -0800 Message-Id: <199511181944.LAA00714@corbin.Root.COM> To: tim@sssun.spb.su cc: hackers@freebsd.org, olah@freebsd.org, wollman@freebsd.org Subject: Re: TIME_WAIT and linear chain of TCPCBs (was: ...beat a WEB server to death) In-reply-to: Your message of "Sat, 18 Nov 95 21:59:16 +0300." From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 18 Nov 1995 11:44:01 -0800 Sender: owner-hackers@freebsd.org Precedence: bulk >I still have no time to look in 2.1 sources, but in 2.0.5 there was >a bug in ip_icmp.c in ICMP_UNREACH type processing. >It look like a misprint, you may see it from a diff: > >*** ip_icmp.c.orig Tue May 30 12:09:42 1995 >--- ip_icmp.c Sat Oct 21 13:01:50 1995 >*************** >*** 240,246 **** > case ICMP_UNREACH_PROTOCOL: > case ICMP_UNREACH_PORT: > case ICMP_UNREACH_SRCFAIL: >! code += PRC_UNREACH_NET; > break; > > case ICMP_UNREACH_NEEDFRAG: >--- 240,246 ---- > case ICMP_UNREACH_PROTOCOL: > case ICMP_UNREACH_PORT: > case ICMP_UNREACH_SRCFAIL: >! code = PRC_UNREACH_NET; > break; > > case ICMP_UNREACH_NEEDFRAG: > >---------------- > >This may lead to a large number of TCP connections in SYN RECEIVED state, >for ex. on large mail relays when some site without a back route to it is >trying to semd mail to this relay. It sends SYN, which reach relay via >for ex. default route. Relay sends SYN back, but get ICMP_UNREACH as >a reply :-(. But because of this misprint tcp socket will not be closed >as it should be, but will hang waiting for timeout expire. I believe the original code is correct. Occording to Stevens' TCP/IP Illustrated when discussing this fragment: "There is an implied ordering of the PRC_ constants that matches the ICMP 'code' values. This explains why 'code' is incremented by a PRC_ constant." -DG