uTP Analysis

[The_Don]

Hi Guys,

I have been watching utp over wire-shark. I notice occasionally a really odd packet comes through, I was wondering if anyone could shed any light on it. Below is an example. The conversation consists of three packets, always being sent from my host machine with no response from the destination.

The first packet is the expected SYN packet for utp v0 and third is the same. Which was correctly sent 3 seconds later. However between these 2 packets was some odd packet that doesn't seem to follow utp 0 specfication.

I have shown the hex dump of only the UDP data (i.e. utp). Therfore the 19th byte should be the packet type, which in this case is SYN (4), I have highlighted that byte to show packet 1 and 3 are as expected.

Packet 1:

0000   d7 1e 42 f5 00 00 31 e7 00 0a fd 3f 7f ff ff ff
0010   4a 02 [b]04[/b] 42 30 00 00 00 08 00 00 00 00 00 00 00
0020   00

Packet 2 (???) :

0000   64 31 3a 61 64 32 3a 69 64 32 30 3a 75 2b 70 b8
0010   7b 99 53 13 08 d4 ca dc ed e0 af a7 5d 2f 18 6a
0020   65 31 3a 71 34 3a 70 69 6e 67 31 3a 74 34 3a 44
0030   ed 30 9d 31 3a 76 34 3a 55 54 5c 97 31 3a 79 31
0040   3a 71 65

Packet 3:

0000   d7 1e 42 f5 00 00 31 ea 00 0a ee 2c 7f ff ff ff
0010   4a 02 [b]04[/b] 42 30 00 00 00 08 00 00 00 00 00 00 00
0020   00

Any idea what packet 2 is? I am using mutorrent 2.2. btw.

Thanks In Advance

Don

[arvid]

If you decode it to ascii it's: "d1:ad2:id20:...e"

This is a DHT ping packet. We always try to ping peers to see if they're in the DHT for two reasons:

1. If they are, we might want to add them to our DHT routing table

2. If they respond, we know they are alive, and a TCP connection attempt is less likely to fail with a timeout. For TCP connections, we prioritize peers who have responded to this ping, to save half-open TCP connection slots.

[The_Don]

thank-you very much arvid for the informative reply

So the same socket is used for mutp and DHT interchangeable. Are there any other protocols that run on top?