GL-X3000 / RM520N-GL loses packet service and re-registers every 30–33 minutes

[fregatte]

Hello,

I am experiencing recurring cellular disconnects with a GL.iNet Spitz AX / GL-X3000.

On the affected roaming network, the modem loses packet service approximately every 30–33 minutes. QmiWwanThread then exits, the cellular interface is reported as offline, and GL.iNet’s cellular_manage service performs a complete network re-registration using:

CFUN=4 -> CFUN=1

The connection is restored after approximately 10–15 seconds, but the same issue occurs again roughly half an hour later.

Hardware and software

• Router: GL.iNet Spitz AX / GL-X3000

• Router firmware: 4.9.0

• Modem: Quectel RM520N-GL

• Router protocol: QCM

• Modem interface: PCIe/MHI

• QMI device: /dev/mhi_QMI0

• Usage scenario: international roaming

• Radio connection: LTE or 5G NSA

I have tested several Quectel modem firmware versions from different firmware branches, including 201- and 301-series versions. The recurring disconnect behaviour remained essentially unchanged.

Modem configuration

The relevant modem settings are:

AT+QCFG="pcie/mode"
+QCFG: "pcie/mode",0

AT+QCFG="data_interface"
+QCFG: "data_interface",1,0

AT+QCFG="usbnet"
+QCFG: "usbnet",0

AT+QNWPREFCFG="mode_pref"
+QNWPREFCFG: "mode_pref",AUTO

AT+QNWPREFCFG="nr5g_disable_mode"
+QNWPREFCFG: "nr5g_disable_mode",1

nr5g_disable_mode=1 disables 5G SA but allows 5G NSA.

The permitted NR bands are:

n1, n3, n28, n78

The issue occurs both while the modem is using LTE and while 5G NSA is available.

A normal 5G NSA serving-cell response looks like this:

+QENG: "servingcell","NOCONN"
+QENG: "LTE","FDD",<MCC>,<MNC>,<CELL-ID>,<PCI>,<EARFCN>,<LTE-BAND>,...
+QENG: "NR5G-NSA",<MCC>,<MNC>,<PCI>,<RSRP>,<SINR>,<RSRQ>,<NR-ARFCN>,<NR-BAND>,...

Typical signal levels are usable and do not indicate a complete loss of coverage:

LTE RSRP: approximately -90 to -105 dBm
LTE RSRQ: approximately -6 to -12 dB
LTE SINR: approximately 15 to 19 dB

NR RSRP: approximately -94 dBm
NR RSRQ: approximately -10 dB
NR SINR: approximately 16 dB

I understand that 5G NSA may release the NR secondary carrier while idle and temporarily remain on LTE. However, the problem described here is different: the modem reports PS: Detached, the QCM process exits, and the complete radio registration is restarted.

Anonymized verbatim logread excerpt

The following is a verbatim excerpt from logread. Only the PLMN, CGNAT addresses and process IDs have been anonymized.

Fri Jul 10 19:22:04 2026 daemon.info cellular_manage:
(cm.c:7458) Start force re-register network(CFUN=4 -> CFUN=1)...

Fri Jul 10 19:22:15 2026 daemon.notice netifd:
modem_0001_s1_4 (<PID>): udhcpc:
lease of <CGNAT-IP-1> obtained, lease time 7200


Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:52:47:169]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:52:48:717]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:52:51:498]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:52:53:927]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:52:53:930]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:52:59:146]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:52:59:149]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:53:04:366]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:53:04:371]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:09 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:53:09:584]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:13 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:53:09:587]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 19:53:13 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_19:53:13:783]
QmiWwanThread exit

Fri Jul 10 19:53:14 2026 daemon.info cellular_manage:
(cm.c:8619) Executing dial connect, initiated by INTERFACE OFFLINE
(bus: 0001:01:00.0, slot: 1 interface: modem_0001_s1)

Fri Jul 10 19:53:14 2026 daemon.info cellular_manage:
(cm.c:7458) Start force re-register network(CFUN=4 -> CFUN=1)...

Fri Jul 10 19:53:23 2026 daemon.notice netifd:
modem_0001_s1_4 (<PID>): udhcpc:
lease of <CGNAT-IP-2> obtained, lease time 7200


Fri Jul 10 20:26:16 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:00:124]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:16 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:00:395]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:16 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:04:172]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:16 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:05:682]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:16 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:05:687]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:16 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:10:893]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:16 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:10:898]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:19 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:16:094]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:19 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:16:097]
requestRegistrationState2 MCC: <MCC>, MNC: <MNC>,
PS: Detached, DataCap: UNKNOW

