<div dir="ltr"><div>> 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. </div>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. </div> <div class="gmail_quote"><div dir="ltr">On Thu, 16 Mar 2017 at 11:17 Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Mar 16, 2017 at 10:58 AM, Carlo Lobrano <<a href="mailto:c.lobrano@gmail.com" class="gmail_msg" target="_blank">c.lobrano@gmail.com</a>> 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 <a href="https://aleksander.es" rel="noreferrer" class="gmail_msg" target="_blank">https://aleksander.es</a> </blockquote></div>