[RFC] Probing ttys by default

[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...):

  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