Hey,
>
> I've tried to fix it. Below is for review and if OK then I'll submit MR.
>
> I think, we cannot make assumption that modem will be unlocked after sim pin
> change. Hence, we should not wait for unlock?
>
The mm_iface_modem_update_lock_info() is not "waiting for unlock",
that method is reloading the current lock information status, and I
think that is definitely what we should be doing. The problem now is
what happens with this issue we're seeing; the modem returning Failure
unconditionally if we attempt to reload the lock status. I'm not sure
how to best workaround it, truth be told. Just wondering, have you
tried this very same sequence with the EM7455 running in QMI mode
instead of MBIM mode? Does the issue also happen there?
> diff --git a/src/mm-base-sim.c b/src/mm-base-sim.c
> index 59af3a88..8a181970 100644
> --- a/src/mm-base-sim.c
> +++ b/src/mm-base-sim.c
> @@ -201,20 +201,17 @@ handle_change_pin_ready (MMBaseSim *self,
> GAsyncResult *res,
> HandleChangePinContext *ctx)
> {
> - MMModemLock known_lock = MM_MODEM_LOCK_UNKNOWN;
> + MM_BASE_SIM_GET_CLASS (self)->change_pin_finish (self, res,
> &ctx->save_error);
>
> - if (!MM_BASE_SIM_GET_CLASS (self)->change_pin_finish (self, res,
> &ctx->save_error)) {
> - if (g_error_matches (ctx->save_error,
> - MM_MOBILE_EQUIPMENT_ERROR,
> - MM_MOBILE_EQUIPMENT_ERROR_SIM_PUK))
> - known_lock = MM_MODEM_LOCK_SIM_PUK;
> + if (ctx->save_error) {
> + g_dbus_method_invocation_return_gerror (ctx->invocation,
> ctx->save_error);
> + reprobe_if_puk_discovered (ctx->self, ctx->save_error);
> + g_clear_error (&ctx->save_error);
> + } else {
> + mm_gdbus_sim_complete_change_pin (MM_GDBUS_SIM (ctx->self),
> ctx->invocation);
> }
>
> - mm_iface_modem_update_lock_info (
> - MM_IFACE_MODEM (self->priv->modem),
> - known_lock,
> - (GAsyncReadyCallback)after_change_update_lock_info_ready,
> - ctx);
> + handle_change_pin_context_free (ctx);
> }
>
> Thanks
> Amol
>
> -----Original Message-----
> From: Aleksander Morgado <aleksan...@aleksander.es>
> Sent: Monday, 8 November 2021 5:25 PM
> To: Amol Lad <amol....@4rf.com>
> Cc: ModemManager (development) <modemmanager-devel@lists.freedesktop.org>
> Subject: Re: SIM Card PIN Change Timeout (MM 1.18.2)
>
> Hey,
>
> On Mon, Nov 8, 2021 at 11:36 AM Amol Lad <amol....@4rf.com> wrote:
> >
> > # mmcli -i 1 --change-pin=0000 --pin=1234
> > error: couldn't change PIN code in the SIM: 'Timeout was reached'
> >
> > # mmcli -m 0 --command=AT+CPIN?
> > response: '+CPIN: SIM PIN'
> >
> > So looks like modem is 'really' locked. Btw, which part of debug log showed
> > modem went in searching?
> >
>
> Oh, interesting. Then I wouldn't know what to say :)
>
> Here's the debug log that lead me to think the modem was unlocked already:
>
> debug 2021-11-06T06:46:28+00:00 : [/dev/cdc-wdm0] Received message...
> <<<<<< RAW:
> <<<<<< length = 50
> <<<<<< data =
> 01:31:00:80:03:04:04:02:00:24:00:25:00:01:06:00:02:02:02:02:01:08:11:01:00:00:12:05:00:94:01:2D:00:00:22:05:00:01:02:00:00:00:29:05:00:94:01:2D:00:00
> debug 2021-11-06T06:46:28+00:00 : [/dev/cdc-wdm0] Received generic indication
> (translated)...
> <<<<<< QMUX:
> <<<<<< length = 49
> <<<<<< flags = 0x80
> <<<<<< service = "nas"
> <<<<<< client = 4
> <<<<<< QMI:
> <<<<<< flags = "indication"
> <<<<<< transaction = 2
> <<<<<< tlv_length = 37
> <<<<<< message = "Serving System" (0x0024)
> <<<<<< TLV:
> <<<<<< type = "Serving System" (0x01)
> <<<<<< length = 6
> <<<<<< value = 02:02:02:02:01:08
> <<<<<< translated = [ registration_state =
> 'not-registered-searching' cs_attach_state = 'detached'
> ps_attach_state = 'detached' selected_network = '3gpp'
> radio_interfaces = '{ [0] = 'lte '}' ]
> <<<<<< TLV:
> <<<<<< type = "Data Service Capability" (0x11)
> <<<<<< length = 1
> <<<<<< value = 00
> <<<<<< translated = {}
> <<<<<< TLV:
> <<<<<< type = "Current PLMN" (0x12)
> <<<<<< length = 5
> <<<<<< value = 94:01:2D:00:00
> <<<<<< translated = [ mcc = '404' mnc = '45' description = '' ]
>
> --
> Aleksander
> https://aleksander.es
> ________________________________
> The information in this email communication (inclusive of attachments) is
> confidential to 4RF Limited and the intended recipient(s). If you are not the
> intended recipient(s), please note that any use, disclosure, distribution or
> copying of this information or any part thereof is strictly prohibited and
> that the author accepts no liability for the consequences of any action taken
> on the basis of the information provided. If you have received this email in
> error, please notify the sender immediately by return email and then delete
> all instances of this email from your system. 4RF Limited will not accept
> responsibility for any consequences associated with the use of this email
> (including, but not limited to, damages sustained as a result of any viruses
> and/or any action or lack of action taken in reliance on it).
--
Aleksander
https://aleksander.es
