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.
Use netstat in the ssh terminal. Not the gui.


Hi thanks for the suggestion, the extra dropdown is just missing for further analysis, @RMerlin can decide to leave it or to add it, see it as a sidenote regarding alphas. The Question is, if this is on purpose or just a forgotten one, nothing more. For me, it does it does its purpose within the GUI. Or do you think the outcome of the parameters are wrong within the GUI?
 
So new day the GT-AX11000 did it’s scheduled reboot again this morning however I watched it and LED didn’t reenable itself immediately it took awhile (like a couple hours) to reenable randomly.

under administration - system
Disable LEDsYes No


It was prior yes and now it’s back to no (sometime) after scheduling.

Noticed a similar issue with my RT-AX58u where as a node even though I set led as off under AImesh if the node reboots the leds get turned back on and stay on. For that issue it seems to reenable itself immediately instead of randomly.
 
Last edited:
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.
 
Last edited:
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.
Successfully updated two (2) RT-AX86U AiMesh nodes from previous 386.7 alpha1 to new image without cferom component.
 
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.
What aspect of router operation does the cferom component control?
 
Would you recommend to flash the new build over the first Alpha, even if the router didn't brick with the cferom component included?
The Bootloader (CFE) seems not updated and still at 0.0.0.6 for me, but this is maybe something else?!

RMu1M0qqgn.png
 
Last edited:
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.
Successfully flashed my RT-AX86U remotely via an OpenVPN Connection at work... Thanks.
EDIT: I just noticed that despite me having previously flashed my two RT-AC68U to this alpha...
The AiMesh wasn't re-established. (I haven't flashed in so long I can't remember if that was expected or typical) But I seem to recall having to bring the Node to the router, re-attach it temporarily via Ethernet & re-discover the node after upgrading firmware.
IMO The humorous part is I left one of my (TWO) RT-AC68U configured as an Access-Point with a Static IP-Address.
I did this because I'm finding the AiMesh upgrades seem to require more fiddling around with afterwards.
Sooooo If the BIG-PLUS of AiMesh is having a Single/Centrally Managed Router Configuration...
Isn't it ironic & somewhat unfortunate... that we have to physically relocate each router node, reconnect via ethernet, re-discover & then reposition the node after most firmware upgrades???
 
Last edited:
Problem on the AX86 after flash: I've never encountered this before.

Alpha 1 6.7.2022.JPG


Had to wipe the JFFS and restore from the backup I just made before the flash.

A second solo reboot did not fix it after the initial flash and the USB drive continued to show as "unmounted".
 
Just updated to "_alpha1-g9675d2e79d" and all went fine.

Discovered a new settings though.

Screenshot 2022-06-07 at 19-37-48 ASUS Wireless Router RT-AX86U - Internet Connection.png

Thank you RMerlin
 
Current alpha1 running on my AX-86U for about a half-hour now. No issues.

Thanks for the effort to get the initial alpha1 replaced, RMerlin!
 
Successfully remotely updated another RT-AX86U router from Merlin 386.5_2 to new Merlin 386.7_alpha1-g9675d2e79d.
 
Would you recommend to flash the new build over the first Alpha, even if the router didn't brick with the cferom component included?
Probably wouldn't make any real difference since you already have the newer cferom flashed, and everything is working fine.

The Bootloader (CFE) seems not updated and still at 0.0.0.6 for me, but this is maybe something else?!
The version won't change if it's just a recompiled version with changes or patches applied on top of it, and they are still using the same base code as before.

Problem on the AX86 after flash: I've never encountered this before.
It means your partition either filled itself up, or it's not mounting properly due to an issue or content corruption.

Discovered a new settings though.
A few months ago Asus implemented a preset list of DNS server. A few weeks ago they revamped it to make it more user-friendly by having a dedicated popup rather than a filled up dropdown with limited information. This isn't a new feature, just a redesigned interface to manage the WAN DNS servers.
 
I seem to be having issues with the DNS filter list on my RT-AX88U running alpha1. Once I get over 11 clients in the filter list I cannot set the DNS filter as it (for those clients) reverts back to "No FIltering". I've factory reset and clean installed from scratch (and factroy reset again) and the issue persists. Had a similar issue with an earlier build which RMerlin fixed - wonder if this is a recurrence?
 
Was the 5300 dropped from future builds, or is it still supported moving forward? I have been debating an upgrade lately :confused:
I think the RT-AC3100 and RT-AC5300 are just lower priority than any of the RT-AX models.

There is nothing wrong with my RT-AC3100, but the RT-AX86U is a very good upgrade.
 
What aspect of router operation does the cferom component control?
 
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