Re: ModemManager: [PATCH 1/2] Improvements to SIM PIN handling

[Eric Shienbrood <ers google com>]

Back from vacation, catching up...

On Wed, Oct 26, 2011 at 8:44 PM, Dan Williams <dcbw redhat com> wrote:

On Wed, 2011-10-19 at 15:42 -0400, Eric Shienbrood wrote:

I wonder if we shouldn't keep the change/disable retries separate from
the unlock retries though.  I'm not 100% comfortable with having a
situation where UnlockRetries means one thing if UnlockRequired is this,
and another thing if it's this other thing.  These two operations
(change/disable) don't block the modem from operating, so they are in a
second class.  Which probably merit their own properties instead?

I don't see in what way UnlockRetries means two different things. I thought it just meant the number of retries before the next level of security kicks in. If you enter the SIM PIN incorrectly three times, whether it's for unlock, change, or enable/disable, then the SIM becomes locked and requires the PUK to be entered to unlock it. As far as I can tell from the modems I've tested on, there's no concept of ChangeRetries vs. UnlockRetries, there's just Retries. In other words, the effect of entering the PIN incorrectly three times is the same in all cases - the modem won't operate until the PUK is entered. This may make the rest of the following discussion moot, but here goes anyway:

So the question becomes, as a user, are there any PINs other than SIM-PIN
which the user themselves can change?

The call barring services allow the user to change passwords, but call barring only applies in the CS domain, so does ModemManager care about it? The other category of locks is the personalization locks, but my reading of 3gpp TS 22.022 is that the passwords can't be changed by the user. So that just leaves SIM PIN and SIM PIN2 as changeable. On the other hand, the AT+CPWD command takes a facility name as the first argument, implying changeability for all locks. Which one should be believed?

If not, then a single u32
property for ChangeRetries would be good.  I know there are other PINs
that can be disabled (SIM-PIN, network block/simlock, etc) so that one
might warrant a dict or an array of { "sim-pin": 4, "ph-net pin": 10 }
etc.  All on the Gsm.Card interface (for 0.5...).

The SIM locks can both be disabled/enabled and unlocked. As far as I can tell, the personalization locks can only be enabled/disabled. And I think the user can only disable, not enable. But in any case, I'll go back to my original argument that you only really care about the retry count for the PIN currently being asked for, and that it's not worth the complexity needed to maintain counts for all the locks at once. That's why I think the current UnlockRetries property is sufficient, although maybe it should be renamed to PINRetriesRemaining or PasswordTriesRemaining or something. Do you have a compelling usage case for keeping track of all the counts?

Eric