Tracker itzmx fake peers report

[kiwixz]

These two trackers from the "best" list seems to fake the number of peers and seeds.

http://tracker3.itzmx.com:6961/announce
http://tracker1.itzmx.com:8080/announce

I noticed it on a low-traffic torrent I just uploaded.

[ngosang]

you are right. downgraded to the bottom of the list.
thank you!

[N46AN]

@kiwixz I'm not sure how you conclude that the peer number report is faked?

If you are referring to that the two itzmx trackers report the same number of peers, it is because all four itzmx trackers are synced which I have confirmed with itzmx maintainer.

If you are referring to that you cannot connect to those 12 peers reported by itzmx tracker, it is highly likely that those peers have poor connection between them and you.

@ngosang Please further investigate this issue if possible. Thanks!

[kiwixz]

• I uploaded the torrent the minute before taking the screenshot (the 2 seeders are actually my own machines).
• I hadn't yet published it on any website.
• It's a very niche torrent (so no reason for anybody to instantly download it).
• izmtx trackers are the only ones from the top 20 with so absurdly high peer counts.

All of this leads me believe the peers count is fake, whether or not intentional.

[N46AN]

@kiwixz Is this reproducible?

I tested with a few dummy torrent and had not been able to reproduce this. In my test cases the itzmx tracker always report peer number to be 2, which is myself. Here is a screenshot:

https://img.vim-cn.com/e2/178a47d6c6940a7f0058e466fae2f6523b1702.png

I've contacted itzmx site owner and maintainer and talked about this issue. Their respond was that itzmx tracker did have some special tuning regarding heavily NATed environment in some region, but should not create false peer report in any way.

Thanks for responding! If it is a reproducible issue I'll present it to itzmx maintainer.

[kiwixz]

It looks like the problem is specific to tracker 1 and 3 (4 seems fine, 2 is down).

Restarting the client will add one more peer to the list the tracker returns. Just forcing reannounce seems fine.
I tried to see the list manually with some example torrent:
http://tracker1.itzmx.com:8080/announce?info_hash=%eey%8di%80%b4N%93%ca%ac%e8%aa%c5%3e%ff4%7f0%94%a5&peer_id=aaaaaaaaaaaaaaaaaaaa

A GET request on this link can actually add one duplicate peer, but not always.

At time of writing, it returns:

