lynxis:

can you try to do:

• ifdown modem
• uqmi -s -d "$device" --wda-get-data-format
• only continue if it's not 802.3
• uqmi -s -d "$device" --set-data-format 802.3
• uqmi -s -d "$device" --wda-set-data-format 802.3
• uqmi -s -d "$device" --wda-get-data-format

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: 1514655177

johnfzc:

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?

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 --autoconnect

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

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:

johnfzc/source@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.

lynxis:

Hi,
I'm planning to review the patch tomorrow. I might also have an EC25.

Best,
lynxis

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

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

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?

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 ..

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.

xback:

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

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?

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.

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

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

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...

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)

yurtesen:

Noob question, how do I do the 'tested-by' thingy?

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":{}}


xback:

Hi,

Is this with the latest master branch?
My fixes got accepted yesterday.

Thanks,

Koen

yurtesen:

Sorry I couldn't respond earlier. I just build the newest build with last commit from march 19 -> commit 8e1065d

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})

xback:

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

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

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'

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:#


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

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.

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**

• 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

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

while true; do
check_connection
if [ $? -ne 0 ]; then
#/etc/init.d/ncm-network start
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 wwan
fi
sleep $SLEEP_MAIN
done

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

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 :(

xback:

@evren,

I currently have some time to take another look at uqmi and the apn issue.
Working on it ..

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.

finas:

@evern, can you share your modified script to test connection and reconnect when connection is lost?

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

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.

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.

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:
- "uqmi -d /dev/cdc-wdm0 –get-current-settings" give IP "B".
- "udhcpc" still attribute IP "A" to the wwan0 interface.
The result is an inoperationnal interface until I restart the interface.
- ubus call network.interface.wwan down / ubus call network.interface.wwan up
- "udhcpc" attribute IP "B" to the wwan0 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.

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?