AC5300 performance, high CPU (or not), and AiMesh

[karma]

Could there be an issue with the latest firmware?
It seems to have the smallest file size of all firmware versions.

I had the same issue on my two RT-AC5300, one as main router and the other as repeater, both were showing very high constant CPU usage with the 3.0.0.4.384.81622 firmware. Like you, downgrading to 3.0.0.4.384.81219 solved the issue. I didn't try factory resetting them since you already gave it a try.

 

[pcb]

I discovered this forum while doing web searches about the massive number of "There are still associated scbs, avoid channel switch(txfail_thresh)" messages I'm seeing in the logs of my RT-AC5300. But when I saw this thread I checked my Network Map > System Status > Status tab and discovered that both my CPU cores are running at between 84-97% all the time.

I am running a newer firmware than the one in the OP: 3.0.0.4.384_81625. I have also noticed slower-than-expected download times in certain cases (Nintendo switch, iPhone podcasts). I guess I will have to downgrade, but I have two questions:

1. Is there a reliable way to report this behavior to ASUS? (Clearly they haven't noticed if multiple firmware revs have the problem).

2. Also, how can I monitor the CPU status of my two AiMesh nodes to see if they're having similar problems? I'm only able to see the stats of the main router, the AC5300. I have an RT-AC86U and RT-AC68U in the mix as well.

I am brand new to the forum; forgive if these answers are mentioned elsewhere.

 

[jazzer]

I discovered this forum while doing web searches about the massive number of "There are still associated scbs, avoid channel switch(txfail_thresh)" messages I'm seeing in the logs of my RT-AC5300. But when I saw this thread I checked my Network Map > System Status > Status tab and discovered that both my CPU cores are running at between 84-97% all the time.

I am running a newer firmware than the one in the OP: 3.0.0.4.384_81625. I have also noticed slower-than-expected download times in certain cases (Nintendo switch, iPhone podcasts). I guess I will have to downgrade, but I have two questions:

1. Is there a reliable way to report this behavior to ASUS? (Clearly they haven't noticed if multiple firmware revs have the problem).

2. Also, how can I monitor the CPU status of my two AiMesh nodes to see if they're having similar problems? I'm only able to see the stats of the main router, the AC5300. I have an RT-AC86U and RT-AC68U in the mix as well.

I am brand new to the forum; forgive if these answers are mentioned elsewhere.

I don't have an answer for qn 1.

But for qn 2, if you enable ssh, you can login to your nodes using their IP. Running the command top will give you the list of processes using the most cpu.

 

[pcb]

Thanks, @jazzer , that did the trick.

I have an RT-AC5300 as my main router and a RT-AC86U and a RT-AC68U as AiMesh nodes. Both of the mesh nodes were running their latest firmware revisions (86U: 3.0.0.4.384_81352 and 68U: 3.0.0.4.385.20253).

My AC86U was still working wonderfully (low CPU usage, clients connected, no noticeable connectivity issues), but my AC68U's only client was the one device that's Ethernet-connected to it, no WiFi clients, even though there is one WiFi device literally 8 feet away from it. Logged in via SSH with PuTTY and found the AC68U was also consuming hella CPU (the "mtdblock3" process, whatever that is). I just downgraded it to 3.0.0.4.385_10000 (dated 2019/11/26), and CPU usage is back down to normal (0-4% for that node).

So recent updates to both the RT-AC5300 and RT-AC68U firmware really blew up performance- at least in my AiMesh-based home, and yet they slipped past QA.

 

[docious]

I'm experiencing the same issue as OP with my RT-AC67U in a 1 node mesh configuration (AC1900 pair). Both CPU cores around 90% in the UI and [mtdblock3] showing around 42 % via top on the main router. Last night I did a 'Factory default' restore via the UI and checked the initialise box. I then uploaded a saved config and it appeared to be fixed with both cores at around 1 %. That lasted until around 2 pm today. My current firmware is 3.0.0.4.385_20253.

I've been trying to figure out what could have triggered it again. I dual boot with Win 10/Linux and only noticed the problem return after I had booted Linux today. Another thought is the CVE-2019-15126 (Kr00k) vulnerability fix included in this firmware. Other more paranoid ideas about bitcoin miners have entered my mind but I would expect AiProtection/Firewall/DoS protection to prevent that kind of thing and router CPUs are not exactly ideal for ripping through hashes.

My next move is manually installing the brand new 3.0.0.4.385.20433 not yet offered in the UI and another factory reset.

 

[L&LD]

@docious by uploading your saved config file, you effectively negated the reset/Initialize process you performed.

Flash the same firmware you have installed currently, do a full reset/Initialize procedure. Minimally and manually configure your router to secure it and connect to your ISP. If you normally use a USB drive/device on the router, don't, as a test for a day or two. Now you are properly testing it. If found stable with these default settings, add one feature/customization at a time until you find it either works properly (it may if you don't restore old saved backup config files) or, you find the feature/customization that makes it unstable.

Please have a look at the link in my signature below for the M&M Config and the Nuclear Reset guides on safe defaults and details on how to get your router to a good/known state.

HTH.

 

[docious]

@docious by uploading your saved config file, you effectively negated the reset/Initialize process you performed.

Flash the same firmware you have installed currently, do a full reset/Initialize procedure. Minimally and manually configure your router to secure it and connect to your ISP. If you normally use a USB drive/device on the router, don't, as a test for a day or two. Now you are properly testing it. If found stable with these default settings, add one feature/customization at a time until you find it either works properly (it may if you don't restore old saved backup config files) or, you find the feature/customization that makes it unstable.

