QMI-powered broadband connections in OpenWRT

Linux 3.2 kernel with QMI support

When I started to develop the QMI support in OpenWRT, latest trunk was based on the 3.2 kernel series. By the time you read this, OpenWRT may already have a recent enough kernel (>= 3.4), so this custom setup may not be needed any more, so keep it just for reference.

The ‘v3.2.5-qmi’ branch in the Lanedo stable kernel tree contains a set of patches on top of the 3.2.5. Linux kernel release. These patches add support for QMI ports (updated ‘cdc-wdm’ and new ‘qmi_wwan’ driver) in the 3.2 stable series:
git://gitorious.org/lanedo/linux-stable.git

 

OpenWRT with QMI support

The same set of patches was then added to the ‘qmi-support’ branch of the Lanedo openwrt tree, enabling OpenWRT builds with QMI support:
git://gitorious.org/lanedo/openwrt.git

When you compile this OpenWRT build, make sure you configure the kernel with the QMI-specific requirements enabled:

CONFIG_PACKAGE_kmod-qmi-wwan=m
CONFIG_PACKAGE_kmod-usb-wdm=m
...

For reference, you can find here the .config I used for the ar71xx-nand builds (installable in a RouterBoard 433UAH).

 

libqmi-glib and qmi4g

‘libqmi-glib’ and ‘qmi4g’ are two new packages added to the ‘qmi-support’ branch of the Lanedo openwrt-packages tree:
git://gitorious.org/lanedo/openwrt-packages.git

This repository can be added to your OpenWRT build by creating a new ‘feeds.conf‘ with the following contents:
src-git packages git://gitorious.org/lanedo/openwrt-packages.git;qmi-support

The new packages, in detail:

  • libqmi-glib: This package provides a preliminary version of libqmi-glib, as released unofficially by me. This package will provide the libqmi-glib library, the qmicli command line utility and the qmi-network script.
  • qmi4g: This package registers a new ‘qmi4g‘ network protocol, which takes care of launching the network start/stop requests through QMI.

If you’re using the precompiled OpenWRT images I gave above, you can just install these packages using ‘opkg’ once you’ve added the ‘latest’ Lanedo repository.

 

Configuring qmi4g

Once the qmi4g package is installed, you are then allowed to include the
following configuration under /etc/config/network:

config 'interface' 'broadband'
option 'ifname' 'wwan0'
option 'proto' 'dhcp'
option 'auto' '0'

config 'interface' 'wdm0'
option 'proto' 'qmi4g'
option 'wdmif' '/dev/cdc-wdm0'
option 'wwanif' 'broadband'

The configuration is split into 2 interfaces:

  1. First, the configuration for the ‘wwan0‘ interface. This interface needs to be set with ‘auto‘ equal to ‘0‘, so that it is never brought up automatically; and with ‘dhcp‘ as the protocol to be used. You should never ifup/ifdown this interface manually.
  2. Second, a virtual interface using the new ‘qmi4g‘ protocol, which needs 2 options set: ‘wdmif‘ with the cdc-wdm port to use for the QMI protocol, and ‘wwanif‘ with the uci-interface-name of the wwan iface to use.

 

Start/Stop the network

Once the qmi4g setup is added in /etc/config/network, you can now then just:
$> ifup wdm0

That command will internally first launch the network start QMI command, and if succeeds it will itself ifup wwan0. The wwan interface can be used as any other eth-based interface now, it can be added as part of multiwan or in a vlan or in a bonding, or anything.

Once the connection is no longer wanted, you can just:
$> ifdown wdm0

That command will stop the network with QMI and also ifdown wwan0.

 

LUCI

Once the network configuration is in place, the connection can also be started via web. Just log in to LUCI, go to Network interfaces and you’ll see both the wwan interface (“broadband“) and the virtual “wdm0“. Starting/Stopping the “wdm0” interface via LUCI should work. As said before, you shouldn’t touch the wwan interface directly.

Enjoy!

About these ads

