I have some issue to get the above 4G modem recognized by the OpenWrt/LEDE.

Everything seems to work fine, but the wwan or any other possible 4G device doesn’t show in the /dev/ directory

It’s the first time I try to get a 4G on a OpenWrt/LEDE firmare and don’t really know where to look to troubleshoot.

I have used the binary from the LEDE repo and also compiled the OpenWrt and LEDE sources from the manufacturer repo( https://github.com/domino-team )

Any clue or howto?
Missing module/package on the vanilla firmware for that device?
Compile options?

Thanks.

(Last edited by ripat on 14 Sep 2017, 08:50)

I tried the Quectel EC25 as a cheaper alternative to Huaweis ME909u in a commercial project, with many installations.
No success, so we continued to use the Huawei;  in 3g+ mode (HSDPA+ etc.). No LTE, though.
Lemme know here, in case you have better luck.

I made some progress with the Quectel EC25 compiling from the Gl-iNet repo.

In the menuconfig:

• Target System --> AR7xx

• Target Profile ---> GL-MIFI

• Gl.iNet package choice shortcut --> support modem qmi mode

The latest will install the following packages:

PACKAGE_kmod-mppe
PACKAGE_kmod-usb-net
PACKAGE_kmod-usb-cdc-ether
PACKAGE_kmod-usb-net-rndis
PACKAGE_kmod-usb-net-qmi-wwan

(Last edited by ripat on 13 Sep 2017, 14:13)

Which connection speed (3g/4g) works for you, using the quectel ?

Well, I wish I could tell!

Modem is responding to a uqmi request but can not connect to my provider's APN for some reason.

New to qmi and need some help to troubleshoot.

uqmi -d /dev/cdc-wdm0 --get-data-status --get-signal-info
"disconnected"
{
        "type": "gsm",
        "signal": -98
}

When I try to connect:

uqmi -d /dev/cdc-wdm0 --start-network <my provider's APN>
"No effect"

Any idea?

Update

I placed the MiFi router outside for a better signal reception and I get this now:

uqmi -d /dev/cdc-wdm0 --get-data-status --get-signal-info
"disconnected"
{
        "type": "wcdma",
        "rssi": -96,
        "ecio": 17
}

(Last edited by ripat on 14 Sep 2017, 08:29)

I had contact with quectel some time ago (via provider of router) and got the info, they do not support qmi mode.
As I also did not succeed to use the quectel on my router in serial mode, we dropped it and switched back to Huawei.
You might try to get in touch with quectel directly for an update.

That could be the reason why I can not connect. I am stuck with Quectel on the box I am testing. Which protocol would you then suggest? AT commands?

Yes; you should try basic serial (ppp) . Which should work on all modem types, as it is the most simple protocol (generic).
BTW, also the Huawei only works in serial mode for me, but the conn speed (about 25 MBit/s) is good enough for us.
Only some time ago I succeeded to use qmi with Sierra modem.
To properly set up qmi seems to be some type of Black Magic :-)

However, one of the developers of qmi is here from time to time. May be, you post a specific question regarrding qmi/quectel in the developers section.

I'll do that. Thanks.

As for AT commands, no better luck so far. My SIM card is not recognized for some reason. SIM works alright in my mobile phone. I tried pure AT commands (echo > ttyUSB2) and also with the comgt wrapper. Still trying.

While comgt tries to connect, the device gets this response:

root@GL-MIFI:~# cat /dev/ttyUSB2
+CPIN: SIM PIN

AT+CFUN=1
OK
AT+CPIN?
+CPIN: SIM PIN

OK
AT+CFUN=1
OK
AT+CPIN?
+CPIN: SIM PIN

OK

comgt output says (verbose mode, sorry)

comgt -vd /dev/ttyUSB2
comgt 15:21:45 -> Verbose output enabled
comgt 15:21:45 -> argc:3
comgt 15:21:45 -> argv[0]=comgt
comgt 15:21:45 -> argv[1]=-vd
comgt 15:21:45 -> argv[2]=/dev/ttyUSB2
comgt 15:21:45 ->  ---Script---

deleted for clarity

