From owner-freebsd-hackers Tue Jan 28 09:48:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA26789 for hackers-outgoing; Tue, 28 Jan 1997 09:48:47 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26727; Tue, 28 Jan 1997 09:48:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA01087 ; Tue, 28 Jan 1997 09:48:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA08351; Tue, 28 Jan 1997 10:28:29 -0700 From: Terry Lambert Message-Id: <199701281728.KAA08351@phaeton.artisoft.com> Subject: Re: progress report on connection problems To: shovey@buffnet.net (Steve) Date: Tue, 28 Jan 1997 10:28:28 -0700 (MST) Cc: robert@nanguo.chalmers.com.au, freebsd-questions@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: from "Steve" at Jan 28, 97 09:03:16 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I had similar problems using annexes as term servers with user - and have > posted numerous times that this problem only exists with freebsd - sco, > linux, etc doesnt have trouble - only every time I post it I get bashed > about the head and lectured on freebsd having perfect tcp/ip and > everything else in the world having faulty tcp/ip. Please notify Annex that their TCP/IP implementation is non-conforming int the area of option negotiation (the "Cherynobl packets", where if any option bits are set, all option bits get set). They are non-compliant with forwarding of SYN packets containing data, since they strip the data. They are also nominally non-compliant with extention negotiation, since they should negotiate with the host to turn extensions they do not support off (ie: RFC 1323 and RFC 1644). They also do not implement RFC 1323 or RFC 1644 (they *must* implement *all* extensions they fail to negotiate off). In short, we *claim* they are broken because they *are* broken. If you wish to be able to interoperate with faulty implementations, you can always turn off the extensions which trigger the problem with the faulty implementation. Meanwhile, it provides a nice diagnostic for detecting bad TCP/IP implementations, which will only be going to hell in a big way all at once when IPv6 gating comes online, otherwise. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.