From owner-freebsd-bugs  Sun Apr  7 16:14:07 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA10876
          for bugs-outgoing; Sun, 7 Apr 1996 16:14:07 -0700 (PDT)
Received: from birk04.studby.uio.no (birk04.studby.uio.no [129.240.214.13])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA10867
          for <freebsd-bugs@freebsd.org>; Sun, 7 Apr 1996 16:14:00 -0700 (PDT)
Received: (from aagero@localhost) by birk04.studby.uio.no (8.7.5/sendmail95) id BAA11683; Mon, 8 Apr 1996 01:13:56 +0200 (MET DST)
Date: Mon, 8 Apr 1996 01:13:56 +0200 (MET DST)
Message-Id: <199604072313.BAA11683@birk04.studby.uio.no>
Mime-Version: 1.0
From: =?iso-8859-1?Q?=22=C5ge?=  =?iso-8859-1?Q?R=F8bekk=22?=  <aagero@aage.priv.no>
To: freebsd-bugs@freebsd.org
Subject: tcp extensions broken in current?
MIME-Version: 1.0
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

It appears to me, after comparing -current and -stable, that the tcp
extensions behave differently and not as expected in -current.  The
most apparent and noticeable situation is a finger client request to a
linux box.  This is when net.inet.tcp.rfc1644 is set.  This might
indicate potential problems with other tcp clients too, with a not so
easy interface and therefore not so easy to spot.

But on the other hand, it can also mean that the rfc1644 extension has
been enhanced, and the linux tcp stack has always been broken in this
manner, but noticable first after this change.  I haven't been able to
compare tcpdump output from a -stable and a -current host though.

-aage