qmi_wwan fails with error -22

[Bjørn Mork]

Muri Nicanor <muri+libqmi at immerda.ch> writes:

> Hello,
>
> thanks for the quick reply,
>
> On 10/30/2015 02:48 PM, Bjørn Mork wrote:
>> But the kernel has switched your modem to cfg #2 by default, because of
>> a preference for proper classes.  And that configuration has a standard
>> CDC ECM function.  Which should really work with the cdc_ether driver.
>> I'm a little puzzled as to why that doesn't work.
>>
>> In any case, we'll probably prefer switching this modem to cfg #3 and
>> use it in MBIM mode.  But it would be interesting to make cfg #1 work as
>> well, so that we can use the QMI function.  Could you try these commands
>> as an initial test:
>>
>>  echo 1 >/sys/bus/usb/devices/2-6/bConfigurationValue
> yes, done, and syslog says:
> Oct 30 15:31:28 tekla ModemManager[905]: <info>  (tty/ttyUSB2): released
> by modem /sys/devices/pci0000:00/0000:00:14.0/usb2/2-6
> Oct 30 15:31:28 tekla kernel: [  167.275668] qcserial 2-6:2.0: device
> disconnected
> Oct 30 15:31:28 tekla kernel: [  167.275723] qcserial 2-6:2.1: device
> disconnected
> Oct 30 15:31:28 tekla kernel: [  167.275850] qcserial ttyUSB2: Qualcomm
> USB modem converter now disconnected from ttyUSB2
> Oct 30 15:31:28 tekla kernel: [  167.275872] qcserial 2-6:2.2: device
> disconnected
> Oct 30 15:31:28 tekla kernel: [  167.314669] qcserial 2-6:1.0: Qualcomm
> USB modem converter detected
> Oct 30 15:31:28 tekla kernel: [  167.314795] usb 2-6: Qualcomm USB modem
> converter now attached to ttyUSB0
> Oct 30 15:31:28 tekla kernel: [  167.315990] qcserial 2-6:1.1: Qualcomm
> USB modem converter detected
> Oct 30 15:31:28 tekla kernel: [  167.316106] usb 2-6: Qualcomm USB modem
> converter now attached to ttyUSB1
> Oct 30 15:31:28 tekla kernel: [  167.317553] qcserial 2-6:1.2: Qualcomm
> USB modem converter detected
> Oct 30 15:31:28 tekla kernel: [  167.317643] usb 2-6: Qualcomm USB modem
> converter now attached to ttyUSB2
> Oct 30 15:31:28 tekla kernel: [  167.319064] qmi_wwan: probe of 2-6:1.4
> failed with error -22
>
>>  echo "03f0 581d" >/sys/bus/usb/drivers/qmi_wwan/new_id
> Oct 30 15:34:35 tekla kernel: [  353.291614] qmi_wwan 2-6:1.3: cdc-wdm0:
> USB WDM device
> Oct 30 15:34:35 tekla kernel: [  353.291927] qmi_wwan 2-6:1.3 wwan0:
> register 'qmi_wwan' at usb-0000:00:14.0-6, WWAN/QMI device,
> 92:c2:d2:eb:ab:65
> Oct 30 15:34:35 tekla kernel: [  353.343183] qmi_wwan: probe of 2-6:1.4
> failed with error -22
> Oct 30 15:34:35 tekla NetworkManager[1027]: <info>  devices added (path:
> /sys/devices/pci0000:00/0000:00:14.0/usb2/2-6/2-6:1.3/net/wwan0, iface:
> wwan0)
> Oct 30 15:34:35 tekla NetworkManager[1027]: <info>  device added (path:
> /sys/devices/pci0000:00/0000:00:14.0/usb2/2-6/2-6:1.3/net/wwan0, iface:
> wwan0): no ifupdown configuration found.
>
>> The latter might seem redundant since we have an entry in the driver
>> already.  But the problem is that the driver entry refers to interface
>> #4, while your modem is set up with QMI at interface #3.
> well, only after the latter a /dev/cdcwdm0 device is created


This looks pretty much as expected. The qcserial driver is handling the
correct interfaces, mostly by chance but still. Did you test that the
/dev/cdc-wdm0 device worked as a QMI device?

