RUTX50 - SIM switch every 2 hours and loss off connectivity

I have setup the RUTX50 router with two SIM cards. One SIM card is for a private 5G SA network (n28 and n78) and the other one is for a public 5G NSA network (n28 and n78 + LTE). I have noticed that after FW upgrade to RUTX_R_00.07.11.1 the router does a SIM switch every 2 hours. The modem FW is RG501QEUAAR12A11M4G_04.201.04.201.
I have not configured the router to do SIM switch after any certain time. The primary network to be used is the SIM slot 1 with 5G SA and the secondary is the SIM slot 2 with 5G NSA. I have enabled SIM switch to be done on No Network, On network denied and On data connection fail. None of the criteria’s mentioned for SIM switch are occurring but still a switch happens every two hours.

I disabled SIM switch, but what happens is that when the router is connected with primary SIM in slot 1 (5G SA), then after two hours it looses the connectivity completely.
From the Status → Network → Mobile I can see that the router is registered to the correct network, but the Data connection state is disconnected and the router does not receive any IP address from the network. On the 5G core network side I have configured static IP for the IMSI and it does not use DHCP for changing the IP address. So there is no need for the router to refresh the WAN IP.


The only way to recover seems to be a restart of the router.

Hi…

Did you try another firmware upgrade?
Take a look at log (7.11.3 / 2024.dec.17): RUTX50 Firmware Downloads - Teltonika Networks Wiki

This happens with both RUTX_R_00.07.11.1 and RUTX_R_00.07.11.2. I have not tried RUTX_R_00.07.11.3, but according to the changelog there is nothing there that would affect this behavior.

Hello,

We would like to review the logs from your device to investigate the issue further. A form has been sent to you for this purpose. Once completed, we will contact you privately. Please use the ticket ID “11211” for reference.

Best regards,

Hi…
Can you check at your device about VoLTE?
It is disabled?

I don’t have connection to the routers right now so I am not able to check. If I remember correctly VoLTE is set to Automatic for both SIM cards. I need to verify that once I go onsite to take troubleshooting log from the routers and to recover them.

Hello @MarkusH ,

Could you share a screenshot of your SIM Switch configuration for both SIMs?
If you have them configured, Auto Reboot or any other connectivity-check services configuration would also be appreciated.

In case this issue is not caused by misconfiguration, you could also try disabling IMS services on the device by logging into it’s SSH/CLI and running the following command:

gsmctl -A 'AT+QCFG="ims",2'

Make sure to disable VoLTE before running this command!

Additionally, does your 5G SA SIM have access to the public internet? If no, then make sure to not use AutoAPN on the SIM1 mobile interface and instead specify the APN manually (it uses public well-known DNS servers to verify connectivity).

Best regards,

I have switched off the SIM switch at the moment and only running with SIM1. SIM1 is using 5G SA network that has Internet access. The only network available for SIM 1 is 5G SA. The issue still persists as after a restart the router and SIM1 is connected but after 2 hours the data connection state goes to disconnected and the router looses the mobile network connectivity. VoLTE is switched off. Have tried using both manual APN and automatic APN but both setting gives the same issue.
Firmware is RUTX_R_00.07.11.3.
Internal modem firmware version is RG501QEUAAR12A11M4G_04.201.04.201

Date Connection Type Signal strength SIM slot Network state
30.12.2024 6:02 5G -84 dBm SIM 1 Registered, home
30.12.2024 6:07 5G -82 dBm SIM 1 Registered, home
30.12.2024 6:12 5G -82 dBm SIM 1 Registered, home
30.12.2024 6:17 5G -80 dBm SIM 1 Registered, home
30.12.2024 6:22 5G -83 dBm SIM 1 Registered, home
30.12.2024 6:27 5G -82 dBm SIM 1 Registered, home
30.12.2024 6:32 5G -82 dBm SIM 1 Registered, home
30.12.2024 6:37 5G -83 dBm SIM 1 Registered, home
30.12.2024 6:42 5G -81 dBm SIM 1 Registered, home
30.12.2024 6:47 5G -83 dBm SIM 1 Registered, home
30.12.2024 6:52 5G -84 dBm SIM 1 Registered, home
30.12.2024 6:57 5G -84 dBm SIM 1 Registered, home
30.12.2024 7:02 5G -82 dBm SIM 1 Registered, home
30.12.2024 7:07 5G -82 dBm SIM 1 Registered, home
30.12.2024 7:12 5G -82 dBm SIM 1 Registered, home
30.12.2024 7:17 5G -82 dBm SIM 1 Registered, home
30.12.2024 7:22 5G -83 dBm SIM 1 Registered, home
30.12.2024 7:27 5G -82 dBm SIM 1 Registered, home
30.12.2024 7:32 5G -81 dBm SIM 1 Registered, home
30.12.2024 7:37 5G -79 dBm SIM 1 Registered, home
30.12.2024 7:42 5G -83 dBm SIM 1 Registered, home
30.12.2024 7:47 5G -81 dBm SIM 1 Registered, home
30.12.2024 7:52 5G -82 dBm SIM 1 Registered, home
30.12.2024 7:57 5G -80 dBm SIM 1 Registered, home
30.12.2024 8:03 5G -,-,-,-

Update on this issue. The same issue is also seen with SIM2 that is using public 5G/LTE network. The router stays connected 2 hours after a restart and after that the data connection is disabled. I have now two RUTX50 routers that are behaving this similar way. Both are on the latest FW.

Hi…

So… two RUTX have the same issue?? Sorry… I just a tech/nerd guy… But, I don’t believe that is a hardware/software issue… because happen with two devices, maybe I am wrong…

Can you test with anoher sim card from another telecom?
Use one sim card from telecom A in rutX_a
and
use another sim card from telecom B in rutX_b ?

Just some ideas…

From the system.log file the following can be seen. After device restart the modem is connected to the 5G SA network at 02:02:09. After about two hours the data connection goes disabled at around 04:02.
578 Mon Dec 23 02:02:09 2024 kern.info Mobile data connected (internal modem)
579 Mon Dec 23 02:02:09 2024 kern.info Joined 5G-SA network (internal modem)
580 Mon Dec 23 02:02:09 2024 kern.info Connected to NokiaCoreSaaS operator (internal modem)
581 Mon Dec 23 02:02:12 2024 daemon.err rms_mqtt[5741]: Mosquitto connected
582 Mon Dec 23 02:02:18 2024 daemon.err rms_mqtt[8131]: Connected to remote host
583 Mon Dec 23 02:02:18 2024 daemon.err rms_mqtt[8131]: Registering device
584 Mon Dec 23 02:02:18 2024 daemon.err rms_mqtt[8131]: Request sent
585 Mon Dec 23 02:02:22 2024 daemon.err rms_mqtt[8131]: Mosquitto connected
586 Mon Dec 23 02:03:04 2024 kern.notice IPv4 connectivity restored
587 Mon Dec 23 03:02:03 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
588 Mon Dec 23 03:32:04 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
589 Mon Dec 23 03:47:05 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
590 Mon Dec 23 03:54:35 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
591 Mon Dec 23 03:58:20 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
592 Mon Dec 23 04:00:14 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
593 Mon Dec 23 04:01:10 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
594 Mon Dec 23 04:01:38 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
595 Mon Dec 23 04:01:41 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
596 Mon Dec 23 04:01:44 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
597 Mon Dec 23 04:01:47 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting renew
598 Mon Dec 23 04:01:50 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: lease lost, entering init state
599 Mon Dec 23 04:01:50 2024 daemon.notice netifd: Interface ‘mob1s1a1_4’ has lost the connection
600 Mon Dec 23 04:01:50 2024 daemon.warn dnsmasq[1939]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
601 Mon Dec 23 04:01:50 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting discover
602 Mon Dec 23 04:01:51 2024 daemon.info dnsmasq[1939]: read /etc/hosts - 12 names
603 Mon Dec 23 04:01:51 2024 daemon.info dnsmasq[1939]: read /tmp/hosts/dhcp.cfg01411c - 4 names
604 Mon Dec 23 04:01:51 2024 daemon.info dnsmasq-dhcp[1939]: read /etc/ethers - 0 addresses
605 Mon Dec 23 04:01:52 2024 kern.info Mobile data disconnected (internal modem)
606 Mon Dec 23 04:01:54 2024 daemon.notice netifd: mob1s1a1_4 (6573): udhcpc: broadcasting discover
607 Mon Dec 23 04:02:22 2024 kern.notice IPv4 connectivity started to fail
608 Mon Dec 23 04:02:43 2024 kern.notice DNS resolution started to fail
609 Mon Dec 23 04:02:55 2024 daemon.err rms_mqtt[8131]: Mosquitto disconnected: Keepalive exceeded
610 Mon Dec 23 04:02:55 2024 daemon.err rms_mqtt[8131]: Connection timeout (60), retrying
611 Mon Dec 23 04:02:55 2024 daemon.err rms_mqtt[8131]: Mosquitto reconnecting
612 Mon Dec 23 04:03:56 2024 daemon.err rms_mqtt[8131]: Connection timeout (60), retrying
613 Mon Dec 23 04:03:56 2024 daemon.err rms_mqtt[8131]: Mosquitto reconnecting
614 Mon Dec 23 04:04:57 2024 daemon.err rms_mqtt[8131]: Connection timeout (60), retrying
615 Mon Dec 23 04:04:57 2024 daemon.err rms_mqtt[8131]: Mosquitto reconnecting
616 Mon Dec 23 04:05:58 2024 daemon.err rms_mqtt[8131]: Connection timeout (60), retrying
617 Mon Dec 23 04:05:58 2024 daemon.err rms_mqtt[8131]: Mosquitto reconnecting
618 Mon Dec 23 04:06:59 2024 daemon.err rms_mqtt[8131]: Connection timeout (60), retrying
619 Mon Dec 23 04:06:59 2024 daemon.err rms_mqtt[8131]: Mosquitto reconnecting
620 Mon Dec 23 04:08:02 2024 daemon.err rms_mqtt[8131]: Reached max connection attempts (5), exiting

I found a similar issue in the forum " RUTX50 continous lose of wan ip"
I implemented the solution for to that issue, and now the both routers have been running connected for more than 2 hours.

Adding the line option dhcp ‘0’ to the config interface ‘mob1s1a1’:

  1. Log in to your router via CLI (more details here: Command Line Interfaces)
  2. Run the command vi /etc/config/network
  3. Locate config interface ‘mob1s1a1’ and press “i” to enter edit mode
  4. Add the line option dhcp ‘0’ under the mobile configuration section
  5. Press “Esc”, then type :wq and hit Enter to save and close the file

Seems there has been some changes what comes to the dhcp for the mobile interface. And I would say that those changes have been implemented in either the device or the modem FW as the only changes done prior to first observing the issue was a FW upgrade. Before that the routers had been running without any issues for several months.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.