Troubleshooting QMI connection to a LTE modem, does not get IP address

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi everyone, I'm trying to run a Quectel EC25-E (I'm in europe so this is the right modem) over QMI protocol.

I've used LuCi and the QMI protocol in it to configure the thing.

This is logs of what happens when I click on "connect" button on this interface (called "qmi_wwan0" )

Sun May 27 09:47:43 2018 daemon.notice netifd: qmi_wwan0 (3998): "Unknown error"
Sun May 27 09:47:43 2018 daemon.notice netifd: qmi_wwan0 (3998): Waiting for network registration
Sun May 27 09:47:43 2018 daemon.notice netifd: qmi_wwan0 (3998): Starting network qmi_wwan0
Sun May 27 09:47:43 2018 daemon.notice netifd: qmi_wwan0 (3998): Setting up wwan0
Sun May 27 09:47:43 2018 daemon.notice netifd: Interface 'qmi_wwan0_4' is enabled
Sun May 27 09:47:43 2018 daemon.notice netifd: Interface 'qmi_wwan0' is now up
Sun May 27 09:47:43 2018 daemon.notice netifd: Network device 'wwan0' link is up
Sun May 27 09:47:43 2018 daemon.notice netifd: Network alias 'wwan0' link is up
Sun May 27 09:47:43 2018 daemon.notice netifd: Interface 'qmi_wwan0_4' has link connectivity
Sun May 27 09:47:43 2018 daemon.notice netifd: Interface 'qmi_wwan0_4' is setting up now
Sun May 27 09:47:44 2018 daemon.notice netifd: qmi_wwan0_4 (4044): udhcpc: started, v1.28.3
Sun May 27 09:47:44 2018 daemon.notice netifd: qmi_wwan0_4 (4044): udhcpc: sending discover
Sun May 27 09:47:44 2018 user.notice firewall: Reloading firewall due to ifup of qmi_wwan0 (wwan0)
Sun May 27 09:47:46 2018 daemon.info dnsmasq[3436]: read /etc/hosts - 4 addresses
Sun May 27 09:47:46 2018 daemon.info dnsmasq[3436]: read /tmp/hosts/dhcp.cfg01411c - 1 addresses
Sun May 27 09:47:46 2018 daemon.info dnsmasq-dhcp[3436]: read /etc/ethers - 0 addresses
Sun May 27 09:47:47 2018 daemon.notice netifd: qmi_wwan0_4 (4044): udhcpc: sending discover
Sun May 27 09:47:50 2018 daemon.notice netifd: qmi_wwan0_4 (4044): udhcpc: sending discover

By comapring it to the output in this bug report (which is not a bug) https://bugs.openwrt.org/index.php?do=details&task_id=1304 it seems that my modem isn't getting an IP address from the LTE side.

Also in the Interfaces page in Luci I see that this interface has TX that increases slowly (I assume these are the dhcp requests), while RX remains 0 (i.e. there is no answer).

I also tried to do manually with this guide https://tiebing.blogspot.it/2015/03/linux-running-4g-lte-modem.html and https://github.com/openwrt/luci/issues/275 and what I read in the wiki.

And the output was the same, but at least I got that the RX number was very slowly rising, I was receiving one packet per 30 seconds or so.

In either case there was no connection to the Internet, all pings to known servers failed.

The sim card I'm using in this modem works fine in my smartphone, and I've been using USB tethering to the USB port of the router with no issues.

Do you have any idea about what I could do here?

2

I'm far from an expert on these devices as I'm still in the process of trying to figure out why I'm not getting an IPv6 address on my SIM7100A. I have found uqmi to be helpful, though it is different from the typical qmicli on "desktop" systems.

jeff@devel:/etc$ sudo uqmi -d /dev/cdc-wdm0 --get-data-status
"connected"
jeff@devel:/etc$ sudo uqmi -d /dev/cdc-wdm0 --get-current-settings
{
	"pdp-type": "ipv4-or-ipv6",
	"ip-family": "ipv4",
	"mtu": 1500,
	"ipv4": {
		"ip": "X.X.X.212",
		"dns1": "10.177.0.34",
		"dns2": "10.177.0.210",
		"gateway": "X.X.X.213",
		"subnet": "255.255.255.252"
	},
	"ipv6": {
		
	},
	"domain-names": {
		
	}
}

The OpenWRT config script is /lib/netifd/proto/qmi.sh which hints that the following config parameters are available:

proto_qmi_init_config() {
        available=1
        no_device=1
        proto_config_add_string "device:device"
        proto_config_add_string apn
        proto_config_add_string auth
        proto_config_add_string username
        proto_config_add_string password
        proto_config_add_string pincode
        proto_config_add_int delay
        proto_config_add_string modes
        proto_config_add_string pdptype
        proto_config_add_int profile
        proto_config_add_boolean dhcpv6
        proto_config_add_boolean autoconnect
        proto_config_add_int plmn
        proto_config_add_defaults
}
1 Like
3

Thanks, it seems I'm getting a garbage MTU number, "263644" is way off the charts for ethernet at least, and yours is set to 1500 at least.

Is your modem working (you can connect to the Internet), even if it does not get an IPv6?

here my current settings if I run the above commands.

root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --get-current-settings
{
        "pdp-type": "ipv4",
        "ip-family": "ipv4",
        "mtu": 263644,
        "ipv4": {
                "ip": "0.23.154.198",
                "dns1": "0.4.21.25",
                "dns2": "0.4.97.25",
                "gateway": "10.23.154.197",
                "subnet": "0.4.33.252"
        },
        "ipv6": {

        },
        "domain-names": {

        }
}
root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --get-data-status
"connected"

I'll try out changing manually the mtu to something saner.

4

Hmm, I don't understand what's going on, if I look up the system's MTU it shows a correct value, not a total bogus number like I get with the uqmi command, and changing by echoing another value in that file does not seem to affect that interface.

root@OpenWrt:~# cat /sys/class/net/wwan0/mtu 
1500
5

Yes, the modem seemed to be functional under OpenWRT. It has since been moved over to a Debian box so that I can poke at it with the toolset available there and try to resolve my desire to get an IPv6 address for it. If you have questions, I can easily move it back to my development Archer C7 here as well.

big/little endian????? The IP addresses are "surprising" as well.

config interface 'LTE'
	option ifname 'wwan0'
	option device '/dev/cdc-wdm0'
	option proto 'qmi'
	option apn 'fast.t-mobile.com'
	option auth 'none'
	option dhcpv6 '1'
	option metric '10'

(Metric included since otherwise it replaces the default route on the device with the gateway for the LTE link. Thankfully I didn't burn through the data plan before I discovered it!)

Edit:

You can install the kernel modules to enable both the serial-based access as well as the QMI access and I think that you can use AT commands (within reason) while the modem is being managed with QMI. https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle#optional_packages gives them as

  • kmod-usb-serial-wwan
  • kmod-usb-serial-option
  • kmod-usb-serial
6

big/little endian???

It's a Kirkwood-based router, a Lynksys EA4500 and according to the test I did from this https://serverfault.com/questions/163487/how-to-tell-if-a-linux-system-is-big-endian-or-little-endian

root@OpenWrt:~# echo -n I | hexdump -o | awk '{ print substr($2,6,1); exit}'
1

it should be a little endian.

the config that was generated by the LuCi QMI protocol is this


network.qmi_wwan=interface
network.qmi_wwan.proto='qmi'
network.qmi_wwan.device='/dev/cdc-wdm0'
network.qmi_wwan.apn='internet.wind'
network.qmi_wwan.auth='none'

You can install the kernel modules to enable both the serial-based access as well as the QMI access

I did compile in those drivers too, and some others, maybe they are interfering, I'll try rebuilding the image without the "optional" stuff and see how it goes.

I know I can go over serial but I'd rather not go into that, I have lost so many time in the past tinkering with other USB dongles and AT commands without getting anywhere, and I'm sick and tired of that illogical nonstandard undocumented embedded system bs.

The whole point I bought this thing (and it was not cheap) is because I thought it was mostly plug-and-play due to its use of QMI protocol.

If I can't get this thing working on QMI I'm getting a huawei 310s-22 or 315, which are small LTE modem-routers with their own web interface and a gigabit port, and connect it over the WAN port of my current router (it can at least do a DMZ, I don't know if I can actually disable the NAT too).

7

From what I researched, the "s" (stick) models can provide a "direct" interface, while the "h" (HiLink) models only supply NAT.

8

It's not a dongle, it's a small modem-router with wifi and a gigabit ethernet port, it has a web interface. https://www.4gltemall.com/huawei-b310-lte-cpe.html
I have already confirmed that this thing can do a DMZ, which is good enough, and already better than what most dongles running the "smart" firmware can provide.

The Quectel EC25-E instead is a mini-pcie card and is installed in a modem adapter that routes the modem's native USB lines to a USB port, and adds a SIM card slot. The whole thing is powered by an external power source because I'm not trusting the router itself with such a power hungry device.

9

Good plan! I'll probably end up buying a new Sierra Wireless card and just ordered an eBay-sourced external case for it. It's been recommended to me not to bother with trying to re-flash the Dell-branded units. The main driver for me in a module change is to get B12 capabilities which the module I have now doesn't provide. It's working adequately on the high band, but low-band coverage at my location is significantly better.

From what I've been told, QMI runs circles around PPP over serial in terms of throughput. The suggestion of AT commands was for querying the device for debugging.

10

From what I’ve been told, QMI runs circles around PPP over serial in terms of throughput.

Yeah it's correct. QMI uses serial commands to control the modem but it creates a virtual ethernet-port-over-usb for actual network traffic. Rndis or ncm protocols do the same.

Afaik with serial only connection you can't go faster than 20 Mbit.

The suggestion of AT commands was for querying the device for debugging.

I can do that if someone with experience is guiding me so we can troubleshoot this issue properly, but I don't know enough nor have interest in hacking around this stuff on my own. I have already seen how deep is the rabbit hole and I don't want to get into that alone.

1 Like
11

More digging, I found another thread on the now defunct openwrt forum https://forum.openwrt.org/viewtopic.php?id=72013

where other people can't get these pieces of wasted silicon to connect to anything, and at the end someone connected magically with no effort at all, with a very simple configuration that on mine does not work.

But now I've tried all commands to get data off the thing, and it seems I'm also getting total nonsense in other critical fields like mcc and mnc. For my operator they should be 222 and 88 respectively, I'm seeing again a huge nonsense number instead. Using uqmi commandline to change them isn't working.

This is the current situation so far

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": 263644,
        "ipv4": {
                "ip": "0.9.194.25",
                "dns1": "0.4.21.25",
                "dns2": "0.4.97.25",
                "gateway": "10.9.194.26",
                "subnet": "0.4.33.252"
        },
        "ipv6": {

        },
        "domain-names": {

        }
}
{
        "max_tx_channel_rate": 917888,
        "max_rx_channel_rate": 49999872,
        "data_service": "non_simultaneous_cs_ps",
        "sim": "supported",
        "networks": [
                "gsm",
                "umts",
                "lte"
        ]
}
{
        "type": "lte",
        "rssi": -77,
        "rsrq": -13,
        "rsrp": -27405,
        "snr": -3841
}
{
        "registration": "registered",
        "plmn_mcc": 56832,
        "plmn_mnc": 22528,
        "plmn_description": "I�5�\b",
        "roaming": false
}

Also, it does not seem like this device is in a known data mode, it should report "raw-ip" here according to https://lists.freedesktop.org/archives/libqmi-devel/2017-January/002065.html and https://github.com/openwrt/openwrt/commit/7488be701029a86259dcd297a3c665eb65bdac6e

root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --wda-get-data-format
"unknown"

I'm starting to suspect this thing is either broken, or that the firmware it's running is trashed. Next stop... trying to upgrade the firmware if it's possible at all and I can get it without being an ISP or an OEM.

12

Just to double check, you've got usb-modeswitch installed, yes? I'm guessing you do as you get something, but "grasping at straws"

13

No, I thought this device should not need it as it's a mini-pcie modem for embedded usage.

usb-modeswitch was for dongles that when connected to a PC will show up as a virtual CD drive to install the drivers, and won't switch to dongle mode until their crappy client software tells them to.

Anyway, I'm now installing it and rebooting the modem and... nothing changes.

Meanwhile, Quectel is yet another company that does not deal with consumers and of course there is no way I can get to an official firmware download page unless I'm a businness customer.

Still, I found a youtube video here on how to flash an updated firmware https://www.youtube.com/watch?v=38tb1lwsbuw that provides a download link for another quectel product http://www.quectel.com/Qdownload/UG95.html
And indeed it downloads fine.
What happens if I change the name of the page to EC25? yeah it works. God bless sloppy webdevelopers.
http://www.quectel.com/Qdownload/EC25.html

But still no dice. Now I have a ton of PDF files with all AT commands and various specs and stuff, some windows tools, a bunch of drivers that will likely not work at all, but still no firmware.

14

Even though it goes into a miniPCIe or M.2 slot, at least from what I understand, most of them are still USB devices.

15

yes I know, as I said above it's mounted in a "mini-pcie to USB adapter", which is... not really capable of running pcie over USB, but is just piping the card's native USB connection to a male USB port and providing power at the right voltages from a 5v source. And adding a SIM card slot conencted drirectly to the dedicated sim card pins in the minipcie slot (because yes it also has dedicated sim connections).

What matters is that the minipcie form factor of these things is usually for routers and other embedded equipment, it makes no sense to have them show themselves as virtual CDs by default there.

16

Aand, no firmware anywhere.

I've tried connecting the modem to my PC running OpenSUSE tumbleweed.

this appears on dmesg (nothing strange imho)

[50477.827418] usb 2-1.5.2: new high-speed USB device number 12 using ehci-pci
[50477.945515] usb 2-1.5.2: New USB device found, idVendor=2c7c, idProduct=0125
[50477.945523] usb 2-1.5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[50477.945527] usb 2-1.5.2: Product: Android
[50477.945531] usb 2-1.5.2: Manufacturer: Android
[50477.946831] option 2-1.5.2:1.0: GSM modem (1-port) converter detected
[50477.947098] usb 2-1.5.2: GSM modem (1-port) converter now attached to ttyUSB0
[50477.947479] option 2-1.5.2:1.1: GSM modem (1-port) converter detected
[50477.947815] usb 2-1.5.2: GSM modem (1-port) converter now attached to ttyUSB1
[50477.948227] option 2-1.5.2:1.2: GSM modem (1-port) converter detected
[50477.948652] usb 2-1.5.2: GSM modem (1-port) converter now attached to ttyUSB2
[50477.949066] option 2-1.5.2:1.3: GSM modem (1-port) converter detected
[50477.949479] usb 2-1.5.2: GSM modem (1-port) converter now attached to ttyUSB3
[50477.950365] qmi_wwan 2-1.5.2:1.4: cdc-wdm0: USB WDM device
[50477.953115] qmi_wwan 2-1.5.2:1.4 wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.5.2, WWAN/QMI device, 16:9f:df:80:d5:ca
[50478.769176] qmi_wwan 2-1.5.2:1.4 wwp0s29u1u5u2i4: renamed from wwan0

But it seems every attempt to talk at this thing fails even harder. At least on OpenWrt I was getting some answers and it was somewhat starting up.

The qmicli (linux desktop equivalent of the uqmi tool in OpenWrt) returns only errors or hangs.

Trying to open a serial connection to /dev/ttyUSB1 works, but then it does not answer in any way to my commands it just hangs there until I terminate the console.

Hmm, I think I read that people were complaining that setting this modem to "autoconnect" locks out the user or something. Let's see if I can disable autoconnect with the forced command I saw in the tiebing blog from above.

root@OpenWrt:~# device="/dev/cdc-wdm0"
root@OpenWrt:~# uqmi -s -d "$device" --stop-network 0xffffffff    --autoconnect
root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --get-data-status --get-current-settings --get-capabilities --get-signal-info --get-serving-system
"disconnected"
"Out of call"

Ok the thing is now offline. Let's see if now I can talk to it from my PC.

Nope, still inaccessible

openSUSE-xeon:/home/alby # qmicli -d /dev/cdc-wdm0 --nas-get-system-info 
[28 mag 2018, 01:21:55] -Warning ** Error reading from istream: Resource temporarily unavailable

And AT commands still hang.

My bat-senses are tingling very strongly now. This unit was either screwed with or it is defective.

There is no way I can think of that this thing can't answer to AT commands, it's a damn serial connection.

Last test, trying AT commands from the OpenWrt router, if this fails I'll try to return this thing as defective. I'm probably going to do that anyway, this situation isn't normal.

Recompiling again with serial drivers and picocom, crossing fingers...

17

aand nope, AT commands hang also in the OpenWrt router.

I'm closing this case as "defective card", but if anyone wants to chime in I'm all ears at least to know for the future.

@jeff can you tell me what is the brand/model of your modem? I'd still rather have a modem instead than a full external device and maybe it's cheaper than other EC25 modems I could get.

18

I'm running a SimTech SIM7100A on a "break-out board" from a Chinese eBay seller that seems to be related to, if not the same as, the board house. It's about 5 cm x 5 cm. I can't say that SimTech's reuse of USB device IDs makes me happy or confident in their firmware (see LTE wireless module support by openwrt led on TPLINK, for example), but it's functional at ~US$50.

In retrospect, I wish I had bought a Sierra Wireless directly from a commercial component distributor for the $100 more it would have been, just to save time now, and in the future.

  • EM7565 is "brand new" module, but only in M.2 form factor -- $156
  • EM/MC7455 is an older module with the "MC" being in the miniPCI format -- $143

I'm probably going to order the EM7565 tomorrow, but who knows when the eBay case for it will come from China.

1 Like
19

https://github.com/bmork/LEDE/commit/10aed12fa587e818e4dc5d0db54545623fbe9b5f
check this. I think, that uqmi is broken.
If you can re-compile uqmi, do this with patch.

1 Like
20

Hm, I asked to qmicli devs in their mailing list and it seems the commands from my PC weren't working as I had ModemManager installed (which is normal I guess), after I removed it I could communicate with the card on both serial and QMI protocols.

I tried recompiling uqmi with @iuncuim 's "duct tape patch" https://github.com/teleofis/OpenWRT/commit/cc1d89fdd2c5c9275ce632db8eb94a889c3f6b9e once I have ported it over to OpenWrt master and not to Chaos Calmer which is what his sources are.

And yeah it works if I hardcode that value. I can connect to the internet with that.

Values I read from the device are still looking weird af. I guess the parser is still reading garbage, but at least the commands the system sends TO the modem are working.

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": 263644,
        "ipv4": {
                "ip": "0.7.131.165",
                "dns1": "0.4.21.25",
                "dns2": "0.4.97.25",
                "gateway": "10.7.131.166",
                "subnet": "0.4.33.252"
        },
        "ipv6": {

        },
        "domain-names": {

        }
}
{
        "max_tx_channel_rate": 917888,
        "max_rx_channel_rate": 49999872,
        "data_service": "non_simultaneous_cs_ps",
        "sim": "supported",
        "networks": [
                "gsm",
                "umts",
                "lte"
        ]
}
{
        "type": "lte",
        "rssi": -77,
        "rsrq": -14,
        "rsrp": -27918,
        "snr": 24831
}
{
        "registration": "registered",
        "plmn_mcc": 56832,
        "plmn_mnc": 22528,
        "plmn_description": "I�5�\b",
        "roaming": false
}

I will also try with the other patch suggested by Bjorn in that thread which is available from here (the link in that discussion is dead as the mailing lists were merged) http://lists.infradead.org/pipermail/openwrt-devel/2018-April/011701.html
But since this is also a little endian system I don't think it will fix my issue.
Aaand... no effect here. Connection is still broken with just this patch applied.

@bmork now there is another guy with the same issue.

I can try try debugging the uqmi util, but I'm not a professional programmer and I could use some tips, like for example where is the parser logic in the uqmi source (I cloned the source from its own git repo), if there is something I should look first, whatever you think might be useful to know.