[576] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: ipfw unexpected behavior

daemon@ATHENA.MIT.EDU (Liakakis Kostas)
Mon Jun 26 05:53:45 1995

Date: Mon, 26 Jun 1995 11:18:55 +0300 (EET DST)
From: Liakakis Kostas <kostas@skiathos.physics.auth.gr>
To: Kayvan Sylvan <kayvan@Sylvan.COM>
cc: linux-net@vger.rutgers.edu
In-Reply-To: <m0sQ0kC-000234C@satyr.sylvan.com>

On Sun, 25 Jun 1995, Kayvan Sylvan wrote:

> I'm not sure whether this is a bug or not... The ipfw man page is very

[...]

>     Trying 204.153.195.1 ...
>     Connection closed by foreign host.
> 
> So far, so good.
> 
>     root@satyr[/usr/adm]:599$
> 
> Huh??? I was dumped back on satyr. Why? It looks as if the telnet
> connection *from* satyr was also (after the fact of the connection)
> rejected.

It is exacty this... Umm.. I had read about something like this in the
tcpd daemon readme awhile ago I think. It is a bug in the networking of
the remote system. Making a connection seem unreachable will shut down all
connections from that system. Here's that extract from the readme file: 

========================================================================
@(#) README 1.21 94/03/23 17:47:16

[...]

6.2 - Known system software bugs
--------------------------------

[...]

On some systems, the optional RFC 931 remote username lookups may
trigger a kernel bug.  When a client host connects to your system, and
the RFC 931 connection from your system to that client is rejected by a
router, your kernel may drop all connections with that client.  This is
not a bug in the wrapper programs: complain to your vendor, and don't
enable remote user name lookups until the bug has been fixed.

Reportedly, SunOS 4.1.1, Next 2.0a, ISC 3.0 with TCP 1.3, and AIX 3.2.2
and later are OK.

Sony News/OS 4.51, HP-UX 8-something and Ultrix 4.3 still have the bug.
Reportedly, a fix for Ultrix is available ((CXO-8919).

The following procedure can be used (from outside the tue.nl domain) to
find out if your kernel has the bug. From the system under test, do:

	% ftp 131.155.70.100

This command attempts to make an ftp connection to our anonymous ftp
server (ftp.win.tue.nl).  When the connection has been established, run
the following command from the same system under test, while keeping
the ftp connection open:

	% telnet 131.155.70.100 111

Do not forget the `111' at the end of the command. This telnet command
attempts to connect to our portmap process.  The telnet command should
fail with:  "host not reachable", or something like that. If your ftp
connection gets messed up, you have the bug. If the telnet command does
not fail, please let me know a.s.a.p.!

For those who care, the bug is that the BSD kernel code was not careful
enough with incoming ICMP UNREACHABLE control messages (it ignored the
local and remote port numbers, and therefore zapped *all* connections
with the remote system). The bug is still present in the BSD NET/1
source release (1989) but apparently has been fixed in BSD NET/2 (1991). 

===========================================================================


Hope it gives you some help. For once, if what I am saying is the cause 
Linux is the last one to blame. Alan is doing a great job!

-Kostas


home help back first fref pref prev next nref lref last post