[Beta] Asuswrt-Merlin 384.14 Beta is now available

[randomName]

I'm gonna upload 384.13 tomorrow and test things out. The other odd issue is my cable modem page is a lot slower to open up than before. I'll report back my findings.

 

[SheikhSheikha]

384.14b3 running a few days on one of my RT-AC5300's has been a great experience when it comes down to speed compared to 384.13. But this morning my 2.4GHz completely disappeared. Nothing in the log file, it was simply gone......................
Changing the channel setting to AUTO brought it back alive. Selecting a manual channel is no longer possible as it makes the 2.4GHz disappear again...........

 

[ryannathans]

Re-flashed 384.14b3 on RT-AC5300 and WiFi dropouts are back

Does anyone else have an Intel AX200 client to test with (almost every x570 motherboard)? So far I've only had the dropouts on this device but ONLY with 384.14b3 (384.13 completely stable)

 

[bitsbytes]

how many betas are there before the final release? and would you recommend the latest beta instead of the latest official one for the 86u ?

 

[XIII]

If you login to the router, can you nslookup the name of your time server?

Yes.

And since I'm using <countrycode>.pool.ntp.org this should work even if one server went down temporarily?

 

[Treadler]

Yes.

And since I'm using <countrycode>.pool.ntp.org this should work even if one server went down temporarily?

This may be irrelevant to your issue but, I have had (suspected) system time problems in the past.
Fixed when I shifted to Cloudflare’s time server, using ip addresses.

For IPv6,
2606:4700:f1::1

For IPv4,
162.159.200.1

(Enable local ntp server = y, Intercept ntp client requests = y)

YMMV

 

[Adamm]

Running self compiled 384.14_beta3-g907d21657b (7756 branch). Can confirm the DPI engine is working again and correctly identifying traffic. QOS is still broken but besides that everything else is running smooth, can't replicate any of the other issues people have been posting about the new SDK,

 

[SheikhSheikha]

After a few days 384.14b3 starts to demonstrate problems. After the 2.4GHz crash now L2TP is causing problems - and this time it is visible in the log file:

Dec 11 13:37:21 /usr/sbin/l2tpd[586]: Unknown tunnel 5955
Dec 11 13:37:22 /usr/sbin/l2tpd[586]: Unknown tunnel 5955
Dec 11 13:37:22 /usr/sbin/l2tpd[586]: Unknown tunnel 5955
Dec 11 13:37:22 /usr/sbin/l2tpd[586]: Unknown tunnel 5955
Dec 11 13:37:22 /usr/sbin/l2tpd[586]: Unknown tunnel 5955
the line above is repeated another 1000 times and the router was flooded and blocked. By removing the power and a cold boot it came alive again.

 

[Kingp1n]

Running self compiled 384.14_beta3-g907d21657b (7756 branch). Can confirm the DPI engine is working again and correctly identifying traffic. QOS is still broken but besides that everything else is running smooth, can't replicate any of the other issues people have been posting about the new SDK,

@Adamm, is qos broken only on AX88 only or AC86U as well?

 

[Adamm]

@Adamm, is qos broken only on AX88 only or AC86U as well?

Just the AX88U using the new SDK.

 

[John Adler]

since ß3 was installed everything runs fine
also PPTP/L2TP is working fine

 

[Vexira]

Re-flashed 384.14b3 on RT-AC5300 and WiFi dropouts are back

Does anyone else have an Intel AX200 client to test with (almost every x570 motherboard)? So far I've only had the dropouts on this device but ONLY with 384.14b3 (384.13 completely stable)

Are your drivers and os version the latest?

 

[Vexira]

Running self compiled 384.14_beta3-g907d21657b (7756 branch). Can confirm the DPI engine is working again and correctly identifying traffic. QOS is still broken but besides that everything else is running smooth, can't replicate any of the other issues people have been posting about the new SDK,

If you don't mind me asking what is still broken in QoS, I'm assuming adaptive QoS is what you are referring to?

 

[heysoundude]

So, now that we've determined that fiber is better than DSL, what is the consensus on running beta 3 on an 86U?

It's hard to sort the wheat from the chaff in this thread lately.

It's when beta threads get off track (like this) that the firmware is close to ready for release.
That said, Yay Canada for doing Fibre right...wish I could afford it, or I had alternatives to who sells that service in my area.

 

[lilstone87]

Just the AX88U using the new SDK.

Well Merlin said he wasn't using the new SDK for it, until 384.15. So if you're using his latest beta build for the AX88U, QoS should be working just fine. I know I have it on, on the Beta3 build from the other day, and adaptive QoS seems to be working just fine.

 

[Adamm]

Well Merlin said he wasn't using the new SDK for it, until 384.15. So if you're using his latest beta build for the AX88U, QoS should be working just fine. I know I have it on, on the Beta3 build from the other day, and adaptive QoS seems to be working just fine.

Running self compiled 384.14_beta3-g907d21657b (7756 branch).

 

[L&LD]

Well Merlin said he wasn't using the new SDK for it, until 384.15. So if you're using his latest beta build for the AX88U, QoS should be working just fine. I know I have it on, on the Beta3 build from the other day, and adaptive QoS seems to be working just fine.

Asus sent me a fix for the broken bwdpi with the new ax SDK. I'm dropping a beta3 test build with the new SDK + the bwdpi fix in https://www.asuswrt-merlin.net/test-builds/ .

My plan still hasn't changed for the RT-AX88U, 384.14 will stick to the previous SDK, and the new SDK will be scheduled for 384.15.

EDIT: I know that the System page is still broken, I haven't fixed that branch yet. I uploaded build g6ed03020e2 which contains the System page fixes.

RMerlin is using the latest SDK on that alpha/beta build (he won't use it for 384.14 final though).

 

[lilstone87]

RMerlin is using the latest SDK on that alpha/beta build (he won't use it for 384.14 final though).

The build he just uploaded today, does appear to have the new SDK back in it. As there's around a 5.7mb increase in file size. However the beta3 build before the build today, didn't have the new SDK for the AX88U. As I have been using it, and adaptive QoS is working on it. The file sizes seems to back me up on that as well. As it's 79.8mb vs 85.5mb(build he uploaded today).

 

[L&LD]

@lilstone87, you confused me when you said 'from the other day' in your post earlier today. As that build was available yesterday.

Have been running that g6ed03020e2 beta 3 build without issues, btw.

 

[randomName]

So for Speedtest cross-check testing purposes with 384.14b3 I went back to 384.13 On b3 my line quality was consistently an F on both Firefox and Edge while Bufferbloat was an A+ The other issue I was noticing was my cable modem page took longer to open up. I just switched back to 13 and both issues are back to normal: my cable modem page loads up fast, like before, and my Speedtest line quality is back to an A. Just thought I'd share this. This is with Adaptive QoS enabed, no FreshJR. If anyone needs my other configurations for this testing purpose, let me know. Thanks

Router: 86U