SIM PIN unlock timeout

Sun Mar 23 19:04:05 UTC 2025

On Sun, 2025-03-23 at 18:44 +0100, Robert Marko wrote:
> On Sat, Mar 22, 2025 at 1:23 AM Dan Williams <dan at ioncontrol.co>
> wrote:
> > 
> > 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?
> 
> Hi Dan,
> If this is the same as PR #1318 then I can confirm that it fixes the
> cancellation for me on
> Quectel RM520N after entering the PIN.

The patch had an error which I fixed in the MR. Thanks for testing!

Dominik, would you be able to test out the changes in MR 1318? Ignore
the patch.

Dan

> 
> Regards,
> Robert
> > 
> > (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
> > > > > > follow
> > > > > > https://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>
> > > 
> > > 
> > > 
> > 
> 
> 