https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16420
--- Comment #2 from Guy Harris <g...@alum.mit.edu> ---
(In reply to jgh from comment #0)
> The utility uses pcap_dispatch() with a callback function using
> pcal_datalink();
> the latter returns a value 252 - which is not documented as one of the
> possible return values per https://www.tcpdump.org/linktypes.html
> ( linked from https://www.tcpdump.org/manpages/pcap_datalink.3pcap.html ).
Not all values that pcap_datalink() can and will return are documented on that
page.
> The Wireshark "packet details" pane shows the dissection sequence as
> - Frame
> - EXPORTED_PDU
> - Internet Protocol Version 4
> - Transmission Control Protocol
>
> (and wireshark itself is perfectly happy with reading the file it had
> written).
>
>
> So the need is one of
>
> - a way of writing a pcap file that older libpcap-based utilities understand,
> presumably by stripping the EXPORTED_PDU layer
I'll let Anders address that, although the issue is with the current version of
the utilities; it's only a libpcap issue with libpcap 1.4 and earlier.
> - an update to libpcap, to invisibly handle the new pcap file format
It's not a new file format, it's a new link-layer header type. The pcap and
pcapng file formats are link-layer-header-type agnostic.
Libpcap maps the LINKTYPE_ values in capture files to DLT_ values used in the
libpcap API by:
1) if the value is in the "values match" range, just using the numerical
LINKTYPE_ value as the numerical DLT_ value;
2) otherwise, using a small mapping table to map from the numerical
platform-independent LINKTYPE_ value for the link-layer header type to the
numerical platform-dependent DLT_ value for the link-layer header type.
Starting in libpcap 1.5, DLT_WIRESHARK_UPPER_PDU is defined as 252, and 252 is
in the matching range, so libpcap 1.5 and later have no problem with it.
You're using libpcap 1.9.1, so there is no libpcap problem.
It's the programs *using* libpcap that needs to handle DLT_WIRESHARK_UPPER_PDU.
> - documentation on the new coding pattern required for utilities to handle
> the
> new file format. This would suffice for my immediate need as I am the
> maintainer for this utility
--
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
