From owner-freebsd-bugs Fri Mar 8 15:17:07 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA21087 for bugs-outgoing; Fri, 8 Mar 1996 15:17:07 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA21061 for ; Fri, 8 Mar 1996 15:17:03 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id IAA27132 for ; Fri, 8 Mar 1996 08:52:03 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA12660; Fri, 8 Mar 1996 11:51:23 -0500 Date: Fri, 8 Mar 1996 11:51:23 -0500 From: "Garrett A. Wollman" Message-Id: <9603081651.AA12660@halloran-eldar.lcs.mit.edu> To: Matthew Dillon Cc: bugs@FreeBSD.ORG Subject: bug in netinet/tcp_input.c In-Reply-To: <199603081138.DAA00564@apollo.backplane.com> References: <199603081138.DAA00564@apollo.backplane.com> Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk < 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