Based on a patch from: Bjørn Mork <bjorn@mork.no>
Some messages provide an additional NwError cause code from
the network in case of failure. This means that we need to
parse the reply even if the status indicates failure, to be
able to return the exact failure cause.
When wait_for_final_state_context_complete_and_free is invoked, if the callback
associated with the GSimpleAsyncResult object of the WaitForFinalStateContext
object updates the modem state via mm_iface_modem_update_state, state_changed
is invoked, which causes wait_for_final_state_context_complete_and_free to be
invoked again on the same WaitForFinalStateContext object. That leads to the
following crash, which is observed sometimes when a modem is being disabled.
Thread 0 *CRASHED* ( SIGSEGV @ 0x00000000 )
0x7fcb7728f202 [libgobject-2.0.so.0.3400.3] - gobject.c:2916 g_object_unref
0x7fcb7743205c [ModemManager] - mm-broadband-modem.c:8034 disabling_context_complete_and_free
0x7fcb77434d64 [ModemManager] - mm-broadband-modem.c:8130 disabling_wait_for_final_state_ready
0x7fcb770c0b86 [libgio-2.0.so.0.3400.3] - gsimpleasyncresult.c:775 g_simple_async_result_complete
0x7fcb7740cdbc [ModemManager] - mm-iface-modem.c:101] wait_for_final_state_context_complete_and_free
0x7fcb7740ce19 [ModemManager] - mm-iface-modem.c:128] state_changed_wait_expired
0x7fcb76f78c33 [libglib-2.0.so.0.3400.3] - gmain.c:4026] g_timeout_dispatch
0x7fcb76f78087 [libglib-2.0.so.0.3400.3] - gmain.c:2715] g_main_context_dispatch
0x7fcb76f78437 [libglib-2.0.so.0.3400.3] - gmain.c:3290] g_main_context_iterate
0x7fcb76f78891 [libglib-2.0.so.0.3400.3] - gmain.c:3484] g_main_loop_run
0x7fcb773f4d55 [ModemManager] - main.c:142] main
0x7fcb7698a9c6 [libc-2.15.so] - libc-start.c:234] __libc_start_main
0x7fcb773f48b8 [ModemManager] + 0x000218b8]
This patch addresses a potential memory leak when load_sim_identifier or
load_imsi in MMSimMbim is called but the caller does not provide a
GAsyncReadyCallback.
This patch addresses a potential memory leak when scan_networks in
MMBroadbandModemMbim is called but the caller does not provide a
GAsyncReadyCallback.
Reported by Aleksander Morgado <aleksander@lanedo.com>
This patch addresses a potential memory leak when
load_operator_identifier or load_operator_name in MMSimMbim is called
but the caller does not provide a GAsyncReadyCallback.
Reported by Aleksander Morgado <aleksander@lanedo.com>
Some Huawei modems (e.g. E220) may give an empty response for AT^SYSCFG=?, even
if they do support the command. Handle this case by prividing a default fallback
format string when this happens.
On at least the EC168C, various unsolicited responses like RSSILVL,
HRSSILVL, and MODE can include an extra Carriage Return:
^MODE: 2<CR><CR><LF><CR><CR><LF>
^RSSILVL:60<CR><CR><LF><CR><CR><LF>
Some Qualcomm firmwares disable IPv6 unless this flag is set in nvram, at
least for the LTE default bearer. The firmware will happily let you
configure the IPV6 and IPV4V6 PDP types, also including the default
profile, but any attempt to connect will fail.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
If the bearer doesn't have one of IPv4 or IPv6 configuration, then the
qmi_message_wds_get_current_settings_output_get_ip*_address() functions
will return FALSE with a filled error, which was not cleared.
This fixes a glib warning message about overwriting an already-filled
GError.
A firmware bug in Altair ALT3100 bricks the modem when
- The modem is out of coverage (Registration state is unknown (CEREG: 4))
- A disconnect attempt is made using the AT%DPDNACT command.
This patch prevents this situation by failing the connect/disconnect attempts in
the altair plugin when registration state is unknown, without attempting to
connect/disconnect the modem.
Some MMBearer methods to disconnect the bearer assume that the bearer is
disconnected even if the operation fails in a subclass. This leaves MMBearer
and MMBroadbandBearer states out of sync.
This patch notifies the bearer object of the final disconnection using
mm_bearer_report_connection_status. This gives the subclasses a chance to update
their state even when the disconnection attempt fails.
As soon as we get a match between the current interface being probed, and the
first expected interface to probe, clear the timeout. But this doesn't mean that
this interface being probed will be the correct one, so it may be the case that
we end up expecting a new first interface and probing another one.
With an example probably seen better...
Modem appears with interfaces 2, 3 and 4.
1. We first try to look for interface 0, which is not in the set:
1.1. Probing interfaces 2, 3 and 4 get deferred.
2. First-interface timeout happens because interface 0 doesn't appear, so we
switch to wait for interface 1:
2.1 Probing interfaces 2, 3 and 4 get deferred.
3. First-interface timeout happens because interface 1 doesn't appear, so we
switch to wait for interface 2:
3.1. We get a match on interface 2, which exists. We now remove the
first-interface timeout and start running the init sequence there.
3.2. Probing interfaces 3 and 4 get deferred.
4. Init sequence in interface 2 fails, because it is not an AT port, so we
switch to wait for interface 3:
3.1. We get a match on interface 3, which exists. We do *not* need to remove
now the first-interface timeout because this interface we are testing is
actually the second one which we tried.
So, just check whether the timeout exists or not, and if it exists remove it.
Yeah, this commit just fixes a warning at the end.
When running the pre-probing VID/PID filters, the ports were not filtered out if
the plugin had configured post-probing vendor/product string filters. But, these
post-probing filters are only applicable to AT ports.
From now on, this logic will not be applied to non-serial ports. In other words,
pre-probing VID/PID filters applied to non-serial ports will always result in
the port being filtered out or being allowed, regardless of any additional
vendor/product string post-probing filter configured by the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=710437
Aleksander Morgado
Ben Chan
Dan Williams
Bjørn Mork
Thieu Le
Prathmesh Prabhu