View Full Version : Fix for tracker.openbittorrent.com
If you download public torrents, you're very likely to be familiar with OpenBitTorrent. It's among the most popular open trackers, and for stuff older than a few years, often the only one still online. However, as of a few months ago, it has been plagued with chronic downtime and timeouts. The reason is that while their hostname has 7 A records, only 3 of those are actually operational.
Fortunately, there's an easy fix for this. Open the hosts file for your system and append one of the following lines (not all three, just one; pick any at random).
45.154.253.8 tracker.openbittorrent.com
45.154.253.9 tracker.openbittorrent.com
45.154.253.10 tracker.openbittorrent.com
Then flush the DNS cache or just wait long enough, and everything should work fine again. Note that if they ever switch addresses in the future, you will need to edit or remove the entry.
OpenBitTorrent is now mostly or completely non-functional on all of its IPs, making this fix useless. I looked for contact data to ask them what's going on, but found nothing.
DisasterSurvey
28.01.23, 16:05
OpenBitTorrent is now mostly or completely non-functional on all of its IPs, making this fix useless. I looked for contact data to ask them what's going on, but found nothing.
By a coincidence I was looking into the OpenBitTorrent situation today on my own and found this thread through Google.
It is indeed difficult to find any recent information about the OpenBitTorrent project and so we have to rely on sources from more than 8 years years ago.
The Wikipedia page for the OpenBitTorrent (https://en.wikipedia.org/w/index.php?title=OpenBitTorrent&oldid=1126369813) mentions speculations about the OBT being a side project of the people behind the ThePirateBay.
The suspicions are based on the following:
OpenBitTorrent has been suspected of being a part of, or a side project of, The Pirate Bay, because it was observed early on that both sites used the same trackers.[1] (https://torrentfreak.com/openbittorrent-tracker-muscles-in-on-the-old-pirate-bay-090705/#comment-576934) The OpenBitTorrent project has countered by stating that the sites merely shared a tracker cluster operated by DCP Networks and Fredrik Neij during a startup period (February through August 2009).
...
From 5 December to 30 December 2014, the OpenBitTorrent website and tracker was unreachable, this may have been linked to the arrest of Pirate Bay co-founder Fredrik Neij.[6] (https://torrentfreak.com/pirate-bay-founder-fredrik-neij-arrested-in-asia-141104/)
Using nslookup we can see that the domain "openbittorrent.com" points to the IP address: 198.251.84.144.
However, the tracker subdomain points to a different group of IP addresses:
$ nslookup tracker.openbittorrent.com
Non-authoritative answer:
Name: tracker.openbittorrent.com
Address: 45.154.253.6
Name: tracker.openbittorrent.com
Address: 45.154.253.7
Name: tracker.openbittorrent.com
Address: 45.154.253.8
Name: tracker.openbittorrent.com
Address: 45.154.253.9
Name: tracker.openbittorrent.com
Address: 45.154.253.10
Name: tracker.openbittorrent.com
Address: 45.154.253.4
Name: tracker.openbittorrent.com
Address: 45.154.253.5
Reverse DNS lookup for one of the above IP addresses returns the name of the hosting company:
45.154.253.5
tracker.openbittorrent.com
Svea Hosting AB, Sweden
The Swedish Companies Registration Office has the following info available about this company:
Link: https://foretagsinfo.bolagsverket.se/sok-foretagsinformation-web/foretag/5592468176/foretagsform/AB
Svea Hosting AB
559246-8176
Address: Box 8018, 163 08 SPÅNGA
Registered office: Stockholm kommun, Stockholms län
Type of business: Aktiebolag
Registered: 2020-03-09
The company has only one or two employees that are family-related (presumably a father and his son):
https://www.proff.se/foretag/svea-hosting-ab/sp%C3%A5nga/datacenters/2KHM028I5YDLG/
So, it seems like a newly established one-man company took over the hosting of the tracker server in 2020 and brought it back online after a prolonged downtime.
A network scan of the tracker's servers reveals that they're still online with other services running. It might be that the tracker server just crashed.
I pinged the Svea Hosting AB support and kindly asked them to let the owners know. Let's see if it comes back up any time soon! ;)
EDIT: As of 28/01/2023 22:45 the tracker seems to be working again:
https://www.sb-innovation.de/attachment.php?attachmentid=21445&d=1674938449 (https://www.sb-innovation.de/attachment.php?attachmentid=21445&d=1674938449)
:banana_2: :biggrin: :banana_2:
Great research work, thanks! I didn't think of contacting the host, but I'd have dismissed the idea, as they'd have likely told me it's not their direct responsibility and to message the site owner directly. In any case, your edit was encouraging, but I realized I needed a better way to test this than checking some torrents in my client. First, I appended this to my nmap-payloads file (newer versions may already include a probe, but I haven't updated from 7.70).
# BitTorrent UDP tracker
udp 6969,80
# Magic number
"\x00\x00\x04\x17\x27\x10\x19\x80"
# Action (0x0 = connect)
"\x00\x00\x00\x00"
# Transaction ID
"\x1e\xdf\xad\x18"
Then I did an Nmap UDP scan (port 53 was included purely as a control group, since nothing should be running there).
C:\>nmap -sU -Pn -n --resolve-all -vv -p 6969,80,53 -r -T2 --scan-delay 1 --version-intensity 0 --ttl 64 --noninteractive tracker.openbittorrent.com
Starting Nmap 7.70 ( https://nmap.org ) at 2023-01-28 20:47 SA Eastern Standard Time
Initiating UDP Scan at 20:47
Scanning 7 hosts [3 ports/host]
Discovered open port 80/udp on 45.154.253.10
Discovered open port 80/udp on 45.154.253.5
Discovered open port 80/udp on 45.154.253.7
Discovered open port 6969/udp on 45.154.253.5
Discovered open port 80/udp on 45.154.253.9
Discovered open port 6969/udp on 45.154.253.7
Discovered open port 6969/udp on 45.154.253.10
Discovered open port 80/udp on 45.154.253.8
Discovered open port 6969/udp on 45.154.253.9
Discovered open port 6969/udp on 45.154.253.8
Completed UDP Scan at 20:48, 21.83s elapsed (21 total ports)
Nmap scan report for tracker.openbittorrent.com (45.154.253.10)
Host is up, received user-set (0.25s latency).
Scanned at 2023-01-28 20:47:55 SA Eastern Standard Time for 16s
PORT STATE SERVICE REASON
53/udp closed domain port-unreach ttl 50
80/udp open http udp-response ttl 50
6969/udp open acmsoda udp-response ttl 50
Nmap scan report for tracker.openbittorrent.com (45.154.253.9)
Host is up, received user-set (0.25s latency).
Scanned at 2023-01-28 20:47:55 SA Eastern Standard Time for 19s
PORT STATE SERVICE REASON
53/udp closed domain port-unreach ttl 50
80/udp open http udp-response ttl 50
6969/udp open acmsoda udp-response ttl 50
Nmap scan report for tracker.openbittorrent.com (45.154.253.8)
Host is up, received user-set (0.25s latency).
Scanned at 2023-01-28 20:47:55 SA Eastern Standard Time for 21s
PORT STATE SERVICE REASON
53/udp closed domain port-unreach ttl 50
80/udp open http udp-response ttl 50
6969/udp open acmsoda udp-response ttl 50
Nmap scan report for tracker.openbittorrent.com (45.154.253.6)
Host is up, received user-set.
Scanned at 2023-01-28 20:47:55 SA Eastern Standard Time for 13s
PORT STATE SERVICE REASON
53/udp open|filtered domain no-response
80/udp open|filtered http no-response
6969/udp open|filtered acmsoda no-response
Nmap scan report for tracker.openbittorrent.com (45.154.253.4)
Host is up, received user-set.
Scanned at 2023-01-28 20:47:55 SA Eastern Standard Time for 21s
PORT STATE SERVICE REASON
53/udp open|filtered domain no-response
80/udp open|filtered http no-response
6969/udp open|filtered acmsoda no-response
Nmap scan report for tracker.openbittorrent.com (45.154.253.7)
Host is up, received user-set (0.26s latency).
Scanned at 2023-01-28 20:47:55 SA Eastern Standard Time for 16s
PORT STATE SERVICE REASON
53/udp open|filtered domain no-response
80/udp open http udp-response ttl 50
6969/udp open acmsoda udp-response ttl 50
Nmap scan report for tracker.openbittorrent.com (45.154.253.5)
Host is up, received user-set (0.26s latency).
Scanned at 2023-01-28 20:47:55 SA Eastern Standard Time for 15s
PORT STATE SERVICE REASON
53/udp open|filtered domain no-response
80/udp open http udp-response ttl 50
6969/udp open acmsoda udp-response ttl 50
Read data files from:
Nmap done: 7 IP addresses (7 hosts up) scanned in 22.27 seconds
Raw packets sent: 30 (1.272KB) | Rcvd: 14 (712B)
Note how the IPs that end in 6 and 4 are completely unresponsive; scanning them individually resulted in this...
C:\>nmap -sU -Pn -n -vv -p 6969,80 -r -T2 --scan-delay 1 --max-retries 10 --version-intensity 0 --ttl 64 --noninteractive 45.154.253.6 45.154.253.4
Starting Nmap 7.70 ( https://nmap.org ) at 2023-01-28 20:51 SA Eastern Standard Time
Initiating UDP Scan at 20:51
Scanning 2 hosts [2 ports/host]
Completed UDP Scan at 20:51, 4.81s elapsed (4 total ports)
Nmap scan report for 45.154.253.6
Host is up, received user-set (0.25s latency).
Scanned at 2023-01-28 20:51:42 SA Eastern Standard Time for 3s
PORT STATE SERVICE REASON
80/udp closed http port-unreach ttl 50
6969/udp closed acmsoda port-unreach ttl 50
Nmap scan report for 45.154.253.4
Host is up, received user-set (0.27s latency).
Scanned at 2023-01-28 20:51:42 SA Eastern Standard Time for 5s
PORT STATE SERVICE REASON
80/udp open|filtered http no-response
6969/udp closed acmsoda port-unreach ttl 50
Read data files from:
Nmap done: 2 IP addresses (2 hosts up) scanned in 5.16 seconds
Raw packets sent: 5 (220B) | Rcvd: 3 (216B)
Meaning there's nothing listening on those ports as of this writing. The other addresses work consistently well, though, which is great news. Although I should note that going through months of downtime with the owners not taking any action or noticing at all is not very assuring...
DisasterSurvey
29.01.23, 15:49
Thanks anon!
I didn't think of contacting the host, but I'd have dismissed the idea, as they'd have likely told me it's not their direct responsibility and to message the site owner directly.
You are right. Usually I wouldn't expect this to work and even in this case I mostly relied on the good faith of the hosting provider. If it were a big company, then it would be most definitely met with the response you've expected. However, this provider is a bit special, because they only own 3 small /24 IPv4 ranges and host only 2 significant domains (one of those being OBT).
NETBLOCK
COMPANY
NUM OF IPS
193.239.232.0/24
Svea Hosting AB
256
195.96.151.0/24
Svea Hosting AB
256
45.154.253.0/24
Svea Hosting AB
256
And 2 IPv6 ranges:
NETBLOCK
COMPANY
2001:678:b30::/48
Svea Hosting AB
2a12:1e01::/32
Svea Hosting AB
Source: https://ipinfo.io/AS41634
Thanks for showing your verification process. I tried to use nmap to scan the servers, but I wasn't sure what kind of answer I should expect from a BitTorrent tracker on a UDP socket. I wasn't aware of the nmap-payloads and how it is being used. So, your reply was very helpful! :top:
I got the same results as you did (i.e. those two servers not responding on the port 6969).
Although I should note that going through months of downtime with the owners not taking any action or noticing at all is not very assuring...
It's a pity that such a popular tracker is not getting the attention it deserves. Nowadays, with more modern infrastructure tools it could be much easier to monitor such a service and keep it online 24/7. On the other hand, it's understandable that the people behind OBT most likely have other priorities in their lives these days.
Let's hope the tracker keeps running for a couple of years before we have to ping them again! :pfarrer: :D
Thanks for showing your verification process. I tried to use nmap to scan the servers, but I wasn't sure what kind of answer I should expect from a BitTorrent tracker on a UDP socket. I wasn't aware of the nmap-payloads and how it is being used. So, your reply was very helpful! :top:
The connectionless nature of UDP makes port scanning a complicated process. It's impossible to distinguish ports that are open but discarding incoming data, from those that are filtered, from those that are closed but for which the host didn't send the corresponding ICMP "destination port unreachable" message due to rate-limiting or firewall rules. Nmap tries to find UDP ports that do respond (assisted by the payloads file and version-intensity parameter you saw above) and makes assumptions about the rest; when no probe for a particular protocol is available, it'll send a zero-length packet.
I highly, completely recommend reading the Nmap book, which you can find at Z-Library. It will teach you a great deal not only about the program itself, but networking in general. The BEPs that define the UDP tracker protocol and its extensions are also in the public domain.
It's a pity that such a popular tracker is not getting the attention it deserves. Nowadays, with more modern infrastructure tools it could be much easier to monitor such a service and keep it online 24/7.
That was partly my point. The OpenBitTorrent announce URL is embedded on all magnet links from The Pirate Bay and many other indexers and aggregators, so it should be getting at least a few hundred million requests per day. Any monitoring system should notice those numbers dropping to near-zero, and anyone paying attention to it should have taken action months ago.
Anyway, I'll keep an eye on the .6 and .4 servers, but it seems I can now add one of the others to my hosts file =]
As of this writing, OpenBitTorrent is fully functional on all of its IPs, so there is no need to keep any hosts file entries anymore.
On a sidenote, it would be nice if the following became a CNAME for some tracker that is still operational =]
tracker.leechers-paradise.org
tracker.coppersurfer.tk
tracker.publicbt.com
tracker.ccc.de
tracker.istole.it
OpenBitTorrent has been down for around three weeks, anyone can confirm or have any information? This is pretty vexing, as I have many torrents over a decade old in my client, and by now they are/were the only tracker from that time still operational (there's still DHT, but it isn't 100% effective).
OpenBitTorrent has been down for around three weeks, anyone can confirm or have any information? This is pretty vexing, as I have many torrents over a decade old in my client, and by now they are/were the only tracker from that time still operational (there's still DHT, but it isn't 100% effective).
No news at all. Offline here as well
https://newtrackon.com
And understandably missing from https://github.com/ngosang/trackerslist. I'm not ready to remove it from my torrents just yet, though...
And understandably missing from https://github.com/ngosang/trackerslist. I'm not ready to remove it from my torrents just yet, though...
I always create torrents to share with ngosang list no matter what is in it. I might check for https sometimes because of friends blocked by their environments. That way never depending on single tracker and less likely to be unreliable. However, openbittorrent been down before for sometime then came back up. So time will tell what you can do from here. Just no idea how long that would be.
My suggestion though, silly one but humor me. I would add the other trackers in the list along with openbittorrent and leave all of them there. But for new torrents, just go with ngosang list.
ngosang is a good reference, but for new torrents I choose to stick to what I consider the Top 5 (until now at least) based on longevity, popularity and stability.
udp://tracker.openbittorrent.com:6969/announce
udp://exodus.desync.com:6969/announce
udp://open.stealth.si:80/announce
udp://tracker.torrent.eu.org:451/announce
udp://tracker.opentrackr.org:1337/announce
Other open trackers come and go, and you never know who's behind them or why (Cloudflare ran one on their 1.1.1.1 IP!). For old stuff, adding extra announce URLs only works if others add the same ones, but doing so is an oft-given piece of advice for reviving torrents and nothing can happen if I don't take the first step, so you have a good point.
For sharing with friends or small closed groups I recommend privtracker.com, that way you none of you leak anything to DHT crawlers and consequently the entire world.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.