BiglySoftware / BiglyBT

Feature-filled Bittorrent client based on the Azureus open source project
https://www.biglybt.com
GNU General Public License v2.0
1.55k stars 153 forks source link

Conflicting peer identification, regardless of how many times I2P address is renewed #2412

Closed JBitte closed 2 years ago

JBitte commented 2 years ago

hello, Win10 with latest patches

I continue to get Conflicting peer identification, regardless of how many times my I2P address is renewed. Is there a finite limit to addresses with Conflicting peer a reality or using a torrent client?

my log below,

DEBUG::Sun Jan 16 10:38:42 CET 2022 Conflicting peer identification: unknown_client [LTEP]: "Unknown UW 1.0.8.27" / "libtorrent/1.2.1.0" [6C6962746F7272656E742F312E322E312E30], Peer ID: 2D5557313038522D50537E2142686D514C6C344F DEBUG::Sun Jan 16 10:40:07 CET 2022::com.biglybt.core.util.NetUtils$1::run::121: Network interface enumeration took 223: decreased refresh frequency to 30000ms getNetworkInterfaces (NetUtils.java:220), allAddresses (AddressUtils.java:158), updateBindAddrs (RPCServerManager.java:73), doBindChecks (RPCServerManager.java:89), lambda$14 (DHT.java:714), call (null:-1), runAndReset (null:-1), run (NonblockingScheduledExecutor.java:290), runWorker (null:-1), run (null:-1), run (null:-1) DEBUG::Sun Jan 16 10:40:38 CET 2022::com.biglybt.core.util.NetUtils$1::run::121: Network interface enumeration took 263: increased refresh frequency to 120000ms getNetworkInterfaces (NetUtils.java:220), allAddresses (AddressUtils.java:158), updateBindAddrs (RPCServerManager.java:73), doBindChecks (RPCServerManager.java:89), lambda$14 (DHT.java:714), call (null:-1), runAndReset (null:-1), run (NonblockingScheduledExecutor.java:290), runWorker (null:-1), run (null:-1), run (null:-1) DEBUG::Sun Jan 16 10:42:36 CET 2022::org.parg.azureus.plugins.networks.i2p.plugindht.I2PHelperDHTPluginInterface::importContact::457: DHT not yet available

parg commented 2 years ago

Ignore it, it isn't interesting. It is nothing to do with I2P, it is simply that a client is sending one identification embeded in its peer-id and another in the string it sends during the LT handshake.

JBitte commented 2 years ago

ok, thanks!