Slate AX (GL-AXT1800) Wireguard Issue (REKEY-TIMEOUT)

Howdy, I received my Slate a couple weeks ago and got time to get it working today. I pulled in a wireguard config, and upon trying to connect it gets stuck in a loop with a REKEY-TIMEOUT error. I attempted several resolution fixes, but was unable to get them to work (Pulled in config from phone, tried resetting, saving as a file (.conf) and uploading, etc).

I then attempted to try a beta client version (4.0.2), which did not resolve the issue.

As a last resort I upgraded to the beta kernel (5.4), which after briefly knocking the 5Ghz radio offline, immediately connected to the wireguard server and started working.

I then rolled back to the initial firmware (re-downloaded from firmware page), and was back to the REKEY-TIMEOUT issue.

Is there a known issue with the current client/kernel version that has an open incident/ticket and is being worked on? Would love to get wireguard running on the stable channel version.

EZ Format List of Troubleshooting done:

  • Tried config from phone (vice-versa, on phone the config from the slate worked on the phone)
  • Tried saving differently / using .conf format (LF & CRLF)
  • Bumped client release version from 4.0.0 → 4.0.2
  • Finally bumped kernel from 4.4.60 → 5.4 and wireguard started working immediately
  • Rolled back to initial firmware/client and wireguard stopped working immediately
1 Like

Is this your own Wireguard server? How can I test the same?

I am facing exact the same behavior … @alzhao please bring this topic forward. Spent so much money for good hardware. :confused:

Previously you send me a config privately and it does not work in my Windows client as well.

If you have different case can you send me details?

I understand some people met REKEY-TIMEOUT issue but I still trying to replicate this problem in my side.

alzhao: sounds like a typical crappy excuse,

I have tried downloading multiple configs from providers as well. Famous VPN providers and they all have the same problem. So its clearly a bug in your firmware. An solution would be much appreciated for people who have paid 3 times the price of a normal router to get these functionalities, and all you can come up with is excuses. This has been happening with configs multiple well known vpn providers used by thousands of people also this has been repeatedly complained by people using variety of servers with all combinations, which work elsewhere without any error … Clearly the problem is in ur firmware. We are not here to provide you config we paid more and its your job. There are enough complains of ur buggy firmware and u should arrange your own set of servers/configs/device to test, and replicate… clearly its ur system

Come up with solution not excuses!

Same issue on brand new Slate AX when trying to get WireGuard up and running. The annoying thing is my old Mango works without issue, but my expensive new Slate AX just throws the REKEY-TIMEOUT error we’re all seeing.

Pls let me know Wireguard does not connect at all or it breaks without reconnect.

I have been unsuccessful in getting this working on the slate (despite using the exact same configuration as my Mango (with the exception of the private key which I have generated for the Slate AX). When I try to connect, the VPN will not connect and I am presented with an endless loop of REKEY-TIMEOUT errors - see below. I understand that others may be experiencing the same issue with the Slate AX device and wireguard connections.

I have been through troubleshooting steps (reset Router / reset Router firmware / re-create config files) but nothing seems to address this issue.

Tue Dec 13 21:43:37 2022 daemon.notice netifd: Interface ‘wgclient’ is setting up now
Tue Dec 13 21:43:43 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Dec 13 21:43:48 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Dec 13 21:43:53 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Dec 13 21:43:58 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Dec 13 21:44:03 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Dec 13 21:44:09 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Dec 13 21:44:14 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Dec 13 21:44:19 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Dec 13 21:44:24 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

If it does not connect at all it is a different reason.

Should be pretty easy to find out.

Are you available to do remote check?

Sure - I can do that if you let me know what I you need me to do?

I got your email and replied that. Thanks for your help.

Hi, i hava same problem with GL-A1300
@alzhao can you help with it? i can send you my config in PM

Pls pm the wirguard config

I’ll reply here as this is the most recent forum post. I too have just purchased the Slate AX having previously run a slate for a long time.

Rather than just stating “I have a problem” I’ll collate some information

Current posts with a similar issue

There are 4 more, as a new user I’m limited to 2 links in a post

Personal Issue
Like many others I’m running my own WG server AND I have access to a commercial WG server. I have downloaded, copy and pasted AND manually entered configs which work fine on Linux (Ubuntu 22.04), ChromeOS, Windows and Android when used on the slate AX show the log files below. I’m confident it is not the server with the issue.

Logs

Thu Dec 29 11:47:52 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:47:57 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:48:03 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:48:08 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:48:13 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

Firmware

  • Version4.1.0
  • Firmware Typerelease7
  • Compile Time2022-11-16 14:25:44(UTC+08:00)

Resolving Issue
It seems the only way to revolve the issue is to disable the Wireguard VPN for about 5 minutes giving the wg daemon time to shutdown then restart the wg VPN.

Log on successfully Reconnect

Thu Dec 29 11:48:16 2022 daemon.notice netifd: Interface ‘wgclient’ is now down
Thu Dec 29 11:51:35 2022 daemon.notice netifd: Interface ‘wgclient’ is setting up now
Thu Dec 29 11:51:35 2022 daemon.err tailscaled[4387]: 2022/12/29 11:51:35 LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=wlan-sta0 ifs={br-guest:[192.168.9.1/24] br-lan:[192.168.8.1/24] wlan-sta0:[192.168.68.96/22] wgclient:down} v4=true v6=false}
Thu Dec 29 11:51:35 2022 daemon.err tailscaled[4387]: 2022/12/29 11:51:35 LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=wlan-sta0 ifs={br-guest:[192.168.9.1/24] br-lan:[192.168.8.1/24] wgclient:[10.8.0.4/24] wlan-sta0:[192.168.68.96/22]} v4=true v6=false}
Thu Dec 29 11:51:40 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:51:40 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Thu Dec 29 11:51:40 2022 daemon.notice netifd: Interface ‘wgclient’ is now up
Thu Dec 29 11:51:40 2022 daemon.notice netifd: Network device ‘wgclient’ link is up
Thu Dec 29 11:51:40 2022 kern.info kernel: [42673.545905] IPv6: ADDRCONF(NETDEV_UP): wgclient: link is not ready
Thu Dec 29 11:51:41 2022 user.notice firewall: Reloading firewall due to ifup of wgclient (wgclient)
Thu Dec 29 11:51:48 2022 user.notice wgclient-up: env value:T_J_A1_1=object T_J_V_ifname=string USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=3 J_V_keep=1 T_J_V_ipaddr=array HOME=/ T_J_T2_mask=string HOTPLUG_TYPE=wireguard T_J_V_interface=string J_A1_1=J_T2 J_V_ifname=wgclient T_J_V_link_up=boolean T_J_T2_ipaddr=string LOGNAME=root DEVICENAME= T_J_V_action=int K_J_A1= 1 J_V_ipaddr=J_A1 TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin J_T2_mask=24 CONFIG_LIST_STATE= J_V_interface=wgclient K_J_V= action ifname link_up keep ipaddr interface J_V_link_up=1 J_T2_ipaddr=10.8.0.4 J_V_action=0 N_J_V_link_up=link-up PROTO_IPADDR=10.8.0.4/24// T_J_V_keep=boolean PWD=/ JSON_CUR=J_V K_J_T2= ipaddr mask CONFIG_SECTIONS=global AzireVPN Mullvad FromApp group_2911 group_5878 group_5196 group_9171 peer_2634 CONFIG_cfg030f15_ports=
Thu Dec 29 11:51:48 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

