[review] https://github.com/cbchan/ModemManager/tree/sim-mbim-unlock-retries

[Aleksander Morgado]

>>>> It really is unfortunate that the MBIM_CID_PIN query only reports the
>>>> information of the "currently applicable" PIN type, although the truth
>>>> is that that's the only useful one.
>>>
>>> Yes, indeed. It would have been much better if MBIM_CID_PIN query
>>> could take a PIN type as argument. I'd expect PIN1 (PUK1) is likely
>>> the one being used and thus the most relevant / useful one in typical
>>> scenarios.
>>>
>>> Here's the issue: If PIN1 is currently disabled, some modem reports
>>> the info about another PIN, say PIN2, to a MBIM_CID_PIN query. When we
>>> try to enable PIN1, we won't know the retries count until after
>>> entering a PIN once. Suppose the retries count doesn't go to 0 after a
>>> wrong attempt (i.e. not in sim-puk state), we still can't query MM for
>>> the retries count of PIN1.
>>>
>>
>> Aha, that was what I was missing, the PIN disabled->enabled transition
>> is the problematic one, because with PIN disabled it would report you
>> PIN2 attempts. But, if we do the disabled->enabled transition,
>> couldn't we reload unlock attempts in that moment (after enabling
>> SIM-PIN)? I'm assuming that the "current" PIN would change to PIN1
>> right away and we would get reported the number of attempts of PIN1;
>> without even trying to send a PIN once.
>>
>
> Don't we need to enter the correct PIN to re-enable PIN1? so the
> disabled->enabled transition is essentially a MBIM_CID_PIN set
> operation. Regardless of whether the operation succeeds or fails, the
> response should report the latest remaining attempts for PIN1, which
> we want to propagate that to UnlockRetries. That's why patch #4 always
> calls mm_iface_modem_update_unlock_retries() if we can parse the
> response, regardless of whether the operation succeeds or not.
>

That makes total sense, indeed. Your logic makes the best compromise
given the APIs we have in MBIM.

-- 
Aleksander
https://aleksander.es