Stealth firewalled at BitTorrent site

[Ron]

I've read many posts and have a D-Link 4100 router. I've contacted D-Link support and they've said I've done everything right. Yet, my connection is displayed as being stealth-firewalled at a BitTorrent site though I opened my router port suggested by "Network options" in utorrent's "Preferences". The rest of the boxes are unchecked, though I've learned one can fool with the global settings. I'm downloading OK but I'm sure the speed could be better. I certainly don't see anything remotely close to 100. I've unblocked uTorrent from my Windows XP Firewall but I've learned you have to allow "in and out" on the single port. How that is achieved is vague from all the numerous posts regarding Port forwarding. Maybe the BitTorrent site I frequent doesn't recognize uTorrent but I certainly haven't found any info so far regarding the exact method for opening the assigned port to improve performance. Does anyone have advice on maintaining my security somewhat but having the port 32459 configured so I won't appear firewalled? :?

[chaosblade]

If im correct here, You need to allow incoming connections to the port you chose, but outgoing connections to ALL ports, since people chose a different port for their clients.

[Ron]

I apologize. This is only my first day and I'm not all that familiar yet with uTorrent and the fact it uses only one port. How do I achieve this? With uTorrent or Windows XP Firewall? My router is configured solely for TCP and allowing 32459 open. I've read many posts here on port forwarding but didn't find any regarding this issue. I was using ABC before and it wasn't indicating I was stealth firewalled until recently. I suspect maybe it has to do with the latest Windows XP security updates? I notice a lot more people have become stealth firewalled recently at DimeaDozen. Yet some do not. Of course I haven't seen anyone yet using uTorrent though so there's no one to compare with. Thanks for any advice you can give. I'm aware of the usual suspects. Could you point me in the right direction?

[sethg]

I don't have the same router as you, but assuming that it has NAT (network address translation) enabled, you typically have to forward the uTorrent port to your computer. Here's why.

Network address translation is a clever technique for a number of machines on a local area network to share one public IP address. That public address is on the cable or DSL side of the router and is the only address the rest of the internet can see. All machines on the local network use IP addresses from a range reserved for local connections. These IP's are not routable on the public internet, because everyone uses addresses from the same range locally. When a machine on your network wants to fetch a web page from the internet, it issues an HTTP GET command (using TCP) to the web site. As that packet goes through the router, the source address is changed from the reserved local address to the public IP address of the router. The trick is that the router has to remember that this is part of a "session" between one particular machine on the LAN and a remote web server. When the web server returns the web page to the router, the router looks up which local machine started that session and changes the destination address in the packet to the local machine. This effectively hides the local machine's address from the public internet.

What about unsolicited requests made by remote machines on the internet? Generally, most routers will drop those, unless you speciifically tell them to accept them on a particular port. In that case, there was no session started by a local machine, so the router has no idea which machine to send the incoming request to. That is the purpose of port forwarding. It tells the router which local machine to forward an unsolicited incoming request for a connection from a remote host on the internet.

Now, to make things even more confusing, when contacting other peers, you may make outgoing connection requests on almost any port. That is because the remote client may request connections on those ports. Fortunately, most consumer-grade routers allow outgoing TCP connections from arbitrary ports, or can be configured that way.

So to get uTorrent working, you have to tell your router:

1) open the uTorrent port for incoming TCP traffic

2) forward the uTorrent port to the local machine running uTorrent

3) open all ports above 1023 to outgoing TCP traffic (not required if already router default)

On some routers, doing #2 above automatically accomplishes #1.

I hope this makes things less confusing rather than more.

[Ron]

I'll get started based on what you've told me and get back with you. Again, thanks.

So to get uTorrent working, you have to tell your router:

1) open the uTorrent port for incoming TCP traffic (by configuring the router to open the port suggested in uTorrent's Network Options? Done)

2) forward the uTorrent port to the local machine running uTorrent (Using what?)

3) open all ports above 1023 to outgoing TCP traffic (not required if already router default) (I'll ask Dlink Support)

[sethg]

I'll get started based on what you've told me and get back with you. Again, thanks.

So to get uTorrent working, you have to tell your router:

1) open the uTorrent port for incoming TCP traffic (by configuring the router to open the port suggested in uTorrent's Network Options? Done)

There is an automatic method to set up your router and a manual method.

For the automatic method, you need Windows XP and your router must have Universal Plug 'n Play (UPnP) enabled. That should be in a setup menu for the D-Link. uTorrent has UPnP enabled by default. To verify this, go into the settings menu in uTorrent, look in Network Options and make sure the "Enable UPnP port mapping" box is checked. You're done (skip the rest)!

Some people consider Universal Plug 'n Play a security risk, but this is the easiest way to set things up. It's your choice. If your system doesn't meet the requirements above, or you don't like the security risk, use the manual method below.

First, uncheck the UPnP box in the uTorrent menu from above and make sure UPnP is disabled in your D-Link router, as well. Somewhere in the D-Link setup, there is probably a menu to open incoming ports. If there is such a menu, open the uTorrent TCP port. If there is not a menu to open incoming ports, there will be a menu to forward ports that both opens and forwards them. See step 2 below.

2) forward the uTorrent port to the local machine running uTorrent (Using what?)

