Talk:Tracker Information

From Depthstrike Entertainment
Jump to: navigation, search

Your banning script seems to be banning current versions of the "preferred" clients sometimes. Also, could you specify more clearly the reason specific clients are banned?


There are 2 major types of tracker bans currently active on this tracker.

  1. Client Banning
  2. Port Blacklisting

If a client's version is permitted on the tracker, but the listen port configured is not, the tracker will reject it.

If a client is misidentifying itself (either accidentaly - see Tracker outstanding issues or on purpose - client spoofing, bad source code edits) the client ban may take effect even if it is a preferred version.

As for more detailed explainations. The majority of the older clients banned do not support the compact announce protocol. Because of this if they were permitted on the tracker they would be generating a MASSIVE bandwidth strain, preventing other peers from even being able to connect.

Abusive clients either misreport data or do other bad things like tracker hammering.

-- DWK


PS: We don't use a "script" per se, because the code that handles the banning is built into the tracker package we use.


Could you un-ban µTorrent? I really like this client, and none of the other trackers seem to have problems with it…

This is fixed in the latest version 1.1.6, see: http://forum.utorrent.com/viewtopic.php?p=8880


An unban of uTorrent is pending final review, tracker code updates, and contact of two of the tracker hosts.

--- DWK


Re: Random Ports, make's it have for users behind Nat router if we have to punch a new hole every time, any chance of a port range table? thanks. DR


  • You only need to do the port change once. Not every time you start a new download.
  • The changed ports will work on other trackers.

--- DWK

Random ports annoying for users without control of a router

The hassle of dealing with blacklisted ports for users behind a router, especially one that they do not have control over, is very large. I can still connect to peers and download, but my download speed ends up being somewhere around 10KB/sec, and due to the blacklist I cannot actually contribute anything in the way of seeding. Thus, users who cannot change ports due to NAT issues end up connecting anyway, download at a very low speed, but contribute absolutely nothing back to the cloud, which ruins the BitTorrent network.

Any portscanning by, for example, an ISP, should not be automatic grounds for banning from the service. BitTorrent looks like a web server to external scans, and unless someone has detailed knowledge of the protocol and actually sniffs data from each port, it is easy to argue that the computer is connecting with a web client, or is downloading, et cetera. It would certainly be easier for anyone looking to shut down your tracker to simply find the link through the web and going that route. As a tracker server, you also want to seal off as many incoming ports as possible, and so leaving random ports open is certainly not gong to protect you from security threats.

A client like Azureus asks for only one incoming TCP port, which means that I have to reconfigure it every time that I want to connect to this tracker (and then configure it again to connect to regular trackers).

End users generally like to open as few ports as possible. I do not want to open Port 1115 in addition to port 6883. Depending on the robustness of the random port generator, it may happen that the port listed is one that coincides with a trojan or similar unwanted server that the client has intentionally sealed off and does not wish to open.

The policy of port blacklisting does not offer either the end user or the tracker operator any benefits and should be revoked. Thank you.

Counterpoints

  • Thus, users who cannot change ports due to NAT issues end up connecting anyway, download at a very low speed, but contribute absolutely nothing back to the cloud, which ruins the BitTorrent network.

BitTornado's 'Why is being firewalled bad' states that just because people can't connect to you, you can't connect to others. It just means that, connection-wise, you're putting a strain on peers that are reachable.

  • A client like Azureus asks for only one incoming TCP port, which means that I have to reconfigure it every time that I want to connect to this tracker (and then configure it again to connect to regular trackers).

You don't need to change back to the traditional default port to connect to regular trackers. A port that works on a tracker that does blacklist listen ports will work on a tracker that does not. I have already mentioned this on this discussion page.

  • BitTorrent looks like a web server to external scans, and unless someone has detailed knowledge of the protocol and actually sniffs data from each port, it is easy to argue that the computer is connecting with a web client, or is downloading, et cetera

The BitTorrent peer protocol operates VERY specifically, especially the first bytes of the communication negotiation and can be identified differently from a webserver or other traditional download system. (BitTorrent Protocol Specification - See "Peer Wire Protocol" - "Handshake") I do admit that packetsniffing-based limiting would mean that speeds would be limited regardless of ports, making blacklisting meaningless, but not all ISPs can afford the hardware required to perform this sort of automatic speed limiting.

  • Depending on the robustness of the random port generator, it may happen that the port listed is one that coincides with a trojan or similar unwanted server that the client has intentionally sealed off and does not wish to open.

Whenever such an occurance has been reported to me, the random port generator linked from this site gets updated. Additionally, a simple refresh of the final stage page of the script will generate a different port if the user is uncomfortable with using that port.

  • The policy of port blacklisting does not offer either the end user or the tracker operator any benefits and should be revoked.

This may very well be true, hence the 1 calendar week review period.

--- DWK