Please have a look at the link in my signature below for the M&M Config and the Nuclear Reset guides on safe defaults and details on how to get your router to a good/known state.

HTH.

Thanks for your reply. I did think about the config file potentially being the problem but I ignored myself and carried on. It's good to hear it from a veteran in this forum so I will follow your advice for the next reset/initialise.

I'll see what happens with this new 3.0.0.4.385.20433 first because maybe it will maintain the low CPU use I currently have. Yeah, I'm not too confident about that. The 12-18 hour delay between my previous factory reset and the issue returning almost suggests the config isn't to blame but that might be naive. I'm also limited to perform resets when people on my LAN are not working so I have some time to ssh and observe top.

Thanks for the links, I'll definitely read those

 

[cplay]

After reading Merlin's advisory about AiMesh

Where did you read this?

Last I heard from him since adding ai mesh support to nodes that older advice was updated and now you can use merlin on router and nodes (i run merlin on both nodes and router with no issues).

 

[Grisu]

You can, but what would you gain with Merlin on nodes?
So easier to run them on stock with easiest oneclick-update and Merlin only on master router.

 

[OzarkEdge]

You can, but what would you gain with Merlin on nodes?
So easier to run them on stock with easiest oneclick-update and Merlin only on master router.

One advantage to Asuswrt-Merlin all-around the mesh is that you are certain to have the same Asuswrt code all-around the mesh... no version mis-match.

OE

 

[cplay]

You can, but what would you gain with Merlin on nodes?
So easier to run them on stock with easiest oneclick-update and Merlin only on master router.

Ability to switch to master router substantially quicker from node without having to flash and then reset router.

However, the one click update probably materialises in better time gains constantly and ease of application for normal user.

 

[cplay]

One advantage to Asuswrt-Merlin all-around the mesh is that you are certain to have the same Asuswrt code all-around the mesh... no version mis-match.

OE

Yeah and that!

I know however you dont run merlin at all, why again?

 

[OzarkEdge]

Yeah and that!

I know however you dont run merlin at all, why again?

No key man insurance. And I don't need the added features, steps, and delayed updates... for example, I was running AiMesh long before Asuswrt-Merlin users. To be fair, I don't even need the added features in Asuswrt.

OE

 

[cplay]

No key man insurance. And I don't need the added features, steps, and delayed updates... for example, I was running AiMesh long before Asuswrt-Merlin users. To be fair, I don't even need the added features in Asuswrt.

OE

See, my favourite thing about merlin is that every version is behind the current version. because the latest version of wrt ALWAYS introduces new issues.

I like merlin because asus wrt stock users are always the beta testers without knowing it

I love the stability of Merlin and not sh*tting myself everytime I update.

 

[OzarkEdge]

See, my favourite thing about merlin is that every version is behind the current version. because the latest version of wrt ALWAYS introduces new issues.

I like merlin because asus wrt stock users are always the beta testers without knowing it

I love the stability of Merlin and not sh*tting myself everytime I update.

Coward!

OE

 

[docious]

Thanks for your reply. I did think about the config file potentially being the problem but I ignored myself and carried on. It's good to hear it from a veteran in this forum so I will follow your advice for the next reset/initialise.

I'll see what happens with this new 3.0.0.4.385.20433 first because maybe it will maintain the low CPU use I currently have. Yeah, I'm not too confident about that. The 12-18 hour delay between my previous factory reset and the issue returning almost suggests the config isn't to blame but that might be naive. I'm also limited to perform resets when people on my LAN are not working so I have some time to ssh and observe top.

Thanks for the links, I'll definitely read those

For the record, this new firmware did maintain the low CPU load for a week. Or the second factory reset fixed it. Either way I'm sticking with 3.0.0.4.385.20433 despite the gimmicky gaming auto-port forward option.

 

[karma]

has anybody tried the latest firmware ( Version 3.0.0.4.384.81844 2020/04/30 ) to see if it fixes the CPU issue?