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 688213 - modemmanager probes non-modem CDC_ACM devices
modemmanager probes non-modem CDC_ACM devices
Status: RESOLVED NOTGNOME
Product: NetworkManager
Classification: Platform
Component: ModemManager
0.6.4
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-11-12 23:12 UTC by Sven
Modified: 2014-10-14 15:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
USB descriptor of the device (2.89 KB, text/plain)
2012-11-12 23:13 UTC, Sven
Details

Description Sven 2012-11-12 23:12:50 UTC
The Atmel Corp. at91sam SAMBA bootloader is a USB device which claims to be a cdc_acm device. Now this device is an in-system-programmer to reprogram arm microcontrollers. It is not a modem and AFAIK it does understand AT commands.

When I plug it in, the kernel reports:
[84819.007525] usb 2-1.3: new full-speed USB device number 26 using ehci_hcd
[84819.093055] usb 2-1.3: New USB device found, idVendor=03eb, idProduct=6124
[84819.093062] usb 2-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[84819.093573] cdc_acm 2-1.3:1.0: This device cannot do calls on its own. It is not a modem.
[84819.093594] cdc_acm 2-1.3:1.0: ttyACM3: USB ACM device


As you can see, the kernel knows, that this device is not a modem. And I believe it knows that because of the USB device descriptor. I will attach it.

However, modemmanager seems to think that it is a modem and probes it:
Nov 13 00:03:40 localhost modem-manager[1832]: <info>  (ttyACM3) opening serial port...
Nov 13 00:03:52 localhost modem-manager[1832]: <info>  (ttyACM3) closing serial port...
Nov 13 00:03:52 localhost modem-manager[1832]: <info>  (ttyACM3) serial port closed
... and so on

This should not happen.
Comment 1 Sven 2012-11-12 23:13:36 UTC
Created attachment 228841 [details]
USB descriptor of the device
Comment 2 Sven 2012-11-12 23:54:51 UTC
Looking at /usr/src/linux/drivers/usb/class/cdc-acm.c, the kernel detect non-modem devices using the following:
(call_management_function & 3) != 3

As you can see, CDC Call Management bmCapabilities is zero for my device.
Comment 3 Aleksander Morgado 2012-11-13 06:46:00 UTC
Fixed in git master and MM_06 branch.

Meanwhile, you may want to add the following lines:
# Atmel Corp at91sam SAMBA bootloader
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="6124", ENV{ID_MM_DEVICE_IGNORE}="1"

To the blacklist at:
/usr/lib/udev/rules.d/77-mm-usb-device-blacklist.rules

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Comment 4 Sven 2012-11-13 09:19:24 UTC
Hey! You just blacklisted the device!

That is not a proper fix, as any other non-modem CDC-ACM device without call management will still be probed.
Comment 5 Aleksander Morgado 2012-11-13 09:38:35 UTC
It's not ideal, but that's the only way we currently do this, we don't really dig in what capabilities the CDC-ACM device exposes, and not sure if that's even reliable generally. Patches welcome :-)
Comment 6 Sven 2012-11-13 11:08:41 UTC
(In reply to comment #5)
> It's not ideal, but that's the only way we currently do this, we don't really
> dig in what capabilities the CDC-ACM device exposes, and not sure if that's
> even reliable generally. Patches welcome :-)

I played around with udevadm, and found that the kernel does not seem to make the information about the call management capabilities available as some sort of udev attribute (there is an attribute called bmCapabilities, but it's not clear to me whether it is CDC ACM or CDC Call Management).

But in addition to checking the call management capabilities and printing a message which appears in dmesg, the kernel also has a black list for non-modem devices:

Here's a quote from cdc-acm.c:

        /* Support Lego NXT using pbLua firmware */
        { USB_DEVICE(0x0694, 0xff00),
        .driver_info = NOT_A_MODEM,
        },

Again, it seems there is no easy way of checking via udev whether the device was blacklisted as "not a modem" or not.

Don't you agree, that it's stupid to have two blacklists (one in kernel and one in modemmanager)? Note, that the kernel used to ignore non-modem devices in the past. They didn't show up as ttyACM devices. But then they "fixed" that.

Is there a lack of communication between the modemmanager people and the kernel folks?

I also can't tell whether checking the call management capabilities is reliable. I will ask the kernel developers for advice. And while I'm at it, I will also ask them to expose the call management capabilities via udev.

Note, that non-modem CDC-ACM devices seem to be a big problem. OS X recognizes such devices as modems - and now it turns out, modemmanger does too (even though the kernel itself is fine).
Comment 7 Aleksander Morgado 2012-11-13 11:12:34 UTC
It's not really lack of communication between kernel and MM devs; actually Dan plays in both teams all the time.

Dan:
do you think we could at least replicate the NOT_A_MODEM blacklist in cdc-acm for now? And, what do you think would be best to avoid having the separate blacklists?
Comment 8 Simon Schubert 2013-08-13 22:49:48 UTC
This has been a repeat problem for me - I think the PR should be re-opened until a sustainable fix has been committed.

Blacklisting every single CDC device will not work, especially now that more people are starting to build their own hardware, using cheap development boards.
Comment 9 Sven 2013-08-13 23:08:53 UTC
Reopened, until there is a proper fix. If the kernel doesn't expose the attributes you need, ask the kernel devs to expose them or find another way to access them.

P.S.: not sure how to reopen with this strange bugzilla.
Comment 10 Lars Knudsen 2014-03-20 23:38:04 UTC
I am currently sitting with the same problem...again  VID=0x0425, PID=0x0408 

Over the last 2 years, I have been working on different projects as a contractor, where this problem popped up.

Seriously:  At least provide a bail-out identifier that we can put in the USB/CDC descriptors so modemmanager doesn't pick up the device.  Right now, we are in the process of releasing a device that must work on Mac, Windows, Chromebook and Linux (in general) and our only current way of making our solution work on Linux is to change our VID/PID to something that has already been blacklisted ages ago.

IF we are going to have to live with this monster (sorry.. it's been painful ;)) in the future - AND have it automatically grab whatever it doesn't know getting a /dev/ttyXXX - at least make it very clear to HW/firmware developers how they can make some configuration that will tell modemmanager to go away.  It would be best if we can completely avoid modemmanager to even open a connection (by reading the CDC profile) but until then - could we e.g. make it so that if the first thing the device replies upon "AT" sent is e.g. "GO AWAY MODEMMANAGER!!!" - then modemmanager will quietly and swiftly like a ninja release and forget?

If you already now know of a way for devices to communicate this - please do tell... we hope to be able to release some hardware soon.

br
Lars
Comment 11 Sven 2014-03-21 08:48:19 UTC
I still can't reopen this, even though I'm the reporter and they devs don't reopen this and prefer to leave things as they are.

Lars: you should probably report a new bug. The current way of solving this issue is by blacklisting with udev rules. If you're not happy with it (which I would totally understand, see comment #4), you should encourage the developers to change this by opening a new bug. I bet, nothing has changes and the kernel still doesn't expose the necessary attributes to make it easy for modemmanager to access whichever attributes from the device descriptors lets them distinguish between modems and non-modems.
Comment 12 Lars Knudsen 2014-03-21 08:55:44 UTC
(In reply to comment #11)
> I still can't reopen this, even though I'm the reporter and they devs don't
> reopen this and prefer to leave things as they are.
> 
> Lars: you should probably report a new bug. The current way of solving this
> issue is by blacklisting with udev rules. If you're not happy with it (which I
> would totally understand, see comment #4), you should encourage the developers
> to change this by opening a new bug. I bet, nothing has changes and the kernel
> still doesn't expose the necessary attributes to make it easy for modemmanager
> to access whichever attributes from the device descriptors lets them
> distinguish between modems and non-modems.

Hi Sven,

it's pretty annoying if the developers are not interested in the problems people are facing with the current design :(

We are contemplating different near term solutions:

1. if the device receives an "AT" as the first thing it gets, disconnect the usb and reconnect as a different device that we know is on the blacklist (not very nice - but a hack we need to do to not let the device hang forever)

2. if we detect that our device has been grabbed on Chromebook and other Linux devices, put a big note on screen for the user to contact the developers behind ModemManager to get them to change the design.  At least the amount of pledges from average users might push the developers to consider a redesign.

3. "throw the towel in the ring" and go against all that is good in the way USB should work and report a VID/PID as we know is blacklisted from the beginning... this will create some interesting results on Windows and Mac .. especially when the device pops up as an Arduino or other.
Comment 13 Sven 2014-03-21 09:27:19 UTC
In my optinion, whatever you do, Lars, don't hijack USB IDs of other vendors just because ...

Have a proper ACM/CDC that says "this device can't do calls". To the best of my knowledge, that is the proper way. As I wrote in comment #2, the kernel performs some checks some field of the CDC Call Management descriptor. However, the result of the check is used for nothing else than printing some stupid message. It is not clear, whether modemmanager can easily access the outcome of this test (unlikely!, see comment #6) or easily reimplement the check (why or why!?). It also has turned out, that kernel and modemmanager have their own device blacklists (why oh why!?).

The modemmanager developers however have argued, that the descriptors might not be reliable (comment #5). In the worst case, using the field of the CDC Call Management descriptor would mean that there has to be a white- _and_ a blacklist. The whitelist would cover devices that incorrectly report that they can't do calls. The blacklist would remain the same as before.

As I have pointed out earlier, this is something that needs to be solved hand in hand by kernel and modemmanager developers. The kernel should ideally report whether device is a modem or not. modemmanager should then ignore those devices reported not the be a modem.

The status quo hasn't moved an inch, which of course indicates a mismanagement on the side of the developers. As Lars points out, there is currently no way to have a ACM/CDC device that are not picked up my modemmanager.

Now there is a chance that I'm wrong in the worst way possible, namely in the sense that ACM/CDC devices are required to understand AT commands (they can return an error when receiving AT commands though) since ACM/CDC was intended only for modems by whoever thought it up.

@Lars: have you read the ACM/CDC spec? Can you confirm that it allows for non-modem ACM/CDC devices? If not, then the solution would not be in your list. The solution would be moving away from ACM/CDC and instead implement something that is compatible with and is automatically picked by usbserial. You will need to write an *.inf for Windows and I'm not sure about OS X.

I can only encourage you, Lars, to open a new bug (please add me as CC). Maybe, you should also open a bug in the kernel's bugzilla (https://bugzilla.kernel.org/) or maybe start a discussion on the Linux Kernel Mailing List.
Comment 14 Aleksander Morgado 2014-03-21 09:57:05 UTC
(In reply to comment #11)
> I still can't reopen this, even though I'm the reporter and they devs don't
> reopen this and prefer to leave things as they are.
> 

The bug is not closed; I reopened it long ago.

As for the actual issue, I'll move the discussion to the ModemManager mailing list and put both of you in CC. Please subscribe if you want to get other replies there:

http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel/
Comment 15 Lars Knudsen 2014-03-21 10:41:40 UTC
(In reply to comment #14)
> (In reply to comment #11)
> > I still can't reopen this, even though I'm the reporter and they devs don't
> > reopen this and prefer to leave things as they are.
> > 
> 
> The bug is not closed; I reopened it long ago.
> 
> As for the actual issue, I'll move the discussion to the ModemManager mailing
> list and put both of you in CC. Please subscribe if you want to get other
> replies there:
> 
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel/

Thanks for the update - I just subscribed.  It would be great if we can find a solution that looks for specific things in the CDC descriptor - and at the same time, make a good and solid description of what these things should be an a few typical reference implementations AND put this a place that will be easy to find for HW developers.
Comment 16 Aleksander Morgado 2014-03-21 11:41:02 UTC
> Thanks for the update - I just subscribed.  It would be great if we can find a
> solution that looks for specific things in the CDC descriptor - and at the same
> time, make a good and solid description of what these things should be an a few
> typical reference implementations AND put this a place that will be easy to
> find for HW developers.

Sadly, it isn't the case that HW developers come to us to see how they can integrate their hardware better in a Linux-based platform. It is usually the other way around, and we need to deal with different approaches used by different manufacturers. Finding the 'perfect fit' for every case is really an almost impossible task, especially when HW manufacturers change their way of handling and exposing devices often (e.g. different behaviours of completely different devices using all the same VID/PID).
Comment 17 Zygmunt Krynicki 2014-09-02 14:41:36 UTC
Could we at least confirm the issue to acknowledge the fact that non-modem devices _are_ being probed before we can be certain that is not the case?
Comment 18 Simon Schubert 2014-09-02 15:07:10 UTC
How about using the CDC Call Management Functional Descriptor (CDC PSTN 5.3.1): the bmCapabilities field can report "Device does not handle call management".  Under linux, this gets reported as "This device cannot do calls on its own. It is not a modem." (cdc-acm.c:1148).

Serial devices that expressively do not want to be contacted by ModemManager could include this standard descriptor to signal that they are no modem.
Comment 19 Aleksander Morgado 2014-09-03 08:18:48 UTC
(In reply to comment #18)
> How about using the CDC Call Management Functional Descriptor (CDC PSTN 5.3.1):
> the bmCapabilities field can report "Device does not handle call management". 
> Under linux, this gets reported as "This device cannot do calls on its own. It
> is not a modem." (cdc-acm.c:1148).
> 
> Serial devices that expressively do not want to be contacted by ModemManager
> could include this standard descriptor to signal that they are no modem.

*could* but then they may not... and then we're back again in square one. We cannot control what HW manufacturers do, so we need some compromise between probing all ports and not probing any: and that compromise is for now the black/greylists :/

Anyway, if someone wants to develop that NOT_A_MODEM check in cdc-acm or looking for the call management capabilities, I wouldn't mind to test it with my modems.
Comment 20 Aleksander Morgado 2014-09-03 08:21:46 UTC
(In reply to comment #17)
> Could we at least confirm the issue to acknowledge the fact that non-modem
> devices _are_ being probed before we can be certain that is not the case?

non-modem devices exposing TTYs via USB are being probed automatically unless their USB VID/PID is blacklisted or greylisted in MM's lists in udev.

BTW; cdc-acm devices are just *one* case.
Comment 21 Simon Schubert 2014-09-03 08:47:57 UTC
(In reply to comment #20)
> non-modem devices exposing TTYs via USB are being probed automatically unless
> their USB VID/PID is blacklisted or greylisted in MM's lists in udev.

That means the bug status should be changed to CONFIRMED.
Comment 22 Simon Schubert 2014-09-03 08:50:21 UTC
(In reply to comment #19)
> *could* but then they may not... and then we're back again in square one. We
> cannot control what HW manufacturers do, so we need some compromise between
> probing all ports and not probing any: and that compromise is for now the
> black/greylists :/

At least that would be a generic way for manufacturers to declare non-modemness.

> Anyway, if someone wants to develop that NOT_A_MODEM check in cdc-acm or
> looking for the call management capabilities, I wouldn't mind to test it with
> my modems.

Do you have any pointers on where/how to implement this in the ModemManager code?
Comment 23 Sven 2014-09-03 09:00:49 UTC
(In reply to comment #19)
> *could* but then they may not... and then we're back again in square one. We
> cannot control what HW manufacturers do, so we need some compromise between
> probing all ports and not probing any: and that compromise is for now the
> black/greylists :/

It has been pointed out before that the current situation, which is that the modemmanager _requires_ HW manufacturers to blacklist their devices, is bad. The updated blacklist only appear in major distros only after years, maybe. And there is no way to make a device work with "Linux" (so to speak) within a reasonable time frame for that reason.

I can't really follow the reasoning that modemmanager shouldn't look at the USB descriptor just because some stupid manufacturer may advertise their device as having calling capabilities and speaking the AT protocol when really it has not. That's kind of an insult to all the manufacturer and developers who set their USB descriptors correctly.

Also, the direction of this argument is new. So far, we had the the argument (on the mailinglist), that devices may not advertise calling capabilities and the AT protocol when they are in fact modems. Hence, we cannot exclude all those devices.

Oh well. The world is bad. Manufacturers are stupid. But as I pointed out, OS X has pioneered in this area and is not probing all devices, depending on the USB descriptors (I was not yet able to find out the exact rules, as I have no hardware available to test this and I think the source for this is not open).

On the mailing list, the discussion was stuck at two points:
1) The developer of the kernel cdc acm module was asked whether it would be possible to make more of the USB descriptor accessible via sysfs. No response. However, the apparently obstacles are: (a) a patch has to be written, (b) a name clash must be circumvented, as the developers have chosen to export a single attribute of the USB descriptor under the general name "bmCapabilities", even though there is a second attribute of the very same name. (The latter was really a poor choice, as the problem was forseeable.)

2) The effect on devices that are modems and have a broken USB descriptor must be minimized. Two obstacles exist: (1) the fear of the developers that there are many such devices and (2) there is no database of USB descriptors which could guide the development process.


I believe I already had proposed that modemmanger only ignore devices that fail all of a number of tests. Currently, there are at least two checks one can do, namely check both the bmCapabilities fields. I don't remember whether the was a third one.

Then a white list was proposed to whitelist all main modem manufacturers such that their modems don't get ignored. The assumption of course is, that all non-modem TTY devices are made by other manufacturer, which might not be true. I don't know.

Anyhow, the discussion never progressed beyond that. There does not seem to be much motivation to fix this.


BTW: the check that produces the "This device cannot do calls on its own. It
is not a modem." message in dmesg is completely useless. The result of this check is thrown away, modemmanager does not have access to it. The kernel even has some sort of graylist of devices for which this message is produced. Again, the result is a message - but nothing more. There is no way to determine, whether a device produced this message or not. As I said, the code in the kernel module is useless at the moment.
Comment 24 Sven 2014-09-03 09:05:00 UTC
Ah yes, there was a third check: bInterfaceProtocol
Comment 25 Aleksander Morgado 2014-10-14 15:48:15 UTC
Moving bugreport to the new ModemManager bugzilla in fd.o; summarized the issue
there as well. The new issue is not specific to cdc-acm, though.
  https://bugs.freedesktop.org/show_bug.cgi?id=85007
Please subscribe to the new bugreport to get new updates. Closing this report as NOTGNOME.

BTW, I really have mixed feelings about this issue, but I'm now tempted to say that having a whitelist of modem vendor VIDs could no longer be feared.
  https://bugs.freedesktop.org/show_bug.cgi?id=85007#c1