I have an X3000 that will sometimes switch to SIM 2 - which is empty - after a power cycle. I've seen some other posts - mostly involving various crash scenario - where people say they have seen this. Is this issue more prevalent, and is there a way to force the X3000 to stay on SIM 1 as there's really only 1 SIM. Auto switch is not enabled. Currently running 4.4.13, though it has happened on earlier versions.
hey @n2qew
When switching card slots during startup, you will see a switch to SIM2. Will it still automatically switch to SIM1 in the end
No it does not switch back to SIM 1. The symptom is no cellular communications after power was interrupted to the unit and then restored. Had to log in to it and select SIM 1.This is not the first time it's happened. It's also happened on a prior release. Also, I have seen other reports of this on the forum.
hey @n2qew
I have tried multiple times locally but have not reproduced this problem. When you reproduce this problem,
cat /etc/config/glmodem
To check this issue, can you share your device by following the steps below? Thanks
Technical Support via GoodCloud.tar (192 KB)
I cannot reproduce it at will either. It's a problem when power it randomly interrupted to the units, and it just doesn't resume being visible. To recover requires getting within WiFi range of them, or connecting to the LAN side. When you look at the radio status, it says SIM not registered, and that it's trying to use SIM slot 2, which has no SIM. It's definitely not an "every time" thing.
Which carrier's card are you using
T-Mobile - business. Nothing done to lock sites, or mask channels.
Okay, in order to debug this issue, I need to replicate the scene to verify my hypothesis. If you encounter it again, be sure to
cat /etc/config/glmodem
The same thing happens to me also, in fact today it happened. SIM 2 is empty. I power cycled the Spitz, when it starts up, it tries to connect to SIM 2 for some reason, when it can't, I see it changing Sims, then connecting to SIM 1. If it keeps happening, I will just put SIM 1 SIM card, into SIM 2 slot.
hey @blancmange
Can you cat /etc/config/glmodem and share the results
1 Like
I'll pm the results.
I will do that when it happens again. As I explained, it happens after a power cycle. These are continuously powered, so power interruptions are infrequent. But having it go offline with no way talk to remotely results in having to drive to the site that it happens at. I also see a subsequent message from another user who observes the same. In my initial post, I explained that I see other posts on the forum where others experience this happening. As a point of reference, I am posting from my modem - the one I personally use at home. Sensitive info - MDN, ICCID, etc - cut short or replaced(MDN), but I wonder if what I see is what you are thinking... That I previously had a SIM in slot 2 - it's not there now, it wasn't there when this last happened and the unit hasn't been defaulted since - so it "thinks" maybe it should use that slot. You will also notice that I'm currently running the most current beta. My unit - the one I pasted from - was actually running the latest non-beta when this last happened.
root@192.168.8.1's password:
BusyBox v1.33.2 (2024-12-27 09:03:17 UTC) built-in shell (ash)
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -| || | | || || |
|_____|| |||||___||| |____|
|| W I R E L E S S F R E E D O M
OpenWrt 21.02-SNAPSHOT, r15812+908-46b6ee7ffc
root@GL-X3000:~# cat /etc/config/glmodem
config global 'global'
option log_level '0'
option sim1_apn_polling '0'
option sim2_apn_polling '0'
config switch 'sim'
option sim_num '1'
config signal 'signal'
option enable '1'
option signal_capture_interval '10'
option signal_capture_cycle '1800'
option signal_cloud_cycle '300'
config slot 'modem_0001_dual'
option enable '0'
option timing_enable '0'
config network 'network_sim2'
option apn 'fast.t-mobile.com'
option proto 'qcm'
option device '/dev/mhi_QMI0'
option auth 'NONE'
option metric '40'
option roaming '1'
option band_enable '0'
config slot 'modem_0001_dual_sim2'
option carrier 'T-Mobile'
option iccid '89012604087xxxxxxxx'
config modem 'modem_0001_traffic_limit'
option save_to_flash '0'
config network 'network_sim1'
option apn 'fast.t-mobile.com'
option proto 'qcm'
option device '/dev/mhi_QMI0'
option metric '40'
option roaming '1'
option band_enable '0'
config slot 'modem_0001_dual_sim1'
option carrier 'T-Mobile'
option phone_number '15188675309'
option iccid '89012604077xxxxxxxx'
root@GL-X3000:~#
@n2qew I'm in the same situtation as you, SIM 2 used to have a SIM in, even though it's empty now, the Spitz still tries to connect to SIM2 as it has old APN settings still arroneously associated with it, @Jane is aware, and hopefully will provide a solution.
I wonder if editing that file to delete SIM 2 references will help. Or, maybe nuke - rename - the file and then get on the web interface to get it to use SIM 1 will recreate it with no SIM 2 references?
hey @n2qew @blancmange
can you share your device by following the steps below? Thanks
Technical Support via GoodCloud.tar (192 KB)
Device shared. Instructions say to provide the password and mac. Is there anything to the question I asked about the config file having reference to a second SIM and maybe deleting that?
Device also shared, and if you could lidly diagnose why the tailscale exit node keeps crashing every hour..
I have to SSH into the router each time to do...
tailscale up --accept-routes --advertise-exit-node
Although I am seeing the following in the logs, I hope I dont have a failing Ethernet chipset or theres a bug with the firmware?
Thu Jan 16 14:00:33 2025 daemon.info avahi-daemon[4763]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.40.71.
Thu Jan 16 14:00:33 2025 daemon.notice netifd: Interface 'wan' is disabled
Thu Jan 16 14:00:33 2025 daemon.info avahi-daemon[4763]: Interface eth0.IPv4 no longer relevant for mDNS.
Thu Jan 16 14:00:33 2025 daemon.info avahi-daemon[4763]: Interface eth0.IPv6 no longer relevant for mDNS.
Thu Jan 16 14:00:33 2025 daemon.info avahi-daemon[4763]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe60::48d2:beff:fe12:4c69.
Thu Jan 16 14:00:33 2025 daemon.info avahi-daemon[4763]: Withdrawing address record for fe80::65d2:c4ff:fe22:4c19 on eth0.
Thu Jan 16 14:00:33 2025 daemon.notice netifd: Interface 'wan' is enabled
Thu Jan 16 14:00:33 2025 kern.info kernel: [106854.557935] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/2500base-x link mode
Thu Jan 16 14:00:33 2025 kern.info kernel: [106854.603915] hook is going to be disabled !
Thu Jan 16 14:00:33 2025 user.notice mwan3[29877]: Execute ifdown event on interface wan (unknown)
Thu Jan 16 14:00:33 2025 user.info mwan3track[11161]: Detect ifdown event on interface wan (eth0)
Thu Jan 16 14:00:33 2025 user.notice mwan3track[11161]: Interface wan (eth0) is offline
Thu Jan 16 16:17:28 2025 daemon.notice netifd: Interface 'tailscale' is now up
Thu Jan 16 16:17:28 2025 daemon.info avahi-daemon[4815]: Interface tailscale0.IPv4 no longer relevant for mDNS.
Thu Jan 16 16:17:28 2025 daemon.info avahi-daemon[4815]: Leaving mDNS multicast group on interface tailscale0.IPv4 with address 100.82.103.17.
Thu Jan 16 16:17:28 2025 daemon.notice netifd: Network device 'tailscale0' link is down
Thu Jan 16 16:17:28 2025 daemon.notice netifd: Interface 'tailscale' has link connectivity loss
Thu Jan 16 16:17:28 2025 daemon.notice netifd: Interface 'tailscale' is now down
Thu Jan 16 16:17:28 2025 daemon.info avahi-daemon[4815]: Withdrawing address record for 100.82.103.17 on tailscale0.
Thu Jan 16 16:17:28 2025 daemon.notice netifd: Interface 'tailscale' is disabled
Thu Jan 16 16:17:29 2025 user.notice mwan3[3799]: Execute ifdown event on interface tailscale (unknown)
Thu Jan 16 16:17:29 2025 user.notice firewall: Reloading firewall due to ifdown of tailscale ()
the config network 'network_stim2', this will not affect the switching of card slots, it only saves some configurations from the previous slot 2
Just posting here that I shared the router as requested. I set a time limit of several days before expiry. I got a reply back from Jane after the share expiry saying that access wasn't possible. That means 4 - 5 days went by after sharing and no access was attempted by GL. Something that has to be understood by support is that prior to sharing, it's wise that VPN certs and other 'secret" material has to be removed to prevent intrusion on to the normally connected LAN on the server side - either while the routers are shared, or subsequent access if the VPN access recipe is saved elsewhere. This of course means that the router is not able to be used for it's intended purpose while it's shared. Also, the password for the router had to be shared - after being changed to something other that what it normally is. It's not that I think that GL has bad intentions, but there's no way of knowing how tight the controls on access is after sharing the machine, and the creds. It might be OK to leave it shared for a while if all the router is being used for is endpoint access - like my home router where there's a separate firewall between the X3000 and my home LAN -but my home router hasn't done the unintended SIM swap.
There's not been a SIM in slot 2 ever on mine, and also, it isn't power cycled very often. Based on other response that I've seen, maybe the trigger issue IS that there was a SIM in the second slot at some point, and the router remembers it.
1 Like
Hello,
Truly sorry.
As the Spring Festival and New Year approaches in China, during this period, the respond may not so quickly. Sorry.
We are aware of this problem.
The R&D team is under debugging, and a version of repaired firmware may be released after Spring Festival.
I also left a message to the related people to urge the progress of this issue.
1 Like