dcc.chat Starts a DCC chat connection |
||||||||||||||||||||
Usage |
||||||||||||||||||||
dcc.chat [-s] [-n] [-c] [-u] [-m[=<boolean>]] [-i=<interface>] [-p=<port>] [-a=<fake address>] [-f=<fake port>] <nickname> |
||||||||||||||||||||
Description |
||||||||||||||||||||
Attempts a DCC connection to <nickname>. The simplest case dcc.chat <nickname> will work just as in all the other IRC clients, but this command is really more powerful... Before attempting to understand the possibilities of this command, be sure to know how DCC negotiation and connections work. If the i switch is specified, the local listening socket will be bound to the specified <interface> (which is an IP address, IPv4 or IPv6), otherwise it will be bound to the interface of the current IRC connection. You can also specify a local interface name to get the address from (this works only for IPv4 interfaces since IPv6 ones seem to be unsupported by the system ioctl() calls at the moment (in Linux at least)). Here are some examples: -i=215.243.12.12: This will bind to the IPv4 interface with the specified address. -i=3ffe:1001::1: This will bind to the IPv6 interface with the specified address. -i=ppp0: This will bind to the IPv4 address of the interface ppp0 (if supported by the underlying system). The -i switch parameter may serve also as a target address when the -c switch is used. If the p switch is specified, the local listening socket will be bound to the <port>, otherwise it will be bound to a random port chosen by the kernel. If the a switch is specified, the requesting CTCP message will contain <fake address> as target for the remote user, otherwise the CTCP message will contain the real IP address of the listening interface. If the f switch is specified, the requesting CTCP message will contain <fake port> as target for the remote user, otherwise the CTCP message will contain the real port of the listening socket. All these switches are meant to allow maximum flexibility of the DCC negotiation, earlier KVIrc releases had serious problems with firewalled and/or masqueraded machines. With the -a and -f switches you can workaround it. If the n switch is specified, KVIrc will not send the CTCP request to the target user; you will have to do it manually, or the remote user will have to connect manually (for example by using dcc.chat -c). If the c switch is specified, KVIrc will attempt to connect to the remote host specified as <interface> and <port>, instead of listening (active connection instead of a passive one). In this case the -i and -p switches are mandatory. The c switch takes precedence over n (In fact both should be mutually exclusive). If the c and n switches are missing, this commands needs to be executed in a window that is bound to a connected IRC context (you need a third entity to accomplish the negotiation). If the u switch is given, the connection attempt will never time out; this might be useful if you want to leave a listening socket for a friend of yours while you are sleeping and have the CTCP processing disabled. The u switch works either in active and passive mode. If the -m switch is passed, the default boolCreateMinimizedDccChat option is overridden with the <boolean> parameter passed. So actually by passing -m=1 will create a minimized DCC chat even if the $option(boolCreateMinimizedDccChat) returns false. In the same way, by passing -m=0 you will create a non minimized DCC chat. If no <boolean> value is specified, it defaults to 1. -s will cause the DCC chat to be attempted in Secure Sockets Layer mode: the connection will be encrypted with a private key algorithm after a public key handshake. -s will work only if the KVIrc executable was compiled with SSL support enabled and if the remote end supports it. The eventual DCC request will contain the string SCHAT instead of CHAT. When requesting a SSL based DCC chat to someone you probably will need a certificate. If you don't have one, create it (for example with CA.pl -newcert) and set it in the options dialog. |
||||||||||||||||||||
Switches |
||||||||||||||||||||
|
||||||||||||||||||||
Examples |
||||||||||||||||||||
Simple examples: | ||||||||||||||||||||
# Simple DCC chat to Pragma dcc.chat Pragma # DCC chat to Pragma, listen on address 127.0.0.1 dcc.chat -i=127.0.0.1 Pragma # DCC chat to Pragma, listen on address 168.0.0.1 and port 1025 dcc.chat -i=168.0.0.1 -p=1025 Pragma | ||||||||||||||||||||
More tricky ones: | ||||||||||||||||||||
# DCC chat to Pragma, listen on address 127.0.0.1 and port 1080 # but tell him to connect to address 212.134.22.11 port 1080 dcc.chat -i=127.0.0.1 -p=1080 -a=212.134.22.11 Pragma # DCC chat to Pragma, listen on address 127.0.0.1 and port 1080 # but tell him to connect to address 212.134.22.11 port 1090 dcc.chat -i=127.0.0.1 -p=1080 -a=212.134.22.11 -f=1090 Pragma | ||||||||||||||||||||
Now run completely out of bounds. Use dcc.chat connections to do various things: | ||||||||||||||||||||
# Tricky: simulate a HTTP server dcc.chat -n -i=127.0.0.1 -p=80 WebBrowser # Now open http://127.0.0.1 with your web browser # and type "<html><body>Hello!</body></html>" :) # # Tricky 2: simulate the Ident daemon (if you have none) dcc.chat -n -i=127.0.0.1 -p=113 Client # # Now a self-DCC connection without the IRC negotiation # Src: Setup a listening socket awaiting the "Destination" user connection dcc.chat -n -i=127.0.0.1 -p=1080 Dst # Dst: Connect to the listening socket at addr 127.0.0.1 and port 1080 dcc.chat -c -i=127.0.0.1 -p=1080 Src # The above example will mess you a bit... # Try to guess why in both windows YOU have the same nickname # that is probably not Dst nor Src... :) | ||||||||||||||||||||
Using the shell FTP program is too easy: we're real hackers and want to do complicated things... | ||||||||||||||||||||
# Connect to the local FTP server and get the list of contents /dcc.chat -c -i=127.0.0.1 -p=21 FtpServer # Now login, type in the new window (the following lines are not commands): USER youruser PASS yourpass # Now enter passive mode PASV # And watch the line that you have received...sth like # 227 Entering passive mode (127,0,0,1,210,195) /dcc.chat -c -i=127.0.0.1 -p=$((210 * 256) + 195) FtpList # (Change the port numbers accordingly) # And then type in the FTP server window (this is not a KVIrc command): LIST # Then watch the ls output in the FtpList window. :) # In this way you can also read ASCII files by FTP: # Assume that in the previous ls output you have seen # a README file. # In the FTP server window type: PASV # Watch the message # 227 Entering passive mode (127,0,0,1,22,227) /dcc.chat -c -i=127.0.0.1 -p=$((22 * 256) + 227) README # In the FtpServer window type: RETR README # And read the file in the README window :) | ||||||||||||||||||||