Encryption is unuseful here :(

[pictor]

Hello,

Here a bigger part of the ISPs is using method to block the P2P traffic throught the lines.

I know in μTorrent is already present the option "Encryption Protocol" but it seems to be not sufficient to pass throught our ISPs' routers.

They keep blocking bitTorrent traffic.

But this doesn't happen with the eMule encryption. Maybe it use some more trick.

My question is: are you planning to develope a stronger encryption protocol that could pass even with this routers?

Or we must get used to not download via P2P?

I hope I could continue to use μTorrent in the future.

Thank you.

PS - Pardon my english.

[The8472]

> stronger encryption protocol

they are not breaking the encryption, hence "stronger encryption" won't change anything at all. To determine what they're doing extensive tests on a client affected by the traffic shaping would be required and since you rarely find users who are willing to grant you full remote access to their machines, the effort involved in such testing is not small etc. etc. it's not simple to make progress in that area.

Switching ISPs is often a far easier option.

[pictor]

I understand

But my ISP is the only one giving a decent conncetivity to play online. I couldn't change ...

Anyway, what about looking for a collaboration with the authors of eMule. Maybe they know more about how to pass the traffic shaping (i think they are masking eMule traffic as Firefox packets). They could help uTorrent to pass it too.

For the testing wouldn't be an idea to include some kind of statistics/tests in the uTorrent release, asking the user if he accept to show them, so there would be something to work on?

However I know my ISP's router model. It should be a Cisco SCE 2000, if it could be useful (it analyzes the Layer 7 of the packets).

I hope something could change b/c i use mainly μTorrent rather than eMule...

[jadedknight]

> you rarely find users who are willing to grant you full remote access to their machines

If a uTorrent dev, wanted that from me I would give it. I am with Rogers and they throttle. I would do anything to lend a hand

[pictor]

I think that many users would like to do that.

Anyway I think the aim would be to reach the eMule encrypting level and find a common solution with them (possibly).

[andr_gin]

I also do not think, that they break the encryptions, because this would take far too much power. Maybe the problem is how to get the encryption. The provider can see every packet you send and receive so maybe he filters all packets before the encryption is initialized. If they know the Bittorrent protocol, this should not be very hard. If you have identified a connection as Bittorrent protocal, then you can reduce the speed no matter what data you send.

[jewelisheaven]

For the record the in-development 1.8 line includes workarounds for current shaping methods which has been reported to work on some ISPs. To get ahold of it, check out the Announcements forum.

[mjr]

The traffic shaping used by Comcast sends forged TCP RST packets to both ends. It's triggered when there's lots of connections to a single port. No encryption is broken. There's no need. There's three ways of defeating it. Change the port on each announce, which will hurt DHT; limit the number of incoming peers, which will need tracker help; or just ignore RST packets for the port, which will need low level OS work. This all assumes the RST packets are perfectly formatted. If not, they should be blocked or ignored by any sane OS.

[jewelisheaven]

1.8 also includes "transparent" teredo support. Once enough people are using 1.8 the IPv6 functionality will render the RSTs moot. . . OSes, when are they debated on here

[The8472]

teredo is transparent... they can see the TCP/IPv6 inside teredo and thus inject "TCP-RST over IPv6 over Teredo over UDP over IPv4"-Packets just as they can inject TCP-RST over IPv4 packets... it'll just increase the complexity of the required parsers. So i give that a measure a few months. teredo is more interesting when it comes to circumventing NAT.

And about blocking RST packets, that does not work since they're sent to both ends.

[jewelisheaven]

Would that require a patch to the hardware, or would new hardware need to be upgraded/rolled-out for the change to injection?

[The8472]

nah, that's just software... a new parser that can see TCP inside teredo (from there on they can use their old parsers) and the inverse path for injection. Think of firmware for a router... just that it has a throughput in the multi-gigabit range and firmware updates are contractually guaranteed as part of a maintenance agreement.

They'd only need new hardware if the current ones would be at its limit and the new parser/injector's complexity would push it beyond that.

So it's more a matter of how much ISPs want it throttled, how much time it will take to come up with a parser and then the time to deployment.

[jewelisheaven]

Spiffy... well technology usually is the mousetrap model. If you build a better mousetrap the mouse inevitably gets smarter.

[Klaus_1250]

And about blocking RST packets, that does not work since they're sent to both ends.

If both end block the RST, it would work. Blocking RST's is fairly trivial on *nix (which is used on most routers) and with the right software, even trivial on Windows.