Hi Stephen.
NTAR is a separate library to read and write the so-called "pcap-ng" file
format. The idea is to have a new library supporting the file format, since
the problem of managing trace files spans multiple applications and
libraries (not only libpcap), that's the reason for a separate p
Hi all.
Since the NTAR/pcap-ng topic spans multiple mailing lists, I suggest
everybody to send messages to the ntar-workers mailing list (I forgot to put
that mailing list in my original announcement mail, my bad...), so that it's
easier for everyone to follow the discussion (and in order to a
I'm a bit confused about naming. How does NTAR stand with respect to libpcap?
Is it in fact libpcap 1.0? Or just an independent implementation of the
proposed/agreed format for 'libpcap-ng'?
Can NTAR read 'old' format libpcap traces?
What's next for libpcap development, is there the intent fo
Hi Ronnie,
On Sat, 2005-06-25 at 20:48 -0400, ronnie sahlberg wrote:
>
> I often work with very very large capture files and often want to only
> extract a very small subset (packets captured between time X and time
> Y).
> This is very very slow with the current fileformats doe to the massive
> a
xiaolei zhang wrote:
why the original buf_size == 8192 ?
We have to pick *some* size. I guess 65536 will probably be big enough
on most if not all systems, and probably small enough, but it's
ultimately arbitrary.
in my system, sizeof(struct ifreq) is 40, if the buf_size is 44, then
ioc
I received this bugreport.
The moderator
--- Begin Message ---
hello all:
I think the this codes may contain a logical error (sorry, if i am
wrong ).
libpcap-->fad-gifc.c -->fad-gifc.c-->pcap_findalldevs
=
/*
* Start with an 8K buffer, and keep
Phil Wood wrote:
It works, but I think args 2 and 3 (of 4) to fread are swapped.
Unless it forces the kernel to read a character at a time?
Line 1048: amt_read = fread((char *)&hdr, 1, sizeof(hdr), fp);
That call says "read 'sizeof(hdr)' 1-byte entities, and return the
number of 1-byte ent
