GNOME Bugzilla – Bug 685331
Support PIN entry for 3G connections
Last modified: 2021-07-05 14:18:58 UTC
[ Dan Williams from https://bugzilla.gnome.org/show_bug.cgi?id=685327#c4 ] "I'm not sure if we've handled the 3G PIN entry case yet in the shell, but that's the last possible piece that nm-applet does that the shell doesn't do. This is the feature where nm-applet listens for ModemManager D-Bus signals and sends a saved PIN code to ModemManager to unlock the modem whenever it's inserted, so that registration status and SMS work without having to manually turn the 3G device on. People want to have their PIN code saved in the keyring and the device automatically unlocked on hotplug. But yes, we need the applet for fallback. No, Shell-only setups (like Fedora 18 where we'll always use LLVMpipe and never fallback-mode) do not need the applet if you can live without 3G PIN handling. Or we can add that PIN thing to the Shell. Or, we have been discussing on the mailing list, we enhance NM to have a concept of "device secrets" that are not tied to a connection, but are a property of the device itself (in this case the SIM card, really)." We should make sure the Shell is capable of handling PIN entry for 3G connections and drop nm-applet completely for the non-fallback session.
To follow up on that, the shell will ask for a PIN when requested from NetworkManager (activating a 3G connection), in the same way as any other secret request. Code at js/ui/components/networkAgent.js:326. It will not unlock the device automatically though, and I haven't looked at nm-applet code to that yet. TBH, I didn't even know that feature existed.
*** Bug 687855 has been marked as a duplicate of this bug. ***
Currently (see bug 687908) NM won't ask PIN when just enabling WWAN. It will only ask PIN when trying to activate a connection profile.
The shell should also be able to ask for PUK and new PIN (in the same dialog), when the modem is PUK-locked (this was also done by nm-applet previously). I guess in this case NM needs to request for both, and the shell handle that request by creating the corresponding dialog.
For reference, currently nm-applet creates a dialog with the following fields when PUK-unlocking: --------------------------- PUK: [ ] New PIN: [ ] Repeat new PIN: [ ] --------------------------- It also makes sure that the two PIN entries are numeric and equal.
Having a PIN entry in the shell, popping up only when starting a network connection, would be very useful, but, as geoclue might want to use the GPS inside the device to get started, I'm wondering whether we might not end up having the same bug as nm-applet popping up on session start: https://bugzilla.gnome.org/show_bug.cgi?id=687897 Designers?
If PIN is stored per SIM card ID, then we could always try to auto-unlock it on boot without bothering the user, whenever WWAN is enabled.
(In reply to comment #7) > If PIN is stored per SIM card ID, then we could always try to auto-unlock it on > boot without bothering the user, whenever WWAN is enabled. That's if we have a "remember PIN" option. Is that really wise?
(In reply to comment #8) > (In reply to comment #7) > > If PIN is stored per SIM card ID, then we could always try to auto-unlock it on > > boot without bothering the user, whenever WWAN is enabled. > > That's if we have a "remember PIN" option. Is that really wise? Well... it already is there in the NM settings right now; i.e. remembering PIN per connection setting. This is also really why I've always suggested to have a global WWAN on/off setting; if "off" we wouldn't do anything, if "on" we would directly ask the user for the PIN, and automatically enable the modem (e.g. to allow location retrieval, SMS...). If the user doesn't want to be bothered for WWAN he could just set WWAN "off".
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > If PIN is stored per SIM card ID, then we could always try to auto-unlock it on > > > boot without bothering the user, whenever WWAN is enabled. > > > > That's if we have a "remember PIN" option. Is that really wise? > > Well... it already is there in the NM settings right now; i.e. remembering PIN > per connection setting. That's weird. Why not remove the PIN altogether? So it can't be used outside the laptop in which it is? > This is also really why I've always suggested to have a global WWAN on/off > setting; if "off" we wouldn't do anything, if "on" we would directly ask the > user for the PIN, and automatically enable the modem (e.g. to allow location > retrieval, SMS...). If the user doesn't want to be bothered for WWAN he could > just set WWAN "off". That sounds like a good work-around.
What's the status of this? It seems to me that the only way I can do this is by manually setting the pin with mmcli, every single time.
(In reply to Claudio Saavedra from comment #11) > What's the status of this? It seems to me that the only way I can do this is > by manually setting the pin with mmcli, every single time. If you have nm-applet installed, it will ask you. I still agree that we'd want the functionality in gnome-shell directly though.
Hm, somehow it doesn't really work, not even with nm-applet installed. If I run it manually, it does.
Hello, I chose to autostart nm-applet again because i needed PIN support for some customers (see bug #660044). Is there likely to have double dialog bug for me, if one day GnomeShell manage PIN code on its own ? Thanks.
(In reply to pgramond from comment #14) > Hello, I chose to autostart nm-applet again because i needed PIN support for > some customers (see bug #660044). Is there likely to have double dialog bug > for me, if one day GnomeShell manage PIN code on its own ? > Thanks. Potentially, yes.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.