Date: Sun, 7 Jan 1996 21:24:31 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: taob@io.org (Brian Tao) Cc: freebsd-hackers@FreeBSD.org, freebsd-isp@FreeBSD.org Subject: Re: A few other concerns from a FreeBSD ISP Message-ID: <199601071054.VAA20347@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.91.960106150533.209B-100000@cabal.io.org> from "Brian Tao" at Jan 6, 96 03:07:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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." [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601071054.VAA20347>