Search:  

 
 
   News
newer
Tools To Test Your ISP For BitTorrent Shenanigans
Network Neutrality Squad releases beta NNMA tool
(old news - 03:36PM Friday May 30 2008)
tags: business · software · networking
When Comcast was discovered using forged TCP packets to throttle upstream connections, it spawned a flood of new user diagnostic tools aimed at helping users detect whether their ISP was engaged in P2P tomfoolery.


First came the EFF's Test Your ISP Project, which walks users through using Wireshark to detect packet forgery. Then came an Azureus plugin, though it could't differentiate between intentional or circumstantial RST resets. Most recently came the Glasnost Project, a more sophisticated test that uses multiple criteria before accusing an ISP of interfering with BitTorrent traffic.

The latest tool comes courtesy of the "Network Neutrality Squad," a group created last November to encourage dialog between both sides of the network neutrality debate. According to the project website, the NNSquad Network Measurement Agent (NNMA) is based on the open source "Buster" network management and security program. The new tool was designed to look for and flag a variety of ISP throttling efforts. Keep in mind it just entered beta.

"The idea is to *try* to highlight resets that seem out of place in terms of timing, which could be one indicator of an injected reset," Network Neutrality Squad's Lauren Weinstein tells me. "But none of this is 100% of course, there are lots of issues, and this is beta software to be pounded on in the field so we can learn more and build on the platform," he says.

I can't vouch for quality since I just installed it myself (I have concluded my Wii is getting unfettered access to the Interwebs!), but perhaps some of you can lend your tweaking and testing help to the project. It looks like they're looking for help in porting the app to other platforms, such as Linux, BSD, Mac, or third-party firmware upgradeable routers (WRT54G, etc.).

Related:
  1. Joost Beta Now Available To All
  2. Google Hijacking 404 Pages?
  3. Verizon Wireless Preps 'Open Access' Tier
  4. New Google Tools Test ISP Traffic Discrimination
  5. Four Hour Google Outage Makes Bloggers Cry
  6. Valve's Pipe Dream Now Gigantic
  7. Wednesday Evening Links
  8. Google Starts Discussion About Speeding Things Up
Forums » Tools To Test Your ISP For BitTorrent Shenanigans
view: topics flat text 
Post a:

JamesPC

join:2005-10-12
Orange, CA

1 edit

good for me

I guess I am getting good access while running Azureus on my RR connection. Click on your computer for a good look at what your connected to. Some kool things for a beta.

MxxCon

join:1999-11-19
Brooklyn, NY
clubs:

Re: good for me

indeed, it's showing some interesting data.
and it can even work as a firewall.
but for some reason after a few seconds cpu usage jump to 100%

Hehe

@ssa.gov

Can we block the reset packets?

It would be cool if we could detect and block these reset packets! A rule on the firewall! Or maybe an iptables module?

MxxCon

join:1999-11-19
Brooklyn, NY
clubs:

Re: Can we block the reset packets?

impossible and idiotic request.
RTS packets are an integral part of TCP protocol. blocking them will completely destroy your internet connection.
realtime detection methods are inaccurate so any block rule will have HUGE false positive rate.
the only accurate way to detect faked RST packets is by comparing traffic from both sides and see if one generated the given RST packet to the other.

funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype

Re: Can we block the reset packets?

said by MxxCon See Profile :

impossible and idiotic request.
RTS packets are an integral part of TCP protocol. blocking them will completely destroy your internet connection.
realtime detection methods are inaccurate so any block rule will have HUGE false positive rate.
the only accurate way to detect faked RST packets is by comparing traffic from both sides and see if one generated the given RST packet to the other.
After a 2-way connection has been established, a Reset (RST) flag should only be generated by the far end if it has crashed. However, all of the forged RST packets generated by Sandvine come in within the same second as a previous genuine packet from the remote host. This being the case, it would be possible to detect a bogus RST packet and react to it differently or discard it.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
HTTP is the new Bandwidth Hog...

MxxCon

join:1999-11-19
Brooklyn, NY
clubs:

Re: Can we block the reset packets?

you know perfectly well if the far end crashed, it wouldn't generate RST. it wouldn't generate anything at all.
RST would be generated if far end decided to close the existing connection, which can be a valid request.
some bittorrent clients want to connect only to seeds, so the moment they see it's not a seed, they will abort such connection generating RST. blocking such packets will break your application

funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype


1 edit

Re: Can we block the reset packets?

