Re: [PATCH] broadband-modem-mbim: parse nw_error in register_state_set_ready only if MBIM_STATUS_FAILURE
Hi Aleksander,
Thank you for such a swift response!
I will post updated patch shortly, after testing updated changes locally.
W dniu 21.03.2019 o 13:42, Aleksander Morgado pisze:
> Hey!
>
> See comments below.
>
> On Thu, Mar 21, 2019 at 1:14 PM Lech Perczak
> wrote:
>> 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.
>>
> Understood, makes sense.
>
>> While at that, ensure that nw_error is initialized if parsing MBIM message
>> fails for any reason, which could also break registration process and
>> desynchronize ModemManager's internal state, preventing connection until
>> MM or modem restart.
>>
> That's not a bug, because if
> mbim_message_register_state_response_parse() returns TRUE, we're sure
> nw_error has been initialized. This assumption is expected in all
> message parsing methods.
>
>> Fixes: 854c371c8aa9 ("broadband-modem-mbim: implement 3GPP registration
>> request")
>> Signed-off-by: Lech Perczak
>> ---
>> src/mm-broadband-modem-mbim.c | 31 ---
>> 1 file changed, 16 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/mm-broadband-modem-mbim.c b/src/mm-broadband-modem-mbim.c
>> index fa62485c01e6..3da5b6944718 100644
>> --- a/src/mm-broadband-modem-mbim.c
>> +++ b/src/mm-broadband-modem-mbim.c
>> @@ -3944,24 +3944,25 @@ register_state_set_ready (MbimDevice *device,
>> {
>> MbimMessage *response;
>> GError *error = NULL;
>> -MbimNwError nw_error;
>> +MbimNwError nw_error = MBIM_NW_ERROR_UNKNOWN;
>>
> As said, the above not needed really.
>
>> response = mbim_device_command_finish (device, res, &error);
>> if (response &&
>> -mbim_message_response_get_result (response,
>> MBIM_MESSAGE_TYPE_COMMAND_DONE, &error) &&
>> -mbim_message_register_state_response_parse (
>> -response,
>> -&nw_error,
>> -NULL, /* ®ister_state */
>> -NULL, /* register_mode */
>> -NULL, /* available_data_classes */
>> -NULL, /* current_cellular_class */
>> -NULL, /* provider_id */
>> -NULL, /* provider_name */
>> -NULL, /* roaming_text */
>> -NULL, /* registration_flag */
>> -NULL)) {
>> -if (nw_error)
>> +!mbim_message_response_get_result (response,
>> MBIM_MESSAGE_TYPE_COMMAND_DONE, &error) &&
> Could you please add a comment here, explaining why we're trying to
> parse the response only when it's reporting a FAILURE? I understand
> the logic, but given it's a completely the opposite of what's usually
> done, it makes sense to explain it in a comment.
>
>> +g_error_matches (error, MBIM_STATUS_ERROR,
>> MBIM_STATUS_ERROR_FAILURE)) {
> And given that you have now an additional context here inside the
> if(), you could declare the MbimNwError nw_error variable here.
>
>> +g_clear_error (&error);
>> +if (mbim_message_register_state_response_parse (
>> +response,
>> +&nw_error,
>> +NULL, /* ®ister_state */
>> +NULL, /* register_mode */
>> +NULL, /* available_data_classes */
>> +NULL, /* current_cellular_class */
>> +NULL, /* provider_id */
>> +NULL, /* provider_name */
>> +NULL, /* roaming_text */
>> +NULL, /* registration_flag */
>> +&error))
>> error = mm_mobile_equipment_error_from_mbim_nw_error (nw_error);
>> }
>>
>> --
>> 2.7.4
>>
>> ___
>> ModemManager-devel mailing list
>> ModemManager-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
>
--
Pozdrawiam/With kind regards,
Lech Perczak
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
[PATCH v2] broadband-modem-mbim: parse nw_error in register_state_set_ready only if MBIM_STATUS_FAILURE
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: 854c371c8aa9 ("broadband-modem-mbim: implement 3GPP registration
request")
Signed-off-by: Lech Perczak
---
V2:
- Added explanation about unusual error check based on MBIM specification,
- Moved nw_error to narrower scope of parsing NwError from response and
dropped initialization,
- Reformatted condition slightly.
---
src/mm-broadband-modem-mbim.c | 47 +--
1 file changed, 32 insertions(+), 15 deletions(-)
diff --git a/src/mm-broadband-modem-mbim.c b/src/mm-broadband-modem-mbim.c
index fa62485c01e6..0ecfd1a832ae 100644
--- a/src/mm-broadband-modem-mbim.c
+++ b/src/mm-broadband-modem-mbim.c
@@ -3944,24 +3944,41 @@ register_state_set_ready (MbimDevice *device,
{
MbimMessage *response;
GError *error = NULL;
-MbimNwError nw_error;
response = mbim_device_command_finish (device, res, &error);
+/* According to Mobile Broadband Interface Model specification 1.0,
+ * Errata 1, table 10.5.9.8: Status codes for MBIM_CID_REGISTER_STATE,
+ * NwError field of MBIM_REGISTRATION_STATE_INFO structure is valid
+ * if and only if MBIM_SET_REGISTRATION_STATE response status code equals
+ * MBIM_STATUS_FAILURE.
+ * Therefore it only makes sense to parse this value if MBIM_STATUS_FAILURE
+ * result is returned in response, contrary to usual "success" code.
+ * However, some modems do not set this value to 0 when registered,
+ * causing ModemManager to drop to idle state, while modem itself is
+ * registered.
+ * Also NwError "0" is defined in 3GPP TS 24.008 as "Unknown error",
+ * not "No error", making it unsuitable as condition for registration
check.
+ */
if (response &&
-mbim_message_response_get_result (response,
MBIM_MESSAGE_TYPE_COMMAND_DONE, &error) &&
-mbim_message_register_state_response_parse (
-response,
-&nw_error,
-NULL, /* ®ister_state */
-NULL, /* register_mode */
-NULL, /* available_data_classes */
-NULL, /* current_cellular_class */
-NULL, /* provider_id */
-NULL, /* provider_name */
-NULL, /* roaming_text */
-NULL, /* registration_flag */
-NULL)) {
-if (nw_error)
+!mbim_message_response_get_result (response,
+ MBIM_MESSAGE_TYPE_COMMAND_DONE,
+ &error) &&
+g_error_matches (error, MBIM_STATUS_ERROR, MBIM_STATUS_ERROR_FAILURE))
{
+MbimNwError nw_error;
+
+g_clear_error (&error);
+if (mbim_message_register_state_response_parse (
+response,
+&nw_error,
+NULL, /* ®ister_state */
+NULL, /* register_mode */
+NULL, /* available_data_classes */
+NULL, /* current_cellular_class */
+NULL, /* provider_id */
+NULL, /* provider_name */
+NULL, /* roaming_text */
+NULL, /* registration_flag */
+&error))
error = mm_mobile_equipment_error_from_mbim_nw_error (nw_error);
}
--
2.7.4
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH] broadband-modem-mbim: parse nw_error in register_state_set_ready only if MBIM_STATUS_FAILURE
Hi Aleksander,
Any update on the patch? :)
In the meantime I got response from Telit that they won't fix the original
problem which made me create this patch.
With kind regards,
Lech
W dniu 21.03.2019 o 13:14, Lech Perczak pisze:
> 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.
>
> While at that, ensure that nw_error is initialized if parsing MBIM message
> fails for any reason, which could also break registration process and
> desynchronize ModemManager's internal state, preventing connection until
> MM or modem restart.
>
> Fixes: 854c371c8aa9 ("broadband-modem-mbim: implement 3GPP registration
> request")
> Signed-off-by: Lech Perczak
> ---
> src/mm-broadband-modem-mbim.c | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/src/mm-broadband-modem-mbim.c b/src/mm-broadband-modem-mbim.c
> index fa62485c01e6..3da5b6944718 100644
> --- a/src/mm-broadband-modem-mbim.c
> +++ b/src/mm-broadband-modem-mbim.c
> @@ -3944,24 +3944,25 @@ register_state_set_ready (MbimDevice *device,
> {
> MbimMessage *response;
> GError *error = NULL;
> -MbimNwError nw_error;
> +MbimNwError nw_error = MBIM_NW_ERROR_UNKNOWN;
>
> response = mbim_device_command_finish (device, res, &error);
> if (response &&
> -mbim_message_response_get_result (response,
> MBIM_MESSAGE_TYPE_COMMAND_DONE, &error) &&
> -mbim_message_register_state_response_parse (
> -response,
> -&nw_error,
> -NULL, /* ®ister_state */
> -NULL, /* register_mode */
> -NULL, /* available_data_classes */
> -NULL, /* current_cellular_class */
> -NULL, /* provider_id */
> -NULL, /* provider_name */
> -NULL, /* roaming_text */
> -NULL, /* registration_flag */
> -NULL)) {
> -if (nw_error)
> +!mbim_message_response_get_result (response,
> MBIM_MESSAGE_TYPE_COMMAND_DONE, &error) &&
> +g_error_matches (error, MBIM_STATUS_ERROR,
> MBIM_STATUS_ERROR_FAILURE)) {
> +g_clear_error (&error);
> +if (mbim_message_register_state_response_parse (
> +response,
> +&nw_error,
> +NULL, /* ®ister_state */
> +NULL, /* register_mode */
> +NULL, /* available_data_classes */
> +NULL, /* current_cellular_class */
> +NULL, /* provider_id */
> + NULL, /* provider_name */
> +NULL, /* roaming_text */
> +NULL, /* registration_flag */
> +&error))
> error = mm_mobile_equipment_error_from_mbim_nw_error (nw_error);
> }
>
--
Pozdrawiam/With kind regards,
Lech Perczak
Sr. Software Engineer
Camlin Technologies Poland Limited Sp. z o.o.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: cannot find glib-2.0 when building in openwrt
Hi Enrico, Marek For default configuration, make package/symlinks should do just that. With kind regards, Lech W dniu 11.06.2019 o 10:13, Enrico Mioso pisze: > Dear Belisko Marek, > > it seems the build system can not find other packages in the feeds/packages > repository. > Did you update / install those feeds first? > > ./scripts/feeds update -a > ./scripts/feeds install -a > > Or maybe there is a better way? > > Enrico > > On Tue, 11 Jun 2019, Belisko Marek wrote: > >> Date: Tue, 11 Jun 2019 08:36:49 >> From: Belisko Marek >> To: "ModemManager (development)" >> Subject: cannot find glib-2.0 when building in openwrt >> >> Hi, >> >> I'm following this README : >> https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt >> to have modemmanager to be build in openwrt. But while using this >> step: >> ./scripts/feeds install -p mobile_broadband -a >> >> I get: >> ./scripts/feeds install -p mobile_broadband -a >> WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on >> 'libpam', which does not exist >> WARNING: Makefile 'package/utils/busybox/Makefile' has a build >> dependency on 'libpam', which does not exist >> WARNING: Makefile 'package/network/utils/curl/Makefile' has a >> dependency on 'libgnutls', which does not exist >> WARNING: Makefile 'package/network/utils/curl/Makefile' has a >> dependency on 'libopenldap', which does not exist >> WARNING: Makefile 'package/network/utils/curl/Makefile' has a >> dependency on 'libidn2', which does not exist >> WARNING: Makefile 'package/network/utils/curl/Makefile' has a >> dependency on 'libssh2', which does not exist >> WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency >> on 'liblzma', which does not exist >> WARNING: Makefile 'package/feeds/mobile_broadband/libmbim/Makefile' >> has a dependency on 'glib2', which does not exist >> WARNING: Makefile 'package/feeds/mobile_broadband/libqmi/Makefile' has >> a dependency on 'glib2', which does not exist >> WARNING: Makefile 'package/network/services/lldpd/Makefile' has a >> dependency on 'libnetsnmp', which does not exist >> WARNING: Makefile >> 'package/feeds/mobile_broadband/modemmanager/Makefile' has a >> dependency on 'glib2', which does not exist >> WARNING: Makefile >> 'package/feeds/mobile_broadband/modemmanager/Makefile' has a >> dependency on 'dbus', which does not exist >> Installing all packages from feed mobile_broadband. >> >> and despite of that if I run build then libmbim fails with: >> >> checking pkg-config is at least version 0.9.0... yes >> checking for glib-2.0 >= 2.36... no >> configure: error: Package requirements (glib-2.0 >= 2.36) were not met: >> >> No package 'glib-2.0' found >> >> Consider adjusting the PKG_CONFIG_PATH environment variable if you >> installed software in a non-standard prefix. >> >> Alternatively, you may set the environment variables MBIM_COMMON_CFLAGS >> and MBIM_COMMON_LIBS to avoid the need to call pkg-config. >> See the pkg-config man page for more details. >> Makefile:69: recipe for target >> '/home/marek/projects/cmoss_resin/compex-openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/libmbim-1.18.2/.configured_a17fb5ef857664f03cd0ce37cc5ea591' >> failed >> make[3]: *** >> [/home/marek/projects/cmoss_resin/compex-openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/libmbim-1.18.2/.configured_a17fb5ef857664f03cd0ce37cc5ea591] >> Error 1 >> make[3]: Leaving directory >> '/home/marek/projects/cmoss_resin/compex-openwrt/feeds/mobile_broadband/libmbim' >> Command exited with non-zero status 2 >> time: package/feeds/mobile_broadband/libmbim/compile#7.20#1.00#8.80 >> package/Makefile:107: recipe for target >> 'package/feeds/mobile_broadband/libmbim/compile' failed >> >> Ideas? I'm on actual 18.06 branch. Thanks. >> >> BR, >> >> marek >> >> -- >> as simple and primitive as possible >> - >> Marek Belisko - OPEN-NANDRA >> Freelance Developer >> >> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic >> Tel: +421 915 052 184 >> skype: marekwhite >> twitter: #opennandra >> web: http://open-nandra.com >> ___ >> ModemManager-devel mailing list >> ModemManager-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel -- Pozdrawiam/With kind regards, Lech Perczak Sr. Software Engineer Camlin Technologies Poland Limited Sp. z o.o. Strzegomska 48A, 53-611 Wroclaw Tel: (+48) 71 75 000 16 Email: l.perc...@camlintechnologies.com Website: http://www.camlintechnologies.com ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Timing of next major release
Hello Aleksander, We're considering a major version update of ModemManager used in our platform, so it would be nice to know if you plan a major release until around the end of year. If so, we could pick it up right away, or it'll take longer, so should we go with 1.10 branch instead? -- Pozdrawiam/With kind regards, Lech Perczak Sr. Software Engineer Camlin Technologies Poland Limited Sp. z o.o. ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Segfault in MM 1.12.4 in port timeout detection logic
Hi Aleksander,
While testing a mechanism to trigger a modem restart based on port timeout (and
disposing of modem object in MM) I managed to segfault ModemManager.
I'm using vanilla MM 1.12.4 built for armhf target.
What I've found, is that a race condition is possible on
serial_port_timed_out_cb, which is called one more time than it should, causing
a use-after-free.
I've found out that by the fact I used default value of max_timeouts (10) and
the method got called with n_consecutive_timeouts = 11, but according to the
condition there, the cancellable was triggered on previous call with
n_consecutive_timeouts = 10.
The crash happened when calling g_dbus_object_get_object_path (G_DBUS_OBJECT
(self) when evaluating arguments for the error log in serial_port_timed_out_cb :
Stack trace:
#0 g_dbus_object_get_object_path (object=0x68f1c0) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/gio/gdbusobject.c:110
#1 0x0005844c in serial_port_timed_out_cb (port=,
n_consecutive_timeouts=11, self=0x68f1c0)
at
/usr/src/debug/modemmanager/1.12+gitrAUTOINC+cef03ce291-r6/git/src/mm-base-modem.c:130
#2 0x7699ce48 in g_cclosure_marshal_VOID__FLAGSv (closure=,
return_value=, instance=, args=...,
marshal_data=0x0, n_params=1,
param_types=0x670fa0) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/gobject/gmarshal.c:1570
#3 0x7699aaec in _g_closure_invoke_va (closure=closure@entry=0x66e548,
return_value=return_value@entry=0x0, instance=0x60ea18,
instance@entry=0x6ac628, args=args@entry=..., n_params=1,
param_types=0x670fa0) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/gobject/gclosure.c:867
#4 0x769b5f44 in g_signal_emit_valist (instance=instance@entry=0x6ac628,
signal_id=, detail=detail@entry=0, var_args=...,
var_args@entry=...)
at /usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/gobject/gsignal.c:3294
#5 0x769b6580 in g_signal_emit (instance=instance@entry=0x6ac628,
signal_id=, detail=0) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/gobject/gsignal.c:3441
#6 0x000d225c in port_serial_timed_out (data=) at
/usr/src/debug/modemmanager/1.12+gitrAUTOINC+cef03ce291-r6/git/src/mm-port-serial.c:797
#7 0x768d4758 in g_timeout_dispatch (source=0x682280, callback=0xd21d8
, user_data=)
at /usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/glib/gmain.c:4577
#8 0x768d3b1c in g_main_dispatch (context=0x614bf8) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/glib/gmain.c:3154
#9 g_main_context_dispatch (context=context@entry=0x614bf8) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/glib/gmain.c:3769
#10 0x768d3eb4 in g_main_context_iterate (context=0x614bf8,
block=block@entry=1, dispatch=dispatch@entry=1, self=)
at /usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/glib/gmain.c:3840
#11 0x768d4210 in g_main_loop_run (loop=0x61ef10) at
/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/glib/gmain.c:4034
#12 0x00044714 in main (argc=, argv=) at
/usr/src/debug/modemmanager/1.12+gitrAUTOINC+cef03ce291-r6/git/src/main.c:206
Frame #1:
(gdb) info frame
Stack level 0, frame at 0x7e9fca90:
pc = 0x76ae816c in g_dbus_object_get_object_path
(/usr/src/debug/glib-2.0/1_2.48.2-r0/glib-2.48.2/gio/gdbusobject.c:110); saved
pc = 0x5844c
called by frame at 0x7e9fcac0
source language c.
Arglist at 0x7e9fca88, args: object=0x68f1c0
Locals at 0x7e9fca88, Previous frame's sp is 0x7e9fca90
Saved registers:
r4 at 0x7e9fca88, lr at 0x7e9fca8c
object = 0x68f1c0
(gdb) info args
port =
n_consecutive_timeouts = 11
(gdb) print *self
$2 = {parent = {parent_instance = {parent_instance = {g_type_instance =
{g_class = 0x0}, ref_count = 0, qdata = 0x0}, priv = 0x68f1b0}, priv = 0x0},
priv = 0x68f148}
(gdb) print *self->priv
$4 = {connection = 0x0, cancellable = 0x0, invalid_if_cancelled = 61, device =
0x6b22f0 "XEb", drivers = 0x6abda0, plugin = 0x653fc0 "\230\275j", vendor_id =
7111, product_id = 33,
hotplugged = 0, valid = 0, reprobe = 0, max_timeouts = 10, authp = 0x0,
authp_cancellable = 0x0, ports = 0x0, primary = 0x0, secondary = 0x0, qcdm =
0x0, data = 0x0, gps_control = 0x0,
gps = 0x0, audio = 0x0, enable_tasks = 0x0, disable_tasks = 0x0, qmi = 0x0,
mbim = 0x0}
I have a full session log and a core dump, so pretty much anything could be
extracted if needed. So far it only reproduced once. I'm also analyzing myself
how to fix it, but I'd be glad if you could take a look at this.
--
Pozdrawiam/With kind regards,
Lech Perczak
Sr. Software Engineer
Camlin Technologies Poland Limited Sp. z o.o.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Segfault in MM 1.12.4 in port timeout detection logic
0x68f148}
>>> (gdb) print *self->priv
>>> $4 = {connection = 0x0, cancellable = 0x0, invalid_if_cancelled = 61,
>>> device = 0x6b22f0 "XEb", drivers = 0x6abda0, plugin = 0x653fc0 "\230\275j",
>>> vendor_id = 7111, product_id = 33,
>>> hotplugged = 0, valid = 0, reprobe = 0, max_timeouts = 10, authp = 0x0,
>>> authp_cancellable = 0x0, ports = 0x0, primary = 0x0, secondary = 0x0, qcdm
>>> = 0x0, data = 0x0, gps_control = 0x0,
>>> gps = 0x0, audio = 0x0, enable_tasks = 0x0, disable_tasks = 0x0, qmi =
>>> 0x0, mbim = 0x0}
>>>
>>> I have a full session log and a core dump, so pretty much anything could be
>>> extracted if needed. So far it only reproduced once. I'm also analyzing
>>> myself how to fix it, but I'd be glad if you could take a look at this.
>>>
>> The error makes sense; the port object is living for longer than the
>> modem object, and so by the time the timed-out signal is emitted, the
>> modem object is already unrefed. The fix for this issue is to keep
>> track of all signal ids returned by g_signal_connect(port,
>> "timed-out",...) and make sure they are disconnected when the modem
>> object is unref-ed. Let me try to patch that.
>>
> I believe this should now be fixed in the following merge request:
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/248
>
> If you're able to reproduce the problem easily, please give it a try
> and let me know if it fixes it or not. I'll backport the relevant
> change to 1.12.x once if the change in master looks ok.
>
> --
> Aleksander
> https://aleksander.es
> ___
> This email originated from outside of Camlin Group. Do not click on links or
> open attachments unless you are confident they are secure. If in doubt,
> contact IT Support (itsupp...@camlintechnologies.com).
--
Pozdrawiam/With kind regards,
Lech Perczak
Sr. Software Engineer
Camlin Technologies Poland Limited Sp. z o.o.
Strzegomska 48A,
53-611 Wroclaw
Tel: (+48) 71 75 000 16
Email: l.perc...@camlintechnologies.com
Website: http://www.camlintechnologies.com
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Segfault in MM 1.12.4 in port timeout detection logic
; $2 = {parent = {parent_instance = {parent_instance = {g_type_instance =
>>> {g_class = 0x0}, ref_count = 0, qdata = 0x0}, priv = 0x68f1b0}, priv =
>>> 0x0}, priv = 0x68f148}
>>> (gdb) print *self->priv
>>> $4 = {connection = 0x0, cancellable = 0x0, invalid_if_cancelled = 61,
>>> device = 0x6b22f0 "XEb", drivers = 0x6abda0, plugin = 0x653fc0 "\230\275j",
>>> vendor_id = 7111, product_id = 33,
>>> hotplugged = 0, valid = 0, reprobe = 0, max_timeouts = 10, authp = 0x0,
>>> authp_cancellable = 0x0, ports = 0x0, primary = 0x0, secondary = 0x0, qcdm
>>> = 0x0, data = 0x0, gps_control = 0x0,
>>> gps = 0x0, audio = 0x0, enable_tasks = 0x0, disable_tasks = 0x0, qmi =
>>> 0x0, mbim = 0x0}
>>>
>>> I have a full session log and a core dump, so pretty much anything could be
>>> extracted if needed. So far it only reproduced once. I'm also analyzing
>>> myself how to fix it, but I'd be glad if you could take a look at this.
>>>
>> The error makes sense; the port object is living for longer than the
>> modem object, and so by the time the timed-out signal is emitted, the
>> modem object is already unrefed. The fix for this issue is to keep
>> track of all signal ids returned by g_signal_connect(port,
>> "timed-out",...) and make sure they are disconnected when the modem
>> object is unref-ed. Let me try to patch that.
>>
> I believe this should now be fixed in the following merge request:
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/248
>
> If you're able to reproduce the problem easily, please give it a try
> and let me know if it fixes it or not. I'll backport the relevant
> change to 1.12.x once if the change in master looks ok.
>
> --
> Aleksander
> https://aleksander.es
> ___
> This email originated from outside of Camlin Group. Do not click on links or
> open attachments unless you are confident they are secure. If in doubt,
> contact IT Support (itsupp...@camlintechnologies.com).
--
Pozdrawiam/With kind regards,
Lech Perczak
Sr. Software Engineer
Camlin Technologies Poland Limited Sp. z o.o.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Issues regarding multiple MBIM bearer support
mhi_net driver. Still, a fix regarding bearer cleanup would be much more appreciated, or a hint on where to start looking, so I could develop and upstream the fix. Thanks in advance for any information. [1] https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/188 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/cdc_mbim.rst?id=92f06f4226fd9bdd6fbbd2e8b84601fc14b5855e#n173 [3] https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/05b005951710c8810538ec448e89e32f28c3d592 -- Pozdrawiam/With kind regards, Lech Perczak Sr. Software Engineer Camlin Technologies Poland Limited Sp. z o.o. ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Issues regarding multiple MBIM bearer support
.40.133 <http://100.104.40.133> > > 169.254.0.0/16 <http://169.254.0.0/16> dev lan2 proto kernel scope link src > > 169.254.120.44 <http://169.254.120.44> metric 100 > > 192.168.7.0/24 <http://192.168.7.0/24> dev lan3 proto kernel scope link src > > 192.168.7.2 > > 224.0.0.0/4 <http://224.0.0.0/4> dev lan2 proto static scope link metric 100 > > # ip r add default via 100.104.40.1 <http://100.104.40.1> > > # ip r > > default via 100.104.40.1 <http://100.104.40.1> dev wwan0.1 > > 100.104.40.0/24 <http://100.104.40.0/24> dev wwan0.1 proto kernel scope > > link src 100.104.40.133 <http://100.104.40.133> > > 169.254.0.0/16 <http://169.254.0.0/16> dev lan2 proto kernel scope link src > > 169.254.120.44 <http://169.254.120.44> metric 100 > > 192.168.7.0/24 <http://192.168.7.0/24> dev lan3 proto kernel scope link src > > 192.168.7.2 > > 224.0.0.0/4 <http://224.0.0.0/4> dev lan2 proto static scope link metric 100 > > # ping 8.8.8.8 <http://8.8.8.8> > > PING 8.8.8.8 <http://8.8.8.8> (8.8.8.8 <http://8.8.8.8>: 56 data bytes > > 64 bytes from 8.8.8.8 <http://8.8.8.8> seq=0 ttl=116 time=44.351 ms > > 64 bytes from 8.8.8.8 <http://8.8.8.8> seq=1 ttl=116 time=34.228 ms > > 64 bytes from 8.8.8.8 <http://8.8.8.8> seq=2 ttl=116 time=41.697 ms > > 64 bytes from 8.8.8.8 <http://8.8.8.8> seq=3 ttl=116 time=33.472 ms > > 64 bytes from 8.8.8.8 <http://8.8.8.8> seq=4 ttl=116 time=33.080 ms > > 64 bytes from 8.8.8.8 <http://8.8.8.8> seq=5 ttl=116 time=32.852 ms > > ^C > > --- 8.8.8.8 <http://8.8.8.8> ping statistics --- > > 6 packets transmitted, 6 packets received, 0% packet loss > > round-trip min/avg/max = 32.852/36.613/44.351 ms > > # > > > > Ahh, ok, what you did here is setup a VLAN interface for session 1, > because it was session 1 the one active in the 2nd bearer created > above, right? > If so, yes, you did hit the bug and you found a way to confirm it's a > bug. Still, the solution for this problem is to fully avoid having 2 > connected bearer objects. If you can reproduce the issue with the 2 > bearers and the 2nd one getting session id 1, when using MM 1.16.6, > again, please provide a MM daemon debug log and post it to gitlab for > analysis. > > > > ModemManager only recently gained full support for PDN multiplexing. For > > full support of this, ModemManager most probably should pass the > > information about used PDN session index to NetworkManager, > > which would then setup the VLAN sub-interface accordingly, which > > NetworkManager, as of 1.26.8 currently does not - IP configuration is > > always applied to main interface. > > Therefore, stable versions probably should avoid using PDN sessions other > > than zero. > > > > Stable 1.16 should indeed always use PDN session id 0. > > In git master, the VLAN interface is created by ModemManager itself, > and we report to NetworkManager the name of the interface to be used. > All that works transparently for the user. If you switch to MM git > master, all that should work correctly without additional changes in > your side anywhere. > > > Now after this very long and convoluted story, my question is: Is there any > > particular fix on master branch, that could work for me, or is it possible > > to disable multiplexing explicitly? I think I could alter what's done in > > commit 05b005951710c8810538ec448e89e32f28c3d592 [3] to disable multiplexing > > entirely - as I don't need it currently. Cherry-picking this commit > > verbatim would not work, as cdc_mbim driver does support multiplexing, and > > currently, check is done only against mhi_net driver. Still, a fix > > regarding bearer cleanup would be much more appreciated, or a hint on where > > to start looking, so I could develop and upstream the fix. > > Quick workaround: disable IPv6 in the NM settings. > Final solution: use MM git master as it is. Even if you don't need > multiplexing, using it is straightforward, and all that should be > correctly working (with any version of NetworkManager). > > > Thanks in advance for any information. > > > > [1] > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/188 > > <https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/188> > > [2] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/cdc_mbim.rst?id=92f06f4226fd9bdd6fbbd2e8b84601fc14b5855e#n173 > > > > <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/cdc_mbim.rst?id=92f06f4226fd9bdd6fbbd2e8b84601fc14b5855e#n173> > > [3] > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/05b005951710c8810538ec448e89e32f28c3d592 > > > > <https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/05b005951710c8810538ec448e89e32f28c3d592> > > > > That was a long email; hope any of the things I said were helpful for you :) > > -- > Aleksander > https://aleksander.es <https://aleksander.es> > > ___ > > This email originated from outside of Camlin Group. Do not click on links or > open attachments unless you are confident they are secure. If in doubt, > contact IT Support (itsupp...@camlintechnologies.com). > -- Pozdrawiam/With kind regards, Lech Perczak Sr. Software Engineer Camlin Technologies Poland Limited Sp. z o.o. Strzegomska 48A, 53-611 Wroclaw Tel: (+48) 71 75 000 16 Email: l.perc...@camlintechnologies.com Website: http://www.camlintechnologies.com ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager update
Hey Artur, Aleksander, I think your best bet is compiling .deb's based on source files available from Sid: https://packages.debian.org/sid/libqmi-glib5 https://packages.debian.org/sid/libmbim-glib4 https://packages.debian.org/sid/modemmanager These are IIRC the latest release, or very close to. I managed to successfully compile those against current stable (Bullseye) - they run well. You'll have to compile them in that order, as usually don for Debian packages, because of dependencies, and install respective -dev packages to build the next ones. Installing packages directly from Sid won't work, as required glibmm is too new for Bullseye. Kind regards, Lech
[PATCH] broadband-modem-mbim: parse nw_error in register_state_set_ready only if MBIM_STATUS_FAILURE
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.
While at that, ensure that nw_error is initialized if parsing MBIM message
fails for any reason, which could also break registration process and
desynchronize ModemManager's internal state, preventing connection until
MM or modem restart.
Fixes: 854c371c8aa9 ("broadband-modem-mbim: implement 3GPP registration
request")
Signed-off-by: Lech Perczak
---
src/mm-broadband-modem-mbim.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/src/mm-broadband-modem-mbim.c b/src/mm-broadband-modem-mbim.c
index fa62485c01e6..3da5b6944718 100644
--- a/src/mm-broadband-modem-mbim.c
+++ b/src/mm-broadband-modem-mbim.c
@@ -3944,24 +3944,25 @@ register_state_set_ready (MbimDevice *device,
{
MbimMessage *response;
GError *error = NULL;
-MbimNwError nw_error;
+MbimNwError nw_error = MBIM_NW_ERROR_UNKNOWN;
response = mbim_device_command_finish (device, res, &error);
if (response &&
-mbim_message_response_get_result (response,
MBIM_MESSAGE_TYPE_COMMAND_DONE, &error) &&
-mbim_message_register_state_response_parse (
-response,
-&nw_error,
-NULL, /* ®ister_state */
-NULL, /* register_mode */
-NULL, /* available_data_classes */
-NULL, /* current_cellular_class */
-NULL, /* provider_id */
-NULL, /* provider_name */
-NULL, /* roaming_text */
-NULL, /* registration_flag */
-NULL)) {
-if (nw_error)
+!mbim_message_response_get_result (response,
MBIM_MESSAGE_TYPE_COMMAND_DONE, &error) &&
+g_error_matches (error, MBIM_STATUS_ERROR, MBIM_STATUS_ERROR_FAILURE))
{
+g_clear_error (&error);
+if (mbim_message_register_state_response_parse (
+response,
+&nw_error,
+NULL, /* ®ister_state */
+NULL, /* register_mode */
+NULL, /* available_data_classes */
+NULL, /* current_cellular_class */
+NULL, /* provider_id */
+NULL, /* provider_name */
+NULL, /* roaming_text */
+NULL, /* registration_flag */
+&error))
error = mm_mobile_equipment_error_from_mbim_nw_error (nw_error);
}
--
2.7.4
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Random QMI port probe failures after ed13e053cd42 ("port-probe: fix custom init probing not having open AT port")
Hello,
After updating to the latest main (at eda130f3bf1c), in our team we've noticed,
that in our CI, that QMI port sometimes fails to probe,
with Telit LE910C4-WWXD. The result is the modem having only AT ports
available, thus falling back to using PPP for the data connection.
I've bisected ModemManager's source code from previous update, which was
working OK, and narrowed down the issue to the following commit:
ed13e053cd42 ("port-probe: fix custom init probing not having open AT port").
Reverting it for testing fixes the issue.
I haven't yet dug to the root cause fully, but since current main branch is
affected, I decided to reach out early.
The debug logs show, that probe fails right after first QMI transaction, and
usbmon capture (attached) confirms that:
ModemManager[13321]: [1734028733.422964] [/dev/cdc-wdm0] sent
message...#012<<<<<< RAW:#012<<<<<< length = 28#012<<<<<< data =
01:1B:00:00:00:00:00:01:00:FF:10:00...#012
ModemManager[13321]: [1734028733.423671] [/dev/cdc-wdm0] sent
generic request (translated)...#012<<<<<< QMUX:#012<<<<<< length =
27#012<<<<<< flags = 0x00#012<<<<<< service = "ctl"#012<<<<<< client =
0#012<<<<<< QMI:#012<<<<<< flags = "none"#012<<<<<< transaction =
1#012<<<<<< tlv_length = 16#012<<<<<< message = "Internal Proxy Open"
(0xFF00)#012<<<<<< TLV:#012<<<<<< type = "Device Path" (0x01)#012<<<<<<
length = 13#012<<<<<< value =
2F:64:65:76:2F:63:64:63:2D:77:64:6D:30#012<<<<<< translated =
/dev/cdc-wdm0#012
ModemManager[13321]: [1734028733.429528] [/dev/cdc-wdm0]
received message...#012<<<<<< RAW:#012<<<<<< length = 19#012<<<<<< data =
01:12:00:80:00:00:01:01:00:FF:07:00...#012
ModemManager[13321]: [1734028733.430244] [/dev/cdc-wdm0]
received generic response (translated)...#012<<<<<< QMUX:#012<<<<<< length =
18#012<<<<<< flags = 0x80#012<<<<<< service = "ctl"#012<<<<<< client =
0#012<<<<<< QMI:#012<<<<<< flags = "response"#012<<<<<< transaction =
1#012<<<<<< tlv_length = 7#012<<<<<< message = "Internal Proxy Open"
(0xFF00)#012<<<<<< TLV:#012<<<<<< type = "Result" (0x02)#012<<<<<<
length = 4#012<<<<<< value = 00:00:00:00#012<<<<<< translated =
SUCCESS#012
ModemManager[13321]: [1734028733.430446] [/dev/cdc-wdm0]
checking version info (45 retries)...
ModemManager[13321]: [1734028733.430596] [/dev/cdc-wdm0] sent
message...#012<<<<<< RAW:#012<<<<<< length = 12#012<<<<<< data =
01:0B:00:00:00:00:00:02:21:00:00:00...#012
ModemManager[13321]: [1734028733.430673] [/dev/cdc-wdm0] sent
generic request (translated)...#012<<<<<< QMUX:#012<<<<<< length =
11#012<<<<<< flags = 0x00#012<<<<<< service = "ctl"#012<<<<<< client =
0#012<<<<<< QMI:#012<<<<<< flags = "none"#012<<<<<< transaction =
2#012<<<<<< tlv_length = 0#012<<<<<< message = "Get Version Info"
(0x0021)#012
ModemManager[13321]: [1734028733.434635] [cdc-wdm0/at] <--
'\1\197\0\128\0\0\1\1!\0\186\0\2\4\0\0\0\0\0\1\176\0#\0\1\0\5\0\1\1\0C\0\2\1\0\0\0\3\1\0\25\0\4\1\0\12\0\5\1\0\0\7\1\0\3\0\8\1\0\4\0\9\2\0\1\0\2\0\24\0\11\1\0W\0\12\1\0\4\0\15\1\0\0\0\16\2\0\0\0\17\1\0\0\0\18\1\0\0\0\20\1\0\0\0\23\1\0\0\0\24\1\0\0\0\26\1\0\16\0\29\1\0\1\0\31\1\0\0\0!\1\0\0\0"\1\0\0\0$\1\0\0\0)\1\0\0\0*\1\0\0\00\1\0\0\02\1\0\0\06\1\0\0\0I\1\0\0\0\231\1\0\0\0\232\1\0\0\0\235\1\0\0\0\237\1\0\0\0'
ModemManager[13321]: [1734028733.435136] Cannot read from
istream: connection broken
ModemManager[13321]: [1734028733.435205] [/dev/cdc-wdm0]
endpoint hangup: removed
ModemManager[13321]: [1734028733.435485] [cdc-wdm0/qmi] QMI port
open operation failed: endpoint hangup
ModemManager[13321]: [1734028733.435821] [cdc-wdm0/probe] error
checking QMI support: endpoint hangup
ModemManager[13321]: [1734028733.435881] [cdc-wdm0/probe] port
is not QMI-capable
ModemManager[13321]: [1734028733.436181] [cdc-wdm0/probe] probe
step: done
The line containing binary dump with '[cdc-wdm0/at]' faintly suggests, that
port type might be misdetected - but - I have yet to confirm that.
Since the issue was caused by pretty significant refactoring, it may take some
time, but maybe someone can spot the error faster - so I'm reaching out for
help, especially to Dan :-)
Reproducibility is around 50%
Any help would be greatly appreciated.
--
Pozdrawiam/With kind regards,
Lech Perczak
Sr. Software Engineer
Camlin Technologies Poland Limited Sp. z o.o.
Strzegomska 54,
53-611 Wroclaw
Tel: (+48) 71 75 000 16
Email: lech.perc...@camlingroup.com
Website: http://www.camlingroup.com
le910c4_qmi_probe_fail.pcap
Description: application/vnd.tcpdump.pcap
Re: Random QMI port probe failures after ed13e053cd42 ("port-probe: fix custom init probing not having open AT port")
Hello Aleksander, Dan It works perfect now again, thanks! I'm sorry that I totally forgot about this thread - but still letting you know. With kind regards, Lech W dniu 22.12.2024 o 19:13, Aleksander Morgado pisze: > Hey, > > On Sun, Dec 22, 2024 at 6:49 PM Aleksander Morgado > wrote: > > > > On Sun, Dec 22, 2024 at 6:37 PM Aleksander Morgado > wrote: > > Hey, > > > > > After updating to the latest main (at eda130f3bf1c), in our > team > > > we've noticed, that in our CI, that QMI port sometimes fails > to > > > probe, > > > with Telit LE910C4-WWXD. The result is the modem having only > AT > > > ports > > > available, thus falling back to using PPP for the data > connection. > > > > Well that's not awesome; I'll dig into it. If you figure out > anything > > too, let me know. > > > > When this happens, does MM attempt to probe the port as AT before > trying QMI? > > > With the changes in that referenced commit, it looks like > serial_probe_step() may be running serial_open_at() also for the QMI and MBIM > ports, which is not right, as that would create a new MMSerialPort in > ctx->serial. > > The serial_probe_step() (ideally renamed as probe_step() to make it > clearer that it is not serial-specific) should not run any serial-specific > operation (e.g. CUSTOM_INIT, AT_OPEN_PORT, ) for ports that do not > require any AT or QCDM probing. > > WDYT? > > > The issue can be reproduced with modems for which the corresponding > plugin has "custom_init" configured, e.g. Telit or Cinterion: > > ModemManager[4112]: [1734889629.161510] [cdc-wdm0/probe] no > AT/QCDM/QMI probing in possible MBIM port > ModemManager[4112]: [1734889629.162057] [cdc-wdm0/probe] port is > not AT-capable > ModemManager[4112]: [1734889629.162867] [cdc-wdm0/probe] port is > not QCDM-capable > ModemManager[4112]: [1734889629.163621] [cdc-wdm0/probe] port is > not QMI-capable > ModemManager[4112]: [1734889629.164981] [cdc-wdm0/probe] launching > port probing: 'mbim' > ModemManager[4112]: [1734889629.166516] [cdc-wdm0/probe] probe > step: start > ModemManager[4112]: [1734889629.166988] [cdc-wdm0/probe] probe > step: custom init open port > > > I tried to fix this with > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1273 > > <https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1273> > > Let us know if this solves the problem completely or not. > > ___ > > This email originated from outside of Camlin Group. Do not click on links or > open attachments unless you are confident they are secure. If in doubt, > please raise a security incident via the following portal: Camlin Helpdesk – > Report an Information Security Incident/Non-Conformance > <https://camlin-helpdesk.atlassian.net/servicedesk/customer/portal/2/group/34/create/62> > -- Pozdrawiam/With kind regards, Lech Perczak Sr. Software Engineer Camlin Technologies Poland Limited Sp. z o.o. Strzegomska 54, 53-611 Wroclaw Tel: (+48) 71 75 000 16 Email: lech.perc...@camlingroup.com Website: http://www.camlingroup.com
