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

[kernol]

@RMerlin - are you able to provide any info on what the Asus GPL 386_45581 brings with it by way of bug and security fixes??
I have searched far and wide [within Asus support webui; this forum; Google; Bing etc] and can find no evidence that Asus firmware was ever compiled and released from this particular GPL.

Your released version [386.2 through to 386.3] was merged with 386_42095 provided by Asus way back in March this year. Since then there have been many security and bug fixes included with subsequent Asus stock firmware releases. Always good to know what has been addressed.

Surely it would have made more sense for Asus to provide you with GPL from an already tried, tested and released version [for e.g. GPL 386_45898]??. Issues that members are raising here with Alpha2 seem to be echo's from past, already rectified errors.

 

[Treadler]

“Dcd tainted” message hitting the log every 5 minutes or so.
Router seems to be working ok though.

Not previously seen here…….

I reverted to Alpha 1, “Dcd taint” issues have gone away.

 

[kernol]

Ax88 and not getting dcd tainted but, what's this:
kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

That log entry has been around for ages ... and is apparently just a useless debug report which we must all ignore .
See here for frequency ...
https://www.snbforums.com/search/283906/?q=kernel:+CFG80211-ERROR)+wl_cfg80211_change_station+:+WLC_SCB_AUTHORIZE+sta_flags_mask+not+set&o=date

EDIT: For short and best response see this post ...
http://www.snbforums.com/threads/beta-asuswrt-merlin-384-14-beta-is-now-available.60037/post-528738

 

[SomeWhereOverTheRainBow]

That log entry has been around for ages ... and is apparently just a useless debug report which we must all ignore .
See here for frequency ...
https://www.snbforums.com/search/283906/?q=kernel:+CFG80211-ERROR)+wl_cfg80211_change_station+:+WLC_SCB_AUTHORIZE+sta_flags_mask+not+set&o=date

EDIT: For short and best response see this post ...
http://www.snbforums.com/threads/beta-asuswrt-merlin-384-14-beta-is-now-available.60037/post-528738

@kernol reporting the kernel status. It appears the norms of the Kernel have struck again. Asuswrt is riddled by unknown common kernal messages that never really amount to breaking functionality.

 

[RMerlin]

@RMerlin - are you able to provide any info on what the Asus GPL 386_45581 brings with it by way of bug and security fixes??
I have searched far and wide [within Asus support webui; this forum; Google; Bing etc] and can find no evidence that Asus firmware was ever compiled and released from this particular GPL.

I don't have a list, because it's not an official release, but the snapshot that was taken at the moment Asus were fighting to get the GPL-related licensing issues sorted out. They were not going to re-build new version for validation every 2-3 weeks, which would have delayed everything even further more.

You can do your own search on Asus's release notes from past releases to see what was fixed between 42095 and 45898. Obviously, Asus didn't fix everything in 45897 and released that as 45898, they have gone through hundreds of interim builds between the two over the span of 6 months.

Let's have a look at releases that occurred BEFORE 45581 on which I am currently working:

Version 3.0.0.4.386.45375
2021/08/31 71.45 MBytes
ASUS RT-AX88U Firmware version 3.0.0.4.386.45375
This version includes several vulnerability patches.
BusyBox
- CVE-2016-2148
- CVE-2016-6301
- CVE-2018- 1000517

cURL
- CVE-2020-8169
- CVE-2019-5481
- CVE-2019-5482
- CVE-2018-1000120
- CVE-2018- 1000300
- CVE-2018-16839

Lighttpd
- CVE-2018-19052

Linux
- CVE-2020-14305
- CVE-2020-25643
- CVE-2019-19052

lldpd
- CVE-2020-27827

Avahi
- CVE-2017-6519

hostapd
- CVE-2021-30004
- CVE-2019-16275

OpenVPN
- CVE-2020-11810
- CVE-2020-15078

wpa
- CVE-2021-30004
- CVE-2021-27803
- CVE-2019-11555
- CVE-2019-9499
- CVE-2019-9498
- CVE-2019-9497
- CVE-2019-9496
- CVE-2019-9495
- CVE-2019-9494
- CVE-2017-13086
- CVE-2017-13084
- CVE-2017-13082
- CVE-2016-4476
- CVE-2015-8041