d8:completei6e10:downloadedi0e10:incompletei13e8:intervali1833e12:min intervali916e5:peers114:l¢åÂ��l¢åæ���eX€��¬Dæ���¬Dæ���¬Dæ���¬Dæ���¬Dæ ��¬Dæ8��¬Dæ>��¬DæV��¬Dæb��¬Dæh��°�hÔê`¬E6Íê`¬Dænê`¬Dæhê`¬DæPê`¬Dæ��áe

Which decodes to:

{
   "complete": 6,
   "downloaded": 0,
   "incomplete": 13,
   "interval": 1833,
   "min interval": 916,
   "peers": "<hex>6C A2 E5 C2 00 00 6C A2 E5 E6 00 00 8D 65 58 80 00 00 AC 44 E6 08 00 00 AC 44 E6 0E 00 00 AC 44 E6 14 00 00 AC 44 E6 1A 00 00 AC 44 E6 20 00 00 AC 44 E6 38 00 00 AC 44 E6 3E 00 00 AC 44 E6 56 00 00 AC 44 E6 62 00 00 AC 44 E6 68 00 00 B0 1F 68 D4 EA 60 AC 45 36 CD EA 60 AC 44 E6 6E EA 60 AC 44 E6 68 EA 60 AC 44 E6 50 EA 60 AC 44 E6 08 1A E1</hex>"
}

So peers are:

108.162.229.194:0
108.162.229.230:0
141.101.88.128:0
172.68.230.8:0
172.68.230.14:0
172.68.230.20:0
172.68.230.26:0
172.68.230.32:0
172.68.230.56:0
172.68.230.62:0
172.68.230.86:0
172.68.230.98:0
172.68.230.104:0
__me__  :60000
172.69.54.205:60000
172.68.230.110:60000
172.68.230.104:60000
172.68.230.80:60000
172.68.230.8:6881

So I guess there is a nasty bug somewhere. Good luck !

[N46AN]

Thank you very much for taking time to produce a detailed test result! It does look very helpful. I'll talk to itzmx site maintainer about this and hopefully resolve the issue.

Thanks again!

[N46AN]

@kiwixz
The itzmx maintainers have responded to the issue. To make it convenient I'll just google translate the response. Hope it make sense.

@ngosang Please read the below response from the itzmx maintainer and consider moving the itzmx trackers back. According to the explaination from maintainer those extra peers that may appear in some test cases would not have any negative effect. Thanks!

Date: 18 Jun 2019, 19:11

172.68.*.* These are the IP addresses from the cloudflare CDN node. This is a known issue, but in order to solve the connectivity problem, this problem cannot be easily solved.

The problem with Opentracker is that it does not support cloudflare cdn to pass ip address. Extra cdn layer is for some people who can not connect to make a direct connection, after data synchronization, you can normally get the ip address of other nodes for peer connection.

These are not fake IPs. For example, if the client fails to connect to this ip, it will automatically make a refusal timeout wait state.

Logically speaking, this is beneficial to solve a network connection problem, because the server is not in China, there may be a connectivity problem with some nodes, this may help to solve some tracker not working timeout access connection problem.

The OSS repository of this program: https://erdgeist.org/arts/software/opentracker/

I have contacted the original author mail: erdgeist@erdgeist.org

I contacted the author last year and did not get a solution reply.

The only reply from opentracker maintainer is "If proxy sets the HTTP_X_FORWARDED_FOR header, this ip is used instead of the originating IP. Just tested it here."

Of course, Opentracker is an open source project. If someone can afford to submit code, they can submit it on my github.

[kiwixz]

@N46AN opentracker seems to effectively support CDNs (see here). Are you sure to pass -DWANT_IP_FROM_PROXY when compiling it ?

While I understand the negative effects are pretty limited, I still think no tracker should report IPs of invalid peers.

[ngosang]

@N46AN looks like @theel0ja is running a tracker with Opentracker and Cloudflare. #174

[ngosang]

@N46AN I changed the penalty for itzmx. Instead of moving to the bottom, I'm removing 10 seeds and 10 leechers before calculating the scoring.

[theel0ja]

@N46AN looks like @theel0ja is running a tracker with Opentracker and Cloudflare. #174

I'm not using Cloudflare, but I am using Nginx as proxy for the HTTP/HTTPS.

All configuration (nginx, systemd, diff, etc.) can be found from: https://lelux.fi/tracker/conf/

The differences I made to the opentracker repository:

$ curl https://lelux.fi/tracker/conf/proxy.diff
diff --git a/Makefile b/Makefile
index da2c8f1..7d4148e 100644
--- a/Makefile
+++ b/Makefile
@@ -30,7 +30,7 @@ BINDIR?=$(PREFIX)/bin
 #FEATURES+=-DWANT_COMPRESSION_GZIP_ALWAYS
 #FEATURES+=-DWANT_LOG_NETWORKS
 #FEATURES+=-DWANT_RESTRICT_STATS
-#FEATURES+=-DWANT_IP_FROM_PROXY
+FEATURES+=-DWANT_IP_FROM_PROXY
 #FEATURES+=-DWANT_FULLLOG_NETWORKS
 #FEATURES+=-DWANT_LOG_NUMWANT
 #FEATURES+=-DWANT_MODEST_FULLSCRAPES

(Just enabling DWANT_IP_FROM_PROXY in `Makefile)

However, @nwps is running his tracker with Cloudflare.

(of his trackers, http://torrent.nwps.ws/announce is on Cloudflare, while IPv6-only udp://bigfoot1942.sektori.org:6969/announce is on Hetzner)