Cellular connection dropping on GL-X2000 Spitz Plus

AvailableonBetamax · March 31, 2026, 5:54pm

I own a GL-X2000 Spitz Plus and have been experiencing issues with the cellular connection randomly dropping randomly throughout the day. I've tried different firmware versions (including different stable versions, beta and snapshot) but this has not helped. I’ve also changed the multi-wan settings so only cellular is selected, tried different APNs, enabled/disabled network acceleration but the issue persists. The system log as it disconnected most recently is as follows and it required reboot to reconnect.

Tue Mar 31 13:03:46 2026 daemon.err modem_AT: (modem_AT.c:145) AT_Read@145 epoll timeout!
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12558.999618] ------------[ cut here ]------------
Tue Mar 31 13:04:20 2026 kern.info kernel: [12558.999656] NETDEV WATCHDOG: wwan0 (qmi_wwan_q): transmit queue 0 timed out
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.003365] WARNING: CPU: 0 PID: 23767 at net/sched/sch_generic.c:565 dev_watchdog+0x16c/0x2c8
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.009986] Modules linked in: shortcut_fe_cm ath_pktlog(P) wifi_2_0 monitor wifi_3_0 smart_antenna(P) qca_ol qca_spectral umac qdf mem_manager option usb_wwan nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet ipt_REJECT xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_policy xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_bpf xt_addrtype xt_TCPMSS xt_REDIRECT xt_MASQUERADE xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY wireguard usbserial ts_fsm ts_bm rndis_host ppp_mppe ppp_async nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_fwd_netdev nft_flow_offload nft_dup_netdev nft_ct nft_counter nf_tables nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_rtsp nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_log_ipv4
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.010145] nf_flow_table_hw nf_flow_table nf_dup_netdev nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_rtsp nf_conntrack_rtcache nf_conntrack_pptp nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast ts_kmp nf_conntrack_amanda macvlan l2tp_ppp iptable_raw iptable_nat iptable_mangle iptable_filter ipt_ah ipt_ECN ipheth ip_tables huawei_cdc_ncm cdc_ncm cdc_ether cdc_acm arptable_filter arpt_mangle arp_tables ahci libahci libata sd_mod phy_qca_uniphy phy_qca_m31 dwc3 dwc3_qcom fuse sch_teql sch_sfq sch_red sch_prio sch_pie sch_multiq sch_gred sch_fq sch_dsmark sch_codel sch_cake em_text em_nbyte em_meta em_cmp act_simple act_police act_pedit act_ipt act_gact act_csum act_connmark sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred xhci_plat_hcd xhci_pci xhci_hcd qca_nss_tunipip6 qca_nss_tun6rd leds_gpio pwm_fan hwmon qca_nss_qdisc qmi_wwan_q usbnet cdc_wdm
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.083995] bt_rproc bt_interface g_diag qca_nss_macsec qca_mcs diagchar usb_f_diag crc_ccitt qca_nss_vxlanmgr qca_nss_pptp qca_nss_pppoe pppoe qca_nss_map_t qca_nss_lag_mgr qca_nss_l2tpv2 qca_nss_gre libcomposite udc_core qca_ovsmgr openvswitch nf_conncount xt_sctp emesh_sp cryptodev xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6table_nat nf_nat nf_conntrack pptp pppox ppp_generic slhc nf_defrag_ipv4 libcrc32c ip6t_NPT rmnet_nss nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos bonding ip6_gre ip_gre gre ifb rmnet_core rmnet_ctl nat46 nf_defrag_ipv6 sit qca_nss_drv l2tp_netlink l2tp_core ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel ipcomp esp4 ah4 ip6_tunnel qca_nss_dp
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.171140] tunnel6 tunnel4 ip_tunnel veth tun snd_rawmidi snd_seq_device snd_pcm_oss snd_mixer_oss snd_hwdep snd_compress xfrm_user xfrm_ipcomp af_key xfrm_algo vfat fat ntfs cfg80211 nls_utf8 nls_iso8859_1 nls_cp437 vxlan udp_tunnel ip6_udp_tunnel nsh shortcut_fe_ipv6 shortcut_fe md5 authenc qca_ssdk mtdoops ipq_cnss2 uas usb_storage usbcore usb_common scsi_mod gl_fan_driver bootconfig gl_watchdog kmwan gpio_button_hotplug gl_sdk4_tertf gl_sdk4_black_white_list exfat nls_base button_hotplug input_core mii gl_sdk4_hw_info [last unloaded: qdf]
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.306421] CPU: 0 PID: 23767 Comm: nginx Tainted: P 5.4.213 #0
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.328650] Hardware name: GL.iNet X2000, Inc. IPQ5018/AP-MP03.5-C1 (DT)
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.336201] pstate: 40400005 (nZcv daif +PAN -UAO)
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.342885] pc : dev_watchdog+0x16c/0x2c8
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.347480] lr : dev_watchdog+0x16c/0x2c8
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.351558] sp : ffffff801ff96df0
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.355551] x29: ffffff801ff96df0 x28: 0000000000000010
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.358852] x27: 00000000ffffffff x26: 0000000000000140
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.364235] x25: 0000000000000000 x24: ffffff8018767480
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.369528] x23: 0000000000000001 x22: ffffff80182d845c
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.374823] x21: ffffff80182d8480 x20: 0000000000000000
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.380119] x19: ffffff80182d8000 x18: 0000000000000000
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.385413] x17: 0000000000000000 x16: 0000000000000000
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.390708] x15: 0000000000000000 x14: 0098971eb110c9c9
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.396004] x13: 0000989680013880 x12: fffffffffffec780
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.401299] x11: 000098971eb10000 x10: 000000000003a980
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.406594] x9 : ffffffc01099a000 x8 : 2064656d69742030
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.411889] x7 : 2065756575712074 x6 : 0000000000000001
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.417184] x5 : 0000000000000000 x4 : 0000000000000001
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.422479] x3 : 0000000000000007 x2 : 0000000000000007
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.427774] x1 : f126fa12bf4ecf00 x0 : 0000000000000000
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.433071] Call trace:
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.438367] dev_watchdog+0x16c/0x2c8
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.440542] call_timer_fn.isra.2+0x20/0x74
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.444356] expire_timers+0x84/0xac
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.448348] run_timer_softirq+0x88/0x158
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.452169] __do_softirq+0x10c/0x244
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.456074] irq_exit+0x64/0xb4
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.459721] __handle_domain_irq+0x88/0xac
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.462670] gic_handle_irq+0x74/0xbc
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.466839] el0_irq_naked+0x4c/0x54
Tue Mar 31 13:04:20 2026 kern.warn kernel: [12559.470570] ---[ end trace f3d5101d9c13337f ]---
Tue Mar 31 13:05:16 2026 user.notice root: modem ip different, now regain ip ...
Tue Mar 31 13:05:16 2026 daemon.notice netifd: Interface 'modem_2_1_4' has lost the connection
Tue Mar 31 13:05:17 2026 daemon.notice netifd: Interface 'modem_2_1_4' is now down
Tue Mar 31 13:05:17 2026 daemon.notice netifd: Interface 'modem_2_1_4' is disabled
Tue Mar 31 13:05:17 2026 daemon.notice netifd: Interface 'modem_2_1_4' is enabled
Tue Mar 31 13:05:17 2026 daemon.notice netifd: Interface 'modem_2_1_4' is setting up now
Tue Mar 31 13:05:17 2026 daemon.notice netifd: modem_2_1_4 (21358): udhcpc: started, v1.35.0
Tue Mar 31 13:05:17 2026 daemon.notice netifd: modem_2_1_4 (21358): udhcpc: broadcasting discover
Tue Mar 31 13:05:17 2026 user.notice firewall: Reloading firewall due to ifdown of modem_2_1_4 ()
Tue Mar 31 13:05:19 2026 user.notice kmwan: config json str={ "op": 3, "data": { "cells": [ "modem_2_1_4" ] } }
Tue Mar 31 13:05:20 2026 daemon.notice netifd: modem_2_1_4 (21358): udhcpc: broadcasting discover
Tue Mar 31 13:05:23 2026 daemon.notice netifd: modem_2_1_4 (21358): udhcpc: broadcasting discover
Tue Mar 31 13:05:24 2026 user.notice root: modem ip different, now regain ip ...
Tue Mar 31 13:05:24 2026 daemon.notice netifd: Interface 'modem_2_1_4' is now down
Tue Mar 31 13:05:24 2026 daemon.notice netifd: Interface 'modem_2_1_4' is disabled
Tue Mar 31 13:05:24 2026 daemon.notice netifd: Interface 'modem_2_1_4' is enabled
Tue Mar 31 13:05:24 2026 daemon.notice netifd: Interface 'modem_2_1_4' is setting up now
Tue Mar 31 13:05:24 2026 daemon.notice netifd: modem_2_1_4 (21886): udhcpc: started, v1.35.0
Tue Mar 31 13:05:24 2026 daemon.notice netifd: modem_2_1_4 (21886): udhcpc: broadcasting discover
Tue Mar 31 13:05:27 2026 daemon.notice netifd: modem_2_1_4 (21886): udhcpc: broadcasting discover
Tue Mar 31 13:05:30 2026 daemon.notice netifd: modem_2_1_4 (21886): udhcpc: broadcasting discover
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:01:56:206] call_end_reason_verbose is 210
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:01:56:206] try to requestSetupDataCall 60 second later
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:01:56:207] your sim card may not support ipv6, please contact your carrier
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:01:56:207] check whether the sim card has obtained an ipv6 address. AT command 'AT+CGPADDR'
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:02:56:408] trying to get ipv6 address
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:02:56:422] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:02:56:422] call_end_reason is 1
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:02:56:422] call_end_reason_type is 2
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:02:56:422] call_end_reason_verbose is 210
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:02:56:423] try to requestSetupDataCall 60 second later
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:02:56:423] your sim card may not support ipv6, please contact your carrier
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:02:56:423] check whether the sim card has obtained an ipv6 address. AT command 'AT+CGPADDR'
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:04:11:555] requestQueryDataCall message timeout
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:04:11:555] requestQueryDataCall err = 110
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:06:11:556] requestSetupDataCall message timeout
Tue Mar 31 13:06:11 2026 daemon.notice netifd: modem_2_1 (16269): [03-31_13:06:11:556] requestSetupDataCall err = 110
Tue Mar 31 13:07:03 2026 daemon.err get_current_time[14137]: curl: (6) Could not resolve host: worldtimeapi.org

Cathy · April 1, 2026, 9:17am

Hello @AvailableonBetamax
Can the router automatically restore the network connection after it drops?
Could you provide the complete log of the router for analysis?

AvailableonBetamax · April 1, 2026, 12:00pm

Hello. Yes, it does reconnect after disconnecting for couple of minutes. I've attached a recent log. This issue on the attached log is the usual disconnect occurrence, that happens multiple times a day as follows:

Wed Apr 1 09:01:31 2026 daemon.notice netifd: modem_2_1 (12708): [04-01_09:01:30:332] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED

systemblog April 1 090131.log (66.4 KB)

The log quoted in my original post, is maybe a different issue that has as of yet not repeated

AvailableonBetamax · April 1, 2026, 7:47pm

It has just disconnected in the way I reported in my first log. So the cellular connection seems to disconnect in two different ways! When it fails like this, the router does not automatically reconnect, on our devices it states "connected but no internet" although all the lights are on the router. When it disconnects in this way, the router requires a reboot, after which the internet connects as normal:

system Apr 1 165943.log (66.7 KB)

Wed Apr 1 16:59:39 2026 daemon.err gl-cloud[13879]: (gl-cloud.lua:170) fetch ca fail: resolve "gslb-eu.goodcloud.xyz" fail: recv from "192.168.253.31:53" fail: timeout

Wed Apr 1 16:59:39 2026 daemon.err gl-cloud[13879]: (gl-cloud.lua:991) reconnect mqtt in 10s...

Wed Apr 1 16:59:43 2026 kern.warn kernel: [50363.503571] ------------[ cut here ]------------

Wed Apr 1 16:59:43 2026 kern.info kernel: [50363.503604] NETDEV WATCHDOG: wwan0 (qmi_wwan_q): transmit queue 0 timed out

This is unfortunately very frustrating so any help would be much appreciated, thank you.

Cathy · April 2, 2026, 6:45am

Thanks for the information. May I know the current firmware version of the router? Please go to the admin panel ->SYSTEM ->Upgrade, share a screenshot to show us the firmware details.

AvailableonBetamax · April 2, 2026, 7:53am

I am currently using 4.5.26 but I have also tried all other available firmware, including the older versions, the latest stable 4.7.13, beta 4.8.2 and the latest snapshot 4.8.3 but the disconnect issue persists on all of those

Cathy · April 2, 2026, 9:21am

The causes of these two disconnection issues may be different. If the device can reconnect after dropping offline, it might be related to network quality.
However, if device cannot reconnect, we may need to check if it's related to the cellular module. Could you upgrade device to beta version V4.8, insert a USB drive with 8GB of free space, and then share it to support through Goodcloud for remote troubleshooting? Thanks

AvailableonBetamax · April 2, 2026, 1:44pm

All set up and I have just PM’ed you the info. Many thanks

bob_pickle69 · April 7, 2026, 12:02pm

Hi. I’m seeing the exact same issue on my GL-X2000 Spitz Plus, and my logs are identical to the OP’s. The beta firmware didn’t fix it for me, but the connection does restore faster on the beta. I’ve already opened a support ticket, but I’m not comfortable granting external access via GoodCloud, so I’d appreciate any help that doesn't require remote access. Thanks.

Cathy · April 8, 2026, 11:24am

Are there similar logs after upgrading to V4.8? Could you please export the logs from the 4.8 firmware for review? If you have the correct APN, please manually enter the correct APN to the router and try again.

fafr84 · April 10, 2026, 8:18am

Bug Report: GL-X2000 — qcm.sh overrides ip_type setting, forces IPv4v6 regardless of user configuration

Summary

The file /lib/netifd/proto/qcm.sh contains a hardcoded pdp_type='-4 -6' assignment that overrides the user-configured ip_type setting from the network config. This causes the QConnectManager to always attempt an IPv6 bearer setup — even when the user has explicitly set ip_type='IP' (IPv4 only) in the admin panel or via UCI.

This leads to a permanent connection failure after Telekom Germany's mandatory 24-hour session disconnect, because the IPv6 setup repeatedly fails with call_end_reason_verbose 231 (QMUXError 0xe), enters an infinite retry loop, and blocks the QMI interface with recurring requestSetupDataCall message timeout (err = 110).

Affected Device

Model: GL-X2000 (Spitz Plus)
Modem: Quectel EG120K-EA (firmware EG120KEAAAR01A11M2G)
Carrier: Deutsche Telekom (Germany), APN: internet.telekom
Firmware tested: 4.5.26 (confirmed), but the bug exists in all available firmware versions including 4.7.13 stable and 4.8.2 beta, as the affected code is identical.

Steps to Reproduce

Insert a Telekom Germany SIM card into the GL-X2000.
Set IP Type to "IPv4" in Internet → Cellular → SIM Card Settings.
Confirm via UCI: uci get network.modem_2_1.ip_type returns IP.
Confirm via AT command: AT+CGDCONT? returns +CGDCONT: 1,"IP","internet.telekom",....
Wait for the carrier's 24-hour forced session disconnect (or simulate with ifdown modem_2_1 && sleep 5 && ifup modem_2_1).
Observe the system log: the router attempts IPv6 bearer setup despite IPv4-only configuration.

Root Cause

In /lib/netifd/proto/qcm.sh, the case block correctly maps the ip_type UCI setting to the pdp_type variable:

case "$ip_type" in
    "IPV4V6") pdp_type='-4 -6' ;;
    "IPV6") pdp_type='-6' ;;
    *) pdp_type='-4' ;;
esac

However, a few lines later, inside the if [ "$apn_use" != "-1" ] block, pdp_type is unconditionally overwritten:

if [ "$apn_use" != "" ]; then
    pdp_type='-4 -6'    # <--- BUG: overrides the case block above
    proto_run_command "$interface" qcm ${pdp_type:=-4 -6} \
        ...

This means the user's IPv4-only setting is always ignored when apn_use is set (which is the default path).

Expected Behavior

The pdp_type variable set by the case "$ip_type" block should be passed through to proto_run_command without being overwritten. The QConnectManager should only attempt IPv6 if the user has explicitly configured ip_type='IPV4V6' or ip_type='IPV6'.

Workaround

Comment out the hardcoded assignment:

# pdp_type='-4 -6'

Then restart the network: /etc/init.d/network restart.

This fix must be reapplied after every firmware upgrade.

Log Evidence

After 24h disconnect — IPv6 retry loop (with bug):

modem_2_1: requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
modem_2_1: call_end_reason is 1
modem_2_1: call_end_reason_type is 2
modem_2_1: call_end_reason_verbose is 231
modem_2_1: try to requestSetupDataCall 60 second later
modem_2_1: your sim card may not support ipv6, please contact your carrier
modem_2_1: check whether the sim card has obtained an ipv6 address. AT command 'AT+CGPADDR'
modem_2_1: trying to get ipv6 address
modem_2_1: requestSetupDataCall message timeout
modem_2_1: requestSetupDataCall err = 110

This cycle repeats indefinitely every 60 seconds, preventing reconnection.

Kernel log — related NETDEV WATCHDOG crash:

NETDEV WATCHDOG: wwan0 (qmi_wwan_q): transmit queue 0 timed out

The endless IPv6 retry loop saturates the QMI interface and eventually triggers a transmit queue timeout in the qmi_wwan_q driver.

Related Forum Thread

Other users are reporting identical symptoms and logs.

Suggested Fix

Remove the hardcoded pdp_type='-4 -6' assignment on the line inside the apn_use block, so the value from the case "$ip_type" block is respected. This is a one-line fix.

Cathy · April 10, 2026, 11:04am

Thank you for your feedback. The V4.8 beta version should have addressed the issues with the QCM script and IP Type settings. After you comment out the pdp_type='-4 -6', do you still experience disconnections?

We have reviewed the logs and believe that the disconnection problems may be caused by other factors. Our investigation is still ongoing.

fafr84 · April 11, 2026, 3:41pm

after the fix, no disconnections at all.