TCP / IP Suite


Remote LOGIN (RLOGIN) allows UNIX users of one machine to connect to other UNIX systems across an Internet and interact as if their terminals are directly connected to the machines. This protocol offers essentially the same services as TELNET.

Interested in more details about testing this protocol? click here


The Real-Time Streaming Protocol (RTSP) is an application level protocols for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms bases upon RTP.

The streams controlled by RTSP may use RTP, but the operation of RTSP does not depend on the transport mechanism used to carry continuous media. The protocol is intentionally similar in syntax and operation to HTTP/1.1 so that extension mechanisms to HTTP can in most cases also be added to RTSP. However, RTSP differs in a number of important aspects from HTTP:

  • RTSP introduces a number of new methods and has a different protocol identifier.
  • An RTSP server needs to maintain state by default in almost all cases, as opposed to the stateless nature of HTTP.
  • Both an RTSP server and client can issue requests.
  • Data is carried out-of-band by a different protocol. (There is an exception to this.)
  • RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, consistent with current HTML internationalization efforts.
  • The Request-URI always contains the absolute URI. Because of backward compatibility with a historical blunder, HTTP/1.1 carries only the absolute path in the request and puts the host name in a separate header field.

This makes virtual hosting easier, where a single host with one IP address hosts several document trees.

Interested in more details about testing this protocol? click here


The Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signalling messages over IP networks, but is capable of broader applications. SCTP is an application-level datagram transfer protocol operating on top of an unreliable datagram service such as UDP. It offers the following services:

  • Acknowledged error-free non-duplicated transfer of user data.
  • Application-level segmentation to conform to discovered MTU size.
  • Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival delivery of individual datagrams.
  • Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions.
  • Enhanced reliability through support of multi-homing at either or both ends of the association.

The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and masquerade attacks. The SCTP datagram is comprised of a common header and chunks. The chunks contain either control information or user data.

The following is the format of the SCTP header.

2 bytes 2 bytes
Source Port Number Destination Port Number
Verification Tag
Adler 32 Checksum

Source Port Number This is the SCTP sender’s port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs.

Destination Port Number This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.

Verification Tag The receiver of this 32 bit datagram uses the Verification tag to identify the association. On transmit, the value of this Verification tag must be set to the value of the Initiate tag received from the peer endpoint during the association initialization.

For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0’s. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0’s.

Adler 32 Checksum This field contains an Adler-32 checksum on this SCTP datagram.

Chunk Field Descriptions The following is the field format for the chunks transmitted in the SCTP datagram. Each chunk has a chunk ID field, a chunk specific Flag field, a Length field and a Value field.
1 byte 1 byte 2 bytes
Chunk ID Chunk Flags Chunk Length
Chunk Value (variable)

Chunk ID The type of information contained in the chunk value field. The values of the chunk ID are defined as follows:

ID ValueChunk Type
00000000 Payload Data (DATA)
00000001 Initiation (INIT)
00000010 Initiation Acknowledgment (INIT ACK)
00000011 Selective Acknowledgment (SACK)
00000100 Heartbeat Request (HEARTBEAT)
00000101 Heartbeat Acknowledgment (HEARTBEAT ACK)
00000110 Abort (ABORT)
00000111 Shutdown (SHUTDOWN)
00001000 Shutdown Acknowledgment (SHUTDOWN ACK)
00001001 Operation Error (ERROR)
00001010 State Cookie (COOKIE)
00001011 Cookie Acknowledgment (COOKIE ACK)
00001100 Reserved for Explicit Congestion Notification Echo (ECNE)
00001101 Reserved for Congestion Window Reduced (CWR)
00001110 to11111101 reserved by IETF
11111110 Vendor-specific Chunk Extensions
11111111 IETF-defined Chunk Extensions

Chunk Flags The type of chunk flag as defined in the chunk ID defines whether these bits will be used. Their value is generally 0 unless otherwise specified.

Chunk Length The size of the chunk in octets including the Chunk ID, Flags, Length and Value fields.

Chunk Value This field contains the actual information to be transferred in the chunk. This is dependent on the chunk ID.

Chunk Types

Initiation (INIT) This chunk is used to initiate a SCTP association between two endpoints. The INIT chunk contains the following parameters. Unless otherwise noted, each parameter is only be included once in the INIT chunk.
Fixed Parameters Status
Initiate Tag Mandatory
Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory
Variable Parameters Status
IPv4 Address/Port Optional
IPv6 Address/Port Optional
Cookie Preservative Optional
Reserved For ECN Capable Optional
Host Name Address Optional
Supported Address Types Optional
Initiate Acknowledgement (INIT ACK) The INIT ACK chunk is used to acknowledge the initiation of a SCTP association. The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The Responder Cookie and the Unrecognized Parameter.

Selective Acknowledgement (SACK) This chunk is sent to the remote endpoint to acknowledge received Data chunks and to inform the remote endpoint of gaps in the received subsequences of Data chunks as represented by their TSNs.

The selective acknowledgement chunk contains the highest consecutive TSN ACK and Rcv Window Credit (rwnd) parameters. By definition, the value of the highest consecutive TSN ACK parameter is the last TSN received at the time the Selective ACK is sent, before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the reporting end. This parameter therefore acknowledges receipt of all TSNs up to and including the value given.

The Selective ACK also contains zero or more fragment reports. Each fragment report acknowledges a sub-sequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by fragment reports are higher than the value of the Highest Consecutive TSN ACK.

Heartbeat Request (HEARTBEAT) An endpoint should send this chunk to its peer endpoint of the current association to probe the reachability of a particular destination transport address defined in the present association. The parameter fields contain the time values.

Heartbeat Acknowledgement (HEARTBEAT ACK) An endpoint should send this chunk to its peer endpoint as a response to a Heartbeat Request. The parameter field contains the time values.

Abort Association (ABORT) The Abort Association chunk is sent to the peer of an association to terminate the association. The Abort chunk may contain cause parameters to inform the receiver the reason for the abort. Data chunks are not bundled with the abort, control chunks may be bundled with an abort, but must be placed before the abort in the SCTP datagram or they will be ignored.

SHUTDOWN An endpoint in an association uses this chunk to initiate a graceful termination of the association with its peer.

Shutdown Acknowledgement (SHUTDOWN ACK) This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. The SHUTDOWN ACK chunk has no parameters.

Operation Error (ERROR) This chunk is sent to the other endpoint in the association to notify certain error conditions. It contains one or more error causes.

State Cookie (COOKIE) This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same datagram.

Cookie Acknowledgement (COOKIE ACK) This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE chunk. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same SCTP datagram.

Payload Data (DATA) This contains the user data.

Vendor Specific Chunk Extensions This chunk type is available to allow vendors to support their own extended data formats not defined by the IETF. It must not affect the operation of SCTP. Endpoints not equipped to interpret the vendor-specific chunk sent by a remote endpoint must ignore it. Endpoints that do not receive desired vendor specific information should make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

Interested in more details about testing this protocol? click here


RFC 2165 The Service Location Protocol (SLP) provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration for network services for network-based applications. This is especially important as computers become more portable and users less tolerant or able to fulfill the demands of network system administration. Traditionally, users find services by using the name of a network host (a human readable text string), which is an alias for a network address. The Service Location Protocol eliminates the need for a user to know the name of a network host supporting a service. Rather, the user names the service and supplies a set of attributes, which describe the service. The Service Location Protocol allows the user to bind this description to the network address of the service. Service Location provides a dynamic configuration mechanism for applications in local area networks. It is not a global resolution system for the entire Internet; rather it is intended to serve enterprise networks with shared services. Applications are modeled as clients that need to find servers attached to the enterprise network at a possibly distant location. For cases where there are many different clients and/or services available, the protocol is adapted to make use of nearby Directory Agents that offer a centralized repository for advertised services. The basic operation in Service Location is that a client attempts to discover the location for a service. In small installations, each service is configured to respond individually to each client. In larger installations, service will register their services with one or more directory agents and clients contact the directory agent to fulfill request for service location information. This is intended to be similar to URL specifications and make user of URL technology. The header is used in all the SLP messages
2 bytes
2 bytes
O M U A F rsvd
Language Code
Char encoding
SLP header structure
Version The current version is version 1
Function The function field describes the operation of the Service location datagram. The following message types exist:
Function Message Type
1 Service Request
2 Service Reply
3 Service Registration
4 Service Deregister
5 Service Acknowledge
6 Attribute Request
7 Attribute Reply
8 DA Advertisement
9 Service Type Request
10 Service Type Reply
Length Number of bytes in the message including the Service location header. O The overflow bit. M The monolingual bit. U URL Authentication bit present. A Attribute authentication bit present. F The F bit is set. If the F bit is set in a Service Acknowledgement, the directory agent has registered the service as a new entry. Rsvd These bits are reserved and must have a value of 0. Dialect To be use by future versions of the SLP. Must be set to zero. Language Code The language encoded in this field indicates the language in which the remainder of the message should be interpreted. Character Encoding The characters making up strings within the remainder of this message may be encoded in any standardized encoding Transaction Identifier (XID) Allows matching replies to individual requests. Interested in more details about testing this protocol? click here  


SMPP Developer’s Forum, SMPP Protocol Specification v3.4, 10/12/1999

The Short Message Peer to Peer (SMPP) protocol is designed to provide a flexible data communications interface for transfer of short message data between a Message Center such as a Short Message Service Center (SMSC), GSM Unstructured Supplementary Services Data (USSD) Server or other type of Message Center, and an SMS application system such as a WAP Proxy Server, Email Gateway or other Messaging Gateway. The SMPP PDU format is as follows:
PDU Header (mandatory) PDU Body (Optional)
command length command id command status sequence number PDU Body
4 octets Length=(Command Length valueb – 4) octects
SMPP PDU format

Command length Defines the total octet length of the SMPP PDU packet, including the length field. The Command Length field is 4 octets long.

Command ID Identifies the particular SMPP PDU, e.g., submit_sm, query_sm, etc. The Command ID field is 4 octets long. The following is a list of possible Command ID values:


0x00000001 bind_receiver
0x80000001 bind_receiver_resp
0x00000002 bind_transmitter
0x80000002 bind_transmitter_resp
0x00000003 query_sm
0x80000003 query_sm_resp
0x00000004 submit_sm
0x80000004 submit_sm_resp
0x00000005 deliver_sm
0x80000005 deliver_sm_resp
0x00000006 unbind
0x80000006 unbind_resp
0x00000007 replace_sm
0x80000007 replace_sm_resp
0x00000008 cancel_sm
0x80000008 cancel_sm_resp
0x00000009 bind_transceiver
0x80000009 bind_transceiver_resp
0x0000000B outbind
0x00000015 enquire_link
0x80000015 enquire_link_resp
0x00000021 submit_multi
0x80000021 submit_multi_resp
0x00000102 alert_notification
0x00000103 data_sm
0x80000103 data_sm_resp

Command status Indicates the success or failure of an SMPP request. It is relevant only in the SMPP response PDU and it must contain a NULL value in an SMPP request PDU. The Command Status field is 4 octets long.

Sequence number Contains a sequence number which allows SMPP requests and responses to be associated for correlation purposes. The use of sequence numbers for message correlation allows SMPP PDUs to be exchanged asynchronously. The Sequence Number field is 4 octets long.

Mandatory Parameters Following the header is a set of mandatory parameters, corresponding to the SMPP PDU defined in the Command ID field.

Optional Parameters Optional parameters corresponding to the SMPP PDU defined in the Command ID field, and included as required. Each optional parameter has the following structure:

Tag A field (2 octets long) that uniquely identifies the particular optional parameter in question. The following is a list of possible Tag values:

0x0005 dest_addr_subunit
0x0006 dest_network_type
0x0007 dest_bearer_type
0x0008 dest_telematics_id
0x000D source_addr_subunit
0x000E source_network_type
0x000F source_bearer_type
0x0010 source_telematics_id
0x0017 qos_time_to_live
0x0019 payload_type
0x001D additional_status_info_text
0x001E receipted_message_id
0x0030 ms_msg_wait_facilities
0x0201 privacy_indicator
0x0202 source_subaddress
0x0203 dest_subaddress
0x0204 user_message_reference
0x0205 user_response_code
0x020A source_port
0x020B destination_port
0x020C sar_msg_ref_num
0x020D language_indicator
0x020E sar_total_segments
0x020F sar_segment_seqnum
0x0210 SC_interface_version
0x0302 callback_num_pres_ind
0x0303 callback_num_atag
0x0304 number_of_messages
0x0381 callback_num
0x0420 dpf_result
0x0421 set_dpf
0x0422 ms_availability_status
0x0423 network_error_code
0x0424 message_payload
0x0425 delivery_failure_reason
0x0426 more_messages_to_send
0x0427 message_state
0x0501 ussd_service_op
0x1201 display_time
0x1203 sms_signal
0x1204 ms_validity
0x130C alert_on_message_delivery
0x1380 its_reply_type
0x1383 its_session_info

