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

[Aleksander Morgado <aleksander aleksander es>]

Hey,

> 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.

Yes, that is a very bad scenario. NM should store only the SIM-PIN in
settings if the unlock attempt using that SIM-PIN is successful,
otherwise it should not store it.

Some months ago I was working in a similar setup, but in this case we
had SIM-PIN already stored in settings, so GetSecrets() was not being
used. In this case, IIRC, a failure to unlock the modem with the
stored SIM-PIN would "block" autoconnection of the settings, so the
settings were not automatically attempted any more. But I guess it
doesn't block explicit user requests to connect with the stored
settings.

I wouldn't call it a loophole, though, if the SIM-PIN is the correct
one, everything works. The problem is when SIM-PIN may not be the
correct one, in this case having NM store the SIM-PIN is not a good
idea. That is why I said in my previous email that having NM do all
this may already be a bit too much as well.

> 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.

Yes, I agree that doing all this via NM API only it's a bit
problematic if not impossible at the moment.

> > 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.

Then you should manage the ModemManager DBus API yourself. That is
what I suggest to do in all embedded devices using MM+NM without
direct user control; there must be some higher level application that
provides "logic" to the management of the modems, what I usually call
a "wwan monitor" application, which would be in charge of the
lifecycle of the modem (including SIM-PIN unlock). Under this
scenario, NetworkManager never handles SIM-PIN unlocking, it relies on
others to do that.

> 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.

Yes, or to the Modem State property.

> 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.

SIM-PIN/PUK unlocking is just one of the features you need to handle,
there are many more things that you may want to setup in your embedded
system in addition to that (e.g. access technology selection,  device
reset and recovery operations when it gets stuck, automatic or manual
registration to the network...)


> 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.

Yes, because those operations are modem management operations, not
really related to "connecting the modem".

> 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 :)

I'm giving my personal opinion here; I'm not sure if NetworkManager
devs have some other view on the topic? Please don't take my words as
written in stone!

-- 
Aleksander
https://aleksander.es