Client MTU setting and TCP

Frank, HB9FXQ

Actually its two questions: 

The new MTU setting in V3 is only intended for the UDP data, right? For the TCP part: is PMTU working? Our Flex still has to go through some tunneling and I've moved from OpenVPN (UDP with mssfix/fragment setting) to Wireguard and realized that TCP seems to ignore the PMTU to the client, so we have to do MSS clamping at the gateway. Everything working nice and fast, but still.... would be nice without MSS clamping.

ICMP is allowed on all GWs (PMTU from my home network to the radio)

$ traceroute --mtu 192.168.92.8
traceroute to 192.168.92.8 (192.168.92.8), 30 hops max, 65000 byte packets
 1  192.168.178.1 (192.168.178.1)  0.260 ms F=1500  0.206 ms  0.205 ms
 2  10.15.14.1 (10.15.14.1)  18.205 ms F=1420  19.992 ms  19.586 ms
 3  192.168.92.8 (192.168.92.8)  19.874 ms  18.288 ms  19.853 ms

David-N5PSM

I don't understand your two questions yet......    However, I suspect you are asking if the MTU setting is to "Throttle back" the UDP traffic in order to give better usability in poor internet conditions.  I can understand this regardless weather we are talking about V2.5 or V3   Where is the second question?  Please straighten me out.

Mike-VA3MW

You would only change the MTU values if you feel that your packets are being fragmented or broken up.  It is not a throttle feature.  In fact setting it too low is better than setting it too high (within reason).

For most of us on Cable modems or DSL modems, you should not have to touch the setting.  Do not change it without doing some testing.

If you think your MTU value is wrong there, you can do some tests using Windows command prompt to test it.  

https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router


As an example, I know a value of 1500 works at home, but as I sit here at a Tim Horton's in Canada (eh?) I can see it should be set to 1492 as I did the above test.

Mike va3mw

Frank, HB9FXQ

Thanks Michael. The concept of how TCP/IP works is very clear to me. Let me try to explain my question a bit more detailed:

The MTU Value in FRS Clients (Maestro, Mobile & Windows) only seems to affect the UDP traffic: 

My question is about Path MTU discovery.

My PMTU across the routed subnets / tunnel is 1420. 

(Windows Client MTU 1500)<->(Router MTU 1500)<->(Encrypted Tunnel/WAN MTU 1420)<->(Router2 MTU 1500)<->(Flexradio 6xxx) it results in a Path MTU of 1420.

This should be discovered by a mechanism called "Path MTU Discovery (PMTUD) RFC 1191".
Now I want to figure out if that is not taking place by the radio by a bug or by design. 

The Problem is, without MSS clamping on Router2, the radio still pushes out TCP packets > 1420, witch results in connection loss on the client side within a few seconds. That happens because the router would otherwise drop packages with the DF flag set which is by RFC the correct behaviour.

No, we don't want to use SmartLink. We stick to the routed VPN variant with a little help of my https://github.com/krippendorf/flex6k-discovery-util-go at all peers.

To be clear: Technically it is working fine with MSS clamping enabled, which is not how it should be. With PMTUD working on the radio MSS clamping would not be necessary. MSS clamping is kind of a dirty workaround to fix exactly those situations. We've got a latency around 15ms in cable to cable situations, even with DAX IQ and high frame rates.

FYI, here is how i handle the MSS fix on router2, the relevant rule (--clamp-mss-to-pmtu): 

*mangle ...
-A POSTROUTING -o enp2s0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Roland HB9VQQ

To me it seems like the flex implementation is lacking PMTU functionality

Roland HB9VQQ

Showing actual MTU size per interface on Windows

netsh interface ipv4 show interfaces



ETH 4 is my VPN interface with an MTU Size of 1400. So every time I switch from (W)LAN (MTU 1500) to VPN (for remote OPS) and without PMTU I need to reconfigure the MTU Size in SSDR in order to prevent fragmented packets.

Things get even worse if a link in the path between two endpoints has a lower MTU than 1400.
Without PMTU this is not manageable and will lead to connection issues (packet fragmentation) sooner or later.

Would be nice to see a statement from Flex.

https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html#anc6

73

Frank, HB9FXQ

Exactly, what happens in our case: 

Things get even worse if a link in the path between two endpoints has a lower MTU than 1400.
Without PMTU this is not manageable and will lead to connection issues (packet fragmentation) sooner or later.

What happens is, that packets with DF flag will be dropped at the edge of the LAN subnet.

Peter K1PGV

I remember a discussion long ago, and the conclusion was that the radio does not support Path MTU Discovery. That stuck me, at the time, as less than a great choice, but given my personal needs (LAN only) I didn’t pursue the issue further.

Peter
K1PGV

Frank, HB9FXQ

No statement from FRS? 

Mike-VA3MW

What is your question?

Frank, HB9FXQ

Question is, if path MTU discovery will be implemented in the radio firmware / radio network stack

Mike-VA3MW

Hi Frank

We have a policy of not commenting on future features until they are released.  So, at this time, I guess the answer is no comment.  

73, Mike

Paul - KB5MU

This exact problem now arises in what's becoming a plain-vanilla, consumer internet configuration. In the case I'm investigating, it's Verizon 5G Home Internet. This is a fast, cheap, uncapped data service that's widely available and very simple to install. Entirely suitable as a consumer replacement for wired home internet service. And it DOES NOT WORK with Smartlink because of the inability of the Flexradio to adapt to slightly reduced MTU limits.

I was able to get it working with the Windows SmartSDR using the workaround in W0QL's blog post updated January 2022: https://w0qlremotebase.wordpress.com/2020/03/30/flexradio-6600-on-order/ . Without a day to **** and some familiarity with how TCP works, this would have been impossible. And it's still not a solution for Maestro users, among others.

This really needs to be fixed in the Flexradio network stack ASAP.

73 -Paul KB5MU