From owner-freebsd-bugs  Sat Feb  8 23:41:13 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id XAA04684
          for bugs-outgoing; Sat, 8 Feb 1997 23:41:13 -0800 (PST)
Received: from mp.aha.ru (ns.aha.ru [194.135.22.36])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA04650;
          Sat, 8 Feb 1997 23:41:04 -0800 (PST)
Received: by mp.aha.ru id KAA19046;
  (8.8.5/vak/1.8e) Sun, 9 Feb 1997 10:40:13 +0300 (MSK)
From: bvt@mp.aha.ru (Boris Tyshkiewitch)
Message-Id: <199702090740.KAA19046@mp.aha.ru>
Subject: Re: I give up! no ideas left.
To: jas@flyingfox.COM (Jim Shankland)
Date: Sun, 9 Feb 1997 10:40:12 +0300 (MSK)
Cc: bugs@freebsd.org, freebsd-isp@freebsd.org, freebsd-questions@freebsd.org,
        robert@nanguo.chalmers.com.au
In-Reply-To: <199702090652.WAA07862@saguaro.flyingfox.com> from "Jim Shankland" at Feb 8, 97 10:52:01 pm
X-Mailer: ELM [version 2.4 PL24alpha5]
MIME-Version: 1.0
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> Here's what I find when I connect to port 80 of your machine
> (nanguo.chalmers.com.au) and do a "GET / HTTP/1.0":
> 
> >From SunOS 4.1.4:  everything works.
> 
> >From FreeBSD 2.2-BETA_A:  Connection hangs.  My end is ESTABLISHED.
> A packet trace reveals that after the initial, 3-way TCP handshake,
> I receive the *second* data packet from you (covering bytes
> 1440:2049, or something like that), but I never get the first
> (bytes 1:1440).  Of course, my end immediately does an ACK 1
> to signal that it got an out-of-sequence packet; but to no
> avail.  That packet simply never arrives.
> 
> Same thing happens whether RFC1323 and RFC1644 are enabled or
> not; so my tentative conclusion is that they are not a factor.
> 


 I have souch problem. squid cache works fine from FreeBSD 2.1.0 but
connections hungs from 2.2-BETA.  host in question was www.kenwoodusa.com


  After tricks with tcpdump I see picture like discribed above.

  I found differense. 2.1.0 begin session with mss 512, 2.2-BETA - with 1460.
After setting MTU 1006 or less on 2.2 box they work fine.

  When I do traceroute to  www.kenwoodusa.com, they failed (ping still ok).

  I think that some router in that place discard ICMP replayes, so MTU
discovery not working ....


  Why 2.1.0 begin session from smaller MSS values that 2.2-BETA?  Why 2.2-BETA
do that?  What is right way?



Boris.