From owner-freebsd-hackers Mon Jan 8 11:35:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA29895 for hackers-outgoing; Mon, 8 Jan 1996 11:35:29 -0800 (PST) Received: from cabal.io.org (cabal.io.org [198.133.36.103]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA29887 Mon, 8 Jan 1996 11:35:25 -0800 (PST) Received: (from taob@localhost) by cabal.io.org (8.6.12/8.6.12) id OAA05066; Mon, 8 Jan 1996 14:33:18 -0500 Date: Mon, 8 Jan 1996 14:33:18 -0500 (EST) From: Brian Tao To: Michael Smith cc: freebsd-hackers@FreeBSD.org, freebsd-isp@FreeBSD.org Subject: Blocked rlogin connections (was Re: A few other concerns ... ) In-Reply-To: <199601071054.VAA20347@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Sun, 7 Jan 1996, Michael Smith wrote: > > 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. If I rlogin from trepan (BSD/OS) to cabal (FreeBSD), I get this from "netstat" on cabal: Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 cabal.login trepan.1012 ESTABLISHED Are both port numbers (512 and 1012) chosen by the foreign machine? Even so, there is a high correlation between rlogin failures and the destination machine being a FreeBSD box. > 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. I was fiddling around with it some more last night, but I wasn't able to reproduce the problem on my own machine. Several successive rlogins would yield the same source and destination port numbers, and would connect immediately even if netstat listed the connection in TIME_WAIT state. Then again, my own machine isn't hit by logins every few seconds. > Kernel TCP gurus? If a kernel problem, would setting net.inet.tcp.rfc1323 and net.inet.tcp.rfc1644 with sysctl have any effect (or side effect)? > I've definitely seen this problem; unfortunately I'm not familiar with > the code that I suspect. This _is_ a real problem though. This is potentially a showstopper for an ISP (like mine) that depends on consistent and reliable rlogin connections to their server machines. -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't"