Fixed envrams exposed issue. Thanks to Quentin Kaiser from IoT Inspector Research Lab contribution.

Please unzip the firmware file first then check the MD5 code.
MD5: d507027a6b5b203d5d70be06e5f68abf
DOWNLOAD
SHOW MORE DESCRIPTION
Version 3.0.0.4.386.44266
2021/07/02 71.02 MBytes
ASUS RT-AX88U Firmware version 3.0.0.4.386.44266
1. Fix AiMesh issues
2. Improve system stability
3. Fix WAN DNS setting cannot setup LAN side pihole server.
4. Fixed DoS vulnerability from spoofed sae authentication frame. Thanks for Efstratios Chatzoglou, University of the Aegean, Georgios Kambourakis, European Commission at the European Joint Research Centre, and Constantinos Kolias, University of Idaho.

Please unzip the firmware file first then check the MD5 code.
MD5: 43efe8f59357d53b7b51bc0036d905f2
DOWNLOAD
SHOW MORE DESCRIPTION
Version 3.0.0.4.386.42820
2021/05/10 70.36 MBytes
ASUS RT-AX88U Firmware version 3.0.0.4.386.42820
- Fixed IoT devices connection issues.
- Fixed the fragattacks vulnerability.

Please unzip the firmware file first then check the MD5 code.
MD5: de715b28c7404eed4f5ee6bc007f9342
DOWNLOAD
Version 3.0.0.4.386.42819
2021/04/29 70.06 MBytes
ASUS RT-AX88U Firmware version 3.0.0.4.386.42819
1. Fix VPN GUI issues.
2. Fix WAN connection issues. Special thanks to Yulei Zhang's contribution.
3. Fix AiMesh related bugs.
4. Minor GUI issue fixes.
5. Upgrade dropbear to version 2020.81
6. Fix buffer overflow vulnerability
7. Fix slowloris denial of service attack.
8. Fix authentication bypass vulnerability.

Please unzip the firmware file first then check the MD5 code.
MD5: 47dcbe3ac7084a656304b269a0dd9b0f
DOWNLOAD
SHOW MORE DESCRIPTION

