Re: [PATCH] [ModemManager] Some issues with SIM PIN handling

[Dan Williams <dcbw redhat com>]

On Tue, 2011-07-19 at 13:34 -0400, Eric Shienbrood wrote:
> TL;DR: PIN retry count needs to be fetched after every PIN operation.
> 
> 
> There are some deficiencies in the current handling of PIN-related
> operations in modem-manager, such that it mis-reports the true state
> of the SIM:
>       * The EnablePin and ChangePin operations on an unlocked SIM will
>         result in the PIN retry count being decremented when they are
>         supplied with an incorrect PIN. But modem-manager doesn't
>         fetch the retry count following those operations, so the
>         UnlockRetries property remains unchanged.
>       * After trying EnablePin or ChangePin three times with an
>         incorrect PIN, the SIM becomes blocked, i.e., it is locked
>         until the PUK is entered. Again, modem-manager doesn't
>         recognize this, so the UnlockRequired property doesn't change
>         - its value continues to be the empty string.
>       * As implied by the above two points, modem-manager assumes that
>         the PIN retry count is relevant only when the SIM is locked.
>         Once it is successfully unlocked, modem-manager forces
>         UnlockRetries to zero. This is incorrect, because even when
>         the SIM is unlocked, you only have three chances to enter the
>         right PIN for the other operations.
> So after an EnablePin or ChangePin operation, the modem needs to be
> queried for the new retry count, and a check needs to be done to see
> whether a SIM_PUK error was returned. Finally, UnlockRetries should
> always reflect what the modem reports for the retry count, even when
> the SIM is unlocked. The attached patch does these things.

So we'll need to also update the API spec to indicate that when
'UnlockRequired' is empty, that UnlockRetries indicates the number of
SIM-PIN tries, if known?  The spec won't match reality if this patch is
applied without such an update.

Or, really, we could also add another property (a{sv} mapping lock name
to # retries like {SIM-PIN => 3, SIM-PUK => 10}) that lists # tries for
all known types.  I know of at least 3 or 4 different modems that can
provide this information so it makes sense to extend this.

> There's one other enhancement that I think is needed in this area.
> Right now, there's no way based on the UnlockRequired and
> UnlockRetries properties to tell the difference between a SIM for
> which PIN locking is disabled, and a SIM that has locking enabled, but
> is currently unlocked. In both cases, UnlockedRequired is the empty
> string, and UnlockRetries is zero. This presents a problem for a UI
> that wants to put up a dialog to allow the user to enable or disable
> PIN locking, and wants to show a checkbox that reflects the current
> enabled/disabled state of locking.
> 
> 
> I suggest either introducing a new property to explicitly describe the
> enable/disable state, or reserving the {UnlockRequired = "",
> UnlockRetries=0} combination for the case in which locking is
> disabled. The first of these seems more robust to me, but perhaps
> others have suggestions for alternatives.

So perhaps a new SimLock property that's something like sa{sbu} where
the first 's' is the current "UnlockRequired" value, and the dict is a
mapping of { PIN name => (enable/disable, # tries) }.  Most of the
"facilities" given by AT+CLCK have analogs for PIN names used with AT
+CPIN so we could be OK here.  Thoughts?

Dan