search

rakshasa / libtorrent

libTorrent BitTorrent library
http://rtorrent.net/downloads/
GNU General Public License v2.0
885 stars 209 forks source link

Fixes https://github.com/rakshasa/rtorrent/issues/731 #176

Closed afontenot closed 5 years ago

afontenot commented 6 years ago

Logic:

What the two changed lines are supposed to do is, if the localAddress is ipv4, also send the local ipv6 address to the tracker, if any. And, if the localAddress is ipv6, also send the local ipv4 address to the tracker, if any.

If that's the intent of this bit of code, it should be clear from the diff why the changes are needed for the correct behavior.

This problem also caused https://github.com/rakshasa/rtorrent/issues/731 as a side effect. Since localAddress->is_address_any() is true (at least for people hitting the bug?), the code thinks the localAddress is ipv6 and tries to tack on the ipv4 address. It does this "incorrectly", in that it determines the wrong local address for anyone who's behind NAT.

This request still leaves one problem, in that it's possible that someone could be connecting to the tracker via ipv6, and also be behind NAT. I think the correct solution to that problem is putting an option to disable adding &ipv4 and &ipv6 in the config file. But that's beyond the scope of this request.

Sorry if I've misunderstood anything about how this is supposed to work.

coveralls commented 6 years ago

Coverage Status

Coverage remained the same at 17.953% when pulling 0ee9799f2896a3eff591fce8654d2e1394d9ebd4 on afontenot:master into 074f6ec51a2e4bc5c6140b4dad13c9bb56f3f0dc on rakshasa:master.