uTorrent: hundreds outgoing connections to BItTorrent Inc

[rafi]

I have confirmed that three peers are running in the 208.72.192.0/21 range allocated to BitTorrent, Inc.

The addresses seen by me are 208.72.192.2, 208.72.192.156 and 208.72.192.166 and they appear inthe peers list of many of my legally shared seeding swarms.

if you want your confirmed test to be of help , you should as least report your settings of

perf->general -> check for updates/betas and pref-advanced-> crash reports

[Aaron.Walkhouse]

The people responsible don't need my help to diagnose what is happening on their own computers

and it is irrelevant because participating in swarms with company resources does not depend on

which versions of the software we have or the settings.

They have the hardware and software involved in this activity in their own possession so all they have

to do is ask their staff what is going on and how to explain that and ask their own legal counsel how to

express that information in terms which address their Privacy Policy.

This is a policy issue, not a tech support problem; so only the Management can handle my question.

[Firon]

We run seeders here for many legal swarms (because we want to support legal content, such as Vodo).

It conflicts with nothing in the privacy policy. It relates only to your use of the website and the use of our client.

We can run whatever clients we want from here and it has no relevance to the privacy policy. You are on a PUBLIC SWARM. Note the key word: public.

[Aaron.Walkhouse]

I didn't say the activity was only on "legal" torrents and you are not on this list, so please wait for them instead of growling.

I also sent them an email so don't trouble yourself if you don't feel like forwarding it from here.

I'll be back in a week, and if this attitude proves to be representative of the Company position

my colleagues in various P2P related sites will start copying my files around if I cannot.

Sorry to go over your head but this activity was unannounced and a matter of trust between management and the public.

[Simon Morris]

Hi Aaron - your tone is pretty uncalled-for and your threats are completely out of line. While I appreciate that you think you're standing up for the best interests of our users, you might consider adopting a few manners before letting loose with such hysterics. I'm quite certain that Firon's initial diagnosis is correct (this is just regular traffic related to either developers machines or infrastructure that supports legitimate Bittorrent content distribution) and I'll be happy to confirm this and get back to you tomorrow with more details.

[DreadWingKnight]

Additionally Aaron, any torrents running on opentracker based trackers could have the bittorrent inc IP addresses be explained by the trackers giving out random IP:Port combinations mixed into legitimate peers in peerlist responses.

Simon, what about the rest of the concerns of this thread?

[plim121]

Hi Aaron - your tone is pretty uncalled-for and your threats are completely out of line. While I appreciate that you think you're standing up for the best interests of our users, you might consider adopting a few manners before letting loose with such hysterics. I'm quite certain that Firon's initial diagnosis is correct (this is just regular traffic related to either developers machines or infrastructure that supports legitimate Bittorrent content distribution) and I'll be happy to confirm this and get back to you tomorrow with more details.

Hello.

So first I'll tell it once again:

- disabled DHT,

- automatic updates and sending detailed info when checking for updates.disabled,

- utp disabled,

- search engines disabled,

- it is not DNS traffic,

- uTorrent didn't crash,

- uPnP and NAT disabled,

- no irc,

- this traffic is definitely not bittorrent traffic,

I started this thread. I delivered more then needed information. There still is NO answer what kind of data is send to BItTorrent Inc. The data is transfered to Bittorrent Inc server. The Bittorrent Inc server actively responds. All we have in this thread is pure speculation- nothing more. No real answer was given.

[rafi]

It've only been ~10 days now.... they have my captures/data (and I don't remember you posting any captures, or anyone else here for that matter ... ) give them time, they are probably busy with other, more critical bugs...

consider adopting a few manners before letting loose...

..and.. I'm sure you agree that waiting such a long time for someone in BT inc to actually look at the data, even test-generate it, and not just speculate about it - points to strange conduct on the part of BT inc too (to say the least) ... thus making people suspect hidden intentions

[arvid]

So I found some spare time and used wireshark. The results are weird to me. Te communication with Bittorrent Inc ip 208.72.192.166 has noting to do with torrent download/upload.

I don't possess enough knowledge to say what is it all about. I hope that uTorrent devs can.

If you send me your wireshark log I'll take a look and let you know what the connections are.

