Librem 5 Not Receiving Texts

Hi all. I received my Librem 5 around April/May of this year and have been having a great time with it. But recently I was slowly becoming aware of a reality that although I was receiving texts a few months ago, more recently I am not receiving texts. I am in NA/US and from what I can tell, I can still send texts. Also, the mobile internet connectivity works great when the modem hardware switch is on. My mobile provider at the moment is Google Fi, although I do understand how stupidly contrary that is to the Librem 5’s nature and how at some point I should switch providers when I have the time to look into that.

Maybe this is a question that has been asked before, but where should I look for debugging tips on how Chatty handles receiving mobile texts? I have some software experience and wouldn’t mind grepping some logs or playing with a terminal app to look for or resolve text reception errors, but I haven’t gone and tried to do any of those things with Chatty yet and was just letting it run in the state it was in when I received the device until now.

This being said, I haven’t been doing a lot of research on this yet and it’s possible I’m asking this prematurely and there is a very obvious solution listed somewhere else here on the forums. Feel free to point me in that direction if so.

Edit: With the Google Fi service I can also view my texts via an internet browser because they are all intercepted by some Google server or whatever, so I have that as a second stream to confirm that some texts exist that don’t show on Chatty. But I am specifically trying to use the modem hardware’s SMS systems and the default Chat app as the means by which to receive the texts.

Edit 2: Possibly related, the mmcli shows a lot of messages stuck in the “receiving” state:

root@pureos:~# mmcli -m any --messaging-list-sms
    /org/freedesktop/ModemManager1/SMS/16 (receiving)
    /org/freedesktop/ModemManager1/SMS/15 (receiving)
    /org/freedesktop/ModemManager1/SMS/14 (receiving)
    /org/freedesktop/ModemManager1/SMS/13 (receiving)
    /org/freedesktop/ModemManager1/SMS/12 (receiving)
    /org/freedesktop/ModemManager1/SMS/11 (receiving)
    /org/freedesktop/ModemManager1/SMS/10 (receiving)
    /org/freedesktop/ModemManager1/SMS/9 (receiving)
    /org/freedesktop/ModemManager1/SMS/8 (receiving)
    /org/freedesktop/ModemManager1/SMS/7 (receiving)
    /org/freedesktop/ModemManager1/SMS/6 (receiving)
    /org/freedesktop/ModemManager1/SMS/5 (receiving)
    /org/freedesktop/ModemManager1/SMS/4 (receiving)
    /org/freedesktop/ModemManager1/SMS/3 (receiving)
    /org/freedesktop/ModemManager1/SMS/2 (receiving)
    /org/freedesktop/ModemManager1/SMS/1 (receiving)
    /org/freedesktop/ModemManager1/SMS/0 (receiving)

Other similar threads suggested the use of mmcli to “delete” SMS messages from the Modem Manager. I went ahead and tried this advice because I have that “backup” version of the SMS messages coming through the Google server, but I hesitated because hypothetically for example if I didn’t have a backup of the SMS messages like that I don’t understand how I would have saved these “receiving” messages – my intention is not to delete them, but to receive them.

Anyway, I can confirm that after executing the following command as root (based on what some other threads suggested) I began to receive texts again, although past texts were not recovered:

mmcli -m any --messaging-list-sms | awk '{print $1}' | xargs -I {} mmcli -m any --messaging-delete-sms={}

Edit:
Maybe 30 minutes after doing the above command, the old texts from the past that were in the Google server but not the modem/Librem5 – that I had missed and assumed to have deleted – came in and appeared in Chatty.

Edit 2 (following day): I ran this command again when having issues receiving texts and I know for certain I lost some messages and never received them. Does anybody know what I can do to improve the reliability?

4 Likes

Have you used the SIM Card with Android or, before?

Yes, the SIM card was used on Android for years.

I would simply swap to a different cellular provider temporarily to see if Google Fi is the issue. In any case, your transition is overdue.

I’m on T-Mobile and the firmware of my BM818 is up to date. It is apparently not uncommon for SMSs sent to me to become “stuck”, without me being aware of these SMSs.

Now, I daily run: mmcli -m any --messaging-list-sms
and I delete any messages that show up in this list.

After this, I reboot the L5 and after a few minutes, the missing SMSs are received by the L5. At least, this works for me.

I don’t know why some SMSs become stuck and other not stuck, but it frequently happens to me.

1 Like

I’ll sometimes notice the phone wakes from suspend but there are no notifications of anything. If I use the modem HKS to turn it off and back on it will receive the message(s) that stuck

I think what is supposed to happen is that chatty should fetch the new SMS messages from ModemManager. I suspect there is a bug that causes chatty to fail doing that when it encounters something it cannot handle, such as a funky character that does not belong to the expected character set, or similar.

If it happens often for you, the good thing with that is that it gives a good opportunity to find and fix the bug.

One way to debug would be as follows: wait until you have the situation with some SMS being stuck. Then, in terminal, kill chatty twice:

killall chatty
killall chatty

(Need to do that twice because it restarts automatically once, then it gives up if killed quickly again. To verify, you can do “killall chatty” a third time) afterwards and then it should say that there is no such process, so then you know that there is no chatty running.

Then, when chatty is dead, start it manually with the --debug flag, like this:

