LPD multicast flood from uTorrent

Good day!

On Monday we experienced massive flood inside our customer network. After analyzing network traffic we found that uTorrent flood our network with UDP multicast traffic (LPD packets).

We registered over 8000 – 10000 packets/second from single PC, and there is several of such in the local segment. This traffic effectively bring our network down.

Checked a few clients, they were running uTorrent 2.0.2 (build 19648). The problem is slowly spreading, at first we have only one segment with this anomaly, now there is more.

We would be grateful if you look in to this problem and make a fix.

Packets summary statistics: http://www.atech.lv/troubleshooting/uTorrent/ldp_statistics.png

Packet details: http://www.atech.lv/troubleshooting/uTorrent/ldp_packet.png

PCap sample of the packet stream: http://www.atech.lv/troubleshooting/uTorrent/uTorrent_LPD_Flood.pcap

How much information do you have about the installed software on the offending system?

Not much at this point. We blocked multicast traffic in problem segments to mitigate some flood, and trying to identify reasons for this change in behavior. uTorrent version 2.0.2 (19648) exists for two months, and there was no problems before.

We are gathering more information, is there anything about offending systems that might be helpful besides OS, AV+Firewall software and uTorrent settings?

That looks pretty bad. It's interesting that it seems to happen with just a single torrent. I'll take a look at this

We are gathering more information, is there anything about offending systems that might be helpful besides OS, AV+Firewall software and uTorrent settings?

Possibly, be ready to provide further information as requested. That information would be immediately useful though.

We identified the source of a problem, it's not uTorrent fault.

Problem was caused by ZyXEL P-2702R VoIP Gateways (FW 1.01(BWA.0)C0). These devices misbehave in Bridge mode, capturing multicast packets and resending duplicates back to the network. Several such devices in LAN segment create multicast storms resending same packet back and forward.

Thanks for your support,

and sorry for any troubles.

@MyX: Thanks for letting us know! Can you think of anything uTorrent could do to mitigate the effect of routers that behave this way?

Wow. That's a really nasty bug. Have you informed Zyxel about the problem?

@arvid: I think this should be fixed by vendor in the bridge code, as even a single packet can lead to a problem. However, I suggest you could optimize LPD and mitigate some problems by sending fewer packets to the network. Instead of sending one LPD packet per torrent, you could send one (or two) packet with multiple Infohash fields for every torrent you have.

For example one host sends several packets:

BT-SEARCH * HTTP/1.1
Host: 239.192.152.143:6771
Port: 64746
Infohash: AE1BA3A900C4636DCAA1731F6C59529DC0EE04EA
--
BT-SEARCH * HTTP/1.1
Host: 239.192.152.143:6771
Port: 64746
Infohash: 641B3CDCA88B45E2F6CDB39317423157FD31456D

As every other bit of information is the same, this could be send using multiple fields as:

BT-SEARCH * HTTP/1.1
Host: 239.192.152.143:6771
Port: 64746
Infohash: AE1BA3A900C4636DCAA1731F6C59529DC0EE04EA
Infohash: 641B3CDCA88B45E2F6CDB39317423157FD31456D

Or coma separated like this:

BT-SEARCH * HTTP/1.1
Host: 239.192.152.143:6771
Port: 64746
Infohash: AE1BA3A900C4636DCAA1731F6C59529DC0EE04EA, 641B3CDCA88B45E2F6CDB39317423157FD31456D

Also, instead of using fixed 5m delay timer between sending LDP packet you could use a dynamic one. For example, sending first packet in 5m after uTorrent loaded, second after 20-30m (as new PC doesn't appear too often on the network). You could reset this timer back to 5m if user load new torrent to improve response time.

This would greatly reduce load on the network. If you consider large city-wide network with many thousands of customers and working multicast routing this should make sense.

@ Firon: Not yet, I'll contact them shortly. We are trying to get additional details on the problem and a way to reproduce it.

@Myx: Yeah, that's a good point. I've been wanting to do this for a long time. I'll try to squeeze in support for receiving multi-announce LSD messages, and in a future version we can switch over to sending them as well.

I would like to say multicast flood still issue for utorrent, basically you send updates to multicast address every 5 minutes if user having a lots torrent this will cause really heavy traffic, utorrent should throttle amount of multicast packets/second.

There is ISP who start blocking your switchport if you sending huge amount of multicast per second, this is automatically done to prevent network degradation. I can turn this feature off, but this prevent me to use local speeds to download/upload.

Please consider this as more like bug fix not feature request, I'll appreciate this, thanks!

Are you using a Zyxel modem yourself?

No i don't use Zyxel modem. If you want me to report this in new thread I'll do this.

This thread is basically about Zyxel modems replicating multicast packets to the point of flooding (each packet getting sent out dozens of extra times, etc etc) so yes your issue is separate.