Release Asuswrt-Merlin 386.7 is now available for all models

[petr23]

Tried 386.7_2 on AX56U and unfortunately there is still issue with Wi-Fi throughput which was introduced in 386.7_0, but I guess only ASUS can fix that.

RT-AX56U slow iperf3 in one direction

Hi everyone, I recently purchased RT-AX56U and when testing LAN speeds with iperf3 (TCP, 5 streams) somehow I get expected throughput only in one direction. My first device is desktop connected via ethernet cable to the router and the other device is WiFi 6 Android phone, but only when the phone...

www.snbforums.com

 

[RMerlin]

My bad, those fixes are from Version 3.0.0.4.386.47875 so I assume ALL of those are fixed in the present release?

That's correct.

48966 is in between the 2. Of just the 2 above, are they fixed in the latest build?

It's impossible to tell, as I have no idea which specific issue is fixed by which specific GPL revision. This is why I don't document them, as I have no way of knowing what fixes are present in a specific GPL archive - all I get is 15 1.5 GB archives of source code with no documentation, no changelog, no list of individual changes.

You will have to look for yourself if for some reason you feel this is important for you. I don't want to start analyzing every single documented fix one by one, especially as most of the time, CVEs are confidential for a number of months, meaning I don't even know WHAT the issue is. In your case, I just checked the first one, which is an OpenSSL issue:

NVD - CVE-2022-0778

nvd.nist.gov

My OpenSSL version is actually newer than Asus, so I had that one fixed even before Asus did. That's one example among other why people should stop obsessing about which version fixed what, and whether Asuswrt-Merlin or Asuswrt is more secure fix-wise. My release contains fixes that Asus doesn't yet, and Asus contains fixes that I don't yet. We are two separate projects developed in parallel, we are never in sync.

So if people feel the need to know which exact fixes are present, they will have to search for themselves.

 

[RMerlin]

Tried 386.7_2 on AX56U and unfortunately there is still issue with Wi-Fi throughput which was introduced in 386.7_0, but I guess only ASUS can fix that.

RT-AX56U slow iperf3 in one direction

Hi everyone, I recently purchased RT-AX56U and when testing LAN speeds with iperf3 (TCP, 5 streams) somehow I get expected throughput only in one direction. My first device is desktop connected via ethernet cable to the router and the other device is WiFi 6 Android phone, but only when the phone...

www.snbforums.com

The changelog contains the exact list of wireless driver changes.

 

[Crimliar]

That looks the same as mine (no channel 144) except I also have channels 120 to 128 visible. Your control channel is 116 so if you go to System Log - Wireless Log you can see what bandwidth is actually being used. 116/80 would be the same as 116 to 128.

So had an early chance to play with the 5GHz WiFi channels - CH144 is not available (I was wrong), and channels 132 (20,40), 136 (20,40), and 140 (20) behave as expected.

It still leaves the missing ability to select 3 channels though:

With channels 120, 124, and 128 not selectable but usable in 160MHz and 80MHz depending on the control channel!

 

[Natty]

Several folks have said they were able to update their RT-AC68U to 386.7_2. I don't see the file in the Sourceforge folder. Can you please confirm 386.7_2 for the RT-AC68U (and RT-AC66U_B1) is available? Thank you.

Asuswrt-Merlin - Browse /RT-AC68U/Release at SourceForge.net

Alternative firmware for Asus wireless routers

sourceforge.net

folder: RT-AC68U_386.7_2.zip

 

[RMerlin]

Asuswrt-Merlin - Browse /RT-AC68U/Release at SourceForge.net

Alternative firmware for Asus wireless routers

sourceforge.net

folder: RT-AC68U_386.7_2.zip

Some people mentioned Sourceforge has issues earlier today, that would be why.

I always publish to the Onedrive mirror at the same time as Sourceforge, so that's an alternative.

 

[gmt]

Upgraded the AC86U to 386.7_2 without issues.

 

[shabbs]

Applied the new release version across all my gear just now. Initial upgrade looks fine across the board. Devices all reconnected. VPN back up and running. Will let it settle, give the gear another reboot and then let it ride.

EDIT: So, noticing some stuttering/pausing on my Rogers Ignite TV since the upgrade. Now, that could just be coincidental timing with Rogers legendary unstable system of late... so I'll keep an eye on it. Speed tests from the Router are a fair bit lower than before oddly enough (in the 700Mbps range as opposed to over 900Mbps). May give the Rogers modem an kick later and see. Hopefully just timing. Everything else seems fine. Rogers DHCP lease time is back to an hour so they may be "tweaking" things in my area.

EDIT2: Gave some devices a kick, Ignite TV seems to be stable now. Internet speed tests back over 900Mpbs as well. Dark magic.

 

[netware5]

A few users reported connectivity issue with the wireless firmware from 48966, so it was reverted back to the 46065 version.

I am wondering if the connectivity issues with 386.7 reported by AX88 users are "general", i.e. related to the firmware itself, or are related to their specific configuration. I have no any issues with 386.7 like many other users. Reading the specific thread about 386.7 and AX88U connectivity I have a feeling that the issue has not been deeply investigated, so the solution to revert back to 386.5_2 radio FW is not feasible. Personally I had no issues with 386.7 radio FW since upgrade from 386.5_2 (one day after its release). My feeling is that the majority of AX88U users did not have issues also. Only few users (in fact maybe only one) reported such issues.

 

