Incoming connection

[pax]

Hello all.

Quick question about connections....

µTorrent works fine, and I'm downloading and uploading fine.

My upload is capped at 60KB/sec, and I'm downloading at

whatever speed I can get, so no problem there.

However, I occasionally get incoming connection alerts to

utorrent application on random ports from varying endpoints

reported by my Firewall, which I keep blocking.

I looked in the FAQ and it says this about connections outside

specifide port:

-----------

My firewall is reporting connections being made by µTorrent on a port besides the one I selected. What gives?

Only incoming connections use the port you selected in µTorrent. Outgoing connections use a random local port; this is simply the way TCP/IP functions. It's not a bug.

If you have a firewall, you must allow all outgoing traffic on TCP and UDP.

------------------

So, as far as I can see, regular incoming traffic should be made on

the port specified in the config. Which leads to my question:

- What are these incoming connections on other ports? Since

I keep uploading fine, I assume I'm not blocking anyone...

Thanks to anyone who can shed some light on this.

Regards

Edit: I also did a search in the forum (quickly) and couldn't see this question

answered elsewhere.

[splintax]

hmm, assuming what you're saying is all correct, i'm not sure what the problem could be...

maybe i've misunderstood you...

which firewall are you using? there is some distrust of software firewalls here

[pax]

Hmm.. I'm using Kerio PFW...

Anyway.. I've looked through the forums a bit more, and I've checked my the Peers

tab, and I have no peers with blank "Port" number and no "Flags" with "I"...

So... maybe there are some incoming connections I should accept?....

But then I don't understand too well what I quoted from the FAQ:

Only incoming connections use the port you selected in µTorrent. Outgoing connections use a random local port;

Anyone else have any ideas on this?.. Maybe I'm losing out on DL speed because I'm

blocking these connections.. ... Maybe I'm blocking someone else?..

[splintax]

Well, personally, I would just unblock all µT traffic, since I trust the developer...

But hey, if you're concerned, that's fair enough, especially since what you're seeing is contradicting the FAQ. (Kudos to you for actually searching and reading before coming in here and bitching about how µT is haxoring your PC!)

[Firon]

I = interested

Various topics on the forums are WRONG, I is not incoming. A blank port in the Port column is incoming.

If you have no peers with blank ports, it means you're not allowing incoming connections. You should allow them on the port that you specified in µTorrent on TCP and UDP.

Incoming connections on other ports are probably unrelated random port scans, or anti-p2p (probably the first). Allowing them wouldn't help, since µTorrent isn't listening on any of those ports. Only the one you set.

And like the FAQ says, you need to allow -all- outgoing communication for µTorrent in your firewall.

[pax]

I = interested

Various topics on the forums are WRONG, I is not incoming. A blank port in the Port column is incoming.

If you have no peers with blank ports, it means you're not allowing incoming connections. You should allow them on the port that you specified in µTorrent on TCP and UDP.

Incoming connections on other ports are probably unrelated random port scans, or anti-p2p (probably the first). Allowing them wouldn't help, since µTorrent isn't listening on any of those ports. Only the one you set.

And like the FAQ says, you need to allow -all- outgoing communication for µTorrent in your firewall.

Thanks for the info on the "I" flag

I am allowing all outgoing communication. I'll need to explore this a bit more to see why I don't have any incoming connections... Seems strange. If anyone else has any thoughts or experiences on this, let me know.

Thanks again.

[aadu]

interesting indeed.... in FAQ: I = interested & blank port = incoming

