Release Asuswrt-Merlin 386.5 is now available

[RMerlin]

So I take it that the GPL_firmware version of a given version number has the same changelog and is considered identical to the corresponding Proprietary_firmware version number, then?

The GPL portions of the code are the same, yes. However there are also all my own changes and backports on top of it, so they aren`t 100% identical (for example the OpenSSL and AiCloud backports present in 386.5_2).

When, approximately, do you expect the 4820 to hit GPL and subsequently the Merlin release?

I don`t know. My current focus is 386.6 and the two new models. Once that's out I will discuss with Asus which next GPL version I should get from them for 386.7, I'm nowhere near that stage yet. It will most likely be something newer than 48020 (depending on what's available and considered stable enough at that point).

 

[Bhlhomme]

So 836.5 gave me issues uploading to my GT-AX11000 I totally forgot what I did to make it work, I feel like I altered the file name. But I’m having the same issue with this update. It’ll try uploading the firmware then kick back with a Firmware Update Unsuccessful. Could I get a little insight on how to figure this out?

 

[JIPG]

The GPL portions of the code are the same, yes. However there are also all my own changes and backports on top of it, so they aren`t 100% identical (for example the OpenSSL and AiCloud backports present in 386.5_2).


I don`t know. My current focus is 386.6 and the two new models. Once that's out I will discuss with Asus which next GPL version I should get from them for 386.7, I'm nowhere near that stage yet. It will most likely be something newer than 48020 (depending on what's available and considered stable enough at that point).

Just out of curiosity: Will the "general" commits (not specific to the two new models) included in 386.6, be included again on 386.7 for the rest of the models or new specific ones have to be introduced again?. I am trying to understand how the timeline works in the commits world.

 

[RMerlin]

Just out of curiosity: Will the "general" commits (not specific to the two new models) included in 386.6, be included again on 386.7 for the rest of the models or new specific ones have to be introduced again?. I am trying to understand how the timeline works in the commits world.

It's all linear, from the same master branch on Github. I am not branching out models.

 

[heywire]

The GPL portions of the code are the same, yes. However there are also all my own changes and backports on top of it, so they aren`t 100% identical (for example the OpenSSL and AiCloud backports present in 386.5_2).


I don`t know. My current focus is 386.6 and the two new models. Once that's out I will discuss with Asus which next GPL version I should get from them for 386.7, I'm nowhere near that stage yet. It will most likely be something newer than 48020 (depending on what's available and considered stable enough at that point).

I take it from your answer that the Merlin-project is nowhere near a release that will include a fix for the 2.4ghz crashing on the AC86U if .48020 or newer is required from Asus first. Very sad news.

I hope you can ask Asus specifically about if they are aware of (/will admit) "systemic" issues with 2.4ghz on the AC86U, and whether they can provide you a fix in the GPL branch ASAP. So tired of being capture of Asus' lack of QC at this point. After months of frustration, I was planning on RMA'ing the devices altogether before .48020 came out. Now it seems to have improved since the last powercycle with 10 days uptime where before I had to restart or turn on/off WPS in order to get 2.4ghz working again every 1-3 days (not to mention all the problems before that version again). I upgraded from AC68U specifically to use Merlin, primarily because of CakeQOS, so at this point basically wasted money until Merlin-firmware starts working on the AC86U.

 

[DarkKnight75]

I take it from your answer that the Merlin-project is nowhere near a release that will include a fix for the 2.4ghz crashing on the AC86U if .48020 or newer is required from Asus first. Very sad news.

I hope you can ask Asus specifically about if they are aware of (/will admit) "systemic" issues with 2.4ghz on the AC86U, and whether they can provide you a fix in the GPL branch ASAP. So tired of being capture of Asus' lack of QC at this point. After months of frustration, I was planning on RMA'ing the devices altogether before .48020 came out. Now it seems to have improved since the last powercycle with 10 days uptime where before I had to restart or turn on/off WPS in order to get 2.4ghz working again every 1-3 days (not to mention all the problems before that version again). I upgraded from AC68U specifically to use Merlin, primarily because of CakeQOS, so at this point basically wasted money until Merlin-firmware starts working on the AC86U.

No issues with either 2.4 or 5GHZ crashing on my AC86U and on current Merlin 386.5

 

[RMerlin]

I take it from your answer that the Merlin-project is nowhere near a release that will include a fix for the 2.4ghz crashing on the AC86U if .48020 or newer is required from Asus first. Very sad news.

Have you tried the usual suggestions? Most people who had wifi issues in 386.4 said these were resolved for them with 386.5. Try doing a WPS reset, and ensuring that you disable any non-standard features on the 2.4 GHz band, such as Beamforming. A lot of 2.4 GHz clients use very old wifi modules that are often incompatible with these adavanced non-standard features.

 

[Jeffrey Young]

I take it from your answer that the Merlin-project is nowhere near a release that will include a fix for the 2.4ghz crashing on the AC86U if .48020 or newer is required from Asus first. Very sad news.

I hope you can ask Asus specifically about if they are aware of (/will admit) "systemic" issues with 2.4ghz on the AC86U, and whether they can provide you a fix in the GPL branch ASAP. So tired of being capture of Asus' lack of QC at this point. After months of frustration, I was planning on RMA'ing the devices altogether before .48020 came out. Now it seems to have improved since the last powercycle with 10 days uptime where before I had to restart or turn on/off WPS in order to get 2.4ghz working again every 1-3 days (not to mention all the problems before that version again). I upgraded from AC68U specifically to use Merlin, primarily because of CakeQOS, so at this point basically wasted money until Merlin-firmware starts working on the AC86U.

I have a number of TP-Link devices. No issues on my AC86U. If it helps, this is what what works for me;

 

[mmacedo]

It's not the first time I see these since upgrading to 386.5_2. Anything to worry about?

Apr  8 11:42:30 kernel: potentially unexpected fatal signal 11.
Apr  8 11:42:30 kernel: CPU: 0 PID: 851 Comm: httpd Tainted: P           O    4.1.52 #2
Apr  8 11:42:30 kernel: Hardware name: Broadcom-v8A (DT)
Apr  8 11:42:30 kernel: task: ffffffc01587eac0 ti: ffffffc013518000 task.ti: ffffffc013518000
Apr  8 11:42:30 kernel: PC is at 0x4802c
Apr  8 11:42:30 kernel: LR is at 0x47ff0
Apr  8 11:42:30 kernel: pc : [<000000000004802c>] lr : [<0000000000047ff0>] pstate: 80030010
Apr  8 11:42:30 kernel: sp : 00000000ff8eb5d8
Apr  8 11:42:30 kernel: x12: 00000000000ae280
Apr  8 11:42:30 kernel: x11: 00000000000b152c x10: 0000000000000001
Apr  8 11:42:30 kernel: x9 : 00000000ff8eb6a4 x8 : 0000000000000000
Apr  8 11:42:30 kernel: x7 : 00000000000ae000 x6 : 00000000f777bab8
Apr  8 11:42:30 kernel: x5 : 0000000000367c60 x4 : 0000000000000000
Apr  8 11:42:30 kernel: x3 : 000000000008cc34 x2 : 00000000adea4800
Apr  8 11:42:30 kernel: x1 : 00000000000008a1 x0 : 0000000000000000
Apr  8 11:42:46 watchdog: restart httpd
Apr  8 11:42:46 rc_service: watchdog 862:notify_rc stop_httpd
Apr  8 11:42:46 rc_service: watchdog 862:notify_rc start_httpd
Apr  8 11:42:46 RT-AX68U: start https:8043
Apr  8 11:42:46 RT-AX68U: start httpd:80
Apr  8 11:42:46 httpd: Save SSL certificate...8043
Apr  8 11:42:46 httpd: mssl_cert_key_match : PASS
Apr  8 11:42:46 httpd: Succeed to init SSL certificate...8043
Apr  8 11:42:46 httpd: Succeed to init SSL certificate...80

 

[laracroftonline]

It's not the first time I see these since upgrading to 386.5_2. Anything to worry about?

Apr  8 11:42:30 kernel: potentially unexpected fatal signal 11.
Apr  8 11:42:30 kernel: CPU: 0 PID: 851 Comm: httpd Tainted: P           O    4.1.52 #2
Apr  8 11:42:30 kernel: Hardware name: Broadcom-v8A (DT)
Apr  8 11:42:30 kernel: task: ffffffc01587eac0 ti: ffffffc013518000 task.ti: ffffffc013518000
Apr  8 11:42:30 kernel: PC is at 0x4802c
Apr  8 11:42:30 kernel: LR is at 0x47ff0
Apr  8 11:42:30 kernel: pc : [<000000000004802c>] lr : [<0000000000047ff0>] pstate: 80030010
Apr  8 11:42:30 kernel: sp : 00000000ff8eb5d8
Apr  8 11:42:30 kernel: x12: 00000000000ae280
Apr  8 11:42:30 kernel: x11: 00000000000b152c x10: 0000000000000001
Apr  8 11:42:30 kernel: x9 : 00000000ff8eb6a4 x8 : 0000000000000000
Apr  8 11:42:30 kernel: x7 : 00000000000ae000 x6 : 00000000f777bab8
Apr  8 11:42:30 kernel: x5 : 0000000000367c60 x4 : 0000000000000000
Apr  8 11:42:30 kernel: x3 : 000000000008cc34 x2 : 00000000adea4800
Apr  8 11:42:30 kernel: x1 : 00000000000008a1 x0 : 0000000000000000
Apr  8 11:42:46 watchdog: restart httpd
Apr  8 11:42:46 rc_service: watchdog 862:notify_rc stop_httpd
Apr  8 11:42:46 rc_service: watchdog 862:notify_rc start_httpd
Apr  8 11:42:46 RT-AX68U: start https:8043
Apr  8 11:42:46 RT-AX68U: start httpd:80
Apr  8 11:42:46 httpd: Save SSL certificate...8043
Apr  8 11:42:46 httpd: mssl_cert_key_match : PASS
Apr  8 11:42:46 httpd: Succeed to init SSL certificate...8043
Apr  8 11:42:46 httpd: Succeed to init SSL certificate...80

Nothing to worry about!

 

[Tech9]

fix in the GPL branch ASAP

Software won't fix failing hardware. I had a bunch of AC86U routers, a few with re-flowed 2.4GHz IC. This fixes the issue on any firmware. It's a temporary fix though - the IC has to be re-balled with leaded solder for a permanent fix. Until something else fails on this thermally stressed RoHS board.

 

[pinkgrae]

Have you tried the usual suggestions? Most people who had wifi issues in 386.4 said these were resolved for them with 386.5. Try doing a WPS reset, and ensuring that you disable any non-standard features on the 2.4 GHz band, such as Beamforming. A lot of 2.4 GHz clients use very old wifi modules that are often incompatible with these adavanced non-standard features.

Can confirm this worked in my case: had similar issues with devices dropping of the 2.4GHz (only) band. Same issues across various Merlin and stock firmware versions - sometimes better, sometimes worse, but always there.

A few firmwares ago I realised that none of the (mainly IoT) devices on the 2.4GHz band could use any of the fancy stuff (e.g. universal beamforming, smart connect, etc). So I disabled those settings, and also enabled legacy wireless mode.

Result: issues on the 2.4GHz band just disappeared, and haven't been seen again.

 

[heywire]

Have you tried the usual suggestions? Most people who had wifi issues in 386.4 said these were resolved for them with 386.5. Try doing a WPS reset, and ensuring that you disable any non-standard features on the 2.4 GHz band, such as Beamforming. A lot of 2.4 GHz clients use very old wifi modules that are often incompatible with these adavanced non-standard features.

I have a number of TP-Link devices. No issues on my AC86U. If it helps, this is what what works for me;

View attachment 40676

Yesterday, I decided to give Merlin 385_2 a go. But as I'm writing this, I just discovered the 2.4ghz band crashed again already. So I had to manually turn WPS off to get it back on again (found out that switching WPS on and off restarts the 2.4ghz band without requiring a full restart).

So status so far is that .48020 (official) is the first in a long, long line of firmwares to give me a stable uptime of 10 days, without having to disable stuff.

I have now applied the suggested settings to see if this can get Merlin 385_2 working, even if I am not very happy about having to disable technologies that makes the router something of an upgrade to AC68U. I'll report back whether I get a stable uptime with those settings for a few days, or if it crashes before that.

 

[heywire]

Software won't fix failing hardware. I had a bunch of AC86U routers, a few with re-flowed 2.4GHz IC. This fixes the issue on any firmware. It's a temporary fix though - the IC has to be re-balled with leaded solder for a permanent fix. Until something else fails on this thermally stressed RoHS board.

I see you're at it again with these baseless claims. What is your proof, and how do you explain that the problem persist across several units (also those manufactured 2020, not only the 2017 ones) and firmware revisions that have differens numbers of issues, and now it gets fixed with .48020 (official)? Add to that, I'm now running Merlin 385_2 with the settings disabled mentioned above, and I see lower connections speeds on several units on my network compared to both 385_2_Merlin and .48020 (official) with no settings disabled. Howe does the logic add up with respect to your theory?

 

[RMerlin]

I have now applied the suggested settings to see if this can get Merlin 385_2 working, even if I am not very happy about having to disable technologies that makes the router something of an upgrade to AC68U

The technologies we recommend to disable are mostly non standard extensions which are well known to cause compatibility issues for legacy devices on the 2.4 GHz band. That does not prevent the use of the standard ones, such as Explicit Beamforming (which is part of the 802.11ax standard - Implicit Beamforming isn't).

You should disable any advanced/non-standard features on the 2.4 GHz band as this is where any legacy device will connect. Keep them enabled only on the 5 GHz band. Quite a few clients for instance will fail to connect if you enable WPA2/WPA3 mode rather than just WPA2, because they can't deal with the WPA3 requirements, so it's best to keep WPA2/WPA3 mode only on the 5 GHz band.

Ultimately the problem is with the legacy clients not supporting them properly. That's why the option to disable these features on the router exists.

 

[SwampKracker]

I see you're at it again with these baseless claims. What is your proof, and how do you explain that the problem persist across several units (also those manufactured 2020, not only the 2017 ones) and firmware revisions that have differens numbers of issues, and now it gets fixed with .48020 (official)? Add to that, I'm now running Merlin 385_2 with the settings disabled mentioned above, and I see lower connections speeds on several units on my network compared to both 385_2_Merlin and .48020 (official) with no settings disabled. Howe does the logic add up with respect to your theory?

If you don't have another RT-AC86U for comparison, it is difficult to know if the firmware is causing problems or you have failing hardware. These routers are consumer grade electronics made as cheaply as possible.

 

[Terrabytes]

AX88/386.5_2: So, I'm pretty happy with 386.5_2, especially since ipv6 seems to be fixed in this series, but I've noticed a possible problem with AImesh units when mixing firmware code units. I have three Aimesh units, an AC88 that I upgraded to Asus 3.0.0.4.386_48260-gd4c241c, and it worked fine; and then an AC68 and a AC1750 that both experienced problems (no clients would connect) when upgraded from 3.0.0.4.386_46065 to 3.0.0.4.386_48262. Had to downgrade the latter two. I believe that 386.5 is using Asus 386_46065 code, so the warning is, when mix and matching on mesh units, you probably need to stay with whatever Merlin is running underneath the hood. I was only trying to get ahead a bit because of the current threats on the web.

How would we be able to determine what version Merlin was built on vs Asus?

 

[L&LD]

Study the changelog files.

But do note that RMerlin also backports many fixes from 'future' firmware too. Many RMerlin releases are not built from a single Asus GPL release.

 

[Tech9]

What is your proof

I can fix perhaps any AC86U* with chronic 2.4GHz disease and it will work on any firmware. You just continue hoping for a 2022 software fix of 2017 model router. Most likely not happening. No matter what proof you accept or reject, you're the one with issues. My advice to you is to replace AC86U with something else because this particular router has multiple common issues. I wish you luck in finding your fix.

* - My AX88U had similar issue and was fixed in similar way. It's working properly now.

 

[heywire]

If you don't have another RT-AC86U for comparison, it is difficult to know if the firmware is causing problems or you have failing hardware. These routers are consumer grade electronics made as cheaply as possible.

I do have two other AC86U's for comparison, and my tests have revealed that firmware is what makes the difference.

The technologies we recommend to disable are mostly non standard extensions which are well known to cause compatibility issues for legacy devices on the 2.4 GHz band. That does not prevent the use of the standard ones, such as Explicit Beamforming (which is part of the 802.11ax standard - Implicit Beamforming isn't).

You should disable any advanced/non-standard features on the 2.4 GHz band as this is where any legacy device will connect. Keep them enabled only on the 5 GHz band. Quite a few clients for instance will fail to connect if you enable WPA2/WPA3 mode rather than just WPA2, because they can't deal with the WPA3 requirements, so it's best to keep WPA2/WPA3 mode only on the 5 GHz band.

Ultimately the problem is with the legacy clients not supporting them properly. That's why the option to disable these features on the router exists.

If I was having issues with said legacy device (I don't have later than 820n devices, btw) only, that would make sense. But the whole 2.4ghz band crashing so that it disconnects every 2.4ghz device (plus devices that are slow to roll over to 5ghz band, do so) seems to me to clearly indicate that the router is the problem, not any legacy device.

I had of other issues, btw. The problem I had a few versions ago was instability on both bands with constant "wlceventd: wlceventd_proc_event(527): wl0.1: Auth" /Disassoc/ ReAssoc messages in the log.

I can fix perhaps any AC86U* with chronic 2.4GHz disease and it will work on any firmware.

That's what we call an unsubstantiated claim, not proof.

You just continue hoping for a 2022 software fix of 2017 model router.

I already told you it's a 2020 revision. And if it was a 2017, I still see no reason why a software fix is not to be expected.

The AC86U is still for sale, and for comparison, AC68U is a 2013 router that's still receiving the newest updates from both Asus and Merlin.

Most likely not happening. No matter what proof you accept or reject, you're the one with issues. My advice to you is to replace AC86U with something else because this particular router has multiple common issues. I wish you luck in finding your fix.

As I already stated, it does work with the latest .3820 official. So far, I'm also having success with the settings mentioned above @Merlin 386.5. Again, read what I write before just playing records of the same old autistic nonsense about hardware failure. It does not square with the logic I'm putting forth, and have put forth in pointed questions to you before to no avail, where you just pop up in the next thread and babble about hardware failure again.

* - My AX88U had similar issue and was fixed in similar way. It's working properly now.

Anecdotal story. I have an AX88U that was fixed by upgrading from Merlin 386.3/_2 (if i remember correctly) to the previous version (and then the next when that was released). Again, you seem to reach for hardware failure as an explanation by default. How do I know that it was not the powercycle and not your reflowing that fixed these issues? That's what made .3820 official work for me after initially crashing like the previous. versions after a dirty upgrade from the previous official firmware version.