Is there any way to block a specific client (Thunder)?

[mr-cn]

In China, a download software named Thunder (XunLei) is very popular. But it won't upload even just a bit of data, reporting its progress is 0%, and it is always the fastest leecher in peer list, which made me angry.

To avoid being blocked, its client name is -XL0012- with some random strings.

Here is an example:

I have to right click it and block the IP manually. But it is impracticable due to its a large number of users.

We really need some effective methods to solve this problem.

qBittorrent version and Operating System

qbittorrent 4.1.5 running on Win10 1803.

[PoseidonYun]

唯一的解决方案似乎是使用第三方应用程序

我写了一个脚本来解决这个问题，arzyu/qbittorrent-ban-peer

端口迅雷已经随机，并不是固定的端口，希望官方提供一个允许链接的客户端选项，或者封禁PEER特定值，比如XL0012/XL0018

[starobots]

I solved this problem, by using the modification of qbittorrent, called qbittorrent enhanced. This mod has the anti-leech module for chinese leecher cilent. They have the github page, and the only problem is the enhanced version will replaced the qbittorrent and could not open both cilent at the same time.

[starobots]

I solved this problem, by using the modification of qbittorrent, called qbittorrent enhanced. This mod has the anti-leech module for chinese leecher cilent. They have the github page, and the only problem is the enhanced version will replaced the qbittorrent and could not open both cilent at the same time.

[generalbf]

Banning a specific peer is like cancelling a politician; another corrupted one would rise and take his place. The best way to hinder these leechers is to set 'Upload choking algorithm' to Round-robin, it cannot prevent feeding files to Xunlei, but at least you can make sure the rest of the flock get a portion of your upload.

[Seeker2]

Round-robin is probably a decent idea if you have more than twice as many connected peers as you have upload slots per torrent. The number of upload slots per torrent (and total upload slots globally) depends heavily on upload speed as well as peer quality. qBitTorrent will not work as effectively with only 1 or 2 upload slots per torrent, so that should be avoided unless upload speed is low. (low = less than 5 KB/sec upload speed average per upload slot)

Couple Round-robin also with regular Super Seeding on "afflicted" torrents and only the peers that are uploading to other peers would get significant upload from you over hour-long periods.

[Loyolichoo]

It's not a good idea to check client name...Because they can be easy to change their name even 'qbittorrent' or others...Just like the HTTP user-agent's confrontation between IE/Firefox/Chromium .

Why not try to check the amount of data uploading...If a peer got more than 1 blocks,10 blocks,or more data,but still be 0.00%,just ban it. Another way is to check other clients who are included the same peer and get uploading data from it..But it need protocol support and is too hard..when peers is too much ,it just like to build a Large-scale STP or BGP tree

[Artoria2e5]

It's not a good idea to check client name...Because they can be easy to change their name even 'qbittorrent' or others...Just like the HTTP user-agent's confrontation between IE/Firefox/Chromium .

Oddly enough, it is. Xunlei is a big piece of freemium commercial software that offers minimal configuration. Any faking it does is large enough in scale to detect and respond to, and I would argue the XL identification is actually important to keep the freemium thing (prioritization etc) working. The vast majority of leeches from China (and probably elsewhere) are clueless users using defaults, not pros.

As with transmission/transmission#735, my recommendation is to make something like an IPfliter but with client regexps. The pseudocode shall be:

C_BL_REGEX = re.compile(open('clfilter.txt').readlines().join('|'))

def is_banned(client: bytes) -> bool:
  c_str = client.decode('latin1')   # map all bytes to U+0000 ~ U+00FF, can do analogous for QString
  return C_BL_REGEX.fullmatch(c_str) is not None

Why did it not go through in transmission? Well uh there was no existing regexp library and I had to find one. And choices are hard!

Banning a specific peer is like cancelling a politician; another corrupted one would rise and take his place.

You could say the same about IP filters (especially now that v6 exists), but... Or antivirus, and...

[beoxgame]

我觉得应该把吸血雷看作一种100%丢包的特殊客户端来看待，然后最原始“反吸血”目标都要转变为“识别无效传输”来处理。

