Mudi 7 (GL-E5800) Cellular WAN (modem_cpu) does not recover after carrier idle-deactivation

taus · June 6, 2026, 8:11am

Device: GL.iNet Mudi 7 (GL-E5800)
Firmware: 4.8.5 (OpenWrt 23.05.4, kernel 5.15.170-perf)
Modem: Quectel RG650V-EU
Network: eSIM (eiotclub platform), roaming on MCC/MNC 283/05 (Viva-MTS, Armenia), LTE, signal "Excellent"
Diagnosis method: SSH logread over USB-RNDIS (stable, independent of Wi-Fi)

SUMMARY

With cellular as the WAN, the data session drops after a period of inactivity and the modem does NOT re-establish it. The UI stays on "Connecting…" indefinitely until a manual action (re-applying the APN, Abort, or reboot). Observed and logged repeatedly over several hours. APN
"plus" is correct and connects fine — this is a recovery problem, not a setup problem.

OBSERVED FACTS

A. The carrier deactivates the idle data session — seen with two different call-end codes.

Occurrence 1:
Diag_Lib (cm.c) wwan handle:1 (CallendType=3 CallendCode=1034) wwan_status:0x6
kernel: Deleting wan Conntrack IP:
root: stop rmnet cfg:modem_cpu
hotplug-iface ACTION=ifdown INTERFACE=modem_cpu DEVICE=rmnet_data0

Occurrence 2 (different code; session had been up ~16 min with little/no traffic):
Diag_Lib (cm.c) wwan handle:1 (CallendType=6 CallendCode=36) wwan_status:0x6
kernel: Deleting wan Conntrack IP:
gl-repeater: interface modem_cpu down
root: stop rmnet cfg:modem_cpu

B. No automatic re-dial follows.

After teardown, the connection manager makes no attempt to re-establish the cellular data call. Confirmed by disconnecting the only other backhaul (Wi-Fi repeater) while cellular was down — the router was left with no WAN and still made no redial attempt:
combine_backhaul_ipv4ipv6 ... ipv4_bh=no ... loop on modem_cpu
switch_backhaul ... current_bh:wwan; previous_bh:; new_bh: (empty — no modem_cpu)

In one instance the cellular session stayed down with no recovery attempt for ~50 minutes (until manual intervention).

C. Recovery only happens on a config change.

Re-applying the APN triggers a fresh dial that succeeds:
Diag_Lib (cm.c) dial connect, initiated by CONFIG CHANGE (bus: cpu, slot: 2, interface: modem_cpu)
Diag_Lib (cm.c) Dial success with APN: plus ctx_ipv4:
QCMAP:WAN connected v4 ... CallendCode=0 wwan_status:0x3

D. kmwan tracks cellular and the repeater differently.

Wi-Fi repeater (never observed to drop) is tracked "force":
kmwan op:2 cells:[{ interface:"wwan", track_mode:"force", tracks:[ping 1.1.1.1, 8.8.8.8, 208.67.222.222, 208.67.220.220] }]

Cellular (the one that drops on idle) is tracked "passive":
kmwan op:2 cells:[{ interface:"modem_cpu", track_mode:"passive", tracks:[ping 1.1.1.1, 8.8.8.8, 208.67.222.222, 208.67.220.220] }]

E. IPv4&IPv6 dial -IPv6 leg rejected.

During the dial (IP type IPv4&IPv6), right after the IPv4 context connects:
Diag_Lib (cm.c) wwan handle:1 (CallendType=2 CallendCode=210) wwan_status:0x8

STEPS TO REPRODUCE

Use a SIM/eSIM on a roaming network that deactivates idle PDP sessions.
Make cellular the active WAN; leave it idle (no client traffic) through the carrier's inactivity window.
The carrier deactivates the session; the UI shows "Connecting…" and does not recover until a manual config change/reboot.

IMPACT

On a trip where cellular is the only WAN, any idle-induced drop results in a full loss of connectivity until manual intervention.

ENVIRONMENT NOTES (also seen in logs, possibly relevant)

During backhaul teardown: "sh[...]: unable to attach the filter ... : Out of memory" (repeated).
A dial attempt made with a wrong APN failed with "Failed to get cell info (retry 1/30 … 30/30)" then "dial allowed[No] reason[Failed to get cell info]"; the subsequent dial with the correct APN succeeded.

NOTE ON REDACTION

Logs were redacted before posting - IMEI, ICCID, assigned IPs, cell IDs (CID/TAC/LAC), MAC addresses and Wi-Fi SSID removed. Full SSH logread excerpts and a gl_modem capture can be provided on request.

taus · June 6, 2026, 8:51am

taus · June 6, 2026, 3:11pm

Additional diagnostics captured at the modem level via the Web UI (INTERNET > Cellular > Modem AT Command).

Modem state DURING the failure (UI showing "Connecting", Viva, LTE, signal Excellent):

AT+CGACT?
+CGACT: 1,0 (data context, APN "plus" - DEACTIVATED)
+CGACT: 2,1 (IMS context - still active)
+CGACT: 3,0 (sos - inactive)
AT+CEREG? -> +CEREG: 0,5 (registered, roaming)
AT+COPS? -> +COPS: 0,0,"Viva",7 (Viva, AcT 7 = E-UTRAN / LTE)

