What's new

Release Asuswrt-Merlin 386.5 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.
another issue I have is that i can't switch back to stock on my AX3000 (Aimesh node) from 386.5. Any stock f/w fails to install. I can install any merlin f/w on it. I am definitely using the correct model image (RT-AX3000)
Same problem here.

Also I am unable to search for AIMESH nodes. I can press search but it will not find anything. Worked fine on stock firmware but not on 386.5.
 
I'm running about a dozen IoT devices on my 2.4GHz guest network - connection for all of them has been stable since I flashed 368.5 two days ago. This includes my 'problem child' (TP-Link HS100 plug towards the edge of reception in the far corner of the garden), which has been connected for over 53 hours solid now.
Excellent, thank you. Did you had 386.4 on AC86u? And what was WiFi there?
 
Excellent, thank you. Did you had 386.4 on AC86u? And what was WiFi there?
From memory:
  • 386.3: stable for 150+ days
  • 386.3_2: skipped this one, can't recall why
  • 386.4 caused various issues including guest 1 not propagating to node properly, wifi instability (both 5GHz and 2.4GHz), and general router instability. Symptoms improved (but did not disappear) after I moved my node to stock.
  • 386.5_alpha1: skipped as not available for AC86U
  • 386.5_alpha2: problems vanished: wifi stable, guest 1 propagating properly to node, etc.
  • 386.5_beta: skipped as not too different from alpha2 and was wanting to test alpha2 stability over time
  • 386.5 release: all good so far as reported above.
 
Last edited:
I just can't seem to get the 386.5 firmware upgrade to initialize on a remotely located RT-AC86U.
Meaning... I never get to see the Loading progress bar (which I believe is handled via java/javascript)
After clicking manual update... the browser always times out.
I typically use Firefox, but have also tried Chrome & MS Edge.
Eventually I resorted to trying the latest stock firmware 3.0.0.4.386_46092-g0d2214a.
Which did succeed & the most obvious difference being a smaller file-size.
Unfortunately the reason for the remote location is...
Many moons ago I recommended The RT-AC86U to my wife's boss because I already had familiarity & good experiences with the RT-AC68U in our home.
You can probably imagine my surprise, when discovering... the slower response of the Web-GUI despite the 86 having better specs than the older 68.
IMO It's always seemed the TLS encryption which really slows the GUI responsiveness.

Regardless,
The remote updating on the RT-AC86U has always been a PITA & inconsistent.
I usually have to reboot it several times & make a-few attempts.
+ I typically had success if I used the WAN IP instead of the DDNS...
for example: https://77.77.123.45:8443
But this time...

No Luck, no luck, no luck, no luck...

I've seen many others occasionally fighting with the RT-AC86U & firmware updates.
Not sure if the Web-server time-out could be extended or if there are better options to somehow improve the upgrade process.

But I'm really regretting recommending the RT-AC86U as I'm the guy who tries to remotely update it.

On the positive note...
Myself & the family are already on the 386.5 firmware with a few AC68U nodes & an AX86U.
All good on those routers, THX
 
I am looking upgrade the merlin firmware on my ac68u from 3.0.03.384.5_0 to 386.5, is it possible without having any issues ? Its been long due, I would like to do this without any hiccup.
 
I am looking upgrade the merlin firmware on my ac68u from 3.0.03.384.5_0 to 386.5, is it possible without having any issues ? Its been long due, I would like to do this without any hiccup.
Make a backup of your current firmware, settings and JFFS. Then if the upgrade doesn't work for you it's quick and easy to restore to where you were.

P.S. I assume you mean 384.5_0 rather than 3.0.03.384.5_0.
 
Last edited:
Make a backup of your current firmware, settings and JFFS. Then if the upgrade doesn't work for you it's quick and easy to restore to where you were.

P.S. I assume you mean 384.5_0 rather than 3.0.03.384.5_0.

I believe you are right, I though there was a big gap between firmware. I may have upgraded the firmware.
 
The remote updating on the RT-AC86U has always been a PITA & inconsistent.
I usually have to reboot it several times & make a-few attempts.
+ I typically had success if I used the WAN IP instead of the DDNS...
for example: https://77.77.123.45:8443
But this time...

No Luck, no luck, no luck, no luck...

I've seen many others occasionally fighting with the RT-AC86U & firmware updates.
Not sure if the Web-server time-out could be extended or if there are better options to somehow improve the upgrade process.

But I'm really regretting recommending the RT-AC86U as I'm the guy who tries to remotely update it.
I manage multiple remote RT-AC86U routers and finally decided that it is easier to bypass the GUI. That way I have at least some visibility into what happens with each step along the way. AFAIK, this method is completely unsupported and may melt your router. I do this all over VPN so the GUI is never exposed to the WAN.

1. Use "scp" to transfer the .w file to the remote router's /tmp directory
% scp RT-AC86U_386.5_0_cferom_ubi.w admin@1.2.3.4:/tmp

2. Login to the remote router using 'ssh' and update the firmware via the CLI
% ssh admin@1.2.3.4
# cd /tmp
# /sbin/hnd-write RT-AC86U_386.5_0_cferom_ubi.w

3. When that completes, return back to the GUI and use the "Reboot" button to restart the remote router.

Note that step #1 may be very slow with a high-latency connection due to the small receive buffer window size that 'dropbear' uses by default, so I usually re-launch it on the remote router with a larger buffer size on a different port before step 1 (and then specify -P for the 'scp' command to use the alternate port).
# dropbear -W 524288 -p 1.2.3.4:2222 -j -k
 
Dirty upgrade from 386.4_2, didn't remove any USB sticks, cables or anything. Let it sit for 30 minutes and "settle down". Rebooted, and have been working flawlessly for 3 days straight. Thanks Rmerlin :)
 
I manage multiple remote RT-AC86U routers and finally decided that it is easier to bypass the GUI. That way I have at least some visibility into what happens with each step along the way. AFAIK, this method is completely unsupported and may melt your router. I do this all over VPN so the GUI is never exposed to the WAN.

1. Use "scp" to transfer the .w file to the remote router's /tmp directory
% scp RT-AC86U_386.5_0_cferom_ubi.w admin@1.2.3.4:/tmp

2. Login to the remote router using 'ssh' and update the firmware via the CLI
% ssh admin@1.2.3.4
# cd /tmp
# /sbin/hnd-write RT-AC86U_386.5_0_cferom_ubi.w

3. When that completes, return back to the GUI and use the "Reboot" button to restart the remote router.

Note that step #1 may be very slow with a high-latency connection due to the small receive buffer window size that 'dropbear' uses by default, so I usually re-launch it on the remote router with a larger buffer size on a different port before step 1 (and then specify -P for the 'scp' command to use the alternate port).
# dropbear -W 524288 -p 1.2.3.4:2222 -j -k
OMG, & this... is EXACTLY why I love this Forum!!! I will be trying this shortly...
EDIT: Great Success ;-) & I absolutely loved being able to see all the progress via ssh
Thanks again
If I had only known of this a few years ago... Oh the time it would have saved me.
But I appreciate it sooooo much more after all the failures.
Appreciated VERY much
THX
 
Last edited:
After uploading the latest firmware my "System Log - General Log" in the UI section is empty no matter what log level I set.
Tried to reboot several times but nothing changed.

Any help plz?
 
Last edited:
I just can't seem to get the 386.5 firmware upgrade to initialize on a remotely located RT-AC86U.
Meaning... I never get to see the Loading progress bar (which I believe is handled via java/javascript)
After clicking manual update... the browser always times out.
I typically use Firefox, but have also tried Chrome & MS Edge.
Eventually I resorted to trying the latest stock firmware 3.0.0.4.386_46092-g0d2214a.
Which did succeed & the most obvious difference being a smaller file-size.
Unfortunately the reason for the remote location is...
Many moons ago I recommended The RT-AC86U to my wife's boss because I already had familiarity & good experiences with the RT-AC68U in our home.
You can probably imagine my surprise, when discovering... the slower response of the Web-GUI despite the 86 having better specs than the older 68.
IMO It's always seemed the TLS encryption which really slows the GUI responsiveness.

Regardless,
The remote updating on the RT-AC86U has always been a PITA & inconsistent.
I usually have to reboot it several times & make a-few attempts.
+ I typically had success if I used the WAN IP instead of the DDNS...
for example: https://77.77.123.45:8443
But this time...

No Luck, no luck, no luck, no luck...

I've seen many others occasionally fighting with the RT-AC86U & firmware updates.
Not sure if the Web-server time-out could be extended or if there are better options to somehow improve the upgrade process.

But I'm really regretting recommending the RT-AC86U as I'm the guy who tries to remotely update it.

On the positive note...
Myself & the family are already on the 386.5 firmware with a few AC68U nodes & an AX86U.
All good on those routers, THX
I feel your pain. I have an AX86U remote and trying to update the firmware has been a struggle. I actually was successful once nudging it to 386.5._alpha1. Took many many attempts.

I have an SSD drive attached to the USB and run a few addons (wg_manager, unbound).

Before I attempt an upgrade, I disable jffs scripts and then reboot. I then ssh in and unmount the USB drive. I can't reboot since it will remount.
I have tried the update at least a dozen times. Just hangs - never getting to the Loading bar like yours.

I am going to the remote location mid next week and will do it on-site...

Seems an "86U" issue ;-)
 
Does anyone know what these repeated-by-the-dozen and more Syslog entries are about? Are they result of a misconfiguration? I'm not a Syslog watcher, but these have me curious.

