Defeating DPI?

[Clinch]

I've been doing research and what not about ellacoya because my ISP uses it. At first I thought SSL trackers and only encrypted connections were enough but they aren't. I even tried to tunnel in through an encryptionless VPN but that never worked.

What I found out from some IT people is that it uses behavioral analysis to find the BT protocol and that encryption is useless.

What I know for sure with ellacoya is that tracker SSL or not makes ZERO difference.

I had a few ideas, one of them was create 2 ports instead of just 1 and separate piece requests from piece downloads, but apparently this too easily defeated and alot of work.

So I am wondering if DPI would be defeated if outgoing piece requests were done through a socks proxy but with our real IP somewhere inside the protocol, and actual data of the piece requested were sent directly to us?

Am I thinking about this all wrong in trying to remove the correlation between upload and download?

[Lord Alderaan]

Just switch ISP. Its the only way to make clear BitTorrent throttling is unacceptable.

And the 'stronger' their system is the more traffic that gets mistaken for BitTorrent traffic. If they are not checking content (which can often be defeated by encryptions) but checking for patterns (ports, speeds, number of connections, etc) there is a likelihood other traffic of yours is accidentally throttled too.

[Clinch]

Switch isn't an option for me unfortunately. Alot of ISPS have a natural monpoly such as mine.

I seriously doubt switching will send them a message.

This is a fairly simple idea, but I'd like to know from the mods/developers if this is possible?

[patcat88]

If the ellacoya is triggered based on bandwidth usage of the encrypted VPN. See if you can have padding on your VPN, to break "timing attacks", which is what the ellacoya is doing. Or see if you can set your VPN server's VPN daemon port to port 80 or port 443, will make it look like HTTP/HTTPS a little bit, which is extremely unlikely for the ellacoya to touch. High random port to remote port 80 is godly and can never be touched since any accidental throttling of that will make ALL the users of the ISP system wide have a slower connection, including Joe six pack, Bob the farmer and Grandma Gerardine who have never heard of p2p.

Regarding the socks proxy idea. Make sure you encrypt the socks proxy connection. Or you can use SSH tunneling. 1 danger. SSH socks tunneling doesn't give you incoming connections. But uTorrent will still be listening for incoming connections from your ISP/not SSH server, so only your incoming would be throttled, or the "lack" of outgoing connections might throw off the ellacoya and have it not throttle your incoming. The other choice is to set up incoming connections through SSH tunneling, but the side effect of that is that you must turn on having the "IP can only have 1 connection at a time to you" turned off, since all incoming connections will have the IP of 127.0.0.1/localhost.

Slightly higher chance of queue fraud too from hacked clients that make multiple connections to you for a higher chance of being unchoked/get data sent to them by entering themselves multiple times into your swarm picture, and stuffing the queue. But atleast your helping fix the firewalled peer problem on BT that is continuously growing.