Re: TCP Connection hang - MSS again

> 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
>>> locally!
>> 
>> 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
> route.
> 
>>> 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.

Best regards
Michael
> 
> 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.
> 
> -- 
> Rod Grimes                                                 rgrimes_at_freebsd.org
> _______________________________________________
> freebsd-net_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe_at_freebsd.org"