Date: Fri, 8 Mar 1996 11:51:23 -0500 From: "Garrett A. Wollman" <wollman@lcs.mit.edu> To: Matthew Dillon <dillon@backplane.com> Cc: bugs@FreeBSD.ORG Subject: bug in netinet/tcp_input.c Message-ID: <9603081651.AA12660@halloran-eldar.lcs.mit.edu> In-Reply-To: <199603081138.DAA00564@apollo.backplane.com> References: <199603081138.DAA00564@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 8 Mar 1996 03:38:10 -0800, Matthew Dillon <dillon@backplane.com> said:
> This is a non-fatal bug that nevertheless defeats all of the
> recvpipe/sendpipe/mtu stuff in the routing tables.
The recvpipe/sendpipe stuff is mis-named. It is really
recvbuf/sendbuf. If it really did indicate a pipe size, socket
buffers would end up being huge.
> Specifically, the tcp_mssopt() procedure fails to use the
> rt-> rt_rmx.rmx_mtu information when calculating the maximum
> segment size for outgoing connections.
Quoth RFC 1191:
The MSS option should be 40 octets less than the
size of the largest datagram the host is able to reassemble (MMS_R,
as defined in [1]); in many cases, this will be the architectural
limit of 65495 (65535 - 40) octets. A host MAY send an MSS value
derived from the MTU of its connected network (the maximum MTU over
its connected networks, for a multi-homed host); this should not
cause problems for PMTU Discovery, and may dissuade a broken peer
from sending enormous datagrams.
As you can see, the MSS option that we send is not supposed to be
related to the Path MTU for packets that we are sending; after all,
the MSS option is about what THEY send back TO US, and their path back
to us is often different. We really should take the maximum over all
interfaces as suggested in the RFC, but I didn't get around to doing
that.
RFC 1191 goes on to say:
Note: At the moment, we see no reason to send an MSS greater
than the maximum MTU of the connected networks, and we
recommend that hosts do not use 65495. It is quite possible
that some IP implementations have sign-bit bugs that would be
tickled by unnecessary use of such a large MSS.
In other words, the current implementation is operating according to
specification.
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9603081651.AA12660>