Spitz AX not allowing through traffic, cellular modem online

Just received my new GL-X3000NR Spitz AX 5G, hoping to upgrade from my old Spitz GL-X750C4. This will be my third GL.iNet product. Followed the instructions, pulled the Tmobile SIM from the old Spitz and inserted it into the new one. Connected my laptop to the Spitz AX with an ethernet cable on the router’s LAN port and went into the Admin panel, expecting a pretty similar experience versus prior devices. Did the automatic setup for the SIM, and it appeared to go online.

Beyond that though, I haven’t achieved any actual communication from any connected device (laptop or phone), and only minimal communication (pings) from the router itself to the outside world. At first it seemed like my problem was the same as being discussed in a previous thread I found here (the site is preventing me from including a link), but my problem appears to be very different.

In fact, this site is presenting an error message that I “can only post with 2 links” in response to trying to post a message that now contains zero links. Hopefully I can post the above paragraphs and paste the rest of the message in comments…

First, a strange symptom, which might be an unrelated issue: Whenever I connect to the router with the ethernet cable, or when the router reboots while connected, a window spontaneously appears which in the title bar appears to be a prompt for a “hotspot login”, except in the content of the window all I see is an nginx 404 error. This is unexpected and inappropriate, as there is no hotspot connection involved (wifi is turned off on the laptop; I’m only connecting to the router with ethernet). I would not expect a portal login as a default configuration even if I were connecting to the router via wifi. No other option but to close the window.

When I’m connected to the router, I’m getting a 192.168.8.x address via DHCP as expected, and I’m getting a reasonable route assignment to send outgoing packets through the router. But I can’t communicate with the outside, at all. Pings to Google and Cloudflare DNS servers (8.8.8.8, 1.1.1.1) fail, no response. When I try to browse to a website from the laptop, all attempts fail when for some reason my browser (no matter what site I browse to) attempts (and refuses) to verify the router’s own self-signed cert.

I go into the advanced OpenWrt (LuCI) settings and use the dialog to ping; by default it sends pings to openwrt.org. That hostname resolves to 192.168.8.1 (the router itself) and they echo immediately. Why/how is openwrt.org resolving to the router’s own IP?

So I log in to the router via SSH, and from the command line I ping other hostnames, like google.com, yahoo.com, whatever – they all resolve to 192.168.8.1. DNS isn’t exactly “failing” at least not in the normal way – I’m not getting a pause followed by an error when it can’t resolve the name. Name resolution is completing immediately and it starts to ping, thinking that 192.168.8.1 is the correct address for any hostname.

From that SSH login, I can ping 8.8.8.8 and 1.1.1.1, and that works, sort of. Ping times can at some times vary between 60 and 220 ms (seeming pretty consistent), and at other times they can vary from milliseconds up to 2 to 3 seconds in erratic bursts. The modem does appear to be online and communicating though. But it seems like it isn’t forwarding packets between its interfaces and I’m prevented from pinging from the laptop.

DNS issues aside (let’s tackle that separately), why would the router have a default configuration that doesn’t forward packets? I should be able to ping 8.8.8.8 from my laptop through the router, when the cellular interface is up and I can ping from the router itself, right?

Current running firmware is 4.0 release50402, 2023-09-08.

I’ll end with a possible clue that the network connection with Tmobile may not be totally correct; it looks very different from what it looks like on the old Spitz and I’m not sure what to make of it. While it does look like it’s communicating with the SIM card (it correctly reads the service line’s phone number, and it sees that it’s connected to Tmobile), it’s getting a very different IP address (192.0.0.2, with a gateway of 192.0.0.1). I guess this might be due to it using a 5G connection rather than LTE (?) but maybe it means something. Also the modem is unable to fetch its own firmware updates; I had to update locally.

I’ve just tried putting the SIM back in the old Spitz X750 – still works fine (gets a 25.92.x.x IP from Tmobile).

Ah – I see what was going on. It decided to turn bare hostnames into links on its own and counted them against me.

At any rate, any thoughts? Really surprised that this didn’t “just work” out of the box, as it’s been my experience in the past.

Some new information – I’ve found that the IP address seems to change over time, and sometimes with reboots – sometimes it gets 192.0.0.2, and sometimes it’s 25.x.x.x like I’m familiar with. It does not affect the (mis)behavior of the router, and these seem to be legitimate assignments via DHCP, according to what I see in the syslog.

