IRC questions

[ironliver]

Got a few questions about irc

It seems a lot of DCC's to me doesnt work. Once in a while it does and i can download the file.

I *think* its because of my router/firewall blocking some ports? But why would some work and others not ?

Anyone know how to configure a router to accept all DCC's to me ?

I was reading a guide that told me how to do that, but i had to disable DHCP, and do some port fowarding. I cant put IP Addys in for all my computers, cuz they're not my computers. Is it just possible to open some ports on the router and it'll be all cool ?

Also is it ports 5000-5100 that are for DCC ?

[thebusby]

If your behind a firewall and they're not then it'll work. If they are also behind a firewall it wont. Google, "IRC firewall DCC" and you'll get a page explaining how to setup your router ;)

Originally posted by ironliver
Got a few questions about irc

It seems a lot of DCC's to me doesnt work. Once in a while it does and i can download the file.

I *think* its because of my router/firewall blocking some ports? But why would some work and others not ?

Anyone know how to configure a router to accept all DCC's to me ?

I was reading a guide that told me how to do that, but i had to disable DHCP, and do some port fowarding. I cant put IP Addys in for all my computers, cuz they're not my computers. Is it just possible to open some ports on the router and it'll be all cool ?

Also is it ports 5000-5100 that are for DCC ?

[VFRMike]

ironliver, if you are using MIRC, it prohibits a lot of file types through DCC unless you specifically allow them. If you can't get a file, try this command /dccallow +username. Username being the name of the person trying to send you the file. Hope this helps.

[morthrane]

The DCC protocol uses random ports I believe, and the sender must not be situated behind a NAT device (like most home routers)... unless the NAT device is "aware" of the protocol to start with.

[thebusby]

Originally posted by morthrane
The DCC protocol uses random ports I believe, and the sender must not be situated behind a NAT device (like most home routers)... unless the NAT device is "aware" of the protocol to start with.

IRC's DCC doesn't use random ports.

Here is a howto for linksys routers...
http://www.newircusers.com/java/router1.html

[morthrane]

Originally posted by thebusby
IRC's DCC doesn't use random ports.


I actually looked for this, but wasn't able to find anything close. RFC 1459 (IRC) (http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1459.html) doesn't actually mention anything about DCC.

The closest thing I can find is from an old help file that doesn't mention specific ports (but if it used specific ports, then we wouldn't have nearly as much trouble :laughing).

Its not truly random, but certainly close enough. Clients using a DCC SEND push whatever port they feel like to the receipent (via CTCP), usually based on a configured range. Random enough for my tastes, anyway. Not like HTTP which typically uses one of two ports for public purposes.

The following text mentions port 0, which I'm not really sure about, or as to why you need to bind a socket to port 0 when the client is sending a CTCP with the address and port of the socket...

Any network programmers know the deal with this?


Initiator:
DCC command issued.
Create a socket, bind it to INADDR_ANY, port 0, and
make it passive (a listening socket).
Send the recipient a DCC request via CTCP supplying
the address and port of the socket. (This
is ideally taken from the address of the local
side of the socket which is connected to a
server. This is presumably the interface on
the host which is closest to the rest of
the net, and results in one less routing hop
in the case of gateway nodes).
Continue normally until a connection is received.

On a connection:
Accept the connection.
Close the original passive socket.
Conduct transaction on the new socket.

Acceptor:
CTCP DCC request received.
Record information on the DCC request and notify the user.

At this point, the USER should be able to abort (close) the
request, or accept it. The request should be accepted with
a command specifying the sender, type, and argument, or
a subset of these where no ambiguity exists.

If accepted, create a TCP socket.
Connect the new socket to the address and port supplied.
Conduct the transaction over the socket.

[thebusby]

Originally posted by morthrane

Its not truly random, but certainly close enough.

You specify the port, thats not random or even close!

Thats like going to a gas station and asking for premium. Do you think that it was a random chance that you recieved 92 octane?

[morthrane]

Yeah yeah, you specify the port for a SINGLE INSTANCE. Last time I checked, when I go to "http://" it defaults to port 80. Now what if HTTP ran on any port from 1024 to 65535? :laughing The point is that you run DCC 10 times in a row, it won't necessarily use the same port. Or even close. Otherwise forwarding DCC to a single host behind a NAT wouldn't be a problem.

Stateful isn't enough, since all DCC requests are sent via CTCP, which is internal to the IRC protocol...

[thebusby]

Originally posted by morthrane
Yeah yeah, you specify the port for a SINGLE INSTANCE. Last time I checked, when I go to "http://" it defaults to port 80. Now what if HTTP ran on any port from 1024 to 65535? :laughing The point is that you run DCC 10 times in a row, it won't necessarily use the same port. Or even close. Otherwise forwarding DCC to a single host behind a NAT wouldn't be a problem.

Stateful isn't enough, since all DCC requests are sent via CTCP, which is internal to the IRC protocol...

To start the transfer you have to have some communication between the two clients. Your right web traffic wouldn't work if HTTP wasn't across a standard port.

The issue with DCC is that the client can communicate with the other client across the IRC threw CTCP and it sends a request with the address and port information of the type

PRIVMSG ((target) :^ADCC CHAT ((type) ((longip) ((port)^A

This,
The Initiating client, on creating the socket, should send its details to the target client using the CTCP command DCC. This command takes the form:

DCC type argument address port

type the connection type
argument the connection type dependant argument
address the host address of the initiator as an interger.
port the port or the socket on which the initiator expects to receive the connection.

In the case that you have multiple connections going at the same time most programs like mIRC usually just use the next port in the range. The user specifies the port range it can use though.

Here's a little example
Initiator:

* DCC command issued.
* Create a socket, bind it to INADDR_ANY, port 0, and make it passive (a listening socket).
* Send the recipient a DCC request via CTCP supplying the address and port of the socket. (This is ideally taken from the address of the local side of the socket which is connected to a side of the socket which is connected to a server. This is presumably the interface on the host which is closest to the rest of the net, and results in one less routing hop in the case of gateway nodes).
* Continue normally until a connection is received.

On a connection:

* Accept the connection.
* Close the original passive socket.
* Conduct transaction on the new socket.

Acceptor:

* CTCP DCC request received.
* Record information on the DCC request and notify the user.
* At this point, the USER should be able to abort (close) the request, or accept it. The request should be accepted with a command specifying the sender, type, and argument, or a subset of these where no ambiguity exists.
* If accepted, create a TCP socket. Connect the new socket to the address and port supplied. Conduct the transaction over the socket.

The only reason I can guess you'd think this would be random is that the transmitting party has the OS pick which port (thats what happens when you bind to port 0) to use but then transmitts that address and port info via CTCP. Many actual IRC programs don't do this though they instead have a range of valid port numbers to use.

In summary, your computer picks an free port and sends a request saying "Hey I have some data for you at this address". If the other side wants that data they'll open up a connection to that address and viola your done.