Fri Jul 10 20:26:19 2026 daemon.notice netifd:
modem_0001_s1 (<PID>): [07-10_20:26:19:113]
QmiWwanThread exit

Fri Jul 10 20:26:19 2026 daemon.info cellular_manage:
(cm.c:8619) Executing dial connect, initiated by INTERFACE OFFLINE
(bus: 0001:01:00.0, slot: 1 interface: modem_0001_s1)

Fri Jul 10 20:26:20 2026 daemon.info cellular_manage:
(cm.c:7458) Start force re-register network(CFUN=4 -> CFUN=1)...

Fri Jul 10 20:26:29 2026 daemon.notice netifd:
modem_0001_s1_4 (<PID>): udhcpc:
lease of <CGNAT-IP-3> obtained, lease time 7200

Timing analysis

The excerpt shows the following timing:

• New DHCP lease obtained at 19:22:15

• Packet-service detachment begins at 19:52:47

• Time until failure: approximately 30 minutes and 32 seconds

After recovery:

• New DHCP lease obtained at 19:53:23

• Packet-service detachment begins again at 20:26:00

• Time until the next failure: approximately 32 minutes and 37 seconds

The two GL.iNet-initiated forced re-registrations occurred at:

19:53:14
20:26:20

The interval between them was approximately 33 minutes and 6 seconds.

In both incidents, the sequence is effectively identical:

PS: Detached
DataCap: UNKNOW
QmiWwanThread exit
INTERFACE OFFLINE
cellular_manage starts CFUN=4 -> CFUN=1
new DHCP lease obtained

The DHCP lease duration is 7200 seconds. The failures after approximately 30–33 minutes therefore do not correspond to the normal DHCP lease-expiry or renewal interval.

Normal DHCP renewals can also be seen independently at intervals of approximately two hours:

12:08:17 – lease obtained, lease time 7200
14:07:20 – lease obtained, lease time 7200
16:06:24 – lease obtained, lease time 7200
18:05:27 – lease obtained, lease time 7200
20:04:31 – lease obtained, lease time 7200
22:03:34 – lease obtained, lease time 7200

Troubleshooting already performed

I have already tested:

• Several RM520N-GL modem firmware versions

• Modem firmware from different branches, including 201 and 301

• LTE-only mode

• LTE plus 5G NSA using mode_pref=AUTO

• Different NR band configurations

• Complete radio re-registration

• Router reboot

• Modem firmware reflashing

• Signal Capture disabled:

glmodem.signal.enable=0

• Different roaming operators

The recurring disconnects remained on the affected roaming network.

The behaviour also appears to be operator-dependent. Another available roaming operator was substantially more stable and did not show the same recurring detach pattern.

In the same location, an iPhone connected to 5G remains stable and does not perform a comparable full reconnect every 30–33 minutes.

This suggests that the problem is unlikely to be caused solely by general coverage conditions or by normal network-side 5G NSA idle behaviour.

Interpretation

The logs confirm that GL.iNet’s cellular_manage service starts the forced re-registration after:

QmiWwanThread exit
INTERFACE OFFLINE

However, the excerpt does not reveal why the modem initially changes to:

PS: Detached
DataCap: UNKNOW

The main question is therefore whether the original detachment is caused by:

• the roaming network,

• the Quectel modem firmware,

• the QCM/MHI implementation,

• or a timer, watchdog or registration check inside GL.iNet firmware 4.9.0.

Questions for GL.iNet

Could GL.iNet please investigate the following?

1. What exact QMI or NAS state causes requestRegistrationState2 to report PS: Detached, DataCap: UNKNOW?

2. Why does QmiWwanThread terminate after the detached state persists for approximately 20–25 seconds?

3. Is QmiWwanThread exit caused by the modem, the GL.iNet QCM dialer or the netifd interface-management process?

4. Is there any roaming, packet-service, watchdog or registration timer in firmware 4.9.0 that could explain the recurring 30–33 minute interval?

5. Could a temporary network-side registration or NSA/LTE state transition be interpreted as a complete loss of packet service?

6. Could the cellular manager attempt a QMI data-session recovery before performing a complete CFUN=4 -> CFUN=1 radio re-registration?

7. Are there known compatibility issues between GL.iNet firmware 4.9.0, QCM over PCIe/MHI and particular RM520N-GL modem firmware versions?

8. Is it possible to enable more detailed QMI, NAS, MHI or cellular_manage debugging so that the original reason for PS: Detached can be identified?

