Hey,
I tested the MR 1318 with two different modems. The Quectel RM520-GL and the
Quectel RM500Q-GL.
For both of them, the SIM PIN unlock was executed perfectly without any errors!
Thank you very much!
BR,
Dominik
-----Ursprüngliche Nachricht-----
Von: Dan Williams <d...@ioncontrol.co>
Gesendet: Sonntag, 23. März 2025 20:04
An: Robert Marko <robert.ma...@sartura.hr>
Cc: Dominik Nille <dominik.ni...@balluff.de>; Aleksander Morgado
<aleksande...@chromium.org>; modemmanager-devel@lists.freedesktop.org
Betreff: Re: SIM PIN unlock timeout
On Sun, 2025-03-23 at 18:44 +0100, Robert Marko wrote:
> On Sat, Mar 22, 2025 at 1:23 AM Dan Williams <d...@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.ni...@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 <d...@ioncontrol.co>
> > > > Gesendet: Donnerstag, 27. Februar 2025 16:25
> > > > An: Dominik Nille <dominik.ni...@balluff.de>; Aleksander Morgado
> > > > <aleksande...@chromium.org>
> > > > Cc: modemmanager-devel@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 <d...@ioncontrol.co>
> > > > > Gesendet: Mittwoch, 19. Februar 2025 19:36
> > > > > An: Dominik Nille <dominik.ni...@balluff.de>; Aleksander
> > > > > Morgado <aleksande...@chromium.org>
> > > > > Cc: modemmanager-devel@lists.freedesktop.org
> > > > > Betreff: Re: AW: SIM PIN unlock timeout
> > > > >
> > > > > [Sie erhalten nicht häufig E-Mails von d...@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 <aleksande...@chromium.org>
> > > > > > Gesendet: Mittwoch, 11. Dezember 2024 09:46
> > > > > > An: Dominik Nille <dominik.ni...@balluff.de>
> > > > > > Cc: modemmanager-devel@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.ni...@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>
> > >
> > >
> > >
> >
>
>
