Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#1252 - No IP Assigned to Interface with QMI on Quectel EC-25A #6196

Open
openwrt-bot opened this issue Jan 2, 2018 · 42 comments
Open

FS#1252 - No IP Assigned to Interface with QMI on Quectel EC-25A #6196

openwrt-bot opened this issue Jan 2, 2018 · 42 comments
Labels

Comments

@openwrt-bot
Copy link

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:

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 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
@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

johnfzc:

It's raw_ip, here's the output:

root@OpenWrt:~# uqmi -d /dev/cdc-wdm0 --wda-get-data-format
"raw-ip"

@openwrt-bot
Copy link
Author

lynxis:

so you can not change it?

@openwrt-bot
Copy link
Author

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"

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

lynxis:

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

Best,
lynxis

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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?

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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?

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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)

@openwrt-bot
Copy link
Author

yurtesen:

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

xback:

Hi,

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

Thanks,

Koen

@openwrt-bot
Copy link
Author

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

                  ${autoconnect:+--set-autoconnect enabled})

195c195
< ${autoconnect:+--autoconnect})

                  ${autoconnect:+--set-autoconnect enabled})

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

xback:

@evren,

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

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

finas:

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

@openwrt-bot
Copy link
Author

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)

@openwrt-bot
Copy link
Author

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

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant