Forums General Discussion mIRC and TCP ports/connections

These are just some of my own observations about mIRC's use of TCP/IP connections on Windows. I used the "netstat -a" command to get the information. Admittedly, I should also read the protocol specification for IRC, to see if it specifies how connections/sockets are to be used, and what time-outs, etc. should be used.

Two of the most confusing terms used for TCP/IP are "port" and "connection". A port is one end of a connection. For any connection there are two ports. The port that initiated the connection, and the port that accepted (listened for) the connection. A connection is defined by the IP address and port at each end of the connection. One port can have many connections. As long as either end of the connection has a different IP address, or port, it is a separate connection.

In most situations your computer will initiate the connection, and a server on the Internet will accept (listen for) the connection. Servers listen on well known (preassigned) port numbers.

For peer to peer connections like DCC, one computer has to tell the other computer which port is listening for a connection. The listening port is the DCC port, or DCC server port.

mIRC opens one TCP/IP connection from the randomly chosen application ports range (1026, etc.) to the IRC server port (usually 6667). So far as I can tell this single connection is used for both send and receive data between mIRC and the server.

For DCC chat and file transfers, mIRC listens on a DCC port if it is the initiator of chat, or sender of the file transfer. If mIRC is the acceptor of chat, or receiver of the file, it connects from the randomly chosen application ports range (1026, etc.) to the initiator/sender's DCC port. So far as I can tell this single connection is used for both send and receive data between the two computers using mIRC.

For any TCP connection that mIRC has open, it also listens for connections on that port. I'm not sure why that is, because it even seems to listen on ports that are obviously not going to receive connections (1026, etc.). I have not investigated what would happen if something attempted to connect to one of these ports (a firewall/router would prevent that anyway).

When mIRC terminates a DCC session, or a link to a server, it uses a normal close for a connection, that puts the connection in a TIME_WAIT state. When a connection is closed, mIRC also stops listening on the associated port.

mIRC does not use half-open connections (where one side has closed and the other has not). All open connections are in the CONNECTED state. Since mIRC only opens one connection per server, my assumption is the connection handles both send and receive data. The same thing applies to DCC connections.

When a router is involved, the application ports (1026, etc.) get translated by the NAT router to some other port (ex. 61177) The DCC ports do not (because the router is configured to pass them through).

DCC ports are whatever you tell mIRC to use in the mIRC configuration. If you're using a router, the router has to be configured to pass these ports through unchanged.

You only need the DCC ports if you plan to send files, or initiate DCC chat. You can receive files, or receive DCC chat requests without configuring your router to allow incoming connections.

There has been a lot of discussion about how/when mIRC detects a lost connection to a server.

There are basically three ways a connection can be closed.

• A normal close. Send a FIN message, and wait for the other computer to send a FIN message.
  
• A hard close (or abort). Send a RST message, and don't wait for the other computer. If the other computer sends you anything else, respond with another RST message.
  
• A keep-alive time-out (may be disabled). If no messages are received for too long, assume the connection has closed (as if a RST had been received).
  

Most programs use a normal close (mIRC seems to use this). The other end of the connection will not know the connection has closed, until it tries to receive something from the connection. The other end can still send data, and sending data will not tell it that the connection has closed. Applications usually have some message to tell each other they are done, and both do a normal close. That way they don't have to try and detect that the other end closed the connection.

Most programs don't use a hard close, because any unread data is lost (mIRC does not seem to use this). For example, sending a "/QUIT" would do no good with a hard close, because the connection would probably close before the "/QUIT" got read by the program on the other computer. If applications don't care about that, using a hard close may be a faster way to detect closed connections due to errors.

The keep-alive timer is usually very long (many minutes). In most cases, I would expect a program to detect a loss of communication before this aborts the connection.

When sending or receiving data, programs can use blocking (wait for ready) or non-blocking, (return an error if not ready) mode.

If communication is lost between mIRC and an IRC server, I would expect any number of possible things to happen.

• mIRC doesn't know the connection has closed for a while, because no FIN has been received.
  
• If mIRC tries to send enough data, it might detect the lost connection, if it is using the non-blocking mode of sending.
  
• If the socket has been set to use a keep-alive timer, eventually Windows will close the socket, and mIRC should detect that in its receive processing.
  
• The router (if any) may have a keep-alive timer, and may respond to Windows with a RST when mIRC tries to send data.
  
