After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 608022 - Autoprobing makes serial non-modem devices unusable
Autoprobing makes serial non-modem devices unusable
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: ModemManager
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Depends on:
Blocks:
 
 
Reported: 2010-01-25 11:33 UTC by dom_fischer
Modified: 2010-08-14 21:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
lsudev output for smartcard reader device (54.91 KB, application/octet-stream)
2010-01-25 11:33 UTC, dom_fischer
  Details
lsudev/lsusb output for Treo900 (20.00 KB, application/x-tar)
2010-02-05 11:39 UTC, dom_fischer
  Details
Patch for blacklisting ports (1.92 KB, patch)
2010-02-17 14:52 UTC, torsten
none Details | Review
use udev property to blacklist ports (850 bytes, patch)
2010-02-19 15:37 UTC, Alexander Sack
none Details | Review

Description dom_fischer 2010-01-25 11:33:03 UTC
Created attachment 152218 [details]
lsudev output for smartcard reader device

When ModemManager probes for serial modem devices it makes non-modems unusable.

I don't want to double the work, so please also see: https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/421673

To help you find a way to e.g. blacklist devices I will attach the output of lsudev for a PCMCIA SmartcardReader to this bug. Relevant is ttyS0.

The Modemmanager Version I've tested:
0.2.git.20100102t025215.a06b3f2-0ubuntu1~nmt1~karmic

Kind regards,
Dominik Fischer
Comment 1 Peter Svensson 2010-01-25 18:02:11 UTC
In addition to USB devices, also normal serial ports should be possible exclude. Parhaps some way to mark devices not to be probed in udev?

