Back from vacation, catching up...
On Wed, Oct 26, 2011 at 8:44 PM, Dan Williams <d...@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
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
