Is the suspension a bug, or rather a badly implemented power-saving feature? The default setting for that USB power control is “auto”, which sounds as though the power should come on when needed. Evidently it doesn’t reliably do so, and your fix does put a stop to the modem suspensions.
Should the developers look at making the auto setting more reliable? It seems a good idea to shut off the power when it is not needed, but obviously it should also turn on again at the right time.
SMS was unreliable for me for a while, but now works great.
MMS still does not seem 100% reliable.
LTE is requires a workaround to work reliably. It will disconnect multiple times per day for me and I need to manually switch the modem off and on (via hardware kill switches) to get it to work again. But, after doing this whenever I have any internet issue I have no trouble using its internet all day all across the greater Los Angeles area, other than the very annoying periodic restarts needed.
Edit: Looks like @Aberts10 has a fix in this very thread!
Now I just need to figure out how to set up the cron job to run this upon reboot rather than needing to manually run echo 'on' > /sys/bus/usb/devices/1-1.2/power/control as root…
cron supports the special string @reboot instead of the first five fields.
I was mistaken in posting about a test which seemed to be successful but now I find to be otherwise. This post is withdrawn in its entirety.
Right this way?
login as root and modify crontab to:
@reboot echo ‘on’ | /usr/bin/tee /sys/bus/usb/devices/1-1.2/power/control
The crontab entry does not work, not even it does work on shell:
purism@pureos:~$ echo ‘on’ | sudo /usr/bin/tee /sys/bus/usb/devices/1-1.2/power/control
‘on’
/usr/bin/tee: /sys/bus/usb/devices/1-1.2/power/control: Invalid argument
Any ideas?
On the shell I nailed it down: the ' chars have been due to cut and paste some UTF-8 chars.
and specifically should not turn off while any data modem is supposedly turned on, even if there is momentarily no modem activity.
For root the crontab entry does not get executed. Don’t know why.
Running any cron job for user root gives in ´/var/log/syslog`:
Feb 18 16:47:01 pureos cron[488]: (*system*) RELOAD (/etc/crontab)
Feb 18 16:47:01 pureos CRON[5410]: Authentication failure
Feb 18 16:47:01 pureos cron[5410]: Authentication failure
which must have todo with root somehow being locked on the L5.
@dos, any idea how to make this working?
In another thread, there are strongly expressed opinions in both directions on the question of root account expiry. (Opinions are based on security on one side versus user freedom on the other.) The expiry date can be changed with the chage command (not a typo).
Setting expiry to tomorrow’s date, I rebooted and the cron job worked, i.e. the USB power control was ‘on’ rather than ‘auto’ after reboot.
Aside from the security aspect of non-expiring root account, there is the question of battery consumption if USB power is on by default even when no internet connection is in use. On an L5 turned on but doing nothing except waiting for calls or texts to come in, and starting at a battery level of 85% in both cases, the battery level dropped in 30 minutes to 81% with ‘auto’ USB, whereas it went to 79% with ‘on’ USB.
[EDIT 16:50 EST 20240218: The other thing that bothers me about enabling the root account is that there are four root commands already in /etc/crontab. They seem to be something to do with testing the device before shipping (and presumably before the root account was disabled). Since the device is shipped with those commands apparently not to be run, it might seem that they should be commented out by anyone who re-enables the root account. However, I just don’t know enough to be sure that it is appropriate either to let them run or to comment them out.]
This is a user+Discourse problem. The problem is that if you post code without enclosing in backquote characters then you can get all sorts of fancy “nicer” Unicode characters (in this case “smart quotes”), which of course won’t work in shell.
@reboot echo ‘on’ | /usr/bin/tee /sys/bus/usb/devices/1-1.2/power/control
v
@reboot echo 'on' | /usr/bin/tee /sys/bus/usb/devices/1-1.2/power/control
I didn’t check the details but maybe this: Expired root account
This behaviour of Purism is not understandable. How can they talk about freedom of choice and all other thinks of an unindependent system and the cripple the Debian base in such a way?
For me there is a Debian fork on the L5 and no clean Debian because Purism has done such “specialities”
It is MY phone and only I decide how the settings are. Such an behaviour let me stop all activities on MacOS, iOS and systems like that years ago. I have absolutely no understanding in “WE decide what You want” thinking.
So I set the expiry date for the root account to the year 2030 with chage and set all other passwords in the system to passwords and password lenghts and expiry dates I prefer 
Now " @reboot echo 'on' | /usr/bin/tee /sys/bus/usb/devices/1-1.2/power/control" works as expected
For me the crontab of root and my user was clean. Maybe it was flashed to standard from the pre-owner of the phone?
I’ve not posted this original code, but was a victim of it 
There is another hint about to work against the shutdown of the modem in Data connection lost (since kernel update to 6.6?)
Maybe it’s an idea to test this instead of avoiding the suspend of the modem in general (not yet tested by me).
Thank you very much for this link, from which this further link can be followed.
It’s a very interesting discussion, showing that the Pureos people are not only aware of the problem but might be working to resolve it.
Particularly interesting is the snippet of information that the delay from inactivity to suspension of the USB power was reduced from 2 seconds to half a second in the kernel update 6.6. This goes along with all our experience that the data connections used to be more reliable. I have increased the delay to 1.5 seconds on my L5, using a cron job based on the command in Elias Rudberg’s long post.
(To make this work, I have set the root account to expire in a few months’ time, in the hope that a kernel solution will be in place by that time.)
I had been looking at various other ways to keep the USB active when needed but not otherwise, such as plugging in a USB device with a very tiny LED light (picture below, and it did actually work). The longer delay setting is a better approach, and I have given up the other efforts.
Ive found a longer delay does not help after a while, it just takes longer for the issue too happen. If you want it to be reliable unfortunately the only option is to completely disable modem USB suspension.
I have 100% perfectly working modem experience.
What cellular provider do you use?
