Alternating peers on equal connection

[mcaspi]

Got a TCP connection with a peer's IPv4 address. At a later time a new TCP connection is made with the same peer's IPv6 address (no extension message) with a logger message "Disconnect: already have equal connection (dropped extra connection)" (not the "dropped new connection" message) and the IPv4 connection is disconnected. Later, a connection is made again with the peer's IPv4 address instead of the IPv6 address and the cycle continues. So what you get is constant alternating connections with the same peer's IPv4 and IPv6 addresses and the transfer speed can not build. I think that the new connection needs to be disconnected in this case and not the old one.

[Firon]

That's a pretty dumb behavior... Thanks for the report. We'll look into that.

[mcaspi]

Today I see a normal behavior so I don't get it. Leave it on Hold and I'll continue to look at it.

[mcaspi]

Seeing this again today on version 3.2 build 27568

[13:58:38] Incoming connection from X.106.200:60404

[13:58:39] X.106.200:60404 [uTP](X): [µTorrent/2.0.2.0 (0.0)]: Encrypted handshake completed

[13:58:39] Extension: ipv4:[X.106.200] for 'X'

[13:58:39] Extension: ipv6:[X:bd48:9537] for 'X'

[13:59:45] Incoming connection from [X:bd48:9537]:54329

[13:59:47] [X:bd48:9537]:54329 [uTP](X): [µTorrent/2.0.2.0 (0.0)]: Encrypted handshake completed

[13:59:47] Extension: ipv4:[X.106.200] for 'X'

[13:59:47] Extension: ipv6:[X:bd48:9537] for 'X'

[13:59:47] X.106.200:60404 [uTP](X): [µTorrent 2.0.2 (1.7)]: Disconnect: already have equal connection (dropped extra connection)

[mcaspi]

And this is why I asked it to be on Hold before. You come the day after and it is fine. Really weird.

[08:45:29] Incoming connection from [X:bd48:9537]:54329

[08:45:30] [X:bd48:9537]:54329 [uTP](X): Disconnect: already have equal connection (dropped new connection)

[mcaspi]

Still see this on 3.2.1:

Incoming connection from X.X.38.220:59936

[19:39:47] X.X.38.220:59936(X): [bitTorrent 7.7.2 (0.0)]: Handshake completed

[19:39:48] Extension: ipv4:[X.X.38.220] for 'X'

[19:39:48] Extension: ipv6:[X:10f7:d78a:2bdc:dd1d] for 'X'

[19:39:48] [X:10f7:d78a:2bdc:dd1d]:59691(X): [bitTorrent 7.7.2 (4.3)]: Disconnect: already have equal connection (dropped extra connection)

[fijam]

I see the same behaviour with 3.3. This is especially jarring when being the only seeder. Screenshot below to illustrate the point.

Logs consist of:

Disconnect: already have equal connection (dropped extra connection)

at which point the only peer switches between ipv4 and ipv6

[DreadWingKnight]

And what about 3.3.1, 3.3.2 and 3.4?