On Tue, Oct 30, 2012 at 4:08 PM, Daniel Borkmann <[email protected]> wrote: > On Tue, Oct 30, 2012 at 3:49 PM, Doug Burks <[email protected]> wrote: > >> Thanks for the quick response! Replies inline. >> >> On Tue, Oct 30, 2012 at 10:41 AM, Daniel Borkmann >> <[email protected]> wrote: >> <snip> >>>> -n snort.log >>>> This makes daemonlogger name the files in the output directory >>>> snort.log.$TIMESTAMP. Is there an equivalent option in netsniff-ng? >>> >>> No, currently there is no prefix option. If you like feel free to hack >>> the code, it should actually not be too difficult. >> >> OK, I'll take a look at this. >> >>>> -s 134217728 >>>> This configures daemonlogger to rotate to a new pcap file when it >>>> reaches 129MB. Is there an equivalent option in netsniff-ng? >>> >>> No, we only rotate if a specified interval in seconds runs out. >> >> This is somewhat of a dealbreaker for our project. If we rotate based >> on time, some networks will have 100MB pcaps and other networks will >> have 1GB or bigger pcaps. We need to be able to define a constant >> size so that pcaps can be searched in constant time. Is this >> something that I could hack in fairly easily? > > Fair point, such an option should get into netsniff-ng, I agree. It > should not be too difficult. You can have a look into netsniff-ng.c, > add an option and instead of the timer handler that sets the > "next_dump" variable, it should be determined some byte counter.
Actually it would be great to have the --interval option looking for things like "30s", "100MB" and so on, thus both time-based and size-based intervals would be possible. > If you want to give it a try, I'd be happy and we push this upstream. > I'm currently at a conference in Austin, TX and need to go back to > Zurich in the next days, so I'll have limited connectivity. But I can > assist you in that if you have further questions or if you got stuck > in coding. > >>>> Thanks in advance for any assistance! >>> >>> Also have a look into >>> https://github.com/gnumaniacs/netsniff-ng/tree/master/Documentation >>> >>> It should address quite a lot of things and is more up-2-date than the >>> faq. For everything else, the mailing list of course. ;) > > Thanks, > Daniel --
