A puzzle

[Peter Van Epp]

	Last Saturday someone on our time share host decided to DOS somebody
else. The router logs indicate a 15 minute peak at around 40 megabits per
second (since the link is half duplex for argus that is probably saturation
level) on the 100 meg segment where argus is watching. However argus seems to 
indicate an impossible amount of traffic (although it certainly got the sense 
of things correct!) the output from "ra file -c -n host aaa.bbb.ccc.dd":

Sat 04/15 18:36:12  F   udp   142.58.101.25.38593  ->  aaa.bbb.ccc.dd.16838 31
   0       88536     0        TIM
Sat 04/15 18:36:12  F   udp   142.58.101.25.38594  ->  aaa.bbb.ccc.dd.5758  31
   0       88536     0        TIM
... (193170 similar lines)
Sat 04/15 18:51:13  F   udp   142.58.101.25.41323  ->  aaa.bbb.ccc.dd.2763  31
   0       88536     0        TIM
Sat 04/15 18:51:13  F   udp   142.58.101.25.41327  ->  aaa.bbb.ccc.dd.23882 31
   0       88536     0        TIM

	Now as I understand it the "88536" should be the byte count of the 
packets seen in this flow (obviously as the F flag implies, well fragmented!).
However 193174 * 88536 ~= 17 gigabytes in 15 minutes (900 seconds) which in
turn would seem to indicate a bit rate of 152 megabits per second on the wire
(which is only 100 meg half duplex Ether, the OC3 is after this point). 
	Is this a case of argus calculating what the flow should have 
transferred and ignoring the lost packets? Or I making a mistake or wrong
assumption of some kind here? This comes back to the question (that I still 
haven't resolved) of why argus and tcpdump packet counts on the argus host are 
much higher than the bytes transferred that the router claims to have 
transferred on the interface where argus is. I need to get a sniffer on the 
segment and compare all three (or four if I include tcpdump) and try and nail 
the inconsistancy. I also need to try the newest Netramet which has FreeBSD 
byte order bug fixes (since an older version reported much the same numbers as 
argus) and see what that says ... The tcpdump numbers matching the argus 
numbers (i.e. a perl script summing tcpdump packet sizes and argus byte counts
for the same tcpdump file agree on the byte count) is still much larger than
the byte count the Cisco fastether interface is reporting having transferred. 

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada