- Status Assigned
- Percent Complete
- Task Type Bug Report
- Category Base system
-
Assigned To
Alexander Couzens - Operating System All
- Severity Low
- Priority Very Low
- Reported Version Trunk
- Due in Version Undecided
-
Due Date
Undecided
- Private
FS#1252 - No IP Assigned to Interface with QMI on Quectel EC-25A
I’m attempting to use QMI on a GL.Inet MiFi equipped with a Quectel EC-25A cellular modem.
When I configure the interface using qmi I am able to connect to the cellular network at the radio layer, however my wwan0 interface is not assigned an IP address. Here’s my configuration from /etc/config/network:
config interface 'modem' option proto 'qmi' option ifname 'wwan0' option device '/dev/cdc-wdm0' option country 'country11' option apn 'inet.bell.ca'
And some commands showing the device behaviour. You’ll note that raw_ip needs to be set to Y. I’ve integrated this [patch](https://github.com/bmork/LEDE/commit/10aed12fa587e818e4dc5d0db54545623fbe9b5f) to have qmi.sh set the raw_ip mode when required.
root@OpenWrt:~# cat /sys/class/net/wwan0/qmi/raw_ip Y root@OpenWrt:~# ifup modem root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --get-data-status "connected" root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --get-current-settings { "pdp-type": "ipv4", "ip-family": "ipv4", "mtu": 1500, "ipv4": { "ip": "100.105.180.51", "dns1": "206.47.201.246", "dns2": "207.231.231.254", "gateway": "100.105.180.52", "subnet": "255.255.255.248" }, "ipv6": { }, "domain-names": { } } 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 inet6 addr: fe80::d789:480e:bfc8:2dac/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:28 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5129 (5.0 KiB) TX bytes:768 (768.0 B)
If I manually use the uqmi command to connect to the cellular network I can then drive the wwan0 interface using dhcp successfully. Here’s my /etc/config/network.
config interface 'modem' option proto 'dhcp' option ifname 'wwan0'
And the resulting successful network connection:
root@OpenWrt:~# ifup modem 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:100.105.180.51 P-t-P:100.105.180.51 Mask:255.255.255.248 inet6 addr: fe80::d789:480e:bfc8:2dac/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:80 errors:0 dropped:0 overruns:0 frame:0 TX packets:68 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:24102 (23.5 KiB) TX bytes:16842 (16.4 KiB)
root@OpenWrt:~# ping -c 1 google.ca PING google.ca (172.217.1.163): 56 data bytes 64 bytes from 172.217.1.163: seq=0 ttl=51 time=29.792 ms
- – google.ca ping statistics —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 29.792/29.792/29.792 ms
I believe that for some reason the dhcp client isn’t being run on the wwan0 interface by qmi.sh once it’s online but I’m not able to determine how this is supposed to work. I’m eager to address this issue and submit the resulting patches. Please let me know if you can help.
root@OpenWrt:~# ping -c 1 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=54 time=31.805 ms
- – 8.8.8.8 ping statistics —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 31.805/31.805/31.805 ms
can you try to do:
Here's the version information for the lede release I'm running.
It's raw_ip, here's the output:
so you can not change it?
Sorry, I misread the commands, I've tried the set but it doesn't take:
My issue came from the modem being configured to autoconnect. I was able to disable it with the following command (which isn't network specific, and will instead stop all automatic modem connections):
With this disabled the QMI protocol worked as expected and was able to drive the mobile connection.
I wonder if there's a way to detect that the modem is configured to autoconnect and disable or warn when this happens.
You can find more info on this command here:
https://dev.openwrt.org/ticket/16724
My problems were caused by two different issues. My modem does not work if it's not set in raw-ip mode. Additionally, if the modem is not cleanly shut down (e.g. hard power off) when it's powered back on it will remain in autoconnect mode. This will prevent the connection from functioning properly. I've prepared a patch that you can find here:
https://github.com/johnfzc/source/commit/566c6db
This patch addresses both issues, if the modem can't be set to 802.3 format then the interface will be adjusted to use raw-ip mode. It also integrates the –stop-network command required to disable autoconnect.
Hi,
I'm planning to review the patch tomorrow. I might also have an EC25.
Best,
lynxis
Hi,
My patch got merged. [1]
Is this issue still open when using the latest master state?
Please let me know asap.
I'm currently working on a gl-mifi device (ar71xx) improving QMI.
Thanks,
Koen
[1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7488be701029a86259dcd297a3c665eb65bdac6e
Hi,
I just tried on the latest master:
============================Fri Jan 19 09:33:07 2018 daemon.notice netifd: lte (2215): Stopping network lte
Fri Jan 19 09:33:07 2018 daemon.notice netifd: lte_4 (1863): udhcpc: received SIGTERM
Fri Jan 19 09:33:07 2018 daemon.notice netifd: Interface 'lte_4' is now down
Fri Jan 19 09:33:07 2018 daemon.notice netifd: Network alias '' link is down
Fri Jan 19 09:33:07 2018 daemon.notice netifd: Interface 'lte_4' has link connectivity loss
Fri Jan 19 09:33:07 2018 daemon.notice netifd: Interface 'lte_4' is disabled
Fri Jan 19 09:33:07 2018 daemon.warn dnsmasq[1337]: no servers found in /tmp/resolv.conf.auto, will retry
Fri Jan 19 09:33:07 2018 daemon.notice netifd: lte (2215): Command failed: Permission denied
Fri Jan 19 09:33:07 2018 daemon.notice netifd: Interface 'lte' is now down
Fri Jan 19 09:33:07 2018 daemon.notice netifd: Interface 'lte' is setting up now
Fri Jan 19 09:33:08 2018 daemon.notice netifd: lte (2247): "Not supported"
Fri Jan 19 09:33:08 2018 daemon.notice netifd: lte (2247): Device does not support 802.3 mode. Informing driver of raw-ip only for wwan0 ..
Fri Jan 19 09:33:08 2018 daemon.notice netifd: lte (2247): Waiting for network registration
Fri Jan 19 09:33:08 2018 daemon.notice netifd: lte (2247): Starting network lte
Fri Jan 19 09:33:09 2018 daemon.notice netifd: lte (2247): Setting up wwan0
Fri Jan 19 09:33:09 2018 daemon.notice netifd: Interface 'lte' is now up
Fri Jan 19 09:33:09 2018 daemon.notice netifd: Network device 'wwan0' link is up
Fri Jan 19 09:33:09 2018 daemon.notice netifd: Network alias 'wwan0' link is up
Fri Jan 19 09:33:09 2018 daemon.notice netifd: Interface 'lte_4' is enabled
Fri Jan 19 09:33:09 2018 daemon.notice netifd: Interface 'lte_4' has link connectivity
Fri Jan 19 09:33:09 2018 daemon.notice netifd: Interface 'lte_4' is setting up now
Fri Jan 19 09:33:09 2018 daemon.notice netifd: lte_4 (2321): udhcpc: started, v1.27.2
Fri Jan 19 09:33:09 2018 user.notice firewall: Reloading firewall due to ifup of lte (wwan0)
Fri Jan 19 09:33:10 2018 daemon.notice netifd: lte_4 (2321): udhcpc: sending discover
Fri Jan 19 09:33:10 2018 daemon.notice netifd: lte_4 (2321): udhcpc: sending select for 10.253.58.196
Fri Jan 19 09:33:10 2018 daemon.notice netifd: lte_4 (2321): udhcpc: lease of 10.253.58.196 obtained, lease time 7200
Fri Jan 19 09:33:10 2018 daemon.notice netifd: Interface 'lte_4' is now up
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: reading /tmp/resolv.conf.auto
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using local addresses only for domain test
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using local addresses only for domain onion
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using local addresses only for domain localhost
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using local addresses only for domain local
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using local addresses only for domain invalid
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using local addresses only for domain example.net
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using local addresses only for domain example.org
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using local addresses only for domain example.com
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using nameserver 217.72.230.1#53
Fri Jan 19 09:33:10 2018 daemon.info dnsmasq[1337]: using nameserver 217.72.230.129#53
Network Config:
config interface 'lte'
Firewall config:
config zone
Hardware used:
GL.Inet MiFi containing a Quectel EC25-E
This card works for me with latest code if I disable autoconnect with `uqmi -d /dev/cdc-wdm0 –stop-network 4294967295 –autoconnect` using information from "John Marrett commented on 04.01.2018 15:20"
But, out of the box, it did not receive IP address in QMI mode and I spent hours trying to figure out why it didn't work. I think `qmi.sh` should disable autoconnect perhaps?
The strange item is that the command you mention is already present in the script and is being invoked.
(4294967295 = 0xffffffff)
I'll try to have a closer look later this week.
Will keep you posted ..
I noticed that the 0xffffffff was present in the script, however for me it was only effective with the decimal value. In my commit I left both in because I wasn't certain if the 0xffffffff value might work in specific cases.
To test for this issue connect to the cellular network and then unplug your device from power. If you are able to reconnect once power is restored then the stop auto-connect is working properly.
I had considered testing to see if the cellular network showed as connected before forcing the disconnect.
I'll update my patch to remove the fixes included in Koen's and the 0xffffffff stop-network if it's not needed.
Can you do 1 more test please?
- Build the master *without* any modification
- edit /lib/netifd/proto/qmi.sh and replace all 0xffffffff with the decimal value
- re-test
Maybe there is a bug in interpreting the 0xffffffff :)
Thanks,
Koen
I think it is not an issue with 0x hex value. Because I can confirm that `uqmi -d /dev/cdc-wdm0 –stop-network 0xffffffff –autoconnect` does exactly the same and works.
I see this command in several places in qmi.sh but could it be that they are not executed? I am a total noob at this but is it so that qmi.sh is executed by daemon? but /dev/cdc-wdm0 has owner/root read/write access only?
crw——- 1 root root 180, 176 Jan 25 18:09 /dev/cdc-wdm0
Could that be the reason of not seeing the effect?
Hi,
In qmi.sh, add the following line on line 2:
Then start a second terminal window, and execute:
When this is done, bringup the interface:
Here is the full log:
External Link
And here are the uqmi commands filtered out:
In this example it works nicely .. but I see the potential issue in your case.
I'll submit a patch shortly to further improve qmi dial-in.
@Koen Vandeputte , I thought it was working and I see the same log lines. But after I put a different card, it stopped working again. I don't actually know what is the problem right now. I will try to run some more tests and return back.
Also, should script set interface name with _4 because I am having some problems with that. First LuCI doesn't show the IP and then other programs rely on IP being set on interface name fails. → https://bugs.lede-project.org/index.php?do=details&task_id=1304
Hi,
I've just posted a patch series which fixes more qmi issues: External Link
Attached the qmi script which contains these.
Feel free to test it if you like.
Replace the current one, and make sure it's set executable:
It works everytime I start the router. Great work!
Now the only problem is that the IP address does not appear in LuCI and for example DDNS client does not work unless I set the interface name_4 manually in the config (since it is impossible to select this from LuCI). Just a small nuisance...
Thank you for testing.
Feel free to drop a "tested-by" on the patches.
I'll try to have a look at the remaining issues tomorrow .. (no promises)
Noob question, how do I do the 'tested-by' thingy?
@Koen Vandeputte
I found some other problems now. My provider normally gives private IP but if I use APN "opengate" it gives me public IP.
I found out that this does not work with `–autoconnect` setting. (Also maybe related: https://forum.openwrt.org/viewtopic.php?pid=372211 )
I made a separate report for it: https://bugs.lede-project.org/index.php?do=details&task_id=1363
See:
Hi,
Is this with the latest master branch?
My fixes got accepted yesterday.
Thanks,
Koen
Sorry I couldn't respond earlier. I just build the newest build with last commit from march 19 → commit 8e1065d681daff321f715ce5c6c172c12036bd6f
I can see your commits there in the log also. But the APN is NOT working.
I needed to change `–autocnnect` with `–set-autoconnect enabled` then the APN is actually used. Then my APN is used. I don't know what is in internals of `uqmi` command which may be causing this :(
Hi,
Thanks for testing.
I've also spend a few weeks testing this extensively and noticed following:
- Using your idea indeed ensures the correct APN is used every time.
- However, leaving out "autoconnect" results in the link not restoring on first dropout of the LTE network (which can sometimes take up a few days before it occurs)
I'll cook up another QMI script and post it here for you to test.
The idea is to combine both options.
I'll try to do it this week.
Koen
Hi,
Can you test again using attached qmi script please?
Just replace it on your board, make sure it's set executable, and reboot (to be sure).
Thanks,
Koen
No, it does not work as it is. But it works if I remove `${autoconnect:+–autoconnect}` from it.
After reboot (fail, got generic IP):
If I remove `${autoconnect:+–autoconnect}` then reboot again. After reboot:
Hi,
Thanks again for testing.
This finally proves that the issue is not fixable by using other params.
I'll try to check if something can be fixed at all within uqmi to use the proper APN.
Don't expect a reply within a few days, as this is currently a bit out of my scope. :)
Koen
Koen, if uqmi is broken, why can't we remove `–autoconnect` for connection parameters but instead use `–set-autoconnect enabled` as a workaround?
Because that is the change I made and device seem to connect at boot without intervention and get correct IP. I can re-test that but it has been working fine now for a while.
Hi Evren,
An overview of my test setup for this:
I have hardware mounted (LTE + WiFi) in the mast of multiple ships.
These ships sail in/out of port on a very regular base, and they sail far enough to lose the LTE connection at some point.
I've tested your suggestion for a few weeks in the lab, and onboard these vessels in the field.
A few weeks of testing both in the lab and in the field yielded following conclusions:
* Leaving out –autoconnect introduced issues when the vessels sail back in. They never re-connected. Initial dial-in works very good now.
* Replacing –autoconnect with –set-autoconnect introduces the same issues
* Only using –set-autoconnect shows that first dial-in works very good now
* Leaving out both –set-autoconnect and –autoconnect shows that first dial-in works very good now.
## Summarized:
- Leaving out –autoconnect solved APN issues (initial dial-in), but introduced re-connect issues
- Using –set-autoconnect does not seem to provide any additional benefits compared to just leaving out –autoconnect
Using this workaround solves an issue but introduces a more severe one.
I hope this clarifies the situation a bit.
Koen
@Koen , unfortunately I do not have a way to block the signal to test re-connection. I am able to test initial connection. In my card, it works same as you described.
Perhaps it is a bug in either ec25 or uqmi. Hopefully it would be fixed at some point. It would have been easier to test if I somebody who has another hardware which uses QMI could help testing.
By the way, I had a problem after 36 days uptime that QMI would not respond at all anymore. It felt like it was crashed. I had to send `AT+CFUN=0` then `AT+CFUN=1,1` to reboot EC-25.
So I found out that the sure way to fix the issue once for all was to not rely on so called autoconnect. Instead now I use a script to check internet connectivity and do a full reset upon failure. Actually I used to use this script with NCM connection and put it to OpenWRT wiki way back, just had to modify it for purpose...
In case it comes handy, my poor man's solution is here :)
Hi Evren,
Thanks for sharing.
fyi,
I have the issues described above on multiple different LTE-QMI devices, not only on EC25-x.
I'm also hoping to find some time to get a proper look at uqmi and hope the issue can be fixed there .. maybe within a few weeks ..
Thanks,
Koen
@Koen found a better solution? I still think that since the modems seem to be unreliable, it is perhaps best to use an external script to determine interface status and restart accordingly.
I actually found a new problem in my setup. I am using a SIM card which can receive voice calls. Every time I receive a voice call, the SIM reduces network to 3G. (since 4G can't do circuit switching) This is useless because I can't answer the call anyway :)
I found out that I need to execute a command in the modem to disable CS mode.
AT+QCFG="servicedomain",1,1
I am not sure which script to set this with. I put it in /etc/hotplug.d/iface and I run it when interface wwan goes up. It resets at every restart and I could not manage to get modem to store it permantenly :(
@evren,
I currently have some time to take another look at uqmi and the apn issue.
Working on it ..
man, can't believe how much time I spent dealing with this.
Exactly the same issue. MiFi with EC-25 and EC-60. APN is not set and I get a private IP address.
I am now using this in "3g" mode using luci instead of qmi.
@evern, can you share your modified script to test connection and reconnect when connection is lost?
Seems to be that i have same issue with EG25 modem (same as EC25), internet did not works in LAN (DNS did not resolve and IPs can't ping), but in SSH command line of OpenWRT i can access internet (ping 8.8.8.8, even opkg update works and i can install all packages). Can't resolve this issue...
update
it was issue with SIM card of LTE Vodafone, changing it to another LTE operator is resolve my issue.
update2
but with new SIM got another troubles, after some time of work seems that qmi of system did not refresh IP from modem, for one time commands query:
root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 –get-current-settings {
}
but "ifconfig wwan0" showing IP 10.95.107.241:
DHCP lease can't update automatically by system, need to make "service network restart" to get "fresh" IP (10.81.148.43) from QMI/modem:
Dmitry
I faced the same problem, I have a Sierra Wireless AirPrime MC7455 modem.
Wrote the script which checks compliance of IP addresses, at discrepancy there is a reboot of the modem.
The script placed the tasks in cron, it runs every minute.
one line:
@Pedro the script I use is just above. Recently I added the following line only
Because my SIM card is clone of my normal card and when my phone rings the EC-25 switch to 3G and stay. With this line, it rejects all voice calls.
I made copy of the qmi.sh script and well I am not updating the router! That is it, this issue is quite annoying.
In addition I found out EC-25 just freezes when it is under load for half a minute every few minutes. I don't know if it effects you guys too. My AT+GMR command returns EC25EFAR02A08M4G
I just ordered a ME909s-120 for hopefully replacing EC-25. I had much less problems when I used NCM earlier. It seems to work so much smoother!
Update: While NCM works great with my USB stick. It has a small problem with ME909s-120
https://bugs.openwrt.org/index.php?do=details&task_id=1424 Which is fixed by editing the usb-mode.json file...
I just switched the card and perhaps it was for good to depart from EC-25.
Now I used ME909s-120 for few days and no problems whatsoever. The best part is that I had problems with EC-25 when there was high bandwidth upload/download going on. With ME909s, no problems and it even feels faster. It is possible that EC-25 I had was working badly more than the visible problems.
The problem with missing IP address for EC-25 Modems is also present for other QMI (Rmnet) raw-IP modems. This is the case for 18.06 as well as 19.07 versions of openwrt.
It seems to be sporadic and you may sometimes obtain the IP.
It seems that although qmi.sh tries to set the correct mode (at least in 19.07.03) it either detects incorrectly or there is a permission or timing issue.
If however you add the setting of the driver attribute during local startup (in rc.local) it will work:
echo "Y" > /sys/class/net/$ifname/qmi/raw_ip (replace $ifname with the actual if name. Look it up on your router)
This work around has been tested with MC7455, EM7455 (defaults to MBIM, you must set QMI mode by AT command), SIM7600E-H, SIM7612G and EC25-E with openwrt 17.06.03 on a ZBT-WE826 router.
for 802.3 IP modems (eg. MC7304, SIM7100E) it seems to work, but you may add:
echo "N" > /sys/class/net/$ifname/qmi/raw_ip
Be aware that on some devices the SIM slot is not initialized on hotplug. You need to power off/on.
I have exactly the same problem as @Dmitry: IP refresh every 12 hours.
Every 12 hours my ISP (Free_Mobile a French provider) change the IP of the interface and the DHCP-Client still get the old IP Address even if "uqmi -d /dev/cdc-wdm0 –get-current-settings" give me the new valid ip address. It's reproductible as every 12 hours the bug occur.
Every 12 hours:
The result is an inoperationnal interface until I restart the interface.
I don't know if it's a bug in the firmware of the modem or a problem within OpenWRT.
The script provided by @Frans is a workaround but fixing the issue would be way better.
I can provide more details if needed and this problem happen with my two 4G routers one with EC-25 and another one with BroadMobi BM806.