Bug#877024: modemmanager should ask before messing with serial ports
>
> However, I have to say that that upstream bug log does not really
> suggest to me that upstream thinks that the current probing behaviour
> is unacceptable. It has been open since 2014 and if the bug is to be
> believed the modemmanager default behaviour in upstream has not
> changed.
>
We just didn't find a better solution, that's it. Keeping the
blacklist updated has been the fallback we've used all these years.
> The key part of your response in #683839 is as follows:
>
> Asking the user... well, what would we ask? Should we ask "is this a
> modem" for every TTY we find? Is it better to annoy thousands of
> users each time a TTY is found instead of blacklist for all of them?
> We try to keep the blacklist in stable releases updated and stables
> happening each 2-3 months.
>
> Your concern here is precisely the user convenience which I am saying
> needs to be traded off for safety and reliability.
>
> "Every TTY" is rather hyperbolic, of course. We are only speaking
> here of tty devices which might be modems. modemmanager already
> refrains from autoprobing builtin serial devices ttyS* and I assume it
> ignores things like multiport serial cards. So we are speaking mostly
> of USB-attached serial ports. And we only need confirmation the first
> time one is plugged in.
>
The solution you're suggesting involves changes not only in
ModemManager, but in the whole stack... I personally don't like that,
I don't want to ask users "is this a modem" especially when they're
not plugging in one. I think the solution should involve keeping
ModemManager automatically detect modems, maybe with some heuristics
to try to ignore devices that don't look like modems. For TTY-only
devices (most of the ones that we end up blacklisting), though, the
solution isn't easy, which is why we're still here after all these
years...
> As I have explained, a blocklist is not sufficiently safe or reliable.
>
Yes, I agree.
> A passlist of things known definitely to be modems (not generic USB to
> serial chips) would help reduce the user query burden.
>
If only we had that whitelist...
>
>> > * Say that, in the absence of a better solution, my patch should
>> > be applied to modemmanager.
>>
>> I commented about that patch in bug 683839, please don't apply it,
>> it would break all modems not only those with TTYs.
>
> Sorry about that. I wasn't able to get modemmanager working with my
> MBIM device (which I'm now using in Hilink mode, hence without
> modemmanager, anyway) so I wasn't able to test that path.
>
> Please can you point me to the right place to make this change ?
> I can try revising my patch by myself but it will be more likely
> to be right if you help.
>
If I had to suggest how to do this, probably removing the
"ID_MM_CANDIDATE" from "tty" subsystems devices would do it:
https://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/80-mm-candidate.rules
But not advocating for that option! :)
>> Again, I'd have suggested to bring this patch to the ModemManager
>> mailing list before just saying that the patch should be applied in
>> absence of a better solution...
>
> As a Debian user, experiencing a problem with the default
> configuration of my Debian system, and trying to use Debian's
> governance processes to escalate the bug, it is appropriate for me to
> use a Debian channel for this.
>
I disagree with that reasoning, but well nevermind :)
The discussion of how to best solving the automatic TTY probing is
definitely something that has to be done in the ModemManager mailing
list. I've already started a new thread to bump the discussion again:
https://lists.freedesktop.org/archives/modemmanager-devel/2017-September/005912.html
--
Aleksander
Reply to: