I notice qmi is added to OpenWRT
https://dev.openwrt.org/changeset/40868
Which dependency do we need to enable QMI Support?

I'm not sure I understood your question correctly, but you need basically kmod-usb-net-qmi-wwan, usb-modeswitch, and uqmi. I'll add documentation to wiki on how to configure qmi during the weekend. In the mean time, you'll find an example config from my initial posting: https://lists.openwrt.org/pipermail/ope … 25046.html

What about LuCI Support?

There is no support in LuCI right now.

For some reason "make menuconfig" seems to de-select kmod-usb-net-qmi-wwan for me:

$ fgrep qmi ../cfg/config-ar71xx
CONFIG_PACKAGE_kmod-usb-net-qmi-wwan=y
CONFIG_PACKAGE_libqmi=n
CONFIG_PACKAGE_uqmi=y
$ cp ../cfg/config-ar71xx .config
$ make prereq
$ make menuconfig
...
$ fgrep qmi .config
CONFIG_PACKAGE_uqmi=y
$ fgrep usb .config|fgrep =y
CONFIG_DEFAULT_kmod-ledtrig-usbdev=y
CONFIG_DEFAULT_kmod-usb-core=y
CONFIG_DEFAULT_kmod-usb2=y
CONFIG_PACKAGE_kmod-ledtrig-usbdev=y
CONFIG_PACKAGE_kmod-usb-acm=y
CONFIG_PACKAGE_kmod-usb-core=y
CONFIG_PACKAGE_kmod-usb-ohci=y
CONFIG_PACKAGE_kmod-usb-serial=y
CONFIG_PACKAGE_kmod-usb-serial-option=y
CONFIG_PACKAGE_kmod-usb-serial-wwan=y
CONFIG_PACKAGE_kmod-usb2=y
CONFIG_PACKAGE_libusb-1.0=y
CONFIG_PACKAGE_usb-modeswitch=y
$

Is there a conflict between modules for USB modems of different technology (e.g. USB-to-WWAN, QMI, cdc-ncm), or can we include all of them in an OpenWRT image (assuming adequate flash diskspace)?

TIA

No conflicts.

Of course, qmi_wwan has dependencies of its own (e.g., kmod-usb-net), which you probably didn't add?

Thanks for the clarification, but shouldn't any such dependencies have been added automatically ?

Btw there are over a dozen kmod-usb-net-* packages which can be selected, are these documented anywhere?

Edit: Are perhaps the kmod-usb-serial* and kmod-usb-net*  mutually exclusive ?

(Last edited by kpv on 30 May 2014, 18:22)

They get added automatically if you select kmod-usb-net-qmi-wwan from menuconfig. If you just add it by hand to some .config and then run make menuconfig, they won't be added, AFAIK.

Also, usb-serial* and usb-net* are not mutually exclusive.

You'll get some basic documentation for the usb-net* packages from menuconfig by pressing ?, I don't think there is any other documentation.

Thanks a lot, you have been very helpful, I'm building a new custom image right now for testing.

One final question: Does anyone know how BB trunk + uqmi compares with OpenWRT-based ROOter firmware (http://ofmodemsandmen.com/) that specializes in 3G/4G modem support ?

Web interface integration of uqmi is missing from OpenWrt right now, as well as support for ECM/NCM/MBIM-based modems (but I'm planning to work on them as well). The approach taken by ROOter is a hacky set of scripts, but at least it works on a wider variety of modems.

What about package kmod-usb-net-cdc-ncm, doesn't it offer NCM-based modems support ?

Btw I'm looking at webpages http://www.rfactory.org/OpenWRT/modem.html and http://ofmodemsandmen.com/supported.html to learn more about 3G/4G modem protocols, hopefully they're accurate.

(Last edited by kpv on 30 May 2014, 22:26)

The support in kernel is there (by virtue of the various kmod's), but there is no netifd integration in OpenWrt.

Yes, and contrary to MBIM and QMI which have well defined management protocols, management of NCM devices is a vendor specific mess. Most of these are managed using a mix of standard GSM AT commands and vendor specific AT commands over a serial function.  But some of the Huawei devices use an in-band management channel, like QMI and MBIM, but still use AT commands over this channel.

BTW, thanks for your work on getting QMI support in OpenWRT.  It is fun to see how things can get moving once we get a simple driver like this into mainline Linux :-)

Hi to everyone

I see the last post here is quite old and I don't know if my help request will ever be read by anyone but I'll try my chance anyway since I'm not able to get any further ...

I'm getting mad :-) with the qmi protocol on the BB final release: there is no way I can get a ZTE K5006Z to connect to internet, while the 3g protocol with a huawei E3131 on the same router (and the same sim card) seems, for the time being to have no issues. Is there anybody who can give me a hint?

The hardware and settings info are:

-TPlink wr1043nd
-BARRIER BREAKER (14.07, r42625) installed
-added packages: libpthread kmod-mii kmod-usb-net kmod-usb-wdm kmod-usb-net-qmi-wwan librt libusb-1.0 usb-modeswitch uqmi libqmi comgt kmod-usb2 kmod-usb-ohci kmod-usb-uhci kmod-usb-serial kmod-usb-serial-option kmod-usb-serial-wwan usb-modeswitch sdparm luci-proto-3g luci-app-ddns wget
-network settings:

config interface 'lan'
    option ifname 'eth0.1'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ipaddr '192.168.1.1'

config interface 'wan2'
    option ifname 'eth0.2'
    option proto 'dhcp'
    option auto '0'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '1 2 3 4 5t'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0 5t'

config interface 'wan'
    option ifname 'wwan0'
    option device '/dev/cdc-wdm0'
    option proto 'qmi'
    option apn '*apn*'
    option delay '30'
    option mode 'umts, gsm'

config interface '3G-WAN'
    option proto '3g'
    option device '/dev/ttyUSB0'
    option service 'umts'
    option apn '*apn*'
    option keepalive '5 5'
    option auto '0'

I must add the output of the "ls -l /dev/cdc-wdm0" command which is:

crw-r--r--    1 root     root      180, 176 Oct 27 13:11 /dev/cdc-wdm0

Many thanks

Hi to everyone again,

just for information I reply myself to my previous post. I think the problem I had was related to a too weak radio signal which mostly affected the ZTE modem. As a matter of fact since I use an external antenna the ZTE modem seems to work flawlessly.

Many thanks again especially to the openwrt team