Skip to content
Snippets Groups Projects
  1. Sep 12, 2019
  2. Sep 11, 2019
    • Aleksander Morgado's avatar
      port-serial: force-close the port if reopen fails · 891fccd2
      Aleksander Morgado authored and Aleksander Morgado's avatar Aleksander Morgado committed
      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)
      891fccd2
    • Aleksander Morgado's avatar
      port-serial: flash cancellation always completed in idle · d432bdda
      Aleksander Morgado authored and Aleksander Morgado's avatar Aleksander Morgado committed
      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)
      d432bdda
  3. Sep 04, 2019
    • Aleksander Morgado's avatar
    • Aleksander Morgado's avatar
      udev: repurpose ID_MM_DEVICE_IGNORE and new MM_FILTER_RULE_EXPLICIT_BLACKLIST · dd9f23fd
      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)
      dd9f23fd
  4. Aug 05, 2019
  5. Jul 04, 2019
    • Aleksander Morgado's avatar
      8c4d9ef0
    • Aleksander Morgado's avatar
      release: bump version to 1.10.4 · 4fc7296b
      Aleksander Morgado authored
      1.10.4
      4fc7296b
    • Aleksander Morgado's avatar
      NEWS: update for 1.10.4 · 890d3928
      Aleksander Morgado authored
      890d3928
    • Lech Perczak's avatar
      broadband-modem-mbim: parse nw_error in register_state_set_ready only if MBIM_STATUS_FAILURE · 34025593
      Lech Perczak authored and Aleksander Morgado's avatar Aleksander Morgado committed
      
      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: default avatarLech Perczak <l.perczak@camlintechnologies.com>
      (cherry picked from commit 7a6e9272)
      34025593
    • Lubomir Rintel's avatar
      bearer-qmi: do not call cleanup_event_report_unsolicited_events() w/o indication_id · fae089b7
      Lubomir Rintel authored and Aleksander Morgado's avatar Aleksander Morgado committed
      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)
      fae089b7
  6. Jun 24, 2019
  7. Jun 13, 2019
    • Aleksander Morgado's avatar
      ublox,tests: expect error if empty band list when parsing UACT? · d9e49239
      Aleksander Morgado authored
      (cherry picked from commit ca5f2e8b)
      d9e49239
    • Aleksander Morgado's avatar
      ublox: return error when no bands are parsed · 6e0a32bf
      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)
      6e0a32bf
  8. Jun 10, 2019
  9. Jun 03, 2019
    • Aleksander Morgado's avatar
      quectel: add port type hints for the Quectel LTE-A EG06 · f44df511
      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)
      f44df511
    • Aleksander Morgado's avatar
      port-serial-at: raw commands always run next · 5da06d67
      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)
      5da06d67
    • Aleksander Morgado's avatar
      port-serial: allow deciding whether the command is queued last or run next · c4346342
      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)
      c4346342
  10. May 10, 2019
  11. May 06, 2019
  12. Apr 15, 2019
Loading