Re: Modem authentication via the NM d-bus API - how to handle PUK?

[Sergey 'Jin' Bostandzhyan <jin mediatomb cc>]

Hi,

On Fri, Oct 16, 2020 at 06:01:49PM +0200, Aleksander Morgado wrote:
> > What I could see so far is that the only thing one can provide to the modem
> > via NM is the PIN, that's it. PUK, PIN2, PUK2 are not known to NetworkManager
> > and remain completely unhandled.
>
> My opinion is that PIN is the only thing that NetworkManager should
> attempt to unlock, and that may already be a bit too much as well.
> NetworkManager should not need to handle every possible thing that may
> happen to modems, NetworkManager should have settings to "connect the
> modem" and well, we can consider PIN as part of the connection
> settings even if it's much much more (i.e.  a SIM-PIN locked modem
> doesn't even register in the network). I'm not sure I like much the
> idea of letting NM attempt SIM-PUK unlocks (using what new PIN, btw?)
> as part of the settings to "connect the modem".

thing is that at the moment it's kind of half-half between two worlds. I kept
trying things out and came upon something that is really not nice:

so NM will call my GetSecrets method, will get a PIN from the application,
save it in its settings and execute a SendPin call to ModemManager.

Now... if that PIN happens to be wrong I end up in the following situation:

NM saved the wrong PIN, so GetSecrets is not being called again, that means
that each time I try to reactivate the connectoin I use up one unlock attempt.

Over D-Bus I can see that MM responds to NM with the info that the
PIN is incorrect, later that the PIN has been blocked.

At this point the modem expects the PUK, but attempting to activate the
connection again will just make NM to send the bad PIN instead.

I find that this is not only confusing, but that it is also quite a loophole
in the NM API.

The application has no way of knowing that it ended up in this situation if
it relies only on NMs D-Bus API. The only way to get out of it would be to
Update the Settings, clearing out the bad PIN. That is - if one figures out that
the PIN was no good... and you can't figure that out via NM alone.

> A better place to handle SIM-PIN locked status where SIM-PUK is
> requested could be the "System settings" application, applicable to
> the modem devices, or even gnome-shell triggered unlock dialogs (as we
> did have with network-manager-applet in the GNOME2 days). I planned to
> work on that myself some years ago, and I even talked to Allan Day
> about how to handle that, but then totally forgot about it...

I am working on an embedded device that has no UI, so in my case I need to be 
able to see and react to everything that is going on based on the D-Bus API.

> From the application perspective it'd be really great to have a central
point for authenticating connections or devices. NM felt like the right
place, because NM is the one dealing with connections... Of course if
a dedicated daemon handles that and plays along - that's fine too.

Right now, for the headless application scenario, I see that the only solution 
would be to actually ignore GetSecrets completely and to subscribe to MM 
property changes of UnlockRequired and dealing with those changes directly.

I'll be adding WiFi support to my box soon, I did not yet look into the
wireless API, but I guess I will hit similar issues, so I feel that currently
some sort of a central place for handling authentication of devices/connections
is missing.

That being said: thank you for exlaining, my understanding is that I indeed
need to cover those PUK/PIN2 etc cases myself, bypassing NetworkManagers API.
I was just trying to make sure that I don't end up reinventing the wheel while
missing something that already exists in NMs D-Bus API :)

And of course if we can improve the overall situation - that'd be great too!

Kind regards,
Jin