Sample TCP/IP Packet

Included here is a table below that contains a captured packet as captured by a program I use at home called Sniff-It.

If you want to see a generic TCP, UDP, IP, or ICMP packet, field sizes, meaning for each field, etc. check out my head networking page. It has links to header examination for all of these and each can be found in their associated network layers.

Some things to note before looking at this packet:

• Sniff-It is a simple, and unsophisticated packet sniffer that can only log TCP,IP and UDP packets.
• The analysis it can perform is minimal
• I will use this table format to display packets captured by Sniff-It later in this paper.
• The table has "labels" across the first row and first column. These are not part of the packet itself, but are added by me to make it easier to reference parts of the packet by referencing a coordinate. (example: "A1" would refer to the intersection of column "A" row "1" which is "45 E".)
• Each cell that is part of the packet has a hexadecimal value followed by the printable ASCII character for that hexadecimal value. (Using the previous example, "45 E" is the value of a cell that demonstrates the hexadecimal value of "45" is the same as ASCII letter "E".)
• When a cell contains a hexadecimal value that maps to an unprintable ASCII character, a "." (period) will take the place of the unprintable ASCII character.
• The end of the packet is that last valid hexadecimal and ASCII pair. A ".. ." (period-period-space-period) is padded by me to make the table more readable. This sequence of ".. ." is/was not part of the captured packet.

This packet may not make much sense to a casual observer, but there is a great deal of information in that packet. I will disassemble the different parts of this packet to reveal the information that is contained within its confines as raw data.

If you encounter technical words that you do not understand here, you may be able to consult with my simple list of definitions of common terms.

• TCP Packet ID (from_IP.port-to_IP.port): 172.16.0.9.1095-172.16.0.1.23
  • SEQ (hex): 60C6DF90 FLAGS: ----S-
• Packet ID (from_IP.port-to_IP.port): 172.16.0.9.1095-172.16.0.1.23

The IP Header

Since the IP packet is at a lower level in the ISO/OSI 7 layer model, the TCP packet is encapsulated within the IP datagram. We will cover the IP packet header information first:

The first piece of information in the packet listed above is on the first half of the first byte. The first byte in location A1 is 45. The high nibble (first 4 bits of this 8 bit byte) total to 4 in hex. 4 in hex is the same as 4 for decimal. In this case the 4 refers to the version of IP (IPV4 (Internet Protocol Version 4.)) There is a new version that is being worked on called IPV6. If this packet actually conformed to the version 6 of IP, then this first nibble would have a decimal value of 6, and the rest of this packet would be different as well. It is very important for the part of the operating system that deals with the TCP/IP suite to know very quickly if an incoming packet can be discarded, or kept. It would waste crucial system cycles if more processing time was spent on processing a packet that the OS (operating system) can't use.

The next piece of information in the packet listed above is the low half of the first byte. The value of the first byte in location A1 is 45. The low nibble of this byte (the last 4 bits of this 8 bit byte) is 5. This low nibble of the first byte is known as the Internet Header Length (IHL). This is the size of the Internet header in 32 bit words plus any options. In this case the IHL is 5, 5 times 32 is 160 bits. 160 bits divided by 8 bits/byte yields 20 bytes. This means that the first 160 bits of this packet are reserved for header information.

The next byte (B1) describes what is called the type of service (TOS). The first three bits of this is a precedence field which is not used today, and the fourth bit which is set to zero. This leaves 4 bits that can be used to define the type of service (TOS) for this packet. Only one of these bits should ever be on in any one packet. This TOS allows for specialized routing of the packets. OSPF (Open Shortest Path First) can take advantage of this, and route packets according to their TOS. Listing the assignments for these bits from high bit to low:

1. minimize delay
2. maximize throughput
3. maximize reliability
4. minimize monetary cost

The next two bytes (C1 and D1) specify how long the packet is. In this case we have 00 and 2C. 00 become zero. 2C after being converted to decimal is 2*16+12=44. This tells us that the packet should be 44 bytes long. If you count up the total numbers of bytes, you will see that this is indeed the fact. When we know this value and the IHL, then we can figure where the actual data begins by simple subtraction: packet length - IHL = start of data portion.

Bytes E1 and F1 are often used as a form of identification. This 16 bit field is incremented by 1 for each IP datagram that is sent.

The first 3 bits of the 8 bit byte G1 are used to define what flags are set for IP.

