Release Asuswrt-Merlin 386.7 is now available for all models

[jata]

No idea. That would be unexpected since wifi runs on the SoC's own CPU. Random reboot sound more likely to be hardware issues, as actual crashes would generate a kernel panic log entry.

Thanks for the clarification. Have not seen kernel panic in the logs but will continue to monitor.

 

[Treadler]

Updated test builds have been uploaded to the Onedrive Test Builds folder. These include updated wifi driver for the RT-AX86U, and downgraded wifi drivers for the RT-AX88U and GT-AX11000.

Installed, so far, so good.

 

[Dedel66]

Router and Node updated to 386.7_1-gcbedbbd5b0.
All devices (5GHz 2.4GHz) reconnected and running.
IPv6 working.

 

[AntonK]

Updated test builds have been uploaded to the Onedrive Test Builds folder. These include updated wifi driver for the RT-AX86U, and downgraded wifi drivers for the RT-AX88U and GT-AX11000.

Hi @RMerlin This is an update from the RT-AX86U_386.7_1-g8fd8deefbb_49599 firmware?

Anton

 

[octopus]

Hi @RMerlin This is an update from the RT-AX86U_386.7_1-g8fd8deefbb_49599 firmware?

Anton

Same wifi driver. Some start routing fix.
https://github.com/RMerl/asuswrt-merlin.ng/commit/cbedbbd5b08125fb9f46890c8e2774367b22c78a

 

[Damit1]

Installed 5 hours ago, and running so far so good: 386.7_1-gcbedbbd5b0
AX88U Router- AX88U AiMesh Node- AX56U Node,
Ring is running fine so far without missing any notification,
VOIP adapter is running smoothly
IPv6 is obtained smoothly within router boot,
WiFi backhaul link is good and WiFi to the clients is nearly perfect.

So far, so good- will lyk in few hours now.

 

[rerax]

I updated to 386.7_1-gcbedbbd5b0 (ran for 5 hours, no drops seems stable) from 386.5_2 and I'm getting >200Mbps now (better than 386.7 at <100Mbps) on capable smart phones. But 386.5_2 got my devices at >300Mbps. Starting to think my ET8 is janky on backhaul on 386.7+ drives. Good work!

 

[GHammer]

Same wifi driver. Some start routing fix.
https://github.com/RMerl/asuswrt-merlin.ng/commit/cbedbbd5b08125fb9f46890c8e2774367b22c78a

On the AX86U the WiFi drivers are new.

Previous test build (RT-AX86U_386.7_1-gd1340bd88e)

Wireless Driver Version    wl0: May 24 2022 05:43:41 version 17.10.157.2809 (r801046)
wl1: May 24 2022 06:00:12 version 17.10.157.2809 (r801046) FWID 01-11a500

This test build (RT-AX86U_386.7_1-gcbedbbd5b0)

Wireless Driver Version    wl0: Jul 15 2022 09:34:33 version 17.10.157.2809 (r801046)
wl1: Jul 2 2022 12:07:27 version 17.10.157.2809 (r801046) FWID 01-101e00

 

[RMerlin]

On the AX86U the WiFi drivers are new.

It's the same radio firmware. Don't know where the FWID comes from, it might possibly be dynamically generated at build time. The build time is the most accurate way to determine if the firmware was changed or not.

 

[geobernd]

It's the same radio firmware. Don't know where the FWID comes from, it might possibly be dynamically generated at build time. The build time is the most accurate way to determine if the firmware was changed or not.

The FWID seems to be even more strange - looking through the thread above it looks like two different FWIDs reported and mine is different from both
I installed the same build 2 hours ago and mine shows:

​

Model	RT-AX86U
Firmware Version	386.7_1-gcbedbbd5b0

wl1: Jul  2 2022 12:07:27 version 17.10.157.2809 (r801046) FWID 01-328b00

The build is stable for me so far - thank you

 

[Damit1]

AX88U WiFi Drivers are the same as 386 5 2 which are probably from January, and working perfect here, the most stable so far.

 

