Do you know how to read a pcap file continuously?

Carter Bullard carter at qosient.com
Wed Sep 18 13:14:33 EDT 2013


Hmmmm, not sure where this leaves us on my questions.
Rather than thinking about implementaion, I think it is more important to decribe the features.  So should we exit if the file goes away ???

Carter

On Sep 18, 2013,  at 9:27 AM, "James A. Robinson" <jimr at highwire.stanford.edu> wrote:

> 
> On Wed, Sep 18, 2013 at 9:20 AM, Carter Bullard <carter at qosient.com> wrote:
>> Not sure that I can resolve your 1 and 2.  
>> 
>> So, I could see a situation where argus is just sitting on
>> a single tcpdump output file, say /tmp/tcpdump.out.
>> 
>> This thing grows until someone decides to harvest the file,
>> and renames it and somehow tcpdump recreates it and continues to write.
>> Argus will have to close the packet file it had open, and open the same
>> packet file again.  In this case the file will not exist for a little while.
>> 
>> I could implement this as a loop trying to resolve the argus
>> "waiting for the file to show up" state.
> 
> Based on the earlier messages it sounded as though you wouldn't
> be keeping the filehandle open, that you were periodically opening
> the file and seeking from the last read position?
> 
> If in fact you are keeping the filehandle open all the time, then
> my #2 doesn't make sense, and I believe you'd never really
> detect the "gone away" situation w/o an explicit check (since
> your process has an open handle, the OS will still register the
> file as existing, even if unnamed).
> 
> What I had been imagining, if you weren't keeping an open
> handle, was that the first run would error out if the filename
> wasn't available, and subsequent opens, from a periodic
> polling loop, would then wait for the file to reappear.  In my
> opinion it's actually better if you can just keep the filehandle
> open and then behave exactly like tail(1) (that behavior would
> be the least surprising, in my opinion).
> 
> 
> Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130918/6813fce6/attachment.html>


More information about the argus mailing list