The last 2 bits of G1 and all 8 bits of H1 are used for the fragmentation offset.

The next byte, I1 contains the value for the packet's time to live (TTL). This value is decremented by 1 for each router the packet passes through on its way to its destination. When this value becomes zero, it is thrown away. The reasons for this may seem apparent: If a packets end up in a routing loop, then serious problems would exist if looping packets never disappeared.

Byte J1 is used to describe what protocol is being used by the packet in question. In this packet, the value is 06. The decimal value of hexadecimal 06 is also 6. This corresponds to the IP datagram containing a TCP packet in its payload. Some examples of some decimal values that exist are:

• 1=ICMP
• 2=IGMP
• 6=TCP
• 17=UDP

Bytes K1 and L1 are used as header checksums. This checksum helps to verify that the packet arrived at its destination properly. When the node receives the packet, it computes a checksum for the packet's header. If the packet's header checksum has the same checksum as was computed by the receiver, and the length of the packet is what is specified by the packet length (C1 and D1) then the packet is assumed to be good and is accepted.

Options can follow the header checksums, but in this packet, no options have been specified.

TCP header

This next part of the IP packet is a TCP packet. When the IP layer of the ISO/OSI 7 model layer strips off the IP packet information of this packet, the remaining data is a TCP packet...

The next 4 bytes (M1, N1, O1, and P1) are used to define the source IP address. In this case, we have AC 10 00 and 09. After each of these hexadecimal values are converted to decimal they become 172 16 0 9 which happens to be the IP address of the source: 172.16.0.9.

The next 4 bytes (A2, B2, C2, and D2) are used to define the destination IP address. When they are converted to decimal, we find they become 172 16 0 1 which is the destination IP address: 172.16.0.1.

The next 2 bytes (E2 and F2) define the source machine's port address. In this case we have 04 and 47. When these are converted to decimal, we find that the source machines port address is 1095.

The next 2 bytes (G2 and H2) define the destination machine's port address. In this case we have 00 and 17. When these are converted into decimal we see that we have 23. Port 23 is usually used for telnet. There are many ports that have predefined services. There are standards that are published that allow people to agree upon what ports should be used for what services. Some examples of the common services: chargen is on 19, FTP is on 21, Telnet is on 23, Mail (SMTP) is on 25, web (HTTP) is on port 80. It is possible to alter the port that a service is assigned to use, but breaking standards is not considered good form for system administrators.

