GL-X3000 Cellular network/cell selection (using eSim)

[Xandrios]

I’m using a SIMPoYo physical esim in slot #2, and have a roaming travel esim programmed onto the simcard. It works well, the connection is active as expected.

However, in this case this is a roaming travel eSim that charges differently depending on the local PLMN that I connect to. By default, the router seems to connect to the most expensive network. So I want to change that to the national operator (Better quality, better price).

I’ve tried Lock Operator, both with Lockmode “manual“ and “manual+auto“. I’ve also tried “lock tower“. In all cases the scan starts normally, takes a minute or two, and then shows no result. Simply the previous page with the “Scan“ button is displayed again.

Does this not work for Sim slot #2? Or perhaps it does not work for eSims? What can be done to get this to show a network list correctly (and then lock)?

Scanning:

Scanning complete:

The same (type of) esim on a regular phone allows selecting other network(s) without issue. The network and simcard allow/support this.

Thank you.

[Xandrios]

Note. Using the CLI the scanning and selecting the Manual+Auto mode, works fine:

root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS?'
+COPS: 0,0,"NOVA",13
OK

root@GL-X3000:~# gl_modem -B 0001:01:00.0 SAT sp 'AT+COPS=?'

+COPS: (1,"WIND GR","WIND","20210",12),(1,"NOVA","NOVA","20210",7),(1,"vodafone GR","voda GR","20205",7),(1,"GR COSMOTE","C-OTE","20201",7),(1,"GR COSMOTE","C-OTE","20201",12),,(0-4),(0-2)
OK

root@GL-X3000:~# gl_modem -B 0001:01:00.0 SAT sp 'AT+COPS=4,2,"20201"'
OK

root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS?'
+COPS: 1,2,"20201",13
OK

The above actually switches the modem to the desired network, which is then also visible using the web interface.

But I don’t want to have to manage this via CLI - this seems to be a GUI related bug, as the buttons are there in the GUI and the modem obviously supports it as well. In the past, using physical sims, I have been able to lock the tower without issues using the GUI..but doesn’t seem to be working using the eSIM.

[charles2]

Hi,

Thank you for the detailed information and testing.

Since the modem can scan the available operators and switch to the selected PLMN successfully through the CLI, it appears that the modem and eSIM are able to perform operator selection normally.

To help us check what happens when the scan is triggered from the Web Admin Panel, could you please SSH into the router and run:

logread -f | grep -Ei 'modem_AT|cellular_manage|COPS|operator|scan'

Then please run Lock Operator → Scan again from the Web Admin Panel, wait until the scan finishes, and share the output generated during the scan with us.

Thank you for your help.

[Xandrios]

When I execute the “Lock operator“ function it doesnt show any results. The logs show this, seemingly there is a timeout:

Thu Sep 24 16:02:04 2026 daemon.info modem_AT: (at_server.c:205) AT_Read@205 There is not enough time remaining!
Thu Sep 24 16:02:05 2026 daemon.info modem_AT: (at_server.c:960) get_AT_device api Loop count:1
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:00:05:042] try to requestSetupDataCall 60 second later
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:00:05:042] your sim card may not support ipv6, please contact your carrier
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:00:05:042] check whether the sim card has obtained an ipv6 address. AT command 'AT+CGPADDR'
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:01:05:086] trying to get ipv6 address
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:01:05:091] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:01:05:091] call_end_reason is 1
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:01:05:091] call_end_reason_type is 2
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:01:05:091] call_end_reason_verbose is 210
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:01:05:091] try to requestSetupDataCall 60 second later
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:01:05:091] your sim card may not support ipv6, please contact your carrier
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:01:05:091] check whether the sim card has obtained an ipv6 address. AT command 'AT+CGPADDR'
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:02:05:141] trying to get ipv6 address
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:02:05:145] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:02:05:145] call_end_reason is 1
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:02:05:145] call_end_reason_type is 2
Thu Sep 24 16:02:05 2026 daemon.notice netifd: modem_0001 (27526): [09-24_16:02:05:145] call_end_reason_verbose is 210
Thu Sep 24 16:02:08 2026 daemon.err glc: (api.c:2890) Failed to send AT
Thu Sep 24 16:02:10 2026 daemon.info gl_modem: (modem_network.c:2156) Start lock operator initialization...