Length Indicates the length (in octets) of the Value field. The Length field is 2 octets long.

Value The actual data of the optional parameter.

Interested in more details about testing this protocol? click here



IETF RFC821 defines the Simple Mail Transfer Protocol (SMTP) which is a mail service modeled on the FTP file transfer service. SMTP transfers mail messages between systems and provides notification regarding incoming mail.

Commands SMTP commands are ASCII messages sent between SMTP hosts. Possible commands are as follows:
Command Description
DATA Begins message composition.
EXPN <string> Returns names on the specified mail list.
HELO <domain> Returns identity of mail server.
HELP <command> Returns information on the specified command.
MAIL FROM <host> Initiates a mail session from host.
NOOP Causes no action, except acknowledgement from server.
QUIT Terminates the mail session.
RCPT TO <user> Designates who receives mail.
RSET Resets mail connection.
SAML FROM <host> Sends mail to user terminal and mailbox.
SEND FROM <host> Sends mail to user terminal.
SOML FROM <host> Sends mail to user terminal or mailbox.
TURN Switches role of receiver and sender.
VRFY <user> Verifies the identity of a user.
Messages SMTP response messages consist of a response code followed by explanatory text, as follows:
Response Code Explanatory Text
211 (Response to system status or help request).
214 (Response to help request).
220 Mail service ready.
221 Mail service closing connection.
250 Mail transfer completed.
251 User not local, forward to <path>.
354 Start mail message, end with <CRLF><CRLF>.
421 Mail service unavailable.
450 Mailbox unavailable.
451 Local error in processing command.
452 Insufficient system storage.
500 Unknown command.
501 Bad parameter.
502 Command not implemented.
503 Bad command sequence.
504 Parameter not implemented.
550 Mailbox not found.
551 User not local, try <path>.
552 Storage allocation exceeded.
553 Mailbox name not allowed.
554 Mail transaction failed.
Interested in more details about testing this protocol? click here   SNMP

RFC1157 SNMP Protocol Overview:

IETF RFCs 1155, 1156, and 1157 define the Simple Network Management Protocol (SNMP). The Internet community developed SNMP to allow diverse network objects to participate in a global network management architecture. Network managing systems can poll network entities implementing SNMP for information relevant to a particular network management implementation. Network management systems learn of problems by receiving traps or change notices from network devices implementing SNMP.

SNMP Message Format

SNMP is a session protocol which is encapsulated in UDP. The SNMP message format is shown below:
Version Community PDU
SNMP message format
Version SNMP version number. Both the manager and agent must use the same version of SNMP. Messages containing different version numbers are discarded without further processing. Community Community name used for authenticating the manager before allowing access to the agent. PDU There are five different PDU types: GetRequest, GetNextRequest, GetResponse, SetRequest, and Trap. A general description of each of these is given in the next section. PDU Format The format for GetRequest, GetNext Request, GetResponse and SetRequest PDUs is shown here.
PDU type Request ID Error status Error index Object 1, value 1 Object 2, value 2
SNMP PDU format
PDU type Specifies the type of PDU:
0 GetRequest.
1 GetNextRequest.
2 GetResponse.
3 SetRequest.
Request ID Integer field which correlates the manager’s request to the agent’s response. Error status Enumerated integer type that indicates normal operation or one of five error conditions. The possible values are:
0 noError: Proper manager/agent operation.
1 tooBig: Size of the required GetResponse PDU exceeds a local limitation
2 noSuchName: The requested object name does not match the names available in the relevant MIB View.
3 badValue: A SetRequest contains an inconsistent type, length and value for the variable.
4 readOnly: Not defined in RFC1157.
5 genErr: Other errors, which are not explicitly defined, have occurred.
Error index Identifies the entry within the variable bindings list that caused the error.

Object/value Variable binding pair of a variable name with its value.

Trap PDU Format

The format of the Trap PDU is shown below:
PDU type
Obj 1,
Val 1  
Obj 1,
Val 1  