[gerardr]

10 hrs running, so far with no issues, after dirty upgrade from 386.7_1 1st-alpha to 386.7_1 2nd alpha, on an RT-AX3000 (RT-AX58U firmware).

 

[Ed_Lei]

I'm using the latest ax88u stock (3.0.0.4.386_49674) and it's very stable.

 

[laracroftonline]

I think most devices should get their wifi driver downgraded. The 5300 and ac68u also have these issues.

 

[archiel]

@RMerlin Does the following make any sense, (my apologies if this is a stupid question)?

When running 386.5_2 the RAM used fluctuated between 50 - 65%, the swap file never got used and the web interface was (pretty much) always responsive. Looking at htop I have a couple of VIRT memory hogs - syslog and unbound.

I understand that moving to 386.7 meant reverting to a more normal linux memory use model (optimising the disk cache) but the result is that now RAM is normally around 95-97%, the swap file is in use and loading the scribe page with multiple logs frequently means the bowser hangs (tried different browsers and on different machines, Win 10, Win 11, Ubuntu)

Is it possible that the size of the Virtual Memory requirements of scribe are such that when the browser processes attempt to load it, rather than releasing memory from cache, it is swapping out to the usb drive (ssd connected to USB3) which is causing the lag - hanging?

If this is a wrong idea, any suggestions as to why running scribe is so much lumpier on 386.7 as against 386.5 or how I can troubleshoot this? Thanks Archiel.

 

[ColinTaylor]

When running 386.5_2 the RAM used fluctuated between 50 - 65%...

This was an illusion created by logging into the GUI. When you logged into the GUI it flushed the cache giving the impression that the RAM usage was only 50 - 65%. If you didn't log into the GUI the RAM usage (as shown by top, free, etc.) would increase over time to the 97% level you're seeing now.

 

[archiel]

This was an illusion created by logging into the GUI. When you logged into the GUI it flushed the cache giving the impression that the RAM usage was only 50 - 65%. If you didn't log into the GUI the RAM usage (as shown by top, free, etc.) would increase over time to the 97% level you're seeing now.

Okay, that makes sense, but does not explain why the swap file was not in use (386.5) but is now (as it was with older versions) and whether this is connected to page loading issues with scribe. Any thoughts what to try next?

 

[ColinTaylor]

Okay, that makes sense, but does not explain why the swap file was not in use (386.5) but is now (as it was with older versions) and whether this is connected to page loading issues with scribe. Any thoughts what to try next?

Have you rebooted the router recently? I would expect the swap usage after that to go back to zero. Unless your router is massively overloaded I wouldn't expect there to be any swap activity other than when running some batch process that involves large datasets, e.g. downloading and sorting adblock lists, or processing archive files. I don't use scribe or unbound so can't comment on them.

EDIT: I see in the next post that you've got a problem with excessively sized log files. That could be the cause of your increased swap activity.

 

[archiel]

How does the new DNSFilter work work if there is nothing added to the IPv6 filter - does it pick up the Global IPv6?

I had a secondary setup for Diversion (with Pixelserv) for my wife's work laptop, just using the minimal list (for other users set to standard) and applied this by adding the secondary pixelserv IP as a custom DNS and then adding the laptop to this. Following the upgrade to 386.7 both the dnsmasq and unbound logs ballooned (8Gb and 1.2Gb) as a result of repeated unanswered DNS requests. For now I have removed this machine from Diversion entirely (using Cloudflare IPv4 and IPv6 DNS), but would like to understand what DNSFilter is expected to do if the IPv6 box is left blank.

 

[RMerlin]

How does the new DNSFilter work work if there is nothing added to the IPv6 filter - does it pick up the Global IPv6?

If you use a preset that supports IPv6 and you have a recent HND-based router, it will also redirect IPv6 DNS queries.

If you are manually configuring the IP, or using a service that does not support IPv6, then the original behaviour from 386.5 is used - DNS queries to other servers are flat out blocked by the firewall.