|2. What is DCC? Back to Top|
DCC allows you to connect directly to another
IRC client, instead of going through the IRC Network, to Send and Get files,
and to Chat privately over a more secure connection.
By default, mIRC will
pop up a dialog asking you if you want to accept the file, however if you
select the Auto-Get file option then mIRC will automatically accept the
file. If you select Ignore All then all incoming DCC send requests are
ignored. If you choose to accept the file, mIRC will ask the sender to
begin the file transfer, at which point you should begin receiving the
file. If someone tries to send you a file that already exists in your get
directory then you will be shown a warning that the file exists. You then
have the option to either overwrite the file, resume the transfer, or rename
the file. If you choose to overwrite the file then the whole file will
be downloaded from the beginning and any existing file of the same name
is erased. If you select resume then mIRC will attempt to negotiate a transfer
resume to get the remaining part of the file.
|3. Why DCC? Back to Top|
DCC allows the user to overcome some limitations
of the IRC server network and to have the ultimate in secure
chat connections while still in an IRC oriented protocol.
DCC uses direct TCP connections between the clients
taking part to carry data. There is no flood control, so
packets can be sent at full speed, and there is no
dependence on server links (or load imposed on them). In
addition, since only the initial handshake for DCC connections
is passed through the IRC network, it is impossible for
Operators with cracked servers to spy on DCC messages.
|4. How does DCC work Back to Top|
The initial socket for a DCC connection is created
by the side that initiates (Offers) the connection. This socket
should be a TCP socket bound to INADDR_ANY, listening for
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:
Format: DCC <type> <argument> <address> <port>
- The connection type
- The connecting type dependant argument
- The host address of the initiator as an integer
- The port or the socket on which the initiator expects to receive the connection.
The address and port should be sent as ascii representations of the
decimal integer formed by converting the values to host byte order
and treating them as an unsigned long and unsigned short respectively.
The following DCC connection types are known to IRCII:
||To carry a secure conversation
||the string "chat"
||To send a file to the recipient
||the file name
In addition, the following are included in the IRCII DCC command,
although they do not transmit a DCC request via IRC:
TALK = Establishes a TALK connection
|5. The Implementation of DCC Back to Top|
The CHAT and SEND connection types should not be
accepted automatically as this would create the potential for
terrorism. Instead, they should notify the user that an
offer has been made, and allow the user to accept it.
The recipient should have the opportunity to rename
a file send with the DCC SEND command prior to retrieving
The following are the steps which should occur in
- 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.
- 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.
|6. Type specific details Back to Top|
The two types we explain here are CHAT and FILE.
Data sent across a CHAT connection should be sent line-by-line
without any prefixes or commands. A CHAT connection ends when
one party issues the DCC CLOSE command to their clients, which
causes the socket to be closed and the information on the connection
to be discarded.
Data is sent in packets, rather than dumped in a stream manner.
This allows the DCC SEND connection to survive where an FTP
connection might fail. The size of the packets is up to the
client, and may be set by the user. Smaller packets result
in a higher probability of survival over bad links.
The recipient should acknowledge each packet by transmitting
the total number of bytes received as an unsigned, 4 byte
integer in network byte order. The sender should not continue
to transmit until the recipient has acknowledged all data
already transmitted. Additionally, the sender should not
close the connection until the last byte has been
acknowledged by the recipient.
Note that it is not possible for the recipient to tell if the
entire file has been received - only the sender has that
information, although IRCII does not report it. Users generally
verify the transfer by checking file sizes.
Note also that no provision is made for text translation.
The block size used by IRCII is BIG_BUFFER_SIZE (1024).
This should probably be reviewed and reduced.
|7. What causes DCC Send problems Back to Top|
There are many causes that can lead to DCC send
errors, but to start out, you need to understand the basics. When you DCC
someone, the following process takes place:
- You send a notice to the person sending
-Yournick- DCC Send filename
- Their mIRC initiates a connection to
If YOURIPADDRESS is incorrect, then the
transfer will never take place - it's trying to goto an address that isn't
assigned to you. Also if you are running any type of software (or your
ISP is) that controls/monitors incoming connections, this may not allow
the user to get through to you. This software is known as firewalls, proxies,
wingates, ICS, and other multiple PC internet connection supporting software.
This is also why you are able to receive but not
send - think of the connection process backwards... when you send a file,
the other user connects to you, when someone sends you a file, you are
connecting to them.
|8. Easy Fixes Back to Top|
Built into mIRC 5.71 and newer, is a command
called /localinfo -uh. It's describe in the help file as:
/localinfo -uh [host ip]
Looks up and sets your local info settings. The
-u switch performs a /userhost lookup, the -h switch does a normal lookup. If you wish, you can also set
the local info manually by specifying the host and IP values.
Note: This process isn't flawless and doesn't
always solve the problem, read on for more help.
If you see the message Unable to resolve Local
host with the 32bit version of mIRC, the problem might be related to using
a 16bit winsock, so you should try out the 16bit version of mIRC to see
if it works for you (or download a 32bit winsock) at http://www.sockets.com/
If you type the command /localinfo -u mIRC will automatically fix an
IP mismatch. Now wait, a common misconception is that you need to reconnect
to IRC - and it's wrong.... you don't. Why not? Well we're just simply
having mIRC correct your IP address that is used in the DCC send process.
If you are afraid of typing new commands (like some preach to never type
anything you don't understand fully), then you can use this method:
- Type: //echo
- Type: //dns $me
You may not be able to get a reply to the DNS
command, which means your address is numeric (and your names server is
down). Simply compare your numeric address Yournick!identd@numericaddress
with the //echo 2 $ip data. If the two numbers don't match press ALT E,
goto the local info tab, put the resolved address in IP address block click
on connect always get local host.
- Try to DCC Send a file to someone
Lastly, you need to make sure the person you're
sending to has their mIRC setup... have them type /sreq and it should reply
something along the lines of:
*** DCC Send requests pop
up a dialog
*** DCC Send requests are
You do not want them to have:
*** DCC Send requests are
If they have the ignore return, have them type
Then re-initiate the DCC send. On another note: It sounds stupid but a
full hard disk very effectively blocks DCC getting files!
If none of this works for you, proceed to sections
that might apply to the type of connection/software you are using. And
remember, you should always have:
'On connect, Always get' Local Host and IP Address
options in the Local_Info dialog checked
Set Lookup method to Normal.
If none of the other sections help you, you may
try changing the lookup method to server. Make sure that your time-out
values in DCC/Options are set large enough. "Get/Chat Dialog time out after"
and "Send/Get Transfer time out after" are recommended to be set to at
least 60 and 120, respectively.
With the Normal method, mIRC relies on your winsock
to reply with the correct information. With the Server method, mIRC looks
up your local host through the IRC Server, and then performs a /dns on
it to resolve it to an IP address. The Server method will most likely be
slower, you can tell when it has been completed when you see your local
host name and IP address displayed in the status window. Note: If changing
the above switches still doesn't solve the problem, or you don't know what
to enter for your local host or IP address, contact your internet provider
or system administrator.
|9. TIA/Twinsock/Slipknot Back to Top|
If you use TIA (The Internet Adapter) or Twinsock,
at this point you cannot use DCC send or initiate DCC chat (with any IRC
client, not just mIRC). You may want to try SLiRP or vTCP. SLIRP was the
first SLIP emulator to allow DCC sending and initiating DCC chat. (As you
know DCC get should always work fine, whatever connection you have. Besides
firewall blocking you that is.) Virtual TCP is tested and proofed to allow
DCC sending and chatting.
More info http://blitzen.canberra.edu.au/slirp
|10. SLiRP Back to Top|
set Tools/Options/Connect/Local_Info/ 'always get local host' on connect to Active,
IP Address should be the fake IP used for SLiRP (10.0.2.15 usually). Then
DCC Send, Chat, and everything else should work perfectly fine, even on
Windows95/98/2000 with the Dial-Up Networking.
|11. Dynamic IP Back to Top|
If you have dynamic IP (your IP address is different
each time you log on), make sure that "On connect, always get:" in the
Tools/Options/Connect/Local_Info dialog is set to get the Local Host and IP Address.
If these were already set to ON make sure the correct 'local host' name
and 'IP Address' are found by mIRC... on some winsocks this is rather tricky...
If you have a non-compliant stack, mIRC may not be able to correctly find
your local host (domain name) and IP. With dynamic IP addressing you are
in trouble then !! DCC file sending and initiating a DCC Chat (contrary
to file getting and accepting a DCC Chat) requires that mIRC knows your
correct IP number. Even without an IP number at all, mIRC will work as
far as normal chatting is concerned, but won't allow DCC file sending or
initiating a DCC Chat.
|12. Static IP Back to Top|
If you have a non-compliant stack, mIRC may not
be able to correctly find your local host (domain name) and IP. In the
Tools/Options/Connect/Local_Info dialog, uncheck the options to "Always get the 'Local
Host' and 'IP Address" and manually enter your correct Local Host and IP.
|13. Windows Bugs Back to Top|
A known Windows95/98/2000 bug causes some people
to report that mIRC (and any other IRC program) gets/finds the old (now
wrong) Local Host name and/or IP Address after switching Internet provider.
This blocks their capability of DCC Sending files and Initiating DCC Chats.
If, for some reason, no matter what you do, mIRC picks the user ID (Local
Host name) from the Internet Service Provider that you no longer wish to
use this is fixable by editing the registry. If you open Regedit and look
at MyComputer \HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services
\VxD \MSTCP you will see the Domain and NameServer fields from your old
provider. These fields will persist even if you uninstall Dial-Up Networking
and re-install and go through the TCP/IP settings again ! The best way
to solve the described problem is going to Start/Settings/Control_Panel/Network/
double click on TCPIP/ select DNS_Configuration/ and set the HOST field
to the hostname (ID) you have on your new provider.
|14. Norton Desktop Back to Top|
Some people experience DCC File Send problems
with mIRC on a windows system with Norton Desktop installed. mIRC then
suddenly shuts down completely (sometimes with an error message) as soon
as you try to select a file to send. The problem is that Norton Desktop's
feature called 'File Assist' conflicts with mIRC's DCC Send dialog. If
you shut off File Assist entirely it will allow DCC transfers fine. Even
just disabling the "3D look and feel" in the File Assist options menu helps
|15. Long Filenames Back to Top|
If you use Windows95/98/2000 mIRC allows you
to send long file names with spaces in them, but other IRC programs very
often cant handle this. This might cause your transfers to fail. You might
want to select mIRC's option to fill (up) spaces in such a long file name
by an underscore.
Another program known to give DCC Send problems
is a software package called Long File Names by View software. It is something
you might be running in the background and you might never think of it
as the cause of your troubles. The problem is that when you use the DCC
Send option in mIRC, the dialog that pops-up doesn't allow you to select
files so you can't send anything. Selecting files is blocked by LFN and
if you disable the LFN software all your DCC problems will be solved.
The DCC protocol doesn't take into account the
possibility of a filename containing spaces, so most if not all IRC clients
will incorrectly interpret the following DCC Send message:
PRIVMSG nick :DCC SEND This
is a long file name with.spaces in it ipaddress port file size
Thus mIRC gives you the Fill Spaces option; this
fills spaces in a filename with the underscore character _, which should
then allow other clients to interpret the message correctly. So other clients
PRIVMSG nick :DCC SEND This_is_a_long_file_name_with.spaces_in_it
ipaddress port filesize
If the Fill Spaces option isn't selected then
mIRC sends "Long File Names with.Spaces in them" enclosed in quotes. For
PRIVMSG nick :DCC SEND "This
is a long file name with.spaces in it" ipaddress port filesize
As far as I know, only mIRC can send and receive
messages of this form (and only versions 3.8 and onwards), so if you try
using this dcc send message with other clients it probably won't work.
|16. PROXY Back to Top|
As far as I understand it is totally impossible
to get DCC Sending working when you're behind a proxy. You may try the
DCC Server section.
|17. College/School/Work ISP Back to Top|
Many mIRC users IRC from different places, but
it's important for you to be aware that some network administators protect
their server by not allowing incoming connections. This can be done with
firewalls and such on the server side, and cannot be overridden by end
users. Most suffer from not being able to DCC send, the only other option
is to get the admin to allow incoming connections, or refer to the DCC
|18. Enhancing DCC Speeds Back to Top|
The packet size is the number of bytes that mIRC
will send to another client in one packet. The minimum is 512, the maximum
command: /dcc packetsize 8192
Note: Some sources indicate using 8192 as a packetsize
may fragment your file.
The fill spaces option is only available in the
32bit version and only under operating systems that allow spaces in filenames.
It is highly recommended that you leave this option turned on. For more
information read this.
command: check Fill spaces after typing
Turning on this option should speed up your DCC
command: /fsend on
Basically it just sends N bytes ahead of sent
data without waiting for the other client to reply "Acknowledged"
Since mIRC 5.7 you can only do /pdcc on | off, specifying
a number makes no difference now. Nearly every user will never be able
to send more than 25000 ahead, this is due to the limitations of current
system mediums and bandwidth.
command: /pdcc on
Note: 99999999999 is just ignored
The faster the modem, the quicker the send -
be aware that the send steps down to the speed of the slowest modem in
|19. DALnet Specifics Back to Top|
A new system that prevents the spread
of executable or dangerous scripts without the permission of the user receiving
them. The DCCALLOW system prevents transmission of "exe", "com", "bat",
"dll", "ini", "vbs", "pif", "mrc", "scr", "doc", "xls", "lnk", "shs", "js"
/DCCALLOW [<+|->nick[,<+|->nick, ...]] [list] [help]
You would see a message like this (if trying to
send a file of this type):
The user Somenickname is
not accepting DCC sends of filetype *.EXE from you. Your file filename.exe
was not sent.
And Somenickname would receive:
(address) has attempted to send you a file named filename.EXE, which was
-Servername- The majority
of files sent of this type are malicious virii and trojan horses. In order
to prevent the spread of this problem,
we are blocking DCC sends of these types of files by default.
If you completely trust this person, you would
type /dccallow +nickname
and you will see:
nickname has been added
to your DCC allow list
After you have finished your file transfer, it is wise to remove them
from the list, by typing /dccallow -nickname and you will see:
nickname has been removed
from your DCC allow list
You may list your allowed users by typing:
You will receive:
The following users are
on your dcc allow list:
End of DCCALLOW list
|20. DCC Server Back to Top|
This is how you can bypass the reverse method
of DCC. The receiving user must have DCC server on and listening for the
appropriate type of DCC you intend on sending.
/dccserver [+|-scf] [on|off] [port]
+scf on 59
The mIRC DCC Server listens for direct connections
to your IP address from other mIRC clients. In options (alt D, o) , you
can set the following:
Enable DCC Server
This turns the DCC Server on or off.
Listen on Port
The DCC Server listens on port 59 by default,
however you can change this to another port number.
You can have the DCC Server listen for only certain
types of connections, such as DCC Sends, Chats, or File server requests.
For example, if you turn off the DCC Chat listen option, the DCC Server
will ignore any chat requests.
Perform DNS lookup
When someone connects to your DCC Server only
their IP address is available for identification. If you check the DNS
lookup switch, mIRC will perform a /dns on the IP address to try to resolve
it to a named address. Note: It can take anything from a second to more
than minute to resolve an address depending on network conditions, and
sometimes it may not resolve at all. You can Send/Chat to the DCC Server
using the DCC Send/Chat dialogs and specifying an IP address instead of
To send, you use an IP address instead of a nickname
to initiate a connection
/dcc [send|chat|fserve] IPADDRESS:PORT
The IP address can be numeric or alphanumeric,
to obtain this data do a whois on the person you want to send the file
to. You will see the following (unless you are using a script that filters
this data differently):
nickname is user@host *
"a fancy saying"
nickname on #somechannel
nickname using someserver@somenetwork
"a fancy saying"
nickname End of /WHOIS
The first line is what we are concerned with.
See the user@host part? the host section (whatever is after @) is where
you are going to DCC to. You'll want to use whatever port they have setup
when they enabled their DCC server. To send a file to the user, type:
/dcc send host:port
send cablemodem911.network.com:59 (this
send 100.200.300.4:59 (this is numeric)
Note: Either host type is just as efficient as
the other. /dcc fserve
only works for IP address connections and does not work via IRC.
|21. XDCC/Fserve Back to Top|
As a lot of people on IRC promote and share the
best they found around on the net, mIRC now offers a unique built-in File server.
This File server feature is somewhat of a cross between DCC and FTP. You
open the server window to someone, (it's a special DCC chat window), restricting
them to a certain directory tree, and they can browse your file listings,
change directories, read text files, or get files.
The syntax to set up a DCC server connection to
/fserve <nick> <max
gets simultaneously allowed> <homedir> [welcome file]
"Max gets" is so that the other person doesn't
bring down your machine with too many parallel gets. 4 is probably a reasonable
number. The other person will have access to his homedir and all dirs DOWN
in the directory tree from that homedir on. "Welcome file" is a text file
you can write and specify that will welcome users to your file server.
/fserve Krejt 3 c:\temp\serve
/fserve Mookies 2 c:\outgoing
/fserve Friend 7 c:\
Keep in mind that you can't set up a server to
yourself... you need others to test your server...
Typing help in the file server will show the
available commands, which are styled after Unix and DOS. "ls" or "dir"
will show a directory listing, for example. Even switched commands like
"ls -k" (show file sizes in kilobytes) and "dir /w" (show a wide directory
listing) work. The server supports all normal ftp commands like cd <dir>
, cd.., dir, ls, get, .... but NOT put, hash, upload etc. There is no possibility
to delete files in a server connection. Safety risks are none or minimal
due to the major restricting of available commands.
Of course, the /fserve
command can be used in your Remote section....
Set up a simple Tools/Remote/command like :
ctcp 1:server:/fserve $nick 3 c:\temp\serve
Set the commands to active (/remote on) and off
Other people only have to type "/ctcp yournick
server" to activate the server. You can't set up a server to your own mIRC!!
So, others have to test your server !! In the directory c:\temp\serve,
you place all files other people are allowed to get from you. The people
using your server will have access to the c:\temp\serve directory AND ALL
directories BELOW it.. like c:\temp\serve\games.
|22. DCC Security Back to Top|
NEVER NEVER NEVER accept a DCC chat or file send
from someone you do not know or trust!!!
This is the cause of 95% of all
IRC security problems. In the mIRC DCC options section, set DCC Chat and
Send to "ASK". Never have the Auto Get option checked
In short; Trojan horse attacks are attractively
disguised files that you download and run, resulting in harmful and dangerous
consequences ranging from takeover of your IRC channels, erasing of your
hard disk, theft of your account passwords, etc. These (Trojan) viruses
are not mIRC or IRC specific, they just spread like fire on IRC.
Trojans are typically files with suffices like
"ini", "exe", or "com", such as "dmsetup.exe" or "script.ini". These days
nearly all trojans are spread in the guise of a free game, handy tool or
other software. You probably downloaded one from a WWW or FTP archive,
ICQ file exchange, or through IRC's DCC file transfer (by manual /dcc get
or, even worse, an "auto DCC get" feature which allows anybody to send
you anything, including not only trojans but also other viruses, child
Typically the Trojan needs to be run manually
at first (by you), and then installs hacked files all over your disk silently.
There are many different versions of those files, but almost all of them
interfere with your mIRC placing backdoors in scripts. The files then auto-send
themselves (using an 'ON JOIN' event) to everyone who joins the same channel
as an infected user without the users knowledge.
On DALnet is a channel specifically for helping
users with virii/trojan help. It's called #Nohack you can get there by
clicking here. If you're not
on DALnet and the above link doesn't help, in mIRC type /server irc.dal.net:7000
and once connected type join #nohack. Or you can goto www.nohack.net.
you will find detailed instructions and information on all kinds of problems
you may encounter on IRC. At this site the best help for problems like
this is concentrated and organized by people who are on IRC 24/7, in the
Help channels and alike. Read http://www.irchelp.org/irchelp/security/trojan.html
to learn all about the viruses on IRC, mostly called Worms or Trojans,
that might tackle you.
Prevention: NEVER download files from people or
sites which you aren't 100% sure about. Never use the "auto DCC get" feature,
and always scan your DCC gets with a decent virus scanner. Note that mIRC
by default does NOT accept files from strangers. This has never been otherwise
either. If you accepted files by the "auto DCC get" feature in mIRC, you
have switched this option ON yourself, really. Do not, never ever, accept
anything you have not requested. Do not accept anything from someone you
don't know, no matter how attractively packaged.