https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7300
Stephen Donnelly <stephen@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Platform|All |x86
--- Comment #6 from Stephen Donnelly <stephen@xxxxxxxxxx> 2012-06-25 13:34:25 PDT ---
(In reply to comment #5)
> What's really needed is a more pcap-ng-friendly API for receiving captured
> packets, and a change to the internal programming interface for pcap "modules"
> (the name I'm using for the code to handle particular types of capture devices)
> so that modules can supply additional data; that interface is not yet a
> standard that offers binary compatibility (as there's currently no
> dlopen()/LoadLibrary()-based plugin plugin interface, modules have to be
> compiled in, so they'd either pick up data structure changes or break if the
> module interface changes at the source or binary level). The existing pcap
> APIs, such as pcap_dispatch(), pcap_loop(), pcap_next(), and pcap_next_ex()
> would continue to exist, and would discard the additional data.
Would it make sense for libpcap to export new public interfaces for providing
interface information in pcap-ng format directly, e.g. IDBs, and packets as PB
pointer (+ data pointer).
This way reading from a pcap-ng file can provide the maximum information
available to capable applications, and 'downconvert' to pcap format for older
apps.
It could also intelligently 'upconvert' libpcap files to pcap-ng format, e.g.
preserving the nanosecond resolution of pcap files with 'non-standard' magic
values.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.