> c) size of a secondary header following each pcap_pkghdr
> d) offset pointer to some external storage
>
> It would seem to me that (d) could be accomodated by (c).
I.e., put the external information inline, in the secondary header?
Yes, that makes sense to me; I don't have handy the mail that suggested
the offset pointer, so I'm not sure why they wanted that rather than
just a secondary header.
(Note that the secondary header was, as proposed by Alexey Kuznetzov,
intended, I think, for extensions to be added by some particular version
of libpcap, so that it could add extensions without rendering the
capture files unreadable by standard libpcap.
Of course, if you have two *different* extensions in different versions
of libpcap, you have a problem - especially if the extensions are the
same size, so that there's nothing in the capture file to indicate which
extension is being used.)
> On the kernel side of this, an application needs to be sure that
> it can receive and write out a file of records all in the same
> format. For this to occur, applications like tcpdump need to
> pass a magic number into the kernel which acts as a filter of
> sorts, only passing back internal records which match.
To what sort of records are you referring here, and to what sort of
format are you referring?
> The requirement for this is that all access to BPF is via /dev/bpf#
> - a single interface - whereas from the kernel side you may have
> any number of formats being generated.
Not all OSes supported by libpcap have "/dev/bpf*" devices; what would
the equivalent be on those OSes?
(Note that there isn't a guarantee that the records in a libpcap capture
file look exactly like the data handed back by any particular OS-kernel
packet capture mechanism; libpcap might hand to the application
something different from the raw data handed to you by the kernel.)
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
