From owner-freebsd-questions Fri Sep 20 06:00:33 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA10015 for questions-outgoing; Fri, 20 Sep 1996 06:00:33 -0700 (PDT) Received: from bbs.mpcs.com (hgoldste@bbs.mpcs.com [204.215.226.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA09976 for ; Fri, 20 Sep 1996 06:00:28 -0700 (PDT) Received: (from hgoldste@localhost) by bbs.mpcs.com (8.7.6/8.7.3/MPCS) id JAA32413; Fri, 20 Sep 1996 09:00:22 -0400 Date: Fri, 20 Sep 1996 09:00:22 -0400 From: Howard Goldstein Message-Id: <199609201300.JAA32413@bbs.mpcs.com> To: freebsd-questions@freebsd.org Subject: RFC1323 probs (was Re: odd problem with 2.1R NNTP access) In-Reply-To: <199609200047.AA189830474@relay.hp.com> Reply-To: hgoldste@bbs.mpcs.com Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199609200047.AA189830474@relay.hp.com>, you wrote: : : The same reason is causing me unable to access www.etinc.com and : timeout during smtp session. This is possible if both boxes are running 2.1R or later (never tried it with earlier versions) : : So, does it mean in general the following are true for 2 FreeBSD : boxes: : : 1) Both boxes have tcp_extension enabled and they should talk : happily This doesnt seem to help. Actual RTT is important though (see below) : 2) Both boxes have tcp_extension disabled and they should talk : happily This works : 3) One has tcp_extension enabled and one disabled and there is : no gurantee of the connection ? I believe etinc.com is : using FreeBSD, but I do get this problem before when I have : the tcp_extension stuff enabled. This works and is like #2 since the extension isn't used if one side doesn't have it enabled. To test whether 1323 is biting you, telnet to the echo port on the target machine. An afflicted connection will echo your first line back quickly but subsequent lines will suffer a 3 or 4 second delay. Disconnect and set rfc1323=0 and see if the extra delay goes away. I'd submit a GNAT report on this but it seems the problem is already known. (if not maybe one of the cognoscenti could say something and I will send in the pr) FWIW the problem doesn't show up with ethernetted hosts, perhaps because the timing granularity is too large for the delay to be noted. Unfortunately where the connection is across something with some delay, likea 110ms RTT slip link, the problem is consistent and easily replicable. There also appears to be problems in the RTT handling in non-1323 connections (unrelated except that it involves similar functionality). If no one else is tackling these right now I'm gonna take a whack at it. -- Howard Goldstein