Android issues on cellular but not WiFi connection

This started about 2 months ago. I don’t know if it’s a ZeroTier update or an Android update that causes the issue. Further, it seems to only happen on my Pixel 6 and my wife’s Moto Stylus 2021, but works on my Samsung S21.

If I connect to my server through ZeroTier and retrieve mail via IMAP (with SSL/TLS or STARTTLS), it works perfectly, as long as I’m connected via WiFi. If I connect via cellular, then the TLS handshake always fails (it’s not a connection issue, I can watch the packets with wireshark on the server, and they fly by until a long IMAP Response is sent from the server, and the client goes into a retransmission cycle).

That would be weird enough, but the kicker is that if I take a second phone and put it in hotspot mode (running only over cellular network), and connect the Pixel 6 via WiFi to the hotspot (so ultimately I’m still using the cellular network!), it works every time.

So, the difference is whether ZeroTier is communicating directly with the underlying cellular network or over WiFi and it doesn’t behave identically in those circumstances. But, it’s not a “connection” issue, since I can ping and exchange network packets without any other issue, only the TLS handshake.

Does this sound familiar to anyone?

I’m having exactly the same issue. On my Pixel 5, WiFi+ZeroTier works just fine. When I disable WiFi and fallback to Google Fi, I start experiencing this issue. Same as you, pinging other hosts by their ZeroTier IP works fine. I can also access HTTP websites on those hosts; however, HTTPS endpoints are problematic and won’t load.

This used to work perfectly, so either a semi-recent upgrade to ZeroTier on Android (or Linux?), or something deeper in Android messed this up. Very frustrating. Even more so because the TLS handshake fully starts, and many packets are exchanged, then it fails and times out. Truly hard to imagine what’s going on/wrong here…

After a little more searching, this seems to be another instance of the MTU issue.

I lowered the network-wide MTU (to 1280) per instructions in Make MTU configurable · Issue #74 · zerotier/ZeroTierOne · GitHub and I stopped having connection issues with my HTTPS service. I presume my 56 byte ping and HTTP services worked because the packets were smaller.

Does ZeroTier have any documentation about MTU? Ideally we don’t touch MTU at all.

Thanks for this! Early on in my troubles, I was working with the author of the email program I use on Android (which was failing to do the handshake). He suggested it was an MTU issue, and I tried a variety of things that appeared to lower the MTU but the problems persisted.

I’m now convinced that it is indeed an MTU issue, but I’ll have to do a few more experiments to see if I can actually set it in a way that works consistently for me.

Unfortunately, 99% of the time, I’m accessing my ZT network through WiFi and have no issues at all, so this is particularly annoying since it doesn’t affect me often enough to degrade the rest of my experience (other than being sure that I can use the network when on cell service).

Again, thanks for your response!

I just did the ping test from the article you pointed me to when connected to ZT through T-Mobile. The largest MTU that works is 1328 (1300 packet size + the header). Anything above that I get 100% packet loss. That explains the handshake failure.

Now, it’s my understanding that I can’t change the MTU on Android without being rooted. So, the question is whether the ZT app can be made to change it on their own (which I imagine they can).

I tried (a while ago) to change it on the server side, and it showed the change in the network settings, but it still didn’t work on the phone. I assumed that whichever was smaller would rule. Now I’m wondering whether I just didn’t set it small enough!

Nope. I just set the server side to 1328. When I run MTU Path Len test on Ping&Net (Android), it still shows 2800 as the MTU between the devices (and the larger ping tests still fail), so Android is not lowering the MTU to match the server side… :frowning:

Did you disconnect and reconnect from the network after changing the MTU?

No. Here are some questions relating to that:

  1. Is it good enough to change the MTU with the ip command, or do I have to do the full “curl” thing with the API key, etc.?

  2. Is restarting ZT good enough, or do I really have to disconnect and reconnect from the network?

  3. Do I have to “unjoin” and “rejoin” (and possibly reauthorize), or simply disconnect?

  4. Is it good enough to make the change on the server (since that’s much easier than doing it on the Android side)?

It feels like the order doesn’t make sense. If you restart, the MTU goes back to default (at least that’s my understanding). And, if do the curl thing, you have to use the API key, and I assume be connected to the network, but if you then have to restart or disconnect and reconnect, then doesn’t that reset the MTU?

I’m sure I’m missing something, but it feels reasonably convoluted…

Thanks in advance!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.