Oh yeah that is a good trick. Even toggling the roaming data seems to help too.
Sadly, I think I spoke too soon because now my phone is back getting confused on 4G and sometimes showing 2G. Maybe it’s something location specific and it will get happier when I head to the office tomorrow.
It’s a known issue and there are several threads here that report this issue.
It’s being investigated by support (at least I think it is).
Just take a look at is-there-still-no-cure-for-the-no-wwan-adapter-problem or no-mobile-connection-with-librem-5
Hey, sadly this isn’t the same issue, because I have a pretty good work around for that one where the modem just totally goes away. This one is new to me. It’s like the modem can’t keep the LTE connection. I’ll see it fine 4G with IPv6 and then come back a few minutes later and IP address is gone and it complains about not being able to activate the connection or QMI aborts or the mobile network codes aren’t right or the operator id isn’t and then goes to 2G and gets an IPv4 and is able to make terrible calls (audio quality is terrible) and then a little bit later no IP at all and getting warmer and warmer so it’s trying to do something.
Because I had to get back to normal I put SIM back in iPhone, but my backup number SIM did the same thing in Librem. I was kind of hoping it might have been something where the number needed to be in official device to get full LTE access.
I know I am rambling, but so frustrating because I was having a good run and almost had most of the bugs worked out and was using nexdock a lot and was aiming local first with calendar and files and that certainly doesn’t switch back to iPhone well.
all the Apple people look at my list of markdown files with pure disbelief and want me to go outside
That seems indeed to be a different issue.
Have you reported this to support?
In this listing ( Modem usb periodic disconnects/resets (#303) · Issues · Librem5 / linux · GitLab (puri.sm) there is a solution that disables the modem’s power management was said to solve a lot of the problems seen with the modem dropping out in use.
Disabling PM on the modem seems to “resolve” this. No more usb device resets in dmesg, and the modem hasn’t disappeared in several days despite moving around to different cell areas.
Truly, what I have noticed is under Gnome settings power management is enabled for the modem, and when you try to disable it through the level switch the modem is just turned off. This means that you have no way via the GUI to disable power management on the modem.
So what is being listed here is one solution. However, that no one mentions if this is a solution later or not is worrying, and specifically frustrating. WHY has there not been any attention given to this possible solution?
I would rather have a modem that works reliably for an hour of use, then one that is CONSTANTLY dropping during use.
Following through to look at Postmarket OSes use of the proposed solutions sees that it has been merged and they are using it, noting that it works at the expensive of slightly more power usage which no one has been able to appreciate at this point.
So my question dear savy Linux users is this:
How can I use this:
Author: Clayton Craft <clayton@craftyguy.net>
Date: Thu Jun 17 16:59:55 2021 -0700
librem5-pm.udev: disable PM for broadmobi modem
Workaround for https://source.puri.sm/Librem5/linux-next/-/issues/303
diff --git a/debian/librem5-base-defaults.librem5-pm.udev b/debian/librem5-base-defaults.librem5-pm.udev
index dc005bb..6abdb10 100644
--- a/debian/librem5-base-defaults.librem5-pm.udev
+++ b/debian/librem5-base-defaults.librem5-pm.udev
@@ -9,7 +9,7 @@ DEVPATH=="/devices/platform/soc@0/38100000.usb", TEST=="power/control", ATTR{pow
### Enable power management for internal USB devices:
# Broadmobi BM818
-SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/control", ATTR{power/control}="auto"
+SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/control", ATTR{power/control}="on"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/autosuspend_delay_ms", ATTR{power/autosuspend_delay_ms}="2000"
# Cinterion PLS8
to change the power management settings of the cellular modem on my L5.
Thank you very much in advance!
Disabelling PM will/may result in overheating the L5, as explained in that same article. That might be an explanation for not recommending this work around.
I would like to know where most of the challenges with the modem performance lie. Is it
Then folks running PM OS using the L5 would have reported that, and it would have been removed from their changes. So, I don’t see overheating as a real concern.
OK, so for you this is no big concern, for others it is 
I would like to see this issue being solved too, but I’m OK with their approach to find the root cause and fix it there instead of rolling out a work around that might or might not cause side effects. But that’s just my point of view. 
I think the modem dropping out is a big deal. If turning off PM is a solution that works, then I am all for this. Especially if the power savings we are talking about is a mere 15 minutes or so. With the finite amount of resources at Purism’s disposal for continued L5 development this is low hanging fruit that improves general usage.
purism@pureos:~$ sudo cp /usr/lib/udev/rules.d/85-librem5-pm.rules /etc/udev/rules.d/
[sudo] Passwort für purism:
purism@pureos:~$ sudo vi /etc/udev/rules.d/85-librem5-pm.rules
Copy the packaged version to your /etc/udev/rules/.d directory and edit it.
Use the cursor keys to move the cursor onto the leading S of the following SUBSYSTEM-lines, press i for insert mode and prepand the lines with # to comment them out. Press two times ESC to leave insert mode, type :wq and enter. This should save your changes and leave the editor vi.
This is the section before editing it:
# Broadmobi BM818
SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/control", ATTR{power/control}="auto"
SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/autosuspend_delay_ms", ATTR{power/autosuspend_delay_ms}="2000"
And this is how it should look afterwards:
# Broadmobi BM818
# SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/control", ATTR{power/control}="auto"
# SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/autosuspend_delay_ms", ATTR{power/autosuspend_delay_ms}="2000"
You can check the content by typing cat /etc/udev/rules.d/85-librem5-pm.rules.
Reload the udev-rules:
purism@pureos:~$ sudo udevadm control -R
Switch of the modem, wait, switch it on again.
purism@pureos:~$ echo 0 | sudo tee /sys/class/leds/wwan_en/brightness; sleep 5; echo 1 | sudo tee /sys/class/leds/wwan_en/brightness
0
1
To revert to power management for the modem you’d need to delete the copied file sudo rm /etc/udev/rules.d/85-librem5-pm.rules and repeat the steps to update udev via udevadm and restart the modem by cutting its power for a few seconds.
Thanks ChriChri, but one error in your excellent write up here, is that the changes to the pm.rules had no changes. “auto” was the only thing needing to be changed. It should be changed to “on”. The rest did the trick! Thank you, and thank you for helping me better understand the file structure relevant to the PM subsystem in Linux. 
I am curious if disabling PM on the modem messes with things during suspend? Does this particular PM only pertain to normal running status or is it used in alternate run states of the SoC also?
Maybe I misunderstand what you mean, but my understanding for the mentioned patch has been that the default value for power management is that it is not active and therefor the disabling of the rules that enable it are enough.
Commenting those rules out is what the patch does and what I tried to describe with
Or did you mean a different aspect of what I described?
Ahh yes, I see, but what I saw in the source was that “auto” was changed to “on” and I thought this was the change necessary.
Because of this from the source patch:
# Broadmobi BM818 -SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/control", ATTR{power/control}="auto" +SUBSYSTEM=="usb", ATTRS{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/control", ATTR{power/control}="on"
This explains it. I used Martin Kepplings note as referenced ignoring part of your original question… 
Isn’t that exactly what happened though? pmOS has reverted their changes to disable PM months ago.
It cuts almost one third of idle battery time out, so we’re talking about hours.
I am happy to see some discussion on this issue that shows they are making progress. Seems the suspending of components and resuming is the issue, ONLY if the suspending process is not successfully completed.
I have a script running automatically to reset the modem when it notices that it drops, but it isn’t super reliable. So I am using the following command to do it manually. This seems to work better anyway.
echo 0 | sudo tee /sys/class/leds/wwan_en/brightness; sleep 5; echo 1 | sudo tee /sys/class/leds/wwan_en/brightness
At this point I wish my issue was connected to power management, but starting up fresh it can’t even get on the LTE network happy and it was running really well for almost 2 months?
The lines that have to be a hint are:
[modem1] 3GPP registration state changed (home -> searching)
[modem1] couldn't load operator code: Current operator MCC/MNC is still unknown
[modem1] couldn't load operator name: Current operator id is still unknown
I guess I’ll write support tomorrow about this.
I am reposting this question as I did not get any response earlier.