Re: No new PIN request to the user if PIN stored in settings is wrong

I'm trying to understand whether this behavior is on purpose or

I have some "gsm" settings for a broadband connection, and the
settings have a PIN stored. I then try to use those settings on a
modem device but the expected PIN in the modem is a different one,
the connection attempt fails with a "sim-pin-incorrect" reason. At
this point NetworkManager doesn't request the user new secrets for
this connection after finding that the stored ones are wrong; i.e.
don't see any popup window in the shell asking to enter PIN. The
connection attempt just fails and we do get reported in the UI
the failed attempt.

Is this behavior (asking the user for PIN after a "sim-pin-
failure) not implemented or am I missing some reason that would
prevent doing that? The behavior is different e.g. with WiFi; if I
change the key in my router and I request NM to connect to the WiFi
network, the authentication failure triggers a new request for
to the user.



sounds like a bug. If a secret/pin is wrong, NM should re-ask for it.

We do have to be careful here, because by the time NM asks for the PIN,
we've already tried the stored PIN once, and if the user enters the
wrong pin in the dialog you have one try left before the PIN is
blocked.  And then you have to find your PUK which often isn't right
next to you.

In the network-manager-applet days, we had the SIM-PIN unlocking
dialog glued out of NetworkManager, so I understand this lack of
re-asking the user was due to that, as the applet would detect the
lock and trigger the user dialog. In that SIM-PIN unlocking dialog we
could also do SIM-PUK unlocking if needed via the UI, and I don't
really recall if we had remaining attempts shown

When using gnome-shell, the SIM-PIN unlocking is only done through NM
asking for secrets, there is no dedicated SIM-PIN unlocking dialog
showing remaining attempts, and there is no way to unlock SIM-PUK
through the UI. I discussed this a very long time ago with aday trying
to draft a way to integrate this in the shell, but I think that we
both lost interest about the problem, maybe it's time to revisit this.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]