Date: Tue, 12 May 2009 07:10:31 -0700 From: Michael Sinatra <michael@rancid.berkeley.edu> To: Andrey Voitenkov <av@holymail.biz> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/134486: Wrong MSS in outgoing packets for non-default (1460) MSS Message-ID: <4A098357.2020204@rancid.berkeley.edu> In-Reply-To: <200905121120.n4CBK2bc091671@freefall.freebsd.org> References: <200905121120.n4CBK2bc091671@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/12/09 4:20 AM, Andrey Voitenkov wrote: > The following reply was made to PR amd64/134486; it has been noted by GNATS. > > From: Andrey Voitenkov <av@holymail.biz> > To: bug-followup@FreeBSD.org > Cc: av@holymail.biz > Subject: Re: amd64/134486: Wrong MSS in outgoing packets for non-default > (1460) MSS > Date: Tue, 12 May 2009 13:50:29 +0300 > > Workaround: > ifconfig fxp0 -rxcsum -txcsum -tso > (works for em0 also) I have seen this same problem on i386 with a TSO-capable fxp0 interface. You can also work around the problem with: sysctl net.inet.tcp.tso=0 This issue was mentioned elsewhere on one of the FreeBSD lists, but I can't seem to locate it now. It seems that if TSO is enabled, the system sends packets up to the system's *own* interface MTU-40, ignoring the MSS. After failing to received a delayed ACK, the system drops back to the correct frame size, but the resulting delay makes the connection really slow. Like I said, I can reproduce this behavior on an i386 system with a TSO-capable fxp interface and can send tcpdump output very similar to Andrey's if needed. michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A098357.2020204>