Speaking of which, I’m going to try to attach the system logs here in case it’s helpful.
logread.zip (33.7 KB)

Hi manualdidact:

—>It will disable the network before the password is initialized.
uci show glconfig
uci show dhcp
uci show firewall

—>The allocation of this IP mainly depends on the allocation rules of the base station.
According to the log message, the router is getting 25.x.x.x:

It will disable the network before the password is initialized.

I’m not sure I understand what this means. Of course, setting the administrative password is the first thing I did after I first turned the router on, as part of logging in for the first time.

uci show glconfig
uci show dhcp
uci show firewall

I’ve run these commands, output is attached.
ucishow.zip (2.8 KB)

I agree at this point that the router’s DHCP client is probably not the problem; the addresses it is receiving from Tmobile appear to be legitimate.

I checked your text,It shows that the password is not initialized.
So Because of these rules, it will direct all network addresses to 192.168.8.1.
After password initialization, these rules will be deleted.


image

I checked your text,It shows that the password is not initialized.

Can you please explain what this means – password is not initialized. What steps are required to “initialize” a password, besides setting the password the first time I use the product? I have set the admin password to a series of characters and digits, as I normally do. As I said before, this was the first thing I did after powering on the device the first time and connecting to it from my laptop.

I use this password (the one I have set) to log in to the router’s web interface, and also to log in as root via SSH. I don’t understand how I could even use the product without setting the password.

If this is different from “initializing” the password, please help me to understand what that means.

It need to configure the password on the web page first.

Ok, so this is exactly what I have already done, as I’ve now described several times This is one of the first screens I saw when I connected to the device for the first time. There is no way to get past this screen (i.e. no “Cancel” or “Skip” button, etc) – that is, no way to get to the admin screen or do anything else with the product without doing this step.

So, this is not the problem. I set the password when I first connected to the device. I have been using this password since then.

Just to clarify the file configuration here, it means that there is no password initialization action.

Do you still have issue with Internet use?

it means that there is no password initialization action

We can keep going back and forth here, but it seems that there is little point to it. What you are saying is simply false. The password was set. I could not have gotten into the administration screens without setting the password, which should be obvious. The network configuration change that should happen after setting the password apparently did not occur.

The next thing I am going to try will be to do a firmware reset on the device, so that I can go through the process again. I am not able to do this now but I will post again here when I can, perhaps for the benefit of anyone else reading this thread. Maybe it will work differently, since the device now has a different version of the firmware on it, than what it had when I first set it up.

I assume I am not getting any further help from GL.iNet on this issue. This has been a very disappointing experience so far.

We don’t seem to agree on the above questions:
1,Why is the domain name resolved to 192.168.8.1?
—》This may be caused by the initial failure of the web page.
—》According to the configuration file information you provided, it does indicate that the web page did not initialize successfully。

2,Why do devices occasionally get ‘192.0.0.2’?
—》This ip change is due to the carrier’s allocation decision.

If it is convenient for you, you can share this device with the account ‘gl.inet_support’ through the cloud platform. Can I remotely check it?

The only significant thing I think we’ve disagreed on up to this point is about having set the password. I definitely did this, and it’s not something I could really be confused about since I have used that password to log in multiple times (on the website and via SSH) while trying to figure all this out.

I agreed the IP address was being appropriately set, in my response on Oct 8 (CDT):

the addresses it is receiving from Tmobile appear to be legitimate.

Since my last message I did perform the firmware reset, and was presented with the same screens I saw the first time. The first screen requested I select a language, and the next forced me to set my password. I did this, and fortunately it appears to have worked correctly this time. After doing the automatic SIM configuration, it took a minute or two and connected to the internet with no further work on my part (similar to what I’ve experienced with other products in the past, like my older Spitz). The router is working as expected.

Unfortunately, this means we probably won’t get to find out what was wrong. I can’t remember exactly but I vaguely recall that the original firmware (before I upgraded it while troubleshooting) was from June of this year, so it may have been “Version 4.0-release50303” – this might be relevant to the problem, or it might not. I don’t have any other useful information, and it probably doesn’t matter.

I’m glad it’s working now.

We have tested and repeated this problem. It should be that the router immediately restarts after setting the password.It causes some configurations to be lost and does not take effect.We will fix this bug as soon as possible.

Tank you very much.