Re: remote capture framework

[Phil Paradis <Phil.Paradis () unitedtote com>]

> It should be possible to save the need to clean the buffer
> files at boot and also improve performance by writing to a ramdisk FS,
> such as a tmpfs or ramfs. 

That would probably work, if you can make your ramdisk big enough for what you need to capture. We've never tried this; 
our captures are way to big (many GB/day over several days) to fit in a ramdisk. 

The other possible issue I can think of is that if you reboot, you lose all of your captured data. Not really an issue 
for short-term captures where you go grab the files right away, but if you want to run them over longer periods, it 
might be an issue. (especially if you have multiple people with their fingers on the box...)

> Not sure that I actually want it kicked off
> at boot, though.  For our environment, might be better if people could
> specify their packet filters and start captures on-demand.

It's not all that difficult to do on-demand captures and/or filtering with the init script; for on-demand captures; you 
can use chkconfig (or equivalent) to turn it on and off as desired. For filtering, you can either put the filter into 
the script (say in a variable at the top) or read it from a separate file on start.

One handy trick, if you do end up capturing without a filter, is to use tcpdump to filter the traffic you're interested 
in after the fact, before you transfer the packets back to your central office.

cd packets
mkdir filtered
for FILE in *.cap; do tcpdump -r $FILE -w filtered/$FILE tcp port 80 and host 1.2.3.4; done


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe