gdb data for model....

[Carter Bullard]

Hey Peter,
Thanks for the reply!!!
I've made quite a number of changes to try to solve this problem, but
haven't heard a peep in a while, so I'd love to think that the problem
is solved ;o)

I do know better, so is anyone having problems with their argus
stopping?

Carter

On Apr 29, 2009, at 1:04 AM, Peter Van Epp wrote:

>>>
>>> 2/ after a few hours the argus server stops writing to disk.  I now
>>> have turned off daemon mode and redirecting all output to a file to
>>> see if we get any errors logged there.  I know I've seen this before
>>> but can't remember what the issue was.
>>>
>
> 	Assuming you are on Linux (which I think is true) one previous issue
> on multprocessors was a kernel/hardware bug (cache problems on the  
> CPU causing
> an incorrect time stamp) that was corrected or worked around in a  
> later kernel.
> As far as I know we never saw this on our multiprocessor IBM box but  
> before
> I retired we did upgrade to a kernel after the fix.
>
>>>
>>> I have all but given up on running argus on the OBSD firewall. There
>>> is a linux box which sees all the traffic so I have just installed
>>> argus there.  Once I have things stable then I will investigate  
>>> trying
>>> to trace connections through NAT.  Roll on IP V6!
>>>
>>> [several hours later ;)  ]
>>>
>>> Argus has quit writing the output file... here is what when to
>>> stdout/stderr:
>>>
>>>
>>> ArgusWarning: argus[25297]: 24 Apr 09 13:48:48.754981 started
>>> ArgusWarning: argus[25297]: 24 Apr 09 13:48:48.755375
>>> ArgusGetInterfaceStatus: interface em1 is up
>>> ArgusWarning: argus[25297]: 24 Apr 09 15:26:26.965622 ArgusInterface
>>> timestamps wayyy out of order: now 1240543586 then 1647440201
>
> 	These appear to be timet and the first is likely correct:
>
> ./timet.pl 1240544424
> Thu Apr 23 20:40:24 Canada/Pacific 2009
>
> and the other is very bogus:
>
> ./timet.pl 1647440201
> Wed Mar 16  7:16:41 Canada/Pacific 2022
>
>
>>> ArgusWarning: argus[25297]: 24 Apr 09 15:40:24.551463 ArgusInterface
>>> timestamps wayyy out of order: now -1472925367 then 1240544424
>
> 	This one is worse (and probably a bug as well, timet should be  
> unsigned
> as this is presumably 8something hex). It would be interesting to  
> write the
> pcap records to a file using the argusrc option and see if the pcap  
> timestamps
> are incorrect or if there is an internal time problem somewhere that  
> is
> corrupting system time.
>
> Peter Van Epp
>

Carter Bullard
CEO/President
QoSient, LLC
150 E 57th Street Suite 12D
New York, New York  10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090429/8eb4a92a/attachment.bin>