So obviously, 45581, which is newer than the newest release I posted here, contains all of these previous fixes. What else has happened since then? Well, only one single release (and there's a chance that at least some of these are also present in 45581), and it contains this fairly short changelog:

Firmware
Version 3.0.0.4.386.45898
2021/10/06 71.51 MBytes
ASUS RT-AX88U Firmware version 3.0.0.4.386.45898
1.Fixed AiMesh web page multi-language issues.
2.Fixed Let's encrypt issues.
3.Fixed Stored XSS vulnerability.
4.Fixed CVE-2021-41435, CVE-2021-41436.
Thanks to Efstratios Chatzoglou, University of the Aegean
Georgios Kambourakis, European Commission at the European Joint Research Centre
Constantinos Kolias, University of Idaho.
5.Fixed Stack overflow vulnerability. Thanks to Jixing Wang (@chamd5) contribution.
6.Fixed information disclosure vulnerability .Thanks to CataLpa from DBappSecurity Co.,Ltd Hatlab and 360 Alpha Lab contribution.

Please unzip the firmware file first then check the MD5 code.
MD5: 41ddf19e04b4749ff8c1cea00cb5777d
DOWNLOAD
SHOW MORE DESCRIPTION

So, out of this list, which security fix are you sorely missing that's causing you to suddenly go all panicky?

If the fact that (for obvious reasons) I cannot provide Asus's fixes the very same day they release them themselves, then by all means, switch to the stock firmware.

And when they release Curl security fixes 6 months after me, then you can panic some more, and switch again to my firmware.

Seriously, this constant "OMG SECURITIZE, YOU ARE BEHIND ASUS" panic has to stop, I'm sick and tired of hearing the same tired song year after year.

Surely it would have made more sense for Asus to provide you with GPL from an already tried, tested and released version [for e.g. GPL 386_45898]??. Issues that members are raising here with Alpha2 seem to be echo's from past, already rectified errors.

Dude, the vast majority of the raised issues (PPPoE, VPN page, etc...) were all the usual merge-related issues that come from me having to merge a 1.2 GB source tarball on top of my code with zero idea as to what changed and why. They have nothing to do with things Asus has fixed, they are just the usual issues that will happen whenever I merge a new GPL, and I am still in the alpha stage - not even in beta stage yet. And the few wifi-related complains? Look at every single past release, there are always people claiming that "OMG new release completely broke my wifi!". And not a single time have I been able to reproduce any of the reported wifi issues. Same thing again with 45581, my wifi is rock-solid ever since I started running it last week.

Chill out...

 

[RMerlin]

I'd like to also explain what the kernel error message means exactly, because there is no such thing as "dcd tainted". They are two totally separate fields... Let's take an example:

 kernel: CPU: 1 PID: 17491 Comm: dcd Tainted: P O 4.1.27 #2 Aug 25 10:38:46

This decodes as follow:

CPU: 1
PID: 17491
Comm: dcd
Tainted: P O
4.1.27 #2 Aug 25 10:38

First line: which CPU was running the crashed process
Second line: PID of the crashed process
Third line: name of the process
Fourth line: kernel taint status, with the flags saying what taints it
Fifth line: kernel version

The Taint status is followed by the flags P and O, which means this:

P: Proprietary Module loaded
O: Out of Tree Module loaded

Kernels are flagged as "tainted" by these because to a kernel developer, it means: "Don't accuse the kernel of being buggy, the bug could very well come from those proprietary modules".

The only thing this message says here is that dcd, the Trend Micro proprietary daemon, has crashed. There's nothing "tainted" about it. And there's no way to say why dcd has crashed, because... proprietary. A few years ago thelonelycoder (I believe) did some digging, and apparently one of the things that can lead dcd to crash is the presence of an interface with a very long name. There might be other reasons - only Trend Micro would know (Asus doesn't get that source code either AFAIK).

And yes, as others pointed out, that issue has existed for years, happening mostly on the RT-AC86U, but also on other models when triggered by something in particular (such as the long interface names).

 

[kernol]

...

So, out of this list, which security fix are you sorely missing that's causing you to suddenly go all panicky?

If the fact that (for obvious reasons) I cannot provide Asus's fixes the very same day they release them themselves, then by all means, switch to the stock firmware.

And when they release Curl security fixes 6 months after me, then you can panic some more, and switch again to my firmware.

Seriously, this constant "OMG SECURITIZE, YOU ARE BEHIND ASUS" panic has to stop, I'm sick and tired of hearing the same tired song year after year.

Chill out...

Clearly I offended you [without any intention of doing so] - the personal attack on me in response is not warranted - so I will not respond ...
Save to say nothing in my posts have suggested a state of panic on my part - that's really unfair!

 

[pirx73]

Well some of the security issues are indeed overblown. If you read description that for some of them to trigger you really have to work hard to deliberately create such kind of situation when they can be exploited.
To put it in more flowery terms: "when black raven flies past your window from left to right exactly at midnight and beam of moonlight hits your router precisely in WAN port at the same time, horrible things might happen..."

 

[skeal]

It would seem there are a pile of people here that don't understand alpha testing. Alpha testing is not for the faint of heart. You either stick to it or get out of the testing loop. Another thing you never put an alpha build on a production router anyway without risks. Just my two cents.

 

[waeking]

I noticed that Alpha2 has this listed NEW: Added support for the RT-AC68_V4 in the readme notes. I could not find Alpha2 in the download link. only Alpha1 is listed for AC68U,

 

[RMerlin]

I noticed that Alpha2 has this listed NEW: Added support for the RT-AC68_V4 in the readme notes. I could not find Alpha2 in the download link. only Alpha1 is listed for AC68U,

Support is added based on an older GPLs, I haven`t received an updated 45581 GPL yet for that model (same as for the other missing models).

 

[JGrana]

It would seem there are a pile of people here that don't understand alpha testing. Alpha testing is not for the faint of heart. You either stick to it or get out of the testing loop. Another thing you never put an alpha build on a production router anyway without risks. Just my two cents.

Wise words @skeal. As you so aptly put, Alpha builds are not for production or any other situations were WiFi/Internet is important - like working from home, family needs etc.
Alpha testers should understand this - and do testing. A great example was @Elmer 's noting that there are some issues with mounted USB devices. And, more important, he did the research and explained how to mitigate it.
It also important to note that the Addon devs don't update their code until after Beta. They realize the issues with trying to adapt to Alphas/Betas.

I for one, appreciate the folks that do this Alpha testing. My router is critical in the sense that my wife uses the Internet for learning (and recipes ;-) If it's down - I need to drop whatever I am doing and "fix it"!
So, I will wait until it is more "cooked", closer to Beta.

As a side (and I don't want to start a flame war), there is often some amount of stress on "security updates". From what I can see, @RMerlin and Asus are very knowledgeable in this area and do a great job. Better than most.
If you really need a very secure and always updated router - you probably shouldn't be using Asus or Netgear or Linksys or any consumer grade router.

 

[JWoo]

Wise words @skeal. As you so aptly put, Alpha builds are not for production or any other situations were WiFi/Internet is important - like working from home, family needs etc.
Alpha testers should understand this - and do testing. A great example was @Elmer 's noting that there are some issues with mounted USB devices. And, more important, he did the research and explained how to mitigate it.
It also important to note that the Addon devs don't update their code until after Beta. They realize the issues with trying to adapt to Alphas/Betas.

I for one, appreciate the folks that do this Alpha testing. My router is critical in the sense that my wife uses the Internet for learning (and recipes ;-) If it's down - I need to drop whatever I am doing and "fix it"!
So, I will wait until it is more "cooked", closer to Beta.

As a side (and I don't want to start a flame war), there is often some amount of stress on "security updates". From what I can see, @RMerlin and Asus are very knowledgeable in this area and do a great job. Better than most.
If you really need a very secure and always updated router - you probably shouldn't be using Asus or Netgear or Linksys or any consumer grade router.

The largest business grade router company in the world is Cisco (50BUSD in annual revenue). Cisco owned Linksys up until 2013 when they sold it to Belkin. Linksys while owned by Cisco, and now, is one of the worst on firmware quality, features and update frequency. Cisco, for a lot of their small business routers such as the Cisco RV260W, only provides a firmware update about every 2 years.

Netgear has a division for small business, and I can say first hand that most of their small business products get a firmware update 1 - 2 times a year and not more often.

TP Link on the consumer side sometimes doesn't provide any firmware updates. If they provide 1 or 2 updates in the life of a router it is a miracle.

For all of their warts, Asus is about the best of any of the router manufacturers in maintaining software and providing security updates. Merlin updates components very frequently, which incorporates many security updates. I don't think you will find any firmware updated more frequently or professionally than AsusWRT-Merlin, Fresh Tomato or OpenWRT. These are the best 3 router distros going.

 

[Frost]

As I did a dirty upgrade on RT-AX86U from 386.3_2 to 386.4 Alpha2, all worked well but not one of the OpenVPN Clients. A return to 386.3_2 didn`t help, and now no clients connect. (Only the OpenVPN does not work).

Configured with (not connecting but worked well before alpha2) “auth-nocach”:
Nov 4 18:39:43 ovpn-client1[28050]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:40: auth-nocach (2.5.3)
Nov 4 18:39:43 ovpn-client1[28050]: Use --help for more information.
Nov 4 18:39:43 openvpn: Starting OpenVPN client 1 failed!
Nov 4 18:39:43 openvpn-routing: Clearing routing table for VPN client 1

Configured with no “auth-nocach” and connection ok:
Nov 4 18:42:24 dnsmasq[24513]: using nameserver 62.50.161.166#53
Nov 4 18:42:26 ovpn-client1[28536]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Nov 4 18:42:26 ovpn-client1[28536]: Initialization Sequence Completed.

Any advice ?

 

[octopus]

As I did a dirty upgrade on RT-AX86U from 386.3_2 to 386.4 Alpha2, all worked well but not one of the OpenVPN Clients. A return to 386.3_2 didn`t help, and now no clients connect. (Only the OpenVPN does not work).

Configured with (not connecting but worked well before alpha2) “auth-nocach”:
Nov 4 18:39:43 ovpn-client1[28050]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:40: auth-nocach (2.5.3)
Nov 4 18:39:43 ovpn-client1[28050]: Use --help for more information.
Nov 4 18:39:43 openvpn: Starting OpenVPN client 1 failed!
Nov 4 18:39:43 openvpn-routing: Clearing routing table for VPN client 1

Configured with no “auth-nocach” and connection ok:
Nov 4 18:42:24 dnsmasq[24513]: using nameserver 62.50.161.166#53
Nov 4 18:42:26 ovpn-client1[28536]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Nov 4 18:42:26 ovpn-client1[28536]: Initialization Sequence Completed.

Any advice ?

Return to 386.3_2 build. This is a early Alpha build. """ check spelling"""

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

https://onedrive.live.com/?authkey=!AGY2taGX02nVmWA&id=CCE5625ED3599CE0!1427&cid=CCE5625ED3599CE0 Those of you who want to test alpha builds are aware that no support is given. This is for more advanced users who want to try in an early injury. If you have problems return to the previous...

www.snbforums.com

 

[ItsMeDude]

Dirty flash from A1 to A2 on an AX88U/AX68U node with no issues since Tuesday11/2.

 

[shabbs]

No need to revert to an old firmware version (which to me is a 'worst practice').

When testing out Alpha's, sometimes it's the only option. An actionable and repeatable fallback plan is always a best practice too.

 

[Lee MacMillan]

TP Link on the consumer side sometimes doesn't provide any firmware updates. If they provide 1 or 2 updates in the life of a router it is a miracle.

Exactly the reason I switched from TP Link to Asus 2 1/2 years ago. I got more firmware updates from Asus in the first 3 or 4 months than I had received from TPLink in 2+ years on routers that were released about the same time.

 

[Frost]

Return to 386.3_2 build. This is a early Alpha build. """ check spelling"""

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

https://onedrive.live.com/?authkey=!AGY2taGX02nVmWA&id=CCE5625ED3599CE0!1427&cid=CCE5625ED3599CE0 Those of you who want to test alpha builds are aware that no support is given. This is for more advanced users who want to try in an early injury. If you have problems return to the previous...

www.snbforums.com

Thank you!
SNB: «----return to the previous build and wait---“
OpenVPN Community:
“Client fails to connect with 2.5, succeeds with 2.4.9”
“---failed on version 2.5.0-3, had to revert to 2.4.9 to succeed.”

Yes, I did return to the 386.3_2, but then all 5 OpenVPN Clients did not connect with “auth-nocach” (Connect with no auth-nocach and security risk)
I have tried to “clean” the router as advised by L&LD and flashed Merlin’s 386.3_2 again, but the problem with auth-nocach is the same.

Will it disappear with the new 386.4 ?

 

[octopus]

Thank you!
SNB: «----return to the previous build and wait---“
OpenVPN Community:
“Client fails to connect with 2.5, succeeds with 2.4.9”
“---failed on version 2.5.0-3, had to revert to 2.4.9 to succeed.”

Yes, I did return to the 386.3_2, but then all 5 OpenVPN Clients did not connect with “auth-nocach” (Connect with no auth-nocach and security risk)
I have tried to “clean” the router as advised by L&LD and flashed Merlin’s 386.3_2 again, but the problem with auth-nocach is the same.

Will it disappear with the new 386.4 ?

--auth-nocache Don't cache --askpass or --auth-user-pass username/passwords in virtual memory.
If specified, this directive will cause OpenVPN to immediately forget username/password inputs after they are used. As a result, when OpenVPN needs a username/password, it will prompt for input from stdin, which may be multiple times during the duration of an OpenVPN session.

When using --auth-nocache in combination with a user/password file and --chroot or --daemon, make sure to use an absolute path.

This directive does not affect the --http-proxy username/password. It is always cached.