trackerslist
trackerslist copied to clipboard
ngosang
IPv6 trackers
Could a IPv6 list be added also ? There are a few trackers that support IPv6 only as far as i am aware.
Are you not willing to set up a v6 tunnel on your server, or is there some other limitation?
Over 20% of the connections to Google services are via IPv6. This percentage doesn't even include the large number of users who have limited v6 connectivity (eg Teredo) -- because browsers prefer v4 over Teredo, whereas BT clients will still gladly use Teredo if it's enabled on their system.
Even though basically everyone still has v4 connectivity, v6 trackers are extremely beneficial, especially for clients who don't have proper v4 port-forwarding. Someone behind a NAT can often still use Teredo and receive direct incoming connections, giving a healthier peer swarm.
So yeah, I hope you can take v6 into more consideration. Thanks for your time.
I can set up the tunnel but I don't know any IPv6 tracker. @HarryS @JanPokorny @xiuluo do you have any?
I have IPv6 available on my VPS, but i haven't enabled it on the server side. I will make a issue when i do enable it.
This should be ipv6 only, haven't tested: http://tracker.ipv6tracker.ru/announce
Sounds cool! Here's mine: udp://ipv6.tracker.harry.lu:80/announce http://ipv6.tracker.harry.lu:80/announce
(udp is preferred, but you can add both to the list)
udp://IPv6.open-internet.nl:6969/announce
Heres is another one from leechers-paradise/eddie4 that supports IPv6
yeah, gbitt.info handles IPv4 only. OpenTracker has no IPv6 support yet, but if anybody knows a IPv6 supported OpenTracker, would be appreciated. Otherwise I need to fork it and hack a IPv6 support to it.
Open sourcing the update bot could help people add IPv6 support.
@theel0ja I made this project because all list I found in Google were outdated. Publishing the source code will lead to more abandoned forks and more outdated lists. I will keep updating the list and, if I can't at some point, I will release the source code.
@ngosang Outdated lists can be created pretty easily now, just copy the current list 😄 Also, look at how many project are on GitHub and how many of them are seriously hurt by "abandoned forks" (only ones I know of are illegal ones like Popcorn Time)
@ngosang I'd be willing to reverse engineer the bot and then add IPv6 compatibility. (work started at https://github.com/mikaeldui/TrackerListBot)
If you want somewhere to submit your IPv6 tracker in the meantime https://newtrackon.com/ supports it.
Outdated lists can be created pretty easily now, just copy the current list
Saw many posts around the internet doing that, sadly.
Sorry, the server running the bot doesn't have IPv6 connectivity.
You may be able to use GitHub Action?
I am currently coding on a tracker made in GoLang, and is functioning optimal. For now it will be coded for purely AniRena.com and it has a nice GUI to it. Eventually, when it's finished, I will make a pure public version of it.
It has now IPv4 and IPv6 support for TCP, compact and non-compact mode. UDP will be added later.
@Power2All this is not the place. We only list public trackers, not software.
You may be able to use GitHub Action?
Maybe, but I will lose the control about the DNS blocks, latency... I will implement this in the future, by now I think all trackers but 3 or 4 have dual IP stack. Using the IPv4 list in a IPv6 only client will be still very useful.
yeah, gbitt.info handles IPv4 only. OpenTracker has no IPv6 support yet, but if anybody knows a IPv6 supported OpenTracker, would be appreciated. Otherwise I need to fork it and hack a IPv6 support to it.
I didn’t see anyone contradict this, so I’m doing it.
OpenTracker support IPv6 since a long time ago (before 2018 at least, the first time I checked), but you have to rebuild it from source (with a flag, as explained here), and it’ll be IPv6 only. On my tracker I run two OpenTracker daemons, one IPv4 only and one IPv6 only, on the same computer and same port. For now it seems to works as intented with this setup.
yeah, gbitt.info handles IPv4 only. OpenTracker has no IPv6 support yet, but if anybody knows a IPv6 supported OpenTracker, would be appreciated. Otherwise I need to fork it and hack a IPv6 support to it.
I didn’t see anyone contradict this, so I’m doing it.
OpenTracker support IPv6 since a long time ago (before 2018 at least, the first time I checked), but you have to rebuild it from source (with a flag, as explained here), and it’ll be IPv6 only. On my tracker I run two OpenTracker daemons, one IPv4 only and one IPv6 only, on the same computer and same port. For now it seems to works as intented with this setup.
This is a old thread, I've already switched to my own GO app. OpenTracker does support IPv6 only on TCP, not UDP. My code does support IPv6 with UDP.
I’ve set qBittorrent to only use IPv6 (and even set the tracker with it’s IP instead of domain to be sure) and it seems to work on UDP (all trackers without IPv6 support are marked as "Not working"). If you have better way to check it, I can try it.
"En fonction" mean Working in french: https://fichiers.breizh.pm/Images/Screenshots/2021-05-09-023732_1150x30_scrot.png
Open sourcing the update bot could help people add IPv6 support.
@theel0ja I made this project because all list I found in Google were outdated. Publishing the source code will lead to more abandoned forks and more outdated lists. I will keep updating the list and, if I can't at some point, I will release the source code.
Isn't your project the most starred? People don't automatically resort to using forks. They use what's the most popular. I suggest getting over your fear of forks so IPv6 connectivity finally makes it into your project.
Open sourcing the update bot could help people add IPv6 support.
@theel0ja I made this project because all list I found in Google were outdated. Publishing the source code will lead to more abandoned forks and more outdated lists. I will keep updating the list and, if I can't at some point, I will release the source code.
Isn't your project the most starred? People don't automatically resort to using forks. They use what's the most popular. I suggest getting over your fear of forks so IPv6 connectivity finally makes it into your project.
Agree. GH may be complicated, but even then it's easy enough to find an active fork even if it's a long tree of forks.
Isn't your project the most starred? People don't automatically resort to using forks. They use what's the most popular. I suggest getting over your fear of forks so IPv6 connectivity finally makes it into your project.
I'm not afraid, that is not the reason. I spent several hours a day working in open source projects for free, you can take a look at my profile.
This project has become "de facto" standard for public trackers. It's used by qBittorrent, Jackett, *arr stack and several huge public Bittorrent sites because they know me and they trust me. If any of the trackers in the list is compromised it will be a big security risk because they can track your IP and the torrents you are downloading. That could happen, of course, but I will be notified and I will take actions. They also need a reliable list of trackers to keep the Bittorrent swarm alive as long as possible. Those are other reasons to avoid fragmentation, forks, copycats...
The source code is just 200 lines of Python code. Publishing the source code is not going to fix the IPv6 issue in this fork. The value of this project is my hardware and the CI/CD stack that updates the list every day since 6 years ago. I want to add this feature but my ISP does not provide IPv6 connectivity. I have to deal with tunnels, Docker networks and improvements in the code to not mix IPv6 and IPv4 trackers. Is not that hard but the "big projects" using this project can't use IPv6 lists and the priority is low.
Any of you could tell me if the IPv4 ALL list is working in a IPv6 network? Which trackers are not working? What will be the proposal to include IPv6 trackers? Just a new list with IPv6 trackers? I can't mix IPv6 trackers in the current lists.
Wouldn't it not be better to convert the Python code over to GO? It's much more performant, build-in libraries are easier in use then in Python. Has full IPv6 support out of the box, and supports TCP/UDP connectivity. Currently I'm almost done with my Announce server that uses both TCP and UDP, in IPv4 and IPv6 modus. Just currently properly coding the structs in combination with compression (gzip) for less memory usage, but still optimal speed.
Wouldn't it not be better to convert the Python code over to GO? It's much more performant, build-in libraries are easier in use then in Python. Has full IPv6 support out of the box, and supports TCP/UDP connectivity. Currently I'm almost done with my Announce server that uses both TCP and UDP, in IPv4 and IPv6 modus. Just currently properly coding the structs in combination with compression (gzip) for less memory usage, but still optimal speed.
There couldn't possibly be any benefit converting it, and that's not even counting having to learn a weird new language.
There couldn't possibly be any benefit converting it
Didn't I mention performance-wise as a benefit ? Not to mention better threading and memory consumption ?
and that's not even counting having to learn a weird new language.
I've done it, so can you and anybody else. The language isn't that much different comparing it towards C, PHP and even Python though. In fact, it's even much more readable then Python by a long shot...
The whole point is the extra performance couldn't possibly be useful for the software in question.
The whole point is the extra performance couldn't possibly be useful for the software in question.
Actually, it does. When you have a app that does it's work in a hour, and most of the time it's busy parsing, but if you can speed up the parsing of all the data that is gathered (at that point, the connection is the slowest part of the process, so why not first deal with the access to all the connections one by one, gathering the data, and then parse it), and then generate the output data, there would be a huge speed improvement. I know where you're getting at, but that's a pointless discussion, as any performance improvement, is a improvement. It would be even better when your code is even more readable, so that you could work simpler in the future on your code.
I've improved the same exact parsing method for someone else, that did it in a hour, by connecting each loop to a URL, parsing it, and so on, by just first connecting to all the needed URL's, gathering the data, and after that parsing it. Went from a hour of work, to just over 20 minutes...