Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 May 2007 17:34:29 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Rui Paulo <rpaulo@fnop.net>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Andre Oppermann <andre@freebsd.org>, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/netinet tcp_output.c
Message-ID:  <4643BA15.6020203@elischer.org>
In-Reply-To: <86r6po5i29.wl%rpaulo@fnop.net>
References:  <200705102311.l4ANBTCs036325@repoman.freebsd.org>	<4643A7F5.4090307@freebsd.org>	<86tzuk5iy0.wl%rpaulo@fnop.net>	<4643B505.4030901@freebsd.org> <86r6po5i29.wl%rpaulo@fnop.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Rui Paulo wrote:
> At Fri, 11 May 2007 02:12:53 +0200,
> Andre Oppermann wrote:
>> Rui Paulo wrote:
>>> At Fri, 11 May 2007 01:17:09 +0200,
>>> Andre Oppermann wrote:
>>>> Andre Oppermann wrote:
>>>>> andre       2007-05-10 23:11:29 UTC
>>>>>
>>>>>   FreeBSD src repository
>>>>>
>>>>>   Modified files:
>>>>>     sys/netinet          tcp_output.c 
>>>>>   Log:
>>>>>   Fix an incorrect replace of a timer reference made during the TCP timer
>>>>>   rewrite in rev. 1.132.  This unmasked yet another bug that causes certain
>>>>>   connections to get indefinately stuck in LAST_ACK state.
>>>>>   
>>>>>   Revision  Changes    Path
>>>>>   1.135     +1 -1      src/sys/netinet/tcp_output.c
>>>> Pointy hat to:	andre
>>>>
>>>> Fix for the other masked bug(s) is in the works.
>>> Does this fix the bug related to rfc1323?
>>> If not, is it in the works?
>> No, this doesn't fix it.  Which bug about rfc1323 are referring to?
> 
> I sent you two tcpdump's regarding to an HTTP connection that got
> stuck after a few bytes were transfered. One with RFC1323 enable and
> another one without it.
> Disabling RFC1323 sysctl made the connection work flawlessly.
> The host I'm communicating with is on the same network segment.
> 
> Did you recieve the dumps?


This may be one of the ones I sent to you andre.. 
In the one we saw,
the scaling is done wrong if the other end wants to scale by 9 and set a window size of 1.

FreeBSD thinks it has a window size of 1 instead of 1<<9.

I thought this was fixed in -current but it has the same symptoms as what we see in 6.







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4643BA15.6020203>