[PATCH 1/1] plugins: telit: add supported modes loading

[Daniele Palmas]

This patch add supported modes loading in Telit plugin.
---
 plugins/telit/mm-broadband-modem-telit.c | 173 +++
 1 file changed, 173 insertions(+)

diff --git a/plugins/telit/mm-broadband-modem-telit.c 
b/plugins/telit/mm-broadband-modem-telit.c
index 77b1800..3866e54 100644
--- a/plugins/telit/mm-broadband-modem-telit.c
+++ b/plugins/telit/mm-broadband-modem-telit.c
@@ -536,6 +536,177 @@ setup_flow_control (MMIfaceModem *self,
 }
 
 /*/
+/* Load supported modes (Modem interface) */
+
+typedef struct {
+GSimpleAsyncResult *result;
+MMBroadbandModem *self;
+MMModemMode mode;
+gboolean run_ws46;
+} LoadSupportedModesContext;
+
+static void
+load_supported_modes_context_complete_and_free (LoadSupportedModesContext *ctx)
+{
+g_simple_async_result_complete (ctx->result);
+g_object_unref (ctx->result);
+g_object_unref (ctx->self);
+g_slice_free (LoadSupportedModesContext, ctx);
+}
+
+static GArray *
+modem_load_supported_modes_finish (MMIfaceModem *self,
+   GAsyncResult *res,
+   GError **error)
+{
+GArray *modes;
+MMModemModeCombination mode;
+
+if (g_simple_async_result_propagate_error (G_SIMPLE_ASYNC_RESULT (res), 
error))
+return NULL;
+
+/* Build a mask with all supported modes */
+modes = g_array_sized_new (FALSE, FALSE, sizeof (MMModemModeCombination), 
1);
+mode.allowed = (MMModemMode) GPOINTER_TO_UINT 
(g_simple_async_result_get_op_res_gpointer (
+   G_SIMPLE_ASYNC_RESULT 
(res)));
+mode.preferred = MM_MODEM_MODE_NONE;
+g_array_append_val (modes, mode);
+
+return modes;
+}
+
+static void load_supported_modes_step (LoadSupportedModesContext *ctx);
+
+static void
+supported_modes_ws46_test_ready (MMBroadbandModem *self,
+ GAsyncResult *res,
+ LoadSupportedModesContext *ctx)
+{
+const gchar *response;
+GError *error = NULL;
+
+response = mm_base_modem_at_command_finish (MM_BASE_MODEM (self), res, 
);
+if (!error) {
+MMModemMode mode = MM_MODEM_MODE_NONE;
+
+/*
+ * More than one numeric ID may appear in the list, that's why
+ * they are checked separately.
+ *
+ * From 3GPP TS 27.007 v.11.2.0, section 5.9
+ * 12   GSM Digital Cellular Systems (GERAN only)
+ * 22   UTRAN only
+ * 25   3GPP Systems (GERAN, UTRAN and E-UTRAN)
+ * 28   E-UTRAN only
+ * 29   GERAN and UTRAN
+ * 30   GERAN and E-UTRAN
+ * 31   UTRAN and E-UTRAN
+ */
+
+if (strstr (response, "12") != NULL) {
+mm_dbg ("Device allows (3GPP) 2G-only network mode");
+mode |= MM_MODEM_MODE_2G;
+}
+
+if (strstr (response, "22") != NULL) {
+mm_dbg ("Device allows (3GPP) 3G-only network mode");
+mode |= MM_MODEM_MODE_3G;
+}
+
+if (strstr (response, "28") != NULL) {
+mm_dbg ("Device allows (3GPP) 4G-only network mode");
+mode |= MM_MODEM_MODE_4G;
+}
+
+if (strstr (response, "29") != NULL) {
+mm_dbg ("Device allows (3GPP) 2G/3G network mode");
+mode |= (MM_MODEM_MODE_2G | MM_MODEM_MODE_3G);
+}
+
+if (strstr (response, "30") != NULL) {
+mm_dbg ("Device allows (3GPP) 2G/4G network mode");
+mode |= (MM_MODEM_MODE_2G | MM_MODEM_MODE_4G);
+}
+
+if (strstr (response, "31") != NULL) {
+mm_dbg ("Device allows (3GPP) 3G/4G network mode");
+mode |= (MM_MODEM_MODE_3G | MM_MODEM_MODE_4G);
+}
+
+if (strstr (response, "25") != NULL) {
+if (mm_iface_modem_is_3gpp_lte (MM_IFACE_MODEM (self))) {
+mm_dbg ("Device allows every supported 3GPP network mode 
(2G/3G/4G)");
+mode |= (MM_MODEM_MODE_2G | MM_MODEM_MODE_3G | 
MM_MODEM_MODE_4G);
+} else {
+mm_dbg ("Device allows every supported 3GPP network mode 
(2G/3G)");
+mode |= (MM_MODEM_MODE_2G | MM_MODEM_MODE_3G);
+}
+}
+
+/* If no expected ID found, log error */
+if (mode == MM_MODEM_MODE_NONE)
+mm_dbg ("Invalid list of supported networks reported by WS46=?: 
'%s'", response);
+else
+ctx->mode |= mode;
+} else {
+mm_dbg ("Generic query of supported 3GPP networks with WS46=? failed: 
'%s'", error->message);
+g_error_free (error);
+}
+
+/* Now finish the supported mode check */
+ctx->run_ws46 = FALSE;
+load_supported_modes_step (ctx);
+}
+
+static void
+load_supported_modes_step (LoadSupportedModesContext *ctx)
+{
+if (ctx->run_ws46) {
+mm_base_modem_at_command (
+MM_BASE_MODEM (ctx->self),
+   

[PATCH 0/2] plugin: telit: add supported and current modes loading

[Daniele Palmas]

This patch series adds supported and current modes loading for Telit plugin

Daniele Palmas (2):
  plugin: telit: add supported modes loading
  plugin: telit: add current mode loading

 plugins/telit/mm-broadband-modem-telit.c | 186 +++
 1 file changed, 186 insertions(+)

-- 
2.7.0

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 1/2] plugin: telit: add supported modes loading

[Daniele Palmas]

This patch add supported modes loading in Telit plugin.
---
 plugins/telit/mm-broadband-modem-telit.c | 104 +++
 1 file changed, 104 insertions(+)

diff --git a/plugins/telit/mm-broadband-modem-telit.c 
b/plugins/telit/mm-broadband-modem-telit.c
index 77b1800..5b3d18c 100644
--- a/plugins/telit/mm-broadband-modem-telit.c
+++ b/plugins/telit/mm-broadband-modem-telit.c
@@ -36,6 +36,8 @@
 static void iface_modem_init (MMIfaceModem *iface);
 static void iface_modem_3gpp_init (MMIfaceModem3gpp *iface);
 
+static MMIfaceModem *iface_modem_parent;
+
 G_DEFINE_TYPE_EXTENDED (MMBroadbandModemTelit, mm_broadband_modem_telit, 
MM_TYPE_BROADBAND_MODEM, 0,
 G_IMPLEMENT_INTERFACE (MM_TYPE_IFACE_MODEM, 
iface_modem_init)
 G_IMPLEMENT_INTERFACE (MM_TYPE_IFACE_MODEM_3GPP, 
iface_modem_3gpp_init));
@@ -536,6 +538,104 @@ setup_flow_control (MMIfaceModem *self,
 }
 
 /*/
+/* Load supported modes (Modem interface) */
+
+static GArray *
+load_supported_modes_finish (MMIfaceModem *self,
+ GAsyncResult *res,
+ GError **error)
+{
+if (g_simple_async_result_propagate_error (G_SIMPLE_ASYNC_RESULT (res), 
error))
+return NULL;
+
+return g_array_ref (g_simple_async_result_get_op_res_gpointer 
(G_SIMPLE_ASYNC_RESULT (res)));
+}
+
+static void
+parent_load_supported_modes_ready (MMIfaceModem *self,
+   GAsyncResult *res,
+   GSimpleAsyncResult *simple)
+{
+GError *error = NULL;
+GArray *all;
+GArray *combinations;
+GArray *filtered;
+MMModemModeCombination mode;
+
+all = iface_modem_parent->load_supported_modes_finish (self, res, );
+if (!all) {
+g_simple_async_result_take_error (simple, error);
+g_simple_async_result_complete (simple);
+g_object_unref (simple);
+return;
+}
+
+/* CDMA-only modems don't support changing modes, default to parent's */
+if (!mm_iface_modem_is_3gpp (self)) {
+g_simple_async_result_set_op_res_gpointer (simple, all, 
(GDestroyNotify) g_array_unref);
+g_simple_async_result_complete_in_idle (simple);
+g_object_unref (simple);
+return;
+}
+
+/* Build list of combinations for 3GPP devices */
+combinations = g_array_sized_new (FALSE, FALSE, sizeof 
(MMModemModeCombination), 7);
+
+/* 2G only */
+mode.allowed = MM_MODEM_MODE_2G;
+mode.preferred = MM_MODEM_MODE_NONE;
+g_array_append_val (combinations, mode);
+/* 3G only */
+mode.allowed = MM_MODEM_MODE_3G;
+mode.preferred = MM_MODEM_MODE_NONE;
+g_array_append_val (combinations, mode);
+/* 2G and 3G */
+mode.allowed = (MM_MODEM_MODE_2G | MM_MODEM_MODE_3G);
+mode.preferred = MM_MODEM_MODE_NONE;
+g_array_append_val (combinations, mode);
+/* 4G only */
+mode.allowed = MM_MODEM_MODE_4G;
+mode.preferred = MM_MODEM_MODE_NONE;
+g_array_append_val (combinations, mode);
+/* 2G and 4G */
+mode.allowed = (MM_MODEM_MODE_2G | MM_MODEM_MODE_4G);
+mode.preferred = MM_MODEM_MODE_NONE;
+g_array_append_val (combinations, mode);
+/* 3G and 4G */
+mode.allowed = (MM_MODEM_MODE_3G | MM_MODEM_MODE_4G);
+mode.preferred = MM_MODEM_MODE_NONE;
+g_array_append_val (combinations, mode);
+/* 2G, 3G and 4G */
+mode.allowed = (MM_MODEM_MODE_2G | MM_MODEM_MODE_3G | MM_MODEM_MODE_4G);
+mode.preferred = MM_MODEM_MODE_NONE;
+g_array_append_val (combinations, mode);
+
+/* Filter out those unsupported modes */
+filtered = mm_filter_supported_modes (all, combinations);
+g_array_unref (all);
+g_array_unref (combinations);
+
+g_simple_async_result_set_op_res_gpointer (simple, filtered, 
(GDestroyNotify) g_array_unref);
+g_simple_async_result_complete (simple);
+g_object_unref (simple);
+}
+
+static void
+load_supported_modes (MMIfaceModem *self,
+  GAsyncReadyCallback callback,
+  gpointer user_data)
+{
+/* Run parent's loading */
+iface_modem_parent->load_supported_modes (
+MM_IFACE_MODEM (self),
+(GAsyncReadyCallback)parent_load_supported_modes_ready,
+g_simple_async_result_new (G_OBJECT (self),
+   callback,
+   user_data,
+   load_supported_modes));
+}
+
+/*/
 /* Enabling unsolicited events (3GPP interface) */
 
 static gboolean
@@ -601,6 +701,8 @@ mm_broadband_modem_telit_init (MMBroadbandModemTelit *self)
 static void
 iface_modem_init (MMIfaceModem *iface)
 {
+iface_modem_parent = g_type_interface_peek_parent (iface);
+
 iface->load_supported_bands = modem_load_supported_bands;
 iface->load_supported_bands_finish = 

[PATCH 1/1] plugins: telit: add current modes setting

[Daniele Palmas]

This patch adds current modes setting in Telit plugin
---
 plugins/telit/mm-broadband-modem-telit.c | 98 
 1 file changed, 98 insertions(+)

diff --git a/plugins/telit/mm-broadband-modem-telit.c 
b/plugins/telit/mm-broadband-modem-telit.c
index d4b0a42..0127314 100644
--- a/plugins/telit/mm-broadband-modem-telit.c
+++ b/plugins/telit/mm-broadband-modem-telit.c
@@ -654,6 +654,102 @@ load_current_modes (MMIfaceModem *self,
 }
 
 /*/
+/* Set current modes (Modem interface) */
+
+static gboolean
+set_current_modes_finish (MMIfaceModem *self,
+  GAsyncResult *res,
+  GError **error)
+{
+return !g_simple_async_result_propagate_error (G_SIMPLE_ASYNC_RESULT 
(res), error);
+}
+
+static void
+ws46_set_ready (MMIfaceModem *self,
+GAsyncResult *res,
+GSimpleAsyncResult *operation_result)
+{
+GError *error = NULL;
+
+mm_base_modem_at_command_finish (MM_BASE_MODEM (self), res, );
+if (error)
+/* Let the error be critical. */
+g_simple_async_result_take_error (operation_result, error);
+else
+g_simple_async_result_set_op_res_gboolean (operation_result, TRUE);
+g_simple_async_result_complete (operation_result);
+g_object_unref (operation_result);
+}
+
+static void
+set_current_modes (MMIfaceModem *self,
+   MMModemMode allowed,
+   MMModemMode preferred,
+   GAsyncReadyCallback callback,
+   gpointer user_data)
+{
+GSimpleAsyncResult *result;
+gchar *command;
+gint ws46_mode = -1;
+
+result = g_simple_async_result_new (G_OBJECT (self),
+callback,
+user_data,
+set_current_modes);
+
+if (allowed == MM_MODEM_MODE_2G)
+ws46_mode = 12;
+else if (allowed == MM_MODEM_MODE_3G)
+ws46_mode = 22;
+else if (allowed == MM_MODEM_MODE_4G)
+ws46_mode = 28;
+else if (allowed == (MM_MODEM_MODE_2G | MM_MODEM_MODE_3G)) {
+if (mm_iface_modem_is_3gpp_lte (self))
+ws46_mode = 29;
+else
+ws46_mode = 25;
+} else if (allowed == (MM_MODEM_MODE_2G | MM_MODEM_MODE_4G))
+ws46_mode = 30;
+else if (allowed == (MM_MODEM_MODE_3G | MM_MODEM_MODE_4G))
+ws46_mode = 31;
+else if (allowed == (MM_MODEM_MODE_2G  | MM_MODEM_MODE_3G | 
MM_MODEM_MODE_4G) ||
+ allowed == MM_MODEM_MODE_ANY)
+ws46_mode = 25;
+
+/* Telit modems do not support preferred mode selection */
+if ((ws46_mode < 0) || (preferred != MM_MODEM_MODE_NONE)) {
+gchar *allowed_str;
+gchar *preferred_str;
+
+allowed_str = mm_modem_mode_build_string_from_mask (allowed);
+preferred_str = mm_modem_mode_build_string_from_mask (preferred);
+g_simple_async_result_set_error (result,
+ MM_CORE_ERROR,
+ MM_CORE_ERROR_FAILED,
+ "Requested mode (allowed: '%s', 
preferred: '%s') not "
+ "supported by the modem.",
+ allowed_str,
+ preferred_str);
+g_free (allowed_str);
+g_free (preferred_str);
+
+g_simple_async_result_complete_in_idle (result);
+g_object_unref (result);
+return;
+}
+
+command = g_strdup_printf ("AT+WS46=%d", ws46_mode);
+mm_base_modem_at_command (
+MM_BASE_MODEM (self),
+command,
+10,
+FALSE,
+(GAsyncReadyCallback)ws46_set_ready,
+result);
+g_free (command);
+}
+
+/*/
 /* Load supported modes (Modem interface) */
 
 static GArray *
@@ -837,6 +933,8 @@ iface_modem_init (MMIfaceModem *iface)
 iface->load_supported_modes_finish = load_supported_modes_finish;
 iface->load_current_modes = load_current_modes;
 iface->load_current_modes_finish = load_current_modes_finish;
+iface->set_current_modes = set_current_modes;
+iface->set_current_modes_finish = set_current_modes_finish;
 }
 
 static void
-- 
2.7.0

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: LE910 (used with qmi generic) not working anymore with 1.6-rc2

[Daniele Palmas]

Hi Aleksander,

2016-04-08 13:11 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
> On Thu, Apr 7, 2016 at 12:57 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>> The error seems to be triggered by this:
>>
>> ModemManagere[30896]:  [1460023605.770238]
>> [mm-port-probe-at.c:43] mm_port_probe_response_processor_is_at():
>> Parsing AT got: 'Sending command failed: 'Resource temporarily
>> unavailable''
>>
>> The following patch seems to solve the issue, but I'm not sure it is
>> the right approach.
>>
>> ---
>>  src/mm-port-probe-at.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mm-port-probe-at.c b/src/mm-port-probe-at.c
>> index 10cce9e..b9696f1 100644
>> --- a/src/mm-port-probe-at.c
>> +++ b/src/mm-port-probe-at.c
>> @@ -46,7 +46,10 @@ mm_port_probe_response_processor_is_at (const gchar 
>> *command,
>>   * they will just go on to the next command. */
>>  if (g_error_matches (error,
>>   MM_SERIAL_ERROR,
>> - MM_SERIAL_ERROR_RESPONSE_TIMEOUT)) {
>> + MM_SERIAL_ERROR_RESPONSE_TIMEOUT) ||
>> +g_error_matches (error,
>> + MM_SERIAL_ERROR,
>> + MM_SERIAL_ERROR_SEND_FAILED)) {
>>  return FALSE;
>>  }
>
> Any chance you can get the MM logs before commit
> 1939c5ace50240127276efacec5c7f166483bb79? That commit changed when the
> serial completion was done (idle or not in idle); I believe your patch
> is nowhere related to that issue, so that's why I ask. It is an
> important thing to fix, we should get it right.
>

the error seems to appear also with no modem attached.

I have the following logs:

commit: 1939c5ace50240127276efacec5c7f166483bb79
no modem attached
http://pastebin.com/LysiMzLz

commit: 1939c5ace50240127276efacec5c7f166483bb79
le910 attached
mm_1939c5ace50240127276efacec5c7f166483bb79_le910
http://pastebin.com/qsLfw1st

commit: d9596587e294ffde715fb2a7ef877da9f903558a (port-serial: allow
completions not in idle)
le910 attached
mm_d9596587e294ffde715fb2a7ef877da9f903558a_le910
http://pastebin.com/GQKBHZqe

Thanks,
Daniele

> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] port-probe: make sure stored task pointer is set to NULL before completing

[Daniele Palmas]

Hi Aleksander,

2016-04-08 16:42 GMT+02:00 Aleksander Morgado :
> When we were completing tasks in idle, the logic was like this:
>
>  * Schedule task completion in idle
>  * self->priv->task = NULL
>  * (idle) Task completion callback called
>
> This meant that the self->priv->task was always set to NULL before the
> completion callback was called, which is what we wanted as a new task may be
> scheduled in the callback itself.
>
> Now, without completing in idle, we were wrongly doing:
>
>  * Task completion callback called
>  * self->priv->task = NULL
>
> This commit fixes the logic by making sure self->priv->task = NULL before any
> task completion.
> ---
>
> Daniele, can you validate that this patch fixes your issue?
>

According to a quick test I did, it seems to fix the issue on LE910.

On Monday I will do more testing.

Thank you very much for your help!

Regards,
Daniele

> ---
>  src/mm-port-probe.c | 184 
> 
>  1 file changed, 100 insertions(+), 84 deletions(-)
>
> diff --git a/src/mm-port-probe.c b/src/mm-port-probe.c
> index a1ca8ba..5d2428a 100644
> --- a/src/mm-port-probe.c
> +++ b/src/mm-port-probe.c
> @@ -95,6 +95,50 @@ struct _MMPortProbePrivate {
>  };
>
>  
> /*/
> +/* Probe task completions.
> + * Always make sure that the stored task is NULL when the task is completed.
> + */
> +
> +static gboolean
> +port_probe_task_return_error_if_cancelled (MMPortProbe *self)
> +{
> +GTask *task;
> +
> +task = self->priv->task;
> +self->priv->task = NULL;
> +
> +if (g_task_return_error_if_cancelled (task)) {
> +g_object_unref (task);
> +return TRUE;
> +}
> +
> +self->priv->task = task;
> +return FALSE;
> +}
> +
> +static void
> +port_probe_task_return_error (MMPortProbe *self,
> +  GError  *error)
> +{
> +GTask *task;
> +
> +task = self->priv->task;
> +self->priv->task = NULL;
> +g_task_return_error (task, error);
> +}
> +
> +static void
> +port_probe_task_return_boolean (MMPortProbe *self,
> +gboolean result)
> +{
> +GTask *task;
> +
> +task = self->priv->task;
> +self->priv->task = NULL;
> +g_task_return_boolean (task, result);
> +}
> +
> +/*/
>
>  void
>  mm_port_probe_set_result_at (MMPortProbe *self,
> @@ -527,10 +571,8 @@ wdm_probe (MMPortProbe *self)
>  ctx->source_id = 0;
>
>  /* If already cancelled, do nothing else */
> -if (g_task_return_error_if_cancelled (self->priv->task)) {
> -g_clear_object (>priv->task);
> +if (port_probe_task_return_error_if_cancelled (self))
>  return G_SOURCE_REMOVE;
> -}
>
>  /* QMI probing needed? */
>  if ((ctx->flags & MM_PORT_PROBE_QMI) &&
> @@ -547,8 +589,7 @@ wdm_probe (MMPortProbe *self)
>  }
>
>  /* All done now */
> -g_task_return_boolean (self->priv->task, TRUE);
> -g_clear_object (>priv->task);
> +port_probe_task_return_boolean (self, TRUE);
>  return G_SOURCE_REMOVE;
>  }
>
> @@ -571,10 +612,8 @@ serial_probe_qcdm_parse_response (MMPortSerialQcdm *port,
>  ctx = g_task_get_task_data (self->priv->task);
>
>  /* If already cancelled, do nothing else */
> -if (g_task_return_error_if_cancelled (self->priv->task)) {
> -g_clear_object (>priv->task);
> +if (port_probe_task_return_error_if_cancelled (self))
>  return;
> -}
>
>  response = mm_port_serial_qcdm_command_finish (port, res, );
>  if (!error) {
> @@ -642,10 +681,8 @@ serial_probe_qcdm (MMPortProbe *self)
>  ctx->source_id = 0;
>
>  /* If already cancelled, do nothing else */
> -if (g_task_return_error_if_cancelled (self->priv->task)) {
> -g_clear_object (>priv->task);
> +if (port_probe_task_return_error_if_cancelled (self))
>  return G_SOURCE_REMOVE;
> -}
>
>  mm_dbg ("(%s/%s) probing QCDM...",
>  g_udev_device_get_subsystem (self->priv->port),
> @@ -665,27 +702,25 @@ serial_probe_qcdm (MMPortProbe *self)
>  /* Open the QCDM port */
>  ctx->serial = MM_PORT_SERIAL (mm_port_serial_qcdm_new 
> (g_udev_device_get_name (self->priv->port)));
>  if (!ctx->serial) {
> -g_task_return_new_error (self->priv->task,
> - MM_CORE_ERROR,
> - MM_CORE_ERROR_FAILED,
> - "(%s/%s) Couldn't create QCDM port",
> - g_udev_device_get_subsystem 
> (self->priv->port),
> - g_udev_device_get_name (self->priv->port));
> -g_clear_object (>priv->task);
> +port_probe_task_return_error (self,
> +  g_error_new (MM_CORE_ERROR,
> +   

Re: [PATCH] port-probe: make sure stored task pointer is set to NULL before completing

[Daniele Palmas]

Hi Carlo,

2016-04-11 10:55 GMT+02:00 Daniele Palmas <dnl...@gmail.com>:
> Hi Aleksander,
>
> 2016-04-08 17:14 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
>> On Fri, Apr 8, 2016 at 4:55 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>>> 2016-04-08 16:42 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
>>>> When we were completing tasks in idle, the logic was like this:
>>>>
>>>>  * Schedule task completion in idle
>>>>  * self->priv->task = NULL
>>>>  * (idle) Task completion callback called
>>>>
>>>> This meant that the self->priv->task was always set to NULL before the
>>>> completion callback was called, which is what we wanted as a new task may 
>>>> be
>>>> scheduled in the callback itself.
>>>>
>>>> Now, without completing in idle, we were wrongly doing:
>>>>
>>>>  * Task completion callback called
>>>>  * self->priv->task = NULL
>>>>
>>>> This commit fixes the logic by making sure self->priv->task = NULL before 
>>>> any
>>>> task completion.
>>>> ---
>>>>
>>>> Daniele, can you validate that this patch fixes your issue?
>>>>
>>>
>>> According to a quick test I did, it seems to fix the issue on LE910.
>>
>> I'll get the patch merged to git master, and if your tests on Monday
>> go well, I'll release a new rc with this fix.
>>
>
> I confirm that the issue I was seeing has been fixed by your patch.
> Thanks again!
>

Can you please also test with HE910 and LE910 V2?

Thanks,
Daniele

> Regards,
> Daniele
>
>> --
>> Aleksander
>> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] port-probe: make sure stored task pointer is set to NULL before completing

[Daniele Palmas]

Hi Aleksander,

2016-04-08 17:14 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
> On Fri, Apr 8, 2016 at 4:55 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>> 2016-04-08 16:42 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
>>> When we were completing tasks in idle, the logic was like this:
>>>
>>>  * Schedule task completion in idle
>>>  * self->priv->task = NULL
>>>  * (idle) Task completion callback called
>>>
>>> This meant that the self->priv->task was always set to NULL before the
>>> completion callback was called, which is what we wanted as a new task may be
>>> scheduled in the callback itself.
>>>
>>> Now, without completing in idle, we were wrongly doing:
>>>
>>>  * Task completion callback called
>>>  * self->priv->task = NULL
>>>
>>> This commit fixes the logic by making sure self->priv->task = NULL before 
>>> any
>>> task completion.
>>> ---
>>>
>>> Daniele, can you validate that this patch fixes your issue?
>>>
>>
>> According to a quick test I did, it seems to fix the issue on LE910.
>
> I'll get the patch merged to git master, and if your tests on Monday
> go well, I'll release a new rc with this fix.
>

I confirm that the issue I was seeing has been fixed by your patch.
Thanks again!

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: LE910 (used with qmi generic) not working anymore with 1.6-rc2

[Daniele Palmas]

The error seems to be triggered by this:

ModemManagere[30896]:  [1460023605.770238]
[mm-port-probe-at.c:43] mm_port_probe_response_processor_is_at():
Parsing AT got: 'Sending command failed: 'Resource temporarily
unavailable''

The following patch seems to solve the issue, but I'm not sure it is
the right approach.

---
 src/mm-port-probe-at.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mm-port-probe-at.c b/src/mm-port-probe-at.c
index 10cce9e..b9696f1 100644
--- a/src/mm-port-probe-at.c
+++ b/src/mm-port-probe-at.c
@@ -46,7 +46,10 @@ mm_port_probe_response_processor_is_at (const gchar *command,
  * they will just go on to the next command. */
 if (g_error_matches (error,
  MM_SERIAL_ERROR,
- MM_SERIAL_ERROR_RESPONSE_TIMEOUT)) {
+ MM_SERIAL_ERROR_RESPONSE_TIMEOUT) ||
+g_error_matches (error,
+ MM_SERIAL_ERROR,
+ MM_SERIAL_ERROR_SEND_FAILED)) {
 return FALSE;
 }

-- 
2.7.0


Regards,
Daniele

2016-04-07 9:24 GMT+02:00 Daniele Palmas <dnl...@gmail.com>:
> Hi all,
>
> LE910 (used with qmi generic) seems not to be working anymore with
> 1.6-rc2. Last lines of the log are:
>
> ModemManagere[21197]:  [1460013743.234084]
> [mm-plugin-manager.c:434] port_context_defer_until_suggested():
> [plugin manager] task 2,wwan0: completed, got suggested plugin
> (Generic)
> ModemManagere[21197]:  [1460013743.234090]
> [mm-plugin-manager.c:265] port_context_complete(): [plugin manager]
> task 2,wwan0: finished in '1.621374' seconds
> ModemManagere[21197]:  [1460013743.234096]
> [mm-plugin-manager.c:966] device_context_set_best_plugin(): [plugin
> manager] task 2,wwan0: best plugin matches device reported one:
> Generic
> ModemManagere[21197]:  [1460013743.234102]
> [mm-plugin-manager.c:1005] device_context_continue(): [plugin Manager]
> task 2: still 5 running probes (5 active): ttyUSB1, ttyUSB2, ttyUSB0,
> ttyUSB4, ttyUSB3
> ModemManagere[21197]:  [1460013744.112978]
> [mm-plugin-manager.c:1058] device_context_min_probing_time_elapsed():
> [plugin manager] task 2: min probing time elapsed
> ModemManagere[21197]:  [1460013744.113019]
> [mm-plugin-manager.c:1005] device_context_continue(): [plugin Manager]
> task 2: still 5 running probes (5 active): ttyUSB1, ttyUSB2, ttyUSB0,
> ttyUSB4, ttyUSB3
> ModemManagere[21197]:  [1460013744.230433]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB3): <-- '+CME
> ERROR: 100'
> ModemManagere[21197]:  [1460013744.230539]
> [mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure
> code 100: Unknown error
> ModemManagere[21197]:  [1460013744.230584]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB2): <-- '+CME
> ERROR: 100'
> ModemManagere[21197]:  [1460013744.230594]
> [mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure
> code 100: Unknown error
> ModemManagere[21197]:  [1460013744.230627]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB3): --> 'AT'
> ModemManagere[21197]:  [1460013744.230639]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB2): --> 'AT'
> ModemManagere[21197]:  [1460013744.432433]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB2): <--
> 'OK'
> ModemManagere[21197]:  [1460013744.432588]
> [mm-port-probe.c:109] mm_port_probe_set_result_at(): (tty/ttyUSB2)
> port is AT-capable
> ModemManagere[21197]:  [1460013744.432678]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB3): <--
> 'OK'
> ModemManagere[21197]:  [1460013744.432725]
> [mm-port-probe.c:109] mm_port_probe_set_result_at(): (tty/ttyUSB3)
> port is AT-capable
> ModemManagere[21197]:  [1460013744.432808]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB2): --> 'AT+CGMI'
> ModemManagere[21197]:  [1460013744.432849]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB3): --> 'AT+CGMI'
> ModemManagere[21197]:  [1460013745.137141]
> [mm-port-serial-at.c:459] debug_log(): (ttyUSB2): <--
> 'TelitOK'
> ModemManagere[21197]:  [1460013745.137280]
> [mm-port-probe.c:136] mm_port_probe_set_result_at_vendor():
> (tty/ttyUSB2) vendor probing finished
> ModemManagere[21197]:  [1460013745.137347] [mm-plugin.c:479]
> apply_post_probing_filters(): (Cinterion) [ttyUSB2] filtered by vendor
> strings
> ModemManagere[21197]:  [1460013745.137367]
> [mm-plugin-manager.c:519] port_context_next(): [plugin manager] task
> 2,ttyUSB2: checking with plugin 'Generic'
> ModemManagere[21197]:  [1460013745.137397] [mm-plugin.c:804]
> mm_plugin_supports_port(): (Generic) [ttyUSB2] probe required: 'at,
> qcdm'
> ModemManagere[21197]:  [1460013745.137413]
> [mm-port-probe.c:1348] mm_port_probe_run(): (tty/ttyUSB2) port probing
> finished: no more probin

[PATCH 4/4] build: modified Telit and Dell sections

[Daniele Palmas]

This patch adds section for building Telit common code and modifies
Dell section for using Telit library
---
 plugins/Makefile.am | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/plugins/Makefile.am b/plugins/Makefile.am
index 018b696..31d222a 100644
--- a/plugins/Makefile.am
+++ b/plugins/Makefile.am
@@ -217,6 +217,22 @@ NOVATEL_COMMON_COMPILER_FLAGS = 
-I$(top_srcdir)/plugins/novatel
 NOVATEL_COMMON_LIBADD_FLAGS   = $(builddir)/libmm-utils-novatel.la
 
 

+# common telit support
+
+
+# Common telit modem support library
+noinst_LTLIBRARIES += libmm-utils-telit.la
+libmm_utils_telit_la_SOURCES = \
+   telit/mm-common-telit.c \
+   telit/mm-common-telit.h \
+   telit/mm-broadband-modem-telit.c \
+   telit/mm-broadband-modem-telit.h \
+   $(NULL)
+
+TELIT_COMMON_COMPILER_FLAGS = -I$(top_srcdir)/plugins/telit
+TELIT_COMMON_LIBADD_FLAGS   = $(builddir)/libmm-utils-telit.la
+
+
 # plugin: generic
 

 
@@ -663,7 +679,7 @@ libmm_plugin_novatel_la_LDFLAGS  = 
$(PLUGIN_COMMON_LINKER_FLAGS)
 libmm_plugin_novatel_la_LIBADD   = $(NOVATEL_COMMON_LIBADD_FLAGS)
 
 

-# plugin: dell (novatel or sierra)
+# plugin: dell (novatel, sierra or telit)
 

 
 pkglib_LTLIBRARIES += libmm-plugin-dell.la
@@ -671,9 +687,11 @@ libmm_plugin_dell_la_SOURCES = \
dell/mm-plugin-dell.c \
dell/mm-plugin-dell.h \
$(NULL)
-libmm_plugin_dell_la_CPPFLAGS = $(PLUGIN_COMMON_COMPILER_FLAGS) 
$(NOVATEL_COMMON_COMPILER_FLAGS) $(SIERRA_COMMON_COMPILER_FLAGS) 
$(MBM_COMMON_COMPILER_FLAGS)
+libmm_plugin_dell_la_CPPFLAGS = $(PLUGIN_COMMON_COMPILER_FLAGS) 
$(NOVATEL_COMMON_COMPILER_FLAGS) $(SIERRA_COMMON_COMPILER_FLAGS) 
$(TELIT_COMMON_COMPILER_FLAGS) $(MBM_COMMON_COMPILER_FLAGS)
 libmm_plugin_dell_la_LDFLAGS  = $(PLUGIN_COMMON_LINKER_FLAGS)
-libmm_plugin_dell_la_LIBADD   = $(NOVATEL_COMMON_LIBADD_FLAGS) 
$(SIERRA_COMMON_LIBADD_FLAGS) $(MBM_COMMON_LIBADD_FLAGS)
+libmm_plugin_dell_la_LIBADD   = $(NOVATEL_COMMON_LIBADD_FLAGS) 
$(SIERRA_COMMON_LIBADD_FLAGS) $(TELIT_COMMON_LIBADD_FLAGS) 
$(MBM_COMMON_LIBADD_FLAGS)
+
+dist_udevrules_DATA += dell/77-mm-dell-port-types.rules
 
 

 # plugin: altair lte
@@ -752,12 +770,10 @@ pkglib_LTLIBRARIES += libmm-plugin-telit.la
 libmm_plugin_telit_la_SOURCES = \
telit/mm-plugin-telit.c \
telit/mm-plugin-telit.h \
-   telit/mm-broadband-modem-telit.c \
-   telit/mm-broadband-modem-telit.h \
$(NULL)
 libmm_plugin_telit_la_CPPFLAGS = $(PLUGIN_COMMON_COMPILER_FLAGS)
 libmm_plugin_telit_la_LDFLAGS  = $(PLUGIN_COMMON_LINKER_FLAGS)
-libmm_plugin_telit_la_LIBADD   = $(builddir)/libhelpers-telit.la
+libmm_plugin_telit_la_LIBADD   = $(builddir)/libhelpers-telit.la 
$(TELIT_COMMON_LIBADD_FLAGS)
 
 dist_udevrules_DATA += telit/77-mm-telit-port-types.rules
 
-- 
2.8.1

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 1/4] telit: code refactoring

[Daniele Palmas]

This patch moves init and port grabbing functions to a separate file
to allow functions call from Dell plugin
---
 plugins/telit/mm-common-telit.c | 318 
 plugins/telit/mm-common-telit.h |  40 +
 plugins/telit/mm-plugin-telit.c | 300 +
 3 files changed, 360 insertions(+), 298 deletions(-)
 create mode 100644 plugins/telit/mm-common-telit.c
 create mode 100644 plugins/telit/mm-common-telit.h

diff --git a/plugins/telit/mm-common-telit.c b/plugins/telit/mm-common-telit.c
new file mode 100644
index 000..e607f2e
--- /dev/null
+++ b/plugins/telit/mm-common-telit.c
@@ -0,0 +1,318 @@
+/* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details:
+ *
+ * Copyright (C) 2015 Aleksander Morgado 
+ */
+
+#include 
+
+#include "mm-common-telit.h"
+#include "mm-log.h"
+
+/*/
+
+#define TAG_GETPORTCFG_SUPPORTED   "getportcfg-supported"
+
+#define TAG_TELIT_MODEM_PORT   "ID_MM_TELIT_PORT_TYPE_MODEM"
+#define TAG_TELIT_AUX_PORT "ID_MM_TELIT_PORT_TYPE_AUX"
+#define TAG_TELIT_NMEA_PORT"ID_MM_TELIT_PORT_TYPE_NMEA"
+
+gboolean
+telit_grab_port (MMPlugin *self,
+ MMBaseModem *modem,
+ MMPortProbe *probe,
+ GError **error)
+{
+GUdevDevice *port;
+MMDevice *device;
+MMPortType ptype;
+MMPortSerialAtFlag pflags = MM_PORT_SERIAL_AT_FLAG_NONE;
+
+port = mm_port_probe_peek_port (probe);
+ptype = mm_port_probe_get_port_type (probe);
+device = mm_port_probe_peek_device (probe);
+
+/* Look for port type hints; just probing can't distinguish which port 
should
+ * be the data/primary port on these devices.  We have to tag them based on
+ * what the Windows .INF files say the port layout should be.
+ *
+ * If no udev rules are found, AT#PORTCFG (if supported) can be used for
+ * identifying the port layout
+ */
+if (g_udev_device_get_property_as_boolean (port, TAG_TELIT_MODEM_PORT)) {
+mm_dbg ("telit: AT port '%s/%s' flagged as primary",
+mm_port_probe_get_port_subsys (probe),
+mm_port_probe_get_port_name (probe));
+pflags = MM_PORT_SERIAL_AT_FLAG_PRIMARY;
+} else if (g_udev_device_get_property_as_boolean (port, 
TAG_TELIT_AUX_PORT)) {
+mm_dbg ("telit: AT port '%s/%s' flagged as secondary",
+mm_port_probe_get_port_subsys (probe),
+mm_port_probe_get_port_name (probe));
+pflags = MM_PORT_SERIAL_AT_FLAG_SECONDARY;
+} else if (g_udev_device_get_property_as_boolean (port, 
TAG_TELIT_NMEA_PORT)) {
+mm_dbg ("telit: port '%s/%s' flagged as NMEA",
+mm_port_probe_get_port_subsys (probe),
+mm_port_probe_get_port_name (probe));
+ptype = MM_PORT_TYPE_GPS;
+} else if (g_object_get_data (G_OBJECT (device), TAG_GETPORTCFG_SUPPORTED) 
!= NULL) {
+if (g_strcmp0 (g_udev_device_get_property (port, 
"ID_USB_INTERFACE_NUM"), g_object_get_data (G_OBJECT (device), 
TAG_TELIT_MODEM_PORT)) == 0) {
+mm_dbg ("telit: AT port '%s/%s' flagged as primary",
+mm_port_probe_get_port_subsys (probe),
+mm_port_probe_get_port_name (probe));
+pflags = MM_PORT_SERIAL_AT_FLAG_PRIMARY;
+} else if (g_strcmp0 (g_udev_device_get_property (port, 
"ID_USB_INTERFACE_NUM"), g_object_get_data (G_OBJECT (device), 
TAG_TELIT_AUX_PORT)) == 0) {
+mm_dbg ("telit: AT port '%s/%s' flagged as secondary",
+mm_port_probe_get_port_subsys (probe),
+mm_port_probe_get_port_name (probe));
+pflags = MM_PORT_SERIAL_AT_FLAG_SECONDARY;
+} else if (g_strcmp0 (g_udev_device_get_property (port, 
"ID_USB_INTERFACE_NUM"), g_object_get_data (G_OBJECT (device), 
TAG_TELIT_NMEA_PORT)) == 0) {
+mm_dbg ("telit: port '%s/%s' flagged as NMEA",
+mm_port_probe_get_port_subsys (probe),
+mm_port_probe_get_port_name (probe));
+ptype = MM_PORT_TYPE_GPS;
+} else
+ptype = MM_PORT_TYPE_IGNORED;
+} else {
+/* If the port was tagged by the udev rules but isn't a primary or 
secondary,
+ * then ignore it to guard against race conditions if a device just 
happens
+ * to show up with more than two AT-capable ports.

Re: [PATCH 2/3] telit: add support for Dell VID in Telit plugin

[Daniele Palmas]

Hi Aleksander,

2016-04-27 21:20 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
> On Wed, Apr 27, 2016 at 9:04 PM, Aleksander Morgado
> <aleksan...@aleksander.es> wrote:
>> On Wed, Apr 27, 2016 at 4:36 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>>> This patch adds support for Dell VID in Telit plugin in order to provide
>>> Dell branded Telit modems support
>>> ---
>>
>> No, we don't want to do that.
>>
>> We now have a "Dell" plugin for 1.6.x in git master; this plugin has
>> the VID based filter, and what it does is detect which kind of modem
>> it is (QMI, MBIM, Ericsson, Novatel or Sierra). What we should do is
>> to treat the Telit support in the Dell plugin as we do for Sierra and
>> Novatel. Please check the Dell plugin to see how that goes (basically
>> just parsing GMI/CGMI output to match the real vendor) :)
>
> One of the rationales for this is to try to minimize the amount of
> changes required in the different plugins when new Dell-branded
> devices appear (we don't want to require new commits for each new
> modem VID/PID appearing in the wild). The Dell plugin should be
> intelligent enough to decide which manufacturer is really behind the
> device. In your case, you could just get the Dell plugin run the Telit
> plugin's custom init and create a MMBroadbandModemTelit afterwards.
> Maybe there's something that I'm not considering which prevents this
> from being possible?

I agree with you and I already have a patch that adds support for this
modem in Dell plugin: it just needs a bit of refactoring for Telit
plugin to export some functions, but I don't think this is a problem.

The real problem is that Dell plugin has poor probing performance with
a modem like HE910 that has 6 ttyACM ports, only two of which answers
to AT commands: there are three different commands (+GMI, +CGMI,
I1I2I3) that should be retried three times, since the ports are not
answering.

This means that the modem with Dell plugin is available after more
than 60 seconds, while with Telit one after about 10 seconds.

Is there a way to speed up port probing in Dell plugin without
changing it too much? I don't want to introduce regressions for other
Dell modems.

Thanks,
Daniele

>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH 2/3] telit: add support for Dell VID in Telit plugin

[Daniele Palmas]

Hi Aleksander,

2016-04-27 21:41 GMT+02:00 Daniele Palmas <dnl...@gmail.com>:
> Hi Aleksander,
>
> 2016-04-27 21:20 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
>> On Wed, Apr 27, 2016 at 9:04 PM, Aleksander Morgado
>> <aleksan...@aleksander.es> wrote:
>>> On Wed, Apr 27, 2016 at 4:36 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>>>> This patch adds support for Dell VID in Telit plugin in order to provide
>>>> Dell branded Telit modems support
>>>> ---
>>>
>>> No, we don't want to do that.
>>>
>>> We now have a "Dell" plugin for 1.6.x in git master; this plugin has
>>> the VID based filter, and what it does is detect which kind of modem
>>> it is (QMI, MBIM, Ericsson, Novatel or Sierra). What we should do is
>>> to treat the Telit support in the Dell plugin as we do for Sierra and
>>> Novatel. Please check the Dell plugin to see how that goes (basically
>>> just parsing GMI/CGMI output to match the real vendor) :)
>>
>> One of the rationales for this is to try to minimize the amount of
>> changes required in the different plugins when new Dell-branded
>> devices appear (we don't want to require new commits for each new
>> modem VID/PID appearing in the wild). The Dell plugin should be
>> intelligent enough to decide which manufacturer is really behind the
>> device. In your case, you could just get the Dell plugin run the Telit
>> plugin's custom init and create a MMBroadbandModemTelit afterwards.
>> Maybe there's something that I'm not considering which prevents this
>> from being possible?
>
> I agree with you and I already have a patch that adds support for this
> modem in Dell plugin: it just needs a bit of refactoring for Telit
> plugin to export some functions, but I don't think this is a problem.
>
> The real problem is that Dell plugin has poor probing performance with
> a modem like HE910 that has 6 ttyACM ports, only two of which answers
> to AT commands: there are three different commands (+GMI, +CGMI,
> I1I2I3) that should be retried three times, since the ports are not
> answering.
>
> This means that the modem with Dell plugin is available after more
> than 60 seconds, while with Telit one after about 10 seconds.
>
> Is there a way to speed up port probing in Dell plugin without
> changing it too much? I don't want to introduce regressions for other
> Dell modems.
>
> Thanks,
> Daniele
>

Taking a deeper look at Dell plugin, my idea is to use the same udev
tag needed for Telit dynamic port configuration
(ID_MM_TELIT_PORTS_TAGGED) to set cgmi_retries and ati_retries to 0,
since Telit modems always answer to +GMI.

In this way port probing time should be reduced and the other modems
not affected by the change.

I will submit another patchset for adding support in Dell plugin.

Thanks,
Daniele


>>
>> --
>> Aleksander
>> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 0/3] Add support for Dell branded device in Telit plugin

[Daniele Palmas]

This patch series adds support for Dell DW5580 (413c/81ba)
in Telit plugin.

DW5580 is a Dell branded Telit modem that should be better
driven by Telit plugin instead than Dell one.

Modem probing log and init at:

http://pastebin.com/J1d7yAZa

danielepa@L2094:~/$ mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id 
'6cbde1fd5528b8c42cd2e18ffb690bfd894f13e3')
  -
  Hardware |   manufacturer: 'Telit'
   |  model: 'HE910-D'
   |   revision: '12.00.086'
   |  supported: 'gsm-umts'
   |current: 'gsm-umts'
   |   equipment id: '359658044004697'
  -
  System   | device: '/sys/devices/pci:00/:00:14.0/usb3/3-8'
   |drivers: 'cdc_acm, cdc_ether'
   | plugin: 'Telit'
   |   primary port: 'ttyACM0'
   |  ports: 'ttyACM3 (at), ttyACM4 (unknown), ttyACM5 
(unknown), ttyACM0 (at), ttyACM1 (unknown), ttyACM2 (unknown)'
  -
  Numbers  |   own : 'unknown'
  -
  Status   |   lock: 'none'
   | unlock retries: 'sim-pin (3), sim-puk (10)'
   |  state: 'disabled'
   |power state: 'on'
   |access tech: 'unknown'
   | signal quality: '0' (cached)
  -
  Modes|  supported: 'allowed: 2g; preferred: none
   |  allowed: 3g; preferred: none
   |  allowed: 2g, 3g; preferred: none'
   |current: 'allowed: 2g, 3g; preferred: none'
  -
  Bands|  supported: 'egsm, dcs, pcs, g850, u2100, u1900, u850, u900, 
u17iv'
   |current: 'egsm, dcs, u900'
  -
  IP   |  supported: 'ipv4, ipv6, ipv4v6'
  -
  3GPP |   imei: '359658044004697'
   |  enabled locks: 'none'
   |operator id: 'unknown'
   |  operator name: 'unknown'
   |   subscription: 'unknown'
   |   registration: 'unknown'
  -
  SIM  |   path: '/org/freedesktop/ModemManager1/SIM/0'

  -
  Bearers  |  paths: 'none'

Daniele Palmas (3):
  dell: forbid 413c/81ba modem in order to use Telit plugin
  telit: add support for Dell VID in Telit plugin
  telit: add udev rule for supporting device 413c/81ba

 plugins/dell/mm-plugin-dell.c  | 3 +++
 plugins/telit/77-mm-telit-port-types.rules | 4 
 plugins/telit/mm-plugin-telit.c| 2 +-
 3 files changed, 8 insertions(+), 1 deletion(-)

-- 
2.8.1

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 3/3] telit: add udev rule for supporting device 413c/81ba

[Daniele Palmas]

This patch adds the udev rule for using device 413c/81ba with Telit
plugin (dynamic port configuration)
---
 plugins/telit/77-mm-telit-port-types.rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/plugins/telit/77-mm-telit-port-types.rules 
b/plugins/telit/77-mm-telit-port-types.rules
index 3ff6cce..a42d2a9 100644
--- a/plugins/telit/77-mm-telit-port-types.rules
+++ b/plugins/telit/77-mm-telit-port-types.rules
@@ -4,6 +4,7 @@ ACTION!="add|change|move", GOTO="mm_telit_port_types_end"
 SUBSYSTEM!="tty", GOTO="mm_telit_port_types_end"
 
 SUBSYSTEMS=="usb", ATTRS{idVendor}=="1bc7", GOTO="mm_telit_vendorcheck"
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="413c", GOTO="mm_telit_vendorcheck"
 GOTO="mm_telit_port_types_end"
 
 LABEL="mm_telit_vendorcheck"
@@ -47,6 +48,9 @@ ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0021", 
ENV{ID_MM_TELIT_TAGGED}="1",
 # LE910 V2
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0036", 
ENV{ID_MM_TELIT_TAGGED}="1", ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
 
+# DW5580 (Dell branded Telit modem)
+ATTRS{idVendor}=="413c", ATTRS{idProduct}=="81ba", 
ENV{ID_MM_TELIT_TAGGED}="1", ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
+
 # NOTE: Qualcomm Gobi-based devices like the LE920 should not be handled
 # by this plugin, but by the Gobi plugin.
 
-- 
2.8.1

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 1/3] dell: forbid 413c/81ba modem in order to use Telit plugin

[Daniele Palmas]

413c/81ba is a Dell branded Telit modem that is better driven by Telit
plugin. This patch avoids the modem to be taken by Dell plugin.
---
 plugins/dell/mm-plugin-dell.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/plugins/dell/mm-plugin-dell.c b/plugins/dell/mm-plugin-dell.c
index ced1f3b..2e774d0 100644
--- a/plugins/dell/mm-plugin-dell.c
+++ b/plugins/dell/mm-plugin-dell.c
@@ -416,6 +416,8 @@ mm_plugin_create (void)
 {
 static const gchar *subsystems[] = { "tty", "net", "usb", NULL };
 static const guint16 vendors[] = { 0x413c, 0 };
+static const mm_uint16_pair forbidden_products[] = { { 0x413c, 0x81ba },
+ { 0, 0 } };
 static const MMAsyncMethod custom_init = {
 .async  = G_CALLBACK (dell_custom_init),
 .finish = G_CALLBACK (dell_custom_init_finish),
@@ -426,6 +428,7 @@ mm_plugin_create (void)
   MM_PLUGIN_NAME,  "Dell",
   MM_PLUGIN_ALLOWED_SUBSYSTEMS,subsystems,
   MM_PLUGIN_ALLOWED_VENDOR_IDS,vendors,
+  MM_PLUGIN_FORBIDDEN_PRODUCT_IDS, forbidden_products,
   MM_PLUGIN_ALLOWED_AT,TRUE,
   MM_PLUGIN_CUSTOM_INIT,   _init,
   MM_PLUGIN_ALLOWED_QCDM,  TRUE,
-- 
2.8.1

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 1/2] telit: add udev rules for supporting GE910

[Daniele Palmas]

This patch adds the udev rules for supporting GE910 (PID 0x22)
---
 plugins/telit/77-mm-telit-port-types.rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/plugins/telit/77-mm-telit-port-types.rules 
b/plugins/telit/77-mm-telit-port-types.rules
index c0119c6..36a4f99 100644
--- a/plugins/telit/77-mm-telit-port-types.rules
+++ b/plugins/telit/77-mm-telit-port-types.rules
@@ -43,6 +43,10 @@ ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1011", 
ENV{ID_MM_TELIT_TAGGED}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0021", ENV{ID_MM_TELIT_TAGGED}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0021", 
ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
 
+# GE910 (dynamic port identification supported)
+ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0022", ENV{ID_MM_TELIT_TAGGED}="1"
+ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0022", 
ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
+
 # LE910 V2
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0036", ENV{ID_MM_TELIT_TAGGED}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0036", 
ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
-- 
2.7.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 2/2] telit: add GE910 #PORTCFG layouts

[Daniele Palmas]

GE910 family supports #PORTCFG layouts different than HE910
family ones.

This patch properly tags GE910 ports according to Telit document
"GE910 Family Ports Arrangements, 1vv0301049"
---
 plugins/telit/mm-common-telit.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/plugins/telit/mm-common-telit.c b/plugins/telit/mm-common-telit.c
index 14bf599..78530c4 100644
--- a/plugins/telit/mm-common-telit.c
+++ b/plugins/telit/mm-common-telit.c
@@ -26,6 +26,8 @@
 #define TAG_TELIT_AUX_PORT "ID_MM_TELIT_PORT_TYPE_AUX"
 #define TAG_TELIT_NMEA_PORT"ID_MM_TELIT_PORT_TYPE_NMEA"
 
+#define TELIT_GE910_FAMILY_PID 0x0022
+
 gboolean
 telit_grab_port (MMPlugin *self,
  MMBaseModem *modem,
@@ -143,6 +145,7 @@ cache_port_mode (MMDevice *device,
 
 /* Reference for port configurations:
  * HE910/UE910/UL865 Families Ports Arrangements User Guide
+ * GE910 Family Ports Arrangements User Guide
  */
 switch (portcfg_current) {
 case 0:
@@ -154,7 +157,11 @@ cache_port_mode (MMDevice *device,
 case 10:
 case 11:
 g_object_set_data (G_OBJECT (device), TAG_TELIT_MODEM_PORT, "00");
-g_object_set_data (G_OBJECT (device), TAG_TELIT_AUX_PORT, "06");
+
+if (mm_device_get_product (device) == TELIT_GE910_FAMILY_PID)
+g_object_set_data (G_OBJECT (device), TAG_TELIT_AUX_PORT, "02");
+else
+g_object_set_data (G_OBJECT (device), TAG_TELIT_AUX_PORT, "06");
 break;
 case 2:
 case 3:
@@ -164,8 +171,14 @@ cache_port_mode (MMDevice *device,
 case 8:
 case 12:
 g_object_set_data (G_OBJECT (device), TAG_TELIT_MODEM_PORT, "00");
-g_object_set_data (G_OBJECT (device), TAG_TELIT_AUX_PORT, "06");
-g_object_set_data (G_OBJECT (device), TAG_TELIT_NMEA_PORT, "0a");
+
+if (mm_device_get_product (device) == TELIT_GE910_FAMILY_PID) {
+g_object_set_data (G_OBJECT (device), TAG_TELIT_AUX_PORT, "02");
+g_object_set_data (G_OBJECT (device), TAG_TELIT_NMEA_PORT, "04");
+} else {
+g_object_set_data (G_OBJECT (device), TAG_TELIT_AUX_PORT, "06");
+g_object_set_data (G_OBJECT (device), TAG_TELIT_NMEA_PORT, "0a");
+}
 break;
 default:
 /* portcfg value not supported */
-- 
2.7.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 0/2] telit: add GE910 support

[Daniele Palmas]

This patch series adds support for Telit GE910.

Full startup log at http://pastebin.com/Bpx4XEFy

Daniele Palmas (2):
  telit: add udev rules for supporting GE910
  telit: add GE910 #PORTCFG layouts

 plugins/telit/77-mm-telit-port-types.rules |  4 
 plugins/telit/mm-common-telit.c| 19 ---
 2 files changed, 20 insertions(+), 3 deletions(-)

-- 
2.7.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 1/1] telit: fix supported and current bands query with GE910

[Daniele Palmas]

GE910 is a 2g only modem and when queried for bands it returns
only a 2g set of bands:

--> 'AT#BND=?'
<-- '#BND: (0-3)OK'

Current regex fails, since it considers the 3g bands block mandatory.

A similar problem happens for current bands.

This patch modifies the regular expressions for properly
supporting GE910 and updates tests.
---
 plugins/telit/mm-modem-helpers-telit.c| 4 ++--
 plugins/telit/tests/test-mm-modem-helpers-telit.c | 8 
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/plugins/telit/mm-modem-helpers-telit.c 
b/plugins/telit/mm-modem-helpers-telit.c
index d71a712..665668f 100644
--- a/plugins/telit/mm-modem-helpers-telit.c
+++ b/plugins/telit/mm-modem-helpers-telit.c
@@ -162,9 +162,9 @@ mm_telit_parse_csim_response (const guint step,
 return retries;
 }
 
-#define SUPP_BAND_RESPONSE_REGEX  
"#BND:\\s*\\((?P.*)\\),\\s*\\((?P.*)\\)"
+#define SUPP_BAND_RESPONSE_REGEX  
"#BND:\\s*\\((?P[0-9\\-,]*)\\)(,\\s*\\((?P.*)\\))?"
 #define SUPP_BAND_4G_MODEM_RESPONSE_REGEX 
"#BND:\\s*\\((?P.*)\\),\\s*\\((?P.*)\\),\\s*\\((?P\\d+-\\d+)\\)"
-#define CURR_BAND_RESPONSE_REGEX  
"#BND:\\s*(?P\\d+),\\s*(?P\\d+)"
+#define CURR_BAND_RESPONSE_REGEX  
"#BND:\\s*(?P\\d+)(,\\s*(?P\\d+))?"
 #define CURR_BAND_4G_MODEM_RESPONSE_REGEX 
"#BND:\\s*(?P\\d+),\\s*(?P\\d+),\\s*(?P\\d+)"
 
 /*/
diff --git a/plugins/telit/tests/test-mm-modem-helpers-telit.c 
b/plugins/telit/tests/test-mm-modem-helpers-telit.c
index bfdde89..03b1bc7 100644
--- a/plugins/telit/tests/test-mm-modem-helpers-telit.c
+++ b/plugins/telit/tests/test-mm-modem-helpers-telit.c
@@ -160,6 +160,10 @@ typedef struct {
 } BNDResponseTest;
 
 static BNDResponseTest supported_band_mapping_tests [] = {
+{ "#BND: (0-3)", TRUE, FALSE, FALSE, 4, { MM_MODEM_BAND_EGSM,
+  MM_MODEM_BAND_DCS,
+  MM_MODEM_BAND_PCS,
+  MM_MODEM_BAND_G850} },
 { "#BND: (0-3),(0,2,5,6)", TRUE, TRUE, FALSE, 7, { MM_MODEM_BAND_EGSM,
   MM_MODEM_BAND_DCS,
   MM_MODEM_BAND_PCS,
@@ -242,6 +246,10 @@ test_parse_supported_bands_response (void) {
 
 
 static BNDResponseTest current_band_mapping_tests [] = {
+{ "#BND: 0", TRUE, FALSE, FALSE, 2, { MM_MODEM_BAND_EGSM,
+  MM_MODEM_BAND_DCS
+}
+},
 { "#BND: 0,5", TRUE, TRUE, FALSE, 3, { MM_MODEM_BAND_EGSM,
MM_MODEM_BAND_DCS,
MM_MODEM_BAND_U900
-- 
2.7.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 0/1] broadband-modem-qmi: add QMI_PROTOCOL_ERROR_NOT_SUPPORTED case for pin status checking

[Daniele Palmas]

Telit LE922A does not like the legacy way for checking pin status, but
instead of returning QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAND, it returns
QMI_PROTOCOL_ERROR_NOT_SUPPORTED, making the modem not to be fully
initialized:

http://pastebin.com/UK5uccKm

This patch adds QMI_PROTOCOL_ERROR_NOT_SUPPORTED as another error for
which the new pin checking status way is tried.

The output with the patch is:

http://pastebin.com/JVdZuVMn

Daniele Palmas (1):
  broadband-modem-qmi: add QMI_PROTOCOL_ERROR_NOT_SUPPORTED case for pin
status checking

 src/mm-broadband-modem-qmi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--
2.7.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 1/1] broadband-modem-qmi: add QMI_PROTOCOL_ERROR_NOT_SUPPORTED case for pin status checking

[Daniele Palmas]

Telit LE922A does not like the legacy way for checking pin status, but
instead of returning QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAND, it returns
QMI_PROTOCOL_ERROR_NOT_SUPPORTED, making the modem not to be fully
initialized.

This patch adds QMI_PROTOCOL_ERROR_NOT_SUPPORTED as another error for
which the new pin checking status way is tried.
---
 src/mm-broadband-modem-qmi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mm-broadband-modem-qmi.c b/src/mm-broadband-modem-qmi.c
index 1a13791..44c346a 100644
--- a/src/mm-broadband-modem-qmi.c
+++ b/src/mm-broadband-modem-qmi.c
@@ -1740,7 +1740,10 @@ dms_uim_get_pin_status_ready (QmiClientDms *client,
 /* We get InvalidQmiCommand on newer devices which don't like the 
legacy way */
 if (g_error_matches (error,
  QMI_PROTOCOL_ERROR,
- QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAND)) {
+ QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAND) ||
+g_error_matches (error,
+ QMI_PROTOCOL_ERROR,
+ QMI_PROTOCOL_ERROR_NOT_SUPPORTED)) {
 g_error_free (error);
 qmi_message_dms_uim_get_pin_status_output_unref (output);
 /* Flag that the command is unsupported, and try with the new way 
*/
-- 
2.7.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] telit: support QMI and MBIM modems

[Daniele Palmas]

2017-03-24 17:38 GMT+01:00 Aleksander Morgado <aleksan...@aleksander.es>:
> On Fri, Mar 24, 2017 at 3:33 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>> So LN930 was a "special" modem, in the sense that was never produced
>> with Telit VID.
>
> Did it actually have a custom Telit firmware, or was it the original
> one from Intel? I see that this device also didn't have Telit VID in
> AT+NCM mode.
>

It basically is Intel original one. No Telit AT# command is supported in LN930.

Daniele

>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] telit: support QMI and MBIM modems

[Daniele Palmas]

Hi Aleksander,

2017-03-24 15:33 GMT+01:00 Daniele Palmas <dnl...@gmail.com>:
> Hi Aleksander,
>
> 2017-03-24 14:48 GMT+01:00 Aleksander Morgado <aleksan...@aleksander.es>:
>> Vendor specific plugins that support QMI or MBIM based devices need to
>> handle the creation of these modems themselves.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=100372
>> ---
>>
>> Hey Carlo and Daniele,
>>
>> This patch makes the Telit plugin accept QMI and MBIM modems. Can any of you 
>> test it with such modems to make sure the Telit plugin is the one grabbing 
>> them?
>>
>
> Sure, I can give it a try on Monday.
>

Applying your patch and testing with an mbim based I still see that
the generic plugin is used

daniele@L2122:~/git/ModemManager$ mmcli -L

Found 1 modems:
/org/freedesktop/ModemManager1/Modem/0 [Generic] MBIM [1BC7:0032]

So in the log I found

ModemManager[3807]:  (Telit) [cdc-wdm0] filtered by implicit MBIM driver

and added

  MM_PLUGIN_ALLOWED_QMI,TRUE,
  MM_PLUGIN_ALLOWED_MBIM,   TRUE,

in mm_plugin_create.

I'm now seeing

ModemManager[5758]:  MBIM-powered Telit modem found...

but also

ModemManager[5758]:   Couldn't start initialization: Cannot
initialize: MBIM port went missing
ModemManager[5758]:   couldn't initialize the modem: 'Modem is
unusable, cannot fully initialize'

and the modem was not recognized.

I had also to fix telit_grab_port in order to take mbim, qmi and net
ports. Does this make sense?

Daniele

>> Cheers!
>>
>> ---
>>  plugins/telit/77-mm-telit-port-types.rules |  3 ---
>>  plugins/telit/mm-plugin-telit.c| 33 
>> +-
>>  2 files changed, 32 insertions(+), 4 deletions(-)
>>
>> diff --git a/plugins/telit/77-mm-telit-port-types.rules 
>> b/plugins/telit/77-mm-telit-port-types.rules
>> index 36a4f99f..1b58a3d9 100644
>> --- a/plugins/telit/77-mm-telit-port-types.rules
>> +++ b/plugins/telit/77-mm-telit-port-types.rules
>> @@ -51,7 +51,4 @@ ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0022", 
>> ENV{ID_MM_TELIT_PORTS_TAGGED}
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0036", 
>> ENV{ID_MM_TELIT_TAGGED}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0036", 
>> ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
>>
>> -# NOTE: Qualcomm Gobi-based devices like the LE920 should not be handled
>> -# by this plugin, but by the Gobi plugin.
>> -
>>  LABEL="mm_telit_port_types_end"
>> diff --git a/plugins/telit/mm-plugin-telit.c 
>> b/plugins/telit/mm-plugin-telit.c
>> index ec3c024f..abb87e4f 100644
>> --- a/plugins/telit/mm-plugin-telit.c
>> +++ b/plugins/telit/mm-plugin-telit.c
>> @@ -28,6 +28,15 @@
>>  #include "mm-common-telit.h"
>>  #include "mm-broadband-modem-telit.h"
>>
>> +
>> +#if defined WITH_QMI
>> +# include "mm-broadband-modem-qmi.h"
>> +#endif
>> +
>> +#if defined WITH_MBIM
>> +# include "mm-broadband-modem-mbim.h"
>> +#endif
>> +
>>  G_DEFINE_TYPE (MMPluginTelit, mm_plugin_telit, MM_TYPE_PLUGIN)
>>
>>  MM_PLUGIN_DEFINE_MAJOR_VERSION
>> @@ -44,6 +53,28 @@ create_modem (MMPlugin *self,
>>GList *probes,
>>GError **error)
>>  {
>> +#if defined WITH_QMI
>> +if (mm_port_probe_list_has_qmi_port (probes)) {
>> +mm_dbg ("QMI-powered Telit modem found...");
>> +return MM_BASE_MODEM (mm_broadband_modem_qmi_new (uid,
>> +  drivers,
>> +  
>> mm_plugin_get_name (self),
>> +  vendor,
>> +  product));
>> +}
>> +#endif
>> +
>> +#if defined WITH_MBIM
>> +if (mm_port_probe_list_has_mbim_port (probes)) {
>> +mm_dbg ("MBIM-powered Telit modem found...");
>> +return MM_BASE_MODEM (mm_broadband_modem_mbim_new (uid,
>> +   drivers,
>> +   
>> mm_plugin_get_name (self),
>> +   vendor,
>> +   product));
>> +}
>> +#endif
>> +
>>  return MM_BASE_MODEM (mm_broadband_modem_telit_new (uid,
>>  

Re: [PATCH] telit: support QMI and MBIM modems

[Daniele Palmas]

Hi Aleksander,

2017-03-24 14:48 GMT+01:00 Aleksander Morgado :
> Vendor specific plugins that support QMI or MBIM based devices need to
> handle the creation of these modems themselves.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=100372
> ---
>
> Hey Carlo and Daniele,
>
> This patch makes the Telit plugin accept QMI and MBIM modems. Can any of you 
> test it with such modems to make sure the Telit plugin is the one grabbing 
> them?
>

Sure, I can give it a try on Monday.

> I have a LN930 that I can switch to MBIM mode, but it exposes Intel's VID, 
> not the Telit VID. Do you know if this would be something happening to all 
> MBIM-capable Telit modems?
>

So LN930 was a "special" modem, in the sense that was never produced
with Telit VID.

All the others available MBIM based modems expose Telit VID, such as
LE910 V2 (PID 0x0032), LE922A6 (PID 0x1041), LE920A4 (PID 0x1204)

MBIM composition is not usually the default, but it can be changed
with the #USBCFG command.

Thanks,
Daniele

> Cheers!
>
> ---
>  plugins/telit/77-mm-telit-port-types.rules |  3 ---
>  plugins/telit/mm-plugin-telit.c| 33 
> +-
>  2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/plugins/telit/77-mm-telit-port-types.rules 
> b/plugins/telit/77-mm-telit-port-types.rules
> index 36a4f99f..1b58a3d9 100644
> --- a/plugins/telit/77-mm-telit-port-types.rules
> +++ b/plugins/telit/77-mm-telit-port-types.rules
> @@ -51,7 +51,4 @@ ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0022", 
> ENV{ID_MM_TELIT_PORTS_TAGGED}
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0036", 
> ENV{ID_MM_TELIT_TAGGED}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0036", 
> ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
>
> -# NOTE: Qualcomm Gobi-based devices like the LE920 should not be handled
> -# by this plugin, but by the Gobi plugin.
> -
>  LABEL="mm_telit_port_types_end"
> diff --git a/plugins/telit/mm-plugin-telit.c b/plugins/telit/mm-plugin-telit.c
> index ec3c024f..abb87e4f 100644
> --- a/plugins/telit/mm-plugin-telit.c
> +++ b/plugins/telit/mm-plugin-telit.c
> @@ -28,6 +28,15 @@
>  #include "mm-common-telit.h"
>  #include "mm-broadband-modem-telit.h"
>
> +
> +#if defined WITH_QMI
> +# include "mm-broadband-modem-qmi.h"
> +#endif
> +
> +#if defined WITH_MBIM
> +# include "mm-broadband-modem-mbim.h"
> +#endif
> +
>  G_DEFINE_TYPE (MMPluginTelit, mm_plugin_telit, MM_TYPE_PLUGIN)
>
>  MM_PLUGIN_DEFINE_MAJOR_VERSION
> @@ -44,6 +53,28 @@ create_modem (MMPlugin *self,
>GList *probes,
>GError **error)
>  {
> +#if defined WITH_QMI
> +if (mm_port_probe_list_has_qmi_port (probes)) {
> +mm_dbg ("QMI-powered Telit modem found...");
> +return MM_BASE_MODEM (mm_broadband_modem_qmi_new (uid,
> +  drivers,
> +  mm_plugin_get_name 
> (self),
> +  vendor,
> +  product));
> +}
> +#endif
> +
> +#if defined WITH_MBIM
> +if (mm_port_probe_list_has_mbim_port (probes)) {
> +mm_dbg ("MBIM-powered Telit modem found...");
> +return MM_BASE_MODEM (mm_broadband_modem_mbim_new (uid,
> +   drivers,
> +   
> mm_plugin_get_name (self),
> +   vendor,
> +   product));
> +}
> +#endif
> +
>  return MM_BASE_MODEM (mm_broadband_modem_telit_new (uid,
>  drivers,
>  mm_plugin_get_name 
> (self),
> @@ -56,7 +87,7 @@ create_modem (MMPlugin *self,
>  G_MODULE_EXPORT MMPlugin *
>  mm_plugin_create (void)
>  {
> -static const gchar *subsystems[] = { "tty", NULL };
> +static const gchar *subsystems[] = { "tty", "net", "usb", NULL };
>  /* Vendors: Telit */
>  static const guint16 vendor_ids[] = { 0x1bc7, 0 };
>  static const gchar *vendor_strings[] = { "telit", NULL };
> --
> 2.12.0
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] telit: support RS232 modems

[Daniele Palmas]

Hi Aleksander (resending with all included),

2017-03-13 20:05 GMT+01:00 Aleksander Morgado <aleksan...@aleksander.es>:
> On Mon, Mar 13, 2017 at 6:29 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>>> With this patch on, a Telit RS232 modem still needs the udev tag in
>>> the appropriate port to get it grabbed by the Telit plugin. Without
>>> this patch, the telit plugin would not grab this patch even if the
>>> udev tag is set because the vid/pid filter would filter it out.
>>>
>>
>> It seems good to me, since, as far as I understand it looks like the
>> only way for using use a Telit RS232-based modem: if needed I can do a
>> quick test with one of those modems.
>
> I've tested this already with a Telit LE866, but I wouldn't mind
> additional tests. Remember: you need the ID_MM_TELIT_TAGGED udev tag,
> and if you're using a RS232<->USB adapter, you can request probing of
> the device manually with "mmcli -S".
>

Hi Aleksander,

2017-03-13 20:05 GMT+01:00 Aleksander Morgado <aleksan...@aleksander.es>:
> On Mon, Mar 13, 2017 at 6:29 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>>> With this patch on, a Telit RS232 modem still needs the udev tag in
>>> the appropriate port to get it grabbed by the Telit plugin. Without
>>> this patch, the telit plugin would not grab this patch even if the
>>> udev tag is set because the vid/pid filter would filter it out.
>>>
>>
>> It seems good to me, since, as far as I understand it looks like the
>> only way for using use a Telit RS232-based modem: if needed I can do a
>> quick test with one of those modems.
>
> I've tested this already with a Telit LE866, but I wouldn't mind
> additional tests. Remember: you need the ID_MM_TELIT_TAGGED udev tag,
> and if you're using a RS232<->USB adapter, you can request probing of
> the device manually with "mmcli -S".
>

Tested with GL865 and working fine

daniele@L2122:~$ mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id
'e31ff4d485c411511410e55f1f682373f9f68e2f')
 -
 Hardware |   manufacturer: 'Telit'
  |  model: 'GL865-QUAD'
  |   revision: '10.01.143'
  |  supported: 'gsm-umts'
  |current: 'gsm-umts'
  |   equipment id: '356308040051861'
 -
 System   | device: '/sys/devices/pnp0/00:05'
  |drivers: 'serial'
  | plugin: 'Telit'
  |   primary port: 'ttyS0'
  |  ports: 'ttyS0 (at)'
 -
 Numbers  |   own : '9876543210'
 -
 Status   |   lock: 'none'
  | unlock retries: 'unknown'
  |  state: 'connected'
  |power state: 'on'
  |access tech: 'unknown'
  | signal quality: '61' (recent)
 -
 Modes|  supported: 'allowed: 2g; preferred: none'
  |current: 'allowed: 2g; preferred: none'
 -
 Bands|  supported: 'egsm, dcs, pcs, g850'
  |current: 'egsm, dcs'
 -
 IP   |  supported: 'ipv4, ipv6'
 -
 3GPP |   imei: '356308040051861'
  |  enabled locks: 'none'
  |operator id: '22201'
  |  operator name: 'I TIM'
  |   subscription: 'unknown'
  |   registration: 'home'
 -
 SIM  |   path: '/org/freedesktop/ModemManager1/SIM/0'

 -
 Bearers  |  paths: '/org/freedesktop/ModemManager1/Bearer/0'

> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] telit: fix AT+SERVICE 3GPP2 access technology reporting

[Daniele Palmas]

Hi Dan,

2017-04-03 21:52 GMT+02:00 Dan Williams :
> Looks like a C error from the AT#PSNT codepath; all the docs
> I can find indicate that AT+SERVICE returns only an integer and
> no commas:

Confirmed, when this command is supported as far as I know there is
only one integer.

Regards,
Daniele

>
>  (ttyUSB2): --> 'AT+SERVICE?'
>  (ttyUSB2): <-- '+SERVICE: 3OK'
>  Couldn't refresh access technologies: 'Failed to parse +SERVICE 
> response: '+SERVICE: 3''
> ---
>  plugins/telit/mm-broadband-modem-telit.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/plugins/telit/mm-broadband-modem-telit.c 
> b/plugins/telit/mm-broadband-modem-telit.c
> index 6ef340f..7d453c8 100644
> --- a/plugins/telit/mm-broadband-modem-telit.c
> +++ b/plugins/telit/mm-broadband-modem-telit.c
> @@ -828,7 +828,7 @@ response_processor_service_ignore_at_errors (MMBaseModem 
> *self,
>   GVariant **result,
>   GError **result_error)
>  {
> -const gchar *service, *mode;
> +const gchar *service;
>
>  if (error) {
>  /* Ignore AT errors (ie, ERROR or CMx ERROR) */
> @@ -838,9 +838,8 @@ response_processor_service_ignore_at_errors (MMBaseModem 
> *self,
>  }
>
>  service = mm_strip_tag (response, "+SERVICE:");
> -mode = strchr (service, ',');
> -if (mode) {
> -switch (atoi (++mode)) {
> +if (service) {
> +switch (atoi (service)) {
>  case 1:
>  *result = g_variant_new_uint32 
> (MM_MODEM_ACCESS_TECHNOLOGY_1XRTT);
>  return TRUE;
> --
> 2.9.3
> ___
> 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

Re: [PATCH] telit: don't ignore AT ports without an explicit port type hint tag

[Daniele Palmas]

Hi Aleksander,

2017-03-11 13:29 GMT+01:00 Aleksander Morgado :
> The telit plugin is based on two main ways of checking the purpose of
> each port: udev tags flagging specific interfaces (with info taken
> from Windows .inf drivers), or otherwise using AT#PORTCFG? to query
> the modem about that information. If none of those applies, the port
> is ignored by default.
>
> In order to support devices that are not explicitly tagged, the plugin
> shouldn't flag as ignored the AT-capable TTYs, instead they are now
> grabbed as 'secondary': ports grabbed as secondary will never be used
> for either primary/data IF there is another port flagged explicitly
> for primary/data.
>
> This fixes the support for modems with a single TTY and no explicit
> port type hint tag, e.g. RS232 modems with just one single TTY where
> there's no point in specifying port type hints: the port will be
> grabbed as secondary, and then automatically promoted to primary/data
> as there is no other port grabbed.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=100159
> ---
>
> Hey Dan, Daniele, Carlo and everyone,
>
> This patch makes it possible for the Telit plugin to support Telit modems 
> that only expose a single TTY, without needing to manually add any port type 
> hint.
>
> What do you think?

Makes sense to me, thanks.

Daniele

>
> ---
>  plugins/telit/mm-common-telit.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/plugins/telit/mm-common-telit.c b/plugins/telit/mm-common-telit.c
> index 78530c42..3f2cce5c 100644
> --- a/plugins/telit/mm-common-telit.c
> +++ b/plugins/telit/mm-common-telit.c
> @@ -84,11 +84,22 @@ telit_grab_port (MMPlugin *self,
>  } else
>  ptype = MM_PORT_TYPE_IGNORED;
>  } else {
> -/* If the port was tagged by the udev rules but isn't a primary or 
> secondary,
> - * then ignore it to guard against race conditions if a device just 
> happens
> - * to show up with more than two AT-capable ports.
> +/* If the port isn't explicitly tagged as primary, secondary, or gps
> + * port, we will fallback to flagging it as secondary, but only if it
> + * probed AT successfully.
> + *
> + * This is so that we support the case where a single TTY is exposed
> + * by the modem and no explicit port type hint is specified.
> + *
> + * From the modem point of view, only the AT_FLAG_PRIMARY would be
> + * important, as that is the port that would end up getting used for 
> PPP
> + * in this case, so having multiple secondary ports, if that ever
> + * happened, wouldn't be an issue.
>   */
> -ptype = MM_PORT_TYPE_IGNORED;
> +if (mm_port_probe_is_at (probe))
> +pflags = MM_PORT_SERIAL_AT_FLAG_SECONDARY;
> +else
> +ptype = MM_PORT_TYPE_IGNORED;
>  }
>
>  return mm_base_modem_grab_port (modem,
> --
> 2.12.0
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Telit HE910 not connecting with Modem Manager 1.6.4

[Daniele Palmas]

Hi Salvador,

2017-03-10 13:38 GMT+01:00 Penalva, Salvador :
> Hi Aleksander,
>
> Sorry for the delay but I was trying to debug a little more the logs to 
> isolate the problem.
>
> Answering to your question: We use SimpleConnect command inside a script but 
> we don't use network Manager.
>
> Finally, we got to the conclusion, that the problem could start when trying 
> to unlock the SIM. We tested just unlocking the SIM card with the pin in both 
> versions of ModemManager (1.4.12 and 1.6.4) and we think that the error could 
> be in this step that seem to have changed between both versions of 
> ModemManager. This part is just after sending the PIN to the SIM with CPIN in 
> MM 1.6.4:
>
> ModemManager[814]:  [1489145392.858937] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1288] mm_port_serial_open(): 
> (ttyACM0) device open count is 1 (open)
> ModemManager[814]:  [1489145392.859398] 
> [../../ModemManager-1.6.4/src/mm-port-serial-at.c:459] debug_log(): 
> (ttyACM0): --> 'AT+CSIM=10,002100'
> ModemManager[814]:   [1489145396.334171] 
> [../../ModemManager-1.6.4/plugins/telit/mm-broadband-modem-telit.c:342] 
> csim_query_ready(): No respose for step 1: Serial command timed out
> ModemManager[814]:  [1489145396.334617] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1288] mm_port_serial_open(): 
> (ttyACM0) device open count is 2 (open)
> ModemManager[814]:  [1489145396.334962] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1345] _close_internal(): 
> (ttyACM0) device open count is 1 (close)
> ModemManager[814]:  [1489145396.335307] 
> [../../ModemManager-1.6.4/src/mm-port-serial-at.c:459] debug_log(): 
> (ttyACM0): --> 'AT+CSIM=10,002C000100'
> ModemManager[814]:   [1489145399.334315] 
> [../../ModemManager-1.6.4/plugins/telit/mm-broadband-modem-telit.c:342] 
> csim_query_ready(): No respose for step 2: Serial command timed out
> ModemManager[814]:  [1489145399.334760] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1288] mm_port_serial_open(): 
> (ttyACM0) device open count is 2 (open)
> ModemManager[814]:  [1489145399.335107] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1345] _close_internal(): 
> (ttyACM0) device open count is 1 (close)
> ModemManager[814]:  [1489145399.335456] 
> [../../ModemManager-1.6.4/src/mm-port-serial-at.c:459] debug_log(): 
> (ttyACM0): --> 'AT+CSIM=10,0020008100'
> ModemManager[814]:   [1489145402.811803] 
> [../../ModemManager-1.6.4/plugins/telit/mm-broadband-modem-telit.c:342] 
> csim_query_ready(): No respose for step 3: Sending command failed: 'Resource 
> tempora'
> ModemManager[814]:  [1489145402.812322] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1288] mm_port_serial_open(): 
> (ttyACM0) device open count is 2 (open)
> ModemManager[814]:  [1489145402.812684] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1345] _close_internal(): 
> (ttyACM0) device open count is 1 (close)
> ModemManager[814]:  [1489145402.813025] 
> [../../ModemManager-1.6.4/src/mm-port-serial-at.c:459] debug_log(): 
> (ttyACM0): --> 'AT+CSIM=10,002C008100'
> ModemManager[814]:   [1489145406.273564] 
> [../../ModemManager-1.6.4/plugins/telit/mm-broadband-modem-telit.c:342] 
> csim_query_ready(): No respose for step 4: Sending command failed: 'Resource 
> tempora'
> ModemManager[814]:   [1489145406.273995] 
> [../../ModemManager-1.6.4/src/mm-iface-modem.c:2960] 
> load_unlock_retries_ready(): Couldn't load unlock retries: 'Could not get any 
> of the SIM unlock retries'
> ModemManager[814]:  [1489145406.274272] 
> [../../ModemManager-1.6.4/src/mm-iface-modem.c:3110] 
> update_lock_info_context_step(): SIM is ready, and no need for the after SIM 
> unlock step...
> ModemManager[814]:  [1489145406.274795] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1345] _close_internal(): 
> (ttyACM0) device open count is 0 (close)
> ModemManager[814]:  [1489145406.275051] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1361] _close_internal(): 
> (ttyACM0) closing serial port...
> ModemManager[814]:  [1489145411.274803] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1409] _close_internal(): 
> (ttyACM0) serial port closed
> ModemManager[814]:   [1489145411.277327] 
> [../../ModemManager-1.6.4/src/mm-iface-modem.c:1431] 
> __iface_modem_update_state_internal(): Modem 
> /org/freedesktop/ModemManager1/Modem/0: state changed (loc)
> ModemManager[814]:  [1489145411.282002] 
> [../../ModemManager-1.6.4/src/mm-port-serial.c:1158] mm_port_serial_open(): 
> (ttyACM0) opening serial port...
>

It seems to me that the modem got stuck and is not answering to AT
command. I see you are using firmware version 12.00.026: maybe it is
worth to contact Telit technical support for receiving latest firmware
to see if that makes a difference.

Regards,
Daniele

> Looking over the documentation of HE910 
> (http://www.telit.com/fileadmin/user_upload/products/Downloads/3G/Telit_3G_Modules_AT_Commands_Reference_Guide_r10.pdf
>  , page 115) which explains the CSIM command, it 

Re: Custom AT command support in ModemManager

[Daniele Palmas]

Hi Shijo and Aleksander,

2017-08-17 12:14 GMT+02:00 Aleksander Morgado :
> On Thu, Aug 17, 2017 at 2:45 AM, Jose, Shijo  wrote:
 I just realized you're working with a MBIM modem. So the "No AT port
 available to run command" may actually mean there is no AT port
 detected in the modem. Are you able to see a TTY listed in the
 "System/ports" entry when you do "mmcli -m 0"?
>>
>> No, I do not see TTY listed. Snippet of "mmcli -m 0" below -
>>
>>   Hardware |   manufacturer: 'Generic'
>>|  model: 'MBIM [1BC7:1204]'
>>|revision: '17.01.571'
>>|   supported: 'gsm-umts, lte'
>>| current: 'gsm-umts, lte'
>>| equipment id: '35323806113733'
>>   -
>>   System   | device: 
>> '/sys/devices/platform/soc/soc:internal-regs/d005e000.usb/usb1/1-1'
>>|  drivers: 'cdc_mbim'
>>|plugin: 'Generic'
>>|   primary port: 'cdc-wdm0'
>>|  ports: 'cdc-wdm0 (mbim), wwan0 (net)'
>>
>
> So the modem doesn't expose any AT capable TTY in this mode? Is there
> any /dev/ttyUSBX exposed that we may not be probing correctly?
>
>>
>>>Also, we'd generally discourage enabling custom AT commands in most 
>>>situations.  Instead, we'd like to learn more about your use-case and see if 
>>>we can come up with a more >generic way to do >what you want to do.  It may 
>>>well be the case that what you want to do has an analogue in the other 
>>>protocols like MBIM and QMI, and thus we could expose >that functionality 
>>>generically via D-Bus >rather than doing one-off things for specific modems.
>>
>> One of the custom (vendor) AT commands is to switch the firmware (i.e. 
>> reboot using a different firmware) on the LTE modem based on the SIM card 
>> information (operator type).  Another one (#USBCFG) is to change the USB 
>> configuration mode (such as, enable MBIM) on the modem device.
>>
>
> Is there a configuration mode that has MBIM+AT? You may want to use
> that one instead of the one you currently have, which doesn't seem to
> expose any AT capable TTY.
>

1204 composition indeed has serial ports, but the PID is missing in
option kernel driver.

Regards,
Daniele

> As for the command to reboot with a different firmware; this is
> currently a control flow that ModemManager doesn't expect, so probably
> the best thing would be to chain a ModemManager stop/start sequence
> before/after the firmware update control operation (i.e. ModemManager
> not running at all while your other programs do firmware update,
> including any AT command required to do so).
>
>> I may also need some standard AT commands such as +CRSM to query certain SIM 
>> fields such as APN stored on the SIM,  +CGQREQ/ +CGEQOS for quality of 
>> service profile and +CGDCONTRDP for PDP Context Parameters.
>>
>
> Some of those we already expose in the interfaces, and some others we
> could include in the interfaces if they're useful enough.
>
>> Just a note that the product is a Telit LTE modem hard-wired to a processor 
>> via USB2.0 HS. The requirement is to select the appropriate protocol 
>> (MBIM/QMI/PPP) which will provide a control and data path for one or more 
>> PDP contexts and also monitor all modem and connection statistics and share 
>> this information with other processes or update SNMP MIBs. I am also looking 
>> at way for ModemManager to share updates with other processes.
>>
>
> ModemManager has a DBus interface that other processes can use.
> libmm-glib is a client-side C library that allows applications to
> easily integrate with that DBus interface. mmcli for example is an
> application that uses libmm-glib to talk to ModemManager via DBus.
> ModemManager "shares" all updates with other processes via DBus, e.g.
> with DBus property updates; clients can "connect" to the "update
> signals" and get notified right away when the properties change. I'm
> sure there are multiple ways you could try to integrate the flow you
> need; e.g. with a net-snmp agent monitoring ModemManager interfaces
> and publishing your custom OIDs.
>
> --
> Aleksander
> https://aleksander.es
> ___
> 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

Re: Telit LE910 failing to find network

[Daniele Palmas]

Hi Kelvin,

2017-07-19 14:51 GMT+02:00 Kelvin :
> Hi
>
>> According to logs shared by Kelvin, the modem seems to be properly
>> replying
>
>
> Thanks, yes QMI commands seem to be working now but it fails to register on
> a network.
>
> I've tried a SIM card for a different network provider now (EE) and the scan
> response is:
>
> Jul 19 12:42:44 linaro-gnome ModemManager[802]:  Running registration
> checks (CS: 'yes', PS: 'yes', EPS: 'no')
> Jul 19 12:42:44 linaro-gnome ModemManager[802]: [/dev/cdc-wdm0] Sent
> message...#012<< RAW:#012<<   length = 13#012<<   data   =
> 01:0C:00:00:03:02:00:36:00:24:00:00:00
> Jul 19 12:42:44 linaro-gnome ModemManager[802]: [/dev/cdc-wdm0] Sent message
> (translated)...#012<< QMUX:#012<<   length  = 12#012<<   flags
> = 0x00#012<<   service = "nas"#012<<   client  = 2#012<<
> QMI:#012<<   flags   = "none"#012<<   transaction = 54#012<<
> tlv_length  = 0#012<<   message = "Get Serving System" (0x0024)
> Jul 19 12:42:44 linaro-gnome ModemManager[802]: [/dev/cdc-wdm0] Received
> message...#012>> RAW:#012>>   length = 76#012>>   data   =
> 01:4B:00:80:03:02:02:36:00:24:00:3F:00:02:04:00:00:00:00:00:28:01:00:00:27:05:00:EA:00:1E:00:00:26:02:00:89:01:21:05:00:01:01:00:01:00:15:03:00:01:05:01:12:05:00:EA:00:1E:00:00:11:01:00:00:10:01:00:01:01:06:00:02:02:02:02:01:05
> Jul 19 12:42:44 linaro-gnome ModemManager[802]: [/dev/cdc-wdm0] Received
> message (translated)...#012>> QMUX:#012>>   length  = 75#012>>
> flags   = 0x80#012>>   service = "nas"#012>>   client  = 2#012>>
> QMI:#012>>   flags   = "response"#012>>   transaction =
> 54#012>>   tlv_length  = 63#012>>   message = "Get Serving
> System" (0x0024)#012>> TLV:#012>>   type   = "Result"
> (0x02)#012>>   length = 4#012>>   value  =
> 00:00:00:00#012>>   translated = SUCCESS#012>> TLV:#012>>   type
> = 0x28#012>>   length = 1#012>>   value  = 00#012>>
> TLV:#012>>   type   = "MNC PCS Digit Include Status"
> (0x27)#012>>   length = 5#012>>   value  =
> EA:00:1E:00:00#012>>   translated = [ mcc = '234' mnc = '30'
> includes_pcs_digit = 'no' ]#012>> TLV:#012>>   type   = "UMTS
> Primary Scrambling Code" (0x26)#012>>   length = 2#012>>   value
> = 89:01#012>>   translated = 393#012>> TLV:#012>>   type   =
> "Detailed Service Status" (0x21)#012>>   length = 5#012>>
> value  = 01:01:00:01:00#012>>   translated = [ status = 'limited'
> capability = 'cs' hdr_status = 'none' hdr_hybrid = 'yes' forbidden = 'no'
> ]#012>> TLV:#012>>   type   = "Roaming Indicator List"
> (0x15)#012>>   length = 3#012>>   value  =
> 01:05:01#012>>   translated = { [0] = '[ radio_interface = 'umts'
> roaming_indicator = 'off' ] '}#012>> TLV:#012>>   type   =
> "Current PLMN" (0x12)#012>>   length = 5#012>>   value  =
> EA:00:1E:00:00#012>>   translated = [ mcc = '234' mnc = '30' description
> = '' ]#012>> TLV:#012>>   type   = "Data Service Capability"
> (0x11)#012>>   length = 1#012>>   value  = 00#012>>
> translated = {}#012>> TLV:#012>>   type   = "Roaming Indicator"
> (0x10)#012>>   length = 1#012>>   value  = 01#012>>
> translated = off#012>> TLV:#012>>   type   = "Serving System"
> (0x01)#012>>   length = 6#012>>   value  =
> 02:02:02:02:01:05#012>>   translated = [ registration_state =
> 'not-registered-searching' cs_attach_state = 'detached' ps_attach_state =
> 'detached' selected_network = '3gpp' radio_interfaces = '{ [0] = 'umts '}' ]
> Jul 19 12:42:44 linaro-gnome ModemManager[802]:  Processing 3GPP
> info...
> Jul 19 12:42:44 linaro-gnome ModemManager[802]:  Modem not yet
> registered in a 3GPP network... will recheck soon
>
>
> The --3gpp-scan is a bit different with this SIM card / network, it shows
> 'current' for the correct network (EE) and forbidden for the others:
>
> linaro@linaro-gnome:~$ sudo mmcli -m 0 --3gpp-scan --timeout=300
>
> Found 7 networks:
> 23410 - O2 - UK (lte, forbidden)
> 23415 - voda UK (lte, forbidden)
> 23420 - 3 UK (umts, forbidden)
> 23410 - O2 - UK (umts, forbidden)
> 23415 - voda UK (gsm, forbidden)
> 23415 - voda UK (umts, forbidden)
> 23430 - EE (umts, current)
>
>
> The SIM card / network I was using earlier looked like this while scanning:
>
> Jul 19 10:07:48 linaro-gnome ModemManager[3663]:  [1500458868.901761]
> [mm-iface-modem-3gpp.c:761] mm_iface_modem_3gpp_run_registration_checks():
> Running registration checks (CS: 'yes', PS: 'yes', EPS: 'no')
> Jul 19 10:07:48 linaro-gnome ModemManager[3663]: [/dev/cdc-wdm0] Sent
> message...#012<< RAW:#012<<   length = 13#012<<   data   =
> 01:0C:00:00:03:02:00:2F:00:24:00:00:00
> Jul 19 10:07:48 linaro-gnome 

