SMS list different between mmcli and AT commands

[Matthew Via]

Thank you for looking into this!  Over the weekend I decided to try changing the ADSP firmware to something else to see if it had any impact, and in doing so it seems to have cleared the SMS memory, and thus all debugging evidence I have :)

Maybe this has fixed it, but I'll keep my eye on the AT output and if I can reproduce it I'll open up a github issue with him.

Thanks, Matthew

-- 
  Matthew Via
  via at matthewvia.info

On Sun, Jul 24, 2022, at 8:09 AM, Aleksander Morgado wrote:
> Hey,
>
>>
>> > However, I am still unclear on the issue, and this is certainly just my ignorance around QMI.  I understand this explanation for why I would miss messages when they arrive, but is that the only way MM will ever receive indication of a new message? I would have thought it would try to reconcile the state of the modem on startup at least.  Otherwise this would imply to me that just having MM stopped, or some other failure modes where the notification itself gets missed, would result in never receiving a message, even when its clearly visible as unread via the AT commands.  The list of SMS's I pasted spans a month and dozens of reboots, and even across installations of an OS -- would MM never be aware of those messages?
>> >
>>
>> Yes, ModemManager tries to load the full list of messages on startup
>> always. If this issue is happening consistently, could you get a full
>> MM debug log including the startup sequence when you've reached the
>> point that AT commands show the messages but MM doesn't? It could be
>> the messages are not being properly read via QMI for some reason, we
>> should debug that as well.
>>
>
> Matthew sent me a debug log privately, here is what I can see:
>
>  * The QMI WMS List Messages operations end up like this:
>    ** uim/mt-read returns an empty list.
>    ** uim/mt-not-read returns an empty list
>    ** uim/mo-sent returns an empty list
>    ** uim/mo-not-sent returns an empty list
>    ** nv/mt-read returns a list with 60 PDUs to read, with both
> mt-read and mt-not-read flags.
>        *** The attempt to read PDU #0 in nv fails with "NoEntry"
>        *** The attempt to read PDU #1 in nv fails with "NoEntry"
>        *** The attempt to read PDU #2 in nv fails with "NoEntry"
>        *** The attempt to read PDU #3 in nv fails with "NoEntry"
>        ...
>        *** The attempt to read PDU #59 in nv fails with "NoEntry"
>     ** nv/mt-not-read returns an empty list
>     ** nv/mo-sent fails with "Invalid argument"
>     ** nv/mo-not-sent fails with "Invalid argument"
>
> The first issue I see is that the mt-read list returns also
> mt-not-read PDUs, but this is not a big deal.
> The second issue I see is the NoEntry error returns when attempting to
> read each of the PDUs. Not sure if that error makes any sense, as we
> got the list of messages just before telling us there were 60 PDUs to
> read. This looks like a firmware issue of some kind, if I'm not
> mistaken.
>
> You're using the open source firmware for the modem, maybe Biktorgj
> knows more about what could be happening here? I'd open an issue in
> the github repo and see what he says.
> Cheers!
>
> -- 
> Aleksander