rtorrent uses only IPv6

[lx30011]

My rtorrent installation by default only uses IPv6. Best case I would like to use IPv4 and IPv6. If that isn't possible, I would prefer only IPv4.

I compiled rtorrent with the --enable-ipv6 flag. lsof -i shows it's listening only on IPv6.

rtorrent  200159 user   14u  IPv6 2252171      0t0  TCP *:50000 (LISTEN)

And when downloading a popular torrent lsof -i again only shows IPv6 connections.

Is there a config option I have to set to make use of both IPv4 and IPv6?

Edit: I recompiled without --enable-ipv6 but it still defaults to IPv6.

[kannibalox]

Process only need to have one socket open in order to support IPv6 and IPv4 simultaneously. IPv6 reserves the ::ffff:0:0/96 block specifically to translate IPv4 requests when needed.

In some cases, even if an application has IPv6 disabled, it may open the socket in IPv6 mode for compatibility reasons. From the lsof manpage (emphasis mine):

TYPE       is the type of the node associated with the file - e.g., GDIR, GREG, VDIR, VREG, etc.
           or ``IPv4'' for an IPv4 socket;
           or ``IPv6'' for an open IPv6 network file - **even if its address is IPv4, mapped in an IPv6 address**;

Also, it doesn't look like that flag does anything (i.e. IPv6 features are always enabled) since this change: https://github.com/rakshasa/rtorrent/commit/0df0a6650dcd75653543a3f00a71f30293015392

If you want, you can double check this via socat or some other tool:

# IPv4
echo test | socat - TCP:127.0.0.1:50000
# IPv6
echo test | socat - TCP6:[::ffff:127.0.0.1]:50000

These commands won't do anything except show that the socket is connectable over both protocols.

[Antorell]

Sorry a bit late, but I'd like to add some info if you, or anyone else, who want to use IPV4 and IPV6 with rtorrent. There are issues with the current implantation of ipv6 in rtorrent. When it resolves dual stack IPV4/IPV6 tracker, rtorrent will always resolve the IPV6 and ignore the IPV4. If everyone had a dual stack IPV4/IPV6 it would be fine, but we're not there yet.

For HTTP tracker resolution, rtorrent use the CURL_IPRESOLVE_WHATEVER flag for curl, that will resolve to any ip that comes first. And on dual stack system resolving a tracker with an IPV4 and an IPV6 tied to it's domain name, DNS resolution will always prioritize the IPV6 over the IPV4. rtorrent will also never get anything anything IPV4 only from the tracker's pool of peer/seed.

https://github.com/rakshasa/rtorrent/blob/d067bd802e44f0e6a747aabcc311ada2175fd550/src/core/curl_get.cc#L95

Worse, rtorrent will retry to check for an IPV6 a second time https://github.com/rakshasa/rtorrent/blob/d067bd802e44f0e6a747aabcc311ada2175fd550/src/core/curl_get.cc#L118-L126

The only reason rtorrent get IPV4 and IPV6 peers when using public torrents with multiple trackers is because it scraped the pool of peer/seed from a tracker that only had an IPV4, and scrapped IPV6 pool of peer/seed from another that had dual stack IPV4 and IPV6, only connecting to its IPV6 address.

I had this issue recently with a private tracker that has dual stack IPV4/IPV6, rtorrent would always connect to the IPV6 of the tracker, get IPV6 peers/seeds that had and IPV4 and IPV6 and never get any peer/seed that only had an IPV4.

The same goes for the domain name resolution of UDP trackers in libtorrent. It uses PF_UNSPEC, which has the same behavior as CURL_IPRESOLVE_WHATEVER when resolving the domain name of a tracker with dual stack IPV4/IPV6.

[kannibalox]

I had this issue recently with a private tracker that has dual stack IPV4/IPV6, rtorrent would always connect to the IPV6 of the tracker, get IPV6 peers/seeds that had and IPV4 and IPV6 and never get any peer/seed that only had an IPV4.

Unless I'm misunderstanding, this sounds like a limitation of the tracker itself, not a problem in rTorrent. There's nothing stopping a tracker from returning IPv4-only peers to a IPv6 request. I assume the intention is that since the tracker in question can't actually know if the requester is dual-stack or IPv6-only, it's playing things safe.

[Antorell]

