This CL converts a few g_regex_match_full() expressions to their
equivalent g_regex_match() in order to simplify the code, i.e.
g_regex_match_full (regex, str, strlen (str), 0, 0, &match_info, NULL)
is equivalent to:
g_regex_match_full (regex, str, -1, 0, 0, &match_info, NULL)
or simply:
g_regex_match (regex, str, 0, &match_info)
The operation sending the raw data of the SMS may timeout because the
current value of 10s is too low.
When this happens, we may end up marking the modem as invalid if the
operation takes much longer, as in
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/133
<debug> [1561707204.192676] (ttyUSB3): --> 'AT+CMGS=22<CR>'
<debug> [1561707204.207212] (ttyUSB3): <-- '<CR><LF>> '
<debug> [1561707204.207562] (ttyUSB3) device open count is 3 (open)
<debug> [1561707204.207695] (ttyUSB3) device open count is 2 (close)
<debug> [1561707204.207841] (ttyUSB3): --> '0021000B9164xxxxxxxxFx00000AEDF6989D06D1CB733A\26'
<debug> [1561707204.261028] (ttyUSB3): <-- '<CR><LF>'
<debug> [1561707205.197464] (ttyUSB3) device open count is 3 (open)
<debug> [1561707207.197763] loading signal quality...
<debug> [1561707207.197990] (ttyUSB3) device open count is 4 (open)
<debug> [1561707210.199337] (ttyUSB3) device open count is 5 (open)
<debug> [1561707214.197198] (ttyUSB3) device open count is 4 (close)
<debug> [1561707214.197443] (ttyUSB3): --> 'AT+CGACT?<CR>'
<debug> [1561707215.196530] (ttyUSB3) device open count is 5 (open)
<warn> [1561707217.196750] checking if connected failed: Couldn't check current list of active PDP contexts: Serial command timed out
<debug> [1561707217.196928] (ttyUSB3) device open count is 4 (close)
<warn> [1561707217.197065] (tty/ttyUSB3) at port timed out 2 consecutive times
<debug> [1561707217.197187] (ttyUSB3): --> 'AT+CIND?<CR>'
<debug> [1561707220.198180] (ttyUSB3) device open count is 5 (open)
<debug> [1561707222.196792] (ttyUSB3) device open count is 6 (open)
<debug> [1561707222.196983] (ttyUSB3) device open count is 5 (close)
<warn> [1561707222.197125] (tty/ttyUSB3) at port timed out 3 consecutive times
<debug> [1561707222.197257] (ttyUSB3): --> 'AT+CGACT?<CR>'
<debug> [1561707225.198384] (ttyUSB3) device open count is 6 (open)
<warn> [1561707225.198616] checking if connected failed: Couldn't check current list of active PDP contexts: Serial command timed out
<debug> [1561707225.198703] (ttyUSB3) device open count is 5 (close)
<warn> [1561707225.198814] (tty/ttyUSB3) at port timed out 4 consecutive times
<debug> [1561707225.199437] (ttyUSB3): --> 'AT+CGACT?<CR>'
<warn> [1561707228.196747] checking if connected failed: Couldn't check current list of active PDP contexts: Serial command timed out
<debug> [1561707228.196915] (ttyUSB3) device open count is 4 (close)
<warn> [1561707228.197050] (tty/ttyUSB3) at port timed out 5 consecutive times
<debug> [1561707228.197175] (ttyUSB3): --> 'AT+CGACT?<CR>'
<debug> [1561707230.197709] (ttyUSB3) device open count is 5 (open)
<warn> [1561707231.197089] checking if connected failed: Couldn't check current list of active PDP contexts: Serial command timed out
<debug> [1561707231.197256] (ttyUSB3) device open count is 4 (close)
<warn> [1561707231.197387] (tty/ttyUSB3) at port timed out 6 consecutive times
<debug> [1561707231.197519] (ttyUSB3): --> 'AT+CSQ<CR>'
<debug> [1561707234.199671] Couldn't refresh signal quality: 'Serial command timed out'
<debug> [1561707234.199897] (ttyUSB3) device open count is 5 (open)
<debug> [1561707234.200038] (ttyUSB3) device open count is 4 (close)
<warn> [1561707234.200161] (tty/ttyUSB3) at port timed out 7 consecutive times
<debug> [1561707234.200291] (ttyUSB3): --> 'AT+CGACT?<CR>'
<debug> [1561707235.197071] (ttyUSB3) device open count is 5 (open)
<debug> [1561707237.198460] Signal quality value not updated in 60s, marking as not being recent
<warn> [1561707237.198846] checking if connected failed: Couldn't check current list of active PDP contexts: Serial command timed out
<debug> [1561707237.198949] (ttyUSB3) device open count is 4 (close)
<warn> [1561707237.199060] (tty/ttyUSB3) at port timed out 8 consecutive times
<debug> [1561707237.199636] (ttyUSB3): --> 'AT+CGACT?<CR>'
<debug> [1561707240.198778] (ttyUSB3) device open count is 5 (open)
<warn> [1561707240.199031] checking if connected failed: Couldn't check current list of active PDP contexts: Serial command timed out
<debug> [1561707240.199127] (ttyUSB3) device open count is 4 (close)
<warn> [1561707240.199244] (tty/ttyUSB3) at port timed out 9 consecutive times
<debug> [1561707240.199363] (ttyUSB3): --> 'AT+CNSMOD?<CR>'
<debug> [1561707243.198163] Couldn't refresh access technologies: 'Serial command timed out'
<debug> [1561707243.198294] Periodic signal quality checks scheduled in 30s
<debug> [1561707243.198402] (ttyUSB3) device open count is 3 (close)
<error> [1561707243.198528] (tty/ttyUSB3) at port timed out 10 consecutive times, marking modem '/org/freedesktop/ModemManager1/Modem/0' as invalid
<debug> [1561707243.198699] (ttyUSB3): --> 'AT+CGACT?<CR>'
Or we may end up aborting other actions that the modem is doing...
<debug> [1560473069.956036] (ttyACM2): --> 'AT+CMGS=70<CR>'
<debug> [1560473069.963667] Added CALL at '/org/freedesktop/ModemManager1/Call/1'
<debug> [1560473069.977937] (ttyACM2): <-- '<CR><LF>> '
<debug> [1560473069.978558] (ttyACM2) device open count is 3 (open)
<debug> [1560473069.978812] (ttyACM2) device open count is 2 (close)
<debug> [1560473069.979152] (ttyACM2): --> '0001000D8......................\26'
<debug> [1560473080.317049] (ttyACM2): --> 'ATD123456789;<CR>'
<debug> [1560473092.293458] (ttyACM2): <-- '<CR><LF>+CMGS: 1<CR><LF><CR><LF>OK<CR><LF>'
<warn> [1560473092.293854] Couldn't start call : 'Couldn't start the call: Unhandled response '+CMGS: 1''
<info> [1560473092.293936] Call state changed: dialing -> terminated (unknown)
<debug> [1560473092.293987] Cleaning up in-call unsolicited events...
So, update the raw data sending timeout to a much longer value.
The regex was expecting empty values in several of the fields, which
is wrong. Instead of matching empty fields, just ignore all fields
that we don't require in our logic.
We use the raw commands exclusively when we're sending SMS data to the
device. Until this change, all raw commands were added at the tail of
the queue of pending commands, and that meant that if any unrelated AT
command was interleaved between e.g. our AT+CGMS and the actual SMS
data sent, the operation would have failed.
With this fix, we're making sure that all raw commands are added at
the head of the queue, so we're making sure that the next command
picked after e.g. CGMS is actually the raw SMS data to be sent.
We would be avoiding issues like this one, where an outgoing voice
call attempt gets in the way before we send the SMS data:
[1556246081.786284] (ttyACM2): --> 'AT+CMGS=70<CR>'
[1556246081.814861] (ttyACM2): <-- '<CR><LF>> '
[1556246081.819382] (ttyACM2): --> 'ATD1234567890;<CR>'
[1556246081.839685] (ttyACM2): <-- '<CR><LF>> '
[1556246081.840123] Couldn't start call : 'Couldn't start the call: Unhandled response '> ''
[1556246081.856254] (ttyACM2): --> '0001000D810..............
[1556246081.922470] (ttyACM2): <-- '<CR><LF>+CME ERROR: 4<CR><LF>'
By default all the commands we were sending through the serial port
were added at the tail of the pending queue, but we may want to queue
them at the head in very specific cases (e.g. while sending an SMS).
If ModemManager is being used in a custom system, make it easy to
unconditionally enable the Modem.Command() method, in case the modem
needs to be configured in some way that is not supported via standard
modem interfaces.
When registration is denied, we should be reporting the modem with
'enabled' state instead of 'registered'. This was not happening
because the logic to build the consolidated state (for 3GPP+3GPP2
modems) was using as default initial state the current old state, and
so if the old one was 'registered' it never allowed getting a
consolidated state of 'enabled', because 'registered' > 'enabled'.
Instead of using the old initial state, the consolidated modem state
should use 'enabled' as default initial value, which is the lowest
among 'enabled, 'searching' and 'registered'.
* For QMI modems, make sure we only grab QMI data ports (flag the
rest as ignored).
* For MBIM modems, make sure we only grab MBIM data ports (flag the
rest as ignored).
* For other plugins that use NET ports in their logic, make sure we
only grab non-QMI and non-MBIM data ports.
If a disconnection fails (because stop_network() failed), base-bearer
flips the state back to CONNECTED. Oops. At that point something is
clearly messed up, but it seems correct to assume the bearer is
connected.
Nevertheless, we will have already have unhooked the unsolicited events
reporting. A subsequent attempt to disconnect the bearer will trip the
assertion:
#0 0x00007ffff75f2eb5 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff75dd895 in __GI_abort () at abort.c:79
#2 0x00007ffff77beb53 in g_assertion_message
(domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=0x5088e0 <__FUNCTION__.56253> "cleanup_event_report_unsolicited_events", message=<optimized out>) at ../glib/gtestutils.c:2878
#3 0x00007ffff781a96f in g_assertion_message_expr
(domain=domain@entry=0x0, file=file@entry=0x507aad "mm-bearer-qmi.c", line=line@entry=1138, func=func@entry=0x5088e0 <__FUNCTION__.56253> "cleanup_event_report_unsolicited_events", expr=expr@entry=0x507ae5 "*indication_id != 0") at ../glib/gtestutils.c:2904
#4 0x00000000004a0c49 in cleanup_event_report_unsolicited_events (client=<optimized out>, indication_id=0x5bb30c, self=<optimized out>)
at mm-bearer-qmi.c:1138
#5 0x00000000004a0c49 in cleanup_event_report_unsolicited_events
(client=<optimized out>, indication_id=indication_id@entry=0x5bb30c, self=0x5bb420 [MMBearerQmi]) at mm-bearer-qmi.c:1132
#6 0x00000000004a0ee3 in disconnect_context_step (task=0x7fffe8012100 [GTask]) at mm-bearer-qmi.c:1854
#7 0x000000000046e889 in disconnect_auth_ready (self=<optimized out>, res=<optimized out>, ctx=ctx@entry=0x654630)
at mm-iface-modem-simple.c:865
#8 0x00007ffff79cfa9a in g_task_return_now (task=0x7fffe8012640 [GTask]) at ../gio/gtask.c:1209
...
Add checks for indication_id to calls to
cleanup_event_report_unsolicited_events() on
DISCONNECT_STEP_STOP_NETWORK_IPV4 or DISCONNECT_STEP_STOP_NETWORK_IPV6, as
is done elsewhere.
If we cancel connect_cancellable, the connect task will return a
G_IO_ERROR_CANCELLED. We may need to do some cleanup (like, disconnect
if the connection went far enough to actually start the network
connection), thus it's important we check for cancellation correctly.
Some modems (Namely: Telit LE910 V2) report nonzero NwError code,
outside of 3GPP TS 24.008 - in "register-state set command-done" response,
while status code equals MBIM_STATUS_ERROR_NONE.
In such cases network is operational.
According to MBIM specification 1.0 table 10.5.9.8 "Status codes",
NwError shall be nonzero only if Status Code equals MBIM_STATUS_FAILURE,
and client shall parse NwError only in such cases.
Also, MBIM specification does not explicitly state that 'NwError == 0' equals
no error, rather than that it is unknown error, hence raise an error
unconditionally if MBIM status code is MBIM_STATUS_FAILURE.
Therefore, check NwError IFF MBIM response status code equals
MBIM_STATUS_FAILURE, instead of MBIM_STATUS_SUCCESS.
Fixes: 854c371c8a ("broadband-modem-mbim: implement 3GPP registration request")
Signed-off-by: Lech Perczak <l.perczak@camlintechnologies.com>
This patch fixes a potential memory leak in
mm_3gpp_parse_pdu_cmgl_response() where the allocated MM3gppPduInfo may
be leaked when failing to parse the +CMGL response.
By default the build used -Wno-unused-but-set-variable but that's
clearly not what we want. Fix those problems.
When using clang, the compiler doesn't error on unknown compile
options, so let's add -Werror to the checking too.
CC='clang'
configure:3408: checking for gcc
configure:3435: result: clang
...
configure:17644: checking whether gcc understands -Wno-unused-but-set-variable
configure:17657: clang -c -Wall -std=gnu89 -g -O2 -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wstrict-prototypes -Wno-unused-parameter -Wno-sign-compare -Wno-deprecated-declarations -Wno-unused-but-set-variable conftest.c >&5
warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
1 warning generated.
configure:17657: $? = 0
configure:17666: result: yes
Reported-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
In addition to any installed MCFG file, the firmware itself as a
'default' config that will be selected when no carrier config is
installed.
So it is not an error if 'QMI PDC Get Selected Config' doesn't return
the 'Active ID' TLV, it just means the default one is selected.
Which reports the version of the currently active carrier
configuration.
We also update the firmware 'version' reported in the firmware
settings so that carrier-specific upgrades can be performed (e.g. when
the firmware stays the same but the MCFG is updated).
During initialization phase we will allow querying the modem for the
details of which carrier-specific configuration is being used, and
will expose a description string in the API.
In addition to showing the current configuration, we will also allow
automatically switching the configuration based on the SIM card
detected in the device. In order to allow this, plugins/modems will
need to provide the expected mapping between carrier config
description and MCCMNC. This mapping cannot be generic, because
different manufacturers may use different description strings.
If ModemManager fails to open a QMI port with data format update, it
retries without update. It would be useful to log the reason why the
first try failed; for example on RHEL 7.6 ModemManager fails to write
to sysfs due to SELinux. With this commit, the following message would
be logged:
<debug> QMI port open operation finished
<debug> Couldn't open QMI port with data format update: Expected data
format not updated properly: Failed to open file
'/sys/class/net/wwp0s29u1u2i8/qmi/raw_ip' for R/W: Permission denied
<debug> Opening QMI device...
instead of just:
<debug> QMI port open operation finished
<debug> Opening QMI device...
While at it, also fix the GError leak.
When the MBIM port open involved transparently trying to open a QMI
device as well, we were clearing the progress flag before the full
operation had finished, and so the port could have been closed by
the time we really finish the open operation, leading to a crash:
ModemManager[28824]: <info> [1547386038.726136] (usbmisc/cdc-wdm3): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.728084] (tty/ttyUSB0): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.728738] (tty/ttyUSB1): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.730769] (tty/ttyUSB2): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.731256] (tty/ttyUSB3): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <debug> [1547386038.731301] Removing empty device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <debug> [1547386038.731445] (ttyUSB0) forced to close port
ModemManager[28824]: <debug> [1547386038.731547] (ttyUSB1) forced to close port
ModemManager[28824]: <debug> [1547386038.731638] (ttyUSB2) forced to close port
ModemManager[28824]: <debug> [1547386038.731715] (ttyUSB3) forced to close port
ModemManager[28824]: <debug> [1547386039.580136] [cdc-wdm3] error: couldn't open QmiDevice: MBIM error: Transaction timed out
ModemManager[28824]: <info> [1547386039.580190] [cdc-wdm3] MBIM device is not QMI capable
**
ERROR:mm-broadband-modem-mbim.c:2119:track_mbim_device_removed: assertion failed: (device)
Thread 1 "ModemManager" received signal SIGABRT, Aborted.
0x00007ffff7390d7f in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7390d7f in raise () at /usr/lib/libc.so.6
#1 0x00007ffff737b672 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff7559042 in () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff75865dc in g_assertion_message_expr () at /usr/lib/libglib-2.0.so.0
#4 0x00005555556407f9 in track_mbim_device_removed (self=0x5555557a2830, mbim=0x5555557ea190) at mm-broadband-modem-mbim.c:2119
#5 0x000055555564093e in mbim_port_open_ready (mbim=0x5555557ea190, res=0x55555573fcf0, task=0x5555557d29d0) at mm-broadband-modem-mbim.c:2161
#6 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#7 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#8 0x000055555565fcd5 in qmi_device_open_ready (dev=0x55555578f250, res=0x55555573fb50, task=0x55555573fcf0) at mm-port-mbim.c:191
#9 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#10 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#11 0x00007ffff7c03fe6 in open_version_info_ready (client_ctl=0x7fffe8010c20, res=0x555555739e80, task=0x55555573fb50) at qmi-device.c:2050
#12 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#13 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#14 0x00007ffff7c2034f in get_version_info_ready (device=0x55555578f250, res=0x5555557ea2a0, task=0x555555739e80) at qmi-ctl.c:3746
#15 0x00007ffff778ebcf in g_simple_async_result_complete () at /usr/lib/libgio-2.0.so.0
#16 0x00007ffff778ec5a in () at /usr/lib/libgio-2.0.so.0
#17 0x00007ffff75a98d1 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#18 0x00007ffff75ab5e9 in () at /usr/lib/libglib-2.0.so.0
#19 0x00007ffff75ac5c2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#20 0x0000555555599eb0 in main (argc=2, argv=0x7fffffffe4c8) at main.c:181
This new method allows users of the ModemManager API to take full
control of a given device.
Unlike other operations in the API, the inhibition is maintained as
long as the caller exists in the bus, or until the same caller
uninhibits the device.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/98
Since the Firmware interface now contains more actions and properties
apart from List() and Select(), these two actions are now optional.
Not all modems implementing the Firmware interface must implement
these two methods.
We no longer "check for support" of this interface, it will always be
available for all modem objects.
The only implementation that used this interface was the QMI one, and
only for a very small subset of devices (those supporting the "QMI DMS
List Stored Images" operation). The logic was changed so that the list
of stored images wasn't preloaded during the support check; it will
now instead be preloaded during the first call to List().
Ben Chan
Aleksander Morgado
Lubomir Rintel
yparitcher
Lech Perczak
Dan Williams
Daniele Palmas
Beniamino Galvani