Network Measurement Tool Detects Reset Packets

kickassweb writes "If you think your ISP is sniffing packets, or worse yet, sending reset packets to stop torrents, there's now a beta Network Measurement Tool to detect them, courtesy of Lauren Weinstein of the Net Neutrality Squad. It's released under the LGPL, and runs under Win2K, XP, and Vista. Quoting: 'While the reset packet detection system included in this release is of interest, NNSquad views this package as more important in the long run as a development base for a broad range of network measurement functionalities and associated communications and analysis efforts.'"

Network Measurement Tool Detect Reset Packets

[HPUXCowboy]

I would point out that a tool has existed for years that possessed this capability AND has been available on BOTH Linux (*NIX) and M$ platforms. It's called Wireshark (formerly Ethereal). I will offer the caveat that you had to know a bit about TCP/IP protocol to use this tools but, there it is.

Re:RST blocking?

[Anonymous Coward]

You waste some bandwidth sending more packets to them, and some time waiting for the connection to timeout.

Neither of which really matter - after all packets get dropped often enough anyway, the internet doesn't come to a screeching halt when an RST packet happens to be dropped somewhere...

Re:Cool

[Culture20]

I always use
wget -c <URL>
to download large files. Even when your ISP is on the up and up, you'll get a RST occasionally if the remote computer sends it. Using wget to continue an almost completed download of an iso or XPSP3 is really handy.

Re:RST blocking?

[Ed Avis]

Without RST packets, how are you supposed to know if the remote host is legitimately closing the connection?

Um, IPsec?

Point is, if your ISP spoofs RST packets, you cannot know when the remote host is legitimately closing the connection. If you get such a packet it could be genuine or it could be a fake. So it doesn't tell you much. You need some means for the remote host to sign every packet it sends out so they can't be spoofed, or else stop trusting them.

Re:tcpdump?

[sukotto]

tcpdump 'tcp[13] & 4!=0'

Re:RST blocking?

[tatsu69]

They send you a FIN packet. RST is only for exceptional situations.

Re:RST blocking?

[Hal_Porter]

the internet doesn't come to a screeching halt when an RST packet happens to be dropped somewhere...

No, because there's a timeout in the TIME_WAIT state. As far as I can tell RST packets are a way to break the connection and allow the TCP/IP stack to know that the socket is no longer in use.

I think if you ignored RST packets you'd end up with more sockets stuck in TIME_WAIT rather than being closed. Of course you could just increase the size of the socket table to compensate for entries getting stuck in TIME_WAIT or decrease the timeout or both.

But actually I found another problem. The forged RST packets are sent to both parties in the Bittorrent connection. So all the people downloading would need to hack their TCP/IP stacks to ignore RST packets and cope in that situation. And the ISP could block the connection after it sends RSTs, so even if you ignored them you'd be out of luck.