Guy Harris wrote:
What's next for libpcap development, is there the intent for a new
version of libpcap to also process the new format?
Yes, and to add additional capabilities as well.
Independently of NTAR?
At least as I see it, it'd come out at the same time, or after, NTAR,
and would use NTAR to handle the low-level details of reading pcap-NG
files.
With or without backwards compatibility at the file reading or API
levels?
With backwards compatibility at the file reading layer, so that it can
read old libpcap files.
With backwards compatibility at the API layer, *but* with some
additional new APIs to expose the full capabilities of the new format
and to add additional capabilities.
Thanks for the clarification, it can be difficult to understand the libpcap
'roadmap' from out here. Your suggestions all sound perfectly reasonable to me.
(Are there any API changes that
would allow capturing with libpcap on a DAG device to run at a speed
closer to that of capturing using the native DAG interface?)
Curiously enough I have just been looking at libpcap performance with DAG
cards. The answer is that the current libpcap DAG code works pretty well,
it's not much slower than the native interface. There are however some
changes I'm planning that will improve things a bit more. So far my
proposed changes affect only the library internals, they do not require
changes to the libpcap API.
Regards,
Stephen.
--
-----------------------------------------------------------------------
Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED]
Endace Technology Ltd phone: +64 7 839 0540
Hamilton, New Zealand cell: +64 21 1104378
-----------------------------------------------------------------------
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
