×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Network Measurement Tool Detects Reset Packets

kdawson posted more than 5 years ago | from the getting-it-on-record dept.

Networking 118

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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

118 comments

please allow me to introduce myself (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23598673)

I am a man of wealth and fame !!

Re:please allow me to introduce myself (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23599055)

Not anymore; -1 offtopic (so much for fame)
and the wealth part, that's about as likely as my big, whiteboy 10 inch (record)

Slashdotters would laud this, but... (4, Funny)

elrous0 (869638) | more than 5 years ago | (#23598745)

Without a Linux version, it's obviously the work of Satan.

Re:Slashdotters would laud this, but... (2, Insightful)

morgan_greywolf (835522) | more than 5 years ago | (#23598943)

Uh...it's LGPL. They give you the source. You wanna Linux version? Port it.

Can the eds learn to post headlines in English? (0)

Anonymous Coward | more than 5 years ago | (#23599051)

Network Measurement Tool to Detect Reset Packets

or

Network Measurement Tool Detects Reset Packets

Re:Slashdotters would laud this, but... (4, Insightful)

nmg196 (184961) | more than 5 years ago | (#23599723)

I hate it when people say "just port it" just because something is open source - Like every single computer user is capable of writing low level network code for any platform. I suspect that more than 99.9% of people of people who read slashdot would not stand a hope in hell of "porting it".

Re:Slashdotters would laud this, but... (4, Funny)

morgan_greywolf (835522) | more than 5 years ago | (#23599931)

I hate it when people say "just port it" just because something is open source - Like every single computer user is capable of writing low level network code for any platform. I suspect that more than 99.9% of people of people who read slashdot would not stand a hope in hell of "porting it".
And, yet, at least 50-75% of those (probably much, much more) 99.9% are capable of learning how to do the work. The Linux TCP/IP stack, NIC drivers, etc., are fully open source. There are published specifications, docs, the whole nine yards. Read your RFCs. They're all online.

Programming C is just not that difficult, especially for anyone who already knows how to code in at least one other language.

Don't know how to code? There are tons of tutorials, books, and more on the Web, at your library, at your local bookstore and from e-commerce vendors everywhere.

If you have a brain, and an IQ of at least, say 115 or so, you have no excuse.

Re:Slashdotters would laud this, but... (5, Insightful)

Bill_the_Engineer (772575) | more than 5 years ago | (#23600207)

I would like to give the benefit of the doubt to the original poster and interpret his comments this way:

If there was a ready made package for me to use, I would gladly help the monitoring effort. However, I find the mantra "just port it" not only a reactionary response, but also totally unrealistic.

Don't know how to code? There are tons of tutorials, books, and more on the Web, at your library, at your local bookstore and from e-commerce vendors everywhere.

If you have a brain, and an IQ of at least, say 115 or so, you have no excuse.

I find this totally hilarious and would have modded you funny if I had the points to give. You are a comic genius using the absurd to humorously make a point...

I mean it's like saying "If you are capable of reading all the books available on construction and building codes, then there is no excuse for you not being able to build your own house."

Of course I could be wrong and misinterpreted both of your responses, in that case nevermind...

Re:Slashdotters would laud this, but... (1, Funny)

ATMD (986401) | more than 5 years ago | (#23604083)

I'm sorry, but who modded this insightful? Because it isn't.

It's just plain common sense. The grandparent is just such an idiot that next to him, the frothings of a half-blind raccoon in the later stages of rabies would appear insightful, let alone someone who can string a sentence together.

(And do I get Insightful, Troll, or Funny? Or just ignored? I'll be interested to see...)

Re:Slashdotters would laud this, but... (5, Insightful)

Inner_Child (946194) | more than 5 years ago | (#23600333)

If you have a brain, and an IQ of at least, say 115 or so, you have no excuse.
Maybe your time is worthless, but I actually have things that I have to do. Learning to code requires time that I (and I'm sure many others) just don't have.

Re:Slashdotters would laud this, but... (1)

morgan_greywolf (835522) | more than 5 years ago | (#23602011)

Maybe your time is worthless, but I actually have things that I have to do. Learning to code requires time that I (and I'm sure many others) just don't have.
Changing my own oil requires time that I (and I'm sure many others) just don't have. When I want my oil changed, I hire a mechanic.

Re:Slashdotters would laud this, but... (2, Insightful)

Rycross (836649) | more than 5 years ago | (#23603593)

Yeah pretty much. My time is worth something to me, and I will pay to have someone save me time, if I deem the amount of time saved worthy of the price. Whats wrong with that?

Re:Slashdotters would laud this, but... (1)

morgan_greywolf (835522) | more than 5 years ago | (#23604415)

Nothing. When I say 'port it', this includes paying someone else to port it if it's really that important to you.

Weeping (1)

camperdave (969942) | more than 5 years ago | (#23600387)

And, yet, at least 50-75% of those (probably much, much more) 99.9% are capable of learning how to do the work.

I weep for the future if 25-50% of people are incapable of learning.

Re:Slashdotters would laud this, but... (0)

Anonymous Coward | more than 5 years ago | (#23600731)

114.99.

Well, fuck.

Re:Slashdotters would laud this, but... (1)

Perf (14203) | more than 5 years ago | (#23601431)

It's an issue of symantics...

If Slashdotters took time to learn C,
then they wouldn't have time to monitor Slashdot.

Therefore, they wouldn't be Slashdotters.

Re:Slashdotters would laud this, but... (0)

Anonymous Coward | more than 5 years ago | (#23601599)

Also, on the matter of wood chucks, even if a wood chuck could chuck wood, and the wood would get chucked by the wood chuck if the wood chuck would chuck wood, the wood wouldn't get chucked if the wood chuck wouldnâ(TM)t chuck it.

Re:Slashdotters would laud this, but... (5, Insightful)

blhack (921171) | more than 5 years ago | (#23601561)

If you have a brain, and an IQ of at least, say 115 or so, you have no excuse.
Thank you for completely trivializing a skill that some of us spend our entire lives perfecting.

Seriously, it is this sort of mentality that is killing tech. You DO have to be extremely smart/dedicated to do really low level CS work. You DO have to have a pretty heavy mathematics background to do any really serious code work and it is NOT something that you can "Learn in 7 days" no matter what the books you bought at borders are telling you.

Re:Slashdotters would laud this, but... (1)

morgan_greywolf (835522) | more than 5 years ago | (#23601965)

You DO have to have a pretty heavy mathematics background to do any really serious code work and it is NOT something that you can "Learn in 7 days" no matter what the books you bought at borders are telling you.
Really? You need advanced math degrees to understand TCP/IP, NIC drivers and such? Whoah! I gotta parse out this packet header! Better break out the calculus book! (Not.)

Re:Slashdotters would laud this, but... (1)

Mr Z (6791) | more than 5 years ago | (#23604295)

For a packet filter/pattern matcher like this, probably not. To understand the differences between all the load balancing, window resizing and congestion avoidance algorithms, as well as why and how they work, probably so.

Re:Slashdotters would laud this, but... (1)

wealthychef (584778) | more than 5 years ago | (#23603305)

It takes a long time to learn how to port code. You are totally understating the amount of work it takes to get from user to programmer.

Re:Slashdotters would laud this, but... (1)

Mister Whirly (964219) | more than 5 years ago | (#23601001)

If you want convenient software packages that are ready to go with absolutely no work on your end, I would suggest using Windows or OS X. If you know absolutely zero about programming, why chose a programmer's operating system? I mean really, this IS Slashdot where Open Source is the Greatest Thing Ever(TM) and can save the entire world from any ills...

Re:Slashdotters would laud this, but... (1)

hazah (807503) | more than 5 years ago | (#23602229)

You don't need 99.9% of people to create a port. You just need at least 1 capable person willing to do it.

Re:Slashdotters would laud this, but... (0)

Anonymous Coward | more than 5 years ago | (#23602633)

And the other 99.9% can pay him if they have more money than time. If they have neither, then they can shut the fuck up and quit whining about the way other people choose to spend their resources.

Re:Slashdotters would laud this, but... (1)

sjames (1099) | more than 5 years ago | (#23602813)

Then they can HIRE someone to port it. Perhaps a few people in the same boat can chip in together to pay for it to be ported.

The tool is probably written for Windows because Linux already has decent network analysis tools as part of most distros.

Re:Slashdotters would laud this, but... (1)

axeme (818895) | more than 5 years ago | (#23600815)

If you look in websys.h, you'll see a short block of definitions for making some portion of this compile under Linux. So maybe they were thinking of some portability.

Then there is also this on line 65: /* Hard to believe the Linux bozos tried to rename stricmp() */

tcpdump is much easier.

Re:Slashdotters would laud this, but... (3, Insightful)

lintux (125434) | more than 5 years ago | (#23599177)

As usually, Linux already has tools like this for ages, one just has to know how to use them:

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

Re:Slashdotters would laud this, but... (0)

Anonymous Coward | more than 5 years ago | (#23600519)

Too bad Linux doesn't have tools to make your RTFA before posting.

The tool in question detects *forged* reset packets, not ALL reset packets

Windows too... (0)

Anonymous Coward | more than 5 years ago | (#23600527)


C:\data>netstat -s | find "Reset"
    Reset Connections = 906

Re:Slashdotters would laud this, but... (1)

maxume (22995) | more than 5 years ago | (#23599197)

What about the Microsoft shills and Apple fanboys?

Also, I think one guy uses BSD.

No need to invoke Satan (2, Insightful)

Morgaine (4316) | more than 5 years ago | (#23599277)

> Without a Linux version, it's obviously the work of Satan.

Not really. It's just the work of somebody who doesn't hold portability as an important requirement.

Sometimes this happens because they don't have the means to test on other platforms. Sometimes it's because they're so narrowly focussed that they're not even aware that there's more to computing than their own platform. Some people are simply too lazy, or lacking in computing skills, to write portable applications. And quite frequently it's the work of someone who is totally obsessed with his own platform's unique UI and so produces an UI app that can't run anywhere else, without actually wanting to be evil.

Only very rarely does a minor wannabe Satan appear, one who willfully writes open-source code that can't be run on other platforms by design. I'm not even sure I can name a clear example of it ... mostly they're just lazy or uninformed.

Re:No need to invoke Satan (0, Funny)

Anonymous Coward | more than 5 years ago | (#23599431)

It usually starts with IWFM though YMMV and usually ends with RTFM and or STFU...

Re:No need to invoke Satan (1)

Mister Whirly (964219) | more than 5 years ago | (#23601123)

Or it is simply a matter of numbers. Windows = 85%+ marketshare so therefore writing a package for Windows = millions and millions of potential more users than writing a package for Linux. It's a simple explanation, especially if you apply Heinlein's Razor.

Re:Slashdotters would laud this, but... (1)

jbartas (1298737) | more than 5 years ago | (#23601147)

I wrote this, and yes, I was channeling Satan when I put it on Windows. I've ported a previous version to an embedded Linux platform, so I'm confident the NN Squad version could be ported to Linux, embedded or otherwise, in a few days. If there's enough interest I'll try it on Fedora 7 this weekend.
-JB-

Re:Slashdotters would laud this, but... (1)

Ungrounded Lightning (62228) | more than 5 years ago | (#23603853)

Without a Linux version, it's obviously the work of Satan.

http://en.wikipedia.org/wiki/SATAN">SATAN ran just fine on Linux. But it didn't sniff for forged RST packets.

Ignoring reset packets? (2, Interesting)

Ojuicer (1298565) | more than 5 years ago | (#23598779)

First the Chinese firewall, and now ISPs closer to home.
Of course the ISPs shouldn't be allowed to spoof any packets, but what would be the consequence of ignoring all reset packets on a home network?

RST blocking? (4, Interesting)

Applekid (993327) | more than 5 years ago | (#23598781)

IANANG (I Am Not A Network Guru) but, what harm could happen if, say, all reset packets were just ignored and dropped by the network stack? All the hubbub about figuring out if your ISP is sabotaging you seems less useful than just blocking the shanangans and moving on with your life.

Re:RST blocking? (5, Interesting)

cduffy (652) | more than 5 years ago | (#23598843)

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

Re:RST blocking? (1, Informative)

Anonymous Coward | more than 5 years ago | (#23599071)

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:RST blocking? (2, Informative)

Hal_Porter (817932) | more than 5 years ago | (#23601273)

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.

Re:RST blocking? (2, Informative)

Ed Avis (5917) | more than 5 years ago | (#23599487)

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:RST blocking? (1)

cduffy (652) | more than 5 years ago | (#23599929)

Just so. It's almost a shame opportunistic IPsec came out years too early for most folks to see the need; I imagine it'd get much more attention if it were something big, new and shiny today.

Re:RST blocking? (2, Interesting)

Anonymous Coward | more than 5 years ago | (#23600923)

Opportunistic IPSec runs into the problem that you need a pre-shared secret ("PSK") or a public key infrastructure ("PKI"), otherwise malicious persons will simply do man-in-the-middle attacks on the key exchange, so they can do deep inspection of the encrypted traffic anyway (they just have to add decryption to the inspection process).

The net result of IPSec (or TLS) without strong authentication of both parties is that each packet consumes considerably more energy on the transmit and receive end systems, and any snooping middle system(s).

At best you get protection from trivial sniffing and injection attacks. That is not necessarily bad, but anyone actually doing deep inspection is already in a position to do more than trivial sniffing and injection.

PSK is difficult to scale to large numbers of counterparties, especially since you really want to do PSK out of band, and cope with compromised shared secrets. For small numbers of stable connections with known parties (as with a corporate VPN), PSK is a useful approach. For large numbers of connections with random parties, PSK scalability becomes really difficult, and is largely an unsolved problem (i.e., the "fix" is to use PKI).

PKI suffers from trust issues, namely who do you trust as an introducer. Usually that is done for you by the writer of a library (openssl, for example) or a tool (curl or wget, for example) or a browser, or an OS vendor, or some combination of these (either and-wise or inclusive or-wise). By default, everyone seems to trust Verisign among others. Alternatively, webs of trust are in use, and these suffer from the Kevin Bacon effect -- if you do not know Kevin Bacon, you have to trust someone when he or she claims to know Kevin Bacon, or one of Kevin Bacon's friends, or ... etc. Scalability is awkward, and key distribution becomes a point of failure, since you don't just "build in" a small number of top level certs.

Opportunistic IPSec originally anticipated using DNSSEC as a PKI database. This hasn't worked especially well for a variety of reasons; TLS's PKI system won in the marketplace and will be hard to dislodge, especially as it is increasingly integrated with authorization (and user authentication) systems like SASL.

Most crypto users seem not to turn on ephemeral key negotiation, for example, with Ephemeral Diffie-Hellman session key exchange. EDH is computationally expensive (and requires some handshaking) but without an ephemeral key exchange you are unlikely to have forward security. That means if a certificate is compromised, all sessions protected under that cert are compromised, including those sessions recorded "ages ago". Lots of X.509 certificates are in use now that are fairly weak already, and will be very weak within a couple of years. Some of these certificates supposedly protect information that will still be useful to attackers after those couple years are up...

Crypto is not a bad idea just because it doesn't protect one against determined traffic shapers; the general goal of TLS and IPSec is to make it much more attractive to use social engineering or other attacks on human beings, than to try to do cryptanalysis or other attacks on intercepted (or recorded) traffic. Unfortunately the two methods compose well; record traffic now, seduce/force a human being into giving you the key to decrypt it later. EDH/cycled-ADH with strong PKI certificates are the only well-known way to reduce that particular compositional problem.

Finally, the reality is that most P2P users *don't* want to be strongly identified, so authentication of counterparties is simply not a goal. In that case, crypto does very little except in the short term.

Re:RST blocking? (0)

Anonymous Coward | more than 5 years ago | (#23599639)

You can call them and ask?

Re:RST blocking? (1)

justthinkit (954982) | more than 5 years ago | (#23600975)

IAANANG but what if, and I'm just spitballing here, an alternate network stack is written. It allows user-designated programs to tap into the "sample everything" trough, and does standard network stack stuff for every other program. When you install AltNS it asks for some 2000 byte random string and you have to provide that on a case-by-case basis whenever you want to allow a new progie to snoop everything. Ok, I worded that like crap but I think my drift has been cast, to the four sheets.

Re:RST blocking? (1)

Eponymous Bastard (1143615) | more than 5 years ago | (#23602587)

Wait for the FIN packet? ...But apparently Linux uses RSTs anyway...

Oh, I know, wait for the second RST. When you get one, ignore and respond with an ACK or keepalive. IIRC, if the other side did close the connection, any extra packet is answered with another RST (Not sure about an empty ACK though).

If you receive a packet with a higher sequence number, the original RST was fake. If you get a second RST you acknowledge and close.

I'm not sure if you could do this at the firewall level or if you'd need to modify the TCP stack.

Then again this goes against the robustness principle of the Internet (be careful with what you send, forgiving with what you receive). It would be better to stop Comcast legally than to modify TCP and send exta packets without very careful study.

Re:RST blocking? (4, Interesting)

Zocalo (252965) | more than 5 years ago | (#23598891)

Assuming that you have a device capable of doing so, which I doubt many SoHo router/firewalls are, then there are not too many issues with dropping RST packets, and none of the them are show stoppers. It'll take a little longer before your web browser or whatever can determine that the remote site is genuinely down or otherwise refusing connections but that's about it from the "end-user" point of view. If you have a Linux proxy box however, then IPTables is perfectly capable of doing this for you, and can even do so in a sensible way - ie. just for BitTorrent traffic, just to pick a protocol at random.

Re:RST blocking? (3, Insightful)

yabos (719499) | more than 5 years ago | (#23599309)

If you can do that with iptables then you could do it with a home router and a 3rd party firmware on it. DD-WRT has iptables and I believe Tomato does as well.

Re:RST blocking? (0)

Anonymous Coward | more than 5 years ago | (#23604431)

Assuming, of course, that your router is supported by a 3rd party firmware.

Re:RST blocking? (1)

hawg2k (628081) | more than 5 years ago | (#23603825)

If they're sending RST packets, won't they be sending it to both parties? Just because you ignore them, doesn't mean the other end will. At best you'll have a half open socket, which is basically the same (or maybe worse) than a completely closed socket, no?

Re:RST blocking? (0)

Anonymous Coward | more than 5 years ago | (#23598971)

Please hand over your slashdot account.
This question was not worthy a geek.
We greet ourselves with SYN - SYN/ACK - ACK before engaging a conversation.

Re:RST blocking? (1)

Flamora (877499) | more than 5 years ago | (#23599087)

If you're not happy with the content of the current stream, inject a RST in there instead of just making noise about it.

Re:RST blocking? (1)

Alioth (221270) | more than 5 years ago | (#23600611)

I'm surprised a UDP based filesharing protocol hasn't emerged because of this, allied with an automatic system that signs each UDP packet. That way, if the ISP got "smart" and injected fake UDP packets containing the command to end the transfer, it could easily be determined as fake since its signature would be incorrect.

Re:RST blocking? (1)

steve_ellis (586756) | more than 5 years ago | (#23601069)

The biggest problem with just dropping RSTs is that you can't stop the RSTs going to the other end of the connection--your torrent client may still think the session is open, but your peer will think that it is closed. RST is typically only used for abnormal termination, FIN (and the corresponding FIN/ACK) are used for 'normal' session closing. There is some additional risk to dropping RSTs in that over time all sessions that were supposed to be terminated 'abnormally' will linger, possibly forever, but if you only did RST dropping on the port you used for bittorrent, you could easily monitor them (and perhaps kill them manually, if necessary, if/when you stop your bittorrent client.

tcpdump? (1, Interesting)

FudRucker (866063) | more than 5 years ago | (#23598793)

i wonder if this job could be done with tcpdump in Linux?

http://www.tcpdump.org/ [tcpdump.org]

Re:tcpdump? (0)

Anonymous Coward | more than 5 years ago | (#23599243)

Yes, it can.

The evolvong nature of "open" (2, Interesting)

utnapistim (931738) | more than 5 years ago | (#23598813)

This just highlights the evolving nature of open ... protocols? (it's more than the software).
I believe new software will appear that works around the next attempt to block torrents, and new software to go arround the one after that ...
If there is a big-enough interest in code/protocol changes, and the code / protocol is open, you can't "put a stop" to it.

Well ... not for long.

Not sure what the point is (4, Insightful)

Moraelin (679338) | more than 5 years ago | (#23599193)

I'm not entirely sure what your point is, and if it's supposed to be a good or a bad thing.

What would happen on a closed proprietary protocol? (E.g., let's imagine that MS had pursued their initial idea of makingt a MS net instead of the Internet, or that AOL/Compuserve/whatever had never gone TCP/IP and managed to win on their own, or that we all were on the French minitel. Or, heck, that each ISP had their own protocol and proprietary browser, and just converted to and from it. At least one did try to convert the graphics like that, and at least one is currently re-encoding movies, so it's not a huge stretch of imagination.)

Well, then you'd be pretty much in the hands of whoever owns the protocol, i.e., most likely the ISP. If you were on, say, a proprietary AOL network, which works only with proprietary AOL software, and uses AOL's own proprietary protocols, then you're completely at their mercy. If they want to reset your connections, or whatever else, what are you going to do about it?

Of course, you could reverse-engineer their protocols and patch their programs, which is a hell of a lot more expense and effort than with the open protocols. Except then they could:

1. Just change the protocol from one version to another, to break your changes. (AOL actually did this for a while to keep breaking MS's attempts of making their Windows Messenger interoperable with AIM.)

2. Sue you under DMCA for hacking into their network and bypassing their checks. (Seriously, much smaller attempts at reverse-engineering a protocol resulted in DMCA lawsuits.)

So basically at best you'd have to bet a _lot_ on, well, how sympathetic a judge would be to your view that you have a right to bypass the usage or access restrictions on privately owned servers, to download more than you've bought, and to hack their software to that end. I wouldn't take it as a given.

So basically open software at least gives you a fighting chance at all. Yes, they can keep modifying their implementation, but so can you. In the closed version, they own the software and the protocol, they can change it, but _you_ can't.

Open standards even put a limit on how far they can take technique #1 above, because at the end of the day, they still have to remain compatible with a metric buttload of software and hardware that they don't control. In the all proprietary version, if they want to change the protocol and software _completely_, and leave the old channel open just for downloading the new software, they can.

Re:Not sure what the point is (1)

utnapistim (931738) | more than 5 years ago | (#23599519)

I'm not entirely sure what your point is, and if it's supposed to be a good or a bad thing.

It's a good thing: due to the open nature of the torrent protocol, I think we will see changes in the torrent clients, that will make the current sabotage attempts obsolete.

Grammar? (1, Insightful)

Thornburg (264444) | more than 5 years ago | (#23598857)

Um, sorry, but "Network Measurement Tool Detect Reset Packets" is not a proper grammatical structure. It could be "Network Measurement Tool Detects Reset Packets" or "Network Measurement Tool to Detect Reset Packets" or several other things, but right now it has a problem.

Aside from that, it's great the people develop tools like this, but very surprising to see this be Windows-only.

Re:Grammar? (3, Interesting)

Vectronic (1221470) | more than 5 years ago | (#23599001)

From The Site:

Please let us know if you're interested in coordinating on ports to other platforms, such as Linux, BSD, and Mac, or embedded hardware (e.g. WRT54G router).

Special thanks to John Bartas for all of his diligent and continuing work on this software for NNSquad.
So, I would assume that its just the one guy working on it (at the moment) which would explain why its Windows Only, its probably his chosen platform.

Re:Grammar? (1)

TooMuchToDo (882796) | more than 5 years ago | (#23600447)

Or, perhaps, he just wanted to make it available to a wider audience. Linux on the desktop usage is still a fraction of all desktops.

Too bad (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#23598889)

Too bad they didn't release it for any good operating systems.

Satan Prevails - A distributed Get Your Hands Off (3, Funny)

itsybitsy (149808) | more than 5 years ago | (#23598895)

How about setting up a firewall with our own deep packet inspection and reporting system? That way we can collectively scan, identify, analyze, report to a central site, aggregate the results, perform large scale analysis, and report the full results on all kinds of attacks on these firewalls around the world.

A distributed Get Your Hands Off My Network. This information can be used to provide Objective Evidence for Court Cases Against Aggressive ISP and Those Who Pretend To Be The Governments And Homeland Security Departments of The ~192 Imagined Countries Around The World. It's about time that these pretenders, who do real harm to other people in the world to, know that they are not the only ones with some power. We tech geeks say hands off our Internets and we are watching and reporting on YOU BIG BROTHER!

Power the the Geeks.

Network Measurement Tool Detect Reset Packets (5, Informative)

HPUXCowboy (735911) | more than 5 years ago | (#23598939)

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: Network Measurement Tool Detect Reset Packets (4, Interesting)

CogDissident (951207) | more than 5 years ago | (#23598973)

Well yeah, but having a tool where you can have joe-average download it, press a button, and get all upset at Comcast has much more value.

The race is on (3, Insightful)

bytesex (112972) | more than 5 years ago | (#23598953)

Because, of course, ISPs could also forge legitimate looking TCP RST packets.

Re:The race is on (2, Interesting)

Vectronic (1221470) | more than 5 years ago | (#23599135)

Yeah, and when that fails just cut the internet off... "just doing some routine maintenance"

Im becomming suspicious of my ISP for that reason, aside from obvious traffic shaping (which I usually dont mind too much), they also just drop the internet entirely but leave the network intact, so any computers still think there is internet but it goes no further than the ISP, upon which I start fucking with their servers until I get internet back. (you know, 'boredom')

Re:The race is on (1)

jonaskoelker (922170) | more than 5 years ago | (#23599299)

Because, of course, ISPs could also forge legitimate looking TCP RST packets.
If you read the methodology [nnsquad.org] page, you'll learn that:

It's much harder to fake the timing of a spoofed reset.

This round trip time (RTT) is tracked internally by TCP protocol layers, however it can also be measured by external monitoring devices or software at the endpoints.

When sending bulk data during a TCP connection, the RTT between two TCP endpoints usually settles into a narrow, predictable range. Spoofed resets which are injected into the stream will usually have an RTT well below the measured average.

Reset packet spoofers could attempt to evade this detection technique and improve their "stealthiness" by first measuring the RTT of a connection that they are planning to disrupt, then delaying the transmission of their spoofed reset until timing falls within the "expected" RTT. The problem with this approach is the significant risk that the spoofed reset will arrive too late from the standpoint of the receiving endpoint.

In short, spoofed resets have only a relatively narrow time window in which they can be both effective at disrupting connections and simultaneously be resistant to detection as potentially anomalous events.
So yeah, in theory the ISP could, but anomalies are detected in a way that's hard to get around and still work.

Cool (1)

Taibhsear (1286214) | more than 5 years ago | (#23599021)

Now I can help prove they are spoofing packets not only my torrents but my browsers and games and normal effin' downloads from websites. (Took me two days to legally download a 400MB file from a legitimate website because the transfer would stop halfway through and I'd have to start from scratch all over again. Did this 8 times over the two days for the same damn file.) At least I'm hoping it will help. I have not RTFA. This is slashdot afterall...

Re:Cool (3, Informative)

Culture20 (968837) | more than 5 years ago | (#23599363)

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.

Just drop SYN packets (0)

Anonymous Coward | more than 5 years ago | (#23599525)

Over here at B*Tard ISP we simply drop 4 out of every 5 inbound SYN packets. We find it solves most of our bandwidth issues.

Throttling should not use RESET (3, Interesting)

redelm (54142) | more than 5 years ago | (#23599923)

Not that [ISP] managment have ever been known for great intelligence, but throttling connections via RESET is just plain dumb. The client will just retry and extra data transferred.


The correct (and difficult to detect) way of throttling is by delaying ACK packets a few ms. Then normal TCP congestion control does all the nice throttling for you.


The ethics of throttling are a different matter: one side says they've been promised unlimited, and the other wants to be fair to all customers.

Re:Throttling should not use RESET (1)

kickassweb (974862) | more than 5 years ago | (#23600445)

"The ethics of throttling are a different matter: one side says they've been promised unlimited, and the other wants to totally forgo any network improvments and buildout that would allow tolerable connection speeds, and block any possible competition of their movie download business." There, fixed that for you.

Re:Throttling should not use RESET (0)

Anonymous Coward | more than 5 years ago | (#23601349)

isn't it what ICMP is for?

other solution to reset packets against p2p (1)

hejish (852589) | more than 5 years ago | (#23599973)

do something like 5.8Ghz phones and spread spectrum - use LOTS of "random" ports, initiate them from behind the firewall to make sure they'll get back through and boom comcast has more fun to work against!

Not directly relevent, (1, Interesting)

Anonymous Coward | more than 5 years ago | (#23600097)

A good friend of mine works for Shaw Cable in their bandwidth monitoring department and has told me that they do not do any kind of traffic shaping.

He says it's just three guys (only one on at a time afaik) and when they see someone using to much bandwidth, they phone them up and tell them to settle down with the downloads.

Re:Not directly relevent, (2, Interesting)

Jabrwock (985861) | more than 5 years ago | (#23601133)

A good friend of mine works for Shaw Cable... He says it's just three guys (only one on at a time afaik) and when they see someone using to much bandwidth, they phone them up and tell them to settle down with the downloads.
I got one of those calls, and the guy I spoke with couldn't tell me what "grey zone" I'd wandered into, or why my unlimited account... wasn't. I asked him what I should cap my d/l rate to, so I wouldn't get these calls, and he said there wasn't a limit "per se". So I asked him why he was calling me with a vague request to stop using so much of a service he couldn't define for me. No answer.

I've since switched to Sasktel. While it's a lower max bandwidth, I don't have to share, and I don't get a phone call asking me to "tone it down" when I use my account for more than just email...

Re:Not directly relevent, (0)

Anonymous Coward | more than 5 years ago | (#23601375)

I'm not sure when this might have been, but shaw has defined limits on their website.

High Speed Lite: 10GB/month
High Speed: 60GB/month
Extreme: 100GB/month
Nitro: 150GB/month

It's possible the guy you spoke to was new and didn't know what the defined limits are. My friend says they don't call unless you cross over those defined limits.

I guess my friend can only speak for Shaw Cable in the city he works for though.

Re:Not directly relevent, (1)

Jabrwock (985861) | more than 5 years ago | (#23601759)

I'm not sure when this might have been, but shaw has defined limits on their website.... It's possible the guy you spoke to was new and didn't know what the defined limits are. My friend says they don't call unless you cross over those defined limits. I guess my friend can only speak for Shaw Cable in the city he works for though.
This was a few years ago, before they set up their limits. He was just harassing me for "hogging the node", but Shaw marketing hadn't defined what the "limit" was yet. So he really had nothing to guide me with.

When I called Sasktel, I spoke to a tech, and asked him if there were any limits to how much I could download in a month. He was confused by the question, because Sasktel is DSL, so you don't share it at all. If you max out your "tube" 24/7, they don't care, because you paid for all of it. So I switched right then and there. I'll take lower guaranteed bandwidth over "sometimes" bandwith, "as long as you don't use too much of it during a month".

Also at the time I was on Shaw's "regular" high speed, and he said that downloading 40Gb in a month was "too much". "Too much" being defined depending on how much everyone else on your node downloaded. I was #1 for my node, so I was the "too much" person. Had someone else downloaded 45Gb that month, I would have been fine, and they would have been the "too much" phone call... At least that's the gist I got from the way the conversation was going...

Normal to have lots of RSTs in HTTP traffic (1)

asifyoucare (302582) | more than 5 years ago | (#23600345)

I've written my own software to track RSTs among other things (thankyou JPCAP and TCPDUMP) and RSTs are very common in HTTP traffic. I have assumed this is because it is more efficient to tear down a TCP sessions with RST than it is with FIN/ACK, combined with the fact that web traffic tend to generate lots of TCP sessions per page.

How are you going to tell a fake RST from a real one (and no, I haven't RTFA)?

Re:Normal to have lots of RSTs in HTTP traffic (1)

Culture20 (968837) | more than 5 years ago | (#23603779)

How are you going to tell a fake RST from a real one (and no, I haven't RTFA)?
Just a guess, but if the server on the other side still is sending data after the RST hits you, it's a sign that it didn't send the RST.

'dotted. (1)

Nullav (1053766) | more than 5 years ago | (#23601041)

Or it may as well be. On the bright side, I did just learn a great lesson about the importance of download mirrors.

can't get there from my comcast connection.... (1)

prennix (1069734) | more than 5 years ago | (#23601647)

funny, I can't get to the site from my comcast connection. Getting there just fine from work, so likely not the /. effect...

Got reset packets while downloading this tool! (0)

Anonymous Coward | more than 5 years ago | (#23601913)

Cant believe ISP are adding that site to their blacklist!

problematic detection methodology? (1)

paleshadows (1127459) | more than 5 years ago | (#23602577)

This link [nnsquad.org] describes the manner by which problematic reset packets are detected. Apparently, an RST packet would be flagged as generated by the ISP based on the time at which it arrives, namely, if it arrives too early, or too late:

spoofed resets have only a relatively narrow time window in which they can be both effective at disrupting connections and simultaneously be resistant to detection as potentially anomalous events.
The question is what prevents the ISP from sending the packet within the said "narrow time window" and thereby avoid detection?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...