I noted today that the "fallback_interface" option needs to be added on BOOTH sides, not just at the client-side.
In my case i had massive latency and performance issues in the downstream path, bot upstream was fine.
after i have set fallback =1 at booth eds the LTE interface is really in standard for up/dl.
REQUEST:
It is possible to add the TCP tunnel option (back) ?
i use vtun since more then 15 years with TCP instead UDP protocol. this has the huge advantage that i no longer need the chaotic workarounds for MTU/MSS/PMTU and i can setup up tunnels straight with an MTU of 1500 like before. By using tcp the protocol itself handle all fragmentation issues just between client and server. Basicly i have less problems with specific firewalls or in scenarios where udp is filtered or not optimal to use.
Or can we think about a solution to handle internaly an MTU of 1500 with UDP by fragmenting directly in MLVPN so the tunnel accept the fully standard packet size ?
Another open thing is the time in which a "lossy" link is reused/retryed. At the moment there is no config option set a reusable/retry value. IN my scenario one of my link reached a 10% trigger and goes down - but not comes back byself after a while.
I noted today that the "fallback_interface" option needs to be added on BOOTH sides, not just at the client-side. In my case i had massive latency and performance issues in the downstream path, bot upstream was fine. after i have set fallback =1 at booth eds the LTE interface is really in standard for up/dl.
REQUEST: It is possible to add the TCP tunnel option (back) ?
i use vtun since more then 15 years with TCP instead UDP protocol. this has the huge advantage that i no longer need the chaotic workarounds for MTU/MSS/PMTU and i can setup up tunnels straight with an MTU of 1500 like before. By using tcp the protocol itself handle all fragmentation issues just between client and server. Basicly i have less problems with specific firewalls or in scenarios where udp is filtered or not optimal to use.
Or can we think about a solution to handle internaly an MTU of 1500 with UDP by fragmenting directly in MLVPN so the tunnel accept the fully standard packet size ?
Another open thing is the time in which a "lossy" link is reused/retryed. At the moment there is no config option set a reusable/retry value. IN my scenario one of my link reached a 10% trigger and goes down - but not comes back byself after a while.