What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Did you brick your RT-AX86U when upgrading to 386.7 Alpha1


  • Total voters
    26
  • Poll closed .
Status
Not open for further replies.
Meanwhile, the first alpha has been running on my RT-AC86U for 9 days, 18 hours and 13 minutes without issue.
I'm glad to hear that @HorseCalledHorse!

Have you by any chance noticed if those "bcm_mcast_mld_add:833" log messages (which were re-introduced a couple of versions ago) are still present in this latest GPL? I have 386.5_2 running on my RT-AC86U and I get 50-100 of those every day. As far as I understand, they're debugging entries Asus forgot to suppress, and several RT-AC86U owners are getting them. I know it's just a cosmetic issue and therefore low priority, but they're very distracting when you're trying to examine syslog.log. It's not clear to me whether RMerlin is able to suppress them in his firmware, as they may be part of the closed source.

Thanks in advance!
 
Last edited:
Merge 48966 binary blobs for RT-AC88U and RT-AC3100

Does RT-AC88U compile ok now?
Worth me trying?

Edit..
it failed to compile with an aclocal-1.16 missing error
cp ./aclocal ./aclocal-1.16 fixed it (was 1.16.1)

Untitled.png
 
Last edited:
Have you by any chance noticed if those "bcm_mcast_mld_add:833" log messages (which were re-introduced a couple of versions ago) are still present in this latest GPL?
To be honest, I rarely look at the log. If there's an issue I might examine it, but when things are working as expected, I don't care what the log says:)

But I took a look for you and could not find any "bcm_mcast_mld_add:833" messages in my log file. I have no idea whether or not they were there before switching to the alpha, however.
 
wanna try to enable 160Mhz on AC86u, anyone knows how to flash GT AC2900 firmware on AC86u?

saw a chinese website https://www.right.com.cn/forum/thread-5583755-1-1.html said their AC86u firmware has 160Mhz
Each region has its own rules for using the frequency band. That is why there is a difference. This is also illegal. In some countries, you may be subject to severe sanctions if it is frequency used for something. The same goes for power.
 
A new RT-AX86U image has been uploaded. As per Asus' instructions, this build does not contain the cferom component, which is what was causing the crash on certain routers versions.

Also, to be on the safe side if there are people compiling their own image, I have disabled the RT-AX86U build profile on github. People who still want to build their own RT-AX86U must do the following:

1) edit target.mak, and remove the "-disable" portion of the RT-AX86U model name
2) When flashing, flash the image that does not contain _cferom_ in the filename

This is only for the RT-AX86U (and it's variant the RT-AX86S).

Asus are still testing a permanent fix on their end.

As a side note, the RT-AX86U (and RT-AX68U) must now be built from the src-rt-5.02L.07p2axhnd/ SDK folder. I haven't received confirmation whether this was a permanent change, or if it will eventually be merged back in on top of the existing 5.02p1axhnd.675x SDK.

The Broadcom drivers have been crashing for at least 3 years. This is one on V 385.5.2. Do a google search and you will see all sorts of speculation to the cause. Time to abandon Bradcom based routers?

Jun 8 05:57:41 kernel: CPU: 1 PID: 3057 Comm: dcd Tainted: P O 4.1.52 #2
Jun 8 05:57:41 kernel: Hardware name: Broadcom-v8A (DT)
Jun 8 05:57:41 kernel: task: ffffffc02ccd2b00 ti: ffffffc029ac8000 task.ti: ffffffc029ac8000
Jun 8 05:57:41 kernel: PC is at 0x29c60
Jun 8 05:57:41 kernel: LR is at 0x29ee0
Jun 8 05:57:41 kernel: pc : [<0000000000029c60>] lr : [<0000000000029ee0>] pstate: 20070010
Jun 8 05:57:41 kernel: sp : 00000000ffbd7410
Jun 8 05:57:41 kernel: x12: 00000000000a211c
Jun 8 05:57:41 kernel: x11: 0000000000081bfc x10: 000000000000000b
Jun 8 05:57:41 kernel: x9 : 0000000000000003 x8 : 000000000000000b
Jun 8 05:57:41 kernel: x7 : 00000000f5b004bc x6 : 0000000000000036
Jun 8 05:57:41 kernel: x5 : 0000000000000093 x4 : 00000000f5b0051c
Jun 8 05:57:41 kernel: x3 : 0000000000000000 x2 : 000000000000000a
Jun 8 05:57:41 kernel: x1 : 000000000000000b x0 : 0000000000000000

Is Broadcom actually trying to fix this and made it worse? Possibly Asus is getting better at finding the failing module.
 
To be honest, I rarely look at the log. If there's an issue I might examine it, but when things are working as expected, I don't care what the log says:)

But I took a look for you and could not find any "bcm_mcast_mld_add:833" messages in my log file. I have no idea whether or not they were there before switching to the alpha, however.
Thanks a lot @HorseCalledHorse for checking your log. I understand you don't have a baseline to compare it to, but the absence of those log entries is at least a good sign. Thanks again!
 
The Broadcom drivers have been crashing for at least 3 years.
That`s not a Broadcom driver, that`s the Trend Micro dcd daemon tied to AiProtection... And one of the things that may make it crash are virtual network interfaces such as added by tls-pixelserv.
 
That`s not a Broadcom driver, that`s the Trend Micro dcd daemon tied to AiProtection... And one of the things that may make it crash are virtual network interfaces such as added by tls-pixelserv.
Do you mean... Virtual drivers On the Router or any virtual drivers even elsewhere On the network???
 
Tried flashing both alpha versions available for my RT-AC68U v4
(RT-AC68U_386.7_alpha1-g82406ddc5d.trx and RT-AC68U_386.7_alpha1-g8ee6420ea6.trx)
to see if this would fix the issue with my 2.4ghz network becomes inoperable after a period of time. Seems others have reported this fix this issue.

When I try to flash says firmware not for that router.

Im gussing they are on 30+ megs instead of 80+ meg that the newer v4 needs or just not built for the Rt-AC68U yet?

Any eta for an alpha that will work on v4?
 
Correct! (Brain lapse).

The 386.7.xx builds are becoming available (for supported models) as the GPL and RMerlin's free time to incorporate his changes allows.
 

Available builds:
RT-AC68U

XT12 (May 25, 2022)
- UPDATED: Merged with 386_48966 GPL.
- UPDATED: haveged to 1.9.18.

RT-AX56U (May 26. 2022)
RT-AX58U (May 26. 2022)

RT-AX88U (May 27, 2022)

GT-AC2900 (May 28, 2022)
GT-AX6000 (May 28, 2022)
GT-AX11000 (May 28, 2022)
RT-AC68U (May 28, 2022) (NEW)

RT-AX86U (June 05, 2022) Flash with caution make sure to use RT-AX86U not RT-AC86U, some brick is reported!!!
RT-AX68U (June 05, 2022)

RT-AX86U (June 06,2022) This build does not contain the cferom component, which is what was causing the crash on certain routers versions.



Code:
Asuswrt-Merlin 386/NG Changelog
===============================

386.7 (xx-xxx-xxxx)
  - UPDATED: Merged with 386_48823 GPL.
  - UPDATED: openssl to 1.1.1o.
  - CHANGED: dhcpc-event now has a second parameter that will
             contain "4" or "6" depending on the IP protocol of
             the event (dave14305)
  - FIXED: JFFS backup/restore functions not working on XT12
           and GT-AX6000.
  - FIXED: CVE-2022-0934 in dnsmasq (backport)
  - FIXED: CVE-2022-26376 (reported by Cisco Talos, fixed by Asus)
Just a friendly heads-up, you might want to review the supported model list, as the RT-AC68U is listed twice, but the RT-AC86U is left out, when it is in fact available on RMerlin's OneDrive alpha site.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top