Re: Telit LE910 failing to find network

[Daniele Palmas]

Hi Kelvin,

2017-07-28 10:10 GMT+02:00 Kelvin :
> Hi,
>
>>
>> > And --3gpp-scan on that card showed 'available' for all networks.
>> >
>> > Thanks for any hints,
>>
>> Sorry, I'm not a qmi protocol expert so maybe I'm missing something,
>> but those seem not to be useful to me for understanding the issue.
>>
>> Could you please send AT#MONI in one of the available serial ports and
>> report the output?
>
>
> AT#MONI returns:
> #MONI: EE PSC:393 RSCP:-117 LAC:0489 Id:0D629F4 EcIo:-9.0 UARFCN:10786
> PWR:-108dbm DRX:64 SCR:6288 URA:4294967295
>

PWR: -108 dbm

That can be the issue: signal level is too much low. Maybe some antenna problem?

Regards,
Daniele

>>
>> Has this modem ever worked properly with a different setup (e.g. SIM,
>> OS...) ?
>
>
> It has been a bit intermittent but at the moment is not registering at all
> (with two SIMs from two different providers).
>
>>
>> The only real hint I can provide is to contact Telit technical
>> support: they will probably ask you to update the firmware and retry
>> and, if the problem persists, maybe collect a qxdm trace (that will
>> definitely explain why the modem is not registering).
>
>
> I've tried the latest Telit firmware I was sent (17.0.1.522) and the
> behaviour is pretty much the same. I'll send a separate mail with the logs.
>
> Thanks a lot for the replies,
> Kelvin.
>
>>
>>
>> Regards,
>> Daniele
>>
>> > Kelvin.
>
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Telit LE910 failing to find network

