Вы находитесь на странице: 1из 58

MGM’s College of Engineering Nanded -431605

Department of Computer science & engineering.

Lab Manual

For the subject TCP/IP


(Based on BE (CSE) Course)

Subject In-charge

Mrs. Joshi M.Y


Mr. Salve S.G

This manual is prepared as per the instruction provided by Swami Ramanand


Teerth Marathawada University Nanded-431605
Experiment No 1
Aim:- To study campus network (LAN/WAN).
Theory:- Student should study different networking devices like
1.Routers
2.Switches
3.Hubs
4.Repeaters
5.Bridges

Conclusion:- Hence we have studied existing campus LAN Structure.


Experiment No 2
Aim:- Connect two or three computers using wired media
Theory:-Study of LAN Cable and its color code.
The TX (transmitter) pins are connected to corresponding RX (receiver) pins, with plus to
plus and minus to minus. A cross-over cable must be used to connect units with identical
interfaces. When straight-through cables are used to connect Ethernet devices, one of the
two units must, in effect, perform the cross-over function. This is the reason that straight
through cables work directly between hubs or switches and NIC cards.... the Hub or
Switch is designed so that their RJ45 Jacks are pre-wired with the transmit and receive
pairs already reversed.
There are two colour-code standards in common use: EIA/TIA 568A and EIA/TIA 568B.
These standards derive from TELCO usage and the pairs shown correspond to four phone
lines, each with its own line pair. This same wiring was adopted for LAN standard
Ethernet RJ45 wiring as well. RJ45 receptacle wiring for both standards are shown
below:

EIA/TIA 568A EIA/TIA 568B


WIRING STANDARD WIRING STANDARD

PIN WIRE COLOUR PIN WIRE COLOUR


1 White w/Green Stripe 1 White w/Orange Stripe
2 Green w/White Stripe 2 Orange w/White Stripe
3 White w/Orange Stripe 3 White w/Green Stripe
4 Blue w/White Stripe 4 Blue w/White Stripe
5 White w/Blue Stripe 5 White w/Blue Stripe
6 Orange w/White Stripe 6 Green w/White Stripe
7 White w/Brown Stripe 7 White w/Brown Stripe
8 Brown w/White Stripe 8 Brown w/White Stripe
Straight-Through Wiring Using the 586A Standard

The flat wiring diagram, above, shows the 568A colour code standard as the wiring for
the PC side of the cable and the same 568A standard for the Hub, Switch or Router side
of things (assuming that the Hubs, Switches or Routers are wired internally to perform
the cross-over function). The illustration depicts the wiring arrangement before insertion
into an RJ45 connector prior to crimping.
Cross-Over Wiring Using the 568A to 586B Standards

