Here's the logs
glinet_export.tar (170.9 KB)
openwrt_export.tar (130.1 KB)
Before the problem, did you change the way you used the Internet?
For example, inserting a cable
Now, when the problem occurred, the network configuration changed
I changed nothing. Randomly I just noticed I could not access the Glinet UI and that's how I noticed the issue.
No cables were touched.
Any updates on what happened here?
I have two questions
- Did you replace 'REDACTED' in log?
- Does your sim card change ip every few hours?
I did do that to protect my public IP.
No it doesn't change every few hours.
They were all the same.
hello
Can you comment these lines of code and test them again?
Then check to see if 'modem ip different xxxxxxxxxx' exists in the log
thank you
I just commented out that section and I will monitor the logs thank you.
Oddly since I added this when you told me to i haven't had any issues or seen that in the log.
@ywp
I spoke too soon.
@ywp it finally happened again. Where suddenly it stops advertising routes, and loses a public IP address.
As a reminder I'm running this in passthrough mode.
I had no choice but to reboot it as I couldn't get to the UI to export logs when this happened because it's not advertising routes when it happens.
Attached are the logs I rebooted it around this time
Wed Sep 18 11:10:15
I redacted my IPs partially.
This is the Gateway (Passthrough)
Wed Sep 18 01:48:19 2024 daemon.info avahi-daemon[5031]: Registering new address record for 100.67.REDACTED.REDACTED on br-lan.IPv4.
This is the IP Address (Passthrough)
100.67.REDACTED.PASSTRHOUGH-IP
openwrt_logs.tar (133.1 KB)
glinet_export-9-18-24.tar (146.5 KB)
From the latest log, it is found that cellular has the process of re-obtaining the IP. When a problem occurs, please execute AT+CGPADDR to observe whether the IP has changed. At the same time, share the log with me so that I can further share the problem.Thanks!
reference：
Thank you for update I will keep monitoring it and when it happens I will run the command and report back here.
Sorry, the logread log failed to be decompressed, so please upload it again.Thanks!
@Javon_ma are you able to open the logs this time?
@Dan27212 The log cannot be opened. When decompressing, it prompts that it cannot be opened as a compressed file.After exporting the log from the page, please upload it directly and do not compress it again.Thanks!
@Javon_ma hopefully this works
logs.tar (168.2 KB)
I can open the file with a standard text editor.
As a backup I pasted the logs here
https://dpaste.org/6JycU
Command output from the command you requested is below.
+CGPADDR: 1,"38.0.16.2.16.43.22.45.0.0.0.0.109.150.238.40"
+CGPADDR: 2,"0.0.0.0","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0"
+CGPADDR: 3,"0.0.0.0","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0"
+CGPADDR: 4,"0.0.0.0","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0"
+CGPADDR: 5,"0.0.0.0","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0"
+CGPADDR: 6,"0.0.0.0","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0"
+CGPADDR: 7,"0.0.0.0","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0"
OK
I redacted the IP Address (Passthrough) to IP-ADDRESS and Gateway (Passthrough) to GATEWAY-PASSTROUGH-IP
@Dan27212 I parsed the attached log and found that after the module network was disconnected, it failed to connect again, resulting in the inability to obtain the public IP again. However, the specific reason for the failure needs to be captured and qlog analyzed.
How often does the network disconnect? When the network is unavailable, please execute AT+COPS?, AT+CGPADDR, AT+CGDCONT? to further analyze the problem.
Thanks!
It happens randomly. Sometimes it could be multiple times in a month other times it might take a month or 2.
Do I capture the qlog now or I capture it when the issue is happening?