arvid@bittorrent.com

[arvid]

I wonder - why is a search reported "home" . I guess I have to block the BT IP in my firewall .

With the risk of duplicating some effort, I've had a look at your dumps. Here's what I see (with regards to IP addresses in the BitTorrent Inc. range):

You seem to be trying to connect to a peer on high port numbers. These are probably peers stored in your resume.dat because they used to be running, but not anymore (or their pinholes have time out). When connecting to peers, we first send a DHT ping, any peer that responds to this gets prioritized in the connection queue. This saves a lot of time with versions of windows that have a half-open connection limit. We'll be much more likely to try peers that are alive with this technique. All three of these pings receive an ICMP host unreachable.

The dump contains a number of connection attempts, all of them are reset immediately and not accepted (i.e. blocked by the firewall). They are interleaved with the DHT pings. There are also uTP SYN packets (connection attempts) that all receive ICMP destination unreachable.

Note that uTorrent will try to connect to peers multiple times before giving up. And if it ever sees the peer again, from a tracker for instance, it will start trying to connect again.

Looking at your second dump:

It's mostly more of the same. There's also a ping to the DHT router (router.utorrent.com) which fails for some reason.

My conclusion is that BitTorrent Inc. seems to be running BitTorrent clients every now and then, and actually participate in some swarms.

This is in fact what we do when we test and develop uTorrent.

[plim121]

So I found some spare time and used wireshark. The results are weird to me. Te communication with Bittorrent Inc ip 208.72.192.166 has noting to do with torrent download/upload.

I don't possess enough knowledge to say what is it all about. I hope that uTorrent devs can.

If you send me your wireshark log I'll take a look and let you know what the connections are.

arvid@bittorrent.com

I've just sent them. Thank You.

[arvid]

I've just sent them. Thank You.

looking at your first log:

There are 3 TCP connection attempts to a single hight port (63759). Each connection attempt sends 3 TCP SYN packets (these resends are done by the TCP stack) before TCP gives up. uTorrent then waits a while before trying to connect again, about 85 seconds later, uTorrent tries again and then 357 seconds later, it tries again. Each SYN packet receives a RCP RST (reset) packet from the firewall, since this port is no longer open. The fact that it's a high port suggests that this is a timed out pinhole.

So, this covers 3 * 3 SYN packets and 3 * 3 RST packets.

As some people might know, when uTP is enabled (which it is by default), each peer we try to connect to, we try uTP and TCP in parallel. i.e. each connection attempt comes with a uTP connection attempt. Each uTP connection attempt receives a ICMP destination unreachable, immediately. The uTP implementation actually listens to those and, as opposed to TCP, will stop trying. Hence, each uTP connection attempt only results in one UDP packet + one ICMP response.

This covers 3 UDP outgoing packets and 3 incoming ICMP packets, and that's all the packets in your first log. There is not a single byte of payload being transferred, in any direction.

The uTP connection attempts are a bit tricky, because Wireshark doesn't have a dissector for them (I have a half-done lua dissector if anyone is interested in trying to get it to work in wireshark). One way to identify them is to compare the data in the datagrams with the uTP header described in bep-29.

Looking at your second log:

This log contains the exact same pattern. 3 connection attempts, 9 SYN packets 9 RST packets, 3 outgoing UDP packets and 3 incoming ICMP packets. There are two differences, the port your trying to connect to is different (29375) and the connection attempts happen at different time intervals. The second one happens 265 second after the first one, and the 3rd one happens 516 seconds after the first one.

What this probably means is that you used to be connected to a peer running in the BitTorrent office and it's no longer running and you stored this in your resume.dat (and the pinhole isn't open). Probably what's more likely is that a client announced itself to a tracker on the same swarm but might not have been running at all, and the tracker gave you the IP and you can't get through the firewall.

Please let me know if you have any questions.

[Simon Morris]

Thanks Arvid. So it seems that Firon's original diagnosis was right. Please let us know if there's anything we're missing here. I'm sorry this took us so long to clear up (assuming you agree it is cleared up) but as we don't do anything evil (and nor do we plan to), we therefore don't tend to quickly divert our engineers to dig into what appears to be evidence that people in the BitTorrent, Inc office are indeed using the BitTorrent protocol.

