qBitTorrent users seeing infinite requests from peers in 1.180.24.0/23, 36.102.218.0/24 and 221.203.6.0/24

[anacrolix]

This is a discussion around #889 which I believe has been fixed with regard to anacrolix/torrent. I expect new IP subnets and possible resolution for the offending peers will be discussed.

[JockeyWang]

Here are some IPs I encountered, all from northern China, especially in Jilin and Inner Mongolia province. For Ipv6 addresses, the bits at position 65-112 are always 0, different from personal address.
1.180.24.2/87/220/225/242
1.180.25.15/84/131/210/216/246
36.102.218.131/132/138/222
42.52.131.43
59.47.225.165
59.47.237.156/189
123.184.152.39/88/89/90/98/103/132/133/245/249
218.7.138.15/18/20/24/27/29
218.24.113.70
218.60.174.9/10/30/32/64/65/115/215/222
221.203.3.15/16
221.203.6.54/58/60
2408:862e:ff:ff0d::201/205/209/20b/20d/211/212/21a/21b/21c/21d/226
2408:8738:6000:d::13/16/19/1e
240e:90c:2000:301::218/219/21a/21c/21d/224/225/229/22a/22d
240e:90e:2000:2006::201/202/203/206/208/209/21f
240e:918:8008:3::61
240e:918:8008:4::224

Thus, I use this rules:
1.180.24.0-1.180.25.255
36.102.218.0-36.102.218.255
42.52.131.0-42.52.131.255
59.47.225.0-59.47.225.255
59.47.237.0-59.47.237.255
123.184.152.0-123.184.152.255
218.7.138.0-218.7.138.255
218.24.113.0-218.24.113.255
218.60.174.0-218.60.174.255
221.203.3.0-221.203.3.255
221.203.6.0-221.203.6.255
2408:862e:ff:ff0d::0-2408:862e:ff:ff0d::ffff
2408:8631:2e09:d05::0-2408:8631:2e09:d05::ffff
2408:8738:6000:d::0-2408:8738:6000:d::ffff
240e:90c:2000:301::0-240e:90c:2000:301::ffff
240e:90e:2000:2006::0-240e:90e:2000:2006::ffff
240e:918:8008:3::0-240e:918:8008:3::ffff
240e:918:8008:4::0-240e:918:8008:4::ffff

Moreover, I found some other clients, not anacrolix/torrent, have similar behavior. I am still observing.
2409:8a1e:e23:85b0::8a8 - Transmission, do not report progress, and requests more than file itself.

[TomoeMami]

BT client UA changed, still infinite request

[TTsdzb]

There could be many possible reason for such massive batch of clients in China:

1. Some cloud drive provides bittorrent download feature. If their software is not properly developed, they could be using defective clients without knowing it. In this case the provider is responsible for their clients.
2. Some BT user was mistaken for PCDN and got banned. He was pissed off and run (or even produce) defective clients and hope someone else be banned as well. Such thing could possibly happen, and all we can do is block his IPs or clients.
3. There're underground industry providing PCDN, and they're suffering loss during the detection. To maintain their industry so they could profit, they chose to attack BT users.

The issue doesn't looks like normal bugs. If so, IP address of these clients should be distributed, without recognizable features.

The living environment of BT in China is not well. Ignorant people tends to profit instead of share. There're many users using clients that do not upload (or only upload to their private network), for download speed or just stingy with their network bandwidth. ISPs provide you internet with cascading NATs, and sometimes it's hard to make connections.

[tuxayo]

He was pissed off and run (or even produce) defective clients and hope someone else be banned as well

Produce, unlikely, that seems a genuine bug.
Even willingly run, that's a weird bug to have found and then choose to deploy a lot of clients.

[TTsdzb]

What the issue with PCDN that cause them to be banned?

Residential broadband internet service is much cheaper than commercial ones. ISPs profit with their commercial service, and subsidize residential ones with part of this profit. But soon large internet companies find out that using PCDN is way much cheaper than traditional CDN services. ISPs could not profit anymore.

Soon some people found out there are great benefits providing PCDN services. Some of them buy batches of cheap residential broadband internet, others distribute works to internet users and give them commission (somehow like mining, people run a software on their computers). These industrialized PCDN providers are sucking the blood of ISPs, and also violated terms and conditions of home broadband services.

