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