Analyze Packets from VNS
In this first exercise, we will analyze packets captured from VNS. Locate your VNS project from the first tutorial, and run the program again:
./sr -t <your VNS topology ID> -u <vns-user-name> -s vns-1.stanford.edu -l logfile.dat
Remember to specify the VNS ID assigned to your group. The new -l flag will log all VNS packets received to the file logfile.dat. This file is in the tcpdump/wireshark format and can be opened by either utility.
Wait for a few packets to be received by your VNS toplogy, and then exit the program. Now open Wireshark (you don't need to use op because we're not capturing data from an interface, and thus don't need root access).
Go to File->Open, and click on the Notepad icon in the upper-left corner. Enter the path to your new data file, e.g. /exports/home/<username>/<VNS project>/logfile.dat, and click Open.
Compare the Wireshark packet analysis with the packet decoding that you implemented during the tutorial.
- Was your protocol analysis correct?
- Do all your printed fields match what Wireshark shows for the same packet?
To answer these questions, you will need to explore wireshark's interface for displaying the values of the various packet header fields. The interface is relatively self explanatory, but feel free to ask questions.
Analyze Packets on your Hub
For the second exercise, we will analyze packets captured from your Ethernet hub. Perform the following initial setup steps. (For reference, similar steps were done in the Hardware Tutorial):
- Load your hub bitfile on your Netfpga machine
op nf_download /path/to/your/bitfile.bit
- Open 1 copy of Wireshark on your Netfpga machine and start listening on the private interface that connects to your hub
By default, Wireshark captures all packets it sees on the interface. Generate some packets by pinging from Server1 to Server2 via your hub (and not another group's hub).
Look at the packets captured, and perform the following exercises:
- Can you identify ARP packets?
- Expand a specific ARP packet in the packet analysis pane and look for the hex Ethertype field. Does it match the opcode for ARP as listed in Network Sorcery? (See http://www.networksorcery.com/enp/protocol/IEEE8023.htm)
- Can you identify ping requests from server1?
- Do the source and destination addresses of the ping packets make sense?
- You can do an ifconfig on the servers to find their MAC addresses
- Select a ping request packet and examine it in the analysis pane
- Why is the IP protocol listed at all for a ping (ICMP) packet?
- What is the IP version?
- Can you find the IP checksum? Is it correct? (This will be particularly useful when your router is calculating its own checksums!)
- Can you find the field that specifies that this ICMP packet is a ping request?
- By looking at the header (or from your own knowledge), can you determine how a ping reply is correlated with the original ping request? After all, you could easily send out several ping requests before the first reply makes it back, so how do you know if a reply is lost or returned out-of-order?
With the existing Wireshark window open and captured packets visible, try adding some filters to restrict the list of packets shown. You can type the rules directly into the filter box in the toolbar.
- Only show ARP packets (arp)
- Only show ICMP packets (icmp)
- Only show ARP or ICMP (arp or icmp)
Finally, attempt to open an SSH connection from server2 to server1. (You won't actually be able to open the connection because server1/server2 only allow logins from comp519, but this will still generate some TCP network traffic.) In your Wireshark filter window,
- Only show TCP packets (tcp)
- Hide TCP and ARP packets (not tcp and not arp)
Click on the "Expressions..." button, and construct a more complicated filter:
- Show Ethernet packets from a specific MAC address
Click on the "Statistics->Conversations" menu. From here, you can see all of the conversations (communication between a pair of nodes, or between a node and the broadcast network), and filter by packet type.