Lab 07 Packet Analyzer - III

• Implement ARP, ICMP packet dumper
• Understand UDP packet structure
• Implement UDP packet dumper

Address Resolution Protocol (ARP) is an Internet protocol used for resolution of a layer 3 protocol addresses into layer 2 hardware addresses, a critical function in multiple-access networks. ARP was defined by RFC 826. ARP uses a simple message format that contains one address resolution request or response. The size of the ARP message depends on the protocol and hardware address sizes, which are given by the type of networking protocol (usually IPv4) in use and the type of hardware or virtual link layer (usually Ethernet) on which the upper layer protocol is running. The ARP message header specifies the sizes of the two addresses, as well as the type of each address. The message header also contains an operation code that specifies whether the message carries a request (1) or a reply (2). The remainder of an ARP message consists of four addresses: the hardware and protocol address of the sender and receiver hosts.

The Internet Control Message Protocol (ICMP) is part of the Internet Protocol Suite, as defined in RFC 792. ICMP messages are typically used for diagnostic or control purposes or generated in response to errors in IP operations (as specified in RFC 1122). ICMP errors are directed to the source IP address of the originating packet.

ICMP messages are encapsulated in standard IP datagram, either IPv4 or IPv6. ICMP messages are usually processed as a special case, distinguished from normal IP processing, rather than processed as a normal sub-protocol of IP. In many cases, it is necessary to inspect the contents of the ICMP message and deliver the appropriate error message to the application that generated the original IP packet, the one that sent the packet that prompted the sending of the ICMP message.

Applications that do not require the reliability of a TCP connection may instead use the connectionless User Datagram Protocol (UDP), which emphasizes low-overhead operation and reduced latency rather than error checking and delivery validation. UDP is also considered one of the core members of the Internet protocol suite. With UDP, a computer application can send messages, referred to as user datagrams, to other hosts on on the Internet. UDP does not require any action to set up special transmission channels or data paths. The protocol was designed by David P. Reed in 1980 and formally defined in RFC 768.

In the lab 7, you will enhance your packet dumper to recognize ARP request and reply messages, ICMP “Echo request” and “Echo reply” messages, and UDP datagrams. .

To get started with Lab07:

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

You can use the packetdump() function that you implemented in Lab05 or Lab06 as a base for this lab.

In lab 7, you will implement void packetdump_arp(struct netpacket *pkt) function in packetdump.c to print out ARP packets. First you should check whether received ethernet frame is ARP packet, and if so, call packetdump_arp() to print out the message in following format:

• If ARP Request message:

ETH_SRC -> ETH_DST, ETH_TYPE, REQUEST, HLEN, PLEN, SOURCE_IP[SOURCE_ETH_ADDR] -> TARGET_IP

For example,

aa:aa:aa:aa:aa:aa -> bb:bb:bb:bb:bb:bb, ARP, REQUEST, 6, 4, 128.10.3.250[aa:aa:aa:aa:aa:aa] -> 128.10.3.253

• If ARP Reply message:

ETH_SRC -> ETH_DST, ETH_TYPE, REPLY, HLEN, PLEN, SOURCE_IP[SOURCE_ETH_ADDR] -> TARGET_IP[TARGET_ETH_ADDR]

For example,

aa:aa:aa:aa:aa:aa -> bb:bb:bb:bb:bb:bb, ARP, REPLY, 6, 4, 128.10.3.2[aa:aa:aa:aa:aa:aa] -> 128.10.3.51[cc:cc:cc:cc:cc:cc]

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

You will also implement void packetdump_icmp(struct netpacket *pkt) function in packetdump.c to print out ICMP packets. Note that ICMP packets are stored in IPv4 packet. First you should check whether received ethernet frame is IPv4 packet, and if so, you should check again whether it is for ICMP packet. If so, call packetdump_icmp() to print out the message in following format:

• If ICMP Echo-Request message:

ETH_SRC -> ETH_DST, ETH_TYPE, SOURCE_IP -> DESTINATION_IP, PROTOCOL_VERSION, IHL, TOTAL_PACKET_LENGTH, PROTOCOL_TYPE, ECHO_REQUEST, id = identifier, seq = sequence

