From owner-freebsd-isp Tue Jan 28 09:36:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26130 for isp-outgoing; Tue, 28 Jan 1997 09:36:24 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26108; Tue, 28 Jan 1997 09:36:15 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08314; Tue, 28 Jan 1997 10:18:00 -0700 From: Terry Lambert Message-Id: <199701281718.KAA08314@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: robert@nanguo.chalmers.com.au (Robert Chalmers) Date: Tue, 28 Jan 1997 10:18:00 -0700 (MST) Cc: freebsd-questions@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199701281002.UAA00874@nanguo.chalmers.com.au> from "Robert Chalmers" at Jan 28, 97 08:02:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-isp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I can connect to, and be connected to these OSs with no worries. > I have tried setting tcp_extensions NO and YES. If set to YES, I am unable > to ftp to another FBSD site that also has tcp_extensions set YES (on). > The connection simply 'hung'. If I set rfc1323 to 0 (off) the ftp connection > worked fine, the other end being (on). The same happened at the other end, > when they tried to ftp to me. set tcp_extension on, fail, set it off, fine. > > The only constant is the Annex. However, why does it pass _most_ traffic, > if it is the fault of the Annex, and only fail on some.? > > If FreeBSD is > going to be so fussy about its tcp/ip flow, shouldn't it be reworked. > The world is still full of less than leading edge hardware! Some of it > brand new... > > If anyone wants to comment or offer help, I'mm happy to keep trying to > track this bug(ger) down. I don't understand what you are saying here; if you are saying that it works with extensions off, then it is easy to explain: o All TCP/IP implementations *must* support extension negotiation for locally unsupported extensions (they are to negotiate them "off"). Not all TCP/IP implementations are conforming. o All TCP/IP implementations *must* support data in SYN packets, even though most implementations do not generate data in SYN packets. T/TCP will generate data in SYN packets; so will the FreeBSD "finger" (man finger). Not all TCP/IP implementations are conforming. If you detect a non-conforming implementation: 1) Contact the vendor for a fix; one probably exists. 2) If no fix is available, turn extension off on the FreeBSD system, and submit a bug report to the vendor so that a fix will happen. If you think things are bad now, wait until the net begins migrating to IPv6 at the router level. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.