Damage Plugin

<< Function >>

o Corrupts certain packets either deterministically or probabilistically
(based on settings) by setting the first 8 bytes of their payload to
"XXXXXXX\0" and zeroing the udp checksum (so it is ignored).

<< Control Messages >>

Type	Command Proto	Semantics			Example
set	sst x		Sets every xth packet to be
			damaged when deterministic
			damaging is turned on

set	sde y		If y is 0, sets packets to
			be damaged probabilistically,
			if y is > 0, sets packets to
			be damaged periodically based
			stride; undefined behavior
			for y < 0

set	spr z		Sets every packet entering
			the plugin for the first
			time to have a z% chance
			of being damaged.  z must
			be a whole number.

misc	rst		Resets the count of packets
			passing through the plugin
			for their first time as well
			as the damaged count.
			
get	gco		Returns the number of packets
			with unique sequence numbers
			from distinctive runs that
			have passed through the plugin

get	gda		Returns the number of packets
			that have been damaged.


<< Tested Behavior >>

o Used /473/jmcpktpair/pkt-pair/ for end hosts (pp-rcvr and pp-sndr)
	o Used verbose setting on pp-rcvr to see payloads
o Tested using pluginTesting2.exp with plugin on ME 1
o Saw the debug fields (ie first 8 bytes of the packet payload)
replaced w/ XXXXXXX for "damaged" packets
o Confirmed default behavior of damaging every 4th packet.
o Confirmed correct selection of packets to damage for these strides
while using -n 5 and -n 8:  
	0, 1, 2, 3, 4, 5, 6, 7, 10


o Stride 3 w/ -n 10:  sndr actually sends 34 packets, and every third
is dropped up until #30, which is NOT dropped (and neither is 33)
o Packets only seem be dropped up to seq number 29.  COULD THIS BE DUE
TO NOT SHIFTING ENOUGH TO GET THE PACKET NUMBERS?  The plugin seems
unable to handle the number 29....
o ANY stride that has seq nums > 28:  seems seq num 29 + always get
through and are not detected for any sort of counting either.  (Eg
using gco shows they have not been counted)
o But NOW I test w/ stride = 2 and it doesn't drop #28, but then drops
all 29 and on... This was after adding part to set 

o gco and gda seem to work as long as we don't have more than 29 total
packets sent in one session (ie our ack numbers don't exceed 28)

o Confirmed following fractions of packets damaged for following probabilities:
  NOTE:  fractions out of totals > 29 are inaccurate due to issues w/
  not handling packets past seq num 28 correctly.
	probability		fractions damaged
	50			15/28, 15/28, 19/28, 11/19, 10/19
	10			1/28, 2/28, 1/28, 4/19, 2/19
	25			8/28, 5/28, 8/28, 7/19, 4/19
	0			0/28, 0/28, 0/28, 0/19, 0/19
	80			28/28, 17/28, 22/28, 14/19, 16/19
	100			28/28, 28/28, 28/28, 19/19, 19/19

o gco and gda correctly both return 0 before any packets are sent
and after "rst" is sent.


<< Tests Needed >>

o Check to see that all messages are handled correctly.
	o IE check that same seq # not damaged multiple times
	o Add option to damage seq #???
o Check that "damaged" packets are handled correctly by end host.
o More probability and stride tests
o Different MEs
o Multiple MEs at once?

<< Issues >>

o Doesn't work past seq number 28. (eg nothing is damaged or counted past
seq number 28)
	o If I change code to set nextDroppable == curPkt when 
	curPkt >= 0x1d, they are ALL being damaged and counted past 28
	when stride is 2, when stride is 3, #29 is damaged and none past it
o Removing "if curPkt==nextDroppable" and making all packets checked for
dropping causes compilation to fail due to lack of local memory.
o Counting includes the preliminary pings sent??? (maybe?)
o Might want to fix feed back from sde x so it tells you that damaging
is now set to be either probabilistic or deterministic, as the case may be.