tcpdump mailing list archives
Re: What is the main reason in absent append
From: "Mikhail Manuylov" <mikhail.manuilov () gmail com>
Date: Mon, 27 Feb 2006 15:13:43 +0300
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.
Current thread:
- What is the main reason in absent append capabilities of tcpdump and libpcap? Mikhail Manuylov (Feb 16)
- Re: What is the main reason in absent append capabilities Guy Harris (Feb 16)
- Re: What is the main reason in absent append capabilities Ed Maste (Feb 16)
- Re: What is the main reason in absent append capabilities Mikhail Manuylov (Feb 17)
- Re: What is the main reason in absent append capabilities Ed Maste (Feb 16)
- Re: What is the main reason in absent append Stephen Donnelly (Feb 16)
- Re: What is the main reason in absent append Guy Harris (Feb 16)
- Re: What is the main reason in absent append Christian Kreibich (Feb 20)
- Message not available
- Re: What is the main reason in absent append Mikhail Manuylov (Feb 27)
- Re: What is the main reason in absent append Mikhail Manuylov (Feb 27)
- Re: What is the main reason in absent append Guy Harris (Feb 16)
- Re: What is the main reason in absent append capabilities Guy Harris (Feb 16)