EFF Releases Tool For Testing ISP Interference 96
Placid notes that the EFF has announced Switzerland, a tool for testing if your ISP is interfering with your Net connection (e.g. by resetting BitTorrent transfers). It's command-line only at this point. Of course the tool is FOSS, and you can contribute to it via its SourceForge project. From the announcement: "Developed by the Electronic Frontier Foundation, Switzerland is an open source software tool for testing the integrity of data communications over networks, ISPs, and firewalls. It will spot IP packets which are forged or modified between clients, inform you, and give you copies of the modified packets."
Warning to non-tech people (Score:1, Informative)
This things require root and I am not knoledgable enough to investigate the source code.
As I have not suitable testing environment, I will have to wait trusting Ubuntu or Debian for a pre-packaged version.
I strongly advice you, non-techy, non-programmer to be patient and wait a bit your Linux distribution or vendor to provide a package.
Re:cool, just downloaded it (Score:3, Informative)
Python under win32 is a little on the odd side, i got it to work under cygwin python, Charter Com, in St. Louis Missouri, Doesnt Packet Shape, but the DNS Redir to a search engine is annoying.....
The download link (Score:5, Informative)
From the Install ReadMe (Score:4, Informative)
Switzerland is alpha software. Remarkably, it runs on lots of different operating systems (we've seen it work on Linux, OS X, BSD and Windows XP), but because it's alpha software we can't promise that it's easy to install on all of these operating systems. We're looking for volunteers to help with a Windows installer!
So for those looking for an easy install in Windows, you won't find it yet. Seems like cgywin under Windows XP is indeed the way to go.
Re:Warning to non-tech people (Score:5, Informative)
Yeah, all tools that do tcpdump/Wireshark-style packet inspection require root (you don't want normal user programs sniffing everything). It's true that it's alpha quality code that does TCP communications, so it's a good idea to not leave it running all the time, and/or wait until a beta version has been released.
A bigger issue is that some of your sniffed packets are sent in the clear to EFF, so 1) it's possible that a third party could sniff those few packets (but it's only a handful of packets, but it could still cause problems, and 2) if you use EFF's server, you have to trust EFF with the handful of sniffed packets you send them (but you can run your own server). It's too complicated to summarize in a few sentences, see the README.txt in the package.
They do say they'll fix the issue that third parties could sniff your packets though (by doing the obvious thing and encrypting them between endpoints), so again, waiting for a later version might be a good idea.
Re:The download link (Score:5, Informative)
This is going to change fast so it might be a good idea to download directly from the repository:
svn co https://switzerland.svn.sourceforge.net/svnroot/switzerland [sourceforge.net] switzerland
Enjoy!
Along the same lines... (Score:5, Informative)
There are a few packages available on the Network Neutrality Squad's website [nnsquad.org]:
(These were mentioned on Slashdot a little while back)
Re:EFF not trustworthy (Score:5, Informative)
As with anything, there are ups and downs to a ruling... sure, Comcast may start charging by the bit and so forth. However, the big reason the EFF went after them was because they were forging packets, including the RST packets, and otherwise impersonating users on the bittorrent protocol.
The EFF was never saying they can't use traditional QoS on their network... they're saying companies need to reign in "bandwidth hogs" (as you put it) using protocol-agnostic methods, and they certainly shouldn't be forging any traffic.
Full disclosure: I'm a paid, card-carrying member of the EFF. Just gave them another $15 a week ago.
Re:Behavior is as important as bandwidth (Score:1, Informative)
OK, this is somewhat of a network techie/geeky thing, but you can hog the network even if your bandwidth is capped.
This issue isn't about capping, it's about fair-queuing.
This is due to a flaw in TCP, which does very weak, per-flow congestion avoidance.
No, this is due to a limitation in TCP. But that isn't the point. You are presenting a strawman argument, namely that "neutrality" means relying upon users to play nice (i.e. no fair-queuing). While using such a strawman would probably gain traction in a non-technical forum, it isn't going to get you very far here.
BitTorrent, which is used for downloads that are not time critical, seizes priority over other traffic such as VoIP, which really needs real time performance.
That's what the IPTOS_* bits in the IP header are for. Of course, you need to provide some incentive for users not to automatically request improved ToS just for the sake of it, and to request minimize-cost for bulk transfers, but that's easy enough to build into the fair-queuing weights.
What's more, the streams for which it seizes priority use large packets because they are downloads. The large packets, in turn, create jitter, which really messes up VoIP.
The same is true for most TCP traffic, including HTTP (and, in fact, just about everything except interactive telnet or ssh). This isn't specific to BitTorrent. If the server is trying to send a chunk of data larger than the MTU, it's going to try to use MTU-sized packets.
So, ISPs are doing the right thing when they throttle BitTorrent and keep it from opening up too many streams.
No they aren't. They're either just being lazy (can't be bothered to implement fair-queuing), or they're discriminating against BitTorrent for other reasons. E.g. because although they advertise a 100GB/mo quota, anyone who tries to actually use it is treated like a cheat.
In the event of contention, the "right thing" is to simply share bandwidth fairly. When there is more than one packet in the queue, you give higher priority to packets belonging to users with lower recent bandwidth usage. The end result is that users who don't ask for much get everything they ask for while those who ask for a lot get whatever you can manage.
The bottom line is that my money is as good as anyone else's, and I expect to get the same amount of bandwidth as anyone else who is paying the same rates. Whether I want to use that bandwidth for BitTorrent, web browsing, gaming or VoiP is my business, and not yours. 1Mbit/s is 1Mbit/s, whether it's over a single 1Mbit/s TCP connection, 100x 10Kbit/s connections or, for that matter, a continuous barrage of UDP packets. The bandwidth is the same, the jitter is the same (667 packets/sec @ 1500 bytes/packet is the same whether it's on one connection or many).