Packet Analyzer - Part II

• Dump fields in IPv4 header
• Handle variable IPv4 header length

In the last lab, you implemented a packet dump function for Ethernet frames. As you may have already noticed from the last lab, an Ethernet frame carries one of the higher-layer protocols, such as IPv4, IPv6, or ARP in the payload. In this lab, you will enhance your packet dump function to parse and display an IPv4 datagram that is carried in an Ethernet frame (i.e., Internet packets)

IPv4 is a connectionless protocol that provides packet communication across the Internet. An IP datagram consists of a header followed by a payload (the payload is sometimes called a data area).

An IP datagram has checksum for for the header only, which means that IP does not compute a checksum for the contents of payload. In the future, we will see that higher layer protocols, such as TCP, provide checksums for items in the payload.

An IPv4 datagram header consists of 14 fields, of which 13 are required. The 14th field is optional (red background in table) and aptly named options. Integer fields in the header are stored in big endian order (i.e., the most significant byte first). In the diagram given at the link below and the associated discussion, bits are numbered with the most significant bit of a byte on the left (MSB bit order). Refer RFC-791 section 3.1 to see formast details for an IPv4 header.

To get started with Lab06:

$ mkdir -p ~/cs422/
$ cd ~/cs422/
$ wget "http://courses.cs.purdue.edu/_media/cs42200:spring19:lab06.tar.gz" -O lab06.tar.gz
$ tar -xvf lab06.tar.gz
$ rm lab06.tar.gz

You can use the packetdump() function that you implemented in Lab05 as a starting point for this lab.

In Lab 06, we will take a step beyond what we did in Lab05 by dumping the IP datagram. You will print out various fields in datagram header and first 15 bytes of the payload of IPv4 packet. You should modify your packetdump.c to identify whether the received frame is IPv4 packet. If so, your packet dump will print out IPv4 packet in the following format:

ETH_SRC -> ETH_DST, ETH_TYPE, SOURCE_IP -> DESTINATION_IP, PROTOCOL_VERSION, IHL, TOTAL_PACKET_LENGTH, PROTOCOL_TYPE, FIRST_15_BYTES_OF_PAYLOAD

Note: As you can see above, you are still required to print ethernet header fields (preceding the IPv4 header fields)

For example, if the frame has source IP address 128.10.3.31, destination IP address 128.10.3.102, the protocol type UDP, total length 558, and the first 15 bytes of the payload 97 26 c4 17 02 0c 80 4d 00 03 00 02 e9 23 00, then your packetdump function should print out:

aa:aa:aa:aa:aa:aa -> bb:bb:bb:bb:bb:bb, IPv4, 128.10.3.31 -> 128.10.3.102, 4, 5, 558, UDP, 97 26 c4 17 02 0c 80 4d 00 03 00 02 e9 23 00

We encourage you to read RFC 791 Section-3.1 first to understand the layout of IPv4 datagram header. There are couple of fields that you should be careful when you print out:

• SOURCE_IP and DESTINATION_IP : They are stored as binary numbers in network byte order in the header
• PROTOCOL_VERSION : Print out only protocol version.
• IHL(Internet Header Length) : Print out only IHL. Note that IHL stands for the internet header length for IPv4.
• TOTAL_PACKET_LENGTH : Length field in an IPv4 header specifies length of header plus data. This field is in network byte order.
• PROTOCOL_TYPE : Your code must recognize the numeric values for ICMP, TCP, and UDP and print the name as a string (“ICMP”, “TCP”, “UDP” respectively). For all other types, print out the type in hexadecimal in this format: 0xZZ, where ZZ is the hex value of the byte. Please refer list of IP protocol numbers.
• PAYLOAD : Be careful because IPv4 header length can vary. Use IHL to determine where payload starts.

Make sure you enable promiscuous mode as you did in Lab06.

Just as you did in Lab05, call packetdump() in the while loop in the function netin() in net/net.c

You can test incoming IPv4 packets (type ICMP) easily with ping. If your packetdump function is running on backend galileoXXX, then enter

$ ping galileoXXX

from a xinu frontend machine (e.g. xinu01), which will send IPv4 packets to your backend machine. Similarly, you can test incoming TCP packets with

$ nc galileoXXX SOME_PORT_NUMBER

Also, a xinu backend may receive a few IGMP packets which will have a different IPv4 header size than other datagrams. Be careful when printing out payload for these packets to insure you are indeed starting at the first byte after the datagram header.

00:1a:a0:df:90:5d -> 98:4f:ee:00:08:0e, IPv4, 128.10.136.8 -> 128.10.136.133, 4, 5, 544, UDP, 97 26 c4 17 02 0c 80 4d 00 03 00 02 e9 23 00 
00:1a:a0:df:90:5d -> 98:4f:ee:00:08:0e, IPv4, 128.10.136.8 -> 128.10.136.133, 4, 5, 544, UDP, 97 26 c4 17 02 0c 80 4d 00 03 00 02 e9 23 00 
18:03:73:1d:33:07 -> 98:4f:ee:00:08:0e, IPv4, 128.10.136.51 -> 128.10.136.133, 4, 5, 84, ICMP, 08 00 c2 12 0a 6a 00 01 f1 70 d8 56 00 00 00 
18:03:73:1d:33:07 -> 98:4f:ee:00:08:0e, ARP, 00 01 08 00 06 04 00 02 18 03 73 1d 33 07 80 
18:03:73:1d:33:07 -> 98:4f:ee:00:08:0e, IPv4, 128.10.136.51 -> 128.10.136.133, 4, 5, 60, TCP, a5 ea af c8 ee 45 04 9a 00 00 00 00 a0 02 72 
18:03:73:1d:33:07 -> 98:4f:ee:00:08:0e, IPv4, 128.10.136.51 -> 128.10.136.133, 4, 5, 60, TCP, a5 ea af c8 ee 45 04 9a 00 00 00 00 a0 02 72 
18:03:73:1d:33:07 -> 98:4f:ee:00:08:0e, IPv4, 128.10.136.51 -> 128.10.136.133, 4, 5, 60, TCP, a5 ea af c8 ee 45 04 9a 00 00 00 00 a0 02 72 
18:03:73:1d:33:07 -> 98:4f:ee:00:08:0e, ARP, 00 01 08 00 06 04 00 01 18 03 73 1d 33 07 80 
18:03:73:1d:33:07 -> ff:ff:ff:ff:ff:ff, IPv4, 128.10.136.51 -> 128.10.136.255, 4, 5, 78, UDP, a1 03 07 e9 00 3a 8d 15 43 04 6a 6f 68 6e 31 
18:03:73:1d:33:07 -> 98:4f:ee:00:08:0e, IPv4, 128.10.136.51 -> 128.10.136.133, 4, 5, 84, ICMP, 08 00 12 73 0b 54 00 01 16 71 d8 56 00 00 00 
00:1a:a0:df:90:5d -> ff:ff:ff:ff:ff:ff, ARP, 00 01 08 00 06 04 00 01 00 1a a0 df 90 5d 80 

• Does your Xinu code successfully compile and work when downloaded to a XINU backend?
• Does Xinu print out IPv4 packets correctly?
• Does your packet dump function handle the IPv4 header size correctly?
• Is the output in correct format?

Note that your directory structure should look like this:

~/cs422
~/cs422/lab06
~/cs422/lab06/compile
~/cs422/lab06/config
~/cs422/lab06/device
...

Run make clean before you turnin your work.

cd ~/cs422/lab06/compile
make clean  

You should use turnin command to submit your whole directory.

cd ~/cs422
turnin -c cs422 -p lab06 lab06

You can check with turnin -v.

turnin -c cs422 -p lab06 -v