QMI EC25 LTE modem - no incoming packets

Hi, sorry for rising this topic again, but having read all the topics regarding EC25 I didn't find the solution.
The situation is quite simple: modem (Quectel EC25-E Mini PCIe module) is recognised and seen as /dev/cdc-wdm0 out of the box. Then, successfully connected to the LTE network using uqmi CLI tool. Also, got the IP and right MTU (1500).

Then I am simply trying to ping -I wwan0 8.8.8.8 and it doesn't work. I see TX packets counter moving up and at the same time RX packets counter is constant (normally like 4 or sometimes 6).

I've checked already everything about raw_ip and it's actually ON, i.e. cat /sys/class/net/wwan0/uqmi/raw_ip is Y.

I am using the latest ar71xx build with the latest kernel 18.06.4.

Any ideas what's wrong and how to diagnose?

If you got an IP address, this means there are incoming packets. Because you can not receive an IP from your provider if there was no communication.

What we need is the log output. Can you get all the messages related to your connection attempt using logread for example? Send ifconfig -a and netstat -rn output also.

You can also query the modem status from one of the ttyUSB ports. But I can't recall the exact AT commands, make a web search for EC-25 AT Commands PDF

I used EC-25 quite long time but then switched to ME909s-120 (I think same as ME906s-120) because my EC25-E was freezing under bi-directional traffic load. I don't know why. But the point is, I don't have it installed in the device now myself so I can't check it up.

I agree, as soon as there is an IP assigned means that some packets were travelling between me and provider. And really I see some number of packets received (usually between 4-8).

Here are some logs to show better the situation:

root@LEDE:~# cat /sys/class/net/wwan0/qmi/raw_ip
Y
root@LEDE:~# uqmi -d /dev/cdc-wdm0 --get-signal-info
{
        "type": "lte",
        "rssi": -79,
        "rsrq": -13,
        "rsrp": -106,
        "snr": 26
}
root@LEDE:~# uqmi -d /dev/cdc-wdm0 --get-data-status
"connected"
root@LEDE:~# uqmi -d /dev/cdc-wdm0 --get-current-settings
{
        "pdp-type": "ipv4",
        "ip-family": "ipv4",
        "mtu": 1500,
        "ipv4": {
                "ip": "10.0.1.100",
                "dns1": "217.200.200.42",
                "dns2": "213.230.155.10",
                "gateway": "10.0.1.101",
                "subnet": "255.255.255.248"
        },
        "ipv6": {

        },
        "domain-names": {

        }
}
root@LEDE:~# udhcpc -i wwan0
udhcpc: started, v1.28.4
udhcpc: sending discover
udhcpc: sending select for 10.0.1.100
udhcpc: lease of 10.0.1.100 obtained, lease time 7200
udhcpc: ifconfig wwan0 10.0.1.100 netmask 255.255.255.248 broadcast +
udhcpc: setting default routers: 10.0.1.101

root@LEDE:~# ifconfig -a
...
wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.1.100  P-t-P:10.0.1.100  Mask:255.255.255.248
          inet6 addr: fe80::7fdf:4cef:f7dd:ac00/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2265 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1860 (1.8 KiB)  TX bytes:156718 (153.0 KiB)

root@LEDE:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.1.101      0.0.0.0         UG        0 0          0 wwan0
10.0.1.96       0.0.0.0         255.255.255.248 U         0 0          0 wwan0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br-lan
	  
root@LEDE:~# ping -I wwan0 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

@glalexey

I can send you the latest fw for the EC25 tomorrow if you want to test it?

These devices have lots of issues on older firmware ..

What is the version you have and how you get it? I would be interested also. I am a big fan of upgrading to latest version :slight_smile: When I ran AT+GMR command, it returned EC25EFAR02A08M4G. Also how is this card upgraded exactly?

@glalexey first try to ping the closest place to yourself. Like 10.0.1.100 which is the interface IP. Then try 10.0.1.101.

The problem with your method of testing is that ping may be disabled by your ISP and they may also have a login screen to go through first. In many cases you should receive response to ping even when it is rejected but your ISP can configure their routers to discard all such packets.

After that, try to use nslookup www.google.com they should at least allow you to access their DNS server for anything to work. :slight_smile:

One other thing you can do is to re-run dhcpd manually again to test if you are able to get IP still. If it can re-get the IP. Then I would be expecting that your problem is mostly related to how your ISP functions and your setup is fine.

By the way, do you have to set something specific for APN? Because with EC-25 the APN setting was not working before.

Latest is EC25EFAR06A06M4G
Upgrade is done using their QFlash utility.

