Date: Wed, 13 Mar 1996 12:08:37 -0800 From: Paul Traina <pst@shockwave.com> To: Faried Nawaz <fn@pain.csrv.uidaho.edu> Cc: current@freebsd.org Subject: Re: finger and 2.2-960303-SNAP Message-ID: <199603132008.MAA04472@precipice.shockwave.com> In-Reply-To: Your message of "Wed, 13 Mar 1996 03:31:29 PST." <1047.826716689@pain.csrv.uidaho.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603132008.MAA04472>