Great, looking at the build date solves the problem for me. I had actually run uname -a before and after reboot but it didn’t occur to me to look at the date. Now I see the difference there.
Before reboot:
purism@pureos:~$ uname -a
Linux pureos 5.11.0-1-librem5 #1 SMP PREEMPT Wed Mar 17 02:15:51 PDT 2021 aarch64 GNU/Linux
After reboot:
purism@pureos:~$ uname -a
Linux pureos 5.11.0-1-librem5 #1 SMP PREEMPT Tue Mar 23 15:28:50 PDT 2021 aarch64 GNU/Linux
Thanks again for your help. I’m learning a lot on this forum today, as usual.
While we are discussing this kind of issue, I notice that the notes for the update (that it invites me to read each time) are always content free:
Includes performance, stability and security improvements
(This is using the GUI to update.)
I understand that noone wants to devote Purism resources to writing actual release notes. That’s fine. So would it be possible instead to generate release notes automatically with just the updated package versions (although in this case it would seemingly have to specify the build date)?
I have no performance data to share but one thing I have noted is the following.
There is a place in the house where the charger is.
When I first received the Librem 5 it was possible to put the phone on charge but still work away remotely on it (sshed in).
In the last few weeks that is no longer possible. In the same place in the house the Librem 5 will lose WiFi signal. (This is 5 GHz only. The 2.4 GHz SSID is not even configured in the phone. There is only one WAP.)
Coincidence? Maybe. Of course I will claim that nothing else has changed.
Apart from this, I don’t have any WiFi reliability problems. When the phone is closer to the WAP, the connection is stable.
Are there any settings here that might be relevant? Some trade-off that has been made in the settings?
I don’t think that it is (directly) related to power saving mode.
I can walk to the charging station, pinging continuously, and watch the RSSI icon at the top of the screen reduce and die, and watch the pings go from working to “Destination Host Unreachable” to “Network is unreachable”.
I can walk to the charging station, scanning the actual RSSI number continuously, and watch it progressively lower until, apparently, the signal is no longer viable.
Doing either of those things should keep the WiFi card and other relevant components from power saving.
I can accept that perhaps the signal at the charging station was always marginal but it does seem as if it has become weaker.
A theory about this: it could be that the signal in that place is weak for certain frequency band(s) but not for others. Then, it could be that the change you have noticed is due to a change in the frequency band(s) being used, for whatever reason that may happen. Anyway, in that case it does not necessarily indicate any new bug or so, if it just selects a different band/channel now. This command can be used to show which channel is currently used:
iw dev
You could check that when doing tests, then maybe you could find that performance is bad at a certain location when a certain band is used, but not when another band is used. Maybe. Just speculating.
It would be great if there was some way to get some kind of diagnostics info about how the wifi is working.
OK. Another theory then: maybe your next door neighbors turned on a new gadget they have that interferes with your wifi in certain locations?
For the sake of troubleshooting it would probably be best to live alone far away from civilization, with no other radio waves than those from the WAP and the L5.
Fair theory. For sure no spurious SSIDs show up (e.g. with the above scan or with the same scan on any other WiFi-capable device) but I probably can’t rule out a gadget that nukes the 5 GHz band with non-WiFi traffic, whether that’s one of my gadgets or a neighbour’s gadget with a high-gain antenna.
I don’t know exactly what the sources of interference in the 5 GHz band are. In the 2.4 GHz band, it’s for example leaky microwave ovens and cordless phones that are using that band.
Another awkward fact: The Librem 5 is back working again for access via WiFi while at the charging station. (This kind of intermittency is consistent with noise, rather than a signal problem. It remains to be seen whether intermittency occurs again.)
I did apply some updates this morning. Did it make a difference? Anyone’s guess … The investigation continues …
There are so many parameters affecting Wifi. Maby we should specify one or more standard test scenarios and put together a script that collects information by running some tools and log them with date and time. This would give us a systematic procedure and comparable results. At least more than with unsystematic modus operandi.
Why too many troubles with Librem 5 Wlan? I using my Evergreen everyday and i do not having any troubles with wifi 5Ghz or 2.4Ghz. Librem 5 just support 802.11n-5-2.4Ghz so maybe you need to config your router to run only with 802.11n to prevent conflicts.
Actually only thing that I want to point out here is to try not to experiment further with low quality chargers (if so) that might easily interfere (this or that way) with …
@irvinewade, just another “thought” of mine (that might help? or not).
irvinewade mentioned 5 Ghz. Personally, I run 2.4 Ghz for better coverage through walls. Some say that using 2.4 only saves on power. I use automatic channel selection on my AP, but I guess setting to the upper channel would be best for avoiding USB 3 interference. I was reminded of this:
I wonder if the Librem 5’s internal display has any impact on WiFi as well, and would some resolutions on an external display have an effect.
It would be nice to have a phone friendly SDR app (maybe a RTL-SDR can run from the Librem 5?) to help hunt down WiFi problems. A directional antenna would probably be more effective for locating.
Certainly a good suggestion (@Quarnero) but that can’t be the case. Merely walking the phone to the charging station and putting the phone on the table in the general vicinity of the chargers has the effect of causing WiFi to drop out - long before I get to switch on the Purism-supplied USB-C charger and/or connect the charger to the Librem 5. To be clear: all of the chargers are switched off (at the wall). Nothing is connected to anything.
If it hadn’t been working previously, I would just put it down to “too far away from the WAP”.
I may eventually have to do that. (Or get my dock working so that I can charge and use GbE at the same time.)
That would be harder to test as I am walking-and-pinging in order to test, and looking at the screen to see when it fails.
I did look at doing that at one time (about something else) but the process seemed too intimidating e.g. I don’t know what component I should be filing against. In some respects it would be better to have a front end system where rank amateurs get to file problems (described to the best of their ability), problems get triaged, and then only things that pass muster get properly categorised and filed in the real issue tracking system.
I also figured that you already have more than enough things to work on that you do know about - without nitpicking from me about the message that the GUI updater gives.
Strange. What I know about radio signals is that they do strange and unintuitive things. Like sound, signals can travel through things and bounce off of things. While the access point might be somewhat good at being unidirectional, the smartphone antenna probably is not. A slight difference in orientation could put a signal above or below the noise floor when the signal is weak. Although less likely to the be case, it could be that before, the signal bounced off of something, like an object in the room, and now that object is in a different position. Or instead of reflecting signal, something is reflecting noise into the location. Also, another appliance could be putting out noise, and it does not necessary have to be close by or in the same room, depending on how much noise it is putting off and how narrow of a focus it has in that direction. Also, your access point might be changing channels based on what it senses as a clear channel. But the clarity of that frequency near where the phone is could be very different. That is where a SDR near the phone’s location could come in handy, or just experiment. You could try logging into the AP and selecting a different channel, especially if it is on automatic. The frequency might also affect where the signal’s peaks and troughs are located in the building, although that might only be a practical concern for the longer frequencies. Changing the orientation of the AP, or its antennas (if they are not fixed), might also do something. It will be small effect, but when the signal is at the threshold, it could make a difference.
This is where general OS issues will be tracked for the Librem 5 project. It is a catch-all for issues that do not have a place in specific application/project repositories or Apps_issues.
Also, if you happen to file it in the wrong place, don’t worry, someone will most likely help by moving your issue to the right place. I think the gitlab system that they use has a built-in way of moving issues, for exactly this reason, it is common that it turns out the issue should be under another project.
The channel is fixed (not auto) and hasn’t changed. The WAP is ceiling mounted and hasn’t moved. The WAP’s antennae are internal and haven’t moved.
Maybe the signal (or noise) was bouncing off something that has moved. Always hard to pin everything down. You are also right about the orientation of the phone. I can’t control that precisely.
