From owner-freebsd-hackers Sun Jan 7 02:52:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA03752 for hackers-outgoing; Sun, 7 Jan 1996 02:52:41 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA03435 Sun, 7 Jan 1996 02:51:50 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id VAA20347; Sun, 7 Jan 1996 21:24:31 +1030 From: Michael Smith Message-Id: <199601071054.VAA20347@genesis.atrad.adelaide.edu.au> Subject: Re: A few other concerns from a FreeBSD ISP To: taob@io.org (Brian Tao) Date: Sun, 7 Jan 1996 21:24:31 +1030 (CST) Cc: freebsd-hackers@FreeBSD.org, freebsd-isp@FreeBSD.org In-Reply-To: from "Brian Tao" at Jan 6, 96 03:07:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk Brian Tao stands accused of saying: > 1. Rlogin problem > I have tcp_wrappers installed on the FreeBSD machine. When an > rlogin fails, no connection is registered by tcpd and rlogind on the > destination host doesn't even start. Running inetd in debug mode > indicates that not even inetd is aware there is a connection attempt > on port 513. > > Running netstat around the time of the rlogin attempt suggests > that the rlogin hang may have to do with the kernel assigning the > connection a port number that is still currently in TIME_WAIT from a > previous rlogin. Once the TIME_WAIT status is cleared, the rlogin is > completed. This isn't how it works. The kernel doesn't assign port numbers to incoming connections; the port number is nominated by the remote host. The outgoing port number is probably allocated by rresvport(), which is in the standard library (lib/libc/net/rcmd.c). This searches the list of available ports starting at a nominated number and picks up the first that it can get hold of. (Actually, this function is pretty bogus, but it works OK) It's possible that the remote host is reusing an originating port number that is still recorded by the FreeBSD system as belonging to a connection in one of the closing wait states to that same host. I don't know what would happen here, it's possible that someone got their TCP state diagram confused. Kernel TCP gurus? > I haven't noticed this problem with BSD/OS 2.0 yet, nor any other > flavour of UNIX I've used. I haven't used NetBSD systems enough to > know if they have the same problem in their socket code. Has anyone > else seen this behaviour with 2.1.0-RELEASE (or with earlier or later > kernels)? Better yet, does anyone have a solution? I've definitely seen this problem; unfortunately I'm not familiar with the code that I suspect. This _is_ a real problem though. > Brian Tao (BT300, taob@io.org) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[