Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Jan 1996 14:33:18 -0500 (EST)
From:      Brian Tao <taob@io.org>
To:        Michael Smith <msmith@atrad.adelaide.edu.au>
Cc:        freebsd-hackers@FreeBSD.org, freebsd-isp@FreeBSD.org
Subject:   Blocked rlogin connections (was Re: A few other concerns ... )
Message-ID:  <Pine.BSF.3.91.960108142038.212H-100000@cabal.io.org>
In-Reply-To: <199601071054.VAA20347@genesis.atrad.adelaide.edu.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960108142038.212H-100000>