https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7222
--- Comment #19 from Guy Harris <guy@xxxxxxxxxxxx> 2012-06-05 12:15:35 PDT ---
(In reply to comment #17)
> Just my educated guesses:
>
> * For some (link-layer) protocols (e.g. DPNSS, ISDN, and GSM Um), there simply
> isn't a registered DLT value associated with them - so exporting packets is
> difficult to implement.
That's the basic problem - no link-layer header types assigned for some
encapsulation types supported by Wireshark.
One of the problems with the link-layer types you mention is that they have
"metadata" in addition to packet data, and, while there may be official
standards for the packet data format, there aren't necessarily official
standards for the metadata.
> * In the case of GSM Um (which is mostly stored in XML files generated by a
> family of OSS tools), it might be difficult to determine just how things should
> be serialised for export, so that DLT values can be agreed upon.
Well, if there's more than one widely-adopted convention for metadata, multiple
link-layer header types can be assigned; there are three different link-layer
header types for 802.11+radio metadata, for example, although the Prism and AVS
metadata headers are pretty much dying out.
Ideally, for each link-layer type that requires metadata, there would be one
metadata format for pcap and pcap-ng, sufficient to handle current and future
requirements (which might require it to be extensible, as radiotap is), and it
would be sufficient to handle the metadata from non-pcap-and-pcap-ng file
formats.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
