wireshark实验一答案
实验yi:网络协议分析工具Wireshark的使用
--------------------------------------------------------------------------------
c.根据Wireshark所观察到的现象解释解析域名“”所对应MX记录的过程。
本地主机的DNS客户端发送了一个查询且资源记录类型为MX的DNS查询报文。收到一个DNS回答报文,告知其规范主机名为。
d.“”域有几个邮件服务器?它们的IP地址分别是什么?
进入SYN_SEND状态,等待服务器确认。
第二次握手:服务器收到SYN包,ACK =1,同时发送SYN= 0的包,进入SYN_RECV状态。
第三次握手:收到上部报文后,本地主机回复了ACK=1的确认报文段,至此,链接建立。
c.TCP的连接终止过程:
第一次:本地主机向目的主机发送[FIN,ACK]报文,seq=16452,ack =58,FIN=1,请求中断链接
2.用Wireshark观察tracert命令的工作过程:(20分)
(1)运行Wireshark, 开始捕获tracert命令中用到的消息;
(2)执行“tracert-d ”
根据Wireshark所观察到的现象思考并解释tracert的工作原理。
-----------------------------------------------------------
--------------------------------------------------------------------------------
计算机网络原理与技术实验教程-参考答案-实验报告
声明:每个实验都有与之对应的数据包,表格的数据都是分析数据包填上的,由于姜腊林老师只是批阅没有给我们批改,所以会有很多错的地方没改和不懂的地方没有写。
这真的仅仅是参考而已。
实验1.1 Wireshart的使用实验一、实验目的:掌握协议分析软件Wireshark的使用。
二、实验设备:电脑、Wireshart抓包工具三、实验内容:运行Wireshark程序,启动界面点击start按钮,进入Wireshark主窗口。
主窗口包含了捕获和分析包相关的操作。
四、实验步骤:(1)启动Wireshark。
(2)开始分组捕获。
(3)保存抓包文件。
(4)分析抓包文件。
五、实验结果分析(1)、Wireshark主窗口包含那几个窗口?说明这些窗口的作用。
菜单栏:菜单栏通常用来启动Wireshark有关操作,例如File.工具栏:工具栏提供菜单中常用项目的快速访问。
过滤器栏:过滤器栏提供一个路径,来直接控制当前所用的显示过滤器。
包列表窗口:包列表窗口显示当前捕获的全部包的摘要。
包列表的每一行对应一个包,不同包有不同的颜色。
如果选择了某行,则更详细的信息显示在保协议窗口和包字节数据窗口中,在包列表窗口中的每一行代表捕获的一个包,每个包的摘要信息包括:a、No:包文件中包的编号。
b、T ime:包的时间擢,即捕获该包的时间,该时间戳的实际格式可以改变。
c、Source:包的源地址。
d、D estination:包的目标地址。
e、Length:该数据包的长度。
f、Info:包内容的附加信息。
包协议窗口:包协议窗口以更详细的格式显示从包列表窗口选中的协议和协议字段。
包的协议和字段用树型格式显示,可以扩展和收缩。
这是一种可用的上下文菜单,单机每行前的“+”就可以展开为以“—”开头的若干行,单击“—”又可以收缩。
包字节(十六进制数据窗口):包字节窗口以十六进制形式显示出从包列表窗格中选定的当前包的数据,并以高亮度显示在包协议窗口中选择字段。
实验一 利用WireShark观察网络协议分层架构
实验一利用WireShark观察网络协议分层架构一、实验目的及任务1、熟悉并掌握WireShark的基本操作。
2、了解网络协议实体间进行交互以及报文交换的情况。
二、实验环境与因特网连接的计算机网络系统;主机操作系统为windows;WireShark、IE等软件。
三、预备知识一个人要深入理解网络协议,需要:观察它们的工作并使用它们,即观察两个协议实体之间交换的报文序列,探究协议操作的细节,使协议实体执行某些动作,观察这些动作及其影响。
这些任务可以在仿真环境下或在如因特网这样的真实网络环境中完成。
观察在正在运行协议实体间交换报文的基本工具被称为分组嗅探器(packet sniffer)。
顾名思义,一个分组嗅探器俘获(嗅探)由你的计算机发送和接收的报文。
一般情况下,分组嗅探器将存储和显示出被俘获报文的各协议字段的内容。
图1显示了一个分组嗅探器的结构。
图1右边是计算机上正常运行的协议(在这里是因特网协议)和应用程序(如:web浏览器和ftp客户端)。
分组嗅探器(虚线框中的部分)是附加计算机普通软件上的,主要有两部分组成。
分组俘获库(packet capture library)接收计算机发送和接收的每一个链路层帧的拷贝。
高层协议(如:HTTP、FTP、TCP、UDP、DNS、IP等)交换的报文都被封装在链路层帧中,并沿着物理媒体(如以太网的电缆)传输。
图1假设所使用的物理媒体是以太网,并且上层协议的报文最终封装在以太网帧中。
分组嗅探器的第二个组成部分是分组分析器。
分组分析器用来显示协议报文所有字段的内容。
为此,分组分析器必须能够理解协议所交换的所有报文的结构。
例如:我们要显示图1中HTTP协议所交换的报文的各个字段。
分组分析器理解以太网帧格式,能够识别包含在帧中的IP数据报。
分组分析器也要理解IP数据报的格式,并能从IP数据报中提取出TCP报文段。
然后,它需要理解TCP报文段,并能够从中提取出HTTP消息。
wireshark实验一答案
wireshark实验⼀答案1.What is the IP address and TCP port number used by the clientcomputer (source) that is transferring the file to /doc/8d460b7e8e9951e79b892738.html ?Ip address 192.168.1.36TCP port number:19572.What is the IP address of /doc/8d460b7e8e9951e79b892738.html ? On what port numberis it sending and receiving TCP segments for this connection?the IP address of /doc/8d460b7e8e9951e79b892738.html :128.119.245.12port number:803.What is the sequence number of the TCP SYN segment that is usedto initiate the TCP connection between the client computer and /doc/8d460b7e8e9951e79b892738.html What is it in the segment that identifies the segment as a SYN segmentsequence number:0syn 被设置为1说明是syn段4.What is the sequence number of the SYNACK segment sent bygaia.cs.umass.ed to the client computer in reply to the SYN? What is the value of the ACKnowledgement field in the SYNACK segment?How did /doc/8d460b7e8e9951e79b892738.html determine that value? What is it in the segment that identifies the segment as a SYNACK segment?The sequence number of the SYNACK segment sent by /doc/8d460b7e8e9951e79b892738.html is:0 SYNACK segment 中ACKnowledgement 的值为1;ACKnowledgement number的值为SYN消息中sequencenumber加上1所得;SYN 和Acknowledgement f都置为1说明这是⼀个SYNACK segment.5.What is the sequence number of the TCP segment containing theHTTP POST command?第11号报⽂段是包含HTTP POST 命令的TCP segment。
wireshark练习及答案lab-protocol-layers
Lab Exercise – Protocol LayersObjectiveTo learn how protocols and layering are represented in packets. They are key concepts for structuring networks that are covered in the text.The trace for this lab is here:/~kevin/com320/labs/wireshark/trace-protocol-layers.pcap(although the main trace you will look at is from a site you pick such as in the exam-ples which follow).RequirementsWireshark: This lab uses the Wireshark software tool to capture and examine a packet trace. A packet trace is a record of traffic at a location on the network, as if a snapshot was taken of all the bits that passed across a particular wire. The packet trace records a timestamp for each packet, along with the bits that make up the packet, from the lower-layer headers to the higher-layer contents. Wireshark runs on most operating systems, including Windows, Mac and Linux. It provides a graphical UI that shows the sequence of packets and the meaning of the bits when interpreted as protocol headers and data. It col-or-codes packets by their type, and has various ways to filter and analyze packets to let you investigate the behavior of network protocols. Wireshark is widely used to troubleshoot networks. You can down-load it from for your personal computer. It is an ideal packet analyzer for our labs –it is stable, has a large user base and well-documented support that includes a user-guide /docs/wsug_html_chunked), and a detailed FAQ, rich functionality that in-cludes the capability to analyze hundreds of protocols, and a well-designed user interface. It operates in computers using Ethernet, serial (PPP and SLIP), 802.11 wireless LANs, and many other link-layer tech-nologies (if the OS on which it is running allows Wireshark to do so). It is already installed in the labs.A quick help guide to Wireshark display filters is here: /wireshark_filters.php Wireshark is a c ore tool for any wireless ‘man in the middle’ or similar snooping attack. It is simply in-dispensable for those who wish to examine packets being transferred over a network –good or bad…..Wireshark & Packet Sniffing BackgroundThe basic tool for observing the messages exchanged between executing protocol entities is called a packet sniffer. As the name suggests, a packet sniffer captures (“sniffs”) messages being sent/received from/by your computer; it will also typically store and/or display the contents of the various protocol fields in these captured messages. A packet sniffer itself is passive. It observes messages being sent and received by applications and protocols running on your computer, but never sends packets itself. Simi-larly, received packets are never explicitly addressed to the packet sniffer. Instead, a packet sniffer re-ceives a copy of packets that are sent/received from/by application and protocols executing on your machine.Figure 1 shows the structure of a packet sniffer. At the right of Figure 1 are the protocols (in this case, Internet protocols) and applications (such as a web browser or ftp client) that normally run on your computer. The packet sniffer, shown within the dashed rectangle in Figure 1 is an addition to the usual software in your computer, and consists of two parts. The packet capture library receives a copy of eve-ry link-layer frame that is sent from or received by your computer. Messages exchanged by higher layer protocols such as HTTP, FTP, TCP, UDP, DNS, or IP all are eventually encapsulated in link-layer frames that are transmitted over physical media such as an Ethernet cable.Figure 1: Packet Sniffer StructureIn Figure 1, the assumed physical media is an Ethernet, and so all upper-layer protocols are eventually encapsulated within an Ethernet frame. Capturing all link-layer frames thus gives you all messagessent/received from/by all protocols and applications executing in your computer.The second component of a packet sniffer is the packet analyzer, which displays the contents of all fields within a protocol message. In order to do so, the packet analyzer must “understand” the structure of all messages exchanged by protocols. For example, suppose we are interested in displaying the various fields in messages exchanged by the HTTP protocol in Figure 1. The packet analyzer understands the format of Ethernet frames, and so can identify the IP datagram within an Ethernet frame. It also under-stands the IP datagram format, so that it can extract the TCP segment within the IP datagram. Finally, it understands the TCP segment structure, so it can extract the HTTP message contained in the TCP seg-ment. Finally, it understands the HTTP protocol and so, for example, knows that the first bytes of an HTTP message will contain the string “GET,”“POST,” or “HEAD,”.Step 1: Capture a Traceunching WiresharkYou can type Wireshark in the run box of main Windows 8 start screen. Press the Windows key on the keyboard and type “wireshark”. If a problem launching it then see here1.Figure 2: Wireshark in lab2.Just close the dialog box which prompts you to install a new version. You will then see a startupscreen, as shown next.Figure 3: Initial Wireshark Screen3.Take a look at the left hand side of the screen –you’ll see an “Interface list”. This is the list ofnetwork interfaces on your computer. Choose Ethernet.1 It should load but there can be a problem with the new lab configuration for Wireshark and npf driver. Therefore if this is not working…. then please do the next step. Launch Wireshark as follows. Click desktop icon on main windows screen & use the file explorer to browse to C:\local Disk (C)\Program Files\Wireshark. Finally, RIGHT CLICK on Wireshark as “Run as administrator”.4.Next, click Start (as shown below).5.Wireshark will capture all packets on that interface. Click on the network card on the particularmachine you are working on. In the example above, it is the Ethernet Driver to start packet cap-ture (i.e., for Wireshark to begin capturing all packets being sent to/from that interface), ascreen like the one below will be displayed, showing information about the packets being cap-tured. Once you start packet capture, you can stop it by using the Capture pull down menu and selecting Stop.We want this trace to look at the protocol structure of packets. A simple Web fetch of a URL from a server of your choice to your computer, which is the client, could also serve as traffic.6.Open your browser, e.g. Chrome and pick a URL & fetch it e.g.”.7.Close unnecessary browser tabs and windows. By minimizing browser activity you will stop yourcomputer from fetching unnecessary web content, and avoid incidental traffic in the trace.8.Now return to Wireshark and you will see a screen similar to below.That is all for now. Next you will read a little more about Wireshark and tracing packets.Main Wireshark InterfaceThe Wireshark interface has five major components:Figure 4: Wireshark Graphical User Interface, during packet capture and analysis• The command menus are standard pull down menus located at the top of the window. The File menu allows you to save captured packet data or open a file containing previously captured packet data. The Capture menu allows you to begin packet capture.• The packet-listing window displays a one-line summary for each packet captured, including the pack-et number (assigned by Wireshark; this is not a packet number contained in any protocol’s header), the time at which the packet was captured, the packet’s source and destination addresses, the protocol type, and protocol-specific information contained in the packet. The packet listing can be sorted accord-ing to any of these categories by clicking on a column name. The protocol type field lists the highest-level protocol that sent or received this packet, i.e., the protocol that is source or ultimate sink for this packet.• The packet-header details window provides details about the packet selected (highlighted) in the packet-listing window. (To select a packet in the packet-listing window, place the cursor over the pack-et’s one-line summary in the packet-listing window and click with the left mouse button.). These details include information about the Ethernet frame (assuming the packet was sent/received over an Ethernet interface) and IP datagram that contains this packet. The amount of Ethernet and IP-layer detail dis-played can be expanded or minimized by clicking on the plus minus boxes to the left of the Ethernet frame or IP datagram line in the packet details window.• The packet-contents window displays the entire contents of the captured frame, in both ASCII and hexadecimal format. Towards the top of the Wireshark graphical user interface, is the packet display fil-ter field, into which a protocol name or other information can be entered in order to filter the infor-mation displayed in the packet-listing window.Filtering TrafficNow return to your Wireshark trace captured earlier. We will look to see how we can isolate the Web Page traffic from the other protocol packets.9.You have two options. You can simply type “tcp.port==80” in the main filter box on the mainscreen like below.10.Instead of the method above, you can also filter by typing “port 80” in the filter box like below.This filter will record only standard web traffic and not other kinds of packets that your comput-er may send. The checking will translate the addresses of the computers sending and receivingpackets into names, which should help you to recognize whether the packets are going to orfrom your computer. Your capture window will be similar to the one pictured in next screenshot.Figure 5: Setting up the capture options11.When the capture is started, visit a site which uses http (not https). This time, the packets will berecorded by Wireshark as the content is transferred. Try again, in your browser.12.After the fetch is successful, return to Wireshark and use the menus or buttons to stop the trace.If you have succeeded, the upper Wireshark window will show multiple packets, and most likely it will be full. How many packets are captured will depend on the size of the web page, but there should be at least 8 packets in the trace, and typically 20-100, and many of these packets will be colored green. I recommend you stop recording by pressing the Red Stop button on the inter-face as this will make it easier for you to scroll back to the start of the request to find the “200 OK” packet. An example is shown below. Congratulations, you have captured a trace!Figure 6: Packet trace of web browsing trafficStep 2: Inspect the TraceSelect a packet for which the Protocol column is “HTTP” and the Info column says it is a GET. It is the packet that carries the web (HTTP) request sent from your computer to the server. (You can click the column headings to sort by that value, though it should not be difficult to find an HTTP packet by inspec-tion.) Let’s have a closer look to s ee how the packet structure reflects the protocols that are in use. Since we are fetching a web page, we know that the protocol layers being used are as shown below. That is, HTTP is the application layer web protocol used to fetch URLs. Like many Internet applications, it runs on top of the TCP/IP transport and network layer protocols. The link and physical layer protocols depend on your network, but are typically combined in the form of Ethernet (shown) if your computer is wired, or 802.11 (not shown) if your computer is wireless.Figure 7: Protocol stack for a web fetchWith the HTTP GET packet selected, look closely to see the similarities and differences between it and our protocol stack as described next. The protocol blocks are listed in the middle panel. You can expand each block (by clicking on the “+” expander or icon) to see its details.• The first Wireshark block is “Frame”. This is not a protocol, it is a record that describes overall information about the packet, including when it was captured and how many bits long it is.• The second block is “Ethernet”. Note that you may have taken a trace on a computer using 802.11 yet still see an Ethernet block instead of an 802.11 block. Why? It happens because we asked Wireshark to capture traffic in Ethernet format on the capture options, so it converted the real 802.11 header into a pseudo-Ethernet header.• Then come IP, TCP, and HTTP, which are just as we wanted. Note that the order is from the bot-tom of the protocol stack upwards. This is because as packets are passed down the stack, the header information of the lower layer protocol is added to the front of the information from the higher layer protocol, as in Fig. 1-15 of your text. That is, the lower layer protocols come first in the packet “on the wire”.HTTPTCPIP Ethernet ClientServer HTTP TCP IPEthernetpacketStep 3: Inspect the Trace AgainNow find another HTTP packet, the response from the server to your computer, and look at the structure of this packet for the differences compared to the HTTP GET packet.This packet should have “200 OK” in the Info field, denoting a successful fetch. In our trace, there are two extra blocks in the detail panel as seen in the next figure.•The first extra block says something like “[... reassembled TCP segments …]”. Details in your cap-ture will vary, but this block is describing more than the packet itself. Most likely, the web re-sponse was sent across the network as a series of packets that were put together after they ar-rived at the computer. The packet labeled HTTP is the last packet in the web response, and the block lists packets that are joined together to obtain the complete web response. Each of these packets is shown as having protocol TCP even though the packets carry part of an HTTP re-sponse. Only the final packet is shown as having protocol HTTP when the complete HTTP mes-sage may be understood, and it lists the packets that are joined together to make the HTTP re-sponse.•The second extra block says “Line-based text data …”. Details in your capture will vary, but this block is describing the contents of the web page that was fetched. In our case it is of typetext/html, though it could easily have been text/xml, image/jpeg, or many other types. As with the Frame record, this is not a true protocol. Instead, it is a description of packet contents that Wireshark is producing to help us understand the network traffic.Figure 8: Inspecting a HTTP “200 OK” response1.Locate the HTTP GET packet which has “200 OK (text/html)” in the Info field, denoting asuccessful fetch. See below for instance in the third line in white.2.Scroll down in the middle pane to [+] Line-based text data: text/html and rightclick with your mouse. (See above)3.From the context menu which now appears, select Copy -→ Bytes → Printable Text Only Youshould see a window similar to the following popup window below.4.This copies all the code for the Ulster home page.5.Open up a text editor such as notepad++ and paste this HTML code into a new document. Saveas UlsterHomePage.html in a directory such as W: or downloads. Next open up explorer and scroll to where you have saved the file and open it in the default browser by clicking on it.6.Note how much of the Ulster home page actually gets sent over the wire to your PC.Step 4: Packet StructureExamine a HTTP GET packet that shows the position and size in bytes of the TCP, IP and Ethernet proto-col headers. Note the range of the Ethernet header and the Ethernet payload that IP passes to Ethernet to send over the network. Note also the range of the IP header and the IP payload.To work out sizes, observe that when you click on a protocol block in the middle panel (the block itself, not the “+” expander) then Wireshark will highlight the bytes it corresponds to in the packet in the lower panel and display the length at the bottom of the window. For instance, clicking on the IP version 4 header of a packet in our trace shows us that the length is 20 bytes. (Your trace will be different if it is IPv6, and may be different even with IPv4 depend-ing on various options.) You may also use the overall packet size shown in the Length column or Frame detail block. AnswerFigure 9: Protocol layer structure of the HTTP GET packet There are several features to note:• The order of the headers (Ethernet, IP, TCP, HTTP) is the protocol stack from the bottom up-wards because the lower layers are outermost in the packet as it travels through the network. • Observant students will note some differences between the Ethernet header size in Wireshark and in the text that will be explored in later labs.• The size of the IP and TCP headers is normally around 20 bytes each, but it may be larger in some cases depending on the OS, e.g., IPv6 instead of IPv4 and optional TCP header fields might double these numbers.• The size of the HTTP message will vary depending on what tool and URL is used to send the web request. For wget/curl, it is likely to be around 100-300 bytes.• The Ethernet payload comprises everything beyond the Ethernet header. That is, Ethernet does not understand the IP / TCP / HTTP internal structure; it is up to higher layers to determine their headers and message boundaries.• Similarly, the IP payload comprises everything beyond the IP header. Note that neither the IP header nor payload covers the Ethernet header. HTTP EthernetIP TCP 14 bytes 20 bytes20 bytes 112 bytesEthernet header Ethernet payload166 bytes totalStart of packetIP header IP payloadStep 5: Demultiplexing KeysWhen an Ethernet frame arrives at a computer, the Ethernet layer must hand the packet that it contains to the next higher layer to be processed. The act of finding the right higher layer to process received packets is called demultiplexing. We know that in our case the higher layer is IP. But how does the Ethernet protocol know this? After all, the higher-layer could have been another protocol entirely (such as ARP). We have the same issue at the IP layer – IP must be able to determine that the contents of IP message is a TCP packet so that it can hand it to the TCP protocol to process. The answer is that proto-cols use information in their header known as a “demultiplexing key” to determine the higher layer. Look at the Ethernet and IP headers of a download packet in detail to answer the following questions:1.Which Ethernet header field is the demultiplexing key that tells it the next higher layer is IP?What value is used in this field to indicate “IP”?Answer. The demultiplexing key for Ethernet is the Type field. It holds 0x800 when the higherlayer is IP.2.Which IP header field is the demultiplexing key that tells it the next higher layer is TCP? Whatvalue is used in this field to indicate “TCP”?Answer: The demultiplexing key for IP is the Protocol field. It has value 6 when the higher layer is TCP.。
wireshark练习及答案lab-dns.doc
Lab Exercise – DNSObjectiveDNS (Domain Name System) is the system & protocol that translates domain names to IP addresses . Step 1: Analyse the supplied DNS TraceHere we examine the supplied trace of a browser making DNS requests as follows.The trace is here: /~kevin/com320/labs/wireshark/trace-dns.pcapunch Wireshark and start a capture with a filter of “udp port 53”.We use this filterbe-cause there is no shorthand for DNS, but DNS is normally carried on UDP port 53.Figure 3: Setting up the capture optionsStep 2: Inspect the TraceTo explore the details of DNS packets, select a DNS query expand its Domain Name System block (by us-ing the “+” expander or icon). Your display should be similar to the one shown in our figure, with a series of packets with protocol DNS.. We have selected the first DNS message.Figure 3: Trace of DNStraffic showing the details of the DNS headerLook for the following details:∙The DNS block follows the IP and UDP blocks. This is because DNS messages are carried in UDP segments within IP packets. You will see that the UDP port used by a nameserver is 53.∙The DNS header starts with a Transaction ID that is used to link a request and the corresponding reply – they both carry the same Transaction ID.∙Next come a set of flags that you can expand. They indicate whether the DNS message is a query or response, amongst other details.∙Then comethe number of query, answer, authority and additional records. These fields conclude the header.∙After the DNS header, the remainder of the message consists of the indicated number of query, answer, authority and additional records. Often there will be only one query – for the IP address of the domain name we are seeking – but there may be many of the other records. Theserecords are grouped in sections, such as the Authority section for all of the authority records.Each query has a Type code that indicates the kind of record sought, whether an IP address orotherwise. Each of the other recordsalso has a Type code that indicates whether it carries an IP address of a host, the name of a nameserver, or something else. The format of an individualrecord depends on its type. The entire DNS message is designed to fit within one UDP message.∙Wireshark may show other information, such as the number of the packet that carries the re-sponse to this request or the response time for the DNS exchange, but this is derived informa-tion. It is not actually carried on any packet.Repeat the above to look at a DNS response. You should see a larger set of records in this message; while DNS queries mostly serve to carry the query, DNS responses often return a set of useful information.Step 3: Details of DNS MessagesSelect the first DNS querypacket in your trace, with the first several packetscorresponding to earlier dig commands. To check, see if there are several queries that list the domain you chose in the Info column, each followed by a response.Look at the DNS header, and answer the following questions: (Answers on next page).1.How many bits long is the Transaction ID? Based on this length, take your best guess as to howlikely it is that concurrent transactions will use the same transaction ID.2.Which flag bit and what values signifies whether the DNS message is a query or response?3.How many bytes long is the entire DNS header? Use information in the bottom status line whenyou select parts of the packet and the bottom panel to help you work this out.Now examine the responses to DNS queries in the trace.The initial response should have provided another nameserver one step closer to the nameserver, but not the final answer. You should find that it includes the original query in its Query section. It will also include records with both the name of the nameservers to contact next, and the IP addresses of those nameservers. The final response in this se-ries will include the IP address of the domain name – this is the answer to the query.Look at the body of the DNS response messages, and answer the following questions: (answers overleaf)4.For the initial response, in what section are the names of the nameservers carried? What is theType of the records that carry nameserver names?5.Similarly, in what section are the IP addresses of the nameservers carried, and what is the Typeof the records that carry the IP addresses?6.For the final response, in what section is the IP address of the domain name carried?Answers to Step 3: Details of DNS Messages1.The Transaction ID is 16 bits long, which makes collisions unlikely,. Since the host computer issetting this value, it can use all 2^16 choices before repeating. This means that 2^16query/response pairs would need to be outstanding at the same time to cause a collision. For a normal computer, this is an extremely or implausibly high DNS workload.2.The first flag bit signifies query or response. A “0” indicates a query, and hence a “1” a response.3.The DNS header is 12 bytes long.4.The names of name servers are carried in the Authority section in an NS (NameServer) record.5.The IP addresses of the name servers are carried in the Additional section. The Type of record isA, for an IPv4 address, or AAAA for an IPv6 address.6.The IP address of the queried domain name is carried in the Answer section (in an A or AAAArecord.)Step 4: DNS Response TimeTo conclude this lab, we will look at the DNS response time of the DNS queries. This is a normal DNS usage, in which a computer sends a single query and receives the answer in the response. The response time is the delay between when the computer sends the query to the local nameserver and when it receives the response from the local nameserver. This time includes the time taken by the local name-server to contact remote nameservers, if the answer is not cached. Since this response time can delay connections to sites, it should be as small as possible.Proceed as follows to generate an “IO Graph” of the DNS response time s. IO graphs are a standard fea-ture of Wireshark available under the Statistics menu. By default, this graph shows the rate of packets over time. We will tweak it to show the DNS response time over the trace with the following changes: ∙On the x-axis, adjust the tick interval and pixels per tick for viewing. The tick interval should be small enough to see into the behavior over the trace.One second is probably a good choice foryour trace. The pixels per tick can be adjusted to make the graph wider or narrower to fill thewindow; you can also adjust the width of the window.∙On the y-axis, change the unit to be “Advanced”. The default is Packet/Tick. “Advanced” is a special keyword that will let us access different data values to graph. Once you select it, a new“Calc:” box will appear to let us specify the data values.∙Enter “dns.time” into the calculation box and set the pull-down menu to be“MAX(*)”.dns.time is a virtual field calculated by Wireshark from the query and responsemessages. It is shown with DNS responses, and gives the DNS response time. Choosing “MAX(*)”will let us see the largest DNS response time in every tick interval so that we can spot outliers.“AVG(*)” would also be a reasonable choice.∙Press Enter, and click the “Graph” button ifnecessary. You may need to do this to trigger a redis-play. You should now have a graph of response times similar to our graph in the figure below. We expect that you will see many small DNS response times, and a scattering of larger DNS response times. In our graph, most times are very small, likely because the correct answer is cached by the local nameserver. In some cases, however, there is a longer delay of hundreds of milliseconds as remote na-meservers must be queried. You can click a point on the graph to be taken to the nearest point in the trace if there is a feature you would like to investigate.Figure 4: DNS response time via an IO graphIf you look over the DNS traffic caused by your browser, you are likely to see a greater range of beha-viors than in the DNS traffic caused by the dig commands. This behavior might include new types of records, such as CNAME (canonical name, to provide information about aliases when one machine is known by multiple names), answers that indicate that a name does not exist, and so forth. Explore Your NetworkWe encourage you to explore DNSon your own once you have completed this lab. Some ideas:∙Look up other types of DNS records, such as MX to find the mail server for a domain, and AAAA to find the IPv6 address of a domain.∙Google provides an alternate DNS nameserver system that you may use called “Google P ublic DNS”. Look it up, and follow the configuration instructions to test it out. Experiment to see ifthis DNS service is faster than your existing DNS arrangement.。
网络协议实验一Wireshark_分析IP协议
回答以下问题:1、选择你的电脑所发送的第一个ICMP 请求消息,在包详细信息窗口扩展包的Internet协议部分。
你的电脑的IP 地址是多少?答:10。
127.118.1732、在IP 包头部,上层协议区域的值是多少?答:icmp(1)3、IP 头部有多少字节?IP 数据包的有效载荷是多少字节?解释你是怎样确定有效载荷的数量的?答:头部有20字节有效载荷56—20=36字节4、这个IP 数据包被分割了吗?解释你是怎样确定这个数据包是否被分割?答:没有5、在包捕获列表窗口,你能看到在第一个ICMP 下的所有并发的ICMP 消息吗?答:能6、往同一IP 的数据包哪些字段在改变,而且必须改变?为什么?哪些字段是保持不变的,而且必须保持不变?答:必须改变的:identification(标识)、header chechsum(头部检验和)标识是源主机富裕IP数据报的标识符、头部检验和用于保证IP数据报报头的完整性。
必须保持不变的:version(版本)、header length(头部长度)、differentiated services field (区分服务)、flags(标记)、 fragment offset(片偏移)、 protocol(协议)、 destination (目的地址)7、描述一下在IP 数据包的Identification 字段的值是什么样的?答:每一个IP数据报头部的标识号域都不一样,每次加18。
Identification 字段和TTL字段的值是多少?答:Identification 字段5862TTL字段 1289。
所有的通过最近的路由器发送到你的电脑去的ICMP的TTL溢出回复是不是保持不变?为什么?答:每一个固定的路由器都有一个固定的TTL值,所以最近的那个路由器回复的所有的ICMP TTL—exceeded 的TTL的值都不会改变.以下是pingpolotter 设置为200010.答案如图:有分片11。
wireshark练习及答案lab-ipv4
Lab Exercise – IPv4ObjectiveTo learn about the details of IP (Internet Protocol). IP is the network layer protocol used throughout the Internet. We will examine IP version 4, since it is ubiquitously deployed, while the IP version 6 is partly deployed.The trace is here: /~kevin/com320/labs/wireshark/trace-ipv4.pcapThe text file is here: /~kevin/com320/labs/wireshark/trace-ipv4.txt RequirementsWireshark: This lab uses the Wireshark software tool to capture and examine a packet trace. A packet trace is a record of traffic at a location on the network, as if a snapshot was taken of all the bits that passed across a particular wire. The packet trace records a timestamp for each packet, along with the bits that make up the packet, from the lower-layer headers to the higher-layer contents. Wireshark runs on most operating systems, including Windows, Mac and Linux. It provides a graphical UI that shows the sequence of packets and the meaning of the bits when interpreted as protocol headers and data. It col-or-codes packets by their type, and has various ways to filter and analyze packets to let you investigate the behavior of network protocols. Wireshark is widely used to troubleshoot networks. You can down-load it from if it is not already installed on your computer. We highly recommend that you watch the short, 5 minute video “Introduction to Wireshark” that is on the site.wget / curl: This lab uses wget (Linux and Windows) and curl (Mac) to fetch web resources. wget and curl are command-line programs that let you fetch a URL. Unlike a web browser, which fetches and executes entire pages, wget and curl give you control over exactly which URLs you fetch and when you fetch them. Under Linux, wget can be installed via your package manager. Under Windows, wget is available as a binary; look for download information on /software/wget/. Under Mac, curl comes installed with the OS. Both ha ve many options (try “wget --help” or “curl --help” to see) but a URL can be fetched simply with “wget URL” or “curl URL”. traceroute / tracert: This lab uses “traceroute” to find the router level path from your computer to a remote Internet host. traceroute is a standard command-line utility for discovering the Internet paths that your computer uses. It is widely used for network troubleshooting. It comes pre-installed on Win-dow and Mac, and can be installed using your package manager on Linux. On Windows, it is called “tracert”. It has various options, but simply issuing the command “traceroute .au” will cause your computer to find and print the path to the remote computer (here .au).Step 1: Capture a TraceProceed as follows to capture a trace assuming that your computer has IPv4 connectivity; alternatively, you may use a supplied trace. The trace we want to gather is a simple web fetch from a remote server, which will cause your computer to send and receive IP packets, followed by a traceroute to the re-mote server to find the path it uses over the Internet.1.Pick a URL at a remote server, e.g., .au/ and check that you can fetch thecontents with wget or curl, e.g., “wget .au/” or “curl.au/”. This will fetch the resource and either write it to a file (wget) or to the screen (curl). With wget, you want a single response with status code “200 OK”. Ifthe fetch does not work then try a different URL; keep in mind that you may be referring to aURL by a shortcut for which browsers must do work to find the intended content, e.g., may really be /index.html. If no URLs seem to work then de-bug your use of wget/curl or your Internet connectivity.2.Perform a traceroute to the same remote server to check that you can discover informationabout the network path.On Windows, type, e.g., “tracert .au”. On Linux / Mac, type, e.g., “traceroute .au”. If you are on Linux / Mac and behind aNAT (as most home users or virtual machine users) then use the –I option (that was a capital i)to traceroute, e.g., “traceroute –I .au”. This will cause traceroute to send ICMP probes like tracert instead of its usual UDP probes; ICMP probes are better ableto pass through NAT boxes. A successful example is shown below; save the output as you willneed it for later steps. Note that traceroute may take up to a minute to run. Each line shows information about the next IP hop from the computer running traceroute towards the tar-get destination. T he lines with “*”s indicate that there was no response from the network toidentity that segment of the Internet path. Some unidentified segments are to be expected.However, if traceroute is not working correctly then nearly all the path will be “*”s. In thiscase, try a different remote server, experiment with traceroute, or use the supplied traces.Figure 1: Running traceroute (as tracert on Windows)unch Wireshark and start a capture with a filter of “tcp port 80“. Make sure to check“enable network name resolution”. We use this filter to record only standard web traffic. Name resolution will translate the IP addresses of the computers sending and receiving packets into names. It will help you to recognize whether the packets are going to or from your computer.Your capture window should be similar to the one pictured below, other than our highlighting.Select the interface from which to capture as the main wired or wireless interface used by your computer to connect to the Internet. If unsure, guess and revisit this step later if your capture is not successful. Uncheck “capture packets in promiscuous mode”. This mode is useful to over-hear packets sent to/from other computers on broadcast networks. We only want to record packets sent to/from your computer. Leave other options at their default values. The capture filter, if present, is used to prevent the capture of other traffic your computer may send or re-ceive. On Wireshark 1.8, the capture filter box is present directly on the options screen, but on Wireshark 1.9, you set a capture filter by double-clicking on the interface.Figure 2: Setting up the capture options4.After the capture is started, repeat the wget/curl command above. This time, the packets willalso be recorded by Wireshark.5.After the command is complete, return to Wireshark and stop the trace. You should now have ashort trace similar to that shown in the figure below, along with the output of a traceroute you ran earlier to the corresponding server.Figure 3: Trace of wget/curl traffic showing the details of the IP headerStep 2: Inspect the TraceSelect any packet in the trace and expand the IP header fields (using the “+” expander or icon) to see the details. You can simply click on a packet to select it (in the top panel). You will see details of its structure (in the middle panel) and the bytes that make up the packet (in the bottom panel). Our interest is the IP header, and you may ignore the other higher and lower layer protocols. When you click on parts of the IP header, you will see the bytes that correspond to the part highlighted in the bottom panel. We have expanded the IP header and clicked on all the IP header fields in the figure above.Let us go over the fields in turn:•The version field is set to 4. This is “IPv4” after all.•Then there is the header length field. Observe by looking at the bytes selected in the packet da-ta that version and header length are both packed into a single byte.•The Differentiated Services field contains bit flags to indicate whether the packet should be handled with quality of service and congestion indications at routers.•Then there is the Total Length field.•Next is the Identification field, which is used for grouping fragments, when a large IP packet is sent as multiple smaller pieces called fragments. It is followed by the Flags and the Fragmentoffset fields, which also relate to fragmentation. Observe they share bytes.•Then there is the Time to live or TTL field, followed by the Protocol field.•Next comes the header checksum. Is your header checksum carrying 0 and flagged as incorrect for IP packets sent from your computer to the remote server? On some computers, the operat-ing system software leaves the header checksum blank (zero) for the NIC to compute and fill in as the packet is sent. This is called protocol offloading. It happens after Wireshark sees thepacket, which causes Wireshark to believe that the checksum is wrong and flag it with a differ-ent color to signal a problem. A similar issue may happen for the TCP checksum. You can remove these false errors if they are occurring by telling Wireshark not to validate the checksums. Select “Preferences” from the Wireshark menus and expand the “Protocols” area. Look under the list until you come to IP v4. Uncheck “Validate checksum if possible”. Similarly, you may uncheckchecksum validation for TCP if applicable to your case.•The last fields in the header are the normally the source and destination address. It is possible for there to be IP options, but these are unlikely in standard web traffic.•The IP header is followed by the IP payload. This makes up the rest of the packet, starting with the next higher layer header, TCP in our case, but not including any link layer trailer (e.g., Ether-net padding).Step 3: IP Packet StructureTo show your understanding of IP, sketch a figure of an IP packet you studied. It should show the position and size in bytes of the IP header fields as you can observe using Wireshark.Since you cannot easily de-termine sub-byte sizes, group any IP fields that are packed into the same bytes. Your figure can simply show the frame as a long, thin rectangle. Try not to look at the figure of an IPv4 packet in your text; check it afterwards to note and investigate any differences.To work out sizes, observe that when you click on a protocol block in the middle panel (the block itself, not the “+” expander) Wireshark will highlight the corresponding bytes in the packet in the lower panel, and display the length at the bottom of the window. You may also use the overall packet size shown in the Length column or Frame detail block. Note that this method will not tell you sub-byte positions.By looking at the IP packets in your trace, answer these questions:1.What are the IP addresses of your computer and the remote server?2.Does the Total Length field include the IP header plus IP payload, or just the IP payload?3.How does the value of the Identification field change or stay the same for different packets? Forinstance, does it hold the same value for all packets in a TCP connection or does it differ for each packet? Is it the same in both directions? Can you see any pattern if the value does change?4.What is the initial value of the TTL field for packets sent from your computer? Is it the maximumpossible value, or some lower value?5.How can you tell from looking at a packet that it has not been fragmented? Most often IP pack-ets in normal operation are not fragmented. But the receiver must have a way to be sure. Hint: you may need to read your text to confirm a guess.6.What is the length of the IP Header and how is this encoded in the header length field? Hint: no-tice that only 4 bits are used for this field, as the version takes up the other 4 bits of the byte.You may guess and check your text.Step 4: Internet PathsThe source and destination IP addresses in an IP packet denote the endpoints of an Internet path, not the IP routers on the network path the packet travels from the source to the destination. traceroute is a utility for discovering this path. It works by eliciting responses (ICMP TTL Exceeded messages) from the router 1 hop away from the source towards the destination, then 2 hops away from the source, then 3 hops, and so forth until the destination is reached. The responses will identify the IP address of the router. The output from traceroute normally prints the information for one hop per line, including the measured round trip times and IP address and DNS names of the router. The DNS name is handy for working out the organization to which the router belongs. Since traceroute takes advantage of common router implementations, there is no guarantee that it will work for all routers along the path, and it is usual to see “*” re sponses when it fails for some portions of the path.Using the traceroute output, sketch a drawing of the network path. If you are using the supplied trace, note that we have provided the corresponding traceroute output as a separate file.Show your computer (lefthand side) and the remote server (righthand side), both with IP addresses, as well as the routers along the path between them numbered by their distance on hops from the start of the path. You can find the IP address of your computer and the remote server on the packets in the trace that you captured. The output of traceroute will tell you the hop number for each router.To finish your drawing, label the routers along the path with the name of the real-world organization to which they belong. To do this, you will need to interpret the domain names of the routers given by traceroute. If you are unsure, label the routers with the domain name of what you take to be the or-ganization. Ignore or leave blank any routers for which there is no domain name (or no IP address).This is not an exact science, so we will give some examples. Suppose that traceroute identifies a router along the path by the domain name . Normally, we can ig-nore at least the first part of the name, since it identifies different computers in the same organization and not different organizations. Thus we can ignore at least “arouter” in the domain name. For ge-neric top-level domains, like “.com” and “.edu”, the last two domains give the domain name of the or-ganization. So for our example, it is “”. To translate this domain name into the real-world name of an organization, we might search for it on the web. You will quickly find that is the University of Washington. This means tha t “cac” portion is an internal structure in the University of Washington, and not important for the organization name. You would write “University of Washington” on your figure for any routers with domain names of the form *. Alternatively, consider a router with a domain name like .au. Again, we ignore at least the “arouter” part as indicating a computer within a specific organization. For country-code top-level domains like “.au” (for Australia) the last three domain s in the name will normally give the organization. In this case the organization’s domain name is .au. Using a web search, we find this domain represents AARNET, Australia’s research and education network. The “syd” por-tion is internal structure, and a good guess is that it means the router is located in the Sydney part of AARNET. So for all routers with domain names of the form *.au, you would write“AARNET” on your figure. While there are no guarantees, you should be able to reason similarly and at least give the domain name of the organizations near the ends of the path.Step 5: IP Header ChecksumWe will now look at the IP header checksum calculation by validating a packet. The checksum algorithm adds the header bytes 16 bits at a time. It is computed so that re-computing the sum across the entire IP header (including the checksum value) will produce the result of zero. A complicating factor for us is that this is done using 1s complement arithmetic, rather than 2s complement arithmetic that is normally used for computing. The steps below explain how to perform the necessary computation.From the trace, pick a packet sent from the remote server to your computer and check that you have a non-zero value in the checksum field. The checksum value sent over the network will be non-zero, so if you have a zero value it is because of the capture setup. Try a packet that has an IP header of 20 bytes, the minimum header size when there are no options, to make this exercise easier.Follow these steps to check that the checksum value is correct:1.Divide the header into 10 two byte (16 bit) words. Each word will be 4 hexadecimal digits shownin the packet data panel in the bottom of the Wireshark window, e.g., 05 8c2.Add these 10 words using regular addition. You may add them with a hexadecimal calculator(Google to find one), or convert them to decimal, add them, and convert them back to hexadec-imal. Do whatever is easiest.3.To compute the 1s complement sum from your addition so far, take any leading digits (beyondthe 4 digits of the word size) and add them back to the remainder. For example: 5a432 will be-come a432 + 5= a437.4.The end result should be 0xffff. This is actually zero in 1s complement form, or more precise-ly 0xffff is -0 (negative zero) while 0x0000 is +0 (positive zero).If you cannot get your sum to come out and are sure that the checksum must be wrong, you can get Wireshark to check it. See whether it says “[correct]” already. If it does not then use the menus to go to Preferenc es, expand Protocols, choose IPv4 from the list, and check “validate header checksum”. Now Wireshark will check the checksum and tell you if it is correct.Extra - Explore on your ownWe encourage you to explore IP on your own once you have completed this lab. Some ideas: •Read about and experiment with IPv6. Modern operating systems already include support for IPv6, so you may be able to capture IPv6 traffic on your network. You can also “join the IPv6”backbone by tunneling to an IPv6 provider.•Learn about tunnels, which wrap an IP packet within another IP header.•Read about IP geolocation. It is the process of assigning a geographical location to an IP address using measurements or clues from its name administrative databases. Try a geolocation service.•Learn about IPsec or IP security. It provides confidentiality and authentication for IP packets, and is often used as part of VPNs.。
wireshark练习及答案lab-arpattack
Lab Exercise – Snooping on other traffic in Lab through ARP Poison AttackObjective - To demonstrate a Man in the middle (MITM) hack with the Ettercap tool.Ettercap is a multipurpose sniffer/interceptor/logger for switched LAN, and pretty much the Swiss army knife of ARP poisoning. Every security researcher should include it in his toolbox. It is included in Backtrack – the popular Linux distribution. Ettercap features a GUI and a command line text mode tool.1. Download Ettercap from /~kevin/com320/labs/ettercap.exe.2. Follow the instructions to install it. See figure below.Figure 1: Ettercap installation in progress3. Go to Run button in bottom left and type "ettercap". You should see it appear as in the following fig-ure. Of course, you can also run it from All programs menu in Windows as well.Figure 2: Running Ettercap in Lab4. Next select Unified Sniffing from the Sniff menu option as show in figure 3.Figure 3: Step 1 in process of snooping5. Select the first Etternet interface (in this case it is “eXtreme Gigabit Ethernet Driver” network interface (see figure 4).Figure 4: Selection of network interface1.Next you should be presented with a series of menu options including Start, Targets, Hosts, ViewMitm, Filters, Logging and Plugins. You should select the Hosts option and choose Scan for Hosts.See figure 5.Figure 5: Selection of hosts to scan on LAN2.Once you select Scan for hosts, you should see a pop up window displaying the progess when all255 hosts on the local network are scanned. See figure 6.Figure 6: Hosts being scanned locally3.Next you should select Hosts List from the Hosts menu. You should then see a screen similar tofigure 7 with a list of hosts that have been found.Figure 7: Hosts that were scanned locally4.Please ask permission from a colleague to allow you to select their computer to be scanned.They should confirm their IP address to you. That can be found as in previous weeks by typing cmd in the windows start menu and opening a command prompt. Then in the command prompt, type ipconfig and note the ipv4 address displayed. You may need to scroll up to see it in the command prompt window. Here in figure 8, host 193.61.190.73 is being selected for scanning.Figure 8: host 193.61.190.73 is being selected for scanning5.Once you have the target selected with your mouse, then select the Add to Target 1 button. Seefigure 9.Figure 9: host 193.61.190.73 is being added to Target 1.6.Select the Targets menu option and then select C urrent Targets as shown in figure 10.Figure 10: Targets being selected7.Now you should only see your class mates computer shown as in figure 11.Figure 11: host selected for attack8.Now go to the mitm option as show in figure 12. Select Arp poisoning.Figure 12: ARP Poisoning selection9.Once Arp poisoning is selected, you will be presented with the dialogue window as shown in fig-ure 13. Simply click OK.Figure 13: Options for ARP poison attack10.You will then be presented with a window once again which is similar to figure 14. The ARP poi-son attack however is happening underneath. You now have access to all the traffic which is be-ing routed to the IP address which you have entered earlier. We will now move to Wireshark to see the power of an ARP poison mitm attack.Figure 14: Main window after attack has been started11.Open Wireshark by typing wireshark at the run programs option. You will then select the usualEtternet Intel Interface and Start a capture. In the display filter, type the following:ip.src==yourfriendsipaddress&&tcp.port==80 e.g. ip.src==193.61.191.88 &&tcp.port==80. See figure 15.Figure 15: Sample scan of web traffic on IP address 193.61.191.8812.Get your friend to browse to any site. In this example below, I have gone to a CNN page whichdiscusses Coca-Cola remarks from the CEO. It is at/2013/02/05/business/coke-ceo-muhtar-kent-capitalism-evolve/Figure 16: Sample page surfed.13.Once your friend has started to surf, you should start to see a lot of HTTP and TCP packets ap-pear in your packet list window. After some time you can stop the capture. You may also choose to stop the mitm attack. You can always resume the attack to see ‘fresh’ traffic remotely. You should then select the page that he surfed through e.g. CNN and right click on it as displayed be-low and select Follow TCP Stream.Figure17: Sample page from CNN being selected in the Wireshark interface. Note the ip address and port filtering14.The TCP Follow Stream should lead you to a window such as displayed below. Note the contentsof the GET and HOST on the first two lines. When we put them together we get the location of the site visited which is /2013/02/05/business/coke-ceo-muhtar-kent-capitalism-evolve/. This should now show you that all surfing can be snooped on a LAN.Figure18: CNN page after selecting Follow TCP Stream20.Now get your friend to go to a site which requires a login or passing information such as cnnweather at: /weather. Here type a city such as Belfast:21. Next, examine the wireshark tr ace, you should see a captured packet with “cit y-Search/json/true HTTP/1.1” showing the ‘sensitive data’.22.Finally, please return to the ettercap program and select Mitm and click on Stop mitm attack(s).This will ensure that the ARP tables return to normal and no unnecessary snooping of a newco-mer to your friend’s machine takes place. See figure 19.Figure19: Stopping the man in the middle ARP attack23.The following popup windows should confirm that all man in the middle attacks have stopped.People are now safe again in the lab.Figure 20: Confirmation of mitm attack being stopped.24.Finally, you can exit the program.Figure 21: Ensuring you exit the attack vector programPlease be responsible with this new knowledge……。
《计算机网络》实验一 使用Wireshark分析IP协议
一、实验目的及要求:1、分析IP协议,熟知IP协议数据包各个字段的含义与作用;2、分析IP数据报分片,熟悉IP数据包的传递方式。
二、实验设备:与因特网连接的计算机,操作系统为Windows,安装有Wireshark、IE浏览器等软件。
三、实验原理:1、DHCP(动态主机配置协议)报文说明:(1)DHCP-DISCOVER:DHCP客户端广播发送的,用来查找网络中可用的DHCP服务器。
(2)DHCP-OFFER:DHCP服务器用来响应客户端的DHCP-DISCOVER请求,并为客户端指定相应配置参数。
(3)DHCP-REQUEST:DHCP客户端广播发送DHCP服务器,用来请求配置参数或者续借租用。
(4)DHCP-ACK:DHCP服务器通知客户端可以使用分配的IP地址和配置参数。
(5)DHCP-NAK:DHCP服务器通知客户端地址请求不正确或者租期已过期,续租失败。
(6)DHCP-RELEASE:DHCP客户端主动向DHCP服务器发送,告知服务器该客户端不再需要分配的IP地址。
(7)DHCP-DECLINE:DHCP客户端发现地址冲突或者由于其它原因导致地址不能使用,则发送DHCP-DECLINE报文,通知服务器所分配的IP地址不可用。
(8)DHCP-INFORM:DHCP客户端已有IP地址,用它来向服务器请求其它配置参数2、pingPING(Packet Internet Groper),因特网包探索器,用于测试网络连接量的程序。
Ping是工作在TCP/IP网络体系结构中应用层的一个服务命令,主要是向特定的目的主机发送ICMP (Internet Control Message Protocol因特网报文控制协议)Echo请求报文,测试目的站是否可达及了解其有关状态。
四、实验内容和步骤:1、用300字左右,描述你对IP协议的认识;IP协议,即互联网协议(Internet Protocol),是互联网技术的核心组成部分,它定义了数据如何在互联网中传输。
Wireshark_INTRO_Solution_July_22_2007
WIRESHARK LAB#1 SOLUTIONAnswers were taken from students with correct lab reports and show what should be the ideal format of your lab report.1. List the different protocols that appear in the protocol column in the unfiltered packet-listing window in step 7 above.Answer:The following protocols appeared in the protocol column in the unfiltered packet listing window after downloading a webpage: TCP, UDP, HTTP, DNS.2. How long did it take from when the HTTP GET message was sent until the HTTP OK reply was received? (By default, the value of the Time column in the packet listing window is the amount of time, in seconds, since Wireshark tracing began. To display the Time field in time-of-day format, select the Wireshark View pull down menu, then select Time Display Format, then select Time-of-day.)Answer:If we look at the frame section of the GET request we see that the time the packet arrived is 11:43:13.422848000The same section for the HTTP OK shows an arrival time of11:43:13.43960400The difference of these 2 times gives.43960400 - .426032000 = 0.013572 seconds3. What is the Internet address of the (also known as)? What is the Internet address of your computer?Answer:If we look at the IP section of the GET request, the source and destination are shownThe source is the local machine’s address and the destination is the web server’s public My (local machine’s) address = 128.238.244.28IP address 128.119.245.12 = .This can also be seen during the DNS query4. Print the two HTTP messages displayed in step 9 above. To do so, select Print from the Wireshark File command menu, and select “Selected Packet Only” and “Print as displayed” and then click OK.Answer:Here is the information for the HTTP GET and OK packets:HTTP GET:Frame 4 (862 bytes on wire, 862 bytes captured)Ethernet II, Src: Netgear_61:8e:6d (00:09:5b:61:8e:6d), Dst: WestellT_9f:92:b9(00:0f:db:9f:92:b9)Internet Protocol, Src: 192.168.1.46 (192.168.1.46), Dst: 128.119.245.12(128.119.245.12)Transmission Control Protocol, Src Port: 1474 (1474), Dst Port: http (80), Seq: 1, Ack: 1, Len: 808Hypertext Transfer ProtocolGET /wireshark-labs/INTRO-wireshark-file1.html HTTP/1.1\r\nHost: \r\nUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4)Gecko/20070515 Firefox/2.0.0.4\r\nAccept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,im age/png,*/*;q=0.5\r\nAccept-Language: en-us,en;q=0.5\r\nAccept-Encoding: gzip,deflate\r\nAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\nKeep-Alive: 300\r\nConnection: keep-alive\r\nHTTP OK:Frame 6 (439 bytes on wire, 439 bytes captured)Ethernet II, Src: WestellT_9f:92:b9 (00:0f:db:9f:92:b9), Dst: Netgear_61:8e:6d(00:09:5b:61:8e:6d)Internet Protocol, Src: 128.119.245.12 (128.119.245.12), Dst: 192.168.1.46(192.168.1.46)Transmission Control Protocol, Src Port: http (80), Dst Port: 1474 (1474), Seq: 1, Ack: 809, Len: 385Hypertext Transfer ProtocolHTTP/1.1 200 OK\r\nDate: Thu, 07 Jun 2007 18:09:01 GMT\r\nServer: Apache/2.0.52 (CentOS)\r\nLast-Modified: Thu, 07 Jun 2007 18:08:01 GMT\r\nETag: "d6c69-50-cb94a240"\r\nAccept-Ranges: bytes\r\nContent-Length: 80Keep-Alive: timeout=10, max=100\r\nConnection: Keep-Alive\r\nContent-Type: text/html; charset=ISO-8859-1\r\n\r\nLine-based text data: text/html。
计算机网络实验1:预习报告答案
计算机网络实验1:预习报告答案大连理工大学实验预习报告学院(系):专业:班级:姓名:学号:组:_______;实验时间:实验室:实验平台:讲师签名:分数:注:预习题必须每人做一份,回答部分只允许手写,在上实验课前交;否则,将不允许做实验。
填写实验报告题头部分时,组号和实验台号相同,实验台号参照实验室实验台上数字标识。
实验名称:网络协议分析工具Wireshark的使用1、从课程网站下载wireshark的安装文件,把wireshark安装在自己宿舍中的计算机上。
没有电脑的学生,请和有电脑的学生一起做这项工作。
(1)请回答Wireshark的安装步骤;打开安装包,按提示安装。
(2)根据本课程PPT中的解释回答Wireshark的简要用法;具体为capture->interface->(选择你的网卡)start此时,数据接口将显示当前网卡的所有数据和协议(3)尝试使用显示过滤器和捕获过滤器,思考并回答二者的区别和优缺点。
捕获过滤器:用于确定在捕获结果中记录哪些信息。
你需要在开始抓拍之前设置它。
显示过滤器(displayfilters):在捕捉结果中进行详细查找。
他们可以在得到捕捉结果后随意修改这两个过滤器的用途不同。
捕捉过滤器是数据经过的第一层过滤器,它用于控制捕捉数据的数量,以避免产生过大的日志文件。
显示过滤器是一个功能更强大(更复杂)的过滤器。
它允许您在日志文件中快速准确地找到所需的记录。
两种过滤器使用的语法是完全不同的。
2、查询相关书籍,复习arp协议。
(1)请简要回答ARP的工作过程。
(2)请简要回答windows环境下“arp”命令的用法(3)请回答arp协议的报文格式,并解释每个字段。
假设主机a和主机B在同一网段中,主机a希望向主机B发送信息。
具体的地址解析过程如下:(1)主机a首先检查自己的ARP表,以确定它是否包含与主机B对应的ARP表项。
如果找到对应的MAC地址,主机a直接使用ARP表中的MAC地址来帧和封装IP数据包发送给主机b。
实验1 Wireshark协议分析-HTTP协议
实验二利用Wireshark分析协议HTTP一、实验目的分析HTTP协议二、实验环境与因特网连接的计算机,操作系统为Windows,安装有Wireshark、IE等软件。
三、实验步骤1、利用Wireshark俘获HTTP分组(1)在进行跟踪之前,我们首先清空Web 浏览器的高速缓存来确保Web网页是从网络中获取的,而不是从高速缓冲中取得的。
打开浏览器,找到Internet选项,点击后出现如图1所示的界面。
以IE浏览器为例,步骤为:点击浏览器右上角的“工具”-“Internet选项”。
图1 Internet选项之后,还要在客户端清空DNS高速缓存,以确保Web服务器域名到IP地址的映射是从网络中请求的。
在Windows系列的机器上,可在命令提示行输入ipconfig/flushdns 完成操作(如图2所示);具体步骤及Linux、MAC等系统的清空方法请参见:/blog/1674716。
图2 命令提示行输入ipconfig/flushdns完成操作(2)启动Wireshark 分组俘获器。
(3)在Web 浏览器中输入:/ (重庆大学网站)。
(4)停止分组俘获。
图3 利用Wireshark俘获的HTTP分组在URL 中,是一个具体的web 服务器的主机名。
最前面有两个DNS分组。
第一个分组是将主机名转换成为对应的IP 地址的请求,第二个分组包含了转换的结果。
这个转换是必要的,因为网络层协议——IP协议,是通过点分十进制来表示因特网主机的,而不是通过 这样的主机名。
当输入URL 时,将要求Web服务器从主机上请求数据,但首先Web浏览器必须确定这个主机的IP地址。
小提示--域名和主机关系举例:域名下,有主机server1和server2,其主机全名就是和。
随着转换的完成,Web浏览器与Web服务器建立一个TCP连接。
最后,Web 浏览器使用已建立好的TCP连接来发送请求“GET/HTTP/1.1”。
这个分组描述了要求的行为(“GET”)及文件(只写“/”是因为我们没有指定额外的文件名),还有所用到的协议的版本(“HTTP/1.1”)。
通信网络基础抓包作业答案
网络协议数据获取与TC P/IP协议分析一、实验环境介绍网络接入方式:校园网宽带接入,IP获取方式:DHCP;操作系统为w i ndow s7旗舰版;本机MAC地址为5c:f9:dd:70:6a:89,IP地址为10.104.5.53。
图1 网络状态截图二、实验步骤1. 启动wire shark;2. 启动一个网页浏览器,并键入一个U RL地址,如:www.baidu.com。
注意此时不要按下回车键;3. 清除电脑中的D NS缓存,启动wire shark,开始抓包;4. 在浏览期网页位置按下回车键,开始访问指定的网页。
5. 一旦网页内容下载完毕,立即停止Mi croso f t Networ k Monito r抓包,并将抓到的数据包存入文件中,同时将显示的网页存储下来,以便后面参考。
三、实验过程使用wire shark前清除DNS缓存截图如下。
图2 清除DNS缓存抓取协议如下图所示:图3 抓取协议四、协议分析1. 抓取的协议类型检查在Mic rosof t Networ k Monito r顶端窗口的协议一列,确认你已经抓到了DNS、TCP和HTTP数据包。
答:由图3可看出抓到了DNS、TCP、HTTP数据包。
2. 以太网帧,IP分组和U D P数据报(1) 检查客户端发出的第一个D NS分组a.确定客户端的以太网地址和IP地址答:如图4,客户端的MA C地址为5c:f9:dd:70:6a:89;IPv4地址为:10.104.5.53。
b.以太网帧结构的TYPE字段是什么内容?答:如图所示,以太网帧结构的TYPE字段为:0x0800,表示该帧是I P协议。
c.目的以太网地址和目的I P地址分别是什么?这些地址对应哪些计算机?解释这些结果与你连接到In ter net 的计算机有关系。
wireshark练习及答案lab-udp
Lab Exercise – UDPObjectiveTo look at the details of UDP (User Datagram Protocol). UDP is a transport protocol used throughout the Internet as an alternative to TCP when reliability is not required. It is covered in §6.4 of your text. Re-view that section before doing this lab.The trace file is here: /~kevin/com320/labs/wireshark/trace-udp.pcapStep 1: Capture a TraceThere are many ways to cause your computer to send and receive UDP messages since UDP is widely used as a transport protocol. The easiest options are to:•Do nothing but wait for a while. UDP is used for many “system protocols” that typically run in the background and produce small amounts of traffic, e.g., DHCP for IP address assignment and NTP for time synchronization.•Use your browser to visit sites. UDP is used by DNS for resolving domain names to IP addresses, so visiting fresh sites will cause DNS traffic to be sent. Be careful not to visit unsafe sites; pickrecommended sites or sites you know about but have not visited recently. Simply browsing the web is likely to cause a steady stream of DNS traffic.•Start up a voice-over-IP call with your favorite client. UDP is used by RTP, which is the protocol commonly used to carry media samples in a voice or video call over the Internet.Proceed as follows to capture a trace of UDP traffic; alternatively, you may use a supplied trace:unch Wireshark and start a capture with a filter of “udp“.Figure 1: Setting up the capture options2.When the capture is started, perform some activities that will generate UDP traffic. We de-scribed several options above, e.g., browse the web or start a short VoIP call.3.Wait a little while (say 60 seconds) after you have stopped your activity to also observe anybackground UDP traffic. It is likely that you will observe a trickle of UDP traffic because system activity often uses UDP to communicate. We want to see some of this activity.e the Wireshark menus or buttons to stop the capture. You should now have a trace with pos-sibly many UDP packets. Our example is shown below. We have selected a packet and expand-ed the detail of the UDP header.Figure 2: Trace of UDP traffic showing the details of the UDP headerStep 2: Inspect the TraceDifferent computers are likely to capture different kinds of UDP traffic depending on the network setup and local activity. Observe that the protocol column is likely to show multiple protocols, none of which is UDP. This is because the listed protocol is an application protocol layered on top of UDP. Wireshark gives the name of the application protocol, not the (UDP) transport protocol unless Wireshark cannot determine the application protocol. However, even if the packets are listed as an application protocol, they will have a UDP protocol header for us to study, following the IP and lower-layer protocol headers. Select different packets in the trace (in the top panel) and browse the expanded UDP header (in the mid-dle panel). You will see that it contains the following fields:•Source Port, the port from which the UDP message is sent. It is given as a number and possibly a text name; names are given to port values that are registered for use with a specific application.•Destination Port. This is the port number and possibly name to which the UDP message is des-tined. Ports are the only form of addressing in UDP. There computer is identified using the IPaddress in the lower IP layer.•Length. The length of the UDP message.•Checksum. A checksum over the message that is used to validate its contents. Is your checksum carrying 0 and flagged as incorrect for UDP messages sent from your computer? On some com-puters, the operating system software leaves the checksum blank (zero) for the NIC to compute and fill in as the packet is sent. This is called protocol offloading. It happens after Wireshark sees the packet, which causes Wireshark to believe that the checksum is wrong and flag it with a dif-ferent color to signal a problem. You can remove these false errors if they are occurring by tell-ing Wireshark not to validate the checksums. Select “Preferences” from the Wireshark menusand expand the “Protocols” area. Look under the list until you come to UDP. Uncheck “Validate checksum if possible”.That is it. The UDP header has different values for different messages, but as you can see, it is short and sweet. The remainder of the message is the UDP payload that is normally identified the higher-layer pro-tocol that it carries, e.g., DNS, or RTP.Step 3: UDP Message StructureTo check your understanding of UDP, you should sketch a figure of the UDP message structure as you ob-served. It should show the position of the IP header, UDP header, and UDP payload. Within the UDP header, show the position and size of each UDP field you can observe using Wireshark. Your figure can simply show the message as a long, thin rectangle.Try not to look at the figure of a UDP segment in the answer on next page. To work out sizes, observe that when you click on a protocol block in the middle panel (the block itself, not the “+” expander) then Wireshark will highlight the bytes it corresponds to in the packet in the lower panel and display the length at the bottom of the window.By looking at the details of the UDP messages in your trace, answer these questions:1.What does the Length field include? The UDP payload, UDP payload and UDP header, or UDPpayload, UDP header, and lower layer headers?2.How long in bits is the UDP checksum?3.How long in bytes is the entire UDP header?(Please note that answers are on next page).Solutions – Step 3 UDP Message StructureFigure 1: Structure of a UDP messageThis drawing shows the same UDP header fields as in the book in a slightly different format and with lengths given in bytes, not bits. It also shows the relation of the IP header and UDP payload to the UDP header.The answers to the questions are:1.The Length field gives the length of the UDP payload plus the UDP header.2.The checksum is 16 bits long.3.The UDP header is 8 bytes long.[END]Step 4: UDP UsageTo complete our understanding of UDP, we will look at how UDP is used in practice as a transport by ap-plications. Beginning with IP, the next lower protocol layer, there are several issues we can consider. A first issue is how IP knows that the next higher protocol layer is UDP. The answer is that there is a Proto-col field in the IP header that contains this information.1.Give the value of the IP Protocol field that identifies the upper layer protocol as UDP.A second issue is how UDP messages are typically addressed at the IP layer. You might be surprised to find UDP messages in your trace that neither come from your computer or are sent only to your com-puter. You can see this by sorting on the Source and Destination columns. The source and destinations will be domain names, if Network layer name resolution is turned, and otherwise IP addresses. (You can toggle this setting using the View menu and selecting Name resolution.) You can find out the IP address of your computer using the “ipconfig” command (Windows).The reason you may find UDP messages without your com puter’s IP address as either the source or des-tination IP address is that UDP is widely used as part of system protocols. These protocols often send messages to all local computers who are interested in them using broadcast and multicast addresses. In our traces, we find DNS (the domain name system), MDNS (DNS traffic that uses IP multicast), NTP (for time synchronization), NBNS (NetBIOS traffic), DHCP (for IP address assignment), SSDP (a service discov-ery protocol), STUN (a NAT traversal protocol), RTP (for carrying audio and video samples), and more. Your trace may have other protocols you have not heard about; it is OK, as there are a lot of protocols out there. You can look them up on the web for fun.2.Examine the UDP messages and give the destination IP addresses that are used when your com-puter is neither the source IP address nor the destination IP address. (If you have only your com-puter as the source or destination IP address then you may use the supplied trace.)Finally, let us look at the lengths of typical UDP messages. We know that UDP messages can be as large as roughly 64Kbytes. But as you browse you should see that most UDP messages are much shorter than this maximum, so that UDP messages fit in a single packet.3.What is the typical size of UDP messages in your trace?(Please note that answers are on next page).Solutions to Step 4: UDP UsageThe answers to the questions are:1.The IP Protocol field value of 17 indicates UDP.2. A variety of broadcast and multicast addresses may be found. These include the Internet broad-cast address of 255.255.255.255, subnet broadcast addresses such as 192.168.255.255 (where the 192.168 portion is the subnet number and the .255.255 portion means broadcast), and mul-ticast IP addresses such as 224.0.xx.xx (such as 224.0.0.251 for multicast DNS).3.This answer will vary with your trace. Most often they are a few hundred bytes or less, and oftenmay be around 100 bytes. That is, many messages are relatively short packets.。
实验一(WireShark)
实验一、Packet Tracer中TCP/IP 协议与OSI模型Wireshark工具的使用实验目的:复习Packet Tracer的用法;查看并叙述TCP/IP协议族及OSI模型构成;掌握Wireshark 工具的使用一、Packet Tracer中TCP/IP 协议与OSI模型操作要求见附录文档“e1-2482”。
操作完成后,在EventList列中,找出一个从WebClient 到WebServer的TCP协议报文,下图为单击“Info”信息后的参考图回答下列问题:1、OSI模型中In Layers 与Out Layers各包含那些信息?2、为什么OSI模型中Layer5—Layer7没有任何信息3、Layer2中的头有哪些信息?4、Layer3中的头有哪些信息?5、Layer4中的头有哪些信息?6、Web Client 与Web server的IP地址分别为多少?7、在In Layers中源端口号、目的端口号分别为多少?分别代表客户机还是服务器?8、在Out Layers中源端口号、目的端口号分别为多少?分别代表客户机还是服务器?9、分别查看“Inbound PDU details”与“Outbound PDU details”。
比较两者的共同点与不同点。
二、Wireshark工具的使用参考以下文档。
如果我们通过以下方式对网络协议进行探索,那就会对协议的理解更加深入。
通过观察协议的工作及实际使用它们,即观察两个通信协议实体之间交换的报文系列,研究运行的细节,使协议执行某些动作,观察这些动作的机器后果。
所有这些都能够在仿真环境下或在因特网等真实环境下完成。
本课程有关实验采用后一种方式进行,我们使用个人计算机运行各种网络应用程序,在计算机上观察网络协议及在因特网中执行的协议进行报文交换过程。
观察在通信实体之间的报文交换过程的基本工具称为分组嗅探器(packet sniffer),分组嗅探器捕捉(嗅探)由你使用的计算机发出和或接收的信息。
wireshark练习及答案lab-http
Lab Exercise – HTTPObjectiveHTTP (HyperText Transfer Protocol) is the main protocol underlying the Web. The trace file is here: /~kevin/com320/labs/wireshark/trace-http.pcapStep 1: Capture a TraceCapture a trace of your browser making HTTP requests as follows; alternatively, you may use a supplied trace. Now that we seen how a GET works, we will observe your browser as it makes HTTP requests. Browser behavior can be quite complex, using more HTTP features than the basic exchange, so we will set up a simple scenario. We are assuming that your browser will use HTTP in this simple scenario rather than newer Web protocols such as SPDY, and if this is not the case you will need to disable SPDY.e your browser to find two URLs with which to experiment, both of which are HTTP (not HTTPS)URLs with no special port. The first URL should be that of a small to medium-sized image,whether .jpg, .gif, or .png. We want some static content without embedded resources. You canoften find such a URL by right-clicking on unlinked images in web pages to tell your browser toopen the URL of the image directly. The second URL should be the home page of some majorweb site that you would like to study. It will be complex by comparison. Visit both URLs to check that they work, then keep them handy outside of the browser so you can cut-and-paste them.2.Prepare your browser by reducing HTTP activity and clearing the cache. Apart from one freshtab that you will use, close all other tabs, windows to minimize HTTP traffic.unch Wireshark and start a capture with a filter of “tcp port 80”.We use this filter be-cause there is no shorthand for HTTP, but HTTP is normally carried on TCP port 80.Figure 2: Setting up the capture options4.Fetch the following sequence of URLs, after you wait for a moment to check that there is noHTTP traffic. If there is HTTP traffic then you need to find and close the application that is caus-ing it. Otherwise your trace will have too much HTTP traffic for you to understand. You will paste each URL into the browser URL bar and press Enter to fetch it. Do not type the URL, as this may cause the browser to generate additional HTTP requests as it tries to auto-complete your typing.a.Fetch the first static image URL by pasting the URL into the browser bar and pressing“Enter” or whatever is required to run your browser.b.Wait 10 seconds, and re-fetch the static image URL. Do this in the same manner, andwithout using the “Reload” button of your browser, lest it trigger other behavior.c.Wait another 10 seconds, and fetch the second home page URL.5.Stop the capture after the fetches are complete. You should have a window full of trace in whichthe protocol of some packets is listed as HTTP – if you do not have any HTTP packets there is a problem with the setup such as your browser using SPDY instead of HTTP to fetch web pages.Figure 3: Trace of HTTP traffic showing the details of the HTTP headerStep 2: Inspect the TraceTo focus on HTTP traffic, enter and apply a filter expression of“http”. This filter will show HTTP re-quests and responses, but not the individual packets that are involved. Recall that an HTTP response car-rying content will normally be spread across multiple packets. When the last packet in the response ar-rives, Wireshark assembles the complete response and tags the packet with protocol HTTP. The earlier packets are simply TCP segments carrying data; the last packet tagged HTTP includes a list of all the ear-lier packets used to make the response. A similar process occurs for the request, but in this case it is common for a request to fit in a single packet. With the filter expression of “http” we will hide the in-termediate TCP packets and see only the HTTP requests and responses. With this filter, your Wireshark display should be similar to the figure showing our example.Select the first GET in the trace, and expand its HTTP block. This will let us inspect the details of an HTTP request. Observe that the HTTP header follows the TCP and IP headers, as HTTP is an application proto-col that is transported using TCP/IP. To view it, select the packet, find the HTTP block in the middle panel, and expand it (by using the “+” expander or icon). This block is expanded in our figure.Explore the headers that are sent along with the request. First, you will see the GET method at the start of the request, including details such as the path. Then you will see a series of headers in the form of tagged parameters. There may be many headers, and the choice of headers and their values vary from browser to browser. See if you have any of these common headers:•Host. A mandatory header, it identifies the name (and port) of the server.•User-Agent. The kind of browser and its capabilities.•Accept, Accept-Encoding, Accept-Charset, Accept-Language. Descriptions of the formats that will be accepted in the response, e.g., text/html, including its encoding, e.g., gzip, and language.•Cookie. The name and value of cookies the browser holds for the website.•Cache-Control. Information about how the response can be cached.The request information is sent in a simple text and line-based format. If you look in the bottom panel you can read much of the request directly from the packet itself!Select the response that corresponds to the first GET in the trace, and expand its HTTP block. The Info for this packet will indicate “200 OK” in the case of a normal, successful transfer. You will see that the re-sponse is similar to the request, with a series of headers that follow the “200 OK” status code. However, different headers will be used, and the headers will be followed by the requested content. See if you have any of these common headers:•Server. The kind of server and its capabilities.•Date, Last-Modified. The time of the response and the time the content last changed.•Cache-Control, Expires, Etag. Information about how the response can be cached.Answer the following questions: (answers on next page)1.What is the format of a header line? Give a simple description that fits the headers you see.2.What headers are used to indicate the kind and length of content that is returned in a response?Answers to Inspect the Trace1.Each header line consists of the name of the header field and its value separated by a colon.There can be whitespace before (and after) the value. The line ends with a “carriage return, line feed” pair of characters, often written CRLF or “\r\n”.2.The type of the content is given by the Content-Type header, and its length is normally given bythe Content-Length header. (It is possible but unlikely that these headers are not present.)Step 3: Content CachingThe second fetch in the trace should be a re-fetch of the first URL. This fetch presents an opportunity for us to look at caching in action, since it is highly likely that the image or document has not changed and therefore does not need to be downloaded again. HTTP caching mechanisms should identify this oppor-tunity. We will now see how they work.Select the GET that is a re-fetch of the first GET, and expand its HTTP block. Likely, this will be the second GET in the trace. However, look carefully because your browser may issue other HTTP requests for its own reasons. For example, you might see a GET for /favicon.ico in the trace. This is the browser request-ing the icon for the site to use as part of the browser display. Similarly, if you typed in the URL bar your browser may have issued GETs as part of its auto-completion routine. We are not interested in this background browser activity at the moment.Now find the header that will let the server work out whether it needs to send fresh content. We will ask you about this header shortly. The server will need to send fresh content only if the content has changed since the browser last downloaded it. To work this out, the browser includes a timestamp tak-en from the previous download for the content that it has cached. This header was not present on the first GET since we cleared the browser cache so the browser had no previous download of the content that it could use. In most other respects, this request will be the same as the first time request. Finally, select the response to the re-fetch, and expand its HTTP block. Assuming that caching worked as expected, this response will not contain the content. Instead, the status code of the response will be “304 Not Modified”. This tells the browser that the content is unchanged from its previous copy, and the cached content can then be displayed.Answer the following questions (answer on next page).1.What is the name of the header the browser sends to let the server work out whether to sendfresh content?2.Where exactly does the timestamp value carried by the header come from?Answers to Content Caching1.The header is called “If-Modified-Since”, i.e., it asks the server to send the content if it has beenmodified since a given time.2.The timestamp value comes from the “Last-Modified” header of the most recent download ofthe content. It is a server timestamp for when the content last changed – it is not a timestamp according to the browser clock, and it is not a timestamp of the time of the downloadStep 4: Complex PagesNow let’s examine the third fetch at the end of the trace. This fetch was for a more complex web page that will likely have embedded resources. So the browser will download the initial HTML plus all of the embedded resources needed to render the page, plus other resources that are requested during the ex-ecution of page scripts. As we will see, a single page can involve many GETs!To summarize the GETs for the third page, bring up a HTTP Load Distribution panel. You will find this panel under “Statistics” and “HTTP”. You can filter for the packets that are part of the third fetch by re-moving the packets from the earlier part of the trace by either time or number. For example, use “frame.number>27” or “frame.time_relative>24” for our trace.Looking at this panel will tell you how many requests were made to which servers. Chances are that your fetch will request content from other servers you might not have suspected to build the page. These other servers may include third parties such as content distribution networks, ad networks, and analytics networks. Our panel is shown below – the page fetch involved 95 requests to 4 different serv-ers!Figure 4: HTTP Load Distribution panelFor a different kind of summary of the GETs, bring up a HTTP Packet Counter panel. You will also find this pane l under “Statistics” and “HTTP”, and y ou should filter for the packets that are part of the third fetch as before. This panel will tell you the kinds of request and responses. Our panel is shown in the figure below. You can see that it consists entirely of GET requests that are matched by 200 OK responses. However, there are a variety of other response codes that you might observe in your trace, such as when the resource is already cached.Figure 5: HTTP Packet Counter panelYou might be curious to know what content is being downloaded by all these requests. As well as seeing the URLs in the Info column, you can get a summary of the URLs in a HTTP Request panel under “Statis-tics” and “HTTP”. Each of the individual requests and responses has the same form we saw in an earlier step. Collectively, they are performed in the process of fetching a complete page with a given URL.For a more detailed look a t the overall page load process, use a site such as Google’s PageSpeed or . These sites will test a URL of your choice and generate a report of the page load activity, telling what requests were fetched at what times and giving tips for decreasing the overall page load time. We have shown the beginning of the “waterfall” diagram for the page load corresponding to our trace in the figure below. After the initial HTML resource is fetched there are many subsequent quick fetches for embedded resources such as JavaScript scripts, CSS stylesheets, images, and more.Figure 6: Start of waterfall graph for (from ) Homework - Explore Your Network Explore HTTP on your own once you have finished this lab. Some suggestions:• Study how web pages lead to a pattern of HTTP requests. Many popular web sites have relative-ly complex pages that require many HTTP requests to build. Moreover, these pages may contin-ue to issue “asynchronous” HTTP requests once they appear to have loaded, to load interactive displays or prepare for the next page, etc. You will see this activity when you find HTTP requests that continue after a page is loaded.• Look at video streaming HTTP traffic. We have looked at web HTTP traffic, but other applica-tions make HTTP requests too. It is common for streaming video clients embedded in browsers like Netflix to download content using a HTTP fetches of many small “chunks” of video. If y ou look at other applications, you may find that many of them use HTTP to shift about content, though often on a port different than port 80... .。
wireshark练习及答案lab-dhcp
Lab Exercise – DHCPObjectiveTo see how DHCP (Dynamic Host Configuration Protocol) works. The trace is here: /~kevin/com320/labs/wireshark/trace-dhcp.pcap Network SetupRecall that DHCP is normally used to assign a computer its IP address, as well as other parameters such as the address of the local router. Your computer, the client, uses the DHCP protocol to communicate with a DHCP server on the local network. Other computers on the local network also interact with the DHCP server. In deployments, there are several variations. For example, the local agent may be a DHCP relay that relays messages between local computers and a remote DHCP server. Or the DHCP server may be replicated for reliability, so that there are two or more local DHCP servers. For our purposes, it is suf-ficient to think about a single DHCP server.The complete DHCP exchange involves four types of packets: Discover, for your computer to locate the DHCP server; Offer, for the server to offer an IP address; Request, for your computer to ask for an of-fered address; and Ack, for the server to grant the address lease. However, when a computer is re-establishing its IP address on a network that it has previously used, it may perform a short exchange in-volving only two types of DHCP packets: Request, to ask for the same IP address as from the same server as was used before; and ACK for the server to grant the address lease.Figure 1: DHCP message sequencesYour computer DHCP serverShortexchange Complete exchangeStep 1: Capture a TraceProceed as follows to renew your IP address and gather a trace of DHCP traffic. Note, however, that the following procedure will not work in the unlikely case that your computer’s IP address is statically a s-signed. Alternatively, you may use a supplied trace. Take care not to perform this lab remotely, since when you tell your computer to shut down and restart its network interface you will lose connectivity!unch Wireshark and start a capture with a filter of “(udp port 67) or (udp port 68)”.There is no shorthand to indicate DHCP, so we filter traffic using the UDP ports reserved forDHCP. (Note, in the display filter on main screen you can also type udp.port==67 II udp.port==68)Figure 2: Setting up the capture options2.When the capture is started, release and renew your IP address with the command given below.This procedure may cause your computer to lose network connectivity temporarily, and depend-ing on the operating system it may disrupt network connections. To minimize the disruption,close any programs that are using remote servers and enter the commands into a local window.Windows: T ype the command “ipconfig /release” followed by “ipconfig/renew”.(See figure below.)If on Linux: Find the name of the main network interface by typing “ifconfig” and observing the output.The interface may be called “eth0” or something else. Now use the “dhclient” command to first r e-lease the leased IP address and then to renew the lease. Type, for example, “sudodhclient –reth0” to do the release followed by “sudodhclient eth0” to renew the lease.Figure 5: Releasing and renewing the IP address on Windows 3.Once you have captured some DHCP traffic, stop the capture.Step 2: Inspect the TraceIn this step and the steps that follow, we will inspect only the short DHCP exchange described above. This is because the traffic you have captured can vary widely across settings. You may have as few as two DHCP packets on a quiet network or many DHCP packets on a busy network (especially if a class is running this lab!). The details of DHCP packets may vary depending on how the computers implement DHCP. There may be multiple packets of a single kind in an exchange due to replicated servers, and dif-ferent types of DHCP packets too.Look for the shortDHCP exchange (of a DHCP Request packet followed by a DHCP Ack packet) in your trace. Select the DHCP Request packet, and observe the protocol stack to see how DHCP messages are carried. The link protocol is likely Ethernet, and the next higher protocol is IP. Then comes UDP, so each DHCP message is carried in a UDP packet. On top of UDP, Wireshark is likely to say BOOTP (Bootstrap Protocol) instead of DHCP. This is a bit confusing, but DHCP is implemented as an extension of an older protocol called BOOTP. You can think of the BOOTP section as the DHCP header and message. An exam-ple window is shown below.Figure 3: Capture of DHCP packets, showing details of a DHCP RequestExpand the BOOTP (DHCP) section (using the “+” expander or icon) to look at the details of a DHCP Re-quest message. There are many fields, and we will only point out a few rather than cover them all. These fields are carried in all DHCP messages, though they have different values in different messages.∙The message begins with a Message Type. It is a Boot Request, which is used for all DHCP mes-sages sent from your computer to a DHCP server.∙After a few fields there is a Transaction ID field. All DHCP packets in a specific exchange betweena client and server carry the same transaction ID; that is how both ends know that the packetsbelong to the exchange rather than another concurrent DHCP operation.∙There are several IP address fields. These fields are used to carry IP addresses such as the one that the computer is being assigned.∙There is a Magic Cookie field. It carries a value that indicates the rest of the message contains a series of DHCP Options. That is, this really is a DHCP message, not a BOOTP message.∙Each DHCP option is self-contained, with a type code saying what it represents, along with a length and value. The first option is DHCP Message Type, which says what kind of DHCP message is being carried. The other options vary with the type of DHCP message. For example, a DHCPRequest will have aRequested IP Address option to ask for a specific address, which a DHCP Ack will have a IP Address Lease Time option to say for how long the IP address is being assigned.Now select a DHCP Ack packet and compare the BOOTP fields. We will ask questions about these fields in the next section, but for now want you to observe that the DHCP Ack has the same overall format, but different values for the fields and carries different DHCP options.You can browse the options for DHCP Requests and Acks to learn about DHCP. You can see, for example, how long the IP address is assigned by the server, whether seconds, minutes, hours or days.You will also see the other configuration parameters that are assigned by the DHCP server, such as the IP address of the domain name server and router, the subnet mask, the domain name for the host, and more.You can also try to make out the whole sequence of DHCP messages that is exchanged for your network setup. If may be as simple as the short exchange of Request and Ack, or it may be the complete ex-change of Discover, Offer, Request and Ack. It may have additional messages such as Release, and it may have multiple of the messages (e.g., two or more Offers or Acks) due to multiple local DHCP servers. Complicating the exchange with your computer is that the trace may capture concurrent DHCP traffic from other local computers. You can use the Transaction IDs to separate the different exchanges, and look at the Ethernet source address to see which DHCP messages were sent by your computer. It is likely that other DHCP traffic is mixed in with your exchange.Step 3: Details of DHCP MessagesSpend time understanding DHCP. Note the position of the Ethernet, IP, UDP, and BOOTP protocol block. Answer the following questions based on your examination of the BOOTP/DHCP fields for both the DHCP Request and DHCP Ack. Answers on next page.1.What are the two values of the BOOTP Message Type field?2.How long is the Transaction ID field? Say whether it is likely that concurrent DHCP operationsdone by different computers will happen to pick the same Transaction ID.3.What is the name of the field that carries the IP address that is being assigned to the client?Youwill find this field filled in on the DHCP Ack, as that message is completing the assignment.4. What is the value of the Magic Cookie that stands for DHCP?5.The first DHCP option is DHCP Message Type. What option value stands for this type?6.DHCP Requests will typically have a Client Identifier option. Look at the value of this option. Howdoes it identify the client? Take a guess.7.DHCP Acks will typically have a Server Identifier option. Look at the value of this option. Howdoes it identify the server? Take a guess.8.What option value stands for the Requested IP Address option? And for the IP Address LeaseTime option?9.How does the recipient of a DHCP message know that it has reached the last option?Step 3: Answers to details of DHCP MessagesFigure 1: Structure of a DHCP message1. The two values are Boot Request (1) and Boot Reply (2).2. The Transaction ID is 4 bytes long. Thus it is very unlikely that there will be collisions in a relative-ly small number of concurrent DHCP operations (until that number approaches 216!)3.The “Your (client) IP address” field carries the IP address being leased to the client. 4.The DHCP magic cookie value is 0x63825363. 5. The option value of 53 stands for DHCP Message Type.6. It is typical for the Client Identifier to carry the Ethernet address of the client, but possible to use some other kind of identifier (e.g., hostname, serial number).7. It is typical for the Server Identifier to carry the IP address of the DHCP server, but possible to use some other kind of identifier.8. The option value of 50 stands for Requested IP Address and the value of 51 stands for IP Address Lease Time.9. The end of the DHCP options is identified with a DHCP option called End with value 255. Ether-net IP header UDP header BOOTP fields DHCP Op-tionsStep 4: DHCP Message AddressingNow we will look at how DHCP messages are addressed to computers at the UDP, IP and Ethernet layers. This is interesting because DHCP is used to assign IP addresses – a computer requesting a DHCP address may neither have its own IP address nor know the IP address of the DHCP server.Start by selecting a DHCP Request packet and looking at its UDP details in the middle Wireshark panel. We will only look at the DHCP Request message to keep things simple, as the details of addressing differ for other DHCP messages. Answers on next page.1.What port number does the DHCP client use, and what port number does the DHCP server use?Ports matter because UDP messages are addressed using ports. Both of these port numbers are on the Request in the source and destination port fields (and you will also see them on the Ack). Now look at the IP addresses in the IP protocol header of the packet for the next question. Do not look inside the BOOTP fields for the DHCP parameters, as we care about how DHCP messages are addressed at lower protocol layers. When the request is sent, your computer has no IP address and may not even know the IP address of the DHCP server, so the IP addressing differs from a routine IP packet.2.What source IP address is put on the Request message?It is a special value meaning “this hoston this network” used for initialization.3.What destination IP address is put on the Request message? It is also a reserved value designedto reach the DHCP server wherever it is on the local network.Finally, look at the Ethernet addresses for the next question.4.What source Ethernet address is put on the Request message, and what destination Ethernetaddress is put on the Request message? One of these addresses is a reserved address. Looking at the addressing should help you to understand why your computer may record the DHCP traf-fic of other local computers in your trace. Since the IP addressing is not yet established, many DHCP messages are sent to all computers on the local network. This makes sure every computer receives DHCP messages intended for them, but it poses a difficulty: one computer may receive DHCP messages intended for another computer.5.How does a computer work out whether a DHCP message it receives is intended as a reply to itsDHCP Request message, and not a reply to another computer? Hint: if you are not sure then go over the fields you inspected previously in Step 2 above.Step 4: Answers to DHCP Message Addressing1. The DHCP client (your computer) uses UDP port 68 and the DHCP server uses UDP port 67.2. The source IP address is 0.0.0.0. It is a special address used during address initialization.3. The destination IP address is 255.255.255.255. It is the broadcast address, which means the mes-sage is intended for all computers on the network. (It is not possible to use a more restricted subnet broadcast, e.g., 192.168.255.255, as the subnet mask is not yet known by the client.)4. The source Ethernet addres s is simply your own computer’s Ethernet address, since that is a l-ready assigned to your NIC. The destination Ethernet address is ff:ff:ff:ff:ff:ff, the reserved broadcast Ethernet address, so that the packet reaches all computers on the local network.5. The DHCP messages in a single exchange carry the same Transaction ID. Thus a computer looks for a DHCP reply such as an Ack with a Transaction ID that matches the value it placed on the earlier DHCP message such as a Request. (This is in addition to any Ethernet address filtering: if the reply is un-icast then it will have the computer’s Ethernet address as its destination.)。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
1.What is the IP address and TCP port number used by the clientcomputer (source) that is transferring the file to ?Ip address 192.168.1.36TCP port number:19572.What is the IP address of ? On what port numberis it sending and receiving TCP segments for this connection?the IP address of :128.119.245.12port number:803.What is the sequence number of the TCP SYN segment that is usedto initiate the TCP connection between the client computer and ? What is it in the segment that identifies the segment as a SYN segment?sequence number:0syn 被设置为1说明是syn段4.What is the sequence number of the SYNACK segment sent bygaia.cs.umass.ed to the client computer in reply to the SYN? What is the value of the ACKnowledgement field in the SYNACK segment?How did determine that value? What is it in the segment that identifies the segment as a SYNACK segment?The sequence number of the SYNACK segment sent by is:0SYNACK segment 中ACKnowledgement 的值为1;ACKnowledgement number的值为SYN消息中sequencenumber加上1所得;SYN 和Acknowledgement f都置为1说明这是一个SYNACK segment.5.What is the sequence number of the TCP segment containing theHTTP POST command?第11号报文段是包含HTTP POST 命令的TCP segment。
且报文段的序列号为1522996.Consider the TCP segment containing the HTTP POST as the firstsegment 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 EstimatedRTT value (see page 249 in text) after the receipt of each ACK? Assume that the value of the EstimatedRTT is equal to the measured RTT for the first segment, and then is computed using the EstimatedRTT equation on page 249 for all subsequent segments.前6个报文段为No.11,12,14,15,17,18序列号为:1,619,2027,3435,4843,6251.EstimatedRTT=0.875* EstimatedRTT+0.125*SampleRTT接受到报文段1之后的EstimatedRTT为:EstimatedRTT=RTT for segment 1=0.286157 second接受到报文段2之后的EstimatedRTT为:EstimatedRTT=0.875*0.286357+0.125*289764=0.286783 sencond接受到报文段3之后的EstimatedRTT为:EstimatedRTT=0.875*0.286783+0.125*0.003575=0.251382 second接受到报文段4之后的EstimatedRTT为:EstimatedRTT=0.875*0.251382+0.125*0.28898=0.256082 second接受到报文段5之后的EstimatedRTT为:EstimatedRTT=0.875*0.256082 +0.125*0.285411= 0.259748 second接受到报文段6之后的EstimatedRTT为:EstimatedRTT=0.875*0.259748+0.125*0.285413= 0.262956 second7. What is the length of each of the first six TCP segments?如图答:前6个段的长度分别为:618,1408,1408,1408,1408,1408字节8. 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?答:接收方通知给发送方的最低窗口大小为6798字节,即在服务器端传回的第一个ACK中的窗口大小。
接收方的窗口大小没有抑制发送方的传输速率,因为窗口大小从6798逐步增加到65535,窗口大小始终大于发送方发送的分组的容量9.. Are there any retransmitted segments in the trace file? What did you check for (in the trace) in order to answer this question?答:没有,从TCP报文段的序列号中可以得出以上结论。
从上图中的时间—序号图可以看出,从源端发往目的端的序号逐渐递增,如果这其中有重传的报文段,则其序号中应该有小于其临近的分组序号的分组,在图中未看到这样的分组,所以没有被重传的分组。
10. How much data does the receiver typically acknowledge in an ACK? Can you identify cases where the receiver is ACKing every other received segment (see Table 3.2 on page 257 in the text如图可知,接收方在一个ACK确认的数据大小一般为1408字节。
The Acknowledged sequence number and the Acknowledged data:报文段确认数据为2816bytes=1408*2 bytes,即129131-12631511. What is the throughput (bytes transferred per unit time) for the TCP connection?Explain how you calculated this value.答:TCP 吞吐量计算很大程度上取决于所选内容的平均时间。
作为一个普通的吞吐量计算,在这问题上,选择整个连接的时间作为平均时间段。
然后,此TCP 连接的平均吞吐量为总的传输数据与总传输时间的比值。
传输的数据总量为TCP 段第一个序列号(即第10 段的1 字节)和最后的序列号的ACK (第371 段的152995个字节)之间的差值。
因此,总数据是152995-1 = 152994 字节。
整个传输时间是第一个TCP 段(即10号段2.512909秒)的时间和最后的ACK(即第371 段9.455830秒) 时间的差值。
因此,总传输时间是9.455830-2.512909 = 6.942921 秒。
因此,TCP 连接的吞吐量为152994/6.942921 = 22.035 KByte/sec13. 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 server. Can you identify where TCP’s slowstart phase begins and ends, and where congestion avoidance takes over? Comment on ways in which the measured data differs from the idealized behavior of TCP that we’ve studied in the text.答:慢启动阶段即从HTTP POST 报文段发出时开始,但是无法判断什么时候慢启动结束,拥塞避免阶段开始。
慢启动阶段和拥塞避免阶段的鉴定取决于发送方拥塞窗口的大小。
拥塞窗口的大小并不能从时间—序号图(time-sequence-graph)直接获得。