I can provide a complete support archive and an additional anonymized log covering several minutes before and after further disconnects if required.

Thank you.

[AngelaMcMahon]

VERY unlikely, but have you considered heat? My GL-XE3000 runs a lot cooler with a 140mm fan pushing air into the router and a 140mm exhausting air.

Very unlikely to be your problem as you’re clearly much more adept at getting info out of the router but I hope this helps.

[fregatte]

Thank you very much for pointing out a possible cause of the issue: heat. However, that is not the cause in my case.

I should add that the problem has so far occurred only under certain conditions—currently while roaming on the Swedish Tele2 network (24002). It has also happened once before while travelling on another network, and probably on several other occasions that I did not notice.

Since my iPhone and an Android phone, both connected to the same network under roaming conditions, do not experience these dropouts—and neither does a ZTE MU5120 router—the cause appears to lie with the Spitz router itself. Thanks again

[AngelaMcMahon]

Did you manage to find out more?

[Cathy]

The module manufacturer has not provided access to all logs, so the information displayed by the router is limited.
This disconnection issue may be related to the network operator. Additionally, is the APN used by the X3000 the same as that of the ZTE router? I have sent you a file; could you please help capture the relevant modem logs for review?

[fregatte]

Update: same type of data-session interruptions in Norway on Telia 24202

I have now moved from Sweden to Norway. In Sweden, I observed repeated interruptions while roaming on Tele2 Sweden (24002). I am currently connected to Telia Norway (24202), and I am again seeing unusual interruptions, although the reconnect currently appears to complete more quickly.

Current setup:

• GL.iNet Spitz AX / GL-X3000

• Quectel RM520N-GL

• Modem firmware: RM520NGLAAR03A04M4G

• Router firmware: 4.9.0

• Updated/patched gl-sdk4-cellular package

• QCM/QMI connection mode

• Operator manually locked to 24202

• 5G NSA connection

The important point is that this does not appear to be a complete loss of cellular registration.

Immediately before the interruption, the modem still reports:

MCC: 242, MNC: 2, PS: Attached, DataCap: 5G_NSA

However, at the same time, the IPv4 data call is reported as:

IPv4ConnectionStatus: DISCONNECTED

The router then initiates PREPARE_DIAL, tears down rmnet_mhi0, terminates the QMI process, and performs a full network re-registration using:

CFUN=4 -> CFUN=1

It then reapplies the manual operator selection:

AT+COPS=1,2,"24202"

Afterwards, rmnet_mhi0 comes back up and a new private IPv4 address is assigned. In this example, the interruption lasted approximately 13 seconds from teardown until a new DHCP lease was obtained.

This suggests that the modem remains registered with the mobile network, but the PDP/QMI IPv4 data session becomes disconnected. The GL.iNet cellular management service then responds by performing a full modem/network recovery instead of only re-establishing the data session.

Relevant log excerpt:

root@GL-X3000:~# logread -f | grep -Ei \
'PREPARE_DIAL|SIM_RECOVERY|IPv4ConnectionStatus|RegistrationState|QmiWwanThread|qmi_main|INTERFACE OFFLINE|CFUN=4|COPS=|lease of|rmnet_mhi0'

Fri Jul 17 09:16:52 2026 daemon.info cellular_manage: (cm.c:9163) Executing dial disconnection, initiated by PREPARE_DIAL (bus: 0001:01:00.0, slot: 1 interface:modem_0001_s1 update_status:0 dial_status_flag:0)
Fri Jul 17 09:16:52 2026 daemon.notice netifd: modem_0001_s1_4 (5719): udhcpc: unicasting a release of 100.88.227.250 to 100.88.227.249
Fri Jul 17 09:16:52 2026 daemon.notice netifd: Network device 'rmnet_mhi0' link is down
Fri Jul 17 09:16:52 2026 daemon.notice netifd: Network alias 'rmnet_mhi0' link is down
Fri Jul 17 09:16:52 2026 kern.info kernel: [74408.759281] net rmnet_mhi0: link_state 0x1 -> 0x0

Fri Jul 17 09:16:52 2026 daemon.notice netifd: modem_0001_s1 (5496): [07-17_09:14:33:691] requestRegistrationState2 MCC: 242, MNC: 2, PS: Attached, DataCap: 5G_NSA
Fri Jul 17 09:16:52 2026 daemon.notice netifd: modem_0001_s1 (5496): [07-17_09:14:33:695] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
Fri Jul 17 09:16:52 2026 daemon.notice netifd: modem_0001_s1 (5496): [07-17_09:14:39:287] requestRegistrationState2 MCC: 242, MNC: 2, PS: Attached, DataCap: 5G_NSA
Fri Jul 17 09:16:52 2026 daemon.notice netifd: modem_0001_s1 (5496): [07-17_09:16:31:004] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
Fri Jul 17 09:16:52 2026 daemon.notice netifd: modem_0001_s1 (5496): [07-17_09:16:31:717] requestRegistrationState2 MCC: 242, MNC: 2, PS: Attached, DataCap: 5G_NSA

Fri Jul 17 09:16:52 2026 daemon.notice netifd: modem_0001_s1 (5496): [07-17_09:16:52:574] QmiWwanThread exit
Fri Jul 17 09:16:52 2026 daemon.notice netifd: modem_0001_s1 (5496): [07-17_09:16:52:574] qmi_main exit
Fri Jul 17 09:16:53 2026 daemon.info cellular_manage: (cm.c:9034) Executing dial connect, initiated by INTERFACE OFFLINE (bus: 0001:01:00.0, slot: 1 interface: modem_0001_s1)
Fri Jul 17 09:16:53 2026 daemon.info cellular_manage: (cm.c:7859) Start force re-register network(CFUN=4 -> CFUN=1)...
Fri Jul 17 09:16:58 2026 daemon.info modem_AT: (at.c:2205) The command AT+COPS=1,2,"24202" is executed, and the command is silent

Fri Jul 17 09:17:01 2026 user.info modem: (qcm.sh:125) Device only supports raw-ip mode but is missing this required driver attribute: /sys/class/net/rmnet_mhi0/qmi/raw_ip.
Fri Jul 17 09:17:01 2026 user.info modem: (qcm.sh:165) Setting ifname rmnet_mhi0 MTU to default 1500
Fri Jul 17 09:17:02 2026 user.info modem: (qcm.sh:177) ifname:rmnet_mhi0
Fri Jul 17 09:17:02 2026 daemon.notice netifd: modem_0001_s1 (19793): [07-17_09:17:02:028] network interface 'rmnet_mhi0' or qmidev '' is not exist
Fri Jul 17 09:17:02 2026 daemon.notice netifd: modem_0001_s1 (19793): [07-17_09:17:02:028] qmap_mode = 1, qmap_version = 9, qmap_size = 15360, muxid = 0x81, qmap_netcard = rmnet_mhi0

Fri Jul 17 09:17:05 2026 kern.info kernel: [74421.477816] net rmnet_mhi0: link_state 0x0 -> 0x1
Fri Jul 17 09:17:05 2026 kern.info kernel: [74421.482583] IPv6: ADDRCONF(NETDEV_CHANGE): rmnet_mhi0: link becomes ready
Fri Jul 17 09:17:05 2026 daemon.notice netifd: Network device 'rmnet_mhi0' link is up
Fri Jul 17 09:17:05 2026 daemon.notice netifd: Network alias 'rmnet_mhi0' link is up
Fri Jul 17 09:17:05 2026 daemon.notice netifd: modem_0001_s1_4 (20109): udhcpc: lease of 10.85.109.183 obtained, lease time 7200

My interpretation is therefore:

1. The SIM remains ready and the modem remains registered on Telia Norway.

2. There is no visible PS: Detached event.

3. The IPv4 data session becomes disconnected while the cellular registration remains attached.

4. QmiWwanThread exit appears to be part of the commanded teardown and not necessarily the original cause.

5. cellular_manage performs an aggressive full recovery, including CFUN=4 -> CFUN=1.

6. The raw_ip warning is probably not the primary cause, because the interface successfully comes up and receives an IP address immediately afterwards.

Could GL.iNet please clarify:

• What exactly triggers PREPARE_DIAL in this situation?

• Is it triggered by a QMI data-call indication, the connectivity tracking system, or the SIM recovery logic?

• Why is a full CFUN=4 -> CFUN=1 network re-registration performed when the modem is still PS: Attached?

• Would it be possible to attempt only a PDP/data-call reconnect first?

• Could repeatedly reapplying AT+COPS=1,2,"24202" contribute to this behaviour?

• Is this a known issue with QConnectManager 1.6.3.1, the PCIe MHI driver, or modem firmware RM520NGLAAR03A04M4G?

Because essentially the same type of data-session interruption has now occurred in two different countries and two different roaming networks, it seems less likely that this is caused only by one specific mobile operator. It may instead be related to the RM520N firmware, the QCM/QMI implementation, 5G NSA roaming, or GL.iNet’s recovery logic.