• The router (if any) may have a keep-alive timer, and may actively send a RST to the Windows computer. Windows will close the socket, and mIRC should detect that in its receive processing.
  

What happens on a loss of communication to a server depends on these things.

• Does mIRC use the non-blocking mode for sockets?
  
• Does mIRC use a keep-alive timer for sockets (that might be the default in Windows)?
  
• Does the router have a keep-alive timer?
  
• If the keep-alive time expires, does the router immediately send an RST to Windows, or does it wait for a message before sending RST?
  

The first two questions can probably be answered by someone who has looked at the mIRC source code. There might be other mechanisms in mIRC to detect a lost connection, such as a receive time-out, or send time-out.

The second two questions depend on the router, and might be hard to determine even knowing the exact router being used.

My conclusion is it's probably normal for lost connections to be undetected by mIRC for a period of time. It's also probably normal for lost connections to suddenly be detected by mIRC when an attempt is made to send something. Changing settings in Windows or the router (if any) might reduce the time required to detect a lost connection. Why the connection was lost could also affect how soon the lost connection is detected.

Fairly accurate article as best as I can tell. Though I'm sure there are additional circomstances that may cause a stale connection, including physical interruptions in the connection and crappy/ misconfigured (home) routers that filter things it should not.

Also, you might consider using TCPView (www.sysinternals.com) instead of NETSTAT. Someone also told me that Win2K makes it appear that the client-port endpoint appears as a listening socket, however this port still refuses connection and so it should be ignored.

You accurately noted that client ports are randomly/ incrementally chosen from the 1024-5000 Shared Application Port range, but should also include that DCC (sender/ chat initiator) Listening ports are also chosen in in the same manner by default, even though they are "server ports". Not _ALL_ "Servers listen on well known (preassigned) port numbers." if you consider DCC (and even FTP) data ports as servers (short-lived servers anyway).

You should also mention that when configuring a router to forward DCC ports, a range OUTSIDE of 1024-5000 should be chosen... contrary to many documents that recommend ports 4000-up. I've encountered some very disturbing home routers that translate "DCC Packets" (
DCC SEND file.ext ipaddress port filesize
) by changing the port value to 60000+ (or in some cases completely mangle the packet) if the port value falls inside 1024-5000. I recommend some high range between 12000 and 65535 that wont interfere with other applications, and that isn't as easy to scan for (which can interrupt/ intercept DCC connections if timed right).

Oh, and if you goto Options (ALT+O) > Connect > Options > Advanced... You can checkbox [x] Use random ports for listening sockets (which should actually read "connecting sockets"). This option will make mIRC choose random high client-ports instead of 1024-5000 when establishing a connection to an IRC server. This makes Destination Unreachable (click2) attacks much more difficult, if you're not already protected by a firewall or would prefer not to filter these ICMP packets.

- Raccoon

Thanks Raccoon. It's nice when someone contributes more useful information to a topic. I changed my router and mIRC configuration as you suggested. Do you have any thoughts about the problem of getting routers to handle identd for multiple computers running mIRC? I got my D-Link DI-604 to grudgingly do that, except I have to mess with it every time I reboot it.

I've used some of the Sysinternals programs before, but I keep forgetting to check their site.

I write and troubleshoot TCP/IP network stacks and drivers for a process control company. I've found that every TCP/IP implementation, and every application program do things a little differently. I'm curious if mIRC uses the asynchronous, Windows message driven interface to WINSOCK, or if it uses the unix-style multi-threaded approach to handling connections.

I have a DI-604 myself, so I'm interested what setup you're using. I use an Application entry triggered on TCP 6661-6669 to enable 59,113,12000-12499. If I want to IRC from another computer, I just allow it to ident off the one already connected. It really sucks this router wont let you forward "Virtual Server" a range of ports with exception to the above feature.

I apologize if my previous post keeps flip-flopping using different terminologies, but I didn't learn about TCP/IP from a single source so I mix and match phrases like "client port" with "local port" and "connecting socket" vs "server port" and "listening socket". It's often difficult to explain TCP because there are different vantage points depending on what you're trying to accomplish.

To answer your last question, I would say the former because mIRC is still a simple single threaded app and seems to hang when any significant flood of data ties up one of the connections. Process Explorer says mIRC uses 2 threads, this could be a timer object, I don't know. I think multi-threaded anything would break mIRC Script with race conditions.

- Raccoon