Bug#877024: modemmanager should ask before messing with serial ports
Hey Ian,
On Thu, Oct 12, 2017 at 2:39 PM, Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> Aleksander Morgado writes ("Bug#877024: modemmanager should ask before
> messing with serial ports"):
>> This is part of the discussion we had in the MM mailing list for such
>> a solution:
>> https://lists.freedesktop.org/archives/modemmanager-devel/2017-September/005917.html
>
> Thanks, this looks constructive.
>
> Of the heuristics in that mail, most seem to me to be very sound
> justifications for thinking that the device is safe to probe.
>
> The one big exception is this:
>
> | * If vid is a known modem vendor (e.g. huawei, zte, sierra, u-blox,
> | telit), it's a modem and we probe the tty.
>
> This is a hostage to the future, since of course we don't know what
> devices might be manufactured by a particular vendor in the many-years
> life of a Debian release.
>
Yes, this one is probably the weakest rule of all. Still not sure at
which point to apply the rule, though. E.g. should it be applied after
having applied all the previous rules (in that case it would be a very
safe rule, maybe totally unneeded) or should it be applied as an OR to
some other rule (e.g. driver is option/sierra/qcserial OR vendor is
huawei/zte..., in this case it would be a weaker rule). Will need to
decide this based on testing with real devices.
> I guess that if we in Debian don't like that particular heuristic it
> would be possible for us to disble just that one ?
>
> I don't understand this one:
>
> | * If kernel driver of the TTY is option/sierra/qcserial,
>
> but maybe it is OK.
>
The "option", "sierra" and "qcserial" drivers are all TTY kernel
drivers for modems. Most TTYs from USB modems would fall into one of
these. No non-modem device should bind to these drivers.
I'm planning to have a patch ready to play with in the following week,
will let you know.
--
Aleksander
https://aleksander.es
Bug#877024: modemmanager should ask before messing with serial ports
> Many such modems present as USB serial devices, eg ttyACM or ttyUSB. > Consequently, modemmanager has the ability to open serial ports and > probe them to see if they respond to Hayes-style AT commands. That > functionality is currently triggered automatically by default, even > for USB serial ports whose USB device IDs are unknown to modemmanager, > or whose device IDs correspond to generic USB-to-serial adapters. > > I.e., if one is running a normal Debian installation and plugs in a > usb-to-serial converter, modemmanager will open the device and send AT > commands to it, to see if it is a modem. > > This behaviour is IMO unaccaptable, as a default. > A clarification here, ModemManager doesn't automatically probe usb-to-serial converters, those are "greylisted" so that they're only probed on "manual scans". Of course, the vid:pid needs to be known to MM and in the greylist, for this to happen. ModemManager also doesn't automatically probe platform TTYs, like physical RS232 ports in the host. -- Aleksander
Bug#877024: modemmanager should ask before messing with serial ports
Hey Ian! > Since the maintainers and upstream evidently disagree with this > tradeoff, it has been necessary for me to ask the TC to step in. > The maintainers don't actually disagree. Why didn't you bring this issue to the ModemManager mailing list in the first place? I personally don't follow any downstream ModemManager bug, and we even have a bug open upstream: https://bugs.freedesktop.org/show_bug.cgi?id=85007 > > * 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. 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... An easier thing would be to allow just "dpkg -R modemmanager", there should be no other package depending on the daemon itself. -- Aleksander
Bug#683839: Patch to disable scanning of unsafe devices by default
> It is evident from the history of this bug that the maintainers don't > agree with this as an approach. > I wonder how that is evident given that we (maintainers) still keep the bug open upstream and discuss about it from time to time... https://bugs.freedesktop.org/show_bug.cgi?id=85007 I personally acknowledge the problem, but so far I've failed to find time to think of what the proper solution would be... A full whitelist is something we don't really consider, given the large amount of devices coming out all over the world, and the lack of time we already have. 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. Plus, there isn't always a "user" to ask when a modem is plugged in, ModemManager (as NetworkManager) don't really require a GUI to work and lots of headless systems out there use it. One thing to maybe consider is whether we should just assume that it is a modem if: * We have more than one TTY exposed by the same USB device (are there non-modem devices out there that would usually do this?). * We have a TTY and a NET port exposed by the same USB device. Or in other words, don't autoprobe a TTY if the USB device only has that one single TTY... Less and less mobile broadband modems fall in that last case, and definitely none of the recent modems I've seen would fall into the single-TTY category (except for maybe "professional" ruggerized devices and such but sometimes they're not even USB but pure RS232, and those aren't probed automatically anyway). Maintaining a whitelist of single-TTY modems may be feasible... Blindly requiring a udev tag for a TTY to be probed during automatic scans will break all non-QMI non-MBIM modems :/ So yeah, totally open to discussion here. -- Aleksander
Bug#683839: Patch to disable scanning of unsafe devices by default
>
> /* Is the device in the manual-only greylist? If so, return if this is an
> * automatic scan. */
> -if (!manual_scan && g_udev_device_get_property_as_boolean (physdev,
> "ID_MM_DEVICE_MANUAL_SCAN_ONLY")) {
> -mm_dbg ("(%s/%s): port probed only in manual scan", subsys, name);
> +if (!manual_scan && !g_udev_device_get_property_as_boolean (physdev,
> "ID_MM_DEVICE_AUTO_SCAN_SAFE")) {
> +mm_dbg ("(%s/%s): port not known to be safe, probed only in manual
> scan", subsys, name);
> goto out;
> }
That will effectively block probing for all device ports (QMI, MBIM, net...),
not only TTYs.
--
Aleksander
signature.asc
Description: OpenPGP digital signature
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
Bug#877024: modemmanager should ask before messing with serial ports
> > What I'd love to see is a patch that makes modemmanger behave better for > our users while remaining installed and operational. If it's useful > enough, it should be acceptable upstream as Debian is not the only > community affected by this particular problem. > This is part of the discussion we had in the MM mailing list for such a solution: https://lists.freedesktop.org/archives/modemmanager-devel/2017-September/005917.html > (If only the USB standard had a class definition for 'serial device' that > was separate from 'modem device'.) > Yeah :) -- Aleksander https://aleksander.es
Bug#877024: modemmanager should ask before messing with serial ports
Hey Sam, > It looks like there hasn't been much traffic on this issue in the last > couple of weeks. > Well, I moved the discussion to the ModemManager mailing list and it's already been discussed there among MM developers. > My analysis is that the key technical point here is whether it's > acceptable to treat unknown devices as possible modems. > > It sounds like: > > 1) We don't have a good white list of modems. > > 2) We don't have an adequate blacklist of modems. Ian argues we never > will have an adequate blacklist of modems. > There's a third approach, which is what we've been discussing in the mailing list as a possible good compromise. We are going to update ModemManager with a new command line option that will enable some heuristics to try to guess whether a given set of ports correspond to a modem or not (e.g. based on kernel driver, usb layout and so on). Ideally, this means no blacklist would be needed, and ModemManager would only probe TTYs that are definitely modems. The drawback is that ModemManager won't automatically probe modems that would fall out of the heuristics, but given that most new modems come with network devices, the amount of devices left out should be minimal. The new command line option will enable the new heuristics, and if the command line option not given, the old behavior with the blacklist will be kept. I'm assuming Debian could make use of the new command line option by default, and that would solve this issue. > In going forward, I think it is important to consider that > Modemmanager's needs and Debian's needs may be different here. > In the case of Modemmanager as an upstream project, it may be desirable > to give the best experience for users who do have modems. > However, for Debian and for the Technical committee, we need to consider > what experience we want to give all our users and as a result value > damage caused by false positives more highly than the upstream project > might. Would the new approach satisfy Debian's needs? -- Aleksander https://aleksander.es
Bug#877024: modemmanager should ask before messing with serial ports
FYI, already implemented an initial approach, ready for testing: https://lists.freedesktop.org/archives/modemmanager-devel/2017-October/005969.html In the Debian case, you would want to use "--filter-policy=STRICT" when starting ModemManager. -- Aleksander https://aleksander.es
Bug#877024: modemmanager should ask before messing with serial ports
On Tue, Oct 17, 2017 at 6:48 PM, Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> Aleksander Morgado writes ("Re: Bug#877024: modemmanager should ask before
> messing with serial ports"):
>> FYI, already implemented an initial approach, ready for testing:
>> https://lists.freedesktop.org/archives/modemmanager-devel/2017-October/005969.html
>>
>> In the Debian case, you would want to use "--filter-policy=STRICT"
>> when starting ModemManager.
>
> Thanks. This is very encouraging. I would like to test this.
>
> My testing approach would probably be to prepare a Debian package of
> this version, based on the existing Debian package.
>
> It might be useful for me to upload such a thing to experimental so
> others can try it too ? Would the Debian modemmanager maintainers
> object to that ?
>
> I will do that upload: to DELAYED, picking some suitably cautious
> version number, unless I hear to the contrary. (And I'll wait at
> least a week for a reply to this question.)
>
How about waiting a bit until patches reviewed and tested upstream?
I'm worried about some devices in particular, like Bluetooth DUN based
ones, as I rarely test those and I'm almost certain that I broke them
in strict mode.
As soon as we get this merged to git master, I can tag a 1.8 beta
release (e.g. 1.7.990). What do you think?
--
Aleksander
https://aleksander.es
Bug#877024: modemmanager should ask before messing with serial ports
> > As soon as we get this merged to git master, I can tag a 1.8 beta > release (e.g. 1.7.990). What do you think? > FYI, 1.8-rc1 has been tagged with the optional filter policy support included: https://lists.freedesktop.org/archives/modemmanager-devel/2018-January/006157.html By default it uses the DEFAULT policy (equivalent to what we were doing until now). You can enable the STRICT policy passing --filter-policy=STRICT on the ModemManager startup (e.g. as a patch to the systemd service file). -- Aleksander https://aleksander.es
Bug#877024: modemmanager should ask before messing with serial ports
>> >> As soon as we get this merged to git master, I can tag a 1.8 beta >> release (e.g. 1.7.990). What do you think? >> > > FYI, 1.8-rc1 has been tagged with the optional filter policy support included: > https://lists.freedesktop.org/archives/modemmanager-devel/2018-January/006157.html > > By default it uses the DEFAULT policy (equivalent to what we were > doing until now). You can enable the STRICT policy passing > --filter-policy=STRICT on the ModemManager startup (e.g. as a patch to > the systemd service file). > Ian, any comment about this 1.8-rc1 version with the filter policies implemented? Also, is there any new maintainer I should talk to regarding integration tasks for this new version? -- Aleksander https://aleksander.es
Bug#877024: modemmanager should ask before messing with serial ports
>> Also, is there any new maintainer I should talk to regarding >> integration tasks for this new version? > > I've been in touch with Mathieu Trudel-Lapierre (Cc:ed) and he's still > happy to act as maintainer. He's currently not a DD/DM so needs > sponsorship for his packages, but that should not be problem. > > The @ubuntu email address that was on the package turns out to be > outdated, and was bouncing, which is why he's been out of the loop until > now. Ah! Superb :) -- Aleksander https://aleksander.es
Bug#930264: (no subject)
I am not yet sure what to do with this issue. The Arduino is saying that it has an AT-capable ttyACM port, so ModemManager tries to use the port. I'd like to improve the heuristics to detect this without falling back to the blacklist, but not sure yet how to reliable do that. Ideally, the Arduino shouldn't say that its ttyACM is AT-capable... Any suggestion on how to improve the heuristics, without falling back to the blacklist, would be appreciated. Maybe we should no longer try to use devices that expose one single ttyACM port even if the ports are reported as AT-capable?
Bug#930264: Your mail
And this is the suggested change to avoid the issue with the Arduinos wrongly claiming AT protocol support: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/143 -- Aleksander https://aleksander.es
Bug#930264: Your mail
The ID_MM_DEVICE_IGNORE udev tag is being ignored in strict filter mode, I'm trying to change that in this MR for the next MM release: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/138 Iain, could you let me know the full lsusb -v output of that specific DMR radio? I need to understand whether the device is wrongly claiming AT protocol support in the ttyACM interface or not. -- Aleksander https://aleksander.es
Bug#930264: Your mail
This issue should be hopefully solved in ModemManager 1.10.6 after adding several new heuristics to the "strict" filter mode. Also, the logic behind ID_MM_DEVICE_IGNORE was updated and this udev tag is now applicable in all filter modes (including "strict") and for all device types (not only TTYs). MM 1.10.6 release notes: https://lists.freedesktop.org/archives/modemmanager-devel/2019-September/007424.html -- Aleksander https://aleksander.es
