GNOME Bugzilla – Bug 647556
modemmanager crashes braille display
Last modified: 2014-07-31 08:29:29 UTC
Reported as Debian Bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621851 A debug log is attached at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=19;filename=modemmanager.log;att=1;bug=621851 When a braille display is connected to the system through a serial to USB adapter, /dev/ttyUSB0, it has been noticed that the braille displa handled by brltty stops working at network manager startup. The hypothesis is that network-manager is trying to figure out whether /dev/ttyUSB0 is a modem. It may be better not to do that by default since a braile display hangup is an important problem for a blind user (imagine that would break the display on screen...). > This is most likely a modemmanager issue. Your correct ! Starting it (with networkmanagerstopped) was enough to crash my braille display. According to the attached log modemmanager indeed tries to look fora modem on /dev/ttyUSB0, which is the device corresponding to the USB to serial adapter used to connect the braille display to the computer.
We've got some blacklists and whitelists for probing, so if we can get the USB VID/PID of the braile device and also the driver name we can blacklist this one. For the driver name: ls -al /sys/class/tty/ttyUSB0/device/ and we'll see if the driver is something we should blacklist instead of just the VID/PID.
Since the braille display has a serial connection and the laptop only has USB ports, the two are plugged to each other using a serial to USB adaper, namely one from Prolific, VID=067b, PII=2303. The braille device itself does not have either VID or PID. So it could very well be a modem which is plugged instead of the braille display. Perhaps it could be checked whether the device isn't already in use by another process ?
Some distributions already blacklist serial to USB converters themselves in their MM packaging (e.g. Ubuntu), but we don't do that in upstream MM. What I would like to have in MM, instead, is a new 'greylist' where we tag these adapters, and have MM not automatically probe this ports, and instead only probe them if the user calls Scan() in the Modem interface. See bug 691076.
Fixed in git master now
Err, do I understand it right that modemmanager would, without user confirmation, scan for *any* device providing a USB serial interface, unless they have been explicitly blacklisted or greylisted? That looks to me like just asking for breaking hardware. I mean: new USB devices and dongles will always be added on the market, and for each of them, until somebody finds the time to manage to find out that the culprit is modemmanager, and then request a black/greylist from modemmanager, whatever *any* user will plug at the other end will get bothered by modemmanager probes. This is really asking for ad aeternam troubles. Couldn't modemmanager rather use automatically only a *white* list of what is really known to be interesting, and use a greylist only if the user requests it, and probe for anything else *only* if the user *really* requests it? The bug at stake here (braille device) is really serious: think of it as "modemmanager may kill your VGA screen, depending on how it is connected to your PC, and whether modemmanager happens to have blacklisted it". Even worse, we have seen in the past some probe sequences which would actually *brick* the device!
Agreed with Samuel - having a manual greylist doesn't cut it - there are probably just as many devices out there that should not be probed as devices that should be probed. Hence, both a whitelist and a blacklist approach will be cumbersome to maintain and always out of date. Still, given the safety argument, having a whitelist is much preferred. Additionally, I suppose the user should simply be in charge of what happens here - it's the only way to really distinguish between devices. Something like "A new device was plugged in: <vendor> / <model>. Is this a modem device that should be scanned? Yes/No". Probably a "Just once / Remember for this device / Apply to all future devices" radiobutton is a good addition as well? (for reference - I'm stumbling upon this bug because my Arduino boards won't talk to my PC properly when plugging them in, I have to wait for MM to release the device again...)