Gl-X3000 no roaming germany

@lizh thanks!

I am happy to share the router with your support. On the GoodCloud platform I can’t find any way to link this to the support. I would be happy to set up Wireguard access and send you the data by email.

Also I have added the router to the GoodCloud service. The ID is trfc16c.

Unfortunately, the router cannot be linked to an existing Internet connection via WAN because I am on the road. But I connected it to a WLAN as an amplifier.

please confirm this solution, thank you

Hi saho1:

It need to lock the LTE band first, and then lock the corresponding LTE tower.

gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWPREFCFG="mode_pref",LTE'
gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWLOCK="common/4g",1,1444,387'

Thanks!

1 Like

@lizh

That was it! Great job and tank you very much!

When I leave this area I have to reset the modem to the normal settings.
I’ve tried the command

gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWLOCK="common/4g",0'

to reset the lock to the cell, but that hasn’t any reaction.

What ist the command to reset the modem to the default settings?

Greets

Saho

It need to exec command:
gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWPREFCFG="mode_pref",AUTO'

Hey there @lizh! Thanks for all your help here! :pray:t2:

I was having more or less the same problem here in Finland on Telia, using an Estonian Telia sim card. (it’s a super common scenario here in the nordics, you can use your Telia sim across Estonia, Finland, Sweden, Denmark, Norway etc, as if it’s local, with unlimited data on 5G etc)

I’m more or less across the street from a 5G tower here, yet every ~10-15 minutes or so, GL-X3000 kept falling back to WCDMA, and stuck there until I rebooted the router. On reboot, automatically connected to 5G NSA as expected.

To fix it and to get the GL-X3000 to stay connected to 5G NSA, I had to send :

gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWPREFCFG="mode_pref",LTE:NR5G'

then send :

gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWLOCK="common/5g",XXX,XXXXXX,30,78'

Exposing these mode_pref options + locking to the dashboard would make things so much more convenient for those who aren’t familiar with AT commands! I saw on the forum that you’re already working on this for the next firmware update, so just wanted to stop by to say thanks and chime in with my use case as well.

And not 100% sure if it’s related to this or not, but every now and then, the router still loses connection. To my sheer luck it happened a few minutes after posting this. So updating with the logs. Here’s what I see in the logs when that happens :

Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:06:50:268] requestRegistrationState2 MCC: 244, MNC: 91, PS: Attached, DataCap: 5G_NSA
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:24:03:950] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:24:04:468] requestRegistrationState2 MCC: 244, MNC: 91, PS: Attached, DataCap: 5G_NSA
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:24:05:478] requestSetupDataCall WdsConnectionIPv4Handle: 0x1ac813d0
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:04:625] requestQueryDataCall IPv4ConnectionStatus: DISCONNECTED
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:05:640] requestSetupDataCall QMUXResult = 0x1, QMUXError = 0xe
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:05:640] call_end_reason is 3
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:05:640] call_end_reason_type is 3
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:05:640] call_end_reason_verbose is 2001
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:05:640] try to requestSetupDataCall 5 second later
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:09:324] requestRegistrationState2 MCC: 244, MNC: 91, PS: Detached, DataCap: UNKNOW
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:25:649] requestRegistrationState2 MCC: 244, MNC: 91, PS: Detached, DataCap: UNKNOW
Mon Jul 31 15:41:30 2023 daemon.notice netifd: modem_0001 (11568): [07-31_15:41:30:393] requestRegistrationState2 MCC: 244, MNC: 45, PS: Detached, DataCap: UNKNOW

And pretty much stays disconnected, unless, again, I send :

gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWPREFCFG="mode_pref",LTE:NR5G'

then send :

gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWLOCK="common/5g",XXX,XXXXXX,30,78'

And the router connects to 5G NSA immediately again, and stays connected for an extended period of time.

Please let me know if you’d like to see anything else from my part, and I would be more than happy to send more info / help in any way I can.

Hi coz:

Thank you so much!

NSA mode doesn’t lock alone,NSA anchors the control signaling of 5G Radio Networks to the 4G Core.

You can try the following to test if you can lock NSA mode:

gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWPREFCFG="mode_pref",LTE:NR5G'
gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWPREFCFG="nr5g_disable_mode",1'
gl_modem -B 0001:01:00.0 SAT sp 'AT+QNWLOCK="common/4g",XXX,XXXXXX'
1 Like

Thank you sooo much @lizh! :pray:t2: — Thank you both for taking the time to respond to threads on the forum so quickly, but also helping teach some of your magic. I’ve learned so much today, and now I understand how all this works too thanks to your kind messages and responses.

That worked!
Connection hasn’t dropped for the whole day and I’ve been on 5G NSA the entire time.

All the very best from Northern Europe :v:t2:

C