Ubuntu
modemmanager package

/sbin/modemmanager is too aggressive managing devices that aren't known to be modems

Bug #490194 reported by Carey Underwood
66
This bug affects 13 people
Affects Status Importance Assigned to Milestone
modemmanager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: modemmanager

When connecting an embedded processor via usb (beagleboard or overo), modemmanager immediately starts sending commands to the device with no prompting or otherwise. This is very disruptive to terminal sessions to those devices, especially when uploading firmware or typing commands that need to be correct to avoid bricking the device.]

"""
cwillu@applicati:/dev$ sudo picocom -b 115200 ./serial/by-id/usb-Das_U-B*
picocom v1.4

port is : ./serial/by-id/usb-Das_U-Boot_U-Boot_2009.01-dirty_0000000-if00
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
escape is : C-a
noinit is : no
noreset is : no
nolock is : no
send_cmd is : ascii_xfr -s -v -l10
receive_cmd is : rz -vv

Terminal ready
AT+GCAP
Unknown command 'AT+GCAP' - try 'help'
OMAP3 beagleboard.org # OAT+GCAP
Unknown command 'AT+GCAP' - try 'help'
OMAP3 beagleboard.org #

"""

The AT+GCAP lines above weren't typed by me, but by another process (modemmanager) sending commands to the port. They showed up here because the beagleboard boot loader echoes characters back. The other process continues to send control characters continually which don't disrupt single keystrokes, but which garble lines being pasted or or otherwise transferred to the remote. This has already soft-bricked one of my beagleboards.

ProblemType: Bug
Architecture: i386
Date: Sun Nov 29 22:20:16 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: modemmanager 0.2.git.20091014t233208.16f3e00-0ubuntu1
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_CA.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-14bfsbfq1.48-generic
SourcePackage: modemmanager
Uname: Linux 2.6.31-14bfsbfq1-generic i686

Revision history for this message
Carey Underwood (cwillu) wrote :
Revision history for this message
Jochen Gruse (lpnet) wrote :

I concur, modemmanager is far too aggressive. Please take a look at these bugs, too:

https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/686418
https://bugs.launchpad.net/ubuntu/+source/gobi-loader/+bug/621743
https://bugs.launchpad.net/ubuntu/+source/gobi-loader/+bug/647471

gobi-loader is often blamed, but modemmanager is the culprit trying to access the QDL device while the firmware load is still in progress und thus corrupting the upload. Blacklisting all USB QDL devices of the Gobi modem solves the problem by stopping modemmanager from accessing the corresponding devices.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in modemmanager (Ubuntu):
status: New → Confirmed
Revision history for this message
Roland McIntosh (u-launchpad-rgm-spamgourmet-com) wrote :

This also happens on Ubuntu 13.04 Raring Ringtail for bluetooth serial ports like /dev/rfcomm0. It makes interfacing with robots that use cheap bluetooth SPP modules difficult.

Revision history for this message
brainbug (christoph-amma) wrote :

I experienced the same issue under Ubuntu 13.04 with a prototype research device using a Bluetooth SPP module over /dev/rfcomm (like Roland already pointed out) and this issue probably affects lots of people working with self-built Bluetooth or cable bound serial port devices. This is a very bad and non-acceptable behavior of modemmanager for the following reasons:

1. Things break that used to work before an distribution update. In the past, unfortunately I do not know the exact version but 11.x should have worked, things worked. Maybe modemmanager was not probing devices automatically or was not activated/installed by default. From a user perspective, there is no easy way to find out why things don't work as expected anymore. I, for example, had to inspect the memory holding the incoming bytes on my microcontroller to realize that more bytes arrive than my application is actually sending. It took me quite a while and it was really annoying.

2. Devices might behave unusual from one day to the next after an update, because they receive bytes they do not expect. In the best case, the devices do not work at all, in the worst case they behave oddly and might even get damaged or cause damage (robots, control devices... who knows what's out there)

From what I read in other bug reports, the developers of modemmanager favor a blacklist of devices not to probe as the solution to this issue. I strongly disagree with this solution because it is not working for all the prototype devices and relies on the idea that every problem has to occur once and annoy somebody once before it is solved.

Revision history for this message
Chris Weiss (cweiss) wrote :

this is also affecting me, udev ignore rule for BeagleBone rev A3:

ATTRS{idVendor}=="0403", ATTRS{idProduct}=="a6d0", ENV{ID_MM_DEVICE_IGNORE}="1"

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.