>> As for making it work properly with ModemManager, my proposal is to
>> switch it to cfg #3:
>>
>>  echo 3 >/sys/bus/usb/devices/2-6/bConfigurationValue
>>
>> You may need to do this immediately after device discovery, or the
>> firmware could fail to do a proper mode switch.  An udev rule similar to
>> this one should work (untested, of course...):
>>
>> SUBSYSTEM=="usb", ATTR{idVendor}=="03f0", ATTR{idProduct}=="581d", \
>>   ATTR{bNumConfigurations}=="3", ATTR{bConfigurationValue}!="3" \
>>   ATTR{bConfigurationValue}="3"
> yes, this works:
> [Fri Oct 30 15:42:39 2015] usb 1-6: new high-speed USB device number 7
> using xhci_hcd
> [Fri Oct 30 15:42:39 2015] usb 1-6: New USB device found, idVendor=03f0,
> idProduct=581d
> [Fri Oct 30 15:42:39 2015] usb 1-6: New USB device strings: Mfr=2,
> Product=3, SerialNumber=4
> [Fri Oct 30 15:42:39 2015] usb 1-6: Product: HP lt4112 Gobi 4G Module
> [Fri Oct 30 15:42:39 2015] usb 1-6: Manufacturer: Hewlett-Packard
> [Fri Oct 30 15:42:39 2015] usb 1-6: SerialNumber: 0123456712ABCA17
> [Fri Oct 30 15:42:40 2015] usbcore: registered new interface driver
> usbserial
> [Fri Oct 30 15:42:40 2015] usbcore: registered new interface driver
> usbserial_generic
> [Fri Oct 30 15:42:40 2015] usbserial: USB Serial support registered for
> generic
> [Fri Oct 30 15:42:40 2015] usbcore: registered new interface driver qcserial
> [Fri Oct 30 15:42:40 2015] usbserial: USB Serial support registered for
> Qualcomm USB modem
> [Fri Oct 30 15:42:40 2015] usbcore: registered new interface driver
> cdc_ether
> [Fri Oct 30 15:42:40 2015] usbcore: registered new interface driver cdc_ncm
> [Fri Oct 30 15:42:40 2015] usbcore: registered new interface driver cdc_wdm
> [Fri Oct 30 15:42:40 2015] usbcore: registered new interface driver qmi_wwan
> [Fri Oct 30 15:42:40 2015] qcserial 1-6:3.0: Qualcomm USB modem
> converter detected
> [Fri Oct 30 15:42:40 2015] qcserial 1-6:3.1: Qualcomm USB modem
> converter detected
> [Fri Oct 30 15:42:41 2015] qcserial 1-6:3.2: Qualcomm USB modem
> converter detected
> [Fri Oct 30 15:42:41 2015] usb 1-6: Qualcomm USB modem converter now
> attached to ttyUSB2
> [Fri Oct 30 15:42:41 2015] usbcore: registered new interface driver cdc_mbim

Ouch.  Didn't think of the qcserial conflict here.  It should definitely
not mess with interfaces #0 and #1, which are CDC class interfaces.

You will ether have to blacklist qcserial, or manually unbinding it from
these interfaces and then bind cdc_mbim to them instead.  This should
work: 

 echo 1-6:3.0 >/sys/bus/usb/devices/1-6:3.0/driver/unbind
 echo 1-6:3.1 >/sys/bus/usb/devices/1-6:3.1/driver/unbind
 echo 1-6:3.0 >/sys/bus/usb/drivers/cdc_mbim/bind


But that's of course not the kind of mess you'll want to have to sort
out manually just to use a modem.  We'll definitely have to remove this
device from qcserial..




>> We do handle this scheme correctly for devices with a Huawei vendor ID,
>> but this modem has a HP vendor ID.  Unfortunately, we cannot just switch
>> to the Huawei scheme for all HP devices either, since they use the same
>> vendor ID for modems from many different manufacturers.
>>
>> We'll probably just have to add "Huawei type" entries for each known
>> Huawei modem with a HP vendor ID.
>>
>> Hmm, we have the same problems for the entry in qcserial.  I'm afraid
>> the QCSERIAL_HWI scheme is broken.  Huawei does not use fixed interface
>> numbers. We,ll have to redo this.  Sorry for not catching it earlier.
>>
>>> i can use the modem only, if i do
>>>> echo "03f0 581d" >/sys/bus/usb-serial/drivers/generic/new_id
>>> and restart ModemManager, but its doesn't work very good (i.e. i can
>>> browse the web, but not connect to any vpn).
>>
>> No, that's not going to work very well.  That driver is made for testing
>> slow serial links and not suitable for high speed modems.
>
> although it works now with the udev rule you gave above, my vpn
> connections still don't work (i can connect, but no traffic is going
> over the vpn), but maybe thats an unrelated problem with my setup...

I'm not sure it worked?  Didn't look like that to me.  qcserial "steals"
the MBIM interfaces before cdc_mbim has a chance.

>>> maybe i'm missing one simple step (i also tried to use usb_modeswitch on
>>> the card, but no success), any help appreciated...
>>
>> Hmm, I believe usb_modeswitch should prefer MBIM when supported.  Do you
>> have the cdc_mbim driver available?  What's the output when you run
>> usb_modeswitch?
> well, i don't really have a clue about using usb_modeswich, there is no
> rule for that card, so i tried all the special procedure switches...
> resetting the device worked ;)
>
>> usb_modeswitch -v 03f0 -p 581d -R
> Look for default devices ...
>    product ID matched
>  Found devices in default mode (1)
> Access device 007 on bus 001
> Current configuration number is 3
> Use interface number 0
>
> USB description data (for identification)
> -------------------------
> Manufacturer: Hewlett-Packard
>      Product: HP lt4112 Gobi 4G Module
>   Serial No.: 0123456712ABCA17
> -------------------------
> Warning: no switching method given. See documentation
> Reset USB device .
>  Device was reset

I'm not exactly sure.  It's been a while since I looked at this.  But I
seem to rememeber that Josh added a feature which would switch modems
to a configuration with an MBIM function if
 a) there is one, and
 b) the cdc_mbim driver exists

But you may have to configure it.  I don't know.

I wonder if you and/or Martin is able to test the attached qmi-wwan
patch?  Ideally both should verify that it works, as your lt4112 modems
obviosly are configured slightly different.

You may have to blacklist qcserial while testing this, as it could
otherwise conflict with qmi_wwan.  I'll try to figure out how we should
fix that as well, but I don't know it it is doable without either moving
to the option driver or making major changes to qcserial.

I would also be very interested in seeing the lsusb -v output for
Martin's modem, as that is nice documentation to have the next time we
screw up something :)



Bjørn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-qmi_wwan-fix-entry-for-HP-lt4112-LTE-HSPA-Gobi-4G-Mo.patch
Type: text/x-diff
Size: 2127 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20151030/db969d77/attachment.patch>