Ok, everyone is just pissed off about ToT "throttling" your download speed on torrents. Here is the fix, you have to be a bit computer savy to follow this... If you don't know anything about computers, then I would recommend you not try, get your local computer geek to do it for you.

Okay people, so we understand that ToT (and other ISPS) has been throttling back our torrents! What can we do? Change your bittorrent ports!

If your bittorrent client's port is changed to 21 (the default FTP port), ToT will no longer be able to crush your torrenting balls with its filter system. I'm not sure if this works on 3BB and TT&T (but since all companes are pretty much linked together I assume it will), someone should test it out and post back here to let everyone know how it works.

uTorrent by default uses port 28002:

Use port forwarding software and forward port 28002 to port 21.

This tricks your ISP into thinking that you have an FTP open (FTP = File Transfer Program... Used mainly by web designers)

Go here: http://www.snapfiles...mpleportfw.html

This is free software, it is for port forwarding

*WARNING*

If you set your torrent port to something you use regularly (e.g. port 80), and use bittorrent and whatever the port is meant for, shit will start happening, so choose something you never use (e.g. never use port 80 for torrents while you surf the web). It's best to use port 21 unless your a web designer, and if you are a web designer then you are smart enough to find another port.

Now, everyone say "I LOVE YOU DARKROSE"

And if you live on Koh Samui, I expect you to buy me a beer :jap:

-Darkrose

Edited August 18, 201015 yr by Darkrose

I am not even sure 3BB is throttling torrents but sounds like an interesting suggestion, I'll try that. I FTP only once in a blue moon so the FTP port is usually available, good idea.

I am not even sure 3BB is throttling torrents but sounds like an interesting suggestion, I'll try that. I FTP only once in a blue moon so the FTP port is usually available, good idea.

Thank you

I use ToT and am now downloading at 130kbs (not the fatest, but much better than 10kbs)

Also, you must restart your bittorrent client after you set up the port forwarding

uTorrent by default uses port 28002

There's no such thing as a default port.

Traditionally, bit torrent uses TCP ports 6881-6889/6999.

When setting up port forwarding, choose a port number between 49152 and 65535 for best results.

I am pretty sure they are not doing this throttling based on ports. It simply isn't possible, since torrent applications use random ports.

They must be doing this through packet inspection if they are having any kind of success trotting people.

The only way past that is using encrypted connections, which most torrent applications support.

I am not even sure 3BB is throttling torrents but sounds like an interesting suggestion, I'll try that. I FTP only once in a blue moon so the FTP port is usually available, good idea.

3BB is throttling my torrents, big time.

Some private trackers ban using that port.

Edited August 18, 201015 yr by prism

I am not even sure 3BB is throttling torrents but sounds like an interesting suggestion, I'll try that. I FTP only once in a blue moon so the FTP port is usually available, good idea.

3BB is throttling my torrents, big time.

Some private trackers ban using that port.

I presume you are all encrypting your in and outbound packages?

In Azureus (Vuze) this is done in Tools / Options... / Connection / Transport Encryption : Require encrypted transport - RC4

YES WOW ,WELL DONE HAVE DOWNLOAD SPEEDS OF A PRIVATE TRACKER 250KBS,

UPLOADING STILL AWFULL,GR8,GOOD WORK.

CANT BEAT THE SYSTEM,LMAO.....JUST CHECKED AGAIN 320KBS,YESSSSSSSSSSSS

YES WOW ,WELL DONE HAVE DOWNLOAD SPEEDS OF A PRIVATE TRACKER 250KBS,

UPLOADING STILL AWFULL,GR8,GOOD WORK.

CANT BEAT THE SYSTEM,LMAO.....JUST CHECKED AGAIN 320KBS,YESSSSSSSSSSSS

While I can appreciate the OP's efforts in seeking ways to overcome the bit torrent problem as of late, utilizing ports such as FTP isn't a viable solution, nor do I recommend it. If you continue to have problems, you can do one of two things:

1. Switch to a different ISP;

2. Learn to configure your client: uTorrent | Azureus and setup port forwarding.

Note: The uTorrent guide contains a section on patching tcpip.sys and increasing net.max_halfopen settings. IGNORE IT!

Using IANA assigned ports such as FTP, HTTP, SSH to handle P2P traffic may work in the interim, but it's no permanent solution. Most long-time P2P users will advise you to use higher numbered ports as I suggested in an earlier post. With over 16,000 private ports to choose from, I see no reason why anyone would want to use ports officially designated for a particular purpose (FTP in this case). It's just plain silly.

Do keep in mind, there's no way to "mask" bit torrent traffic -- no matter what port you use. However, ports 49152 to 65535 are less likely to be blocked/throttled by your ISP. Whatever you do, be sure to enable protocol encryption in your torrent client.

I just thought I get this out of the way before more people jump on the bandwagon.

Do keep in mind, there's no way to "mask" bit torrent traffic -- no matter what port you use.

This isn't really true. You can mask it through encrypted transfer and tunneling (not the protocol encryption most clients have).

There are also a couple non english torrent clients out there that totally disguise the torrent transfer as http traffic.

Tot krabi,is back down to maximum 50 kbs,oh well at least it worked for a bit....

Did some testing now here in the last hour, on a TOT line that is heavily throttled.

Without measure, I get 10-20 dl speed.

Changing the port to 21 did not improve anything.

Setting the encryption to enforced and refusing unencrypted incoming connections did not improve anything.

What is working for me now, is using TOR for all Torrent Traffic. I am getting 200-300 speeds now on a 4 MB TOT line.

Tested with one torrent only (private tracker, 10 seeds, 2 leechers)

I'm not having a problem downloading now, but uploading is much slower than before all the trouble.

Quote:

If your bittorrent client's port is changed to 21 (the default FTP port), ToT will no longer be able to crush your torrenting balls with its filter system. I'm not sure if this works on 3BB and TT&T (but since all companes are pretty much linked together I assume it will), someone should test it out and post back here to let everyone know how it works.

uTorrent by default uses port 28002:

Use port forwarding software and forward port 28002 to port 21.

This tricks your ISP into thinking that you have an FTP open (FTP = File Transfer Program... Used mainly by web designers)

uTorrent's default port is 6881, TOT is currently blocking that port. A user can of course change this any (unused) port, or even randomize this port each time app. is started.

You cannot forward port 28002 to port 21. You can forward a port to an IP address. I'm not sure what you are suggesting? Perhaps to modify your BT client to use port 21, then forward that port?

FWIW, I use FTP (FileZilla) alot and TOT is not currently limiting my FTP upload or download rates.

I'm not sure what TOT is doing? Deep Packet Inspection (DPI), limiting user bandwidth based on tacker communication (if a user is communicating with a tracker then they must be using BT), limiting bandwidth generally (not in my case), limiting int'l bandwidth (possibly, all my FTP traffic is domestic).

I am pretty sure they are not doing this throttling based on ports. It simply isn't possible, since torrent applications use random ports.

They must be doing this through packet inspection if they are having any kind of success trotting people.

The only way past that is using encrypted connections, which most torrent applications support.

I am not so sure about this i download a lot of newsgroups when i use the standard port it is really slow. But when i change it to an other port i get my full 10mb out of it. (servers in the USA)

Quote:

You cannot forward port 28002 to port 21. You can forward a port to an IP address. I'm not sure what you are suggesting? Perhaps to modify your BT client to use port 21, then forward that port?

FWIW, I use FTP (FileZilla) alot and TOT is not currently limiting my FTP upload or download rates.

I'm not sure what TOT is doing? Deep Packet Inspection (DPI), limiting user bandwidth based on tacker communication (if a user is communicating with a tracker then they must be using BT), limiting bandwidth generally (not in my case), limiting int'l bandwidth (possibly, all my FTP traffic is domestic).

As pointed out, my personal uTorrent was using Port 28002, you can find your connection port by looking in your setup.

