Date: Fri, 18 May 2007 18:04:34 +0100 From: Rui Paulo <rpaulo@fnop.net> To: Andre Oppermann <andre@freebsd.org> Cc: Rui Paulo <rpaulo@fnop.net>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Julian Elischer <julian@elischer.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_output.c Message-ID: <86bqgioyfx.wl%rpaulo@fnop.net> In-Reply-To: <4644CB11.8030603@freebsd.org> References: <200705102311.l4ANBTCs036325@repoman.freebsd.org> <4643A7F5.4090307@freebsd.org> <86tzuk5iy0.wl%rpaulo@fnop.net> <4643B505.4030901@freebsd.org> <86r6po5i29.wl%rpaulo@fnop.net> <4643BA15.6020203@elischer.org> <4644CB11.8030603@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Fri, 11 May 2007 21:59:13 +0200, Andre Oppermann wrote: > > Julian Elischer wrote: > > 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. > > Julian, Rui, > > what is the output of 'sysctl net.inet.tcp.minmss' on the affected > machines (those that do not enable scaling)? net.inet.tcp.minmss: 216 The other machine is Linux and has a limited /proc: # pwd /proc/net # ls arp ip_mr_vif raw time atm ip_tables_names route udp dev netlink rt_cache unix dev_mcast netstat rt_cache_stat voice firewall_start packet snmp wireless igmp port_trap sockstat ip_conntrack pppoe softnet_stat ip_mr_cache psched tcp -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86bqgioyfx.wl%rpaulo>