Re: [PATCH v2] telit: lock/unlock CSIM operations by default

2017-03-16 Thread Carlo Lobrano 
> Is this extra "#QSS: 1" indication maybe a way the modem has to say
> "SIM ready" when it has been configured with "#QSS=1" instead of
> #QSS=2? If it happens just after SIM-PIN unlock, it could very well
> be.

I think the same, but it shouldn't do it. #QSS: 0/1 are for physical
changes on SIM, #QSS: 2 should be for SIM unlock, but we're not listening
to it.

On Thu, 16 Mar 2017 at 11:17 Aleksander Morgado 
wrote:

> On Thu, Mar 16, 2017 at 10:58 AM, Carlo Lobrano 
> wrote:
> > Sorry for the late reply, but I was double checking this change because
> of
> > the last paragraph in +CSIM reference:
> >
> >> After the locking of the SIM-ME interface (AT+CSIM=1) the SIM will be
> >> accessible only by AT+CSIM commands (#QSS: 0). The GSM and GPRS services
> >> will be automatically de-registered to avoid the TE commands alter the
> GSM
> >> application. They will be automatically reconditioned after the
> unlocking
> >> of the
> >> SIM-ME interface. After the unlocking of the SIM-ME interface if PIN is
> >> required
> >> it will be necessary to enter it another time.
> >
> > But this does not seems to affect the behaviour of the modem, which still
> > works fine.
> > In my environment I can't reproduce the issue this patch fixes (tty
> locked),
> > but I do not see any side effect, so for me it's ok.
> >
> >
>
> Good!
>
> > But, while this patch does not cause regression, I did observe a problem
> > testing this use case: when SIM is locked and then unlocked, with SIM hot
> > swap enabled, we receive an unsolicited "#QSS: 1", which is not related
> to
> > any physical SIM insertion, and release the modem:
> >
> >
> > mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): -->
> 'AT+CSQ'
> > mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): <--
> ''
> > mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): <-- '+CSQ:
> > 9,4OK'
> > mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0) device open
> count
> > is 3 (close)
> > mar 16 09:55:00 d2092 ModemManager[542]:  Modem
> > /org/freedesktop/ModemManager1/Modem/0: signal quality updated (29)
> > mar 16 09:55:00 d2092 ModemManager[542]:  Periodic signal quality
> > checks rescheduled (interval = 30s)
> > mar 16 09:55:02 d2092 ModemManager[542]:  (ttyACM3): <--
> > '+CIEV: service,1'
> > mar 16 09:55:02 d2092 ModemManager[542]:  (ttyACM3): <--
> > '+CIEV: roam,0'
> > mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0) device open
> count
> > is 4 (open)
> > mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): -->
> > 'AT+CCLK?'
> > mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): <--
> ''
> > mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): <-- '+CCLK:
> > "17/03/16,09:55:05+04"OK'
> > mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0) device open
> count
> > is 3 (close)
> > mar 16 09:55:09 d2092 ModemManager[542]:  (ttyACM3): <--
> > '#QSS: 1'
> > mar 16 09:55:09 d2092 ModemManager[542]:   QSS: SIM inserted
> > mar 16 09:55:09 d2092 ModemManager[542]:  Releasing SIM hot swap
> > ports context
> >
> > This happens with master ModemManger too.
> >
> > I'm working on this now, probably a solution would be to borrow
> Aleksander
> > patch about #QSS: 3, in order to keep an internal state of the SIM
> presence
> > and just ignore #QSS: 1 when we already know that SIM is inserted.
>
> Is this extra "#QSS: 1" indication maybe a way the modem has to say
> "SIM ready" when it has been configured with "#QSS=1" instead of
> #QSS=2? If it happens just after SIM-PIN unlock, it could very well
> be.
>
> --
> Aleksander
> https://aleksander.es
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH v2] telit: lock/unlock CSIM operations by default