chatty --debug &> debug-log.txt

Then inspect the resulting debug-log.txt file and look for error messages involving the attempts to fetch SMS messages.

Can you try that?

I will try what you suggest. Thank you.

1 Like

I have also run into this issue recently. It’s reported on mobian’s troubleshooting page and pine64 users are reporting it, supposedly an mms gets ‘stuck’ in the modem and prevents it from receiving incoming sms. According to the purism git, this issue was from chatty was not processing the mms, and this prevented all incoming sms after, marked as solved 1 year ago, so there could have been a regression in a recent update to chatty. I have since removed all incoming sms from modemmanager’s queue and now have to just wait and see if it occurs again.

2 Likes

How did it go?

If you could report back what you find in logs, that could help finding and fixing the bug(s).

The fact that there are messages that are not displayed and the user has no indication that this is happening, makes librem5 NOT a phone.

1 Like

Somewhere I’m sure there is somebody who believes that rotary telephones are the only phones, and iPhone is not a phone. This issue is probably even just a software issue and not a hardware issue. Maybe the cell companies could update their protocols at any time to break Librem 5’s if they wanted to force you onto their favorite devices.

I find that I enjoy how the Librem 5 allows me to pretend to confirm to the direction society is going while actually holding something as capable as a laptop. Also, my phone provider has a web login that shows my texts, so I can always get a backup, even from the Librem 5.

Why is the rest of the world not like that?

1 Like

you can pretend whatever you want, but by basic phone functionality today most will understand at least voice and SMS.

If it fails when you make a call or send text, is annoying, but not that bad. You retry. But, as a receiver, you want to get all (voice calls and text), or at least to know when there is an attempt and from who, because the sender won’t bother to retry.

But, when someone sends a text that goes to a black hole, and you don’t know unless you look from command line, but have no metadata from that message, and the only thing you can do is to delete that message, this is really bad, especially when it is marketed or implied as at least a basic phone.

Sure, you are the 1% with a data method to check for texts and like to hold something that is more than a phone, and have no big problem with texts sent to you. How sweet!

This forums sounds more and more like a sect: this is more than phone.

3 Likes

Please don’t confuse myself with the nature of the entire Purism forums! I could get on here and say that Chicken Little was right that the sky is falling, or that David Grusch is right that the US government is hiding recovered alien technology from out of this world, and I should hope this would make PureOS and their devices no less valid nor sincere, and their communities no less wholesome, because I am not PureOS. I am simply a user,
that they might choose to ban at any time.

If we hold the Volume Down button on a Librem 5, we can boot the device off of an SD card without needing to reflash the OS nor risk damaging the main system install. These are amazing powers that Android devices typically do not offer the user. And that might make it much easier, for example, to experiment with a different version of the ModemManager program to try to fix it!

I understand that the ability for you to try to fix your issue yourself does not necessarily fix your issue in this case, but that ability is one of the aspects of living with a Librem 5 that I truly enjoy. And as far as I know, I did not have anyone sell me on that idea through some occult mind influence. As far as I know, it is an enjoyment of technology I arrived at myself.

1 Like

The fact that this phone (hw+sw) hides and looses text received from network is a very serious issue. (I consider the text lost because I can’t see the sender, nor the content)

And this should be obvious for all, even if some might use it as a laptop connected with a usb-to-ethernet adapter, not affected by GSM/wifi issues. Without acknowledging this, there will be no urgency to fix this issue. Mocking my words (is not a phone) and downgrading the importance of this issue will probably “help” fix this later than sooner, which nobody wants.

I’ve used Neo FreeRunner for 4 years as my only phone. I know how a Linux Phone feels like. I live it for years. Librem5 looked much better when I got it and I was ready to use a secondary phone for Android stuff forever.

However, after about 5 months I have to drop off this pocket-warmer and text-eater. Purism marketed (bull$hitting) much-much-much more than Openmoko. But, this can’t cover serious issues for too much time.

Librem5 looks 10 times better than NeoFreerunner, but after the makeup fades away in time, it is 10 times worst, even if you compare only the time I could use them.

I understand the excitement to have a linux phone and make use of it the way you can’t do with one with android/ios, but downgrading/dismissing serious issues because of X is mind blowing to me.

I hope one day I would use a linux phone or a mini-laptop with modem, built/supported by one or more companies that make profit from that, regardless if they brag about being “social interest(ed)” or not.

Android is Open Source and runs a Linux kernel. Certainly on devices that have SD cards, one can boot an Android ROM from an sd card. Just because you’re not aware of it, doesn’t mean it doesn’t exist. One can also multi-boot.

1 Like

I’m only aware of being able to install a ROM from the SD card (and if desired, go back and reinstall the former ROM). Is it actually possible to boot a different ROM at will without fully installing it? If so, I like that.

EDIT: Did a search, and discovered it’s a thing. Interesting.

So this issue used to be rare for me but has become near constant. As best I can tell android RCS messages are the most likely to have issues … this is becoming quite painful to deal with as people end up sending me screenshots of the messages they sent because resending doesn’t work.

1 Like

Not so rare. Happened to me again. twice in the last 4 months. Can someone further investigate + fix this? It may be a coincidence, but I just updated my phone and this problem reoccurred.

2 Likes