Wireshark-bugs: [Wireshark-bugs] [Bug 7300] patch: Add frame.interface support for pcapng LINKTY
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7300
--- Comment #5 from Guy Harris <guy@xxxxxxxxxxxx> 2012-06-21 11:34:04 PDT ---
(In reply to comment #4)
> Primary I'm not sure if libpcap maintainers (Guy?) want to have new members in
> pcap_pkthdr
pcap_pkthdr is a non-opaque structure defined in pcap.h, and the pcap_next()
API takes a pointer to a pcap_pkthdr as an argument, requiring its callers to
declare such a structure, so any change to libpcap/WinPcap that increases the
size of the structure would break binary compatibility with applications *and*
do so in a way such that, in an application compiled with the older version of
the structure and running with a libpcap/WinPcap with a newer version of the
structure, data *following* the structure would be overwritten by pcap_next().
I.e., yes, this assumption
> I assume that struct pcap_pkthdr can't be changed without breaking
> compatibility.
is correct, and I would oppose *ever* adding anything to pcap_pkthdr.
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.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
