[ 3004.388.6 alpha Build(s) ] Testing available build(s)

[hifiwifi]

What model of router are you using? Do you install the last version of alpha on it? Last alpha doesn't have any problems with DNS-over-TLS.

Latest Alpha. RT-AX86U.

 

[hifiwifi]

Latest Alpha. RT-AX86U.

UPDATE: Flashed again and working as expected.

 

[visortgw]

UPDATE: Flashed again and working as expected.

Most likely you were still running previous version of alpha.

 

[Dedel66]

It would be helpful if every tester had his setup and the software version in his signature.

 

[aex.perez]

One positive, overall the wireless drivers in this release have for me been the most stable especially from a roaming perspective than just about any prior release. That said I've pretty much optimized everything between the router and both nodes (AiMesh) in that I had minimized a just to a certain number of devices that would disconnect/reconnect on their own on a reboot of the router, often to the wrong node/router. The Samsung sound bar was notoriously fond of connecting randomly to the farthest node (over 5Ghz, AX not supported but it works fine) even though the router is less than six feet away from it. Binding it to the router didn't help. Happened rarely but enough times to be a nuisance to get it connected to the router again. Alexa Echo devices were also notoriously bad, but only on a reboot, to get them connected to the right node/router.

Jump forward to the 386.Alpha and so far so good, absolutely no devices moving around on their own, even between reboots (which have been minimal). All the devices have stayed to the router/node they've connected to or been bound to. The only devices that do move are the phones and tablets that actually do move about the house.

Your mileage may vary, but just felt I had to share something positive.

 

[dark]

these error messages are new to me


Dec 30 14:42:13 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:13 rc_service: udhcpc_wan 355345:notify_rc start_dhcp6c
Dec 30 14:42:13 rc_service: waitting "start_dnsmasq" via watchdog ...
Dec 30 14:42:13 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:14 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:14 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:15 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:15 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:16 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:17 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:17 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:18 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:18 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:19 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:19 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:20 kernel: Serdes 8 False Link Up with Error Symbol 0x4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:20 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:21 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:22 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:22 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:23 kernel: Serdes 8 False Link Up with Error Symbol 0xf4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:23 kernel: Serdes 8 False Link Up with Error Symbol 0x4 at 3.c466h at speed 2500Mbps
Dec 30 14:42:23 kernel: ^[[0;30;103mWarning: Serdes at 8 link does not go up following external copper PHY at 21.^[[0m
Dec 30 14:42:24 kernel: eth5 (Int switch port: 7) (Logical Port: 7) (phyId: 15) Link Up at 2500 mbps full duplex

Did you see these errors after an event related to the WAN interface? For example wan reconnection, ip changed by ISP etc...

 

[robinjoo1]

Did you see these errors after an event related to the WAN interface? For example wan reconnection, ip changed by ISP etc...

my ip almost never changes but seems to be just notification related i don't experience any problems
ISP modem is a Sagemcom F3896
ISP itself is VodafoneZiggo Netherlands

 

[Damit1]

Waiting on for Beta release.
Hopefully soon it will happen

 

[Analog-1]

Waiting on for Beta release.
Hopefully soon it will happen

Yep this latest Alpha is rock solid.

 

[Dedel66]

If you had read the thread completely, you would notice that there ARE errors.

 

[Analog-1]

If you had read the thread completely, you would notice that there ARE errors.

Ok. But for most it's solid.

 

[cc666]

I am assuming the one dated 6 days ago is the latest Beta?

CC

 

[RMerlin]

@AsusFreak
Can confirm! Same here! After choosing "Enable Access Restrictions" the router became unresponsive. I had to WPS reset my ax88u and restore my backups.
I don't know if this bug also existed in 388.5 because I hadn't used this feature yet.

The bug was introduced by Asus in 388_24353.

 

[Dedel66]

I am assuming the one dated 6 days ago is the latest Beta?

CC

GT-AXE16000_3004_388.6_alpha1-gb287d474ae

is the latest ALPHA... At this point there is no BETA.

 

[sluzza]

Feedback from RT-AX86U_PRO users has been a bit mixed but my experience has been pretty positive.

I was coming from Asus stock 3.0.0.4.388_24198 but couldn't update to 3004_388.6_alpha1-gb287d474ae until I had done a WPS-reset back to factory defaults on stock and then configured the alpha from scratch. I've been a 'dirty upgrader' for a while without any problems but thought it was time to bite the bullet rather than try reloading any saved .cfg files from stock or 388.5 before that.

Reliability has been fine over the last 7 days with minimal changes from the defaults, and it rebooted automatically as configured on the 7th. Having run fine for a week I tried enabling access restrictions (having double-checked that I had saved a .cfg of that working configuration) to limit login to two devices but as soon as I clicked on Apply the router crashed. I could only get back in by performing a WPS-reset and reloading the good .cfg saved earlier. The two devices I put in the Access restrictions list are the only two in the Manually Assigned IP list on the DHCP Server page and I was doing the configuration from one of the devices in that list.

Happy enough to stick with this alpha for now though.

 

[sluzza]

Feedback from RT-AX86U_PRO users has been a bit mixed but my experience has been pretty positive.

I was coming from Asus stock 3.0.0.4.388_24198 but couldn't update to 3004_388.6_alpha1-gb287d474ae until I had done a WPS-reset back to factory defaults on stock and then configured the alpha from scratch. I've been a 'dirty upgrader' for a while without any problems but thought it was time to bite the bullet rather than try reloading any saved .cfg files from stock or 388.5 before that.

Reliability has been fine over the last 7 days with minimal changes from the defaults, and it rebooted automatically as configured on the 7th. Having run fine for a week I tried enabling access restrictions (having double-checked that I had saved a .cfg of that working configuration) to limit login to two devices but as soon as I clicked on Apply the router crashed. I could only get back in by performing a WPS-reset and reloading the good .cfg saved earlier. The two devices I put in the Access restrictions list are the only two in the Manually Assigned IP list on the DHCP Server page and I was doing the configuration from one of the devices in that list.

Happy enough to stick with this alpha for now though.

FYI I tried going back to 3.0.0.4.388_24198, loading the most recent .cfg, deleting the access restriction list, saving the updated settings then going back to 388.6_alpha1-gb287d474ae.

Without the access restrictions it is possible to update the f/w from Asus stock to Merlin alpha1 without problems and all the previous settings are preserved. It's too early to say if they all still work but it's definitely a quicker route for anyone using access restrictions and wanting to upgrade.

 

[kernol]

RT-AX86U-PRO ... started on stock 3.0.0.4.388_24198 with manual config from factory reset and then dirty flashed to 3004.388.6_alpha1-gb09e5eb501 {self compiled 01/01/2024}. Rock steady so far (6+ hours). I don't use restricted access - which seems to have troubled some with this specific router.
Great work as usual by the Maestro .

 

[maxbraketorque]

The bug was introduced by Asus in 388_24353.

This is a rarely used feature, but the bug is severe. Are you going to use this version of ASUS firmware, or wait for a fix? I guess it seems that sometimes, ASUS issues you a patch for specific bugs?

 

[visortgw]

This is a rarely used feature, but the bug is severe. Are you going to use this version of ASUS firmware, or wait for a fix? I guess it seems that sometimes, ASUS issues you a patch for specific bugs?

There is a work-around that is much more secure: Disable WAN access altogether, and use OpenVPN to access the router remotely.

 

[JGrana]

There is a work-around that is much more secure: Disable WAN access altogether, and use OpenVPN to access the router remotely.

Or wait for the release.