Jump to content

Setting outbound port ranges


Screndib

Recommended Posts

Right now it looks like uTorrent uses the default behavior of just getting a random port when it makes an outgoing connection. What would be nice is the ability to set a range of ports that will be used when making a connection. I haven't done any sockets programming in a while, but from what I can tell this would be a fairly easy feature to implement. I believe it would only require adding in a call to bind the socket to a port before it connects and whatever fairly simple logic would be needed to keep track of open ports.

This feature would make it much easier for me to shape bittorrent traffic using port-based shaping tools, specifically m0n0wall. Right know I know all incoming connections are coming to the port that I specified, but any outgoing connections are completely random.

Link to comment
Share on other sites

Yeah, it does if you call just call connect after creating the socket. I can't test it right this second because I'm at work, but I'm fairly certain that if you bind the socket to a specific port before calling connect it will use that port rather than allowing the operating system to automatically select one at random.

Pseudo code such as:

mySockaddrStruct.sin_port = OUTGOING_CONNECTION_PORT_NUMBER;

bind( mySocket, &mySockaddrStruct, sizeof(mySockaddrStruct) );

connect( mySocket, &connectionSockaddrStruct, sizeof(connectionSockaddrStruct) );

Link to comment
Share on other sites

  • 1 month later...

oh well, several days ago i sent again an email to ludde with this exact feature request. i wrote that it would be very easy to implement and not only in mirc it is also possible to specify the port range to use for all outgoing connections.

he still hasn't answered yet.

i wrote two times "PLEASE" in my email. maybe this wasn't enough?

also some weeks ago i sent him an email with the request to, please, add a tooltip with a description of all the peers flags to the peers tab which would be very useful for nearly every user and which i think simply HAS to be there. he answered me that he would keep it in mind. til today he STILL didn't implement it. i'm quite sure it's already a month or more ago i sent him this first email.

there it goes, his willingness to actually "do it for the community".

i (and i'm sure the whole community) expect a clear answer.

edit: btw, these are NO cosmetical feature requests like ALL the other requests (which are simply unimportant for now), these are fundamental features. first, outgoing port ranges are a must-have for a decent network application; second, the description of all peers flags has to be a part of the documentation.

so this is not your average "please add a fancy button which makes sound" request. this is serious stuff which is still missing, although this application is in 1.5-stage.

Link to comment
Share on other sites

maxe: I'm not sure what your problem is, but Ludde is the one who decides what goes in and what stays out. You don't need to get angry just because your feature wasn't implemented. We all want our own features included, but if he doesn't like it, that's where it ends. Gheeez... :/

Link to comment
Share on other sites

i never was angry, i'm just stating the facts here. i may sound a bit harsh, so what, im expressing feelings, can you do the same?, but reread my post and you will realize that ludde actually does nothing for the users.

you don't need to play the forum police here because YOU AREN'T. add something useful or when you don't have anything useful to add, to put it against your angry childish words, shut up.

btw, i reported your post.

Link to comment
Share on other sites

i wrote that it would be very easy to implement and not only in mirc it is also possible to specify the port range to use for all outgoing connections.

The thing is, DCC transfers connect in reverse. The DCC range specified in the preferences of mIRC is still a listen range, not an outbound connection range. (Why do you think there's a firewall workaround function in most f-serve scripts for mIRC?)

Whenever it has been suggested to Ludde to e-mail someone, he has always said that he prefers contact over IRC, so e-mailed feature requests will probably be ignored.

Link to comment
Share on other sites

The thing is, DCC transfers connect in reverse. The DCC range specified in the preferences of mIRC is still a listen range, not an outbound connection range.

that's plain wrong. the port range specified in mirc applies to ALL connections.

you write about dcc gets only. server connections in mirc are still outgoing not incoming. also outgoing dcc transfers (dcc sends) are outgoing connections.

Link to comment
Share on other sites

also outgoing dcc transfers (dcc sends) are outgoing connections.

DCC SENDS are incoming connections by default.

Why do you think people behind routers and firewalls have so much trouble sending files?

Why do you think IROffer XDCC bots have such problems behind firewalls/routers that don't have the ports open?

Why do you think that f-serve scripts have firewall workaround?

that's plain wrong. the port range specified in mirc applies to ALL connections.

Only when you have both checkboxes selected in the port range screen.

Most people only select DCC there (which is the default).

When you restrict your ports to such a range in mIRC, you are restricting to a total of:

1> The number of servers you're connecting to

2> The number of DCC chats you have open

3> The number of DCC Sends you have open

4> The number of DCC Gets not using the firewall workaround you have open

When you restrict your ports to such a range in a BT client, you are restricting the number of outgoing peer connections.

Also, the last time TheSHAD0W tried to restrict the outgoing port ranges, it didn't work out too well once he tied up all the ports within the range.

If this setting is implemented, people WILL set it wrong. Even if it's buried under 20 layers of configuration screens, people WILL find it and WILL set it wrong.

Link to comment
Share on other sites

omfg get your stuff right, kid. nearly EVERYTHING you wrote is WRONG, plain wrong.

i spare my time and won't correct you here, go educate yourself.

fyi: there is always a client and a server. one who initiates the connection and one who accepts it. and yes, you have NO knowledge about networking. and yes, i don't care what you think. screndib and me made a feature request. a very decent one. don't! reply to this fyi, just read my next statement.

damn, i'm discussing networking fundamentals with an i***t.

Link to comment
Share on other sites

The port range in mIRC only applies to DCCs, unless you check 'Other.'

He is also right about DCC sends and chats, when you "initiate" one, you actually send a DCC message across the IRC server (as if it were a normal message), then the person you're sending to tries to make a direct connection to you. DCC Sends and Chats really are incoming connections.

Link to comment
Share on other sites

omfg get your stuff right, kid. nearly EVERYTHING you wrote is WRONG, plain wrong.

If you don't believe me that DCC connections happen in reverse to what you say, packetsniff your IRC client while initiating a DCC transfer (in either direction) and watch the traffic flow.

Procedures for a non-firewall-workaround DCC connection:

> Sender opens a listen socket in their DCC range

> Sender sends a DCC request via the server to the intended linking party with their IP and Port

> Reciever attempts to connect to the IP and Port sent in the DCC request.

I'm not disputing the client and server basics. I'm disputing which end is the client and which one is the server in IRC DCC transfers.

Passive and Active FTP anyone?

Link to comment
Share on other sites

  • 1 year later...
mySockaddrStruct.sin_port = OUTGOING_CONNECTION_PORT_NUMBER;

bind( mySocket, &mySockaddrStruct, sizeof(mySockaddrStruct) );

connect( mySocket, &connectionSockaddrStruct, sizeof(connectionSockaddrStruct) );

That's already done. Setting net.outgoing_port does exactly this. And you haven't explained why you need more than one port for traffic shaping.

Link to comment
Share on other sites

Sorry about the duplicate post, other forums also have policies against responding to very old threads.

I don't need more than one outgoing port if utorrent is able to run fine through a single port, I assumed that since it uses multiple outgoing ports by default there was a good reason for it. A single port would be preferred.

The problem with net.outgoing_port is that I don't actually understand what it does in addition to running all outgoing connections through that port. Can you tell me why it causes me to lose connection to the tracker (all up/down arrows go red)?

Also there's this bit from the FAQ:

net.outgoing_port makes µTorrent use a single outgoing port. This should only be used in specific cases. "This can be used with full cone NAT routers to reduce the number of NAT table entries and thus prevent crashes on some router models. When the outgoing port is bound to the same as the incoming port that might even solve NAT problems on full cone NAT routers." - AzureusWiki. This option may not be working properly. It will only work on Windows 2000 and later.

This seems to indicate it's a hack to fix a specific problem with some routers and it doesn't always work correctly (which I'd be inclined to agree with since it seems to cause tracker problems for me). If there's a further explanation as to what exactly net.outgoing_port does I'd be interested in reading it.

Link to comment
Share on other sites

The problem with net.outgoing_port is that I don't actually understand what it does in addition to running all outgoing connections through that port. Can you tell me why it causes me to lose connection to the tracker (all up/down arrows go red)?

Hmm... I don't get that result here (at home behind a Netgear FVS318) when I try it. I do get errors from peers when my client tries to reconnect, since they don't seem to appreciate that the port changed. But no tracker problems. So I suspect it might be your router perhaps?

Edit: come to think it, it might be a feature of certain trackers that they're suspicious about the port number changing?

Link to comment
Share on other sites

I'm running a m0n0wall box for my router which is usually pretty solid. I'm not going to say that it can't be causing problems but I don't think it's likely.

I looked into this a bit further. It looks like (as you probably already know) it's also using the net.outgoing_port port to connect to the tracker (which for my specific purposes is unnecessary because I don't care about filtering that traffic). When I look at the 'Tracker Status' of the problem torrents it says

"Only one usage of each socket address (protocol/network address/port) is normally permitted."

which here (error code 10048) it looks like it's coming from the OS on my end (XP Pro) rather than from the tracker.

It seems that the torrents are colliding when they're trying to reach the tracker on the same port. If I select 10 of them and do an "Update Tracker" on them all at the same time, they'll all go red with that error message. They'll then switch between green or red every time they auto-update depending on, I guess, whether or not they're colliding on the single outgoing port. All of the torrents are running off of the same tracker.

It seems that the fix for the tracker problem would be to just run torrent connections through the port in net.outgoing_port and let tracker queries and whatever else just do their thing with any assigned OS port. Torrent connections don't seem to have this problem, torrents will quickly connect to many peers.

Link to comment
Share on other sites

looked into this a bit further. It looks like (as you probably already know) it's also using the net.outgoing_port port to connect to the tracker (which for my specific purposes is unnecessary because I don't care about filtering that traffic).

Yeah, it limits you to one connection to each tracker, including past ones sitting in TIME_WAIT. And each peer. And each web seed (in 1.7). Adding more ports would reduce the frequency the endpoint tuple conflicts with an existing tuple in TIME_WAIT, but not really solve it. We could add a specific port setting for peer connections (leaving the existing setting to the legacy router support), but that would limit the number of connections you can have to a single peer, and it's probably a really bad idea for web seeding since the same web server likely will back up a large number of torrents. (And you'd certainly want to shape this traffic as well.)