[TTsdzb]

He was pissed off and run (or even produce) defective clients and hope someone else be banned as well

Produce, unlikely, that seems a genuine bug. Even willingly run, that's a weird bug to have found and then choose to deploy a lot of clients.

There might be sour grapes. I think we should stay alert before we could say "It IS a genuine bug", since it's so susbisious.

In the original issue someone reported that this behavior has been going on for more than a week. It should have been found out if it's a bug.

[RealYukiSan]

What is PCDN?

[BUnipendix]

What is PCDN?

Networks/P2P CDN - W3C Wiki
windows delivery optimization for example

[TTsdzb]

I tried the following things in my filter dat:

1.180.24.0-1.180.25.255
36.102.218.0-36.102.218.255
221.203.6.1-221.203.6.255
240e:918:8008::0-240e:918:8008:ffff:ffff:ffff:ffff:ffff

And qbt could recognize 4 rules. I'm not sure whether this works.

[JockeyWang]

One more client found: 221.203.3.16.
Maybe 221.203.6.1-221.203.6.255 should update to 221.203.0.0-221.203.7.255

[WhiteCoffee9834]

[MisakaMikoto-35c5]

用 cat GT0003.DT0001.HP0001.txt | grep -v -e '[0-9a-z]*:' | sed 's/[0-9]* .*\-/0\/24/' | sort -n | uniq | wc -l 剔除掉 IPv6 段以后统计 /24 数量，也只有 183 个 /24 而已。因为现在宽带账号虽然是动态 IP，但 ISP 分配 IP 的规则通常都是一个宽带账号在几个 /24 或者一个 /22 来回跳的，所以这符合逻辑。

[qwqcwcawa]

同时出现一堆/24范围的ip家宽可做不到

[MisakaMikoto-35c5]

如果是下面这张图还真可以做到（来源），地理位置相近大概率开到同一段 IP

[qwqcwcawa]

123盘怎么可能用家宽搞这玩意

链接

[bluicezhen]

PCDN is not a good reason for them to broak BT network.

[WhiteCoffee9834]

Discussion of PCDN is off-topic

In the previous issue, the repository owner mentioned a way to block client strings, blocking github.com/anacrolix/torrent (devel) (anacrolix/torrent unknown).

I only know how to block IP segments using dat files, but how to block client version string?

The software used is qBittorrent Enhanced Edition.

---

讨论PCDN脱离了主题

在之前的issue中,仓库主有提到禁止客户端字符串的方式,也就是屏蔽 github.com/anacrolix/torrent (devel) (anacrolix/torrent unknown)

目前只知道如何使用 dat 文件屏蔽 IP 段,如何屏蔽客户端标识呢

做种软件使用的是 qBittorrent Enhanced Edition

[karuboniru]

It do have such mechanism for blocking certain client ID, while due to lack of documentation following is just some guess by quick looking at the code.

Create a file named after peer_blacklist.txt under data folder of qBittorrent EE.

The file created should contain peer_id client_name per each line, and regex rule applies here.

[UshioA]

In qBittorrentEE, they use std::ifstream and >> to read peer_id and client, making client string github.com/anacrolix/torrent (devel) (anacrolix/torrent unknown) basically unbanable because it contains space.

Here i just substitute every space with \s as a work around. This also means that the regex rule cannot contain any whitespace or it won't work as expected.

To me the solution maybe (Thanks @Duck1998 for new malicious clients)

-GT0003- github.com/anacrolix/torrent\s\(devel\)\s\(anacrolix/torrent\sunknown\)
-DT0001- dt/torrent/v1.00
-DT0001- dt/torrent/v1.01
-DT0001- DT\s0.0.0.1

[matchbean111]

I will try this ,thank you

[JotmKKmkLTzE]

thank you, it works fine

[Gloryandel]

Thanks a lot for the source code analysis!

[AutismGaming228]

It might be a rogue operation, considering a client under same IP has two different "percent downloaded", downloads at high speeds yet both don't increase. (I have "Accept multiple connections from the same IP" option enabled in qBittorrent)

[Moredistant]

this guy is a disgrace to China

[tuxayo]

this guy is a disgrace to China

