GNOME Bugzilla – Bug 697282
[MM 0.8] Use AT+CSIM to gather unlock attempts
Last modified: 2014-10-15 08:37:44 UTC
Several modems allow to use AT+CSIM to get remaining unlock retries, so probably worth adding it to the generic modem implementation. From the Sierra Wireless forum: AT+CSIM=10,”0020000100” to check PIN1 remaining unlock attempts AT+CSIM=10,”002C000100” to check PUK1 remaining unlock attempts AT+CSIM=10,"0020008100" to check PIN2 remaining unlock attempts AT+CSIM=10,"002C008100" to check PUK2 remaining unlock attempts For example: AT+CSIM =10,"0020008100" +CSIM: 4,"63C3" displays PIN2 remaining unlock attempts OK Last number shows 3 attempts left For the Sierra modems, we should actually try this one first and if unsupported fallback to AT+CPINC.
> > For example: > AT+CSIM =10,"0020008100" > +CSIM: 4,"63C3" displays PIN2 remaining unlock attempts > OK > Last number shows 3 attempts left There is something wrong with this. Here's the output I get with a MC7710: AT+CSIM=10,"0020000100" +CSIM: 4,"6A86" OK AT+CSIM=10,"002C000100" +CSIM: 4,"6A86" OK AT+CSIM=10,"0020008100" +CSIM: 4,"6A86" OK AT+CSIM=10,"002C008100" +CSIM: 4,"6A86" OK While with the newer CPINC I get the correct results: AT+CPINC? +CPINC: 3,2,10,10 OK
If I'm reading this right, the commands here are: 0020000100 (remaining PIN1) CLS = 00 INS = 20 (VERIFY) P1 = 00 P2 = 01 LEN = 00 ETSI TS 102.221 Section 10.2.1.3 table 10.9 shows SW1=63 SW2=CX and states "For the VERIFY PIN command, SW1SW2 indicates that the command was successful but the PIN was not correct and there are 'X' retries left. For all other commands it indicates the number of internal retries performed by the card to complete the command." Further, section 11.1.9.1.2 (PIN retry counter) states "The VERIFY PIN with empty data field is used to retrieve the PIN retry counter from the UICC. This function is performed whether or not the relevant PIN is disabled or blocked (e.g. by 3 consecutive wrong PIN presentations). The VERIFY PIN command is sent to the UICC with parameter P2 indicating the PIN for which the retry counter value is to be retrieved with an empty data field. The number of retries, if any, is indicated in the response by SW1 SW2 = '63CX', where X indicates the number of retries left. A VERIFY PIN command with empty data field applied to a blocked PIN shall return SW1 SW2 = '63C0' or SW1 SW2 = '6983'." The lower 5 bits of P2 indicate which access condition you want, and 01 = PIN (see Table 9.2, clause 9.5.1). The error you're getting (6A86) means "Incorrect parameters P1 to P2" (TS 102.221 Table 10.14 "Status byte coding - wrong parameters"). No idea what's going on there. 002C000100 (remaining PUK1) CLS = 00 INS = 2C (CHANGE PIN) P1 = 00 P2 = 01 LEN = 00 See section 11.1.13.1.2 (UNBLOCK PIN retry counter), which states "The UNBLOCK PIN command with empty data field is used to retrieve the UNBLOCK PIN retry counter from the UICC. This function may be performed whether or not the relevant PIN is blocked (e.g. by 3 consecutive wrong PIN presentations) and whether or not the UNBLOCK PIN is blocked. The UNBLOCK PIN command is sent to the UICC with parameter P2 indicating the PIN for which the UNBLOCK PIN retry counter value is to be retrieved with an empty data field. The number of retries, if any, is indicated in the response by SW1 SW2 ='63CX', where X indicates the number of retries left. An UNBLOCK PIN command with empty data field applied to a blocked UNBLOCK PIN shall return SW1 SW2 = '63C0' or SW1 SW2 = '6983'." But maybe we could use these commands if the other ones fail, since we know what the "success" code is.
Moving bugreport to the new ModemManager bugzilla in fd.o; summarized the issue there as well. Please subscribe to the new bugreport to get new updates. https://bugs.freedesktop.org/show_bug.cgi?id=85037 Closing this report as NOTGNOME.