I think some leech peer like -XL0012- should be viewed as a special client with 100% packet loss, and then the original "anti-leech" target should be transformed into "identifying invalid transmissions" to handle.

---

（由于我并不是充分了解bt的底层原理，所以可能有事实错误，但相信思路是没问题的）

1. 比如说，如果一个torrent的文件总大小是100mb，切片大小是16kb的， 那在向一个进度为0%的peer传输了1mb流量之后，这个peer汇报的进度还是0%，那么可以判定传输有效率为0/64。 这种情况下不论是真的吸血，还是因为什么特殊的网络状态导致，最终结果都是传输无效，对这个peer上传是在纯粹的浪费资源，因此直接ban掉这个peer，关进黑名单过段时间再解禁就行了。

2. 此外还有一种策略是，在self->client上传了一部分内容后，反过来向client请求已经上传了的内容（最好使用伪造的另一个请求self2<-client），如果请求不到就调低client的上传优先级。 （这里无法准确判断实际情况，比如client已经满载向其他客户端上传了，没有带宽建立新的上传通道，因此只能是调低优先级）

在这两个策略的基础上，再提供几个“反吸血等级”的选项，交给用户来精确控制自己想要的效果。

---

最后有一个我不清楚的问题需要解决，虚拟一个peer身份是否可行？

如果不可行的话，吸血方很轻易就能回避这个方案带来的限制： 常规用户a向吸血方b上传资源（a->b），b只要汇报正确的进度就能回避第一点带来的限制，同时b可以阻塞掉其他客户端的下载请求（other<--X--b）实现吸血。 第二点是针对上面这个情况的，但是如果虚拟出来的peer身份不可靠（能被识别），那b只要在other<-b的请求中筛选出other(a)<-b，就能完全回避所有限制了。

[cablehub]

Might sound harsh, but after watching peer uploads/downloads for a long time, I noticed that there seem to be almost NO clients/peers located in China that ever upload. And if they do, the upload speed is usually below 1 KB/s.

Thus I now use IP filtering to block peers from China altogether (using https://github.com/fonic/ipfilter).

Might seem drastic, but I don't see any reason to bother dealing with badly behaving peers that just use up connection slots and fail to contribute to the swarm.

[azurenekowo]

It's nearly the end of 2023 now, I (and probably others) still have to watch Xunlei leechers steal stuffs without any payback. Fuck off. I have like 2 torrents that have been stalled because there is only a single peer, and they are using BitComet / Xunlei / Thunder and is uploading at 1 kb/s. It is stuck on 87% now. I can't even seed it, even if I want, because apparently he thinks "meh, only I shall get it and nobody else would!"

qBittorrent should ban them by default, out-of-the-box. Those leechers contribute absolutely nothing.

[Simple-Tracker]

https://github.com/Simple-Tracker/qBittorrent-ClientBlocker A client developed by us, we hope it can solve your problem. Currently only supports Simplified Chinese. Maybe it will be supported in the future? Because I don't really like translating so much text, but someone is welcome to contribute other language support (but I hope it's not hardcoded)

Since we realize that masking by name alone may be ineffective, we have introduced some methods for more advanced blocking. For example: 1. Blocking based on client upload size and Peer progress, which is very suitable for Peers whose progress does not increase; 2. Blocking based on the total upload volume of IP over a period of time. Excessive upload volume often means extremely high transmission speed, which may mean that some peers are continuing to seize the speed of other peers, which may be malicious; 3. Blocking based on the number of ports an IP has, an IP having too many ports could mean it is malicious (but could also be in a NAT environment), although qBittorrent does not enable multi-port connections by default; Our users reported that method 1 worked on a recent buggy client: anacrolix/torrent

[UjuiUjuMandan]

I agree that improving anti-leech algorithm is necessary, and UA-based blocking is ineffective, as long as XunLei can change it to whatever.

And now, you see, in 2024, setting Upload choking algorithm to Anti-leech seems solved the problem, I can observe one XL0012 in my peer list, and Up Speed for it was gradually reaching 0, though at first it was full speed. And it will disappear after a while.

Edit: I was wrong, it's just there's not many enough XL0012 for that torrent. I recently downloaded a trending torrent, and the Anti-leech algorithm doesn't work at all, the freaking XL0012 always get the most 'Uploaded'.

[Artoria2e5]

The "Anti-leech" choke working now is... interesting. 5 years ago there was indeed a libtorrent change that reacts to dishonest peers like Xunlei https://github.com/arvidn/libtorrent/pull/3833, explicitly referencing this issue. Except it should have made it into libtorrent 1.2, so people should have realized that it works for much longer.

Or maybe "people" are just not that good at checking. Could make sense!

---

UA-based blocking is ineffective, as long as XunLei can change it to whatever.

Xunlei does not intentionally obfuscate its UA. Maybe it's because UA-based blocking is not popular enough to make them change, maybe they really want to use it to find fellow Xunlei peers.

Anyways, with the choke we now know we have a way to choke Thunder. As mentioned in the PR, the dishonest check can be circumvented simply by sending HAVE messages, but Xunlei does not do that yet. Maybe it's because the choke method is not popular enough (it isn't the default after all).

Do we keep this issue open so we can still block BitComet and friends? Good to have another piece of kit in the arsenal. And running a regex match on the UA is cheap anyways.

[UjuiUjuMandan]

What's wrong with BitComet? Rutracker.org even recommends it.

[winnie23-23]

https://github.com/Simple-Tracker/qBittorrent-ClientBlocker A client developed by us, we hope it can solve your problem. Currently only supports Simplified Chinese. Maybe it will be supported in the future? Because I don't really like translating so much text, but someone is welcome to contribute other language support (but I hope it's not hardcoded)

Since we realize that masking by name alone may be ineffective, we have introduced some methods for more advanced blocking. For example: 1. Blocking based on client upload size and Peer progress, which is very suitable for Peers whose progress does not increase; 2. Blocking based on the total upload volume of IP over a period of time. Excessive upload volume often means extremely high transmission speed, which may mean that some peers are continuing to seize the speed of other peers, which may be malicious; 3. Blocking based on the number of ports an IP has, an IP having too many ports could mean it is malicious (but could also be in a NAT environment), although qBittorrent does not enable multi-port connections by default; Our users reported that method 1 worked on a recent buggy client: anacrolix/torrent

Will it work on a seedbox??

[Simple-Tracker]

https://github.com/Simple-Tracker/qBittorrent-ClientBlocker A client developed by us, we hope it can solve your problem. Currently only supports Simplified Chinese. Maybe it will be supported in the future? Because I don't really like translating so much text, but someone is welcome to contribute other language support (but I hope it's not hardcoded) Since we realize that masking by name alone may be ineffective, we have introduced some methods for more advanced blocking. For example: 1. Blocking based on client upload size and Peer progress, which is very suitable for Peers whose progress does not increase; 2. Blocking based on the total upload volume of IP over a period of time. Excessive upload volume often means extremely high transmission speed, which may mean that some peers are continuing to seize the speed of other peers, which may be malicious; 3. Blocking based on the number of ports an IP has, an IP having too many ports could mean it is malicious (but could also be in a NAT environment), although qBittorrent does not enable multi-port connections by default; Our users reported that method 1 worked on a recent buggy client: anacrolix/torrent

Will it work on a seedbox??

Yes, it works, as long as you have access to shell and systemd.

[winnie23-23]

https://github.com/Simple-Tracker/qBittorrent-ClientBlocker A client developed by us, we hope it can solve your problem. Currently only supports Simplified Chinese. Maybe it will be supported in the future? Because I don't really like translating so much text, but someone is welcome to contribute other language support (but I hope it's not hardcoded) Since we realize that masking by name alone may be ineffective, we have introduced some methods for more advanced blocking. For example: 1. Blocking based on client upload size and Peer progress, which is very suitable for Peers whose progress does not increase; 2. Blocking based on the total upload volume of IP over a period of time. Excessive upload volume often means extremely high transmission speed, which may mean that some peers are continuing to seize the speed of other peers, which may be malicious; 3. Blocking based on the number of ports an IP has, an IP having too many ports could mean it is malicious (but could also be in a NAT environment), although qBittorrent does not enable multi-port connections by default; Our users reported that method 1 worked on a recent buggy client: anacrolix/torrent

