What's new

Beta Asuswrt-Merlin 386.1 Beta (stage 2) is now available

  • 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!

Status
Not open for further replies.
Then I don't know. The RT-AC66U_B1 is my primary development platform (since it's faster to compile), so I've done lots of firmware flashing to it so far, never ran into any issue.

I would check the amount of available nvram. Asus suspects that part of the recent failures for the RT-AC68U firmware update were caused by lack of nvram.
The one I am having issue with shows 55.33 KB NVRAM used of 64 KB total (about 9 KB (or 13.5%) free). Asus has flashed a warning on the GUI home page when NVRAM drops too low, but it has never done it on this particular device. The warning suggests a validation issue, similar to what I saw on my RT-AX88U (resolved by your test release earlier this evening!) Does the RT-AC66U hardware identify itself differently than the RT-AC68U?
 
Asus has flashed a warning on the GUI home page when NVRAM drops too low, but it has never done it on this particular device

They haven't, it's a feature of my firmware.

The warning suggests a validation issue, similar to what I saw on my RT-AX88U (resolved by your test release earlier this evening!) Does the RT-AC66U hardware identify itself differently than the RT-AC68U?

I have no idea what exact validation steps are taken, the validation code is closed source. All I can say is that the component I had to downgrade on the RT-AX88U doesn't exist on the RT-AC68U, it's part of the HND architecture used by the RT-AC86U and newer models.

In the past, validation involved checking that you were running genuine hardware by looking at various parameters (to prevent cross flashing on hacked/non Asus models for instance), making sure you are flashing the correct model, enforcing a minimum firmware version on certain hardware revisions to prevent people with an RT-AC68U V2 from flashing a pre-V2 firmware that would soft brick their router, and things like that. I include the pre-compiled validation code whenever I merge a new GPL, it's part of the binary blobs for libshared.
 
People with failed RT-AC68U upgrades, what exact model and revision do you have? It should be on the sticker under the router.
 
The one I am having issue with shows 55.33 KB NVRAM used of 64 KB total (about 9 KB (or 13.5%) free). Asus has flashed a warning on the GUI home page when NVRAM drops too low, but it has never done it on this particular device. The warning suggests a validation issue, similar to what I saw on my RT-AX88U (resolved by your test release earlier this evening!) Does the RT-AC66U hardware identify itself differently than the RT-AC68U?

I disabled the Trend Micro stuff and was able to flash beta4 - the only problem is that it wants to be rebooted manually - and it's 50 km away :)
 
I uploaded a beta4b build for the RT-AC86U which overrides the closed source portion that was disabling CPU wait state. Same test-build folder as the RT-AX88U build.
 
People with failed RT-AC68U upgrades, what exact model and revision do you have? It should be on the sticker under the router.
I will check later today as I'm not at the location at the moment.
 
People with failed RT-AC68U upgrades, what exact model and revision do you have? It should be on the sticker under the router.

As an additional data point, 68U dirty upgrade went fine from beta3 to beta4. HW ver. C1.
 
Last edited:
I uploaded a beta4b build for the RT-AC86U which overrides the closed source portion that was disabling CPU wait state. Same test-build folder as the RT-AX88U build.
Just uploaded beta4b build, CPU temp drop around 5 C
 
Since I posted in the wrong message thread, o_O I have restored my AX88U with the Asus firmware recovery tool. I could not get the AX88U to accept another firmware. I tried multiple reboots and different firmwares. The recovery tool worked perfectly fine.

I tried Skynet again. It's working now. Picking up the model of the router successfully.

Router Model; RT-AX88U
Skynet Version; (01/12/2020) (358a0e65e85afa8425897a993eb84b8c)
iptables v1.4.15 - (eth0 @ 192.168.1.1)
ipset v7.6, protocol version: 7
IP Address;
FW Version; 386.1_beta4b-gb9175c6a96 (Jan 9 2021) (4.1.51)
Install Dir; /tmp/mnt/sda1/skynet (50.3G / 56.2G Space Available)
 
I uploaded a beta4b build for the RT-AC86U which overrides the closed source portion that was disabling CPU wait state. Same test-build folder as the RT-AX88U build.
CPU wait is enabled after flashing Beta 4b over Beta 4. Thanks!
 
Woke up to one or two events :)

So I'm using the problematic initial beta 4 for my AX88U. I noted that I'm unable to flash anything as, what has been reported, it reports invalid image.
I have download the Asus restoration utility (never used before) and also both the 384.19 and the test beta 4b firmware that Eric has upload.
Before I do anything is the beta 4b good to be considered a "keeper" or was that released for the intentions of understanding the current situation better..?
In other words would I be better using the Asus restoration utility (rescue) to flash beta 3 or can the beta 4 be used just as safely..?


Thanks
 
Woke up to one or two events :)

So I'm using the problematic initial beta 4 for my AX88U. I noted that I'm unable to flash anything as, what has been reported, it reports invalid image.
I have download the Asus restoration utility (never used before) and also both the 384.19 and the test beta 4b firmware that Eric has upload.
Before I do anything is the beta 4b good to be considered a "keeper" or was that released for the intentions of understanding the current situation better..?
In other words would I be better using the Asus restoration utility (rescue) to flash beta 3 or can the beta 4 be used just as safely..?


Thanks


So far I'm very happy with beta4b...
 
I seem to be getting that nf_contrack expectation table full error again seems to have returned after the faulty beta 4, I'm on the revised beta 4 after following Merlin's instructions.

I hope that one day Asus will fix whatever is causing the that error message.
 
Thank you! I did not know that enabling AI-Protection reduces the DL speed by almost 30%
I think it's a bug in the beta 4 update after flashing to the new beta 4 I'm getting full speed with AI protection on on my AX88U.
 
I uploaded a beta4b build for the RT-AC86U which overrides the closed source portion that was disabling CPU wait state. Same test-build folder as the RT-AX88U build.
Its this sort of dedication, time and energy, you put into your firmware, is the only reason I stay with ASUS routers. Thank you in providing a better world with ASUS routers..

It works, after reboot it sticks....no script required.

1610267471981.png
 
Last edited:
Hi,
here is my story: Yesterday i upgraded my ax88u to the beta 4. Today i used the recovery tool to went back to beta 3. All went fine but in the end my ax88u won´t start. All lights are dead. I´m very happy that my old ac88u was always fully configured. I bought my ax88u in November at Amazon, so i can change the device without issue. In future i only will use stable versions. Learned that.
 
So that means Asus broke the firmware validation code, and it's not a merge error on my end. I know it's not an image header issue since previous firmware images or the same image will fail to flash. Flashing through the webui fails reporting a CRC mismatch between the file and the image, and flashing through the command line fails because it reports a mismatched OTP configuration. Which makes it even weirder, two totally different error messages when flashing from two different tools. Even weirder is that little has changed in the AX88U SDK, beside the wifi SoC firmware itself (which had finally resolved video streaming issues here).

I guess we're looking at a few more weeks of debugging until I can finally get 386.1 finalized. At this point maybe I should just pull a Brainslayer, and give up on pushing out "final" releases, and just push a constant stream of betas...

So I had that validation issue on RC10. But I tried 4 times to revert the fw to beta 3 from RC10 using GUI and then the validation passed. No issues downgrading from beta4 to beta3 on ax88u. 41535 is broken a lot for AX88U.
 
So I had that validation issue on RC10. But I tried 4 times to revert the fw to beta 3 from RC10 using GUI and then the validation passed. No issues downgrading from beta4 to beta3 on ax88u. 41535 is broken a lot for AX88U.
See post# 202 from Merlin......there is a new b4b image for this router.....have you tried that new build yet? People are already reporting, a lot of good things about this revised firmware.



 
Last edited:
So far I'm very happy with beta4b...

Agreed. Out of the 3 versions of "Beta 4" for the RT-AX88U, Beta 4B is a keeper. Been testing it all night, no bugs or issues found yet,
 
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