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.
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
> > > > > 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.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>
> >
> >
> >
>
--
Robert Marko
Staff Embedded Linux Engineer
Sartura d.d.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.ma...@sartura.hr
Web: www.sartura.hr