Will it work on a seedbox??

Yes, it works, as long as you have access to shell and systemd.

How do I go about installing it on my seedbox? They provide SSH and systemd access

[Simple-Tracker]

https://github.com/Simple-Tracker/qBittorrent-ClientBlocker A client developed by us, we hope it can solve your problem. Currently only supports Simplified Chinese. Maybe it will be supported in the future? Because I don't really like translating so much text, but someone is welcome to contribute other language support (but I hope it's not hardcoded) Since we realize that masking by name alone may be ineffective, we have introduced some methods for more advanced blocking. For example: 1. Blocking based on client upload size and Peer progress, which is very suitable for Peers whose progress does not increase; 2. Blocking based on the total upload volume of IP over a period of time. Excessive upload volume often means extremely high transmission speed, which may mean that some peers are continuing to seize the speed of other peers, which may be malicious; 3. Blocking based on the number of ports an IP has, an IP having too many ports could mean it is malicious (but could also be in a NAT environment), although qBittorrent does not enable multi-port connections by default; Our users reported that method 1 worked on a recent buggy client: anacrolix/torrent

Will it work on a seedbox??

Yes, it works, as long as you have access to shell and systemd.

How do I go about installing it on my seedbox? They provide SSH and systemd access

https://github.com/Simple-Tracker/qBittorrent-ClientBlocker

Read the readme (you can translate it appropriately). Use systemd service directly or use docker container.

[trabolic]

Why not having support for regular expression or at least wildcard expression to block peers by their client names?

Something like: expression ^-?XL\d{1,4}- to match the following patterns

-XL0011-
-XL0012-
-XL0013-
-XL0099-
-XL01-
-XL9999-

https://regex101.com/r/reRaZ8/1

[cablehub]

Why not having support for regular expression or at least wildcard expression to block peers by their client names?

In the long run, this would just become a game of whac-a-mole. If BT apps start blacklisting certain clients based on their id (or similar characteristics), developers of blacklisted clients will simply implement some sort of faking mechanism or randomization. That's a competition that cannot be won.

[Seeker2]

Then competition needs to be based on bad behavior, which is a lot harder to hide. Might even encourage bittorrent developers to fix unintentionally leech-like behavior.

[netheril96]

Why does no bittorrent client record the history of uploads/downloads permanently and prioritize seeding to peers who have uploaded to self? I can think of two reasons (1. starving newbies 2. IP address is often not permanent), but these can be solved (partially). It would encourage good behavior from everyone. Right now the problem lies not only with people running these leeching clients, but also people who exit their clients as soon as the download is finished and never seed after that.

[Artoria2e5]

While the "anti-leech" choke works for Xunlei (because Xunlei never gives HAVE messages), there is recently a new breed of powerful leechers in the Chinese internet. Apparently the 123 云盘 online storage service now uses BitTorrent as a P2P CDN without contributing back. It even uses the client name of an existing client...

https://github.com/anacrolix/torrent/discussions/891#discussioncomment-8810897

(I don't quite get the business model of PCDN. The user is somehow motivated to download anything a lot to trick the carrier or something.)

We need to figure out if the same check works on these chuds. They seem to send HAVE messages but lies about them (https://github.com/anacrolix/torrent/discussions/891#discussioncomment-8861355). The choke now mandates some degree of honesty with HAVE messages by calculating a max of sent size vs HAVE size, so it could still work.

With PCDN though, the choke working as designed might still not be enough: choking is about priority, not blocking. There are concerning reports of carriers shutting off people's internet access because their torrent clients are uploading too much from the recent PCDN mega-leeches.

[yueisme]

use https://github.com/PBH-BTN/PeerBanHelper helpful for me