- Sep 12, 2019
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
If there is one registration state which is denied and the remaining ones are either unknown or idle, then report denied. (cherry picked from commit 417c0ed8)
-
Aleksander Morgado authored
(cherry picked from commit e9f5700d)
-
Aleksander Morgado authored
(cherry picked from commit d9615bfc)
-
Aleksander Morgado authored
The first two ports are AT control ports (application/modem). We rely on AT^SQPORT to decide which one is which. The last two ports are unknown and we explicitly ignore them to make port probing much quicker. (cherry picked from commit 0f8580f3)
-
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com> (cherry picked from commit c61bd846)
-
Aleksander Morgado authored
Do not wait until all parts are received in order to initialize all fields that are common to all parts in the SMS message, do it as soon as the first part is received. mobile-broadband/ModemManager#137 (cherry picked from commit 0c921bbc)
-
ussd_decode() expects a non-null GByteArray while process_ussd_message() could potentially passes a null GByteArray to ussd_decode(). This patch fixes the issue by having process_ussd_message() always creates a GByteArray. (cherry picked from commit 5efa15b8)
-
For devices which do not provide feature_extended_lte_band_preference mm_modem_bands_to_qmi_band_preference() gets called from mm_shared_qmi_set_current_bands() with extended_qmi_lte_bands set to NULL which may cause a SIGSEGV in the memset() call in mm_modem_bands_to_qmi_band_preference(). Avoid this by checking whether extended_qmi_lte_bands is non-NULL before calling memset(). Reported-by: Nick <mips171@icloud.com> (cherry picked from commit f2c878e7)
-
mm_firmware_update_settings_get_variant() checks for a null `self' pointer when accessing `self->priv->method', but doesn't perform the null check when accessing other members of MMFirmwareUpdateSettingsPrivate. This patch fixes mm_firmware_update_settings_get_variant() to fully handle a null `self' pointer. (cherry picked from commit c6cf7cf0)
-
Aleksander Morgado authored
(cherry picked from commit edac8c37)
-
Aleksander Morgado authored
As suggested by Paul Bartell <paul.bartell@gmail.com> (cherry picked from commit b0ec3030)
-
Aleksander Morgado authored
If the signal is automatically disconnected during object disposal, we shouldn't explicitly try to disconnect it ourselves during finalize(). Reported by: Lubomir Rintel <lkundrak@v3.sk> (cherry picked from commit f684c713)
-
Aleksander Morgado authored
Several plugins define the specific device vid:pid pairs they support. Let's use this information as a direct indication that ModemManager can probe the devices. (cherry picked from commit 51c46264)
-
Aleksander Morgado authored
Instead of blindly allowing to be probed all ttyACM ports that report them as AT-capable, we will now instead forbid all ttyACM ports that don't report themselves as AT-capable. Also, require the modem to expose other additional ports (of any kind usable by ModemManager) in addition to the AT-capable ttyACM port. This update should avoid automatically probing Arduino devices that wrongly report their exposed single ttyACM port as AT-capable. https://github.com/arduino/ArduinoCore-avr/pull/92 mobile-broadband/ModemManager#140 mobile-broadband/ModemManager#127 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930264 (cherry picked from commit 0e02771e)
-
Aleksander Morgado authored
Several plugins define specific udev tags that must be available in the device in order for the plugins to use them. Let's use these tags as a direct indication that ModemManager can probe the devices. In particular, this change would make all Ericsson MBM modems probed right away also in STRICT filter mode, without needing to check the ttyACM interface type or the available net ports. (cherry picked from commit c1257579)
-
Aleksander Morgado authored
(cherry picked from commit a45508ba)
-
- Sep 11, 2019
-
-
If the reopening operation fails when attempting to recover the previous open count, it could mean the port is already gone. We didn't get a HUP in the TTY because the channel I/O monitoring isn't in place during this time, so this is the best way to detect that at this point. And if we do see an error, we'll flag the port as forced closed so that we do not attempt to reopen it again. ModemManager[4219]: <debug> [1568123246.421399] Disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0' ModemManager[4219]: <info> [1568123246.421465] Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connected -> disconnecting) ModemManager[4219]: <debug> [1568123246.421698] Reopening data port (modemu)... ModemManager[4219]: <debug> [1568123246.421722] (modemu) reopening port (2) ModemManager[4219]: <debug> [1568123246.421740] (modemu) device open count is 1 (close) ModemManager[4219]: <debug> [1568123246.421754] (modemu) device open count is 0 (close) ModemManager[4219]: <debug> [1568123246.421770] (modemu) closing serial port... ModemManager[4219]: <debug> [1568123246.421786] (modemu): port now disconnected ModemManager[4219]: <debug> [1568123246.421816] (modemu) serial port closed ModemManager[4219]: <info> [1568123248.028573] (tty/modemu): released by device '/sys/devices/pci0000:00/0000:00:00.0' ModemManager[4219]: <debug> [1568123248.028637] Removing empty device '/sys/devices/pci0000:00/0000:00:00.0' ModemManager[4219]: <debug> [1568123248.028866] Removing from DBus bearer at '/org/freedesktop/ModemManager1/Bearer/0' ModemManager[4219]: <debug> [1568123248.028914] [device /sys/devices/pci0000:00/0000:00:00.0] unexported modem from path '/org/freedesktop/ModemManager1/Modem/0' ModemManager[4219]: <debug> [1568123248.028944] Periodic signal checks disabled ModemManager[4219]: <debug> [1568123256.401738] Connection monitoring is unsupported by the device ModemManager[4219]: <debug> [1568123256.422939] (modemu) opening serial port... ModemManager[4219]: <warn> [1568123256.423062] (modemu) could not open serial device (2) ModemManager[4219]: <debug> [1568123256.423104] Couldn't disconnect bearer '/org/freedesktop/ModemManager1/Bearer/0': Couldn't reopen port (0): Could not open serial device modemu: No such file or directory ModemManager[4219]: _close_internal: assertion 'self->priv->open_count > 0' failed Thread 1 "ModemManager" received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff77894e6 in ?? () from /usr/lib/libglib-2.0.so.0 (gdb) (gdb) bt #0 0x00007ffff77894e6 in () at /usr/lib/libglib-2.0.so.0 #1 0x00007ffff7789738 in g_logv () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff777ff80 in g_log () at /usr/lib/libglib-2.0.so.0 #3 0x0000555555661115 in _close_internal (self=0x555555796380, force=0) at mm-port-serial.c:1378 #4 0x0000555555661865 in mm_port_serial_close (self=0x555555796380) at mm-port-serial.c:1503 #5 0x00005555556078cc in ports_context_unref (ctx=0x5555557c4ca0) at mm-broadband-modem.c:9801 #6 0x000055555560e33a in finalize (object=0x5555557a4250) at mm-broadband-modem.c:11940 #7 0x00007ffff787b351 in g_object_unref () at /usr/lib/libgobject-2.0.so.0 #8 0x00005555555b1c71 in detailed_disconnect_context_free (ctx=0x555555785000) at mm-broadband-bearer.c:1369 #9 0x00007ffff795d62a in () at /usr/lib/libgio-2.0.so.0 #10 0x00007ffff787b351 in g_object_unref () at /usr/lib/libgobject-2.0.so.0 #11 0x00005555555b2532 in data_reopen_3gpp_ready (data=0x555555796380, res=0x55555573a580, task=0x55555573a040) at mm-broadband-bearer.c:1605 #12 0x00007ffff795d584 in () at /usr/lib/libgio-2.0.so.0 #13 0x00007ffff7962a87 in () at /usr/lib/libgio-2.0.so.0 #14 0x0000555555661bc6 in reopen_do (self=0x555555796380) at mm-port-serial.c:1607 #15 0x00007ffff778e3c4 in () at /usr/lib/libglib-2.0.so.0 #16 0x00007ffff778ebb0 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #17 0x00007ffff7790b11 in () at /usr/lib/libglib-2.0.so.0 #18 0x00007ffff7791a63 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #19 0x000055555559afb0 in main (argc=3, argv=0x7fffffffea58) at main.c:181 (cherry picked from commit 2a8d2029)
-
We cannot complete the flash task cancellation right away because this may be called from within _close_internal() during a forced port close after the TTY has gone, which would mean the object is fully disposed already after the flash cancellation has been requested. By making the task cancellation complete in idle, we're sure that there will be at least one reference valid (the one in the task) during the port close operation. ModemManager[25156]: <debug> [1568121341.696563] Modem (Generic) '/sys/devices/pci0000:00/0000:00:00.0' completely disposed ** ERROR:mm-port-serial.c:2067:finalize: assertion failed: (self->priv->iochannel == NULL) (gdb) bt #0 0x00007ffff757c755 in raise () at /usr/lib/libc.so.6 #1 0x00007ffff7567851 in abort () at /usr/lib/libc.so.6 #2 0x00007ffff7741062 in () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff776d99d in g_assertion_message_expr () at /usr/lib/libglib-2.0.so.0 #4 0x0000555555662f0a in finalize (object=0x55555577a380) at mm-port-serial.c:2067 #5 0x0000555555664d81 in finalize (object=0x55555577a380) at mm-port-serial-at.c:632 #6 0x00007ffff787b351 in g_object_unref () at /usr/lib/libgobject-2.0.so.0 #7 0x00007ffff795d5eb in () at /usr/lib/libgio-2.0.so.0 #8 0x00007ffff787b351 in g_object_unref () at /usr/lib/libgobject-2.0.so.0 #9 0x0000555555662126 in mm_port_serial_flash_cancel (self=0x55555577a380) at mm-port-serial.c:1747 #10 0x0000555555661224 in _close_internal (self=0x55555577a380, force=1) at mm-port-serial.c:1397 #11 0x000055555566197b in port_serial_close_force (self=0x55555577a380) at mm-port-serial.c:1526 #12 0x000055555565fbe5 in common_input_available (self=0x55555577a380, condition=(G_IO_IN | G_IO_ERR | G_IO_HUP)) at mm-port-serial.c:971 #13 0x00005555556600c0 in iochannel_input_available (iochannel=0x55555578a0a0, condition=(G_IO_IN | G_IO_ERR | G_IO_HUP), data=0x55555577a380) at mm-port-serial.c:1073 #14 0x00007ffff778ebb0 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #15 0x00007ffff7790b11 in () at /usr/lib/libglib-2.0.so.0 #16 0x00007ffff7791a63 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #17 0x000055555559afb0 in main (argc=3, argv=0x7fffffffea58) at main.c:181 (cherry picked from commit 25011ec7)
-
- Sep 04, 2019
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the internal blacklist of devices shipped by ModemManager when running in either DEFAULT or PARANOID filter modes. The name of the tag is extremely misleading because it doesn't really make the full device be ignored, the tag only applied to TTY ports. This commit repurposes the tag so that it applies to ANY kind of port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type (i.e. also applicable in STRICT mode). The internal blacklist shipped by ModemManager, which should NOT be used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST. The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its name is really meaningful. If there are users or third-party projects adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name, they should have no problem as the new rule is more restrictive than the old one. (cherry picked from commit 250639e3)
-
- Aug 05, 2019
-
-
Aleksander Morgado authored
Never automatically flag the bearer as disconnected if it's using PPP, because we could end up using the TTY at the same time as pppd, with the wrong CLOCAL settings. So, whenever we detect that the bearer requires PPP, we will ignore all disconnection reports generated by ModemManager itself. (cherry picked from commit 5f29bd64)
-
- Jul 04, 2019
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
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: 854c371c ("broadband-modem-mbim: implement 3GPP registration request") Signed-off-by: Lech Perczak <l.perczak@camlintechnologies.com> (cherry picked from commit 7a6e9272)
-
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. (cherry picked from commit 50fc46c1)
-
- Jun 24, 2019
-
-
Aleksander Morgado authored
mobile-broadband/ModemManager#131 (cherry picked from commit d1b716ab)
-
- Jun 13, 2019
-
-
Aleksander Morgado authored
(cherry picked from commit ca5f2e8b)
-
Aleksander Morgado authored
If load_current_bands_finish() returns a NULL GArray, we must set the GError or otherwise the daemon will segfault when the caller dereferences the GError: current_bands = MM_IFACE_MODEM_GET_INTERFACE (self)->load_current_bands_finish (self, res, &error); if (!current_bands) { /* Errors when getting current bands won't be critical */ mm_warn ("couldn't load current Bands: '%s'", error->message); g_error_free (error); } This may happen with an empty but balid +UACT response, e.g.: AT+UACT? +UACT: ,,, OK Or when it replies a full empty string: AT+UACT? OK (cherry picked from commit 20c5d7fd)
-
- Jun 10, 2019
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
- Jun 03, 2019
-
-
Aleksander Morgado authored
ttyUSB0 (if #0): QCDM/DIAG port ttyUSB1 (if #1): GPS data port ttyUSB2 (if #2): AT primary port ttyUSB3 (if #3): AT secondary port (cherry picked from commit 8ec9789e)
-
Aleksander Morgado authored
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>' (cherry picked from commit 72bdb1b3)
-
Aleksander Morgado authored
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). (cherry picked from commit 8092e301)
-
- May 10, 2019
-
-
Aleksander Morgado authored
So that clients are able to have the full updated list before the list update notification. (cherry picked from commit 7753eb00)
-
- May 06, 2019
-
-
(cherry picked from commit d56bc301)
-
- Apr 15, 2019
-
-
Aleksander Morgado authored
Reported by: Enrico Mioso <mrkiko.rs@gmail.com> (cherry picked from commit de1ae549)
-