libtorrent not honouring announce_to_all_trackers settings

[ghost]

libtorrent version (or branch):
1.2.3
platform/architecture:
Windows 10
compiler and compiler version:

please describe what symptom you see, what you would expect to see instead and
how to reproduce it.

In Qbit latest version 4.2.1 using libtorrent 1.2.3 if you set Announce to all trackers to false libtorrent still announcing to all trackers in same tier. If downgraded to 4.1.9.1 which use libtorrent 1.1x this problem doesn't exist. So I'm suspecting the problem is with libtorrent 1.2.3.

[arvidn]

I'm trying to reproduce this by extending the unit tests, and I cannot. There's a possibility this is an issue on qBT. Could you provide some more details on the behavior and the expected behavior?
Are you certain of the tiers the trackers belong to?

[arvidn]

for instance, are you sure all trackers are not part of different tiers? perhaps the announce_to_all_tiers changed its default between qbt-4.1.9 and qbt-4.2.1. Could you try changing the announce_to_all_tiers setting as well?

[ghost]

Ok I found an interesting thing. When I bind Qbit to a specific IP address it honours the settings. But when I bind it to all IP addresses it announces to all trackers.
The issue doesn't exist on Qbit 4.2.0 which uses libtorrent 1.2.2.0
So something might have broken between these two version changes. Either on your side or Qbit side.

[arvidn]

interesting. This really overlaps with what I've been working on fixing for 1.2.4. It would be great if you would have a chance to try a recent build. However, I don't think this issue is fixed, but I think I know what's going on.

The way multi-homing support works is by attempting to announce from all source IP addresses, but under normal circumstances, only one will work and the other ones will be considered "no route to host". I bet this failure of specific endpoints for a tracker spills over into the whole tracker being considered not working. If a tracker isn't working, the next one in the tier is tried.

I think the logic needs to be that all endpoints for a tracker fail before the tracker is considered failed.

[ghost]

So who's considering the tracker as failed when one of the endpoints fail? Qbit or lib?
If Qbit decides that then the issue has to be fixed on their end. I tried with Qbit master as well which contains this PR but it doesn't fix the multi announce issue.
qbittorrent/qBittorrent#11733

[arvidn]

Here's an attempt to fix this: #4310
There may be more updates to this patch, but at least the unit tests I added suggests that this is a step in the right direction.

[ghost]

Here's an attempt to fix this: #4310
There may be more updates to this patch, but at least the unit tests I added suggests that this is a step in the right direction.

Let me know when you merge it. Will test and confirm if it works.

[arvidn]

it has landed in RC_1_2 now

[ghost]

Nice! Is 1.2.4 release coming soon? Or the RC_1_2 branch is stable?

[arvidn]

yes, I will cut 1.2.4 tonight or tomorrow. Unless something comes up

[arvidn]

It looks like you are picking up header files from an older version of libtorrent

[ghost]

Thanks! Forgot to clean previous build.

[skuizy]

I'm still getting "No route to host" errors on latest build from launchpad :

16:09:04.130 [DEBUG   ][deluge.core.torrentmanager          :1393] Tracker Error Alert: torrent (url to my tracker)[10.0.0.37:64270] No route to host "" (1) [No route to host]

In my setup, Deluge is running as a specific user whose default routing table send all traffic to a vpn. This setup was working great for ages and still working great if I log as this user and access https://www.ripe.net/ : it shows my vpn public address.

[arvidn]

is 10.0.0.37:64270 your IP address assigned for the VPN?
does the tracker resolve to an IPv4 address? (I would expect that it does).
Do you get any other tracker alerts that indicate success?

[skuizy]

is 10.0.0.37:64270 your IP address assigned for the VPN?

Yes

does the tracker resolve to an IPv4 address? (I would expect that it does).

Definitely

Do you get any other tracker alerts that indicate success?

Nope... I have 3 torrents that finished correctely this week, but it was with several public trackers and I don't have relevant logs anymore to see if it was from DHT or not...

[ghost]

I had the same kind of issue due to bad DNS server.

[skuizy]

It doesn't come from my DNS (selfhosted recursive pi-hole btw) :

[~]$ dig tracker.coppersurfer.tk

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> tracker.coppersurfer.tk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55255
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;tracker.coppersurfer.tk.       IN      A

;; ANSWER SECTION:
tracker.coppersurfer.tk. 3600   IN      A       62.138.0.158

;; Query time: 91 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 08 19:35:13 CET 2020
;; MSG SIZE  rcvd: 68

[~]$ sudo -u vpn dig tracker.coppersurfer.tk
[sudo] password for odroid:

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> tracker.coppersurfer.tk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2932
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;tracker.coppersurfer.tk.       IN      A

;; ANSWER SECTION:
tracker.coppersurfer.tk. 3582   IN      A       62.138.0.158

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 08 19:35:31 CET 2020
;; MSG SIZE  rcvd: 68

[arvidn]

thanks for reporting this! fixed here: #4320

[arvidn]

please give it another try now!