Академический Документы
Профессиональный Документы
Культура Документы
Lab Manual
Subject In-charge
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
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
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:
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:
Formatting legend
Format Meaning
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.
ipconfig
ipconfig /all
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:
To set the DHCP class ID for the Local Area Connection adapter to TEST, type:
Formatting legend
Format Meaning
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:
Formatting legend
Format Meaning
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:
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
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.
• 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
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.
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.