Date: Tue, 6 Apr 2021 13:20:47 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Rozhuk Ivan <rozhuk.im@gmail.com> Cc: freebsd-current@freebsd.org, freebsd-net <freebsd-net@freebsd.org> Subject: Re: TCP Connection hang - MSS again Message-ID: <e585d6e5-6cdf-ff9b-b7f6-c55d890e94ca@grosbein.net> In-Reply-To: <20210405154449.2d267589@rimwks.local> References: <20210405124450.7505b43c@rimwks.local> <0D7C52FC-DA37-41B6-A05C-F49ECEFE51FC@freebsd.org> <20210405154449.2d267589@rimwks.local>
next in thread | previous in thread | raw e-mail | index | archive | help
05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropped >>> by router. >> If the peer does not provide an MSS option, your local FreeBSD based >> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is >> 536. So I don't think this should be a problem. > > Thats it! > Thanks, it was ~64k in mine config. This is also per-host setting, you know :-) It is generally bad idea using MTU over 1500 for an interface facing public network without -mtu 1500. You see, because TCP MSS affects only TCP and there is also UDP that happily produces oversized datagramms for DNS or RTP or NFS or tunneling like L2TP or OpenVPN etc. relying on IP fragmentation. I still recommend using -mtu 1500 in addition to mssdflt in your case.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e585d6e5-6cdf-ff9b-b7f6-c55d890e94ca>