Hello, @zinz @Joro711 @anes @wahlendm
Thank you.
Hello,
Mowt of us[quote="maikfield, post:1, topic:53134, full:true"]
Hello, good morning.
A few days ago, I installed the beta for Flint 1 and I am experiencing many issues with getting the network to function properly. I have tried resetting the routers and configuring them from scratch, but the errors persist. The router loses connection, drops Ping packets intermittently, and devices lose connectivity after a day, requiring a router restart. Additionally, IoT devices (like Home Assistant) lose information because they lose connectivity. Is there anything that can be done to resolve this?
If any specific information is needed, I can provide it without any problem.
[/quote]
Most of us as you can see downgraded to 4.6.8 or 4.6.11 . And as you can see it is a systemic problem. With PpOa disconnection and restarts. I think the router was flooded with multiple requests
Hello,
We did not reproduce this issue on AX1800 with v4.7.0.
This is my topology and setup steps. If there is a difference with yours, please let me know your topology and how to reproduce the issue.
As this issue needs to be reproduced locally before it can be checked.
Internet --- (cable) --- Brume 2 --- (cable) --- Flint 1 --- (cable) --- PC
I--- (wireless) --- Phones
Flint 1 upgrade to v4.7.0
Flint 1 WAN port connected to Brume 2, and all clients networks are normal
Flint 1 change the Network Mode to Access Point, all clients networks are normal, PC ping phone is normal.
Hello,
Good morning!
We attach great importance to this issue, and we'd like to know your network topology graph, wireless configuration, and issue syslogs.
Please let us know the MAC address of the IoT device, we will check this device in syslog, and is it 2.4G or 5G WiFi connection?
Here are the basics of my config. AP mode, using the advanced config page to enable a guest wifi network that relies on a 2nd VLAN. I doubt everyone else with the issue on this thread is doing the same thing.
My guest network is only 2.4GHz. I have my regular network on both 5GHz and 2.4GHz.
Soon after the upgrade to 4.7.0 (without resetting the settings), my network began experiencing problems. The problems worsened with time. At one point, while on a wifi connection, I could not ping host "b" on my network, but I could SSH into host "a" and then SSH from host "a" into host "b". Later, I manually assigned an IP to my host and after I connected to wifi, I could not ping anything. So it seemed like the radio interface was working, but I did not have access to a wired host at the time to test access to the wired interface. I have a few network switches connected and all of them were blinking fiercely at the time of the issues. I checked the packets-per-second as seen by a wired device on my network and it was nominal. Whatever the root cause was, it was causing the ARP tables on the switches to be messed up, I suspect. That is probably what was causing the strange behavior where some hosts could be pinged, but others could not.
At the time of the incident, my guest network was more reliable than my regular network. Once I could get a DHCP IP assigned, I seemed to be pretty solid. But if I disconnected/reconnected a few times, the DHCP requests would timeout and my client would be offline.
One last thing, I did try completely resetting the settings on my access point and reconfiguring it. The problem was not immediately evident, but once again over time it did present itself. I could trigger it simply by disconnecting/reconnecting to different SSIDs a few times until the DHCP requests just stopped being answered.
My setup is pretty much vanilla to the factory firmware, no additional plugins or enabled services. I use it as the perimeter firewall for the network. I have both wifi channels disabled and only use the wired ports.The Wan port is plugged into a fiber ONT with a static ip, one lan port is plugged into a google nest pro, providing home wifi, and the other into a cisco switch that provides network services. On the ax-1800 lan I have approx 12 dhcp reservations and about 6 port forwards for mail, web, ssh, plex and minecraft. Outside of that I have not enabled/disabled anything that is not present on the factory firmware. As this is my main network, I will have to plan to upgrade where a a span of outages is tolerable to get you logs.
To note, I did try the 4.7.0 upgrade twice, first through the gli auto upgrade. Factory reset the router, downgrade to 4.6.11 and set bare network requirements and then reupgraded to 4.7.0. The issue existed both times, so i downgraded and stayed on 4.6.11.
As I already wrote, I bought this router a year and a half ago with the idea of using it mostly for the WireGuard server feature. I set it up right from the start and then the router just worked. I only applied the new updates from time to time and everything was fine. And so on until the ill-fated version 4.7.0. The device became unusable and only rolling back to the previous version restored it. I also had some plugins installed, but there was never a problem with them.
I also have problems with the AX1800 after updating to version 4.7 — it’s very unstable and keeps disconnecting.Some time ago, I already updated to version 4.7 in the beta release and had the same issue. I thought it was just a problem with the beta, but the current 'stable' version is also unusable.
Hello,
Please let me know what the interface is unstable and keep disconnecting, WAN, LAN, WiFi?
Please share the issue syslog with us when the interface (like WAN) is disconnecting.
It seems that the topology is not complicated. For that Flint 1, it is a wired connection: WAN - Flint 1 - LAN, Flint 1 PPPoE dialing, right?
Sorry, it has caused inconvenience to your use.
Please reproduce this issue and get the syslog.
We think little strange, that it did not reproduce in our lab.
When the issue reproduced, please export the syslog and share the issue syslog with us. Thanks.
Hello,
Please share the issue syslog with us. Thanks.
With this topology image, I tested on the iPhone to reconnect the AX1800 WiFi with multi-times, the DHCP IP offer and Internet is stable.
Hello,
R&D has confirmed this issue, and found that the program exceptions, it is from the repeater password verification program.
We will resolve this issue in the next firmware version for AX1800.
Here is the workaround for the AX1800 v4.7.0 firmware:
hostapd-common_2021-02-20-59e9794c-55_aarch64_cortex-a53_neon-vfpv4.ipk and wpad-openssl_2021-02-20-59e9794c-55_aarch64_cortex-a53_neon-vfpv4.ipk in the /root directory of the router through WinSCP
cd /root/
opkg remove wpad-openssl && opkg install wpad-openssl_2021-02-20-59e9794c-55_aarch64_cortex-a53_neon-vfpv4.ipk && opkg install hostapd-common_2021-02-20-59e9794c-55_aarch64_cortex-a53_neon-vfpv4.ipk --force-reinstall && /etc/init.d/repeater restart
I did the 4.7.0 update on one of my GL-AXT1800(Slate AX) travel routers and hooked it up to my fiber as the main firewall. I upgraded ~11:25amCDT and by 12:15ish-12:27ish I had 3 instances of full internet down including the wired lan port connection to the router and gl interface. It took about 15 minutes or so before the router network was up long enough for me to grab the logs. Though whatever is going on with this issue does not seem to be logged as far as I can tell. What I can say is that the router is not fully rebooting during the issue as when I finally got back into the router, it said its uptime was 50 minutes, which would coincide with the 4.7.0 upgrade reboot. Hopefully you can see something in the logs I did not.
logread.tar (127 KB)
For some additional info, here are the logs from my network switch during the issue, it is in GMT(-5) for CDT. The 16:31(GMT) was the reboot after the firmware upgrade:
Apr 11 16:31:04.408: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 16:31:05.409: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 16:31:08.264: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 16:31:09.264: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:25:14.824: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:25:15.825: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:25:21.889: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:25:22.889: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:25:26.942: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:25:27.942: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:25:30.848: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:25:31.848: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:25:38.941: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:25:39.943: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:25:42.905: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:25:43.906: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:29:51.597: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:29:52.598: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:30:02.965: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:30:03.965: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:30:08.014: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:30:09.015: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:30:11.980: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:30:12.980: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:30:20.705: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:30:21.706: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:30:24.612: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:30:25.612: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:31:34.396: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:31:35.397: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:31:38.245: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:31:39.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:37:04.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:37:05.032: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:37:14.940: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:37:15.940: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:37:20.393: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:37:21.393: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:37:24.301: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:37:25.301: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:37:32.220: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:37:33.219: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to down
Apr 11 17:37:36.126: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/45, changed state to up
Apr 11 17:37:37.126: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/45, changed state to up
Apologies if I'm hijacking the thread but I need to chime in on this..
I have a flint 1 downstairs and a flint 2 upstairs. They are connected via ethernet cable. They both run 4.7.0. They run my IoT devices, downstairs flint runs the downstairs devices and the upstairs flint runs the upstairs devices. They run their own subnets. Makes sense right?
The downstairs flint can access ALL devices, up and downstairs without issues.
The upstairs flint intermittently can't see the downstairs devices and some of the upstairs devices appear offline ONLY on the upstairs flint.
If I switch to the downstairs flint all devices jump back into life and are actually connected to the upstairs flint without issues.
The configurations are exactly the same as they were in 4.6.8 when it ran flawlessly for both. So it appears to be a new problem with 4.7.0.
I do have NAT activated on both but what I found was if I turn off NAT SIP the problem exists but not as bad and only a few upstairs devices will appear as offline on upstairs flint and downstairs flint can still see all devices without issues.
More than likely I accept it's probably me misconfiguring the upstairs router but if that was the case then I would have ALWAYS had the issue even on 4.6.8.
This is completely baffling me.. It must be a firmware change somewhere in 4.7.0 that is causing this issue because no matter what I change the problem persists and I don't want to delve too deep because I know how easy it is to 'Medusa' these devices via Luci..
I hope this helps devs somewhat..
Honestly, this is beginning to feel like a traffic load issue with 4.7.0. I have a tv device Nat'd behind a GL-AXT1800(Slate AX) using openVPN, it's the only device and for the most part seems relatively unaffected by the 4.7.0 upgrade. I did notice a interface drop a few times as well as when I swapped the permitter router as noted above. I'll attach its logs. But like I said it takes days for this router to do something odd vs just minutes for one that has 20 devices on it and a lot of traffic.
logread (1).tar (129 KB)
Hello,
Thank you for providing 2 syslogs.
The first log has no exception information, and the router OS does not crash.
After restarting, the syslog will be lost.
You can SSH to the router, and execute logread -f, and may be able to observe what printing is in the system or kernel before the network exception, but we may only guess what the reason is.
The second one is mostly VPN logs, but we found it has "eth1 down -> up" appears. Did you manually replug the network cable?
It seems that there is nothing strange about your topology. For Flint1, it is a wired WAN in - Flint1 - LAN out. We will try to reproduce on local.