Character Generator Protocol

Not to be confused with character generator.

Internet protocol suite
Application layer
BGP DHCP DNS FTP HTTP IMAP IRC LDAP MGCP NNTP NTP POP RIP RPC RTP SIP SMTP SNMP SOCKS SSH Telnet TLS/SSL XMPP (more)
Transport layer
TCP UDP DCCP SCTP RSVP ECN (more)
Internet layer
IP (IPv4 • IPv6) ICMP ICMPv6 IGMP IPsec (more)
Link layer
ARP/InARP NDP OSPF Tunnels (L2TP) PPP Media access control (Ethernet • DSL • ISDN • FDDI) (more)
v · d · e

The Character Generator Protocol (CHARGEN) is a service of the Internet Protocol Suite defined in RFC 864 in 1983 by Jon Postel. It is intended for testing, debugging, and measurement purposes.

A host may connect to a server that supports the Character Generator Protocol on either Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port number 19. Upon opening a TCP connection, the server starts sending arbitrary characters to the connecting host and continues until the host closes the connection. In the UDP implementation of the protocol, the server sends a UDP datagram containing a random number (between 0 and 512) of characters every time it receives a datagram from the connecting host. Any data received by the server is discarded.

Inetd implementation

On most UNIX-like operating systems a CHARGEN server is built into the inetd (or xinetd) daemon. The CHARGEN service is usually not enabled by default. It may be enabled by adding the following lines to the file /etc/inetd.conf and telling inetd to reload its configuration:

chargen   stream  tcp     nowait  root    internal
chargen   dgram   udp     wait    root    internal

Applications

The CHARGEN service may be used as a source of a byte-stream for debugging TCP network code for proper bounds checking and buffer management. It may also be a source of generic payload for bandwidth measurement and/or QoS fine-tuning.^{[citation needed]} Although consideration must be given if hardware compression is active, as the output from the CHARGEN service is easily and efficiently compressed. This compression can cause bandwidth tests to report the size of the data after decompression, instead of the actual amount of data which passed the wire.

Sample session

A typical CHARGEN service session looks like this: The user connects to the host using a telnet client. The user receives a stream of bytes. Although the specific format of the output is not prescribed by RFC 864, the recommended pattern (and a de-facto standard) is shifted lines of 72 ASCII characters repeating.

$ telnet localhost chargen
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgh
"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi
#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij
$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk
%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkl
&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmn
()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno
)*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnop
*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopq
+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst
./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu
/0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv
^]
telnet> quit
Connection closed.

This continues until the TCP connection is closed as shown in the trace by ending the telnet session.

Abuse

The service was used maliciously to crash MS DNS servers running Microsoft Windows NT 4.0 by piping the arbitrary characters straight into the DNS server listening port (telnet ntbox 19 | telnet ntbox 53).^[1] However, the attack was presumably a symptom of improper buffer management on the part of Microsoft's DNS service and not directly related to the CHARGEN service.^{[citation needed]}

See also

• Barber pole
• List of well-known ports (computing)
• Echo Protocol
• Discard Protocol
• Daytime Protocol
• Time Protocol

References

1. ^ "Access Violation in Dns.exe Caused by Malicious Telnet Attack". Support.microsoft.com. 2006-11-01. http://support.microsoft.com/kb/169461. Retrieved 2009-05-31.