EG25 LTE via Luci/qmi - traffic only after 1min

Hi,
I've got a working setup of an EG25 LTE USB stick on RasPi 3B+ HW and
OpenWrt 22.03.4 r20123-38ccc47687.

QMI WAN interface is configured via LUCI and is working well.....but traffic is possible only after around 1:10 - 1:30 additional minutes.

During startup USB device is recognized correctly after 14secs:

...
[   14.709680] usb 1-1.4: new high-speed USB device number 4 using dwc_otg
[   14.859665] usb 1-1.4: New USB device found, idVendor=2c7c, idProduct=0125, bcdDevice= 3.18
[   14.873688] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   14.886513] usb 1-1.4: Product: EG25-G
[   14.895568] usb 1-1.4: Manufacturer: Quectel
[   14.906061] option 1-1.4:1.0: GSM modem (1-port) converter detected
[   14.916996] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB0
[   14.928388] option 1-1.4:1.1: GSM modem (1-port) converter detected
[   14.939394] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB1
[   14.951057] option 1-1.4:1.2: GSM modem (1-port) converter detected
[   14.961954] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB2
[   14.974389] option 1-1.4:1.3: GSM modem (1-port) converter detected
[   14.985626] usb 1-1.4: GSM modem (1-port) converter now attached to ttyUSB3
[   14.997916] qmi_wwan 1-1.4:1.4: cdc-wdm0: USB WDM device
[   15.008348] qmi_wwan 1-1.4:1.4 wwan0: register 'qmi_wwan' at usb-3f980000.usb-1.4, WWAN/QMI device, b2:0b:31:ae:4c:86

Connection is set up:

> Wed Aug  9 17:04:26 2023 daemon.notice netifd: Interface 'qmi' is now up
> Wed Aug  9 17:04:26 2023 daemon.notice netifd: Network device 'wwan0' link is up
> Wed Aug  9 17:04:26 2023 daemon.notice netifd: Network alias 'wwan0' link is up
> Wed Aug  9 17:04:26 2023 daemon.notice netifd: Interface 'qmi_4' is enabled
> Wed Aug  9 17:04:26 2023 daemon.notice netifd: Interface 'qmi_4' has link connectivity
> Wed Aug  9 17:04:26 2023 daemon.notice netifd: Interface 'qmi_4' is setting up now
> Wed Aug  9 17:04:26 2023 daemon.notice netifd: qmi_4 (5958): udhcpc: started, v1.35.0
> Wed Aug  9 17:04:26 2023 user.notice firewall: Reloading firewall due to ifup of qmi (wwan0)
> Wed Aug  9 17:04:26 2023 daemon.notice netifd: qmi_4 (5958): udhcpc: broadcasting discover
> Wed Aug  9 17:04:27 2023 daemon.notice netifd: qmi_4 (5958): udhcpc: broadcasting select for 10.210.210.50, server 10.210.210.49
> Wed Aug  9 17:04:27 2023 daemon.notice netifd: qmi_4 (5958): udhcpc: lease of 10.210.210.50 obtained from 10.210.210.49, lease time 7200
> Wed Aug  9 17:04:27 2023 daemon.notice netifd: Interface 'qmi_4' is now up
> Wed Aug  9 17:04:27 2023 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
> Wed Aug  9 17:04:27 2023 daemon.info dnsmasq[1]: using nameserver 192.168.0.1#53
> Wed Aug  9 17:04:27 2023 daemon.info dnsmasq[1]: using nameserver 100.127.0.53#53
> Wed Aug  9 17:04:27 2023 daemon.info dnsmasq[1]: using nameserver 100.127.1.53#53
> Wed Aug  9 17:04:27 2023 daemon.info dnsmasq[1]: using only locally-known addresses for lan
> Wed Aug  9 17:04:27 2023 user.notice firewall: Reloading firewall due to ifup of qmi_4 (wwan0)
> Wed Aug  9 17:05:09 2023 kern.info kernel: [   65.359721] device wwan0 entered promiscuous mode

Interface is up and running and has an IP:

wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.210.210.50  P-t-P:10.210.210.50  Mask:255.255.255.252
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1436  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:630 (630.0 B)  TX bytes:732 (732.0 B)

I see the device gets online in the provider portal.

I start a ping to a dedicated ping server of the provider (masking the IP below):

PING pong.provider.com (1xx.1xx.1xx.1xx): 56 data bytes

But get no reply for around 1:10 to 1:30min.

In tcpdump I see many outgoing ping requests, but no replies:

17:10:22.414692 IP 10.210.210.50 >.....
...
17:11:05.421652 IP 10.210.210.50 > 1xx.1xx.1xx.1xx: ICMP echo request, id 6623, seq 47, length 64
17:11:06.421797 IP 10.210.210.50 > 1xx.1xx.1xx.1xx: ICMP echo request, id 6623, seq 48, length 64
17:11:07.421946 IP 10.210.210.50 > 1xx.1xx.1xx.1xx: ICMP echo request, id 6623, seq 49, length 64
17:11:08.422159 IP 10.210.210.50 > 1xx.1xx.1xx.1xx: ICMP echo request, id 6623, seq 50, length 64
...

