Date: Fri, 08 Mar 1996 04:41:37 -0800 From: David Greenman <davidg@Root.COM> To: Matthew Dillon <dillon@backplane.com> Cc: bugs@freebsd.org, wollman@freebsd.org, olah@freebsd.org Subject: Re: bug in netinet/tcp_input.c Message-ID: <199603081241.EAA00927@Root.COM> In-Reply-To: Your message of "Fri, 08 Mar 1996 03:38:10 PST." <199603081138.DAA00564@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> This is a non-fatal bug that nevertheless defeats all of the > recvpipe/sendpipe/mtu stuff in the routing tables. > > Specifically, the tcp_mssopt() procedure fails to use the > rt->rt_rmx.rmx_mtu information when calculating the maximum > segment size for outgoing connections. This results in the > remote end sending us packets larger then we intend, messing > up any fine tuning we tried to do with the route recvpipe/sendpipe/mtu. > > In anycase, the fix is simple. Here's a new tcp_mssopt() routine: I'll pass this along, but my understanding is that the code was changed to the way it is in order for Path MTU Discovery to work correctly with asymetric routes (all too common in the Internet today). The change was made on Oct 13th of last year: ---------------------------- revision 1.30 date: 1995/10/13 16:00:25; author: wollman; state: Exp; lines: +1 -7 Routes can be asymmetric. Always offer to /accept/ an MSS of up to the capacity of the link, even if the route's MTU indicates that we cannot send that much in their direction. (This might actually make it possible to test Path MTU discovery in a useful variety of cases.) -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603081241.EAA00927>