Incorrect processing of network name and time messages from operator leads to multiple issues
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| modemmanager (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Ubuntu version: 20.04.1 LTS
modemmanager version: 1.12.8-1
modem-manager-gui version: 0.0.19.1-2
What I expected to happen: SMSes in the GUI have correct timestamps; the operator name is reported correctly in the GUI; USSD communications work correctly in the GUI and through the mmcli interface.
What is actually happening: SMSes in the GUI have no timestamps; the operator name disappears from the GUI; USSD communications randomly fail both in the GUI and on the commandine. I understand that the maintainers of this package are not responsible for the GUI application, but below I explain my rationale for filing this bug against this package and why I think these issues are related.
I use modemmanager and modem-manager-gui to manage a GSM modem in my Thinkpad. In 18.04 everything worked correctly, but since I upgraded to 20.04 I have noticed multiple issues which I believe may have the same underlying cause:
1. Received SMSes logged in modem-manager-gui no longer have timestamps. This may be the same issue as is reported here in the Fedora package, since the upstream version appears to be the same: https:/
2. When I start up modem-manager-gui, I can see the operator name displayed correctly in the info tab, but after some time it disappears, and I see "Searching" as the value in the "Registration" field.
3. This is the most critical issue and the primary reason that I'm reporting this. When I interact with any USSD menu, I experience intermittent "Invalid USSD message received" errors which disrupt any sufficiently long chain of USSD interactions and make it near-impossible to complete certain tasks via USSD. It's only through extensive trial and error that I found that sometimes it's possible to retry the same reply successfully, although this is very sensitive to timeouts. After initially observing this behaviour in modem-manager-gui I tried to use the mmcli interface on the commandline to access these USSD menus, and found the same erratic behaviour. This is why I'm filing this bug against the modemmanager package.
The exact error messages are always in this format:
error: couldn't send response in USSD session: 'GDBus.
^NWTIME: 21/01/20,
My layperson's hypothesis is that these are messages from the operator containing the name of the network and the system time of the network, but modemmanager is not expecting them and therefore not processing them correctly for some reason, which is why 1) the network name and time is not being set in modem-manager-gui and 2) USSD communications are being disrupted by unexpected messages.
I'd be happy to help to debug this further if there is any other information that I can provide.
