Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key parameter in the requests differs when it should be the same #11858

Open
Ovsyanka opened this issue Jan 10, 2020 · 8 comments
Open

Key parameter in the requests differs when it should be the same #11858

Ovsyanka opened this issue Jan 10, 2020 · 8 comments

Comments

@Ovsyanka
Copy link

@Ovsyanka Ovsyanka commented Jan 10, 2020

qBittorrent version and Operating System

arch linux,
qBittorrent 4.2.1

If on linux, libtorrent-rasterbar and Qt version

libtorrent-rasterbar 1:1.2.3-1
qt5-base 5.14.0-1

What is the problem

On some trackers the download counted twice. I dug into the problem and studied out that when both ipv4 and ipv6 is enabled and tracker has both addresses qbittorrent sends duplicated requests to each of these addresses. But the 'key' parameter of these requests is differed (see example below).

I think this cause miscalculation of the downloaded (possibly uploaded too) value on some trackers.

What is the expected behavior

The 'key' parameter is equal in requests that contain the same information.

Steps to reproduce

  1. Enable listening on ipv6 and ipv4 in qbittorrent.
  2. Start downloading torrent from tracker with host name that has both ipv6 and ipv4 addresses.
  3. Sniff requests for that tracker
  4. Stop downloading torrent
  5. See that there is different key parameter in the 'event = stopped' requests.

Extra info(if any)

Argument


BEP 7 (IPv6 Tracker Extension)
says:

When host component of a tracker url resolves to multiple IP addresses then a client MAY announce to multiple addresses, one for each address family. When doing so the client SHOULD include an additional key parameter in its requests. The key should remain the same for a particular infohash during a torrent session. Together with the peer_id this allows trackers to uniquely identify clients for the purpose of statistics-keeping when they announce from multiple IPs . The key should be generated so it has at least 32bits worth of entropy.

When announcing to multiple address families all request parameters should be kept the same.

Example

This is example. I replaced all possibly sensitive values by theirs names.

No. Time Source Destination Protocol Length Info

883 466.839274657 2a03:5800:f9cd:3000:78a6:5e54:363f:c3c2 2606:4700:3038::681f:2b0 HTTP 546 GET /announce.php?pid=pid&info_hash=info_hash&peer_id=peer_id&port=53204&uploaded=0&downloaded=50135040&left=0&corrupt=0&key=key1&event=stopped&numwant=0&compact=1&no_peer_id=1&supportcrypto=1&redundant=0&trackerid=1058232046&ipv6=2a03%3a5800%3af9cd%3a3000%3a78a6%3a5e54%3a363f%3ac3c2 HTTP/1.1

886 466.842520121 192.168.0.170 104.31.2.176 HTTP 526 GET /announce.php?pid=pid&info_hash=info_hash&peer_id=peer_id&port=44015&uploaded=0&downloaded=50135040&left=0&corrupt=0&key=key2&event=stopped&numwant=0&compact=1&no_peer_id=1&supportcrypto=1&redundant=0&trackerid=1058232046&ipv6=2a03%3a5800%3af9cd%3a3000%3a78a6%3a5e54%3a363f%3ac3c2 HTTP/1.1

@xavier2k6

This comment has been minimized.

Copy link

@xavier2k6 xavier2k6 commented Jan 11, 2020

@arvidn what do you think?

@arvidn

This comment has been minimized.

Copy link

@arvidn arvidn commented Jan 11, 2020

thanks for pinging me on this one. This is related to an issue that was brought up recently, here.

Taking another pass over the code to generate the key, it is deliberately kept unique per listen interface. I'm not sure this is a good idea. The rationale behind it is the idea that &key= is primarily meant for supporting a peer changing its IP address, and if the key would be the same, the tracker might just overwrite the first entry in its database when it received the announce from the 2:nd IP address.

i.e. mistake a multi-homed peer for a peer that changed its IP.

I don't think there's a clear-cut solution to this (yet). I'm really interested in hearing ideas. Clearly the other side of that is that the tracker will want to know whether it's the same peer or not too. It could use the &peer_id= for that, but it's not optimal as that's a publicly known ID, and can easily be spoofed.

@arvidn

This comment has been minimized.

Copy link

@arvidn arvidn commented Jan 11, 2020

Having thought a bit more about this I think the right approach is to comply with BEP7 and make &key= consistent across all source IP announces.

@arvidn

This comment has been minimized.

Copy link

@arvidn arvidn commented Jan 11, 2020

@arvidn

This comment has been minimized.

Copy link

@arvidn arvidn commented Jan 11, 2020

@Ovsyanka you say you use libtorrent 1.1. Looking over the libtorrent logic from that version, I don't see how the key could be different for the different source IPs. Are you sure you're not using libtorrent-1.2?

@Ovsyanka

This comment has been minimized.

Copy link
Author

@Ovsyanka Ovsyanka commented Jan 11, 2020

@arvidn I am using 1.2.3 version.
The 1: in the 1:1.2.3-1 isn't actually a part of the version. I just didn't know that and copy pasted pacman output.

@arvidn

This comment has been minimized.

Copy link

@arvidn arvidn commented Jan 11, 2020

ok. this will be fixed in libtorrent-1.2.4

@Ovsyanka

This comment has been minimized.

Copy link
Author

@Ovsyanka Ovsyanka commented Jan 11, 2020

Great, thank you!

I am not sure when the issue should be closed. I think it is appropriate to close it after libtorrent-1.2.4 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.