zerotier windows - not ajusting interface mtu

[giobatta]

We are experiencing this issue which causes packet loss on Windows

If you change to zerotier MTU to something lower than 2800, the windows client ignores this setting and the windows interface mtu says at 2800; if you query via zerotier-cli get NET_ID mty you get the correct value. In our case, with windows zerotier client 1.12.2 and also latest version, we get:

zerotier-cli get NET_ID mtu - we get 1388 if we do netsh interface ipv4 show subinterface 2800 1 2240 58058 ZeroTier One [NET_ID]

So if one of the members is on a mobile network which requires lower mtu, you can ping from mobile to windows, but from windows to mobile you get erratic behaviour.

If we force it via netsh interface ipv4 set interface "ZeroTier One [NET_ID]" mtu=1388 it works fine.

Client should be modified as mobile client: when MTU gets changed on the zerotier network, it gets notified and modifies the Windows interface mtu accordingly.

[laduke]

Try to leave and re-join the network on the client

[giobatta]

Try to leave and re-join the network on the client

Hello If you mean to go to zerotier UI and do "disconnect" and "reconnect" we did, but did not do anything. Mobile client (Android) updates it on the fly without even disconnecting/reconnecting, windows does not do it neither automatically nor disconnecting/reconnecting.

As per my point of view, it should

1. Do it automatically like Android client
2. The Zerotier central should do it dynamically (if allowed) because when a client roams from a Wifi network to a mobile network which have different phisical interface MTUs (wifi 1500 and our mobile il 1412), traffic gets disrupted unless the zerotier mtu is manually forced as low as possible (1280). In my point of view each client joined to a network should periodically report its physical interface MTU and the zerotier central should dynamically change the network MTU to the lowest MTU - 28 bytes, this based on our experience up to now.

[laduke]

I mean on the client

[giobatta]

I mean on the client

Yes, on the client: we disconnect and reconnect but MTU remains the same (2800) even if the zerotier central mtu is 1388

[laduke]

I thought this had been fixed actually. #1804 maybe only linux got fixed. If you restart the windows zerotier-one system service, that might change the mtu.

The real issue is, users shouldn't need to fuss with the virtual mtu to make it work on mobile carriers

[giobatta]

I thought this had been fixed actually. #1804 maybe only linux got fixed. If you restart the windows zerotier-one system service, that might change the mtu.

The real issue is, users shouldn't need to fuss with the virtual mtu to make it work on mobile carriers

We also rebooted the machine, no way. I do confirm that with 2800 mtu no traffic flows with most mobile ISP here (we tried the 3 most important operators in Italy). Only way is to lower Zerotier central MTU down to PHY mobile interface -28 And with some mobile operators we have also to change the secondaryPort to some well known UDP port such as 1194 (OpenVPN) otherwise after some packets their DOS systems block UDP traffic so you can ping from Mobile to Fixed client, but reverse traffic (to Mobile) has huge packet loss.

[giobatta]

I thought this had been fixed actually. #1804 maybe only linux got fixed. If you restart the windows zerotier-one system service, that might change the mtu. The real issue is, users shouldn't need to fuss with the virtual mtu to make it work on mobile carriers

We also rebooted the machine, no way. I do confirm that with 2800 mtu no traffic flows with most mobile ISP here (we tried the 3 most important operators in Italy). Only way is to lower Zerotier central MTU down to PHY mobile interface -28 And with some mobile operators we have also to change the secondaryPort to some well known UDP port such as 1194 (OpenVPN) otherwise after some packets their DOS systems block UDP traffic so you can ping from Mobile to Fixed client, but reverse traffic (to Mobile) has huge packet loss.

As per Linux I do confirm that latest version on Ubuntu works fine: change the MTU on Zerotier Central and it "adapts"

[ShadowX117]

Can confirm I was having the same issue on windows 10 after updating from 1.8.7/1.8.9 to 1.14.0.

I changed the mtu of the ZeroTier network to 1388 which did not help until I forced the Zerotier adapter to the mtu of the network. Also if you disconnect from a network and reconnect to it sets the mtu of the adapter to 2800 regardless of the mtu setting of the ZeroTier network.

[gomaaz]

does the issue still persists?

[gomaaz]

I just made some tests on two windows machine. I changed the controller network to MTU 1400 (with api) and it adapts immediately to the adapters of the clients. Windows itself shows still 2800 by checking with netsh interface ipv4 show subinterfaces in powershell.

But as I test between two machines...

with ping <zerotier-ip> -l 1500 -f

all packets above 1400 needs to be fragmented.

so it's a visual bug (Im running version 1.14.2 )

[thomasdaly5]

I can confirm the same - visual bug - the MTU is enforced, and even increasing the MTU at the controller works on the fly.