RT-AX88U maxing out a core and regularly showing 60+ MB/s upload

[SmallKiwi]

I had Diversion and Skynet running but have since disabled them, suspecting that may be the culprit. Essentially, I can't see any device connected to my network that is sending large amounts of data, but when I look at the traffic monitor (Analyzer) it shows this:

I only have ~30Mbps of upload. I can't figure out what is causing this, but everytime it spikes everyone is stuck waiting. I've uninstalled all packages and am just running Merlin with no added packages now. Anyone ever seen this, or know what might be going on?

 

[Ripshod]

We can't say what's causing this, but it's easy to find out. Flick to the Statistic tab, Enable it, let it run a while, then see what device IP is causing this unexpected traffic. You'll also be able to see the protocol which may help you identify an app on that device. Worst case, block it and wait to see what stops working or who starts complaining.
My suspicion is file sharing (bittorrent)

 

[SmallKiwi]

No you don't understand, my connection is not CAPABLE of those upload speeds. Not even close. Those spikes are 130MB/s. I have ~30Mbps Up. And besides that there are no devices that are using that kind of bandwidth. This is what my upload Stats look like:

I went back to stock Asus firmware and without changing any settings the problem seems to have stopped. But I really like Diversion so I'm hoping someone has some clue as to what may be causing this.

 

[Ripshod]

I'm on a phone - that's my excuse.
That is a strange one. You're definitely using the WAN port for Internet, not a LAN port.
I also run Diversion but never seen anything like this.

 

[SmallKiwi]

That is a strange one. You're definitely using the WAN port for Internet, not a LAN port.
I also run Diversion but never seen anything like this.

Correct. Everything was working fine for several months, no real issues. Then Saturday this started. At first I thought maybe it was reporting USB disc access as outgoing data (it roughly matched the speed I get when transferring to/from the USBs) but the fact that the problem continued after uninstalling all add-ons and unplugging the USB discs means it wasn't that. Is there a way to get any more details about what's going on in the router? See what process might be responsible?

 

[Ripshod]

As it's running one core up you could login via ssh and run htop. Whatever is using the cpu most will be at the top of the list. Grab a screenshot while this is happening.

 

[dave14305]

If it’s happening on the router (and not through the router LAN to WAN), you might see connections with:

netstat -ntup

 

[jonathonballen]

As it's running one core up you could login via ssh and run htop. Whatever is using the cpu most will be at the top of the list. Grab a screenshot while this is happening.

I’ve had this issue for about a week, AX XT8 on stock firmware. I initially thought it was due to a recent firmware upgrade (end September) so downgraded but still same behaviour. I followed Ripshod’s advice and it turns out that the culprit is sshd. Any clues as to what and why this might be happening? I disabled the AIProtection stuff but didn’t make any difference.

 

[dave14305]

it turns out that the culprit is sshd

There is no sshd daemon in the Asus firmware. It’s called dropbear instead. If you saw sshd running, perhaps it’s a nice piece of malware. Please clarify which you saw.

 

[Martinski]

... I followed Ripshod’s advice and it turns out that the culprit is sshd.

If you have the "sshd" process running, under normal circumstances that would be the OpenSSH server daemon (i.e. /opt/sbin/sshd) which can be installed via Entware (it's *not* built-in as part of the F/W).

However, if you have *not* explicitly installed the Entware package yourself, then someone or something else may have installed it, likely for nefarious purposes. I'd suggest you remove the OpenSSH package immediately. It may even be a "compromised" version of the OpenSSH server that has been installed by some malware.

Try the following commands to remove the package (if it exists):

{
   opkg list-installed | grep openssh ; echo
   opkg remove --force-removal-of-dependent-packages openssh-server
   opkg list-installed | grep openssh ; echo
}

My 2 cents.

 

[jonathonballen]

There is no sshd daemon in the Asus firmware. It’s called dropbear instead. If you saw sshd running, perhaps it’s a nice piece of malware. Please clarify which you saw.

If you have the "sshd" process running, under normal circumstances that would be the OpenSSH server daemon (i.e. /opt/sbin/sshd) which can be installed via Entware (it's *not* built-in as part of the F/W).

View attachment 61858

View attachment 61859

However, if you have *not* explicitly installed the Entware package yourself, then someone or something else may have installed it, likely for nefarious purposes. I'd suggest you remove the OpenSSH package immediately. It may even be a "compromised" version of the OpenSSH server that has been installed by some malware.

Try the following commands to remove the package (if it exists):

{
   opkg list-installed | grep openssh ; echo
   opkg remove --force-removal-of-dependent-packages openssh-server
   opkg list-installed | grep openssh ; echo
}

My 2 cents.

Thanks for the advice. haven’t explicitly installed any SSH package, so I’ll check and remove if necessary.

 

[Radek8]

Měl jsem spuštěné Diversion a Skynet, ale od té doby jsem je deaktivoval s podezřením, že to může být viník. V podstatě nevidím žádné zařízení připojené k mé síti, které odesílá velké množství dat, ale když se podívám na monitor provozu (Analyzer), ukazuje toto:View attachment 61835

Mám pouze ~30 Mbps uploadu. Nemohu přijít na to, co to způsobuje, ale pokaždé, když to vyskočí, všichni čekají a čekají. Odinstaloval jsem všechny balíčky a nyní používám Merlin bez přidaných balíčků. Už to někdo viděl nebo víte, co se může stát?

I have exactly the same problem with the RT AX86S FW3004_388.8.0 router
Communication to the WAN is always visible, but communication to the LAN or WIFI does not correspond to this. At the same time, I also noticed a high CPU load. Mostly at 100% both cores.
After upgrading to version 3004_388.8.2, the problem became even more frequent.
So I returned FW3004_388.7.0.
Upload an older version has fixed the problem for now.

I'm sorry

 

[bennor]

Mám úplně stejný problém s routerem RT AX86S FW3004_388.8.0
Komunikace do WAN je viditelná vždy, ale komunikace do LAN nebo WIFI tomu neodpovídá. Zároveň jsem zaznamenal i vysokou zátěž CPU. Většinou na 100% obě jádra.
Po upgradu na verzi 3004_388.8.2 byp problém ještě častější. Alespoň do minuty odejdou.
Tak jsem vrátil FW3004_388.7.0.
Dawngrad problém prozatím vyřešil.

English only please.

 

[Radek8]

We can't say what's causing this, but it's easy to find out. Flick to the Statistic tab, Enable it, let it run a while, then see what device IP is causing this unexpected traffic. You'll also be able to see the protocol which may help you identify an app on that device. Worst case, block it and wait to see what stops working or who starts complaining.
My suspicion is file sharing (bittorrent)

This traffic does not originate from any device on the network.
This load is visible only on the WAN connector and does not go to any IP address behind the router.
As if the router itself caused the traffic.
Since the apparent traffic is more than the line from the ISP, and the CPU is at 100% at that moment, and upgrading to an older FW will solve the problem, it looks like a bug in the current version of FW.

 

[Ripshod]

This traffic does not originate from any device on the network.
This load is visible only on the WAN connector and does not go to any IP address behind the router.
As if the router itself caused the traffic.
Since the apparent traffic is more than the line from the ISP, and the CPU is at 100% at that moment, and upgrading to an older FW will solve the problem, it looks like a bug in the current version of FW.

As it's running one core up you could login via ssh and run htop. Whatever is using the cpu most will be at the top of the list. Grab a screenshot while this is happening.

There is no sshd daemon in the Asus firmware. It’s called dropbear instead. If you saw sshd running, perhaps it’s a nice piece of malware. Please clarify which you saw.

The answers are in this thread. No-one said the problem was anywhere other than the router.

 

[jonathonballen]

So, I couldn’t find any explicit installation of OpenSSH (nothing in /opt/sbin) so I decided to follow the advice posted and reset to factory settings, change all SSIDs and passwords, create a guest wireless network for IoT devices, turn off WAN access, uPnP and SSH, and upgrade to the latest firmware. So far so good, problem seems to have disappeared for now. It doesn’t help getting to the origin of the issue, but at least I now have a useable network. Thanks for everyone’s advice.

 

[jonathonballen]

So, I couldn’t find any explicit installation of OpenSSH (nothing in /opt/sbin) so I decided to follow the advice posted and reset to factory settings, change all SSIDs and passwords, create a guest wireless network for IoT devices, turn off WAN access, uPnP and SSH, and upgrade to the latest firmware. So far so good, problem seems to have disappeared for now. It doesn’t help getting to the origin of the issue, but at least I now have a useable network. Thanks for everyone’s advice.

Unfortunately it’s started happening again, so I’ll redo everything but stick to the previous FW version.

 

[ColinTaylor]

Unfortunately it’s started happening again, so I’ll redo everything but stick to the previous FW version.

SSH into the router and run top to see which process is consuming the CPU. If it's still sshd (a process that shouldn't exist) then search for it with find / -name sshd

 

[jonathonballen]

Everything seems OK so far with factory reset and 3.0.0.4.388 24621 FW. Can't get Amazon Echos to connect, but that's another problem for another day!

 

[kknishev]

The same here for a week... with RT-AX86U (Merlin_3004_388.8_2) - a huge upload traffic and CPU load for 100%
top show on the top {sshd}
Downgrade to 3004_388.7_0 - looks stable