Currently working from home and using a Slate AX (GL-AXT1800) with firmware Version: 3.214.
This is picking up the 2.4g signal from a TP Link WR841N and using that as WAN.
Local clients are then connected via 5g to the the GL-AXT1800.
One problem I’m having is that the wireless network on the GL-AXT1800 just drops out form time to time. It’s there working fine one minute, the next there is no wifi at all. As in the network just disappears.
One such incident was around 10:30 today. Which was a problem for my work as I was unable to enter to call. I have attached the logs from today. Though looking at it, the log (zip file) only starts from 10:30 so possibly the portion before the Slate was restarted is missing.
I’ve posted below an extract from the log of the TP Link router around the time of this event:
2022-11-23 10:29:55 [5] DHCPD: Recv REQUEST from 04:CF:4B:1F:25:93 2022-11-23 10:29:55 [5] DHCPD: Send ACK to 192.168.0.104 2022-11-23 10:29:56 [5] DHCPD: Recv REQUEST from 04:CF:4B:1F:25:93 2022-11-23 10:29:56 [5] DHCPD: Send ACK to 192.168.0.104 2022-11-23 10:29:56 [5] DHCPD: Recv REQUEST from 04:CF:4B:1F:25:93 2022-11-23 10:29:56 [5] DHCPD: Send ACK to 192.168.0.104 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:30:05 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:30:05 [5] DHCPD: Recv REQUEST from 94:83:C4:20:1D:41 2022-11-23 10:30:06 [5] DHCPD: Send ACK to 192.168.0.100 2022-11-23 10:33:19 [5] DHCPD: Recv REQUEST from 04:CF:4B:1F:25:93 2022-11-23 10:33:19 [5] DHCPD: Send ACK to 192.168.0.104 2022-11-23 10:36:41 [5] DHCPD: Recv REQUEST from 48:60:5F:86:24:8E 2022-11-23 10:36:41 [5] DHCPD: Send ACK to 192.168.0.102 2022-11-23 10:37:57 [5] DHCPD: Recv REQUEST from 50:ED:3C:22:FB:40 2022-11-23 10:37:57 [5] DHCPD: Send ACK to 192.168.0.126 2022-11-23 10:40:02 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:40:02 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:40:02 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:40:02 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:40:02 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:40:02 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:40:02 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:40:02 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:40:02 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41 2022-11-23 10:40:02 [5] DHCPD: Send OFFER with ip 192.168.0.100 2022-11-23 10:40:02 [5] DHCPD: Recv DISCOVER from 94:83:C4:20:1D:41
Looks like the Slate isn’t responding to the DHCP offer for reasons unknown.
Are you running stock firmware on the TPLink, or something else?
One brute force approach would be to assign a static IP on the Slate (not just a static lease on the TP-Link). You could also extend the DHCP lease time on the TP-Link.
Note that my previous post is really just about the DHCP issue - its possible the Slate is doing something more wonky like rebooting or losing it’s wireless connection.
Are you using the slate purely as a wifi extender?
TP Link router which is receiving broadband into the home. This bone stock.
The Slate is connected to this wirelessly. The Slate is connected to a VPN as a wireguard client.
Local laptop then connected to the Slate via wifi 5g.
I have limited access to to the TP Link router but can setup a static address and or extend the lease time to 48 hours. It’s currently only 120mins.
There was just an outage now as I type this around 13:40-13:50. I’ve attached both the log from the Slate which this time I believe captured the event, and the log from the TP-Link.
I would do a clean install and setup on the Slate AX, do not save settings or packeages and do not use a saved config file. When you start wgclient it tries to us Ipv6 to resolve but can’t and starts the process again.
It also seems that the tp-link is multicasting to the Slate AX.
The Slate has a issue Tx/Rx on Channel 2 with bandwidth set to 20/40.
Try another channel and set bandwidth to 20mHz
The Slate AX is disconnecting but I think it is a config error possible do to Firewall 3 to Firewall 4 again.
Do you happen to have anything before that in the logs? It would be helpful to see what comes before the CTRL-EVENT-BEACON-LOSS.
Did the slate start a scan just before what you posted?
The CTRL-EVENT-DISCONNECTED reason is “disassociated due to inactivity” (reason=4), but it sounds like you were passing traffic the entire time while this happened? If you start a ping on the router to an external source, does it ever disconnect? You might try running an extended ping session and see what your overall packet loss is.
What I posted was the whole system.log file downloaded from the slate there was nothing before that.
Since the last post I did a factory reset of the slate (why doesn’t this actually wipe the configs?) I’ve configured it with a manual IP and it had been ok, but this morning again (around 10:40) there was a short period with no internet connectivity (wifi didn’t drop though). When internet access was back, I noticed that the VPN in the router admin panel was “connecting” orange light, rather than green, yet and IPleak.net showed the router was indeed connected to the VPN.
Latest log attached but curiously there is nothing after the event. The log was downloaded from the router at 10:50 but for some reason didn’t record anything after 10:42.
Mmmh, seems there is no evident interference but in any case your 2.4ghz has a higher noise floor than 5Ghz…
I had the exact simpthomps like yours when I used an usb 3.0 flash drive but my noise was about -89dBm.
Depending on what your use case is, you might try out a more stock version of OpenWRT. You can build one using the gl-infra-builder, or I can shoot you my current axt1800 build. I had a lot of difficulty with hotel connections on early versions of firmware, but haven’t had any problems since switching to my own build.