[Goned75]

I am wondering if the connectivity issues with 386.7 reported by AX88 users are "general", i.e. related to the firmware itself, or are related to their specific configuration. I have no any issues with 386.7 like many other users. Reading the specific thread about 386.7 and AX88U connectivity I have a feeling that the issue has not been deeply investigated, so the solution to revert back to 386.5_2 radio FW is not feasible. Personally I had no issues with 386.7 radio FW since upgrade from 386.5_2 (one day after its release). My feeling is that the majority of AX88U users did not have issues also. Only few users (in fact maybe only one) reported such issues.

True...

 

[Damit1]

I am wondering if the connectivity issues with 386.7 reported by AX88 users are "general", i.e. related to the firmware itself, or are related to their specific configuration. I have no any issues with 386.7 like many other users. Reading the specific thread about 386.7 and AX88U connectivity I have a feeling that the issue has not been deeply investigated, so the solution to revert back to 386.5_2 radio FW is not feasible. Personally I had no issues with 386.7 radio FW since upgrade from 386.5_2 (one day after its release). My feeling is that the majority of AX88U users did not have issues also. Only few users (in fact maybe only one) reported such issues.

Excuse me, I have the SIMPLEST SETUP.
No VPN, no servers, nada.
Just AiMesh system with multiple nodes.

I do know more friends of mine who have same setup, and WiFi crashed.

I think it is more about client-devices comptability to the drivers than setup/config.

 

[netware5]

I think it is more about client-devices comptability to the drivers than setup/config.

That is the key statement. The issue has not been investigated. It could be the AiMesh or specific client device or something in "Professional configuration". In the other thread I never noticed any detailed information published, only statements like "random disconnecting" or similar ...

 

[RMerlin]

I am wondering if the connectivity issues with 386.7 reported by AX88 users are "general", i.e. related to the firmware itself, or are related to their specific configuration.

Wifi-related issues are often client-specific. I generally ignore wifi feedback as quite often it's an environment or configuration issue rather than a real bug. In this case however there were a number of complains, and reverting the radio firmware resolved their issue.

386.8 will contain an updated driver for the RT-AX88U anyway, as it will be required to support a new hardware revision.

so the solution to revert back to 386.5_2 radio FW is not feasible

For the RT-AX88U it's feasible, since that model runs a separate firmware on its radio SoC. So it was possible for me to revert to a previous version of that firmware, without requiring any change to the SDK or source code itself, and testers confirmed the issue went away after that change.

However other models that use the older wl driver (like the RT-AX58U) cannot be downgraded without an SDK downgrade (which may not be compatible with the rest of the firmware code), as the radio firmware is embedded into the driver, rather than a separate file loaded at boot time.

Only few users (in fact maybe only one) reported such issues.

I think there were at least two, if not three separate reports. Doing a test build with the old radio firmware was easy enough to do, and it worked fine for these reported cases.

 

[roundaway]

Some people mentioned Sourceforge has issues earlier today, that would be why.

I always publish to the Onedrive mirror at the same time as Sourceforge, so that's an alternative.

@RMerlin

Thanks for the reminder about the OneDrive mirror. The file for the RT-AC68U is there. Still not showing on Sourceforge. Time to flash the latest!

 

[Tech9]

For the RT-AX88U it's feasible, since that model runs a separate firmware on its radio SoC.

Wondering what makes AX88U drivers different than other routers with the same SoC?
BCM43684 radio SoC is used in AX86U, AX92U, AX58U, AX95Q (XT8)... perhaps some more.

 

[Kingp1n]

Wifi-related issues are often client-specific. I generally ignore wifi feedback as quite often it's an environment or configuration issue rather than a real bug. In this case however there were a number of complains, and reverting the radio firmware resolved their issue.

386.8 will contain an updated driver for the RT-AX88U anyway, as it will be required to support a new hardware revision.


For the RT-AX88U it's feasible, since that model runs a separate firmware on its radio SoC. So it was possible for me to revert to a previous version of that firmware, without requiring any change to the SDK or source code itself, and testers confirmed the issue went away after that change.

However other models that use the older wl driver (like the RT-AX58U) cannot be downgraded without an SDK downgrade (which may not be compatible with the rest of the firmware code), as the radio firmware is embedded into the driver, rather than a separate file loaded at boot time.


I think there were at least two, if not three separate reports. Doing a test build with the old radio firmware was easy enough to do, and it worked fine for these reported cases.

@RMerlin, would you know if the GT-AX11000 (386.8 fw) will have updated drivers as well?

 

[kiomisu]

I don't have any plan to work on IPSEC support. My focus is on OpenVPN.

Thanks, so I'm assuming if ASUS include updated protocols then that will be included in future releases by you?

 

[BreakingDad]

Disgustingly, filthy, sweaty and covid free update. All ok, had to reinstall flex to get full speeds back, but that seems to be the norm for my setup.

 

[evlo]

When i try to run

opkg update

I get error

"wget: not an http or ftp url"

as it is https, how to fix it? (maybe related to busybox i might or might not have installed using opkg)

 

[ColinTaylor]

(maybe related to busybox i might or might not have installed using opkg)

Do not install busybox from Entware. It will cause problems.