SIM PIN unlock timeout
Dan Williams
dan at ioncontrol.co
Sat Mar 22 00:23:21 UTC 2025
On Sat, 2025-03-08 at 10:19 -0600, Dan Williams wrote:
> Hey,
>
> > On Mar 3, 2025, at 2:44 AM, Dominik Nille
> > <Dominik.Nille at balluff.de> wrote:
> >
> > Hey,
> >
> > the modem is directly connected to the power supply of the device.
> > I logged in on the device after startup, stopped MM and started it
> > in debug mode.
> >
> > I ran the startup phase in the modemmanager_debug.log.
> >
> > I ran the startup phase and additionally tried to unlock with the
> > command "mmcli -I any --pin=<SIM_PIN>" in the
> > modemmanager_debug_simpin.log
> >
> > Are you able to figure out the problem?
>
> Working on it… I see from your logs it may be connected to an issue
> MM currently has with PIN entry that causes it to clean up, dispose,
> and then re-detect the modem because it sees the PIN entry as a SIM
> hot-swap. I have a modem somewhere that can reproduce the problem,
> but couldn’t find it the other day.
>
> It may be the case that mmcli handles this badly and waits for the
> operation to complete on the original modem, when MM has already
> destroyed that one and redetected it as a new device.
>
> I’ll try again with a couple other devices.
>
> In the mean time, would you be willing to re-do your logging with the
> “—pin=<PIN>” bit, but run MM with the —debug-personal-info option (I
> forget what it's named exactly right now), and send me the debug log
> _privately_? That will show what the IMSI and ICCID are before the
> unlock, and what MM thinks they are after, and that could help
> establish the scenario. Again, send privately if you are willing to
> do this.
I think in your case, the combination of the Quectel plugin + QMI is
necessary for the problem to occur. For reasons I don't understand the
Quectel plugin uses AT-based SIM swap notifications with QMI-based
devices rather than the generic QMI methods.
What happens is that after the PIN has been verified the modem sends
the QUSIM URC indicating that the USIM is now available and active. The
Quectel plugin uses that for hot-swap detection and interrupts the
normal QMI flow for PIN entry. That causes the SIM swap detection to
run a bit too early, before the QMI code has been able to re-read the
IMSI.
In any case, I've attached a patch that (hopefully?) solves the problem
by treating the PIN unlock case specially. Would you be able to try the
patch out?
(note; only the mm-broadband-modem.c bit is relevant for your modem but
I wanted to do the code for both paths anyways)
Thanks,
Dan
>
> Thanks,
> Dan
>
> >
> > Thank you very much!
> >
> > BR
> > Dominik
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Dan Williams <dan at ioncontrol.co>
> > Gesendet: Donnerstag, 27. Februar 2025 16:25
> > An: Dominik Nille <Dominik.Nille at balluff.de>; Aleksander Morgado
> > <aleksandermj at chromium.org>
> > Cc: modemmanager-devel at lists.freedesktop.org
> > Betreff: Re: AW: AW: SIM PIN unlock timeout
> >
> > On Wed, 2025-02-26 at 10:19 +0000, Dominik Nille wrote:
> > > Hey,
> > > thank you very much for your reply.
> > >
> > > I was not expecting that type of behavior. I did only connect one
> > > modem, so I was expecting the "any" keyword to work.
> > > I am wondering why ModemManager lists two different Modems.
> >
> > Are you able to stop MM and start it manually with the "--debug"
> > argument?
> >
> > If we can get the full from-the-beginning logging that may show why
> > MM thinks there's two modems. It could be kernel/udev issues that
> > prevent MM from knowing that all the ports are from the same device
> > but having the full logs would be easier.
> >
> > Note that when the modem is connected and when MM is started can
> > have an effect on detection. eg if MM is already running and the
> > modem is "hot"-plugged, versus if the modem is already connected
> > and MM is started after ("cold" plug). If you're able to match the
> > problem scenario with your manual debugging here, it'll be easier
> > to figure out the problem.
> >
> > > I tried it again and "mmcli -m any" lists the modem as modem0 and
> > > SIM0 before sending the command.
> > >
> > > When I send the command "mmcli -i any --pin=<SIM-PIN>", the
> > > timeout
> > > will be reached.
> > > Afterwards, the same modem will be listed as Modem1 with Sim1.
> > >
> > > Result of "lsusb":
> > > Bus 002 Device 003: ID 2c7c:0801 Quectel Wireless Solutions Co.,
> > > Ltd.
> > > RM520N-GL
> > >
> > > Result of "mmcli --list-modems"
> > > /org/freedesktop/ModemManager1/Modem/1 [Quectel] RM520N-GL
> > >
> > > "mmcli -m any" lists also only one modem.
> >
> > If MM isn't able to fully initialize a modem, it won't export it to
> > D- Bus and clients like mmcli.
> >
> > Dan
> >
> > >
> > > These outputs do not match the information of a second modem
> > > being
> > > connected.
> > >
> > > Are you able to explain the behavior?
> > >
> > > Thank you very much!
> > >
> > > Best regards,
> > > Dominik
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Dan Williams <dan at ioncontrol.co>
> > > Gesendet: Mittwoch, 19. Februar 2025 19:36
> > > An: Dominik Nille <Dominik.Nille at balluff.de>; Aleksander Morgado
> > > <aleksandermj at chromium.org>
> > > Cc: modemmanager-devel at lists.freedesktop.org
> > > Betreff: Re: AW: SIM PIN unlock timeout
> > >
> > > [Sie erhalten nicht häufig E-Mails von dan at ioncontrol.co. Weitere
> > > Informationen, warum dies wichtig ist, finden Sie unter
> > > https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > On Mon, 2025-01-20 at 14:34 +0000, Dominik Nille wrote:
> > > >
> > > >
> > > >
> > > > Hey Aleksander, hey Dan,
> > > >
> > > > I ran the ModemManager with debug logs and produced the same
> > > > behavior as in the previous mail again.
> > > >
> > > > Maybe, you can gain some knowledge from the debug log I
> > > > attached.
> > > >
> > > > Any ideas, why the command keeps failing, but after waiting a
> > > > little
> > > > the state changes from “locked” to “registered”?
> > >
> > > Looks like you've got two modems on the system, and the other one
> > > (modem0) isn't happy:
> > >
> > > ModemManager[4639]: <debug> [1737381559.914951] [modem0] couldn't
> > > check if unlock required: Couldn't peek QMI port
> > > ModemManager[4639]: <debug> [1737381559.915068] [modem0] retrying
> > > (22) unlock required check
> > >
> > > so what happens is that modem1 gets unlocked just fine, but
> > > because
> > > you sent "-i any" MM will try to unlock both modems, and the
> > > other one
> > > times out.
> > >
> > > We could debug why modem0 isn't happy, or alternatively you could
> > > send
> > > the PIN to modem1's SIM and it shouldn't take long.
> > >
> > > Dan
> > >
> > > >
> > > > BR
> > > > Dominik
> > > >
> > > >
> > > >
> > > > Von: Aleksander Morgado <aleksandermj at chromium.org>
> > > > Gesendet: Mittwoch, 11. Dezember 2024 09:46
> > > > An: Dominik Nille <Dominik.Nille at balluff.de>
> > > > Cc: modemmanager-devel at lists.freedesktop.org
> > > > Betreff: Re: SIM PIN unlock timeout
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hey Dominik,
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I am currently trying to unlock myQuectel RM520N-GL on Linux
> > > > > Debian with the ModemManager (Version1.20.4).
> > > > >
> > > > > mmcli -i any --pin=<SIMPIN>
> > > > > > > error: couldn't send PIN code to the SIM: 'Timeout was
> > > > > > > reached'
> > > > >
> > > > > Runs into atimeout and still manages to unlock the SIM-Card.
> > > > > Afterwards the state changes from “locked” to “registered”.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Please run MM with debug logs (use "mmcli -G DEBUG" or
> > > > followhttps://modemmanager.org/docs/modemmanager/debugging/),
> > > > as
> > > > that will give us much more information about the specific
> > > > sequence
> > > > in place here.
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Aleksander
> > > >
> > > >
> > > > Dominik Nille
> > > > Technology
> > > > Innovation Management
> > > >
> > > >
> > > >
> > > >
> > > > Balluff GmbH · Schurwaldstrasse 9 · 73765 Neuhausen a.d.F. ·
> > > > Germany
> > > > Phone +497158173-8020 · Fax +4971585010 ·
> > > > Dominik.Nille at balluff.de ·
> > > > www.balluff.com
> > > >
> > > > Facebook
> > > > LinkedIn
> > > > Twitter
> > > > Youtube
> > > > Xing
> > > > Blog
> > > >
> > > >
> > > > Place of incorporation/Sitz der Gesellschaft: Neuhausen a.d.F.,
> > > > Germany · Register court/Registergericht: Amtsgericht
> > > > Stuttgart,
> > > > Germany Trade register/Handelsregister: HRB 214038 · Managing
> > > > directors/Geschäftsführer: Katrin Stegmaier-Hermle, Florian
> > > > Hermle,
> > > > Frank Nonnenmann Chairman board of directors/Vorsitzender des
> > > > Aufsichtsrats: Michael Unger · VAT ID/USt-ID: DE213 402 337
> > > >
> > > >
> > > >
> > >
> >
> > <modemmanager_debug.log><modemmanager_debug_simpin.log>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simunlock.patch
Type: text/x-patch
Size: 3254 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20250321/45eb4120/attachment.bin>
More information about the ModemManager-devel
mailing list