Mar 6 14:34:18 acsd: acs_candidate_score_txop(1860): eth7: txop check failed for chanspec: 0xe832 (36/160)
Mar 6 14:34:18 acsd: acs_candidate_score_intf(1133): eth7: intf check failed for chanspec: 0xe932 (40/160)
Mar 6 14:34:18 acsd: acs_candidate_score_bgnoise(1602): eth7: bgnoise check failed for chanspec: 0xe932 (40/160)
Mar 6 14:34:18 acsd: acs_candidate_score_txop(1860): eth7: txop check failed for chanspec: 0xe932 (40/160)
Mar 6 14:34:18 acsd: acs_candidate_score_intf(1133): eth7: intf check failed for chanspec: 0xea32 (44/160)
Mar 6 14:34:18 acsd: acs_candidate_score_bgnoise(1602): eth7: bgnoise check failed for chanspec: 0xea32 (44/160)
Mar 6 14:34:18 acsd: acs_candidate_score_txop(1860): eth7: txop check failed for chanspec: 0xea32 (44/160)
Mar 6 14:34:18 acsd: acs_candidate_score_intf(1133): eth7: intf check failed for chanspec: 0xeb32 (48/160)
Mar 6 14:34:18 acsd: acs_candidate_score_bgnoise(1602): eth7: bgnoise check failed for chanspec: 0xeb32 (48/160)
Mar 6 14:34:18 acsd: acs_candidate_score_txop(1860): eth7: txop check failed for chanspec: 0xeb32 (48/160)
Mar 6 14:39:05 hostapd: eth7: STA 4c:17:44:08:2b:ab WPA: group key handshake completed (RSN)

Thanks.
 
My "System Log - General Log" in the UI section is empty no matter what log level I set.
Tried to reboot several times but nothing changed.

Any help plz?
Have you reset to factory defaults and manually reconfigured the router?
 
Does anyone know what these repeated-by-the-dozen and more Syslog entries are about? Are they result of a misconfiguration? I'm not a Syslog watcher, but these have me curious.

Mar 6 14:34:18 acsd: acs_candidate_score_txop(1860): eth7: txop check failed for chanspec: 0xe832 (36/160)
Mar 6 14:34:18 acsd: acs_candidate_score_intf(1133): eth7: intf check failed for chanspec: 0xe932 (40/160)
Mar 6 14:34:18 acsd: acs_candidate_score_bgnoise(1602): eth7: bgnoise check failed for chanspec: 0xe932 (40/160)
Mar 6 14:34:18 acsd: acs_candidate_score_txop(1860): eth7: txop check failed for chanspec: 0xe932 (40/160)
Mar 6 14:34:18 acsd: acs_candidate_score_intf(1133): eth7: intf check failed for chanspec: 0xea32 (44/160)
Mar 6 14:34:18 acsd: acs_candidate_score_bgnoise(1602): eth7: bgnoise check failed for chanspec: 0xea32 (44/160)
Mar 6 14:34:18 acsd: acs_candidate_score_txop(1860): eth7: txop check failed for chanspec: 0xea32 (44/160)
Mar 6 14:34:18 acsd: acs_candidate_score_intf(1133): eth7: intf check failed for chanspec: 0xeb32 (48/160)
Mar 6 14:34:18 acsd: acs_candidate_score_bgnoise(1602): eth7: bgnoise check failed for chanspec: 0xeb32 (48/160)
Mar 6 14:34:18 acsd: acs_candidate_score_txop(1860): eth7: txop check failed for chanspec: 0xeb32 (48/160)
Mar 6 14:39:05 hostapd: eth7: STA 4c:17:44:08:2b:ab WPA: group key handshake completed (RSN)

Thanks.
Rather than auto channel selection, it's widely believed that setting a static channel is far better for all sorts of reasons. You can use the wifi radar to figure what channel you should use.
EDIT: I see your set to 160 channel bandwidth, I would use 80 myself. There is also 802.11b and 802.11g noise problem.
 
Last edited:
No reset to factory defaults. I just enabled ssh to create a JFFS script to check the WAN connection (Chk-WAN).
I highly recommend it. If you don't have many settings it's really easy.
 
OMG, & this... is EXACTLY why I love this Forum!!! I will be trying this shortly...
EDIT: Great Success ;-) & I absolutely loved being able to see all the progress via ssh
Thanks again
If I had only known of this a few years ago... Oh the time it would have saved me.
But I appreciate it sooooo much more after all the failures.
Appreciated VERY much
THX
I just did this procedure as well. Thanks @csj97229 and @capncybo . I figured I would be on site in a few days, I have an internet monitoring plug that will power cycle the router in case of a hang. Checked the sha256 of the firmware post SCP and - the AX86U is now running 386.5 happily.
 
Same problem here.

Also I am unable to search for AIMESH nodes. I can press search but it will not find anything. Worked fine on stock firmware but not on 386.5.

I suggest you connect the node via WAN port to ethernet port (cat5) to the main router then add/search for the node. Once added. disconnect from ethernet and it will switch to wifi backhaul
 
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