[RFC] Probing ttys by default

Sven Köhler sven.koehler at gmail.com
Fri Mar 21 06:23:09 PDT 2014


Am 21.03.2014 14:21, schrieb Bjørn Mork:
> Aleksander Morgado <aleksander at aleksander.es> writes:
>> On Fri, Mar 21, 2014 at 11:37 AM, Sven Köhler <sven.koehler at gmail.com> wrote:
>>> The kernel cdc_acm driver could expose whether the device seems to be a
>>> modem. It knows, through the bmCapabilities field in the CDC Call
>>> Management descriptor [1]. Another field that comes to mind is the
>>> bInterfaceProtocol of the Interface Descriptor. For devices that don't
>>> speak AT-commands it should be zero.
>>>
>>> Then one can craft some general udev rule that grey- or blacklists
>>> (what's the difference) all devices that don't seem to be a modem. If
>>> there devices out there that erroneously report that they don't have
>>> calling capabilities, then that those would have to be whitelisted.
>>>
>>> I can confirm that for the UMTS card in my Laptop, lsusb explicitly
>>> lists that it speaks the AT-commands protocol (bInterfaceProtocol=1) and
>>> that it has call management (bmCapabilities=3 in the CDC Call Management
>>> descriptor).
>>
>> Bjørn, Dan, do you guys think that this is something doable? Or,
>> otherwise, do you have any other idea on how we can handle this
>> better?
> 
> I think this makes sense as a generic best guess, as long as you have
> the possibility of overriding it in either direction.
> 
> I don't have any examples at hand, but I am sure there are vendors out
> there screwing this up completely so we need to deal with that. We
> cannot trust USB descriptors for anything Windows don't use them for.
> And Windows drivers tend to ignore almost anything that could be useful
> to a class handling driver/userspace, because they are made specifically
> for a single device.
> 
> Writing the rule should be pretty easy. Here's an example of a device
> where the info is correct (Ericsson is the exceptional vendor which tend
> to follow specs...):

The value of ATTR{bmCapabilities} you find below may be from the CDC ACM
descriptor instead of the CDC Call Management descriptor.
At least for my UMTS card that is true, and I see a value of 7 instead
of 3. My best guess is, that udev doesn't handle it very well if there
are two fields of the same name in different descriptors of the same device.

>   looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.1':
>     KERNEL=="2-2:1.1"
>     SUBSYSTEM=="usb"
>     DRIVER=="cdc_acm"
>     ATTR{bInterfaceClass}=="02"
>     ATTR{bmCapabilities}=="7"
>     ATTR{bInterfaceSubClass}=="02"
>     ATTR{bInterfaceProtocol}=="01"
>     ATTR{bNumEndpoints}=="01"
>     ATTR{supports_autosuspend}=="1"
>     ATTR{bAlternateSetting}==" 0"
>     ATTR{bInterfaceNumber}=="01"
>     ATTR{interface}=="F5521gw Mobile Broadband Modem"
> 
>   looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.3':
>     KERNEL=="2-2:1.3"
>     SUBSYSTEM=="usb"
>     DRIVER=="cdc_acm"
>     ATTR{bInterfaceClass}=="02"
>     ATTR{bmCapabilities}=="7"
>     ATTR{bInterfaceSubClass}=="02"
>     ATTR{bInterfaceProtocol}=="01"
>     ATTR{bNumEndpoints}=="01"
>     ATTR{supports_autosuspend}=="1"
>     ATTR{bAlternateSetting}==" 0"
>     ATTR{bInterfaceNumber}=="03"
>     ATTR{interface}=="F5521gw Mobile Broadband Data Modem"
> 
>   looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.9':
>     KERNEL=="2-2:1.9"
>     SUBSYSTEM=="usb"
>     DRIVER=="cdc_acm"
>     ATTR{bInterfaceClass}=="02"
>     ATTR{bmCapabilities}=="7"
>     ATTR{bInterfaceSubClass}=="02"
>     ATTR{bInterfaceProtocol}=="01"
>     ATTR{bNumEndpoints}=="01"
>     ATTR{supports_autosuspend}=="1"
>     ATTR{bAlternateSetting}==" 0"
>     ATTR{bInterfaceNumber}=="09"
>     ATTR{interface}=="F5521gw Mobile Broadband GPS Port"
> 
> 
> Note that you can apply similar logic to figure out the "Device
> Management" ports.  The bInterfaceProtocol attribute has the same
> meaning for both cdc-wdm and cdc-acm. So you will *know* that the
> /dev/cdc-wdmX device attached to this interface speaks V.250 AT commands
> even before probing it:
> 
>   looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.5':
>     KERNEL=="2-2:1.5"
>     SUBSYSTEM=="usb"
>     DRIVER=="cdc_wdm"
>     ATTR{bInterfaceClass}=="02"
>     ATTR{bInterfaceSubClass}=="09"
>     ATTR{bInterfaceProtocol}=="01"
>     ATTR{bNumEndpoints}=="01"
>     ATTR{supports_autosuspend}=="1"
>     ATTR{bAlternateSetting}==" 0"
>     ATTR{bInterfaceNumber}=="05"
>     ATTR{interface}=="F5521gw Mobile Broadband Device Management"
> 
> 
> Most vendors are of course going to make a mess out of this, but using
> it as a starting point cannot harm.
> 
> 
> Bjørn
> 


More information about the ModemManager-devel mailing list