By supergrobi | January 30, 2007
Today, supergrobi explains how a connection to a tracker should NOT look like!
You ever wondered why it seems that our tracker answers your announce requests with an RST packet thus destroying your connection? Think again! It is your ISP who tries to kill your connection without admitting it to save bandwidth for which you probably paid money.
Lets look how an ordinary TCP connection is set up.
First you send a SYN packet to the tracker:
03:38:07.763665 IP (tos 0x0, ttl 104, id 28391, offset 0, flags [DF], proto: TCP (6), length: 48) 18.104.22.168.1737 > 22.214.171.124.6969: S, cksum 0x764c (correct), 3957760381:3957760381(0) win 16384
Our tracker answers this with a SYN and ACK:
03:38:07.763687 IP (tos 0x0, ttl 64, id 51007, offset 0, flags [DF], proto: TCP (6), length: 48) 126.96.36.199.6969 > 188.8.131.52.1737: S, cksum 0x0bcb (correct), 2652573014:2652573014(0) ack 3957760382 win 65535
Your clients also acknowledges this with an ACK:
03:38:08.163338 IP (tos 0x0, ttl 104, id 28398, offset 0, flags [DF], proto: TCP (6), length: 40) 184.108.40.206.1737 > 220.127.116.11.6969: ., cksum 0xf31d (correct), ack 1 win 17520
Now both ends of the connection have exchanged the sequence numbers (3957760381 and 2652573014) – the client could send the actual request to the client. But look closer and see what happens next:
03:38:08.165227 IP (tos 0x0, ttl 13, id 0, offset 0, flags [DF], proto: TCP (6), length: 62) 18.104.22.168.1737 > 22.214.171.124.6969: R, cksum 0xf303 (correct), 1:23(22) ack 1 win 17520 [RST 00000000000000000000000000000000000000000000]
This is an RST packet which destroys the connection no matter what. The tracker will not accept any more packets from this connection after it received this RST packet. So this client will never get any peers from our tracker.
But why did I choose the peculiar title of this blog entry? This RST is NOT sent by the client – it is injected. It even has a different TTL and a payload of 22 bytes filled with zeros which is unusual AND useless for an RST packet. Let’s look at the next packet:
03:38:17.151116 IP (tos 0x0, ttl 104, id 29025, offset 0, flags [DF], proto: TCP (6), length: 471) 126.96.36.199.1737 > 188.8.131.52.6969: P, cksum 0xddd8 (correct), 1:432(431) ack 1 win 17520
This is the actual announce request from client to tracker. But it comes ca. nine seconds later and has the same sequence number as the RST packet. So one of both packets is injected. You can guess which! Since our tracker has no state for this connection anymore it will answer this request with another RST, which is normal behavior.
So what happened here? After some head scratching and googling we think we can explain it. Somewhere between client and tracker sits a filter. THEY use it to sniff the first data packet of a connection. There is not so much else THEY can do to detect bittorrent traffic. Bittorrents tracker protocol can use any port and uses HTTP GET request for its tracker⇔client communication. So THEY need to look inside packets and scan for strings like ‘info_hash’ (‘info_hash’ is unavoidable because it is part of the bittorrent spec).
Once THEY identifiy that it is a bittorrent announce request, THEY drop it and send an RST packet instead. Some ISPs do not send such an RST packet back to the client. Your client still waits for an ACK for this request packet. But our tracker got THEIR RST packet and will not send this ACK, so your client is sending the announce request again. Since THEIR filter only sniffs the first data packet of a connection (it would be too much work to inspect every packet from every connection) this packet does not get filtered and arrives nine seconds later at the tracker.
Actually once we tried to filter incoming RST packets for our tracker, enabling us to successfully answer the arriving (second) announce request packet. The problem is, that we can not filter the RST packets from the whole internet because it costs us too much open sockets while it generates alot of connections in a wait state (they invented this RST flag with a reason after all!).
So if anyone has some suggestions how this ISP p2p blocking can be avoided, leave a comment.