Posted on August 20, 2012, in Development, FreeDesktop Planet, GNU Planet, Lanedo Planet, Planets and tagged , , , . Bookmark the permalink. 44 Comments.

  1. Hello!

    I’ve built an image for my TP-Link TL-MR3220 from the sources qmi-support branch because I want to use a Huawei E398 (Telekom Germany Speedstick LTE) in QMI mode.

    If I plug my 3G-dongle into the USB-port of the router, the donge get’s registered as QMI speakding wwan device (accoring to the log entries), and something about a cdc_wdm QMI interface appears in the log messages.

    See here:
    http://pastebin.com/raw.php?i=eJ8K6iyF

    Unfortunately no /dev/cdc-wdm0 device get’s created in my system:

    Look here:
    http://pastebin.com/raw.php?i=QGsHqDNy

    Of course no connection can be set up without a cdc-wdmX interface.

    Can you give me any hints what’s going wrong on my router?

    Here is a list of all modules active in my system when the dongle is plugged in:
    http://pastebin.com/BN3RjFf8

    And here the output of ifconfig -a (the device wwan0 successfully get’s created)
    http://pastebin.com/4QCZUZSp

  2. That is really strange, the E398 is explicitly supported in this commit, which should be included in your build.

    You should really see logs like these:
    [ 2237.602722] usb 1-1.1: USB disconnect, device number 7
    [ 2241.356694] usb 1-1.1: new high-speed USB device number 8 using ehci_hcd
    [ 2241.445647] usb 1-1.1: New USB device found, idVendor=12d1, idProduct=1506
    [ 2241.445653] usb 1-1.1: New USB device strings: Mfr=4, Product=3, SerialNumber=0
    [ 2241.445656] usb 1-1.1: Product: HUAWEI Mobile
    [ 2241.445659] usb 1-1.1: Manufacturer: Huawei Technologies
    [ 2241.550207] cdc_wdm 1-1.1:1.1: Ignoring extra header, type 15, length 13
    [ 2241.550216] cdc_wdm 1-1.1:1.1: Ignoring extra header, type 6, length 5
    [ 2241.550304] cdc_wdm 1-1.1:1.1: cdc-wdm1: USB WDM device
    [ 2241.551004] qmi_wwan 1-1.1:1.2: Use “cdc_wdm” for QMI interface 1-1.1:1.1
    [ 2241.552580] qmi_wwan 1-1.1:1.2: wwan1: register ‘qmi_wwan’ at usb-0000:00:1a.0-1.1, QMI speaking wwan device, 02:50:f3:00:00:00

    Which config did you use for the build?

  3. Hello!

    I used this config:
    http://pastebin.com/GWMEXRSh

    Could there be any problem with my selection of components to compile i made?

  4. Not sure, truth be told… check the config I used here.

    I just assumed that qmi-wwan and cdc-wdm are mandatory in the compilation, but I also enabled several others like serial port drivers and such. Why don’t you try with my config setup and see if you get the cdc-wdm port there? If you don’t, then we know there’s some other thing missing that we didn’t think of.

  5. I’m already trying in this moment, compilation is running …

  6. With a build made from your config I still get no cdc-wdm device.

    Can you provide me the output of your “opkg list-installed” command? Perhaps you have installed some packeges I am still missing.

  7. Another strange thing:

    With all builds (my own and that with your config) I have to load the module qmi_wwan.ko manually (via insmod in the file /etc/rc.config), otherwise nothing of the qmi/wwan stuff gets initialized – even not the wwan0 network device

  8. :-/ I no longer have that setup around… Maybe try to backport new QMI related patches from the kernel? I stopped backporting them to the branch after a while.

  9. Hello Aleksander. I’m using current trunk (r34304) with Kernel 3.6.4 (edited the Makefile) and trying to build a x86_generic image for virtualbox. I don’t see qmi options qmi-wwan or usb-wdm while configuring kernel modules.

    Was qmi support incorporated into 3.4+ or do I need to patch the source? If so, is it possible to patch current 3.3 kernel? How?

    Thanks in advance.

  10. Every kernel newer than 3.4 should already come with built-in qmi-wwan support. What you probably need is to add new config sections to the OpenWRT specific configuration, like:
    https://gitorious.org/lanedo/openwrt/commit/027ef5c56afc5181c565fd1cc262ec4cdae14950
    and
    https://gitorious.org/lanedo/openwrt/commit/328cae723390e6d2e983561c70e4ebc08570c078.

    If you want to patch a 3.3 kernel you can include the same patches as I included for the 3.2.5 kernel; that should work. I guess you can look at my OpenWRT repo to see how I did this:
    https://gitorious.org/lanedo/openwrt/commits/qmi-support

  11. Thanks for the (fast) reply. I see QMI/WDM options while searching in “kernel_menuconfig” but not in “menuconfig”. Maybe because of the “specific configuration” you referred above.

    I’m currently downloading your sources. Hope I can get this working by the end of the day.

  12. Weird, I don’t see QMI options also when working with your sources. Do I need to run a script to patch ‘package/kernel/modules/*.mk’ files?

  13. As you can guess, I don’t know what steps you did, so don’t know where you’re at :-)

  14. You’re right. My fault, forgot to fetch and checkout to qmi-support branch. Compiling now…

  15. 1) The builds fails with this message: “ERROR: module ‘/projects/openwrt-qmi/build_dir/linux-x86_generic/linux-2.6.39.4/drivers/net/usb/qmi_wwan.ko’ is missing.” Any idea on how to fix this?

    2) ar71xx uses LINUX_VERSION=3.2.5 but x86 gets LINUX_VERSION=2.6.39.4. I’m building for x86, is it ok to edit x86/Makefile to use 3.2.5 as well?

    3) I’ve added option qmi-wwan to netdevices.mk and usb-wdm to usb.mk. Is this enough? Strangely USB Support entry is locked for x86/(generic,Intel EP80579) but available for others. Suggestion?

    4) What 4G-dongles have you used and with what results?

  16. Hey; some replies below.

    1) The patches backporting qmi support are explicitly added to the 3.2 kernel series; I didn’t backport them to 2.6.x.

    2) No idea, you can try :-) Actually; why don’t you try upstream OpenWRT git master, they should already have a kernel >= 3.4 supported, with built-in qmi support, no additional patches would be needed.

    3) No idea :-) I just focused on ar71xx-nand builds…

    4) I tested this with a Pantech UML290 (all good except for IPv6), but should work out of the box with most QMI-based modems. A lot of people have tried libqmi/qmicli already with lots of different modems.

  17. Hi again Aleksander.

    I fixed 1) by editing x86/Makefile and replacing the 2.6 kernel with 3.2.5 like I said in 2). Compilation went fine and system is bootable.

    I’m currently in a trial-and-error sprint, booting the Virtualbox image and adjusting the .config. Still no cdc device. Dongle is Huawei E392.

    What I got is this (logread):

    user.notice usb-modeswitch: 1-1:1.1: Manufacturer=? Product=? Serial=?
    user.notice usb-modeswitch: 2-0:1.0: Manufacturer=Linux_3.2.5_ohci_hcd Product=OHCI_Host_Controller Serial=0000:00:06.0
    kern.info kernel: [ 41.090181] usb 1-1: new high-speed USB device number 3 using ehci_hcd
    kern.info kernel: [ 41.271728] option 1-1:1.0: GSM modem (1-port) converter detected
    kern.info kernel: [ 41.274163] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
    kern.info kernel: [ 41.275603] option 1-1:1.1: GSM modem (1-port) converter detected
    kern.info kernel: [ 41.278461] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
    kern.info kernel: [ 41.279979] option 1-1:1.2: GSM modem (1-port) converter detected
    kern.info kernel: [ 41.281305] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
    daemon.info init: starting pid 624, tty '/dev/tty1': '/bin/ash --login'
    user.notice ifup: Enabling Router Solicitations on loopback (lo)
    user.notice usb-modeswitch: 2-1:1.0: Manufacturer=VirtualBox Product=USB_Tablet Serial=?
    user.notice usb-modeswitch: 1-0:1.0: Manufacturer=Linux_3.2.5_ehci_hcd Product=EHCI_Host_Controller Serial=0000:00:0b.0
    user.notice usb-modeswitch: 1-1:1.0: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 1-1:1.1: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 2-0:1.0: Manufacturer=Linux_3.2.5_ohci_hcd Product=OHCI_Host_Controller Serial=0000:00:06.0
    user.notice usb-modeswitch: 2-1:1.0: Manufacturer=VirtualBox Product=USB_Tablet Serial=?
    user.notice usb-modeswitch: 1-1:1.0: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?

    I’ve used selected options in menuconfig as built-in (y) instead of module (m). Does it make any difference?

  18. Aleksander, do you think this is caused by usb-modeswitch registering /dev/tty* devices for 3G and that is stopping the cdc-wdm0 device from appearing?

    Btw, libqmi is working fine on a regular Linux distro (3.4.5 kernel) with the same dongle.

  19. OK. as John said the qmi_wwan module is not loaded automatically. After I added it (insmod) I got some feedback in dmesg about “QMI speaking wwan device”. Then I physically disconnected the dongle and plugged it back in again.

    This is the result:

    kern.info kernel: [ 454.362058] usb 1-1: USB disconnect, device number 3
    kern.info kernel: [ 480.559020] usb 1-1: new high-speed USB device number 4 using ehci_hcd
    kern.info kernel: [ 480.776790] option 1-1:1.0: GSM modem (1-port) converter detected
    kern.info kernel: [ 480.777394] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
    kern.info kernel: [ 480.777896] option 1-1:1.1: GSM modem (1-port) converter detected
    kern.info kernel: [ 480.778279] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
    kern.info kernel: [ 480.779304] option 1-1:1.2: GSM modem (1-port) converter detected
    kern.info kernel: [ 480.780606] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
    kern.info kernel: [ 480.785707] qmi_wwan 1-1:1.4: Use "cdc_wdm" for QMI interface 1-1:1.3
    kern.info kernel: [ 480.793870] qmi_wwan 1-1:1.4: wwan0: register 'qmi_wwan' at usb-0000:00:0b.0-1, QMI speaking wwan device, 00:a0:c6:00:00:00
    syslog.notice usb_modeswitch: switched to 12d1:1506 on 001/003
    user.notice usb-modeswitch: 1-1:1.1: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 1-1:1.0: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 1-1:1.1: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 1-1:1.2: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 1-1:1.3: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 1-1:1.4: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 1-1:1.5: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?
    user.notice usb-modeswitch: 1-1:1.6: Manufacturer=Huawei_Technologies Product=HUAWEI_Mobile Serial=?

    No /dev/cdc-wdm0 device comes up. Can you help? I don’t know what to do more.

  20. Good you’re closer now. Is cdc-wdm loaded? It probably should, as qmi-wwan depends on it, but just in case.

    You’re still using the branch I prepared with backported patches as far as I can see. That worked well for my Pantech UML290, but maybe there is still some missing patch in either qmi_wwan or cdc-wdm for your modem? Now that you’re already getting some results, I would suggest to try with upstream OpenWRT and Kernel version >= 3.4.0.

  21. cdc-wdm is loaded at boot, then I manually load qmi_wwan and plug-in the dongle and get this in dmesg:

    [ 116.516054] usbcore: registered new interface driver qmi_wwan
    [ 303.256015] usb 1-1: new high-speed USB device number 2 using ehci_hcd
    [ 303.487344] qmi_wwan 1-1:1.4: Use "cdc_wdm" for QMI interface 1-1:1.3
    [ 303.491986] qmi_wwan 1-1:1.4: wwan0: register 'qmi_wwan' at usb-0000:00:0b.0-1, QMI speaking wwan device, 00:a0:c6:00:00:00

    ifconfig -a shows a wwan interface.

    But again the /dev/cdc-wdm0 device is missing. Do I need udev for this? Can I create it manually? How can I debug this?

  22. About your suggestion, I would like to try with upstream OpenWRT and Kernel version >= 3.4.0 but x86 is still using 3.3.8.

  23. It is very weird; both you (noisebleed) and John before are suffering the same issue: you end up with no cdc-wdm interface in neither a Huawei E398 nor a Huawei E392. My guess here is that there are patches missing to be backported to have these properly working, but don’t know which ones.

    From what I can see, this patch should provide support for those modems in cdc-wdm:
    https://gitorious.org/lanedo/openwrt/blobs/qmi-support/target/linux/generic/patches-3.2/056-usb_cdc_wdm_add_device_id_for_huawei_3g_lte_modems.patch

    And this patch should provide support for those modems in qmi_wwan:
    https://gitorious.org/lanedo/openwrt/blobs/qmi-support/target/linux/generic/patches-3.2/063-net_usb_qmi_wwan_new_driver_for_huawei_qmi_based_wwa.patch

    If any additional patch is missing, cannot tell…

  24. Hi,
    I’ve tried to use your module with OpenWrt Attitude Adjustment 12.09-rc1 – package was provided by http://eko.one.pl for kernel: 3.3.8. Detail log is attached here: http://eko.one.pl/forum/viewtopic.php?pid=57193#p57193

    Do you have any idea why segmentation fault is returned?

  25. Could you help me, please?
    I tried qmi4g with OpenWrt Attitude Adjustment 12.09-rc1 (r34302) by obsy, but some things went bad.
    1. cdc_wdm returned errors “Ignoring extra header …”
    [ 0.000000] Linux version 3.3.8 (cezary@eko.one.pl) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #31 Fri Nov 23 23:04:15 CET 2012
    [ 0.000000] MyLoader: sysp=4b1bf7b5, boardp=9002c600, parts=6bde8914
    [ 0.000000] bootconsole [early0] enabled
    [ 0.000000] CPU revision is: 0001974c (MIPS 74Kc)
    [ 0.000000] SoC: Atheros AR9344 rev 2
    [ 0.000000] Clocks: CPU:560.000MHz, DDR:450.000MHz, AHB:225.000MHz,
    Ref:40.000MHz

    [ 41.120000] usb 1-1.1: new high-speed USB device number 4 using ehci-platform
    [ 41.230000] option 1-1.1:1.0: GSM modem (1-port) converter detected
    [ 41.240000] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB0
    [ 41.250000] option 1-1.1:1.1: GSM modem (1-port) converter detected
    [ 41.250000] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB1
    [ 41.260000] option 1-1.1:1.2: GSM modem (1-port) converter detected
    [ 41.270000] usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB2
    [ 41.270000] cdc_wdm 1-1.1:1.3: Ignoring extra header, type 15, length 13
    [ 41.280000] cdc_wdm 1-1.1:1.3: Ignoring extra header, type 6, length 5
    [ 41.290000] cdc_wdm 1-1.1:1.3: cdc-wdm0: USB WDM device
    [ 41.310000] qmi_wwan 1-1.1:1.4: Use “cdc_wdm” for QMI interface 1-1.1:1.3
    [ 41.330000] qmi_wwan 1-1.1:1.4: wwan0: register ‘qmi_wwan’ at usb-ehci-platform-1.1, QMI speaking wwan device, 00:a0:c6:00:00:00
    [ 41.350000] scsi1 : usb-storage 1-1.1:1.5
    [ 41.350000] scsi2 : usb-storage 1-1.1:1.6
    [ 42.350000] scsi 1:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 0
    [ 42.360000] scsi 2:0:0:0: Direct-Access HUAWEI SD Storage 2.31 PQ: 0 ANSI: 2
    [ 42.380000] sd 2:0:0:0: [sda] Attached SCSI removable disk

    2. qmicli returned an error “Segmentation fault”
    $qmi-network /dev/cdc-wdm0 start
    Starting network with ‘qmicli -d /dev/cdc-wdm0 –wds-start-network –client-no-release-cid’…
    Segmentation fault
    Saving state… (CID: 11)
    Saving state… (PDH: 34039896)
    Network started successfully

    $qmicli -v -d /dev/cdc-wdm0 –wds-start-network –client-no-release-cid
    [26 Nov 2012, 22:52:43] [Debug] QMI Device at ‘/dev/cdc-wdm0′ ready
    [26 Nov 2012, 22:52:43] [Debug] Assuming service ‘wds’ is supported…
    [26 Nov 2012, 22:52:43] [Debug] Allocating new client ID…
    [26 Nov 2012, 22:52:43] [Debug] [/dev/cdc-wdm0] Sending message…
    <<<<<< QMUX:
    <<<<<< length = 15 (0x000f)
    <<<<<< flags = 0×00
    <<<<<< service = "ctl" (0×00)
    <<<<<< client = 0 (0×00)
    <<<<<< QMI:
    <<<<<< flags = "none" (0×00)
    <<<<<< transaction = 1 (0×0001)
    <<<<<< message = "allocate-client-id" (0×0022)
    <<<<<< tlv_length = 4 (0×0004)
    <<<<<< TLV:
    <<<<<< type = 0×01
    <<<<<< length = 1 (0×0001)
    <<<<<>>>>> QMUX:
    >>>>>> length = 23 (0×0017)
    >>>>>> flags = 0×80
    >>>>>> service = “ctl” (0×00)
    >>>>>> client = 0 (0×00)
    >>>>>> QMI:
    >>>>>> flags = “response” (0×01)
    >>>>>> transaction = 1 (0×0001)
    >>>>>> message = “allocate-client-id” (0×0022)
    >>>>>> tlv_length = 12 (0x000c)
    >>>>>> TLV:
    >>>>>> type = 0×02
    >>>>>> length = 4 (0×0004)
    >>>>>> value = 00:00:00:00
    >>>>>> TLV:
    >>>>>> type = 0×01
    >>>>>> length = 2 (0×0002)
    >>>>>> value = 01:11

    [26 Nov 2012, 22:52:43] [Debug] KEY: 00:00:00:01
    [26 Nov 2012, 22:52:43] [Debug] Service: 00
    [26 Nov 2012, 22:52:43] [Debug] Client ID: 00
    [26 Nov 2012, 22:52:43] [Debug] Transaction ID: 00:01
    [26 Nov 2012, 22:52:43] [Debug] Allocated client ID ’17′ for service ‘wds’
    [26 Nov 2012, 22:52:43] [Debug] Registered ‘wds’ client with ID ’17′
    [26 Nov 2012, 22:52:43] [Debug] Asynchronously starting network…
    [26 Nov 2012, 22:52:43] [Debug] [/dev/cdc-wdm0] Sending message…
    <<<<<< QMUX:
    <<<<<< length = 12 (0x000c)
    <<<<<< flags = 0×00
    <<<<<< service = "wds" (0×01)
    <<<<<< client = 17 (0×11)
    <<<<<< QMI:
    <<<<<< flags = "none" (0×00)
    <<<<<< transaction = 1 (0×0001)
    <<<<<< message = "start-network" (0×0020)
    <<<<<>>>>> QMUX:
    >>>>>> length = 26 (0x001a)
    >>>>>> flags = 0×80
    >>>>>> service = “wds” (0×01)
    >>>>>> client = 17 (0×11)
    >>>>>> QMI:
    >>>>>> flags = “response” (0×02)
    >>>>>> transaction = 1 (0×0001)
    >>>>>> message = “start-network” (0×0020)
    >>>>>> tlv_length = 14 (0x000e)
    >>>>>> TLV:
    >>>>>> type = 0×02
    >>>>>> length = 4 (0×0004)
    >>>>>> value = 00:00:00:00
    >>>>>> TLV:
    >>>>>> type = 0×01
    >>>>>> length = 4 (0×0004)
    >>>>>> value = 58:68:07:02

    [26 Nov 2012, 22:52:43] [Debug] KEY: 01:11:00:01
    [26 Nov 2012, 22:52:43] [Debug] Service: 01
    [26 Nov 2012, 22:52:43] [Debug] Client ID: 11
    [26 Nov 2012, 22:52:43] [Debug] Transaction ID: 00:01
    [26 Nov 2012, 22:52:43] [Debug] [/dev/cdc-wdm0] Received message…
    >>>>>> QMUX:
    >>>>>> length = 21 (0×0015)
    >>>>>> flags = 0×80
    >>>>>> service = “wds” (0×01)
    >>>>>> client = 255 (0xff)
    >>>>>> QMI:
    >>>>>> flags = “indication” (0×04)
    >>>>>> transaction = 0 (0×0000)
    >>>>>> message = “get-packet-service-status” (0×0022)
    >>>>>> tlv_length = 9 (0×0009)
    >>>>>> TLV:
    >>>>>> type = 0×01
    >>>>>> length = 2 (0×0002)
    >>>>>> value = 02:00
    >>>>>> TLV:
    >>>>>> type = 0×12
    >>>>>> length = 1 (0×0001)
    >>>>>> value = 04

    [/dev/cdc-wdm0] Network started
    Packet data handle: 34039896
    [/dev/cdc-wdm0] Client ID not released:
    Service: ‘wds’
    CID: ’17′
    [26 Nov 2012, 22:52:43] [Debug] Unregistered ‘wds’ client with ID ’17′
    [26 Nov 2012, 22:52:43] [Debug] Client released
    Segmentation fault

  26. For whoever is re-packaging the’qmi4g’ and ‘libqmi’ packages in openwrt, please use the released libqmi 1.0:
    http://lists.freedesktop.org/archives/libqmi-devel/2012-November/000335.html

    I have no idea which version is the one being used in those issues. If it’s the version I originally included in my builds, you *really* want to get 1.0 instead, several bugs were fixed already.

    That said, no idea why the segfaults without more information. If you can reproduce the same issue with libqmi 1.0, please file a bug in the bug tracker:
    https://bugs.freedesktop.org/enter_bug.cgi?product=libqmi

  27. And for anyone else with problems with their modems, Bjørn Mork just suggested me to avoid if possible 3.4 and 3.5 kernels, and instead switch to >= 3.6, where cdc_wdm is used as a subdriver regardless of USB interface layout.

    And regarding the issues with the Huawei modems, he says:

    Without having looked at that in detail yet, I am guessing that is
    because their device doesn’t match the device IDs in cdc_wdm ofr some
    reason. It is probably not more difficult than getting a “lsusb -v”
    dump and add whatever needed to make cdc_wdm handle the QMI/wwan control
    interface.

    Another quick fix is changing the usb_modeswitch configuration to switch
    the modem to “Windows” mode, where the control and data functions are
    combined in the same USB interface. I assume they use the default
    “55534243123456780000000000000011062000000100000000000000000000″

    If that is correct, then it is worth trying
    “55534243000000000000000000000011060000000100000000000000000000″
    instead.

    Hope that helps.

  28. Aleksander, thanks for reaching Bjørn Mork about this issue.

    > “It is probably not more difficult than getting a lsusb -v dump and add whatever needed to make cdc_wdm handle the QMI/wwan control interface.”

    Aleksander, if you need any info about the Huawei E392 (like a lsusb -v) just ask and I’ll gladly post it. I’m also reachable via the #openwrt IRC channel (same nick).

  29. As for libqmi 1.0 there is no segfaults. But I still doesn’t work (no IP provided) :(

    $ qmi-network /dev/cdc-wdm0 start
    Starting network with ‘qmicli -d /dev/cdc-wdm0 –wds-start-network= –client-no-release-cid’…
    Saving state… (CID: 45)
    Saving state… (PDH: 34039896)
    Network started successfully

    $ qmi-network /dev/cdc-wdm0 status
    Loading previous state…
    Previous CID: 45
    Previous PDH: 34039896
    Getting status with ‘qmicli -d /dev/cdc-wdm0 –wds-get-packet-service-status –client-cid=45 –client-no-release-cid’…
    Status: connected

    $ifup wdm0

    $ ifconfig wwan0
    wwan0 Link encap:Ethernet HWaddr 00:A0:C6:00:00:00
    BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

  30. Once it says ‘connected’ you need to:
    ifup wwan0
    dhclient wwan0

    Hopefully your modem will like DHCP to get the IP.

  31. aleksander :
    Once it says ‘connected’ you need to:
    ifup wwan0
    dhclient wwan0
    Hopefully your modem will like DHCP to get the IP.

    only ifup wdm0 works for me.

    then
    neither udhcpc wwan0 nor udhcpc wdm0 works :(

    mt

  32. $ udhcpc wwan0
    udhcpc (v1.19.4) started
    Sending discover…
    Sending discover…
    Sending discover…


    .

  33. There are more ‘strange’ things:
    1. Cezary from eko.one.pl suggested to check what AT^DHCP command returns. It seems that there is full IP configuration. But if then I try to manualy (ifconfig) set ip and mask to wwan0, my router hangs and restarts (no logs)
    2. After qmi-network start command lsmod says that module qmi_wwan is not used. I can even remove it with no problem: AT^DHCP returns ip, mask etc anyway.

  34. AT^DHCP is the Huawei-specific thingy to check whether the modem is connected or not. You shouldn’t need that when using QMI.

    ifup wdm0 is useless, that’s the control port you’re already talking to. Each control QMI port has a corresponding wwan port: once you’re connected you need to ifup that wwan port and dhclient (or equivalent) on it.

    Make sure you’re using the correct APN. If you need user/pass for the APN, you’ll need to extend qmi-network, with those.

    And qmi_wwan should really be used… Try to modprobe qmi_wwan before plugging in the modem and see if that helps. Note that sending AT commands without qmi_wwan is perfectly valid, they are independent control ports with different protocols.

  35. aleksander :
    AT^DHCP is the Huawei-specific thingy to check whether the modem is connected or not. You shouldn’t need that when using QMI.
    ifup wdm0 is useless, that’s the control port you’re already talking to. Each control QMI port has a corresponding wwan port: once you’re connected you need to ifup that wwan port and dhclient (or equivalent) on it.
    Make sure you’re using the correct APN. If you need user/pass for the APN, you’ll need to extend qmi-network, with those.
    And qmi_wwan should really be used… Try to modprobe qmi_wwan before plugging in the modem and see if that helps. Note that sending AT commands without qmi_wwan is perfectly valid, they are independent control ports with different protocols.

    as for APN, I created /etc/qmi-network.conf with APN=____ and qmi-network scripts uses it. There is no user/password for my APN.

    I’m using standard udhcpc and insmod commands from openwrt.

    Even if qmi-network status reports that modem is connected, module qmi_wwan is not used.

    Is it possible to add some additional logging to qmi_wwan or cdc_wdm modules?

  36. It is impossible that qmi_wwan is not used and qmi-network works. If you don’t see qmi_wwan listed as a module loaded by the kernel, maybe it’s because it wasn’t compiled as a module; I don’t know how you compiled it. Of course you can add logs to qmi_wwan or cdc-wdm, but I tell you that it’s probably useless to do so :-)

    And regarding ifup wwan0, just forget what I said about that. You really need to “ifup wdm0″ as you said, as that is the new interface defined by the “qmi4g” protocol handler I wrote.

    So, don’t know why you don’t have connectivity, you should :-)

  37. Maybe I wasn’t clear enough. It’s possible to run qmi-network start successfully without qmi_wwan, problem occurs when I try to run ifup :(
    According to discussion at http://eko.one.pl/forum/viewtopic.php?pid=57394#p57394 there are some that managed to run e398 at AA openwrt using qmi.

  38. I don’t really know which steps you took, so don’t know where you are at :-)

    qmi_wwan is definitely needed to have all the setup running. If you don’t have it loaded, modprobe it to get it loaded.

    Then, remember that the ifup is to be done in the virtual interface you configured for openwrt. It was named ‘wdm0′ in my example here, but I think it’s named differently in that forum thread.

  39. Hi!

    I just patched libqmi to allow me to give username and password for the connection. This is essential for some services..
    Here is my “Test Patch”
    —————————————————————————————————————
    index 775824b..134beb9 100644
    — a/cli/qmicli-wds.c
    +++ b/cli/qmicli-wds.c
    @@ -58,7 +58,7 @@ static gboolean noop_flag;
    static GOptionEntry entries[] = {
    { “wds-start-network”, 0, 0, G_OPTION_ARG_STRING, &start_network_str,
    “Start network”,
    - “[APN]”
    + “[APN|Username|Password]”
    },
    { “wds-follow-network”, 0, 0, G_OPTION_ARG_NONE, &follow_network_flag,
    “Follow the network status until disconnected. Use with `–wds-start-network’”,
    @@ -582,6 +582,8 @@ qmicli_wds_run (QmiDevice *device,
    QmiClientWds *client,
    GCancellable *cancellable)
    {
    + gchar **split;
    + QmiWdsAuthentication qmiwdsauth;
    /* Initialize context */
    ctx = g_slice_new (Context);
    ctx->device = g_object_ref (device);
    @@ -596,8 +598,18 @@ qmicli_wds_run (QmiDevice *device,

    /* Use the input string as APN */
    if (start_network_str[0]) {
    + split = g_strsplit (start_network_str, “|”, 3);
    input = qmi_message_wds_start_network_input_new ();
    - qmi_message_wds_start_network_input_set_apn (input, start_network_str, NULL);
    + if (split[1][0]) {
    + qmi_message_wds_start_network_input_set_username (input, split[1], NULL);
    + qmiwdsauth = QMI_WDS_AUTHENTICATION_PAP;
    + qmi_message_wds_start_network_input_set_authentication_preference (input, qmiwdsauth, NULL);
    + }
    + if (split[2][0]) {
    + qmi_message_wds_start_network_input_set_password (input, split[2], NULL);
    + }
    + qmi_message_wds_start_network_input_set_apn (input, split[0], NULL);
    + g_strfreev (split);
    }

    g_debug (“Asynchronously starting network…”);
    —————————————————————————————————————
    I know it has several issues.
    But the problem ist, if I try to dial in with:
    # qmicli -vvv -d /dev/cdc-wdm0 ‘–wds-start-network=web.vodafone.de|XXXX|XX’
    [20 Dec 2012, 10:42:42] [Debug] [/dev/cdc-wdm0] Received message (translated)…
    >>>>>> QMUX:
    >>>>>> length = 31
    >>>>>> flags = 0×80
    >>>>>> service = “wds”
    >>>>>> client = 4
    >>>>>> QMI:
    >>>>>> flags = “response”
    >>>>>> transaction = 1
    >>>>>> tlv_length = 19
    >>>>>> message = “Start Network” (0×0020)
    >>>>>> TLV:
    >>>>>> type = “Result” (0×02)
    >>>>>> length = 4
    >>>>>> value = 01:00:0E:00
    >>>>>> translated = FAILURE: CallFailed
    >>>>>> TLV:
    >>>>>> type = “Call End Reason” (0×10)
    >>>>>> length = 2
    >>>>>> value = 01:00
    >>>>>> translated = generic-unspecified
    >>>>>> TLV:
    >>>>>> type = “Verbose Call End Reason” (0×11)
    >>>>>> length = 4
    >>>>>> value = 77:01:C8:71
    >>>>>> translated = [ type = '(null)' reason = '29128' ]

    In a non-public channel I could give you the complete log.
    Do you have an idea?

    Thanks,

    André

  40. You may want to ask the question directly in the libqmi-devel mailing list, including a proper full log:

    http://lists.freedesktop.org/mailman/listinfo/libqmi-devel

  41. Sorry, just saw that device was rebootet and PIN was not entered. Argh.
    Now it works! ;-)
    Do you have any whishes for such a patch?

    Thanks,

    André

  42. I’ll move the discussion to the list ;-)

  1. Pingback: Links 24/8/2012: Linux 3.6 RC3, Gnome Shell 3.6 Beta | Techrights

  2. Pingback: ModemManager (and latest udev) in OpenWRT « SIGQUIT

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 36 other followers

%d bloggers like this: