Date: Tue, 6 Apr 2021 19:49:08 +0200 From: Michael Tuexen <tuexen@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Eugene Grosbein <eugen@grosbein.net>, freebsd-net <freebsd-net@freebsd.org>, freebsd-current@freebsd.org Subject: Re: TCP Connection hang - MSS again Message-ID: <C41B260B-D065-4F78-843C-EECFF8FD05BD@freebsd.org> In-Reply-To: <202104061702.136H2hZh006398@gndrsh.dnsmgr.net> References: <202104061702.136H2hZh006398@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 6. Apr 2021, at 19:02, Rodney W. Grimes = <freebsd-rwg@gndrsh.dnsmgr.net> wrote: >=20 >> 06.04.2021 19:54, Rodney W. Grimes wrote: >>>> 05.04.2021 19:44, Rozhuk Ivan wrote: >>>>=20 >>>>>>> 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. =20 >>>>>> 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. >>>>>=20 >>>>> Thats it! >>>>> Thanks, it was ~64k in mine config. >>>>=20 >>>> This is also per-host setting, you know :-) >>>>=20 >>>> 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. >>>>=20 >>>> I still recommend using -mtu 1500 in addition to mssdflt in your = case. >>>=20 >>> I do not recommend such a setting. That would defeat any jumbo = frame usage >>> locally! >>=20 >> Why? Default route should not be used for local delivery. >=20 > Your right, but we are both making assumptions, I assumed that most > likely the only route on the system is the default route, and your > assuming that they are running with something more than a default > route. >=20 >>> The gateway/router that is forwarding packets to the internet = connection >>> needs its upstream interface mtu set properly, and configured to = properly >>> return icmp need fragement messages on the interfaces towards the >>> internal network. >>=20 >> This results in extra delays and retransmission during outgoing data = transfer, not good. >> The mechanics is much more fragile than default route's mtu = attribute. >=20 > The delay should be pretty slight, the router is going to return an > icmp message, and if configured to do so frag the packets and > forward them on, no retransmission would occur as the DF flag > is not normally set unless explicitly requested. 1. Isn't a router either fragmenting a packet and forwarding the fragments or sending back an ICMP packet and dropping the packet? 2. Isn't FreeBSDs TCP implementation setting the DF bit, if net.inet.tcp.path_mtu_discovery is set to 1, which is the default. So it would take one RTT to the router For TCP to react and reduce the = MSS. Best regards Michael >=20 > It still makes no since to me to increase the interface MTU and then > crank it back down by using a route MTU. You might as well just leave > the MTU alone and not have 2 configurations items more or less doing > nothing. >=20 > --=20 > Rod Grimes = rgrimes@freebsd.org > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C41B260B-D065-4F78-843C-EECFF8FD05BD>