Most https sites no longer work through wifi hotspot

I noticed a strange regression since a couple of weeks ago. Wondering if anyone else is seeing it and what might be the cause:

Most websites don’t work (unable to connect, specifically to complete TLS handshake) when I try to access them from a computer connecting to the Librem5 wi-fi hotspot (the Librem5 itself using a 4G connection). But all those sites load instantly when trying on the phone. When I was using it in July it was working fine…

Some websites like works fine. does not (curl’s last messages are client hello (1) followed by STATE: PROTOCONNECT). A website I need for work ( goes a little bit further (client and server hello, change cipher spec, then client and server hello (2), and hangs there).

How to troubleshoot this? It fails the same way no matter which computer connects to the hotspot (tried Windows, Linux and Android)

Packet length (MTU) issue?

Hi irvinewade, thanks for your message. I looked but I think not? ip link show on my computer connecting to the home wi-fi shows exactly the same as when connected to the Librem5 hotspot:

wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000

Running that command on the Librem 5 when it’s in hotspot mode shows:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 36:4f:fa:c6:6c:a8 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 88:da:1a:7c:75:6c brd ff:ff:ff:ff:ff:ff
4: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff
7: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1464 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 1000

To be honest I don’t understand all those keywords but I’m guessing the relevant part is mtu 1500 on the wlan0 line so the MTU should be ok I think?

This is a wireshark capture on the laptop doing curl Packet 155’s “previous segment not captured” seems to say something from the server is missing? (And packets 157 and later are probably not related, they happened four seconds later) :

Hum, so I reflashed my phone. And that did NOT fix the issue (I restored my home directory and reinstalled a couple applications that should not be doing anything related to networking).

So I decided to be a good linux user and find out how to configure connection sharing from the command line.

I found this tutorial.

Coup de théâtre! (how do we say that in English?) Before starting creation of a new connection profile I figured I’d try enabling the Hotspot using nmcli:

sudo nmcli connection up Hotspot

and everything is working as before! What is the GUI doing differently?

1 Like

Google Translate says: Spectacular turn of events!

Good work getting it going again. A really good Linux user would then dig into the code for the GUI to answer the final question. :wink:

Maybe “plot twist”?

Yes, “plot twist” sounds right. And turns out it was a double plot twist because it worked only once. I tried again last night, and this morning, and it no longer works :sob:

Sometimes I’m tired of shit that just won’t work. Since reflashing I can’t connect to Signal anymore (Not getting verification code with Axolotl, and signald-purple is not recognised by Chatty). And I can’t report issues to Purism because they don’t let people create accounts on their Gitlab instance. /rant

You can, but you have to email support first and request it. They do that to mitigate spam.

Assuming that it’s the same issue as you initially posted, then it does appear most likely to be an issue of packet size as @irvinewade suggested.

From the ip link show output from the phone the wwan interface has an MTU of 1464, from the wireshark capture the machine claims an MSS of 1460, you won’t get a 1460 byte payload packet through an interface with an MTU of 1464. The max packet size will have been negotiated down based on’s claimed MSS of 1440 but you still won’t get a 1440 byte payload packet through an interface with a MTU of 1464.

The quick workaround would be to clamp the MSS value to the PMTU value as it flows through the forwarding chain.

1 Like

My original post may have been too terse - and it is difficult to know what level of knowledge each forum participant has.

There are three numbers here relating to packet size and usually they will all be very roughly the same.

MTU = Maximum Transmission Unit - the largest packet that can be sent between adjacent IP hosts - I would expect it to be equal to the link layer frame size minus the link layer overheads

PMTU = Path MTU - the largest packet that can be sent between the source IP host and the destination IP host - I would expect it to be equal to the minimum over the path from source to destination of the individual MTU values

PMTUs are discovered (learned; and remembered) and in principle can change in the lifetime of a TCP connection (and presumably are intentionally forgotten after a while too i.e. expired).

I probably should actually have written PMTU rather than MTU in my original post.

MSS = Maximum Segment Size - the largest TCP payload that can be sent on the TCP connection - should be equal to the PMTU minus the IP and TCP overheads (NB: overheads will differ between IPv4 and IPv6, but we appear to be using only IPv4 here)

Because VPNs introduce extra overhead, and for related reasons, the above is a slight simplification if a VPN is involved. (Is a VPN involved?)

Normally all of this takes care of itself.

I’m not sure of the exact incantations for overriding the MSS value (and I didn’t read the above-linked tutorial and I don’t know precisely what commands you used to set up the hotspot) but this link gives two example commands, one for forcing MSS to a specific value (could be useful for confirming the fix, if chosen conservatively, but is inflexible and could in theory break) and one for forcing the MSS to the value calculated from the PMTU (a better long term choice).