OpenWrt/LEDE Project

  • Status Assigned
  • Percent Complete
    0%
  • 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
Attached to Project: OpenWrt/LEDE Project
Opened by John Marrett - 02.01.2018

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
  1. – 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
  1. – 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
Project Manager
Alexander Couzens commented on 02.01.2018 16:16

can you try to do:

  1. ifdown modem
  2. uqmi -s -d "$device" –wda-get-data-format
  3. only continue if it's not 802.3
  4. uqmi -s -d "$device" –set-data-format 802.3
  5. uqmi -s -d "$device" –wda-set-data-format 802.3
  6. uqmi -s -d "$device" –wda-get-data-format
John Marrett commented on 02.01.2018 16:27

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
John Marrett commented on 02.01.2018 16:29

It's raw_ip, here's the output:

  root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --wda-get-data-format
  "raw-ip"
Project Manager
Alexander Couzens commented on 02.01.2018 17:06

so you can not change it?

John Marrett commented on 02.01.2018 17:14

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"
John Marrett commented on 04.01.2018 04:04

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

John Marrett commented on 04.01.2018 15:20

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.

Project Manager
Alexander Couzens commented on 09.01.2018 11:38

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

Best,
lynxis

Project Manager
Koen Vandeputte commented on 18.01.2018 11:49

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

Project Manager
Koen Vandeputte commented on 19.01.2018 09:49

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

Evren Yurtesen commented on 24.01.2018 09:03

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?

Project Manager
Koen Vandeputte commented on 24.01.2018 09:27

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

John Marrett commented on 24.01.2018 12:52

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.

Project Manager
Koen Vandeputte commented on 24.01.2018 14:44

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

Evren Yurtesen commented on 25.01.2018 18:31

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?

Project Manager
Koen Vandeputte commented on 07.02.2018 09:27

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

Evren Yurtesen commented on 07.02.2018 12:30

@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

Project Manager
Koen Vandeputte commented on 07.02.2018 13:00

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:

chmod+rwx /lib/netifd/proto/qmi.sh
   qmi.sh (8.7 KiB)
Evren Yurtesen commented on 07.02.2018 22:03

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

Project Manager
Koen Vandeputte commented on 07.02.2018 22:09

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)

Evren Yurtesen commented on 09.02.2018 12:55

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

Evren Yurtesen commented on 14.02.2018 19:50

@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":{}}
Project Manager
Koen Vandeputte commented on 14.02.2018 22:17

Hi,

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

Thanks,

Koen

Evren Yurtesen commented on 24.03.2018 20:57

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})
Project Manager
Koen Vandeputte commented on 26.03.2018 08:01

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

Project Manager
Koen Vandeputte commented on 26.03.2018 12:22

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

   qmi.sh (9.2 KiB)
Evren Yurtesen commented on 26.03.2018 14:59

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:~#
Project Manager
Koen Vandeputte commented on 26.03.2018 15:40

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

Evren Yurtesen commented on 28.03.2018 00:07

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.

Project Manager
Koen Vandeputte commented on 29.03.2018 10:14

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

Evren Yurtesen commented on 03.04.2018 11:04

@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 :)

#!/bin/sh

# Device for AT commands
DEVICE="/dev/ttyUSB2"

# Enter the FQDNs you want to check with ping (space separated)
# Script does nothing if any tries to any FQDN succeeds
FQDN="www.google.com"
FQDN="$FQDN www.amd.com"
FQDN="$FQDN www.juniper.net"

# Sleep between ping checks of a FQDN (seconds between pings)
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
  # If we are here, it means all failed
  return 1
}

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
Project Manager
Koen Vandeputte commented on 03.04.2018 11:14

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

Evren Yurtesen commented on 16.11.2018 02:19

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

Project Manager
Koen Vandeputte commented on 14.12.2018 13:30

@evren,

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

Pedro commented on 01.03.2019 17:36

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.

Pedro commented on 01.03.2019 17:37

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

Dmitry commented on 25.04.2019 21:28

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 commented on 23.05.2019 10:37

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
Evren Yurtesen commented on 05.06.2019 22:26

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing