From owner-freebsd-current  Wed Mar 13 12:09:57 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA20640
          for current-outgoing; Wed, 13 Mar 1996 12:09:57 -0800 (PST)
Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA20631
          for <current@freebsd.org>; Wed, 13 Mar 1996 12:09:54 -0800 (PST)
Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.4/8.7.3) with SMTP id MAA04472; Wed, 13 Mar 1996 12:08:38 -0800 (PST)
Message-Id: <199603132008.MAA04472@precipice.shockwave.com>
To: Faried Nawaz <fn@pain.csrv.uidaho.edu>
cc: current@freebsd.org
Subject: Re: finger and 2.2-960303-SNAP 
In-reply-to: Your message of "Wed, 13 Mar 1996 03:31:29 PST."
             <1047.826716689@pain.csrv.uidaho.edu> 
Date: Wed, 13 Mar 1996 12:08:37 -0800
From: Paul Traina <pst@shockwave.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

I'd give them the following summary:

I am using an implementation of T/TCP (RFC-1644),  a backwards compatible
extension of TCP (RFC-794) and having difficulty accessing your terminal
server.

T/TCP sends out the initial SYN packet with additional TCP options, a
non-zero data portion, and a FIN.  While this is unusual (you'd normally
not see it) under standard TCP, it _is_ completely legal and any TCP
implementation conformant to RFC-794 should handle this properly.  The FreeBSD
team has encountered a few other TCP implementations with similar problems.
The cause is usually due to not handling the data in the SYN packet properly.

Please update your TCP implementation so that it is RFC-794 compliant.

Here's a tcpdump of the conversation:

% tcpdump host <annex> &
% finger @<annex>
% fg
^C

% tcpdump -x host <annex> &
% finger @<annex>
% fg
^C

Many of the TCP implementations we've found that do not inter-operate properly
with T/TCP are based off of code originally written by Phil Karn.  Phil
recently published a fix for this problem.  In the off chance your TCP is based
upon his code, here was his fix (the function in question is tcp_input):

*** tcpin.c.orig        Fri Aug 18 10:49:17 1995
--- tcpin.c     Tue Feb 13 01:13:00 1996
***************
*** 162,171 ****
                        proc_syn(tcb,ip->tos,&seg);
                        send_syn(tcb);
                        setstate(tcb,TCP_SYN_RECEIVED);
-                       if(length != 0 || seg.flags.fin) {
-                               /* Continue processing if there's more */
-                               break;
-                       }
                        tcp_output(tcb);
                }
                free_p(bp);     /* Unlikely to get here directly */
--- 162,167 ----


If you have any further questions, feel free to contact Garret Wollman
(wollman@freebsd.org), Andreas Olah (olah@freebsd.org), or Paul Traina
(pst@freebsd.org).


--------

What do you think of that?




  From: Faried Nawaz <fn@pain.csrv.uidaho.edu>
  Subject: Re: finger and 2.2-960303-SNAP 
  
  Paul Traina wrote...
     
     No, it's actually better if the bug reports come to US first.  The reason
     being that most vendors would say "pshaw, you guys are idiots." whereas
     there are a bunch of us on the mailing list who can point to the exact
     bits of trivia in RFC-793 and sample "killer packets" to get these guys to
     fix their TCP implementation.
  
  for xylogics/annex it's annex_support@xylogics.com i believe.  any ideas on
  how i should compose my `bug report'?  i've never really done this before.
  
  
  faried.