Subject: Re: tcp_mssdflt
To: Hiroto Shibuya <>
From: Kevin Lahey <>
List: tech-net
Date: 06/21/2001 13:06:34
In message <15154.19925.470883.986326@gargle.gargle.HOWL>Hiroto Shibuya writes
>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.

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

This was changed at about the same time we added path MTU discovery --
the idea was that we always wanted to advertise the largest possible
segment size that we could accept, so that the other side could do
PMTUD, even if we didn't have it turned on.

That is, without PMTUD, we are constrained to send segments of no
more than 536 bytes.  There isn't anything that suggests that we
can't accept larger segments, just that we can't send them.  Thus,
we advertise a large MSS no matter what.

>2) Does anybody has patch (or suggestion on how) to restore the old
>   behavior?
>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.

I've heard suggestions that other people have been similarly bitten
by tunnelling and fragmentation bugs like this and have written
patches, but I haven't seen them.

As a temporary fix, you could add a host route on the source system
with an appropriately smaller MTU.  That sounds like an unsatisfactory
answer, but there it is...