Jump to content

IPv6/IPv4 leech exploit robs initial seeders


Honeyko

Recommended Posts

This affects both 3.3x and 3.4, and concerns something you won't notice unless you initially seed-mode very large torrents, and have the peer display sorted by %.

(Text below is a cut-n-paste from a thread elsewhere yesterday.)

This issue is back, and causing enormous bandwidth loss to leeching. In a nutshell, some downloaders have figured out how to "ghost" themselves as IPv6 and IPv4 couplets, one of which DLs at maximum velocity while the other reports reception to uTorrent, fooling the application into believing it's dealing with disparate peers who are sharing nicely. The result is that uTorrent continues to reward them with pieces far in excess of their actual sharing.

This is intensely frustrating as an uploader of huge torrents in initial-seeding mode in which, to manage my bandwidth, I halt uploading after the Availability of the torrent exceeds 2.0. -- In the old days before IPv6, this normally wouldn't happen until several peers were "99%"ers (meaning Avilabiliy would quickly shoot to 4 and higher as the 99%ers quickly traded the last rare pieces); now, Availability might reach 2.0 when the highest percentage peer is no better than 85% (well, him and his ghost buddy), with the next ghost-pair many percentage points farther down.

If a ghost-pair is a leech who splits soon after hitting 100%, they could up robbing 5%-10% of the torrent (and, if several couplets are leeches, it can be a lot more than that) -- a possibility that initial seeding mode exists as a feature to explicitly prevent.

