I came across this while searching if a different issue regarding hotspot has already been filed and I'm now wondering if this can be closed?
The redpine in my L5 let's me connect one client and everything appears to be working just fine.
A forum member helped me workaround the issue. Running the following command on the Librem5 makes the Hotspot work normally. (The setting is lost after a reboot.)
sudo iptables-legacy -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
My problem was that my WWAN interface had an MTU of 1464 bytes, and the default MTU of the wireless interface (used by the Hotspot) is 1500 bytes, and it seems fragmentation-needed packets don't reach the phone. I don't know if it is an issue on the Librem5 or something my ISP is doing.
Should we close this ticket because I have a working workaround? Or might there still be a bug because the hotspot doesn't work when the WWAN MTU is less than 1500 bytes without running this command?
Hi, thank you for your reply!
All connections from the Librem5 work fine, whether the hotspot is enabled or not.
I don't have other SIM cards to try. However I'm going to check that the hotspot from an Android phone works, which would rule out the provider blocking some connections for whatever reason. I will also run tcpdump
from the Librem5 when attempting to connect from a hotspot client, and report back.
Strange. For me, Wifi Hotspot works fine on the Librem 5, I have used it many times.
A theory: it could be that your mobile provider is doing something unusual that triggers this problem. To check that, you could try with a different SIM card, from a different provider. (the behavior you see could be explained, maybe, if the provider has some limitation on the number of TCP connections to the same destination or something like that)
You could also look at the traffic to and from the Librem 5 by running tcpdump
or tshark
or similar on the Librem 5. Then you might see some ICMP error packets or something else that could give clues.
Regarding which websites work and which don't work: could it be that the ones that work are ones you did not yet try from the Librem 5 itself? Like, the first N connections to a given destination succeeds and later connections to that destination fail? I guess that could happen if there is a limit on the number of allowed connections.
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. The issue has been happening since August 2022. When I was using it in July 2022 it was working fine…
I am reporting this to the gnome-control-center
project because I saw other issues related to the Wi-Fi Hotspot here (although they are not the same issue, as I am able to connect to the hotspot and get an IP address). However it might not be the right project because the issue occurs if I use nmcli
to enable the hotspot. If that's the case, could you tell me which might be a more suitable project to report the issue?
Steps:
Expected Result:
it should load fine
Actual Result:
It starts the TLS handshake and then times out.
Additional Details:
Some websites like https://en.wikipedia.org works fine. https://puri.sm does not:
$ curl -v https://puri.sm/
* Trying 138.68.253.24:443...
* Connected to puri.sm (138.68.253.24) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL connection timeout
* Closing connection 0
curl: (28) SSL connection timeout
(about five minutes pass between that Client hello (1)
and the SSL connection timeout
).
Wireshark on my laptop shows the following when running that curl https://puri.sm
command:
It fails the same way no matter which computer connects to the hotspot (tried Windows, Linux and Android).
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
...
ip link show
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
link/none
A forums.puri.sm user said the computers trying to use the hotspot appear to fail calculating the PMTU properly. He said:
So you might wonder whether it’s the Librem 5 that is blocking (or, perhaps more accurately, failing to forward) the ICMP error packets.
Extremely rarely (I would say less than 1% of the times) it works, and then it works completely. All websites load fine. But then the next attempt (after a reconnect) fails.
I have reflashed my Librem5 to the stock image in hope to fix this issue, but it didn't improve things.
We do htis in phosh-mobile-settings, hence closing.
feedbackd learned how to manage per application feedback levels so we could make that configurable via the notifications tab as we do for the global level.
Related upstream issue https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/288
EDITed to have the right message for this bug
That's a valid reason to keep the page always available. Can you file an issue with upstream at https://gitlab.gnome.org/GNOME/gnome-control-center/?
@mohammed.sadiq it maybe the current design choice to check, but my opionin is not to hide any settings in the first place based on enabled or disabled module that exists in hardware.
Show wifi, bluetooth, and mobile data regardless if these modules are presently available.
Even on desktop i find it distracting that the wifi symbol disappears when disabling wifi. That is a gnome feature but i think a better approach is to show what exists (while not necessarily enabled) and limit functionality for these items accordingly (maybe grey out / disable certain buttons). If wifi is powered down and the user wants to delete a previously connected wifi network then that should be doable in software and the current UI gnome settings.
That feature should be enabled and exist even if wifi is off. Once the user turns wifi on it simply would not automatically connect to previously deleted wifi network if network is now in range - just to give you a simple use case.
I can make the same case for mobile data and bluetooth.
For bluetooth items previously connected but not in range it should show and allow deletion of previously paired devices and all related data, even with bluetooth off.
This is because gnome-control-center do some checks before showing the window. It checks if WiFi, Bluetooth, Modem hardware are available and usable (or not) before the window is shown so that it can decide whether these items should be shown in the items list when the window is presented.
We shall be able to reduce startup time once we have unified network page as in https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/network/network-wires.png (as we can defer the check until the user have switched to the network page)
Environment: posh 0.14.1, phosh 0.21.1, gnome 1:3.38+3, phoc 0.21.1.
What happens:
What it should be doing is launch gnome settings in <1 second so the user barely notices. the gnome settings app only displays text and it does seem much too slow displaying say 300kb of information in total, that should be possible in ms not seconds.
I am using phosh on Arch Linux for Arm on a Pinetab. In the settings, there is no option to change the primary button of an external mouse.
Hi,
based on #13 some panels of this fork have been hided because not useful/not working/not adapting.
I would like to ask if it is possible and if it is a good idea (maybe there is something that i have not considered) to re-enable the Background panel. Currently on gnome-control-center
version 3.38.2-r0
, the Background panel itself work and scale perfectly. Unfortunately the popup created by the "Add Picture" button do not scale perfectly (the image preview on the right is a bit truncated), but it is still usable and i'm able to add custom images anyway. Maybe if you prefer that everything accessible should work perfectly, an half way solution could be to enable the panel while disabling the add picture button, so that the user could at least select a background from default background folders. Since changing the background in other ways (like dconf) is unintuitive and error prone, this could be very useful.
I'm currently using a Pinephone PMOS Edge Phosh, so i have no right to make any kind of request here, so treat this post as a thought.
Thanks for your time and your effort in linux phones, Have a nice day!
Changed language from "unspecified" to "English" and was offered a "Restart" button that does not work.
"Restart..." does nothing
"Restart..." works "Restart the session for changes to take effect"
librem-5-chestnut-region-and-language-restart-fails-2020-01-12
purism@pureos:~$ uname -a
Linux pureos 5.3.0-librem5-h1 #1 SMP PREEMPT Tue Jan 7 10:16:00 CET 2020 aarch64 GNU/Linux
purism@pureos:~$ dpkg -s phosh | grep Version
Version: 0.1.6
purism@pureos:~$ dpkg -s gnome-control-center | grep Version
Version: 1:3.34.0.1+19975+gitf7dfd564f-1pureos0
purism@pureos:~$
Opening wired networks settings does not fit by default on the phone.
Tested on an updated Byzantium image.
This is not the case for me, so maybe this issue was solved in the meantime and can be closed. I did a cold boot with all HKSs off, went to the g-c-c Bluetooth panel and then turned on the Bluetooth HKS, which resulted in the panel updating properly.