Douglas E. Comer

Computer Science Department
Purdue University
West Lafayette, IN 47907

webmaster: W. David Laverell

Companion Topics

Home

Book Information

Purpose of Site

Getting Started

Students

Faculty

"What's New"

"Coming Attractions"

"C Pointers"

Acknowledgements

This chapter seems straightforward, but there are complexities arising from variations in packet sniffing software and computer architecture. Professor Comer's comments under Manual Packet Inspection are very important. It is hard for me to imagine completing this experiment without such analysis. You will eventually be working with a file containing captured packets, and your packet sniffing software, tcpdump, snoop, or whatever likely has an option which will take that file and give you a more user friendly output. (Check the man page for your packet sniffer software.) This will allow you to identify certain fields, especially hardware addresses, that will help you as you find your way around the raw packets that your program has to read.

The first thing you must deal with is the header files. My preference is to use the include files found on your machine. However, snoop or tcpdump output must be taken into account. There is always a file header as well as a header for each individual packet. Finding a header file that corresponds turned out not to be possible. So, I made my own and you are welcome to use my snoop.h. I found /usr/include/sys/ethernet.h on my Solaris machine to be quite useful.

You need to be aware of the following problems:

• Some software used to capture packets pads ethernet frames so that they are a multiple of 4 bytes in length. Mine wants a multiple of 8 bytes. Some packet sniffing software does no padding at all.
• It is tempting to treat IP addresses as long integers. On a Sparc station integers and short integers must be aligned to 4 and 2 byte boundaries respectively. So if you have, say, a short integer in your data but are not sure its address will be even, you need to use the memcpy to copy it to a data area defined as a short integer. Otherwise, you will get the dreaded bus error! At one time Intel machines allowed any four bytes to constitute a long integer. Surprisingly, even with LINUX on a PC you must deal with alignment issues. For example, suppose that you have a chunk of data containing an ip address preceded by 10 bytes of stuff. It is tempting to define the following struct:

  	struct mysruct {
  		char stuff[10];
  		long int ip_address;
  	};
  

  I was rather surprised to discover that this will not work on any LINUX box known to me or to the students of the local chat mailing list. Put this struct in a C program, and print the sizeof(struct mystruct). 14, right? No. It is 16. gcc aligns the long integer because on some architectures aligning long integers is more efficient. So define that ip address as a four byte string and use memcpy.

• Treating IP addresses as long integers had a different consequence on my Linux box. The version of tcpdump that I was using (Mandrake) treated them as 4 individual bytes. Hence, an unnecessary ntohl had to be removed.

It is hard to imagine dealing with these problems or even understanding them without analyzing the packets manually.

The Optional Extensions are particularly interesting. On a Linux box you can get your hardware address by using the ifconfig command. Solaris will give you this information if you are root, by typing /usr/sbin/ifconfig -a. If you are not root use the previous command to get the IP address and type /usr/sbin/arp your_ip_address.

snoop.h

struct snoop_file_header	{
	char name[8];
	char junk[8];
};

struct snoop_packet_header	{
	long	packet_size;
	char	junk[20];
};

---

This site is maintained by W. David Laverell of the Computer Science Department at Calvin College. For assistance or corrections, please contact him at lave@calvin.edu.