Date: Mon, 15 Jan 1996 17:27:02 -0500 (EST) From: Brian Tao <taob@io.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: FREEBSD-HACKERS-L <freebsd-hackers@freebsd.org>, FREEBSD-ISP-L <freebsd-isp@freebsd.org> Subject: Re: Blocked rlogin connections (was Re: A few other concerns ... ) Message-ID: <Pine.BSF.3.91.960115170249.278q-100000@cabal.io.org> In-Reply-To: <199601090124.LAA03919@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Jan 1996, Michael Smith wrote:
>
> You say that inet doesn't see the incoming connections; can you use
> tcpdump() to specifically watch for opening rlogin sessions?
I've never really used tcpdump before (other than to marvel at all
the information coming across the interface ;-)), so if anyone has
some helpful suggestions on what switches to use or what to look for,
I will gladly accept them. :)
cabal is the source of the rlogin, zap is the destination. I
fired up 'tcpdump -lq host cabal and port login' in one xterm and
'rlogin zap' in another. This is what I'm getting on the cabal side:
# tcpdump -lq host cabal and port login
tcpdump: listening on ed0
17:16:56.019745 cabal.io.org.1023 > zap.io.org.login: tcp 0
17:16:56.020146 zap.io.org.login > cabal.io.org.1023: tcp 0
17:16:57.030426 cabal.io.org.1023 > zap.io.org.login: tcp 0
17:16:57.030995 zap.io.org.login > cabal.io.org.1023: tcp 0
17:16:59.040373 cabal.io.org.1023 > zap.io.org.login: tcp 0
17:16:59.040774 zap.io.org.login > cabal.io.org.1023: tcp 0
17:17:03.050413 cabal.io.org.1023 > zap.io.org.login: tcp 0
17:17:03.050805 zap.io.org.login > cabal.io.org.1023: tcp 0
17:17:11.060380 cabal.io.org.1023 > zap.io.org.login: tcp 0
17:17:11.060752 zap.io.org.login > cabal.io.org.1023: tcp 0
17:17:27.070400 cabal.io.org.1023 > zap.io.org.login: tcp 0
17:17:27.071068 zap.io.org.login > cabal.io.org.1023: tcp 0
17:17:27.071246 cabal.io.org.1023 > zap.io.org.login: tcp 0
17:17:27.071466 cabal.io.org.1023 > zap.io.org.login: tcp 1
17:17:27.149950 zap.io.org.login > cabal.io.org.1023: tcp 0 [tos 0x10]
17:17:27.150086 cabal.io.org.1023 > zap.io.org.login: tcp 21
17:17:27.277057 zap.io.org.login > cabal.io.org.1023: tcp 1 [tos 0x10]
17:17:27.286097 zap.io.org.login > cabal.io.org.1023: tcp 1 [tos 0x10]
17:17:27.286648 cabal.io.org.1023 > zap.io.org.login: tcp 12 [tos 0x10]
17:17:27.336123 zap.io.org.login > cabal.io.org.1023: tcp 62 [tos 0x10]
17:17:27.500116 cabal.io.org.1023 > zap.io.org.login: tcp 0 [tos 0x10]
17:17:27.502165 zap.io.org.login > cabal.io.org.1023: tcp 1270 [tos 0x10]
17:17:27.700111 cabal.io.org.1023 > zap.io.org.login: tcp 0 [tos 0x10]
17:17:29.912278 zap.io.org.login > cabal.io.org.1023: tcp 61 [tos 0x10]
17:17:30.100138 cabal.io.org.1023 > zap.io.org.login: tcp 0 [tos 0x10]
The rlogin hung for about the first 30 seconds (17:16:56 to
17:17:27 in the dump), then I got in. The rest of the dump is the
FreeBSD banner and motd scrolling by. I don't know how to interpret
tcpdump output, but it does appear that zap is sending some sort of
acknowledgement back to cabal (0 bytes?).
I can produce more verbose output from both cabal and zap for an
actual failed rlogin attempt (this one was just delayed) if that will
help.
> > If a kernel problem, would setting net.inet.tcp.rfc1323 and
> > net.inet.tcp.rfc1644 with sysctl have any effect (or side effect)?
>
> No idea; try it 8)
Those to parameters are still set to 1. Do I need to reboot for
changes from sysctl to take place? I haven't heard any reports from
our customer support people about users not being able to rlogin from
a terminal server, but that doesn't mean it isn't happening. :(
--
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.960115170249.278q-100000>