argus-3.0.0.rc.3

[Carter Bullard]

Well, the fact that the ring buffer is working with two interfaces
may be an issue with getting duplicate frags?   Getting a huge
packet trace will help, if you can handle the disk space.

Carter


On Jun 8, 2006, at 1:55 PM, Peter Van Epp wrote:

> On Thu, Jun 08, 2006 at 01:14:45PM -0400, Carter Bullard wrote:
>> No body should need to modify the code, permissions seem fine  ;o)
>>
>
> 	I suppose that makes sense and a simple chmod fixes it when I'm doing
> things I shouldn't be :-)
>
>
>> The no frag struct means that we're processing a fragment, but
>> the internal frag control block for the parent flow has either been
>> deallocated or was never allocated (unlikely).  This could
>> happen if we think we've seen all the fragments, deallocate the
>> fragment tracking control block, and then, ..., somehow, we get
>> another fragment for the packet id, or a copy of one we've already
>> seen.   This, of course, is not suppose to happen.
>>
> 	Ah the "should not occur type transmission error" which used to  
> require
> a reboot of MVS to get out of :-). This is likely a stray fragment  
> (2.0.6 sees
> them occasionally) rather than a problem in the ring code I think.  
> I'll have
> to see if I can find one in one of the 2.0.6 archives. I think we  
> used to
> output a record for an unassociated frag (but I may also be  
> remembering 1.8.1
> :-)) and I think the type field was frag rather than tcp or udp. I  
> see lots
> of frags but nothing like that in the currently active argus.out  
> file in
> production and the ring buffer instance is still fine.
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>