libtorrent fix: UDP tracker: accept responses from unexpected IPs

Related issues

https://github.com/qbittorrent/qBittorrent/issues/20882
https://github.com/arvidn/libtorrent/issues/7679

Related BEP

Why are these issues closed?

In one of the issues the author of the issue just provided the question but didn't follow the contributing rule so it was closed, the other one I don't know. But the issue still exists.

Changes

one line. do not return when ip not match.

I can give a short description of the problem. the BEP0015 only asks for verification of the txID, not the server IP consistency. So, limiting ip consistency is redundant and causes quite a few problems.

Whats problem

TBA, which has only been massively reported in recent years. Because in the ipv4 era, a tracker generally did not have multiple ip addresses, this validation did not cause serious problems, however, in the ipv6 era, a tracker can have many ipv6 addresses, and which ip it uses for a response is not strictly limited in BEP, so there are many scenarios where it is not the same ip that is used for a response.

Also, since some proxies (ie Fake IP) may change the address to which UDP packets are sent, these packets will also be dropped, making the udp tracker completely inoperable after the proxy.

So I submitted this PR

Mar 20 '25 07:03 baka-gourd

the #ifndef TORRENT_DISABLE_LOGGING should be extended to cover the outer if-statement, and probably merged with the inner if-block.

done

The comment should be extended with a justification to allow the response from a different IP.

done

Ideally there would be a test as well, a simulation would probably be the simplest way to do that.

I tried, but it's hard to simulate a tracker with two ip's in a test environment, I failed and my test samples never returned, sorry.

Meanwhile, I haven't found why CI fails on MACOS

Mar 24 '25 07:03 baka-gourd

this test is still failing test_tracker.cpp.udp_tracker_v4

Apr 27 '25 12:04 arvidn

interestingly, it works when I run the test locally

Apr 27 '25 12:04 arvidn

interestingly, it works when I run the test locally

Yes, I suspect it's an issue with the github network stack, since macos runners seem to share the network

Apr 27 '25 13:04 baka-gourd

I don't think it's a coincidence that the udp tracker tests are failing, seemingly consistently

May 11 '25 07:05 arvidn

I don't think it's a coincidence that the udp tracker tests are failing, seemingly consistently

at the moment I don't have a mac to test and develop on (I've only been able to test with other people's macs before, which obviously can't be occupied for long periods of time), so if this isn't a coincidence I probably don't have a way to fix it. Sorry

May 11 '25 09:05 baka-gourd