While not seen in this wireshark log, I'm sure you can find other evidence of BitTorrent clients connecting to IP addresses owned by BitTorrent that might be related to a range of other activities, for example running BitTorrent DNA infrastructure, DNS resolution, some (limited) seeding of content, DHT bootstrapping, auto-updates (for those who have it enabled), install success tracking, and tracking usage of the (project griffin) Apps we have recently published. But in every case this is benign and conforms with our published policies. While the potential for accidental mis-configuration always exists (which is why we're happy to be held to account on this stuff) there is nothing but benign intent behind every connection that your uTorrent or BitTorrent client will ever make to our IP ranges.

[Aaron.Walkhouse]

Hi Aaron - your tone is pretty uncalled-for and your threats are completely out of line. While I appreciate that you think you're standing up for the best interests of our users, you might consider adopting a few manners before letting loose with such hysterics. I'm quite certain that Firon's initial diagnosis is correct (this is just regular traffic related to either developers machines or infrastructure that supports legitimate Bittorrent content distribution) and I'll be happy to confirm this and get back to you tomorrow with more details.

Sorry to make you uncomfortable, Simon, but I really did put a lot of thought into what I put into that post

and also into what I left in between the lines. I heartily encourage you to look into the details and then go

to the rest of the team and talk it over before jumping to conclusions about what I am doing by bringing

your attention to this matter. One particular concern will now be send to your personal mailbox on these

forums. Once you see that you may decide I'm not such a bad guy after all.

[Aaron.Walkhouse]

Additionally Aaron, any torrents running on opentracker based trackers could have the bittorrent inc IP addresses be explained by the trackers giving out random IP:Port combinations mixed into legitimate peers in peerlist responses.

Actually , the three addresses are clearly not random. They show up too consistently

across many torrents and on widely separate peers.

[Aaron.Walkhouse]

Hello.

So first I'll tell it once again:

- disabled DHT,

- automatic updates and sending detailed info when checking for updates.disabled,

- utp disabled,

- search engines disabled,

- it is not DNS traffic,

- uTorrent didn't crash,

- uPnP and NAT disabled,

- no irc,

- this traffic is definitely not bittorrent traffic,

I started this thread. I delivered more then needed information. There still is NO answer what kind of data is send to BItTorrent Inc. The data is transfered to Bittorrent Inc server. The Bittorrent Inc server actively responds. All we have in this thread is pure speculation- nothing more. No real answer was given.

I did all those setting and also turned PEX off. Unlike your results all the addresses showed up in my test swarms.

Whether it's peer chatter, stats functions or magic I agree with you that whatever is going on must be clarified quickly.

[DreadWingKnight]

If they are appearing on public swarms, then the above explanations from the programming staff of this project cover what is going on, regardless of what you want to believe in regards to the swarms themselves. Additionally, I am aware that several staff members at BitTorrent inc are members of private trackers for purposes of client testing.

Provide a packet capture of what is going on with the offending torrents, including any tracker announces and peer exchange messages.

Additionally, the complete staff list of BitTorrent inc isn't on the page you linked, only management, and you don't have the authority to claim someone who posts here with an administrator title doesn't work for them, since users cannot set their own titles here.

[Aaron.Walkhouse]

All I had to work with was what was put online so I did what I could to get this over and done with

before rumours spread that you were doing something new that involved connecting to people

and then not explaining it when asked. That's where you were when I found you and it was from

another website where I first heard it. Rumours and questions travel quickly so this is the place

and the time to nip it in the bud.

I was pretty sure from the start that it was probably work-related and relatively innocuous but only

people like Simon and arvid could bring answers that are clear and detailed enough to be trusted.

As the forums staff had their turn and I can't speak for the company I made sure that the company

spoke up for itself with enough candour and information to be convincing.

I'm glad to see it work out as quickly as it did. You can count on me to back you up again even if it

means leaving bruises that you can't sit on for a week. Just ask Switeck about the years I put in on

BearShare and how often I had to kick Vinnie around to keep him from shooting himself in the foot.

Don't make me come down there and do it again!

Answer people when they are worried or annoyed about something!