PDU type Specifies the type of PDU (4=Trap).

Enterprise Identifies the management enterprise under whose registration authority the trap was defined.

Agent address IP address of the agent, used for further identification.

Generic trap type Field describing the event being reported. The following seven values are defined:

0 coldStart: Sending protocol entity has reinitialized, indicating that the agent’s configuration or entity implementation may be altered.
1 warmStart: Sending protocol has reinitialized, but neither the agent’s configuration nor the protocol entity implementation has been altered.
2 linkDown: A communication link has failed.
3 linkUp: A communication link has come up.
4 authenticationFailure: The agent has received an improperly authenticated SNMP message from the manager, i.e., community name was incorrect.
5 egpNeighborLoss: An EGP peer neighbor is down.
6 enterpriseSpecific: A non-generic trap has occurred which is further identified by the Specific Trap Type and Enterprise fields.

Specific trap type Used to identify a non-generic trap when the Generic Trap Type is enterpriseSpecific.

Timestamp Value of the sysUpTime object, representing the amount of time elapsed between the last (re-)initialization and the generation of that Trap.

Object/value Variable binding pair of a variable name with its value.

Interested in more details about testing this protocol? click here


This protocol provides a framework for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall. The protocol is conceptually a “shim-layer” between the application layer and the transport layer, and as such does not provide network layer gateway services, such as forwarding of ICMP messages. SOCKS Version 4 provides unsecured firewall traversal for TCP-based client-server applications, including TELNET, FTP, and protocols such as HTTP, WAIS and GOPHER. This version of SOCKS extends the SOCKS Version 4 model to include UDP, and extends the framework to include provisions for generalized strong authentication schemes. It also adapts the addressing scheme to encompass domain-name and V6 IP addresses.

The implementation of the SOCKS protocol typically involves the recompilation or relinking of TCP-based client applications to use the appropriate encapsulation routines in the SOCKS library.

Protocol Structure for TCP-based Clients Version identifier/method selection message:
1 byte 1 byte 1-225 bytes
Version NMethods Methods

Version The version is 05.

Nmethod The NMETHODS field contains the number of method identifier octets that appear in the METHODS field.

The method selection message:

1 byte 1 byte
Version Method

Methods Possible values for methods are:

00 No authentication required
02 Username/Password
3 IANA assigned
4 to FE Reserved for private methods
FF No acceptable methods

Socks Request Message

1 byte 1 byte Value of 0 1 byte Variable 2 bytes
Version CMD Rsv ATYP DST addr DST Port

Version The Protocol version is 5.

CMD Possible values for the cmnd field are:


Reserved The value of this field is 0.

ATYP Address type of the following address:

01 IP V4 address
04 IP V6 address: X’04’

Destination Address The destination address desired.

Destination Port The desired destination port in network octet order.

Socks Reply Message

1 byte 1 byte Value of 0 1 byte Variable 2 bytes
Version REP RSV ATYP BND addr BND Port

Version The protocol version is 5.

REP The reply field. Possible values for the reply field are:

00 Succeeded
01     General SOCKS server failure
02 Connection not allowed by ruleset
03 Network unreachable
04 Host unreachable
05 Connection refused
06 TTL expired
07 Command not supported
08 Address type not supported
09 to FF Unassigned

RSV Reserved, the value of this field is 0.

ATYP Address type of the following address:

01 IP V4 address
04 IP V6 address: X’04’

BND Address Server bound address.

BND Port Server bound port in network octet order.

Protocol Structure for UDP-based Clients Each UDP datagram carries a UDP request header with it:

UDP Request Header

2byte 1 byte 1 byte Variable 2 Variable

RSV This field is reserved. Its value is 0000.

FRAG This field contains the current fragment number, and indicates whether the datagram is one of a number of fragments.

ATYP Address type of the following address:

01 IP V4 address
04 IP V6 address: X’04’

DST addr Desired destination address.

DST Port Desired destination port.

Data User data.

Interested in more details about testing this protocol? click here


draft RFC1492

TACACS+ is a protocol providing access control for routers, network access servers and other networked computing devices via one or more centralized servers. TACACS+ provides separate authentication, authorization and accounting services. (Compliant with IETF draft-grant-tacacs-00.txt 10-1996.)

