Beta Asuswrt-Merlin 3004.388.6 Beta is now available

[RMerlin]

Good news! Thanks!

BTW: Does this note still apply? Note that enabling WireGuard will disable hardware NAT acceleration due to compatibility reasons.

Most models (if not all, I don't remember specifically) should be able to use Asus' bypass method that will leave hardware acceleration enabled for regular WAN traffic, only traffic going through the tunnel will be marked to bypass acceleration.

Look at the content of the changelog, it was documented at the time, whether some models were excluded from this implementation.

 

[Analog-1]

Any ETA for a final release ?

 

[RMerlin]

Any ETA for a final release ?

No.

 

[Piotrek]

Most models (if not all, I don't remember specifically) should be able to use Asus' bypass method that will leave hardware acceleration enabled for regular WAN traffic, only traffic going through the tunnel will be marked to bypass acceleration.

Thank you for the information!

Look at the content of the changelog, it was documented at the time, whether some models were excluded from this implementation.

I didn't find it in the changelog - that's why I asked

 

[dave14305]

Just a heads up that the 388.6 beta1 SHA256 checksums have overwritten the 388.5 checksums on the https://asuswrt-merlin.net/download page. They appear under both "Latest release" and "Latest beta".

 

[RMerlin]

Just a heads up that the 388.6 beta1 SHA256 checksums have overwritten the 388.5 checksums on the https://asuswrt-merlin.net/download page. They appear under both "Latest release" and "Latest beta".

I know. The publish script didn't properly rename the generated file, so it overwrote the release file, and I didn't have any backup of it.

 

[Damit1]

4 days.
Stable as should be
no major issues, nothing to report.

 

[swejuggalo]

Anyone one got stuff rebooting automatically? A single RT-AX88U.
Back on a wiped router, with SSH turned on, VPNs done, split 2.4/5 GHz SSID, DDNS and DoT setup. Leaving it without adding Skynet or Diversion and will run it for some time.
Think I recall it working just fine until I added Diversion. Never used before, but decided to try it out.
I could see stuff dropping like every 30 minutes or so (including wired). Logs didn't show much other than it looked like a reboot, but not taking just as long time.

 

[Ripshod]

I could see stuff dropping like every 30 minutes or so (including wired). Logs didn't show much other than it looked like a reboot, but not taking just as long time.

Can you share some of the logs for us?

 

[swejuggalo]

Can you share some of the logs for us?

Will do if I can replicate it. But when I looked at it everything looked fine. But poof. Stuff just started over. Not even an error message.

 

[Dedel66]

4 days.
Stable as should be
no major issues, nothing to report.

Same here:

 

[Wisiwyg]

Anyone one got stuff rebooting automatically? A single RT-AX88U.

Also AX88U... dirty upgrade from A1, dirty upgrade A1 from 388.5... no random reboots..

 

[Damit1]

Same here

 

[HeadBanger]

GT-AXE16000 - all seems OK. Found one UI bug (which may have been introduced in a previous firmware).
If you disable other WiFi bands whilst leaving 2.4 on, the UI reports that 2.4 is disabled when it is not. I do not use Smart connect.

HB

 

[Dedel66]

GT-AXE16000 - all seems OK. Found one UI bug (which may have been introduced in a previous firmware).
If you disable other WiFi bands whilst leaving 2.4 on, the UI reports that 2.4 is disabled when it is not. I do not use Smart connect.

HB

View attachment 55471

Works as expectedet at my network.

 

[Elmer]

AX88U/Beta1: DDNS was inactive when firmware was applied. Reset certs and DDNS came back (using asus DDNS), after a couple of days it went inactive again and I cannot restore it. Other than that, things seem fine.

Update: It's back again after a few down days. Is the asuscomm site having troubles?

 

[Mutzli]

Also no issues here for over 7 days.

Even made it through last nights winter storm here in Michigan, thanks to the UPS that kicked in several times through short power outagages.

 

[swejuggalo]

Also AX88U... dirty upgrade from A1, dirty upgrade A1 from 388.5... no random reboots..
View attachment 55460

For me it was not a dirty upgrade. I wiped due to other reasons. And something I did with either settings and scripts made it go nuts. Just Skynet, Diversion (with dependencies) and drifted away slightly from stock WiFi settings.

 

[octopus]

Want to check with you if this is real. Have two vpnclients running and it seems they get the same10.128.0.0/22.
Shouldn't 10.128.0.0/22 and 10.129.0.0/22 be different addresses for them.

And it seems there is a rule missing for 112
217.64.148.xx via 158.174.112.1 dev eth0

octopus@GT-AX6000-F1E8:/tmp/home/root# ip route
default via 158.174.xxx.1 dev eth0
10.6.0.2 dev wgs1 scope link
10.6.0.3 dev wgs1 scope link
10.8.40.0/24 dev tun22 proto kernel scope link src 10.8.40.1
10.128.0.0/22 dev tun11 proto kernel scope link src 10.128.2.92
10.128.0.0/22 dev tun12 proto kernel scope link src 10.128.2.123
127.0.0.0/8 dev lo scope link
158.174.xxx.0/22 dev eth0 proto kernel scope link src 158.174.xxx.xx
158.174.xxx.1 dev eth0 proto kernel scope link
192.168.50.0/24 dev br0 proto kernel scope link src 192.168.50.1
192.168.101.0/24 dev br1 proto kernel scope link src 192.168.101.1
213.80.98.2 via 158.174.xxx.1 dev eth0 metric 1
213.80.101.3 via 158.174.xxx.1 dev eth0 metric 1

octopus@GT-AX6000-F1E8:/tmp/home/root# ip route show table 111
default via 10.128.0.1 dev tun11
10.6.0.2 dev wgs1 scope link
10.6.0.3 dev wgs1 scope link
10.8.40.0/24 dev tun22 proto kernel scope link src 10.8.40.1
10.128.0.0/22 dev tun11 proto kernel scope link src 10.128.2.92
127.0.0.0/8 dev lo scope link
158.174.xxx.0/22 dev eth0 proto kernel scope link src 158.174.xxx.xx
158.174.xxx.1 dev eth0 proto kernel scope link
192.168.50.0/24 dev br0 proto kernel scope link src 192.168.50.1
192.168.101.0/24 dev br1 proto kernel scope link src 192.168.101.1
213.80.98.2 via 158.174.xxx.1 dev eth0 metric 1
213.80.101.3 via 158.174.xxx.1 dev eth0 metric 1
217.64.148.59 via 158.174.xxx.1 dev eth0

octopus@GT-AX6000-F1E8:/tmp/home/root# ip route show table 112
default via 10.128.0.1 dev tun12
10.6.0.2 dev wgs1 scope link
10.6.0.3 dev wgs1 scope link
10.8.40.0/24 dev tun22 proto kernel scope link src 10.8.40.1
10.128.0.0/22 dev tun11 proto kernel scope link src 10.128.2.92
127.0.0.0/8 dev lo scope link
158.174.xxx.0/22 dev eth0 proto kernel scope link src 158.174.xxx.xx
158.174.xxx.1 dev eth0 proto kernel scope link
192.168.50.0/24 dev br0 proto kernel scope link src 192.168.50.1
192.168.101.0/24 dev br1 proto kernel scope link src 192.168.101.1
193.187.91.199 via 158.174.xxx.1 dev eth0
213.80.98.2 via 158.174.xxx.1 dev eth0 metric 1
213.80.101.3 via 158.174.xxx.1 dev eth0 metric

 

[ColinTaylor]

Want to check with you if this is real. Have two vpnclients running and it seems they get the same10.128.0.0/22.
Shouldn't 10.128.0.0/22 and 10.129.0.0/22 be different addresses for them.

The route/subnet is pushed from the server side. So you need to check that's not creating the conflict you're seeing.