Current Stance
The stance from the support team here appears to be that they cannot replicate the issue and as such they cannot resolve the issue which I understand (I’ve supported several dev teams over the years) If however this is the case you need to do the following

  1. Improve your logging so the above is not the case
  2. Add a function somewhere to pull out the information you need not in the logging.

Not being able to replicate an issue which is seen across several of your products (links above as proof) is not a good enough reason not to be fixing it. If you don’t have the data to fix it, that is in your hands to produce the GUI to provide it.

Required Action

  1. Post here what you need from people who are having the same issue? Logs, other data?
  2. Is there any testing people can do?
  3. Provide a timeline of what happens next

Conclusion
Since the 4.x upgrades there is a problem with the WG client, this needs to be resolved.

4 Likes

You’ve done the reconnect in 3 Seconds?
This is the time between unsuccessful last message and successful first message.

Could it be a time issue?
I read a lot about this here, too, but I can’t confirm. I am moving in only one timezone. And set it right is the first action after every reset.

2 Likes

Thanks for your info.

Yes I take your advise and working on a solution, e.g. more logs etc.

I just want to say again that the most of REKEY-TIMEOUT is just the server is not available.

If users cannot just say I have the same problem, rather give some decriptions like you, it will be much helpful.

3 Likes

I did a further deep dive to the underlying network this morning, and while my Wireguard server was working OK, I’m now tending to agree with you (at the moment) that the REKEY-TIMEOUT isn’t related to the Wireguard server its related to the underlying internet connection having an issue.

I was connected to an AirBnB wifi and was getting consistent dropout of wireguard, (approx every 10 minutes) when I connected the Slate AX to my Mobile phone hotspot I got a consistent connection. (no dropouts)

Personally I’d like to see maybe an Uptime Kuma (GitHub - louislam/uptime-kuma: A fancy self-hosted monitoring tool) style UDP poll to the wireguard server and an associated ping test maybe to a custom location.

This at least starts a correlation between the Wireguard server and general internet uptime.

I’m not 100% convinced there isn’t an issue (probably on OpenWRT side) and will give you any testing / feedback you need to assist.

1 Like

Thats poor logging, not factual. When you turn off the Wireguard VPN the log doesn’t register it as turned off, not until its started again does the log file state its taken down the Wireguard connection (hence the 3 seconds) I noted this last night.

I have put some further test notes below in the page.

Its not timezone related, I tested that…

2 Likes

In my case, I’m having this issue when I try to use a Wireguard VPN with USB tethering (Android phone).
VPN works fine with a normal Ethernet WAN connection, but if I try to switch to USB tethering, I get the endless “REKEY-TIMEOUT” logs.

Problem is, this worked fine in version 4.0.3. I upgraded to version 4.1.0 (just to get rid of the yellow dot in the UI), and it stopped working. I rolled back to 4.0.3, but it never worked again.

VPN works fine with a normal Ethernet connection, and the router also works fine with USB tethering without VPN turned on.

I don’t think this is related to firmware version.

Maybe try change Wireguard MTU and test.