FCC unlock surprises after upgrading (was: Re: ANN: ModemManager 1.18.4 released)

[Aleksander Morgado]

Hey,

> >  * A new FCC unlock operation management via external scripts is
> >    introduced, which will avoid to automatically unlock FCC locked
> >    devices unless the user has configured the operation manually, or
> >    unless an official vendor-provided FCC unlock tool is found in the
> >    system.
>
> Sorry for late comments again, but I'm worrying about the user
> experience for those upgrading a previously working system.
>
> I did read this announcement and the discussion about the feature back
> in november, and thought it sounded all fine. And I upgraded to 1.18.4
> right before christmas when the Debian package showed up.  Still didn't
> think much about this, and obviously didn't read out of the NEWS file
> that I was supposed to do something...
>
> Now I don't suspend or reboot my laptop often with Corona office and all
> that.  But today I did.  And was very surprised when MM failed to
> connect after resuming.  Manually trying to enable the modem failed with
> a message which didn't immediately ring any bells:
>
>  root at miraculix:/home/bjorn# mmcli -m any -e
>  error: couldn't enable the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Retry: Invalid transition'
>
> I must admit that I had to take a detour via AT commands, looking at
> AT!PCINFO? to realize that this was a failure to do the FCC unlock. Only
> after that did it occur to me that I should read those instructions
> again. But that was only because I had seen then before only a few
> weeks ago.  I'm not sure everyone else would make the connection.  Or
> maybe they would, and I'm the only slow one here :-)
>
> Fixing the problem was of course as simple as
>
>  cd /etc/ModemManager/fcc-unlock.d
>  ln -s /usr/share/ModemManager/fcc-unlock.available.d/1199\:9079
>
> and everything worked as expected after that.
>

Please note that you can use one single command to link all known
scripts, it's probably easier than going to the directory and looking
up which is your exact vid:pid:
$ sudo ln -sft /etc/ModemManager/fcc-unlock.d
/usr/share/ModemManager/fcc-unlock.available.d/*

> I understand that you want/need to make this a concious decision for new
> users and modems.  But I wonder if we really have to make it this
> difficult for existing users?  After all, I am spoiled by 5+ years of
> fully automatic unlock on this laptop/modem. Why should I have to
> manually re-enable it now?  Maybe we could accept a script adding the
> symlink on upgrades from older MM versions, on systems with an affected
> modem?  Or at least a subset of older modems?

When I started to work on this, I definitely didn't want to have
different approaches for different modems. Because, where to draw the
line? In the modems using the old Sierra approach? In the SDX55 that
we already had included to autounlock? In the new EM120 unlock logic
that is already available in libmbim/mbimcli? If we had some to
autounlock, but not all, why not add all the ones we know how to
unlock? My approach is to say that ModemManager has been doing it all
wrong since the very beginning, we shouldn't have done any auto
unlock. MM has tried to solve (circumvent) an issue introduced by
modem manufacturers, and it shouldn't have even tried it.

So, all modules require the manual user configuration. This is a
one-time operation to be done by the user, effectively selecting which
fcc unlock procedure to run (the ones known by MM, or the ones
installed by manufacturers).

>
> Or maybe this isn't a big problem?  After all, it's just a one time
> thing.  I only hope people figure it out quicker than me...
>

I'd like to think that any user complaining about 1.18.4 not
connecting will be able to find info about the FCC unlock change on
the Internet. I've written info in the release notes, I wrote the
whole https://modemmanager.org/docs/modemmanager/fcc-unlock/ page in
the doc site, and I've also blogged about it.

-- 
Aleksander
https://aleksander.es