The cleaner change would be to add an IP TOS label setting and use that to identify download/upload traffic. How many routers can do QoS based on TOS labels?

Link to comment
Share on other sites

I haven't done a ton of network programming so you'll have to excuse me if I stop making sense at some point.

Adding more ports would reduce the frequency the endpoint tuple conflicts with an existing tuple in TIME_WAIT, but not really solve it.

Given a large enough port range it is essentially solved. As it is, I believe windows by default won't give out any ports above 5000 unless you make some changes in the registry, you'd have to be making a lot of connections to fill that up. How many connections per peer are being made anyway? Since the port can be reused for each peer you'd really only need to set aside enough ports to reach the maximum number of connections to a single peer wouldn't you?

I agree though that some sort of packet based filtering is a better option. m0n0wall appears to support the default TOS values (lowdelay, throughput, reliability, mincost, congestion) but there's no way to define your own values to filter by. Also, I don't know if using the default TOS values will make it significantly easier for the ISP to filter torrent traffic.

Link to comment
Share on other sites

I agree though that some sort of packet based filtering is a better option. m0n0wall appears to support the default TOS values (lowdelay, throughput, reliability, mincost, congestion) but there's no way to define your own values to filter by. Also, I don't know if using the default TOS values will make it significantly easier for the ISP to filter torrent traffic.

That's a bit old... the TOS field was redefined in rfc 2474 to be a set of diffserv codepoint spaces (DSCP).

OK, I agree there might be a case for an outbound port range.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...