Trying the scan using the CLI a few times gives very mixed results. Sometimes it completes in 8 seconds, sometimes in 37 seconds, and sometimes a response takes up to 1,5 to 3 minutes - in which case an ERROR is returned from the modem.

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
+COPS: (1,"vodafone GR","voda GR","20205",7),(1,"GR COSMOTE","C-OTE","20201",7),(1,"WIND GR","WIND","20210",7),(1,"GR COSMOTE","C-OTE","20201",12),,(0-4),(0-2)

OK
real	0m 7.68s
user	0m 0.00s
sys	0m 0.00s

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
ERROR
real	1m 31.30s
user	0m 0.00s
sys	0m 0.00s

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
ERROR
real	3m 0.07s
user	0m 0.00s
sys	0m 0.00s

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
ERROR
real	3m 0.07s
user	0m 0.00s
sys	0m 0.00s

root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS?'
+COPS: 0,0,"vodafone GR",13
OK

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
+COPS: (1,"vodafone GR","voda GR","20205",7),(1,"GR COSMOTE","C-OTE","20201",7),(1,"WIND GR","WIND","20210",7),(1,"GR COSMOTE","C-OTE","20201",12),,(0-4),(0-2)

OK
real	0m 36.86s
user	0m 0.00s
sys	0m 0.00s

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
+COPS: (1,"vodafone GR","voda GR","20205",7),(1,"GR COSMOTE","C-OTE","20201",7),(1,"WIND GR","WIND","20210",7),(1,"WIND GR","WIND","20210",12),(1,"GR COSMOTE","C-OTE","20201",12),,(0-4),(0-2)
OK
real	0m 37.45s
user	0m 0.00s
sys	0m 0.00s

I’m expecting that the GL-Inet software also uses a timeout for this AT command? Seeing that the modem sometimes takes a long time to respond (and sometimes returns an error) it makes sense that this may not work in the GUI.

Does this mean that there is an issue with my modem?

[AI_bot]

These results do not by themselves indicate a faulty modem. Successful AT+COPS=? scans and successful manual operator selection show that the modem can perform both operations. However, the intermittent 90–180 second ERROR responses also show that this is not exclusively a Web Admin Panel display issue; the GUI appears to reach its timeout when the modem scan is unusually slow or fails.

The log also shows repeated data-call/IPv6 setup attempts while the operator scan is running, which may contend for the modem interface. As a focused test, disconnect the Cellular interface first, wait until the retries stop, and then run the GUI scan again. If the SIM profile does not provide IPv6, also test with the cellular APN protocol set temporarily to IPv4 only. If scanning still times out while disconnected, please provide the router firmware version and modem firmware version; that would help staff determine whether the timeout or modem firmware behavior needs further investigation. The IPv6/QMUX messages alone are not evidence of hardware failure.

This reply was generated by AI. Please verify its accuracy.

GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.

[Xandrios]

Disabling the IPv6 does stop the periodic ipv6 check/query on the modem. However, the issue remains (or has gotten worse, as no status is returned at all any more):

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
real	3m 4.03s
user	0m 0.00s
sys	0m 0.00s

The minutes before, and during the scan no longs were written/visible with ‘logread‘, implying that now there was no competing other command. At the 3 minute timeout mark the logs show this:

Thu Sep 24 16:57:08 2026 daemon.info modem_AT: (at_server.c:205) AT_Read@205 There is not enough time remaining!
Thu Sep 24 16:57:08 2026 daemon.info modem_AT: (at_server.c:960) get_AT_device api Loop count:1
Thu Sep 24 16:57:13 2026 daemon.info gl_modem: (modem_network.c:2156) Start lock operator initialization...

After a few tries it works..sometimes.

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'

+COPS: (1,"vodafone GR","voda GR","20205",7),(1,"Telekom GR","Telekom ","20201",7),(1,"WIND GR","WIND","20210",7),(1,"WIND GR","WIND","20210",12),(1,"GR COSMOTE","C-OTE","20201",12),,(0-4),(0-2)

OK
real	0m 53.68s
user	0m 0.00s
sys	0m 0.00s

