| Age | Commit message (Collapse) | Author |
|---|
|
Otherwise your logs fill up if the signal quality changes, which is
pretty frequently for many devices.
|
|
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
|
|
Some firmware version sends quotes around SIMREFRESH, this patch adds support
for those versions.
|
|
|
|
|
|
|
|
If a task is marked as defer-until-suggested (e.g. a wwan port) and there was
already a 'best' plugin set in the parent device, use it to complete the
deferred task.
This may happen in e.g. MBIM devices if the WWAN port arrives later than the
already probed /dev/cdc-wdm character device.
|
|
A device like this shows up briefly while the Sierra EM7345 is booting:
P: Vendor=8087 ProdID=0716 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
We do have a driver identifying this as an "Infineon Flashloader"
device. It is not a modem in any case, and should be ignored.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
|
|
If the initialization of the Modem3gpp / ModemCdma interface fails, the
modem transitions to the FAILED state. But since the Modem interface is
already initialized and exported over DBus, it is possible to invoke the
Enable method on the Modem interface. This patch changes
MMBroadbandModem to report an error if one tries to enable the modem in
the FAILED state instead of raising an assertion.
|
|
This patch fixes memory leaks in PCO parsing code detected by LeakSanitizer.
|
|
This patch fixes memory leaks in unit tests detected by LeakSanitizer.
|
|
|
|
Due to a firmware issue, the modem may reply an invalid band value, such
as 0, for the %BANDCAP or %GETCFG="BAND" command. This patch moves
parse_bands_response() to mm-modem-helpers-altair-lte.c, modifies the
function to ignore any invalid band outside the range of E-UTRAN
operating bands, and add unit tests for the function.
|
|
E-UTRAN operating band 44 is specified in 3GPP release 11 (see Table
5.5-1 "E-UTRA operating bands" in 3GPP TS 36.101 version 11.2.0 Release
11).
|
|
|
|
|
|
This patch modifies the Altair LTE plugin to fail connect requests while the
modem has detached from the network when processing sim refresh.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This patch refines the access technology updates on a MBIM modem by
observing the MBIM_CID_PACKET_SERVICE notifications in addition to the
MBIM_CID_REGISTER_STATE notifications. If a MBIM_CID_PACKET_SERVICE
notification indicates the highest available data class, the current
access technology is updated to reflect that. Otherwise, the access
technology is updated according to the available data classes indicated
by a MBIM_CID_REGISTER_STATE notification.
|
|
We can use these to return better error messages if an operator
does not support the default subscription APN functionality,
and the user does not give us an APN.
|
|
If the APN was empty (implying that the modem/network should choose
the default APN) this caused an assertion in libqmi. Just don't
set an APN if we aren't given one.
|
|
In mm_modem_messaging_get_supported_storages(), initialize array to avoid a
potential crash with an uninitialized value, and a build failure due to
mm-modem-messaging.c:168:24: error: 'array' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
*n_storages = array->len;
https://bugzilla.gnome.org/show_bug.cgi?id=729267
|
|
OFF only applies to a real shutdown, where the modem no longer replies.
|
|
The Huawei plugin uses +CFUN=0 to put the modem in low power mode as
+CFUN=4 isn't supported by all Huawei modems. This patch modifies the
plugin to treat CFUN 0 as the 'LOW' power state, which is necessary as
otherwise ModemManager would prevent the modem from transitioning to the
'ON' power state.
|
|
|
|
|
|
The 3s wait before opening a MBIM port is not necessary for handling a
delayed response to the MBIM OPEN messages. mbim_device_open() already
retries the MBIM OPEN message when the MBIM device does not respond.
|
|
products.
We make many USB virtual COM port devices, none of which are modems.
ModemManager's automatic attempts to access those devices can cause
problems.
That might change in the future, so we have left two potential
future product IDs off of the blacklist.
|
|
(ttyUSB0): --> 'AT$NWRSSI<CR>'
(ttyUSB0): <-- '<CR><LF><CR><CR><LF> HDR RSSI= 93<CR><LF><CR><LF><CR><LF>OK<CR><LF>
|
|
|
|
This patch modifies MMBearerMbim to update the MTU value in the bearer
IPv4 and IPv6 config property when such information is available in the
MBIM_CID_IP_CONFIGURATION response.
|
|
|
|
This patch adds a 'mtu' value to the Ip4Config and Ip6Config property of
a Bearer object, which indicates the value of the maximum transmission
unit for the established connection when such information is available
(e.g. via QMI_WDS_GET_RUNTIME_SETTINGS on a QMI modem or
MBIM_CID_IP_CONFIGURATION on a MBIM modem).
|
|
|
|
|
|
|
|
This patch removes an extra invocation of g_simple_async_result_complete
on the result associated with each command context in the command queue
when mm_port_serial_close clears the queue. It also changes the code to
complete the results in idle, which avoids a nested invocation of
mm_port_serial_close. That could happen if the completion of the result
calls mm_port_serial_close again (e.g. via at_command_context_free,
at_sequence_context_free in mm-base-modem-at.c). The nested invocation
of mm_port_serial_close could create undesirable effects (e.g. the
assertion on open_count > 0 fails in case of a forced close).
|
|
This patch fixes the following crash, which happens when
MMBroadbandBearer tries to parse the NULL response of a failed +CGDCONT?
query. It also fixes a leak in parse_pdp_list where it fails to free the
GError object return by mm_3gpp_parse_cgdcont_read_response.
Thread 0 *CRASHED* ( SIGSEGV @ 0x00000000 )
0x7feb15564c11 [ModemManager] - mm-modem-helpers.c:850 mm_3gpp_parse_cgdcont_read_response
0x7feb15518e51 [ModemManager] - mm-broadband-bearer.c:927 parse_pdp_list
0x7feb1551ada2 [ModemManager] - mm-base-modem-at.c:189 at_sequence_parse_response
0x7feb151d4b86 [libgio-2.0.so.0.3400.3] - gsimpleasyncresult.c:775 g_simple_async_result_complete
0x7feb1556e223 [ModemManager] - mm-port-serial-at.c:355 serial_command_ready
0x7feb151d4b86 [libgio-2.0.so.0.3400.3] - gsimpleasyncresult.c:775 g_simple_async_result_complete
0x7feb1556a834 [ModemManager] - mm-port-serial.c:141 command_context_complete_and_free
0x7feb1556bc26 [ModemManager] - mm-port-serial.c:734 port_serial_got_response
0x7feb1556c51a [ModemManager] - mm-port-serial.c:758 port_serial_timed_out
0x7feb1508cc33 [libglib-2.0.so.0.3400.3] - gmain.c:4026 g_timeout_dispatch
0x7feb1508c087 [libglib-2.0.so.0.3400.3] - gmain.c:2715 g_main_context_dispatch
0x7feb1508c437 [libglib-2.0.so.0.3400.3] - gmain.c:3290 g_main_context_iterate
0x7feb1508c891 [libglib-2.0.so.0.3400.3] - gmain.c:3484 g_main_loop_run
0x7feb1550ad16 [ModemManager] - main.c:154 main
0x7feb14a9e9c6 [libc-2.15.so] - libc-start.c:234 __libc_start_main
0x7feb1550a808 [ModemManager + 0x00023808
|
|
|
|
AT+COPS=0 in a FXT009 may end up making the device stuck in a weird state
in which it only replies "+CME ERROR: 515" to every AT command. So try to
avoid this command whenever possible.
|
