Messages (SMS) sent when phone is off are not received when turned on - Bug report

Bug Reports
, ,
1

REPRODUCIBILITY: 100%
OS VERSION: 5.0.0.72 and older
HARDWARE: Jolla C2
UI LANGUAGE: English
REGRESSION:

DESCRIPTION:

Messages (SMS) that are sent to the device while it is turned off are not shown when turned on again. The Telco provider told me, that their logs indicate, that the messages are delivered.
Topic has been asked here already: Messages (SMS) sent when phone is off are not received when turned on

PRECONDITIONS:

Dunno. Never worked on the phone.

STEPS TO REPRODUCE:

  1. Turn off phone.

  2. Send SMS to the phone via any other phone

  3. Turn the phone back on.

  4. No new message is displayed in the “Messages” app.

EXPECTED RESULT:

I expect the new message to appear in the messages app

ACTUAL RESULT:

Message disappears somewhere. No error message, or indication that a message has been received. Telco provider tells me the messages are delivered, when the phone is turned on again.

MODIFICATIONS:

Vanilla

ADDITIONAL INFORMATION:

Telco provider: Spusu (https://spusu.at)
Network generation: 4G

3 Likes
2

You should add what network provider and network generation and settings on your C2 about that.

Ofono logs would be very useful.

3

I could not reproduce this with quick tests. The messages arrive fine after the device is turned on, with either VoLTE on or off.

So this is possibly a network specific issue, or some weird timing thing…
Do you have SIM PIN set? Having to enter the pin might affect the timing.

Need to check how to get the ofono logs right from the boot.

1 Like
4

No SIM PIN is set.
What are ofono logs? And how do I get them?

5

What do the messages contain? Just plain text? or do they contain weird characters and other non-ASCII data? You say it is 100% reproducible and your provider said the messages get delivered, so you need to root around in your phone, they are stored somewhere. I remember one user had to do that to figure out why messages seemingly got lost.

edit: one possible directory is /var/lib/ofono.

Here are two related threads:

1 Like
6

To get the ofono logs starting from the boot:

Enable developer mode in settings if you haven’t already done that.

Connect to the device over SSH

On the terminal switch to root and enable ofono debug logging

devel-su
mkdir /etc/systemd/journald.conf.d
echo -e "[Journal]\nRuntimeMaxUse=50M\nRateLimitBurst=0" > /etc/systemd/journald.conf.d/debug.conf
echo "OFONO_DEBUG=--debug" > /var/lib/environment/ofono/debug.conf

Shut down the device, send SMS to it, and turn the device back on.
Once the device has booted, ssh to the device again and as root dump the ofono logs

devel-su
journalctl -au ofono > /home/defaultuser/Documents/ofono.log

Then email that ofono.log file to me, I’ll PM you the address.

Afterwards you can delete the log file and disable the extra debug logging

devel-su
rm /home/defaultuser/Documents/ofono.log
rm /etc/systemd/journald.conf.d/debug.conf
rm /var/lib/environment/ofono/debug.conf
4 Likes
7

Messages are plaintext only.
I will get the ofono logs and answer as soon as I have them

1 Like
8

I have had the same thing happen to me last summer (autumn?) on Orange ( www.orange.ro ), with messages sent by the operator itself in my case.
The phone was intermitently off (usually for a work week; 5 days) and I did not receive the SMSes when I turned on the phone.
The phone was an Xperia 10 V with the latest (at the time) OS version available for regular users.

9

It could be that unsent SMS keep timeout has passed after 5 days.

10

Based on the logs we got (thanks @Lithilion) it seems that the message is received by ofono, but is lost somewhere higher up the stack.

The possible culprits there are telepathy-ring and mission-control-5, so we would need to get a bit more logs. To enable debug logging in those, the following changes are needed (in addition to the ofono debug logging from earlier):

Journal needs persistent storage, so the user session unit logs are accessible. As root do:

echo -e "[Journal]\nStorage=persistent\nRateLimitBurst=0" > /etc/systemd/journald.conf.d/debug.conf

For mission-control-5 need to add some environment variables in the service (as root):

mkdir /etc/systemd/user/mission-control-5.service.d
echo -e "[Service]\nEnvironment=G_MESSAGES_DEBUG=all MC_DEBUG=all" > /etc/systemd/user/mission-control-5.service.d/debug.conf

And same for telepathy-ring, with slightly different variables

mkdir /etc/systemd/user/telepathy-ring.service.d
echo -e "[Service]\nEnvironment=G_MESSAGES_DEBUG=all MODEM_DEBUG=all RING_DEBUG=all CALL_DEBUG=all" > /etc/systemd/user/telepathy-ring.service.d/debug.conf

Then shutdown the device and send a test SMS to it.

After starting the device the combined log out of all three can be collected (as root) with

journalctl -a _COMM=telepathy-ring _COMM=ofonod _COMM=mission-control > /home/defaultuser/Documents/sms_combined.log

Later to cleanup and disable the debug logging (as root):

rm -r /etc/systemd/user/mission-control-5.service.d
rm -r /etc/systemd/user/telepathy-ring.service.d
rm /home/defaultuser/Documents/sms_combined.log
5 Likes
11

It looks like the problem is that ofono receives the message before the higher level services are running and ready to handle it. And the way ofono just forwards the incoming message in a dbus signal and does not store it, means that the message gets lost if there is nothing listening for the signal.

This may cause lost messages also in other situations where the higher level services might not be listening, for example if they have crashed for what ever reason.

As a workaround, enabling PIN code on the SIM delays the ofono network registration and SMS receiving to give time for the other services to start up.

7 Likes
12

Great to hear that you found the bug! Hopefully there will be some official fix in the future releases :slight_smile:

2 Likes
13

Hey! Thanks for finding the error. Will you fix this in an upcoming release?

As for the workaround, I try to find out my deactivated PIN :slight_smile:

14

Fixing it might be complicated as it probably requires fundamental changes to how the incoming messages are handled. So it’s a bit too early to say when we might get a fix for this.

1 Like
15

Is it not an option to depend start of ofono service on those higher level ones?

1 Like
16

Losing an SMS can be serious. To make it worse that loss is invisible. Many of us might encounter that without even knowing.
Some even turn off the phone during night, flight, meeting, … So there is a lot of “bug windows”.

5 Likes
17

Just confirmed the PIN workaround. Thanks for helping.

+1 to filip. Fixing would fancy a lot.

2 Likes
18

Ofono needs to start early as it is needed for emergency calls from unlock UI, before any of the user session services are started.

2 Likes
19

If I read this correctly, you have this on your roadmap somewhere. Correct?

20

Why do you ask again?

2 Likes