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