-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
One thread stuck at 100% usage due to connection flood? #20830
Comments
Probably a DDoS or another kind of attack.
qB restricts a number of active connections (
Yes. Who knows.
Yep, different kind of attacks will happen, especially if you have a static IP. Torrent clients basically advertise their existance to the whole world via DHT. So you have no other choice than utilizing firewalls. The client itself also supports IP filters, but I guess it will continue to drain CPU to reject connections (and also spams into the log), so OS-level firewall it the way to go I believe. |
Indeed and I have it set to 500. It doesn't seem to have helped in this case. |
qBittorrent & operating system versions
qBittorrent: v4.6.4
Operating system: Ubuntu 20.04
Qt: 6.7.0
libtorrent-rasterbar: 2.0.10.0
What is the problem?
This one's a bit peculiar and I'm not sure if it qualifies as a bug, so feel free to close. But I wanted to draw attention to it.
Today I noticed that one of the threads belonging to the
qbittorrent-nox
process was constantly at 100% cpu usage.I first checked using strace and it seemed to be doing normal stuff, sending packets, receiving packets.
What caught my eye in the strace output was this:
IP addresses are usually distributed quite randomly, so qBt organically interacting with this many IPs in the same subnet is statistically unlikely.
I also checked all my active torrents and couldn't find a single of these IPs in the peer list.
Next I used tcpdump to capture all traffic to/from the relevant subnet (
190.80.24.0/24
).In the ~20 seconds I captured Wireshark counted more than 800 unique conversations happening with the port qBt was listening on.
Almost all of the 256 IPs in that subnet were involved (that includes
.0
and.255
).What I tried next was to block all traffic from
190.80.24.0/24
in the firewall. The CPU usage instantly returned to normal levels.The last thing I tested was to remove the firewall rule. It didn't take long for some suspicious CPU peaks to appear and the 100% usage returned after about half an hour.
Unanswered questions:
Steps to reproduce
Additional context
I can share the PCAPs if they're useful.
Log(s) & preferences file(s)
No response
The text was updated successfully, but these errors were encountered: