no way they can break ccmp like they did with the easy rc4Originally Posted by anon
if most of peers were to support ccmp it would almost as good as no throttling
if general isp's can block ccmp protocol from passing torrent data they might as well destroy your vpn pptp torrent packets
Last edited by n4overclock; 22.03.12 at 19:35.
interesting ...
when you are being throttle does it apply to all traffic or only the bittorrent connections?
The images are not clear and display very little peer information, but on top we see all visible peers have this:
D = currently downloading from the peer (interested and not choked)
E = peer is using Protocol Encryption (all traffic)
Not "I" so its a connection that you started.
on bottom we see that all visible peers have this:
D = currently downloading from the peer (interested and not choked)
I = peer established an incoming connection
E = peer is using Protocol Encryption (all traffic)
P = peer is communicating and transporting data over uTP
From that we see that top is pretty much the opposite of bottom:
- on top you started the connection and you are using TCP
- on bottom you received a connection and are using UDP
There are many variables here that needs to be eliminated in order too figure out how do they know when to throttle you.
Because socks5 doesn't encrypt the traffic it only changes the way the connection starts and the path to it's destination not the content.
Last edited by The248; 22.03.12 at 20:08.
they only play with the p2p traffic, when i start a multithreaded http download i get the full speed for adsl2+ that's around 13mbps because im not close enough to the exchange..
but in those examples i didn't focus on showing those flags if you look at it again you'll see that diffident torrents are being selected. they're not from the same tracker btw
ill try a vpn example from the same tracker
Last edited by n4overclock; 22.03.12 at 21:22.
It doesn't matter what torrents or trackers, it's a protocol/connection thing.
Try running a torrent normally and screenshot the peerlist (throttle example) and then restart the bittorrent client and use your technique to achieve maximum speed and screenshot the peerlist (unthrottle example)
You also said that you announce without using socks5 (you appear connectable), so outgoing connections will pass through socks5 and incoming connection will not, that will resume in connections with "I" being throttle and the others not, see if you can get screenshot of that
trying things at random will not help you
you need to understand how do they know that X connection is bittorrent
when you know that then you know if you can avoid that and how to avoid it if possible
incoming connections and udp will not get effected by socks regardless! you'd better off disabling dht and and udp connections for both the announcing and the peer connections if you gonna try socks
i agree you shouldn't be trying tings randomly but trying out the obvious first is wise
here's another example
VPN
the results of forcing only encrypted tcp data while increasing peer connecting timeout and no dht on tixati.. 12mbps no throttling no socks no vpn.. (7mbps with vpn)
botom line
-dht and its udp port should be disabled
-only forced encryption
-only tcp peer connections for both outbound and incoming
-change your mac adress if the current has been flagged
Last edited by n4overclock; 24.03.12 at 03:29.
did you tried disabling all udp transactions on utorrent?
under advanced settings: bt.transp_disposition, set it to 5
they can't afford to check multiple things, needs to be something like "if you receive udp and tcp on the same port probably means is p2p then throttle" otherwise the remaining connections would suffer significant delays with all that extra work
Forgive me for my ignorance, but I am little confused. :(
@n4overclock, why do you think dht is relevant here? For all private trackers, this is disabled already.
@The248, interesting ideas about the throttling rules. Any more rules you would think about? Also, you seem to have a different opinion on udp/tcp (5 for bt.transp_disposition instead of 10 as suggested by anon). Any reasons?
If I am still to use uTorrent, what log options should I enable to check the possible ISP throttling?
Thanks a lot in anticipation!
Last edited by bjs; 23.03.12 at 21:47.
keep in mind that my throttle jus happened recently and wasn't there before February
I set it to both 10 and then 5 earlier i double checked it now but still around 1 kbps for utorrent or deluge vuze without socks or vpn .. my theory is that they check only once .. once you're flagged temporarily all your rc4 encrypted traffic gets throttled temporarily and ofcourse the plain text traffic is too easy if you decide to disable encryption and i know this because only a new mac address reset thing for me.. i already verified this
so on utorrent using a fresh mac i notice there is a 60kbps 5 sec spike for download speed before throttle happens but after that no more spikes at the start until i change the mac again
what makes things even more interesting is that tixati itself gets the throttle if my mac already been temporary flagged by the use of utorrent..
if i get a new mac the throttle disappear if i don't use the other clients, so something caused by the other clients causes the throttle flag
@bjs dht is not about just getting initial list's of other dht peers, it can be used for different things including chat channels and it absolutely could trigger the throttle
Last edited by n4overclock; 24.03.12 at 03:29.
5 means 4+1, so only TCP connectionsbt.transp_disposition: This option controls µTorrent's level of bias towards using TCP or uTP for transporting data (assuming the peer at the other end of the connection supports both transport protocols). The following is a list of the accepted values:
1 allows µTorrent to attempt outgoing TCP connections
2 allows µTorrent to attempt outgoing uTP connections
4 allows µTorrent to accept incoming TCP connections
8 allows µTorrent to accept incoming uTP connections
16 tells µTorrent to use the new uTP header. This is an improved communication header, but is not backwards compatible with clients that do not understand it.
This option is interpreted as a bitfield, so values can be added together to obtain a combination of behaviors. Setting this value to 255 guarantees that all behaviors are enabled.
10 means 8+2, only UDP connections
you can make any combination you want by adding the values
----
do they throttle all the upload traffic? or just bittorrent?
if you can make it work throttle and unthrottle then we can find out how they detect it
try socks and/or vpn, disable everything on utorrent that use the internet, dht, peer exchange, force encryption and don't allow incoming legacy, disable udp (bt.transp_disposition = 5) then try disabling all tcp (bt.transp_disposition = 10), disable scrape, disable utorrent update check, ... anything you can remember
it can't be checking rc4 because you get tixati to work without socks or vpn, otherwise tixati would get detected to
you've find out something important, see, now we are getting somewhere
there's something important that popular clients do that tixati doesn't
and it's being used by the isp to detect bittorrent protocol
-----
here's a test you can do that will help us narrow it down:
- put tixati downloading at max speed
- open utorrent (don't download or seed anything, just open it)
- give it some time and see if you start to be throttle
if you don't, then start a torrent on utorrent and see how much time it takes for tixati to lose speed
it may also happen that it only affects new connections, old ones (the ones running on tixati) may not be throttle, take special attention to that
its checking rc4 and other factors if you consider this
router using a fresh mac and both clients are using different ports with forced rc4
i run tixati first and i see no throttling
i did keep it running then i started utorrent (it gets throttled after a spike) and that didn't effect current tixati connections
waited a minute then stoped all and restarted tixati and so it gets throttled (no hiding utorrent proccess running)
just those facts and the spike proves that the isp doesn't outright know but it takes a little traffic/time..
also there is no starting speed spike when i use utorrent on disabled encryption and i changed the client id in tixato to utorrent id provided by rm memory reader and it just didn't affect anything.. so now we know its not the client id.. it was correct btw since a strict tracker allowed it instead of the default tixati id..
Last edited by n4overclock; 24.03.12 at 01:56.
You need to check if you get throttle without starting any torrent on uTorrent.
- Put tixati running and downloading
- Start utorrent (don't download or seed any torrent)
- Stop and restart tixati connections and see if it gets throttle
if it doesn't gets throttle then we will move to another variable called tracker
if that doesn't work too then we start analyzing a single peer connection
if we cooperate sooner or later we will find out
keep in mind that tixati is a bittorrent client like any other
if it works there is works on any other
I've told you this it's unlikely that they would check this deep, even checking for rc4 is way to much
imagine checking thousands of connections every seconds, for it to check for peerid it would need to check every byte passing through it's just not doable in a affordable way for them to care
it does get throttle as i told you before.. i tested both the stoped and leeching utorrent using clean mac adress's and both cause tixate to throttle.. whats the point of even saying tixate is a better client ? its obviously just about configuration and the way/what type of packets gets from a to b, so we should configure other clients the same way.You need to check if you get throttle without starting any torrent on uTorrent.
- Put tixati running and downloading
- Start utorrent (don't download or seed any torrent)
- Stop and restart tixati connections and see if it gets throttle
if it doesn't gets throttle then we will move to another variable called tracker
if we cooperate sooner or later we will find out
keep in mind that tixati is a bittorrent client like any other
if it works there is works on any other
my point is that they dont have to scan all packets as you say.. they only confirmed the first RC4 packets and see if they use contain bittorent and after that its only a matter of wich packet type/header of wich mac address .. we can test this by running a rc4 traffic that isn't p2p after we get flagged, any ideas or other protocols that use this ?I've told you this it's unlikely that they would check this deep, even checking for rc4 is way to much
imagine checking thousands of connections every seconds, for it to check for peerid it would need to check every byte passing through it's just not doable in a affordable way for them to care
Last edited by n4overclock; 24.03.12 at 03:16.
n4overclock, please hide the IPs on those screenshots, they don't need to be shown.
------------------------------>>>>>>>>>> <<<<<<<<<<------------------------------
DONE, tnx for point it out.
If you're saying that tixati get throttle even if uTorrent doesn't start to download or seed anything, then clearly is not related with rc4, because if you don't start a torrent rc4 is never used.
Disable scrape and updates check from utorrent and try again having tixati downloading and opening utorrent to see if tixati gets throttle
Posting Permissions
Reply With Quote
Bookmarks