Wireshark mailing list archives
Re: Adding IEEE 802.15.4 DLT for meta data?
From: James Ko <jim.list () hotmail com>
Date: Thu, 17 Jan 2019 01:01:47 +0000
In order to go down the path of adding DLT_PPI fields for IEEE 802.15.4, I tried sent an email off to winpcap-users () winpcap org but I found that the list is no longer. It appears to me that much of that list is also part of this list but I could not find the responsible party for allocating and managing PPI link-type fields since CACE was acquired by Riverbed. The PPI document I've drafted up a document with the proposed format of the additional PPI fields and attached it. How can I formally go about putting this through review? James ________________________________ From: Wireshark-dev <wireshark-dev-bounces () wireshark org> on behalf of James Ko <jim.list () hotmail com> Sent: Thursday, January 10, 2019 11:10 To: Guy Harris; Developer support list for Wireshark Subject: Re: [Wireshark-dev] Adding IEEE 802.15.4 DLT for meta data? Thanks Guy, I submitted my request for a link-type assignment but I see that the DLT_PPI is generic enough to extend support for IEEE 802.15.4 packets as well with new field types. The approach there is is similar to what I am proposing but the field types defined in the PPI are aggregate blocks of a not small number of parameters/values instead of a single or few related values per type. Perhaps that is just a factor of the IEEE802.11 specification that the values are tightly coupled. James ________________________________ From: Wireshark-dev <wireshark-dev-bounces () wireshark org> on behalf of Guy Harris <guy () alum mit edu> Sent: Monday, January 7, 2019 13:50 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Adding IEEE 802.15.4 DLT for meta data? On Jan 7, 2019, at 1:18 PM, James Ko <jim.list () hotmail com> wrote:
There are ongoing proposal in pcapng format for adding generic wireless meta data options to the enhanced packet block (EPB) and invariant (or seldom changing) capture interface meta data to a new capture interface block (CIB). https://github.com/pcapng/pcapng/pull/51 and https://github.com/pcapng/pcapng/pull/56 I see that 802.11 has several DLT types for including metadata. (DLT_PRISM_HEADER, DLT_IEEE802_11_RADIO, & DLT_IEEE802_11_RADIO_AVS)
Yes. Personally, I think that's two too many - three, actually, with DLT_PPI - but there are historical reasons for them. I'd like to see radiotap pick up all of the 802.11-specific things PPI does, at which point PPI's remaining capabilities should probably be picked up either by other link-layer header types or by pcapng options.
I would like to propose one or more DLT types for including 802.15.4 meta-data.
I'd prefer "one" to "or more".
Defining a new DLT type instead of relying on PCAPNG out of band data enables adding the additional information to pcap sources as well.
Yes. My inclination, by default, is to put the metadata in the link-layer header, with a new link-layer header type assigned, rather than use pcapng for this.
Preference of course is to have only one DLT type with type/length/value (TLV) for each meta data object just as pcapng deals with options. However creating different DLT types may make more sense for the various MACs defined in IEEE802.15.4 (i.e. TSCH-MAC specific). The new DLT would encapsulate the existing packet-ieee802154.c dissector as the last option.
If the metadata is mostly MAC-specific, that'd probably mean either 1) the MAC type as the first item in the metadata, followed by MAC-specific metadata or 2) multiple link-layer header types. Presumably a single interface will always have the same MAC type, so that, in the multiple link-layer header types case, the interface can be given a specific link-layer header type.
Any advice/comments on how to proceed or not proceed? Shall I go just ahead and create the dissector with a new DLT type and submit it for code-review to solicit feedback?
The procedure for assigning a link-layer header type is outlined at the beginning of https://www.tcpdump.org/linktypes.html Note that the first thing you start with is *not* code to parse the header, it's a specification of the header, independent of code. All the specs on the tcpdump.org site, or linked to from the tcpdump.org site, should be sufficient for somebody to write code to parse the header without ever looking at tcpdump or Wireshark code. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Attachment:
ieee802154_ppi.txt
Description: ieee802154_ppi.txt
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Adding IEEE 802.15.4 DLT for meta data? James Ko (Jan 07)
- Re: Adding IEEE 802.15.4 DLT for meta data? Guy Harris (Jan 07)
- Re: Adding IEEE 802.15.4 DLT for meta data? James Ko (Jan 10)
- Re: Adding IEEE 802.15.4 DLT for meta data? James Ko (Jan 16)
- Re: Adding IEEE 802.15.4 DLT for meta data? James Ko (Jan 10)
- Re: Adding IEEE 802.15.4 DLT for meta data? Guy Harris (Jan 07)