Firmware 4.2.x is out as snapshot firmware

I put that snapshot on the Beryl 1300 - aside from /overlay having no space, I don’t see these applications listed. I guess the Beryl is limited to space built in.

MT3000 will include Tailscale.

You asked about the gl-mt3000 Beryl ax then switched to gl-mt1300 beryl

@K3rn3l_Ku5h Currently have a 1300 Beryl in my hands. Waiting on the 3000.

A couple questions:
Will tailscale be available on the original Slate? It looks like 4.2.0 offers zerotier, but no tailscale on it.
Will 4.2.0 be coming to the original Brume/Brume-W?
Thanks!

1 Like

We will assess whether the system resources can support it when we adapt. I don’t think it’s very likely.

BrumeW should have a 4.x beta firmware release. But there is no timetable yet.

I confirm that I’m facing the same problem that @mainufer described, with VPN client turning yellow after some time and remaining yellow forever. Differences are that I’m not using Torguard but Mullvad, I’m not on GL-AXT1800 Slate AX but on GL-AX1800 Flint. I’m also using 4.2.0 beta2 firmware version. I alson confirm I wasn’t experiencing this in 4.1.0 stable (although I didn’t use the VPN client much on this version while the VPN cascading didn’t exist).

How often do you experience this issue? Do you have a log?

It depends, it usually takes several hours before it happens, but I’ve never had a full day with VPN client continuously working. When it happens I cannot access Internet anymore and I need to connect to the router interface to manually stop and restart the VPN client, so I’m keeping it off for now, but when I have some time to give it another try, and that I can catch the moment it goes wrong, I’ll post some logs.

Check the DHCP lease time from the ISP, past 6 months many ISP have changed from 7 to 15 day lease to 2-4 hours. I had a similar issue and nothing in the logs indicated anything but a connection drop.

My public IP is static so I think there’s nothing wrong with it. If it wasn’t, I’d be more struggling with the wireguard server than the client.

1 Like

It just happened. I turned WG client on at 20:11, at 21:39 I notice that Internet is not working anymore and WG client is yellow, stuck at “client starting, please wait…”

Here are the logs:

Tue Jan 24 21:34:37 2023 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 Jan 24 21:34:37 2023 daemon.notice netifd: Interface ‘wgclient’ has lost the connection
Tue Jan 24 21:34:37 2023 daemon.notice netifd: Network device ‘wgclient’ link is down
Tue Jan 24 21:34:37 2023 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=/
Tue Jan 24 21:34:38 2023 user.notice mwan3[23591]: Execute ifdown event on interface wgclient (unknown)
Tue Jan 24 21:34:38 2023 daemon.notice netifd: wgclient (23599): udhcpc: started, v1.33.2
Tue Jan 24 21:34:38 2023 daemon.notice netifd: wgclient (23599): udhcpc: sending discover
Tue Jan 24 21:34:39 2023 user.notice firewall: Reloading firewall due to ifdown of wgclient ()
Tue Jan 24 21:34:40 2023 daemon.notice netifd: wgclient (23599): udhcpc: no lease, failing
Tue Jan 24 21:34:40 2023 daemon.notice netifd: wgclient (23599): udhcpc: started, v1.33.2
Tue Jan 24 21:34:41 2023 daemon.notice netifd: wgclient (23599): udhcpc: sending discover
Tue Jan 24 21:34:42 2023 daemon.notice netifd: Interface ‘wgclient’ is now down
Tue Jan 24 21:34:42 2023 daemon.notice netifd: Interface ‘wgclient’ is setting up now
Tue Jan 24 21:34:43 2023 user.notice mwan3[24372]: Execute ifdown event on interface wgclient (unknown)
Tue Jan 24 21:34:44 2023 user.notice firewall: Reloading firewall due to ifdown of wgclient ()
Tue Jan 24 21:34:51 2023 user.notice wgclient-up: env value:T_J_A1_1=object T_J_V_ifname=string USER=root T_J_A3_1=object ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=3 J_V_keep=1 T_J_V_ipaddr=array HOME=/ PROTO_IP6ADDR=fc00:bbbb:bbbb:bb01::1:9f10/128//// T_J_T2_mask=string HOTPLUG_TYPE=wireguard T_J_V_interface=string T_J_T4_mask=string J_A1_1=J_T2 CONFIG_wwan_dns= J_V_ifname=wgclient T_J_V_link_up=boolean T_J_T2_ipaddr=string J_A3_1=J_T4 LOGNAME=root DEVICENAME= T_J_V_action=int K_J_A1= 1 T_J_T4_ipaddr=string J_V_ipaddr=J_A1 K_J_A3= 1 TERM=linux SUBSYSTEM=wireguard T_J_V_ip6addr=array PATH=/usr/sbin:/usr/bin:/sbin:/bin J_T2_mask=32 CONFIG_LIST_STATE= J_V_interface=wgclient J_T4_mask=128 K_J_V= action ifname link_up keep ipaddr ip6addr interface J_V_link_up=1 J_T2_ipaddr=10.64.159.17 J_V_action=0 J_T4_ipaddr=fc00:bbbb:bbbb:bb01::1:9f10 N_J_V_link_up=link-up PROTO_IPADDR=10.64.159.17/32// T_J_V_keep=boolean J_V_ip6addr=J_A3 PWD=/ JSON_CUR=J_V K_J_T2= ipaddr mask CONFIG_SECTIONS=global AzireVPN Mullvad FromApp group_8259 grou
Tue Jan 24 21:34:51 2023 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=/
Tue Jan 24 21:35:20 2023 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=/
Tue Jan 24 21:37:22 2023 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=/
Tue Jan 24 21:39:24 2023 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=/

It looks like MWAN3 or Mult-wan failover/balance gets triggered because the connection is lost either by the isp or vpn being disconnect.

Do you have MWAN3 configure in failover or balance?
Could also be the DNS setting in MWAN3, if it ping google and did not get a response.

Do you have any updates that are in LuCi waiting? udhcpc is part of busybox

FYI if you copy and paste with a space under “here are the logs” it should auto column and make it alot easier to follow the timeline.

I didn’t touch anything in Multi-WAN section so it’s all set by default, it’s in failover mode. I didn’t install LuCi either. I did a firmware reset yesterday so the customized part is limited to what I need. Router is working in Repeater mode… I don’t know if it’s important to mention, I have no Ethernet WAN, in case the failover wants to get there ?

Sorry I’m doing all this from my phone, I added a blank space like you said but it didn’t seem nicer, I’ll see what I can do to display it fancier.

Use the code block example on the bottom.

https://commonmark.org/help/

I don’t have the foggiest clue on your disconnects though. Have you tried rebooting with your mouth tilting to the right or left like so (: / or : \ ) … I’ll see myself out… :face_in_clouds:

It’s even worse with code block because the log has no actual line feed. :roll_eyes:

Edit: here it is, I’ve used a computer to replace the “\n” with a line feed. Too bad the log that the interface proposes to copy isn’t directly pastable.

I could imagine that the VPN provider disconnects the session, because of an IP change, and the client fails to reconnect. Is that possible?

My public IP is static, as seems the one of the VPN server, so I’ll leave the room to the experts to answer this but don’t see which IP could be changing here. And I don’t see why the client cannot just do the same thing that what I’m doing when I’m just clicking “Stop” then “Start” so it works again. For now I have to manually do this every few hours to keep it working, so it looks like a bug.

I thinking because you are running a custom image something got taken out. Multi-Wan does support repeater set up, you could use that