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
On 2/27/06, Mikhail Manuylov [EMAIL PROTECTED] wrote:
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
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
Hi there,
All I wonder is why tcpdump still hasn't any binary dump append feature.
A got some facts and thoughts:
Implemetation of mentioned above feature is just a sligtly change to
libcap's savefile.c
( i. e. addition of pcap_dump_open_append or add append flag to
pcap_dump_open
( first won't
On Thu, Feb 16, 2006 at 10:56:26AM -0800, Guy Harris wrote:
Mikhail Manuylov wrote:
All I wonder is why tcpdump still hasn't any binary dump append feature.
Because nobody who needed that capability wrote code to implement it and
contributed it to tcpdump-workers?
I've just discovered
On Thu, 2006-02-16 at 20:17 +0300, Mikhail Manuylov wrote:
Hi there,
All I wonder is why tcpdump still hasn't any binary dump append feature.
The biggest problem I imagine is that the resulting file would have only
one header block, so the configuration of the capture for the appended
records
On Feb 16, 2006, at 12:06 PM, Stephen Donnelly wrote:
The biggest problem I imagine is that the resulting file would have
only
one header block, so the configuration of the capture for the appended
records would have to be the same as for the original file.
I'm not sure how you could check