What I'm mentioning happens on every tracker that has an IPV4 and an IPV6 assigned to its domain. I'm mentioning the private tracker because it's the first time I noticed the issue and it's when I started digging.

Unless I'm misunderstanding, this sounds like a limitation of the tracker itself, not a problem in rTorrent. There's nothing stopping a tracker from returning IPv4-only peers to a IPv6 request. I assume the intention is that since the tracker in question can't actually know if the requester is dual-stack or IPv6-only, it's playing things safe.

Yes, trackers can't magically guess the IPV4 if the client doesn't let them know they also have an IPV4. Either rtorrent doesn't send an IPV4 address, normal or translated to IPV6, or it doesn't know what to do with what the tracker returns.

It can't be an issue with all the trackers I tried; I also tried with qBittorrent forcing it to only get peers from http tracker, I fed it a torrent with a single tracker that had an IPV4 and IPV6 and it connected without any issue to IPV4 and IPV6 peers. Rtorrent, for the same .torrent/tracker always connected to all the IPV6 ignoring peers that only have an IPV4. Even the pool of peer/seed is smaller with rtorrent when it only connects to IPV6 peers, or even compared to when I force rtorrent to only use IPV4. Either by recompiling rtorrent with CURL_IPRESOLVE_V4 instead of CURL_IPRESOLVE_WHATEVER or editing /ect/gai.conf to force IPV4 domain resolution to be first -> "precedence ::ffff:0:0/96 100"

[cwbsw]

@Antorell I think you misunderstand it. If you're using private tracker, rtorrent can get both ipv4 and ipv6 peers list from ipv6 only tracker, and can connect all these peers actively, but can not be connected by ipv4 peers. Because when you connect tracker by ipv6, your ipv4 public address will not be reported to tracker, even if you attach &ip query parameters to announce message, most trackers will just ignore it. To resolve this, both tracker and client should implement either older or newer version of bep_0007 correctly. It means, either client should connect tracker by ipv4 and attach &ipv6 to announce message, or client should connect tracker by both ipv4 and ipv6.

[Antorell]

If you're using private tracker, rtorrent can get both ipv4 and ipv6 peers list from ipv6 only tracker, and can connect all these peers actively, but can not be connected by ipv4 peers.

That's not how a torrent client is supposed to work, you're supposed be able to connect by both dual stack IPV4/IPV6 peers and IPV4 only peers, and single stack IPV4 and dual stack IPV4/IPV6 peers should be able to access your torrent client/server when IPV6 is enabled. Otherwise it defeats the purpose of using a torrent client/server. rtorrent is not a download client/manager where whichever IP you connect to download is fine.

~~And nope, you don't/rtorrent doesn't get any IPV4 from scrapping a tracker's IPV6. If you get anything IPV4, it's the IP of peers that are dual stack but I really doubt you get any of the IPV4 only peers. You can test it yourself, when IPV6 is enabled for the same given torrent and dual stack IPV4/IPV6 tracker the pool of peer/seed you get from the tracker you scrape is smaller than when you force rtorrent to only use IPV4.~~

Doesn't happen on all trackers/only seem to happen on some trackers. A torrent with forced IPV4 only: Same torrent IPV6 enabled, no forced IPV4:

When I mentioned about rtorrent not telling the tracker that it also had an IPV4, I didn't have bep_0007 "IP announce parameters" in mind. I was thinking about rtorrent not doing a second domain resolution and tracker scrape to show/plug its IPV4 to the pool of IP.

There are also obvious issues with the current implantation with CURL (or even socket.h PF_UNSPEC). CURL_IPRESOLVE_WHATEVER when doing a domain name resolution on a dual stack IPV4/IPV6 system, rtorrent will never resolve the tracker's IPV4 of a tracker that is also dual stack. Worse, it will do another forced domain name resolution to check if the domain also has an IPV6. Again? https://github.com/rakshasa/rtorrent/blob/d067bd802e44f0e6a747aabcc311ada2175fd550/src/core/curl_get.cc#L118-L126

There's a PR #648 to fix this issue, but that doesn't address the fact that rtorrent should be connectable by peers that are IPV4 only as well as peers that are dual IPV4/IPV6 when IPV6 is enabled. qBittorrent does that by spawning a listening server on an IPV4 and another on an IPV6, and it scrape trackers using both servers.

edit: clarifications.