Ulf Lamping wrote:
To make a long story short: the use of the Packet32.h file is only
required for the "Interface Details" dialog implemented in
gtk/capture_if_details_dlg.c (and the loader of the packet.dll in
capture_wpcap_packet.c).
...and that's only because there's no libpcap API yet to get that.
This is an indication that APIs to get that should be added.
At least some of them can potentially change over time (e.g., some of
the 802.11 settings, if the machine is being moved from location to
location), so at least some of it should be made available through an
API other than the next-generation replacement for pcap_findalldevs()
I'm planning to add (the replacement supplies interface information as
an attribute/value list, so more types of information can be added
without breaking source or binary compatibility). An API to return
information about the adapter to which an opened pcap_t is bound would
be useful here. (The pcap_findalldevs() replacement, and the new
"currently-open device" API, should probably return the same type of list.)
The statistics should be returned in a pcap_stats() replacement, which
should also return tagged values, so new values can be added without
breaking the API or ABI, *AND* values not supported by the platform can
be omitted rather than having 0 returned as a fake value.
(I'm inclined to use tag values from
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionidb
for the interface information, and from
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#anchor9
for the statistics, with new tags added as needed.)
That doesn't help in the short term, but it does mean that, in the long
term, Ethereal won't need to use the packet.dll API for that
information, at least when it's using a sufficiently up-to-date version
of WinPcap, and it'll also be able to get at least some of that
information on UN*X as well (the way it's fetched is platform-dependent,
which makes it something libpcap should implement).