Only racists and ultra nationalists care about where people are from so it not important.

If that's indeed a rogue operation, then there is no hope in the person managing those nodes updating them and the problem going away. It's insane they have so much bandwidth if they are leeching on multiple peers at these speeds.

[Dokupe999]

218.60.174.254
218.60.174.8

[karuboniru]

Noticed several clients in
240e:90e:2000:2006::/64

[Moredistant]

New malicious ip：123.184.152.242 123.184.152.81 123.184.152.90

There is another suspected new malicious client called "taipei-torrent dev". It did not report any download progress, and when I wanted to continue observing, It suddenly disappeared.

[Moredistant]

我又发现了它，它视乎下载到一定量，就会主动消失，像是在对抗反吸血检测
I found it again, and it seems to disappear once it reaches a certain amount of downloads, as if it is evading anti-vampire detection.

[Moredistant]

出个门被偷袭了，妈的
I was ambushed when I went out

[nulllee]

Same, same. This guy(↓) has downloaded more than 300GB from just one torrent on my computer with this client called Taipei-Torrent dev.
IP: 58.241.210.(7,8,9,10).

[nulllee]

And 58.241.210.5.

[LightmoonXD]

同样的问题，这些客户端偷走了我超过300倍于实际大小的上传量，不过我没有看到它突然断开连接。
Same here, these clients had taken more than 300 times the actual size of data.But I don`t notice any sudden disconnection.

[anacrolix]

That's interesting, I don't think Taipei torrent is based on my client.

[Moredistant]

That's interesting, I don't think Taipei torrent is based on my client.

from: https://github.com/jackpal/Taipei-Torrent

[ExplodingDragon]

或许可以配置一个策略，如果客户端请求流量在1天的窗口期超过文件实际大小的 25% 则直接拉黑？
似乎所有的客户端都不支持此方案 。

Maybe configure a policy to simply pull the plug if client request traffic exceeds 25% of the actual size of the file in a 1-day window?
It seems that all clients do not support this option .

[TTsdzb]

也许可以请求 qBittorrent Enhanced Edition 实现这个策略。它的限制是比较激进的。

Maybe we can request qBittorrent Enhanced Edition to implement this policy, since it has very aggressive limitations.

[anacrolix]

This is a pretty good idea. I would set the ratio to something like 3x the actual size of the torrent. So you would record an IP (and maybe port) combo against a total data download. If that quantity exceeds ~3x the size of the torrent in some timeframe (24-48 hours would be reasonable), you would block them for 24 hours.

The reason you want to do several multiples is you don't want to ban streaming clients that use caches for storage, and clients with legitimate errors (like the user running out of disk space, aborting the download, cleaning up and then restarting it).

[winnie23-23]

What about people on seedboxes that don't have opportunity to use anything beside what the provider offers? Had to stop 7 torrents after one of these Chinese IPs downloaded over 1 TB of data in one day on a single torrent. And it's not a solution at all as that prevents legitimate users from downloading the content. Ipfilter doesn't seem to work properly and as I use 3 different clients (deluge, qbt, transmission) there's no universal solution for that

[tuxayo]

What about people on seedboxes that don't have opportunity to use anything beside what the provider offers? [...] And it's not a solution at all as that prevents legitimate users from downloading the content.

If anyone notices that issue on their client on a seedbox, they need to report that to their provider and pester them about until they upgrade the software. The proper solution to this issue is someone using or managing those bugged versions to notice it.

[winnie23-23]

How it's gonna help? These Chinese IPs will still.do their thing and my seedbox provider can't do anything about it...they can't even update some clients to latest versions available and whitelisted on trackers I'm on...

[xyhxh46]

Does anyone know how Deluge blocks clients, I only know that QEE can block clients at the moment.
请问有人知道deluge如何屏蔽客户端吗，我目前只知道qee可以屏蔽客户端，deluge只能屏蔽IP地址。

[kirisauce]

You could try using PeerBanHelper

[Sphyix]

I started using qBitTorrent API to track who's downloading more than 125% of torrent max size without ever updating the completed %.
I can publish the list of IPs banned or make the c# script public.
I think this is more accurate than just banning entire subnets

[winnie23-23]

Will it work on seedbox? Or just on PC?

[Sphyix]

It would be a .exe that runs on windows.
Code is pretty basic, someone could easily rewrite it in other languages.
Only requirement is access to the API of the qbit instance

[Sphyix]

now we know, they just consume traffic

[tuxayo]

Damn so it's not a bug, it's an attack. Likely the asshole behind this found this ticket: thanks that you changed the name, now the developer can stop worrying of having a bug. And people won't blame them thinking anacrolix client has a terrible bug.

[tuxayo]

This discussion and #889 would benefit being renamed to explicitly mention that it's a malicious fork.

[F-TD5X]

hmm...

[LightmoonXD]

So, he is the one who uses bugs from anacrolix for no reason? This guy forked anacrolix on 15 Feb, and it did not match the earliest report for unusual leecher.（on Jan）I think anacrolix v1.53.3 had fixed up this problem, maybe he just using the normal client and modified it to escape the auto ban script?

[lirener]

240e:90e:2000:2006::209			中国辽宁省本溪市 中国电信IDC（持续攻击者）（探测=4）
240e:90c:2000:301::219			中国辽宁省本溪市 中国电信IDC（持续攻击者）
240e:90e:2000:2006::215			中国辽宁省本溪市 中国电信IDC（持续攻击者）
240e:90e:2000:2006::21b			中国辽宁省本溪市 中国电信IDC（持续攻击者）
240e:90c:2000:301::21d			中国辽宁省沈阳市 中国电信IDC（持续攻击者）
240e:90c:2000:301::216			中国辽宁省沈阳市 中国电信IDC（持续攻击者）
240e:90c:2000:301::225			中国辽宁省沈阳市 中国电信IDC
240e:90c:2000:301::211			中国辽宁省沈阳市 中国电信IDC（持续攻击者）
240e:90c:2000:301::22b			中国辽宁省沈阳市 中国电信IDC
240e:90e:2000:2006::21c			中国辽宁省本溪市 中国电信IDC（持续攻击者）
240e:90e:2000:2006::213			中国辽宁省本溪市 中国电信IDC
240e:90e:2000:2006::216			中国辽宁省本溪市 中国电信IDC（持续攻击者）
240e:90e:2000:2006::207
240e:90c:2000:301::223
240e:90c:2000:301::218
240e:90e:2000:2006::210
240e:90c:2000:301::22a
240e:90c:2000:301::229
240e:90e:2000:2006::205
240e:90e:2000:2006::21e
240e:90c:2000:301::21f
240e:90c:2000:301::224
240e:90e:2000:2006::208
240e:90e:2000:2006::217
240e:90c:2000:301::221
240e:90c:2000:301::21e
240e:90e:2000:2006::204
240e:90e:2000:2006::21d
240e:90c:2000:301::213
240e:90e:2000:2006::21a
240e:90e:2000:2006::206
240e:90c:2000:301::222
240e:90e:2000:2006::211
240e:90c:2000:301::226
240e:90e:2000:2006::203
240e:90c:2000:301::210
240e:90c:2000:301::220
240e:90c:2000:301::22c

2408:8631:2e09:d05::22e			中国辽宁省 中国联通政企专线（持续攻击者）
2408:8631:2e09:d05::233		中国 辽宁省 中国联通 政企专线
2408:8738:6000:d::10			中国黑龙江省大庆市 中国联通IDC（持续攻击者）
2408:8738:6000:d::12
2408:8738:6000:d::11
2408:8738:6000:d::1b
2408:8738:6000:d::1a
2408:8738:6000:d::17
2408:8738:6000:d::1c
2408:8738:6000:d::19
2408:8738:6000:d::15
2408:8738:6000:d::14

//持续攻击者统计
240e:90e:2000:2006::/112		中国 辽宁省 本溪市 中国电信 IDC
240e:90c:2000:301::/112			中国 辽宁省 沈阳市 中国电信 IDC
2408:8738:6000:d::/112			中国 黑龙江省 大庆市 中国联通 IDC
240e:918:8008:1::/112			中国 内蒙古区 呼和浩特市 中国电信 IDC
240e:918:8008:2::/112			中国 内蒙古区 呼和浩特市 中国电信 IDC
240e:918:8008:3::/112			中国 内蒙古区 呼和浩特市 中国电信 IDC
240e:918:8008:4::/112			中国 内蒙古区 呼和浩特市 中国电信 IDC
240e:918:8008:5::/112			中国 内蒙古区 呼和浩特市 中国电信 IDC

@JockeyWang
@karuboniru
这些IPV6地址从 2024年02月07日 18:17:03 开始就对我的tracker：http://ipv6.rer.lol:6969/announce
进行持续ipv6 syn/rst攻击 流量大且持续 远超正常流量 几十倍之多
分析要么对方的IP是伪造的 要么就是客户端BUG
没有一个IP是能ping通的……流量可能1M/s

[y0umu]

If it is intended then this IS cyberwar.

[lirener]

new ip

240e:918:8008:2::226
240e:918:8008:3::222

[ours1505]

I think that is because it is a nat user or firewall?

[brepublic]

如果是离线下载的话，不应该无限下载啊 发件人: ***@***.*** ***@***.***> 代表 qwqcwcawa 发送时间: 2024年5月13日 上午 12:53 收件人: anacrolix/torrent ***@***.***> 抄送: brepublic ***@***.***>; Manual ***@***.***> 主题: Re: [anacrolix/torrent] qBitTorrent users seeing infinite requests from peers in 1.180.24.0/23, 36.102.218.0/24 and 221.203.6.0/24 (Discussion #891) 123盘怎么可能用家宽搞这玩意 2024-05-13-00-45-59-268.jpg (view on web) <https://github.com/anacrolix/torrent/assets/156668576/c5c68d5d-3bcf-4524-9eba-f8867507f384> <#891?sort=old#discussioncomment-8793293> 链接 — Reply to this email directly, view it on GitHub <#891 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/A35HVAYLEY7JVTOAIEWZLRTZB6M6TAVCNFSM6AAAAABB37XYFGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TIMBXGY3TE> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/A35HVA6KFM25R3T2DYU6OQLZB6M6TA5CNFSM6AAAAABB37XYFGWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAR6GLQ.gif> Message ID: ***@***.*** ***@***.***> >

[qwqcwcawa]

不知道123盘搞的什么操作
后面有人用123盘的离线下载试了它离线下载公布的peerid是GT0003 链接
HP0001/DT0001都能发现和GT0003相同网段的
也可能是明赋云搞的，当时我还翻了一下17777端口的网络日志发现个明赋云的域名，而明赋云和123盘是一家的(数据来源于爱企查)

[Ghost-chu]

因为他们就是为此而生的，利用BT网络免费的带宽，消耗自己的流量，以达成某种目的。&nbsp; 2908803755 ***@***.*** &nbsp;

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: ***@***.***&gt;; 发送时间: 2024年6月2日(星期天) 晚上11:08 收件人: ***@***.***&gt;; 抄送: ***@***.***&gt;; ***@***.***&gt;; 主题: Re: [anacrolix/torrent] qBitTorrent users seeing infinite requests from peers in 1.180.24.0/23, 36.102.218.0/24 and 221.203.6.0/24 (Discussion #891) 很好奇，为什么这些魔改客户端比正常客户端还吸流量？整得别的客户端浏览器被抢光 &mdash; Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***&gt;

[SaharaMiyoko]

不是,nyaa的老种也有人吸？各位可以自己试试
https://nyaa.si/view/1631859

[oodzchen]

据我的经验，它们不在乎是什么种子，只要文件体积够大，比如5GB以上的，就容易被吸，小体积的文件反而不怎么吸

[SaharaMiyoko]

据我的经验，它们不在乎是什么种子，只要文件体积够大，比如5GB以上的，就容易被吸，小体积的文件反而不怎么吸

重点是这个种子就一两个人（包括我）做种啊。。。太抽象了

[Hasnothing]

我去，内蒙人，我说最近为啥下载速度变慢了

[wenwenwenzq]

可能不是内蒙人，但我知道内蒙古那边的机房网络相比国内比较便宜的镇江机房网络还便宜得多

[qwqcwcawa]

在qbee的peers.db文件看到了新的客户端
xm/torrent/
-XM0001-
和以前的DT HP一样的ip
peer_blacklist.txt 这是qbee用的客户端黑名单
使用方法 c0re100/qBittorrent-Enhanced-Edition#528

[shionryuu]

2024/8/3 17:51 - 'peer_blacklist.txt': invalid client name matching expression 'github.com/anacrolix/torrent\s\(devel\)\s\(anacrolix/torrent\sunknown\' detected at line 7, ignoring rule

过滤规则有问题

[qwqcwcawa]

2024/8/3 17:51 - 'peer_blacklist.txt': invalid client name matching expression 'github.com/anacrolix/torrent\s\(devel\)\s\(anacrolix/torrent\sunknown\' detected at line 7, ignoring rule

过滤规则有问题

少打了个)，换了新的peer_blacklist.txt

[wenwenwenzq]

最新的qbclientblocker已经包含了该正则表达式，建议去那复制

[wenwenwenzq]

帮我告知一下写doc的作者，这个IP漏写了后缀，导致qb打开会卡死
https://docs.qq.com/doc/DQmpBZmNMRFpiZUhZ
第356行219.129.195.0-219.129.255
正确应该是219.129.195.0-219.129.255.255
这个问题从6月就已经出现了，但作者应该是忘了用qb去验证一下IP清单可用性

[scientificworld]

58.216.0.0/16 ABC 2.63.1
Really scary.

[scientificworld]

看了一下这似乎是 AS140293 常州电信 5G 网络的 IP？所以这是拿流量在刷？这么有钱的吗

[wu67]

58.216.63.0/24 这个我也遇到了. 没刷动我流量, 看起来跟我的aria2客户端没有握手成功, 但是一直在疯狂连接.

[kLiHz]

看了一下这似乎是 AS140293 常州电信 5G 网络的 IP？所以这是拿流量在刷？这么有钱的吗

看到其他帖子里提到的，大概是说，能够修改开源客户端，并且持有成段的 IPv4，个人基本做不到，所以可以合理猜测，能动用如此的资源，至少是运营商或者某些大公司的手笔。

[GalaxySnail]

看到其他帖子里提到的

请问有帖子链接吗？

[Gloryandel]

似乎不仅 BT 受到波及，Web 服务器也照刷 PCDN 不误。

蓝点网：与其他站长讨论后蓝点网猜测这些刷量 IP 段可能是来自 PCDN 运营者，这些人为了避免出现大量的上传而下载量较低估计刷量将下载量与上传量平衡用来躲避运营商的检测。 by 蓝点网

[lyzzlszh]

Here are some IPs, which put infinite requests, occupied too many bandwidth but refuse upload.
To used the list,you need Create a new .txt document，then Copy the below list into the .txt, and Change the File extension from .txt to .dat .After that,you can References the .dat in QB setting.
这里列出了部分吸血ip。你只需要新建一个文本文档（.txt），把以下内容复制进去，再把后缀改成dat，然后在你的下载工具（比如QB）里引用就可以了。
Here's the discussions (相关讨论) :
##891
And that's the list address page（更新的列表一）:
#https://docs.qq.com/doc/DQnJBTGJjSFZBR2JW
Another list page (also updated regularly)（更新的列表二）:
#https://github.com/PBH-BTN/BTN-Collected-Rules/tree/main/combine

#c0re100/qBittorrent-Enhanced-Edition#582

[lyzzlszh]

可以配合这个程序（PeerBanHelper）封禁IP。You can use this program (PeerBanHelper) to block IP too.
#https://github.com/PBH-BTN/PeerBanHelper/releases

这里是帮助文档，以及win版本的部署说明。
Here is the help document and the deployment instructions for the win version.
#https://pbh-btn.github.io/pbh-docs/docs/category/%E5%AE%89%E8%A3%85%E9%83%A8%E7%BD%B2/
#https://pbh-btn.github.io/pbh-docs/docs/downloader/qBittorrent

[faltonico]

There is a very simple way to prevent this leeching and not having to rely on complex peer block list or IP bans or client bans...
And it doesn't have to involve a change in the protocol either.

The fix could be completely on the client side.
What the client needs to do is to verify that the completion percentage at least corresponds to what my client has sent to the peer asking for the packages.
eg. If i have sent a leech the equivalent of 1% of the total size of the torrent, his client can't say he is still at 0%. Given that it is unlikely that i would lose that much data it is more likely that the client is lying and it should be automatically blocked.
Our client can to this check several times, preferably at random so the leech can't adapt to that new condition, but not constantly to save some resources.
The leech would have to be constantly increasing the % to the point it will eventually reach 100 and our client should stop even if it continues to ask for more pieces.

I have no idea how to do this tough as i am not a coder, but the client already collects all the necessary data and it should be fairly easy to do the math.

[anacrolix]

It's still spoofable. The best thing you could do is not send the same piece twice to the same peer.

[faltonico]

@Ghost-chu You change the protocol and you need to convince every other client to use your new protocol "bittorrent 2.0", that it is not a quick solution.
And @anacrolix you mean what i suggested? Our local client is tracking how much data we have sent, The cheating client can ask for the same piece a million times, it will probably say that it has received less than we have sent him, but our client could decide if it is lying by virtue of the discrepancy between what it is reporting and what we have sent it. That is basically what i am doing right now but manually, and that is a pain in the ass.
And fixing this should be paramount, both the name of the clients and their nationality are being spoofed now. We can't rely on good people to do the good thing anymore, this is a threat to the whole essence of bittorrent.

[anacrolix]

@faltonico are you using a torrent client that uses anacrolix/torrent under the hood?

[Simple-Tracker]

A simple solution is that users can configure the maximum ratio rate/maximum traffic size (IP-Torrent) and total traffic size (IP) in the BT client to suppress (but not eliminate) abuse. This will increase the complexity.

Most fundamentally, ISPs should improve their judgment algorithms to avoid the effectiveness of such behavior.

This phenomenon does not only affect the BT community. It is disappointing that it has not been solved at the root cause for nearly 6 months.

[anacrolix]

As a client author it's a fairly simple fix. There are data structures that could help reduce the storage cost to implement it efficiently.

However it only helps people running the fixed clients. You can't fix other people's clients.

As it is it's worth pointing out that a lot of the seeding abuse going on is because my client implementation is so easy to modify to use it as the aggressor in this situation. That can't be fixed

[wenwenwenzq]

目前发现 -LT2070- 有很大一部分是迅雷离线，各位可以考虑屏蔽该客户端，虽然该客户端会汇报下载进度但是不会给其他用户上传，涉及IP大多都来自一个地区，绝大部分来自江苏省（三大运营商都有），有一部分是浙江

[synodriver]

Okey, now we got random peer id……

[LaoshuBaby]

Recently noticed with a series client "Gopeed dev" and always keep 0.0% even sent to them GBs traffic, maybe another kind of traffic consumer

[Avamander]

I've noticed these peers using either Transmission 3.00 or -RN0.0.0.

Here's a list of peers I've recently seen abusing Ubuntu torrents: abuse.txt

[wenwenwenzq]

1、发现一个奇怪的客户端，奇怪的是这个用户还挂着迅雷5下同一个资源
HitomiDownloader/4.2 (libtorrent 0.1.0)，-LT0100-

2、还有一个远古的BT客户端，-TR2840-

3、A2-1-34-，aria2，国内大部分网站下载的aria2，预配置文件都是吸血配置，所以建议屏蔽该客户端

[wenwenwenzq]

[xfl12345]

你可以考虑使用评论的 edit 功能，避免发邮件通知骚扰该主题的订阅用户，谢谢。😊

[wenwenwenzq]

你可以考虑使用评论的 edit 功能，避免发邮件通知骚扰该主题的订阅用户，谢谢。😊

问题是你没有评论过该主题，为什么会收到评论提醒的邮件？

[xfl12345]

你可以考虑使用评论的 edit 功能，避免发邮件通知骚扰该主题的订阅用户，谢谢。😊

问题是你没有评论过该主题，为什么会收到评论提醒的邮件？

被折叠了
#891 (comment)

[Ghost-chu]

你可以考虑使用评论的 edit 功能，避免发邮件通知骚扰该主题的订阅用户，谢谢。😊

问题是你没有评论过该主题，为什么会收到评论提醒的邮件？

天哪，请停下。我的邮箱里被灌满了邮件！麻烦使用编辑功能。
就算你没有回复也可以选择订阅讨论，你也一样能收到评论提醒的邮件。

让我们停下，善用编辑功能！