Via the GUI the scan also, sometimes, works. (1 in 4 times perhaps). When locking 202-01 in 5G however, the following message is shown:

The following logs are observed:

Thu Sep 24 17:04:50 2026 daemon.info glc: (api.c:3073) Mode 4 operator registration fails, and the automatic network selection mode has been switched!
Thu Sep 24 17:04:50 2026 daemon.info glc: (modem_cm.c:33) Disconnect from the network
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001_4 (19238): udhcpc: received SIGTERM
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001_4 (19238): udhcpc: unicasting a release of 10.204.50.109 to 10.204.50.110
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001_4 (19238): udhcpc: sending release
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001_4 (19238): udhcpc: entering released state
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001_4 (19238): Command failed: Permission denied
Thu Sep 24 17:04:50 2026 kern.info kernel: [271646.756183] net rmnet_mhi0: link_state 0x1 -> 0x0
Thu Sep 24 17:04:50 2026 daemon.notice netifd: Network device 'rmnet_mhi0' link is down
Thu Sep 24 17:04:50 2026 daemon.notice netifd: Network alias 'rmnet_mhi0' link is down
Thu Sep 24 17:04:50 2026 daemon.notice netifd: Interface 'modem_0001_4' has link connectivity loss
Thu Sep 24 17:04:50 2026 user.notice kmwan: config json str={ "op": 6, "data": { } }
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_16:59:43:645] requestRegistrationState2 MCC: 202, MNC: 1, PS: Attached, DataCap: 5G_NSA
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:06:354] requestRegistrationState2 MCC: 202, MNC: 1, PS: Attached, DataCap: 5G_NSA
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:43:989] requestRegistrationState2 MCC: 0, MNC: 0, PS: Detached, DataCap: UNKNOW
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:43:993] requestRegistrationState2 MCC: 0, MNC: 0, PS: Detached, DataCap: UNKNOW
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:44:029] requestRegistrationState2 MCC: 0, MNC: 0, PS: Detached, DataCap: UNKNOW
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:44:070] requestRegistrationState2 MCC: 0, MNC: 0, PS: Detached, DataCap: UNKNOW
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:44:231] requestRegistrationState2 MCC: 202, MNC: 1, PS: Detached, DataCap: UNKNOW
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:44:234] requestRegistrationState2 MCC: 202, MNC: 1, PS: Detached, DataCap: UNKNOW
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:44:768] requestRegistrationState2 MCC: 202, MNC: 1, PS: Detached, DataCap: UNKNOW
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:44:773] requestRegistrationState2 MCC: 202, MNC: 1, PS: Detached, DataCap: UNKNOW
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:45:052] requestRegistrationState2 MCC: 202, MNC: 1, PS: Attached, DataCap: 5G_NSA
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:50:383] QmiWwanThread exit
Thu Sep 24 17:04:50 2026 daemon.notice netifd: modem_0001 (18969): [09-24_17:04:50:385] qmi_main exit
Thu Sep 24 17:04:50 2026 daemon.notice netifd: Interface 'modem_0001' is now down
Thu Sep 24 17:04:50 2026 daemon.notice netifd: Interface 'modem_0001_4' is now down
Thu Sep 24 17:04:50 2026 daemon.notice netifd: Interface 'modem_0001_4' is disabled
Thu Sep 24 17:04:50 2026 user.notice kmwan: config json str={ "op": 3, "data": { "cells": [ "modem_0001" ] } }
Thu Sep 24 17:04:50 2026 kern.debug kernel: [271646.924184] kmwan: Delete node:modem_0001
Thu Sep 24 17:04:50 2026 user.notice firewall: Reloading firewall due to ifdown of modem_0001 ()
Thu Sep 24 17:04:53 2026 daemon.info glc: (modem_cm.c:25) Start connect to the network...
Thu Sep 24 17:04:53 2026 daemon.err glc: (api.c:3168) Failed to lock operator
Thu Sep 24 17:04:53 2026 daemon.info gl_modem: (modem_cm.c:1411) Enter the dialing process
Thu Sep 24 17:04:53 2026 daemon.info gl_modem: (modem_cm.c:1448) Now that the simcard is ready, try dialing...
Thu Sep 24 17:04:53 2026 daemon.info gl_modem: (modem_cm.c:1477) curr dial imsi:
Thu Sep 24 17:04:53 2026 daemon.info gl_modem: (modem_cm.c:1493) network configuration exists
Thu Sep 24 17:04:53 2026 daemon.info gl_modem: (modem_cm.c:1505) Start dial form network...
Thu Sep 24 17:04:53 2026 daemon.info gl_modem: (modem_cm.c:1193) Start performing the dialing action...
Thu Sep 24 17:04:55 2026 daemon.notice netifd: Interface 'modem_0001' is setting up now
Thu Sep 24 17:04:55 2026 user.info modem: (qcm.sh:28) (unlock_sim_pin)sim_status:READY modem_bus:0001:01:00.0
Thu Sep 24 17:04:55 2026 daemon.notice netifd: modem_0001 (4055): Failed to parse message data
Thu Sep 24 17:04:56 2026 user.info modem: (qcm.sh:106) Device only supports raw-ip mode but is missing this required driver attribute: /sys/class/net/rmnet_mhi0/qmi/raw_ip.
Thu Sep 24 17:04:56 2026 user.info modem: (qcm.sh:153) Setting ifname rmnet_mhi0 MTU to default 1500
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:266] QConnectManager_Linux_V1.6.3.1
Thu Sep 24 17:04:56 2026 kern.err kernel: [271652.706364] [I][mhi_netdev_open] Opened net dev interface
Thu Sep 24 17:04:56 2026 daemon.notice netifd: Interface 'modem_0001' is now up
Thu Sep 24 17:04:56 2026 daemon.notice netifd: Interface 'modem_0001_4' is enabled
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:267] Find /sys/bus/usb/devices/1-1.2 idVendor=0x2c7c idProduct=0x801, bus=0x001, dev=0x004
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:267] network interface '' or qmidev '' is not exist
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:267] netcard driver = pcie_mhi, driver version = V1.3.4
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:268] qmap_mode = 1, qmap_version = 9, qmap_size = 15360, muxid = 0x81, qmap_netcard = rmnet_mhi0
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:268] Modem works in QMI mode
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:274] cdc_wdm_fd = 7
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:289] Get clientWDS = 2
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:293] Get clientDMS = 1
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:295] Get clientNAS = 3
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:298] Get clientUIM = 2
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:301] Get clientWDA = 1
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:305] requestBaseBandVersion RM520NGLAAR03A03M4G
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:308] qmap_settings.rx_urb_size = 15360
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:308] qmap_settings.ul_data_aggregation_max_datagrams  = 11
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:308] qmap_settings.ul_data_aggregation_max_size       = 8192
Thu Sep 24 17:04:56 2026 daemon.notice netifd: modem_0001 (4470): [09-24_17:04:56:308] qmap_settings.dl_minimum_padding                 = 0
Thu Sep 24 17:04:59 2026 kern.info kernel: [271655.837809] net rmnet_mhi0: link_state 0x0 -> 0x1
Thu Sep 24 17:04:59 2026 kern.info kernel: [271655.843194] IPv6: ADDRCONF(NETDEV_CHANGE): rmnet_mhi0: link becomes ready
Thu Sep 24 17:04:59 2026 daemon.notice netifd: Network device 'rmnet_mhi0' link is up
Thu Sep 24 17:04:59 2026 daemon.notice netifd: Network alias 'rmnet_mhi0' link is up
Thu Sep 24 17:04:59 2026 daemon.notice netifd: Interface 'modem_0001_4' has link connectivity
Thu Sep 24 17:04:59 2026 daemon.notice netifd: Interface 'modem_0001_4' is setting up now
Thu Sep 24 17:04:59 2026 daemon.notice netifd: modem_0001_4 (4722): udhcpc: started, v1.33.2
Thu Sep 24 17:04:59 2026 user.notice kmwan: config json str={ "op": 6, "data": { } }
Thu Sep 24 17:04:59 2026 daemon.notice netifd: modem_0001_4 (4722): udhcpc: sending discover
Thu Sep 24 17:04:59 2026 daemon.notice netifd: modem_0001_4 (4722): udhcpc: sending select for 10.204.50.109
Thu Sep 24 17:04:59 2026 daemon.notice netifd: modem_0001_4 (4722): udhcpc: lease of 10.204.50.109 obtained, lease time 7200
Thu Sep 24 17:04:59 2026 daemon.notice netifd: Interface 'modem_0001_4' is now up

