Packet Pass Around Project

by: burt rosenberg
at: university of miami

The luggage is a UDP packet;
the carrier an L2 frame for transport

Specific Objectives

• Networking: To understand IP/UDP networking including: IP addresses, DNS concepts, UDP ports, packet type communications.
• Sockets: To be able to use the socket interface on Unix.
• Development: To be able to develop using several machines to test networking code. To use ssh and certificates to work on remote machines.
• Standards programming: To be about to program interoperable systems from specifications.

Man Page

NAME
   passaround --- listen for UDP packets and forward with reception host:port appended.
   passaround-test --- client for passaround. Sends a UDP packet.
      
SYNOPSIS

   passaround [-vzd] [-D debuglevel] [-p listenport] host port
   passaround-test [-v] [-D debuglevel] [-c hopcount] host port

DESCRIPTION

   Passaround listens on a port (-p option or default port) for UDP packets formated
   as a hopcount followed by an ASCII string. The ASCII string should be of the format 
   
        origin(;host:port)*
        
   and records the packet's forwardings. The receiving host appends the host:port 
   information of from where the packet was received.
   
   The hopcount is decremented and unless the hop count is zero sends a UDP packet with
   the hopcount followed by the ASCII string to the host and port given in the command line.
   
   If not forwarded (hopcount is zero, or the -z flag is set), passaround prints out the ASCII 
   portion of the packet, after having appended the host:port information for the last hop.
   
   Passaround-test sends a single UDP packet to host:port with message "origin" and hopcount
   1 (or as given by the -c option) and exits.

   The hopcount is a 2 byte short in network endian order, and is the first 2 bytes of 
   the packet. The entire message is limited to 2048 bytes. No null character terminator 
   is sent for the ASCII string. 
   
OPTIONS

  -z ignore hop count and print received UDP packet information, without forwarding.
     Else silently forward packet to host at port.
  -d deamon mode. After each UDP packet forward, return to listening for the next packet.
     If not in this mode, exit. 
  -v verbose
  -D debug level, takes an positive integer 0 (default) through [your choice].
  -p Port number to listen to for incoming packets. Default is 3333.
  
ARGUMENTS

  host hostname to forward packet
  port port number on hostname to forward packet 

RETURNS
  
  None
  
AUTHOR

  You!

Detailed Directions

Copy the files from [class-repo]/class/proj2 into [class-repo]/[username]/proj2 directory, add, commit, make clean, make, make test.

• The file passaround.h gives the header files that connect your main programs to the helper subroutines in mynetfunctions.c
• The functions in mynetfunctions.c should be reasonably complete. You are free to modify those functions, or correct bugs in them, should you find bugs.
• The program passaround-test.c has been supplied and is reasonably complete. You might want to modify it for your own tests, however.
• The program passaround.c is given to your with a getopt section that indicates somewhat, but not guaranteed fully, the options and arguments. The command line interface is important, as any automated tests will assume them.
• Your first goal is to complete the program passaround sufficiently to satisfy "make test".
• Your second goal is to prepare passaround for further testing during grading.
• You are required to create tests with a make target that automates (as far as possible) the test.
• Tests for grading will look for reasonable completeness.
• Things such as oversized buffers, incorrect option usage, etc., should not cause your program to crash or otherwise open up a security vulnerability such as (i) information disclosure (writing out of memory into a packet information not intended to be written), or (ii) buffer overwrites (that might be exploitable to get a local shell).

The Makefile

Study the provided Makefile. No project is correct without a correct Makefile. The grader and I expect that we can:

svn update; make clean; make ; make test

One line in the makefile has substituted with something odd. Part of the assignment is to have all targets in the makefile working properly.

You also have to add at least one original test case and test target. I left an empty my-test target for you.

The Competition

When the program is completed, we will have a competition for the longest pass around chain, with the winning team getting extra credit points. You all organize to create the chain of passaround servers. This is to exercise the idea of interoperability in network protocols. Your programs have to work not only with themselves, but with other implementations.

I will send a packet to the head of the chain from antietam and it should come back eventually to antietam, passing through a sequence of machines, once through each team member's server. It can all one team, for all I care.

As for hacking the chain — the intent is that the message is honestly appended. Hacks will be considered only if they are more intriguing than annoying.

The competition will begin at 7pm on Friday, February 27. Use:

   nohup ./passaround -d -p PORTNUMBER TO_HOST TO_PORT &

   ps aux | grep passaround

Email me who is in your group, and the host names and port numbers where servers are listening. Indicate which is the first in the chain and I will send a packet there and listen on "antietam, port 9945" for the return.

Additional Notes

See the blog posting on access to the lab for how to use certificates to make using the lab machines easy.

Always put your name and date in the header comments of your code. I will consider that your promise to have sincerely contributed your own work to the project (although you can discuss and collaborate — the final product must be your own.)

Please be assiduous in naming of your files and directories. It should be [your-repo]/proj2, not [your-repo]/projects/proj2 or [your-repo]/Project-2.

This project is about 100 lines of code. If it takes up to 300 lines of code, that's probably normal. If you start hitting 500 lines of code, you might want to reconsider your approach. Here is the edited the output of wc run in the class directory ("before") and in a solutions directory ("after").

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Author: Burton Rosenberg
Created: February 3, 2015
Last Update: February 3, 2015