REPRODUCIBILITY: happens regularly, but no clear reproducable conditions
OS VERSION: 22.214.171.124
HARDWARE: Xperia X 10 III
UI LANGUAGE: de
When sharing the mobile internet connection via WLAN, I’ve encountered several times that, judging by normal web browsing usage, the internet connection appears to be broken from the tethered device (e.g. laptop), while the same website is still accessible directly from the phone.
A further investigation revealed that on the tethered side, only sites with an encrypted connection are affected:
$ curl -4 -v https://orlives.de/
* Trying 126.96.36.199:443...
* Connected to orlives.de (188.8.131.52) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
curl -4 -v http://orlives.de/ still work fine, but TLS-encrypted curl calls always hang at the TLS client hello stage. At the same time, the https sites can still be opened directly from the phone.
Mobile tethering had worked sometimes before with the Xperia 10 III and continues to work again from time to time. I cannot recall that this issue happened with older Sailfish devices, but these of course also shipped with an older Sailfish release.
a mobile data connection and a Linux laptop for tethering.
Non-optimal connectivity situations might facilitate this issue to arise, I’ve mostly had that issue on train rides. But I’ve both encountered it with 4G and 2.5G connections.
- Open a mobile hotspot while connected to mobile data
- connect to that hotspot from a laptop via WLAN.
- Browse the internet. Once you notice that some https sites do not load anymore while the phone still shows mobile connectivity, compare the behaviour of
curl -4 -v http://orlives.de/and
curl -4 -v https://orlives.de/
Both curl calls shall successfully fetch an html document. Web browsing also works fine on https sites.
curl -4 -v http://orlives.de/ still successfully outputs a small html document,
curl -4 -v https://orlives.de/ blocks on the TLS client hello.
Chum, OpenRepos, but no deeply integrated system package changes or patches
I’ve logged the network packet flow via Wireshark. The broken https retrieval look very interesting, they always had a
[TCP Previous segment not captured], Continuation Data part like this:
The raw pcap capture files are available on request.
Role of MTU: One obvious difference between the two
curl calls is that the html document retreived via
curl -4 -v http://orlives.de/ is just a tiny html page with a redirect. That’s just a small amount of bytes.
The encrypted version already needs to build larger IP packets during the TLS handshake. So one thing that came to my mind was that somehow the MTU on the tethered device was configured incorrectly?
In one occasion, reducing the MTU from auto (1500 Bytes) to 1000 Bytes helped restore HTTPS connectivity. But this might as well have been a coincidence:
- right now I am writing this successfully again over a tethered connection with MTU auto (1500)
- in another occasion, I’ve played around with different ping package sizes like
ping 184.108.40.206 -s 1200, no clear picture arose from this.