Netcat Users Guide by Fyodor
Netcat Users Guide by Fyodor
Netcat Users Guide by Fyodor
Fyodor
Ncat is a feature-packed networking utility which will read and write data across a network from the command line. Ncat was written for the Nmap Project as a much-improved reimplementation of the venerable Netcat. It uses both TCP and UDP for communication and is designed to be a reliable back-end tool to instantly provide network connectivity to other applications and users. Ncat will not only work with IPv4 and IPv6 but provides the user with a virtually limitless number of potential uses. Among Ncats vast number of features there is the ability to chain Ncats together, redirect both TCP and UDP ports to other sites, SSL support, and proxy connections via SOCKS4 or HTTP (CONNECT method) proxies (with optional proxy authentication as well). Some general principles apply to most applications and thus give you the capability of instantly adding networking support to software that would normally never support it. . .
\`-"'"-'/ } 6 6 { ==. Y ,== /^^^\ . / \ ) ( )-( )/ _ -""---""--/ / Ncat \_/ ( ____ \_.=|____E
Ncat is a general-purpose command-line tool for reading, writing, redirecting, and encrypting data across a network. It aims to be your network Swiss Army knife, handling a wide variety of security testing and administration tasks. Ncat is suitable for interactive use or as a network-connected back end for other tools. Ncat can: Act as a simple TCP/UDP/SSL client for interacting with web servers, telnet servers, mail servers, and other TCP/IP network services. Often the best way to understand a service (for fixing problems, finding security flaws, or testing custom commands) is to interact with it using Ncat. This lets you you control every character sent and view the raw, unfiltered responses. Act as a simple TCP/UDP/SSL server for offering services to clients, or simply to understand what existing clients are up to by capturing every byte they send. Redirect or proxy TCP/UDP traffic to other ports or hosts. This can be done using simple redirection (everything sent to a port is automatically relayed somewhere else you specify in advance) or by acting as a SOCKS or HTTP proxy so clients specify their own destinations. In client mode, Ncat can connect to destinations through a chain of anonymous or authenticated proxies. Run on all major operating systems. We distribute Linux, Windows, and Mac OS X binaries, and Ncat compiles on most other systems. A trusted tool must be available whenever you need it, no matter what computer you're using. Encrypt communication with SSL, and transport it over IPv4 or IPv6. Act as a network gateway for execution of system commands, with I/O redirected to the network. It was designed to work like the Unix utility cat, but for the network.
Page 1 of 17
These capabilities become even more powerful and versatile when combined. Ncat is our modern reinvention of the venerable Netcat (nc) tool released by Hobbit in 1996. While Ncat is similar to Netcat in spirit, they don't share any source code. Instead, Ncat makes use of Nmap's well optimized and tested networking libraries. Compatibility with the original Netcat and some well known variants is maintained where it doesn't conflict with Ncat's enhancements or cause usability problems. Ncat adds many capabilities not found in Hobbit's original nc, including SSL support, proxy connections, IPv6, and connection brokering. The original nc contained a simple port scanner, but we omitted that from Ncat because we have a preferred tool for that function. This guide starts with examples of basic Ncat usage, then moves on to more advanced features. Those are followed by practical sections which use examples to demonstrate how Ncat can solve common real-world problems. A few neat Ncat tricks are covered as well.
Basic Usage
Ncat always operates in one of two basic modes: connect mode and listen mode. In connect mode, Ncat initiates a connection (or sends UDP data) to a service that is listening somewhere. For those familiar with socket programming, connect mode is like using the connect function. In listen mode, Ncat waits for an incoming connection (or data receipt), like using the bind and listen functions. You can think of connect mode as client mode and listen mode as server mode. To use Ncat in connect mode, run
ncat <host> [<port>]
<host> may be a hostname or IP address, and <port> is a port number. Listen mode is the same, with the addition of the --listen option (or its -l alias):
ncat --listen [<host>] [<port>] ncat -l [<host>] [<port>]
In listen mode, <host> controls the address on which Ncat listens; if you omit it, Ncat will bind to all local interfaces (INADDR_ANY). If the port number is omitted, Ncat uses its default port 31337. Typically only privileged (root) users may bind to a port number lower than 1024. A listening TCP server will accept multiple concurrent connections up to the connection limit. The server receives everything sent by any of its clients, and anything the server sends is sent to all of them. A UDP server will communicate with only one client (the first one to send it data), because in UDP there is no list of connected clients. By default, Ncat uses TCP and IPv4. The option --udp or -u enables UDP instead, and -6 enables IPv6. The rest of this guide documents all the Ncat options through descriptions and examples. For a quick summary of options at any time, run ncat --help or man ncat.
Page 2 of 17
Here we have instructed Ncat to connect to the host scanme.nmap.org on port 80, the port for HTTP. The -C option turns on CRLF replacement, which replaces any line endings you type with CRLF. CRLF line endings are required by many protocols, including HTTP, though many servers will accept a plain newline (LF) character. GET / HTTP/1.0 requests the root document of the server; we are retrieving the same document named by the URL http://scanme.nmap.org:80/. The web server responds with a status code (HTTP/1.1 200 OK), followed by the HTTP header and the text of the web page. If you try this with other web servers, note that many of them are actually virtual hosts and you will need to send the Host header field. See RFC 2616 for more information about HTTP.
Now run the command ncat -l localhost 8080 < hello.http. This instructs Ncat to listen on the local port 8080 and read hello.http on its input. Ncat is now primed to send the contents of the file as soon as it receives a connection. Now open a web browser and type in the address http://localhost:8080/. Figure 1 shows a sample of what will appear.
Page 3 of 17
In the terminal where you ran Ncat, you will see everything the web browser sent to request the page. You should see a GET line like the one you sent in the connect mode example. This shows that Ncat by default both sends and receives. If you try to refresh the page, it won't work. That's because Ncat ran out of input; it won't re-send what has already been sent. For more information on making a server that continually responds to requests, see the examples in the section called Emulating Diagnostic Services.
Connection Brokering
One of Ncat's most useful and unique abilities is called connection brokering. A listening Ncat in broker mode accepts connections from multiple clients. Anything received from one of the clients is sent back out to all the others. In this way an Ncat broker acts like a network hub, broadcasting all traffic to everyone connected. Activate broker mode with the --broker option, which must be combined with --listen. It wouldn't make sense for a client to be a broker. See the section called File Transfer for details on using brokering to transfer files through restrictive firewalls, and the section called Chatting for using brokering to set up multi-user chat rooms.
SSL
Ncat can encrypt its traffic using SSL. In connect mode, simply add the --ssl option. Here is the syntax for connecting to an HTTPS server:
ncat -C --ssl <server> 443
Page 4 of 17
Verification is done using the ca-bundle.crt certificate bundle shipped with Ncat, plus whatever trusted certificates the operating system may provide. If you want to verify a connection to a server whose certificate isn't signed by one of the default certification authorities, use the --ssl-trustfile to name a file containing certificates you trust. The file must be in PEM format.
ncat -C --ssl-verify --ssl-trustfile <custom-certs.pem> <server> 443
Verification should be done whenever it is feasible. Even with encryption, an unverified connection is vulnerable to a man-in-the-middle attack. Ncat does not do certificate revocation checking. Ncat can act as an SSL server as well. The server must provide a certificate that clients can verify if they choose. If you start an SSL server without using the --ssl-cert and --ssl-key options, Ncat will automatically generate a certificate and 1,024-bit RSA key. The certificate will of course not be trusted by any application doing certificate verification. In verbose mode, the key's fingerprint will be printed so you can do manual verification if desired. Example 2 shows sample output. Example 2 Automatic certificate generation
$ ncat -v --listen --ssl Ncat ( http://nmap.org/ncat ) Generating a temporary 1024-bit RSA key. Use --ssl-key and --ssl-cert to use a permanent one. SHA-1 fingerprint: F0:13:BF:FB:2D:AA:76:88:22:60:3E:17:93:29:3E:0E:6B:92:C0:2F
Using an existing certificate and key is recommended whenever possible because it allows for robust server authentication. Use the --ssl-cert and --ssl-key options to pass in PEM-encoded files. For testing purposes you can generate a self-signed certificate and private key. If you have OpenSSL installed, use this command:
openssl req -new -x509 -keyout test-key.pem -out test-cert.pem.
For purposes of certificate verification, the commonName in the certificate should match the fully qualified domain name of the host that will run the server. After generating the files, start the server:
ncat --listen --ssl --ssl-cert test-cert.pem --ssl-key test-key.pem.
To make a verified client connection, copy the test-cert.pem file somewhere where the client can access it, then run
ncat --ssl-verify --ssl-trustfile test-cert.pem.
Command Execution
Revised July 16, 2009 Page 5 of 17
The --sh-exec (-c) works the same way as --exec, except that it executes the command by passing it to /bin/sh -c on Unix or cmd.exe /C on Windows. You don't have to use the full pathname of the command if the command is in the PATH. Additionally you have access to shell facilities such as pipelines and environment variable expansion. Example 4 shows a command run with --sh-exec. This server, when connected to, sends back the name of its working directory. Example 4 Running a command with --sh-exec
ncat -l --sh-exec "echo `pwd`"
The exec options can be used both in connect mode and in listen mode, but in listen mode they have an extra feature. For each connection received, Ncat forks off a new handler, leaving the original Ncat still running and waiting for connections. This is so even in UDP mode; the usual limit of only one client doesn't apply. In this way Ncat can work much like inetd. Many examples of the use of --exec and --sh-exec in listen mode are found in the section called Emulating Diagnostic Services. Any program that takes input and produces output can be executed by Ncat, but not all programs are suited for interaction. The reason is that many programs buffer their input and output, so if they receive some bytes, they many not process those bytes and write output until their input buffer is full, or the output may be deferred until the output buffer is full. If another program sends a few bytes and then waits for a response, it may hang indefinitely. Buffers are flushed when input or output ends, so even those programs that don't work interactively will work when run on an entire file at a time. Be careful when using the --exec and --sh-exec options. It can be dangerous to connect a new application to a network, especially one that wasn't written with potentially hostile input in mind. Any local vulnerabilities in an application may become remote vulnerabilities when you execute it through Ncat.
Output Options
Like any proper pipeline utility, Ncat reads from standard input and writes to standard output so you can redirect I/O to or from any program or file. The only exception is when Ncat is run with the --exec or --sh-exec options, in which case it communicates with the subprocess instead. Nothing in the streams is added, removed, or altered, unless you specifically ask for it with an option such as -C (CRLF processing) or --telnet (Telnet negotiation). If Ncat prints any diagnostic messages, they are sent to standard error so as not to interfere with the data stream. By default Ncat does not print any
Revised July 16, 2009 Page 6 of 17
The log contains everything sent and received without differentiation. Sometimes a hex dump is more useful than a plain text log; for that use --hex-dump or -x. Let's see what happens if we accidentally speak SMTP to an SSH server:
$ ncat -C --hex-dump ssh-hex.log scanme.nmap.org 22 SSH-2.0-OpenSSH_4.3 HELO example.com Protocol mismatch.
Each transmission is dumped separately. There is a break and the counter at the left starts over each time there is a new send.
Access Control
A listening Ncat may control which hosts connect to it with the --allow and --deny options. Each of these takes a comma-separated list of host specifications. The syntax is almost identical to that recognized by Nmap for targets (see the section called Target Specification). This includes IPv4 and IPv6 addresses, hostnames, IPv4 octet ranges, and CIDR netmasks. In Ncat (unlike Nmap), CIDR netmasks are supported for IPv6 addresses. With --allow, any hosts matching one of the listed specifiers are allowed and all others are denied. With --deny, those hosts matching the list are denied and all others are accepted. If a host matches both the --allow and --deny lists, it is denied. Use --allowfile and --denyfile to allow or deny a list of host/network specifiers stored in a file. Each line of the file contains a specification in one of the forms listed above. Any file acceptable to Nmap's -iL and --excludefile options is suitable for --allowfile and --denyfile. The following example commands demonstrate various kinds of access control. Allow one host, deny all others
ncat -l --allow 192.168.0.125 ncat -l --allow 2001:db8::7d ncat -l --allow trusted.example.com
Be aware that host-based access control is susceptible to spoofing attacks and various other possible failures. These mechanisms should not be relied on for complete security. Another kind of access control is simply limiting the maximum number of connections a listening Ncat will accept. Use the --max-conns option or its -m alias to do that. The default maximum number of connections is 100.
ncat -l --max-conns 5
Proxying
Ncat can route its connections through a SOCKS 4 or HTTP proxy. A basic connection looks like
ncat --proxy <proxyhost>[:<proxyport>] --proxy-type { http | socks4 } <host> [<port>]
--proxy-type may be omitted; it defaults to http. If <proxyport> is omitted, it defaults to the well-known port for the chosen proxy type: 1080 for SOCKS and 3128 for HTTP. An exception to this rule is when the proxy host is given by a IPv6 address; in this case the port is required because otherwise it would be ambiguous whether the digits after the last colon are the port number or part of the address. If the proxy server requires authentication, use the --proxy-auth option. Use --proxy-auth <username>:<password> for HTTP proxies and --proxy-auth <username> for SOCKS proxies. Ncat can act as a proxy server itself in listen mode. The only proxy type supported is http.
ncat -l 3128 --proxy-type http ncat -l 3128 --proxy-type http --proxy-auth <user>:<pass>
In listen mode the proxy port number is not automatically set and will be the default of 31337 unless specified. The proxy supports the GET, HEAD, and POST methods used in web browsing, as well as the CONNECT method that allows tunneling arbitrary TCP connections. (When Ncat connects as a client, it uses CONNECT.) Use --proxy-auth to make the server require authentication with a specific username and password. Be aware that the server uses the insecure Basic authentication mode and the credentials will be vulnerable to being intercepted. The proxy server uses the fork system call, so it is not supported on Windows.
Page 8 of 17
Other Options
This section contains descriptions of all options that haven't been discussed so far. The --nodns option (and its short form -n) instructs Ncat never to resolve names into addresses. All hosts must appear as IPv4 or IPv6 addresses. Ncat can be used as a Telnet client or server with the --telnet option (-t). This simply causes Ncat to respond negatively to any questions asked by the other host in the binary Telnet protocol, removing such negotiations from the stream seen by the user. The primary use of this option is to allow running canned Telnet scripts. The --send-only and --recv-only options do what their names imply, turning Ncat into a one-way communications channel instead of its default two-way channel. A usage example is gathering data from a server without the possibility of accidentally sending something typed at the keyboard. --sendonly in both connect and listen modes causes Ncat to quit when its input runs out. Normally it will not quit until the network connection is closed because the remote side may still send something, but in the case of --send-only there's no reason to receive anything more.
Source Options
In connect mode, you may set the source address and port used for the connection with the --source (-s) and --source-port (-p). The -s option only works for locally configured addresses; it doesn't work like Nmap's -S option. The value of -p is that sometimes firewalls will allow traffic that comes from certain source ports (such as 20 or 53). The -g option allows hops selection for IPv4 loose source routing. List the hops in order by giving -g multiple times or by separating the hops with commas. By default the source routing pointer is 4 in the packets sent, indicating the first hop in the list. You may set the pointer to another value with the -G option. The pointer value must be a multiple of 4 between 4 and 28, but some operating systems only support 4.
Timing
Ncat offers various options to control timing. Each of them take an argument that is assumed to be in milliseconds, unless followed by s for seconds, m for minutes, or h for hours. 30s means 30 seconds. This format should already be familiar to Nmap users. The --delay option and its short form -d make Ncat wait the given amount of time between each discrete read or write operation. For example, --delay 500 enforces a delay of half a second. The --idle-timeout option and it synonym -i allow setting a timeout for reads and writes in connect mode. If the client fails to read or write for the given time period, the connection is dropped. These options do not work in listen mode. The --wait (or -w for short) option sets how long Ncat will wait for a connection to be established in connect mode. The default is 10 seconds.
Revised July 16, 2009 Page 9 of 17
Note the order of the commands. The listener must be started first, regardless of the direction of transfer, or else the client will not have anything to connect to. The above technique works fine for sending a single file. One way to send multiple files is to bundle them up with tar or zip and send the archive file. But there's an even easier way. Just pipe the output of tar directly into Ncat on the sending side, and pipe Ncat's output into tar on the receiving side. This is especially useful when the sending computer doesn't have enough free disk space to hold the archive file. Here's how to transfer <files> using the receiver listens method, though of course the sender listens method works just as well. Transfer a bundle of files
host2$ ncat -l | tar xzv host1$ tar czv <files> | ncat --send-only host2 Revised July 16, 2009 Page 10 of 17
Disk images are typically large files that take a long time to transfer. You can compress the image on the fly while sending and decompress it on the other end. Whether this makes an improvement depends on the speed of the network and the compression program. Transfer a disk image with compression
host2$ ncat -l | bzip2 -d > host1-hda.image host1$ cat /dev/hda | bzip2 | ncat --send-only host2
The basic file transmission technique described at the beginning of this section fails if neither participating host is capable of listening, or the two hosts can't communicate directly. This situation has become common with the prevalence of network address translation. A way to work around it is to use a third host as an intermediary. The intermediate host listens in connection brokering mode and the other two hosts connect to it. Recall from the section called Connection Brokering that in connection brokering mode any input received on one socket is copied and sent out to all other sockets. With just two hosts connected this is especially simple: anything coming from one host gets forwarded to the other. This example shows host1 sending inputfile to outputfile on host2, using host3 as an intermediary. Transfer a file through an intermediary
host3$ ncat -l --broker host2$ ncat host3 > outputfile host1$ ncat --send-only host3 < inputfile
Note that it's important for host2 (the receiving host) to connect to the broker before host1 (the sending host) does. The broker does not buffer received data to send to hosts that connect later. After the file is transferred, it is necessary to forcible disconnect the Ncat on host2 with ctrl+C. The broker never disconnects any of its clients.
Chatting
In its most basic form, Ncat simply moves bits from one place to another. This is all that is needed to set up a simple chat system. By default, Ncat reads from standard input and writes to standard output, meaning that it will send whatever is typed at the keyboard and will show on the screen whatever is received. Two-user chat
host1$ ncat -l host2$ ncat host1
Page 11 of 17
Once the server is started, this is how the chat appears to one of the connected users. The lines that begin with <user<n>> are from other connected users. The line beginning with <user0> was sent by the listening broker.
client$ ncat server <user6> Is anyone there? I'm here. <user5> Me too. <user0> Go away, all of you.
The user IDs generated by Ncat are based on the file descriptor for each connection, and must be considered arbitrary. There is no way to choose a particular ID or make one persist across sessions. Nevertheless, --chat can come in handy for those quick multi-user conversations.
Neat Tricks
Send Mail It is great fun to interact with text-based network protocols with nothing more than Ncat and a keyboard. Here's a short example showing how to send email by talking to an SMTP server. SMTP is described in RFC 5321, but you don't need to know much about the protocol to send a simple message. The service's assigned port number is 25, and we use -C because it requires CRLF line endings. Example 5 contains a transcript of a session. Example 5 Ncat as mail client
$ ncat -C mail.example.com 25 220 mail.example.com ESMTP HELO client.example.com 250 mail.example.com Hello client.example.com MAIL FROM:a@example.com 250 OK Revised July 16, 2009 Page 12 of 17
To make this example work for you, change mail.example.com to your SMTP server and client.example.com to your domain name. Naturally you'll want to change the email addresses and message too. It will likely only work when using your normal mail server with your real email address, or when using the recipient's mail server (look up the MX record for the domain name in their email address). Obviously this technique can be used for more than just sending mail. Ncat is a great interactive debugging tool for any text-based protocol. Such debugging is sometimes done with the telnet command, because it provides something like a raw text stream. Ncat offers a few advantages over telnet, though. Ncat doesn't print anything except what is sent by the remote host. Telnet isn't suitable for arbitrary binary data because it reserves some bytes as control characters. The telnet command quits when its input runs out, so you may not see what the other end sends. And finally, telnet doesn't do UDP.
A possible problem with this technique is that it is one-way: host1 can send to host3 but there is no way for host3 to send anything back to host1. In this case it doesn't matter, but it can be done with a small change. Consider this:
host3$ ncat -l > log.txt host2$ ncat -l --sh-exec "ncat host3" host1$ ncat --send-only host2 < log.txt
The Ncat listening on host2, upon receiving a connection, creates a new Ncat to speak to host3 and connects the inputs and outputs of the programs running on host1 and host3 together. The same trick can be used on the local host too. This example forwards the local port 8080 to the web server on example.org:
ncat -l localhost 8080 --sh-exec "ncat example.org 80"
Unwrap SSL
Revised July 16, 2009 Page 13 of 17
Once this is in place, instruct the mail client to connect to the IMAP server on localhost. This trick works for protocols that pass traffic strictly between two hosts. It doesn't work well for HTTP because HTTP is usually aware of hostnames and often involves multiple hosts.
The ProxyCommand option of ssh tells how to open the SSH connection to <host>. It does this by opening another SSH session to <router> and connecting it to <host> with Ncat.
An except of the hex dump is shown in Example 6. Example 6 Hex dump of Nmap version detection
[0000] [0000] [0010] [0000] [0010] [0000] [0010] [0000] [0010] [0020] [0000] [0010] 0D 47 0D 4F 2E 4F 2E 80 00 00 00 65 0A 45 0A 50 30 50 30 00 01 00 1E 72 0D 0A 54 20 2F 20 48 54 54 0D 54 0D 00 86 00 00 73 49 0A 49 0A 28 A0 00 06 69 4F 0D 4F 0D 72 00 00 01 6F 4E 0A 4E 0A FE 01 00 00 6E 53 20 53 20 1D 97 00 00 04 13 7C 00 01 62 54 50 2F 31 2E 30 0D 0A 2F 20 48 54 54 50 2F 31 2F 20 52 54 53 50 2F 31 00 00 00 00 69 00 00 00 00 6E 00 00 00 00 64 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 07 76 00 10 00 03 .... GET / HT .. OPTIONS .0.... OPTIONS .0.... ...(r... .......| ........ ........ ersion.b TP/1.0.. / HTTP/1 / RTSP/1 ........ ........ .... .......v ind.....
Page 14 of 17
At the beginning, Nmap would have sent its NULL probe, which isn't shown in the log file because the NULL probe doesn't send anything. At the top of the log is the GenericLines probe (0D 0A 0D 0A, or \r\n\r\n). After that is our old friend the HTTP GET request. Then come all the other probes in the nmap-service-probes file. In this excerpt are shown probes designed to get a response from RPC, DNS, and SMTP.
With the TCP server we used --keep-open so the server could handle multiple simultaneous connections, not just one. For the UDP server we had to use --sh-exec to allow multiple conncurrent connections. Recall from the section called Basic usage that a UDP server can handle only one client but with --exec and --sh-exec this limitation does not apply. The echo service is defined in RFC 862. It runs on TCP or UDP port 7. One step more advanced than discard, it sends back any data received until the connection is closed. How do you instruct Ncat to return what it receives? One easy way is to run everything through /bin/cat. TCP echo server
ncat -l 7 --exec "/bin/cat"
The daytime service, defined in RFC 867, sends a human-readable date and time string over TCP or UDP port 13. It ignores any input. The format of the date and time string is left unspecified, so we are
Page 15 of 17
Nmap comes with a daytime.nse script that works with the daytime service. Here is its output running against Ncat daytime servers on TCP and UDP. Example 7 daytime.nse against an Ncat daytime server
# nmap -sSU -p 13 --script=daytime localhost Starting Nmap ( http://nmap.org ) Interesting ports on localhost (127.0.0.1): PORT STATE SERVICE 13/tcp open daytime |_ daytime: Mon Jan 19 17:43:18 MST 2009 13/udp open daytime |_ daytime: Mon Jan 19 17:43:18 MST 2009 Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
The qotd (quote of the day) service is defined in RFC 865. When a connection is made to TCP or UDP port 17, it sends back a short message, ignoring any input. Ncat can do this by invoking a program that generates messages. A traditional choice is /usr/games/fortune, though there are many possibilities. /usr/bin/uptime, for example, could be useful. TCP qotd server
ncat -l 17 --send-only --exec "/usr/games/fortune"
In this example it's instructive to consider the difference between ncat -l 17 --exec "/usr/games/fortune" and /usr/games/fortune | ncat -l 17. Think about why the second command stops working after the first connection. The chargen service from RFC 864 rounds out our tour of diagnostic services. It runs on TCP and UDP port 19. With TCP, chargen ignores any input and sends a never-ending stream of data. Neverending, that is, until the connection is closed by the user, who the RFC suggests may have had enough. There are many ways of generating the characters; reading from /dev/zero and running yes come to mind.
Page 16 of 17
Notice that in this case the program pipes its output into ncat rather than being invoked with --exec. For chargen either method would work, because the output of yes never changes. Using a pipe requires only one process other than ncat, but all users connected simultaneously will see the same output stream in synchrony. If the contents must be independent for each stream, then use the --exec method, with the understanding that a new process will be started for each connection. The UDP chargen protocol is a little different. When a datagram is received, it sends back one datagram containing a random number of characters. Implementing this is starting to get away from Ncat, but one way it could be done with the Bash shell is this: UDP chargen server
ncat -l 19 --udp --send-only --sh-exec \ "yes chargenchargenchargen | dd count=1 bs=$(($RANDOM % 512)) 2> /dev/null"
Notice the use of --sh-exec rather than --exec to allow the use of the shell's environment variables and arithmetic evaluation. Standard error is redirected to /dev/null to avoid including dd's summary lines (1+0 records out), which would otherwise be included by Ncat. This completes the tour of simple diagnostic services. These have been easy to implement with Ncat because (with the exception of UDP chargen) they all map directly onto a familiar command-line program. As services become more complex it gets harder to do everything in the shell. For complicated services it's better to write a separate program and have Ncat exec it directly.
Page 17 of 17