aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-22base-modem: use g_steal_pointer() during disposeAleksander Morgado
g_steal_pointer() sets the original location to NULL already, so it's very handy.
2020-01-22base-modem: serial ports require 'timed-out' signal disconnection on cleanupAleksander Morgado
Fixes https://lists.freedesktop.org/archives/modemmanager-devel/2020-January/007686.html
2020-01-22base-modem: new helper method to cleanup ports during modem disposeAleksander Morgado
The different types of ports available in the modem will require different types of cleanup actions. E.g. QMI and MBIM ports need an explicit device close, and some other port types may need other cleanups.
2020-01-22port-qmi: asynchronous close operation alwaysAleksander Morgado
To be in sync with the qmi_device_close_async() underlying method, given that the synchronous one is deprecated.
2020-01-22port-qmi: use qmi_device_close_async() in the port open logicAleksander Morgado
The qmi_device_close() synchronous operation is deprecated.
2020-01-22port-mbim: use qmi_device_close_async()Aleksander Morgado
The qmi_device_close() synchronous operation is deprecated.
2020-01-22broadband-modem-qmi: no longer need QMI port cleanup in finalize()Aleksander Morgado
We're already doing it in dispose() since commit 00bb228472ff8669b1d60a251ac533a366e507cb.
2020-01-22base-modem: fix list iteration closing MBIM portsAleksander Morgado
The mm_port_mbim_close() operation needs 3 arguments explicitly, so make sure we provide the two additional ones as NULL.
2020-01-21build: add note for glib < 2.55.1Aleksander Morgado
2020-01-15libmm-glib: unconditionally define autoptr support for all typesAleksander Morgado
As we now depend on glib 2.48
2020-01-15altair-lte: use autoptr support from glibAleksander Morgado
2020-01-15build: bump minimum glib required version to 2.48Aleksander Morgado
2020-01-15broadband-modem-{qmi,mbim}: port cleanups always during dispose()Aleksander Morgado
If we need to disconnect signal handlers for the different port objects managed in the QMI/MBIM modems, we need to do that during dispose(), as there is no guarantee at all that the port objects will exist in the MMBaseModem by the time finalize() is run. ModemManager[4183]: <debug> [1579097652.255333] Modem (Sierra) '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8.4' completely disposed ModemManager[4183]: [/dev/cdc-wdm1] unexpected port hangup! ModemManager[4183]: [/dev/cdc-wdm1] channel destroyed ModemManager[4183]: <info> [1579097652.258186] Connection to mbim-proxy for /dev/cdc-wdm1 lost, reprobing (ModemManager:4183): GLib-GObject-WARNING **: 15:14:12.258: invalid unclassed pointer in cast to 'MMBaseModem' ModemManager[4183]: mm_base_modem_set_reprobe: assertion 'MM_IS_BASE_MODEM (self)' failed (ModemManager:4183): GLib-GObject-WARNING **: 15:14:12.258: invalid unclassed pointer in cast to 'MMBaseModem' ModemManager[4183]: mm_base_modem_set_valid: assertion 'MM_IS_BASE_MODEM (self)' failed ModemManager[4183]: [/dev/cdc-wdm1] unexpected port hangup! ModemManager[4183]: [/dev/cdc-wdm1] channel destroyed ModemManager[4183]: [/dev/cdc-wdm1] MBIM error: Cannot write message: Broken pipe ModemManager[4183]: [/dev/cdc-wdm1] MBIM error: Cannot write message: Broken pipe ModemManager[4183]: [/dev/cdc-wdm1] MBIM error: Cannot write message: Broken pipe ModemManager[4183]: [/dev/cdc-wdm1] MBIM error: Cannot write message: Broken pipe
2020-01-10iface-modem-location: fix big memleak when processing location updatesAleksander Morgado
The GVariants that we obtain during the processing of the "previous" dictionary with g_variant_iter_next() are full references, while the GVariants that we obtain processing the input MMLocationXX objects are floating references. The code was working well with the floating references only, as it was assumed that g_variant_builder_add() would take ownership of them as full references; but when the GVariant came from the g_variant_iter_next() processing, g_variant_builder_add() would take a full new extra reference, triggering the memory leak. Fix this, by making sure that we always work with full GVariant references in all cases, converting the floating ones with g_variant_ref_sink() and making sure we explicitly unref them after g_variant_builder_add(). ==3146== 112 (48 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 4,532 of 4,887 ==3146== at 0x483877F: malloc (vg_replace_malloc.c:309) ==3146== by 0x50D53DA: g_malloc (gmem.c:99) ==3146== by 0x50F19ED: g_slice_alloc (gslice.c:1024) ==3146== by 0x511D639: g_variant_alloc (gvariant-core.c:486) ==3146== by 0x511D6F9: g_variant_new_from_bytes (gvariant-core.c:529) ==3146== by 0x51146C3: g_variant_new_from_trusted (gvariant.c:326) ==3146== by 0x5115D28: g_variant_new_string (gvariant.c:1264) ==3146== by 0x48EC642: mm_location_3gpp_get_string_variant (mm-location-3gpp.c:294) ==3146== by 0x196350: build_location_dictionary (mm-iface-modem-location.c:162) ==3146== by 0x197E0C: handle_setup_auth_ready (mm-iface-modem-location.c:891) ==3146== by 0x4EC9160: g_task_return_now (gtask.c:1212) ==3146== by 0x4EC92AA: g_task_return (gtask.c:1281) ==3146== 41,658 (35,520 direct, 6,138 indirect) bytes in 740 blocks are definitely lost in loss record 4,887 of 4,887 ==3146== at 0x483877F: malloc (vg_replace_malloc.c:309) ==3146== by 0x50D53DA: g_malloc (gmem.c:99) ==3146== by 0x50F19ED: g_slice_alloc (gslice.c:1024) ==3146== by 0x511E02B: g_variant_get_child_value (gvariant-core.c:1093) ==3146== by 0x5114FA7: g_variant_get_variant (gvariant.c:748) ==3146== by 0x511B196: g_variant_valist_get_nnp (gvariant.c:4934) ==3146== by 0x511B87B: g_variant_valist_get_leaf (gvariant.c:5051) ==3146== by 0x511BFBF: g_variant_valist_get (gvariant.c:5232) ==3146== by 0x511C145: g_variant_valist_get (gvariant.c:5267) ==3146== by 0x511C953: g_variant_iter_next (gvariant.c:5667) ==3146== by 0x1962F5: build_location_dictionary (mm-iface-modem-location.c:128) ==3146== by 0x19659A: notify_gps_location_update (mm-iface-modem-location.c:231)
2020-01-10iface-modem-location: fix very very unlikely memory leakAleksander Morgado
2020-01-10iface-modem-location: assert if rewriting a variant during iterationAleksander Morgado
This should never ever happen, so assert
2020-01-09bearer-qmi: simplify dispose() just by reseting connection dataAleksander Morgado
2020-01-09bearer-qmi: plug memleak when disposing connected bearerAleksander Morgado
Also, explicitly close the QMI port if we had it open for the connected bearer. ==991919== 6,533 (48 direct, 6,485 indirect) bytes in 1 blocks are definitely lost in loss record 5,171 of 5,177 ==991919== at 0x5048291: g_type_create_instance (gtype.c:1844) ==991919== by 0x502DFC4: g_object_new_internal (gobject.c:1827) ==991919== by 0x502EFA9: g_object_new_valist (gobject.c:2152) ==991919== by 0x502DB9E: g_object_new (gobject.c:1670) ==991919== by 0x2215CA: mm_port_qmi_new (mm-port-qmi.c:615) ==991919== by 0x16C892: mm_base_modem_grab_port (mm-base-modem.c:295) ==991919== by 0x1CEEE5: mm_plugin_create_modem (mm-plugin.c:1048) ==991919== by 0x157E1E: mm_device_create_modem (mm-device.c:413) ==991919== by 0x1535A0: device_support_check_ready (mm-base-manager.c:195) ==991919== by 0x4EC9160: g_task_return_now (gtask.c:1212) ==991919== by 0x4EC92AA: g_task_return (gtask.c:1281) ==991919== by 0x4EC9E34: g_task_return_pointer (gtask.c:1689)
2020-01-09broadband-modem-qmi: plug memleak when checking unlock status with DMS UIMAleksander Morgado
==990910== 28 bytes in 1 blocks are definitely lost in loss record 1,943 of 5,051 ==990910== at 0x483877F: malloc (vg_replace_malloc.c:309) ==990910== by 0x50D53DA: g_malloc (gmem.c:99) ==990910== by 0x50F19ED: g_slice_alloc (gslice.c:1024) ==990910== by 0x50F1A2D: g_slice_alloc0 (gslice.c:1050) ==990910== by 0x4A3FD4A: __qmi_message_dms_uim_get_pin_status_response_parse (qmi-dms.c:8212) ==990910== by 0x4A6AFEA: uim_get_pin_status_ready (qmi-dms.c:31662) ==990910== by 0x4EADC8B: g_simple_async_result_complete (gsimpleasyncresult.c:802) ==990910== by 0x4EADCBF: complete_in_idle_cb.lto_priv.0 (gsimpleasyncresult.c:814) ==990910== by 0x50CF4AE: g_idle_dispatch (gmain.c:5617) ==990910== by 0x50CC6F0: g_main_dispatch (gmain.c:3179) ==990910== by 0x50CD616: g_main_context_dispatch (gmain.c:3844) ==990910== by 0x50CD81B: g_main_context_iterate (gmain.c:3917)
2020-01-06device: don't reprobe if device is goneAleksander Morgado
When a QMI/MBIM device is unplugged, we first get the notification from the proxy that the communication is broken, and then we get the kernel event reporting that the cdc-wdm port is gone. If we reprobe the device as soon as the proxy notifies us that the communication is broken, we would end up trying to reprobe the cdc-wdm port when it's already gone, and we end up trying to create a modem object when we shouldn't: <debug> [1577963152.429386] (ttyUSB0) unexpected port hangup! <debug> [1577963152.429506] (ttyUSB0) forced to close port <debug> [1577963152.429546] (ttyUSB0) device open count is 0 (close) <debug> [1577963152.429582] (ttyUSB0) closing serial port... <debug> [1577963152.429653] (ttyUSB0) serial port closed <debug> [1577963152.430340] (ttyUSB2) unexpected port hangup! <debug> [1577963152.430391] (ttyUSB2) forced to close port <debug> [1577963152.430418] (ttyUSB2) device open count is 0 (close) <debug> [1577963152.430451] (ttyUSB2) closing serial port... <debug> [1577963152.430517] (ttyUSB2) serial port closed <info> [1577963152.436932] (tty/ttyUSB0): released by device '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3' <info> [1577963152.439176] (tty/ttyUSB1): released by device '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3' <info> [1577963152.440409] (tty/ttyUSB2): released by device '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3' <info> [1577963152.447977] (net/wwan1): released by device '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3' Cannot read from istream: connection broken <info> [1577963152.458878] Connection to qmi-proxy for /dev/cdc-wdm1 lost, reprobing <debug> [1577963152.459144] [device /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3] unexported modem from path '/org/freedesktop/ModemManager1/Modem/1' <debug> [1577963152.460151] (ttyUSB1) forced to close port <info> [1577963152.460182] [device /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3] creating modem with plugin 'Sierra' and '1' ports <debug> [1577963152.460199] QMI-powered Sierra modem found... <debug> [1577963152.460382] (cdc-wdm1) type 'qmi' claimed by /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3 <debug> [1577963152.460417] Modem (Sierra) '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3' completely disposed <warn> [1577963152.460431] Could not recreate modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3': Failed to find a net port in the QMI modem <debug> [1577963152.460526] Modem (Sierra) '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3' completely disposed <info> [1577963152.460627] (usbmisc/cdc-wdm1): released by device '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3' <debug> [1577963152.460666] Removing empty device '/sys/devices/pci0000:00/0000:00:14.0/usb2/2-3' Fix this by delaying the reprobing attempt some time, and make sure we cancel the reprobing if the device detects that all ports are gone.
2020-01-06device: keep reference to object manager serverAleksander Morgado
Instead of having the reference to the object manager server only while the modem is exported, just keep a reference for as long as the device object exists. This will make it easier to handle reprobing logic.
2020-01-06iface-modem-3gpp: forced registration is not stateAleksander Morgado
The request for forced registration is an implementation detail of mm_iface_modem_3gpp_register_in_network(), not part of any state to keep in the private info.
2020-01-06cinterion: use common re-registration logic when neededAleksander Morgado
If the modem requires +COPS re-registration after setting modes, use the common logic provided by the 3GPP interface, which already knows e.g. whether the registration was automatic or the actual requested operator id in case of being manual.
2020-01-06ublox: use common re-registration logic when neededAleksander Morgado
If the modem requires +COPS re-registration after setting bands or modes, use the common logic provided by the 3GPP interface, which already knows e.g. whether the registration was automatic or the actual requested operator id in case of being manual. This will also make the u-blox plugin use the common +COPS set command implemented in the broadband modem object, which has the fallback to use the MCCMNC encoded in the current charset if needed.
2020-01-06iface-modem-3gpp: allow re-registering in network with last settingsAleksander Morgado
This is going to be used by modems that require this operation e.g. after changing access technology or bands.
2020-01-06iface-modem-3gpp: fix manual re-registration to the same operatorAleksander Morgado
We should not assume that a manual registration request to a given operator is successful if the modem is already registered in that operator, because if the registration was due to an automatic process, we cannot make sure the modem won't roam to a different network. We should only assume that a manual registration is not needed to be relaunched if the modem is already registered in the requested network AND if the registration process was manual (i.e. we asked the modem to lock into a given network).
2020-01-06iface-modem-3gpp: refactor private data handlingAleksander Morgado
Instead of having separate contexts for different things, setup a interface-wide private struct.
2020-01-06broadband-modem: retry +COPS=1,2,<mccmnc> with current charsetAleksander Morgado
If the modem (e.g. u-blox LARA) returns a "Not supported" error when attempting to run +COPS=1,2,<mccmnc> with the MCCMNC encoded in ASCII (and current charset is different, e.g. UCS2), then attempt to re-run the same command with the MCCMNC encoded in the explicit current charset. <debug> (ttyACM0): --> 'AT+COPS=1,2,"21404"<CR>' <debug> (ttyACM0): <-- '<CR><LF>+CME ERROR: 4<CR><LF>' <debug> Got failure code 4: Operation not supported <debug> (ttyACM0): --> 'AT+COPS=1,2,"00320031003400300034"<CR>' <debug> (ttyACM0): <-- '<CR><LF>+CME ERROR: 111<CR><LF>
2020-01-06broadband-modem: +COPS=? response may give strings in UCS2Aleksander Morgado
If the charset selected via CSCS is UCS2, the modem may decide to return all the strings in the +COPS=? response in UCS2: <debug> (ttyACM0): --> 'AT+COPS=?<CR>' <debug> (ttyACM0): <-- '<CR><LF>+COPS: (2,"004D006F007600690073007400610072","004D006F007600690073007400610072","00320031003400300037",7) <debug> Found network '00320031003400300037' ('004D006F007600690073007400610072','004D006F007600690073007400610072'); availability: current, access tech: lte
2020-01-06novatel-lte: fallback to parent scan methodAleksander Morgado
There is no need to run +COPS=? in the same way as the parent does it, just fallback to the parent implementation.
2020-01-06libmm-glib,simple-connect-properties: cleaner error handlingAleksander Morgado
If processing a key-value pair as a bearer property fails, we need to know if it failed due to the key being unknown or due to some other reason (e.g. failure parsing value of a known key). We'll only try with the Simple.Connect properties if the key is reported as unknown in the bearer properties. This will help us better identify errors if e.g. an invalid value is given to a known key. E.g. "yes" was invalid for allow-roaming here: daemon.notice netifd: wan (30476): simple connect=apn=internet,ip-type=ipv4,allow-roaming=yes daemon.notice netifd: wan (30476): Error parsing connect string: 'Invalid properties string, unexpected key 'allow-roaming''
2020-01-06libmm-glib,common-helpers: allow yes/no as booleans in stringAleksander Morgado
E.g. so that the settings passed on Simple.Connect() or Bearer.Connect() are parsed correctly from the user string: daemon.notice netifd: wan (30476): simple connect=apn=internet,ip-type=ipv4,allow-roaming=yes daemon.notice netifd: wan (30476): Error parsing connect string: 'Invalid properties string, unexpected key 'allow-roaming'' This also goes inline with e.g. the --create-bearer help in the man page that suggests using yes/no for the allow-roaming setting.
2020-01-03iface-modem-voice: fix segfault when voice support check failsAleksander Morgado
The error returned in support_check_finish() should be treated as optional, as in all the other optional feature interfaces. Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/172
2020-01-03build: bump copyright years to 2020Aleksander Morgado
2020-01-01libmm-glib,nmea: deprecate mm_location_gps_nmea_build_full()Aleksander Morgado
The new mm_location_gps_nmea_get_traces() is a much more generic way to retrieve the full list of traces and suits the libmm-glib API much better.
2020-01-01cli,location: use new mm_location_gps_nmea_get_traces()Aleksander Morgado
2019-12-31libmm-glib,nmea: new method to get list of tracesAleksander Morgado
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/120
2019-12-31port-serial: un-schedule flash operation as soon as it's cancelledAleksander Morgado
When a flash operation is started, it is always scheduled in an idle. If this operation is cancelled, we should right away un-schedule it, otherwise we may end up calling flash_do() with the GTask in the private info already gone. See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/178#note_330017
2019-12-21iface-modem-simple: clear ongoing connect cancellable on early errorsAleksander Morgado
If the Simple.Connect() operation fails before the bearer connection process starts (e.g. during the previous SIM-PIN checks or explicit registration attempt), the ongoing connect cancellable is not being properly cleared, and this would prevent additional new connection attempts unless an explicit Simple.Disconnect() is called. $ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet" error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NetworkTimeout: Network timeout' $ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet" error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InProgress: Connection request forbidden: operation already in progress' $ sudo mmcli -m 1 --simple-connect="operator-id=21403,apn=internet" error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.InProgress: Connection request forbidden: operation already in progress' Fix this, by making sure the ongoing connect cancellable is always cleared when completing the DBus method invocation that created it. Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/169
2019-12-17core,tests: new test to make sure all error codes are supportedAleksander Morgado
Defining the new error codes in the headers is not enough, we also need to add support in the error helpers in order to create proper GErrors with the expected error codes.
2019-12-17core,error-helpers: add missing ME error codesAleksander Morgado
2019-12-16base-bearer: avoid conncheck or stats update while disconnectingAleksander Morgado
We don't want the connection status checks to interfere with the disconnection logic, e.g. if they're both using the same TTY for both things. E.g. the CGACT? from the conncheck gets in the way of the disconnection logic: <debug> [1576037519.710684] Flashing data port (ttyUSB1)... <debug> [1576037519.710740] (ttyUSB1): port attributes not fully set <debug> [1576037520.287636] (ttyUSB1) device open count is 3 (open) <debug> [1576037520.287804] (ttyUSB1): --> 'AT+CGACT?<CR>' <debug> [1576037520.711067] (ttyUSB1) device open count is 2 (close) <debug> [1576037520.711127] (ttyUSB1): running init sequence... <debug> [1576037520.711231] PDP disconnection already sent <debug> [1576037520.711263] Disconnected bearer '/org/freedesktop/ModemManager1/Bearer/0' Instead, fully skip all conncheck and stat updates as long as the modem is not connected. The actual conncheck and stat update timeouts will be removed once completely disconnected, as it was before.
2019-12-16ublox: ignore error when disconnecting last LTE bearerAleksander Morgado
This is required in the TOBY-L2 and TOBY-L4 modules in order to report a proper disconnection, even if there is none in reality. The default LTE bearer is always reported connected while registered in LTE. Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/166
2019-12-16include,errors: define +CME ERROR code 151 equal to 171Aleksander Morgado
When the MT detects an attempt to disconnect the last PDN or when the network returns a response message with cause value #49, the "Last PDN disconnection not allowed" error is returned. The numeric error code was changed from 151 to 171 in 3GPP Rel-11, and therefore there are devices out there that would conform to Rel-10 or below and that would report +CME ERROR code 151 instead of 171. Given that 151 isn't defined to a different meaning in the specs, let's define it in the same way as 171.
2019-12-13libmm-glib,3gpp: make MMModem3gppNetwork a boxed typeAleksander Morgado
So that bindings know how to free the list of structs. This commit ends up triggering an API break in the bindings generated via GObject introspection, because the methods to access the items of a MMModem3gppNetwork are no longer treated as Modem3gpp class methods. E.g. instead of: ModemManager.Modem3gpp.network_get_operator_code(network) We should now do: network.get_operator_code() There is no API break in libmm-glib.
2019-12-13examples: new network-scan-python exampleAleksander Morgado
This is currently not working completely ok because python doesn't know how to free the GList of MMModem3gppNetwork elements. /org/freedesktop/ModemManager1/Modem/1: starting network scan... 21403: Orange - Orange (unknown, forbidden) 21401: vodafone ES - vodafone ES (unknown, forbidden) 21403: Orange - Orange (unknown, forbidden) 21403: Orange - Orange (unknown, forbidden) 21401: vodafone ES - vodafone ES (unknown, forbidden) 21404: Yoigo - Yoigo (unknown, forbidden) 21401: vodafone ES - vodafone ES (unknown, forbidden) 21404: Yoigo - Yoigo (unknown, forbidden) 21407: Movistar - Movistar (unknown, available) 21407: Movistar - Movistar (unknown, available) 21407: Movistar - Movistar (unknown, current) free(): invalid pointer Aborted
2019-12-12Revert "build: fix order of linked libs in test apps"Aleksander Morgado
This reverts commit 3eb623e73b546a444c1fc717f4ed105b3b2d5eae. This change is plain wrong. The correct order was already fixed in commit 42dab8e8.
2019-12-11build: fix order of linked libs in test appsAleksander Morgado
Solving build issues with truly strict linkers, as in: http://lists.busybox.net/pipermail/buildroot/2019-December/268817.html
2019-12-05ublox: implement support to enable and detect +UUDTMF URCsAleksander Morgado
Also, make sure we enable/disable the voice related unsolicited events in both primary and secondary ports, because it may happen that the primary port is connected with PPP and we're using the secondary port for control.
2019-12-05cinterion: fix using correct finish() method in AT commandAleksander Morgado
When using mm_base_modem_at_command_full(), the corresponding mm_base_modem_at_command_full_finish() should be used.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-06-14 06:33:05 +0000