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

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 11:08 PM, Daniele Palmas  wrote:
>> On Fri, Mar 24, 2017 at 3:33 PM, Daniele Palmas  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.

Ok, thanks. I was actually thinking in using that device as a base for
a new plugin; including the AT+NCM mode.


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

Re: [PATCH v2] Fixed wrong MEM1 value passed to +CPMS

[Carlo Lobrano]

Sure, I didn't see the other error. I'll update the patch


Il venerdì 24 marzo 2017, Aleksander Morgado  ha
scritto:
> Hey Carlo,
>
> On Fri, Mar 24, 2017 at 12:48 PM, Carlo Lobrano 
wrote:
>> Let modem_messaging_set_default_storage returns with error
>> if current_sms_mem1_storage is MM_SMS_STORAGE_UNKNOWN
>>
>> ---
>>
>> I updated the patch according the code review, moreover I'd like
>> to note a little difference respect the previous version:
>>
>> currently, even if +CPMS fails because of the wrong value for
>> mem1, we do store "storage" as the current_sms_mem2_storage value.
>>
>>  self->priv->current_sms_mem2_storage = storage;
>>
>> In this patch I preferred to change this behaviour and setting default
>> storage for SMS mem2 only if we are actually going to set
>> this value on the modem.
>>
>
> That is a good change, yes.
>
>> What do you think about it?
>>
>
> The same issue happens in mm_broadband_modem_lock_sms_storages();
> where we may end up using "self->priv->current_sms_mem1_storage"
> without checking it is UNKNOWN first. Could you also update that
> method with the same logic? i.e. return an error if we end up there
> with UNKNOWN in "current_sms_mem1_storage".
>
> Also see comments below.
>
>> ---
>>  src/mm-broadband-modem.c   | 29 +++--
>>  src/mm-iface-modem-messaging.c |  2 +-
>>  2 files changed, 20 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
>> index 17b3253..0bbf626 100644
>> --- a/src/mm-broadband-modem.c
>> +++ b/src/mm-broadband-modem.c
>> @@ -5590,22 +5590,31 @@ modem_messaging_set_default_storage
(MMIfaceModemMessaging *_self,
>>  gchar *mem1_str;
>>  gchar *mem_str;
>>
>> -result = g_simple_async_result_new (G_OBJECT (self),
>> -callback,
>> -user_data,
>> -
modem_messaging_set_default_storage);
>> +/* We provide the current sms storage for mem1 if not UNKNOWN */
>> +if (self->priv->current_sms_mem1_storage == MM_SMS_STORAGE_UNKNOWN)
{
>> +g_simple_async_report_error_in_idle (G_OBJECT (self),
>> + callback,
>> + user_data,
>> + MM_CORE_ERROR,
>> + MM_CORE_ERROR_INVALID_ARGS,
>> + "Current SMS MEM1 storage
is UNKNOWN (SIM busy?)");
>> +return;
>> +}
>>
>>  /* Set defaults as current */
>>  self->priv->current_sms_mem2_storage = storage;
>>
>> -/* We provide the current sms storage for mem1 if not UNKNOWN */
>>  mem1_str = g_ascii_strup (mm_sms_storage_get_string
(self->priv->current_sms_mem1_storage), -1);
>> -
>>  mem_str = g_ascii_strup (mm_sms_storage_get_string (storage), -1);
>> -cmd = g_strdup_printf ("+CPMS=\"%s\",\"%s\",\"%s\"",
>> -   mem1_str ? mem1_str : "",
>> -   mem_str,
>> -   mem_str);
>> +
>> +cmd = g_strdup_printf ("+CPMS=\"%s\",\"%s\",\"%s\"", mem1_str,
mem_str, mem_str);
>> +
>> +result = g_simple_async_result_new (G_OBJECT (self),
>> +callback,
>> +user_data,
>> +
modem_messaging_set_default_storage);
>> +
>> +
>
> Just a single whiteline here.
>
>>  mm_base_modem_at_command (MM_BASE_MODEM (self),
>>cmd,
>>3,
>> diff --git a/src/mm-iface-modem-messaging.c
b/src/mm-iface-modem-messaging.c
>> index 0cff1f2..01a30f0 100644
>> --- a/src/mm-iface-modem-messaging.c
>> +++ b/src/mm-iface-modem-messaging.c
>> @@ -789,7 +789,7 @@ set_default_storage_ready (MMIfaceModemMessaging
*self,
>>  GError *error = NULL;
>>
>>  if (!MM_IFACE_MODEM_MESSAGING_GET_INTERFACE
(self)->set_default_storage_finish (self, res, )) {
>> -mm_dbg ("Couldn't set default storage: '%s'", error->message);
>> +mm_warn ("Could not set default storage: '%s'", error->message);
>>  g_error_free (error);
>>  }
>>
>> --
>> 2.9.3
>>
>> ___
>> ModemManager-devel mailing list
>> ModemManager-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
>
>
> --
> 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]

2017-03-24 17:38 GMT+01:00 Aleksander Morgado :
> On Fri, Mar 24, 2017 at 3:33 PM, Daniele Palmas  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 v2] Fixed wrong MEM1 value passed to +CPMS

[Aleksander Morgado]

Hey Carlo,

On Fri, Mar 24, 2017 at 12:48 PM, Carlo Lobrano  wrote:
> Let modem_messaging_set_default_storage returns with error
> if current_sms_mem1_storage is MM_SMS_STORAGE_UNKNOWN
>
> ---
>
> I updated the patch according the code review, moreover I'd like
> to note a little difference respect the previous version:
>
> currently, even if +CPMS fails because of the wrong value for
> mem1, we do store "storage" as the current_sms_mem2_storage value.
>
>  self->priv->current_sms_mem2_storage = storage;
>
> In this patch I preferred to change this behaviour and setting default
> storage for SMS mem2 only if we are actually going to set
> this value on the modem.
>

That is a good change, yes.

> What do you think about it?
>

The same issue happens in mm_broadband_modem_lock_sms_storages();
where we may end up using "self->priv->current_sms_mem1_storage"
without checking it is UNKNOWN first. Could you also update that
method with the same logic? i.e. return an error if we end up there
with UNKNOWN in "current_sms_mem1_storage".

Also see comments below.

> ---
>  src/mm-broadband-modem.c   | 29 +++--
>  src/mm-iface-modem-messaging.c |  2 +-
>  2 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
> index 17b3253..0bbf626 100644
> --- a/src/mm-broadband-modem.c
> +++ b/src/mm-broadband-modem.c
> @@ -5590,22 +5590,31 @@ modem_messaging_set_default_storage 
> (MMIfaceModemMessaging *_self,
>  gchar *mem1_str;
>  gchar *mem_str;
>
> -result = g_simple_async_result_new (G_OBJECT (self),
> -callback,
> -user_data,
> -modem_messaging_set_default_storage);
> +/* We provide the current sms storage for mem1 if not UNKNOWN */
> +if (self->priv->current_sms_mem1_storage == MM_SMS_STORAGE_UNKNOWN) {
> +g_simple_async_report_error_in_idle (G_OBJECT (self),
> + callback,
> + user_data,
> + MM_CORE_ERROR,
> + MM_CORE_ERROR_INVALID_ARGS,
> + "Current SMS MEM1 storage is 
> UNKNOWN (SIM busy?)");
> +return;
> +}
>
>  /* Set defaults as current */
>  self->priv->current_sms_mem2_storage = storage;
>
> -/* We provide the current sms storage for mem1 if not UNKNOWN */
>  mem1_str = g_ascii_strup (mm_sms_storage_get_string 
> (self->priv->current_sms_mem1_storage), -1);
> -
>  mem_str = g_ascii_strup (mm_sms_storage_get_string (storage), -1);
> -cmd = g_strdup_printf ("+CPMS=\"%s\",\"%s\",\"%s\"",
> -   mem1_str ? mem1_str : "",
> -   mem_str,
> -   mem_str);
> +
> +cmd = g_strdup_printf ("+CPMS=\"%s\",\"%s\",\"%s\"", mem1_str, mem_str, 
> mem_str);
> +
> +result = g_simple_async_result_new (G_OBJECT (self),
> +callback,
> +user_data,
> +modem_messaging_set_default_storage);
> +
> +

Just a single whiteline here.

>  mm_base_modem_at_command (MM_BASE_MODEM (self),
>cmd,
>3,
> diff --git a/src/mm-iface-modem-messaging.c b/src/mm-iface-modem-messaging.c
> index 0cff1f2..01a30f0 100644
> --- a/src/mm-iface-modem-messaging.c
> +++ b/src/mm-iface-modem-messaging.c
> @@ -789,7 +789,7 @@ set_default_storage_ready (MMIfaceModemMessaging *self,
>  GError *error = NULL;
>
>  if (!MM_IFACE_MODEM_MESSAGING_GET_INTERFACE 
> (self)->set_default_storage_finish (self, res, )) {
> -mm_dbg ("Couldn't set default storage: '%s'", error->message);
> +mm_warn ("Could not set default storage: '%s'", error->message);
>  g_error_free (error);
>  }
>
> --
> 2.9.3
>
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel



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

Re: [PATCH] telit: don't require udev tags to bind devices

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 5:08 PM, Carlo Lobrano  wrote:
> tested with HE910, LE910, LE910 V2, LE910 sv1 and everything is fine for me.

I've pushed this to git master.

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

Re: [PATCH] base-bearer: stop connection status monitoring if no TTY available

[Aleksander Morgado]

On 24/03/17 21:20, Aleksander Morgado wrote:
>>> +/* If CID not defined, error out */
>>>  if (!MM_BROADBAND_BEARER (self)->priv->cid) {
>>> -g_task_return_new_error (task, MM_CORE_ERROR,
>>> MM_CORE_ERROR_FAILED,
>>> +g_task_return_new_error (task, MM_CORE_ERROR,
>>> MM_CORE_ERROR_UNSUPPORTED,
>> Did you mean to change this case from FAILED -> UNSUPPORTED?
> Yes, but on a second thought, you're right, that should be kept
> FAILED. I'll update it.

Pushed to git master after updating that specific error back to FAILED,
and also the error string returned when no available TTY was found,
which was also incorrect.

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

Re: [PATCH] broadband-bearer: set TTY as connected as soon as ATD replies

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 9:35 PM, Dan Williams  wrote:
>> When the connection request is done via ATD, flag the port as
>> connected as soon as the successful response is received, so that we
>> remove our polling on the device right away.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=99541
>
> LGTM.

Pushed to git master, mm-1-6 and mm-1-4.


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

Re: [PATCH] broadband-bearer: set TTY as connected as soon as ATD replies

[Dan Williams]

On Fri, 2017-03-24 at 15:03 +0100, Aleksander Morgado wrote:
> When the connection request is done via ATD, flag the port as
> connected as soon as the successful response is received, so that we
> remove our polling on the device right away.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=99541

LGTM.

Dan

> ---
> 
> Hey Colin, Dan & everyone,
> 
> This patch tries to minimize the possibility of a race condition
> happening when we end up sending AT commands (e.g. signal quality
> loading request) between a successful reply to ATD, and the actual
> setting of the TTY as 'connected', which is done in an idle.
> 
> This was discussed not long ago:
> https://lists.freedesktop.org/archives/modemmanager-devel/2017-Januar
> y/003773.html
> 
> Comments?
> 
> ---
>  src/mm-broadband-bearer.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mm-broadband-bearer.c b/src/mm-broadband-bearer.c
> index f2834b1b..bb4ff567 100644
> --- a/src/mm-broadband-bearer.c
> +++ b/src/mm-broadband-bearer.c
> @@ -254,7 +254,10 @@ dial_cdma_ready (MMBaseModem *modem,
>  return;
>  }
> 
> -/* else... Yuhu! */
> +/* The ATD command has succeeded, and therefore the TTY is in
> data mode now.
> + * Instead of waiting for setting the port as connected later in
> + * connect_succeeded(), we do it right away so that we stop our
> polling. */
> +mm_port_set_connected (ctx->data, TRUE);
> 
>  /* Keep port open during connection */
>  ctx->close_data_on_exit = FALSE;
> @@ -573,6 +576,11 @@ atd_ready (MMBaseModem *modem,
>  return;
>  }
> 
> +/* The ATD command has succeeded, and therefore the TTY is in
> data mode now.
> + * Instead of waiting for setting the port as connected later in
> + * connect_succeeded(), we do it right away so that we stop our
> polling. */
> +mm_port_set_connected (MM_PORT (ctx->dial_port), TRUE);
> +
>  g_simple_async_result_set_op_res_gpointer (ctx->result,
> g_object_ref (ctx-
> >dial_port),
> (GDestroyNotify)g_obj
> ect_unref);
> @@ -1177,7 +1185,8 @@ connect_succeeded (ConnectContext *ctx,
>  ctx->self->priv->port = g_object_ref
> (mm_bearer_connect_result_peek_data (result));
>  ctx->self->priv->connection_type = connection_type;
> 
> -/* Port is connected; update the state */
> +/* Port is connected; update the state. For ATD based
> connections, the port
> + * may already be set as connected, but no big deal. */
>  mm_port_set_connected (ctx->self->priv->port, TRUE);
> 
>  /* Set operation result */
> --
> 2.12.0
> ___
> 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 2/2] broadband-modem: fix capabilities in 4G-only devices

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 9:12 PM, Dan Williams  wrote:
>> The +CGSM capability is saying that the modem is a 3GPP modem, but
>> that doesn't necessarily mean it's a GSM/UMTS modem, it could be a
>> LTE-only device.
>>
>> We did add the GSM_UMTS capability when +CGSM was found, so now we'll
>> check if the device only reports 4G-only mode, and remove the
>> capability if so.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=100155
>
> LGTM.

Pushed to git master.


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

Re: [PATCH 1/2] broadband-modem, helpers: implement AT+WS46=? response parser

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 9:22 PM, Aleksander Morgado
 wrote:
>>> We want a parser that returns the full list of combinations found.
>>
>> Looks good to me except the comment:
>>
>> +/* Fixup the ANY value, based on whether LTE is supported or not
>>
>> the code under that comment seems to use all modes, not just LTE/4G.
>
> Ah, good catch, yes, first version of the patch was only for LTE and
> then I updated it without updating the comment :) Will fix that before
> merging.

Pushed to git master after changing the comment text to:
/* Fixup the ANY value, based on which are the supported modes */


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

Re: [PATCH] base-bearer: stop connection status monitoring if no TTY available

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 9:15 PM, Dan Williams  wrote:
>> +/* If CID not defined, error out */
>>  if (!MM_BROADBAND_BEARER (self)->priv->cid) {
>> -g_task_return_new_error (task, MM_CORE_ERROR,
>> MM_CORE_ERROR_FAILED,
>> +g_task_return_new_error (task, MM_CORE_ERROR,
>> MM_CORE_ERROR_UNSUPPORTED,
>
> Did you mean to change this case from FAILED -> UNSUPPORTED?

Yes, but on a second thought, you're right, that should be kept
FAILED. I'll update it.


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

Re: [PATCH] base-bearer: stop connection status monitoring if no TTY available

[Dan Williams]

On Fri, 2017-03-24 at 14:55 +0100, Aleksander Morgado wrote:
> On modems with a single TTY for both control and data, we cannot use
> the TTY to load connection status once we're in connected mode:
> 
> Connection through a plain serial AT port (ttyUSB2)
> (ttyUSB2): --> 'ATD*99***2#'
> (ttyUSB2): <-- 'CONNECT 1'
> (ttyUSB2): port now connected
> Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
> Modem /org/freedesktop/ModemManager1/Modem/0: state changed
> (connecting -> connected)
> Simple connect state (8/8): All done
> checking if connected failed: Couldn't check current list of
> active PDP contexts: No AT port available to run command
> checking if connected failed: Couldn't check current list of
> active PDP contexts: No AT port available to run command
> checking if connected failed: Couldn't check current list of
> active PDP contexts: No AT port available to run command
> ...
> 
> So, disable connection monitoring right away if that situation is
> detected:
> 
> Connection through a plain serial AT port (ttyUSB2)
> (ttyUSB2): --> 'ATD*99***2#'
> (ttyUSB2): <-- 'CONNECT 1'
> (ttyUSB2): port now connected
> Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
> Modem /org/freedesktop/ModemManager1/Modem/0: state changed
> (connecting -> connected)
> Simple connect state (8/8): All done
> Connection monitoring is unsupported by the device
> ...
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=100376
> ---
> 
> Hey everyone,
> 
> Plugins can now report a MM_CORE_UNSUPPORTED error in
> load_connection_status() in order to instruct the upper layers to
> stop doing the connection status monitoring for the current
> connection. This is implemented in the generic broadband bearer for
> the specific case of single-TTY modems, where the control TTY can no
> longer be used for AT commands once it gets in connected mode.
> 
> Comments?
> 
> ---
>  src/mm-base-bearer.c  | 20 ++--
>  src/mm-broadband-bearer.c | 43 +--
> 
>  2 files changed, 47 insertions(+), 16 deletions(-)
> 
> diff --git a/src/mm-base-bearer.c b/src/mm-base-bearer.c
> index 0cca8534..02084dff 100644
> --- a/src/mm-base-bearer.c
> +++ b/src/mm-base-bearer.c
> @@ -92,6 +92,8 @@ struct _MMBaseBearerPrivate {
> 
>  /* Connection status monitoring */
>  guint connection_monitor_id;
> +/* Flag to specify whether connection monitoring is supported or
> not */
> +gboolean load_connection_status_unsupported;
> 
>  /*-- 3GPP specific --*/
>  guint deferred_3gpp_unregistration_id;
> @@ -162,7 +164,18 @@ load_connection_status_ready (MMBaseBearer
> *self,
> 
>  status = MM_BASE_BEARER_GET_CLASS (self)-
> >load_connection_status_finish (self, res, );
>  if (status == MM_BEARER_CONNECTION_STATUS_UNKNOWN) {
> -mm_warn ("checking if connected failed: %s", error-
> >message);
> +/* Only warn if not reporting an "unsupported" error */
> +if (!g_error_matches (error, MM_CORE_ERROR,
> MM_CORE_ERROR_UNSUPPORTED)) {
> +mm_warn ("checking if connected failed: %s", error-
> >message);
> +g_error_free (error);
> +return;
> +}
> +
> +/* If we're being told that connection monitoring is
> unsupported, just
> + * ignore the error and remove the timeout. */
> +mm_dbg ("Connection monitoring is unsupported by the
> device");
> +self->priv->load_connection_status_unsupported = TRUE;
> +connection_monitor_stop (self);
>  g_error_free (error);
>  return;
>  }
> @@ -176,7 +189,7 @@ load_connection_status_ready (MMBaseBearer *self,
>  static gboolean
>  connection_monitor_cb (MMBaseBearer *self)
>  {
> -/* If the implementation knows how to update stat values, run it
> */
> +/* If the implementation knows how to load connection status,
> run it */
>  MM_BASE_BEARER_GET_CLASS (self)->load_connection_status (
>  self,
>  (GAsyncReadyCallback)load_connection_status_ready,
> @@ -192,6 +205,9 @@ connection_monitor_start (MMBaseBearer *self)
>  !MM_BASE_BEARER_GET_CLASS (self)-
> >load_connection_status_finish)
>  return;
> 
> +if (self->priv->load_connection_status_unsupported)
> +return;
> +
>  /* Schedule */
>  g_assert (!self->priv->connection_monitor_id);
>  self->priv->connection_monitor_id = g_timeout_add_seconds
> (BEARER_CONNECTION_MONITOR_TIMEOUT,
> diff --git a/src/mm-broadband-bearer.c b/src/mm-broadband-bearer.c
> index 1188f60a..f2834b1b 100644
> --- a/src/mm-broadband-bearer.c
> +++ b/src/mm-broadband-bearer.c
> @@ -1983,30 +1983,45 @@ load_connection_status
> (MMBaseBearer*self,
>  GAsyncReadyCallback  callback,
>  gpointer user_data)
>  {
> -GTask   *task;
> -MMBaseModem *modem = NULL;

Re: [PATCH 2/2] broadband-modem: fix capabilities in 4G-only devices

[Dan Williams]

On Sun, 2017-03-12 at 21:05 +0100, Aleksander Morgado wrote:
> The +CGSM capability is saying that the modem is a 3GPP modem, but
> that doesn't necessarily mean it's a GSM/UMTS modem, it could be a
> LTE-only device.
> 
> We did add the GSM_UMTS capability when +CGSM was found, so now we'll
> check if the device only reports 4G-only mode, and remove the
> capability if so.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=100155

LGTM.

Dan

> ---
>  src/mm-broadband-modem.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
> index aa84fc7e..302fc3db 100644
> --- a/src/mm-broadband-modem.c
> +++ b/src/mm-broadband-modem.c
> @@ -397,6 +397,21 @@ current_capabilities_ws46_test_ready
> (MMBaseModem *self,
>  break;
>  }
>  }
> +
> +/* The +CGSM capability is saying that the modem is a 3GPP
> modem, but that
> + * doesn't necessarily mean it's a GSM/UMTS modem, it could be a
> LTE-only
> + * device. We did add the GSM_UMTS capability when +CGSM was
> found, so now
> + * we'll check if the device only reports 4G-only mode, and
> remove the
> + * capability if so.
> + *
> + * Note that we don't change the default +CGSM -> GSM/UMTS
> logic, we just
> + * fix it up.
> + */
> +if ((modes->len == 1) && (g_array_index (modes, MMModemMode, 0)
> == MM_MODEM_MODE_4G)) {
> +g_assert (ctx->caps & MM_MODEM_CAPABILITY_LTE);
> +ctx->caps &= ~MM_MODEM_CAPABILITY_GSM_UMTS;
> +}
> +
>  g_array_unref (modes);
>  
>  out:
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH 1/2] broadband-modem,helpers: implement AT+WS46=? response parser

[Dan Williams]

On Sun, 2017-03-12 at 21:05 +0100, Aleksander Morgado wrote:
> We want a parser that returns the full list of combinations found.

Looks good to me except the comment:

+/* Fixup the ANY value, based on whether LTE is supported or not

the code under that comment seems to use all modes, not just LTE/4G.

Dan


> ---
>  src/mm-broadband-modem.c   | 111 ---
> -
>  src/mm-modem-helpers.c | 143
> +
>  src/mm-modem-helpers.h |   3 +
>  src/tests/test-modem-helpers.c | 102 +
>  4 files changed, 290 insertions(+), 69 deletions(-)
> 
> diff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
> index 17b3253a..aa84fc7e 100644
> --- a/src/mm-broadband-modem.c
> +++ b/src/mm-broadband-modem.c
> @@ -378,17 +378,28 @@ current_capabilities_ws46_test_ready
> (MMBaseModem *self,
>    LoadCapabilitiesContext *ctx)
>  {
>  const gchar *response;
> +GArray  *modes;
> +guinti;
>  
>  /* Completely ignore errors in AT+WS46=? */
>  response = mm_base_modem_at_command_finish (self, res, NULL);
> -if (response &&
> -(strstr (response, "28") != NULL ||   /* 4G only */
> - strstr (response, "30") != NULL ||   /* 2G/4G */
> - strstr (response, "31") != NULL)) {  /* 3G/4G */
> -/* Add LTE caps */
> -ctx->caps |= MM_MODEM_CAPABILITY_LTE;
> +if (!response)
> +goto out;
> +
> +modes = mm_3gpp_parse_ws46_test_response (response, NULL);
> +if (!modes)
> +goto out;
> +
> +/* Add LTE caps if any of the reported modes supports 4G */
> +for (i = 0; i < modes->len; i++) {
> +if (g_array_index (modes, MMModemMode, i) &
> MM_MODEM_MODE_4G) {
> +ctx->caps |= MM_MODEM_CAPABILITY_LTE;
> +break;
> +}
>  }
> +g_array_unref (modes);
>  
> +out:
>  g_simple_async_result_set_op_res_gpointer (
>  ctx->result,
>  GUINT_TO_POINTER (ctx->caps),
> @@ -1430,78 +1441,40 @@ supported_modes_ws46_test_ready
> (MMBroadbandModem *self,
>   LoadSupportedModesContext *ctx)
>  {
>  const gchar *response;
> -GError *error = NULL;
> +GArray  *modes;
> +GError  *error = NULL;
> +guinti;
>  
>  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.
> - *
> - * NOTE: Do not skip WS46 prefix; it would break Cinterion
> handling.
> - *
> - * From 3GPP TS 27.007 v.11.2.0, section 5.9
> - * 12GSM Digital Cellular Systems (GERAN only)
> - * 22UTRAN only
> - * 253GPP Systems (GERAN, UTRAN and E-UTRAN)
> - * 28E-UTRAN only
> - * 29GERAN and UTRAN
> - * 30GERAN and E-UTRAN
> - * 31UTRAN 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 (error) {
> +mm_dbg ("Generic query of supported 3GPP networks with
> WS46=? failed: '%s'", error->message);
> +g_error_free (error);
> +goto out;
> +}
>  
> -if (strstr (response, "29") != NULL) {
> -mm_dbg ("Device allows (3GPP) 2G/3G network mode");
> -mode |= (MM_MODEM_MODE_2G | MM_MODEM_MODE_3G);
> -}
> +modes = mm_3gpp_parse_ws46_test_response (response, );
> +if (!modes) {
> +mm_dbg ("Parsing WS46=? response failed: '%s'", error-
> >message);
> +g_error_free (error);
> +goto out;
> +}
>  
> -if (strstr (response, "30") != NULL) {
> -mm_dbg ("Device allows (3GPP) 2G/4G network mode");
> -mode |= (MM_MODEM_MODE_2G | MM_MODEM_MODE_4G);
> -}
> +for (i = 0; i < modes->len; i++) {
> +MMModemMode  mode;
> +gchar   *str;
>  
> -if (strstr (response, "31") != NULL) {
> -mm_dbg ("Device allows (3GPP) 3G/4G network mode");
> -mode |= (MM_MODEM_MODE_3G | MM_MODEM_MODE_4G);
> -}
> +mode = g_array_index (modes, MMModemMode, i);
>  
> -if (strstr (response, "25") != NULL) {
> -if (mm_iface_modem_is_3gpp_lte (MM_IFACE_MODEM (self)))
> {
> - 

Re: [PATCH] Huawei: Ignore unsolicited message ^EONS

[Aleksander Morgado]

On 24/03/17 15:43, Riccardo Vangelisti wrote:
> Ops, sorry :)
> 
> 

Pushed now to git master after doing some minor alignment fixes.

Thanks!

-- 
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

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 3:33 PM, Daniele Palmas  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.


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

Re: [PATCH] telit: don't require udev tags to bind devices

[Carlo Lobrano]

Hi Aleksander,

tested with HE910, LE910, LE910 V2, LE910 sv1 and everything is fine for me.

On 24 March 2017 at 15:37, Carlo Lobrano  wrote:

> Hi,
>
> sure I can test it today or the next week
>
> BR,
> Carlo
>
> On 24 March 2017 at 14:51, Aleksander Morgado 
> wrote:
>
>> The vendor id/string based rules should already be enough to get the
>> telit plugin bind telit devices.
>>
>> This simplifies support for future Telit devices, as we wouldn't need
>> any additional change in the plugin. It also helps when working with
>> RS232 devices as the user wouldn't need to add the explicit tag to get
>> the devices bound to this plugin.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=100373
>> ---
>>
>> Hey Carlo & Daniele,
>>
>> This patch removes the need of having an explicit ID_MM_TELIT_TAGGED to
>> flag those devices that may be grabbed by the Telit plugin.
>>
>> Could you test it with your devices to see if it works as expected?
>>
>> ---
>>  plugins/dell/77-mm-dell-port-types.rules   | 3 +--
>>  plugins/telit/77-mm-telit-port-types.rules | 9 -
>>  plugins/telit/mm-plugin-telit.c| 6 --
>>  3 files changed, 1 insertion(+), 17 deletions(-)
>>
>> diff --git a/plugins/dell/77-mm-dell-port-types.rules
>> b/plugins/dell/77-mm-dell-port-types.rules
>> index d619456c..bbb59b92 100644
>> --- a/plugins/dell/77-mm-dell-port-types.rules
>> +++ b/plugins/dell/77-mm-dell-port-types.rules
>> @@ -9,8 +9,7 @@ LABEL="mm_dell_vendorcheck"
>>  SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*",
>> ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}"
>>
>>  # DW5580 is a Dell-branded Telit modem
>> -# tag is needed here both for dynamic port recognition and minimizing
>> port probing time
>> -ATTRS{idVendor}=="413c", ATTRS{idProduct}=="81ba",
>> ENV{ID_MM_TELIT_TAGGED}="1"
>> +# tag is needed here for dynamic port recognition
>>  ATTRS{idVendor}=="413c", ATTRS{idProduct}=="81ba",
>> ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
>>
>>  GOTO="mm_dell_port_types_end"
>> diff --git a/plugins/telit/77-mm-telit-port-types.rules
>> b/plugins/telit/77-mm-telit-port-types.rules
>> index 1b58a3d9..01538cb6 100644
>> --- a/plugins/telit/77-mm-telit-port-types.rules
>> +++ b/plugins/telit/77-mm-telit-port-types.rules
>> @@ -10,45 +10,36 @@ SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*",
>> ENV{.MM_USBIFNUM}="$attr{bInte
>>  # UC864-E, UC864-E-AUTO, UC864-K, UC864-WD, UC864-WDU
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003",
>> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003",
>> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
>> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003",
>> ENV{ID_MM_TELIT_TAGGED}="1"
>>
>>  # UC864-G
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004",
>> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004",
>> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004",
>> ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
>> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004",
>> ENV{ID_MM_TELIT_TAGGED}="1"
>>
>>  # CC864-DUAL
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005",
>> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005",
>> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005",
>> ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
>> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005",
>> ENV{ID_MM_TELIT_TAGGED}="1"
>>
>>  # CC864-SINGLE, CC864-KPS
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006",
>> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006",
>> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
>> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006",
>> ENV{ID_MM_TELIT_TAGGED}="1"
>>
>>  # DE910-DUAL
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010",
>> ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010",
>> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010",
>> ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010",
>> ENV{ID_MM_TELIT_TAGGED}="1"
>>
>>  # CE910-DUAL
>>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1011",
>> ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1011",
>> ENV{ID_MM_TELIT_TAGGED}="1"
>>
>>  # HE910, UE910, UL865 (dynamic port identification supported)
>> -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 

Re: [PATCH] telit: don't require udev tags to bind devices

[Carlo Lobrano]

Hi,

sure I can test it today or the next week

BR,
Carlo

On 24 March 2017 at 14:51, Aleksander Morgado 
wrote:

> The vendor id/string based rules should already be enough to get the
> telit plugin bind telit devices.
>
> This simplifies support for future Telit devices, as we wouldn't need
> any additional change in the plugin. It also helps when working with
> RS232 devices as the user wouldn't need to add the explicit tag to get
> the devices bound to this plugin.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=100373
> ---
>
> Hey Carlo & Daniele,
>
> This patch removes the need of having an explicit ID_MM_TELIT_TAGGED to
> flag those devices that may be grabbed by the Telit plugin.
>
> Could you test it with your devices to see if it works as expected?
>
> ---
>  plugins/dell/77-mm-dell-port-types.rules   | 3 +--
>  plugins/telit/77-mm-telit-port-types.rules | 9 -
>  plugins/telit/mm-plugin-telit.c| 6 --
>  3 files changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/plugins/dell/77-mm-dell-port-types.rules
> b/plugins/dell/77-mm-dell-port-types.rules
> index d619456c..bbb59b92 100644
> --- a/plugins/dell/77-mm-dell-port-types.rules
> +++ b/plugins/dell/77-mm-dell-port-types.rules
> @@ -9,8 +9,7 @@ LABEL="mm_dell_vendorcheck"
>  SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*",
> ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}"
>
>  # DW5580 is a Dell-branded Telit modem
> -# tag is needed here both for dynamic port recognition and minimizing
> port probing time
> -ATTRS{idVendor}=="413c", ATTRS{idProduct}=="81ba",
> ENV{ID_MM_TELIT_TAGGED}="1"
> +# tag is needed here for dynamic port recognition
>  ATTRS{idVendor}=="413c", ATTRS{idProduct}=="81ba",
> ENV{ID_MM_TELIT_PORTS_TAGGED}="1"
>
>  GOTO="mm_dell_port_types_end"
> diff --git a/plugins/telit/77-mm-telit-port-types.rules
> b/plugins/telit/77-mm-telit-port-types.rules
> index 1b58a3d9..01538cb6 100644
> --- a/plugins/telit/77-mm-telit-port-types.rules
> +++ b/plugins/telit/77-mm-telit-port-types.rules
> @@ -10,45 +10,36 @@ SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*",
> ENV{.MM_USBIFNUM}="$attr{bInte
>  # UC864-E, UC864-E-AUTO, UC864-K, UC864-WD, UC864-WDU
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003",
> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003",
> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003",
> ENV{ID_MM_TELIT_TAGGED}="1"
>
>  # UC864-G
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004",
> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004",
> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004",
> ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004",
> ENV{ID_MM_TELIT_TAGGED}="1"
>
>  # CC864-DUAL
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005",
> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005",
> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005",
> ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005",
> ENV{ID_MM_TELIT_TAGGED}="1"
>
>  # CC864-SINGLE, CC864-KPS
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006",
> ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006",
> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006",
> ENV{ID_MM_TELIT_TAGGED}="1"
>
>  # DE910-DUAL
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010",
> ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010",
> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010",
> ENV{.MM_USBIFNUM}=="03", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010",
> ENV{ID_MM_TELIT_TAGGED}="1"
>
>  # CE910-DUAL
>  ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1011",
> ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
> -ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1011",
> ENV{ID_MM_TELIT_TAGGED}="1"
>
>  # HE910, UE910, UL865 (dynamic port identification supported)
> -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",
> 

Re: [PATCH] Huawei: Ignore unsolicited message ^EONS

[Riccardo Vangelisti]

Ops, sorry :)


Il 24/03/2017 15:28, Aleksander Morgado ha scritto:

Hey Riccardo,

On Fri, Mar 24, 2017 at 3:03 PM, Riccardo Vangelisti
 wrote:

Hi, I've found an unsolicited message (^EONS) that broke the incoming voice
call in Huawei ME909s-120 modules.
This patch can fix it (simply ignore it).


Could you make sure the patch applies in top of git master and re-send
it in a way I can easily import it? (e.g. git send-email or git
format-patch)

it's currently giving me an error when applying:

$ git am /home/aleksander/\[PATCH\]\ Huawei\:\ Ignore\ unsolicited\
message\ \^EONS.eml
Applying: Huawei: Ignore unsolicited message ^EONS
error: corrupt patch at line 16
Patch failed at 0001 Huawei: Ignore unsolicited message ^EONS
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


From 97891e3eea4d5c25d1e185193e24b5387892673d Mon Sep 17 00:00:00 2001
From: Riccardo Vangelisti 
Date: Fri, 24 Mar 2017 15:35:25 +0100
Subject: [PATCH] Huawei: Ignore unsolicited message ^EONS

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

diff --git a/plugins/huawei/mm-broadband-modem-huawei.c 
b/plugins/huawei/mm-broadband-modem-huawei.c
index 0e375e1..4b6ba90 100644
--- a/plugins/huawei/mm-broadband-modem-huawei.c
+++ b/plugins/huawei/mm-broadband-modem-huawei.c
@@ -110,6 +110,7 @@ struct _MMBroadbandModemHuaweiPrivate {
 GRegex *cend_regex;
 GRegex *ddtmf_regex;
 GRegex *cschannelinfo_regex;
+GRegex *eons_regex;
 
 /* Regex to ignore */
 GRegex *boot_regex;
@@ -3149,6 +3150,12 @@ set_voice_unsolicited_events_handlers 
(MMBroadbandModemHuawei *self,
 port,
 self->priv->cschannelinfo_regex,
 NULL, NULL, NULL);
+
+/* Ignore this message (Huawei ME909s-120 firmware. 23.613.61.00.00) */
+mm_port_serial_at_add_unsolicited_msg_handler (
+port,
+self->priv->eons_regex,
+NULL, NULL, NULL);
 }
 
 g_list_free_full (ports, (GDestroyNotify)g_object_unref);
@@ -4474,6 +4481,13 @@ mm_broadband_modem_huawei_init (MMBroadbandModemHuawei 
*self)
 self->priv->cschannelinfo_regex = g_regex_new 
("\\r\\n\\^CSCHANNELINFO:\\s*(\\d+),(\\d+)\\r\\n",
 G_REGEX_RAW | 
G_REGEX_OPTIMIZE, 0, NULL);
 
+/* Voice: Unknown message that's broke ATA command
+ * ^EONS:
+ */
+self->priv->eons_regex = g_regex_new ("\\r\\n\\^EONS:\\s*(\\d+)\\r\\n",
+G_REGEX_RAW | 
G_REGEX_OPTIMIZE, 0, NULL);
+
+
 
 self->priv->ndisdup_support = FEATURE_SUPPORT_UNKNOWN;
 self->priv->rfswitch_support = FEATURE_SUPPORT_UNKNOWN;
@@ -4529,6 +4543,7 @@ finalize (GObject *object)
 g_regex_unref (self->priv->cend_regex);
 g_regex_unref (self->priv->ddtmf_regex);
 g_regex_unref (self->priv->cschannelinfo_regex);
+g_regex_unref (self->priv->eons_regex);
 
 if (self->priv->syscfg_supported_modes)
 g_array_unref (self->priv->syscfg_supported_modes);
-- 
2.11.0

___
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 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] Huawei: Ignore unsolicited message ^EONS

[Aleksander Morgado]

Hey Riccardo,

On Fri, Mar 24, 2017 at 3:03 PM, Riccardo Vangelisti
 wrote:
> Hi, I've found an unsolicited message (^EONS) that broke the incoming voice
> call in Huawei ME909s-120 modules.
> This patch can fix it (simply ignore it).
>

Could you make sure the patch applies in top of git master and re-send
it in a way I can easily import it? (e.g. git send-email or git
format-patch)

it's currently giving me an error when applying:

$ git am /home/aleksander/\[PATCH\]\ Huawei\:\ Ignore\ unsolicited\
message\ \^EONS.eml
Applying: Huawei: Ignore unsolicited message ^EONS
error: corrupt patch at line 16
Patch failed at 0001 Huawei: Ignore unsolicited message ^EONS
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


> diff --git a/plugins/huawei/mm-broadband-modem-huawei.c
> b/plugins/huawei/mm-broadband-modem-huawei.c
> index 0e375e1..4b6ba90 100644
> --- a/plugins/huawei/mm-broadband-modem-huawei.c
> +++ b/plugins/huawei/mm-broadband-modem-huawei.c
> @@ -110,6 +110,7 @@ struct _MMBroadbandModemHuaweiPrivate {
>  GRegex *cend_regex;
>  GRegex *ddtmf_regex;
>  GRegex *cschannelinfo_regex;
> +GRegex *eons_regex;
>
>  /* Regex to ignore */
>  GRegex *boot_regex;
> @@ -3149,6 +3150,12 @@ set_voice_unsolicited_events_handlers
> (MMBroadbandModemHuawei *self,
>  port,
>  self->priv->cschannelinfo_regex,
>  NULL, NULL, NULL);
> +
> +/* Ignore this message (Huawei ME909s-120 firmware.
> 23.613.61.00.00) */
> +mm_port_serial_at_add_unsolicited_msg_handler (
> +port,
> +self->priv->eons_regex,
> +NULL, NULL, NULL);
>  }
>
>  g_list_free_full (ports, (GDestroyNotify)g_object_unref);
> @@ -4474,6 +4481,13 @@ mm_broadband_modem_huawei_init
> (MMBroadbandModemHuawei *self)
>  self->priv->cschannelinfo_regex = g_regex_new
> ("\\r\\n\\^CSCHANNELINFO:\\s*(\\d+),(\\d+)\\r\\n",
>  G_REGEX_RAW |
> G_REGEX_OPTIMIZE, 0, NULL);
>
> +/* Voice: Unknown message that's broke ATA command
> + * ^EONS:
> + */
> +self->priv->eons_regex = g_regex_new ("\\r\\n\\^EONS:\\s*(\\d+)\\r\\n",
> +G_REGEX_RAW |
> G_REGEX_OPTIMIZE, 0, NULL);
> +
> +
>
>  self->priv->ndisdup_support = FEATURE_SUPPORT_UNKNOWN;
>  self->priv->rfswitch_support = FEATURE_SUPPORT_UNKNOWN;
> @@ -4529,6 +4543,7 @@ finalize (GObject *object)
>  g_regex_unref (self->priv->cend_regex);
>  g_regex_unref (self->priv->ddtmf_regex);
>  g_regex_unref (self->priv->cschannelinfo_regex);
> +g_regex_unref (self->priv->eons_regex);
>
>  if (self->priv->syscfg_supported_modes)
>  g_array_unref (self->priv->syscfg_supported_modes);
>
>
> --
>
> *Riccardo Vangelisti*
>
> Software Design Engineering Dept.
>
> *SADEL S.p.A*
>
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel



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

[PATCH] Huawei: Ignore unsolicited message ^EONS

[Riccardo Vangelisti]

Hi, I've found an unsolicited message (^EONS) that broke the incoming 
voice call in Huawei ME909s-120 modules.

This patch can fix it (simply ignore it).

diff --git a/plugins/huawei/mm-broadband-modem-huawei.c 
b/plugins/huawei/mm-broadband-modem-huawei.c

index 0e375e1..4b6ba90 100644
--- a/plugins/huawei/mm-broadband-modem-huawei.c
+++ b/plugins/huawei/mm-broadband-modem-huawei.c
@@ -110,6 +110,7 @@ struct _MMBroadbandModemHuaweiPrivate {
 GRegex *cend_regex;
 GRegex *ddtmf_regex;
 GRegex *cschannelinfo_regex;
+GRegex *eons_regex;

 /* Regex to ignore */
 GRegex *boot_regex;
@@ -3149,6 +3150,12 @@ set_voice_unsolicited_events_handlers 
(MMBroadbandModemHuawei *self,

 port,
 self->priv->cschannelinfo_regex,
 NULL, NULL, NULL);
+
+/* Ignore this message (Huawei ME909s-120 firmware. 
23.613.61.00.00) */

+mm_port_serial_at_add_unsolicited_msg_handler (
+port,
+self->priv->eons_regex,
+NULL, NULL, NULL);
 }

 g_list_free_full (ports, (GDestroyNotify)g_object_unref);
@@ -4474,6 +4481,13 @@ mm_broadband_modem_huawei_init 
(MMBroadbandModemHuawei *self)
 self->priv->cschannelinfo_regex = g_regex_new 
("\\r\\n\\^CSCHANNELINFO:\\s*(\\d+),(\\d+)\\r\\n",
 G_REGEX_RAW | 
G_REGEX_OPTIMIZE, 0, NULL);


+/* Voice: Unknown message that's broke ATA command
+ * ^EONS:
+ */
+self->priv->eons_regex = g_regex_new ("\\r\\n\\^EONS:\\s*(\\d+)\\r\\n",
+G_REGEX_RAW | 
G_REGEX_OPTIMIZE, 0, NULL);

+
+

 self->priv->ndisdup_support = FEATURE_SUPPORT_UNKNOWN;
 self->priv->rfswitch_support = FEATURE_SUPPORT_UNKNOWN;
@@ -4529,6 +4543,7 @@ finalize (GObject *object)
 g_regex_unref (self->priv->cend_regex);
 g_regex_unref (self->priv->ddtmf_regex);
 g_regex_unref (self->priv->cschannelinfo_regex);
+g_regex_unref (self->priv->eons_regex);

 if (self->priv->syscfg_supported_modes)
 g_array_unref (self->priv->syscfg_supported_modes);


--

*Riccardo Vangelisti*

Software Design Engineering Dept.

*SADEL S.p.A*

___
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

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 2:57 PM, Carlo Lobrano  wrote:
>> 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?
>
> this shouldn't happen. How do you switch to MBIM mode?

at@usbmwtestfw:usb_profile_set_nvm_configuration(...


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

[PATCH] broadband-bearer: set TTY as connected as soon as ATD replies

[Aleksander Morgado]

When the connection request is done via ATD, flag the port as
connected as soon as the successful response is received, so that we
remove our polling on the device right away.

https://bugs.freedesktop.org/show_bug.cgi?id=99541
---

Hey Colin, Dan & everyone,

This patch tries to minimize the possibility of a race condition happening when 
we end up sending AT commands (e.g. signal quality loading request) between a 
successful reply to ATD, and the actual setting of the TTY as 'connected', 
which is done in an idle.

This was discussed not long ago:
https://lists.freedesktop.org/archives/modemmanager-devel/2017-January/003773.html

Comments?

---
 src/mm-broadband-bearer.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/mm-broadband-bearer.c b/src/mm-broadband-bearer.c
index f2834b1b..bb4ff567 100644
--- a/src/mm-broadband-bearer.c
+++ b/src/mm-broadband-bearer.c
@@ -254,7 +254,10 @@ dial_cdma_ready (MMBaseModem *modem,
 return;
 }

-/* else... Yuhu! */
+/* The ATD command has succeeded, and therefore the TTY is in data mode 
now.
+ * Instead of waiting for setting the port as connected later in
+ * connect_succeeded(), we do it right away so that we stop our polling. */
+mm_port_set_connected (ctx->data, TRUE);

 /* Keep port open during connection */
 ctx->close_data_on_exit = FALSE;
@@ -573,6 +576,11 @@ atd_ready (MMBaseModem *modem,
 return;
 }

+/* The ATD command has succeeded, and therefore the TTY is in data mode 
now.
+ * Instead of waiting for setting the port as connected later in
+ * connect_succeeded(), we do it right away so that we stop our polling. */
+mm_port_set_connected (MM_PORT (ctx->dial_port), TRUE);
+
 g_simple_async_result_set_op_res_gpointer (ctx->result,
g_object_ref (ctx->dial_port),
(GDestroyNotify)g_object_unref);
@@ -1177,7 +1185,8 @@ connect_succeeded (ConnectContext *ctx,
 ctx->self->priv->port = g_object_ref (mm_bearer_connect_result_peek_data 
(result));
 ctx->self->priv->connection_type = connection_type;

-/* Port is connected; update the state */
+/* Port is connected; update the state. For ATD based connections, the port
+ * may already be set as connected, but no big deal. */
 mm_port_set_connected (ctx->self->priv->port, TRUE);

 /* Set operation result */
--
2.12.0
___
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

[Carlo Lobrano]

Hi Aleksander,

> 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?

this shouldn't happen. How do you switch to MBIM mode?

Carlo

Il venerdì 24 marzo 2017, Aleksander Morgado  ha
scritto:

> 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?
>
> 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?
>
> 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

[PATCH] base-bearer: stop connection status monitoring if no TTY available

[Aleksander Morgado]

On modems with a single TTY for both control and data, we cannot use
the TTY to load connection status once we're in connected mode:

Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#'
(ttyUSB2): <-- 'CONNECT 1'
(ttyUSB2): port now connected
Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> 
connected)
Simple connect state (8/8): All done
checking if connected failed: Couldn't check current list of active PDP 
contexts: No AT port available to run command
checking if connected failed: Couldn't check current list of active PDP 
contexts: No AT port available to run command
checking if connected failed: Couldn't check current list of active PDP 
contexts: No AT port available to run command
...

So, disable connection monitoring right away if that situation is
detected:

Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#'
(ttyUSB2): <-- 'CONNECT 1'
(ttyUSB2): port now connected
Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> 
connected)
Simple connect state (8/8): All done
Connection monitoring is unsupported by the device
...

https://bugs.freedesktop.org/show_bug.cgi?id=100376
---

Hey everyone,

Plugins can now report a MM_CORE_UNSUPPORTED error in load_connection_status() 
in order to instruct the upper layers to stop doing the connection status 
monitoring for the current connection. This is implemented in the generic 
broadband bearer for the specific case of single-TTY modems, where the control 
TTY can no longer be used for AT commands once it gets in connected mode.

Comments?

---
 src/mm-base-bearer.c  | 20 ++--
 src/mm-broadband-bearer.c | 43 +--
 2 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/src/mm-base-bearer.c b/src/mm-base-bearer.c
index 0cca8534..02084dff 100644
--- a/src/mm-base-bearer.c
+++ b/src/mm-base-bearer.c
@@ -92,6 +92,8 @@ struct _MMBaseBearerPrivate {

 /* Connection status monitoring */
 guint connection_monitor_id;
+/* Flag to specify whether connection monitoring is supported or not */
+gboolean load_connection_status_unsupported;

 /*-- 3GPP specific --*/
 guint deferred_3gpp_unregistration_id;
@@ -162,7 +164,18 @@ load_connection_status_ready (MMBaseBearer *self,

 status = MM_BASE_BEARER_GET_CLASS (self)->load_connection_status_finish 
(self, res, );
 if (status == MM_BEARER_CONNECTION_STATUS_UNKNOWN) {
-mm_warn ("checking if connected failed: %s", error->message);
+/* Only warn if not reporting an "unsupported" error */
+if (!g_error_matches (error, MM_CORE_ERROR, 
MM_CORE_ERROR_UNSUPPORTED)) {
+mm_warn ("checking if connected failed: %s", error->message);
+g_error_free (error);
+return;
+}
+
+/* If we're being told that connection monitoring is unsupported, just
+ * ignore the error and remove the timeout. */
+mm_dbg ("Connection monitoring is unsupported by the device");
+self->priv->load_connection_status_unsupported = TRUE;
+connection_monitor_stop (self);
 g_error_free (error);
 return;
 }
@@ -176,7 +189,7 @@ load_connection_status_ready (MMBaseBearer *self,
 static gboolean
 connection_monitor_cb (MMBaseBearer *self)
 {
-/* If the implementation knows how to update stat values, run it */
+/* If the implementation knows how to load connection status, run it */
 MM_BASE_BEARER_GET_CLASS (self)->load_connection_status (
 self,
 (GAsyncReadyCallback)load_connection_status_ready,
@@ -192,6 +205,9 @@ connection_monitor_start (MMBaseBearer *self)
 !MM_BASE_BEARER_GET_CLASS (self)->load_connection_status_finish)
 return;

+if (self->priv->load_connection_status_unsupported)
+return;
+
 /* Schedule */
 g_assert (!self->priv->connection_monitor_id);
 self->priv->connection_monitor_id = g_timeout_add_seconds 
(BEARER_CONNECTION_MONITOR_TIMEOUT,
diff --git a/src/mm-broadband-bearer.c b/src/mm-broadband-bearer.c
index 1188f60a..f2834b1b 100644
--- a/src/mm-broadband-bearer.c
+++ b/src/mm-broadband-bearer.c
@@ -1983,30 +1983,45 @@ load_connection_status (MMBaseBearer*self,
 GAsyncReadyCallback  callback,
 gpointer user_data)
 {
-GTask   *task;
-MMBaseModem *modem = NULL;
+GTask  *task;
+MMBaseModem*modem = NULL;
+MMPortSerialAt *port;

 task = g_task_new (self, NULL, callback, user_data);

+g_object_get (MM_BASE_BEARER (self),
+  MM_BASE_BEARER_MODEM, ,
+  NULL);
+
+/* If CID not defined, error out */
 

[PATCH] telit: don't require udev tags to bind devices

[Aleksander Morgado]

The vendor id/string based rules should already be enough to get the
telit plugin bind telit devices.

This simplifies support for future Telit devices, as we wouldn't need
any additional change in the plugin. It also helps when working with
RS232 devices as the user wouldn't need to add the explicit tag to get
the devices bound to this plugin.

https://bugs.freedesktop.org/show_bug.cgi?id=100373
---

Hey Carlo & Daniele,

This patch removes the need of having an explicit ID_MM_TELIT_TAGGED to flag 
those devices that may be grabbed by the Telit plugin.

Could you test it with your devices to see if it works as expected?

---
 plugins/dell/77-mm-dell-port-types.rules   | 3 +--
 plugins/telit/77-mm-telit-port-types.rules | 9 -
 plugins/telit/mm-plugin-telit.c| 6 --
 3 files changed, 1 insertion(+), 17 deletions(-)

diff --git a/plugins/dell/77-mm-dell-port-types.rules 
b/plugins/dell/77-mm-dell-port-types.rules
index d619456c..bbb59b92 100644
--- a/plugins/dell/77-mm-dell-port-types.rules
+++ b/plugins/dell/77-mm-dell-port-types.rules
@@ -9,8 +9,7 @@ LABEL="mm_dell_vendorcheck"
 SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*", 
ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}"

 # DW5580 is a Dell-branded Telit modem
-# tag is needed here both for dynamic port recognition and minimizing port 
probing time
-ATTRS{idVendor}=="413c", ATTRS{idProduct}=="81ba", ENV{ID_MM_TELIT_TAGGED}="1"
+# tag is needed here for dynamic port recognition
 ATTRS{idVendor}=="413c", ATTRS{idProduct}=="81ba", 
ENV{ID_MM_TELIT_PORTS_TAGGED}="1"

 GOTO="mm_dell_port_types_end"
diff --git a/plugins/telit/77-mm-telit-port-types.rules 
b/plugins/telit/77-mm-telit-port-types.rules
index 1b58a3d9..01538cb6 100644
--- a/plugins/telit/77-mm-telit-port-types.rules
+++ b/plugins/telit/77-mm-telit-port-types.rules
@@ -10,45 +10,36 @@ SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*", 
ENV{.MM_USBIFNUM}="$attr{bInte
 # UC864-E, UC864-E-AUTO, UC864-K, UC864-WD, UC864-WDU
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003", ENV{.MM_USBIFNUM}=="00", 
ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003", ENV{.MM_USBIFNUM}=="02", 
ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
-ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1003", ENV{ID_MM_TELIT_TAGGED}="1"

 # UC864-G
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004", ENV{.MM_USBIFNUM}=="00", 
ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004", ENV{.MM_USBIFNUM}=="02", 
ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004", ENV{.MM_USBIFNUM}=="03", 
ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
-ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1004", ENV{ID_MM_TELIT_TAGGED}="1"

 # CC864-DUAL
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005", ENV{.MM_USBIFNUM}=="00", 
ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005", ENV{.MM_USBIFNUM}=="02", 
ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005", ENV{.MM_USBIFNUM}=="03", 
ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
-ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1005", ENV{ID_MM_TELIT_TAGGED}="1"

 # CC864-SINGLE, CC864-KPS
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006", ENV{.MM_USBIFNUM}=="00", 
ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006", ENV{.MM_USBIFNUM}=="02", 
ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
-ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1006", ENV{ID_MM_TELIT_TAGGED}="1"

 # DE910-DUAL
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010", ENV{.MM_USBIFNUM}=="01", 
ENV{ID_MM_TELIT_PORT_TYPE_NMEA}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010", ENV{.MM_USBIFNUM}=="02", 
ENV{ID_MM_TELIT_PORT_TYPE_AUX}="1"
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010", ENV{.MM_USBIFNUM}=="03", 
ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
-ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1010", ENV{ID_MM_TELIT_TAGGED}="1"

 # CE910-DUAL
 ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1011", ENV{.MM_USBIFNUM}=="01", 
ENV{ID_MM_TELIT_PORT_TYPE_MODEM}="1"
-ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="1011", ENV{ID_MM_TELIT_TAGGED}="1"

 # HE910, UE910, UL865 (dynamic port identification supported)
-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"

 LABEL="mm_telit_port_types_end"
diff --git a/plugins/telit/mm-plugin-telit.c b/plugins/telit/mm-plugin-telit.c
index abb87e4f..57ecd444 100644
--- a/plugins/telit/mm-plugin-telit.c
+++ b/plugins/telit/mm-plugin-telit.c
@@ 

[PATCH] telit: support QMI and MBIM modems

[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?

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?

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

[PATCH v2] Fixed wrong MEM1 value passed to +CPMS

[Carlo Lobrano]

Let modem_messaging_set_default_storage returns with error
if current_sms_mem1_storage is MM_SMS_STORAGE_UNKNOWN

---

I updated the patch according the code review, moreover I'd like
to note a little difference respect the previous version:

currently, even if +CPMS fails because of the wrong value for
mem1, we do store "storage" as the current_sms_mem2_storage value.

 self->priv->current_sms_mem2_storage = storage;

In this patch I preferred to change this behaviour and setting default
storage for SMS mem2 only if we are actually going to set
this value on the modem.

What do you think about it?

---
 src/mm-broadband-modem.c   | 29 +++--
 src/mm-iface-modem-messaging.c |  2 +-
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
index 17b3253..0bbf626 100644
--- a/src/mm-broadband-modem.c
+++ b/src/mm-broadband-modem.c
@@ -5590,22 +5590,31 @@ modem_messaging_set_default_storage 
(MMIfaceModemMessaging *_self,
 gchar *mem1_str;
 gchar *mem_str;
 
-result = g_simple_async_result_new (G_OBJECT (self),
-callback,
-user_data,
-modem_messaging_set_default_storage);
+/* We provide the current sms storage for mem1 if not UNKNOWN */
+if (self->priv->current_sms_mem1_storage == MM_SMS_STORAGE_UNKNOWN) {
+g_simple_async_report_error_in_idle (G_OBJECT (self),
+ callback,
+ user_data,
+ MM_CORE_ERROR,
+ MM_CORE_ERROR_INVALID_ARGS,
+ "Current SMS MEM1 storage is 
UNKNOWN (SIM busy?)");
+return;
+}
 
 /* Set defaults as current */
 self->priv->current_sms_mem2_storage = storage;
 
-/* We provide the current sms storage for mem1 if not UNKNOWN */
 mem1_str = g_ascii_strup (mm_sms_storage_get_string 
(self->priv->current_sms_mem1_storage), -1);
-
 mem_str = g_ascii_strup (mm_sms_storage_get_string (storage), -1);
-cmd = g_strdup_printf ("+CPMS=\"%s\",\"%s\",\"%s\"",
-   mem1_str ? mem1_str : "",
-   mem_str,
-   mem_str);
+
+cmd = g_strdup_printf ("+CPMS=\"%s\",\"%s\",\"%s\"", mem1_str, mem_str, 
mem_str);
+
+result = g_simple_async_result_new (G_OBJECT (self),
+callback,
+user_data,
+modem_messaging_set_default_storage);
+
+
 mm_base_modem_at_command (MM_BASE_MODEM (self),
   cmd,
   3,
diff --git a/src/mm-iface-modem-messaging.c b/src/mm-iface-modem-messaging.c
index 0cff1f2..01a30f0 100644
--- a/src/mm-iface-modem-messaging.c
+++ b/src/mm-iface-modem-messaging.c
@@ -789,7 +789,7 @@ set_default_storage_ready (MMIfaceModemMessaging *self,
 GError *error = NULL;
 
 if (!MM_IFACE_MODEM_MESSAGING_GET_INTERFACE 
(self)->set_default_storage_finish (self, res, )) {
-mm_dbg ("Couldn't set default storage: '%s'", error->message);
+mm_warn ("Could not set default storage: '%s'", error->message);
 g_error_free (error);
 }
 
-- 
2.9.3

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

Re: Default "ip-type" in modem-manager "simple-connect"?

[Ajay Garg]

Thanks a ton Aleksander !!!

On Fri, Mar 24, 2017 at 2:43 PM, Aleksander Morgado <
aleksan...@aleksander.es> wrote:

> On Fri, Mar 24, 2017 at 4:20 AM, Ajay Garg  wrote:
> > If we don't specify ip-type parameter while doing a simple-connect via
> mmcli
> > (http://manpages.ubuntu.com/manpages/trusty/man8/mmcli.8.html), what is
> the
> > default parameter picked? ipv4 or ipv6? Or whatever the network offers?
>
> It defaults to IPv4
>
> --
> Aleksander
> https://aleksander.es
>



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

Re: Default "ip-type" in modem-manager "simple-connect"?

[Aleksander Morgado]

On Fri, Mar 24, 2017 at 4:20 AM, Ajay Garg  wrote:
> If we don't specify ip-type parameter while doing a simple-connect via mmcli
> (http://manpages.ubuntu.com/manpages/trusty/man8/mmcli.8.html), what is the
> default parameter picked? ipv4 or ipv6? Or whatever the network offers?

It defaults to IPv4

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