Open aparcar opened 6 years ago
aparcar
commented
6 years ago lynxis:
can you try to do:
aparcar
commented
6 years ago johnfzc:
Here's the version information for the lede release I'm running.
root@OpenWrt:~# cat /etc/openwrt_release ; opkg info uqmi
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r5644-3267ce7'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r5644-3267ce7'
DISTRIB_TAINTS='no-all'
Package: uqmi
Version: 2016-12-19-8ceeab69-1
Depends: libc, libubox, libblobmsg-json, kmod-usb-net, kmod-usb-net-qmi-wwan, wwan
Status: install user installed
Architecture: mips_24kc
Installed-Time: 1514655177johnfzc:
It's raw_ip, here's the output:
root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --wda-get-data-format
"raw-ip"lynxis:
so you can not change it?
aparcar
commented
6 years ago johnfzc:
Sorry, I misread the commands, I've tried the set but it doesn't take:
root@OpenWrt:~# uqmi -s -d /dev/cdc-wdm0 set-data-format 802.3
root@OpenWrt:~# uqmi -s -d /dev/cdc-wdm0 wda-set-data-format 802.3
root@OpenWrt:~# uqmi -s -d /dev/cdc-wdm0 wda-get-data-format
root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --wda-get-data-format
"raw-ip"johnfzc:
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):
uqmi -d /dev/cdc-wdm0 --stop-network 4294967295 --autoconnectWith 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:
aparcar
commented
6 years ago johnfzc:
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.
aparcar
commented
6 years ago lynxis:
Hi, I'm planning to review the patch tomorrow. I might also have an EC25.
Best, lynxis
aparcar
commented
6 years ago xback:
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
aparcar
commented
6 years ago xback:
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' option proto 'qmi' option device '/dev/cdc-wdm0' option apn 'apn.nextel.be' option pincode '1111' option auth 'none'
Firewall config:
config zone option name 'wan' option input 'REJECT' option output 'ACCEPT' option forward 'REJECT' option masq '1' option mtu_fix '1' option network 'wan wan6 lte'
Hardware used: GL.Inet MiFi containing a Quectel EC25-E
aparcar
commented
6 years ago yurtesen:
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?
aparcar
commented
6 years ago xback:
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 ..
aparcar
commented
6 years ago johnfzc:
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.
aparcar
commented
6 years ago xback:
Can you do 1 more test please?
Maybe there is a bug in interpreting the 0xffffffff :)
Thanks,
Koen
aparcar
commented
6 years ago yurtesen:
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?
aparcar
commented
6 years ago xback:
Hi,
In qmi.sh, add the following line on line 2:
set -x
Then start a second terminal window, and execute:
logread -f
When this is done, bringup the interface:
ifup name
Here is the full log: [[https://pastebin.com/raw/BMM4AsAx|External Link]]
And here are the uqmi commands filtered out:
Wed Feb 7 09:06:36 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --get-pin-status
Wed Feb 7 09:06:37 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --verify-pin1 8267
Wed Feb 7 09:06:37 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --uim-verify-pin1 8267
Wed Feb 7 09:06:37 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --set-data-format 802.3
Wed Feb 7 09:06:37 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --wda-set-data-format 802.3
Wed Feb 7 09:06:37 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --wda-get-data-format
Wed Feb 7 09:06:37 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --sync
Wed Feb 7 09:06:37 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --get-serving-system
Wed Feb 7 09:06:38 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --get-client-id wds
Wed Feb 7 09:06:38 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,18 --set-ip-family ipv4
Wed Feb 7 09:06:38 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,18 --stop-network 0xffffffff --autoconnect
Wed Feb 7 09:06:38 2018 daemon.notice netifd: lte (5500): + uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,18 --start-network --apn internet.proximus.be --autoconnect
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.
aparcar
commented
6 years ago yurtesen:
@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
aparcar
commented
6 years ago xback:
Hi,
I've just posted a patch series which fixes more qmi issues: [[http://patchwork.ozlabs.org/project/lede/list/?series=27352|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:
chmod+rwx /lib/netifd/proto/qmi.sh
aparcar
commented
6 years ago yurtesen:
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...
aparcar
commented
6 years ago xback:
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)
aparcar
commented
6 years ago yurtesen:
Noob question, how do I do the 'tested-by' thingy?
aparcar
commented
6 years ago yurtesen:
@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:
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --stop-network 0xffffffff --autoconnect
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
"Out of call"
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate --autoconnect
-2020095904
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
{"pdp-type":"ipv4","ip-family":"ipv4","mtu":1500,"ipv4":{"ip":"100.69.24.116","dns1":"192.89.123.230","dns2":"192.89.123.231","gateway":"100.69.24.117","subnet":"255.255.255.248"},"ipv6":{},"domain-names":{}}
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --stop-network 0xffffffff --autoconnect
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
"Out of call"
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate
-2020095904
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
{"pdp-type":"ipv4","ip-family":"ipv4","mtu":1500,"ipv4":{"ip":"46.132.191.50","dns1":"192.89.123.230","dns2":"192.89.123.231","gateway":"46.132.191.49","subnet":"255.255.255.252"},"ipv6":{},"domain-names":{}}
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --stop-network 0xffffffff --autoconnect
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
"Out of call"
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --set-client-id wds,19 --start-network --apn opengate --set-autoconnect enabled
-2020095904
root@OpenWrt:/# uqmi -s -d /dev/cdc-wdm0 --get-current-settings
{"pdp-type":"ipv4","ip-family":"ipv4","mtu":1500,"ipv4":{"ip":"194.251.18.231","dns1":"192.89.123.230","dns2":"192.89.123.231","gateway":"194.251.18.232","subnet":"255.255.255.240"},"ipv6":{},"domain-names":{}}
aparcar
commented
6 years ago xback:
Hi,
Is this with the latest master branch? My fixes got accepted yesterday.
Thanks,
Koen
aparcar
commented
6 years ago yurtesen:
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 :(
158c158
< ${autoconnect:+--autoconnect})${autoconnect:+--set-autoconnect enabled})195c195 < ${autoconnect:+--autoconnect})
${autoconnect:+--set-autoconnect enabled})
aparcar
commented
6 years ago xback:
Hi,
Thanks for testing.
I've also spend a few weeks testing this extensively and noticed following:
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
aparcar
commented
6 years ago xback:
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
aparcar
commented
6 years ago yurtesen:
No, it does not work as it is. But it works if I remove ${autoconnect:+--autoconnect} from it.
root@OpenWrt:~# wget https://bugs.openwrt.org/index.php?getfile=458
--2018-03-26 14:46:47-- https://bugs.openwrt.org/index.php?getfile=458
Resolving bugs.openwrt.org... 148.251.78.235, 2a01:4f8:202:43ea::3
Connecting to bugs.openwrt.org|148.251.78.235|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9433 (9.2K) [text/x-shellscript]
Saving to: 'index.php?getfile=458'
index.php?getfile=458 100%[========================================================================================================================================>] 9.21K --.-KB/s in 0.04s
2018-03-26 14:46:49 (240 KB/s) - 'index.php?getfile=458' saved [9433/9433]
root@OpenWrt:~# mv index.php?getfile\=458 qmi.sh.koen root@OpenWrt:~# cp qmi.sh.koen /lib/netifd/proto/qmi.sh root@OpenWrt:~# chmod 775 /lib/netifd/proto/qmi.sh root@OpenWrt:~# ls -al /lib/netifd/proto/qmi.sh -rwxrwxr-x 1 root root 9433 Mar 26 14:47 /lib/netifd/proto/qmi.sh root@OpenWrt:~#
After reboot (fail, got generic IP):
root@OpenWrt:~# ifconfig wwan0 |grep 'inet addr'
inet addr:10.37.39.186 P-t-P:10.37.39.186 Mask:255.255.255.252
root@OpenWrt:~#
If I remove ${autoconnect:+--autoconnect} then reboot again. After reboot:
root@OpenWrt:~# ifconfig wwan0 |grep 'inet addr'
inet addr:46.132.189.90 P-t-P:46.132.189.90 Mask:255.255.255.252
root@OpenWrt:~#
aparcar
commented
6 years ago xback:
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
aparcar
commented
6 years ago yurtesen:
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.
aparcar
commented
6 years ago xback:
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
Using this workaround solves an issue but introduces a more severe one.
I hope this clarifies the situation a bit.
Koen
aparcar
commented
6 years ago yurtesen:
@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 [[https://wiki.openwrt.org/doc/recipes/ethernetoverusb_ncm#troubleshooting|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 :)
#!/bin/sh
DEVICE="/dev/ttyUSB2"
FQDN="www.google.com" FQDN="$FQDN www.amd.com" FQDN="$FQDN www.juniper.net"
SLEEP=3 # Sleep time between each retry RETRY=3 # Retry each FQDN $RETRY times SLEEP_MAIN=300 # Main loop sleep time in seconds
check_connection() { for NAME in $FQDN; do for i in $(seq 1 $RETRY); do ping -c 1 $NAME > /dev/null 2>&1 if [ $? -eq 0 ]; then return 0 fi sleep $SLEEP done done
return 1 }
while true; do check_connection if [ $? -ne 0 ]; then
logger conncheck.sh: Restarting EC-25
ifdown wwan
echo -ne "AT+CFUN=0\r\n" > ${DEVICE}
echo -ne "AT+CFUN=1,1\r\n" > ${DEVICE}
# Reset takes about 30 sec on Quectel EC-25
sleep 60
ifup wwanfi sleep $SLEEP_MAIN done
aparcar
commented
6 years ago xback:
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
aparcar
commented
5 years ago yurtesen:
@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 :(
aparcar
commented
5 years ago xback:
@evren,
I currently have some time to take another look at uqmi and the apn issue. Working on it ..
aparcar
commented
5 years ago finas:
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.
aparcar
commented
5 years ago finas:
@evern, can you share your modified script to test connection and reconnect when connection is lost?
aparcar
commented
5 years ago Gektor:
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 { "pdp-type": "ipv4", "ip-family": "ipv4", "mtu": 1500, "ipv4": { "ip": "10.81.148.43", "dns1": "193.41.60.16", "dns2": "193.41.60.15", "gateway": "10.81.148.44", "subnet": "255.255.255.248" }, "ipv6": { }, "domain-names": { } } but "ifconfig wwan0" showing IP 10.95.107.241:
inet addr:10.95.107.241 P-t-P:10.95.107.241 Mask:255.255.255.252
inet6 addr: fe80::e1b3:e56d:de16:ba57/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:54582 errors:0 dropped:0 overruns:0 frame:0
TX packets:64104 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:46222544 (44.0 MiB) TX bytes:60349584 (57.5 MiB)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:
inet addr:10.81.148.43 P-t-P:10.81.148.43 Mask:255.255.255.248
inet6 addr: fe80::e1b3:e56d:de16:ba57/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:54584 errors:0 dropped:0 overruns:0 frame:0
TX packets:64112 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:46223174 (44.0 MiB) TX bytes:60351028 (57.5 MiB)Frans:
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:
[ $(uqmi -d /dev/cdc-wdm0 --get-current-settings | grep -om1 "[0-9]+.[0-9]+.[0-9]+.[0-9]+") = $(ip a s wwan0 | sed -n 's/.inet (.)\/./\1/p') ] || echo -e "at!reset" > /dev/ttyUSB2
aparcar
commented
5 years ago yurtesen:
@Pedro the script I use is just above. Recently I added the following line only
echo -ne "AT+QCFG=\"servicedomain\",1,1\r\n" > ${DEVICE}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.
aparcar
commented
4 years ago Frankedinven01:
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.
aparcar
commented
3 years ago bgiboudeau:
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:
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.
aparcar
commented
2 years ago Joshun:
I am having this issue too with Quectel EC20. Interestingly, in Quectel's official connection manager, they seem to periodically check if the QMI IP address has changed, and if so they reconnect:
https://github.com/kmilo17pet/quectel-cm/blob/2c623ffc8a1a8a7054b695956eb343e37b04727b/main.c#L487
I wonder if this is to work around a bug in modem firmware, or perhaps a quirk with how IP addresses are allocated on certain mobile networks?
johnfzc:
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:
And some commands showing the device behaviour. You'll note that raw_ip needs to be set to Y. I've integrated this patch to have qmi.sh set the raw_ip mode when required.
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.
And the resulting successful network connection:
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.