A poorly fragmented packet stream that seg faults argus.

[Peter Van Epp]

	Yep, this appears to do the trick. I put my test machine running 
unpatched beta.1e beside the production machine that had been patched and the
unpatched machine seg faulted last night while the patched machine is still
happily collecting this morning.

-rw-------  1 root  wheel  2555904 Mar  3 19:01 argus_bpf.core

which corresponds to this connection:

...
Wed 03/03 18:54:35     icmp    142.58.107.4       <->     24.113.4.68       7
   7                          ECO
Wed 03/03 19:01:45      tcp    142.58.107.4.49109 <|      24.113.4.68.80    1
   1       0         0        RST

	and a search of the output file for "frag" comes up empty. On the
patched machine I see:

Wed 03/03 19:01:13 frag  ip    142.58.107.4        ->     24.113.4.68 31904 pk
1  ex    0  ob    4  max    4 TIM
Wed 03/03 19:01:13 frag  ip    142.58.107.4        ->     24.113.4.68 18398 pk
1  ex    0  ob    4  max    4 TIM
Wed 03/03 19:01:13 frag  ip    142.58.107.4        ->     24.113.4.68 13616 pk
1  ex    0  ob    4  max    4 TIM

which I expect are the packet(s) that took out the unpatched version. Thanks
for the fix!

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

> 
> Hey Peter Van,
>   So I believe the fixes to ./server/cons_ip.c will handle
> your problem.  Tell me ASAP if this isn't true.  There
> are two fixes in cons_ip.c, both related to truncated
> packets, but your problem was specific to truncated
> fragments, so both patches apply.
> 
>   The output for your example with these fixes will not be
> accurate, (your sample has 101 packets and argus will report
> 101 packets seen, but only 76 packets mapped to flows).
> Actually the missing packets are not related to the TCP
> connection, but to the ICMP processing.  That will be
> fixed in the 1.8 timeframe.
> 
> Carter
>