Open HanabishiRecca opened 1 week ago
Some testing confirms that moving the add_dht_node
part below all filters at least prevents such outgoing connections.
--- a/src/torrent.cpp
+++ b/src/torrent.cpp
@@ -11182,17 +11182,6 @@ namespace {
TORRENT_ASSERT(info_hash().has_v2() || !(flags & pex_lt_v2));
-#ifndef TORRENT_DISABLE_DHT
- if (source != peer_info::resume_data)
- {
- // try to send a DHT ping to this peer
- // as well, to figure out if it supports
- // DHT (uTorrent and BitComet don't
- // advertise support)
- session().add_dht_node({adr.address(), adr.port()});
- }
-#endif
-
if (m_apply_ip_filter
&& m_ip_filter
&& m_ip_filter->access(adr.address()) & ip_filter::blocked)
@@ -11241,6 +11230,17 @@ namespace {
return nullptr;
}
+#ifndef TORRENT_DISABLE_DHT
+ if (source != peer_info::resume_data)
+ {
+ // try to send a DHT ping to this peer
+ // as well, to figure out if it supports
+ // DHT (uTorrent and BitComet don't
+ // advertise support)
+ session().add_dht_node({adr.address(), adr.port()});
+ }
+#endif
+
if (!torrent_file().info_hashes().has_v1())
flags |= pex_lt_v2;
I noticed that libtorrent still tries to contact filtered IPs. It sends UDP packets as part of an outgoing connection, which appears to be DHT traffic. Fun fact that it does alert about IP being filtered, but still sends the packets regardless. And amount of outgoing UDP packets on my firewall matches with amount of alerts.
Seeking through the code, I see that at least here a DHT node is added before the filter:
https://github.com/arvidn/libtorrent/blob/bb08bdbd8c8ae2355ec79d55de090f894eb6e451/src/torrent.cpp#L11185-L11199
And I don't see any filters in the DHT tracker logic at all, so it appears to be talking with blocked IPs freely. That should not happen in my opinion. It's hard to track the logic though, so maybe I misunderstood something. @arvidn, could you clarify on that?