The current probing wrecks havoc on e.g. embedded devices attached to serial ports.
Comment 2 Dan Williams 2010-01-25 21:07:27 UTC
(In reply to comment #1)
> In addition to USB devices, also normal serial ports should be possible
> exclude. Parhaps some way to mark devices not to be probed in udev?
> 
> The current probing wrecks havoc on e.g. embedded devices attached to serial
> ports.

For devices that have specific identifiers (USB/PCI and to some degree PCMCIA) we can blacklist devices or whole drivers as appropriate.  Where we have to be careful is where the driver drives a lot of devices (cp210x for example) where some are actually modems and some are not.

Furthermore some PCMCIA devices (Sierra 775, 850, 860 and Novatel 620) are 3G cards and show up as /dev/ttyS0.  So we can't automatically exclude legacy serial ports.  There are also cases where we may want to probe legacy serial-connected devices, which of course we can't get any identifying information out of.

So in short; we can probably whitelist PCMCIA devices by manfid.  We then also blacklist certain USB devices by vid/pid.

Somebody needs to get that list started, any takers?  Can I get an 'lspcmcia -v' for the smartcard reader?
Comment 3 Peter Svensson 2010-01-26 07:23:43 UTC
I really think (well, I certainly need it) that we need a mechanism to manually specify ports to exclude, even if they would by default be probed. IDeally tied to the udev scripts since that is where we specify things like permissions etc for the ports in the system. 

Can the udev ENV menchanism be used to pass information from udev to modemmanager?
Comment 4 Dan Williams 2010-01-26 07:30:31 UTC
Yes, udev is the best candidate for such a system of blacklisting.  We don't want to manually specify *ports* by name, we want to blacklist specific devices or drivers.  Since port names are not stable (especially with USB), you never want to say "blacklist ttyUSB0".
Comment 5 Peter Svensson 2010-01-26 07:38:53 UTC
Some ports are stable (e.g.ttyS0 and ttyS1 which are real serial ports in some of the lab computers). Other ports udev can figure out by connection. So, I really would like to see a way to specify from udev (using all the rules and scripts available there) which ports should not be touched.

For now I have killed off modemmanager on all computers doing anything with the embedded systems. Kind of annoying for the laptops though...

I will reinstall modemmanager and kill the generic plugin later when I have time to test it. Perhaps a way to tell modemmanager to not touch anything it is not sure of is a modem?
Comment 6 Dan Williams 2010-01-26 20:43:03 UTC
The problem not touching things it's not sure of is mobile phones; that's why MM does probing in the first place.  There are tons of phones out there and there's no way to whitelist them.  Some use usbserial, some use cdc-acm, and there's no way figure out unless we probe them.

I'm also not sure there's a good way to figure out that the machien you're running has real legacy serial ports, since PCMCIA serial cards show up as ttySX.  On a machine without real serial ports (though internally who knows what PNP does) the PCMCIA serial card will show up as ttyS0.
Comment 7 Peter Svensson 2010-01-27 06:58:03 UTC
Yes, I understand the need for probing. What I need is a way to disable probing for interfaces I know are not modems, and that are hurt by the probing. The user can know this, but ModemManager, as you say, can not. Thus the need to be able to specify ports not to touch manually.

I would have preferred ModemManager to ask before probing any devices not certain to be modems, but I can apprechiate that this would annoy more users than it benefits. Thus a manual blacklisting of ports.

Does ModemManager receive the environment set up by the udev scripts? In that case, a simple do-not-touch environment variable would suffice.
Comment 8 dom_fischer 2010-01-27 12:23:36 UTC
> Somebody needs to get that list started, any takers?  Can I get an 'lspcmcia
> -v' for the smartcard reader?

# lspcmcia -v 
Socket 0 Bridge:   	[yenta_cardbus] 	(bus ID: 0000:05:00.0)
	Configuration:	state: on	ready: yes
			Voltage: 5.0V Vcc: 5.0V Vpp: 0.0V
Socket 0 Device 0:	[serial_cs]		(bus ID: 0.0)
	Configuration:	state: on
	Product Name:   Gemplus SerialPort GemPC Card 
	Identification:	manf_id: 0x0157	card_id: 0x0100
			function: 2 (serial)
			prod_id(1): "Gemplus" (0x0981590f)
			prod_id(2): "SerialPort" (0xe9010d26)
			prod_id(3): "GemPC Card" (0xddc63bd8)
			prod_id(4): --- (---)
Comment 9 dom_fischer 2010-02-05 11:39:11 UTC
Created attachment 153075 [details]
lsudev/lsusb output for Treo900

I've attached the output from lsudev and lsusb for a treo900 device. So you can extract informations to blacklist this device too.
Comment 10 torsten 2010-02-17 14:52:18 UTC
Created attachment 154040 [details] [review]
Patch for blacklisting ports

The attached patch is a first attempt of getting a blacklisting functionality into modem manager. It evaluates /etc/modemmanager/blacklist and does not probe a port specified there. 

The patch reads the blacklist file currently for every port that is meant to be polled. It would be much nicer if it would read the file only once and stores it. I would need guidance how to achieve this.
Comment 11 Alexander Sack 2010-02-19 15:37:12 UTC
Created attachment 154215 [details] [review]
use udev property to blacklist ports

adjusting thorsten's patch to look at udev property rather than adding a conffile.
Comment 12 torsten 2010-02-19 16:18:51 UTC
I tested Alex' patch and it works for me. I added a udev rule for blacklisting a 3G USB key and it was not probed by the generic plugin, only by the specialized one (option).
Comment 13 Dan Williams 2010-04-10 02:43:12 UTC
Blacklisting added as of:

44deca2c5a9b7414d2e65fc62f87f67df3066810

I've added blacklists for all the UPS devices I could find in 'nut', as well as the Palm 700/900 and the GemPlus device in this bug.

The blacklisting is a little bit different than the previous patch.  We want to blacklist the *physical* device, not the ports, because blacklisting individual ports of a device lets MM probe the other ports of the device and possibly control them, which would be a problem.
Comment 14 gdt 2010-05-25 04:32:01 UTC
Thanks for this. It looks like we can now have serial terminals working again on recent Fedora.