(i.e. uTorrent = Options -> Prefrences -> Connection

Well, you can easily configure your BitTorrent Client to use a selected port, I just found the results to be better with port forwarding software. I "suggested" port 21 because it is dedicated to FTPs... and the common person does not use an FTP. If you are having problems as you said, I would really find your local computer geek and give him a call. There could be any number of problems, or rather "misconfigurations", it isn't exactly a science but don't take this article and do half of what you think sounds good and leave out half, I suggested port forwarding software and not reconfiguring the BitTorrent Client for a reason

Whatever you do, be sure to enable protocol encryption in your torrent client.

I find this is the easiest. I use uTorrent and selecting the uTorrent options as recommended by Supernova and uToorrent itself when ISP's are shaping will remove the throttling. Tested it again today, was getting 5kbps d/l with uTorrent protocol encryption off. With it set to forced and allow incoming legacy connections disabled d/l of over 700kbps achievable on the basic 599THB True package. Ymmv with TOT!

Edited August 19, 201015 yr by Digitalbanana

Judging from both my experiments and all the other users' experiences reported here and elsewhere, I can only assume that TOT is currently experimenting with different methods to block/shape the torrent traffic.

Well, whatever they do, they wont stop me, and lots of others.

@Digitalbanana: The encryption options I have already tried, they brought no results for me. Obviously I am at another branch of their experimentation line.

I was definitely under the impression that the myth - that port forwarding "correctly" tuned to work with your torrent download platform was the ultimate solution - had been debunked various times. It just does not work.

I genuinely believe that those not on Premium style packages that do momentarily get high range download speeds are not the architects of this. I think this is the ISP not handling/analysing the data correctly for periods of the day and you seeing increased speeds as a result until they rectify the situation.

If you those are you that are lost can get your head around the file-hosting/downloader idea (which is not hard to understand given that you're happy to fiddle with the port settings on your torrent platform) and the small noimal fee you have to pay, I genuinely believe your file downloading experience will be much more happy and relaxed in Thailand. Not only that you'll get your files in a much more timely manner.

Something tells me that I'm shouting into the wind though here.

Edited August 19, 201015 yr by ManInSurat

Hopefully the wannabe engineers at TOT won't read or understand the part below.

Shaping torrent or p2p traffic requires identification to begin with. And that is the biggest headache. Clients now allow encryption of the payload, which makes packet inspection slow or useless.

However, approaching this issue from the other way is much easier:

consider all traffic as p2p and start making exceptions. The trick described in the OP will then no longer work;

any tcp traffic directed at port 80 can be considered webtraffic and thus can be inspected. If the payload does not comply with the structure of an http request, throttle it.

This process can be configured for any known tcp and/or udp port and is very effective.

The difficulty in this approach is formed by applications like ftp and Skype. Passive ftp uses a second (data-)session which can be learned from the control session to port 21, but apart from that it's too easy to classify it as p2p.

Skype uses p2p to build up several connections to other Skype clients, and these sessions look like torrent traffic. The only difference is that the number of sessions from a specific port number at the client will usually stay below 30.

A final check can be done on the number of concurrent sessions with the same client port-number. Once this goes way over 50 concurrent sessions, it's very likely to be bit-torrent traffic.

In case of SSL ports like 22, 443, 989-995 the number of concurrent sessions should be less than 10.

Using well-known port numbers for bit-torrent while they're intended for other applications is a bad idea and it's very easy for an ISP to recognize this!

So the approach to disguise traffic should not just be in payload encryption, which is available in most clients.

Limiting sessions should be the extra step. Unfortunately most clients keep hundreds of sessions to other bit-torrent clients open, even when no data is being sent (except keep-alives). Some clients can be configured to limit the concurrent number of outgoing requests and limit the number of connections being build up during a time period, but it seems that nobody ever takes a look at these parameters.

A benefit to this is that your own router is not killing itself while maintaining a massive NAT table.

I was definitely under the impression that the myth - that port forwarding "correctly" tuned to work with your torrent download platform was the ultimate solution - had been debunked various times. It just does not work.

I genuinely believe that those not on Premium style packages that do momentarily get high range download speeds are not the architects of this. I think this is the ISP not handling/analysing the data correctly for periods of the day and you seeing increased speeds as a result until they rectify the situation.

If you those are you that are lost can get your head around the file-hosting/downloader idea (which is not hard to understand given that you're happy to fiddle with the port settings on your torrent platform) and the small noimal fee you have to pay, I genuinely believe your file downloading experience will be much more happy and relaxed in Thailand. Not only that you'll get your files in a much more timely manner.

Something tells me that I'm shouting into the wind though here.

Interesting. So you've never got port forwarding to work and therefore state that it is just a 'myth' and does not work?

Do you own shares in a file-hosting site or something?

I know port-forwarding is hard to "get your head around", but you shouldn't give up on it.

Limiting sessions should be the extra step. Unfortunately most clients keep hundreds of sessions to other bit-torrent clients open, even when no data is being sent (except keep-alives). Some clients can be configured to limit the concurrent number of outgoing requests and limit the number of connections being build up during a time period, but it seems that nobody ever takes a look at these parameters.

A benefit to this is that your own router is not killing itself while maintaining a massive NAT table.

So is this working for you? And what settings are you using (Glonal maximum nu,ber of connections; maximum number of connected peers per torrent)?

Once TOT identifies BT usage (using your methods) by customer how do they limit BT traffic without impacting subscriber bandwidth which presumably must be available for downloading files from a rapid share site or to stream YouTube videos?

Edited August 20, 201015 yr by lomatopo

<snip>

Note: The uTorrent guide contains a section on patching tcpip.sys and increasing net.max_halfopen settings. IGNORE IT!

<snip>

Do keep in mind, there's no way to "mask" bit torrent traffic -- no matter what port you use.

<snip>

Dämn! So, to summarise, what I must do is:

1. Undo the TCPIP.sys patch - because you say to ignore it

2. Turn off the RC4 encryption - because you say there's no way to "mask" bit torrent traffic

3. Turn off port-forwarding - because ManInSurat says it's a myth.

Glad there are so many experts on this forum.

<snip>

Note: The uTorrent guide contains a section on patching tcpip.sys and increasing net.max_halfopen settings. IGNORE IT!

<snip>

Do keep in mind, there's no way to "mask" bit torrent traffic -- no matter what port you use.

<snip>

Dämn! So, to summarise, what I must do is:

1. Undo the TCPIP.sys patch - because you say to ignore it

2. Turn off the RC4 encryption - because you say there's no way to "mask" bit torrent traffic

3. Turn off port-forwarding - because ManInSurat says it's a myth.

Glad there are so many experts on this forum.

Haha, JS, a case of too many cooks?

I've never professed to be an expert when it comes to port-forwarding and the 'myth' is not something I made up. I've been told by the ISP, Thais subscribers and farangs alike that port-forwarding specifically with Maxnet is known to be ineffective for a range of different protocols. I can categorically state that I have not done any testing to back those sentiments up, so fundamentally any argument relating to port-forwarding I have here is flawed and I won't press the issue until there's some more consistent verifiable data to see.

I think the idea I am trying to intimate here is that all the time wasted trying to find a workaround for the torrent (which does seem very long winded by the looks of the threads in here) could have been happily spent downloading using other methods and services that are by no means an inconvenience and are very stable. There are other means available other than those I outline, but I just speak about what I know well. I'm not here to plug any service or business - you'd have seen my links plastered everywhere if that were the case, which you know I haven't!

I'm just trying to promote the concept. Get the idea out there. As I genuinely think it'd just make people's lives easier and I consider TV to be a place to be able to come to find the most easy and stress-free way of achieving things in this lovely country. I think people also have an issue with the fact that there's fee with the method I use, but it's such a minor inconvenience. It's $10 a month or 8 large bottles of Chang in the same period! Peanuts. Maybe it's the fact one can be anonymous with a torrent, I don't really know. I just know from personal experience the method I use now is vastly less stressful than any other alternative.

It also seems to me that the ISP don't want to allow their subscribers to run riot with torrents and will do everything to try and stop us, thus making the whole process of say downloading a film, a much more drawn out process than it needs to be. I just want to get the media I'm after, have it saved on my HD and view it at my own leisure and I want all this done in the least amount of fuss and in the quickest time possible. Having to constantly stay ahead of the torrent game (the rules will change all the time) by tyring to garner tidbits of information from TV members, the ISP, locals, the postman, the soi dogs - anyone - would really not be my cup of tea. Maybe some people like the challenge. Is that it? Or not being dictated to by the ISP?

We're all pretty much aware of the fact that the Thai ISPs are completely wont to do what they like outside of being dictated to by the gov in specific areas. They can do what they want and that isn't going to change any time soon! True appear to me to be the only company that genuinely seem to understand the importance of having decent customer relations and are very very aware of their foreign customer base and have changed their advertising and work ethic accordingly. It's great to see. The more long-in-the-tooth ISPs, TOT & Maxnet - let's just say "old dog new tricks" I don't think you can ever win the battle of attrition there - with relation to torrents.

BUT...I digress, back to downloading..... From personal experience what I can say is that using the methods I have outlined above I get all media really very fast, speeds of 1.9 megabits download on a 16M connection last night using RS. That to me is amazing. That's a 700MB film in around 6-7 minutes. Yes, over the last month there have been some severe issues and I was getting the dropouts, lost connections and timeouts like everyone else, but they seem to have gone away for a full 48 hours now. Even when the gremlins were here I would get above 500kbs speeds without issue using the method I do to download.

I promise I won't keep harping on about. I've said all I have to say on my methods and you're quite right, it's time to change the record. I genuinely rest my case now about this.

I prefer to pass my days by without stress in this wonderfully beautiful country! :jap:

Sincerely best of luck with your torrent endeavours all of you, I hope you manage to crack it soon!

Should any of you any need any pointers with any of the services I use, I'd be happy to help anyone that needs it.

Here endeth the lesson.

you could always use a CAT CDMA air card for your downloads/illega browsing..

Everything is unblocked on CDMA, xcept wikileaks (even the govt blocked porn)

Dämn! So, to summarise, what I must do is:

1. Undo the TCPIP.sys patch - because you say to ignore it

2. Turn off the RC4 encryption - because you say there's no way to "mask" bit torrent traffic

You don't have to do anything... Try not to blow things out of proportion, there's plenty of folks doing that already.

1. TCPIP.sys Patch

No need to "undo" the patch, it can be left as it is without any harm. As a matter of fact, my TCPIP.sys is patched to allow up to 100 half-open connections. I was merely advising those who have not run the patch to ignore it because patching TCPIP.sys does nothing to improve speed. Moreover, should something go wrong during the patch process, he/she will be left with a broken TCPIP.sys file. Better to avoid, since there's no benefit from patching in the first place.

2. Protocol Encryption

My statement had nothing to do with enabling or disabling encryption. I don't know where you got the idea from to turn off RC4 encryption since I've never suggested it to begin with. Protocol encryption should always be enabled, if only for the added security.

Should any of you any need any pointers with any of the services I use, I'd be happy to help anyone that needs it.

Here endeth the lesson.

It might be easier if you just said, "I don't know anything about this topic, but I do know that services like RapidShare continue to work for me."

Maybe you could try less pontification, and provide more "pointers" in a less cryptic fashion?

Limiting sessions should be the extra step. Unfortunately most clients keep hundreds of sessions to other bit-torrent clients open, even when no data is being sent (except keep-alives). Some clients can be configured to limit the concurrent number of outgoing requests and limit the number of connections being build up during a time period, but it seems that nobody ever takes a look at these parameters.

A benefit to this is that your own router is not killing itself while maintaining a massive NAT table.

So is this working for you? And what settings are you using (Glonal maximum nu,ber of connections; maximum number of connected peers per torrent)?

Once TOT identifies BT usage (using your methods) by customer how do they limit BT traffic without impacting subscriber bandwidth which presumably must be available for downloading files from a rapid share site or to stream YouTube videos?

Unfortunately I have no solution for limiting the number of sessions in the client software. But I'm always surprised that there's dozens of connections open without any data being sent. The developers of client software should program something that disconnects the session when no data has been retransmitted for a specific time.

On the network, I limit the number of concurrent sessions per client to 250, which works out fine. But still the average download speed stays around 1Mbps. It's not that bad, I just have a bit more patience.

Unfortunately I have no solution for limiting the number of sessions in the client software. But I'm always surprised that there's dozens of connections open without any data being sent. The developers of client software should program something that disconnects the session when no data has been retransmitted for a specific time.

On the network, I limit the number of concurrent sessions per client to 250, which works out fine. But still the average download speed stays around 1Mbps. It's not that bad, I just have a bit more patience.

Could you possibly share a little bit more? Who is your ISP? Do you have DSL? What are the DL/UL speeds advertised for your package? Are you experiencing BT issues? How do you propose people address any BT issues?

It seems like with 250 concurrent sessions you would be 'discovered' by your ISP, and throttled? Did I misunderstand your original post?

A download speed of 1 Mega-BITS per second (~ 125 Kilo-BYTES per second, forgetting about overhead) seems reasonable, but that's impossible to determine without knowing what package you have.