And with this failure the lock is not applied (mode 0 / automatic):

gl_modem -B 0001:01:00.0 AT 'AT+COPS?'

+COPS: 0,2,"20201",13

However, manually locking that exact same network still works fine. Note that I am using the same PLMN as given with the GUI (202-01), as well as technology (5G / 13):

root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS=4,2,"20201"'

OK

root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS?'

+COPS: 1,2,"20201",13

OK

[AI_bot]

The successful CLI command is not quite equivalent to the GUI selection: AT+COPS=4,2,"20201" omits the access-technology parameter, allowing the modem to choose it. The GUI’s 5G option may be forcing access technology 13.

Please test the exact variant below while the cellular interface is disconnected:

gl_modem -B 0001:01:00.0 AT 'AT+COPS=4,2,"20201",13'

If that fails while the command without ,13 succeeds, the issue is the forced technology selection rather than the PLMN itself. If both succeed, the evidence instead points to the Web Admin Panel workflow or timeout. Please also provide the GL-X3000 firmware version so staff can match this behavior to the relevant firmware branch.

Your posted log contains the SIM’s IMSI. Please edit the post and redact the curr dial imsi value.

This reply was generated by AI. Please verify its accuracy.

GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.

[Xandrios]

@AI_bot

gl_modem -B 0001:01:00.0 AT 'AT+COPS=4,2,"20201",13'

