PINE64
To live and die on LTE (with a Pinephone) - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120)
+--- Forum: General Discussion on PinePhone (https://forum.pine64.org/forumdisplay.php?fid=127)
+--- Thread: To live and die on LTE (with a Pinephone) (/showthread.php?tid=16980)



To live and die on LTE (with a Pinephone) - robthebold - 07-08-2022

Well, that sounds dramatic, but here in the US 2g and 3g service is all but gone with T-Mo dropping the last (maybe . . . mostly . . .) of theirs last week and ATT's going offline last February. As far as the rest of the world, YMMV, but if GSM and 3g are set to be phased out where you communicate this might be interesting.

I've been spending a lot of time trying to figure out why (and when) my pinephone stops receiving calls. I found this thread which provides an interesting "watchdog" work-around for the pinephone modem falling into a coma and never waking up again. User @kebab (thanks, kebab!) describes using the modem manager to reset the modem and bring it back to life. Unfortunately, that never worked for me Sad . . . but it can sometimes fix two other issues that will knock the pinephone offline on my all-LTE network.

kebab's service checks the results of mmcli -m any for the phrase "No modems were found" and calls for an eg25-manager restart (using the appropriate system service manager for your OS. This problem -- the modem not waking up -- will definitely interrupt your service regardless of location, technology or network provider. However, I found my device not working at other times too, and I started logging the output of mmcli
Code:
mmcli -m any >> log.txt

I found at least 2 other problems that can break LTE silently resulting in a phone that won't be receiving calls or texts without the user even knowing it. In both cases, the problem can be detected in the output of mmcli. I'll quote the relevant sections as I describe the issues I've found.

Problem 1: Status
Code:
  Status  |                    lock: sim-pin2
          |          unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), sim-puk2 (10)
          |                  state: connected
          |            power state: on
          |            access tech: lte
          |          signal quality: 59% (cached)

When everything's OK, the line containing "access tech: lte" is present. If grepping for this term in the output of "mmcli -m any" fails, the device cannot make or receive calls or texts. This problem sometimes gets better on its own. Sad  But sometimes it doesn't either. Sad Using the appropriate service manager to restart eg25-manager usually fixes the problem. BTW, the modem will come back with a new index number. When it gets better either due to eg25-manager restart, a phone reset or just on its own, the "access tech: lte" line reappears in the mmcli output.

Problem 2: Modes

When things are working (and problem 1 has been ruled out) I check the Modes section. I see this when things are working properly.

Code:
  Modes    |              supported: allowed: 2g; preferred: none
          |                          allowed: 3g; preferred: none
          |                          allowed: 4g; preferred: none
          |                          allowed: 2g, 3g; preferred: 3g
          |                          allowed: 2g, 3g; preferred: 2g
          |                          allowed: 2g, 4g; preferred: 4g
          |                          allowed: 2g, 4g; preferred: 2g
          |                          allowed: 3g, 4g; preferred: 4g
          |                          allowed: 3g, 4g; preferred: 3g
          |                          allowed: 2g, 3g, 4g; preferred: 4g
          |                          allowed: 2g, 3g, 4g; preferred: 3g
          |                          allowed: 2g, 3g, 4g; preferred: 2g
          |                current: allowed: 4g; preferred: none
It took me forever to find it, but when I got a call on another phone to tell me I wasn't answering, I quickly logged the mmcli output:

Code:
  Modes    |              supported: allowed: 2g; preferred: none
          |                          allowed: 3g; preferred: none
          |                          allowed: 4g; preferred: none
          |                          allowed: 2g, 3g; preferred: 3g
          |                          allowed: 2g, 3g; preferred: 2g
          |                          allowed: 2g, 4g; preferred: 4g
          |                          allowed: 2g, 4g; preferred: 2g
          |                          allowed: 3g, 4g; preferred: 4g
          |                          allowed: 3g, 4g; preferred: 3g
          |                          allowed: 2g, 3g, 4g; preferred: 4g
          |                          allowed: 2g, 3g, 4g; preferred: 3g
          |                          allowed: 2g, 3g, 4g; preferred: 2g
          |                current: allowed: 2g, 3g, 4g; preferred: 4g
There it is the the "current:" line of the "Modes" section. LTE working ok and calls going thru I see "current: allowed: 4g; preferred: none".
OTOH, when calls and texts aren't working (even if the "access" issue above is fine) I see "current: allowed: 2g, 3g, 4g; preferred: 4g". The same status can be seen in the GUI "System|Mobile Network"

Doing an eg25-manager restart did restore service, but the current Mode setting remained "current: allowed: 2g, 3g, 4g;" until I went in and manually changed the setting in the GUI. I haven't tried changing the setting with mmcli, and don't know if I can or not.

Anyway, if anyone has any extra insights on this issue, I'd love to hear about it.


RE: To live and die on LTE (with a Pinephone) - zetabeta - 07-08-2022

for that first i recommend to test changing usb settings for eg25-g.

Code:
/usr/lib/udev/rules.d/80-modem-eg25.rules

ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ATTR{power/control}="on"

link:
https://github.com/Biktorgj/pinephone_modem_sdk/blob/kirkstone/docs/SETTINGS.md

if biktorgj is recommending this, it tells a hint. (although for pinephone sdk, i recommend for both stock and pinephone sdk). this fixes constant modem disappearings and occasional die outs.

i use lte (4g) only mode almost all times. some special commands like call waiting commands and call divert commands does not work in lte (in most of a time), so i use older network technolgies some cases.


RE: To live and die on LTE (with a Pinephone) - robthebold - 07-08-2022

(07-08-2022, 10:58 AM)zetabeta Wrote: for that first i recommend to test changing usb settings for eg25-g.

Code:
/usr/lib/udev/rules.d/80-modem-eg25.rules

ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0125", ATTR{power/control}="on"

link:
https://github.com/Biktorgj/pinephone_modem_sdk/blob/kirkstone/docs/SETTINGS.md

if biktorgj is recommending this, it tells a hint. (although for pinephone sdk, i recommend for both stock and pinephone sdk). this fixes constant modem disappearings and occasional die outs.

i use lte (4g) only mode almost all times. some special commands like call waiting commands and call divert commands does not work in lte (in most of a time), so i use older network technolgies some cases.

I changed the modem settings when I first started investigating the issue. In retrospect, I wish I'd investigated a little more before making the change to get some hard data about "modem coma", but my feeling is it seems to happen less frequently with the change.  And missing fewer calls from my wife is pretty much the only goal. Wink (Although the "modem gone" audio warning at midnight last night wasn't such a good idea either . . .)

I use 4g only, since my network only supports 4g now. But when something happens, the setting gets changed automagically from "current: allowed: 4g; preferred: none" to "allowed: 2g, 3g, 4g; preferred: 4g" without me doing anything. And that seems to happen when phone service disappears -- which seems like a reasonable hypothesis. I'm still trying to figure out exactly what the something is, but now I have a script watching the config and logging unexpected changes and playing an audio file when that occurs.