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

[sorachan]

It's AiCloud.


No they're not because the firewall blocks access to them. The use of 0.0.0.0 is common practice (and often a necessity) when dealing with dynamic network interfaces.

But that does raise an interesting point... @kknishev @firecracker If the problem reoccurs can you post the same information as before together with the output of iptables-save. Thanks.

You are right, but not everyone enables firewall, and you'd be surprised how many don't.

I know a certain proxy program used in some certain countries running on ASUS routers which listens to 0.0.0.0:***** (I'm not going to disclose the port number). The program includes a socks5 proxy tunnel.

I also know since last year there has been a script that actively scans for this port number to take advantage of this socks5 proxy.

 

[ColinTaylor]

You are right, but not everyone enables firewall, and you'd be surprised how many don't.

True. Quite often it's gamer kiddies that think it's going to improve their gameplay in some. way. But you can't account for user stupidity.

I know a certain proxy program used in some certain countries running on ASUS routers which listen to 0.0.0.0:***** (I'm not going to disclose the port number). The program includes a socks5 proxy tunnel.

I also know since last year there is a script that actively scans for this port number to take advantage of this socks5 proxy.

Installing third party software is always a risk. If that software compromises your whole router (rather then opening a single port in the firewall) then it's the responsibly of the user.

 

[sorachan]

@ColinTaylor Thanks for answering my silly question

 

[Ripshod]

@ColinTaylor Thanks for answering my silly question

Never a silly question. If it occured to you it likely would occur to thousands of others. It's not always the direct answers that educate. We're all learning.

 

[kknishev]

If the problem reoccurs

yes, you knew .. attached (replaced public ip with 000.000.000.000)

 

[Armand28]

I changed password, turned off SSH, rolled back and then rolled forward to latest Merlin firmware. Should I turn off DDNS? Is that any part of this equation or can I leave it on? Thanks!

 

[jd24]

I changed password, turned off SSH, rolled back and then rolled forward to latest Merlin firmware. Should I turn off DDNS? Is that any part of this equation or can I leave it on? Thanks!

I have ddns turned off for now, just testing. OpenVPN On (new config/cert created) though and still no issues for 24 hours.

 

[firecracker]

@kknishev @firecracker can you run those commands again while the CPU problem is actually occurring. Thanks.

It hasn't happened again since about 10AM today.

I found a strange entry in the log file though.

Any idea what "Tainted" means in this context? Also, first time I've seen "sshd" in the log file as well.

 

[Martinski]

..
I found a strange entry in the log file though.
...
Any idea what "Tainted" means in this context? Also, first time I've seen "sshd" in the log file as well.

In general terms, the string "Tainted:" (usually followed by a series of one-letter "taint flags") in a crash report means that the kernel has been marked and is considered to be in an "unknown state" (i.e. "tainted state") because a possibly non-native component was loaded & later crashed which puts the kernel in an unreliable state. Most of the time, this is caused by loading & running an externally compiled or unsigned proprietary module. As a result, the reported crash cannot be debugged by kernel developers because the source code of the external module is not included with or part of the Linux kernel source code (i.e. an "out-of-tree" component).

In your screenshot of the crash report you can see 2 taint flags:

P = A proprietary module was loaded/running.

O = An "out-of-tree" external module was loaded/running.

HTH.

 

[Armand28]

I got a similar one:


Oct 15 22:00:16 kernel: ubi0 error: ubi_io_write: error -5 while writing 2048 bytes to PEB 1622:0, written 0 bytes
Oct 15 22:00:16 kernel: CPU: 1 PID: 119 Comm: ubi_bgt0d Tainted: P O 4.19.183 #1
Oct 15 22:00:16 kernel: Hardware name: GTAXE16000_2GB (DT)
Oct 15 22:00:16 kernel: Call trace:
Oct 15 22:00:16 kernel: dump_backtrace+0x0/0x150
Oct 15 22:00:16 kernel: show_stack+0x14/0x20
Oct 15 22:00:16 kernel: dump_stack+0x94/0xc4
Oct 15 22:00:16 kernel: ubi_io_write+0x574/0x690
Oct 15 22:00:16 kernel: ubi_io_write_ec_hdr+0xc4/0x110
Oct 15 22:00:16 kernel: sync_erase.isra.0+0x11c/0x1f0
Oct 15 22:00:16 kernel: __erase_worker+0x34/0x460
Oct 15 22:00:16 kernel: erase_worker+0x18/0x80
Oct 15 22:00:16 kernel: do_work+0x98/0x120
Oct 15 22:00:16 kernel: ubi_thread+0x108/0x190
Oct 15 22:00:16 kernel: kthread+0x118/0x150
Oct 15 22:00:16 kernel: ret_from_fork+0x10/0x24
Oct 15 22:00:16 kernel: ubi0: dumping 2048 bytes of data from PEB 1622, offset 0
Oct 15 22:00:16 kernel: ubi0 error: __erase_worker: failed to erase PEB 1622, error -5
Oct 15 22:00:16 kernel: ubi0: mark PEB 1622 as bad
Oct 15 22:00:16 kernel: ubi0: 4 PEBs left in the reserve
Oct 15 22:24:15 ddns: IP address, server and hostname have not changed since the last update.
Oct 15 22:54:15 ddns: IP address, server and hostname have not changed since the last update.
Oct 15 23:00:17 kernel: ubi0 error: ubi_io_write: error -5 while writing 2048 bytes to PEB 85:0, written 0 bytes
Oct 15 23:00:17 kernel: CPU: 1 PID: 119 Comm: ubi_bgt0d Tainted: P O 4.19.183 #1
Oct 15 23:00:17 kernel: Hardware name: GTAXE16000_2GB (DT)
Oct 15 23:00:17 kernel: Call trace:
Oct 15 23:00:17 kernel: dump_backtrace+0x0/0x150
Oct 15 23:00:17 kernel: show_stack+0x14/0x20
Oct 15 23:00:17 kernel: dump_stack+0x94/0xc4
Oct 15 23:00:17 kernel: ubi_io_write+0x574/0x690
Oct 15 23:00:17 kernel: ubi_io_write_ec_hdr+0xc4/0x110
Oct 15 23:00:17 kernel: sync_erase.isra.0+0x11c/0x1f0
Oct 15 23:00:17 kernel: __erase_worker+0x34/0x460
Oct 15 23:00:17 kernel: erase_worker+0x18/0x80
Oct 15 23:00:17 kernel: do_work+0x98/0x120
Oct 15 23:00:17 kernel: ubi_thread+0x108/0x190
Oct 15 23:00:17 kernel: kthread+0x118/0x150
Oct 15 23:00:17 kernel: ret_from_fork+0x10/0x24
Oct 15 23:00:17 kernel: ubi0: dumping 2048 bytes of data from PEB 85, offset 0
Oct 15 23:00:17 kernel: ubi0 error: __erase_worker: failed to erase PEB 85, error -5
Oct 15 23:00:17 kernel: ubi0: mark PEB 85 as bad
Oct 15 23:00:17 kernel: ubi0: 3 PEBs left in the reserve

 

[ColinTaylor]

I got a similar one:


Oct 15 22:00:16 kernel: ubi0 error: ubi_io_write: error -5 while writing 2048 bytes to PEB 1622:0, written 0 bytes
Oct 15 22:00:16 kernel: CPU: 1 PID: 119 Comm: ubi_bgt0d Tainted: P O 4.19.183 #1
Oct 15 22:00:16 kernel: Hardware name: GTAXE16000_2GB (DT)
Oct 15 22:00:16 kernel: Call trace:
Oct 15 22:00:16 kernel: dump_backtrace+0x0/0x150
Oct 15 22:00:16 kernel: show_stack+0x14/0x20
Oct 15 22:00:16 kernel: dump_stack+0x94/0xc4
Oct 15 22:00:16 kernel: ubi_io_write+0x574/0x690
Oct 15 22:00:16 kernel: ubi_io_write_ec_hdr+0xc4/0x110
Oct 15 22:00:16 kernel: sync_erase.isra.0+0x11c/0x1f0
Oct 15 22:00:16 kernel: __erase_worker+0x34/0x460
Oct 15 22:00:16 kernel: erase_worker+0x18/0x80
Oct 15 22:00:16 kernel: do_work+0x98/0x120
Oct 15 22:00:16 kernel: ubi_thread+0x108/0x190
Oct 15 22:00:16 kernel: kthread+0x118/0x150
Oct 15 22:00:16 kernel: ret_from_fork+0x10/0x24
Oct 15 22:00:16 kernel: ubi0: dumping 2048 bytes of data from PEB 1622, offset 0
Oct 15 22:00:16 kernel: ubi0 error: __erase_worker: failed to erase PEB 1622, error -5
Oct 15 22:00:16 kernel: ubi0: mark PEB 1622 as bad
Oct 15 22:00:16 kernel: ubi0: 4 PEBs left in the reserve
Oct 15 22:24:15 ddns: IP address, server and hostname have not changed since the last update.
Oct 15 22:54:15 ddns: IP address, server and hostname have not changed since the last update.
Oct 15 23:00:17 kernel: ubi0 error: ubi_io_write: error -5 while writing 2048 bytes to PEB 85:0, written 0 bytes
Oct 15 23:00:17 kernel: CPU: 1 PID: 119 Comm: ubi_bgt0d Tainted: P O 4.19.183 #1
Oct 15 23:00:17 kernel: Hardware name: GTAXE16000_2GB (DT)
Oct 15 23:00:17 kernel: Call trace:
Oct 15 23:00:17 kernel: dump_backtrace+0x0/0x150
Oct 15 23:00:17 kernel: show_stack+0x14/0x20
Oct 15 23:00:17 kernel: dump_stack+0x94/0xc4
Oct 15 23:00:17 kernel: ubi_io_write+0x574/0x690
Oct 15 23:00:17 kernel: ubi_io_write_ec_hdr+0xc4/0x110
Oct 15 23:00:17 kernel: sync_erase.isra.0+0x11c/0x1f0
Oct 15 23:00:17 kernel: __erase_worker+0x34/0x460
Oct 15 23:00:17 kernel: erase_worker+0x18/0x80
Oct 15 23:00:17 kernel: do_work+0x98/0x120
Oct 15 23:00:17 kernel: ubi_thread+0x108/0x190
Oct 15 23:00:17 kernel: kthread+0x118/0x150
Oct 15 23:00:17 kernel: ret_from_fork+0x10/0x24
Oct 15 23:00:17 kernel: ubi0: dumping 2048 bytes of data from PEB 85, offset 0
Oct 15 23:00:17 kernel: ubi0 error: __erase_worker: failed to erase PEB 85, error -5
Oct 15 23:00:17 kernel: ubi0: mark PEB 85 as bad
Oct 15 23:00:17 kernel: ubi0: 3 PEBs left in the reserve

This is not the same problem as being discussed in this thread. You have a flash memory problem (see other posts regarding this error message).

 

[Armand28]

I also disabled DDNS and removed “Allow access from WAN” and for some reason my DDNS is still allowing me to access the router management and a port forwarded NVR using my asuscomm DNS…. I removed access and re-flashed the latest firmware, and checked the settings and both show disabled.

 

[Armand28]

This is not the same problem as being discussed in this thread. You have a flash memory problem (see other posts regarding this error message).

OK thanks! I was having the issue in this thread as well, was getting massive upload spikes so this must just be coincidental. Changed my password and the spikes seemed to have stopped, but had one short spike last night when these errors occurred.

 

[jd24]

All good overnight and today!! Stll looking into Omada or MikroTik routers though.
I see Microtik have an online trial of their routeros. Going to have a play with that