TCP Connection hang - MSS again
tuexen at freebsd.org
Tue Apr 6 17:49:13 UTC 2021
> On 6. Apr 2021, at 19:02, Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net> wrote:
>> 06.04.2021 19:54, Rodney W. Grimes wrote:
>>>> 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.
>>> I do not recommend such a setting. That would defeat any jumbo frame usage
>> Why? Default route should not be used for local delivery.
> 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
>>> 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.
>> 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.
> 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.
> 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
> Rod Grimes rgrimes at freebsd.org
> freebsd-net at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-current