2017-03-16 Thread Aleksander Morgado 
On Thu, Mar 16, 2017 at 10:58 AM, Carlo Lobrano  wrote:
> Sorry for the late reply, but I was double checking this change because of
> the last paragraph in +CSIM reference:
>
>> After the locking of the SIM-ME interface (AT+CSIM=1) the SIM will be
>> accessible only by AT+CSIM commands (#QSS: 0). The GSM and GPRS services
>> will be automatically de-registered to avoid the TE commands alter the GSM
>> application. They will be automatically reconditioned after the unlocking
>> of the
>> SIM-ME interface. After the unlocking of the SIM-ME interface if PIN is
>> required
>> it will be necessary to enter it another time.
>
> But this does not seems to affect the behaviour of the modem, which still
> works fine.
> In my environment I can't reproduce the issue this patch fixes (tty locked),
> but I do not see any side effect, so for me it's ok.
>
>

Good!

> But, while this patch does not cause regression, I did observe a problem
> testing this use case: when SIM is locked and then unlocked, with SIM hot
> swap enabled, we receive an unsolicited "#QSS: 1", which is not related to
> any physical SIM insertion, and release the modem:
>
>
> mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): --> 'AT+CSQ'
> mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): <-- ''
> mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): <-- '+CSQ:
> 9,4OK'
> mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0) device open count
> is 3 (close)
> mar 16 09:55:00 d2092 ModemManager[542]:  Modem
> /org/freedesktop/ModemManager1/Modem/0: signal quality updated (29)
> mar 16 09:55:00 d2092 ModemManager[542]:  Periodic signal quality
> checks rescheduled (interval = 30s)
> mar 16 09:55:02 d2092 ModemManager[542]:  (ttyACM3): <--
> '+CIEV: service,1'
> mar 16 09:55:02 d2092 ModemManager[542]:  (ttyACM3): <--
> '+CIEV: roam,0'
> mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0) device open count
> is 4 (open)
> mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): -->
> 'AT+CCLK?'
> mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): <-- ''
> mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): <-- '+CCLK:
> "17/03/16,09:55:05+04"OK'
> mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0) device open count
> is 3 (close)
> mar 16 09:55:09 d2092 ModemManager[542]:  (ttyACM3): <--
> '#QSS: 1'
> mar 16 09:55:09 d2092 ModemManager[542]:   QSS: SIM inserted
> mar 16 09:55:09 d2092 ModemManager[542]:  Releasing SIM hot swap
> ports context
>
> This happens with master ModemManger too.
>
> I'm working on this now, probably a solution would be to borrow Aleksander
> patch about #QSS: 3, in order to keep an internal state of the SIM presence
> and just ignore #QSS: 1 when we already know that SIM is inserted.

Is this extra "#QSS: 1" indication maybe a way the modem has to say
"SIM ready" when it has been configured with "#QSS=1" instead of
#QSS=2? If it happens just after SIM-PIN unlock, it could very well
be.

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

Re: [PATCH v2] telit: lock/unlock CSIM operations by default

2017-03-16 Thread Carlo Lobrano 
Hi all,

Sorry for the late reply, but I was double checking this change because of
the last paragraph in +CSIM reference:

> After the locking of the SIM-ME interface (AT+CSIM=1) the SIM will be
> accessible only by AT+CSIM commands (#QSS: 0). The GSM and GPRS services
> will be automatically de-registered to avoid the TE commands alter the GSM
> application. They will be automatically reconditioned after the unlocking
of the
> SIM-ME interface. After the unlocking of the SIM-ME interface if PIN is
required
> it will be necessary to enter it another time.

But this does not seems to affect the behaviour of the modem, which still
works fine.
In my environment I can't reproduce the issue this patch fixes (tty
locked), but I do not see any side effect, so for me it's ok.


But, while this patch does not cause regression, I did observe a problem
testing this use case: when SIM is locked and then unlocked, with SIM hot
swap enabled, we receive an unsolicited "#QSS: 1", which is not related to
any physical SIM insertion, and release the modem:


mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): --> 'AT+CSQ'
mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): <-- ''
mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0): <-- '+CSQ:
9,4OK'
mar 16 09:55:00 d2092 ModemManager[542]:  (ttyACM0) device open
count is 3 (close)
mar 16 09:55:00 d2092 ModemManager[542]:  Modem
/org/freedesktop/ModemManager1/Modem/0: signal quality updated (29)
mar 16 09:55:00 d2092 ModemManager[542]:  Periodic signal quality
checks rescheduled (interval = 30s)
mar 16 09:55:02 d2092 ModemManager[542]:  (ttyACM3): <--
'+CIEV: service,1'
mar 16 09:55:02 d2092 ModemManager[542]:  (ttyACM3): <--
'+CIEV: roam,0'
mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0) device open
count is 4 (open)
mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): -->
'AT+CCLK?'
mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): <-- ''
mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0): <-- '+CCLK:
"17/03/16,09:55:05+04"OK'
mar 16 09:55:05 d2092 ModemManager[542]:  (ttyACM0) device open
count is 3 (close)
mar 16 09:55:09 d2092 ModemManager[542]:  (ttyACM3): <--
'#QSS: 1'
mar 16 09:55:09 d2092 ModemManager[542]:   QSS: SIM inserted
mar 16 09:55:09 d2092 ModemManager[542]:  Releasing SIM hot swap
ports context

This happens with master ModemManger too.

I'm working on this now, probably a solution would be to borrow Aleksander
patch about #QSS: 3, in order to keep an internal state of the SIM presence
and just ignore #QSS: 1 when we already know that SIM is inserted.




On Wed, 15 Mar 2017 at 23:49 Aleksander Morgado 
wrote:

Wrap the AT+CSIM=XX commands between lock (CSIM=1) and
unlock (CSIM=0) operations.

This seems to avoid the TTY lockup seen in several different Telit
modules.

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

Reported-by: Penalva, Salvador 
---

Hey Dan & everyone,

This v2 just adds a NOTE at the beginning of the section specifying that
the UNLOCK step must always be run if LOCK is run.

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

diff --git a/plugins/telit/mm-broadband-modem-telit.c
b/plugins/telit/mm-broadband-modem-telit.c
index b1679ae4..6ef340f1 100644
--- a/plugins/telit/mm-broadband-modem-telit.c
+++ b/plugins/telit/mm-broadband-modem-telit.c
@@ -450,8 +450,17 @@ modem_load_supported_bands (MMIfaceModem *self,
 }

 /*/
-/* Load unlock retries (Modem interface) */
+/* Load unlock retries (Modem interface)
+ *
+ * NOTE: the logic must make sure that LOAD_UNLOCK_RETRIES_STEP_UNLOCK is
always
+ * run if LOAD_UNLOCK_RETRIES_STEP_LOCK has been run. Currently, the logic
just
+ * runs all intermediate steps ignoring errors (i.e. not completing the
+ * operation if something fails), so the LOAD_UNLOCK_RETRIES_STEP_UNLOCK is
+ * always run.
+ */

+#define CSIM_LOCK_STR   "+CSIM=1"
+#define CSIM_UNLOCK_STR "+CSIM=0"
 #define CSIM_QUERY_PIN_RETRIES_STR  "+CSIM=10,002100"
 #define CSIM_QUERY_PUK_RETRIES_STR  "+CSIM=10,002C000100"
 #define CSIM_QUERY_PIN2_RETRIES_STR "+CSIM=10,0020008100"
@@ -460,10 +469,12 @@ modem_load_supported_bands (MMIfaceModem *self,

 typedef enum {
 LOAD_UNLOCK_RETRIES_STEP_FIRST,
+LOAD_UNLOCK_RETRIES_STEP_LOCK,
 LOAD_UNLOCK_RETRIES_STEP_PIN,
 LOAD_UNLOCK_RETRIES_STEP_PUK,
 LOAD_UNLOCK_RETRIES_STEP_PIN2,
 LOAD_UNLOCK_RETRIES_STEP_PUK2,
+LOAD_UNLOCK_RETRIES_STEP_UNLOCK,
 LOAD_UNLOCK_RETRIES_STEP_LAST
 } LoadUnlockRetriesStep;

@@ -500,6 +511,25 @@ modem_load_unlock_retries_finish (MMIfaceModem *self,
 }

 static void
+csim_unlock_ready (MMBaseModem  *self,
+   GAsyncResult *res,
+   LoadUnlockRetriesContext *ctx)
+{
+const gchar *response;
+GError  *error = NULL;
+
+/*