For comparison, while the session is up the same query returns +CGACT: 1,1 and +CGACT: 2,1. So at the moment of failure the modem is still registered on the network (CEREG 5), with the IMS context still active, but the data PDP context (1) is deactivated and is not
re-established. This rules out signal, registration, APN and operator as the cause. The only thing missing is the data bearer, and the modem does not redial it.

Does outgoing traffic trigger a redial? No.

I tested this cleanly: cellular as the only WAN (Wi-Fi repeater disabled, management over USB-RNDIS so the test survives the radio change), with a continuous ping running on the client (ping -t 8.8.8.8). The moment the repeater was disabled, every packet was "Request timed
out", and the ping kept generating traffic toward the cellular interface continuously. The data context did not come back (AT+CGACT? stayed 1,0). So the device does not bring the data session back up on demand when traffic is present.

Recovery behaviour is inconsistent. Sometimes the data context re-activates on its own after about a minute, sometimes it stays down for 10+ minutes, and sometimes it only recovers after a manual action (Abort, re-applying the APN, or reboot). There is no reliable automatic
re-dial after the network deactivates the idle session.

taus · June 6, 2026, 3:12pm

Update: I asked my eSIM provider (GlobalYO) whether they apply an inactivity/idle timeout. Their answer (ticket reply, quoted):

"Our Global YO eSIMs do not have a specific inactivity timeout configured by us. However, data session management is handled by our roaming partners and the local network operators in each country... If a network closes an idle data session, the device should normally reconnect
automatically once new data traffic is generated."

So the carrier-side idle deactivation appears to be normal, network-managed behavior, and the expectation is that the device re-establishes the data session when new traffic is generated.

On the Mudi 7 this does not happen. After the carrier deactivates the idle session, the modem does not re-dial even when client traffic resumes. It stays on "Connecting…" until a manual config change (re-applying the APN), Abort, or reboot, as detailed in the logs above. This
looks like the device is not detecting the lost PDP context and not triggering an on-demand re-dial.

Network: roaming, LTE, signal Excellent.

fab · June 8, 2026, 7:30pm

I think this is also my issue, good catch. Hope it will be fixed as today mudi 7 is not rock solid today on my side also.

taus · June 10, 2026, 3:43am

Thanks fab for confirming you hit the same problem. That makes it two of us now, so it does not look like an isolated setup issue.

Could someone from the GL.iNet team take a look at this one? The diagnostics above narrow it down to a router-side behavior: after the carrier deactivates the idle data session, the modem stays registered (CEREG 0,5, IMS context up, LTE), but the data PDP context is not re-dialed, and new traffic does not trigger a redial either. The eSIM provider considers the idle teardown normal and expects the device to reconnect on its own.

Happy to share anything else that is still in the logs. Is this something that can be addressed in firmware, or is there a recommended setting in the meantime?

Cathy · June 10, 2026, 4:29am

Hello

Thanks for the feedback and sharing the detailed information. We are currently investigating this issue.

Cathy · June 10, 2026, 6:17am

Hi @taus for your situation, I've sent you a test ipk, please check the email.

Cathy · June 10, 2026, 6:24am

Hello,

Are you also experiencing problems where the network fails to reconnect after a disconnection? The reasons for network dropouts may vary. I recommend to try the following steps first to see if it helps:

Go to the admin panel ->INTERNET ->Cellular, edit SIM Card Setting and change TTL to 64
disable SMS by running the following AT command on the Modem AT Command page:

AT+QCFG="IMS",2
AT+CFUN=1,1

taus · June 10, 2026, 8:39am

Thanks Cathy. Yes, that is exactly the problem: after the carrier disconnects the idle data session the modem stays registered, but the data context is not re-dialed, so the WAN never comes back on its own.

I installed the test build you sent (gl-sdk4-cellular git-2026.156.24582). I deliberately left TTL at default and did not disable IMS yet, so I could see what the ipk does on its own.

To trigger the failure on demand I forced the data context down on the modem with AT+CGACT=0,1, keeping the Wi-Fi repeater as primary so management stayed up. With the test build the router now re-establishes the data call by itself. The log shows a recovery step that was not there before:

dial connect, initiated by INTERFACE OFFLINE (interface: modem_cpu)
Dial success with APN: plus
QCMAP:WAN connected v4

It reconnected within a few seconds, with no manual APN re-apply, Abort or reboot. On the previous build nothing happened after the teardown and it stayed on "Connecting".

So the ipk fixes the core problem for me. The IPv6 leg is still rejected during dial (CallendCode 210) but IPv4 comes up fine, so that is not blocking.

Two questions:

Do you still recommend the TTL=64 and disable-IMS changes on top of this build, or is the ipk enough on its own?
Will this fix be included in an upcoming official firmware release for the Mudi 7?

Cathy · June 10, 2026, 8:56am

The ipk is enough and doesn't need to change TTL and IMS, as the disconnection of your device is initiated by the carrier. And this fix will be added in the future release to avoid such issue.

fab · June 20, 2026, 6:48am

Any short term plan to release a new firmware with ipk ?