[PATCH v2] telit: lock/unlock CSIM operations by default
Carlo Lobrano
c.lobrano at gmail.com
Thu Mar 16 10:19:47 UTC 2017
> 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 <aleksander at aleksander.es>
wrote:
> On Thu, Mar 16, 2017 at 10:58 AM, Carlo Lobrano <c.lobrano at gmail.com>
> 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]: <debug> (ttyACM0): -->
> 'AT+CSQ<CR>'
> > mar 16 09:55:00 d2092 ModemManager[542]: <debug> (ttyACM0): <--
> '<CR><LF>'
> > mar 16 09:55:00 d2092 ModemManager[542]: <debug> (ttyACM0): <-- '+CSQ:
> > 9,4<CR><LF><CR><LF>OK<CR><LF>'
> > mar 16 09:55:00 d2092 ModemManager[542]: <debug> (ttyACM0) device open
> count
> > is 3 (close)
> > mar 16 09:55:00 d2092 ModemManager[542]: <debug> Modem
> > /org/freedesktop/ModemManager1/Modem/0: signal quality updated (29)
> > mar 16 09:55:00 d2092 ModemManager[542]: <debug> Periodic signal quality
> > checks rescheduled (interval = 30s)
> > mar 16 09:55:02 d2092 ModemManager[542]: <debug> (ttyACM3): <--
> > '<CR><LF>+CIEV: service,1<CR><LF>'
> > mar 16 09:55:02 d2092 ModemManager[542]: <debug> (ttyACM3): <--
> > '<CR><LF>+CIEV: roam,0<CR><LF>'
> > mar 16 09:55:05 d2092 ModemManager[542]: <debug> (ttyACM0) device open
> count
> > is 4 (open)
> > mar 16 09:55:05 d2092 ModemManager[542]: <debug> (ttyACM0): -->
> > 'AT+CCLK?<CR>'
> > mar 16 09:55:05 d2092 ModemManager[542]: <debug> (ttyACM0): <--
> '<CR><LF>'
> > mar 16 09:55:05 d2092 ModemManager[542]: <debug> (ttyACM0): <-- '+CCLK:
> > "17/03/16,09:55:05+04"<CR><LF><CR><LF>OK<CR><LF>'
> > mar 16 09:55:05 d2092 ModemManager[542]: <debug> (ttyACM0) device open
> count
> > is 3 (close)
> > mar 16 09:55:09 d2092 ModemManager[542]: <debug> (ttyACM3): <--
> > '<CR><LF>#QSS: 1<CR><LF>'
> > mar 16 09:55:09 d2092 ModemManager[542]: <info> QSS: SIM inserted
> > mar 16 09:55:09 d2092 ModemManager[542]: <debug> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170316/b5781a1a/attachment.html>
More information about the ModemManager-devel
mailing list