That works fine:

root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS=4,2,"20201",13'


OK

[AI_bot]

That result rules out the PLMN/access-technology combination itself: the modem accepts AT+COPS=4,2,"20201",13. Together with the successful scans, this makes a faulty modem or an eSIM/SIM-slot limitation less likely. The remaining evidence points to the Web Admin Panel’s lock workflow or timeout handling, although this is not yet a confirmed firmware bug.

Please provide the GL-X3000 router firmware version shown under SYSTEM → Upgrade. The modem firmware is already visible in the log as RM520NGLAAR03A03M4G; the router firmware version will let staff determine whether this behavior matches a specific firmware branch.

This reply was generated by AI. Please verify its accuracy.

GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.

[Xandrios]

Version info in first post.

[charles2]

Hi,

Thank you for the additional testing.

Could you please try upgrading the modem firmware to this version and then test Lock Operator → Scan again?
You can download the modem firmware and follow the upgrade guide here:

Upgrade steps - Upgrade Quectel Module - GL.iNet Router Docs 4

[Xandrios]

Thank you. Modem was upgraded:

Unfortunately the issues are not resolved.

After the modem update the manually set lock had dissapeared:

root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS?'
+COPS: 0,0,"NOVA",13

Doing a scan via the GUI worked. However, the list is incomplete; Vodafone 5G is missing in this overview. A manual scan is also missing Vodafone 5G. However, this is not correct as Vodafone 5G (NSA) definitely is available (and is used every now and then when automatic selection is enabled).

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
+COPS: (2,"NOVA","NOVA","20210",7),(1,"vodafone GR","voda GR","20205",7),(1,"GR COSMOTE","C-OTE","20201",7),(1,"WIND GR","WIND","20210",12),(1,"GR COSMOTE","C-OTE","20201",12),,(0-4),(0-2)

Note that Wind and Nova are the same operator. Meaning that Cosmote is available as 4G and 5G, Nova is available as 4G/5G and Vodafone is only displayed as 4G. At the time of scan the modem was connected to Nova.

Selecting the Wind 5G network causes the following error, and the process is aborted.

Doing the same manually:

root@GL-X3000:~# time gl_modem -B 0001:01:00.0 AT 'AT+COPS=?'
+COPS: (2,"NOVA","NOVA","20210",7),(1,"vodafone GR","voda GR","20205",7),(1,"GR COSMOTE","C-OTE","20201",7),(1,"WIND GR","WIND","20210",12),(1,"GR COSMOTE","C-OTE","20201",12),,(0-4),(0-2)
root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS=4,2,"20210",12'
OK
root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS?'
+COPS: 0,2,"20210",13
OK
root@GL-X3000:~# gl_modem -B 0001:01:00.0 AT 'AT+COPS?'
+COPS: 1,2,"20210",13

Note that the scan returns mode 12 being available, and the GUI shows this as ‘5G‘. That is incorrect. Mode 12 is 5G-SA, while mode 13 is 5G-NSA. The scan command does not distinguish these two technologies and only returns 5G-SA.

However this does not mean that my sim is allowed to attach to 5G-SA. In this case, I am roaming, 5G-SA is not allowed - and I can only use 5G-NSA. When manually locking to 5G-NSA it works fine.

So, a few issues:

• The scan command only reports the 5G-SA networks. That means that Vodafone 5G-NSA (Vodafone does not offer 5G-SA!) is not displayed at all in the overview. But it also means that the GUI page does not show 5G networks, it only shows 5G-SA networks.
• When locking to one of the PLMN/Technologies using the GUI, the lock will be to the technology that was returned by the scan (12 in this case). That technology may not be supported/allowed by the service, resulting in the error above.
• It does not seem to be possible to scan for 5G-NSA networks specifically.

I would propose three updates to the GUI:

1. When scanning, display all networks having technology ‘12‘ specifically as “5G-SA“ instead of just 5G like they are now. The scan result shows technology-12, which is 5G-SA specifically. That should be distinguished for clarity.
2. When scanning, display all 4G networks twice: Once as a 4G network (already the case), and once as a 5G-NSA network. When locking to the 4G network use technology 7 (4G), when locking to the 5G-NSA network use technology 13 ( = 5G-NSA / 4G fallback).
3. When scanning, also display each unique PLMN without technology. Choosing this would lock to the operator only (omitting the technology setting), meaning simply the highest available technology is used. This is probably what most people are looking for.

Would appreciate your feedback. In my opinion the currently implemented logic is incorrect; you effectively can only scan and select 4G or 5G-SA networks - but not 5G-NSA (Which is what most people would want to use).

[AI_bot]

Your results isolate two separate behaviors:

• The GUI is treating access-technology value 12 as generic “5G,” although value 13 represents E-UTRA/NR dual connectivity (5G NSA) on this modem.
• AT+COPS=? does not necessarily return a separate NSA entry. NSA depends on an LTE anchor, so displaying every LTE result again as “5G NSA” could incorrectly claim that NR is available. A safer GUI option would be Auto / LTE+NR (NSA allowed) for each PLMN, preserving the modem’s RAT preference and omitting the optional <AcT> value from AT+COPS.

There is a closely related GL-X3000 Operator Lock report in which GL.iNet staff confirmed that the implementation needed optimization and provided a patch for testing. Your exact-command comparison adds useful evidence that the current GUI workflow is selecting the wrong mode for this roaming NSA scenario. The modem update clearing the previous operator selection is also expected after rewriting/resetting the modem firmware and is separate from the GUI issue.

This reply was generated by AI. Please verify its accuracy.

GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.

[Xandrios]

This seems to be a similar case. The suggested solution there matches with my proposed update #3. Happy to see that this seems to be coming soon (?).

However I still do believe that the scan results should be displayed more truthfully. meaning networks that are reported back as technology=12, should be displayed as 5G-SA. As that is the exact technology that you would be locking to.

And I would appreciate an option to lock to 5G-NSA (technology=13). Since in some cases, like when roaming - or using a travel esim like this - 5G-SA is simply not allowed by policy. The modem supports this, so why not make the choice available to the user?

[AI_bot]

Labeling access technology 12 as 5G SA / NG-RAN would be more precise than the current generic 5G label. A separate 5G NSA (LTE–NR dual connectivity) choice could use value 13, but it should be presented as a requested registration mode—not as proof that the scan detected NSA availability, since AT+COPS=? may report only the LTE anchor.

An Auto / operator-only choice that omits <AcT> remains the safest default, while explicit LTE, 5G SA, and 5G NSA options would serve advanced cases such as roaming restrictions. The related topic confirms that staff tested an adjustment and mentioned inclusion in a future firmware update, but it does not provide a confirmed version or release date.

This reply was generated by AI. Please verify its accuracy.

GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.