Lab Manual Tcp

MGM’s College of Engineering Nanded -431605Department of Computer science & engineering.

Lab Manual

For the subject TCP/IP(Based on BE (CSE) Course)

Subject In-charge

Mrs. Joshi M.YMr. 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 568AWIRING STANDARD

PIN WIRE COLOUR

1White w/Green Stripe

2Green w/White Stripe

3White w/Orange Stripe

4Blue w/White Stripe

5White w/Blue Stripe

6Orange w/White Stripe

7White w/Brown Stripe

8Brown w/White Stripe

EIA/TIA 568BWIRING STANDARD

PIN WIRE COLOUR

1White w/Orange Stripe

2Orange w/White Stripe

3White w/Green Stripe

4Blue w/White Stripe

5White w/Blue Stripe

6Green w/White Stripe

7White w/Brown Stripe

8Brown 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:

http://gaia.cs.umass.edu/ethereal-labs/alice.txt

• 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?

http://gaia.cs.umass.edu/ethereal-labs/etherealtraces

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: - PingVerifies 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




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 pipe (|). Example: {even|odd}

Set of choices from which the user must 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.

/?


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.



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








Experiment No 6

Aim:-To study Trace root, Net stat utility.

Theory: - TracertDetermines 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.

-?


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.



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





Between braces ({}); choices separated by Set of choices from which the user

pipe (|). Example: {even|odd} must choose only one


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.

/?


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.



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








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.




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.)


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:


above.




Your browser should display the rather lengthy US Bill of Rights.


so that only captured HTTP messages will be displayed.



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!


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:


above.




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.


so that only captured HTTP messages will be displayed.




computers.)


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



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..


so that only captured HTTP messages will be displayed later in the packet-listing

window.




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


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 youshould 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.


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/UDPTheory:-