Ok, fair enough. It's a bit confusing when some modems like HuaweiOn Tue, 2011-11-01 at 14:45 -0400, Eric Shienbrood wrote:
> 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:
allow you to get the # retries for the current unlock (^CARDLOCK) *and*
the # retries for multiple operations at the same time (^CPIN returns
tries for PUK, PIN, PUK2, and PIN2 in the same command). There's also
the subsidy lock for the device, and facility locks. It's unclear to me
from 27.007 whether the <passwd> they talk about is one set explicitly
with CLCK when the facility is locked, or whether it's the
PIN/PUK/PIN2/PUK2 or what. So there's a lot of locks running around
here, and it was somewhat unclear what UnlockRetries was really supposed
to be talking about. Initially it was supposed to be only the # retries
allowed for the current unlock request specified in UnlockRequired, and
when UnlockRequired was NULL, UnlockRetries would also be NULL, since
otherwise there's no way to know what UnlockRetries specifies the number
of retries for (given all the different locks and their retries).
Which spawned the discussion of "how can we keep the required code
(pin/puk/facility/whatever) together with the # of retries for that
specific item".
When you want to change your PIN code, the modem is already unlocked,
and thus UnlockRequired would be NULL/"". So when you try to change the
PIN and enter the PIN wrong, it wouldn't make a ton of sense to change
UnlockRetries to some value and keep UnlockRequired NULL/"" since that
breaks the contract between them.
Which is why (if I remember last week correctly) I was trying to add
another property which contained all the unlocks and their respective
retries, regardless of what state the modem was in at that point in
time. My thought was that UnlockRequired/UnlockRetries would be what
was needed to make the modem function *now*, but other stuff could be
punted to the Big Unlock Array that also contained the # retries for
each item. That way we keep a simpler, more understandable interface,
and provide the ability for retries for actions that don't prevent the
modem from working at the time they are performed.
Dan
>
> 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