sms is quietly dropped under crust

As reported by sircmpwn, sms texts are dropped while the phone is in crust and there is no notification or anything in the log. Toggling the modemmonitor does not help.


Assigned to
1 year, 1 month ago
15 days ago

~proycon 1 year, 1 month ago

~proycon 1 year, 1 month ago

They're not really dropped but they will not come in as they should. This is still an issue in 1.4.1, a rough workaround is to run sudo rc-service modemmanager restart

Hopefully we can get this fixed soon because it's a real show-stopper.

~franck_stauffer 1 year, 1 month ago

As a temporary fix, is it a good idea to add rc-service modemmanager restart as a postwake default_hook?

~proycon 1 year, 1 month ago

On 21-04-01 07:56, ~franck_stauffer wrote:

As a temporary fix, is it a good idea to add rc-service modemmanager restart as a postwake default_hook?

No, because if you get an incoming call and wake up from sleep, it would ruin it and you'd miss it.


Maarten van Gompel (proycon) https://proycon.anaproy.nl

~franck_stauffer 1 year, 1 month ago

Ah yep didn't think about that, thank you

~murks 10 months ago*

I just noticed the same. What is even weirder is that after restarting the modemmanager the entire contact list flashes on screen as part of the notification.

On top of that I have SMS that are literaly shown empty:

Received from  at  :

~murks 10 months ago

I'm kinda crap with shell scripting but if I look at sxmo_modemmonitor.sh checkfornewtexts() it seems that $NUM, $TIME and $TEXT were empty because $TEXTDATA was empty. I think $TEXTID could not have been empty because otherwise the loop would not have been entered. Consequently the problem would be with the line:

TEXTDATA="$(mmcli -m "$(modem_n)" -s "$TEXTID" -K)"

Btw. is this the intended quotation? Let me split it up to make clear what I mean:

TEXTDATA="$(mmcli -m "    $(modem_n)    " -s "    $TEXTID    " -K)"

Some other instances are quoted as "$(modem_n)" and "$TEXTID". I have no clue whether the bug could be related to that, but it looks like a potential issue to me. Don't take my word for it, I suck at shell scripting :]

Also is modem_n() even returning anything? Looks to me as if it isn't, but maybe I misread that. I hope this helps.

~murks referenced this from #314 10 months ago

~kavuskazian referenced this from #314 10 months ago

~stacyharper 10 months ago

TEXTDATA="$(mmcli -m "    $(modem_n)    " -s "    $TEXTID    " 


Some other instances are quoted as "$(modem_n)" and "$TEXTID". I have no clue whether the bug could be related to that, but it looks like a potential issue to me. Don't take my word for it, I suck at shell scripting :]

Aha np :D but I think this line is right of very probably not related with this issue. Shell can look crazy in the first look ya. The command line is not parsed like every other languages.

~murks 10 months ago

I mean if I understand that correctly the quotation in this file at least is totally inconsistent. As an example, sometimes $TEXTID is quoted, sometimes, like in this line, it is not. Same for a bunch of other variables. I only stumbled upon that thanks to vis syntax highlighting. Some instances of the variables were white, others red because it matches pairs of quotation marks.

I do not think that you can nest double quotes, not even in shell scripting.

Whether that is the actual issue I do not know. I will try to find some time to fix the quotation and test it.

~noneofyourbusiness 10 months ago

Iirc this patch solves the problem? if not, make sure to correct me. https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/356 someone still needs to look at that log that was posted

~fjc 10 months ago*

