Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

Client MTU setting and TCP

Frank, HB9FXQ
Frank, HB9FXQ Member ✭✭
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


Answers

  • David-N5PSM
    David-N5PSM Member ✭✭
    edited September 2019
    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
    Mike-VA3MW Administrator, FlexRadio Employee, Community Manager, Super Elmer, Moderator admin
    edited September 2019
    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
    Frank, HB9FXQ Member ✭✭
    edited September 2019
    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
    Roland HB9VQQ Member ✭✭
    edited September 2019
    To me it seems like the flex implementation is lacking PMTU functionality
  • Roland HB9VQQ
    Roland HB9VQQ Member ✭✭
    edited September 2019
    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
    Frank, HB9FXQ Member ✭✭
    edited September 2019
    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
    Peter K1PGV Member ✭✭✭
    edited June 2020
    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
    Frank, HB9FXQ Member ✭✭
    edited October 2019
    No statement from FRS? 
  • Mike-VA3MW
    Mike-VA3MW Administrator, FlexRadio Employee, Community Manager, Super Elmer, Moderator admin
    edited October 2019
    What is your question?
  • Frank, HB9FXQ
    Frank, HB9FXQ Member ✭✭
    edited October 2019
    Question is, if path MTU discovery will be implemented in the radio firmware / radio network stack
  • Mike-VA3MW
    Mike-VA3MW Administrator, FlexRadio Employee, Community Manager, Super Elmer, Moderator admin
    edited October 2019
    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
    Paul - KB5MU Member ✭✭

    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

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.