During initial seeding, non-ghosted peers are almost completely shut out of any meaningful fraction of my upload bandwidth (since they don't have a ghost partner instantaneously reporting successful re-trades), as uTorrent will upload virtually exclusively to ghost-pairs. I can only cross my fingers and hope that not too many of the ghost-pairs are leeches who'll disconnect at 100% before they've shared their rarest pieces.

To give you some idea of bandwidth loss potential, I was recently "robbed" of over 40gigs out of a 250+ gig torrent established via initial-seeding, despite there being nearly a hundred peers in it near the finish. This occurred even though I had posted the torrent with a smaller piece size of only 4mb -- if I had gone with the default of 16mb or higher, the loss-to-leeching would have been even more severe.

2ggb.jpg

Link to comment
Share on other sites

If a ghost-pair is a leech who splits soon after hitting 100%

ALL peers will "split" when reaching 100% because uTorrent does not maintain connections to seeds.

But if it concerns you that much ... turn IPv6 connections OFF, set allow_same_ip to false and set connections per torrent to a sensible level.

Link to comment
Share on other sites

  • 7 months later...

ALL peers will "split" when reaching 100% because uTorrent does not maintain connections to seeds.

It is very frustrating when people do not read an OP before commenting. -- This IPv4/6 "leech-pairing" phenomenom has nothing to do with seeds -- of which there won't be any aside from the uploader while he's initially-seeding a torrent,

But if it concerns you that much ..

It "concerns me that much" when IPv4/6 leech-pairing can rob an initial seeder of up to 50% of his upload with large piece-size torrents.

turn IPv6 connections OFF,

That Advanced toggle setting has infamously not worked for forever and a day. Maybe it did under XP, but it sure doesn't under 7.

set allow_same_ip to false

IPv4/6 leech-pairs will by definition not have the same IPs.

Link to comment
Share on other sites

Bump to note that IPv4/6 leech-pairing is still a problem with current versions of uTorrent. As far as I can discern from performance, nothing has been done about it since the issue was first noted years ago. (Those old links in the OP may be zonked, but the attached pic should demonstrate the undesirous behavior).

Link to comment
Share on other sites

  • 5 months later...

This is definitely happening in uTorrent v3.4.2.

 

I am seeding a lot of torrents, but for an example, I have 6 peers connected to utorrent I'm seeing and 2 are 95.9% complete, 2 are 58.6% and 2 are 21.0% complete.

 

These completion percentages change for each set a of two clients at exactly the same time, and in other cases, even if I'm not giving bandwidth to one of the duped clients and the peer download is 0, or far lower than what I am giving the duped client.

So essentially there are 6 peers showing, only 3 are actual clients though.  This is creating an unfair bias as well because two slots are being taken for a single user and if that user is not or cannot give good bandwidth back, it is ultimately destroying the overall performance of the seed because it's forcing a client to seed to half as many clients with its available bandwidth.

Of course some IPs are only IPv4 and some are only IPv6, but a huge percentage of connected peers - I will hazard to claim about 50% overall - are duplicate clients.

 

uTorrent staff should definitely should fix this as soon as possible.

 

In the screen shot, all peer are getting bandwidth and sharing, but it gives you an idea of the duplicate clients.

post-305709-0-24820700-1418151740_thumb.

Link to comment
Share on other sites

  • 2 weeks later...

We are having some trouble duplicating this in order to narrow it down more.  We still have questions - if anyone has more information it would be appreciated.

- Is this an innocent bug in the client or a deliberate malicious configuration?

- Is the "ghost pair" really just one client instance or two separate running clients?

- Has anyone logged relevant peer traffic?

- Are there particular torrents this is seen with?

 

With the advanced setting bt.randomize_peer_id on, which is the default, it seems possible that a single client could have two different connections to the same peer, with no way to distinguish them, but we will need more information to proceed.

Thanks in advance for your help.

Link to comment
Share on other sites

I am seeing this for years and it looked to me like normal operation as some clients are capabale of making these two connections at the same time. One will always be UDP and the other TCP.

 

- Is this an innocent bug in the client or a deliberate malicious configuration?

Not a deliberate malicious configuration in my opinion. If it's a bug in your opinion that shouldn't happen then it's a bug.

 

- Is the "ghost pair" really just one client instance or two separate running clients?

One client in my opinion and from my experience.

 

- Are there particular torrents this is seen with?

No particuar torrents from my experience.

Link to comment
Share on other sites

It is possible that the extension message we send (http://www.bittorrent.org/beps/bep_0010.html) may not always contain both IPV4 and IPV6 addresses, which could prevent the client on the other end from correctly associating the two addresses with one peer.

 

Not being able to reproduce this reliably, this is still just a guess.  If someone could provide a log file with all the peer flags on and indicate which IPs seem to be "ghost pairs", it would be very helpful.

Link to comment
Share on other sites

Don't have the logs now but I've seen them. For example, an IPV4 uTP connection is made, the log says that there is an IPV6 extension to the remote peer, the clients try to make an IPV6 connection with each other for some time which later becomes a TCP connection. That's how you have two connections with the same peer. Flags are not important in my opinion as each client attempts to make a connection which is later made but you can see them and the "ghost pairs" in the first post here.

Link to comment
Share on other sites

By "flags" I mean the logging flags.  When you right-click on the logger tab, under the pop-up menu item "Peer Traffic Logging", select all of them: incoming connections, outgoing connections, disconnects, blocked connections, PEX, holepunch.  If it is as common as suggested in forum posts, it should only take a couple of minutes to capture the relevant handshakes.  If someone could turn these on and log to a file and send or post it, it would be very helpful.

 

In my tests, when handshaking over the ipv6 adress, the client always drops it in favor of a "better" connection to the peer via IPV4/uTP, and ghost pairs never appear.

 

I might have mentioned I'm a developer at BitTorrent and have been recently assigned to look into this, so there is a real chance of resolving it, but our network infrastructure makes it difficult to observe certain types of issues.

Link to comment
Share on other sites

I don't see this very often so I guess, Honeyko, that logging will have to be on you. As for dropping connections in favor of a "better" connection, sometimes I see the dropping and sometimes I don't and the connections look like the image in the first post here.

Link to comment
Share on other sites

My advice would be to try initially-seeding a big, fat torrent from a home computer with a decent cable connection (no cheap DSL). Pick something reasonablly popular enough that it'll attract more than minimal interest. Size should be 4gb or bigger, and the bigger the better. Piece size 4mb or larger (I prefer smaller piece size, but go with big for the test. Post the torrent to a popular public site. Normally seed it until about 5% complete or a dozen peers are in, then stop the torrent.

 

Close uTorrent. Re-open it. Set the torrent to initial-seeding mode. Start the torrent. Go to the peers tab and list by percentage.

 

By the time you're to 25% or more uploaded, you will see the ghost-pairing behavior.

 

Every single time.

Link to comment
Share on other sites

Honeyko, I don't see this very often as you as I'm not a heavy user and it looks like you can bring the log. Unless zanderz sees the log it looks like he can't do anything about it.

 

One thing that I saw today was a peer PEXing me both IPV6 and IPV4 of a seed in the swarm which means that he had two connections with the same client. I saw the peers list using an older version of 3.4 and I see this sometimes.

Link to comment
Share on other sites

You don't need to be "a heavy user"; you need fast internet and ONE torrent, uploaded using initial-seeding mode.

 

I have seen the behavior in literally every torrent I've uploaded in the last two years (which is why I just choke IPv6 at the OS level).

 

Note: it will help if you adjust the preferences to permit more connections and simultanious upload and download slots -- because obviously you're unlikely to see the behavior if you're strarving slot access to like five peers at a time.

 

(If you're wondering why I'm being tardy posting any logs, I have three excuses: 1) I'm not presently uploading anything, 2) I'm lazy, 3) I *really* would like the people who make this application to embrace the frame of mind of an uploader -- "peer management" tools from our POV have always been lackluster. Downloaders may be 99% of your users, but we uploaders create 100% of the content.)

Link to comment
Share on other sites

  • 3 weeks later...
  • 1 month later...

Hi--

I'm not sure if this is relevant or not, but I've been able to spot this exploit by turning on the "port" column under the peers tab,

then sorting by port number. (Right-click on the column labels bar, then make sure "port" is checked).

 

The port number is always the same for these "superleech" pairs.

 

If you translate the IPv6 address to IPv4, they're also the same.

 

That might be a way for uTorrent to patch this problem, by translating IPv6 to IPv4 & then applying the allow_same_ip rule.

 

BTW, I've also completely disabled IPv6, and no more ghost leechers!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...