qmi_wwan fails with error -22

Muri Nicanor muri+libqmi at immerda.ch
Fri Oct 30 08:20:45 PDT 2015


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

>
> 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

> 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...

>> 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


> Thanks a lot for that!  It made it very easy to verify our error here,
> and also made it terribly clear that we have a little cleaup to do.
> It's reports like yours that move us forward. Thanks.
Thanks a lot for taking the time to look into this! I really appreciate it!

cheers,
muri


More information about the libqmi-devel mailing list