Re: nm in different linux distributions - ppp versus qmi-wwan

[Dan Williams <dcbw redhat com>]

On Fri, 2015-11-06 at 23:40 +0100, Bjørn Mork wrote:
> Thomas Schäfer <tschaefer t-online de> writes:
> > lsusb-20151106-suse.txt (good case)
> > lsusb-20151106.txt (manjaro - bad case)
> >
> >
> > both use kernel 4.1.x
> >
> > The diff is not big:
>
> Yes, the device appears identical, switched to the same mode with a
> single config.  This is as expected.
>
> >     Interface Descriptor:
> >       bLength                 9
> >       bDescriptorType         4
> >       bInterfaceNumber        3
> >       bAlternateSetting       0
> >       bNumEndpoints           1
> >       bInterfaceClass       255 Vendor Specific Class
> >       bInterfaceSubClass      1 
> >       bInterfaceProtocol      9 
> >       iInterface              0 
> >       ** UNRECOGNIZED:  05 24 00 10 01
> >       ** UNRECOGNIZED:  0d 24 0f 01 00 00 00 00 00 20 01 00 00
> >       ** UNRECOGNIZED:  05 24 06 03 04
> >       Endpoint Descriptor:
> >         bLength                 7
> >         bDescriptorType         5
> >         bEndpointAddress     0x85  EP 5 IN
> >         bmAttributes            3
> >           Transfer Type            Interrupt
> >           Synch Type               None
> >           Usage Type               Data
> >         wMaxPacketSize     0x0040  1x 64 bytes
> >         bInterval               5
> >     Interface Descriptor:
> >       bLength                 9
> >       bDescriptorType         4
> >       bInterfaceNumber        4
> >       bAlternateSetting       0
> >       bNumEndpoints           2
> >       bInterfaceClass       255 Vendor Specific Class
> >       bInterfaceSubClass      1 
> >       bInterfaceProtocol      8 
> >       iInterface              0 
>
>
>
> Interfaces 3 and 4 make a QMI function together. They are using Huaweis
> well known QMI subclass/protocol values, and the control interface has a
> valid union descriptor.  All looking good.  The mainline option driver
> will not attempt to probe these interfaces by default.
>
> > [  164.681791] option 4-2:1.3: GSM modem (1-port) converter detected
> > [  164.682175] option 4-2:1.4: GSM modem (1-port) converter detected
> > [  164.682557] usb 4-2: GSM modem (1-port) converter now attached to ttyUSB4
>
>
> But the option driver erronously tries to bind (to both interfaces
> actually).  Note that it even attempts to bind to interface #3. Which
> fails of course, since there are no bulk endpoints.
>
> This is obviously a misconfiguration of the option driver.  It could in
> theory be patched, but I suspect some userspace script has been
> "helpful", adding the device ID dynamically.  Could you post the output
> of "cat /sys/bus/usb-serial/drivers/option1/new_id" as well?

It could also be usb_modeswitch's misguided attempts to force-bind
option when it finds no other suitable driver?  It's got functionality
to do that in some cases.

Dan