| Age | Commit message (Collapse) | Author |
|---|
|
In MM 0.6 days it used to be obfuscated, but that was pointless. Now
it's just the ICCID.
|
|
Auth settings will be added in a QMI message only if at least one of these is
requested:
* An explicit auth preference is requested.
* User string is given and isn't empty.
* Password string is given and isn't empty.
|
|
When changing from idle to registered we'll load registration info before really
reporting that we're registered (so that clients can get the new registration
info directly). During this time, we should also allow LAC/CID updates triggered
in the location interface.
E.g. when receiving this QMI message, we're not processing LAC/CID because when
they get reported, the registration state was not yet 'registered':
[/dev/cdc-wdm0] Received message (translated)...
>>>>>> QMUX:
>>>>>> length = 67
>>>>>> flags = 0x80
>>>>>> service = "nas"
>>>>>> client = 1
>>>>>> QMI:
>>>>>> flags = "indication"
>>>>>> transaction = 0
>>>>>> tlv_length = 55
>>>>>> message = "Serving System" (0x0024)
>>>>>> TLV:
>>>>>> type = "MNC PCS Digit Include Status" (0x29)
>>>>>> length = 5
>>>>>> value = D6:00:01:00:00
>>>>>> translated = [ mcc = '214' mnc = '1' includes_pcs_digit = 'no' ]
>>>>>> TLV:
>>>>>> type = "LTE TAC" (0x25)
>>>>>> length = 2
>>>>>> value = 08:01
>>>>>> translated = 264
>>>>>> TLV:
>>>>>> type = "Detailed Service Status" (0x22)
>>>>>> length = 5
>>>>>> value = 02:03:00:01:00
>>>>>> translated = [ status = 'available' capability = 'cs-ps' hdr_status = 'none' hdr_hybrid = 'yes' forbidden = 'no' ]
>>>>>> TLV:
>>>>>> type = "CID 3GPP" (0x1e)
>>>>>> length = 4
>>>>>> value = 01:A1:4D:04
>>>>>> translated = 72196353
>>>>>> TLV:
>>>>>> type = "LAC 3GPP" (0x1d)
>>>>>> length = 2
>>>>>> value = FE:FF
>>>>>> translated = 65534
>>>>>> TLV:
>>>>>> type = "Current PLMN" (0x12)
>>>>>> length = 5
>>>>>> value = D6:00:01:00:00
>>>>>> translated = [ mcc = '214' mnc = '1' description = '' ]
>>>>>> TLV:
>>>>>> type = "Data Service Capability" (0x11)
>>>>>> length = 2
>>>>>> value = 01:0B
>>>>>> translated = { [0] = 'lte '}
>>>>>> TLV:
>>>>>> type = "Serving System" (0x01)
>>>>>> length = 6
>>>>>> value = 01:01:01:02:01:08
>>>>>> translated = [ registration_state = 'registered' cs_attach_state = 'attached' ps_attach_state = 'attached' selected_network = '3gpp' radio_interfaces = '{ [0] = 'lte '}' ]
<debug> [1444895382.427216] Processing 3GPP info...
<info> [1444895382.433423] Modem /org/freedesktop/ModemManager1/Modem/3: 3GPP Registration state changed (idle -> registering)
[ Here we tried to update LAC/CID ]
<debug> [1444895382.439668] Modem /org/freedesktop/ModemManager1/Modem/3: 3GPP location updated (MCC: '214', MNC: '1', Location area code: '0', Cell ID: '0')
<info> [1444895382.446788] Modem /org/freedesktop/ModemManager1/Modem/3: 3GPP Registration state changed (registering -> home)
<info> [1444895382.452383] Modem /org/freedesktop/ModemManager1/Modem/3: state changed (enabled -> registered)
|
|
Given that the Location interface requires 3GPP info reported by the 3GPP
interface, we should only trigger registration checks once the Location
interface has been already enabled and ready to be used. If we don't do this,
we'll end up e.g. getting initial MCCMNC values but never reaching the Location
interface properly.
So, fix this by triggering all registration checks (CDMA and 3GPP) only after
having enabled all interfaces.
|
|
LAC/CID may only be given in the serving system indications when the values
change, and therefore we shouldn't reset the values to 0 whenever they're not
reported.
This seems to happen in newer devices; older devices like the MC7710 did always
report the values in the indications.
|
|
remove them
|
|
|
|
This check makes no sense. We're converting from a ModemManager enum to a QMI
enum, nothing else; i.e. 'caps' is *not* the current capabilities of the modem.
|
|
QMI commands
|
|
Found by Jean-Christian de Rivaz
|
|
Breakpoint 2, g_log (log_domain=log_domain@entry=0x7ffff6ad744e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff6ae0c1d "%s: assertion '%s' failed") at gmessages.c:1075
1075 {
(gdb) bt
#0 0x00007ffff6a71b20 in g_log (log_domain=log_domain@entry=0x7ffff6ad744e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff6ae0c1d "%s: assertion '%s' failed")
at gmessages.c:1075
#1 0x00007ffff6a71be9 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff6ad744e "GLib", pretty_function=pretty_function@entry=0x7ffff6b316a0 <__FUNCTION__.5266> "g_variant_new_string", expression=expression@entry=0x7ffff6b2f1e8 "g_utf8_validate (string, -1, NULL)") at gmessages.c:1088
#2 0x00007ffff6a9e925 in g_variant_new_string (string=0x7cf850 "260\366\377\177") at gvariant.c:1230
#3 0x00007ffff7068cfe in g_dbus_gvalue_to_gvariant (gvalue=gvalue@entry=0x7fffffffdec0, type=0x7ffff7b9df91) at gdbusutils.c:604
#4 0x00007ffff7b8f1eb in _mm_gdbus_modem3gpp_skeleton_handle_get_property (connection=<optimized out>, sender=sender@entry=0x0, object_path=object_path@entry=0x7bd340 "/org/freedesktop/ModemManager1/Modem/1", interface_name=interface_name@entry=0x7ffff7b97320 "org.freedesktop.ModemManager1.Modem.Modem3gpp", property_name=property_name@entry=0x7ffff7baa0a4 "OperatorCode", error=error@entry=0x0, user_data=0x799ab0)
at mm-gdbus-modem.c:19680
#5 0x00007ffff7b8f894 in mm_gdbus_modem3gpp_skeleton_dbus_interface_get_properties (_skeleton=<optimized out>) at mm-gdbus-modem.c:19759
#6 0x00007ffff708e791 in g_dbus_interface_skeleton_get_properties (interface_=0x799ab0 [MmGdbusModem3gppSkeleton]) at gdbusinterfaceskeleton.c:371
#7 0x00007ffff70937a2 in manager_method_call (connection=<optimized out>, sender=sender@entry=0x7fffe0005200 ":1.270", object_path=object_path@entry=0x7fffe0002fd0 "/org/freedesktop/ModemManager1", interface_name=interface_name@entry=0x7fffe0002dd0 "org.freedesktop.DBus.ObjectManager", method_name=method_name@entry=0x7fffe00059e0 "GetManagedObjects", parameters=parameters@entry=0x7c1e70, invocation=0x7fffe0003260 [GDBusMethodInvocation], user_data=0x713cd0) at gdbusobjectmanagerserver.c:845
#8 0x00007ffff7076aac in call_in_idle_cb (user_data=0x7fffe0003260) at gdbusconnection.c:4884
#9 0x00007ffff6a6a7fb in g_main_context_dispatch (context=0x713a00) at gmain.c:3111
#10 0x00007ffff6a6a7fb in g_main_context_dispatch (context=context@entry=0x713a00) at gmain.c:3710
#11 0x00007ffff6a6ab98 in g_main_context_iterate (context=0x713a00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#12 0x00007ffff6a6aec2 in g_main_loop_run (loop=0x71bf50) at gmain.c:3975
#13 0x0000000000430e57 in main (argc=<optimized out>, argv=<optimized out>) at main.c:150
|
|
Instead, we'll return NULL and an error set.
|
|
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'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
