| Age | Commit message (Collapse) | Author |
|---|
|
The MC7304, which is a 3GPP only device, reports a ESN with value 0 in "DMS Get IDs":
ModemManager[10121]: [/dev/cdc-wdm0] Received message (translated)...
>>>>>> QMUX:
>>>>>> length = 45
>>>>>> flags = 0x80
>>>>>> service = "dms"
>>>>>> client = 2
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 6
>>>>>> tlv_length = 33
>>>>>> message = "Get IDs" (0x0025)
>>>>>> TLV:
>>>>>> type = "Result" (0x02)
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> translated = SUCCESS
>>>>>> TLV:
>>>>>> type = 0x13
>>>>>> length = 1
>>>>>> value = 42
>>>>>> TLV:
>>>>>> type = "Esn" (0x10)
>>>>>> length = 1
>>>>>> value = 30
>>>>>> translated = 0
>>>>>> TLV:
>>>>>> type = "Imei" (0x11)
>>>>>> length = 15
>>>>>> value = <hidden>
>>>>>> translated = <hidden>
|
|
|
|
Variability in the response style from certain modems causes the parsing
of the +CGMR response to fail. For example, the Telit HE910 inserts an
empty string ("") in the second field of the response, causing the
sscanf implementation to fail.
This patch converts the parsing of the CGMR response to a regex that
allows for more flexibility and robustness, and adds unit tests around
the parsing call.
Signed-off-by: Nick Stevens <Nick.Stevens@digi.com>
|
|
|
|
|
|
as a warning
|
|
Previously the enable unsolicited messages command (+CNMI) was only
being sent on the primary. This patch adds support for sending the
enable on the secondary as well. If the secondary doesn't exist, or if
setting the enable causes an error, a warning is logged but no error is
propagated up.
This change is needed for proper SMS operation on the Telit HE910, which
requires that +CNMI be sent to both primary and secondary. Since a
failure to send the +CNMI command on the secondary is a non-fatal error,
it is unlikely that this will cause issues with other modems.
Signed-off-by: Nick Stevens <Nick.Stevens@digi.com>
|
|
MBIM+CDMA
CDMA-capable modems (like a Sierra EM7355) will fail to even enable,
because the internal CDMA code tries to initialize using AT commands and
that fails because many MBIM modems don't have an AT port. We should
figure out how to support minimal MBIM + CDMA using MBIM instead of
AT-anything.
[mm-broadband-modem.c:9000] enabling_step(): Modem has CDMA capabilities, enabling the Modem CDMA interface...
[mm-iface-modem-cdma.c:946] mm_iface_modem_cdma_run_registration_checks(): Running registration checks (CDMA1x: 'yes', EV-DO: 'yes')
[mm-broadband-modem.c:7397] setup_registration_checks_context_complete_and_free(): Will skip all QCDM-based registration checks
[mm-broadband-modem.c:7418] setup_registration_checks_context_complete_and_free(): Will skip generic detailed registration check, we don't have Sprint commands
[mm-iface-modem-cdma.c:768] registration_check_step(): Starting QCDM-based registration checks
[mm-iface-modem-cdma.c:780] registration_check_step(): Skipping all QCDM-based checks and falling back to AT-based checks
[mm-iface-modem-cdma.c:823] registration_check_step(): Starting AT-based registration checks
[mm-iface-modem-cdma.c:641] get_service_status_ready(): Could not get service status: No AT port available to run command
[mm-iface-modem.c:1392] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/0: state changed (enabling -> disabled)
|
|
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1473246
|
|
|
|
# Extra options to supply to gtkdoc-scan
SCAN_OPTIONS = --rebuild-types
|
|
DOC Building HTML
../libmm-glib-docs.xml:6: element indexdiv: validity error : ID api-index-full already defined
DOC Fixing cross-references
|
|
|
|
|
|
There's no MM_CALL_DIRECTION_TERMINATED enum; plus, anyway, hangup() should be
allowed regardless the direction.
|
|
|
|
|
|
|
|
This command is sent by Huawei ME909s-120 with firmware 23.613.61.00.00
|
|
signal with 'SendDtmf' and 'DtmfReceived'
|
|
|
|
This response is already managed by the generic AT serial port and translates
it into a proper error. This change also avoids the Call.Start() call to report
a timeout in the serial port, instead we get a proper no-carrier error.
Before:
$ sudo mmcli -m 0 --voice-create-call="number=12345678"
Successfully created new call:
/org/freedesktop/ModemManager1/Call/1 outgoing (unknown)
$ sudo mmcli -o 1 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Serial.ResponseTimeout: Serial command timed out'
After:
$ sudo mmcli -m 0 --voice-create-call="number=12345678"
Successfully created new call:
/org/freedesktop/ModemManager1/Call/1 outgoing (unknown)
$ sudo mmcli -o 1 --start
error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Connection.NoCarrier: No carrier'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ok, busy and no carrier messages are handled by serial-parser.
|
|
|
|
|
