On Thu, Jun 21, 2001 at 03:41:09PM -0400, Hiroto Shibuya wrote:

 > I have questions regarding the semantics of the variable
 > "tcp_mssdflt".  From the references I looked (i.e. Stevens vol1,
 > Appendix E.), the meaning seems to be: "The default TCP MSS for
 > nonlocal destionation".
 > 
 > This logic existed in NetBSD a while back when there was a function
 > tcp_mss() in tcp_input.c which did:
 > 
 >                 if (!in_localaddr(inp->inp_faddr))
 >                         mss = min(mss, tcp_mssdflt);
 > 
 > But at certain point, this routine was deprecated and replaced with
 > "tcp_mss_to_advertise(const struct ifnet *ifp)" in tcp_subr.c, which
 > does not contain this logic.  FreeBSD seems to retain the tcp_mss()
 > NetBSD used to have and maintain that logic.

Right, the reason we pulled that is because it essentially defeats Path
MTU Discovery.  Refer to RFC1191, section 3.1:

    Moreover, doing this prevents PMTU Discovery from discovering PMTUs
    larger than 576, so hosts SHOULD no longer lower the value they send
    in the MSS option.  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.

 > 1) Is this intentional behavior change?  If so, is there any
 >    discussion regarding this in the archive I can refer to?

I'm positive it was discussed on tech-net, but the change was made ..
along time ago.  Moreover, this has been an encouraged practice ever
since 1990 (when the RFC was published).

 > 2) Does anybody has patch (or suggestion on how) to restore the old
 >    behavior?

You should not restore the old behavior.  Instead, you should be using
Path MTU Discovery.  Set the sysctl variable `net.inet.ip.mtudisc' to 1.

If that is still losing for you (i.e. "someone has a broken firewall
that blocks ICMP NEEDS-FRAGMENTATION messages"), then let me know --
we might be able to add a new option that, if enabled, places a cap
on MSS advertisement.

 > I have a customer having problem with MSS due to packet getting
 > fragmented getting into ipsec tunnel and then their ISP filters
 > fragmented ipsec packets.  I'm hoping old behavior of mss will fix
 > this problem.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>