ModemManager sending data to a device that is not a modem

You can probably blacklist like it is done for some other devices. Look at:

/lib/udev/rules.d/77-mm-pcmcia-device-blacklist.rules
/lib/udev/rules.d/77-mm-qdl-device-blacklist.rules

and add a line like this:

ATTRS{prod_id1}=="Gemplus", ATTRS{prod_id2}=="SerialPort", ATTRS{prod_id3}=="GemPC Card", ENV{ID_MM_DEVICE_IGNORE}="1"

This blacklisting should probably not be added to Ubuntu; someone might want to connect a modem or GPS to one of those serial adapters.

Thanks for the answer. Currently I've simply removed the modem-manager binary from my system. Next time I'll upgrade my distro I'll use you advice and locally blacklist the serial adapters with udev.

However, my point is that the idea of opening automatically each serial port and sending AT commands as-if it were a modem is a brittle solution for plug and play. There are a lot of other devices that apper as serial ports, such as GPS, Arduinos, even old printers and plotters, etc. that might not like AT commands.
One such example is this: http://fedetft.wordpress.com/2011/01/07/linux-today-too-much-plug-and-play/#comment-202 where modem-manager seems to interfere with a set-top-box.

Those at GPSD that used to make the same thing after my bug report found a good solution: they open the port for a couple of seconds and listen only, which is way less invasive than sending data. I don't know if this is a possible solution for modem-manager. Another option, if modem-manager runs only after the user logs in (which I don't know) would be a popup the first time a serial adapter is connected.

Japp, I see your consern. It would maybe be better to whitelist devices we know are modems instead. But what would you listen to if you just open the port? Assume GPS devices sending NMEA data, but what about modems? I am not sure if it is common for them to start sending any data when the port is just opened.

Note: I'm writing all this hoping it will be useful to you to understand the whole problem and find a general solution. For me it's no longer a problem, since with the udev rules I can fix my distro myself and call it a day.

Whitelisting would be the perfect solution, but it would be difficult to implement.
Talking to the GPSD developers I discovered that there are devices that are neither in nor out.
For example, the PL2303 is the worst. It is a cheap IC used by OEM to assemble a whole range of products, including USB to serial ports, USB adapters for older cellphones, and GPSes. Don't know if it's used for modems too, but if it is, you're in trouble as well. The bad is that it has absolutely no identification info, no serial number whatsoever. It appears as a "ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port" with no way to know what's behind. This raises the edge case of an user with two distinct devices, one which is a modem and another which is not (and doesn't withstand AT commnads), that both identify as a PL2303. In this case there's no way to make whitelisting/blacklisting work.

Aside from this edge case, the bigger issue is if these generic IDs such as PL2303 or FT232 should be in the whitelist by default, or not. If they are, some non-modems devices may "misteriously malfunction", since not all users have the skill to track down the issue and unserstand it's because of modem-manager. But if they aren't in the whitelist by default, some modems may not work out of the box...

Hello,
I just wanted to add that the problem here appears also with bluez. Whenever I add a serial device with bluez modem-manager opens the device before I can and makes the resource busy. So I had to uninstall modem-manager here as well.
Maybe modem-manager needs and addition or bluez any rule which should prevent modem-manager to take the virtual serial port.