Re: What is the main reason in absent append

["Mikhail Manuylov" <mikhail.manuilov () gmail com>]

I really glad to report that I've ported some necessary bits from pflogd to
implement apped feature in tcpdump.
No changes were made in tcpdump sources yet ( i.e. we use same -w flag), but
libpcap's savefile.c
I've added new function pcap_scan_dump() that's intended to be used for
pcap_setup_dump() ( which is called from pcap_open_dump()).
I've already made some testing and found a bug ( or maybe misfeature ): this
implementation can't change snaplen to snaplen stored in header of dump file
( we need to call pcap_compile() && pcap_setfilter() if header snaplen not
equal to default/command line supplied). In pflogd that function (called
scan_dump()) implemented in daemon, so this behaviour is possible ( we have
access to all external variables and stuff).
So here's the main question: is there any other way ( except to mentioned
above) to change snaplen on the fly?
See attached patch.

On 2/21/06, Mikhail Manuylov <mikhail.manuilov () gmail com> wrote:
> On 2/20/06, Christian Kreibich <christian () whoop org> wrote:
> > On Thu, 2006-02-16 at 12:42 -0800, Guy Harris wrote:
> > > Require read and write access for appending, open for reading and
> > > writing, read the header, make sure the link-layer type and snapshot
> > > length are the same (and fail if they're not), and then seek to the
> > > end and start writing.
> >
> > And check whether the last packet has indeed been written out in its
> > entirety, otherwise pcap header corruption will occur at the append
> > spot.
> >
> > I'm really looking forward to seeing this in pcap itself. If you need it
> >
> > today, use pcapnav:
> >
> > http://netdude.sourceforge.net/doco/libpcapnav/pcapnav-pcapnav.html#PCAPNAV-DUMP-OPEN
> >
> >
> > Cheers,
> > Christian.
> > --
> Last days I have been investigating pflogd code, a daemon which has
> implemented feature of log appending with buffering and all necessary
> checks. pflogd was written by OpenBSD developers and then ported to FreeBSD
> and perhaps NetBSD. It looks a bit sophisticated for me, cause there are
> also implementation of privelege separation with local socket and other
> stuff. Now I'm going to look at tcpdump code towards porting some code from
> pflogd there (license is BSD too).
> I have a question about version of tcpdump I shall change and then send
> patch to patches@. Were there any major changes between 3.9.3 and 3.9.4 or
> maybe I should checkout current branch from cvs repository?
>
> I see pflogd as tcpdump with very redundant feature set (no printing
> features at all), but for dumping working with binary data it's perfect.
> Here some features I'd like to see in tcpdump ported from pflogd:
> 1) daemonizing when dumping
> 2) checking integrity of existing dumpfile
> 3) mess with different snaplength
> 4) privelege separation while dumping
> --
> Truly yours, Mikhail Manuilov


--
Truly yours, Mikhail Manuilov

Attachment: libpcap-0.9.4_append_patch.txt
Description:

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.