The format of the header is shown in the following illustration:

32 bits
Packet type
Sequence no.
Session ID (4 bytes)
Length (4 bytes)
TACACS+ header structure

Major version The major TACACS+ version number.

Minor version The minor TACACS+ version number. This is intended to allow revisions to the TACACS+ protocol while maintaining backwards compatibility.

Packet type Possible values are: TAC_PLUS_AUTHEN:= 0x01 (Authentication). TAC_PLUS_AUTHOR:= 0x02 (Authorization). TAC_PLUS_ACCT:= 0x03 (Accounting).

Sequence number The sequence number of the current packet for the current session. The first TACACS+ packet in a session must have the sequence number 1 and each subsequent packet will increment the sequence number by one. Thus clients only send packets containing odd sequence numbers, and TACACS+ daemons only send packets containing even sequence numbers.

Flags This field contains various flags in the form of bitmaps. The flag values signify whether the packet is encrypted.

Session ID The ID for this TACACS+ session.

Length The total length of the TACACS+ packet body (not including the header).

Interested in more details about testing this protocol? click here


RFC854 RFC855 RFC857

TELNET is the terminal emulation protocol of TCP/IP. Modern TELNET is a versatile terminal emulation due to the many options that have evolved over the past twenty years. Options give TELNET the ability to transfer binary data, support byte macros, emulate graphics terminals, and convey information to support centralized terminal management.

TELNET uses the TCP transport protocol to achieve a virtual connection between server and client. After connecting, TELNET server and client enter a phase of option negotiation that determines the options that each side can support for the connection. Each connected system can negotiate new options or renegotiate old options at any time. In general, each end of the TELNET connection attempts to implement all options that maximize performance for the systems involved.

In a typical implementation, the TELNET client sends single keystrokes, while the TELNET server can send one or more lines of characters in response. Where the Echo option is in use, the TELNET server echoes all keystrokes back to the TELNET client.

Dynamic Mode Negotiation

During the connection, enhanced characteristics other than those offered by the NVT may be negotiated either by the user or the application. This task is accomplished by embedded commands in the data stream. TELNET command codes are one or more octets in length and are preceded by an interpret as command (IAC) character, which is an octet with each bit set equal to one (FF hex). The following are the TELNET command codes:

Commands Code No. Dec Hex Description
data All terminal input/output data.
End subNeg 240 FO End of option subnegotiation command.
No Operation 241 F1 No operation command.
Data Mark 242 F2 End of urgent data stream.
Break 243 F3 Operator pressed the Break key or the Attention key.
Int process 244 F4 Interrupt current process.
Abort output 245 F5 Cancel output from current process.
You there? 246 F6 Request acknowledgment.
Erase char 247 F7 Request that operator erase the previous character.
Erase line 248 F8 Request that operator erase the previous line.
Go ahead! 249 F9 End of input for half-duplex connections.
SubNegotiate 250 FA Begin option subnegotiation.
Will Use 251 FB Agreement to use the specified option.
Won’t Use 252 FC Reject the proposed option.
Start use 253 FD Request to start using specified option.
Stop Use 254 FE Demand to stop using specified option.
IAC 255 FF Interpret as command.

Each negotiable option has an ID, which immediately follows the command for option negotiation, that is, IAC, command, option code. Following is a list of TELNET option codes:

Option ID Dec Hex Option Codes Description
0 0 Binary Xmit Allows transmission of binary data.
1 1 Echo Data Causes server to echo back all keystrokes.
2 2 Reconnect Reconnects to another TELNET host.
3 3 Suppress GA Disables Go Ahead! command.
4 4 Message Sz Conveys approximate message size.
5 5 Opt Status Lists status of options.
6 6 Timing Mark Marks a data stream position for reference.
7 7 R/C XmtEcho Allows remote control of terminal printers.
8 8 Line Width Sets output line width.
9 9 Page Length Sets page length in lines.
10 A CR Use Determines handling of carriage returns.
11 B Horiz Tabs Sets horizontal tabs.
12 C Hor Tab Use Determines handling of horizontal tabs.
13 D FF Use Determines handling of form feeds.
14 E Vert Tabs Sets vertical tabs.
15 F Ver Tab Use Determines handling of vertical tabs.
16 10 Lf Use Determines handling of line feeds.
17 11 Ext ASCII Defines extended ASCII characters.
18 12 Logout Allows for forced log-off.
19 13 Byte Macro Defines byte macros.
20 14 Data Term Allows subcommands for Data Entry to be sent.
21 15 SUPDUP Allows use of SUPDUP display protocol.
22 16 SUPDUP Outp Allows sending of SUPDUP output.
23 17 Send Locate Allows terminal location to be sent.
24 18 Term Type Allows exchange of terminal type information.
25 19 End Record Allows use of the End of record code (0xEF).
26 1A TACACS ID User ID exchange used to avoid more than 1 log-in.
27 1B Output Mark Allows banner markings to be sent on output.
28 1C Term Loc# A numeric ID used to identify terminals.
29 1D 3270 Regime Allows emulation of 3270 family terminals.
30 1E X.3 PAD Allows use of X.3 protocol emulation.
31 1F Window Size Conveys window size for emulation screen.
32 20 Term Speed Conveys baud rate information.
33 21 Remote Flow Provides flow control (XON, XOFF).
34 22 Linemode Provides linemode bulk character transactions.
255 FF Extended options list Extended options list.

Interested in more details about testing this protocol? click here


The Web Cache Coordination Protocol (WCCP) has 2 main functions. The first is to allow a router enabled for transparent redirection to discover, verify, and advertise connectivity to one or more web-caches.

Transparent redirection is a technique used to deploy web-caching without the need for reconfiguration of web-clients. It involves the interception and redirection of HTTP traffic to one or more web-caches by a router or switch, transparently to the web-client.

The second function of WCCP is to allow one of the web-caches, the designated web-cache, to dictate how the router distributes redirected traffic across the web-cache farm. It is recommended that the web-cache with the lowest IP address be elected as designated web-cache for a farm.

Each WCCP protocol packet is carried in a UDP packet with a destination port of 2048.

 Packets can be of the following types; HERE_I_AM, I_SEE_YOU, ASSIGN_BUCKETS.


The format of the Here I am message isL
3 bytes
Protocol Version
Hash revision
Hash Information (1)
Hash Information (7)
Received Id.


Protocol Version This field has a value of 4.

Hash Revision The value of this field is 0.

Hash Information A 256-element bit-vector. A set bit indicates that the corresponding bucket in the Redirection Hash Table is assigned to this web-cache.

U The value of the U flag present in the last WCCP_I_SEE_YOU message received by this cache. Set in first WCCP_HERE_I_AM to indicate that Hash Information is historical.

Received ID The value of the Received ID present in the last WCCP_I_SEE_YOU received by this web-cache.

I SEE YOU Message

The format of the I SEE YOU message is:
3 bytes
Protocol Version
Change number
Received Id.
Number of WCs
Web-Cache List Entry(0)
Web-Cache List Entry (n) v


Protocol Version 4

Change Number Incremented if a Web-Cache List Entry has been added, removed or its hash information has been modified since the last WCCP_I_SEE_YOU sent by the router.

Received ID Incremented each time the router generates a WCCP_I_SEE_YOU.

Number of WCs Number of Web-Cache List Entry elements in the packet.

Web Cached List entry The Web-Cache List Entry describes a Web-Cache by IP Address and lists the redirection hash table entries assigned to it.

WCCP ASSIGN BUCKET The format of the WCCP ASSIGN BUCKET message is: 
3 bytes
Received ID
Number of Web Caches
Web Cache 0 IP address
Web Cache n IP address
Bucket 0 Bucket 1 Bucket 2 bucket 3
Bucket 252 Bucket 253 Bucket 254 bucket 255


Received ID Value of Received ID in last WCCP_I_SEE_YOU received from router.

Number of Web Caches Number of Web Caches to which redirect traffic can be sent.

Web Cache IP address 0-n IP Addresses of Web-Caches to which redirect traffic can be sent. The position of a Web-Cache’s IP Address in this list is the Web-Cache’s index number. The first entry in the list has an index number of zero.

Buckets 0-255 These 256 buckets represent the redirection hash table. The value of each bucket may be 0xFF (Unassigned) or a Web-Cache index number (0-31).

Interested in more details about testing this protocol? click here



The X-Window protocol provides a remote windowing interface to distributed network applications. It is an application layer protocol which uses TCP/IP or DECnet protocols for transport.

The X-Window networking protocol is client-server based, where the server is the control program running on the user workstation and the client is an application running elsewhere on the network. An X-server control program running on a workstation can simultaneously handle display windows for multiple applications, with each application asynchronously updating its window with information carried by the X-Window networking protocol.

To provide user interaction with remote applications, the X-server program running on the workstation generates events in response to user input such as mouse movement or a keystroke. When multiple applications display, the system sends mouse movements or click events to the application currently highlighted by the mouse pointer. The current input focus selects which application receives keystroke events. In certain cases, applications can also generate events directed at the X-server control program.

Request and Reply Frames Request and reply frames can use the following commands:
Command Description
BackRGB Background colors listed in red, green and blue components.
BackPM Pixel map used for the window background.
BellPitch Bell pitch.
BellVol Bell volume in percent.
BM Bit mask assigned to a drawable item.
BordPM Border pixel map. Pixel map used for the window border.
b Border width of the drawable item.
Click Key click volume in percent.
Ord Click order. Drawable clip order, as <Unsorted>, <Y-sorted>, <YX-sorted> or <YX-banded>.
CMap Color map. Code representing the colors in use for a drawable.
CID Context ID. Identifier for a particular graphics context.
Cur Cursor. Reference code identifying a specific cursor.
d Depth. Current window depth.
DD Destination drawable. Target item in a bitmap copy.
D Drawable. Reference code used to identify a specific window or pixel map.
Exp Exposures. Drawable currently exposed.
Fam Protocol family in use, as Internet, DECnet, or CHAOSnet.
Font Reference code used to specify a font.
Font(a,d) Font ascent/descent. The vertical bounds of a font.
ForeRGB Foreground colors listed in red, green, and blue components.
Fmt Format of the current window.
GC Graphics context. Reference code used to identify a particular graphical definition.
h Height of the drawable item.
Key Key code. Specific key code value.
KeySym Code used to identify the family of key codes in use.
MinOp X-Windows minor operation code.
MajOp X-Windows major operation code.
N Number of drawable items in the list.
P Parent window. Window that produced the current window.
PixMap Pixel map. Reference code used to identify a bitmap region.
p Plane. Bit plane in use.
PM Plane max. Bit plane mask assigned to a drawable item.
Prop Property. Specified window property.
SW Sibling window. Window produced from this window.
SD Source drawable. Source item in a bitmap copy.
T/O Screen saver time out.
Typ Type of current window.
w Width of drawable item.
W Window. Reference code used to identify a particular window.
X X-coordinate for a drawable item.
Y Y-coordinate for a drawable item.
Event Frames Event frames can have the following commands:
Command Description
Btn Button number pressed.
C Child window associated with the event.
F Event flags. Set flags display in upper-case and inactive flags display in lower-case: f,F Input focus applies to the event. s,S Event is on the same screen.
E(x,y) Event location. The X and Y coordinates of the event.
E Event window. Window where the event occurred.
Key Key number. Number associated with the pressed key.
O Owner of the window associated with the event.
R Root window associated with the event.
R(x,y) Root location. X and Y coordinates of the root position.
SN Sequence number used to serialize events.
Interested in more details about testing this protocol? click here   1 2 3 4 5 6 7 8 9 TCP/IP Family Protocol Information AH | ATMP | ARP/RARP | BGMP | BGP-4 | COPS | DCAP | DHCP | Diameter | DIS | DNS | DVMRP | EGP | EIGRP | ESP | FANP | Finger | FTP | HSRP | HTTP | ICMP/ICMPv6 | IGMP | IGRP | IMAP4 | IMPPpre/IMPPmes | IPDC | IP | IPv6 | IRC | ISAKMP | ISAKMP/IKE | iSCSI | ISTP | ISP | LDAP | L2F | L2TP | MARS | Mobile IP | MZAP | NARP | NetBIOS/IP | NHRP | NTP | OSPF | PIM | POP3 | PPTP | Radius | RLOGIN | RIP2 | RIPng for IPv6 | RSVP | RTSP | RUDP | SCTP | S-HTTP | SLP | SMTP | SNMP | SOCKS | TACACS+ | TALI | TCP | TELNET | TFTP | TLS | TRIP | UDP | Van Jacobson | VRRP | WCCP | X-Window | XOT
Additional Information