comgt 15:21:45 ->  ---End of script---
comgt 15:21:45 -> @0000 opengt
comgt 15:21:45 -> Opened /dev/ttyUSB2 as FD 3
comgt 15:21:45 -> @0011 set com 115200n81
comgt 15:21:45 -> @0033 set senddelay 0.05
comgt 15:21:45 -> @0056 send "AT+CFUN=1^m"
comgt 15:21:46 -> @0079 waitquiet 1 0.2
comgt 15:21:46 -> @0097 :start
comgt 15:21:46 -> @0108 flash 0.1
comgt 15:21:46 -> @0122 send "AT+CPIN?^m"
comgt 15:21:47 -> @0144 waitfor 30 "SIM PUK","SIM PIN","READY","ERROR","ERR"
comgt 15:22:17 -> @0201 if % = -1 goto error
comgt 15:22:17 -> @0211 goto error
comgt 15:22:17 -> @0345 :error
comgt 15:22:17 -> @0356 print $s," ***SIM ERROR***
 ***SIM ERROR***
comgt 15:22:17 -> @0389 print "Check device port configuration.
Check device port configuration.
Check SIM is inserted
Test SIM in a mobile phone?
comgt 15:22:17 -> @0485 exit 1:

(Last edited by ripat on 16 Sep 2017, 20:23)

This usually means that the modem is configured for autoconnect.  Which in my opinion does not work.  Or at least:  It does not work as one would expect.

See for example http://lists.infradead.org/pipermail/le … 05182.html

I am aware that the OpenWrt qmi scripts enable autoconnect in some futile attempt for work around the lack of host based modem management.  I believe this is a disservice to the users. Modem firmware sucks.  You cannot trust it to implement features you find too complicated to do properly on the host side.  Not in a remotely sane way, anyway.

autoconnect in qmi makes the firmware connect alright.  But as you've noticed, there is no way for the host to regain control over that connection. Which makes the feature pretty useless, IMHO.

Have a Quectel EC25-A working on ZBT WG3526 16M hardware. This is requiring a 4.9+ kernel, but hey, it's works simply with only a couple additional packages. I'm on AT&T, btw. The actual kernel version of SNAPSHOT r6334-36fb069 is 4.9.82.

I installed the 20180228 snapshot release. It's relatively bare, so log on with SSH to a wired LAN port. The WiFi radios are disable so I edited the /etc/config/wireless to switch the interfaces on at boot time.

In my case, I bridged the WAN port through my Macbook's Thunderbolt wired port to give it Internet access.

Grab the package list:

opkg update

Install luci and its qmi component to make your life easier, one other package, and restart:

opkg install luci luci-proto-qmi kmod-usb-net-cdc-ether
reboot

Logon to the web client

Add a "WWAN" interface as "QMI Cellular", with "/dev/cdc-wdm0" as the device, APN = "Broadband" (but I don't think it matters), Auth = "NONE"

Set the Advanced Settings to "Bring up on boot", if it's not already set.

Reboot once again. The Interfaces Overview page then showed packets both being transmitted and received.

reboot

BusyBox v1.27.2 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt SNAPSHOT, r6334-36fb069
 -----------------------------------------------------
root@OpenWrt:~# ifconfig wwan0
wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.129.134.152  P-t-P:10.129.134.152  Mask:255.255.255.240
          inet6 addr: fe80::748d:8c25:fca5:4e2d/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:4601 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5162 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2431725 (2.3 MiB)  TX bytes:2346637 (2.2 MiB)

root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --get-data-status --get-current-settings --get-capabilities --get-signal-info --get-serving-system
"connected"
{
    "pdp-type": "ipv4",
    "ip-family": "ipv4",
    "mtu": 1430,
    "ipv4": {
        "ip": "10.129.134.152",
        "dns1": "172.26.38.1",
        "gateway": "10.129.134.153",
        "subnet": "255.255.255.240"
    },
    "ipv6": {
        
    },
    "domain-names": {
        
    }
}
{
    "max_tx_channel_rate": 50000000,
    "max_rx_channel_rate": 100000000,
    "data_service": "non_simultaneous_cs_ps",
    "sim": "supported",
    "networks": [
        "umts",
        "lte",
        "unknown"
    ]
}
{
    "type": "lte",
    "rssi": -70,
    "rsrq": -11,
    "rsrp": -100,
    "snr": 48
}
{
    "registration": "registered",
    "plmn_mcc": 310,
    "plmn_mnc": 410,
    "plmn_description": "A??\n",
    "roaming": false
}

I transferred a 56MB file and had an average transfer speed of 312 KB/s and a transfer time of just under three minutes (2:58). Max observered transfer speed in the middle of my house on the side of a hill without direct LoS to a cell tower was 340 KB/s.

I hope this help other folks struggling with this.

(Last edited by Buzzsaw on 5 Mar 2018, 16:36)