- Feb 12, 2020
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
This avoids issues when e.g. sending SIM-PIN while the modem is already unlocked or when SIM-PIN is not enabled. Under those conditions, the needlessly sent SIM-PIN unlock attempt may fail while libmm-glib/mmcli reports a successful operation. E.g.: # mmcli --sim=/org/freedesktop/ModemManager1/SIM/0 --pin=3497 successfully sent PIN code to the SIM But in reality... Wed Nov 20 14:38:52 2019 daemon.debug [4254]: <debug> [1574260732.489513] Verifying PIN... Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 27 <<<<<< data = 01:1A:00:00:0B:02:00:09:00:26:00:0E:00:02:06:00:01:04:33:34:39:37:01:02:00:06:00 Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] sent generic request (translated)... <<<<<< QMUX: <<<<<< length = 26 <<<<<< flags = 0x00 <<<<<< service = "uim" <<<<<< client = 2 <<<<<< QMI: <<<<<< flags = "none" <<<<<< transaction = 9 <<<<<< tlv_length = 14 <<<<<< message = "Verify PIN" (0x0026) <<<<<< TLV: <<<<<< type = "Info" (0x02) <<<<<< length = 6 <<<<<< value = 01:04:33:34:39:37 <<<<<< translated = [ pin_id = 'pin1' pin_value = '3497' ] Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] received message... <<<<<< RAW: <<<<<< length = 30 <<<<<< data = 01:1D:00:80:0B:02:02:09:00:26:00:11:00:02:04:00:01:00:52:00:13:02:00:69:84:10:02:00:03:0A Wed Nov 20 14:38:52 2019 daemon.debug [4254]: [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 29 <<<<<< flags = 0x80 <<<<<< service = "uim" <<<<<< client = 2 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 9 <<<<<< tlv_length = 17 <<<<<< message = "Verify PIN" (0x0026) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 01:00:52:00 <<<<<< translated = FAILURE: AccessDenied As we already know what the current lock status is, just abort the user operation if the unlock operation isn't required. (cherry picked from commit fd052c8e)
-
Aleksander Morgado authored
(cherry picked from commit 9f192be6)
-
Aleksander Morgado authored
(cherry picked from commit 634bb1ca)
-
Aleksander Morgado authored
(cherry picked from commit b6add181)
-
Aleksander Morgado authored
Keep the saved GError directly as GTask context, instead of allocating the SendPinPukContext unconditionally. (cherry picked from commit 94025aad)
-
- Feb 07, 2020
-
-
Aleksander Morgado authored
When a GSM-7 encoded string is packed, the process of packing the septets into bytes may end up with one last byte holding the last bit of the last septet. When this situation happens, the last byte will end up with the 7 remaining bits set to 0. When this packed string is unpacked, the logic to unpack will unpack those last 7 bits as an additional septet, with the value 0x00. The 0x00 value encoded in GSM-7 is the '@' character, EXCEPT when this character is found at the end of the string, in which case the value should be considered as NUL and trigger the end of string already. So, fix the conversion logic between GSM-7 and UTF-8, so that whenever we find the 0x00 character at the end of the string, we ignore it instead of adding a bogus '@' trailing character. This commit fixes the "/MM/charsets/gsm7/default-chars" unit test after having it updated to perform the full conversion cycle: UTF-8 -> packed GSM7 -> UTF-8 (cherry picked from commit 2406a551)
-
Aleksander Morgado authored
The helper method returning a variant from a MMLocationGpsRaw would return already a full variant reference instead of a floating one, so we were really increasing the refcount when doing g_variant_ref_sink() in the location interface. Fix this by consolidating all helper methods in libmm-glib that return variants from the different MMLocationXX objects, so that they all return full variants instead of floating ones. (cherry picked from commit a61caff7)
-
- Jan 24, 2020
-
-
Aleksander Morgado authored
Fixes https://lists.freedesktop.org/archives/modemmanager-devel/2020-January/007686.html (cherry picked from commit 3490f997)
-
Aleksander Morgado authored
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. (cherry picked from commit 9b56ce8c)
-
- Jan 22, 2020
-
-
Aleksander Morgado authored
The mm_port_mbim_close() operation needs 3 arguments explicitly, so make sure we provide the two additional ones as NULL. (cherry picked from commit e793e4e6)
-
- Jan 13, 2020
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
- Jan 10, 2020
-
-
Aleksander Morgado authored
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) (cherry picked from commit 246fe710)
-
Aleksander Morgado authored
(cherry picked from commit 7c66b608)
-
Aleksander Morgado authored
(cherry picked from commit 33b19626)
-
Aleksander Morgado authored
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) (cherry picked from commit 29e64f59)
-
Aleksander Morgado authored
==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) (cherry picked from commit e3e837a8)
-
- Jan 06, 2020
-
-
Aleksander Morgado authored
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. (cherry picked from commit 15e8a78a)
-
- Jan 03, 2020
-
-
Aleksander Morgado authored
The error returned in support_check_finish() should be treated as optional, as in all the other optional feature interfaces. Fixes mobile-broadband/ModemManager#172 (cherry picked from commit 0d8a5e2a)
-
- Dec 31, 2019
-
-
Aleksander Morgado authored
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 mobile-broadband/ModemManager!178 (comment 330017) (cherry picked from commit 21e5b1d6)
-
- Dec 21, 2019
-
-
Aleksander Morgado authored
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 mobile-broadband/ModemManager#169 (cherry picked from commit 7a398214)
-
- Dec 17, 2019
-
-
Aleksander Morgado authored
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. (cherry picked from commit ab007960)
-
Aleksander Morgado authored
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. (cherry picked from commit d83c018f)
-
Aleksander Morgado authored
(cherry picked from commit 9991f290)
-
Aleksander Morgado authored
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 mobile-broadband/ModemManager#166 (cherry picked from commit 7d1e9491)
-
Aleksander Morgado authored
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. (cherry picked from commit f157d02f)
-
- Dec 16, 2019
-
-
Aleksander Morgado authored
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. (cherry picked from commit fcbffbd1)
-
Aleksander Morgado authored
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 (cherry picked from commit 248cd55f)
-
- Dec 12, 2019
-
-
Aleksander Morgado authored
This reverts commit 3eb623e7. This change is plain wrong. The correct order was already fixed in commit 42dab8e8. (cherry picked from commit f9e26fb5)
-
Aleksander Morgado authored
Solving build issues with truly strict linkers, as in: http://lists.busybox.net/pipermail/buildroot/2019-December/268817.html (cherry picked from commit 3eb623e7)
-
- Dec 10, 2019
-
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
Aleksander Morgado authored
-
- Dec 03, 2019
-
-
Aleksander Morgado authored
If for any reason getting current settings fails and we require static IP addressing (when using raw-ip), then that must be a hard error, otherwise we'll end up with the modem reported as connected but without any IP settings to use: <info> error: couldn't get current settings: QMI protocol error (15): 'OutOfCall' <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connected) <info> Simple connect state (8/8): All done <warn> Reloading stats failed: Couldn't get packet statistics: QMI protocol error (15): 'OutOfCall' # mmcli -b 0 Bearer '/org/freedesktop/ModemManager1/Bearer/0' ------------------------- Status | connected: 'yes' | suspended: 'no' | interface: 'wwan1' | IP timeout: '20' ------------------------- Properties | apn: 'm2minternet' | roaming: 'allowed' | IP type: 'none' | user: 'none' | password: 'none' | number: 'none' | Rm protocol: 'unknown' ------------------------- IPv4 configuration | method: 'unknown' ------------------------- IPv6 configuration | method: 'unknown' ------------------------- Stats | Duration: '0' | Bytes received: 'N/A' | Bytes transmitted: 'N/A' # mmcli -m 0 /org/freedesktop/ModemManager1/Modem/0 (device id '48f6c35f3d0376aa261a91c0cf7e6340d5a91601') ... Status | lock: 'sim-pin2' | unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)' | state: 'connected' | power state: 'on' | access tech: 'lte' | signal quality: '96' (recent) (cherry picked from commit 03e6375a)
-
Aleksander Morgado authored
When we try to disconnect a bearer and the bearer is already disconnected (e.g. after a cancelled connection attempt), avoid reporting that as an error: <warn> [1575287560.433398] Error disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0': 'Couldn't disconnect QMI bearer: this bearer is not connected'. Will assume disconnected anyway. (cherry picked from commit 76cafbb6)
-
Aleksander Morgado authored
If a WDS indication is received telling us that the modem is no longer connected, abort the ongoing connection attempt right away with an error and cleanup all allocated clients (implicitly disconnecting them if required).. Fixes mobile-broadband/ModemManager#155 (cherry picked from commit 991e6157)
-
Aleksander Morgado authored
Refactor the logic and setup a common complete_connect() method that helps us complete the GTask associated to the connection attempt. (cherry picked from commit ae53b045)
-