For example,

aa:aa:aa:aa:aa:aa -> bb:bb:bb:bb:bb:bb, IPv4, 128.10.3.31 -> 128.10.3.102, 4, 5, 84, ICMP, ECHO_REQUEST, id = 10996, seq = 1

• If ICMP Echo-Reply message:

ETH_SRC -> ETH_DST, ETH_TYPE, SOURCE_IP -> DESTINATION_IP, PROTOCOL_VERSION, IHL, TOTAL_PACKET_LENGTH, PROTOCOL_TYPE, ECHO_REPLY, id = identifier, seq = sequence

For example,

aa:aa:aa:aa:aa:aa -> bb:bb:bb:bb:bb:bb, IPv4, 128.10.3.31 -> 128.10.3.102, 4, 5, 84, ICMP, ECHO_REPLY, id = 10996, seq = 1

• If else (for other control message types):

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

For example,

aa:aa:aa:aa:aa:aa -> bb:bb:bb:bb:bb:bb, IPv4, 128.10.3.31 -> 128.10.3.102, 4, 5, 84, ICMP, 0x03

UDP has a very simple and straightforward packet structure. You can refer to RFC 768 for further explanation.

In lab 7, you will implement void packetdump_udp(struct netpacket *pkt) function in packetdump.c to print out UDP packets. First you should check whether received ethernet frame is IPv4 packet, and if so, check if it is a UDP packet, then call packetdumpf_udp() to print out the message in the following format:

ETH_SRC -> ETH_DST, ETH_TYPE, SRC_IP -> DST_IP, PROTOCOL_VERSION, IHL, TOTAL_PACKET_LENGTH, PROTOCOL_TYPE, SRC_PORT, DST_PORT, CHECKSUM, UDP_LENGTH

There are couple of fields that you should be careful when you print out:

• %SRC_IP% : Print out IPv4 source IP address. e.g. 127.0.0.1. If you treat IP addresses as integers, be careful with endianness – a user will expect the address to be printed with the most significant octet first.
• %DST_IP% : Print out IPv4 destination IP address. e.g. 127.0.0.1. Again, be careful with endianness.
• %SRC_PORT% : Print out UDP source port in integer. Be careful with endianness.
• %DST_PORT% : Print out UDP destination port in integer. Be careful with endianness.
• %CHECKSUM% : Print out UDP checksum field in 4-digit hexadecimal 0xXXXX. Again, be careful with endianness.
• %LENGTH% : Print out UDP packet length in integer.

For example:

aa:aa:aa:aa:aa:aa -> bb:bb:bb:bb:bb:bb, IPv4, 128.10.3.31 -> 128.10.3.102, 4, 5, 328, UDP, 41259, 2073 , 0xce0b, 308

• If an IPv4 packet is not a UDP or ICMP packet, it must be printed out as you did in Lab06
• If an ethernet packet is not an IPv4 or ARP packet, it must be printed out as you did in Lab05

Do not forget to enable promiscuous mode before dumping your packet.

You can cast struct netpacket to struct arppacket defined in /include/arp.h. It will help you to layout the ARP packet structure.

You can test incoming ICMP packets with

$ ping galileoXXX

from a xinu machine (e.g. xinu01) to your xinu backend machine.

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.

In addition to generate UDP packets:

nc -u galileoXXX SOME_PORT_NUMBER

• Does your Xinu code successfully compile and work when uploaded to a XINU backend?
• Does Xinu print out ARP packets correctly according to the format specification?
• Does Xinu print out ICMP packets correctly according to the format specification?
• Does Xinu print out UDP packets correctly according to the format specification?
• Does Xinu print out the rest of each packet (IPv4, ETH) correctly according to the format specification?

Note that your directory structure should look like this:

~/cs422
~/cs422/lab07
~/cs422/lab07/compile
~/cs422/lab07/config
~/cs422/lab07/device
...

Run make clean before you turnin your work.

cd ~/cs422/lab07/compile
make clean  

You should use turnin command to submit your whole directory.

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

You can check with turnin -v.

turnin -c cs422 -p lab07 -v