Bug 94855

Summary: Huawei E182E cannot receive SMS
Product: ModemManager Reporter: Alexander E. Patrakov <patrakov>
Component: pluginsAssignee: ModemManager bug user <modemmanager>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: 1.4   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: ModemManager debug log

Description Alexander E. Patrakov 2016-04-07 08:47:50 UTC
Created attachment 122785 [details]
ModemManager debug log

If I try to use a Huawei E182E modem, it is not fully functional. It connects, it can do USSD queries and send SMS, but cannot receive them.

After some debugging, I found that it is because ModemManager by default selects the ME storage, which exists but has has zero capacity on this modem. I.e., every time an incoming message arrives, it triggers this:

(ttyUSB2): <-- '<CR><LF>^SMMEMFULL:"ME"<CR><LF>'

Please don't use the "ME" storage on this modem. If I send SIGSTOP to ModemManager, then use picocom to send this AT command to ttyUSB2:

AT+CPMS="SM","SM","SM"

...then SMS reception starts working.

Log attached.
Comment 1 Alexander E. Patrakov 2016-04-07 08:59:47 UTC
Of course, I send SIGCONT to ModemManager after the AT command
Comment 2 Aleksander Morgado 2016-04-08 11:33:57 UTC
I wonder if this is something specific to your own setup; i.e. is that ME memory full of SMS messages, or is just non functional for some reason?
Comment 3 Alexander E. Patrakov 2016-04-08 11:37:06 UTC
If you can provide me with some AT commands or other instructions how to diagnose - please send them here.

AFAIK the "ME" storage is supposed to be cleaned up on modem plug/replug, and the log starts with plugging the modem in, so it can't have any messages in it.
Comment 4 Alexander E. Patrakov 2016-05-11 06:09:12 UTC
The bug is in the NEEDINFO state for more than a month, and it is not clear what information is needed and how to get it.
Comment 5 Aleksander Morgado 2016-05-11 06:36:07 UTC
> AFAIK the "ME" storage is supposed to be cleaned up on modem plug/replug,
> and the log starts with plugging the modem in, so it can't have any messages
> in it.

"ME" is "Mobile Equipment", i.e. the SMS are stored in the modem memory itself, which means they're not cleaned up on plug/replug, unless I'm missing something.

But this is not really the issue here. ModemManager isn't defaulting the storage of the SMS received to the ME memory, it's instead using MT:

ModemManager[1614]: <debug> [1460018571.731722] [mm-port-serial-at.c:440] debug_log(): (ttyUSB2): --> 'AT+CPMS="","MT","MT"<CR>'

The order preference for the default storage is: MT, ME, SM. In your case the first is reported as usable, and that's what it's being used.

Now, "MT" is not a real storage, it's just a way to specify "ME+SM", which means that the modem should either the device memory or the SIM memory and we don't care which one.

If MT doesn't work even if reported as supported, I believe this may be a problem with your specific device firmware. We would need to provide a plugin override for that specific device to default to SM always, or something like that.

Or, instead of that, leave the auto-default logic as it is, which I think is sane, and provide an additional "SetDefaultStorage" method in MM to allow changing the default storage during runtime.
Comment 6 Alexander E. Patrakov 2016-08-12 07:55:34 UTC
I am at GUADEC. If you are there too, we can debug the modem issue together.
Comment 7 Aleksander Morgado 2016-08-12 16:38:59 UTC
(In reply to Alexander E. Patrakov from comment #6)
> I am at GUADEC. If you are there too, we can debug the modem issue together.

Sorry, I'm not there this year :/
Comment 8 GitLab Migration User 2018-06-10 09:02:57 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/31.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.