[Javon_ma]

1. Please check whether NETWORK -> Multi-WAN -> Cellular -> Detection Mode is set to Low data. If it is, please change it to Normal mode and then observe whether the frequent disconnection issue still occurs. Note that Normal mode periodically checks network connectivity, so it will consume a small amount of data.

2. Please modify /etc/config/cellular/network_check.json on the device and set check_period_sec to 60. This value means the active network connectivity check interval is 60 seconds. In cases of network fluctuation or poor signal/network quality, increasing this interval can help reduce false offline detection and avoid unnecessary dial recovery.

[fregatte]

Thank you very much. I have changed the values and would now like to monitor the router’s behaviour over time.

Will the changes made to the JSON file remain in place after a firmware update or a factory reset?

Thank you.

[Javon_ma]

@fregatte

固件更新或恢复出厂设置后，JSON 文件的更改会保留吗

After a firmware upgrade or factory reset, changes made to the JSON configuration file will not be retained. The file will be restored to its default values, so you will need to modify it again manually if needed.

Please also check whether the current network environment is unstable or fluctuating heavily. If the cellular network quality is poor, you may need to lower the kmwan detection sensitivity to avoid frequent dial recovery triggers. You can set the detection mode to Low or Custom in the location shown in the screenshot.

If you have any further questions or need any assistance, please feel free to contact us.

Have a nice day!

[fregatte]

seems to be a roaming / operator issue. router not handling the network as smooth as for instance an iphone working in the same network / same APN; Network always with strong signal; that seems to be not the issue:

to clarify my pm to Cathy from today:

I collected modem logs while the router was connected to Telia Norway (24202).

It appears that Telia Norway may not be fully available for my SIM card under the applicable roaming agreement. However, the Spitz repeatedly connected to the network, remained connected for a short period, then lost the data session and initiated another reconnect. The router was effectively caught in a repeated connection and recovery loop.

At approximately 10:02, the router no longer completed the reconnect automatically. I therefore aborted the connection attempt in the web interface and initiated a manual reconnect:

10:02:12 – connection attempt aborted and manually restarted

Afterwards, I removed the operator lock and allowed all available operators again. The router then performed a network scan:

Fri Jul 17 10:17:30 2026 daemon.debug modem_AT:
(at.c:1902) at_cmd[AT+COPS=?] random_generat...

At this point, I would have expected the router to select another available roaming network automatically, particularly Telenor. However, it continued trying to connect to Telia Norway rather than switching to another usable operator.

I therefore manually locked the router to Telenor:

Switched to N Telenor

I then stopped the logging script. The connection on Telenor appeared stable at that point.

At 11:22, I removed the operator lock again and allowed all operators. The router then remained connected to Telenor, which was the network to which it had previously been manually locked.

For comparison, an iPhone using the same SIM and APN configuration automatically selected Telenor in Norway and did not remain caught in repeated attempts to use Telia.

This issue is not exactly the same as the disconnection problem I experienced in Sweden. In Sweden, the modem remained registered with the network while the IPv4 data session repeatedly changed to DISCONNECTED. In Norway, the additional issue appears to be that the router does not reliably abandon an unusable or possibly unauthorized roaming network and move to another available operator.

My current impression is that the roaming network-selection logic is not sufficiently adaptive. The router can remain stuck in a reconnect loop with one operator, even though another permitted and functioning network is available.

The collected modem logs are currently more than 10 GB in size, so I have not uploaded them yet.

Would you like to examine the complete log package? In that case, I can upload the full archive. Alternatively, please let me know which specific time period or which individual log files would be most useful, and I can provide only the relevant section to avoid uploading more than 10 GB of data.

The most relevant periods are approximately:

• around 10:02, when I aborted the unsuccessful reconnect and manually reconnected;

• around 10:17, when I enabled automatic operator selection and the router continued trying Telia;

• the period when I manually switched to Telenor;

• around 11:22, when I unlocked all operators again and the router remained on Telenor.

Could you also please clarify:

• Why does the router repeatedly reconnect to Telia Norway instead of trying another operator?

• Is there a threshold after which automatic network selection should temporarily avoid an unsuccessful operator?

• Does the previous manual operator selection remain active internally after selecting all operators in the interface?

• Could the patched cellular package be reapplying the previous AT+COPS selection?

• Can the recovery logic distinguish between a temporary data-session failure and a roaming network that is not permitted or usable for the SIM?

Thank you for taking a closer look at this.