Environment
- Device: GL-X2000 (Spitz Plus), firmware 4.7.13 stable (OpenWrt 19.07 base, ipq50xx)
- Modem: Quectel EG120K-EA, firmware EG120KEAAAR01A11M2G_01.200.01.200
- Carrier: Telstra Australia, APN telstra.wap, ip_type='IP' (IPv4 only), apn_use='1'
- Role: cellular failover behind an NBN fibre WAN (kmwan failover mode)
Summary
When the carrier renegotiates or drops the data bearer (routine on Telstra CGNAT), the running qcm session wedges permanently. It retries requestSetupDataCall forever, every attempt timing out with err = 110. The host interface (wwan0_1) loses its IPv4 address and never gets it back. The modem itself is healthy the whole time: registered, live bearer, and AT+CGPADDR returns a valid IP. Nothing in the firmware ever tears down and redials the session, so cellular stays dead until a manual ifup or a reboot.
On our failover router this left the site with no WAN at all for 12h23m overnight on 29-30 Aug 2026, because the fibre WAN dropped while cellular was in this wedged state.
This is not the known ip_type issue
The thread "Cellular connection dropping on GL-X2000 Spitz Plus" covers the same symptom family, and the community fix there (commenting out the hardcoded pdp_type='-4 -6' in /lib/netifd/proto/qcm.sh) is the ip_type issue staff said V4.8 beta should address. We have run exactly that patch since May 2026, confirmed working (qcm -4 -n 1 in ps). The wedge in this report still occurs with IPv4-only dialling. Users in that thread also reported drops persisting on 4.8.2 beta and 4.8.3 snapshot, and 4.7.13 is still the latest stable for the X2000, so there is no released fix to upgrade to. This is a second, separate defect.
Fault signature (all three at once)
- Syslog loops indefinitely (ours ran for days):
netifd: modem_2_1 (14827): requestSetupDataCall message timeout
netifd: modem_2_1 (14827): requestSetupDataCall err = 110
netifd: modem_2_1 (14827): try to requestSetupDataCall 60 second later
netifd: modem_2_1 (14827): your sim card may not support ipv6, please contact your carrier
netifd: modem_2_1 (14827): check whether the sim card has obtained an ipv6 address. AT command 'AT+CGPADDR'
-
The interface has no IPv4 (ifconfig wwan0_1 shows only link-local IPv6), and udhcpc on wwan0_1 broadcasts discover with no answer.
-
The modem is fine: AT+CSQ: 21,99 / AT+CREG: 0,1 / AT+QNWINFO: "FDD LTE","50501","LTE BAND 28",9410 / and crucially AT+CGPADDR: 1,"10.110.123.69" (a live bearer IP the host never receives).
Why the firmware cannot self-recover
check_ip() in /lib/functions/modem.sh is the only recovery path for this condition, and it has a gap. It compares the modem IP (AT+CGPADDR) with the interface IP, but the repair branch is guarded by:
if [ -n "$module_ip" -a -n "$interface_ip" ]; then
In this failure mode interface_ip is empty (the interface has no IPv4 at all), so the guard fails and check_ip does nothing. The stale qcm process is never restarted, and there is no other watchdog for this state.
Recovery (proven)
A single ifup modem_2_1 recovers in under a minute: netifd kills the stale qcm, starts a fresh one, the data call sets up immediately and the interface gets a new bearer IP. Reproduced live on 2026-08-30 with the router in the wedged state (100% packet loss on wwan0_1 before, 0% after). A reboot also "fixes" it, but only because it includes the same redial. We currently work around it with a cron probe that redials when the cellular route disappears, but this belongs in the firmware.
Suggested fix (either)
- In check_ip(), treat an empty interface_ip with a non-empty module_ip as the same repair case as an IP mismatch (redial).
- In the qcm retry loop, escalate after N consecutive requestSetupDataCall err=110 timeouts: tear down the session and restart the data call from scratch instead of retrying the stale session forever.
Notes
- Frequency: on Telstra the bearer renegotiated and triggered this state multiple times per day during 28-30 Aug 2026.
- Possibly related (different error code, same spurious requestSetupDataCall behaviour on X-3000): forum thread 47182.
- Full syslog archives available on request.