Webspace Sponsored by:
Webspace Sponsored by:
In my house, I have a LAN with about 14 nodes. On this LAN I have two machines that I use in this paper. The first machine, I call fempto. It is a simple IBM Notebook running Linux. It has an IP Address of 172.16.0.9 when it is on my LAN at home. The second machine I call nerds and is a generic PC purchased at a local computer store. This PC is also running Linux. It has an IP Address of 172.16.0.1 and is the gateway for my house network. Nerds doubles as my house LAN's gateway to route traffic and allow the rest of the machines at my house to access resources on the Internet. Outside of my house, an on campus at school is a machine called libvax or 130.157.2.5 which is one of our campus' Domain Name Servers (DNS.)
Some things to note before looking at these packets captured with sniff-it:
Below this paragraph is a sample UPD/IP packet. I will decompose the sequence of data into more easily understood information.
1) - |
45 E |
00 . |
00 . |
37 7 |
00 . |
2D - |
00 . |
00 . |
40 @ |
11 . |
49 I |
CE . |
AC . |
10 . |
00 . |
09 . |
2) - |
82 . |
9D . |
02 . |
05 . |
04 . |
0A . |
00 . |
35 5 |
00 . |
23 # |
7F . |
74 t |
01 . |
11 . |
01 . |
00 . |
3) - |
00 . |
01 . |
00 . |
00 . |
00 . |
00 . |
00 . |
00 . |
05 . |
73 s |
6F o |
6E n |
69 i |
63 c |
03 . |
6E n |
4) - |
65 e |
74 t |
00 . |
00 . |
01 . |
00 . |
01 . |
.. . |
.. . |
.. . |
.. . |
.. . |
.. . |
.. . |
.. . |
.. . |
This packet is actually the very first packet sent by fempto to one of our campus DNS that is not on my LAN at home. This packet went through my LAN's gateway (nerds) to the campus network and one of its DNS (130.157.2.5) for resolution.
Before I disassemble this packet, I should let you know this really contains two main parts within this single IP packet. First, there is the IP header portion. Next, there is the UDP portion. The UDP portion of this packet is part of the IP packet, but the IP portion is not part of the UDP packet. The UDP packet is the data portion of the IP packet.
Since the IP packet is at a lower level in the ISO/OSI 7 layer model than UDP, the UDP 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 byte 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:
The next two bytes (C1 and D1) specify how long the packet should be if properly transmitted and received. In this case we have 00 and 37. 00 become zero. 37 after being converted to decimal is 3*16 +7=55. This tells us that the packet should be 55 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 Internet Header Length (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 11 (hexadecimal.) The decimal value of hexadecimal 11 is 17. This corresponds to the IP datagram containing a UDP packet in its data payload. Some examples of some decimal values that exist are:
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.
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 (82, 9D, 02, and 05). When they are converted to decimal, we find they become 130 157 2 and 5 which is the destination IP address: 130.157.2.5.
Options can follow the header checksums, but in this packet, no options have been specified.
The first 20 bytes of this IP packet were the header. The remaining bytes are all "data" to the IP layer and are handed to the UDP layer to deal with the processing.
The first part of the UDP header can be found with the two bytes found at E2 and F2. These two bytes make up a 16 bit value that defines the port number on the source machine. In this case, we see that the 16 bit hexadecimal value created by joining fields E2 and F2 is 040A which maps to become 1024 (04) + 10 (0A) = 1034 (040A).
The second part of the UDP header can be found by examining the two bytes found at G2 and H2. These two bytes make up a 16 bit value that defines the destination port. In this case, we see that the 16 bit hexadecimal value of 0035. 0035 (hexadecimal) is the same as 53 in decimal notation. Port 53 is commonly used for DNS services.
The third part of this UDP header is also 16 bits. The value found in I2-J2 is 0023. This is 35 in decimal. If you total up the number of bytes from E2 to G4, you will see that this is the case with this packet.
The fourth and final part of this UDP header is also a 16 bit value. The value held by K2-L2 is a 16 bit checksum. The value of these fields is set to 00 and then a checksum algorithm is applied to the packet to yield a 16-bit checksum value. This value replaces the 00 values held by the packet during the checksum process. When the recipient acquires this packet, it copies and removes this 16 bit value out of the packet, and then performs a checksum on the packet as well. If the checksum copied is the same as the checksum that was computed by the recipient, then the packet is accepted as good.
That is the end of the UDP header. The rest of this packet is data to be used by the service (if any) that is running on port 53 on 130.157.2.5 at SSU.
Now that we have covered a UDP/IP packet, I can show you a very simple sample session. In this session, a single UDP/IP packet is sent from fempto 172.16.0.9 to libvax 130.157.2.5. This packet is a request for a name address to be converted to an IP address. This is known as a name resolution to IP Address from the DNS.
The DNS server libvax (130.157.2.5) runs an application level service on its port number 53 called a DNS. fempto (172.16.0.9) is about to send the DNS server a request.
1) - |
45 E |
00 . |
00 . |
37 7 |
00 . |
2D - |
00 . |
00 . |
40 @ |
11 . |
49 I |
CE . |
AC . |
10 . |
00 . |
09 . |
2) - |
82 . |
9D . |
02 . |
05 . |
04 . |
0A . |
00 . |
35 5 |
00 . |
23 # |
7F . |
74 t |
01 . |
11 . |
01 . |
00 . |
3) - |
00 . |
01 . |
00 . |
00 . |
00 . |
00 . |
00 . |
00 . |
05 . |
73 s |
6F o |
6E n |
69 i |
63 c |
03 . |
6E n |
4) - |
65 e |
74 t |
00 . |
00 . |
01 . |
00 . |
01 . |
.. . |
.. . |
.. . |
.. . |
.. . |
.. . |
.. . |
.. . |
.. . |
The proceeding UDP/IP packet may look familiar to you. Actually, this is the very same UDP/IP packet that we disassembled during the introduction to UDP/IP.
In this packet, fempto asked libvax the IP address for a machine called "sonic.net" on the Internet.
Since this packet's IP and UDP headers were examined earlier, duplicating that analysis would be unnecessary. However, a surface examination of the data could prove interesting.
You will notice the ASCII characters in the fields J3-B4 spell "sonic.net"
and this is the same name that fempto asked
libvax to resolve to a numerical IP address. The rest of the information from M2-I3 is information used by the DNS application level
service to perform its duties, and is beyond the scope of this paper.
1) - 45 E 10 . 01 . 05 . 6E n 0B . 00 . 00 . 3F ? 11 . DC . 11 . 82 . 9D . 02 . 05 . 2) - AC . 10 . 00 . 09 . 00 . 35 5 04 . 0A . 00 . F1 . 86 . 18 . 01 . 11 . 85 . 80 . 3) - 00 . 01 . 00 . 01 . 00 . 05 . 00 . 05 . 05 . 73 s 6F o 6E n 69 i 63 c 03 . 6E n 4) - 65 e 74 t 00 . 00 . 01 . 00 . 01 . C0 . 0C . 00 . 01 . 00 . 01 . 00 . 00 . 0E . 5) - 10 . 00 . 04 . D0 . C9 . E0 . 0B . C0 . 0C . 00 . 02 . 00 . 01 . 00 . 00 . 0E . 6) - 10 . 00 . 06 . 03 . 6E n 73 s 31 1 C0 . 0C . C0 . 0C . 00 . 02 . 00 . 01 . 00 . 7) - 00 . 0E . 10 . 00 . 06 . 03 . 6E n 73 s 32 2 C0 . 0C . C0 . 0C . 00 . 02 . 00 . 8) - 01 . 00 . 00 . 0E . 10 . 00 . 12 . 06 . 41 A 55 U 54 T 48 H 30 0 33 3 02 . 4E N 9) - 53 S 02 . 55 U 55 U 03 . 6E n 65 e 74 t 00 . C0 . 0C . 00 . 02 . 00 . 01 . 00 . A) - 00 . 0E . 10 . 00 . 0A . 07 . 6F o 6C l 64 d 2D - 6E n 73 s 31 1 C0 . 0C . C0 . B) - 0C . 00 . 02 . 00 . 01 . 00 . 00 . 0E . 10 . 00 . 0A . 07 . 6F o 6C l 64 d 2D - C) - 6E n 73 s 32 2 C0 . 0C . C0 . 37 7 00 . 01 . 00 . 01 . 00 . 00 . 0E . 10 . 00 . D) - 04 . D0 . C9 . E0 . 0B . C0 . 49 I 00 . 01 . 00 . 01 . 00 . 00 . 0E . 10 . 00 . E) - 04 . D0 . C9 . E0 . 21 ! C0 . 5B [ 00 . 01 . 00 . 01 . 00 . 02 . 9B . DD . 00 . F) - 04 . C6 . 06 . 01 . 53 S C0 . 79 y 00 . 01 . 00 . 01 . 00 . 00 . 0E . 10 . 00 . G) - 04 . C7 . 04 . 76 v 0B . C0 . 8F . 00 . 01 . 00 . 01 . 00 . 00 . 0E . 10 . 00 . H) - 04 . C7 . 04 . 76 v 21 ! .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 2, libvax has responded to packet 1 sent from fempto that asked about "sonic.net" and its IP address.
If we just examine the UDP header portion of this packet (which starts at E2 and ends at L2) we can see some information in this packet is similar to the UDP header information of packet 1. First, you will notice that the source port for this packet coming from libvax (E1-F1=0035 (hexadecimal) = 53 (decimal)) is the same port that received the request from fempto, port 53. The destination port for packet 2 is the source port of fempto in packet 1. From this, you can see that the source port of fempto became the destination port used by libvax in packet 2.
Fields D5, E5, F5 ,and G5 contain the IP address in hexadecimal form. These fields' vales are D0 C9 E0 and 0B. When they are converted to decimal, you see 208 201 224 11 or 208.201.224.11 in the proper dot notation. The rest of this information is used by the application level command "nslookup" issued on fempto.
In order for me to generate the request packet, I used a Unix command called nslookup. You can see that the amount of information displayed on fempto's screen by using nslookup was smaller than the amount of information transmitted in the packets.
Here is what I saw as a user when I performed this DNS lookup with nslookup:
$ nslookup
: sonic.net
SONIC.NET A 208.201.224.11
If you count the number of meaningful characters in the three previous commands, you will find that it is much smaller than the number of bytes transmitted and received in the 2 session UDP/IP packets.
UDP/IP packets are very simple packets, when compared to TCP/IP. You will see this is true when we examine a TCP/IP packet, and a simple telnet session that uses TCP/IP to allow two machines to communicate.
Here is a table below that contains a captured packet.
1) - |
45 E |
10 . |
00 . |
2C , |
24 $ |
B2 . |
00 . |
00 . |
40 @ |
06 . |
FD . |
DF . |
AC . |
10 . |
00 . |
09 . |
2) - |
AC . |
10 . |
00 . |
01 . |
04 . |
47 G |
00 . |
17 . |
60 ` |
C6 . |
DF . |
90 . |
00 . |
00 . |
00 . |
00 . |
3) - |
60 ` |
02 . |
02 . |
00 . |
F9 . |
46 F |
00 . |
00 . |
02 . |
04 . |
05 . |
B4 . |
.. . |
.. . |
.. . |
.. . |
This TCP/IP 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.
Now we will examine the following packet:
1) - |
45 E |
10 . |
00 . |
2C , |
24 $ |
B2 . |
00 . |
00 . |
40 @ |
06 . |
FD . |
DF . |
AC . |
10 . |
00 . |
09 . |
2) - |
AC . |
10 . |
00 . |
01 . |
04 . |
47 G |
00 . |
17 . |
60 ` |
C6 . |
DF . |
90 . |
00 . |
00 . |
00 . |
00 . |
3) - |
60 ` |
02 . |
02 . |
00 . |
F9 . |
46 F |
00 . |
00 . |
02 . |
04 . |
05 . |
B4 . |
.. . |
.. . |
.. . |
.. . |
Since the IP packet is at a lower level in the ISO/OSI 7 layer model than TCP, the TCP packet is encapsulated within the IP datagram. We will cover the IP packet header information first:
The information covered in the IP header of this packet will look a lot like the IP information of the IP header in the first sample UDP/IP packet. Some of the background on this information may be omitted, since it has been covered above in the IP header examination of the first sample UDP/IP packet.
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. Again, just like the IP header of the first sample UDP/IP packet, you will see that this packet is also using IPV4 and has an Internet Header Length (IHL) of 5, or a 20 byte IP header.
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, and the fourth bit which is set to zero or one. 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:
The next two bytes (C1 and D1) specify how long the packet should be if properly transmitted and received. In this case we have 00 and 2C. 00 (hexadecimal) becomes zero (decimal.) 2C (hexadecimal) after being converted to decimal is 44 (decimal) (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 case. When we know this value and the Internet Header Length 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. (See the above description in the IP header examination of the first sample UDP/IP packet.)
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. See the analysis of the IP header in the first UDP/IP sample packet
Bytes K1 and L1 are used as header checksums.
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.
Options can follow the header checksums, but in this packet, no options have been specified.
This next part of the IP packet is the data. In this IP packet, the data portion 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 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 a previous packet sent by a remote machine. Each packet requiring an acknowledgment is acknowledged by sending back to the original packet's source a modified SEQ# but instead in the ACK# field. The modified SEQ# being transmitted as an ACKnowledgement can be computed by adding the original SEQ# to the number of bytes in that packets data field plus 1 if the SYNcronize flag is set. This modified SEQuence number becomes the ACKnowledgement number to tell the remote machine that the packet with a SEQuence number equal to the unmodified SEQuence number was received. If the packet was properly transmitted, then the returning ACKnowledgement will be expected. 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 SYNcronize 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.)
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 see 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. Precedence allows this data to reach the application before other data waiting in buffers on the recipient's machine.
Options can follow the urgent pointer, but in this packet, no options have been specified.
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. (Well over this quantity of pages have been written in TCP/IP Illustrated Vol I,II, and III (Stevens), Essential TCP/IP for UNIX System Administration (Hunt), and there is even a "TCP/IP for Dummies" . 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 near the end of this paper.
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 user name 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 sheet attached to this report called "session.txt" and it shows what I, as a user, saw when I logged into a machine I use at home.
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.)
Both of these two papers have been combined below with comments explaining some of the things that are happening with the data exchanged between the client (172.16.0.9) and the server (172.16.0.1).
In order to make a connection, I needed to use an application level program to deal with my user interface. I issued the an application level command from BASH (Bourne Again Shell) on a Linux Box (IP address: 172.16.0.9). The application level program I decided to use was the very old telnet program. telnet is used, and has been used to connect to remote machines and use remote machine resources by issuing text based commands to a shell, or interactive controller. Beyond proper networking between a local machine and a remote machine, the telnet client needs to have a server to connect to use. Many UNIX based servers use something called telnetd (telnet Daemon) to allow users to connect, and use the resources on the UNIX server offering the telnetd service.
So, I typed the following:
$ telnet nerds
The "$" is part of BASH. It is the interactive prompt that waits for me to give it a command. In this case, I told BASH to run a program called telnet. telnet takes the next item "nerds" and uses it as its argument when it starts to performs its function. "Nerds" is the name of another Linux box in my house (IP address=172.16.0.1).
telnet realizes that it needs to make a connection to a machine called "nerds" and does not care if this machine exists, or if this is the name that is answers requests with on any of the lower levels of the ISO/OSI 7 layer model. The system's Transport layer (or as a super-service of the Networking layer) realizes that this name "nerds" is not acceptable. The Transport layer (or a super-service for it in the system's kernel) need to find a way to convert a name into an IP address more easily used by the Transport and Networking layers of the TCP/IP suite. Sometimes another server called a DNS (Domain Name Server) is asked for a conversion from name to IP address with numbers. In this case, I have a "hosts" file which is a database that is consulted by the system before checking a DNS. I have a single line in my "hosts" file on the 172.16.0.9 Linux box that reads:
172.16.0.1 nerds.sonoma.edu nerds
172.16.0.1 is the number that the networking layer will use instead of "nerds" to communicate with the machine I call nerds.
Next, telnet gives me some feedback. It tells me what it is going to be doing:
Trying 172.16.0.1...
This is the point where the actual network traffic starts. The next part shown below covers everything that happens on the network until just before I see anything more reported to me from telnet.
In this first packet you will notice that the SYN flag is set, and the ACK field (M2, N2, O2, and P2) are all set to "00" as well. The SYN flag is used to SYNcronize the SEQuence, and ACKnowledgement numbers of two machines. Since the machine (172.16.0.9) that wishes to start a TCP/IP connection does not know the SEQuence number to ACKnowledge when the connection has not happened yet.
1) - |
45 E |
10 . |
00 . |
2C , |
0A . |
27 ' |
00 . |
00 . |
40 @ |
06 . |
18 . |
6B k |
AC . |
10 . |
00 . |
09 . |
2) - |
AC . |
10 . |
00 . |
01 . |
04 . |
3B ; |
00 . |
17 . |
D3 . |
9A . |
FE . |
97 . |
00 . |
00 . |
00 . |
00 . |
3) - |
60 ` |
02 . |
02 . |
00 . |
67 g |
77 w |
00 . |
00 . |
02 . |
04 . |
05 . |
B4 . |
.. . |
.. . |
.. . |
.. . |
At this point, a single lonely packet has been sent out on the EtherNet. An examination of the TCP header (Transport Control Protocol/Transport Layer's header) reveals that this packet's source port address is 1083. This port value does not need to be 1083 for telnet connections. Actually, it could have been generated on port 20000, or any other port. (However, most UNIX systems will not allow standard non-administrators to start any service or application layer process on ports less than or equal to 1024.) We also can tell that the destination port for this packet is port 23. There is an RFC (Request For Comment) that are published that specify what services should be offered on which ports. These services can be offered on ports other than what the RFCs specify, but then they would be non-standard, and users wishing to use these services would have a more difficult time figuring out how to use them. The size of the window is also unknown. This is something that has to be negotiated by the Transport layer on both machines. The SEQuence number on the 172.16.0.9 machine is D39AFE97 (hexadecimal).
There is more information in the rest of this packet, however, a complete examination of every value in every packet would cause this paper to exceed 150 pages. I feel that the rest of the information remaining in this packet is not as important as the information already covered. The rest of the packets will be treated the same way.
After the first packet is transmitted by 172.16.0.9, it is up to the destination machine 172.16.0.1 to respond if it is willing and able to respond.
1) - 45 E 00 . 00 . 2C , EF . CA . 00 . 00 . 40 @ 06 . 32 2 D7 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 78 x F9 . D3 . 9A . FE . 98 . 3) - 60 ` 12 . 37 7 FF . 5C \ 59 Y 00 . 00 . 02 . 04 . 05 . 9C . .. . .. . .. . .. .
Packet 2 shows that machine 172.16.0.1 is able to respond to the request from 172.16.0.9 for a connection. The SYNcronize flag and the ACKnowledgement flag are both set. Each 8-bit byte value in the data portion of the TCP portion of the packet increases the SEQuence number being sent by 172.16.0.9. The ACKnowledgement sent back to 172.16.0.9 from 172.16.0.1 includes the SEQuence number sent by 172.16.0.9 plus the number of bytes in the data portion of the TCP encapsulated portion of this IP packet. There wasn't any data transmitted by 172.16.0.9 to 172.16.0.1 in Packet 1, but the SYNcronize flag was set. This means that 172.16.0.1 must increment the SEQuence value it received from 172.16.0.9 in packet 1 by 1. So, the SEQuence value of D39AFE97 (hexadecimal) becomes the ACKnowledgement value of D39AFE97 in packet 2 from 172.16.0.1 in packet 2.
The SEQuence number generated by 172.16.0.1 is 5C2C78F9. There isn't any data in the data field of the encapsulated TCP portion of IP packet 2. There is however a SYNcronize flag set in packet 2 by 172.16.0.1 in packet 2. You would expect that the ACKnowledgement sent in packet 3 by 172.16.0.9 to packet 2 to be 5C2C78FA (hexadecimal). You will see that this is indeed the case in packet 3 below.
You will also notice another value that did not exist in packet 1. This value is the window value. Each machine needs to let the other one know how big of a window exists for sequenced packets. The size of the window for 172.16.0.1 is noted to be 37FF (hexadecimal). (Refer to the previous complete dissection of the sample TCP/IP packet above.)
1) - 45 E 10 . 00 . 28 ( 0A . 28 ( 40 @ 00 . 40 @ 06 . D8 . 6D m AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . 98 . 5C \ 2C , 78 x FA . 3) - 50 P 10 . 7D } 78 x 2E . 85 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
At this point, both machines are talking to each other, have identified what ports they are using, what SEQuence numbers, what ACKnowledgement numbers, window sizes, and other reviewed information.
The critical TCP/IP information required to start a TCP/IP connection has taken place. The two machines are now willing and able to talk to each other.
The next few packets include data relevant to the telnet client and server as well as some extra networking info on Maximum packet sizes. Since this is not an analysis of the application layer, this analysis will be skipped.
An example of what kind of information can be exchanged between the telnet server and client include: X-Window and terminal settings of the client's shell. Specialized exported environmental variables in BASH are also possible candidates for exchange in these packets.
1) - 45 E 10 . 00 . 40 @ 0A . 29 ) 40 @ 00 . 40 @ 06 . D8 . 54 T AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . 98 . 5C \ 2C , 78 x FA . 3) - 50 P 18 . 7D } 78 x D2 . 13 . 00 . 00 . FF . FD . 03 . FF . FB . 18 . FF . FB . 4) - 1F . FF . FB . 20 FF . FB . 21 ! FF . FB . 22 " FF . FB . 27 ' FF . FD . 05 . 1) - 45 E 10 . 00 . 28 ( EF . CB . 00 . 00 . 40 @ 06 . 32 2 CA . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 78 x FA . D3 . 9A . FE . B0 . 3) - 50 P 10 . 37 7 E7 . 73 s FE . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 2B + EF . CC . 00 . 00 . 40 @ 06 . 32 2 C6 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 78 x FA . D3 . 9A . FE . B0 . 3) - 50 P 18 . 37 7 E7 . 4E N F5 . 00 . 00 . FF . FD . 25 % .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 2B + 0A . 2A * 40 @ 00 . 40 @ 06 . D8 . 68 h AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . B0 . 5C \ 2C , 78 x FD . 3) - 50 P 18 . 7D } 78 x 09 . 62 b 00 . 00 . FF . FC . 25 % .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( EF . CD . 00 . 00 . 40 @ 06 . 32 2 C8 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 78 x FD . D3 . 9A . FE . B3 . 3) - 50 P 10 . 37 7 E4 . 73 s FB . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 46 F EF . CE . 00 . 00 . 40 @ 06 . 32 2 A9 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 78 x FD . D3 . 9A . FE . B3 . 3) - 50 P 18 . 37 7 FF . F1 . 41 A 00 . 00 . FF . FB . 03 . FF . FD . 18 . FF . FD . 4) - 1F . FF . FD . 20 FF . FD . 21 ! FF . FE . 22 " FF . FE . 27 ' FF . FB . 05 . 5) - FF . FD . 23 # FF . FD . 24 $ .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 37 7 0A . 2B + 40 @ 00 . 40 @ 06 . D8 . 5B [ AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . B3 . 5C \ 2C , 79 y 1B . 3) - 50 P 18 . 7D } 78 x 94 . 16 . 00 . 00 . FF . FA . 1F . 00 . 50 P 00 . 19 . FF . 4) - F0 . FF . FC . 23 # FF . FC . 24 $ .. . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( EF . CF . 00 . 00 . 40 @ 06 . 32 2 C6 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 1B . D3 . 9A . FE . C2 . 3) - 50 P 10 . 37 7 F0 . 73 s C2 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 34 4 EF . D0 . 00 . 00 . 40 @ 06 . 32 2 B9 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 1B . D3 . 9A . FE . C2 . 3) - 50 P 18 . 37 7 FF . 3B ; C5 . 00 . 00 . FF . FA . 20 01 . FF . F0 . FF . FA . 4) - 18 . 01 . FF . F0 . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 44 D 0A . 2C , 40 @ 00 . 40 @ 06 . D8 . 4D M AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . C2 . 5C \ 2C , 79 y 27 ' 3) - 50 P 18 . 7D } 78 x 13 . B6 . 00 . 00 . FF . FA . 20 00 . 33 3 38 8 34 4 30 0 4) - 30 0 2C , 33 3 38 8 34 4 30 0 30 0 FF . F0 . FF . FA . 18 . 00 . 6C l 69 i 6E n 5) - 75 u 78 x FF . F0 . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( EF . D1 . 00 . 00 . 40 @ 06 . 32 2 C4 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 27 ' D3 . 9A . FE . DE . 3) - 50 P 10 . 37 7 E3 . 73 s A7 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 2B + EF . D2 . 00 . 00 . 40 @ 06 . 32 2 C0 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 27 ' D3 . 9A . FE . DE . 3) - 50 P 18 . 37 7 FF . 72 r 82 . 00 . 00 . FF . FD . 01 . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 2B + 0A . 2D - 40 @ 00 . 40 @ 06 . D8 . 65 e AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . DE . 5C \ 2C , 79 y 2A * 3) - 50 P 18 . 7D } 78 x 2D - 07 . 00 . 00 . FF . FC . 01 . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( EF . D3 . 00 . 00 . 40 @ 06 . 32 2 C2 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 2A * D3 . 9A . FE . E1 . 3) - 50 P 10 . 37 7 FC . 73 s 88 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
After the necessary information has been exchanged by both 172.16.0.1 and its copy of telnetd as well as 172.16.0.9 and its copy of a telnet client, we get back to seeing what telnet is going to report.
In this case, when I examine BASH on 172.16.0.9, I see that my telnet client is reporting some information back to me:
Connected to nerds.sonoma.edu.
Escape character is '^]'.
Now, the telnet application and server have agreed upon their terms of communication, and the server would like to send my telnet client some data. The following packet is sent by 172.16.0.1 to 172.16.0.9 as shown below.
Packet 18 has information that is useful to the user. It tells the user what telnetd is programmed to tell the client to tell the user. In this case, the following data is:
Linux 1.2.13 (nerds.sonoma.edu) (ttyp2)
This says that the server (172.16.0.1) is running Linux kernel version 1.2.13. It thinks its name is nerds.sonoma.edu, and ttyp2 is the terminal device assigned for this connection. (ttyp2 is a special file known as a device on the server (172.16.0.1). The name ttyp is actually an abbreviation for an old piece of hardware called a teletype. The number specifies which "teletype" the server thinks is assigned for this connection. Modern shells, and terminal access is not as simple as a teletype, but the name is still referenced) It is also noteworthy to mention that this string of data is not necessarily true. A UNIX server can also have its telnetd service configured to say that it is a Commodore 64, or Apple ][e. There is nothing to prevent the sysadmin from lying to the users that are connecting.
1) - 45 E 10 . 00 . 58 X EF . D4 . 00 . 00 . 40 @ 06 . 32 2 91 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 2A * D3 . 9A . FE . E1 . 3) - 50 P 18 . 37 7 FF . 43 C B3 . 00 . 00 . FF . FB . 01 . 0D . 0A . 4C L 69 i 6E n 4) - 75 u 78 x 20 31 1 2E . 32 2 2E . 31 1 33 3 20 28 ( 6E n 65 e 72 r 64 d 73 s 5) - 2E . 73 s 6F o 6E n 6F o 6D m 61 a 2E . 65 e 64 d 75 u 29 ) 20 28 ( 74 t 74 t 6) - 79 y 70 p 32 2 29 ) 0D . 0A . 0D . 0A . 0A . 0A . 0A . 0A . 0A . 0A . 0A . 0A . 1) - 45 E 10 . 00 . 2B + 0A . 2E . 40 @ 00 . 40 @ 06 . D8 . 64 d AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . E1 . 5C \ 2C , 79 y 5A Z 3) - 50 P 18 . 7D } 78 x 2C , D3 . 00 . 00 . FF . FD . 01 . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( EF . D5 . 00 . 00 . 40 @ 06 . 32 2 C0 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 5A Z D3 . 9A . FE . E4 . 3) - 50 P 10 . 37 7 FC . 73 s 55 U 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 2A * EF . D6 . 00 . 00 . 40 @ 06 . 32 2 BD . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 5A Z D3 . 9A . FE . E4 . 3) - 50 P 18 . 37 7 FF . 66 f 3E > 00 . 00 . 0D . 0A . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( 0A . 2F / 40 @ 00 . 40 @ 06 . D8 . 66 f AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . E4 . 5C \ 2C , 79 y 5C \ 3) - 50 P 10 . 7D } 78 x 2D - D7 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
This next packet sends the request for the user name of the server from 172.16.0.1 in the form of:
nerds login:
1) - 45 E 10 . 00 . 35 5 EF . D7 . 00 . 00 . 40 @ 06 . 32 2 B1 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 5C \ D3 . 9A . FE . E4 . 3) - 50 P 18 . 37 7 FF . BD . 3D = 00 . 00 . 6E n 65 e 72 r 64 d 73 s 20 6C l 6F o 4) - 67 g 69 i 6E n 3A : 20 .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( 0A . 30 0 40 @ 00 . 40 @ 06 . D8 . 65 e AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . E4 . 5C \ 2C , 79 y 69 i 3) - 50 P 10 . 7D } 78 x 2D - CA . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 25 contains the user name being submitted from 172.16.0.9 to 172.16.0.1. What I saw on the console of fempto was:
nerds login: mike
I typed in "mike" as the response to the "nerds login:" referenced in packet 23. "mike" is my user name on nerds.
1) - 45 E 10 . 00 . 2C , 0A . 31 1 40 @ 00 . 40 @ 06 . D8 . 60 ` AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . E4 . 5C \ 2C , 79 y 69 i 3) - 50 P 18 . 7D } 78 x 54 T EF . 00 . 00 . 6D m 69 i 6B k 65 e .. . .. . .. . .. .
Packet 26 acknowledges packet 25.
1) - 45 E 10 . 00 . 28 ( EF . D8 . 00 . 00 . 40 @ 06 . 32 2 BD . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 69 i D3 . 9A . FE . E8 . 3) - 50 P 10 . 37 7 FB . 73 s 43 C 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 27, you see that the word "mike" is being transmitted from the
server nerds to fempto.
This may appear strange. Why would the server send back to me the same data
I have typed into my console on fempto? The answer to this lies in the telnet protocol. In this case, telnet only displays the output
coming back from the server. This is done for two reasons. First, the server
nerds will not echo back what I type into the telnet
session when it asks for a password. Second, I can actually
see what the server thinks it should have received. This allows me as a user to act as the highest level of error correction: user verification of
data. In the unlikely even that I typed a "#" and the server received an "!",
I would be able to see what the server received, and be able to change the
value with a delete.
1) - 45 E 10 . 00 . 2C , EF . D9 . 00 . 00 . 40 @ 06 . 32 2 B8 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 69 i D3 . 9A . FE . E8 . 2) - 50 P 18 . 37 7 FF . 9A . 64 d 00 . 00 . 6D m 69 i 6B k 65 e .. . .. . .. . .. .
This packet ACKnowledges to nerds from
fempto that the packet containing the echoed
"mike" arrived successfully.
1) - 45 E 10 . 00 . 28 ( 0A . 32 2 40 @ 00 . 40 @ 06 . D8 . 63 c AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . E8 . 5C \ 2C , 79 y 6D m 3) - 50 P 10 . 7D } 78 x 2D - C2 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In this packet I send a simple Carrige Return - Line Feed after my user name.
1) - 45 E 10 . 00 . 2A * 0A . 33 3 40 @ 00 . 40 @ 06 . D8 . 60 ` AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . E8 . 5C \ 2C , 79 y 6D m 3) - 50 P 18 . 7D } 78 x 20 B8 . 00 . 00 . 0D . 00 . .. . .. . .. . .. . .. . .. .
This packet ACKnowledges my Carrige Return - Line Feed.
1) - 45 E 10 . 00 . 28 ( EF . DA . 00 . 00 . 40 @ 06 . 32 2 BB . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 6D m D3 . 9A . FE . EA . 3) - 50 P 10 . 37 7 FD . 73 s 3B ; 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
This packet echos back my Carrige Return - Line Feed.
1) - 45 E 10 . 00 . 2A * EF . DB . 00 . 00 . 40 @ 06 . 32 2 B8 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 6D m D3 . 9A . FE . EA . 3) - 50 P 18 . 37 7 FF . 66 f 25 % 00 . 00 . 0D . 0A . .. . .. . .. . .. . .. . .. .
Another ACKnowledgement for a Carrige return Line Feed
1) - 45 E 10 . 00 . 28 ( 0A . 34 4 40 @ 00 . 40 @ 06 . D8 . 61 a AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . EA . 5C \ 2C , 79 y 6F o 3) - 50 P 10 . 7D } 78 x 2D - BE . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Now the server prompts me for a password with packet 33:
Password:
1) - 45 E 10 . 00 . 32 2 EF . DC . 00 . 00 . 40 @ 06 . 32 2 AF . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 6F o D3 . 9A . FE . EA . 3) - 50 P 18 . 37 7 FF . 8B . 5C \ 00 . 00 . 50 P 61 a 73 s 73 s 77 w 6F o 72 r 64 d 4) - 3A : 20 .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
fempto Acknowledges successful receipt of
Password:.
1) - 45 E 10 . 00 . 28 ( 0A . 35 5 40 @ 00 . 40 @ 06 . D8 . 60 ` AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . EA . 5C \ 2C , 79 y 79 y 3) - 50 P 10 . 7D } 78 x 2D - B4 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 35 is used by 172.16.0.9 to transmit the password to 172.16.0.1 for login validation. The password is not echo-ed back to 172.16.0.9 like other traffic. The password I typed in for this session, that was transmitted by packet 35 was:
SuprSecr
1) - 45 E 10 . 00 . 30 0 0A . 36 6 40 @ 00 . 40 @ 06 . D8 . 57 W AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . EA . 5C \ 2C , 79 y 79 y 3) - 50 P 18 . 7D } 78 x B2 . E4 . 00 . 00 . 53 S 75 u 70 p 72 r 53 S 65 e 63 c 72 r
Packet 36 from
nerds ACKnowledges receipt of the string
SuprSecr
1) - 45 E 10 . 00 . 28 ( EF . DD . 00 . 00 . 40 @ 06 . 32 2 B8 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 79 y D3 . 9A . FE . F2 . 3) - 50 P 10 . 37 7 F7 . 73 s 2D - 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 37 is a carrige return - line feed issued by
fempto to finish entering the password.
1) - 45 E 10 . 00 . 2A * 0A . 37 7 40 @ 00 . 40 @ 06 . D8 . 5C \ AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F2 . 5C \ 2C , 79 y 79 y 3) - 50 P 18 . 7D } 78 x 20 A2 . 00 . 00 . 0D . 00 . .. . .. . .. . .. . .. . .. .
Packet 38 ACKnowledges packet 37 and its carrige return - line feed.
1) - 45 E 10 . 00 . 28 ( EF . DE . 00 . 00 . 40 @ 06 . 32 2 B7 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 79 y D3 . 9A . FE . F4 . 3) - 50 P 10 . 37 7 F5 . 73 s 2D - 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 39, the server nerds sends
fempto a few more carrige returns
1) - 45 E 10 . 00 . 2C , EF . DF . 00 . 00 . 40 @ 06 . 32 2 B2 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 79 y D3 . 9A . FE . F4 . 3) - 50 P 18 . 37 7 FF . 59 Y 0D . 00 . 00 . 0D . 00 . 0D . 0A . .. . .. . .. . .. .
In packet 40, fempto ACKnowledges those Carrige return
line feeds.
1) - 45 E 10 . 00 . 28 ( 0A . 38 8 40 @ 00 . 40 @ 06 . D8 . 5D ] AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 79 y 7D } 3) - 50 P 10 . 7D } 78 x 2D - A6 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 41 includes the next line of data sent by the server (172.16.0.1) to the client (172.16.0.9). This line looked like:
Last login: Wed Apr 1 22:40:03 from fempto.sonoma.ed
1) - 45 E 10 . 00 . 5F _ EF . E0 . 00 . 00 . 40 @ 06 . 32 2 7E ~ AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y 7D } D3 . 9A . FE . F4 . 3) - 50 P 18 . 37 7 FF . D5 . 6A j 00 . 00 . 4C L 61 a 73 s 74 t 20 6C l 6F o 67 g 4) - 69 i 6E n 3A : 20 57 W 65 e 64 d 20 41 A 70 p 72 r 20 20 31 1 20 32 2 5) - 32 2 3A : 34 4 30 0 3A : 30 0 33 3 20 66 f 72 r 6F o 6D m 20 66 f 65 e 6D m 6) - 70 p 74 t 6F o 2E . 73 s 6F o 6E n 6F o 6D m 61 a 2E . 65 e 64 d 0D . 0A . .. .
In packet 42, fempto ACKnowledges receipt of packet 41 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 39 9 40 @ 00 . 40 @ 06 . D8 . 5C \ AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 79 y B4 . 3) - 50 P 10 . 7D } 78 x 2D - 6F o 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 43 includes the next line of data sent by the server (172.16.0.1) to the client (172.16.0.9). This line looked like:
Nerd House gateway running Linux 1.2.13.
1) - 45 E 10 . 00 . 52 R EF . E1 . 00 . 00 . 40 @ 06 . 32 2 8A . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y B4 . D3 . 9A . FE . F4 . 3) - 50 P 18 . 37 7 FF . 37 7 4C L 00 . 00 . 4E N 65 e 72 r 64 d 20 48 H 6F o 75 u 4) - 73 s 65 e 20 67 g 61 a 74 t 65 e 77 w 61 a 79 y 20 72 r 75 u 6E n 6E n 69 i 5) - 6E n 67 g 20 4C L 69 i 6E n 75 u 78 x 20 31 1 2E . 32 2 2E . 31 1 33 3 2E . 6) - 0D . 0A . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 44 is an ACKnowledgement from fempto to
nerds that is received packet 43 properly.
1) - 45 E 10 . 00 . 28 ( 0A . 3A : 40 @ 00 . 40 @ 06 . D8 . 5B [ AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 79 y DE . 3) - 50 P 10 . 7D } 78 x 2D - 45 E 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In Packet 45 nerds sends fempto
more carrige return - line feeds.
1) - 45 E 10 . 00 . 2A * EF . E2 . 00 . 00 . 40 @ 06 . 32 2 B1 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y DE . D3 . 9A . FE . F4 . 3) - 50 P 18 . 37 7 FF . 65 e AA . 00 . 00 . 0D . 0A . .. . .. . .. . .. . .. . .. .
In Packet 46, fempto ACKnowledges those CR/LF.
1) - 45 E 10 . 00 . 28 ( 0A . 3B ; 40 @ 00 . 40 @ 06 . D8 . 5A Z AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 79 y E0 . 3) - 50 P 10 . 7D } 78 x 2D - 43 C 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 47, the first line of a fortune is transmitted by the server (172.16.0.1) to the client (172.16.0.9).:
Don: I didn't know you had a cousin Penelope, Bill! Was she
1) - 45 E 10 . 00 . 69 i EF . E3 . 00 . 00 . 40 @ 06 . 32 2 71 q AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 79 y E0 . D3 . 9A . FE . F4 . 3) - 50 P 18 . 37 7 FF . 5E ^ EF . 00 . 00 . 44 D 6F o 6E n 3A : 20 20 20 20 4) - 49 I 20 64 d 69 i 64 d 6E n 27 ' 74 t 20 6B k 6E n 6F o 77 w 20 79 y 6F o 5) - 75 u 20 68 h 61 a 64 d 20 61 a 20 63 c 6F o 75 u 73 s 69 i 6E n 20 50 P 6) - 65 e 6E n 65 e 6C l 6F o 70 p 65 e 2C , 20 42 B 69 i 6C l 6C l 21 ! 20 20 7) - 57 W 61 a 73 s 20 73 s 68 h 65 e 0D . 0A . .. . .. . .. . .. . .. . .. . .. .
In packet 48, fempto ACKnowledges packet 47 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 3C < 40 @ 00 . 40 @ 06 . D8 . 59 Y AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 7A z 21 ! 3) - 50 P 10 . 7D } 78 x 2D - 02 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 49, the rest of my fortune is transmitted:
Don: I didn't know you had a cousin Penelope, Bill! Was she
pretty?
W. C.: Well, her face was so wrinkled it looked like seven miles of
bad road. She had so many gold teeth, Don, she use to have to
sleep with her head in a safe. She died in Bolivia.
Don: Oh, Bill, it must be hard to lose a relative.
W. C.: It's almost impossible.
--W.C. Fields, From "The Further Adventures of Larson
E. Whipsnade and other Tarradiddles"
1) - 45 E 10 . 01 . AB . EF . E4 . 00 . 00 . 40 @ 06 . 31 1 2E . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7A z 21 ! D3 . 9A . FE . F4 . 3) - 50 P 18 . 37 7 FF . 38 8 77 w 00 . 00 . 09 . 70 p 72 r 65 e 74 t 74 t 79 y 3F ? 4) - 0D . 0A . 57 W 2E . 20 43 C 2E . 3A : 20 20 57 W 65 e 6C l 6C l 2C , 20 5) - 68 h 65 e 72 r 20 66 f 61 a 63 c 65 e 20 77 w 61 a 73 s 20 73 s 6F o 20 6) - 77 w 72 r 69 i 6E n 6B k 6C l 65 e 64 d 20 69 i 74 t 20 6C l 6F o 6F o 6B k 7) - 65 e 64 d 20 6C l 69 i 6B k 65 e 20 73 s 65 e 76 v 65 e 6E n 20 6D m 69 i 8) - 6C l 65 e 73 s 20 6F o 66 f 0D . 0A . 09 . 62 b 61 a 64 d 20 72 r 6F o 61 a 9) - 64 d 2E . 20 20 53 S 68 h 65 e 20 68 h 61 a 64 d 20 73 s 6F o 20 6D m A) - 61 a 6E n 79 y 20 67 g 6F o 6C l 64 d 20 74 t 65 e 65 e 74 t 68 h 2C , 20 B) - 44 D 6F o 6E n 2C , 20 73 s 68 h 65 e 20 75 u 73 s 65 e 20 74 t 6F o 20 C) - 68 h 61 a 76 v 65 e 20 74 t 6F o 0D . 0A . 09 . 73 s 6C l 65 e 65 e 70 p 20 D) - 77 w 69 i 74 t 68 h 20 68 h 65 e 72 r 20 68 h 65 e 61 a 64 d 20 69 i 6E n E) - 20 61 a 20 73 s 61 a 66 f 65 e 2E . 20 20 53 S 68 h 65 e 20 64 d 69 i F) - 65 e 64 d 20 69 i 6E n 20 42 B 6F o 6C l 69 i 76 v 69 i 61 a 2E . 0D . 0A . G) - 44 D 6F o 6E n 3A : 09 . 4F O 68 h 20 42 B 69 i 6C l 6C l 2C , 20 69 i 74 t H) - 20 6D m 75 u 73 s 74 t 20 62 b 65 e 20 68 h 61 a 72 r 64 d 20 74 t 6F o I) - 20 6C l 6F o 73 s 65 e 20 61 a 20 72 r 65 e 6C l 61 a 74 t 69 i 76 v 65 e J) - 2E . 0D . 0A . 57 W 2E . 20 43 C 2E . 3A : 09 . 49 I 74 t 27 ' 73 s 20 61 a K) - 6C l 6D m 6F o 73 s 74 t 20 69 i 6D m 70 p 6F o 73 s 73 s 69 i 62 b 6C l 65 e L) - 2E . 0D . 0A . 09 . 09 . 2D - 2D - 20 57 W 2E . 20 43 C 2E . 20 46 F 69 i M) - 65 e 6C l 64 d 73 s 2C , 20 66 f 72 r 6F o 6D m 20 22 " 54 T 68 h 65 e 20 N) - 46 F 75 u 72 r 74 t 68 h 65 e 72 r 20 41 A 64 d 76 v 65 e 6E n 74 t 75 u 72 r O) - 65 e 73 s 20 6F o 66 f 20 4C L 61 a 72 r 73 s 6F o 6E n 0D . 0A . 09 . 09 . P) - 20 20 20 45 E 2E . 20 57 W 68 h 69 i 70 p 73 s 6E n 61 a 64 d 65 e 20 Q) - 61 a 6E n 64 d 20 6F o 74 t 68 h 65 e 72 r 20 54 T 61 a 72 r 72 r 61 a 64 d R) - 69 i 64 d 64 d 6C l 65 e 73 s 22 " 0D . 0A . 0D . 0A . .. . .. . .. . .. . .. .
In packet 50, fempto ACKnowledges packet 49 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 3D = 40 @ 00 . 40 @ 06 . D8 . 58 X AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 7B { A4 . 3) - 50 P 10 . 7D } 78 x 2B + 7F . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 2E . EF . E5 . 00 . 00 . 40 @ 06 . 32 2 AA . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { A4 . D3 . 9A . FE . F4 . 3) - 50 P 18 . 37 7 FF . 4F O FE . 00 . 00 . FF . FA . 21 ! 00 . FF . F0 . .. . .. . 1) - 45 E 10 . 00 . 28 ( 0A . 3E > 40 @ 00 . 40 @ 06 . D8 . 57 W AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 7B { AA . 3) - 50 P 10 . 7D } 78 x 2B + 79 y 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
At this point, my shell on the server (172.16.0.1) has started, and I am told this is the case when I see "bash" printed on my screen in this case.
nerds:~$
1) - 45 E 10 . 00 . 31 1 EF . E6 . 00 . 00 . 40 @ 06 . 32 2 A6 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { AA . D3 . 9A . FE . F4 . 3) - 50 P 18 . 37 7 FF . 7E ~ B8 . 00 . 00 . 6E n 65 e 72 r 64 d 73 s 3A : 7E ~ 24 $ 4) - 20 .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 54, fempto ACKnowledges packet 53 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 3F ? 40 @ 00 . 40 @ 06 . D8 . 56 V AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 7B { B3 . 3) - 50 P 10 . 7D } 78 x 2B + 70 p 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
At this point, in packet 55, I have instructed the remote shell on the server (172.16.0.1) to "ls -l /home" to list the contents of the home folder on my system. On the client machine (172.16.0.9)
nerds:~$ ls -l /home
1) - 45 E 10 . 00 . 33 3 0A . 40 @ 40 @ 00 . 40 @ 06 . D8 . 4A J AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . F4 . 5C \ 2C , 7B { B3 . 3) - 50 P 18 . 7D } 78 x 2E . C6 . 00 . 00 . 6C l 73 s 20 2D - 6C l 20 2F / 68 h 4) - 6F o 6D m 65 e .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 56, fempto ACKnowledges packet 55 from
nerds
1) - 45 E 10 . 00 . 28 ( EF . E7 . 00 . 00 . 40 @ 06 . 32 2 AE . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { B3 . D3 . 9A . FE . FF . 3) - 50 P 10 . 37 7 F4 . 70 p E9 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In this packet nerds is trying to echo back my command
(ls -l /home) to fempto. However, it was only able to send
the "l" of ls -l /home in this packet.
1) - 45 E 10 . 00 . 29 ) EF . E8 . 00 . 00 . 40 @ 06 . 32 2 AC . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { B3 . D3 . 9A . FE . FF . 3) - 50 P 18 . 37 7 FF . 04 . D5 . 00 . 00 . 6C l .. . .. . .. . .. . .. . .. . .. .
In packet 58, fempto ACKnowledges packet 57 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 41 A 40 @ 00 . 40 @ 06 . D8 . 54 T AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . FF . 5C \ 2C , 7B { B4 . 3) - 50 P 10 . 7D } 78 x 2B + 64 d 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In this packet, the rest of the command (ls -la /home) is transmitted (s -la /home).
1) - 45 E 10 . 00 . 32 2 EF . E9 . 00 . 00 . 40 @ 06 . 32 2 A2 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { B4 . D3 . 9A . FE . FF . 3) - 50 P 18 . 37 7 FF . DA . 3A : 00 . 00 . 73 s 20 2D - 6C l 20 2F / 68 h 6F o 4) - 6D m 65 e .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 60, fempto ACKnowledges packet 59 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 42 B 40 @ 00 . 40 @ 06 . D8 . 53 S AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . FF . 5C \ 2C , 7B { BE . 3) - 50 P 10 . 7D } 78 x 2B + 5A Z 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 61, fempto sends another CR/LF to
nerds
1) - 45 E 10 . 00 . 2A * 0A . 43 C 40 @ 00 . 40 @ 06 . D8 . 50 P AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FE . FF . 5C \ 2C , 7B { BE . 3) - 50 P 18 . 7D } 78 x 1E . 50 P 00 . 00 . 0D . 00 . .. . .. . .. . .. . .. . .. .
In packet 62, nerds ACKnowledges packet 61 from
fempto
1) - 45 E 10 . 00 . 28 ( EF . EA . 00 . 00 . 40 @ 06 . 32 2 AB . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { BE . D3 . 9A . FF . 01 . 3) - 50 P 10 . 37 7 FD . 70 p D3 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
nerds echoes back the CR/LF to fempto
1) - 45 E 10 . 00 . 2A * EF . EB . 00 . 00 . 40 @ 06 . 32 2 A8 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { BE . D3 . 9A . FF . 01 . 3) - 50 P 18 . 37 7 FF . 63 c BD . 00 . 00 . 0D . 0A . .. . .. . .. . .. . .. . .. .
In packet 64, fempto ACKnowledges packet 63 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 44 D 40 @ 00 . 40 @ 06 . D8 . 51 Q AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 01 . 5C \ 2C , 7B { C0 . 3) - 50 P 10 . 7D } 78 x 2B + 56 V 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 65 includes the first line response to my "ls -l /home" command issued previously:
total 24
1) - 45 E 10 . 00 . 32 2 EF . EC . 00 . 00 . 40 @ 06 . 32 2 9F . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { C0 . D3 . 9A . FF . 01 . 3) - 50 P 18 . 37 7 FF . DC . 8D . 00 . 00 . 74 t 6F o 74 t 61 a 6C l 20 32 2 34 4 4) - 0D . 0A . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 66, fempto ACKnowledges packet 65 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 45 E 40 @ 00 . 40 @ 06 . D8 . 50 P AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 01 . 5C \ 2C , 7B { CA . 3) - 50 P 10 . 7D } 78 x 2B + 4C L 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 67 includes the second line of output from 172.16.0.1 and the "ls -l /home" command I issued previously
drwxr-xr-x 28 dugan net 16384 Apr 5 12:23 dugan/
1) - 45 E 10 . 00 . 74 t EF . ED . 00 . 00 . 40 @ 06 . 32 2 5C \ AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7B { CA . D3 . 9A . FF . 01 . 3) - 50 P 18 . 37 7 FF . B4 . ED . 00 . 00 . 64 d 72 r 77 w 78 x 72 r 2D - 78 x 72 r 4) - 2D - 78 x 20 20 32 2 38 8 20 64 d 75 u 67 g 61 a 6E n 20 20 20 20 5) - 6E n 65 e 74 t 20 20 20 20 20 20 20 20 20 31 1 36 6 33 3 38 8 6) - 34 4 20 41 A 70 p 72 r 20 20 31 1 20 32 2 32 2 3A : 32 2 31 1 20 1B . 7) - 5B [ 30 0 31 1 3B ; 33 3 34 4 6D m 64 d 75 u 67 g 61 a 6E n 1B . 5B [ 30 0 30 0 8) - 6D m 2F / 0D . 0A . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 68, fempto ACKnowledges packet 67 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 46 F 40 @ 00 . 40 @ 06 . D8 . 4F O AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 01 . 5C \ 2C , 7C | 16 . 3) - 50 P 10 . 7D } 78 x 2B + 00 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
The "ls -l /home" command is still producing output from the server (172.16.0.1) and this is what is being sent to the telnet session on the client (172.16.0.9):
drwxr-xr-x 28 dugan net 16384 Apr 5 12:23 dugan/
drwxrwxr-x 8 ftp users 1024 May 18 1996 ftp/
drwxrwxrwx 2 root httpd 1024 Nov 7 05:20 httpd/
drwxr-xr-x 11 luvisi users 1024 Feb 4 00:18 luvisi/
drwxr-xr-x 3 mike users 1024 Apr 5 12:12 mike/
1) - 45 E 10 . 01 . 56 V EF . EE . 00 . 00 . 40 @ 06 . 31 1 79 y AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7C | 16 . D3 . 9A . FF . 01 . 3) - 50 P 18 . 37 7 FF . DE . 16 . 00 . 00 . 64 d 72 r 77 w 78 x 72 r 77 w 78 x 72 r 4) - 2D - 78 x 20 20 20 38 8 20 66 f 74 t 70 p 20 20 20 20 20 20 5) - 75 u 73 s 65 e 72 r 73 s 20 20 20 20 20 20 20 20 31 1 30 0 32 2 6) - 34 4 20 4D M 61 a 79 y 20 31 1 38 8 20 20 31 1 39 9 39 9 36 6 20 1B . 7) - 5B [ 30 0 31 1 3B ; 33 3 34 4 6D m 66 f 74 t 70 p 1B . 5B [ 30 0 30 0 6D m 2F / 8) - 0D . 0A . 64 d 72 r 77 w 78 x 72 r 77 w 78 x 72 r 77 w 78 x 20 20 20 32 2 9) - 20 72 r 6F o 6F o 74 t 20 20 20 20 20 68 h 74 t 74 t 70 p 64 d 20 A) - 20 20 20 20 20 20 20 31 1 30 0 32 2 34 4 20 4E N 6F o 76 v 20 B) - 20 37 7 20 30 0 35 5 3A : 32 2 30 0 20 1B . 5B [ 30 0 31 1 3B ; 33 3 34 4 C) - 6D m 68 h 74 t 74 t 70 p 64 d 1B . 5B [ 30 0 30 0 6D m 2F / 0D . 0A . 64 d 72 r D) - 77 w 78 x 72 r 2D - 78 x 72 r 2D - 78 x 20 20 31 1 31 1 20 6C l 75 u 76 v E) - 69 i 73 s 69 i 20 20 20 75 u 73 s 65 e 72 r 73 s 20 20 20 20 20 F) - 20 20 20 31 1 30 0 32 2 34 4 20 46 F 65 e 62 b 20 20 34 4 20 30 0 G) - 30 0 3A : 31 1 38 8 20 1B . 5B [ 30 0 31 1 3B ; 33 3 34 4 6D m 6C l 75 u 76 v H) - 69 i 73 s 69 i 1B . 5B [ 30 0 30 0 6D m 2F / 0D . 0A . 64 d 72 r 77 w 78 x 72 r I) - 2D - 78 x 72 r 2D - 78 x 20 20 20 32 2 20 6D m 69 i 6B k 65 e 20 20 J) - 20 20 20 75 u 73 s 65 e 72 r 73 s 20 20 20 20 20 20 20 20 K) - 31 1 30 0 32 2 34 4 20 41 A 70 p 72 r 20 20 31 1 20 32 2 32 2 3A : 33 3 L) - 38 8 20 1B . 5B [ 30 0 31 1 3B ; 33 3 34 4 6D m 6D m 69 i 6B k 65 e 1B . 5B [ M) - 30 0 30 0 6D m 2F / 0D . 0A . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 70, fempto ACKnowledges packet 69 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 47 G 40 @ 00 . 40 @ 06 . D8 . 4E N AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 01 . 5C \ 2C , 7D } 44 D 3) - 50 P 10 . 7D } 78 x 29 ) D2 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 71 finishes the output produced by the "ls -l /home" command issued previously. Also, appended to the end of this packet is the BASH prompt "nerds:~$ " as seen here, and on the client (172.16.0.9).
drwxr-xr-x 2 root users 1024 Nov 15 16:23 netboot/
drwxr-xr-x 4 public users 1024 Jan 4 1997 public/
drwxr-xr-x 2 root root 1024 Mar 17 00:08 si/
nerds:~$
1) - 45 E 10 . 01 . 15 . EF . EF . 00 . 00 . 40 @ 06 . 31 1 B9 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7D } 44 D D3 . 9A . FF . 01 . 3) - 50 P 18 . 37 7 FF . 91 . F4 . 00 . 00 . 64 d 72 r 77 w 78 x 72 r 2D - 78 x 72 r 4) - 2D - 78 x 20 20 20 32 2 20 72 r 6F o 6F o 74 t 20 20 20 20 20 5) - 75 u 73 s 65 e 72 r 73 s 20 20 20 20 20 20 20 20 31 1 30 0 32 2 6) - 34 4 20 4E N 6F o 76 v 20 31 1 35 5 20 31 1 36 6 3A : 32 2 33 3 20 1B . 7) - 5B [ 30 0 31 1 3B ; 33 3 34 4 6D m 6E n 65 e 74 t 62 b 6F o 6F o 74 t 1B . 5B [ 8) - 30 0 30 0 6D m 2F / 0D . 0A . 64 d 72 r 77 w 78 x 72 r 2D - 78 x 72 r 2D - 78 x 9) - 20 20 20 34 4 20 70 p 75 u 62 b 6C l 69 i 63 c 20 20 20 75 u 73 s A) - 65 e 72 r 73 s 20 20 20 20 20 20 20 20 31 1 30 0 32 2 34 4 20 B) - 4A J 61 a 6E n 20 20 34 4 20 20 31 1 39 9 39 9 37 7 20 1B . 5B [ 30 0 C) - 31 1 3B ; 33 3 34 4 6D m 70 p 75 u 62 b 6C l 69 i 63 c 1B . 5B [ 30 0 30 0 6D m D) - 2F / 0D . 0A . 64 d 72 r 77 w 78 x 72 r 2D - 78 x 72 r 2D - 78 x 20 20 20 E) - 32 2 20 72 r 6F o 6F o 74 t 20 20 20 20 20 72 r 6F o 6F o 74 t 20 F) - 20 20 20 20 20 20 20 20 31 1 30 0 32 2 34 4 20 4D M 61 a 72 r G) - 20 31 1 37 7 20 30 0 30 0 3A : 30 0 38 8 20 1B . 5B [ 30 0 31 1 3B ; 33 3 H) - 34 4 6D m 73 s 69 i 1B . 5B [ 30 0 30 0 6D m 2F / 0D . 0A . 6E n 65 e 72 r 64 d I) - 73 s 3A : 7E ~ 24 $ 20 .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 72, fempto ACKnowledges packet 71 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 48 H 40 @ 00 . 40 @ 06 . D8 . 4D M AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 01 . 5C \ 2C , 7E ~ 31 1 3) - 50 P 10 . 7D } 78 x 28 ( E5 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 73 includes another command being sent from the client (172.16.0.9) to the server (172.16.0.1) asking for an "exit" from the shell, and eventually to drop the telnet connection, and then the TCP/IP connection between the server (172.16.0.1) and the client (172.16.0.9).
I only type "exit" so that is all that is sent to the server through the network. However, what appears in my console, is:
nerds:~$ exit
where the "nerds:~$ " item was actually sent by the server to the client in packet 70.
1) - 45 E 10 . 00 . 2C , 0A . 49 I 40 @ 00 . 40 @ 06 . D8 . 48 H AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 01 . 5C \ 2C , 7E ~ 31 1 3) - 50 P 18 . 7D } 78 x 59 Y EC . 00 . 00 . 65 e 78 x 69 i 74 t .. . .. . .. . .. .
In packet 74, nerds ACKnowledges packet 73 from
fempto
1) - 45 E 10 . 00 . 28 ( EF . F0 . 00 . 00 . 40 @ 06 . 32 2 A5 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7E ~ 31 1 D3 . 9A . FF . 05 . 3) - 50 P 10 . 37 7 FB . 6E n 5E ^ 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Packet 75 is sending an "e" from the server (172.16.0.1) to the client (172.16.0.9). This is actually what is called an echo-response. The "exit" typed and transmitted from the client in packet 73, is being echoed back as it is typed. The "e" was chopped off of the word "exit" because the server was ready to send another TCP/IP packet, and had not processed the rest of the "exit" command. The "xit" portion of the "exit" command is echoed back to the client (172.16.0.9) from the server (172.16.0.1) in packet 77 as you will see below.
As you type your commands from a client to a server, in a telnet session, the client does not assume that all things typed on the client shell should be displayed on the client's screen. A good example of this is when the user is prompted for their password. The text they type into their session is not redisplayed back to them. This is done for security reasons. A users does not want to have a person looking over their should to have the opportunity to see the password on the screen. Other control characters do not need to be printed, but instead interpreted by the terminal display.
If the server did not echo back the word "exit" to my session as I typed it, I would find that I would not see the word "exit" on my screen. This is an example of what is called "typing blind." Most telnet sessions require a user to enter their password while "typing blind" but this is one of the rare examples of where it is helpful to offer this as a feature for security.
1) - 45 E 10 . 00 . 29 ) EF . F1 . 00 . 00 . 40 @ 06 . 32 2 A3 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7E ~ 31 1 D3 . 9A . FF . 05 . 3) - 50 P 18 . 37 7 FF . 09 . 51 Q 00 . 00 . 65 e .. . .. . .. . .. . .. . .. .
In packet 76, fempto ACKnowledges packet 75 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 4A J 40 @ 00 . 40 @ 06 . D8 . 4B K AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 05 . 5C \ 2C , 7E ~ 32 2 3) - 50 P 10 . 7D } 78 x 28 ( E0 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
Here is the other half of the command "exit" that is being echoed by the server back to the client. Since the "e" was transmitted in packet 75.
1) - 45 E 10 . 00 . 2B + EF . F2 . 00 . 00 . 40 @ 06 . 32 2 A0 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7E ~ 32 2 D3 . 9A . FF . 05 . 3) - 50 P 18 . 37 7 FF . 81 . E4 . 00 . 00 . 78 x 69 i 74 t .. . .. . .. . .. . .. .
In packet 78, fempto ACKnowledges packet 77 from
nerds
1) - 45 E 10 . 00 . 28 ( 0A . 4B K 40 @ 00 . 40 @ 06 . D8 . 4A J AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 05 . 5C \ 2C , 7E ~ 35 5 3) - 50 P 10 . 7D } 78 x 28 ( DD . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 79, a CR/LF is sent, to issue the exit command.
1) - 45 E 10 . 00 . 2A * 0A . 4C L 40 @ 00 . 40 @ 06 . D8 . 47 G AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 05 . 5C \ 2C , 7E ~ 35 5 3) - 50 P 18 . 7D } 78 x 1B . D3 . 00 . 00 . 0D . 00 . .. . .. . .. . .. . .. .
In packet 80, fempto ACKnowledges packet 79 from
nerds
1) - 45 E 10 . 00 . 28 ( EF . F3 . 00 . 00 . 40 @ 06 . 32 2 A2 . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7E ~ 35 5 D3 . 9A . FF . 07 . 3) - 50 P 10 . 37 7 FD . 6E n 56 V 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In packet 81, nerds echos back the CR/LF to
nerds
1) - 45 E 10 . 00 . 2A * EF . F4 . 00 . 00 . 40 @ 06 . 32 2 9F . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7E ~ 35 5 D3 . 9A . FF . 07 . 3) - 50 P 18 . 37 7 FF . 61 a 40 @ 00 . 00 . 0D . 0A . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 29 ) EF . F5 . 00 . 00 . 40 @ 06 . 32 2 9F . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7E ~ 37 7 D3 . 9A . FF . 07 . 3) - 50 P 18 . 37 7 FF . 02 . 49 I 00 . 00 . 6C l .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( EF . F6 . 00 . 00 . 40 @ 06 . 32 2 9F . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7E ~ 38 8 D3 . 9A . FF . 07 . 3) - 50 P 11 . 37 7 FF . 6E n 50 P 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( 0A . 4D M 40 @ 00 . 40 @ 06 . D8 . 48 H AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 07 . 5C \ 2C , 7E ~ 39 9 3) - 50 P 10 . 7D } 78 x 28 ( D7 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
In this packet fempto sets the FINish flag to end its side of the connection.
1) - 45 E 10 . 00 . 28 ( 0A . 4E N 00 . 00 . 40 @ 06 . 18 . 48 H AC . 10 . 00 . 09 . 2) - AC . 10 . 00 . 01 . 04 . 3B ; 00 . 17 . D3 . 9A . FF . 07 . 5C \ 2C , 7E ~ 39 9 3) - 50 P 11 . 7D } 78 x 28 ( D6 . 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. . 1) - 45 E 10 . 00 . 28 ( EF . F7 . 00 . 00 . 40 @ 06 . 32 2 9E . AC . 10 . 00 . 01 . 2) - AC . 10 . 00 . 09 . 00 . 17 . 04 . 3B ; 5C \ 2C , 7E ~ 39 9 D3 . 9A . FF . 08 . 3) - 50 P 10 . 37 7 FE . 6E n 50 P 00 . 00 . .. . .. . .. . .. . .. . .. . .. . .. .
When BASH on the server quits, and telnetd on the server closes the connection this session, and TCP/IP deals with the last packet that has the FINish flag set for the session, then my telnet client tells me what has happened:
Connection closed by foreign host.
This was a simple, sample telnet session. 86 packets were created, and so little was accomplished in this telnet session.
Both TCP and UDP can be used to send and receive data. Why should it matter which protocol is used? Other than simplicity, UDP has some advantages over TCP. However, there are some things that TCP is better suited for a a method for moving data. First of all, UDP is not a responsible service; it is unreliable. By unreliable, I do not mean that it is careless with its packets, and frequently ends up loosing them. Instead, I am saying that it does not make any attempt to fix errors it encounters in transmissions. UDP can determine if a UDP packet is the wrong length or does not have the proper checksum, but what does it do after that? In most cases, the UDP packet is just dropped, and goes away. TCP on the other hand uses sequence numbers and acknowledgements, and preset window sizes to control the flow of packets. If a TCP packet has an error, another one can be sent after the sender does not get an acknowledgement from the recipient in a pre-specified length of time as set by the sender. This helps TCP to make sure that all of the data being moved from one machine to another does make it even if some of the packets are lost in transit.
Imagine an office situation, where you have a boss dictating a note to her secretary over a speaker phone. Her secretary happens to spill a cup of coffee all over himself and walks away to get a towel without saying anything to his boss. With UDP, the boss would continue to speak, and not check to see if everything is going OK on the secretary's side. With TCP, after every few letters (or words, or sentences) said by the boss, the boss would also tell the secretary how many words were spoken, and give a checksum for that group of words. If the secretary was there, then he would verify the number of words spoken with the total that was spoken, and the checksum of the words that were spoken as calculated by the secretary was equal to the checksum of the words as calculated by the boss. If all of these things were correct, the secretary would say, "I received that last batch of words just fine." If the secretary was not there, then no response would be heard when the boss waited for his acknowledgment, "I received that last batch of words just fine" from his secretary. When the boss did hear that key phrase, "I received that last batch of words just fine", he would know that he could continue and the previous stream of letter words or sentences) arrived safely.
So when would you want to send data and not care if it all made it to its destination properly? Two very good examples of this are audio, and video transmissions. TCP will re-order packets as they come in so that the data arrives to the application layer unharmed. TCP may hold off on sending a chunk of data to the application layer until it is satisfied that all of the packets leading up to the data that needs to be handed to the application level are error-free. This would be a very poor thing to do with audio and video. If you get an error with audio or video, just drop the packet and keep going. The sound of the audio, or view of the video may appear to be a bit jittery, but if a packet is missing, the UDP layer won't wait for that packet to properly be transmitted before going on. TCP might wait a number of seconds, or in cases with very high latency, minutes to recover a single packet, when a whole collection of packets is ready to go to the application level.
TCP is very good with interactive sessions. If you were at a UNIX BASH prompt and you typed rm -rf ~/bin to remove the bin folder in your home directory, and you were logged in as "root" (the administrator), you would only want to remove the directory bin in *your* home directory. What would happen if this was UDP and the packet containing the "~" as dropped? Well, your system would proceed to delete the system's bin directory and destroy many system applications.
What other uses does UDP have over TCP? Next, you may look at the header length of UDP vs. TCP. UDP headers are 8 bytes, while TCP headers are a minimum of 20 bytes (and with TCP options even more.) The IP header is already 20 bytes long to begin with. If you wanted to move 25 bytes of data from one machine to another, and you used TCP/IP to do it, you would need to transmit 65 bytes just to get 25 bytes moved to their destination! If you sent that same 25 bytes with UDP/IP, you would only need 53 bytes to do this. As you decrease the size of the data. 61.5% of at TCP/IP packet used to move 25 bytes of data is overhead an maintenance for TCP and IP! 52.8% of the UDP/IP packet is over head. UDP can be more efficient over connections that use reliable medium.
It seems as though the use for UDP is limited if only video and audio can take advantage of the unreliable nature of the protocol. There is a saving quality for UDP (just like any other unreliable protocol.) If a higher level service can make the connection more reliable, then UDP can be used in other ways. The application would take on the responsibility of ensuring end-to-end reliability.
TCP helps to make the data delivered with an unreliable protocol (IP) reliable, while UDP is a simple way of adding only the information needed by a the transport layer to deliver IP data to an application.
If time and space permitted, I was going to compare the security of TCP over UDP. I see that I am running short on time, and this paper is much longer than I intended. However, I will hint at the problems that UDP has when compared to TCP. TCP uses sequence numbers to keep track of the packets being sent and acknowledgements for the packets being received. If a malicious user is not on my collision domain, then it would be difficult for them to quickly guess the sequence number presently being used by an arbitrary connection on an arbitrary machine. If they were on my collision domain, then they would need a packet sniffer to find my sequence numbers. Why would a user want to know a sequence number let alone *my* sequence number? Well, you can think of a telnet connection as a virtual wire from your machine to a remote site. If I knew what your sequence numbers were, I could route your session through my machine, or even kill your end of the session (send a properly configured TCP/IP packet to your machine with a FINish flag set, or a RESET while making the other machine unavailable with a denial of service attack and in the end continue where you left off. If you were root when I took over you session, I would have full access to your remote server.
There are other concerns on security when comparing TCP to UDP, but time does not permit me to elaborate.
Both TCP and UDP are interesting protocols. TCP is more complicated than UDP and has a greater overhead for transmitting small amounts of data, but has the advantage of being able to offer an error-free delivery of data to the application level programs. UDP has the advantage that less overhead is imposed on transmitting smaller amounts of data, but makes no guarantee on end-to-end delivery of data.
The security of TCP is greater than the security of UDP. One of the reasons for this is that TCP uses sequence numbers. This is security by obscurity or concealment and is not the most ideal method to use for implementing security.
TCP and UDP packets operate at the transport layer of the ISO/OSI seven layer model. IP operates at the networking layer of the ISO/OSI seven layer model. Since TCP and UDP operate at a higher level than IP, they are encapsulated with IP datagrams before being sent to lower levels of the ISO/OSI seven layer model.
The headers of TCP, UDP and IP all have a great deal of highly concentrated information about the data being transmitted in their respective packets. Not all of this information is used by an arbitrary packet at once. Sometimes certain values are mutually exclusive to each other. Some of the values in may the headers may appear meaningless, but in most cases, the values assigned to each location in the header are needed in order to properly deliver a packet.
Discussing the differences of TCP and UDP is more difficult than I anticipated. There are many more things about TCP that I did not cover. There are options that can be set after the TCP header, and before the data. Each of the flags in a TCP header can be explained i greater detail with samples to reference for each flag. A description of the sliding window that is used by the OS on each end to verify sequences of TCP packet have been received. Samples of improperly transmitted packets, and the retransmission of the bad packets could be shown. There are many other things that are associated with TCP that I could have discussed. There are several resources that exist to offer a person more interested in TCP, UDP and IP more information about these protocols, and in greater detail than I offered here in this paper. Please see the references in the references section for some examples.