Well spotted. Operator's portal IP or sometimes their DNS could be a better target for pings.

Never noticed that, even with the old firmware.

That version looks newer than mine. I would like to get it. How can I get it? Also I need the QFlash utility obviously. I feel like I am the only person who doesn't have the latest firmware now.

That is the thing, you can see the DNS IPs in OPs post and I can't ping it from outside also :slight_smile: But surely DNS packets should be passing so nslookup should be used for test.

See here (somewhere in middle): https://bugs.openwrt.org/index.php?do=details&task_id=1252

You can't really notice it if your provider defaults to an APN. But if your provider has different APN for different purposes, then you can see that EC25 only use the default one.

Now I don't remember all the details. But I had to write scripts to get around EC25 not using APN setting.

For the latest firmware I suggest to contact Quectel support, usually they provide a firmware along the tool.
OP seems to be a TIM customer, so I would try to ping 156.54.69.9 (tim.it), but better to check for a possible redirect to a portal or landing page from another device.

1 Like

I just asked Quectel explaning the issues I noticed with the product. :slight_smile:

1 Like

I have checked the firmware version:

root@LEDE:~# echo "AT+GMR" > /dev/ttyUSB2 | cat /dev/ttyUSB2
AT+GMR

EC25EFAR06A04M4G

Actually, looks quite new and I don't think that it causes the issue. Anyway, will try to update to the most recent one.

Tried also to ping the gateway to call nslookup and many other things - the result is always the same. In case of nslookup is connection timeout.

I have passed the APN to the uqmi CLI tool explicitly. So, I am sure that it uses the right APN - otherwise it doesn't connect to the network.

Another thing: I have tried another modem Long Sung U9300C (had to modify kernel a bit to add appropriate USB device ID and vendor ID). Anyway, after everything connected its seen as a modem, connects to the network using QMI CLI tool, gets the IP and again cannot ping and cannot receive any data. So, basically, the same way as Quectel EC25 did.

At this point I am thinking that the issue is not the modem module itself and nor the firmware, but something deep inside linux. And really, I am running out of ideas how to diagnose better the issue.

@glalexey
read PM

@glalexey you did not answer if you can re-run dhcp client and get IP again. (and if the packet counters increase) ? or it does get stuck also ?

Yes, but it has a bug. It won't work if you use --autoconnect option See: https://bugs.openwrt.org/index.php?do=details&task_id=1252 look at my post on 14.02.2018 19:50
The point is, you can't trust it.

Let me put it this way, does your ISP require a specific APN? Also are you able to test the SIM card in a phone?

What do you mean? You tried to ping your own IP and ping does not work??? If that is the case, you may have messed up your firewall rules which causes this problem.

I doubt there is anything wrong with Linux itself as I was using this module until quite recently and also other people have been using it. You must have done something wrong.

Many thanks to everybody!
The problem is solved and it was quite simple - the SIM card!
I was using the same module and the same SIM card in AT mode and therefore I was sure that it will work in QMI mode as well. Didn't expect the issue to come from that side.
So, I've managed to make it working with another SIM card of another operator. Might be the problem is that the original SIM requires data roaming to be on.

FYI the symptoms were: the ping worked fine for the own IP being used w/o network interface key, i.e.

ping 10.0.11.77

but it doesn't if interface is provided:

ping -I wwan0 10.0.11.77

I tried to renew DHCP lease and in that case even if I got the same IP, the TX packets counter was increased by 2. So, some packets were travelling fine.

Also, Long Sung Mini-PCIe (U9300C) now works fine with the same software configuration (it required a few kernel changes to add USB devId and venId to be recognised).

@glalexey it can't be roaming etc. as you got an IP address from your provider. You had a connection.
There is no such thing as AT mode. You can issue AT commands to modem even when you use QMI.
I think there was something else like wrong APN or something but we will never know I guess...

I meant chatscript+ppp.

OK so you mean PPP. But if it worked with PPP, it should work with QMI also. Especially it also shows that the issue is not roaming etc. as PPP mode would have suffered from the same problem otherwise.

QMI mode connection can also be controlled by AT commands/chatscript. As a matter of fact, I am using my EC-25 with chatscript in QMI mode. Because APN setting did not work properly in OpenWRT.
Here is a whole section explaining that under /dev/cdc-wdm0 does not respond. What do I do?
https://openwrt.org/docs/guide-user/network/wan/wwan/ethernetoverusb_ncm

I simply have DHCP client on my WWAN interface and I control link using my own scripts. This was the best solution for me as APN setting did not work properly with EC-25 when using QMI and I could modify scripts to auto-restart network in case EC-25 froze (and it did every once in a while).