The next 4 bytes (I2, J2, K2, and L2) define the sequence number (SEQ#) for the packet. Each packet has a sequence number. This is computed by adding the size of the data portion to the previously *generated* packet's SEQ#. In this case, the sequence number in hexadecimal is 60C6DF90.

The next 4 bytes (M2, N2, O2 and P2) define the acknowledgment number (ACK#) to acknowledge the previous packet. Each packet requiring an acknowledgment is acknowledged by sending back to the original packet's source its SEQ# but instead in the ACK# field. This allows an acknowledgment to take place in the same packet that data is being transmitted. Both machines can send new data with an acknowledgement. When a connection is being created, the very first packet sent from the machine trying to establish a connection does not have an acknowledgement value. This is why the values for M2, N2, O2 and P2 are 00 00 00 00.

The first 4 (high bits, or first nibble) of the A3 byte are use to describe the length of the TCP header in 32 bit words. In this packet, the hexadecimal value of the 4 high bits of the 8 bit byte with designation of A3 is 06. 06 in decimal is the same thing. This means that there are 6 x 32 / 8 bytes of data in the TCP header. If you recall, there were 20 bytes in the IP header. It ranged from A1 to D2. The TCP header length is 24 bytes (6 x 32 / 8) and that starts where the IP header leaves off. So from E2 up to L3 is the TCP packet. (This is 24 bytes, and you can count them to verify this is the case.

The remaining 4 bits of A3 and the first 2 bits of B3 are reserved. I was not able to find out for what purpose they are reserved. (6 bits total)

The last 6 bits of B3 are used as flags. Each flag has its own special meaning, and controls. In this packet, the SYN bit is set. This means that this packet is trying to Synchronize sequence numbers. Since the Acknowledgement number field is empty, it is likely that this is the first packet from one machine asking another machine for a connection. Here is a list of the flags in order from high bit to low bit: (More than one flag *can* be set at the same time.)

• URG=Urgent pointer is valid
• ACK=Acknowledgement number is valid
• PSH=Recipient should pass this up to the application layer quickly.
• RST=Reset the connection in operation
• SYN=Synchronize sequence numbers when starting a connection.
• FIN=Finished with this connection. Sender does not need to send any more data.

The next 2 bytes (C3 and D3) are used to tell the recipient the size of the window on the sender. The larger a window is, the more packets that can be transmitted and received before the receiver starts having to wait for early packets, not yet received, to arrive. TCP uses what is called a sliding window protocol. For more information on how a sliding window protocol works, please se the cited references at the end of this paper.

The next two bytes (E3 and F3) cover the TCP packets header and also the data of the packet. This checksum helps to verify that the TCP packet arrived properly

The last two bytes on this packet (G3 and H3) make up the Urgent Pointer field. This field is only valid when the URG flag listed before is set to true. The Urgent Pointer points to the last byte of data that needs to be rushed to the Application layer. This allows for emergency transmissions to exist. They are given greater precedence over non-URGent packets/data. This pointer and flag are set by the transmitter.

Options can follow the urgent pointer, but in this packet, no options have been specified.

Limitations

There are limitations to just how many examples, and sample packets I can analyze in a simple paper. There is enough information about TCP/IP to write well over 1000 pages. The purpose of this paper is to provide a general overview of TCP/IP and UDP/IP as well as demonstrate the connection process with TCP/IP. If a more detailed analysis of the TCP/IP suite is desired, please refer to the list of sources.

Making the Connection...

It can be difficult to apply the above information to a real connection being made. To make this task easier, I have logged the events of a telnet session from one of my home computers to another home computer. I have two copies of this sample connection. The first copy if this connection is a plain text version of what I saw when I logged into a machine. The second copy shows what happened at the TCP/IP level at every step from establishing a connection, through to exchanging information, and ending up with closing the connection. (You will see a real username and real a password in the data captured by this sniffer session. Please note, that this account was immediately disabled after this experiment.)

There is a text file available called "session.txt" and it shows what I, as a user, saw when I logged into a machine I use at home using telnet. This allows you to match the sniffer analysis with the telnet on-screen data.

There is also a sheet attached to this report called "login.html" and it shows an HTML friendly version of the packet sniffed session. ("login.txt" also exists for a non-html version.)

Comments and/or suggestions for this?: Email me at: dugan@passwall.com

Attempts have been made to make the tables appear as they should for LYNX users by forcing a common field width for fields being used by padding them with other printable characters. This is meant to allow for LYNX users to see the tables much like the Netscape and other web browser worlds might show them. However, from personal experience, some versions of LYNX still manage to munge the tables, making them use up several pages. It seems to be a problem with how earlier versions of LYNX dealt with tables, but the problem has not been entirely isolated.

Some have asked why this collection of on-line documents is so lacking of graphic content. To them I answer: faster downloads. Many of these pages are smaller than some pictures on many commercial web sites. You do not come here to look at my pictures. You come here to read content. Also, LYNX users benefit from this, and by using ALL text, people with ADA issues are able to use speech recognition software on the text to hear the words.

Copyright (C) 1999, 2000, 2001, 2002 by Michael Egan: All rights reserved.

A Special License: No part of this document may be used for profit without the consent of the author Michael Egan in writing. Content may be duplicated for retransmission for non-profit purposes as long as the copyright and license remain included in their entirety. The content is provided "as-is" and I take no responsibility on the content's truthfulness or consistency. Errors may exist in these documents, but acting upon these errors is left up to the reader to verify by a third party that will take responsibility for fact verification. When notified of errors or inconsistencies, attempts will be made to rectify the errors.

In plan English this is meant to do many things: This copyright is meant to exist so that others may not profit from this work as published in paper form, or by duplicating the content to place advertisements over it and generate income. It is also meant to exist to prevent people from publishing this work as their own and receiving profit from this process on research they did not perform. It is not meant to stop a professor from running off copies to use in their classes for their students. It is also not meant to stop the student from printing up copies for their own education. How depressing it would be to find your work published in book form without your permission, or compensation. Another reason for this Copyright is to limit the effect of the mistakes I have made within this document before I was able to complete it. It would be even sadder to notice my mistakes in print and criticized before I could resolve them. Eventually, after I finish this work, I may retain copyright, but eliminate the license.