[Daniele Palmas]

Hi Lars,

2017-07-19 13:43 GMT+02:00 Lars Melin :
> On 2017-07-19 16:48, Kelvin wrote:
>>
>>
>> If I'm not wrong qmi_wwan is trying to bind to interface 5, but
>> rmnet
>> is on 2 (that has been wrongly taken by option). Which kernel
>> version
>> are you using? Did you modify the source code of option and
>> qmi_wwan?
>>
>>
>> This does indeed look incorrect - the qmi_wwan.c modification on
>> this kernel uses 5 but the LE910 documents say to use 2. Good catch,
>> thanks!
>
>
> 1bc7:1201 needs special handling (set DTR) in the qmi_wwan driver so the fix
> is not as simple as just changing a 5 to a 2.
> You will not get any reply on the qmi interface without that.

LE910 does not need to have dtr set: the change is needed, instead,
for LE920A4 and other more recent modems that are sharing the same
PID, but need DTR set.

According to logs shared by Kelvin, the modem seems to be properly replying.

Regards,
Daniele

>
> /Lars
>
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH 1/1] telit: port mm-common-telit to use GTask

[Daniele Palmas]

HI Aleksander,

2017-06-28 18:44 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
> Hey Daniele,
>
> See comments below.
>
> On 28/06/17 16:07, Daniele Palmas wrote:
>> ---
>>  plugins/telit/mm-common-telit.c | 64 
>> +++--
>>  1 file changed, 29 insertions(+), 35 deletions(-)
>>
>> diff --git a/plugins/telit/mm-common-telit.c 
>> b/plugins/telit/mm-common-telit.c
>> index 1e43588..cfd3292 100644
>> --- a/plugins/telit/mm-common-telit.c
>> +++ b/plugins/telit/mm-common-telit.c
>> @@ -120,10 +120,7 @@ out:
>>  /* Custom init */
>>
>>  typedef struct {
>> -MMPortProbe *probe;
>>  MMPortSerialAt *port;
>> -GCancellable *cancellable;
>> -GSimpleAsyncResult *result;
>>  gboolean getportcfg_done;
>>  guint getportcfg_retries;
>>  } TelitCustomInitContext;
>> @@ -133,10 +130,10 @@ telit_custom_init_finish (MMPortProbe *probe,
>>GAsyncResult *result,
>>GError **error)
>>  {
>> -return !g_simple_async_result_propagate_error (G_SIMPLE_ASYNC_RESULT 
>> (result), error);
>> +return g_task_propagate_boolean (G_TASK (result), error);
>>  }
>>
>> -static void telit_custom_init_step (TelitCustomInitContext *ctx);
>> +static void telit_custom_init_step (GTask *task);
>>
>>  static gboolean
>>  cache_port_mode (MMDevice *device,
>> @@ -217,10 +214,15 @@ out:
>>  static void
>>  getportcfg_ready (MMPortSerialAt *port,
>>GAsyncResult *res,
>> -  TelitCustomInitContext *ctx)
>> +  GTask *task)
>>  {
>>  const gchar *response;
>>  GError *error = NULL;
>> +MMPortProbe *probe;
>> +TelitCustomInitContext *ctx;
>> +
>> +ctx = g_task_get_task_data (task);
>> +probe = g_task_get_source_object (task);
>>
>>  response = mm_port_serial_at_command_finish (port, res, );
>>  if (error) {
>> @@ -237,7 +239,7 @@ getportcfg_ready (MMPortSerialAt *port,
>>  } else {
>>  MMDevice *device;
>>
>> -device = mm_port_probe_peek_device (ctx->probe);
>> +device = mm_port_probe_peek_device (probe);
>>
>>  /* Results are cached in the parent device object */
>>  if (g_object_get_data (G_OBJECT (device), TAG_GETPORTCFG_SUPPORTED) 
>> == NULL) {
>> @@ -249,35 +251,34 @@ getportcfg_ready (MMPortSerialAt *port,
>>  }
>>
>>  /* Port answered to #PORTCFG, so mark it as being AT already */
>> -mm_port_probe_set_result_at (ctx->probe, TRUE);
>> +mm_port_probe_set_result_at (probe, TRUE);
>>  }
>>
>>  if (error)
>>  g_error_free (error);
>>
>> -telit_custom_init_step (ctx);
>> +telit_custom_init_step (task);
>>  }
>>
>>  static void
>> -telit_custom_init_context_complete_and_free (TelitCustomInitContext *ctx)
>> +telit_custom_init_context_free (TelitCustomInitContext *ctx)
>>  {
>> -g_simple_async_result_complete_in_idle (ctx->result);
>> -
>> -if (ctx->cancellable)
>> -g_object_unref (ctx->cancellable);
>>  g_object_unref (ctx->port);
>> -g_object_unref (ctx->probe);
>> -g_object_unref (ctx->result);
>>  g_slice_free (TelitCustomInitContext, ctx);
>>  }
>>
>>  static void
>> -telit_custom_init_step (TelitCustomInitContext *ctx)
>> +telit_custom_init_step (GTask *task)
>>  {
>>  MMKernelDevice *port;
>> +MMPortProbe *probe;
>> +TelitCustomInitContext *ctx;
>> +
>> +ctx = g_task_get_task_data (task);
>> +probe = g_task_get_source_object (task);
>>
>>  /* If cancelled, end */
>> -if (g_cancellable_is_cancelled (ctx->cancellable)) {
>> +if (g_task_return_error_if_cancelled (task)) {
>>  mm_dbg ("telit: no need to keep on running custom init in (%s)",
>>  mm_port_get_device (MM_PORT (ctx->port)));
>>  goto out;
>
> This is not right. The g_task_return_error_if_cancelled() already does the 
> GTask return, so you cannot "goto out" and try to g_task_return_boolean() 
> again there. In this specific case we do want to return TRUE, so we should be 
> checking manually the cancellable ourselves (i.e. without returning the 
> GTask), with:
>   if (g_cancellable_is_cancelled (g_task_get_cancellable ())) {
>   

[PATCH 1/1] telit: port mm-broadband-modem-telit to use GTask

[Daniele Palmas]

---
 plugins/telit/mm-broadband-modem-telit.c | 285 ++-
 1 file changed, 131 insertions(+), 154 deletions(-)

diff --git a/plugins/telit/mm-broadband-modem-telit.c 
b/plugins/telit/mm-broadband-modem-telit.c
index 55deeed..2054b0c 100644
--- a/plugins/telit/mm-broadband-modem-telit.c
+++ b/plugins/telit/mm-broadband-modem-telit.c
@@ -62,14 +62,14 @@ modem_after_sim_unlock_finish (MMIfaceModem *self,
GAsyncResult *res,
GError **error)
 {
-return TRUE;
+return g_task_propagate_boolean (G_TASK (res), error);
 }
 
 static gboolean
-after_sim_unlock_ready (GSimpleAsyncResult *result)
+after_sim_unlock_ready (GTask *task)
 {
-g_simple_async_result_complete (result);
-g_object_unref (result);
+g_task_return_boolean (task, TRUE);
+g_object_unref (task);
 return G_SOURCE_REMOVE;
 }
 
@@ -78,16 +78,13 @@ modem_after_sim_unlock (MMIfaceModem *self,
 GAsyncReadyCallback callback,
 gpointer user_data)
 {
-GSimpleAsyncResult *result;
+GTask *task;
 
-result = g_simple_async_result_new (G_OBJECT (self),
-callback,
-user_data,
-modem_after_sim_unlock);
+task = g_task_new (self, NULL, callback, user_data);
 
 /* A short delay is necessary with some SIMs when
 they have just been unlocked. Using 1 second as secure margin. */
-g_timeout_add_seconds (1, (GSourceFunc) after_sim_unlock_ready, result);
+g_timeout_add_seconds (1, (GSourceFunc) after_sim_unlock_ready, task);
 }
 
 /*/
@@ -324,25 +321,24 @@ modem_set_current_bands_finish (MMIfaceModem *self,
 GAsyncResult *res,
 GError **error)
 {
-return !g_simple_async_result_propagate_error (G_SIMPLE_ASYNC_RESULT 
(res), error);
+return g_task_propagate_boolean (G_TASK (res), error);
 }
 
 static void
 modem_set_current_bands_ready (MMIfaceModem *self,
GAsyncResult *res,
-   GSimpleAsyncResult *simple)
+   GTask *task)
 {
 GError *error = NULL;
 
 mm_base_modem_at_command_finish (MM_BASE_MODEM (self), res, );
 if (error) {
-g_simple_async_result_take_error (simple, error);
+g_task_return_error (task, error);
 } else {
-g_simple_async_result_set_op_res_gboolean (simple, TRUE);
+g_task_return_boolean (task, TRUE);
 }
 
-g_simple_async_result_complete (simple);
-g_object_unref (simple);
+g_object_unref (task);
 }
 
 static void
@@ -358,7 +354,7 @@ modem_set_current_bands (MMIfaceModem *self,
 gboolean is_2g;
 gboolean is_3g;
 gboolean is_4g;
-GSimpleAsyncResult *res;
+GTask *task;
 
 mm_telit_get_band_flag (bands_array, , , );
 
@@ -418,16 +414,13 @@ modem_set_current_bands (MMIfaceModem *self,
  "Unexpectd error: could not 
compose AT#BND command");
 return;
 }
-res = g_simple_async_result_new (G_OBJECT (self),
- callback,
- user_data,
- modem_set_current_bands);
+task = g_task_new (self, NULL, callback, user_data);
 mm_base_modem_at_command (MM_BASE_MODEM (self),
   cmd,
   20,
   FALSE,
   
(GAsyncReadyCallback)modem_set_current_bands_ready,
-  res);
+  task);
 g_free (cmd);
 }
 
@@ -435,8 +428,6 @@ modem_set_current_bands (MMIfaceModem *self,
 /* Load current bands (Modem interface) */
 
 typedef struct {
-MMIfaceModem *self;
-GSimpleAsyncResult *result;
 gboolean mm_modem_is_2g;
 gboolean mm_modem_is_3g;
 gboolean mm_modem_is_4g;
@@ -444,11 +435,8 @@ typedef struct {
 } LoadBandsContext;
 
 static void
-load_bands_context_complete_and_free (LoadBandsContext *ctx)
+load_bands_context_free (LoadBandsContext *ctx)
 {
-g_simple_async_result_complete (ctx->result);
-g_object_unref (ctx->result);
-g_object_unref (ctx->self);
 g_slice_free (LoadBandsContext, ctx);
 }
 
@@ -457,26 +445,24 @@ modem_load_bands_finish (MMIfaceModem *self,
  GAsyncResult *res,
  GError **error)
 {
-if (g_simple_async_result_propagate_error (G_SIMPLE_ASYNC_RESULT (res), 
error))
-return NULL;
-
-return (GArray *) g_array_ref (g_simple_async_result_get_op_res_gpointer (
-   G_SIMPLE_ASYNC_RESULT (res)));
+return (GArray *) g_task_propagate_pointer (G_TASK (res), error);
 }
 
 static void
 

[PATCH v2 1/1] telit: port mm-common-telit to use GTask

[Daniele Palmas]

---
v2: address GTask cancellation issues highlighted by Aleksander
---
 plugins/telit/mm-common-telit.c | 65 +++--
 1 file changed, 30 insertions(+), 35 deletions(-)

diff --git a/plugins/telit/mm-common-telit.c b/plugins/telit/mm-common-telit.c
index 1e43588..fa0dc65 100644
--- a/plugins/telit/mm-common-telit.c
+++ b/plugins/telit/mm-common-telit.c
@@ -120,10 +120,7 @@ out:
 /* Custom init */
 
 typedef struct {
-MMPortProbe *probe;
 MMPortSerialAt *port;
-GCancellable *cancellable;
-GSimpleAsyncResult *result;
 gboolean getportcfg_done;
 guint getportcfg_retries;
 } TelitCustomInitContext;
@@ -133,10 +130,10 @@ telit_custom_init_finish (MMPortProbe *probe,
   GAsyncResult *result,
   GError **error)
 {
-return !g_simple_async_result_propagate_error (G_SIMPLE_ASYNC_RESULT 
(result), error);
+return g_task_propagate_boolean (G_TASK (result), error);
 }
 
-static void telit_custom_init_step (TelitCustomInitContext *ctx);
+static void telit_custom_init_step (GTask *task);
 
 static gboolean
 cache_port_mode (MMDevice *device,
@@ -217,10 +214,15 @@ out:
 static void
 getportcfg_ready (MMPortSerialAt *port,
   GAsyncResult *res,
-  TelitCustomInitContext *ctx)
+  GTask *task)
 {
 const gchar *response;
 GError *error = NULL;
+MMPortProbe *probe;
+TelitCustomInitContext *ctx;
+
+ctx = g_task_get_task_data (task);
+probe = g_task_get_source_object (task);
 
 response = mm_port_serial_at_command_finish (port, res, );
 if (error) {
@@ -237,7 +239,7 @@ getportcfg_ready (MMPortSerialAt *port,
 } else {
 MMDevice *device;
 
-device = mm_port_probe_peek_device (ctx->probe);
+device = mm_port_probe_peek_device (probe);
 
 /* Results are cached in the parent device object */
 if (g_object_get_data (G_OBJECT (device), TAG_GETPORTCFG_SUPPORTED) == 
NULL) {
@@ -249,35 +251,34 @@ getportcfg_ready (MMPortSerialAt *port,
 }
 
 /* Port answered to #PORTCFG, so mark it as being AT already */
-mm_port_probe_set_result_at (ctx->probe, TRUE);
+mm_port_probe_set_result_at (probe, TRUE);
 }
 
 if (error)
 g_error_free (error);
 
-telit_custom_init_step (ctx);
+telit_custom_init_step (task);
 }
 
 static void
-telit_custom_init_context_complete_and_free (TelitCustomInitContext *ctx)
+telit_custom_init_context_free (TelitCustomInitContext *ctx)
 {
-g_simple_async_result_complete_in_idle (ctx->result);
-
-if (ctx->cancellable)
-g_object_unref (ctx->cancellable);
 g_object_unref (ctx->port);
-g_object_unref (ctx->probe);
-g_object_unref (ctx->result);
 g_slice_free (TelitCustomInitContext, ctx);
 }
 
 static void
-telit_custom_init_step (TelitCustomInitContext *ctx)
+telit_custom_init_step (GTask *task)
 {
 MMKernelDevice *port;
+MMPortProbe *probe;
+TelitCustomInitContext *ctx;
+
+ctx = g_task_get_task_data (task);
+probe = g_task_get_source_object (task);
 
 /* If cancelled, end */
-if (g_cancellable_is_cancelled (ctx->cancellable)) {
+if (g_cancellable_is_cancelled (g_task_get_cancellable (task))) {
 mm_dbg ("telit: no need to keep on running custom init in (%s)",
 mm_port_get_device (MM_PORT (ctx->port)));
 goto out;
@@ -286,7 +287,7 @@ telit_custom_init_step (TelitCustomInitContext *ctx)
 /* Try to get a port configuration from the modem: usb interface 00
  * is always linked to an AT port
  */
-port = mm_port_probe_peek_port (ctx->probe);
+port = mm_port_probe_peek_port (probe);
 if (!ctx->getportcfg_done &&
 g_strcmp0 (mm_kernel_device_get_property (port, 
"ID_USB_INTERFACE_NUM"), "00") == 0) {
 
@@ -300,15 +301,15 @@ telit_custom_init_step (TelitCustomInitContext *ctx)
 2,
 FALSE, /* raw */
 FALSE, /* allow_cached */
-ctx->cancellable,
+g_task_get_cancellable (task),
 (GAsyncReadyCallback)getportcfg_ready,
-ctx);
+task);
 return;
 }
 
 out:
-g_simple_async_result_set_op_res_gboolean (ctx->result, TRUE);
-telit_custom_init_context_complete_and_free (ctx);
+g_task_return_boolean (task, TRUE);
+g_object_unref (task);
 }
 
 void
@@ -318,23 +319,17 @@ telit_custom_init (MMPortProbe *probe,
GAsyncReadyCallback callback,
gpointer user_data)
 {
-MMDevice *device;
-MMKernelDevice *port_device;
 TelitCustomInitContext *ctx;
-
-device = mm_port_probe_peek_device (probe);
-port_device = mm_port_probe_peek_port (probe);
+GTask *task;
 
 ctx = g_slice_new (TelitCustomInitContext);
-ctx->result = g_simple_async_result_new (G_OBJECT (probe),
- callback,
-  

[PATCH 1/1] telit: port mm-common-telit to use GTask

[Daniele Palmas]

---
 plugins/telit/mm-common-telit.c | 64 +++--
 1 file changed, 29 insertions(+), 35 deletions(-)

diff --git a/plugins/telit/mm-common-telit.c b/plugins/telit/mm-common-telit.c
index 1e43588..cfd3292 100644
--- a/plugins/telit/mm-common-telit.c
+++ b/plugins/telit/mm-common-telit.c
@@ -120,10 +120,7 @@ out:
 /* Custom init */
 
 typedef struct {
-MMPortProbe *probe;
 MMPortSerialAt *port;
-GCancellable *cancellable;
-GSimpleAsyncResult *result;
 gboolean getportcfg_done;
 guint getportcfg_retries;
 } TelitCustomInitContext;
@@ -133,10 +130,10 @@ telit_custom_init_finish (MMPortProbe *probe,
   GAsyncResult *result,
   GError **error)
 {
-return !g_simple_async_result_propagate_error (G_SIMPLE_ASYNC_RESULT 
(result), error);
+return g_task_propagate_boolean (G_TASK (result), error);
 }
 
-static void telit_custom_init_step (TelitCustomInitContext *ctx);
+static void telit_custom_init_step (GTask *task);
 
 static gboolean
 cache_port_mode (MMDevice *device,
@@ -217,10 +214,15 @@ out:
 static void
 getportcfg_ready (MMPortSerialAt *port,
   GAsyncResult *res,
-  TelitCustomInitContext *ctx)
+  GTask *task)
 {
 const gchar *response;
 GError *error = NULL;
+MMPortProbe *probe;
+TelitCustomInitContext *ctx;
+
+ctx = g_task_get_task_data (task);
+probe = g_task_get_source_object (task);
 
 response = mm_port_serial_at_command_finish (port, res, );
 if (error) {
@@ -237,7 +239,7 @@ getportcfg_ready (MMPortSerialAt *port,
 } else {
 MMDevice *device;
 
-device = mm_port_probe_peek_device (ctx->probe);
+device = mm_port_probe_peek_device (probe);
 
 /* Results are cached in the parent device object */
 if (g_object_get_data (G_OBJECT (device), TAG_GETPORTCFG_SUPPORTED) == 
NULL) {
@@ -249,35 +251,34 @@ getportcfg_ready (MMPortSerialAt *port,
 }
 
 /* Port answered to #PORTCFG, so mark it as being AT already */
-mm_port_probe_set_result_at (ctx->probe, TRUE);
+mm_port_probe_set_result_at (probe, TRUE);
 }
 
 if (error)
 g_error_free (error);
 
-telit_custom_init_step (ctx);
+telit_custom_init_step (task);
 }
 
 static void
-telit_custom_init_context_complete_and_free (TelitCustomInitContext *ctx)
+telit_custom_init_context_free (TelitCustomInitContext *ctx)
 {
-g_simple_async_result_complete_in_idle (ctx->result);
-
-if (ctx->cancellable)
-g_object_unref (ctx->cancellable);
 g_object_unref (ctx->port);
-g_object_unref (ctx->probe);
-g_object_unref (ctx->result);
 g_slice_free (TelitCustomInitContext, ctx);
 }
 
 static void
-telit_custom_init_step (TelitCustomInitContext *ctx)
+telit_custom_init_step (GTask *task)
 {
 MMKernelDevice *port;
+MMPortProbe *probe;
+TelitCustomInitContext *ctx;
+
+ctx = g_task_get_task_data (task);
+probe = g_task_get_source_object (task);
 
 /* If cancelled, end */
-if (g_cancellable_is_cancelled (ctx->cancellable)) {
+if (g_task_return_error_if_cancelled (task)) {
 mm_dbg ("telit: no need to keep on running custom init in (%s)",
 mm_port_get_device (MM_PORT (ctx->port)));
 goto out;
@@ -286,7 +287,7 @@ telit_custom_init_step (TelitCustomInitContext *ctx)
 /* Try to get a port configuration from the modem: usb interface 00
  * is always linked to an AT port
  */
-port = mm_port_probe_peek_port (ctx->probe);
+port = mm_port_probe_peek_port (probe);
 if (!ctx->getportcfg_done &&
 g_strcmp0 (mm_kernel_device_get_property (port, 
"ID_USB_INTERFACE_NUM"), "00") == 0) {
 
@@ -300,15 +301,15 @@ telit_custom_init_step (TelitCustomInitContext *ctx)
 2,
 FALSE, /* raw */
 FALSE, /* allow_cached */
-ctx->cancellable,
+g_task_get_cancellable (task),
 (GAsyncReadyCallback)getportcfg_ready,
-ctx);
+task);
 return;
 }
 
 out:
-g_simple_async_result_set_op_res_gboolean (ctx->result, TRUE);
-telit_custom_init_context_complete_and_free (ctx);
+g_task_return_boolean (task, TRUE);
+g_object_unref (task);
 }
 
 void
@@ -318,23 +319,16 @@ telit_custom_init (MMPortProbe *probe,
GAsyncReadyCallback callback,
gpointer user_data)
 {
-MMDevice *device;
-MMKernelDevice *port_device;
 TelitCustomInitContext *ctx;
-
-device = mm_port_probe_peek_device (probe);
-port_device = mm_port_probe_peek_port (probe);
+GTask *task;
 
 ctx = g_slice_new (TelitCustomInitContext);
-ctx->result = g_simple_async_result_new (G_OBJECT (probe),
- callback,
- user_data,
- telit_custom_init);
-  

Re: Sending SMS in PDU mode fails.

[Daniele Palmas]

2017-08-07 11:04 GMT+02:00 Aleksander Morgado :
>>> I can confirm that LE866-SV1 uses Telit custom 3GPP2 PDU format: there
>>> should be a PDU example in the AT commands user guide (see +CMGS
>>> 3GPP2), while EU variants use 3GPP.
>>
>> Thanks for the information. Then it is expected that the USA version (the
>> one I reported) does not work with ModemManager because it uses 3GPP2 PDU
>> format? Or is this format also supported in ModemManager?
>>
>
> My understanding is that it is currently not supported in ModemManager.
>

 But... 
 https://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-sms-part-cdma.c

 The issue here is that the message isn't formatted as 3GPP2/CDMA
 because the modem is actually an LTE modem (i.e. 3GPP). As soon as a
 modem is 3GPP, we use the 3GPP format, see:
 https://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-base-sms.c#n311

 The question now would be, is this something that happens to all
 US-version Telit modems?
>>>
>>> As far as I know this happens only for Verizon customization that uses
>>> SMS over IMS with 3GPP2 pdu.
>>>
 Isn't this actually a bit weird, given that
 the LE866-SV1 is actually LTE-only (i.e. 3GPP-only, not 3GPP2)?
>>>
>>> Looks like a carrier requirement for SMS.
>>>
>>
>> See also Reinhard's comment about this:
>>
>> https://lists.freedesktop.org/archives/modemmanager-devel/2016-January/002468.html
>>
>
> Interesting... I now wonder how we can setup all this to work
> automatically, if at all possible. We don't have any carrier-specific
> customization right now anywhere. Maybe some user specified parameter
> asking for a specific type of PDU to generate?
>

For this specific scenario would it be a too ugly hack blindly
re-trying with 3GPP2 if 3GPP fails and then storing the setting if
successful?

Unfortunately the result code is not helpful here (CMS ERROR: 41 that
is temporary failure), but this could be something Telit specific...

Or maybe we can let each plugin take care of this: for Telit modems
probably we can think of checking some substring in the model name
(e.g. -SV or -NV). Maybe other modems have a similar rule or some
custom AT command that can be checked for that.

Just throwing some ideas, not sure how much they make sense..

However a more generic way to address carrier customization issues
could be helpful for other scenarios.

Daniele

> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

[Daniele Palmas]

Hi Aleksander and José,

2017-08-04 15:24 GMT+02:00 Aleksander Morgado :
> Hey José, Carlo & Daniele
>
> On Fri, Aug 4, 2017 at 10:27 AM, José  wrote:
>> I am trying the same thing with the Telit LE866. With that modem I am
>> able to send SMSs in Text mode using AT commands, but no in PDU mode.
>>
>
> Hum I totally believe I did send SMS in PDU mode with the Telit
> LE866 a while back... What is the error you're getting, and which is
> the actual PDU you're trying to send?
>
>> I have been told that "Telit's PDU mode doesn't use the standard GSM
>> PDUs" but I am checking the AT Reference sheet and this is not clear
>> to me. Does anyone know about this? Would it be possible to make the
>> Telit plugin from ModemManager to use Text mode for the LE866-SV1?
>>
>
> Carlo, Daniele, do you have any comment on that statement regarding
> Telit's PDU mode?
>

as far as I remember 3GPP pdu should be supported, but maybe this
could depend on firmware customizations.

I'm checking this internally, but since it is vacation time it could
not be immediate.

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

[Daniele Palmas]

Hi Josè,

2017-08-04 16:18 GMT+02:00 José <josedd...@gmail.com>:
> On Fri, Aug 4, 2017 at 4:14 PM, Daniele Palmas <dnl...@gmail.com> wrote:
>>
>> as far as I remember 3GPP pdu should be supported, but maybe this
>> could depend on firmware customizations.
>>
> Just in case, this is the information for the Modem I am using:
>
>   -
>   Hardware |   manufacturer: 'Telit'
>|  model: 'LE866-SV1'

I can confirm that LE866-SV1 uses Telit custom 3GPP2 PDU format: there
should be a PDU example in the AT commands user guide (see +CMGS
3GPP2), while EU variants use 3GPP.

Regards,
Daniele

>|   revision: '23.00.002 (M0A.00020)'
>|  supported: 'lte'
>|current: 'lte'
>|   equipment id: '352613070097419'
>   -
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

[Daniele Palmas]

2017-08-07 9:50 GMT+02:00 José <josedd...@gmail.com>:
>
> On Mon, Aug 7, 2017 at 9:46 AM, Daniele Palmas <dnl...@gmail.com> wrote:
>> I can confirm that LE866-SV1 uses Telit custom 3GPP2 PDU format: there
>> should be a PDU example in the AT commands user guide (see +CMGS
>> 3GPP2), while EU variants use 3GPP.
>
> Thanks for the information. Then it is expected that the USA version (the
> one I reported) does not work with ModemManager because it uses 3GPP2 PDU
> format? Or is this format also supported in ModemManager?
>

My understanding is that it is currently not supported in ModemManager.

Regards,
Daniele
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

[Daniele Palmas]

2017-08-07 10:39 GMT+02:00 Daniele Palmas <dnl...@gmail.com>:
> 2017-08-07 10:24 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
>>>>> I can confirm that LE866-SV1 uses Telit custom 3GPP2 PDU format: there
>>>>> should be a PDU example in the AT commands user guide (see +CMGS
>>>>> 3GPP2), while EU variants use 3GPP.
>>>>
>>>> Thanks for the information. Then it is expected that the USA version (the
>>>> one I reported) does not work with ModemManager because it uses 3GPP2 PDU
>>>> format? Or is this format also supported in ModemManager?
>>>>
>>>
>>> My understanding is that it is currently not supported in ModemManager.
>>>
>>
>> But... 
>> https://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-sms-part-cdma.c
>>
>> The issue here is that the message isn't formatted as 3GPP2/CDMA
>> because the modem is actually an LTE modem (i.e. 3GPP). As soon as a
>> modem is 3GPP, we use the 3GPP format, see:
>> https://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-base-sms.c#n311
>>
>> The question now would be, is this something that happens to all
>> US-version Telit modems?
>
> As far as I know this happens only for Verizon customization that uses
> SMS over IMS with 3GPP2 pdu.
>
>> Isn't this actually a bit weird, given that
>> the LE866-SV1 is actually LTE-only (i.e. 3GPP-only, not 3GPP2)?
>
> Looks like a carrier requirement for SMS.
>

See also Reinhard's comment about this:

https://lists.freedesktop.org/archives/modemmanager-devel/2016-January/002468.html

Daniele

> Regards,
> Daniele
>
>>
>> --
>> Aleksander
>> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 1/1] helpers: extend +WS46=? response parser to support ranges

[Daniele Palmas]

Telit LTE modems could reply to +WS46=? with:

+WS46: (12,22,25,28-31)

This patch extends +WS46=? response parser to support ranges.
---
Hi,

current mm log is

Jun 15 15:04:04 L2122 ModemManager[831]:  (ttyACM0): --> 'AT+WS46=?'
Jun 15 15:04:04 L2122 ModemManager[831]:  (ttyACM0): <-- ''
Jun 15 15:04:04 L2122 ModemManager[831]:  (ttyACM0): <-- '+WS46: 
(12,22,25,28-31)OK'
Jun 15 15:04:04 L2122 ModemManager[831]: Invalid +WS46 mode reported: 28-31

Daniele
---
 src/mm-modem-helpers.c | 58 +++---
 src/tests/test-modem-helpers.c | 33 
 2 files changed, 76 insertions(+), 15 deletions(-)

diff --git a/src/mm-modem-helpers.c b/src/mm-modem-helpers.c
index 73822e1..dbd3cf8 100644
--- a/src/mm-modem-helpers.c
+++ b/src/mm-modem-helpers.c
@@ -920,29 +920,57 @@ mm_3gpp_parse_ws46_test_response (const gchar  *response,
 for (i = 0; split && split[i]; i++) {
 guint val;
 guint j;
+guint k;
+GArray *range_values = NULL;
+
+range_values = g_array_new (FALSE, FALSE, sizeof (guint));
 
 if (!mm_get_uint_from_str (split[i], )) {
-g_warning ("Invalid +WS46 mode reported: %s", split[i]);
-continue;
+gchar **split_range;
+guint range_start;
+guint range_end;
+
+split_range = g_strsplit (split[i], "-", -1);
+
+if (!split_range ||
+!mm_get_uint_from_str (split_range[0], _start) ||
+!mm_get_uint_from_str (split_range[1], _end)) {
+g_warning ("Invalid +WS46 mode reported: %s", split[i]);
+g_strfreev (split_range);
+g_array_free (range_values, TRUE);
+continue;
+}
+
+for (k = range_start; k <= range_end; k++)
+g_array_append_val (range_values, k);
+g_strfreev (split_range);
+} else {
+g_array_append_val (range_values, val);
 }
 
-for (j = 0; j < G_N_ELEMENTS (ws46_modes); j++) {
-if (ws46_modes[j].ws46 == val) {
-if (val != 25) {
-if (ws46_modes[j].mode & MM_MODEM_MODE_4G)
-supported_4g = TRUE;
-if (ws46_modes[j].mode & MM_MODEM_MODE_3G)
-supported_3g = TRUE;
-if (ws46_modes[j].mode & MM_MODEM_MODE_2G)
-supported_2g = TRUE;
+for (k = 0; k < range_values->len; k++) {
+val = g_array_index (range_values, guint, k);
+
+for (j = 0; j < G_N_ELEMENTS (ws46_modes); j++) {
+if (ws46_modes[j].ws46 == val) {
+if (val != 25) {
+if (ws46_modes[j].mode & MM_MODEM_MODE_4G)
+supported_4g = TRUE;
+if (ws46_modes[j].mode & MM_MODEM_MODE_3G)
+supported_3g = TRUE;
+if (ws46_modes[j].mode & MM_MODEM_MODE_2G)
+supported_2g = TRUE;
+}
+g_array_append_val (modes, ws46_modes[j].mode);
+break;
 }
-g_array_append_val (modes, ws46_modes[j].mode);
-break;
 }
+
+if (j == G_N_ELEMENTS (ws46_modes))
+g_warning ("Unknown +WS46 mode reported: %s", split[i]);
 }
 
-if (j == G_N_ELEMENTS (ws46_modes))
-g_warning ("Unknown +WS46 mode reported: %s", split[i]);
+g_array_free (range_values, TRUE);
 }
 
 g_strfreev (split);
diff --git a/src/tests/test-modem-helpers.c b/src/tests/test-modem-helpers.c
index 5928412..feb4fae 100644
--- a/src/tests/test-modem-helpers.c
+++ b/src/tests/test-modem-helpers.c
@@ -215,6 +215,37 @@ test_ws46_response_telit_le866 (void)
 test_ws46_response (str, expected, G_N_ELEMENTS (expected));
 }
 
+static void
+test_ws46_response_range_1 (void)
+{
+static const MMModemMode expected[] = {
+MM_MODEM_MODE_4G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_3G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_4G,
+MM_MODEM_MODE_3G | MM_MODEM_MODE_4G,
+};
+const gchar *str = "+WS46: (28-31)";
+
+test_ws46_response (str, expected, G_N_ELEMENTS (expected));
+}
+
+static void
+test_ws46_response_range_2 (void)
+{
+static const MMModemMode expected[] = {
+MM_MODEM_MODE_2G,
+MM_MODEM_MODE_3G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_3G | MM_MODEM_MODE_4G,
+MM_MODEM_MODE_4G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_3G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_4G,
+MM_MODEM_MODE_3G | MM_MODEM_MODE_4G,
+};
+const gchar *str = "+WS46: (12,22,25,28-31)";
+
+test_ws46_response (str, expected, G_N_ELEMENTS (expected));
+}
+
 /*/
 /* Test CMGL responses */
 
@@ 

Re: [PATCH 1/1] helpers: extend +WS46=? response parser to support ranges

[Daniele Palmas]

Hi Aleksander,

2017-06-16 10:39 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
> Hey Daniele,
>
> On Fri, Jun 16, 2017 at 10:11 AM, Daniele Palmas <dnl...@gmail.com> wrote:
>> Telit LTE modems could reply to +WS46=? with:
>>
>> +WS46: (12,22,25,28-31)
>>
>> This patch extends +WS46=? response parser to support ranges.
>> ---
>> Hi,
>>
>> current mm log is
>>
>> Jun 15 15:04:04 L2122 ModemManager[831]:  (ttyACM0): --> 
>> 'AT+WS46=?'
>> Jun 15 15:04:04 L2122 ModemManager[831]:  (ttyACM0): <-- ''
>> Jun 15 15:04:04 L2122 ModemManager[831]:  (ttyACM0): <-- '+WS46: 
>> (12,22,25,28-31)OK'
>> Jun 15 15:04:04 L2122 ModemManager[831]: Invalid +WS46 mode reported: 28-31
>>
>> Daniele
>
>
> How about using this method instead? It already supports parsing lists
> of numbers, including intervals:
>GArray *mm_parse_uint_list (const gchar  *str, GError **error)
>
> See:
>
> https://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-modem-helpers.c#n139
>

Sorry, I missed that :-( I will write a new patch.

Thanks,
Daniele

>> ---
>>  src/mm-modem-helpers.c | 58 
>> +++---
>>  src/tests/test-modem-helpers.c | 33 
>>  2 files changed, 76 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/mm-modem-helpers.c b/src/mm-modem-helpers.c
>> index 73822e1..dbd3cf8 100644
>> --- a/src/mm-modem-helpers.c
>> +++ b/src/mm-modem-helpers.c
>> @@ -920,29 +920,57 @@ mm_3gpp_parse_ws46_test_response (const gchar  
>> *response,
>>  for (i = 0; split && split[i]; i++) {
>>  guint val;
>>  guint j;
>> +guint k;
>> +GArray *range_values = NULL;
>> +
>> +range_values = g_array_new (FALSE, FALSE, sizeof (guint));
>>
>>  if (!mm_get_uint_from_str (split[i], )) {
>> -g_warning ("Invalid +WS46 mode reported: %s", split[i]);
>> -continue;
>> +gchar **split_range;
>> +guint range_start;
>> +guint range_end;
>> +
>> +split_range = g_strsplit (split[i], "-", -1);
>> +
>> +if (!split_range ||
>> +!mm_get_uint_from_str (split_range[0], _start) ||
>> +!mm_get_uint_from_str (split_range[1], _end)) {
>> +g_warning ("Invalid +WS46 mode reported: %s", split[i]);
>> +g_strfreev (split_range);
>> +g_array_free (range_values, TRUE);
>> +continue;
>> +}
>> +
>> +for (k = range_start; k <= range_end; k++)
>> +g_array_append_val (range_values, k);
>> +g_strfreev (split_range);
>> +} else {
>> +g_array_append_val (range_values, val);
>>  }
>>
>> -for (j = 0; j < G_N_ELEMENTS (ws46_modes); j++) {
>> -if (ws46_modes[j].ws46 == val) {
>> -if (val != 25) {
>> -if (ws46_modes[j].mode & MM_MODEM_MODE_4G)
>> -supported_4g = TRUE;
>> -if (ws46_modes[j].mode & MM_MODEM_MODE_3G)
>> -supported_3g = TRUE;
>> -if (ws46_modes[j].mode & MM_MODEM_MODE_2G)
>> -supported_2g = TRUE;
>> +for (k = 0; k < range_values->len; k++) {
>> +val = g_array_index (range_values, guint, k);
>> +
>> +for (j = 0; j < G_N_ELEMENTS (ws46_modes); j++) {
>> +if (ws46_modes[j].ws46 == val) {
>> +if (val != 25) {
>> +if (ws46_modes[j].mode & MM_MODEM_MODE_4G)
>> +supported_4g = TRUE;
>> +if (ws46_modes[j].mode & MM_MODEM_MODE_3G)
>> +supported_3g = TRUE;
>> +if (ws46_modes[j].mode & MM_MODEM_MODE_2G)
>> +supported_2g = TRUE;
>> +}
>> +g_array_append_val (modes, ws46_modes[j].mode);
>> +break;
>>  }
>> -g_array_append_val (modes, ws46_modes[j].mode);
>> -break;
>>  }
>> +
>> +if (j == G_N_ELEMENTS (ws46_modes))
>> +g_warning ("Unknown +WS46 mode reported: %s&qu

[PATCH v2 1/1] helpers: extend +WS46=? response parser to support ranges

[Daniele Palmas]

Telit LTE modems could reply to +WS46=? with:

+WS46: (12,22,25,28-31)

This patch extends +WS46=? response parser to support ranges.
---
v2: used mm_parse_uint_list as suggested by Aleksander
---
 src/mm-modem-helpers.c | 25 -
 src/tests/test-modem-helpers.c | 32 
 2 files changed, 44 insertions(+), 13 deletions(-)

diff --git a/src/mm-modem-helpers.c b/src/mm-modem-helpers.c
index 73822e1..5e257a8 100644
--- a/src/mm-modem-helpers.c
+++ b/src/mm-modem-helpers.c
@@ -887,12 +887,14 @@ mm_3gpp_parse_ws46_test_response (const gchar  *response,
   GError  **error)
 {
 GArray *modes = NULL;
+GArray *tech_values = NULL;
 GRegex *r;
 GError *inner_error = NULL;
 GMatchInfo *match_info = NULL;
 gchar  *full_list = NULL;
-gchar **split;
+guint   val;
 guint   i;
+guint   j;
 gbooleansupported_4g = FALSE;
 gbooleansupported_3g = FALSE;
 gbooleansupported_2g = FALSE;
@@ -914,17 +916,13 @@ mm_3gpp_parse_ws46_test_response (const gchar  *response,
 goto out;
 }
 
-split = g_strsplit (full_list, ",", -1);
+if (!(tech_values = mm_parse_uint_list (full_list, _error)))
+goto out;
+
 modes = g_array_new (FALSE, FALSE, sizeof (MMModemMode));
 
-for (i = 0; split && split[i]; i++) {
-guint val;
-guint j;
-
-if (!mm_get_uint_from_str (split[i], )) {
-g_warning ("Invalid +WS46 mode reported: %s", split[i]);
-continue;
-}
+for (i = 0; i < tech_values->len; i++) {
+val = g_array_index (tech_values, guint, i);
 
 for (j = 0; j < G_N_ELEMENTS (ws46_modes); j++) {
 if (ws46_modes[j].ws46 == val) {
@@ -942,11 +940,9 @@ mm_3gpp_parse_ws46_test_response (const gchar  *response,
 }
 
 if (j == G_N_ELEMENTS (ws46_modes))
-g_warning ("Unknown +WS46 mode reported: %s", split[i]);
+g_warning ("Unknown +WS46 mode reported: %u", val);
 }
 
-g_strfreev (split);
-
 if (modes->len == 0) {
 inner_error = g_error_new (MM_CORE_ERROR, MM_CORE_ERROR_FAILED, "No 
valid modes reported");
 g_clear_pointer (, g_array_unref);
@@ -976,6 +972,9 @@ mm_3gpp_parse_ws46_test_response (const gchar  *response,
 }
 
 out:
+if (tech_values)
+g_array_unref (tech_values);
+
 g_free (full_list);
 
 g_clear_pointer (_info, g_match_info_free);
diff --git a/src/tests/test-modem-helpers.c b/src/tests/test-modem-helpers.c
index 5928412..5fdded4 100644
--- a/src/tests/test-modem-helpers.c
+++ b/src/tests/test-modem-helpers.c
@@ -215,6 +215,36 @@ test_ws46_response_telit_le866 (void)
 test_ws46_response (str, expected, G_N_ELEMENTS (expected));
 }
 
+static void
+test_ws46_response_range_1 (void)
+{
+static const MMModemMode expected[] = {
+MM_MODEM_MODE_2G | MM_MODEM_MODE_3G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_4G,
+MM_MODEM_MODE_3G | MM_MODEM_MODE_4G,
+};
+const gchar *str = "+WS46: (29-31)";
+
+test_ws46_response (str, expected, G_N_ELEMENTS (expected));
+}
+
+static void
+test_ws46_response_range_2 (void)
+{
+static const MMModemMode expected[] = {
+MM_MODEM_MODE_2G,
+MM_MODEM_MODE_3G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_3G | MM_MODEM_MODE_4G,
+MM_MODEM_MODE_4G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_3G,
+MM_MODEM_MODE_2G | MM_MODEM_MODE_4G,
+MM_MODEM_MODE_3G | MM_MODEM_MODE_4G,
+};
+const gchar *str = "+WS46: (12,22,25,28-31)";
+
+test_ws46_response (str, expected, G_N_ELEMENTS (expected));
+}
+
 /*/
 /* Test CMGL responses */
 
@@ -3715,6 +3745,8 @@ int main (int argc, char **argv)
 g_test_suite_add (suite, TESTCASE (test_ws46_response_generic_2g3g_v2, 
NULL));
 g_test_suite_add (suite, TESTCASE (test_ws46_response_cinterion, NULL));
 g_test_suite_add (suite, TESTCASE (test_ws46_response_telit_le866, NULL));
+g_test_suite_add (suite, TESTCASE (test_ws46_response_range_1, NULL));
+g_test_suite_add (suite, TESTCASE (test_ws46_response_range_2, NULL));
 
 g_test_suite_add (suite, TESTCASE (test_cops_response_tm506, NULL));
 g_test_suite_add (suite, TESTCASE (test_cops_response_gt3gplus, NULL));
-- 
2.7.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH v2 1/1] helpers: extend +WS46=? response parser to support ranges

[Daniele Palmas]

2017-06-16 15:56 GMT+02:00 Aleksander Morgado <aleksan...@aleksander.es>:
> On 16/06/17 14:57, Daniele Palmas wrote:
>> Telit LTE modems could reply to +WS46=? with:
>>
>> +WS46: (12,22,25,28-31)
>>
>> This patch extends +WS46=? response parser to support ranges.
>> ---
>> v2: used mm_parse_uint_list as suggested by Aleksander
>
>
> Pushed to git master and mm-1-6. I realized late that mm-1-6 didn't have the 
> mm_parse_uint_list() method yet, but I cherry-picked that one on top of your 
> patch, so now mm-1-6 also builds correctly... sorry for that mixup.

Thanks! I'll send shortly another patch that depends on this one to
properly work with Telit LTE modems.

Regards,
Daniele

>
>> ---
>>  src/mm-modem-helpers.c | 25 -
>>  src/tests/test-modem-helpers.c | 32 
>>  2 files changed, 44 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/mm-modem-helpers.c b/src/mm-modem-helpers.c
>> index 73822e1..5e257a8 100644
>> --- a/src/mm-modem-helpers.c
>> +++ b/src/mm-modem-helpers.c
>> @@ -887,12 +887,14 @@ mm_3gpp_parse_ws46_test_response (const gchar  
>> *response,
>>GError  **error)
>>  {
>>  GArray *modes = NULL;
>> +GArray *tech_values = NULL;
>>  GRegex *r;
>>  GError *inner_error = NULL;
>>  GMatchInfo *match_info = NULL;
>>  gchar  *full_list = NULL;
>> -gchar **split;
>> +guint   val;
>>  guint   i;
>> +guint   j;
>>  gbooleansupported_4g = FALSE;
>>  gbooleansupported_3g = FALSE;
>>  gbooleansupported_2g = FALSE;
>> @@ -914,17 +916,13 @@ mm_3gpp_parse_ws46_test_response (const gchar  
>> *response,
>>  goto out;
>>  }
>>
>> -split = g_strsplit (full_list, ",", -1);
>> +if (!(tech_values = mm_parse_uint_list (full_list, _error)))
>> +goto out;
>> +
>>  modes = g_array_new (FALSE, FALSE, sizeof (MMModemMode));
>>
>> -for (i = 0; split && split[i]; i++) {
>> -guint val;
>> -guint j;
>> -
>> -if (!mm_get_uint_from_str (split[i], )) {
>> -g_warning ("Invalid +WS46 mode reported: %s", split[i]);
>> -continue;
>> -}
>> +for (i = 0; i < tech_values->len; i++) {
>> +val = g_array_index (tech_values, guint, i);
>>
>>  for (j = 0; j < G_N_ELEMENTS (ws46_modes); j++) {
>>  if (ws46_modes[j].ws46 == val) {
>> @@ -942,11 +940,9 @@ mm_3gpp_parse_ws46_test_response (const gchar  
>> *response,
>>  }
>>
>>  if (j == G_N_ELEMENTS (ws46_modes))
>> -g_warning ("Unknown +WS46 mode reported: %s", split[i]);
>> +g_warning ("Unknown +WS46 mode reported: %u", val);
>>  }
>>
>> -g_strfreev (split);
>> -
>>  if (modes->len == 0) {
>>  inner_error = g_error_new (MM_CORE_ERROR, MM_CORE_ERROR_FAILED, "No 
>> valid modes reported");
>>  g_clear_pointer (, g_array_unref);
>> @@ -976,6 +972,9 @@ mm_3gpp_parse_ws46_test_response (const gchar  *response,
>>  }
>>
>>  out:
>> +if (tech_values)
>> +g_array_unref (tech_values);
>> +
>>  g_free (full_list);
>>
>>  g_clear_pointer (_info, g_match_info_free);
>> diff --git a/src/tests/test-modem-helpers.c b/src/tests/test-modem-helpers.c
>> index 5928412..5fdded4 100644
>> --- a/src/tests/test-modem-helpers.c
>> +++ b/src/tests/test-modem-helpers.c
>> @@ -215,6 +215,36 @@ test_ws46_response_telit_le866 (void)
>>  test_ws46_response (str, expected, G_N_ELEMENTS (expected));
>>  }
>>
>> +static void
>> +test_ws46_response_range_1 (void)
>> +{
>> +static const MMModemMode expected[] = {
>> +MM_MODEM_MODE_2G | MM_MODEM_MODE_3G,
>> +MM_MODEM_MODE_2G | MM_MODEM_MODE_4G,
>> +MM_MODEM_MODE_3G | MM_MODEM_MODE_4G,
>> +};
>> +const gchar *str = "+WS46: (29-31)";
>> +
>> +test_ws46_response (str, expected, G_N_ELEMENTS (expected));
>> +}
>> +
>> +static void
>> +test_ws46_response_range_2 (void)
>> +{
>> +static const MMModemMode expected[] = {
>> +MM_MODEM_MODE_2G,
>> +MM_MODEM_MODE_3G,
>> +MM_MODEM_MODE_2G | MM_MODEM_MODE_3G | MM_MODEM_MODE_4G,
>> +MM_M

[PATCH 1/1] telit: fix #PSNT values interpretation for HSDPA and LTE modems

[Daniele Palmas]

Telit LTE modems use #PSNT: 4 for LTE access technology,
and #PSNT: 5 for unknown access technology, while HSDPA
modems use #PSNT: 4 for unknown access technology.

This patch fixes those #PSNT values interpretation according
to the modem capabilities.
---
Hi,

this patch needs commit

58206664959a73deb8008b82b5070edb4ef87df2
helpers: extend +WS46=? response parser to support ranges

to work properly.

Thanks,
Daniele
---
 plugins/telit/mm-broadband-modem-telit.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/plugins/telit/mm-broadband-modem-telit.c 
b/plugins/telit/mm-broadband-modem-telit.c
index bd568a0..55deeed 100644
--- a/plugins/telit/mm-broadband-modem-telit.c
+++ b/plugins/telit/mm-broadband-modem-telit.c
@@ -954,8 +954,17 @@ response_processor_psnt_ignore_at_errors (MMBaseModem 
*self,
 *result = g_variant_new_uint32 (MM_MODEM_ACCESS_TECHNOLOGY_HSDPA);
 return TRUE;
 case 4:
-*result = g_variant_new_uint32 (MM_MODEM_ACCESS_TECHNOLOGY_LTE);
+if (mm_iface_modem_is_3gpp_lte (MM_IFACE_MODEM (self)))
+*result = g_variant_new_uint32 
(MM_MODEM_ACCESS_TECHNOLOGY_LTE);
+else
+*result = g_variant_new_uint32 
(MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN);
 return TRUE;
+case 5:
+if (mm_iface_modem_is_3gpp_lte (MM_IFACE_MODEM (self))) {
+*result = g_variant_new_uint32 
(MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN);
+return TRUE;
+}
+/* Fall-through since #PSNT: 5 is not supported in other than lte 
modems */
 default:
 break;
 }
-- 
2.7.4

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Telit CE910D OMA-DM issues and cert testing using ModemManager

[Daniele Palmas]

Hi Aleksander and Rowan,

2017-09-19 18:53 GMT+02:00 Aleksander Morgado :
>>
>>
>> Interesting, in the testing lab they noticed that they only saw this being a
>> problem when ModemManager was running. But if your telling me that it’s
>> related to the modules firmware... Can you think of anything in Modem
>> Manager that could be conflicting with the carrier messages going to the
>> module?
>
> The only thing I can think of is that ModemManager actually consumes
> the AT unsolicited messages it receives in the TTYs. Maybe the module
> is sending these messages and expecting something else to happen? No
> idea.
>

yes, the modem could send notifications related to the OMA DM session,
but my understanding is that those are only to report the status, so
consuming unsolicited should not be an issue.

Rowan,

is ModemManager starting a data connection before the tests are started?

If yes, maybe it could be worth retrying with data connection
disabled, since there could be some issue with the contexts managed
internally by the firmware for the session and the one used by
ModemManager.

> Maybe getting debug logs of MM while reproducing the issues may give
> us more hints:
> https://www.freedesktop.org/wiki/Software/ModemManager/Debugging/
>

Agree, that could be useful.

Regards,
Daniele

>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Telit CE910D OMA-DM issues and cert testing using ModemManager

[Daniele Palmas]

Hi Rowan,

2017-09-20 16:36 GMT+02:00 Rowan Hamilton :
>
> Please see the attached logs. In the file entitled:
> ModemManager_waiting_on_prl_update_from_carrier.txt you can see that a #905
> comes in but we never get a #909. I'm thinking that its not relaying these
> #9xx messages to the module. If this is not possible would it be possible to
> put something in ModemManager to abort the data session and relay the
> previously sent commands to the module?
>

Since the modem is not receiving any other notification (especially
related to errors) I suspect here a firmware issue .

There are some custom AT commands for modem-initiating a session (see
document OMA-DM Client User Guide that you should have received), but,
before trying to implement a complicated logic, I suggest you to check
with Telit customer support if the firmware is behaving properly: they
will probably request you to collect modem traces for this.

By the way, from your logs, if I'm not wrong, it seems that data
connection setup attempts by NetworkManager are not succeeding.

Regards,
Daniele

>
> Some Telit #9xx commands:
> Hands Free Activation (Includes device configuration, PRL, and FUMO)
> #904 - Notification - HFA Started
> #914 - Notification – Done, HFA Success
>
> Stand Alone Device Configuration Network Initiated
> #906 - Notification – DC DM session started
> #918 - Notification – DC Done, success
>
> Stand Alone PRL Network Initiated
> #905 - Notification – PRL DM session started
> #909 - Notification – Done, PRL success
>
> Stand FUMO Network Initiated
> #907 - Notification – FUMO DM session started
> #916 - Notification – Done, No firmware update
> #919 - Notification – Done, Firmware downloaded successfully
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Set allowed mode to 2G, 3G, 4G not working

[Daniele Palmas]

Hi Carsten,

Il giorno ven 22 feb 2019 alle ore 12:12 Stelling2 Carsten
 ha scritto:
>
> Hi,
>
> I must correct me, modem type is LE910-EU1 as Reinhard assumed. Sorry for 
> this confusion.
> As a workaround for testing, we send AT+WS46 commands via D-Bus, but that 
> seems possible only, if MM runs in debug mode.
> If we need this feature for production in the future, I understand that we 
> can add it to the Telit plugin.

at the following link

https://gitlab.freedesktop.org/dnlplm/ModemManager.git

you can find a fork with two additional commits that should implement
what needed.

Before sending to Aleksander a merge request would you like to give it a try?

Regards,
Daniele

> I'd be very happy, if you can support me during implementation at a later 
> point in time.
>
> Thank you Aleksander and Reinhard for your support.
>
> Carsten
>
> -Ursprüngliche Nachricht-
> Von: Aleksander Morgado [mailto:aleksan...@aleksander.es]
> Gesendet: Freitag, 22. Februar 2019 09:59
> An: Reinhard Speyerer
> Cc: modemmanager-devel@lists.freedesktop.org; Stelling2 Carsten
> Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
>
> > > > Within the debug output I found the following line
> > > > ModemManager[623]:  [1550762368.321591] MBIM-powered Telit modem 
> > > > found...
> > > > which points out, that calling
> > > > if (mm_port_probe_list_is_xmm (probes))
> > > > did not find the XMM support.
> > >
> > > It didn't find it, because the XACT=? check failed:
> > > ModemManager[623]:  [1550762359.960165] (ttyACM0): --> 
> > > 'AT+XACT=?'
> > > ModemManager[623]:  [1550762360.882668] (ttyACM0): <--
> > > 'ERROR'
> > >
> > > So I assume the XMM support that we have in the xmm plugin isn't ready
> > > to handle this specific device.
> > >
> > > The inability to switch modes in this device is not a bug, it's just
> > > not implemented I'm afraid.
> >
> > Hi Aleksander,
> >
> > the Telit-preferred way seems to be to handle this with AT+WS46.
> > I haven't checked the code in detail but based on the AT+WS46
> > references in the Telit plugin I would have expected for
> > ModemManager to already use it.
> >
>
> If the modem is managed with MBIM, the generic MBIM implementation is
> used for the Telit modem, so no AT+WS46 based mode switching will be
> done. For this kind of cases, where we have MBIM for generic control
> plus AT for other features, we would need to have a
> "MMBroadbandModemMbimTelit" implementation that inherits from
> MMBroadbandModemMbim but then shares features with the Telit-specific
> AT modem object. So, it's totally possible to do this, but needs to be
> done.
>
> --
> Aleksander
> https://aleksander.es
>
>
> ___
> 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

Re: Set allowed mode to 2G, 3G, 4G not working

[Daniele Palmas]

Il giorno mer 27 feb 2019 alle ore 11:22 Aleksander Morgado
 ha scritto:
>
> >
> > But setting the preferred mode fails.
> >
> > mmcli -m 0 --set-preferred-mode=2G
> > error: setting preferred mode requires list of allowed modes
> >
>
> This is expected; you only want to set a "preferred mode" if you're
> configuring multiple "allowed modes".
>
> E.g. if you just want 2G, you would do:
>   --set-allowed-modes=2G
> If you want 2G+3G with 3G preferred, you would do:
>   --set-allowed-modes="2G|3G" --set-preferred-mode=3G
>

Let me add also that preferred mode setting is not supported at the AT
command level for Telit modems (see comment in set_current_modes).

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Planning to add a PCIe(not in USB protocol) device

[Daniele Palmas]

Hi Bjørn,

Il giorno lun 10 dic 2018 alle ore 14:25 Bjørn Mork  ha scritto:
>
> As for Qualcomm based modems:  Haven't yet seen any docs for the PCIe
> interface there either.  So I'll assume it is similar to the Intel one.

related to Qualcomm I guess this development

http://archive.lwn.net:8080/linux-kernel/1524795811-21399-1-git-send-email-sd...@codeaurora.org/

should be related, but unfortunately it seems that the attempt for
upstream inclusion stopped.

Regards,
Daniele
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Set allowed mode to 2G, 3G, 4G not working

[Daniele Palmas]

Hi Carsten,

Il giorno mar 19 nov 2019 alle ore 14:24 Daniele Palmas
 ha scritto:
>
> Hi Carsten,
>
> Il giorno mar 19 nov 2019 alle ore 10:10 Stelling2 Carsten
>  ha scritto:
> >
> > Hi,
> >
> > I've just updated MM from 1.10.0 to 1.12.0 with the result, that my 
> > application fails when setting the mode ('2G|4G') for Telit LE910-EU1. It 
> > also fails when using mmcli.
> > My version 1.10.0 contains Daniele's patches mentioned here 
> > https://lists.freedesktop.org/archives/modemmanager-devel/2019-February/007044.html
> >  and in following messages.
> >
> > I assume, that Daniele's patches didn't go mainline.
> >
>
> odd, they should be there, see commits 3921c120 and c7be4af5.
>
> I'll try to verify the feature on my LE910-EU1 by this week and give
> you some feedback.
>

I double-checked with 1.12.0, but I did not find any issue, see the following:

ModemManager[25584]:   [1574254091.241979] ModemManager (version
1.12.0) starting in system bus...

danielepa@danielepa-ThinkCentre-M93p:~/git/gitlab/ModemManager$ sudo mmcli -m 0
  
  General  |dbus path: /org/freedesktop/ModemManager1/Modem/0
   |device id: e3d2345d529078ca9387c8f81a844f19097127ca
  
  Hardware | manufacturer: Telit
   |model: FIH7160
   | revision: 20.00.414
   | h/w revision: XMM7160_V1.2_HWID790_MBIM_NAND
   |supported: gsm-umts, lte
   |  current: gsm-umts, lte
   | equipment id: 356611070026426
  
  System   |   device: /sys/devices/pci:00/:00:14.0/usb3/3-7
   |  drivers: cdc_acm, cdc_mbim
   |   plugin: Telit
   | primary port: cdc-wdm0
   |ports: ttyACM3 (at), wwp0s20u7i12 (net),
cdc-wdm0 (mbim)
  
  Status   |   unlock retries: sim-pin2 (3)
   |state: enabling
   |  power state: on
   |   signal quality: 0% (cached)
  
  Modes|supported: allowed: 2g; preferred: none
   |   allowed: 4g; preferred: none
   |   allowed: 2g, 4g; preferred: none
   |  current: allowed: 2g, 4g; preferred: none
  
  Bands|supported: egsm, dcs, eutran-1, eutran-3,
eutran-7, eutran-8, eutran-20
   |  current: egsm, dcs, eutran-1
  
  IP   |supported: ipv4, ipv6, ipv4v6
  
  3GPP | imei: 356611070026426
   |enabled locks: fixed-dialing
  
  3GPP EPS | ue mode of operation: csps-1
  
  SIM  |dbus path: /org/freedesktop/ModemManager1/SIM/0

danielepa@danielepa-ThinkCentre-M93p:~/git/ModemManager$ sudo
./cli/mmcli -m 0 --set-allowed-modes="2G"
successfully set current modes in the modem

ModemManager[25584]:  [1574254264.636226] (ttyACM3) device open
count is 3 (open)
ModemManager[25584]:  [1574254264.636294] (ttyACM3): --> 'AT+WS46=12'
ModemManager[25584]:  [1574254266.556383] (ttyACM3): <--
'OK'
ModemManager[25584]:  [1574254266.556495] (ttyACM3) device open
count is 4 (open)
ModemManager[25584]:  [1574254266.556532] (ttyACM3) device open
count is 3 (close)
ModemManager[25584]:  [1574254266.556559] (ttyACM3): --> 'AT+WS46?'
ModemManager[25584]:  [1574254266.568991] (ttyACM3): <-- ''
ModemManager[25584]:  [1574254266.569435] (ttyACM3): <--
'+WS46: 12OK'
ModemManager[25584]:  [1574254266.569582] Periodic signal check
refresh requested
ModemManager[25584]: [/dev/cdc-wdm0] Sent message...

danielepa@danielepa-ThinkCentre-M93p:~/git/ModemManager$ sudo ./cli/mmcli -m 0

  
  Modes|supported: allowed: 2g; preferred: none
   |   allowed: 4g; preferred: none
   |   allowed: 2g, 4g; preferred: none
   |  current: allowed: 2g; preferred: none


danielepa@danielepa-ThinkCentre-M93p:~/git/ModemManager$ sudo
./cli/mmcli -m 0 --set-allowed-modes="2G|4G"
successfully set current modes in the modem

ModemManager[25584]:  [1574254329.741936] (ttyACM3) device open
count is 3 (open)
ModemManager[25584]:  [1574254329.741979] (ttyACM3): --> 'AT+WS46=30'
ModemManager[25584]:  [1574254332.464923] (ttyACM3): <--
'OK'
ModemManager[25584]:  [1574254332.465145] (ttyACM3) device open
count is 4 (open)
ModemManager[25584]:  [1574254332.465227] (ttyACM3) device open
count is 3 (close)
ModemManager[25584]:  

Re: AW: Set allowed mode to 2G, 3G, 4G not working

[Daniele Palmas]

Hi Enrico,

Il giorno mar 19 nov 2019 alle ore 10:52 Enrico Mioso
 ha scritto:
>
> I am experiencing similar issues when trying to set allowed mode to all 
> modes, and preferred to "none in particular" :) .
> Simply doesn't work - even with a success message then settings remain so 
> that preferred mode looks to be 4G. Would like very much to solve this.
>

are you using LE910-EU1 as well?

Regards,
Daniele

> Enrico
>
>
>
> On Tue, 19 Nov 2019, Stelling2 Carsten wrote:
>
> > Date: Tue, 19 Nov 2019 10:10:44
> > From: Stelling2 Carsten 
> > To: "modemmanager-devel@lists.freedesktop.org"
> > ,
> > "Daniele Palmas (dnl...@gmail.com)" 
> > Subject: AW: Set allowed mode to 2G, 3G, 4G not working
> >
> > Hi,
> >
> > I've just updated MM from 1.10.0 to 1.12.0 with the result, that my 
> > application fails when setting the mode ('2G|4G') for Telit LE910-EU1. It 
> > also fails when using mmcli.
> > My version 1.10.0 contains Daniele's patches mentioned here 
> > https://lists.freedesktop.org/archives/modemmanager-devel/2019-February/007044.html
> >  and in following messages.
> >
> > I assume, that Daniele's patches didn't go mainline.
> >
> > Daniele, can you send a merge request, containing your patches for the 
> > master branch?
> > I'll test them as soon as possible with Telit LE910-EU1 and give you 
> > feedback, such that this feature can be released.
> >
> > Thank you for your help.
> >
> > Carsten
> >
> > -Ursprüngliche Nachricht-
> > Von: ModemManager-devel 
> > [mailto:modemmanager-devel-boun...@lists.freedesktop.org] Im Auftrag von 
> > Stelling2 Carsten
> > Gesendet: Mittwoch, 27. Februar 2019 10:16
> > An: Daniele Palmas
> > Cc: modemmanager-devel@lists.freedesktop.org; Reinhard Speyerer; Aleksander 
> > Morgado
> > Betreff: AW: Set allowed mode to 2G, 3G, 4G not working
> >
> > Hi Daniele,
> >
> > Thank you. Yes, I'll give it a try tomorrow.
> >
> > Following patches from your commits should be applied to MM 1.10.0
> >
> > 4089726c1fbdc90ecec8737f9ea287784708ca7f
> > 90cb911437538d5b6bd681aa1d7e1be2e1700227
> >
> > Is this right?
> >
> > Best regards,
> >
> > Carsten
> >
> > -Ursprüngliche Nachricht-
> > Von: Daniele Palmas [mailto:dnl...@gmail.com]
> > Gesendet: Dienstag, 26. Februar 2019 14:59
> > An: Stelling2 Carsten
> > Cc: Aleksander Morgado; Reinhard Speyerer; 
> > modemmanager-devel@lists.freedesktop.org
> > Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
> >
> > Hi Carsten,
> >
> > Il giorno ven 22 feb 2019 alle ore 12:12 Stelling2 Carsten
> >  ha scritto:
> >>
> >> Hi,
> >>
> >> I must correct me, modem type is LE910-EU1 as Reinhard assumed. Sorry for 
> >> this confusion.
> >> As a workaround for testing, we send AT+WS46 commands via D-Bus, but that 
> >> seems possible only, if MM runs in debug mode.
> >> If we need this feature for production in the future, I understand that we 
> >> can add it to the Telit plugin.
> >
> > at the following link
> >
> > https://gitlab.freedesktop.org/dnlplm/ModemManager.git
> >
> > you can find a fork with two additional commits that should implement
> > what needed.
> >
> > Before sending to Aleksander a merge request would you like to give it a 
> > try?
> >
> > Regards,
> > Daniele
> >
> >> I'd be very happy, if you can support me during implementation at a later 
> >> point in time.
> >>
> >> Thank you Aleksander and Reinhard for your support.
> >>
> >> Carsten
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Aleksander Morgado [mailto:aleksan...@aleksander.es]
> >> Gesendet: Freitag, 22. Februar 2019 09:59
> >> An: Reinhard Speyerer
> >> Cc: modemmanager-devel@lists.freedesktop.org; Stelling2 Carsten
> >> Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
> >>
> >>>>> Within the debug output I found the following line
> >>>>> ModemManager[623]:  [1550762368.321591] MBIM-powered Telit modem 
> >>>>> found...
> >>>>> which points out, that calling
> >>>>> if (mm_port_probe_list_is_xmm (probes))
> >>>>> did not find the XMM support.
> >>>>
> >>>> It didn't find it, because the XACT=? check failed:
> >>>> ModemManager[623

Re: Set allowed mode to 2G, 3G, 4G not working

[Daniele Palmas]

Hi Carsten,

Il giorno mar 19 nov 2019 alle ore 10:10 Stelling2 Carsten
 ha scritto:
>
> Hi,
>
> I've just updated MM from 1.10.0 to 1.12.0 with the result, that my 
> application fails when setting the mode ('2G|4G') for Telit LE910-EU1. It 
> also fails when using mmcli.
> My version 1.10.0 contains Daniele's patches mentioned here 
> https://lists.freedesktop.org/archives/modemmanager-devel/2019-February/007044.html
>  and in following messages.
>
> I assume, that Daniele's patches didn't go mainline.
>

odd, they should be there, see commits 3921c120 and c7be4af5.

I'll try to verify the feature on my LE910-EU1 by this week and give
you some feedback.

Regards,
Daniele

> Daniele, can you send a merge request, containing your patches for the master 
> branch?
> I'll test them as soon as possible with Telit LE910-EU1 and give you 
> feedback, such that this feature can be released.
>
> Thank you for your help.
>
> Carsten
>
> -Ursprüngliche Nachricht-
> Von: ModemManager-devel 
> [mailto:modemmanager-devel-boun...@lists.freedesktop.org] Im Auftrag von 
> Stelling2 Carsten
> Gesendet: Mittwoch, 27. Februar 2019 10:16
> An: Daniele Palmas
> Cc: modemmanager-devel@lists.freedesktop.org; Reinhard Speyerer; Aleksander 
> Morgado
> Betreff: AW: Set allowed mode to 2G, 3G, 4G not working
>
> Hi Daniele,
>
> Thank you. Yes, I'll give it a try tomorrow.
>
> Following patches from your commits should be applied to MM 1.10.0
>
> 4089726c1fbdc90ecec8737f9ea287784708ca7f
> 90cb911437538d5b6bd681aa1d7e1be2e1700227
>
> Is this right?
>
> Best regards,
>
> Carsten
>
> -Ursprüngliche Nachricht-
> Von: Daniele Palmas [mailto:dnl...@gmail.com]
> Gesendet: Dienstag, 26. Februar 2019 14:59
> An: Stelling2 Carsten
> Cc: Aleksander Morgado; Reinhard Speyerer; 
> modemmanager-devel@lists.freedesktop.org
> Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
>
> Hi Carsten,
>
> Il giorno ven 22 feb 2019 alle ore 12:12 Stelling2 Carsten
>  ha scritto:
> >
> > Hi,
> >
> > I must correct me, modem type is LE910-EU1 as Reinhard assumed. Sorry for 
> > this confusion.
> > As a workaround for testing, we send AT+WS46 commands via D-Bus, but that 
> > seems possible only, if MM runs in debug mode.
> > If we need this feature for production in the future, I understand that we 
> > can add it to the Telit plugin.
>
> at the following link
>
> https://gitlab.freedesktop.org/dnlplm/ModemManager.git
>
> you can find a fork with two additional commits that should implement
> what needed.
>
> Before sending to Aleksander a merge request would you like to give it a try?
>
> Regards,
> Daniele
>
> > I'd be very happy, if you can support me during implementation at a later 
> > point in time.
> >
> > Thank you Aleksander and Reinhard for your support.
> >
> > Carsten
> >
> > -Ursprüngliche Nachricht-
> > Von: Aleksander Morgado [mailto:aleksan...@aleksander.es]
> > Gesendet: Freitag, 22. Februar 2019 09:59
> > An: Reinhard Speyerer
> > Cc: modemmanager-devel@lists.freedesktop.org; Stelling2 Carsten
> > Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
> >
> > > > > Within the debug output I found the following line
> > > > > ModemManager[623]:  [1550762368.321591] MBIM-powered Telit 
> > > > > modem found...
> > > > > which points out, that calling
> > > > > if (mm_port_probe_list_is_xmm (probes))
> > > > > did not find the XMM support.
> > > >
> > > > It didn't find it, because the XACT=? check failed:
> > > > ModemManager[623]:  [1550762359.960165] (ttyACM0): --> 
> > > > 'AT+XACT=?'
> > > > ModemManager[623]:  [1550762360.882668] (ttyACM0): <--
> > > > 'ERROR'
> > > >
> > > > So I assume the XMM support that we have in the xmm plugin isn't ready
> > > > to handle this specific device.
> > > >
> > > > The inability to switch modes in this device is not a bug, it's just
> > > > not implemented I'm afraid.
> > >
> > > Hi Aleksander,
> > >
> > > the Telit-preferred way seems to be to handle this with AT+WS46.
> > > I haven't checked the code in detail but based on the AT+WS46
> > > references in the Telit plugin I would have expected for
> > > ModemManager to already use it.
> > >
> >
> > If the modem is managed with MBIM, the generic MBIM implementation is
> > used for the Telit modem, so no AT+WS46 based mode switching will be
> > 

Re: Telit LE910C1 - GPS integration

[Daniele Palmas]

Hi Aleksander,

Il giorno dom 3 mag 2020 alle ore 21:35 Aleksander Morgado
 ha scritto:
>
> Hey!
>
> > After digging for documentation with no success, I migrate the location 
> > interface to mm-shared-telit and added a qmi interface for the telit 
> > plugin. For the merge request, would it be OK to merge that kind of changes 
> > in 1.12 or it must me on master for the next release?
> >
>
> The merge request must be for master; we can then decide whether we
> want to include it in 1.12.x or not.
>
> But I'd like to clarify first whether not having GNSS location info
> from either PDS or LOC service is expected in Telit devices or not.
> @Daniele Palmas could you help with that?
>

Yes, the C1 supports the LOC service, as well as LM940/960 and FN980.

Regards,
Daniele

> Cheers!
>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Telit LE910C1 - GPS integration

[Daniele Palmas]

Hi Aleksander,

Il giorno gio 7 mag 2020 alle ore 17:45 Aleksander Morgado
 ha scritto:
>
> Hey Daniele,
>
> > > > > Then we need to debug why we were not able to get any LOC indication
> > > > > with NMEA traces in David's setup.
> > > >
> > > > > David, could you retry to setup the location using the QMI protocol
> > > > > (i.e. without your changes) but enabling both "nmea" and "raw"
> > > > > locations?
> > > > > Also, another test could be to enable MSB A-GPS or MSA A-GPS and see
> > > > > what happens.
> > > >
> > > > Sure, here are the logs:
> > > >
> > > > mmcli -m 0
> > > > ---
> > > >   General  |dbus path: 
> > > > /org/freedesktop/ModemManager1/Modem/0
> > > >|device id: 
> > > > 3722d156689e3dccd0080cdb2418e5159e13c738
> > > >   
> > > >   Hardware | manufacturer: QUALCOMM INCORPORATED
> > > >|model: LE910C1-NA
> > > >|firmware revision: 25.00.212  1  [Feb 03 2017 10:00:00]
> > > >|   carrier config: default
> > > >| h/w revision: 1
> > > >|supported: gsm-umts, lte
> > > >|  current: gsm-umts, lte
> > > >| equipment id: *
> > > >   
> > > >   System   |   device: 
> > > > /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1
> > > >|  drivers: option1, qmi_wwan
> > > >|   plugin: Telit
> > > >| primary port: cdc-wdm0
> > > >|ports: ttyUSB0 (unknown), ttyUSB1 (gps), 
> > > > ttyUSB2 (at),
> > > >|   cdc-wdm0 (qmi), wwan0 (net), ttyUSB4 
> > > > (unknown), ttyUSB3 (at)
> > > >   
> > > >   Status   | lock: sim-pin2
> > > >|   unlock retries: sim-pin (5), sim-pin2 (5), sim-puk 
> > > > (10), sim-puk2 (10)
> > > >|state: connected
> > > >|  power state: on
> > > >|  access tech: umts
> > > >|   signal quality: 57% (recent)
> > > >   
> > > >   Modes|supported: allowed: 2g; preferred: none
> > > >|   allowed: 3g; preferred: none
> > > >|   allowed: 4g; preferred: none
> > > >|   allowed: 2g, 3g; preferred: 3g
> > > >|   allowed: 2g, 3g; preferred: 2g
> > > >|   allowed: 2g, 4g; preferred: 4g
> > > >|   allowed: 2g, 4g; preferred: 2g
> > > >|   allowed: 3g, 4g; preferred: 3g
> > > >|   allowed: 3g, 4g; preferred: 4g
> > > >|   allowed: 2g, 3g, 4g; preferred: 4g
> > > >|   allowed: 2g, 3g, 4g; preferred: 3g
> > > >|   allowed: 2g, 3g, 4g; preferred: 2g
> > > >|  current: allowed: 2g, 3g, 4g; preferred: 3g
> > > >   
> > > >   Bands|supported: egsm, dcs, pcs, g850, utran-1, 
> > > > utran-4, utran-5, utran-8,
> > > >|   utran-2, eutran-2, eutran-4, 
> > > > eutran-12
> > > >|  current: egsm, dcs, pcs, g850, utran-1, 
> > > > utran-4, utran-5, utran-8,
> > > >|   utran-2, eutran-2, eutran-4, 
> > > > eutran-12
> > > >   
> > > >   IP   |supported: ipv4, ipv6, ipv4v6
> > > >   
> > > >   3GPP | imei: *
> > > >|  operator id: *
> > > >|operator name: *
> > > >| registration: home
> > > >   
> > > >   3GPP EPS | ue mode of operation: csps-1
> > > >   
> > > >   SIM  |dbus path: /org/freedesktop/ModemManager1/SIM/0
> > > >   
> > > >   Bearer   |dbus path: 
> > > > /org/freedesktop/ModemManager1/Bearer/0
> > > > ---
> > > >
> > > >
> > > > mmcli -m 0 --location-enable-gps-raw
> > > > ---
> > > >  [1588613175.107558] Setting up location sources: '3gpp-lac-ci, 
> > > > gps-raw'
> > > >  [1588613175.107665] Location '3gpp-lac-ci' gathering is already 
> > > > enabled...
> > > >  [1588613175.107700] Location 'gps-nmea' gathering is already 
> > > > disabled...
> > > >  [1588613175.107729] Location 'agps-msa' gathering is already 
> > > > 

Re: Telit LE910C1 - GPS integration

[Daniele Palmas]

Hi Aleksander and David,

Il giorno mar 5 mag 2020 alle ore 17:14 Aleksander Morgado
 ha scritto:
>
> Hey Daniele & David
>
> > > Then we need to debug why we were not able to get any LOC indication
> > > with NMEA traces in David's setup.
> >
> > > David, could you retry to setup the location using the QMI protocol
> > > (i.e. without your changes) but enabling both "nmea" and "raw"
> > > locations?
> > > Also, another test could be to enable MSB A-GPS or MSA A-GPS and see
> > > what happens.
> >
> > Sure, here are the logs:
> >
> > mmcli -m 0
> > ---
> >   General  |dbus path: /org/freedesktop/ModemManager1/Modem/0
> >|device id: 3722d156689e3dccd0080cdb2418e5159e13c738
> >   
> >   Hardware | manufacturer: QUALCOMM INCORPORATED
> >|model: LE910C1-NA
> >|firmware revision: 25.00.212  1  [Feb 03 2017 10:00:00]
> >|   carrier config: default
> >| h/w revision: 1
> >|supported: gsm-umts, lte
> >|  current: gsm-umts, lte
> >| equipment id: *
> >   
> >   System   |   device: 
> > /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1
> >|  drivers: option1, qmi_wwan
> >|   plugin: Telit
> >| primary port: cdc-wdm0
> >|ports: ttyUSB0 (unknown), ttyUSB1 (gps), 
> > ttyUSB2 (at),
> >|   cdc-wdm0 (qmi), wwan0 (net), ttyUSB4 
> > (unknown), ttyUSB3 (at)
> >   
> >   Status   | lock: sim-pin2
> >|   unlock retries: sim-pin (5), sim-pin2 (5), sim-puk (10), 
> > sim-puk2 (10)
> >|state: connected
> >|  power state: on
> >|  access tech: umts
> >|   signal quality: 57% (recent)
> >   
> >   Modes|supported: allowed: 2g; preferred: none
> >|   allowed: 3g; preferred: none
> >|   allowed: 4g; preferred: none
> >|   allowed: 2g, 3g; preferred: 3g
> >|   allowed: 2g, 3g; preferred: 2g
> >|   allowed: 2g, 4g; preferred: 4g
> >|   allowed: 2g, 4g; preferred: 2g
> >|   allowed: 3g, 4g; preferred: 3g
> >|   allowed: 3g, 4g; preferred: 4g
> >|   allowed: 2g, 3g, 4g; preferred: 4g
> >|   allowed: 2g, 3g, 4g; preferred: 3g
> >|   allowed: 2g, 3g, 4g; preferred: 2g
> >|  current: allowed: 2g, 3g, 4g; preferred: 3g
> >   
> >   Bands|supported: egsm, dcs, pcs, g850, utran-1, utran-4, 
> > utran-5, utran-8,
> >|   utran-2, eutran-2, eutran-4, eutran-12
> >|  current: egsm, dcs, pcs, g850, utran-1, utran-4, 
> > utran-5, utran-8,
> >|   utran-2, eutran-2, eutran-4, eutran-12
> >   
> >   IP   |supported: ipv4, ipv6, ipv4v6
> >   
> >   3GPP | imei: *
> >|  operator id: *
> >|operator name: *
> >| registration: home
> >   
> >   3GPP EPS | ue mode of operation: csps-1
> >   
> >   SIM  |dbus path: /org/freedesktop/ModemManager1/SIM/0
> >   
> >   Bearer   |dbus path: /org/freedesktop/ModemManager1/Bearer/0
> > ---
> >
> >
> > mmcli -m 0 --location-enable-gps-raw
> > ---
> >  [1588613175.107558] Setting up location sources: '3gpp-lac-ci, 
> > gps-raw'
> >  [1588613175.107665] Location '3gpp-lac-ci' gathering is already 
> > enabled...
> >  [1588613175.107700] Location 'gps-nmea' gathering is already 
> > disabled...
> >  [1588613175.107729] Location 'agps-msa' gathering is already 
> > disabled...
> >  [1588613175.107752] Location 'agps-msb' gathering is already 
> > disabled...
> >  [1588613175.107773] Need to enable the following location sources: 
> > 'gps-raw'
> > [/dev/cdc-wdm0] sent message...
> > << RAW:
> > <<   length = 38
> > <<   data   = 
> > 

Re: Telit LE910C1 - GPS integration

[Daniele Palmas]

Hi Aleksander and David,

Il giorno mar 5 mag 2020 alle ore 17:14 Aleksander Morgado
 ha scritto:
>
> Hey Daniele & David
>
>
> Daniele, any idea why we're not receiving NMEA traces via QMI
> indications in this case? Do you see something wrong in the sequence
> to enable the GNSS location gathering?
>

Let me check with the firmware developers.

Regards,
Daniele

> >
> > Note this was added to the udev rule for gps port with clean MM 1.12.8
> > # LE910C1 with default usb cfg
> > ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1201", ENV{.MM_USBIFNUM}=="00", 
> > ENV{ID_MM_PORT_IGNORE}="1"
> > ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1201", ENV{.MM_USBIFNUM}=="03", 
> > ENV{ID_MM_PORT_TYPE_GPS}="1"
> > ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1201", ENV{.MM_USBIFNUM}=="04", 
> > ENV{ID_MM_PORT_TYPE_AT_PRIMARY}="1"
> > ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1201", ENV{.MM_USBIFNUM}=="05", 
> > ENV{ID_MM_PORT_TYPE_AT_SECONDARY}="1"
> > ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1201", ENV{.MM_USBIFNUM}=="06", 
> > ENV{ID_MM_PORT_IGNORE}="1"
> >
>
> Not truly needed for the QMI case, as all NMEA traces should be
> received via QMI LOC indications.
>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Location of rmnet setup

[Daniele Palmas]

Hi Michal,

Il ven 9 ott 2020, 04:05 Michał Mazur  ha scritto:

> Hi Aleksander,
>
> Thank you for the reply. As you suggested I created MMPortRmnet to handle
> data port setup:
>
> https://gitlab.freedesktop.org/mkm/ModemManager/-/commit/b25310666e41a19150fe2b18ff3b7cce73f9129a
> It includes all the code that uses the rmnet library to configure devices
> but it is not probed yet.
>

Can you please post a link for the official librmnetctl code repository?

I can find many, but I'm not sure of the correct one.

Thanks,
Daniele


> Regards,
> Michal
>
>
> sob., 3 paź 2020 o 14:34 Aleksander Morgado 
> napisał(a):
>
>> Hey Michał!
>>
>> >
>> > We've decided to move the rmnet configuration to libqmi. It seems to be
>> a better place because there is already a class for QRTR control socket.
>>
>> I would suggest discussing in the public mailing list or in gitlab
>> issues this kind of thing, so that everyone can participate in the
>> discussion.
>>
>> >
>> >
>> https://gitlab.freedesktop.org/mkm/libqmi/-/commit/3e063884efd6cc217e91be4601ee3b
>> > This patch adds a new class for QRTR data port. During initialization
>> it opens an INET socket to bring up the rmnet_ipa device and uses the
>> rmnetctl library to create a virtual network device (rmnet_data0). This new
>> device will be used in ModemManager.
>>
>> How is it that the "QRTR data port" does nothing with the QRTR
>> protocol? Yes, this rmnet data port is the one that would be used for
>> data while QRTR is used for control, but I don't think libqrtr would
>> be the place to add this. From an outsider perspective, you could say
>> you need libqmi+libqrtr for control, and rmnetctl to bring up the data
>> network interface, but I wouldn't add this new object in libqrtr, as
>> it really has nothing to do with the QRTR protocol itself.
>>
>> If you ask me, ModemManager is a better place for this, e.g. a let's
>> say a MMPortRmnet object which would map the virtual network interface
>> created with rmnetctl. Oh wait, I did already suggest something like
>> this in a previous email that was never replied...
>>
>> --
>> Aleksander
>> https://aleksander.es
>> ___
>> 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
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Instantiating rmnet devices for data ports on QRTR-based modems

[Daniele Palmas]

Hi all,

Il giorno sab 17 ott 2020 alle ore 23:05 Aleksander Morgado
 ha scritto:
>
> Hey Carl,
>
> > Some ideas from me.
>
> Thanks for your comments, very much appreciated.
>
> > The discussion is based on QUALCOMM's rmnet driver and his data 
> > services.
> > We are discussing how porting these software to MM and libqmi.
> > But I think QUALLCOMM's solution is too complex, porting is 
> > impossible.
> > What we have to do is re-implementation.
> >
> > I seem we have done for "QMI based on QTRT" in libqmi.
> > For QUALCOMM's data services, there are lots of QMI library, and 
> > libqmi used a more simply solution. (in fact, if just send QMI, QTRT is 
> > also not a good idea)
>
> Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only
> way to handle the communication in certain setups?
>
> >
> > So, others part of QUALCOMM's data services and  QUALCOMM's rmnet 
> > drvier, we also can simplify.
> >
>
> I'm all for simplifying :D
>
> > Take rmnet driver for example:
> > QUALCOMM;s  rmnet driver consist of two parts.
> > 1. physic netcard part, name as 
> > rmnet_usb.c/rmnet_mhi.c/rmnet_ipa.c,, depend on the hardware interface used.
> > this driver response for transfer QMAP packet to modem.
> > 2. virtual nectar part, name as rmnet_data.c, this driver response 
> > for: rx IP packets from tcp/ip stack, and add QMAP header to IP packet, and 
> > sent to rmnet physic driver.
> >
>
> Ok, understood.
>
> > So the process can next:
> > 1. rmnet physic driver probe, create netcard 
> > rmnet_usb0/rmnet_mhi0/rmnet_ipa0, and call register_rmnet_data
> > 2. rmnet data driver create rmnet_data0
>
> Are you suggesting that there is always a virtual network interface
> created for the physical network interface? In terms of qmi_wwan, are
> you suggesting a virtual qmimux0 is always created when the physical
> wwan0 interface is exposed? What would be the benefit of doing that?
>

One of the benefits is dl throughput for high-cat modems, since
enabling data aggregation is mandatory to get the most out of the
modem.

> > 3. MM query qmap-version, ep-type, iface-id, 
> > dll_data_aggregation_max_size from rmnet physic driver
> > 4. MM send QMIWDS_ADMIN_SET_DATA_FORMAT_REQ to modem.
> > 5. MM get ul_data_aggregation_max_size from 
> > QMIWDS_ADMIN_SET_DATA_FORMAT_RESP, and send to rmnet physic driver.
>
> @Bjørn Mork @Daniele Palmas is that step 5 something we're not
> currently doing and we may need to do? Does the physical wwan
> interface truly need to know the ul_data_aggregation_max_size?
>

I can't find this WDS request, or do you mean QMI_WDA_SET_DATA_FORMAT?
Anyway, the driver is not dealing with ul values: so far I did not
receive complaints on upload performance, even with high-cat modems,
so I'm not sure this is something that should be fixed at the moment.
I'm more concerned about the dl aggregation, whose setting is still a
manual process.

> > 6. MM want to setup data call on PDN-x. MM send muxid-X to rmnet 
> > physic driver, rmnet physic driver tell rmnet data driver to create 
> > rmnet_dataX.
> >
>
> This logic you're suggesting, except for step 5 I think, is what we
> already had in mind more or less. I think we could have that done by
> ModemManager, and connection managers like NetworkManager will get
> that working automatically, but now I also fear that if we change the
> default QMI modem behavior w.r.t. which is the connected network
> interface, we may be breaking user setups out there that rely on fixed
> interface names (e.g. for iptables rules).
>
> > rmnet_dataX is not a good name, there may be rment_usb0, rment_mhi0 
> > exist at the same time, so can named as rment_usb0_X.
>
> In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And
> if you have 5 different modems, each of them instantiating muxed
> virtual interfaces, they'll just get assigned sequential interface
> names, without any reference in the interface name to which physical
> interface they're mapped to. I don't think the name of the interface
> matters much at this point, as long as we can know which virtual
> interface maps to which physical interface.
>
> E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs
> contents pointing to the physical interface:
> # ls -ltr /sys/class/net/qmimux0/lower_wwan0
> lrwxrwxrwx1 root root 0 Oct 17 20:52
> /sys/class/net/qmimux0/lower_wwan0 ->
&g

Re: Instantiating rmnet devices for data ports on QRTR-based modems

[Daniele Palmas]

Hi,

Il giorno lun 19 ott 2020 alle ore 09:57 Aleksander Morgado
 ha scritto:
>
> Hey,
>
> > > > I seem we have done for "QMI based on QTRT" in libqmi.
> > > > For QUALCOMM's data services, there are lots of QMI library,
> > > > and libqmi used a more simply solution. (in fact, if just send QMI,
> > > > QTRT is also not a good idea)
> > >
> > > Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only way 
> > > to
> > > handle the communication in certain setups?
> > [carl.yin] 1. QRTR codes is much complex than direct send QMI message via 
> > QMI channel like /dev/cdc-wdm0
> > And it is not easy to find real hardware device for the 
> > QTRT node.
> > No matter the hardware interface between AP and Qualcomm 
> > modem is USB/PCIE/SMD,
> > (SMD is for QUALCOMM inter-AP, like MDM, APQ,MSM chipset.)
> > There always have QMI channel can be used to send QMI 
> > message.
> > If use these QMI channel, very few modifies is need apply 
> > to libqmi and MM
>
> I cannot comment on this, probably @Eric Caruso has a better point of view.
>
> > > This logic you're suggesting, except for step 5 I think, is what we 
> > > already had in
> > > mind more or less. I think we could have that done by ModemManager, and
> > > connection managers like NetworkManager will get that working 
> > > automatically,
> > > but now I also fear that if we change the default QMI modem behavior 
> > > w.r.t.
> > > which is the connected network interface, we may be breaking user setups 
> > > out
> > > there that rely on fixed interface names (e.g. for iptables rules).
> > >
> > > > rmnet_dataX is not a good name, there may be rment_usb0,
> > > rment_mhi0 exist at the same time, so can named as rment_usb0_X.
> > >
> > > In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And if 
> > > you
> > > have 5 different modems, each of them instantiating muxed virtual 
> > > interfaces,
> > > they'll just get assigned sequential interface names, without any 
> > > reference in the
> > > interface name to which physical interface they're mapped to. I don't 
> > > think the
> > > name of the interface matters much at this point, as long as we can know 
> > > which
> > > virtual interface maps to which physical interface.
> > >
> > > E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs 
> > > contents
> > > pointing to the physical interface:
> > > # ls -ltr /sys/class/net/qmimux0/lower_wwan0
> > > lrwxrwxrwx1 root root 0 Oct 17 20:52
> > > /sys/class/net/qmimux0/lower_wwan0 ->
> > > ../../../pci:00/:00:16.0/usb1/1-1/1-1.2/1-1.2:1.8/net/wwan0
> > >
> > > And it adds a "upper_qmimux0" file in the physical interface sysfs 
> > > pointing to the
> > > virtual device:
> > > # ls -ltr /sys/class/net/wwan0/upper_qmimux0
> > > lrwxrwxrwx1 root root 0 Oct 17 20:53
> > > /sys/class/net/wwan0/upper_qmimux0 ->
> > > ../../../../../../../../virtual/net/qmimux0
> > >
> > > As long as we have this kind of relationship between the virtual and 
> > > physical
> > > interfaces, we're good to go, regardless of the actual naming of the 
> > > interface.
> > [carl.yin] developer can find the relationship of wwanX and qmimuxX.
> > But for the end customers, maybe it is difficult, maybe he 
> > want to setup data call on PDN-x on modem y.
> > It will be Very intuitive if we can make PDN-x to muxid-X 
> > to rmnet_modemY_X.
>
> I truly don't have a strong opinion on that, kernel devs probably have
> a better idea on what the naming should look like. Either way, it is
> true that the current kernel implementation for the muxing in qmi_wwan
> already relies on that naming mechanism, so not sure if that could be
> changed right now without breaking the API.
>

Maybe a possibility to align things is to add rmnet support to
qmi_wwan? In the past there was an attempt for this (see
https://www.mail-archive.com/netdev@vger.kernel.org/msg239867.html),
but not completed.

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es
> ___
> 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

Re: Adding Telit ME310G1-WW support

[Daniele Palmas]

Hi Aleksander,

Il giorno lun 13 lug 2020 alle ore 10:08 Aleksander Morgado
 ha scritto:
>
> Hey!
>
> > > > This particular device has a second port configuration (1bc7:1102),
> > > > which which  looks like this:
> > > >
> > > > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=atmel-ehci/3p, 480M
> > > > |__ Port 2: Dev 7, If 0, Class=Vendor Specific Class, 
> > > > Driver=option, 480M
> > > > |__ Port 2: Dev 7, If 1, Class=Vendor Specific Class, 
> > > > Driver=option, 480M
> > > > |__ Port 2: Dev 7, If 2, Class=Vendor Specific Class, 
> > > > Driver=option, 480M
> > > > |__ Port 2: Dev 7, If 3, Class=Communications, Driver=cdc_ether, 
> > > > 480M
> > > > |__ Port 2: Dev 7, If 4, Class=CDC Data, Driver=cdc_ether, 480M
> > > >
> > > > I've not been able to get the cdc_ether portion working yet, although
> > > > I am hopeful.  If both ECM and "option" serial interfaces are
> > > > available, how does ModemManager choose between them?
> > >
> > > MM doesn't have any implementation yet to handle ECM interfaces in
> > > Telit modems, but that would definitely be preferred over PPP in a
> > > TTY.
> > >
> >
> > Not sure that ECM is better than PPP for this modem, since
> > connection/disconnection requires a reboot of the modem.
> >
>
> Oh why is that? Is that a limitation of the modem firmware? Not sure I
> understood that.
>

Yes, this is by firmware design.

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Adding Telit ME310G1-WW support

[Daniele Palmas]

Hi Mark,

Il giorno lun 13 lug 2020 alle ore 15:17 Mark Deneen
 ha scritto:
>
> Daniele,
>
> > @Mark, did you check if there's a more recent firmware update than the
> > one you are using?
>
> I'm running 37.00.210-B038-P0C.21, but I'm having trouble
> understanding if any of the available firmware releases apply to the
> model number that I have.  Regardless, the firmware seems only made
> available as Windows binaries and my modem is soldered to a board with
> an ARM processor.  Is there a way to update the firmware in Linux?  I
> have used the HE910 module in the past and was able to flash firmware
> from an ARM-based Linux platform, but perhaps they do things
> differently now.
>

better reach directly Telit TS for both the things.

Thanks,
Daniele
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Adding Telit ME310G1-WW support

[Daniele Palmas]

Hi Aleksander and Mark,

Il giorno dom 12 lug 2020 alle ore 09:08 Aleksander Morgado
 ha scritto:
>
> Hey!
>
> > I've attached a patch which uses the "custom regex" feature of the
> > existing parser in order to detect PPP and say that things are good.
> > A few things to note:
> >
> > * I created the regex based on data I saw output from my modem.  At
> > best it is correct, at worst it won't do any harm.
>
> I find this regex is extremely specific to your usecase. As you said
> it may be a fix, or it may not do anything, that isn't a complete
> solution, and I think we should try to find some other way to handle
> this if possible.
>
> I find it very very weird that the modem doesn't reply a CONNECT
> response after the ATD, that would be a very weird firmware bug! Maybe
> the TTY we're using for connection isn't the correct one? @Daniele
> Palmas @Carlo Lobrano Do you guys have any idea of why this may be
> happening in the ME310?
>

I recently used a ME910G1, which should be the same as the 310,
besides the form factor, but I do not remember such an issue. I'm
going to check again in the first days of the week.

@Mark, did you check if there's a more recent firmware update than the
one you are using?

> > * Ideally I would only use this for the ME310 modem, but I didn't see
> > a way to do that in the plugin.  I'm certainly open to suggestions.
>
> If we needed a quirk like this one, we could flag via udev with a new udev 
> tag.
>
> > This particular device has a second port configuration (1bc7:1102),
> > which which  looks like this:
> >
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=atmel-ehci/3p, 480M
> > |__ Port 2: Dev 7, If 0, Class=Vendor Specific Class, Driver=option, 
> > 480M
> > |__ Port 2: Dev 7, If 1, Class=Vendor Specific Class, Driver=option, 
> > 480M
> > |__ Port 2: Dev 7, If 2, Class=Vendor Specific Class, Driver=option, 
> > 480M
> > |__ Port 2: Dev 7, If 3, Class=Communications, Driver=cdc_ether, 480M
> > |__ Port 2: Dev 7, If 4, Class=CDC Data, Driver=cdc_ether, 480M
> >
> > I've not been able to get the cdc_ether portion working yet, although
> > I am hopeful.  If both ECM and "option" serial interfaces are
> > available, how does ModemManager choose between them?
>
> MM doesn't have any implementation yet to handle ECM interfaces in
> Telit modems, but that would definitely be preferred over PPP in a
> TTY.
>

Not sure that ECM is better than PPP for this modem, since
connection/disconnection requires a reboot of the modem.

> Regarding the patch itself, you shouldn't add the regex to the primary
> port. You should run mm_base_modem_peek_data_ports() and add the regex
> to all data ports that are TTYs (MM_IS_PORT_SERIAL()). But as said, I
> would totally prefer to have this solved somehow without needing to
> detect the PPP stream, because it is pppd the only one who should be
> touching that (MM yields the control of the TTY to pppd as soon as the
> port is in data mode).
>
> --
> Aleksander
> https://aleksander.es
> ___
> 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

Re: problems with QMI dual stack connections from MM - works with qmicli

[Daniele Palmas]

Hi Bjørn,

Il giorno lun 26 apr 2021 alle ore 18:23 Bjørn Mork  ha scritto:
>
> Bjørn Mork  writes:
>
> > Sorry, i do not think these issues are related to ModemManager at all.
>
> This is a test from freshly booted modem, MM not running:
>
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --device-open-sync 
> --wda-set-data-format=ep-type=hsusb,ep-iface-number=4,link-layer-protocol=raw-ip,ul-protocol=qmapv5,dl-protocol=qmapv5,dl-max-datagrams=32,dl-datagram-max-size=31744
> [/dev/cdc-wdm0] Successfully set data format
> QoS flow header: no
> Link layer protocol: 'raw-ip'
>Uplink data aggregation protocol: 'qmapv5'
>  Downlink data aggregation protocol: 'qmapv5'
>   NDP signature: '0'
> Downlink data aggregation max datagrams: '32'
>  Downlink data aggregation max size: '31744'
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=4
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '15'
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --client-cid=15 --wds-set-ip-family=4
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '15'
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --client-cid=15 --wds-start-network=apn=telenor.smart,ip-type=4
> [/dev/cdc-wdm0] Network started
> Packet data handle: '3891631616'
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '15'
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=4
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '16'
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --client-cid=16 --wds-set-ip-family=6
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '16'
> root@finn:~#  qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --client-cid=16 --wds-start-network=apn=telenor.smart,ip-type=6
> [/dev/cdc-wdm0] Network started
> Packet data handle: '3891309184'
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '16'
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --wds-bind-mux-data-port=mux-id=2,ep-type=hsusb,ep-iface-number=4
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '17'
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --client-cid=17 --wds-set-ip-family=4
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '17'
> root@finn:~# qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid 
> --client-cid=17 --wds-start-network=apn=telenor,ip-type=4
> error: couldn't start network: QMI protocol error (14): 'CallFailed'
> call end reason (1): generic-unspecified
> verbose call end reason (2,236): [internal] call-already-present
> [/dev/cdc-wdm0] Client ID not released:
> Service: 'wds'
> CID: '17'

I guess the modem you are using is based on SDX55.

Testing with a modem based on the same chipset, I can replicate your
issue with just two ipv4 connections:

$ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --device-open-sync
--wda-set-data-format=ep-type=hsusb,ep-iface-number=2,link-layer-protocol=raw-ip,ul-protocol=qmapv5,dl-protocol=qmapv5,dl-max-datagrams=32,dl-datagram-max-size=31744
[/dev/cdc-wdm0] Successfully set data format
QoS flow header: no
Link layer protocol: 'raw-ip'
   Uplink data aggregation protocol: 'qmapv5'
 Downlink data aggregation protocol: 'qmapv5'
  NDP signature: '0'
Downlink data aggregation max datagrams: '32'
 Downlink data aggregation max size: '16384'

$ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid
--wds-bind-mux-data-port=mux-id=1,ep-type=hsusb,ep-iface-number=2
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '17'

$ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid
--client-cid=17 --wds-set-ip-family=4
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '17'

$ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid
--client-cid=17 --wds-start-network=apn=ibox.tim.it,ip-type=4
[/dev/cdc-wdm0] Network started
Packet data handle: '4120009568'
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '17'

$ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid
--wds-bind-mux-data-port=mux-id=2,ep-type=hsusb,ep-iface-number=2
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '18'

$ sudo ./src/qmicli/qmicli -p -d /dev/cdc-wdm0 --client-no-release-cid
--client-cid=18 --wds-set-ip-family=4
[/dev/cdc-wdm0] Client ID not released:

Re: [RFC] Keeping send-delay for all RS232 ttys only?

[Daniele Palmas]

Hi Aleksander,

Il giorno mar 4 mag 2021 alle ore 00:34 Aleksander Morgado
 ha scritto:
>
> Hey Dan & all,
>
> The send-delay property allows us to send the characters in an AT
> command one by one, with some delay in between them. Right now the
> default configuration of the send-delay property is 100ms unless
> explicitly disabled, as it's done in several plugins.
>
> I'm wondering whether it makes sense to keep this logic as it is, or
> change the defaults a bit; e.g. we could keep the logic for plain
> RS232 modems but assume that all USB/PCI modems will be fine without
> the send delay.
>
> What do you all think?
>

I agree, USB modems should be working fine without the send delay.

> P.S. this comes in the context of this bug, which to me is due to a
> firmware issue or limitation, but anyway:
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/354
>

Odd, I did not see this with FN980: wondering if this is something
related to a specific Qualcomm baseline...

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es
> ___
> 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

Re: [RFC] QMAP data aggregation support in ModemManager

[Daniele Palmas]

Hi Aleksander,

Il giorno sab 27 feb 2021 alle ore 10:47 Aleksander Morgado
 ha scritto:
>
> Hey
>
> > > I've been working on updating ModemManager to allow setting up QMAP
> > > data aggregated links transparently, either with qmi_wwan
> > > add_mux/del_mux or with qmi_wwan+rmnet (pass_through=Y).
> > >
> > > See 
> > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/447
> > >
> > > For the qmi_wwan+rmnet logic this MR in libqmi to disable the MAP
> > > checksum seems to be required, I don't fully understand why yet:
> > > https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/215
> > >
> > > For the qmi_wwan add_mux/del_mux logic, it works quite well without
> > > any additional thing required, with the limitation of max 4 links for
> > > now, because we cannot create new links once the master interface is
> > > already up (so we always precreate 4 link interfaces upon the first
> > > connection attempt). The MTU of the master link is set to the max data
> > > aggregation size reported by the modem in this case.
> > >
> > > What do you think of these changes? For now, I've made it the default
> > > to "multiplex=request" when setting up a connection, so that you can
> > > directly use e.g. NetworkManager to bring up the connection without
> > > any single change in NetworkManager itself. That may change later on,
> > > and we may leave the default as "multiplex=none" instead; comments
> > > welcome on that as well.
> > >
> > > Anyone wants to give all this a try? Comments?
> >
> > Great work Aleksander, I'll be happy to test this (probably next week).
> > Aggregation offered by QMAP is especially useful for reaching max 5G 
> > throughput.
> >
>
> Please let me know what your tests go!
>

Going to test me too, hope to have some results by the end of next week.

Thanks a lot for having done this!

Regards,
Daniele

> > I've heard that some modems support checksum offload, and it seems
> > already supported on rmnet kernel side (MAPv5). Not sure however how
> > it needs to be configured for the modem side, maybe via a QMI
> > wda_set_data_format parameter. On high throughput, the CPU spends
> > substantial time on checksumming, so it could be useful to have that
> > at some point.
> >
>
> I have no idea how that is configured in the modem side either; maybe
> we're indeed missing some parameter in the WDA Set Data Format
> message, because as soon as I enable MAPv4 the traffic is broken in my
> tests: 
> https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/215.
> I have seen the MAPv5 patches in the LKML, but haven't tried that
> either.
>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ANN: ModemManager 1.18 released

[Daniele Palmas]

Hi Aleksander,

Il giorno gio 9 set 2021 alle ore 11:28 Aleksander Morgado
 ha scritto:
>
> Hey hey,
>
> This is a new major release of ModemManager, which will be the base for the 
> 1.18.x stable series (the new "mm-1-18" branch in git). The release has been 
> tagged as "1.18.0".
>
> This is probably the biggest major release we have done since 1.0, and that 
> is thanks to a lot of people!

Most of all, thanks to you for your great work and continued effort on this!

Regards,
Daniele

Re: [RFC] No multiplexing by default in MM 1.18

[Daniele Palmas]

Hi Aleksander,

Il giorno lun 2 ago 2021 alle ore 16:41 Aleksander Morgado <
aleksan...@aleksander.es> ha scritto:

> Hey all,
>
> I've been testing with all my modems for the next 1.18 release, and
> for the QMI and MBIM ones I've done tests with and without
> multiplexing support (i.e. connecting normally as we did until now,
> and also connecting with multiplexing enabled).
>
> All the QMI modems I have tested with have worked fine. If QMAP wasn't
> supported by the modem and we were requesting multiplexing, it would
> automatically just fallback to no multiplexing (802.3 or plain
> raw-ip), and that was it.
>
> Most of the MBIM modems I have tested with have worked fine as well,
> with the exception of the Netgear AC340U, which would reply with
> "InvalidParameters" if we were attempting to connect any session with
> id != 0. All the other modems have been able to correctly setup
> multiplexing when requested without issues.
>
> Even if the tests have been quite satisfactory overall (I've tested
> >60 different modems in the past month), I think that for 1.18 we
> should not enable multiplexing by default (except for IPA), and still
> leave it as a requirement from the user at connect time. So, if the
> user wants to setup a connection with multiplexing enabled, it should
> pass either "multiplex=requested" or "multiplex=required" in the
> connection settings explicitly
>
>
I think it makes sense.

Thanks,
Daniele


> I've also updated the daemon to have a "--test-multiplex-requested"
> option, so that if given, the default would be back to attempt to
> enable multiplexing whenever possible.
>
> The main reason for this decision is that the network interface that
> gets connected if multiplexing is enabled would change between 1.16
> and 1.18, because with multiplexing we're connecting an ephemeral
> network link that we have created during runtime  (e.g. for a QMI
> modem that had a connected net interface named wwan0 in 1.16, the
> connected net interface in 1.18 would be named qmapmux0.0 instead).
>
> This connected net interface name change wasn't an issue for
> NetworkManager or standard distributions, but it would have been a
> major change for every other custom system using ModemManager, if e.g.
> custom firewall or routing rules were configured based on the network
> interface name and such. I think we should provide more information
> about the feature to system integrators, and give some more time for
> the feature to be used and tested, before discussing again whether it
> should be the default or not in 1.20.
>
> The MR that includes the changes to update the multiplexing default is
> this one, including some other related fixes:
>
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/598
>
> Comments welcome!
>
> --
> Aleksander
> https://aleksander.es
>

Re: LN920: MBIM Bands not shown (MM 1.18.2)

[Daniele Palmas]

Hi Amol,

Il giorno lun 11 ott 2021 alle ore 15:03 Amol Lad  ha scritto:
>
> Hi Daniele,
>
>
>
> I’m patched my MM 1.18.2 with your MR (LN920 Initial Support) and testing 
> LN920 in MBIM mode. I’m noticing that the “supported” and “current” bands are 
> not shown in “mmcli -m 0” output and below error is seen in the logs:
>
>
>
>   [modem0] couldn't load supported bands: Could not find 4G band flags 
> from response
>
>
>
> Any suggestion what could be going wrong?
>

I think this is coming from the failure of the regex for collecting
the supported bands with #BND=?

It should be fixed for LN920 output.

Regards,
Daniele

>
>
> mmcli -m 0 output in both MBIM and QMI is below:
>
>
>
>
>
> MBIM
>
> 
>
>
>
> # mmcli -m 0
>
>   --
>
>   General  |   path: /org/freedesktop/ModemManager1/Modem/0
>
>|  device id: 168c2aa5755860bee3694899a635af0df25e7fcf
>
>   --
>
>   Hardware |   manufacturer: Telit Wireless Solutions
>
>|  model: LN920
>
>|  firmware revision: SDX12.LE.1.0-00085-NBOOT.NEFS.
>
>| carrier config: default
>
>|   h/w revision: LN920A12-WW
>
>|  supported: gsm-umts, lte
>
>|current: gsm-umts, lte
>
>|   equipment id: 354175759991229
>
>   --
>
>   System   | device: 
> /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1
>
>|drivers: cdc_mbim, option1
>
>| plugin: telit
>
>|   primary port: cdc-wdm0
>
>|  ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), 
> ttyUSB1 (gps),
>
>| ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 
> (ignored), wwan0 (net)
>
>   --
>
>   Numbers  |own: 9108813566
>
>   --
>
>   Status   | unlock retries: sim-pin2 (3)
>
>|  state: connected
>
>|power state: on
>
>|access tech: lte
>
>| signal quality: 12% (recent)
>
>   --
>
>   Modes|  supported: allowed: 3g; preferred: none
>
>| allowed: 4g; preferred: none
>
>| allowed: 3g, 4g; preferred: none
>
>|current: allowed: 4g; preferred: none
>
>   --
>
>   IP   |  supported: ipv4, ipv6, ipv4v6
>
>   --
>
>   3GPP |   imei: 354175759991229
>
>|  enabled locks: fixed-dialing
>
>|operator id: 40445
>
>|  operator name: airtel
>
>|   registration: home
>
>   --
>
>   3GPP EPS |   ue mode of operation: csps-2
>
>|initial bearer path: /org/freedesktop/ModemManager1/Bearer/0
>
>| initial bearer ip type: ipv4v6
>
>   --
>
>   SIM  |   primary sim path: /org/freedesktop/ModemManager1/SIM/0
>
>| sim slot paths: slot 1: 
> /org/freedesktop/ModemManager1/SIM/0 (active)
>
>| slot 2: 
> /org/freedesktop/ModemManager1/SIM/1
>
>   --
>
>   Bearer   |  paths: /org/freedesktop/ModemManager1/Bearer/1
>
>
>
>
>
> QMI
>
> ---
>
>
>
>   --
>
>   General  |   path: /org/freedesktop/ModemManager1/Modem/0
>
>|  device id: 5c1922b03727107842603eccdea2bb4cd26436f5
>
>   --
>
>   Hardware |   manufacturer: Telit
>
>|  model: LN920A12-WW
>
>|  firmware revision: M0L.00-A006
>
>| carrier config: default
>
>|   h/w revision: 10001
>
>|  supported: gsm-umts, lte
>
>|current: gsm-umts, lte
>
>|   equipment id: 354175759991229
>
>   --
>
>   System   | device: 
> /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1
>
>|drivers: option1, qmi_wwan
>
>| plugin: telit
>
>|   primary port: cdc-wdm0
>
>|  ports: cdc-wdm0 (qmi), ttyUSB0 (ignored), 
> ttyUSB1 (gps),
>
>| ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 
> (ignored), wwan0 (net)
>
>   --
>
>   Numbers  |own: 9108813566
>
>   

Re: Telit LN920 Support

[Daniele Palmas]

Hi Amol,

Il giorno ven 8 ott 2021 alle ore 10:18 Amol Lad  ha scritto:
>
> Hi,
>
> LN920 is a new modem from Telit. Any suggestions, how can I add compositions 
> rules for this modem in plugins/77-mm-telit-port-types.rules?
>
> lsusb output is available here: 
> https://www.spinics.net/lists/linux-usb/msg216555.html
>
> The USB compositions are mentioned as below:
>
> 0x1060: DIAG + ADB + RmNet + NMEA + MODEM + MODEM + AUX
> 0x1061: DIAG + ADB + MBIM + NMEA + MODEM + MODEM + AUX
>
> Please advise.

I can take care of this, and will provide a MR soon.

Regards,
Daniele

>
> Thanks
>

Re: LN920: MBIM Bands not shown (MM 1.18.2)

[Daniele Palmas]

Il giorno lun 11 ott 2021 alle ore 18:06 Amol Lad  ha scritto:
>
> LIBQMI_WITH_MBIM_QMUX is enabled in libqmi and qmicli reports ok. It seems 
> for some reasons modemmanager is not able to read out the bands. Any input 
> regarding this will be helpful.
>

Currently Telit mbim plugin uses just AT commands for retrieving
bands: maybe a possible improvement could be to use the qmi requests
when supported by the modem and available in the build. Added on my
TODO list...

Anyway, it would be better also to fix #BND=? management for those
setups where qmi is not used.

Regards,
Daniele

>
>
> # qmicli -d /dev/cdc-wdm0 -p --dms-get-band-capabilities
>
> [/dev/cdc-wdm0] Device band capabilities retrieved:
>
> Bands: 'wcdma-2100, wcdma-pcs-1900, wcdma-dcs-1800, wcdma-1700-us, 
> wcdma-850-us, wcdma-800, wcdma-900, wcdma-1700-japan, wcdma-850-japan'
>
> LTE bands: '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 
> 28, 29, 30, 38, 39, 40, 41, 42, 43'
>
> LTE bands (extended): '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 
> 20, 25, 26, 28, 29, 30, 38, 39, 40, 41, 42, 43, 48, 66, 71'
>
>
>
> Thanks
>
> Amol
>
>
>
> From: Amol Lad
> Sent: Monday, 11 October 2021 6:34 PM
> To: 'Daniele Palmas' ; 'ModemManager (development)' 
> 
> Subject: LN920: MBIM Bands not shown (MM 1.18.2)
>
>
>
> Hi Daniele,
>
>
>
> I’m patched my MM 1.18.2 with your MR (LN920 Initial Support) and testing 
> LN920 in MBIM mode. I’m noticing that the “supported” and “current” bands are 
> not shown in “mmcli -m 0” output and below error is seen in the logs:
>
>
>
>   [modem0] couldn't load supported bands: Could not find 4G band flags 
> from response
>
>
>
> Any suggestion what could be going wrong?
>
>
>
> mmcli -m 0 output in both MBIM and QMI is below:
>
>
>
>
>
> MBIM
>
> 
>
>
>
> # mmcli -m 0
>
>   --
>
>   General  |   path: /org/freedesktop/ModemManager1/Modem/0
>
>|  device id: 168c2aa5755860bee3694899a635af0df25e7fcf
>
>   --
>
>   Hardware |   manufacturer: Telit Wireless Solutions
>
>|  model: LN920
>
>|  firmware revision: SDX12.LE.1.0-00085-NBOOT.NEFS.
>
>| carrier config: default
>
>|   h/w revision: LN920A12-WW
>
>|  supported: gsm-umts, lte
>
>|current: gsm-umts, lte
>
>|   equipment id: 354175759991229
>
>   --
>
>   System   | device: 
> /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1
>
>|drivers: cdc_mbim, option1
>
>| plugin: telit
>
>|   primary port: cdc-wdm0
>
>|  ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), 
> ttyUSB1 (gps),
>
>| ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 
> (ignored), wwan0 (net)
>
>   --
>
>   Numbers  |own: 9108813566
>
>   --
>
>   Status   | unlock retries: sim-pin2 (3)
>
>|  state: connected
>
>|power state: on
>
>|access tech: lte
>
>| signal quality: 12% (recent)
>
>   --
>
>   Modes|  supported: allowed: 3g; preferred: none
>
>| allowed: 4g; preferred: none
>
>| allowed: 3g, 4g; preferred: none
>
>|current: allowed: 4g; preferred: none
>
>   --
>
>   IP   |  supported: ipv4, ipv6, ipv4v6
>
>   --
>
>   3GPP |   imei: 354175759991229
>
>|  enabled locks: fixed-dialing
>
>|operator id: 40445
>
>|  operator name: airtel
>
>|   registration: home
>
>   --
>
>   3GPP EPS |   ue mode of operation: csps-2
>
>|initial bearer path: /org/freedesktop/ModemManager1/Bearer/0
>
>| initial bearer ip type: ipv4v6
>
>   --
>
>   SIM  |   primary sim path: /org/freedesktop/ModemManager1/SIM/0
>
>

Re: LN920: MBIM Bands not shown (MM 1.18.2)

[Daniele Palmas]

Il giorno mar 12 ott 2021 alle ore 14:26 Amol Lad  ha scritto:
>
>
> > Anyway, it would be better also to fix #BND=? management for those
> > setups where qmi is not used.
> >
>
> I've started on this and shall submit a MR in a day or two..
>

Thanks! Meanwhile I'm going to look at the qmi way.

Regards,
Daniele

>
> 
> The information in this email communication (inclusive of attachments) is 
> confidential to 4RF Limited and the intended recipient(s). If you are not the 
> intended recipient(s), please note that any use, disclosure, distribution or 
> copying of this information or any part thereof is strictly prohibited and 
> that the author accepts no liability for the consequences of any action taken 
> on the basis of the information provided. If you have received this email in 
> error, please notify the sender immediately by return email and then delete 
> all instances of this email from your system. 4RF Limited will not accept 
> responsibility for any consequences associated with the use of this email 
> (including, but not limited to, damages sustained as a result of any viruses 
> and/or any action or lack of action taken in reliance on it).

Re: mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]

[Daniele Palmas]

Hi Aleksander and Amol,

Il giorno mar 30 nov 2021 alle ore 09:54 Aleksander Morgado
 ha scritto:
>
> If this works for you in MBIM I guess it's because the AT commands to
> change bands using the Telit shared utils do wait for the band change
> to take effect before going on. Maybe @Daniele Palmas or @Carlo
> Lobrano can confirm if this is the case?
>

The #BND command returning OK does not guarantee that the modem is
actually registered, but just that the bands have been switched.

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es

Re: How to trace the communication with the modem?

[Daniele Palmas]

Hi Juan,

Il giorno mar 23 nov 2021 alle ore 11:03 Aleksander Morgado
 ha scritto:
>
> Hey,
>
> >
> > I am trying to debug the reset sequence of my modem (I've posted today
> > a separate message about this).
> >
> > I was wondering if there is a way to trace the communication between
> > MM and the device, or perhaps between libqmi or the device to output
> > the content and translation of the QMI messages (or whatever is used
> > to talk to the modem)?
> >
>
> Yes, you can enable MM debug logs and have everything you need, see:
> https://modemmanager.org/docs/modemmanager/debugging/
>

If you are unable to have debug logs for a reason or another, you can
also collect an usbmon trace and use the proper dissector with
wireshark.

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es

Re: Telit LN920: Incorrect Network Time Reported

[Daniele Palmas]

Hi Amol,

Il giorno ven 5 nov 2021 alle ore 04:12 Amol Lad  ha scritto:
>
> Hi,
>
> We're not getting network time using mmcli -time command. I'm not sure if it 
> is something specific to my setup or an issue. However, I do get correct 
> network time when using Sierra modem with the same SIM card
>
> (I'm using MM 1.18.2 release)
>
> Please advise

Which PID are you using?

Can you please also provide MM debug logs?

Regards,
Daniele

> Amol
>
> # mmcli -m 0 --time
>   ---
>   Time | current: 1980-01-06T05:46:43+05:30
>   ---
>   Timezone | current: 330
>

Re: Telit LN920: Incorrect Network Time Reported

[Daniele Palmas]

Hi Amol,

Il giorno sab 6 nov 2021 alle ore 06:01 Amol Lad  ha scritto:
>
> Hi Daniele,
>
> I'm using PID 1061 (MBIM). I did some investigation and found that if I set 
> AT#NITZ=15,1 then times are correctly reported. I'm now not recalling what 
> was #NITZ? before I changed it.
>
> Please let me know if this information is sufficient. If not, I'll get debug 
> logs and send across
>

that #NITZ values enable automatic date/time update (other than
setting the format of the #NITZ unsolicited, that should not be
important since there's no #NITZ unsolicited management in Telit
plugin).

Its default should be #NITZ=7,0 (meaning automatic update already enabled).

Is it possible that, for some reason, your modem had automatic update disabled?

Regards,
Daniele

> Thanks
> Amol
>
> -Original Message-
> From: Daniele Palmas 
> Sent: Saturday, 6 November 2021 12:12 AM
> To: Amol Lad 
> Cc: ModemManager (development) 
> Subject: Re: Telit LN920: Incorrect Network Time Reported
>
> Hi Amol,
>
> Il giorno ven 5 nov 2021 alle ore 04:12 Amol Lad  ha 
> scritto:
> >
> > Hi,
> >
> > We're not getting network time using mmcli -time command. I'm not sure if 
> > it is something specific to my setup or an issue. However, I do get correct 
> > network time when using Sierra modem with the same SIM card
> >
> > (I'm using MM 1.18.2 release)
> >
> > Please advise
>
> Which PID are you using?
>
> Can you please also provide MM debug logs?
>
> Regards,
> Daniele
>
> > Amol
> >
> > # mmcli -m 0 --time
> >   ---
> >   Time | current: 1980-01-06T05:46:43+05:30
> >   ---
> >   Timezone | current: 330
> >
> 
> The information in this email communication (inclusive of attachments) is 
> confidential to 4RF Limited and the intended recipient(s). If you are not the 
> intended recipient(s), please note that any use, disclosure, distribution or 
> copying of this information or any part thereof is strictly prohibited and 
> that the author accepts no liability for the consequences of any action taken 
> on the basis of the information provided. If you have received this email in 
> error, please notify the sender immediately by return email and then delete 
> all instances of this email from your system. 4RF Limited will not accept 
> responsibility for any consequences associated with the use of this email 
> (including, but not limited to, damages sustained as a result of any viruses 
> and/or any action or lack of action taken in reliance on it).

Re: Question about 3gpp-profile-manager to select proper PDP context ID

[Daniele Palmas]

Hi Aleksander and Carsten,

Il giorno sab 12 feb 2022 alle ore 01:02 Aleksander Morgado
 ha scritto:
>
> Hey,
>
> >
> > I'm struggling to connect to a private Vodafone APN using MM and NM.
> >
> > Modem Telit LE910-EU1 (MBIM)
> > ModemManager 1.18.6
> > libmbim 1.18.4
> > libqmi 1.30.2
> > NetworkManager 1.22.10
> >
> > My problem is, that the bearer gets connected, but not assigned an IP 
> > address.
> > To make it work, I was told to use PDP context ID 3 instead of 1 for this 
> > private APN.
> >
>
> Daniele, Carlo, would you know why CID 3 is so important to make this work?

It could be an Intel quirk (not the first one), but to be more precise
I would need additional details that I can gather only talking to
Telit owner of the support ticket.

Carsten, if you are interested to further investigate this please
privately send me the ticket number, subject of the case and name of
the owner.

Regards,
Daniele

>
> Could it be that is the default context for the initial defaut EPS
> bearer settings?
> Carsten, could you try to setup the APN settings you require with
> --3gpp-set-initial-eps-bearer-settings instead?
>
> E.g. mmcli -m a
> --3gpp-set-initial-eps-bearer-settings="apn=apn.vodafone.de,ip-type=ipv4,allowed-auth=pap,user=abc,password=def"
>
> If that doesn't work, you can always reset them with
> --3gpp-set-initial-eps-bearer-settings=""
>
> > When searching the internet, I've found this older thread about selecting a 
> > CID.
> > https://lists.freedesktop.org/archives/modemmanager-devel/2021-February/008420.html
> >
> > With MR 179 merged, this feature should be available now.
> > Unfortunately, the documentation about 3gpp-profile-management is a little 
> > bit
> > poor and mmcli --help-3gpp-profile-manager leaves me with some questions.
> >
> > Is the 3gpp-profile-manager 'profile-id' corresponding with the PDP context 
> > ID (CID)
> > which can be set by AT+CGDCONT?
> >
>
> At least that is what we try, yes. We're a bit limited here to what
> the actual protocol allows us to do, but IIIRC, whenever possible, the
> profile id is equal to the cid in +CGDCONT.I
>
> > From the merge request discussion, I've noticed, that one cannot specify a 
> > specific
> > profile-id when creating a new profile.
> > Do I have to create empty profiles until getting to the profile ID to use?
> >
>
> Yeah, this is a limitation in the generic QMI services I think, which
> we inherited in our API. Sierra Wireless has its own QMI service
> additions to provide a method that allows creating profiles with a
> specific ID, but those are not generic.
>
> > For instance:
> >
> > root@dev:~# mmcli -m 0 --3gpp-profile-manager-set=""
> >   ---
> >   3GPP profile manager | set: profile-id: 1
> >|  apn-type: default
> > root@dev:~# mmcli -m 0 --3gpp-profile-manager-set=""
> >   ---
> >   3GPP profile manager | set: profile-id: 2
> >|  apn-type: default
>
> Yes. It's a bit of a hack if you're looking to update a specific CID,
> but should work. As long as you want to edit a CID with a low number
> :)
>
> > root@dev:~# mmcli -m 0 
> > --3gpp-profile-manager-set="apn=apn.vodafone.de,ip-type=ipv4,allowed-auth=pap,user=abc,password=def"
> > error: couldn't set profile: 
> > 'GDBus.Error:org.freedesktop.libmbim.Error.Core.InvalidMessage: Couldn't 
> > validate update of profile '3': cannot read string data (6 bytes) (274 < 
> > 278)'
> >
>
> Oh, that's an error deep in the MBIM protocol. Could be a bug in the
> message format, or a malformed response sent by the module (I would
> bet on the latter ). Can you gather ModemManager *debug* logs while
> you run that operation? See
> https://modemmanager.org/docs/modemmanager/debugging/
>
> > I wonder, what are the correct options to be passed to 
> > 3gpp-profile-manager-set?
> > My first assumption is to use the same options as for create-bearer.
> >
> > After deleting all profiles, I can use the same settings
> > for profile 1 and 2 with success, but for profile 3 it fails.
> >
> > root@dev:~# mmcli -m 0 --3gpp-profile-manager-delete=3
> > successfully deleted the profile
> > root@dev:~# mmcli -m 0 --3gpp-profile-manager-delete=2
> > successfully deleted the profile
> > root@dev:~# mmcli -m 0 --3gpp-profile-manager-delete=1
> > successfully deleted the profile
> > root@dev:~# mmcli -m 0 
> > --3gpp-profile-manager-set="apn=apn.vodafone.de,ip-type=ipv4,allowed-auth=pap,user=abc,password=def"
> >   ---
> >   3GPP profile manager | set: profile-id: 1
> >|  apn: apn.vodafone.de
> >|  allowed-auth: pap
> >|  user: abc
> >|  password: d
> >|  apn-type: default
> >
> > Why are the last two characters of the given password "def" not shown?
> > I've tried with password='def' (in single quotes), but 

Re: Telit FN990 Support in ModemManager

[Daniele Palmas]

Hi Amol,

Il giorno lun 25 lug 2022 alle ore 07:34 Amol Lad  ha scritto:
>
> Hi Daniele,
>
>
>
> Can we use latest MM 1.18.10 release to test Telit FN990 (USB 3.1 host 
> interface) or we should use git main? Is this chip now fully supported in MM?
>

I've been testing FN990 through main, never tried with the stable
releases. My tests were mainly focused on the PCIe setup, not USB, but
I think it's probably usable also with 1.18.10, since I don't remember
any relevant patch mandatory for that.

I still have to send the MR for adding the port hints, this is
something I plan to do in the very next days.

Regards,
Daniele

>
>
> Thanks
>
> Amol
>
>
>
>
>
> 
> The information in this email communication (inclusive of attachments) is 
> confidential to 4RF Limited and the intended recipient(s). If you are not the 
> intended recipient(s), please note that any use, disclosure, distribution or 
> copying of this information or any part thereof is strictly prohibited and 
> that the author accepts no liability for the consequences of any action taken 
> on the basis of the information provided. If you have received this email in 
> error, please notify the sender immediately by return email and then delete 
> all instances of this email from your system. 4RF Limited will not accept 
> responsibility for any consequences associated with the use of this email 
> (including, but not limited to, damages sustained as a result of any viruses 
> and/or any action or lack of action taken in reliance on it).

Re: unexpected pdp ctx deactivation

[Daniele Palmas]

Hi Alexey,

Il giorno mer 31 ago 2022 alle ore 14:43 Alexey Orishko
 ha scritto:
>
> Hi,
>
> I'm implementing ecm support in telit plugin (baseline: latest main).

if it's not a reserved piece of information, which Telit model are you using?

Regards,
Daniele

> Somehow modem goes in connect-disconnect loop with a few seconds in between.
> I'm trying to identify a reason for disconnect and related issues in MM debug 
> log.
>
> Q1. Is a negative value in profile_id (and eventually in 
> index_field_value_str) a legal one?
> Does a negative value mean uninitialized data in profile context? Coz CGACT 
> output has always positive ctx index:
> AT+CGACT?
> +CGACT: 1,1
> +CGACT: 3,0
>
> ModemManager[]:  [1661944714.481355] [modem0] set profile state (3/8): 
> select profile (best)
> ModemManager[]:  [1661944714.481370] [modem0] found exact context at 
> profile 1
> ModemManager[]:  [1661944714.481375] [modem0] reusing profile '1'
> ModemManager[]:  [1661944714.481379] [modem0] set profile state (4/8): 
> check activated profile
> ModemManager[]:  [1661944714.481390] [modem0] checking if profile with 
> id '1' is already activated...
> ModemManager[]:  [1661944714.481402] [ttyUSB1/at] device open count is 
> 4 (open)
> ModemManager[]:  [1661944714.481418] [ttyUSB1/at] device open count is 
> 3 (close)
> ModemManager[]:  [1661944714.481436] [ttyUSB1/at] --> 'AT+CGACT?'
> ModemManager[]:  [1661944714.518369] [ttyUSB1/at] <-- '+CGACT: 
> 1,1+CGACT: 3,0OK'
> ModemManager[]:  [1661944714.518463] [modem0] profile '-1' is activated
> ModemManager[]:  [1661944714.518479] [modem0] set profile state (5/8): 
> deactivate profile
> ModemManager[]:  [1661944714.518488] [modem0] deactivating profile 
> with id '1'...
> ModemManager[]:  [1661944714.518502] [ttyUSB1/at] device open count is 
> 4 (open)
> ModemManager[]:  [1661944714.518519] [ttyUSB1/at] device open count is 
> 3 (close)
> ModemManager[]:  [1661944714.518540] [ttyUSB1/at] --> 
> 'AT+CGACT=0,1'
> ModemManager[]:  [1661944714.561517] [ttyUSB1/at] <-- 
> 'OK'
> ModemManager[]:  [1661944714.561599] [modem0] deactivated profile '-1'
> ModemManager[]:  [1661944714.561610] [modem0] set profile state (6/8): 
> profile already stored
> ModemManager[]:  [1661944714.561616] [modem0] set profile state (8/8): 
> all done
> ModemManager[]:  [1661944714.561639] [modem0/bearer0] (shared-telit) 
> ECM: selecting NW interface as a data port
> ModemManager[]:  [1661944714.561664] [ttyUSB1/at] device open count is 
> 2 (close)
> ModemManager[]:  [1661944714.561700] [modem0/wwan0/net] port now 
> connected
> ModemManager[]:  [1661944714.561707] [modem0/bearer0] connected
> ModemManager[]:   [1661944714.561776] [modem0] state changed 
> (connecting -> connected)
> ModemManager[]:   [1661944714.562088] [modem0] simple connect state 
> (10/10): all done
> ModemManager[]:  [1661944730.307060] [modem0] user request to 
> disconnect modem (all bearers)
>
>
> Q2: Since no mmcli or any other human input was used, what the phrase "user 
> request to disconnect modem" really mean?
> Could internal MM logic be considered as "user input"?
>
> Q3. Will MM always tear down existing pdp context instead of reusing it? 
> (even if all parameters are the same)
> Q4: If answer to Q3 is yes, is there a way to force MM always reusing 
> existing pdp context? (at least as a private patch)
>
> Regards,
> Alexey
>

Re: Telit LN920 rules

[Daniele Palmas]

Hello Peter,

Il giorno mer 7 set 2022 alle ore 16:00 Peter Naulls
 ha scritto:
>
>
> Based upon the similar models, this appears to be correct. This is against
> ModemManager 1.18.10:
>
> --- plugins/telit/77-mm-telit-port-types.rules.orig 2022-09-07
> 09:51:25.186228559 -0400
> +++ plugins/telit/77-mm-telit-port-types.rules  2022-09-07 09:56:48.650231458 
> -0400
> @@ -74,6 +74,13 @@
>   ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1051", ENV{.MM_USBIFNUM}=="06",
> SUBSYSTEM=="tty", ENV{ID_MM_PORT_TYPE_AT_SECONDARY}="1"
>   ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1051", ENV{.MM_USBIFNUM}=="07",
> ENV{ID_MM_PORT_IGNORE}="1"
>
> +# LN920
> +ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1060", ENV{.MM_USBIFNUM}=="00",
> ENV{ID_MM_PORT_IGNORE}="1"
> +ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1060", ENV{.MM_USBIFNUM}=="03",
> ENV{ID_MM_PORT_IGNORE}="1"
> +ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1060", ENV{.MM_USBIFNUM}=="04",
> SUBSYSTEM=="tty", ENV{ID_MM_PORT_TYPE_AT_PRIMARY}="1"
> +ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1060", ENV{.MM_USBIFNUM}=="05",
> SUBSYSTEM=="tty", ENV{ID_MM_PORT_TYPE_AT_SECONDARY}="1"
> +ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1060", ENV{.MM_USBIFNUM}=="06",
> ENV{ID_MM_PORT_IGNORE}="1"
> +
>   # LE910C1 with default usb cfg
>   ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1201", ENV{.MM_USBIFNUM}=="00",
> ENV{ID_MM_PORT_IGNORE}="1"
>   ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1201", ENV{.MM_USBIFNUM}=="03",
> SUBSYSTEM=="tty", ENV{ID_MM_PORT_TYPE_GPS}="1"

similar port hints were committed to main through
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/53f6c309bfbf87fe2ccb28dc3b9a3775e4e20897

Regards,
Daniele

Re: MHI on 5G modems

[Daniele Palmas]

Hi Koen,

Il giorno gio 11 ago 2022 alle ore 15:24 Koen Vandeputte
 ha scritto:
>
> Hi All,
>
> I'm currently working on adding MHI support within OpenWRT. (kernel 5.15.59)
>
> I have a few modems laying around here:
>
> - Sierra Wireless EM9191
> - Telit FN980
> - Fibocom FM150-AE
>
> On all 3 of them, MHI seems to enumerate correctly:
>
> [8.258921] mhi-pci-generic :01:00.0: BAR 0: assigned [mem
> 0x0110-0x01100fff 64bit]
> [8.267488] mhi-pci-generic :01:00.0: enabling device (0140 -> 0142)
> [8.276817] mhi mhi0: Requested to power ON
> [8.288905] mhi mhi0: Power on setup success
> [8.341370] mhi mhi0: Wait for device to enter SBL or Mission mode
>
> Exposed devices:
>
> /dev/wwan0mbim0
> /dev/wwan0qcdm0
> /dev/wwan0qmi0
>
> And a network device:
>
> mhi_hwip0
>
>
> Following kernel SYMS are enabled:
>
> CONFIG_MHI_BUS=m
> CONFIG_MHI_BUS_DEBUG=y
> CONFIG_MHI_BUS_PCI_GENERIC=m
> CONFIG_MHI_NET=m
> CONFIG_MHI_WWAN_CTRL=m
> CONFIG_MHI_WWAN_MBIM=m
> CONFIG_WWAN=m
>
>
> Now the problem is, when sending QMI traffic towards wwan0qmi0, I never
> get a reply back on any of them.
> When using cdc-wdm  or when wwan0qmi0 is exposed over usb, it works,
> but as soon as wwan0qmi0 is exposed over pcie, it fails.
>
> Does anyone have any clue what is missing here?
>

I suggest you enable dynamic debugging on mhi and wwan to get more
information about what's going on.

My experience is that some hosts have issues with runtime power
management (e.g. the modem is not able to exit M3) and the symptoms
seem to be the same as the ones you describe.

Regards,
Daniele

>
>
> Thanks!
>
> Koen
>

Re: MHI on 5G modems

[Daniele Palmas]

Hi Koen,

Il giorno ven 12 ago 2022 alle ore 15:26 Koen Vandeputte
 ha scritto:
>
>
> On 12.08.22 10:55, Daniele Palmas wrote:
> > Hi Koen,
> >
> > Il giorno gio 11 ago 2022 alle ore 15:24 Koen Vandeputte
> >  ha scritto:
> >> Hi All,
> >>
> >> I'm currently working on adding MHI support within OpenWRT. (kernel 
> >> 5.15.59)
> >>
> >> I have a few modems laying around here:
> >>
> >> - Sierra Wireless EM9191
> >> - Telit FN980
> >> - Fibocom FM150-AE
> >>
> >> On all 3 of them, MHI seems to enumerate correctly:
> >>
> >> [8.258921] mhi-pci-generic :01:00.0: BAR 0: assigned [mem
> >> 0x0110-0x01100fff 64bit]
> >> [8.267488] mhi-pci-generic :01:00.0: enabling device (0140 -> 0142)
> >> [8.276817] mhi mhi0: Requested to power ON
> >> [8.288905] mhi mhi0: Power on setup success
> >> [8.341370] mhi mhi0: Wait for device to enter SBL or Mission mode
> >>
> >> Exposed devices:
> >>
> >> /dev/wwan0mbim0
> >> /dev/wwan0qcdm0
> >> /dev/wwan0qmi0
> >>
> >> And a network device:
> >>
> >> mhi_hwip0
> >>
> >>
> >> Following kernel SYMS are enabled:
> >>
> >> CONFIG_MHI_BUS=m
> >> CONFIG_MHI_BUS_DEBUG=y
> >> CONFIG_MHI_BUS_PCI_GENERIC=m
> >> CONFIG_MHI_NET=m
> >> CONFIG_MHI_WWAN_CTRL=m
> >> CONFIG_MHI_WWAN_MBIM=m
> >> CONFIG_WWAN=m
> >>
> >>
> >> Now the problem is, when sending QMI traffic towards wwan0qmi0, I never
> >> get a reply back on any of them.
> >> When using cdc-wdm  or when wwan0qmi0 is exposed over usb, it works,
> >> but as soon as wwan0qmi0 is exposed over pcie, it fails.
> >>
> >> Does anyone have any clue what is missing here?
> >>
> > I suggest you enable dynamic debugging on mhi and wwan to get more
> > information about what's going on.
> >
> > My experience is that some hosts have issues with runtime power
> > management (e.g. the modem is not able to exit M3) and the symptoms
> > seem to be the same as the ones you describe.
> >
> > Regards,
> > Daniele
>
> Hi Daniele,
>
> Thanks for the reply.
> Well .. this is interesting.  Looks like my EM919x is always detected as
> a generic "qcom sdx55"
>
> All looks well-defined within mhi/pci-generic.c and lspci -v reports the
> proper ID's:
>
>
> static const struct pci_device_id mhi_pci_id_table[] = {
>  /* EM919x (sdx55), use the same vid:pid as qcom-sdx55m */
>  { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x18d7, 0x0200),
>  .driver_data = (kernel_ulong_t) _sierra_em919x_info },
>  /* Telit FN980 hardware revision v1 */
>  { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x1C5D, 0x2000),
>  .driver_data = (kernel_ulong_t)
> _telit_fn980_hw_v1_info },
>  { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0306),
>  .driver_data = (kernel_ulong_t) _qcom_sdx55_info },
>  { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304),
>  .driver_data = (kernel_ulong_t) _qcom_sdx24_info },
>
>
> 01:00.0 Unassigned class [ff00]: Qualcomm Device 0306
>  Subsystem: Device 18d7:0200
>
>
> hmz ..
>

Yeah, that's odd.

>
>
> Here are the logs:
>
>
> [   10.506776] mhi-pci-generic :01:00.0: MHI PCI device found:
> qcom-sdx55m
> [   10.513847] mhi-pci-generic :01:00.0: BAR 0: assigned [mem
> 0x0110-0x01100fff 64bit]
> [   10.522357] mhi-pci-generic :01:00.0: enabling device (0140 -> 0142)
> [   10.532198] mhi mhi0: Requested to power ON
> [   10.536490] mhi mhi0: Attempting power on with EE: PASS THROUGH,
> state: RESET
> [   10.547145] mhi mhi0: Power on setup success
> [   10.547293] mhi mhi0: Handling state transition: PBL
> [   10.556541] mhi mhi0: Device in READY State
> [   10.560738] mhi mhi0: Initializing MHI registers
> [   10.565457] mhi mhi0: Wait for device to enter SBL or Mission mode
> [   10.633687] mhi mhi0: local ee: MISSION MODE state: READY device ee:
> MISSION MODE state: READY
> [   10.657015] mhi mhi0: State change event to state: M0
> [   10.662281] mhi mhi0: Received EE event: MISSION MODE
> [   10.667577] mhi mhi0: Handling state transition: MISSION MODE
> [   10.673524] mhi mhi0: Processing Mission Mode transition
> [   10.684850] mhi_net mhi0_IP_HW0: 100: Updating channel state to: START
> [   10.707859] mhi_net mhi0_IP_HW0: 100: Channel state change to START
> successful
> [   10.715374] mhi_net mhi0_IP_HW0:

Re: Telit FN990: All supported/current modes not reported (MM 1.20.2)

[Daniele Palmas]

Amol,

Il giorno lun 28 nov 2022 alle ore 13:22 Aleksander Morgado
 ha scritto:
>
> > > Attaching full log and relevant portion seems below. No it's not 
> > > regression. I just loaded 1.20.2 mainly for 5g support.
> > >
> >
> > I've got  a bunch of changes fixing this and adding modes retrieval
> > through QMI (which makes more sense than using AT commands when
> > available), just need to find the time to polish and submit...
> >
>
> Great! thanks for letting us know
>

I've pushed a few commits for FN990 support at
https://gitlab.freedesktop.org/dnlplm/ModemManager/-/tree/dp/fn990
based on today's main.

The qmi fallback is still not implemented, but they should solve the
modes issue.

The commits had very limited testing, so I haven't yet sent a MR: I'll
try to finalize once I come back from holidays, but still wanted to
share them with you.

Regards,
Daniele

Re: Telit FN990: MM 1.20.4: mmcli --location-enable-gps-nmea reporting error

[Daniele Palmas]

Hi Amol,

Il giorno mar 3 gen 2023 alle ore 06:36 Amol Lad  ha scritto:
>
> Hi,
>
> I get the following error when enabling NMEA in FN990 with MM 1.20.4 (It 
> comes with 1.18.6 as well). I do not recall seeing this with Telit LN920 so 
> looks like this is something FN990 specific. Please advise. (I'm using MBIM)
>
> # mmcli -m "$modem" --location-enable-gps-nmea
> error: couldn't setup location gathering: 
> 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.GeneralError: Couldn't 
> enable location 'gps-nmea' gathering: Couldn't start GPS engine: QMI protocol 
> error (46): 'GeneralError''

>  [1672723268.345371] [/dev/cdc-wdm0] sent generic request 
> (translated)...
> << QMUX:
> <<   length  = 19
> <<   flags   = 0x00
> <<   service = "loc"
> <<   client  = 1
> << QMI:
> <<   flags   = "none"
> <<   transaction = 4
> <<   tlv_length  = 7
> <<   message = "Set NMEA Types" (0x003E)
> << TLV:
> <<   type   = "NMEA Types" (0x01)
> <<   length = 4
> <<   value  = 0D:00:02:00
> <<   translated = gga, gsv, gsa
>
>  [1672723268.345445] [/dev/cdc-wdm0] sent message...
> << RAW:
> <<   length = 68
> <<   data   = 03:00:00:00:44:00:00:00:3A:00:00:00...
>
>  [1672723268.345621] [/dev/cdc-wdm0] sent message (translated)...
> << Header:
> <<   length  = 68
> <<   type= command (0x0003)
> <<   transaction = 58
> << Fragment header:
> <<   total   = 1
> <<   current = 0
> << Contents:
> <<   service = 'qmi' (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)
> <<   cid = 'msg' (0x0001)
> <<   type= 'set' (0x0001)
> << Fields:
> <<   QmiMsg = 
> '01:13:00:00:10:01:00:04:00:3e:00:07:00:01:04:00:0d:00:02:00'
>
>  [1672723268.376601] [/dev/cdc-wdm0] received message...
> >> RAW:
> >>   length = 68
> >>   data   = 03:00:00:80:44:00:00:00:3A:00:00:00...
>
>  [1672723268.376810] [/dev/cdc-wdm0] received message (translated)...
> >> Header:
> >>   length  = 68
> >>   type= command-done (0x8003)
> >>   transaction = 58
> >> Fragment header:
> >>   total   = 1
> >>   current = 0
> >> Contents:
> >>   status error = 'None' (0x)
> >>   service  = 'qmi' (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)
> >>   cid  = 'msg' (0x0001)
> >> Fields:
> >>   QMUX = '01:13:00:80:10:01:02:04:00:3e:00:07:00:02:04:00:01:00:73:00'
>
>  [1672723268.376877] [/dev/cdc-wdm0] received message...
> << RAW:
> <<   length = 20
> <<   data   = 01:13:00:80:10:01:02:04:00:3E:00:07...
>
>  [1672723268.376982] [/dev/cdc-wdm0] received generic response 
> (translated)...
> << QMUX:
> <<   length  = 19
> <<   flags   = 0x80
> <<   service = "loc"
> <<   client  = 1
> << QMI:
> <<   flags   = "response"
> <<   transaction = 4
> <<   tlv_length  = 7
> <<   message = "Set NMEA Types" (0x003E)
> << TLV:
> <<   type   = "Result" (0x02)
> <<   length = 4
> <<   value  = 01:00:73:00
> <<   translated = FAILURE: NoPermission
>
>   [1672723268.377384] [modem0] couldn't setup required NMEA traces: QMI 
> protocol error (115): 'NoPermission'

I can't check right now on the target, but this and the start error
are probably related to the control point not registered as the master
client.

I suggest to file a ticket with Telit technical support to deal with this.

Regards,
Daniele

>  [1672723268.377493] [/dev/cdc-wdm0] sent message...
> << RAW:
> <<   length = 38
> <<   data   = 01:25:00:00:10:01:00:05:00:22:00:19...
>
>  [1672723268.377685] [/dev/cdc-wdm0] sent generic request 
> (translated)...
> << QMUX:
> <<   length  = 37
> <<   flags   = 0x00
> <<   service = "loc"
> <<   client  = 1
> << QMI:
> <<   flags   = "none"
> <<   transaction = 5
> <<   tlv_length  = 25
> <<   message = "Start" (0x0022)
> << TLV:
> <<   type   = "Minimum Interval between Position Reports" (0x13)
> <<   length = 4
> <<   value  = E8:03:00:00
> <<   translated = 1000
> << TLV:
> <<   type   = "Intermediate Report State" (0x12)
> <<   length = 4
> <<   value  = 02:00:00:00
> <<   translated = disable
> << TLV:
> <<   type   = "Fix Recurrence Type" (0x10)
> <<   length = 4
> <<   value  = 01:00:00:00
> <<   translated = periodic-fixes
> << TLV:
> <<   type   = "Session ID" (0x01)
> <<   length = 1
> <<   value  = 10
> <<   translated = 16
>
>  [1672723268.377846] [/dev/cdc-wdm0] sent message...
> << RAW:
> <<   length = 86
> <<   data   = 03:00:00:00:56:00:00:00:3B:00:00:00...
>
>  [1672723268.378097] [/dev/cdc-wdm0] sent message (translated)...
> << Header:
> <<   length  = 86
> <<   type= command (0x0003)
> <<   

Re: Telit FN990: All supported/current modes not reported (MM 1.20.2)

[Daniele Palmas]

Hi Amol and Aleksander,

Il giorno lun 28 nov 2022 alle ore 12:19 Amol Lad  ha scritto:
>
> Attaching full log and relevant portion seems below. No it's not regression. 
> I just loaded 1.20.2 mainly for 5g support.
>

I've got  a bunch of changes fixing this and adding modes retrieval
through QMI (which makes more sense than using AT commands when
available), just need to find the time to polish and submit...

Regards,
Daniele

> ==
>  [1669633765.148778] [modem0] no carrier config currently selected 
> (default in use)
>  [1669633765.149038] [modem0] device identifier built: 
> 1bc7107135917239176FN990TelitWirelessSolutions -> 
> d04794b2e195986e2087001f45f6a4b81d1e3f16
>  [1669633765.149153] [ttyUSB2/at] device open count is 2 (open)
>  [1669633765.149226] [ttyUSB2/at] --> 'AT+WS46=?'
>  [1669633765.163992] [ttyUSB2/at] <-- '+WS46: 
> (22,28,31,36-38,40)OK'
>  [1669633765.164170] [modem0] (shared-telit) device allows (3GPP) mode 
> combination: 3g
>  [1669633765.164198] [modem0] (shared-telit) device allows (3GPP) mode 
> combination: 4g
>  [1669633765.164230] [modem0] (shared-telit) device allows (3GPP) mode 
> combination: 3g, 4g
>  [1669633765.164253] [modem0] (shared-telit) device allows (3GPP) mode 
> combination: 5g
>  [1669633765.164281] [modem0] (shared-telit) device allows (3GPP) mode 
> combination: 4g, 5g
>  [1669633765.164312] [modem0] (shared-telit) device allows (3GPP) mode 
> combination: 3g, 4g, 5g
>  [1669633765.164341] [modem0] (shared-telit) device allows (3GPP) mode 
> combination: 3g, 5g
>  [1669633765.164366] [modem0] filtering 7 supported mode combinations 
> with 1 modes
>  [1669633765.164390] [modem0] device supports 3 different mode 
> combinations
> ===
>  [1669633765.212244] [ttyUSB2/at] device open count is 2 (open)
>  [1669633765.212331] [ttyUSB2/at] --> 'AT+WS46?'
>  [1669633765.225404] [ttyUSB2/at] <-- '+WS46: 
> 37OK'
>   [1669633765.225529] [modem0] couldn't load current allowed/preferred 
> modes: Couldn't parse unexpected +WS46 response: '+WS46: 37'
>
> From the FN990 AT command guide:
> AT+WS46=[]
>  integer 38 WDS-Side Stack to be used by the TA.
> Values:
> 22 : UTRAN only
> 28 : E-UTRAN only
> 31 : UTRAN and E-UTRAN
> 36 : NG-RAN only
> 37 : NG-RAN and E-UTRAN
> 38 : NG-RAN, E-UTRAN and UTRAN
> 40 : NG-RAN and UTRAN
>
> 
> From: Aleksander Morgado 
> Sent: Monday, November 28, 2022 4:03 PM
> To: Amol Lad 
> Cc: Daniele Palmas ; ModemManager (development) 
> 
> Subject: Re: Telit FN990: All supported/current modes not reported (MM 1.20.2)
>
> Hey,
>
> >
> > I'm trying Telit FN990 with MM 1.20.2 release and "supported" and "current" 
> > modes always report "4g" in MBIM mode. I believe it's reported correctly in 
> > QMI. It seems not all +WS46 combinations are supported in MBIM.
> >
> >   Modes |  supported: allowed: 4g; preferred: none
> > |current: allowed: 4g; preferred: none
> >
>
> Could you please run MM with debug logs to see what the modem is replying?
>
> Also, just to confirm, this is not a regression, right?
>
> --
> Aleksander
> 
> The information in this email communication (inclusive of attachments) is 
> confidential to 4RF Limited and the intended recipient(s). If you are not the 
> intended recipient(s), please note that any use, disclosure, distribution or 
> copying of this information or any part thereof is strictly prohibited and 
> that the author accepts no liability for the consequences of any action taken 
> on the basis of the information provided. If you have received this email in 
> error, please notify the sender immediately by return email and then delete 
> all instances of this email from your system. 4RF Limited will not accept 
> responsibility for any consequences associated with the use of this email 
> (including, but not limited to, damages sustained as a result of any viruses 
> and/or any action or lack of action taken in reliance on it).

Re: [Telit LE910C1-EU] ModemManager crashes when establishing online connection

[Daniele Palmas]

Hello,

Il giorno mer 3 mag 2023 alle ore 15:12 Christian Schneider
 ha scritto:
>
> Hello,
> I have a Telit LE910C1-EU modem. It is recognized and calls/SMS work,
> but when I establish an online connection, eg. with
> mmcli -m 0 --simple-connect "apn=internet.telekom"
> ModemManager crashes. The error message including a few lines before are:
>
> ModemManager[2838]:  [modem0] unhandled PDP type in CGDCONT=?
> reply: 'PPP'
> ModemManager[2838]:  [modem0] unknown +CGDCONT format details for
> PDP type 'none', using defaults: minimum 1, maximum 2147483646
> ModemManager[2838]:  [modem0] context definition format: minimum
> 1, maximum 2147483646
> ModemManager[2838]:  [modem0] set profile state (2/8): list before
> ModemManager[2838]:  [modem0/ttyUSB2/at] device open count is 5
> (open)
> ModemManager[2838]:  [modem0/ttyUSB2/at] device open count is 4
> (close)
> ModemManager[2838]:  [modem0/ttyUSB2/at] --> 'AT#PSNT?'
> ModemManager[2838]:  [modem0/ttyUSB2/at] <-- '#PSNT:
> 0,4OK'
> ModemManager[2838]:  [modem0] access technology changed (unknown
> -> lte)
> ModemManager[2838]:  [modem0] periodic signal quality and access
> technology checks scheduled
> ModemManager[2838]:  [modem0/ttyUSB2/at] device open count is 3
> (close)
> ModemManager[2838]:  [modem0/ttyUSB2/at] --> 'AT+CGDCONT?'
> ModemManager[2838]:  [modem0/ttyUSB2/at] <-- '+CGDCONT:
> 1,"IPV4V6","","",0,0,0,0+CGDCONT:
> 2,"IPV4V6","ims","",0,0,0,0+CGDCONT:
> 3,"IPV4V6","sos","",0,0,0,1OK'
> ModemManager[2838]:  [modem0] set profile state (3/8): select
> profile (best)
> ModemManager[2838]:  [modem0] found unused profile 4 (<2147483646)
> ModemManager[2838]:  [modem0] set profile state (4/8): check
> activated profile
> ModemManager[2838]:  [modem0] checking if profile with id '4' is
> already activated...
> ModemManager[2838]:  [modem0/ttyUSB2/at] device open count is 4
> (open)
> ModemManager[2838]:  [modem0/ttyUSB2/at] device open count is 3
> (close)
> ModemManager[2838]:  [modem0/ttyUSB2/at] --> 'AT+CGACT?'
> ModemManager[2838]:  [modem0/ttyUSB2/at] <-- '+CGACT:
> 1,1+CGACT: 2,0+CGACT: 3,0OK'
> ModemManager[2838]:  [modem0] profile '4' is not activated:
> Profile '4' not found in CGACT? response
> ModemManager[2838]:  [modem0] set profile state (6/8): store profile
> **
> ERROR:../../ModemManager-1.18.12/src/mm-broadband-modem.c:10677:modem_3gpp_profile_manager_store_profile:
> assertion failed: (ip_type != MM_BEARER_IP_FAMILY_NONE)
> Aborted
>
> mm seems to have trouble with this Profile stuff, but not sure if this
> is directly related to the crash.

With main I can't replicate the issue: when not declaring the ip-type,
MM by default is using "IP", e.g.

$ sudo mmcli -m 0 --simple-connect "apn=web.omnitel.it"
successfully connected the modem

ModemManager[725461]:  [1683183155.578330] [modem0] set profile
state (2/8): list before
ModemManager[725461]:  [1683183155.578357] [ttyUSB1/at] device
open count is 4 (open)
ModemManager[725461]:  [1683183155.578391] [ttyUSB1/at] device
open count is 3 (close)
ModemManager[725461]:  [1683183155.578428] [ttyUSB1/at] -->
'AT+CGDCONT?'
ModemManager[725461]:  [1683183155.619178] [ttyUSB1/at] <--
'+CGDCONT: 1,"IPV4V6","","",0,0,0,0+CGDCONT:
2,"IP","mobile.vodafone.it","",0,0,0,0OK'
ModemManager[725461]:  [1683183155.619435] [modem0] set profile
state (3/8): select profile (best)
ModemManager[725461]:  [1683183155.619479] [modem0] found unused
profile 3 (<24)
ModemManager[725461]:  [1683183155.619500] [modem0] set profile
state (4/8): check activated profile
ModemManager[725461]:  [1683183155.619542] [modem0] checking if
profile with id '3' is already activated...
ModemManager[725461]:  [1683183155.619583] [ttyUSB1/at] device
open count is 4 (open)
ModemManager[725461]:  [1683183155.619636] [ttyUSB1/at] device
open count is 3 (close)
ModemManager[725461]:  [1683183155.619690] [ttyUSB1/at] --> 'AT+CGACT?'
ModemManager[725461]:  [1683183155.660510] [ttyUSB1/at] <--
'+CGACT: 1,1+CGACT: 2,0OK'
ModemManager[725461]:  [1683183155.660768] [modem0] profile '-1'
is not activated: Profile '3' not found in CGACT? response
ModemManager[725461]:  [1683183155.660810] [modem0] set profile
state (6/8): store profile
ModemManager[725461]:  [1683183155.660843] [modem0] storing
profile '3': apn 'web.omnitel.it', ip type 'ipv4'
ModemManager[725461]:  [1683183155.660893] [ttyUSB1/at] device
open count is 4 (open)
ModemManager[725461]:  [1683183155.660948] [ttyUSB1/at] device
open count is 3 (close)
ModemManager[725461]:  [1683183155.661010] [ttyUSB1/at] -->
'AT+CGDCONT=3,"IP","web.omnitel.it"'
ModemManager[725461]:  [1683183155.837506] [ttyUSB1/at] <--
'OK'
ModemManager[725461]:  [1683183155.837684] [modem0] stored profile '-1'
ModemManager[725461]:  [1683183155.837721] [modem0] set profile
state (7/8): list after
ModemManager[725461]:  [1683183155.837782] [ttyUSB1/at] device
open count is 4 (open)
ModemManager[725461]:  [1683183155.837842] [ttyUSB1/at] device
open count is 3 (close)
ModemManager[725461]:  [1683183155.837903] 

Re: The MBIM protocol and the Microsoft extensions

[Daniele Palmas]

Hi Aleksander,

Il giorno mar 23 mag 2023 alle ore 14:43 Aleksander Morgado
 ha scritto:
>
> Hey all,
>
> The modemmanager.org site now includes a document explaining details
> about the MBIM protocol and the new Microsoft extensions (e.g. for 4G
> and 5G specific features):
>
> https://modemmanager.org/docs/libmbim/mbim-protocol/
>

cool, thanks for this!

I've just a doubt about this statement:

> Quectel defines a QDU service that supports performing the whole device 
> firmware upgrade operation (including file download to the module) via MBIM 
> requests and responses.

Maybe is this "Qualcomm" instead of "Quectel"?

Regards,
Daniele

> Please be advised that this document is not specific to either libmbim
> or ModemManager. It is intended to be general in nature.
>
> Cheers
>
> --
> Aleksander