The flat wiring illustration, above, shows cross-over cable wiring using the 568A colour
code standard as the wiring for the PC side of things and the 568B standard for wiring to
the other PC. Note that in both cases, all eight wires are shown but only four are actually
needed. Pins 4, 5, 7, and 8 and the blue and brown pairs are not used in either standard.
Contrary to common tech-lore and what you may have read elsewhere, these pins and
wires are not used or required to implement 100BASE-TX duplexing. In fact, they can be
used for other purposes such as a single line phones or even operating two separate
Ethernet channels, provided care is taken to assure that these wire pairs are isolated from
the other wires. In practice, making actual RJ45 Patch cables is not physically that
simple. The connection of the pairs to the pins in the RJ45 jack isn’t wire pair by wire
pair. Instead, the orange pair of wires is not adjacent and the blue pair is upside-down. If
fact...flattening out the cables in the correct order for insertion into the RJ45 jack before
crimping is by far the most complex part of the job of making twisted pair Ethernet patch
cables. One cannot use flat-untwisted telephone cable for a network cable that runs any
appreciable distance. One must use a pair of twisted wires to connect a set of transmitter
pins to their corresponding receiver pins. One cannot use a wire from one pair and
another wire from a different pair.
Experiment No 3
Aim:-Capturing and analyzing Ethernet frame using Wire shark packet
Sniffer.
Theory: - Let’s begin by capturing a set of Ethernet frames to study. Do the following
1. First, make sure your browser’s cache is empty. (To do this under Netscape 7.0,
select Edit->Preferences->Advanced->Cache and clear the memory and disk
cache. For Internet Explorer, select Tools->Internet Options->Delete Files
2. Start up the ethereal packet sniffer (Wire shark). Select Capture->start
3. Enter the following URL into your browser; for Ex.
http://gaia.cs.umass.edu/ethereal-labs/
4. Stop ethereal packet capture. First, find the packet numbers (the leftmost column
in the upper ethereal window) of the HTTP GET message that was sent from your
computer to gaia.cs.umass.edu, as well as the beginning of the HTTP response
message sent to your computer by gaia.cs.umass.edu. You should see a screen
that looks something like this (where packet 10 in the screen shot below contains
the HTTP GET message)
5. Since this lab is about Ethernet and ARP, we’re not interested in IP or higher-
layer protocols. So let’s change ethereal “listing of captured packets” window so
that it shows information only about protocols below IP. To have Ethereal do this,
select Analyze->Enabled Protocols. Then uncheck the IP box and select OK. You
should now see an Ethereal window that looks like the screen shot shown in
figure
Observations

1. What is the 48-bit Ethernet address of your computer?


2. What is the 48-bit destination address in the Ethernet frame? Is this the Ethernet
address of gaia.cs.umass.edu? (Hint: the answer is no).
3. Give the hexadecimal value for the two-byte Frame type field. What do the bit(s)
whose value is 1 mean within the flag field?
4. How many bytes from the very start of the Ethernet frame does the ASCII “G” in
“GET” appear in the Ethernet frame?
5. What is the hexadecimal value of the CRC field in this Ethernet frame?
Experiment No 4
Aim: To study the address resolution protocol (ARP)
Theory:-ARP Caching
Recall that the ARP protocol typically maintains a cache of IP-to-Ethernet address
Translation pairs on your computer. The arp command (in both MSDOS and Linux/Unix)
is used to view and manipulate the contents of this cache. Since the arp Command and
the ARP protocol have the same name, it’s understandably easy to confuse them. But
keep in mind that they are different - the arp command is used to view and manipulate the
ARP cache contents, while the ARP protocol defines the format and meaning of the
Messages sent and received, and define the actions taken on message transmission and
receipt.
Let’s take a look at the contents of the ARP cache on your computer:
• MS-DOS. The arp command is in c:\windows\system32, so type either “arp” or
“c:\windows\system32\arp” in the MS-DOS command line (without quotation
marks).
• Linux/Unix. The executable for the arp command can be in various places.
Popular locations are /sbin/arp (for linux) and /usr/etc/arp (for some Unix variants).
The arp command with no arguments will display the contents of the ARP cache on your
computer. Run the arp command.
1. Write down the contents of your computer’s ARP cache. What is the meaning of
each column value?
In order to observe your computer sending and receiving ARP messages, we’ll need to
clear the ARP cache, since otherwise your computer is likely to find a needed IP-Ethernet
address translation pair in its cache and consequently not need to send out an ARP
message.
• MS-DOS. The MS-DOS arp –d * command will clear your ARP cache. The –d flag
indicates a deletion operation, and the * is the wildcard that says to delete all table
entries.
• Linux/Unix. The arp –d * will clear your ARP cache. In order to run this command
you’ll need root privileges. If you don’t have root privileges and can’t run Ethereal on a
Windows machine, you can skip the trace collection part of this lab and just use the trace
discussed in footnote 1.
Observing ARP in action
Do the following2:
• Clear your ARP cache, as described above.
• Next, make sure your browser’s cache is empty. (To do this under Netscape 7.0,
Select Edit->Preferences->Advanced->Cache and clear the memory and disk cache.
For Internet Explorer, select Tools->Internet Options->Delete Files.)
• Start up the ethereal packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/ethereal-labs/ HTTP-ethereal-lab-file3.html
Your browser should again display the rather lengthy US Bill of Rights.
• Stop ethereal packet capture. Again, we’re not interested in IP or higher-layer
Protocols, so change Ethereal’s “listing of captured packets” window so that it shows
information only about protocols below IP. To have Ethereal do this, select
Analyze->Enabled Protocols. Then uncheck the IP box and select OK. You should
now see an Ethereal window that looks like:
In the example above, the first two frames in the trace contain ARP messages (as does the
6th message) the screen shot above corresponds to the trace referenced in footnote 1.
Answer the following questions:
2. What are the hexadecimal values for the source and destination addresses in the
Ethernet frame containing the ARP request message?
3. Give the hexadecimal value for the two-byte Ethernet Frame type field. What do the
bit(s) whose value is 1 mean within the flag field?
4. Download the ARP specification from ftp://ftp.rfc-editor.org/in-
notes/std/std37.txt. A readable, detailed discussion of ARP is also at
http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/arp.html.
a) How many bytes from the very beginning of the Ethernet frame does the
ARP opcode field begin?
b) What is the value of the opcode field within the ARP-payload part of the
Ethernet frame in which an ARP request is made?
c) Does the ARP message contain the IP address of the sender?
d) Where in the ARP request does the “question” appear – the Ethernet address of
the machine whose corresponding IP address is being queried?
5. Now find the ARP reply that was sent in response to the ARP request.
a) How many bytes from the very beginning of the Ethernet frame does the
ARP opcode field begin?
b) What is the value of the opcode field within the ARP-payload part of the
Ethernet frame in which an ARP response is made?
c) Where in the ARP message does the “answer” to the earlier ARP request appear –
the IP address of the machine having the Ethernet address whose
Corresponding IP address is being queried?
6. What are the hexadecimal values for the source and destination addresses in the
Ethernet frame containing the ARP reply message?
Experiment No 4
Aim: - Study of IP datagram using Wire shark.
Theory:-In this lab, we’ll investigate the IP protocol, focusing on the IP datagram.
We’ll do so by analyzing a trace of IP datagram’s sent and received by an execution of
the trace route program (the trace route program itself is explored in more detail in the
Ethereal ICMP lab).
We’ll investigate the various fields in the IP datagram, and study IP fragmentation in
detail.
1. Capturing packets from an execution of trace route
In order to generate a trace of IP datagram’s for this lab, we’ll use the trace route program
to send datagram’s of different sizes towards some destination, X. Recall that trace route
operates by first sending one or more datagram’s with the time-to-live (TTL) field in the
IP header set to 1; it then sends a series of one or more datagram’s towards the same
destination with a TTL value of 2; it then sends a series of datagram’s towards the same
destination with a TTL value of 3; and so on. Recall that a router must decrement the
TTL in each received datagram by 1 (actually, RFC 791 says that the router must
decrement the TTL by at least one). If the TTL reaches 0, the router returns an ICMP
message (type 11 – TTL-exceeded) to the sending host. As a result of this behavior, a
datagram with a TTL of 1 (sent by the host executing trace route) will cause the router
one hop away from the sender to send an ICMP TTL-exceeded message back to the
sender; the datagram sent with a TTL of 2 will cause the router two hops away to send an
ICMP message back to the sender; the datagram sent with a TTL of 3will cause the router
three hops away to send an ICMP message back to the sender; and so on. In this manner,
the host executing trace route can learn the identities of the routers between itself and
destination X by looking at the source IP addresses in the datagram’s containing the
ICMP TTL-exceeded messages.
We’ll want to run trace route and have it send datagram’s of various lengths.
• Windows. The tracert program (used for our ICMP Ethereal lab) provided with
Windows does not allow one to change the size of the ICMP echo request (Ping) message
sent by the tracert program. A nicer Windows trace route program is ping plotter,
available both in free version and shareware versions at http://www.pingplotter.com.
Download and install ping plotter, and test it out by performing a few trace routes to your
favorite sites. The size of the ICMP echo request message can be explicitly set in ping
plotter by selecting the menu item
Edit->Advanced Options->Packet Options and then filling in the Packet Size field. The
default packet size is 56 bytes. Once ping plotter has sent a series of packets with the
increasing TTL values, it restarts the sending process again with a TTL of 1, after waiting
Trace Interval amount of time. The value of Trace Interval and the number of intervals
can be explicitly set in ping plotter.
• Linux/Unix. With the UNIX trace route command, the size of the UDP datagram sent
towards the destination can be explicitly set by indicating the number of bytes in the
datagram; this value is entered in the trace route command line immediately after the
name or address of the destination. For example, to send trace route datagram’s of 2000
bytes towards gaia.cs.umass.edu, the command would be: %trace route gaia.cs.umass.edu
2000
Do the following:
• Start up Ethereal and begin packet capture (Capture->Start) and then press OK on the
Ethereal Packet Capture Options screen (we’ll not need to select any options here).
• If you are using a Windows platform, start up ping plotter and enter the name of a target
destination in the “Address to Trace Window.” Enter 3 in the “# of times to Trace” field,
so you don’t gather too much data. Select the menu item Edit- >Advanced Options-
>Packet Options and enter a value of 56 in the Packet Size field and then press OK. Then
press the Trace button. You should see a ping plotter window that looks something like
this:
Next, send a set of datagram’s with a longer length, by selecting Edit->Advanced
Options->Packet Options and enter a value of 2000 in the Packet Size field and then
press OK. Then press the Resume button.
Finally, send a set of datagram’s with a longer length, by selecting Edit- >Advanced
Options->Packet Options and enter a value of 3500 in the Packet Size field and then
press OK. Then press the Resume button. Stop ethereal tracing.
• If you are using a Unix platform, enter three trace route commands, one with a length of
56 bytes, one with a length of 2000 bytes, and one with a length of 3500 bytes. Stop
ethereal tracing.
2. A look at the captured trace
In your trace, you should be able to see the series of ICMP Echo Request (in the case of
Windows machine) or the UDP segment (in the case of UNIX) sent by your computer
and the ICMP TTL-exceeded messages returned to your computer by the intermediate
routers. In the questions below, we’ll assume you are using a Windows machine; the
corresponding questions for the case of a UNIX machine should be clear. Whenever
possible, when answering a question you should hand in a printout of the packet(s) within
the trace that you used to answer the question asked. Annotate the printout to explain
your answer. To print a packet, use File->Print, choose selected packet only, choose
Packet summary line, and select the minimum amount of packet detail that you need to
answer the question.
1. Select the first ICMP Echo Request message sent by your computer, and expand the
Internet Protocol part of the packet in the packet details window

What is the IP address of your computer?


