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

And I have used the anti-bloodsucking upload congestion control strategy. (I don't know the English exact name)

There's a qBittorrent fork here that you may be interested in, see https://github.com/c0re100/qBittorrent-Enhanced-Edition/issues/2

There's a qBittorrent fork here that you may be interested in, see c0re100#2

That seems good.
But I am curious about if the origin qBittorrent is willing to add similar features.
If I can, I prefer to use an official version instead of a 3rd-party version.

I think it will be nice if we can set some rules to match a client and block it.

Such as, blocking a peer whose ip is in range from x.x.x.x to x.x.x.x, or blocking a peer whose client name contains string 'XL0012', and so on.

Even we can write a userscript to implement advanced features.

"And I have used the anti-bloodsucking upload congestion control strategy. (I don't know the English exact name)"

Anti-leech is what that option is called in English.
From this link: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp
"the anti-leech seeding algorithm is based on the paper "Improving BitTorrent: A Simple Approach" from Chow et. al. and ranks peers based on how many pieces they have, preferring to unchoke peers that just started and peers that are close to completing."
It uploads MORE to the 0% complete Thunder (XunLei) clients than 5-95% complete random peers!

A more effective means of combating peers that give nothing is enabling "regular" super seeding on ALL torrents. Max upload slots MUST be lower than number of connected peers or qBitTorrent will still upload to every peer.
Strict super seeding is a more extreme form that does not work well on torrents with <5 connected peers -- it will end up NOT uploading to good peers for long intervals of time.

Manually banning the peers is unfortunately necessary if you want to keep uploading to them to a minimum. This may require creating an ipfilter.dat block range for the worst ip ranges.

"And I have used the anti-bloodsucking upload congestion control strategy. (I don't know the English exact name)"

Anti-leech is what that option is called in English.
From this link: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp
"the anti-leech seeding algorithm is based on the paper "Improving BitTorrent: A Simple Approach" from Chow et. al. and ranks peers based on how many pieces they have, preferring to unchoke peers that just started and peers that are close to completing."
It uploads MORE to the 0% complete Thunder (XunLei) clients than 5-95% complete random peers!

A more effective means of combating peers that give nothing is enabling "regular" super seeding on ALL torrents. Max upload slots MUST be lower than number of connected peers or qBitTorrent will still upload to every peer.
Strict super seeding is a more extreme form that does not work well on torrents with <5 connected peers -- it will end up NOT uploading to good peers for long intervals of time.

Manually banning the peers is unfortunately necessary if you want to keep uploading to them to a minimum. This may require creating an ipfilter.dat block range for the worst ip ranges.

I see. I have taken the option name literally.

So, it means that no matter using 'super seeding' mode or changing options, there's no good way on an official build to block it out, right?

Being the same as them, I don't want to upload any a bit to these junk clients, too.

I 'm using 3rd-party version now, feeling good.

Super seeding with upload slots limited lower than max connections works well over 1+ hour time.
A 0% peer will get ONE piece that few/no other peers have and until other peers report having that piece that 0% peer is unlikely to get any more upload from you.

Having read this page, I understood how the super seed mode works.

But I am not the initial seeder, all peers can easily get any pieces, so I think it can't help me.

Super seeding doesn't require you being the initial seeder, it just works more efficiently there -- with less duplicate uploading. But you probably don't care as much about uploading the same piece to multiple peers over a 1 hour interval than uploading multiple pieces to leeching XunLei clients.

theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me?
都９１０２年了，还有人在说迅雷不上传给其他客户端...

theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me?
都９１０２年了，还有人在说迅雷不上传给其他客户端...

如图这种XL0012的迅雷客户端，不论你上传多少给他们，他回报的进度永远是0%，并且不会上传任何信息给你。

不信你自己去公网随便下载几个种子，就清楚了。

有些版本的迅雷(UA是迅雷的版本号，而不是XL0012)，是会上传的。

即使是9102年了，迅雷做过的恶依然不会消失！

"theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?"

They lie about their percentage complete, claiming always 0% even after seeds and peers have uploaded many pieces to them.

Older versions of qBitTorrent (about 3.0.10 or before?) did the same thing to a lesser degree, partially due to a bug and/or programming oversight.

I enabled Strict Super Seeding and set Upload Choking Algorithm to Anti-leech. However, it seems the Xunlei clients flood the swarm with connections during peak times for popular torrents. Only solution for increasing download and upload rates was to manually ban IPs with client label "-XL0012..." as they connected - which was quite laborious.

ankushnarula, as I already pointed out earlier in this issue thread, Anti-leech makes the problem worse instead of better.
Also, regular Super Seeding is more effective than Strict Super Seeding -- both in slightly resisting leech attacks and in dealing with hostile peers.

There needs to be a more comprehensive manner of dealing with hostile peers. Banning hostile clients will unfortunately need to be automated/automatic, but with a means to disable that due to possible bugs in its logic.

Forgive me. I misunderstood. However, I arrived at your conclusion via trial and error. It also seems this won’t be solved fairly outside a per torrent distributed consensus approach.

On Apr 24, 2019 at 18:46,

ankushnarula, as I already pointed out earlier in this issue thread, Anti-leech makes the problem worse instead of better.
Also, regular Super Seeding is more effective than Strict Super Seeding -- both in slightly resisting leech attacks and in dealing with hostile peers.

There needs to be a more comprehensive manner of dealing with hostile peers. Banning hostile clients will unfortunately need to be automated/automatic, but with a means to disable that due to possible bugs in its logic.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (https://github.com/qbittorrent/qBittorrent/issues/10258#issuecomment-486455764), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAAQWM7YZNFLNGHCQWTNR7TPSDPOBANCNFSM4GUKOVLQ).

Same here, banning -XL012 manually when downloading a public torrent is laborious as they keep popping up through dht pex if not added third party trackers (some popular trackers either are blocked in China or block Chinese ips). Not only do they appear to be at 0% and occupy a huge portion of your upload bandwidth if left unchecked, but also give none in return. Though it's less a problem for users that are not in China, as far as I can see GFW filters inbound traffic even more than it does outbound so Xunlei can't leech as efficiently.
(But as far as I know, qb won't have this feature unless libtorrent implements it.)

You are right. Maybe I should post it to libtorrent’s repo?

发送自 Windows 10 版邮件应用

发件人: NAVrasZ
发送时间: 2019年5月13日 18:10
收件人: qbittorrent/qBittorrent
抄送: MR; Author
主题: Re: [qbittorrent/qBittorrent] Is there any way to block a specificclient (Thunder)? (#10258)

Same here, banning -XL012 manually when downloading a public torrent is laborious. Not only do they appear to be 0%, if left unchecked they usually occupy a huge portion of your upload bandwidth, leaving little for others and give none in return.
(But as far as I know, qb won't have this feature unless libtorrent implements it.)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

It's already referenced in https://github.com/arvidn/libtorrent/pull/3833, tho their take on this is to fix the loophole that is being abused instead of adding an extra ban feature.

Maybe adding to blacklist is a fast way to block Xunlei? I just need to add XL0012 to that blacklist and qbt will block these clients automatically. It is easy to hack for leeches but sometimes may be a little bit useful.

theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me?
都９１０２年了，还有人在说迅雷不上传给其他客户端...

I have been using qbit for four years ,
and I have never seen Thunder upload (xunlei/XL002).
Even if I upload 1GB to him, he still shows 0% progress,
Only the speed version (7.x.x.x) will upload at a speed of 50kb or less.
There are too many Thunder users, we need anti-blood function.
Just want to use the official version.

"choke dishonest peer in anti-leech seeding algorithm" has been implemented in libtorrent 1.2.1, currently there is a qbittorrent 4.2.0RC with libtorrent 1.2.2 released, can those of you having issues with Thunder (XunLei) test it & can you report if there is any uploading happening still??

"choke dishonest peer in anti-leech seeding algorithm" has been implemented in libtorrent 1.2.1, currently there is a qbittorrent 4.2.0RC with libtorrent 1.2.2 released, can those of you having issues with Thunder (XunLei) test it & can you report if there is any uploading happening still??

https://imgur.com/qYKQqfr
still uploading

@cannotbeblank are you using anti-leech algorithm??

@cannotbeblank are you using anti-leech algorithm??

Need to use this feature? I thought it was blocked by default.
I am using algorithm now.
but still
https://imgur.com/ME9peky

Anti-leech is not only ineffective, it does the OPPOSITE of what the name implies -- as I explained earlier on this thread.

qBitTorrent's Super-seeding method (but not strict super-seeding or initial seeding) is more effective -- but only if upload slots per torrent is less than peers on that torrent.

"choke dishonest peer in anti-leech seeding algorithm" has been implemented in libtorrent 1.2.1, currently there is a qbittorrent 4.2.0RC with libtorrent 1.2.2 released, can those of you having issues with Thunder (XunLei) test it & can you report if there is any uploading happening still??

The solution seems not working.

Anti-leech algorithm. Windows 10. qBittorren 4.2.0RC

At the moment I've already uploaded more or less 800KiB to the client.

Edit - Follow-up

The client has just downloaded 1 MiB and still marks 0.0% progress. In the swarm other clients which have downloaded 64 KiB marks 0.1% in the progress column.

Edit/2

After rebooting no traces of XunLei in the swarm at the moment

Edit/3

XunLei 0012 and 0.0.1.8 still present, still downloading, still marking 0 % progress

Using Linux & version 4.3.0alpha1, they still connect & only leech. There was one odd one who actually showed something more than 0% complete though.

It seems that the PR arvidn/libtorrent#3833 doesn't help.

qbittorrent version: 4.2.0

Upload choking algorithm has been set to "Anti-leech". (and other two algorithm don't help too.)

As you can see, it received more than 120MB (currently 180MB before banned), which means 30 pieces and 1.5% of the entire torrent.

Additionally, In the screenshot, you can see a peer whose UA is 7.10.34.360. It is the old version of Xunlei, which is honest.

If a torrent is utterly flooded with incoming connections of which many/most of them are leeches or worse hostiles, try temporarily disabling incoming connections (by removing port forwarding/adding a firewall rule), DHT and PEX.
...and reduce max connections per torrent to equal or below the currently connected number of peers+seeds. (This should have the same effect as disabling incoming connections, but may take more bandwidth.)

According to wikipedia, Thunder doesn't support uTP ...or if it does, even more poorly than qBitTorrent/libTorrent does! So disabling TCP seed+peer connections should block it completely.
Even not allowing incoming TCP connections (only port forward UDP on your router for example) should make them rarely seen -- because the Great Firewall of China blocks most outside-of-China attempts to connect to Thunder clients in China.

If a torrent is utterly flooded with incoming connections of which many/most of them are leeches or worse hostiles, try temporarily disabling incoming connections (by removing port forwarding/adding a firewall rule), DHT and PEX.
...and reduce max connections per torrent to equal or below the currently connected number of peers+seeds. (This should have the same effect as disabling incoming connections, but may take more bandwidth.)

According to wikipedia, Thunder doesn't support uTP ...or if it does, even more poorly than qBitTorrent/libTorrent does! So disabling TCP seed+peer connections should block it completely.
Even not allowing incoming TCP connections (only port forward UDP on your router for example) should make them rarely seen -- because the Great Firewall of China blocks most outside-of-China attempts to connect to Thunder clients in China.

LOL
Have you seen previous comment's image..........?
Thunder support uTP since long time ago,,,,,,

Good point...and yes, I missed that. But can it do STUN with uTP?
...if not, don't forward UDP and it probably can't connect incoming.

With the help of web api and ipfilter.dat (like Get torrent peers data and Set application preferences), those specific peer clients (like XL0012, Xunlei, client: 7.2.) are still easy to be filtered out, though it's a not built-in feature.

BTW, considering about those clients without static ips, a time-based rotate mechanism of filtering ip may be needed to implement.

I assume everyone has thought about the fact if you try to ban specific clients, those people that code that client could just make or enable something to spoof their client ID to another that is not what it is, so this really isn't a good 'fix' necessarily? Or hopefully I'm wrong, I don't do much coding.

I hate to say it, but maybe you prioritize connections from certain countries, like with a drop down menu, and then on top of that you can base transfer rates based upon the transfer speed? But this probably has gotten beyond a qBitorrent issue? I'm sure I'm not the first one to think about this either, sorry.

With the help of web api and ipfilter.dat (like Get torrent peers data and Set application preferences), those specific peer clients (like XL0012, Xunlei, client: 7.2.) are still easy to be filtered out, though it's a not built-in feature.

BTW, considering about those clients without static ips, a time-based rotate mechanism of filtering ip may be needed to implement.
老哥能弄个懒人版的脚本吗？
只需要ban xl0012就行了，那个第三方的qtorrent把所有迅雷都ban了

I hate to say it, but maybe you prioritize connections from certain countries, like with a drop down menu, and then on top of that you can base transfer rates based upon the transfer speed? But this probably has gotten beyond a qBitorrent issue?

qBitTorrent (or rather libtorrent that qBT uses) has local peer handling which either gives higher priority or unlimited speed to ips it determines are "local". Such behavior could possibly be extended to middle-distance peers with low pingtimes and/or traceroute hop count...and distant peers would get lower priority.
This behavior probably needs to default to OFF, as not everyone needs it and defaulting to on could be detrimental to torrent swarms that don't have lots of Thunder peers.

Linux users can configure their firewall to filter packets from these malicious clients, as a temporary workaround.

For example:
iptables -I INPUT -p tcp -m string --string XL0012 --algo bm -j DROP
iptables -I INPUT -p udp -m string --string XL0012 --algo bm -j DROP

In most times this will work, but sometimes I still can see some XL0012 clients connected. I'm not sure whether they're doing some kinds of obfuscating.

In #issuecomment-462029063, someone says:

theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me?
都９１０２年了，还有人在说迅雷不上传给其他客户端...

Translation:

It is 2019 now, and there is still some people say that XunLei (Thunder) won't upload to other clients

都 0202 年了

However, it's even 2020 now, and this is what I see:

(a forever 0% peer)

Yes, Thunder have released new version that is not so evil, but there is still a number of people using old version evil client. So anti-leech and banning client feature is still necessary.

Update: add English translation

换成bitcomet就行了，对付迅雷不上传的客户端非常有效。这作者看样子也不会花时间去解决国内种源特有的迅雷问题

@Phuker @foxdodo English only please.

I'm seeing this issue too. Clients with string "-XL0012" leeching and not advancing their progress. Maybe it's out of scope but it would be nice to have a feature to block those clients.

你快照中两个迅雷客户端的分步是 0%，他们怎么能上传到别人呢？ [9102]，...

我已经使用 qbit 四年了，
我从来没有见过雷声上传 （迅雷 / XL002） 。
即使我上传 1GB 给他， 他仍然显示 0% 的进展
， 只有速度版本 （7.x. x. x） 将上传的速度 50kb 或更少。
雷霆用户太多，我们需要防血功能。
只想用官方版。

it seems true, I am concerned about that, while using the pt to download torrent, the pt website band the qbittorrent enhanced version which is works in prohibiting thunder(XL0012), but using the offical version won't be like that.