Your grade for project 2 is computed based on four components, each of them having a weight of 25%. The four components are
In case you would like a component to be re-graded, you must take a closer look at the tests run for the evaluation of this component first. You should re-run the tests. If you notice that your code passes tests that have been reported to fail, please send email to uhengart+@cs.cmu.edu. In case your tests confirm the reported failures and you still think that you deserve a better grade, you should investigate the failures in more detail. We expect you to have a very clear picture of why your code fails, what needs to be fixed, and why you think you deserve a better grade. Only if you can answer all of these questions, send email to uhengart+@cs.cmu.edu. As a rule of thumb, each line of code that needs to be modified in your code to make it pass a test results in a penalty of 10 points from the overall grade.
Requests for re-grading must be received by Nov, 13.
We now describe the evaluation of the four components in more detail.
The files used for testing this component (and all the other ones) are in /afs/cs/academic/class/15441-f01/projects/project2/grading. In the rest of this document, we use $grading_dir when referring to this directory. In all experiments, node 1 is running your kernel. All the other nodes in the network are running the sample kernel provided in $grading_dir. This configuration also holds for the NAT and firewalling tests, but not for the DHCP tests, where all nodes are running your kernel.
$grading_dir/start_kernel.pl $grading_dir/network2.cfg rttest -n 1 add 0.0.0.0 1 rttest -n 2 add 0.0.0.0 1 udprcv -n 2 50 & udpsend -n 1 1.1.2.1 50
The source code for the udprcv and udpsend applications is available in $grading_dir.
$grading_dir/start_kernel.pl $grading_dir/network2.cfg rttest -n 1 add 0.0.0.0 1 rttest -n 2 add 0.0.0.0 1 udprcv -n 1 50 & udpsend -n 2 1.1.1.1 50
$grading_dir/start_kernel.pl $grading_dir/network3.cfg rttest -n 1 add 1.1.1.2 1 rttest -n 1 add 1.1.2.2 2 rttest -n 2 add 0.0.0.0 1 rttest -n 3 add 0.0.0.0 1 udprcv -n 2 50 & udpsend -n 3 1.1.1.2 50
Your code is evaluated by running an experiment and visually inspecting it. The experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel.pl $grading_dir/network3.cfg udprcv -n 2 50 & udprcv -n 3 50 udpsend -n 1 255.255.255.255 50
The experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel.pl $grading_dir/network3.cfg setnat -n 1 $grading_dir/nat_rulesA.txt rttest -n 1 add 1.1.1.2 1 rttest -n 1 add 1.1.2.2 2 rttest -n 2 add 0.0.0.0 1 rttest -n 3 add 0.0.0.0 1 # outgoing packet udprcv -n 3 -d 50 & udpsend -n 2 1.1.2.2 50 # incoming packet udprcv -n 2 50 & udpsend -n 3 5.6.7.8 50 $grading_dir/start_kernel.pl $grading_dir/network2.cfg setnat -n 1 $grading_dir/nat_rulesB.txt rttest -n 1 add 0.0.0.0 1 rttest -n 2 add 0.0.0.0 1 # locally generated packet udprcv -n 2 -d 50 udpsend -n 1 1.1.2.1 50
The first experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel.pl $grading_dir/network3.cfg setfilter -n 1 $grading_dir/fw_rulesPlacement.txt rttest -n 1 add 1.1.1.2 1 rttest -n 1 add 1.1.2.2 2 rttest -n 2 add 0.0.0.0 1 rttest -n 3 add 0.0.0.0 1 # input filter # to be dropped udprcv -n 1 50 & udpsend -n 2 1.1.1.1 50 # not to be dropped udprcv -n 3 50 & udpsend -n 2 1.1.2.2 50 # forward filter # to be dropped udprcv -n 3 51 & udpsend -n 2 1.1.2.2 51 # not to be dropped udprcv -n 1 51 &" udpsend -n 2 1.1.1.1 51 # output filter # to be dropped udprcv -n 3 52 & udpsend -n 1 1.1.2.2 52 # not to be dropped udpsend -n 2 1.1.2.2 52
The second experiment is run in the following way (from the directory containing your kernel):
# first complicated rule $grading_dir/start_kernel.pl $grading_dir/network3.cfg setfilter -n 1 $proj_dir/grading/fw_rulesComplicated.txt rttest -n 1 add 1.1.1.2 1 rttest -n 1 add 1.1.2.2 2 rttest -n 2 add 0.0.0.0 1 rttest -n 3 add 0.0.0.0 1 # to be dropped udprcv -n 3 50 & udpsend -n 2 -t1 1.1.2.2 50 # not to be dropped udpsend -n 2 -t2 1.1.2.2 50 #second complicated rule $grading_dir/start_kernel.pl $grading_dir/network3.cfg rttest -n 1 add 1.1.1.2 1 rttest -n 1 add 1.1.2.2 2 rttest -n 2 add 0.0.0.0 1 rttest -n 3 add 0.0.0.0 1 # to be dropped (IP id will be zero) udprcv -n 3 51 & udpsend -n 2 1.1.2.2 51 # not to be dropped (IP id will be one) udpsend -n 2 1.1.2.2 51Note that for the first complicated rule, we use a hack in the ip_output() routine of our kernel that "transforms" a UDP packet into a TCP packet. Also note that the kernel will crash for the "TCP" packet that should not be dropped, which is "fine". Our hack looks as follows:
{ /* * make udp packet appear as tcp packet and set some flags * depending on payload */ struct udphdr* udp_h = ((struct udphdr *) (pkt->p_data + sizeof(struct ip))); struct tcphdr* tcp_h = (struct tcphdr*) udp_h; char* payload = ((char*)udp_h) + sizeof(struct udphdr); if (!strncmp("tcp1string", payload, strlen("tcp1string"))) { printf("ip_input: found tcp1\n"); tcp_h->th_flags = TH_SYN|TH_FIN; hdr->ip_p = IPPROTO_TCP; } else if (!strncmp("tcp2string", payload, strlen("tcp2string"))) { printf("ip_input: found tcp2\n"); tcp_h->th_flags = TH_ACK; hdr->ip_p = IPPROTO_TCP; } }
$grading_dir/start_kernel.pl $grading_dir/network2.cfg setnat -n 2 $proj_dir/grading/nat_rules1.txt setnat -n 2 $proj_dir/grading/nat_rules2.txt
The experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel.pl $grading_dir/network2.cfg setfilter -n 2 $proj_dir/grading/fw_rules1.txt setfilter -n 2 $proj_dir/grading/fw_rules2.txt setfilter -n 2 $proj_dir/grading/fw_rules3.txt setfilter -n 2 $proj_dir/grading/fw_rules4.txt setfilter -n 2 $proj_dir/grading/fw_rules5.txt
Your DHCP server and client are tested separately by letting them interact with the sample DHP client and server, respectively. We did not require you to have your DHCP implementation work with the sample implementation. However, your implementation has to follow the requirements in the RFC. Since the sample implementation was implemented according to these requirements, your solution should be able to interact with it. If you think that your solution complies with the RFC, though it is not able to interact with the sample implementation, write up the observed problem and why you think the behavior of your implementation is legal and send email to uhengart+@cs.cmu.edu.
Our DHCP implementation used for testing is a functionally slightly extended version of the provided sample implementation. It examines compliance of received DHCP messages with the RFC.
All the nodes in the network are running your kernel.
The experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel2.pl $grading_dir/network2.cfg $your_dhcp_server -n 2 --topology=$grading_dir/network2.cfg --config=$grading_dir/dhcp_network2.txt --default_lease=60 --max_lease=120 & $our_dhcp_client -n 1 --lease_length=60 --release_time=10
The experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel2.pl $grading_dir/network3.cfg $your_dhcp_server -n 1 --topology=$grading_dir/network3.cfg --config=$grading_dir/dhcp_network3.txt --default_lease=60 --max_lease=120 & $our_dhcp_client -n 2 --lease_length=60 --release_time=20 $our_dhcp_client -n 3 --lease_length=60 --release_time=20
The experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel2.pl $grading_dir/network2.cfg $our_dhcp_server -n 2 --topology=$grading_dir/network2.cfg --config==$grading_dir/dhcp_network2.txt --default_lease=60 --max_lease=120 & $your_dhcp_client -n 1 --lease_length=60 --release_time=10
We use the same experiment as for D2a.
The experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel2.pl $grading_dir/network2.cfg $our_dhcp_server -n 2 --topology=$grading_dir/network2.cfg --config==$grading_dir/dhcp_network2.txt --default_lease=60 --max_lease=120 & $your_dhcp_client -n 1 --lease_length=20 --release_time=25
The experiment is run in the following way (from the directory containing your kernel):
$grading_dir/start_kernel2.pl $grading_dir/network2.cfg $our_dhcp_server -n 2 --topology=$grading_dir/network2.cfg --config==$grading_dir/dhcp_network2.txt --default_lease=60 --max_lease=120 --loose_first_discover & $your_dhcp_client -n 1 --lease_length=60 --release_time=10We use a specially prepared version of our DHCP server and instruct it to drop the first Discover message using the --loose_first_discover option.