2. Within the IP packet header, what is the value in the upper layer protocol field?
3. How many bytes are in the IP header? How many bytes are in the payload of the IP
datagram? Explain how you determined the number of payload bytes.
4. Has this IP datagram been fragmented? Explain how you determined whether or not
the datagram has been fragmented
Next, sort the traced packets according to IP source address by clicking on the Source
column header; a small downward pointing arrow should appear next to the word Source.
If the arrow points up, click on the Source column header again. Select the first ICMP
Echo Request message sent by your computer, and expand the Internet Protocol portion
in the “details of selected packet header” window. In the “listing of captured packets”
window, you should see all of the subsequent ICMP messages (perhaps with additional
interspersed packets sent my other protocols running on your computer) below this first
ICMP. Use the down arrow to move through the ICMP messages sent by your computer.
5. Which fields in the IP datagram always change from one datagram to the next within
this series of ICMP messages sent by your computer?
6. Which fields stay constant? Which of the fields must stay constant? Which fields must
change? Why?
7. Describe the pattern you see in the values in the Identification field of the IP datagram
Next (with the packets still sorted by source address) find the series of ICMP TTL
exceeded replies sent to your computer by the nearest (first hop) router.
8. What is the value in the Identification field and the TTL field?
9. Do these values remain unchanged for all of the ICMP TTL-exceeded replies sent to
your computer by the nearest (first hop) router? Why?
Fragmentation
Sort the packet listing according to time again by clicking on the Time column.
10. Find the first ICMP Echo Request message that was sent by your computer after you
changed the Packet Size in ping plotter to be 2000. Has that message been fragmented
across more than one IP datagram? [Note: if you find your packet has not been
fragmented, you should download the zip file http://gaia.cs.umass.edu/ethereal-
labs/ethereal-traces.zip and extract the ip ethereal- trace-1packet trace. If your computer
has an Ethernet interface, a packet size of 2000 should cause fragmentation.3]
11. Print out the first fragment of the fragmented IP datagram. What information in the IP
header indicates that the datagram been fragmented? What information in the IP header
indicates whether this is the first fragment versus a latter fragment? How long is this IP
datagram?
12. Print out the second fragment of the fragmented IP datagram. What information in the
IP header indicates that this is not the first datagram fragment? Are the more fragments?
How can you tell?
13. What fields change in the IP header between the first and second fragment?
Now find the first ICMP Echo Request message that was sent by your computer after you
changed the Packet Size in ping plotter to be 3500.
14. How many fragments were created from the original datagram?
15. What fields change in the IP header among the fragments?
Experiment No 5
Aim: - Study of TCP/UDP using Wire shark.
Theory: - In this lab, we’ll investigate the behavior of TCP in detail. We’ll do so by
analyzing a trace of the TCP segments sent and received in transferring a 150KB file
(containing the text of Lewis Carroll’s Alice’s Adventures in Wonderland) from your
computer to a remote server. We’ll study TCP’s use of sequence and acknowledgement
numbers for providing reliable data transfer; we’ll see TCP’s congestion control
algorithm – slow start and congestion avoidance – in action; and we’ll look at TCP’s
receiver-advertised flow control mechanism. We’ll also briefly consider TCP connection
setup and we’ll investigate the performance (throughput and round-trip time) of the TCP
connection between your computer and the server.
1. Capturing a bulk TCP transfer from your computer to a remote server
Before beginning our exploration of TCP, we’ll need to use Ethereal to obtain a packet
trace of the TCP transfer of a file from your computer to a remote server. You’ll do so by
accessing a Web page that will allow you to enter the name of a file stored on your
computer (which contains the ASCII text of Alice in Wonderland), and then transfer the
file to a Web server using the HTTP POST method (see section 2.2.3 in the text). We’re
using the POST method rather than the GET method as we’d like to transfer a large
amount of data from your computer to another computer. Of course, we’ll be running
Ethereal during this time to obtain the trace of the TCP segments sent and received from
your computer.
Do the following:
• Start up your web browser. Go the http://gaia.cs.umass.edu/ethereal-labs/alice.txt and
retrieve an ASCII copy of Alice in Wonderland. Store this file somewhere on your
computer.
• Next go to http://gaia.cs.umass.edu/ethereal-labs/TCP-ethereal-file1.html.
• You should see a screen that looks like:
• Use the Browse button in this form to enter the name of the file (full path name) on your
computer containing Alice in Wonderland (or do so manually). Don’t yet press the
“Upload alice.txt file” button.
• Now start up Ethereal and begin packet capture (Capture->Start) and then press
OK on the Ethereal Packet Capture Options screen (we’ll not need to select any options
here).
• Returning to your browser, press the “Upload alice.txt file” button to upload the file to
the gaia.cs.umass.edu server. Once the file has been uploaded, a short congratulations
message will be displayed in your browser window.
• Stop ethereal packet capture. Your ethereal window should look similar to the window
shown below.
If you are unable to run Ethereal on a live network connection, you can download a
packet trace file that was captured while following the steps above on one of the author’s
computers2. You may well find it valuable to download this trace even if you’ve captured
your own trace and use it, as well as your own trace, when you explore the questions
below.
2. A first look at the captured trace
Before analyzing the behavior of the TCP connection in detail, let’s take a high level
view of the trace.
• First, filter the packets displayed in the ethereal window by entering “tcp” (lowercase,
no quotes, and don’t forget to press return after entering!) into the display filter
specification window towards the top of the Ethereal window.
What you should see is series of TCP and HTTP messages between your computer and
gaia.cs.umass.edu. You should see the initial three-way handshake containing a SYN
message. You should see an HTTP POST message and a series of “HTTP Continuation”
messages being sent from your computer to gaia.cs.umass.edu. Recall from our
discussion in the earlier HTTP Ethereal lab, that is no such thing as an HTTP
Continuation message – this is Ethereal’s way of indicating that there are multiple TCP
segments being used to carry a single HTTP message. You should also see TCP ACK
segments being returned from gaia.cs.umass.edu to your computer.
Answer the following questions, by opening the Ethereal captured packet file tcp
ethereal trace-1 in http://gaia.cs.umass.edu/ethereal-labs/ethereal-traces.zip (that is
download the trace and open that trace in Ethereal; see footnote 2). Whenever possible,
when answering a question you should hand in a printout of the packet(s) within the trace
that you used to answer the question asked. Annotate the printout to explain your answer.
To print a packet, use File->Print, choose selected packet only, choose Packet summary
line, and select the minimum amount of packet detail that you need to answer the
question.
1. What is the IP address and TCP port number used by the client computer (source) that
is transferring the file to gaia.cs.umass.edu? To answer this question, it’s probably easiest
to select an HTTP message and explore the details of the TCP packet used to carry this
HTTP message, using the “details of the selected packet header window” (refer to Figure
2 in the “Getting Started with Ethereal” Lab if you’re uncertain about the Ethereal
windows.
2. What is the IP address of gaia.cs.umass.edu? On what port number is it sending and
receiving TCP segments for this connection?
If you have been able to create your own trace, answer the following question:
3. What is the IP address and TCP port number used by your client computer (source) to
transfer the file to gaia.cs.umass.edu?
Since this lab is about TCP rather than HTTP, let’s change Ethereal’s “listing of captured
packets” window so that it shows information about the TCP segments containing the
HTTP messages, rather than about the HTTP messages. To have Ethereal do this, select
Analyze->Enabled Protocols. Then uncheck the HTTP box and select OK. You should
now see an ethereal window that looks like:
This is what we’re looking for - a series of TCP segments sent between your computer
and gaia.cs.umass.edu. We will use the packet trace that you have captured (and/or the
packet trace tcp-ethereal-trace-1 in http://gaia.cs.umass.edu/ethereal-labs/etherealtraces.
zip; see footnote 2) to study TCP behavior in the rest of this lab.

3. TCP Basics
Answer the following questions for the TCP segments:
4. What is the sequence number of the TCP SYN segment that is used to initiate the TCP
connection between the client computer and gaia.cs.umass.edu? What is it in the segment
that identifies the segment as a SYN segment?
5. What is the sequence number of the SYNACK segment sent by gaia.cs.umass.edu to
the client computer in reply to the SYN? What is the value of the ACKnowledgement
field in the SYNACK segment? How did gaia.cs.umass.edu determine that value? What
is it in the segment that identifies the segment as a SYNACK segment?
6. What is the sequence number of the TCP segment containing the HTTP POST
command? Note that in order to find the POST command, you’ll need to dig into the
packet content field at the bottom of the Ethereal window, looking for a segment with a
“POST” within its DATA field.
7. Consider the TCP segment containing the HTTP POST as the first segment in the TCP
connection. What are the sequence numbers of the first six segments in the TCP
connection (including the segment containing the HTTP POST)? At what time was each
segment sent? When was the ACK for each segment received?
Given the difference between when each TCP segment was sent, and when its
acknowledgement was received, what is the RTT value for each of the six segments?
What is the Estimated RTT value (see page 237 in text) after the receipt of each ACK?
Assume that the value of the Estimated RTT is equal to the measured RTT for the first
segment, and then is computed using the Estimated RTT equation on page 237 for all
subsequent segments.
Note: Ethereal has a nice feature that allows you to plot the RTT for each of the TCP
segments sent. Select a TCP segment in the “listing of captured packets” window that is
being sent from the client to the gaia.cs.umass.edu server. Then select: Statistics->TCP
Stream Graph-
>Round Trip Time Graph.
8. What is the length of each of the first six TCP segments?
9. What is the minimum amount of available buffer space advertised at the received for
the entire trace? Does the lack of receiver buffer space ever throttle the sender?
10. Are there any retransmitted segments in the trace file? What did you check for (in the
trace) in order to answer this question?
11. How much data does the receiver typically acknowledge in an ACK? Can you
identify cases where the receiver is ACKing every other received segment
12. What is the throughput (bytes transferred per unit time) for the TCP connection?
Explain how you calculated this value.
4. TCP congestion control in action
Let’s now examine the amount of data sent per unit time from the client to the server.
Rather than (tediously!) calculating this from the raw data in the ethereal window, we’ll
use one of Ethereal’s TCP graphing utilities - Time-Sequence-Graph (Stevens) - to plot
out data.
• Select a TCP segment in the Ethereal’s “listing of captured-packets” window.
Then select the menu: Statistics->TCP Stream Graph-> Time-Sequence- Graph
(Stevens). You should see a plot that looks similar to the following plot, which was
created from the captured packets in the packet trace tcp-ethereal- 3 the race-1 in
http://gaia.cs.umass.edu/ethereal-labs/ethereal-traces.zip (see footnote 2):
Here, each dot represents a TCP segment sent, plotting the sequence number of the
segment versus the time at which it was sent. Note that a set of dots stacked above each
other represents a series of packets that were sent back-to-back by the sender.
Answer the following questions for the TCP segments the packet trace tcp-ethereal trace
1 in http://gaia.cs.umass.edu/ethereal-labs/ethereal-traces.zip
13. Use the Time-Sequence-Graph (Stevens) plotting tool to view the sequence number
versus time plot of segments being sent from the client to the gaia.cs.umass.edu server.
Can you identify where TCP’s slow start phase begins and ends, and where congestion
avoidance takes over? Note that in this “real world” trace, not everything is quite as neat
and clean as in Figure 3.51 (also note that the y-axis labels for the Time-Sequence-
Graph(Stevens) plotting tool and
Figure 3.51 are different).
14. Comment on ways in which the measured data differs from the idealized behavior of
TCP that we’ve studied in the text.
15. Answer each of two questions above for the trace that you have gathered when you
transferred
Here, each dot represents a TCP segment sent, plotting the sequence number of
the segment versus the time at which it was sent. Note that a set of dots stacked
above each other represents a series of packets that were sent back-to-back by the
sender.
Answer the following questions for the TCP segments the packet trace tcp-etherealtrace-
1 in http://gaia.cs.umass.edu/ethereal-labs/ethereal-traces.zip
13. Use the Time-Sequence-Graph(Stevens) plotting tool to view the sequence
number versus time plot of segments being sent from the client to the
gaia.cs.umass.edu server. Can you identify where TCP’s slowstart phase begins
and ends, and where congestion avoidance takes over? Note that in this “realworld”
trace, not everything is quite as neat and clean as in Figure 3.51 (also note
that the y-axis labels for the Time-Sequence-Graph(Stevens) plotting tool and
Figure 3.51 are different).
14. Comment on ways in which the measured data differs from the idealized behavior
of TCP that we’ve studied in the text.
15. Answer each of two questions above for the trace that you have gathered when
you transferred a file from your computer to gaia.cs.umass.edu
Experiment No 5
Aim:- To study Ping, IPconfig utility.
Theory: - Ping
Verifies IP-level connectivity to another TCP/IP computer by sending Internet Control
Message Protocol (ICMP) Echo Request messages. The receipt of corresponding Echo
Reply messages are displayed, along with round-trip times. Ping is the primary TCP/IP
command used to troubleshoot connectivity, reach ability, and name resolution. Used
without parameters, ping displays help.

Syntax
Ping [-t] [-a] [-nCount] [-l Size] [-f] [-iTTL] [-vTOS] [-rCount] [-sCount] [{-jHostList |
-k HostList}] [-wTimeout] [-R] [-SSrcAddr] [-4] [-6] TargetName

Parameters
-t
Specifies that ping continue sending Echo Request messages to the destination
until interrupted. To interrupt and display statistics, press CTRL+BREAK. To
interrupt and quit ping, press CTRL+C.
-a
Specifies that reverse name resolution is performed on the destination IP address.
If this is successful, ping displays the corresponding host name.
-n Count
Specifies the number of Echo Request messages sent. The default is 4.
-l Size
Specifies the length, in bytes, of the Data field in the Echo Request messages sent.
The default is 32. The maximum Size is 65,527.
-f
Specifies that Echo Request messages are sent with the Don't Fragment flag in the
IP header set to 1 (available on IPv4 only). The Echo Request message cannot be
fragmented by routers in the path to the destination. This parameter is useful for
troubleshooting path Maximum Transmission Unit (PMTU) problems.
-i TTL
Specifies the value of the TTL field in the IP header for Echo Request messages
sent. The default is the default TTL value for the host. The maximum TTL is 255.
-v TOS
Specifies the value of the Type of Service (TOS) field in the IP header for Echo
Request messages sent (available on IPv4 only). The default is 0. TOS is specified
as a decimal value from 0 through 255.
-r Count
Specifies that the Record Route option in the IP header is used to record the path
taken by the Echo Request message and corresponding Echo Reply message
(available on IPv4 only). Each hop in the path uses an entry in the Record Route
option. If possible, specify a Count that is equal to or greater than the number of
hops between the source and destination. The Count must be a minimum of 1 and
a maximum of 9.
-s Count
Specifies that the Internet Timestamp option in the IP header is used to record the
time of arrival for the Echo Request message and corresponding Echo Reply
message for each hop. The Count must be a minimum of 1 and a maximum of 4.
This is required for link-local destination addresses.
-j HostList
Specifies that the Echo Request messages use the Loose Source Route option in
the IP header with the set of intermediate destinations specified in HostList
(available on IPv4 only). With loose source routing, successive intermediate
destinations can be separated by one or multiple routers. The maximum number
of addresses or names in the host list is 9. The host list is a series of IP addresses
(in dotted decimal notation) separated by spaces.
-k HostList
Specifies that the Echo Request messages use the Strict Source Route option in
the IP header with the set of intermediate destinations specified in HostList
(available on IPv4 only). With strict source routing, the next intermediate
destination must be directly reachable (it must be a neighbor on an interface of the
router). The maximum number of addresses or names in the host list is 9. The host
list is a series of IP addresses (in dotted decimal notation) separated by spaces.
-w Timeout
Specifies the amount of time, in milliseconds, to wait for the Echo Reply message
that corresponds to a given Echo Request message to be received. If the Echo
Reply message is not received within the time-out, the "Request timed out" error
message is displayed. The default time-out is 4000 (4 seconds).
-R
Specifies that the round-trip path is traced (available on IPv6 only).
-S SrcAddr
Specifies the source address to use (available on IPv6 only).
-4
Specifies that IPv4 is used to ping. This parameter is not required to identify the
target host with an IPv4 address. It is only required to identify the target host by
name.
-6
Specifies that IPv6 is used to ping. This parameter is not required to identify the
target host with an IPv6 address. It is only required to identify the target host by
name.
TargetName
Specifies the host name or IP address of the destination.
/?
Displays help at the command prompt.
Remarks

• You can use ping to test both the computer name and the IP address of the
computer. If pinging the IP address is successful, but pinging the computer name
is not, you might have a name resolution problem. In this case, ensure that the
computer name you are specifying can be resolved through the local Hosts file, by
using Domain Name System (DNS) queries, or through NetBIOS name resolution
techniques.
• This command is available only if the Internet Protocol (TCP/IP) protocol is
installed as a component in the properties of a network adapter in Network
Connections.

Examples
The following example shows ping command output:

C:\>ping example.microsoft.com

Pinging example.microsoft.com [192.168.239.132] with 32 bytes of data:

Reply from 192.168.239.132: bytes=32 time=101ms TTL=124

Reply from 192.168.239.132: bytes=32 time=100ms TTL=124

Reply from 192.168.239.132: bytes=32 time=120ms TTL=124

Reply from 192.168.239.132: bytes=32 time=120ms TTL=124

To ping the destination 10.0.99.221 and resolve 10.0.99.221 to its host name, type:

ping -a 10.0.99.221

To ping the destination 10.0.99.221 with 10 Echo Request messages, each of which has a
Data field of 1000 bytes, type:

ping -n 10 -l 1000 10.0.99.221

To ping the destination 10.0.99.221 and record the route for 4 hops, type:

ping -r 4 10.0.99.221

To ping the destination 10.0.99.221 and specify the loose source route of 10.12.0.1-
10.29.3.1-10.1.44.1, type:

ping -j 10.12.0.1 10.29.3.1 10.1.44.1 10.0.99.221

Formatting legend

Format Meaning

Italic Information that the user must supply


Bold Elements that the user must type exactly
as shown
Ellipsis (...) Parameter that can be repeated several
times in a command line
Between brackets ([]) Optional items
Between braces ({}); choices separated by Set of choices from which the user must
pipe (|). Example: {even|odd} choose only one
Courier font Code or program output

Ipconfig

Displays all current TCP/IP network configuration values and refreshes Dynamic Host
Configuration Protocol (DHCP) and Domain Name System (DNS) settings. Used without
parameters, ipconfig displays IPv6 addresses or the IPv4 address, subnet mask, and
default gateway for all adapters.

Syntax
ipconfig [/all] [/renew[Adapter]] [/release [Adapter]] [/flushdns] [/displaydns]
[/registerdns] [/showclassidAdapter] [/setclassidAdapter [ClassID]]

Parameters
/all
Displays the full TCP/IP configuration for all adapters. Without this parameter,
ipconfig displays only IPv6 addresses or the IPv4 address, subnet mask, and
default gateway values for each adapter. Adapters can represent physical
interfaces, such as installed network adapters, or logical interfaces, such as dial-up
connections.
/renew[ Adapter]
Renews DHCP configuration for all adapters (if an adapter is not specified) or for
a specific adapter if the Adapter parameter is included. This parameter is available
only on computers with adapters that are configured to obtain an IP address
automatically. To specify an adapter name, type the adapter name that appears
when you use ipconfig without parameters.
/release[ Adapter]
Sends a DHCPRELEASE message to the DHCP server to release the current
DHCP configuration and discard the IP address configuration for either all
adapters (if an adapter is not specified) or for a specific adapter if the Adapter
parameter is included. This parameter disables TCP/IP for adapters configured to
obtain an IP address automatically. To specify an adapter name, type the adapter
name that appears when you use ipconfig without parameters.
/flushdns
Flushes and resets the contents of the DNS client resolver cache. During DNS
troubleshooting, you can use this procedure to discard negative cache entries from
the cache, as well as any other entries that have been added dynamically.
/displaydns
Displays the contents of the DNS client resolver cache, which includes both
entries preloaded from the local Hosts file and any recently obtained resource
records for name queries resolved by the computer. The DNS Client service uses
this information to resolve frequently queried names quickly, before querying its
configured DNS servers.
/registerdns
Initiates manual dynamic registration for the DNS names and IP addresses that are
configured at a computer. You can use this parameter to troubleshoot a failed
DNS name registration or resolve a dynamic update problem between a client and
the DNS server without rebooting the client computer. The DNS settings in the
advanced properties of the TCP/IP protocol determine which names are registered
in DNS.
/showclassid Adapter
Displays the DHCP class ID for a specified adapter. To see the DHCP class ID for
all adapters, use the asterisk (*) wildcard character in place of Adapter. This
parameter is available only on computers with adapters that are configured to
obtain an IP address automatically.

/setclassid Adapter[ ClassID]


Configures the DHCP class ID for a specified adapter. To set the DHCP class ID
for all adapters, use the asterisk (*) wildcard character in place of Adapter. This
parameter is available only on computers with adapters that are configured to
obtain an IP address automatically. If a DHCP class ID is not specified, the
current class ID is removed.
/?
Displays help at the command prompt.
Remarks

• The ipconfig command is the command-line equivalent to the winipcfg


command, which is available in Windows Millinnium Edition, Windows 98, and
Windows 95. Although Windows XP and the Windows Server 2003 family do not
include a graphical equivalent to the winipcfg command, you can use Network
Connections to view and renew an IP address. To do this, open Network
Connections, right-click a network connection, click Status, and then click the
Support tab.
• This command is most useful on computers that are configured to obtain an IP
address automatically. This enables users to determine which TCP/IP
configuration values have been configured by DHCP, Automatic Private IP
Addressing (APIPA), or an alternate configuration.
• If the Adapter name contains any spaces, use quotation marks around the adapter
name (that is, "Adapter Name").
• For adapter names, ipconfig supports the use of the asterisk (*) wildcard character
to specify either adapters with names that begin with a specified string or adapters
with names that contain a specified string. For example, Local* matches all
adapters that start with the string Local and *Con* matches all adapters that
contain the string Con.
• This command is available only if the Internet Protocol (TCP/IP) protocol is
installed as a component in the properties of a network adapter in Network
Connections.
Examples
To display the basic TCP/IP configuration for all adapters, type:

ipconfig

To display the full TCP/IP configuration for all adapters, type:

ipconfig /all

To renew a DHCP-assigned IP address configuration for only the Local Area


Connection adapter, type:

ipconfig /renew "Local Area Connection"

To flush the DNS resolver cache when troubleshooting DNS name resolution problems,
type:

ipconfig /flushdns

To display the DHCP class ID for all adapters with names that start with Local, type:

ipconfig /showclassid Local*

To set the DHCP class ID for the Local Area Connection adapter to TEST, type:

ipconfig /setclassid "Local Area Connection" TEST

Formatting legend

Format Meaning

Italic Information that the user must supply


Bold Elements that the user must type exactly
as shown
Ellipsis (...) Parameter that can be repeated several
times in a command line
Between brackets ([]) Optional items
Between braces ({}); choices separated by Set of choices from which the user must
pipe (|). Example: {even|odd} choose only one
Courier font Code or program output
Experiment No 6
Aim:-To study Trace root, Net stat utility.
Theory: - Tracert
Determines the path taken to a destination by sending Internet Control Message Protocol
(ICMP) Echo Request or ICMPv6 messages to the destination with incrementally
increasing Time to Live (TTL) field values. The path displayed is the list of near-side
router interfaces of the routers in the path between a source host and a destination. The
near-side interface is the interface of the router that is closest to the sending host in the
path. Used without parameters, tracert displays help.

Syntax
tracert [-d] [-hMaximumHops] [-jHostList] [-wTimeout] [-R] [-SSrcAddr] [-4][-6]
TargetName

Parameters
-d
Prevents tracert from attempting to resolve the IP addresses of intermediate
routers to their names. This can speed up the display of tracert results.
-h MaximumHops
Specifies the maximum number of hops in the path to search for the target
(destination). The default is 30 hops.
-j HostList
Specifies that Echo Request messages use the Loose Source Route option in the
IP header with the set of intermediate destinations specified in Host List. With
loose source routing, successive intermediate destinations can be separated by one
or multiple routers. The maximum number of addresses or names in the host list is
9. The HostList is a series of IP addresses (in dotted decimal notation) separated
by spaces. Use this parameter only when tracing IPv4 addresses.
-w Timeout
Specifies the amount of time in milliseconds to wait for the ICMP Time Exceeded
or Echo Reply message corresponding to a given Echo Request message to be
received. If not received within the time-out, an asterisk (*) is displayed. The
default time-out is 4000 (4 seconds).
-R
Specifies that the IPv6 Routing extension header be used to send an Echo Request
message to the local host, using the destination as an intermediate destination and
testing the reverse route.
-S
Specifies the source address to use in the Echo Request messages. Use this
parameter only when tracing IPv6 addresses.
-4
Specifies that Tracert.exe can use only IPv4 for this trace.
-6
Specifies that Tracert.exe can use only IPv6 for this trace.
TargetName
Specifies the destination, identified either by IP address or host name.
-?
Displays help at the command prompt.
Remarks

• This diagnostic tool determines the path taken to a destination by sending ICMP
Echo Request messages with varying Time to Live (TTL) values to the
destination. Each router along the path is required to decrement the TTL in an IP
packet by at least 1 before forwarding it. Effectively, the TTL is a maximum link
counter. When the TTL on a packet reaches 0, the router is expected to return an
ICMP Time Exceeded message to the source computer. Tracert determines the
path by sending the first Echo Request message with a TTL of 1 and incrementing
the TTL by 1 on each subsequent transmission until the target responds or the
maximum number of hops is reached. The maximum number of hops is 30 by
default and can be specified using the -h parameter. The path is determined by
examining the ICMP Time Exceeded messages returned by intermediate routers
and the Echo Reply message returned by the destination. However, some routers
do not return Time Exceeded messages for packets with expired TTL values and
are invisible to the tracert command. In this case, a row of asterisks (*) is
displayed for that hop.
• To trace a path and provide network latency and packet loss for each router and
link in the path, use the path ping command.
• This command is available only if the Internet Protocol (TCP/IP) protocol is
installed as a component in the properties of a network adapter in Network
Connections.

Examples
To trace the path to the host named corp7.microsoft.com, type:

tracert corp7.microsoft.com

To trace the path to the host named corp7.microsoft.com and prevent the resolution of
each IP address to its name, type:

tracert -d corp7.microsoft.com

To trace the path to the host named corp7.microsoft.com and use the loose source route
10.12.0.1-10.29.3.1-10.1.44.1, type:

tracert -j 10.12.0.1 10.29.3.1 10.1.44.1 corp7.microsoft.com

Formatting legend

Format Meaning

Italic Information that the user must supply


Bold Elements that the user must type exactly
as shown
Ellipsis (...) Parameter that can be repeated several
times in a command line
Between brackets ([]) Optional items
Between braces ({}); choices separated by Set of choices from which the user must
pipe (|). Example: {even|odd} choose only one
Courier font Code or program output

Net stat

Displays active TCP connections, ports on which the computer is listening, Ethernet
statistics, the IP routing table, IPv4 statistics (for the IP, ICMP, TCP, and UDP
protocols), and IPv6 statistics (for the IPv6, ICMPv6, TCP over IPv6, and UDP over IPv6
protocols). Used without parameters, net stat displays active TCP connections.

Syntax
Net stat [-a] [-e] [-n] [-o] [-pProtocol] [-r] [-s] [Interval]

Parameters
-a
Displays all active TCP connections and the TCP and UDP ports on which the
computer is listening.
-e
Displays Ethernet statistics, such as the number of bytes and packets sent and
received. This parameter can be combined with -s.
-n
Displays active TCP connections, however, addresses and port numbers are
expressed numerically and no attempt is made to determine names.
-o
Displays active TCP connections and includes the process ID (PID) for each
connection. You can find the application based on the PID on the Processes tab in
Windows Task Manager. This parameter can be combined with -a, -n, and -p.
-p Protocol
Shows connections for the protocol specified by Protocol. In this case, the
Protocol can be tcp, udp, tcpv6, or udpv6. If this parameter is used with -s to
display statistics by protocol, Protocol can be tcp, udp, icmp, ip, tcpv6, udpv6,
icmpv6, or ipv6.
-s
Displays statistics by protocol. By default, statistics are shown for the TCP, UDP,
ICMP, and IP protocols. If the IPv6 protocol is installed, statistics are shown for
the TCP over IPv6, UDP over IPv6, ICMPv6, and IPv6 protocols. The -p
parameter can be used to specify a set of protocols.
-r
Displays the contents of the IP routing table. This is equivalent to the route print
command.
Interval
Redisplays the selected information every Interval seconds. Press CTRL+C to
stop the redisplay. If this parameter is omitted, netstat prints the selected
information only once.
/?
Displays help at the command prompt.
Remarks

• Parameters used with this command must be prefixed with a hyphen (-) rather
than a slash (/).
• Netstat provides statistics for the following:
• Proto
The name of the protocol (TCP or UDP).
• Local Address
• The IP address of the local computer and the port number being used. The
name of the local computer that corresponds to the IP address and the name of
the port is shown unless the -n parameter is specified. If the port is not yet
established, the port number is shown as an asterisk (*).
• Foreign Address
The IP address and port number of the remote computer to which the socket is
connected. The names that corresponds to the IP address and the port are
shown unless the -n parameter is specified. If the port is not yet established, the
port number is shown as an asterisk (*).
• (state)
Indicates the state of a TCP connection. The possible states are as follows:
CLOSE_WAIT
CLOSED
ESTABLISHED
FIN_WAIT_1
FIN_WAIT_2
LAST_ACK
LISTEN
SYN_RECEIVED
SYN_SEND
TIMED_WAIT
For more information about the states of a TCP connection, see RFC 793.
• This command is available only if the Internet Protocol (TCP/IP) protocol is
installed as a component in the properties of a network adapter in Network
Connections.

Examples
To display both the Ethernet statistics and the statistics for all protocols, type:

netstat -e -s

To display the statistics for only the TCP and UDP protocols, type:

netstat -s -p tcp udp

To display active TCP connections and the process IDs every 5 seconds, type:

netstat -o 5

To display active TCP connections and the process IDs using numerical form, type:
netstat -n -o

Formatting legend

Format Meaning

Italic Information that the user must supply


Bold Elements that the user must type exactly
as shown
Ellipsis (...) Parameter that can be repeated several
times in a command line
Between brackets ([]) Optional items
Between braces ({}); choices separated by Set of choices from which the user must
pipe (|). Example: {even|odd} choose only one
Courier font Code or program output
Experiment No 7
Aim:- Study of HTTP using Wire shark.
Theory:-In this lab, we’ll explore several aspects of the HTTP protocol: the basic
GET/response interaction, HTTP message formats, retrieving large HTML files,
retrieving HTML files with embedded objects, and HTTP authentication and security.

1. The Basic HTTP GET/response interaction


Let’s begin our exploration of HTTP by downloading a very simple HTML file - one that
is very short, and contains no embedded objects. Do the following:
1. Start up your web browser.
2. Start up the ethereal packet sniffer, as described in the introductory lab (but don’t yet
begin packet capture). Enter “http” (just the letters, not the quotation marks) in the
display-filter-specification window, so that only captured HTTP messages will be
displayed later in the packet-listing window. (We’re only interested in the
HTTP protocol here, and don’t want to see the clutter of all captured packets).
3. Wait a bit more than one minute (we’ll see why shortly), and then begin Ethereal
packet capture.
4. Enter the following to your browser
http://gaia.cs.umass.edu/ethereal-labs/HTTP-ethereal-file1.html
Your browser should display the very simple, one-line HTML file.
5. Stop ethereal packet capture. Your ethereal window should look similar to the window
shown in Figure 1. If you are unable to run Ethereal on a live network connection, you
can download a packet trace that was created when the steps above were followed.
Figure 1: Ethereal Display after http://gaia.cs.umass.edu/ethereal-labs/ HTTP
etherealfile1. html has been retrieved by your browser

The example in Figure 1 shows in the packet-listing window that two HTTP messages
were captured: the GET message (from your browser to the gaia.cs.umass.edu web
server) and the response message from the server to your browser. The packet-contents
window shows details of the selected message (in this case the HTTP GET message,
which is highlighted in the packet-listing window). Recall that since the HTTP message
was carried inside a TCP segment, which was carried inside an IP datagram, which was
carried within an Ethernet frame, Ethereal displays the Frame, Ethernet, IP, and TCP
packet information as well. We want to minimize the amount of non-HTTP data
displayed (we’re interested in HTTP here, and will be investigating these other protocols
is later labs), so make sure the boxes at the far left of the Frame, Ethernet, IP and TCP
information have a right-pointing arrowhead (which means there is hidden, underplayed
information), and the HTTP line has a down-pointing arrowhead (which means that all
information about the HTTP message is displayed).
(Note: You should ignore any HTTP GET and response for favicon.ico. If you see a
reference to this file, it is your browser automatically asking the server if it (the server)
has a small icon file that should be displayed next to the displayed URL in your browser.
We’ll ignore references to this pesky file in this lab.).
By looking at the information in the HTTP GET and response messages, answer the
following questions. When answering the following questions, you should print out the
GET and response messages (see the introductory Ethereal lab for an explanation of how
to do this) and indicate where in the message you’ve found the information that answers
the following questions.
1. Is your browser running HTTP version 1.0 or 1.1? What version of HTTP is the server
running?
2. What languages (if any) does your browser indicate that it can accept to the server?
3. What is the IP address of your computer? Of the gaia.cs.umass.edu server?
4. What is the status code returned from the server to your browser?
5. When was the HTML file that you are retrieving last modified at the server?
6. How many bytes of content are being returned to your browser?
7. By inspecting the raw data in the packet content window, do you see any headers
within the data that are not displayed in the packet-listing window? If so, name one.
In your answer to question 5 above, you might have been surprised to find that the
document you just retrieved was last modified within a minute before you downloaded
the document. That’s because (for this particular file), the gaia.cs.umass.edu server is
setting the file’s last-modified time to be the current time, and is doing so once per
minute. Thus, if you wait a minute between accesses, the file will appear to have been
recently modified, and hence your browser will download a “new” copy of the document.

2. The HTTP CONDITIONAL GET/response interaction


Recall from Section 2.2.5 of the text, that most web browsers perform object caching and
thus perform a conditional GET when retrieving an HTTP object. Before performing the
steps below, make sure your browser’s cache is empty. (To do this under Netscape 7.0,
select Edit->Preferences->Advanced->Cache and clear the memory and disk cache.
For Internet Explorer, select Tools->Internet Options->Delete File; these actions will
remove cached files from your browser’s cache.) Now do the following:
• Start up your web browser, and make sure your browser’s cache is cleared, as discussed
above.
• Start up the ethereal packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/ethereal-labs/HTTP-ethereal-file2.html
Your browser should display a very simple five-line HTML file.
• Quickly enter the same URL into your browser again (or simply select the refresh
button on your browser)

• Stop ethereal packet capture, and enter “http” in the display-filter-specification window,
so that only captured HTTP messages will be displayed later in the packet-listing
window.
• (Note: If you are unable to run Ethereal on a live network connection, you can use the
http-ethereal-trace-2 packet trace to answer the questions below; see footnote 1. This
trace file was gathered while performing the steps above on one
of the author’s computers.)
Answer the following questions:
8. Inspect the contents of the first HTTP GET request from your browser to the server.
Do you see an “IF-MODIFIED-SINCE” line in the HTTP GET?
9. Inspect the contents of the server response. Did the server explicitly return the contents
of the file? How can you tell?
10. Now inspect the contents of the second HTTP GET request from your browser to the
server. Do you see an “IF-MODIFIED-SINCE:” line in the HTTP GET? If so, what
information follows the “IF-MODIFIED-SINCE:” header?
11. What is the HTTP status code and phrase returned from the server in response to this
second HTTP GET? Did the server explicitly return the contents of the file?
Explain.
1. Retrieving Long Documents

In our examples thus far, the documents retrieved have been simple and short HTML
files. Let’s next see what happens when we download a long HTML file. Do the
following:
• Start up your web browser, and make sure your browser’s cache is cleared, as discussed
above.
• Start up the ethereal packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/ethereal-labs/HTTP-ethereal-file3.html
Your browser should display the rather lengthy US Bill of Rights.
• Stop ethereal packet capture, and enter “http” in the display-filter-specification window,
so that only captured HTTP messages will be displayed.
• (Note: If you are unable to run Ethereal on a live network connection, you can use the
http-ethereal-trace-3 packet trace to answer the questions below; see footnote 1. This
trace file was gathered while performing the steps above on one of the author’s
computers.)

In the packet-listing window, you should see your HTTP GET message, followed by a
multiple-packet response to your HTTP GET request. This multiple-packet response
deserves a bit of explanation. Recall from Section 2.2 (see Figure 2.9 in the text) that the
HTTP response message consists of a status line, followed by header lines, followed by a
blank line, followed by the entity body. In the case of our HTTP GET, the entity body in
the response is the entire requested HTML file. In our case here, the HTML file is rather
long, and at 4500 bytes is too large to fit in one TCP packet. The single HTTP response
message is thus broken into several pieces by TCP, with each piece being contained
within a separate TCP segment (see Figure 1.22 in the text). Each TCP segment is
recorded as a separate packet by Ethereal, and the fact that the single HTTP response was
fragmented across multiple TCP packets is indicated by the “Continuation” phrase
displayed by Ethereal. We stress here that there is no “Continuation” message in HTTP!
Answer the following questions:
12. How many HTTP GET request messages were sent by your browser?
13. How many data-containing TCP segments were needed to carry the single HTTP
response?
14. What is the status code and phrase associated with the response to the HTTP GET
request?
15. Are there any HTTP status lines in the transmitted data associated with a TCPinduced
“Continuation”?
4. HTML Documents with Embedded Objects
Now that we’ve seen how Ethereal displays the captured packet traffic for large HTML
files, we can look at what happens when your browser downloads a file with embedded
objects, i.e., a file that includes other objects (in the example below, image files) that are
stored on another server(s).
Do the following:
• Start up your web browser, and make sure your browser’s cache is cleared, as discussed
above.
• Start up the ethereal packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/ethereal-labs/HTTP-ethereal-file4.html
Your browser should display a short HTML file with two images. These two images are
referenced in the base HTML file. That is, the images themselves are not contained in the
HTML; instead the URLs for the images are contained in the downloaded HTML file. As
discussed in the textbook, your browser will have to retrieve these logos from the
indicated web sites. Our publisher’s logo is retrieved from the www.awl.com web site.
The image of our book’s cover is stored at the manic.cs.umass.edu server.
• Stop ethereal packet capture, and enter “http” in the display-filter-specification window,
so that only captured HTTP messages will be displayed.
• (Note: If you are unable to run Ethereal on a live network connection, you can use the
http-ethereal-trace-4 packet trace to answer the questions below; see footnote 1. This
trace file was gathered while performing the steps above on one of the author’s
computers.)
Answer the following questions:
16. How many HTTP GET request messages were sent by your browser? To which
Internet addresses were these GET requests sent?
17. Can you tell whether your browser downloaded the two images serially, or whether
they were downloaded from the two web sites in parallel? Explain.
2.5 HTTP Authentication
Finally, let’s try visiting a web site that is password-protected and examine the sequence
of HTTP message exchanged for such a site. The URL
http://gaia.cs.umass.edu/ethereal-labs/protected_pages/HTTP-ethereal-file5.html is
password protected. The username is “eth-students” (without the quotes), and the
password is “networks” (again, without the quotes). So let’s access this “secure”
password-protected site. Do the following:
• Make sure your browser’s cache is cleared, as discussed above, and close down your
browser. Then, start up your browser
• Start up the ethereal packet sniffer
• Enter the following URL into your browser
http://gaia.cs.umass.edu/ethereal-labs/protected_pages/HTTP-ethereal-file5.html
Type the requested user name and password into the pop up box..
• Stop ethereal packet capture, and enter “http” in the display-filter-specification window,
so that only captured HTTP messages will be displayed later in the packet-listing
window.
• (Note: If you are unable to run Ethereal on a live network connection, you can use the
http-ethereal-trace-5 packet trace to answer the questions below; see footnote 1. This
trace file was gathered while performing the steps above on one of the author’s
computers.)
Now let’s examine the ethereal output. You might want to first read up on HTTP
authentication by reviewing the easy-to-read material on “HTTP Access Authentication
Framework” at http://frontier.userland.com/stories/storyReader$2159
Answer the following questions:
18. What is the server’s response (status code and phrase) in response to the initial HTTP
GET message from your browser?
19. When your browser’s sends the HTTP GET message for the second time, what new
field is included in the HTTP GET message?
The username (eth-students) and password (network) that you entered are encoded in the
string of characters (ZXRoLXN0dWRlbnRzOm5ldHdvcmtz) following the
“Authorization: Basic” header in the client’s HTTP GET message. While it may appear
that your username and password are encrypted, they are simply encoded in a format
known as Base64 format. The username and password are not encrypted! To see this, go
to http://www.securitystats.com/tools/base64.php and enter the base64-encoded string
ZXRoLXN0dWRlbnRzOm5ldHdvcmtz and press decode. Voila! You have translated
from Base64 encoding to ASCII encoding, and thus should see both your username and
password! Since anyone can download a tool like Ethereal and sniff packets (not just
their own) passing by their network adaptor, and anyone can translate from Base64 to
ASCII (you just did it!), it should be clear to you that simple passwords on WWW sites
are not secure unless additional measures are taken.
Fear not! As we will see in Chapter 7, there are ways to make WWW access more secure.
However, we’ll clearly need something that goes beyond the basic HTTP authentication
framework
Experiment No 8
Aim:- Study of DHCP using Wire shark.
Theory:- In this lab, we’ll take a quick look at DHCP. DHCP is covered in Section
5.4.3 of the 3rd edition of the textbook. Recall that DHCP is used extensively in corporate,
university and home-network wired and wireless LANs to dynamically assign IP
addresses to hosts (as well as to configure other network configuration information).
This lab is brief, as we’ll only examine the DHCP packets captured by a host. If you also
have administrative access to your DHCP server, you may want to repeat this lab after
making some configuration changes (such as the lease time). If you have a router at
home, you most likely can configure your DHCP server. Because many Linux/Unix
machines (especially those that serve many users) have a static IP address and because
manipulating DHCP on such machines typically requires super-user privileges, we’ll only
present a Windows version of this lab below.
DHCP Experiment
In order to observe DHCP in action, we’ll perform several DHCP-related commands and
capture the DHCP messages exchanged as a result of executing these commands. Do the
following1:
1. Begin by opening the Windows Command Prompt application (which can be found in
your Accessories folder). As shown in Figure 1, enter
“ipconfig /release”. The executable for ipconfig is in C:\windows\system32. This
command releases your current IP address, so that your host’s IP address becomes
0.0.0.0
2. Start up the ethereal packet sniffer, as described in the introductory ethereal lab and
begin ethereal packet capture.
3. Now go back to the Windows Command Prompt and enter “ipconfig /renew”.
This instructs your host to obtain a network configuration, including a new IP address. In
Figure 1, the host obtains the IP address 192.168.1.108
4. Wait until the “ipconfig /renew” has terminated. Then enter the same command
“ipconfig /renew” again.
5. When the second “ipconfig /renew” terminates, enter the command
“ipconfig/release” to release the previously-allocated IP address to your computer.
6. Finally, enter “ipconfig /renew” to again be allocated an IP address for your computer.
6. Stop ethereal packet capture.
Figure 1 Command Prompt window showing sequence of ipconfig commands that you
should enter.
Now let’s take a look at the resulting ethereal window. To see only the DHCP packets,
enter into the filter field “bootp”. (DHCP derives from an older protocol called BOOTP.
Both BOOTP and DHCP use the same port numbers, 67 and 68. To see DHCP packets in
the current version of Ethereal, you need to enter “bootp” and not “dhcp” in the filter.)
We see from Figure 2 that the first ipconfig renew command caused four DHCP packets
to be generated: a DHCP Discover packet, a DHCP Offer packet, a DHCP Request
packet, and a DHCP ACK packet.
Figure 2 ethereal windows with first DHCP packet – the DHCP Discover packet –
expanded.
What to Hand In:
You should hand in a screen shot of the Command Prompt window similar to Figure 1
above. Whenever possible, when answering a question below, you should hand in am
printout of the packet(s) within the trace that you used to answer the question asked.
Annotate the printout to explain your answer. To print a packet, use File->Print, choose
Selected packet only, chooses Packet summary line, and select the minimum amount of
packet detail that you need to answer the question.
Answer the following questions:
1. Are DHCP messages sent over UDP or TCP?
2. Draw a timing datagram illustrating the sequence of the first four-packet
Discover/Offer/Request/ACK DHCP exchange between the client and server. For each
packet, indicated the source and destination port numbers. Are the port numbers the same
as in the example given in this lab assignment?
3. What is the link-layer (e.g., Ethernet) address of your host?
4. What values in the DHCP discover message differentiate this message from the DHCP
request message?
5. What is the value of the Transaction-ID in each of the first four
(Discover/Offer/Request/ACK) DHCP messages? What are the values of the
Transaction-ID in the second set (Request/ACK) set of DHCP messages? What is the
purpose of the Transaction-ID field?
6. A host uses DHCP to obtain an IP address, among other things. But a host’s IP address
is not confirmed until the end of the four-message exchange! If the IP address is not set
until the end of the four-message exchange, then what values are used in the IP
datagram’s in the four-message exchange? For each of the four
DHCP messages (Discover/Offer/Request/ACK DHCP), indicate the source and
destination IP addresses that are carried in the encapsulating IP datagram.
7. What is the IP address of your DHCP server?
8. What IP address is the DHCP server offering to your host in the DHCP Offer message?
Indicate which DHCP message contains the offered DHCP address.
9. In the example screenshot in this assignment, there is no relay agent between the
host and the DHCP server. What values in the trace indicate the absence of a relay
agent? Is there a relay agent in your experiment? If so what is the IP address of the agent?
10. Explain the purpose of the router and subnet mask lines in the DHCP offer message.
11. In the example screenshots in this assignment, the host requests the offered IP address
in the DHCP Request message. What happens in your own experiment?
12. Explain the purpose of the lease time. How long is the lease time in your experiment?
13. What is the purpose of the DHCP release message? Does the DHCP server issue an
acknowledgment of receipt of the client’s DHCP request? What would happen if the
client’s DHCP release message is lost?
14. Clear the bootp filter from your ethereal window. Were any ARP packets sent or
received during the DHCP packet-exchange period? If so, explain the purpose of those
ARP packets.
Experiment No 9

Aim:-Data transfer using stop and wait protocol.

Theory: - Stop and Wait Protocol

Protocols in which the sender sends on frame and then waits for an acknowledgement
before proceeding are called stop-and-wait protocols. The following code gives the
example of simplex stop-and-wait protocols.

Protocols 2 (stop-and-wait) also provides for a one-directional flow of data from sender
to receiver. The communication channel is once again assumed to be error free, as in
protocol 1. However, this time, the receiver has only a finite buffer capacity and a finite
processing speed, so the protocol must explicitly prevent the sender from flooding the
receiver with data faster than it can be handled.

typedef enum (frame arrival) event type :


#include “protocol.h”
void sender 2(void)
{
frame s; /*buffer for an outbound frame*/
packet buffer; /* buffer for an outbound frame*/
event_type event; /* frame arrival is the only possibility*/
while (true) {
from_network_layer (&buffer); /* go get something to send*/
s.info=buffer; /* copy it into s for transmission*/
to_physical layer (&s) /* bye little frame*/
wait_for_event (&event); /* do not proceed until given the go ahead*/
}
}
void receiver 2 (void)
{
frame r, s; /* buffers for frame*/
event_type event; /* frame_arrival is the only possibility*/
while (true) {
wait_for_event (&event); /* only possibility is frame_arrival*/
from_physical_layer (&r) /* go get the inbound frame */
to_network_layer(&r.info); /* pass the data to the network layer*/
to_physical_layer (&s) /* send a dummy frame to awakers sender*/

Here the sender starts out by fetching a packet from the network layer, using it to
construct a frame and sending it on its way. Only now, the sender must wait until an
acknowledgement frame arrives before looping back and fetching the next packet from
the network layer. The sending data link layer need not even inspect the incoming frame :
there is only one possibility.

After delivering a packet to the network layer, receiver 2 sends an acknowledgement


frame back to the sender before entering the wait loop again. Because only the arrival of
the frame back at the sender is important, not its contents, the receiver need not put any
particular information in it.
Experiment No 10
Aim:-Build a chat Server using TCP/UDP
Theory:-

Вам также может понравиться