however... when i look at the peers that are flagged 'I' and check these connections from a firewall or TCPView ( http://www.sysinternals.com/Utilities/TcpView.html ) they always appear to be incoming (connected to my defined µ port) AND not all of them are 'blank' ports. so what gives? changed behaviour and not updated FAQ or...

[Firon]

[aadu]

please explain this

edit: my µtorrent uses port 52555

[Firon]

Your viewer is wrong.

I've also seen the I flag when no incoming connections are possible (NAT Error)

Can you explain that?

[aadu]

well.. for 1 thing, the TCPView is not wrong.

and the I-flag might be working as intended/designed indicating 'Interested'. still, if the coder decided to show if a connection is incoming or outgoing i think there is some room for improvements here

[Leech_Hunter]

@aadu

yeah , you are correct. I also wondered about this & did a bit of sniffing. Every time there is an 'I' flag, with a port #, the session IS actually made from the remote peer.Also.did you notice that the port # displayed in µtorrent is actually incorrect - your screenshots show this & the tests I did showed the same....strangely all the ones that met that condition were from 100% seeds, it's not possible to see from your screenshots if it was the same for you.

I used ethereal to capture the setup.

Explain that?

[boo]

lol leech hunter, both peer ports are inside the port range that ethernal log show

[pax]

Hmm.. this seems rather strange...

However, I guess it's safe to block these incoming connections. I am now downloading 5 torrents simultaneously, having a total DL

speed of between 250 and 400KB/s and uploading at 60KB/s (capped)....

So I guess these occasional incoming connection attempts indicate either an error in the FAQ or there's something fishy going on (random port scans, anti p2p, whatever....)

[aadu]

@Leech_Hunter

yup i noticed some of the port #s in µ do not match the actual ports in use and although i do not want to speculate why is that i have a couple of ideas ; the reason i did not mention this earlier is that i simply did not want to add more confusion to this thread

on the other thing... 100% seeds and 'I' as Interested do not make much sense, do they lol.

but the incoming 'I's here are not all 100%:

@Firon

curiously I do not see any I-flags at all on another pc that is behind a NAT and firewall so no incoming connections possible. which again suggests that I-flag and incoming connections are somehow related

@pax

I do not see any reason to block these incomings.. they're normal bt connections, nothing wrong with them apart the presentation weirdness in µ

[pax]

@pax

I do not see any reason to block these incomings.. they're normal bt connections, nothing wrong with them apart the presentation weirdness in µ

Well.. then this doesn't make any sense.....

Allowing them wouldn't help, since µTorrent isn't listening on any of those ports. Only the one you set.

Getting more and more confusing....

[aadu]

@pax

what Firon says is true, no confusion here: µTorrent is listening only the port you set it to listen (or a random port if you have chosen so). confusing is the meaning of the I-flag and on some occasions the port # of the remote peer

[pax]

@pax

what Firon says is true, no confusion here: µTorrent is listening only the port you set it to listen (or a random port if you have chosen so). confusing is the meaning of the I-flag and on some occasions the port # of the remote peer

Hmm.. maybe it's just me...

But if µTorrent isn't listening on the other random ports, there is no reason not to block them, is there?

So might as well block?.. Or..

[aadu]

@pax

now that i've re-read your original post... i c i was referring to a different thing lol

sorry, i'm not sure what these incoming connections to µTorrent that you say your firewall detects are. wild guess: erratic firewall behaviour.

AFAIK, the packets contain only information of the destination ip and port among other things but certainly not of the application that they are meant for

[splintax]

I = interested

Various topics on the forums are WRONG, I is not incoming. A blank port in the Port column is incoming.

I personally reckon that the whole flags section could do with a little work.

I for interested is OK, but 'blank port' for incoming connections? How about another column that just says "in" or "out"? Seems simpler to me.

And what about getting a better flag for DHT, if there is an uninterested peer you're downloading off the flag will just be D (not 100% sure on this), so how do you know if they're a DHT peer or not?

[aadu]

alright, the port# mystery is solved, or at least i think i got it right after a few tests

so for the firewalled remote peers µTorrent displays not the actual port in use but what the remote peer is set to use this is sort of nonsense as the port# setting has no useful meaning for a firewalled client :/

[splintax]

No, a firewalled remote peer will never display a port - since they can only connect to you locally (ie. an incoming connection = blank port).

If you do see a port it means you connected to that peer - ie. they are connectable/not firewalled, and the port is the port they have open.

[pax]

alright, the port# mystery is solved, or at least i think i got it right after a few tests

so for the firewalled remote peers µTorrent displays not the actual port in use but what the remote peer is set to use this is sort of nonsense as the port# setting has no useful meaning for a firewalled client :/

I think you may be right.. I've managed to set up my port forwarding and I have "Network OK" now.

And I checked a bit more into the firewall warnings, and the local endpoint must have been my uTorrent port, while the

port number I wondered about must have been the remote.. Bit strange behaviour still, though.. that even without these

I could download and upload fine... maybe most people run default settings..

[Leech_Hunter]

lol leech hunter, both peer ports are inside the port range that ethernal log show

<snigger>You don't understand how to read an ethereal log. 3939 > 55560 does not indicate a range , but the respective port numbers of the SA > DA packets.

If you do see a port it means you connected to that peer - ie. they are connectable/not firewalled, and the port is the port they have open.

See the screens I posted - The ethereal log clearly shows that the session was initated from a remote ip address/peer ( follow the classic TCP SYN, SYN-ACK, ACK handshake) , yet µtorrent displays a port number for that session, a port number that does not actually correspond to that particular TCP conversation. Aadu has it right.

[Steady]

I had this problem too. When I check the log of uTorrent in Kerio,

it shows incoming connections outside the port I gave for uTorrent.

But, in the application column it says N/A, not uTorrent (for those connections that are blocked).

What is the meaning of this?