Experiment 2: Network Protocol Analyzer Introduction

Objectives

  1. Become familiar with the Wireshark network protocol analyzer program.

  2. Observe the Address Resolution Protocol (ARP) in action and how a computer keeps a table that relates IP and Ethernet addresses

  3. Observe the exchange of Internet Control Message Protocol (ICMP) packets.

Background

The following topics from class notes: Internet layers, IP addressing, rudimentary Ethernet network concepts, ARP and ICMP protocols.

ARP frame exchange: the ARP protocol runs at the interface between Link and Network layers. It is used to find the Link layer address (or ‘hardware’ address or Ethernet address in our case) of for a given IP address within the LAN.

References

Procedure

  1. Launch the Wireshark program

  2. Open a command-line window (cmd.exe)

  3. Run the “ipconfig” command to find the LAN address and the network mask.

    ipconfig and arp command outputs

    From this example we know that the host IP is 192.168.122.24 and the mask is 255.255.255.0. Therefore, any host address beginning with 192.168.122.* is within the LAN. Note: this is just an example, the IP host and network addresses will be different in the lab.

  4. Run the “arp” command to print the kernel ARP cache table (also shown in the figure above). In order to create an ARP request, we can attempt to contact another host in the local network not yet listed in cache (can also use the “-d” option to delete entries from the cache as shown above, type arp /? to see all options).

  5. Start capturing the Ethernet interface with the Wireshark program (Capture->Interfaces->Local Area Connection). Important: to simplify analysis, start capturing shortly before next step (Step 6) and stop capturing as soon as Step 6 is completed. Otherwise, too many frames will be captured and it will become more difficult to locate the ARP and ICMP packets.

  6. Use the “ping” command to send ICMP packets to another host in the local network (but not in the ARP cache). For example, below we send packets to 192.168.122.108.

    ping and arp commands output

    This command will first generate and ARP request (at the link layer) to find the unknown Ethernet address for 192.168.122.108. After a response is received, the program will send ICMP packets (at the network layer) to 192.168.122.108. The host at 192.168.122.108 must respond to those packets by sending packets back to the source. The program receives those packets and can determine the total delay for the round-trip from the time-stamp field in the ICMP packet.

    Stop capturing the network interface in Wireshark and run “arp” again. The ARP table should now include the ‘pinged’ host as shown above. Note: if you wait too long after running the “ping” command, the entry in the ARP cache may expire and be erased automatically.

  7. Analysis of captured frames: set a filter in wireshark as shown below (arp or icmp):

    wireshark captured packets and frames

    Wireshark should display mostly frames and packets relevant to this experiment now. Identify all traffic generated by the ping command and associated ARP request. Highlight individual packets and try to understand the frame/packet hierarchy for each type (ARP/ICMP) by analyzing the windows below the packet list. Show this list to the lab instructor when answering questions.

Questions to be answered at the end of the Experiment

  1. Show the captured ARP frames in Wireshark to answer the following questions:

    1. Why there is no IP header in the ARP request frames?

    2. How many bytes are used for the hardware address?

    3. Do you notice any redundancy in the information sent in the ARP request/reply?

    4. Where is the Ethernet CRC field?

  2. Show the captured ICMP messages in Wireshark to answer the following questions:

    1. What is the total (Ethernet) frame length in bytes?

    2. What is the length (in bytes) of the IP packet?

    3. What numeric ICMP types are used for the echo request and reply?

    4. Is the ICMP data field always the same? Is it the same for a particular request/reply pair?