If you are using the manual method, find the menu in the D-Link router setup that does port forwarding. Forward the uTorrent TCP port to the machine running uTorrent. The port forwarding menu will either request that you specify a machine name or an IP address. If it insists on having an IP address, you should probably set your machine up to use a static IP. If you are not comfortable doing that, find out the IP address of the machine running uTorrent and enter it. To find the IP address of a machine, open a MSDOS window, type ipconfig and hit return. One of the response lines will say "IP address". Enter that number (the format will look like 192.168.0.5 but use the number from your system) as the machine address to forward the uTorrent port to. This is not guaranteed to work forever, but the addresses given out to local machines by the router are supposed to be consistent, so you should not have any problems in practice.

3) open all ports above 1023 to outgoing TCP traffic (not required if already router default) (I'll ask Dlink Support)

Good call. Thanks for giving this a go. You won't be sorry

[Ron]

Stick a fork in it. It's done. I no longer appear firewalled to others. There are no red parentheses around my user name. I didn't even have to go to step 3. Honestly though, how secure am I with UPnP enabled? It was the only step I was reluctant to perform when first setting up uTorrent. Is there a way to satisfy both worlds when I'm using uTorrent and when I'm not other than changing the settings in the router and uTorrent every time I want to either torrent or be protected? Am I small enough potatoes that hackers won't bother? Thanks a heap for the guidance. I don't think anyone is using uTorrent yet at DimeaDozen (to my knowledge, legal downloads BTW). I wonder if my ratio will go down because they can't track it. I hope not. ABC sucked ass when it came to using so much resources so I'm glad to use uTorrent just to get some of my performance back. I hope they keep improving on uTorrent. A quick tutorial certainly wouldn't hurt for novices. The Internet has become a little less secure in the past couple of years so naturally I am reluctant to let my guard down too much. Again many thanks. I'll pass your tips on to others.

[chaosblade]

Good to know. UPnP is regarded as not being so safe, But i really dont believe it puts that much of a risk. Unless you know your way around a computer and wont start clicking random .exe files you have no idea where they came from (which is usualy the source of any problems), You should be ok with a decent antivirus (I recommanded kaspersky, Detected many a trojans in files and malcious code).

[Ron]

I may attempt to do the manual method once I feel comfortable with uTorrent. Two things I did notice. It seems my DL speed in torrents suffers if I surf the net at the same time I'm downloading. Also, it looks like DimeaDozen the torrent site doesn't recognize uTorrent and hence doesn't increase my ratio for uploading to peers once my DL is complete? My spam filter unfortunately deleted an e-mail from DAD's moderator so I may have to submit the question again to them. I heard Azureus had the same problem and users were forced to resort to either another client or use an older version.

[chaosblade]

On the first issue i can only say that download speed may suffer if you use too much upload speed, andor all of it. So even if uTorrent is capped other programs are pushing your connection to its maximum upload rate, That's usualy bad. You could try and use a program like NetLimiter to impose a global cap on upload rate.

On the second issue, It's definitly something with their detection of clients. They should add code to detect uTorrent properly, Though im not sure why this is keeping them from receiving the trackers messages sent by uTorrent (unless they block responses from unknown clients).

[Ron]

Going to have to find out at DAD. I had to join a forum via (ugh!) Yahoo and just as I was sending them an e-mail inquiry regarding uTorrent, Comcast showed up and disconnected my line to put a new one in. I'll let you know. Have to go to work now.

[sethg]

On the second issue, It's definitly something with their detection of clients. They should add code to detect uTorrent properly, Though im not sure why this is keeping them from receiving the trackers messages sent by uTorrent (unless they block responses from unknown clients).

You may well be right that it is the tracker software. However, I am still concerned as per our discussion in the thread about ending TCP sessions in the Bugs Found forum, that this is a uTorrent issue. My concern stems from the fact that after we manually shut down a torrent, wait for all the TCP connections to enter TIME_WAIT state (local outgoing buffers are empty), close uTorrent and wait for all the TIME_WAIT TCP connections to time out and close (whew!), there are still continual connection attempts by former clients on the uTorrent port for at least 24 hours.

It could be that the other clients are broken and never drop our IP address from their peer lists, but it is equally likely that we didn't successfully communicate with the tracker that we were leaving the swarm. That seems more likely, given the symptoms. It doesn't mean that we didn't tell the tracker we were leaving, it just may be that we didn't tell the tracker in a format that it understands. I suggest this since trackers apparently don't understand some of the other information we send them.

I haven't traced the IP's to see if it is a limited subset of client types or all clients that persist with connection attempts, so I have no proof one way or the other. The fact that incoming connection requests continue for so long after the user properly shuts down suggests that it's the communication with the tracker, not the individual clients, causing the problem, in my humble, but partly ignorant, opinion (IMHBPIO?).

This also makes me wonder what else the tracker doesn't properly understand that we tell it. Other people, including myself, have noticed that uTorrent doesn't seem to connect to as many peers/seeds as some other clients. That's subjective, and I also can't prove it, but it's been mentioned enough times that there might be some truth to it. You can't tell by the number of peers scraped from the tracker, as some of those peers could have left the swarm. uTorrent still works very well in practice, though that could parly be due to Azureus spreading our IP around via DHT. So the question remains, are we effectively getting the tracker to understand what we tell it? It's obvious that we successfully download a list of peers from the tracker, but it is less obvious that the tracker understands what we tell it.

Let's assume, for the moment, that we do properly tell the trackers our download/upload numbers, our IP address and when we enter or leave the swarm, and that the problem is the tracker software failing to understand us. I'm not sure it is likely that we can get the all writers of tracker software to change their code to accomodate any small differences in sematics that we use. Even if we could accomplish that, there would be a long flush-out period until the various sites running trackers upgraded their tracker packages. Anything reasonable that we can do inside uTorrent to solve this problem would have much better results than waiting for the rest of the world to accomodate us.

I haven't read the BT protocol standard, yet (looks like I need to), so I need to ask this question. Does the standard include the specific interactions with trackers and specify those semantics in full detail? If not, I'd suggest that rather than try to get all the trackers in the world to recognize yet another client (their job is already hard enough), it would probably be more successful if we mimic the client-to-tracker communication style of the Mainline BitTorrent client, or some other popular client of your choice. I'm not suggesting for a second that we should announce ourselves as anyting other than uTorrent, but we might use the Mainline communication style to exchange information with the tracker. Hopefully, that would cause the tracker to behave properly. This would fix the minor problem with download/upload numbers, but also the more important problem of taking us off the peer list to minimize the ongoing connection attempts long after we leave a swarm. If some trackers don't currently add us to the peer list when we join, then we would get some real performance benefits by making such a change.

The other related question that I have regarding the BT protocol is whether there is a method to tell a peer, before we close the connection with them, that we are leaving the swarm and to therefore take us off their peer list? If that method exists, it would contribute to solving the persistent incoming connection request problem.

Lastly, I would encourage the developers to consider the post from NiceGuy in the TCP connection thread. If there are indeed Windows methods for gracefully shutting down the socket, waiting for an acknowledge from the system and then closing it, or even setting the individual socket timeouts to zero and closing them, that would be better than just allowing them to go idle then time out four minutes later. If you want to be really polite, you could only apply this to sockets that have no outgoing data queued up in the socket buffers. However, I don't see the harm in just shutting them down hard and fast. That's what happens when you shut down the computer, so I assume that the BT protocol can handle that.

[Ron]

I think you're on to something because I left my torrent uploading until I returned home. Granted it was only at 30 or so kb/sec but my share ratio didn't change one iota upon my return. I'll contact DAD now that I'm home discussing the problem and let you know once they respond. I hope I can find someone more knowledgeable than peers on a forum.

[Ron]

I made a jpg of what Utorrent looked like as I downloaded a folder. I suppose there's no way of attaching it? In the General tab field, under Tracker, it's stated that it's working. Is that proof that the DAD tracker is indeed keeping a record of my share ratio?

[sethg]

Please include it in a post. I think that would be helpful.

[sethg]

Is that proof that the DAD tracker is indeed keeping a record of my share ratio?

It's proof that we think we told the tracker our numbers but it's anybody's guess if the tracker understood it. If you post the address for a specific tracker that does this, I think the developers will look into it.

[Ron]

I sent two jpg files to the server below reflecting my use of uTorrent. You'll probably receive 2 e-mails from usendit sent by me. I hope I've configured uTorrent properly. The second one crapped out in transit so deep-six it. No idea why.

First day

http://s46.yousendit.com/d.aspx?id=3AH6KSHM1KFVS1WK4SL2QWPCF4

Meanwhile DAD is having trouble confirming my membership since I used an e-mail address other than the e-mail address I used to register when I asked for support re: whether uTorrent was recognized by DAD's tracker properly. I am registed. Otherwise I wouldn't be able to participate in the sharing of the torrent. I sent them an explanation that I have 5 e-mail addresses with my ISP and even used the proper one to confirm my membership. They still refused to offer support because I initially asked for support using a different e-mail address other than the e-mail address I used to register. A convenient response for avoiding a technical question? I need a little privacy sometimes when joining bulletin boards. On DAD there are a few whackos. I know. I've read their posts.

[Ron]

Did you read this yet?

http://www.geeknewscentral.com/archives/005057.html