Then suddenly the first replies come though:

....
17:11:43.425408 IP  1xx.1xx.1xx.1xx > 10.210.210.50: ICMP echo reply, id 6623, seq 0, length 64
17:11:43.427886 IP 10.210.210.50 >  1xx.1xx.1xx.1xx: ICMP echo request, id 6623, seq 85, length 64
17:11:43.762248 IP  1xx.1xx.1xx.1xx > 10.210.210.50: ICMP echo reply, id 6623, seq 1, length 64
....

In System log I only see dnsmasq deamon infos during that time.

In the provider console I can see that there is a close of the former 1st session and a new session setup with same IP etc. which is finally the working one.

I do not see any indication on openWRT side about a new session setup or a renewal.

WWAN - IF does not show dropped packets or similar:

wwan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.210.210.50  P-t-P:10.210.210.50  Mask:255.255.255.252
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1436  Metric:1
          RX packets:52 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4920 (4.8 KiB)  TX bytes:7334 (7.1 KiB)

For me this looks like a a timer runs out of one of the involved network agents....like maybe DNS?

Using the same USB LTE device on other distribution works right away. No 'waiting time'.

Any idea what this could be related to?

you, not being able to wait for 90 sec ?

Are you using httpdns proxy or something as a up stream resolver ?

disable that and see if it comes up straight away, I don't think it responds to hotplug events there was recent patches to help here.

Try 'ping 8.8.8.8' . To check, if it is a DNS issue, in case this ping is immediately replied to.

hi prof_jonny

nothing is setup like this what I know.
The whole setup is quite basic with standad settings. DNS is received during LTE attach procedure and is correctly used.
THX for your suggestion

hi reinerotto

same result for 8.8.8.8.

@frollic - I thoought this is a tech forum only but now getting a psychoanalysis as well - thx

1 Like

Is there a valid route after getting the IP on wwan0 ?
(route) ?
Which mobile carrier do you use ?
My suspicion besides the notes above is the firewall.
Unfortunately, with openwrt-firewall I can not help, although running 100+ devices with Quectel EC25, but using plain iptables rules only.
I am wondering about Interface 'qmi' and 'qmi_4' Why/How 2 qmi-interfaces ?
(IPv4 and IPv6 ?)

1 Like

They are dynamically created one for ipv4 and one for ipv6 it is normal for some mobile connections.

have you tried an IPv6 DNS ?

2001:4860:4860::8844
2001:4860:4860::8888

IPv6 is disabled completely as the connection supports ipV4 only.

The second QMI interface seems to be an openWRT thing...it pops up as virtual interface as soon as WAN connection is set up.

I did some further tracing....I did set up QCSuper to get layer3 device trace.
During the related time I see only incoming pagings.
It does not like a single packets is leaving the WAN adapter which more and more is pointing to maybe the firewall.

I also have IPv4 only, but not this strange qmi_4.
How did you disable IPv6 ?
You can disable firewall completely, and use simple iptables rules (NAT !)
You might provide /etc/config/network

@reinerotto
I think these are mostly the steps to disable IPv6:

> uci set 'network.lan.ipv6=0'
> uci set 'network.wan.ipv6=0'
> uci set 'dhcp.lan.dhcpv6=disabled'
> /etc/init.d/odhcpd disable
> uci commit
> uci -q delete dhcp.lan.dhcpv6
> uci -q delete dhcp.lan.ra
> uci commit dhcp
> /etc/init.d/odhcpd restart
> uci set network.lan.delegate="0"
> uci commit network
> /etc/init.d/network restart
> /etc/init.d/odhcpd disable
> /etc/init.d/odhcpd stop
> uci -q delete network.globals.ula_prefix
> uci commit network
> /etc/init.d/network restart
  • deselecting some more entries in the lucy UI which are related to IPv6.

I will try to disable the FW.

this qmi_4 IF is mentioned in this guide as well...

I finally got it working after adding the following line in the /lib/netifd/proto/qmi.sh script (IPv4 section only in my case):

...
uqmi -s -d "$device" --set-client-id wds,"$cid_4" --set-ip-family ipv4 > /dev/null 2>&1
add>> uqmi -s -d "$device" --set-client-id wds,"$cid_4" --set-network-roaming any > /dev/null 2>&1
v4s=0
...

With that setting QMI on the Raspberry Pi is able to ping my backend via cellular LTE in around 25secs after startup.
So the possibility to enable roaming is somehow missing which prevented communication. Why it finally worked after these1.5-2min with a new session I could not find out.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.