Jump to content

µTorrent 1.9 alpha 15380


Firon

Recommended Posts

I've noticed that at times when uTorrent 1.9 clients with uTP enabled connect to me (I use 1.8.2) they send something crazy like 100+ udp connections per second for as long as they are connected.

Is this expected behavior?

If uTP is going to flood people with udp packets in a DoS like manner, you should consider adding an option to block uTP in uTorrent 1.8.x.

Link to comment
Share on other sites

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

The peer was connected and was shown as uTorrent 1.9 [utp]. I'm not too familiar with how uTP is supposed to work, but I'm referring to udp connections. I have no idea what sort of data was contained in those connections since I haven't analyzed the traffic. All I know is an excessive number of udp connections were being made in an extremely short about of time, all of which were coming from a single uTP client IP address. This is now the third time I've seen this happen with uTorrent 1.9 uTP clients. Most seem to behave but some go crazy and flood me with udp connections which stands out like a sore thumb.

I already had bt.transp_disposition set to 0 (TCP only) in 1.8.2, and that doesn't prevent what I am seeing since it is only for outgoing connections and these are incoming connections.

Link to comment
Share on other sites

... IF @ 0 uT is still accepting UTP connections, that is a bug http://forum.utorrent.com/viewtopic.php?pid=393902#p393902 (I could not reproduce)

[2009-05-22 01:47:56] Incoming connection from 192.168.1.102:24742

[2009-05-22 01:47:57] 192.168.1.102:24742 [utp]: Disconnect: Banned

Testing multiple connection attempts on LAN peers, I didn't see this multiple connection behavior :/ sorry.

Edit: seems they did backport disabling TCP and make bt.transp_disposition=0 work correctly, as http://forum.utorrent.com/viewtopic.php?pid=399544#p399544 says that 1.8.2 still accepts incoming. Fortunately, I don't see that. :/

Link to comment
Share on other sites

@ Ciberbeing:

Where did you saw these "many" UDP connections?

(UDP don't SYN, so maybe you are seeing something unreal)

The ONLY way to stop uTP at all is working with 1.8.3 or higher. uTP is a way to bypass ISP traffic-shaping (from/to peers ISP's TOO), so, it's a cool thing.

Link to comment
Share on other sites

@jewelisheaven: No, that wouldn't be a bug. To attempt would be to attempt outgoing connections; it doesn't tell other peers what to do, or how to handle other peers' uTP connections

In 1.8.0 - 1.8.2, bt.transp_disposition controls which transport is used for outgoing connections only (that is, it doesn't filter incoming connections).

As mentioned, only the new implementation of bt.transp_disposition found in 1.8.3+ can prevent incoming uTP connections from being accepted (though it still won't prevent other peers from at least attempting to connect using uTP).

@Cyberbeing: UDP is connectionless. Everything UDP is based around individual packets, not connections. If your firewall were to consider each individual packet sent over a TCP connection to be a connection onto itself, you'd see the same thing even then with TCP instead, as you receive hundreds of TCP packets on any one connection very quickly too. The amount of packets seen is to be expected, but the way the firewall interprets doesn't mean it's too different from normal TCP connections.

Link to comment
Share on other sites

I don't know -- there are plenty of reasons that a ban may occur -- but banning a peer just because a different transport is used is kinda dumb. Not accepting a connection is simple enough if the devs wanted it to do that, and banning just to achieve that is beyond reason. The only difference is that banning would prevent even the acceptable TCP connection from ever being established with that peer in the future.

Besides which, bt.transp_disposition defaults to 0 in v1.8.2. That v1.8.2 clients are even able to establish uTP connections by default is already proof enough that incoming uTP connections are accepted even when the option is set to 0 (you'll find, by reading the beginning of this thread, that that was by design).

Link to comment
Share on other sites

I just tested two local copies of µTorrent running simultaneously, and a uTP connection was established ("[utp]" in the 1.8.2 Peers tab), 1.8.2 with bt.transp_disposition set to 0, and 1.9.0 with bt.transp_disposition set to 10.

Edit:

connected.th.png

Link to comment
Share on other sites

@Ultima It still doesn't seem normal to me for a single uTP peer to show up as making more connections (sending more packets, since you say it's connectionless) then the all of the 100+ peers on the torrent combined. For every two packets sent from the entire swarm, these single misbehaving uTP clients are sending ten or more. I have a hard time believing that a single uTP IP sending something like 5 times as many packets as the entire swarms from multiple torrents is normal.

What I am suspecting is uTP clients over a high latency, low bandwidth link are flooding me with very, very, very, very small udp packets. It seems the release notes mention variable packet size, so if there is no minimum size, this seems to make the most sense to me as the IP doing this yesterday was from Malaysia. If not that, could someone be exploiting the uTP advanced settings to send an excessive amount of packets?

In any case, you better make sure this is not a bug, since I'm unsure how well most consumer gear (e.g. NAT) will handle being flooded with 100,000+ udp packets/sec when uTorrent 1.9 goes mainstream and everybody is using uTP.

Link to comment
Share on other sites

Let's get some things straight:

[ul][li]UDP "connections" aren't connections because there is no such thing as a "connection" with UDP. Individual packets often end up each getting treated as connections because firewalls are simply wrong about how they classify them. Any form of communication over the Internet generally requires several to many packets, so you shouldn't be surprised to be seeing a lot of UDP packets being generated (and end up getting incorrectly classified as connections by firewalls). uTP extends UDP in a way such that uTP itself knows what's considered a "connection," but uTP-unaware devices/softwares simply see a bunch of UDP packets, and interpret them in the usual way.

[/li][li]TCP connections are real connections. Each connection involves many packets getting transmitted back and forth between both ends, and it is still considered to be one connection. Firewalls don't mistaken individual packets to be different connections with TCP because connections are defined in the TCP specifications.

[/li][li]See Wikipedia for some more detail.

[/li][/ul]

So are you literally counting TCP packets and comparing the count with the UDP packet count? Or are you misunderstanding and considering each TCP connection as one packet now?

I'm not denying that there may be potential problems associated with using UDP in some consumer networking devices (it was discussed even before 1.9 was first released to the public), and I'm not saying that there definitely isn't a bug with uTP. I'm clarifying definitions with you only because it sounds like you're mixing them up, and what you're thinking is a bug might simply be the expected behavior when using UDP.

Link to comment
Share on other sites

Consumer NAT gear most likely only cares about the source IP, Port and destination Port. That's all it could possibly uses to identify "connections". Your router would only see 1 "connection" if all the traffic is from one source IP:port towards one destination port (ie. the port that is forwarded).

Link to comment
Share on other sites

Using Wireshark,

Packet size for uTP can fall to 215 bytes even if upload speed is 100 mbit/sec LAN speeds. In my tests, this has ALSO caused upload speed to fall to ~4-5 KB/sec. The reply packet for uTP seems to be about 65-69 bytes (typically 65.) At higher speeds I saw considerably fewer reply packets than incoming packets.

Link to comment
Share on other sites

I hear what you're saying Ultima.

Going with the small uTP packets Switeck has seen, this begins to make a bit of sense. If the UDP packets are a fraction of the size of the TCP packets, and both are logged on a per packet basis that would explain seeing so many more. The alternative of TCP being logged on a source<->destination per connection basis, and UDP on a source<->destination per packet basis, would also make sense.

Either way, I expect it's going to put a lot of stress on and possibly crash any firewall which tries to log the mass UDP traffic on a per packet basis. Especially if it chooses to deal with each UDP packet as an individual connection instead of grouping them together on a source/destination/port basis (in the sense that most firewalls can only handle the processing of so many connections at once).

If the developers have thoroughly tested this and don't believe this is a problem, then I will just hope for the best and see what happens when uTorrent 1.9 is released.

In any case, since it sounds like 1.8.3+ and 1.9 are able to reject both incoming and outgoing uTP connections, if it becomes a problem, it's nice to know people have a way to block it as a last resort.

Link to comment
Share on other sites

The other day I was looking at PeerGuardian, and I have no idea how it handles TCP and UDP traffic logging.

Posting here was an afterthought, so I hadn't checked my router firewall log (to see if it was showing the same thing as PeerGuardian) or run a network analysis tool. Since I only very rarely (once a month?) run into a client using uTP, so far I haven't cared enough to prepare myself to fully investigate when it does happen.

Link to comment
Share on other sites

uTP goes thru UDP. UDP packets have distinct transit than TCPIP.SYS, obey self-independent parameters not the same valid to TCP packets.

AFD strings "equivalent" to TCP MSS (MSS = MTU - header) are "FastSendDatagramThreshold" and "FastCopyReceiveThreshold". M$ default for XP and VISTA with Fast Ethernet 100Mbits cards, the driver sets these UDP AFD's parameters on 1024 bits as stand in RFC rules. UDP don't obey the same TCPWindowSize as TCP.

If your driver is at wrong values, this size of the packet in transit can be very very short.

http://technet.microsoft.com/en-us/library/bb726981.aspx

http://technet.microsoft.com/en-us/library/cc781532.aspx

The number expected of packets per second is easy math, since you know the bandwidth (speed) of the transit and the amount of data transfered.

This procedure is already working in ALL versions of uT for pure UDP connections. DHT, PEX realizes on UDP.

PeerGuardian doesn't log each packet sent/received via TCP, but UDP.

Link to comment
Share on other sites

I'm using the latest build with a setting of 10 (UDP only), yet I still see multiple TCP connections being made on my listening port to random IPs. This was with 1 torrent active using 1 tracker, so I don't think they were tracker connections. It seemed to only maintain 1 or 2 at a time, dropping them for completely different IPs each time.

Link to comment
Share on other sites

They're getting your ip from the tracker and don't know to use uTP yet...or can't because they're not uTorrent clients. It's normal behavior for BitTorrent.

Ah, that makes sense. Will uTP protocol information be shared with Azureus and other such clients so this becomes less common?

Link to comment
Share on other sites

Yes, uTP is on track to be an IETF (open) standard. By the time it's completed, other clients should be able to implement uTP support too. At the moment, though, the transport protocol is still a work-in-progress, which is why it's only available in µTorrent, and the details aren't yet freely available.

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...