(Are any of the "supported" devices multi-modem? If not, -m any is simpler (but doesn't address waiting for the modem to come available).)

Btw. is this the intended quotation? I do not think that you can nest double quotes, not even in shell scripting.

Yes, that quoted example quoting is valid due the nesting being in $(). https://unix.stackexchange.com/a/118438

~murks 10 months ago

Thanks for the explanation, I see now how the quoting works (but I'll need to read up more on that anyway).

Looks like that ModemManager patch is waiting for review by now, since a month. Is there anything we can do to move that forward?

~noneofyourbusiness 10 months ago

Nope, but the actual commit that adds the stuff required (according to dylan) is in master (I've checked).

~kavuskazian 9 months ago

It seems this is still happening in the new 1.5.0 version of SXMO. As a possible workaround, is there a way to detect that the phone woke up due to modem but there's no incoming call, and then put it back to sleep? Otherwise after receiving a text, it stays awake in my pocket.

~stacyharper 9 months ago

Yes I know this issue. My best hope still is that modemmanager will eventually work as expected some day :(

Having a watchdog is difficult without breaking the workflow when modemmanager works. Maybe the best idea would be to find a way to auto-suspend the system after some inactivity.

~murks 9 months ago

I had the same though regarding a workaround as that SMS problem is annoying. When waking up, somehow check whether a call is incoming. If not, restart the modem. So I guess the question is whether we can check for an incoming.

~murks 8 months ago

It seems now there is a script that runs under some conditions that is supposed to work around this issue. That script seems to be "sxmo_modemmonitortoggle.sh reset". However, that particular functionality seems to be broken and does not start the modem again.

In my experience it is sufficient to call "rc-service modemmanager restart" to receive the SMS. It would be nice to call that instead from wherever the broken "reset script" is called currently.

~kavuskazian 8 months ago

I think that may be a deeper problem, as the modem vanishes from lsusb entirely when that happens.

~stacyharper 8 months ago

I refactorised this modemmonitortoggle script today. It should now be bullet proof.

It will eventually notify you with a critical notification that you may need a reboot if it didnt succeed rocketing back the modem monitor.

We already know there is issue with the ModemManager and eg25-manager reliability. We already know that atm, sometime, you have to reboot your phone.

It is not a Sxmo issue.

We are all waiting for 1.8.0 that will very probably embed the last patches from Dylan to use QMI and AT to catch sms and call while leaving crust. I also hope that this 1.8.0 will bring more stability on this modem part.

If you want to debate more on this, build a latest ModemManager, and open issues in their Gitlab.

~stacyharper 6 months ago

I sometime got delayed sms receiving. Sending one sms will trigger things in ModemManager that force it to received some other.

AFAIK, all modem issues are not definitely closed but it now works way better than before. Incoming call should trigger from crust reliably. The phone should also wake for incoming sms (but sometime got delay to pull them as I said).

I also recommend you to flash the modem using the Biktorgj modem (https://github.com/Biktorgj/pinephone_modem_sdk) and to follow new release from this repo. It remains some usb disconnection that can happen but in my experience, it happen way less often than before where I couldnt use suspension for this reason.

~gled 5 months ago*

I confirm this is not a sxmo issue ( reproduced on 1.5 and 1.6 ), nor a modem firmware issue ( reproduced on both biktorgj and official fw ), but it is still happening for some reasons on some carriers ( happens to me on verizon, not on tmobile apparently from irc ).

Every message received in deep sleep is dropped till modemmanager is restarted, either manually or by a reboot. can reproduce 100% of the time. Opened an issue upstream.

regarding comments from 3 months ago, trying also to figure out how to check if the phone woke up because of an incoming call or not, and if not to restart modemmanager. Did someone figured this out ?

~baroque0 5 months ago*

ah-ha! we got a clue and a way forward!!

from https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/466

"Aleksander Morgado @aleksm · 3 hours ago

When this happens, can you wait a bit more and retry the AT+CMGR= command manually? (e.g. with mmcli --command)

If this is a timing issue, we could add a workaround to detect this situation and request a controlled retry of the read command."

~gled 5 months ago

I discovered this morning accidently that it may unfortunately be a sxmo issue.

When entering deep sleep using the dmenu / power / sleep item, 100% of the messages are lost.

If I enter deep sleep though using the power button ( sxmo 1.6, purple then red led ), no issues at all.

Reproduced on demand, I am still unfamiliar with sxmo though, so if you have specific logs you want me to collect, happy to do so !

~gled 5 months ago

Test thanks to wart_ this morning, patching line 200 sxmo_appmenu.sh to change lock to off ( power / sleep section ), and it works, sms are received fine.

I wonder if this is a hardware revision issue, I have a pinephone 1.2a I think ( hard to tell, got it used ).

~phartman 16 days ago

A lot of work has been done with biktorgj's firmware that should fix this.

~phartman REPORTED FIXED 15 days ago

Register here or Log in to comment, or comment via email.