From owner-freebsd-current Sun Dec 31 09:13:48 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA13798 for current-outgoing; Sun, 31 Dec 1995 09:13:48 -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 JAA13792 for ; Sun, 31 Dec 1995 09:13:45 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.6.12) with SMTP id JAA01624; Sun, 31 Dec 1995 09:12:06 -0800 (PST) Message-Id: <199512311712.JAA01624@precipice.shockwave.com> To: Andras Olah cc: current@FreeBSD.org Subject: Re: -current TCP interoperability issues In-reply-to: Your message of "Sun, 31 Dec 1995 09:01:20 +0100." <13557.820396880@curie.cs.utwente.nl> Date: Sun, 31 Dec 1995 09:12:06 -0800 From: Paul Traina Sender: owner-current@FreeBSD.org Precedence: bulk From: Andras Olah Subject: Re: -current TCP interoperability issues On Fri, 29 Dec 1995 19:12:07 PST, Paul Traina wrote: > I'm having problems with tcp connections that contain data with SYN packets >>. > It seems like turning off the TCP extensions is not sufficient. It would be nice if you could send a tcpdump of how these connections fail. On the other hand, the handling of the TCP extension bits could be more conservative in our TCP implementation. Right now, we send data on the SYN segment even if rfc1644=0, only the CC option is turned off. In defense of the current mechanism, however, note that this is perfectly valid TCP behavior. Andras Certainly: 09:10:27.483614 precipice.1093 > AMPRnet-Gateway.finger: SFP 3642470994:3642470996(2) win 16384 (DF) (ttl 64, id 4774) No response. I've actually gdb'ed the remote host's tcp stack (it's not UCB based) and found (but not fixed) the two bugs causing it to fail there. The problem is that there are a ton of broken hosts out there, and we really could use a sysctl variable to disable this functionality.