Incorrect SMS reassembly including stale fragments

Bug Reports
#1

REPRODUCIBILITY: once a week or so, not predictable, no clear STR.
OS VERSION: currently 4.6.0.11, but I’ve seen this problem for many years.
HARDWARE: currently Xperia 10 III, previously observed at least on Xperia XA2 and Xperia X.
UI LANGUAGE: English.
REGRESSION: no.

DESCRIPTION:

Sometimes it happens that the SMS I receive in the Messages app looks broken: the beginning obviously belongs to one SMS while the end belongs to a different one. I’ve observed this with SMS from different senders (although the beginning and the end seem to always belong to the same sender).

As an additional data point, my /var/lib/ofono/<number>/sms_assembly directory contains 185 files in 183 directories named like 0123ABCD-123-3/002, the oldest of which are from December 2022 (which is not long after I installed Sailfish on this phone). As these files seem to contain text fragments looking like SMS text, my best guess would be that stale fragments from SMS never received completely are stored indefinitely. When SMS identifiers, whatever these are, are reused the phone sometimes reassembles the message incorrectly by reusing a stale fragment with the same identifier in place of a fragment received now (and possibly leaving that fragment to confuse reassembly after the next sms id reuse?).

PRECONDITIONS:

The phone needs a SIM card and some sender needs to send a lot of SMS to it. The behavior seems to be dependent on the amount of use since installation - I’ve seen this on multiple phones and in all cases the problem only became noticeable after a significant amount of use.

STEPS TO REPRODUCE:

No clear STR, see description. I assume reproducing the problem requires receiving many SMS from the same contact, poor network signal and/or some specific sender configuration.

EXPECTED RESULT:

Whole message correctly displayed if possible. Otherwise (if some parts have been lost) I’d prefer either displaying the available part of the message clearly marked as “partial message” or not displaying it at all.

ACTUAL RESULT:

Parts of received messages are replaced with some stale fragments, which can be at least as bad as not receiving it at all.

MODIFICATIONS:

Storeman, Chum, a few minor native apps, but nothing significant.

ADDITIONAL INFORMATION:

(not sure what kind of additional information would be needed here)

3 Likes
#2

Hi,
unfortunatelly this is a very old bug, which never got fixes. It dates back to Jolla Phone and happend on all four sailfish phones I owned. It was reported many timew, even on together.jolla, e.g. Bug received sms mixed together.
It may fix itself by retirement of SMS :wink:

2 Likes
#3

I’d guess that it could be mostly fixed (or at least reduced in normal use) by just cleaning up fragments after a week or so assuming that the remaining parts of this sms have already expired on the network side and thus it won’t ever be completed.

#4

I just checked and I have a lot of directories (named as you describe) with timestamps going back to last December, and always exactly one binary-looking file in it (strings revealed nothing) 50-150 bytes in size. And I have not experienced this bug, at least not regularly.

2 Likes
#5

Yeah, the files are binary. As I receive a lot of SMS in Cyrillic, for me cat $file | iconv -f utf16be -t utf8 (or utf16le for some files) reveals the contained text. Not sure what’s needed to show SMS in English - I think they might use some nonstandard encoding.

1 Like
#6

Yes, absolutely: I experience this bug since I started using SailfishOS seriously on a Jolla 1 with SailfishOS 1.1.6.

As this bug is not easily reproducible, there was much speculation about its preconditions on TJC between 2015 and 2020.

  1. I can only confirm a few facts: The affected SMS have to be multi-part SMS, i.e. comprise more than 160 bytes (which is not necessarily more than 160 characters: When a 16-bit character encoding is used, the limit is less than 80 characters, @MattVogt wrote “about 65”).

    Then sometimes (quoted from the OP, with inserts by me in brackets) "the beginning obviously belongs to one SMS while the end belongs to a different [, older] one [from the same conversation]."
    The original end of the viewed SMS is not visible / accessible in the Messages app.

  2. Observations from the original thread at TJC which I can clearly dismiss as relevant:

    • No, it does not need more the 1000 SMS from the same sender to occur. I have seen it happening within conversations with ca. 100 SMS. Some indicated even “with only a few SMS”.
    • No Emoji character is required, but AFAIU they cause a switch to 16-bit encoding, which more than halves the character limit for a single part SMS (to less than 80 chars).
    • No, it definitely does require “tampering with the SMS database” for this bug to occur.
    • The OS of the sending device appears to be irrelevant: While I and some others have only observed this with SMS from Android devices (likely just because most people I know use Android devices), others observed this with SMS sent by iOS and @tanghus with SMS sent by SailfishOS.

  3. Observations which seem to increase the likelihood for this bug to occur, but are not a precondition:

    • Many SMS in a conversation

  4. My personal, additional observation:

    • It seems that not only the affected SMS has to be a multipart SMS, but also the fragment of the old SMS which substitutes the original end of the affected SMS is always from a multi-part SMS and never from its first part.

@chris.adams (at that time a sailor) wrote that this bug is “tracked by Jolla”, but neither the original thread at TJC nor this one here is marked as “tracked by Jolla”! I hope it is still in Jolla’s bug database, and it definitely should be updated (or recreated) to include information from this thread.
And I regularly wonder, why Jolla does not seem to prioritise bugs which long affect very basic functionality of a mobile phone, as (here) receiving SMS.

I wonder, if the workaround by @fLegmatik from 2017 still works, but as apparently nothing has changed since 2015, I assume so.
By quickly reading how to employ this workaround, I did not really understand how and why it works, but I guess I should take a closer look on the device with more time and patience than now.

4 Likes
#7

Seems to work for me, although it’s a temporary workaround. IIUC, it just moves the SMS fragment “database” used for reassembly so that the component doing that does not find the stale fragments.

1 Like