Problem with argus under load not reopening output file.

[Martijn van Oosterhout]

On Sun, Jan 11, 2009 at 10:49 PM, Peter Van Epp <vanepp at sfu.ca> wrote:
> On Sun, Jan 11, 2009 at 01:17:49PM -0500, Carter Bullard wrote:
>> Hmmm,
>> Should we for packet streams that are "PCAP_OPEN_LIVE" interfaces:
>>    1) Adjust the time for packets that are way out of scope (>  5-10
>> seconds away from real time)
>>        to current time.

>        I'd be in favor of 1) (so as to not lose any packets) and not adjusting
> global time at least immediately. Thats an ugly bug :-), it looks like it will
> affect everything except a DAG with internal time keeping turned on as the
> kernel's sense of time is being messed with, so the packet could be ahead by
> an hour (if it hits during interrupt when the packet is getting tine stamped)
> or argus could get hit if it happens when argus asks for time of day.

The simple fix I proposed (changing the less-then to not-equals) will
fix the not-reopening-of-output-file I originally ran into. All that
happened there is that the lastwritten got stuck in the future and
that fixes it.

What actual problem could it cause if GlobalTime were are hour ahead
for a single packet? If that doesn't matter much, then I'd suggest
only worrying about those variables which could be stuck for longer
periods, like lastwritten.

>        Debugging will be interesting (as in may you live in interesting times
> :-)). Setting argus packet capture on (preferably writing to a ram disk for
> speed) would be one obvious choice. If you see a time jump forward and then
> back in sequential packets in the pcap then you likely have a kernel level
> time problem.

That's what I'm trying. I have a packet logger so with any luck I
should catching it in the act.

Have a nice day,
-- 
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/