said by MxxCon See Profile :

you know perfectly well
With respect, your unnecessary attitude toward others does not promote friendliness. You called the previous poster's idea idiotic and you're being condescending to me.

In this case, you misunderstand how RST works. These are just facts, nobody wins or loses on the strength of their debating skills. It is whatever it is. We both learn about it by being here.

said by MxxCon See Profile :

if the far end crashed, it wouldn't generate RST. it wouldn't generate anything at all.
Right, but when network devices crash, they often reboot. When they come back up with no memory of the pre-crash states, then start receiving TCP packets on a closed port, they send RST in response.

This specific example is explained in RFC 793, Figure 11 (either page 34 or 35).

said by MxxCon See Profile :

RST would be generated if far end decided to close the existing connection, which can be a valid request.
If the far end decided to end the existing connection, FIN should be sent, not RST.

Anything is possible (there's an older Microsoft webserver that sends RST to kill the FIN's TIME_WAIT interval), but these exceptions are rare and usually pointed out as mistaken implementations.

said by MxxCon See Profile :

some bittorrent clients want to connect only to seeds, so the moment they see it's not a seed, they will abort such connection generating RST. blocking such packets will break your application
As said above, FIN not RST, is what should be sent. FIN completes the connection gracefully. RST can cause the loss of sent-but-unacknowledged data.

You can see this using Wireshark.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
HTTP is the new Bandwidth Hog...

Hehe

@ssa.gov

Re: Can we block the reset packets?

Well, looking at the RFC it seems like we should not receive a RST while the connection is in the ESTABLISHED STATE. So, maybe we can drop RST if ESTABLISHED?

Anyone know how to make iptables do that?

And I assume I am not 100% correct!
It just can't be that easy.

funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype

Re: Can we block the reset packets?

said by Hehe :

Well, looking at the RFC it seems like we should not receive a RST while the connection is in the ESTABLISHED STATE. So, maybe we can drop RST if ESTABLISHED?

Anyone know how to make iptables do that?

And I assume I am not 100% correct!
It just can't be that easy.
RFC 793, Figure 11 would happen with one end in the Established state, thinking it was in a full-open connection when it actually is only in a half-open connection due to the remote host's reboot.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
HTTP is the new Bandwidth Hog...

knightmb
Everybody Lies

join:2003-12-01
Franklin, TN
·AT&T DSL Service


1 edit

tested with some screenshots

Click for full size
Downloading the *cough* Linux ISO called Indiana Jones and something

Alerts for RST packets
 
Click for full size
Software Screenshot, all runs from browser
For those that haven't had a chance to test it. I went my favorite linux ISO downloading website called the pirate bay. I looked for a large ISO to download that had a lot of seeders to test with. That "Indiana Jones and the something" Linux ISO looks like a good test, so I started a download with that one.

After a few minutes in, I was watching the NNMA software.

After it was done downloading, I counted up about 3 alerts for RST packets, which may be due to either Comcast or maybe the ISP I was connecting with, hard to tell?
--
Fight NebuAD and the like:
Click Here to pollute their data

Doctor Four
My other vehicle is a TARDIS
Premium
join:2000-09-05
Dallas, TX
·AT&T U-Verse


1 edit

Re: tested with some screenshots

It could have something to do with the default BitTorrent
port of 6881. A lot of trackers block that port, which is
why Azureus recommends using a high numbered port between
49152 and 65535.

Also, I've read of instances of Comcast users not seeing any
forged TCP resets. Perhaps it is only occurring in major
markets with saturated nodes.
--
"The trouble with computers, of course, is that they are very sophisticated idiots." - Doctor Who (from Robot)

RR206

join:2001-12-11
Renton, WA
clubs:

Wide open on Qwest

It's showing everything wide open on my new 12mb Qwest line. I don't feel like plugging comcast back in to test it.

Packeteers
Premium
join:2005-06-18
Forest Hills, NY

no complaints on Verizon

according to their web sight forum
»forums.pfir.org/main/messages/714/714.html
nobody is complaining about Verizon
so I guess my DSL is safe for now
I'd rather wait till this is out of
beta, before keeping it running here.
Forums » Tools To Test Your ISP For BitTorrent Shenanigans


Monday, 09-Nov 15:53:29 Terms of Use | Privacy Policy | Hosting by www.nac.net - DSL,Hosting & Co-lo | feedback | contact
over 10 years online! © 1999-2009 dslreports.com.republican-creole