[tcpdump-workers] Request: New Link Type for IEEE 802.15.4 TAP
Please assign a new DLT_/LINKTYPE_ value for IEEE802_15_4_TAP packets. The IEEE 802.15.4 TAP packet format proposal is in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15429. IEEE 802.15.4 defines both PHY and MAC layers and the proposed format enables the sniffer/tap device to provide additional information from both layers. Thanks, James ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request: New Link Type for IEEE 802.15.4 TAP
Hi, Is there something blocking my request? Concerns that I may address to get an assignment? Thanks, James On Fri, Feb 8, 2019 at 3:37 PM James Ko wrote: > Please assign a new DLT_/LINKTYPE_ value for IEEE802_15_4_TAP packets. > > The IEEE 802.15.4 TAP packet format proposal is in > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15429. > > IEEE 802.15.4 defines both PHY and MAC layers and the proposed format > enables the sniffer/tap device to provide additional information from both > layers. > > Thanks, > James > > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request: New Link Type for IEEE 802.15.4 TAP
Thanks. Created PR for libpcap and tcpdump. Wireshark changes pending. https://github.com/the-tcpdump-group/libpcap/pull/803 https://github.com/the-tcpdump-group/tcpdump/pull/734 The existing DLTs for IEEE 802.15.4 have versions for FCS, NOFCS, NONASK_PHY, and LINUX (address fields padded). The NONASK_PHY includes only fixed preamble bytes, and the FCS/NOFCS versions support for heuristic match for ZBOSS generated format again with some fixed fields. The proposed format attempts to wrap up the different types into one and provide an extensible TLV format for capture devices to provide additional meta-data. James On Fri, Feb 15, 2019 at 9:45 AM Michael Richardson wrote: > > James Ko wrote: > > Is there something blocking my request? Concerns that I may address > to get > > an assignment? > > I don't recall seeing it last week, sorry. > > > On Fri, Feb 8, 2019 at 3:37 PM James Ko wrote: > > >> Please assign a new DLT_/LINKTYPE_ value for IEEE802_15_4_TAP > packets. > >> > >> The IEEE 802.15.4 TAP packet format proposal is in > >> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15429. > >> > >> IEEE 802.15.4 defines both PHY and MAC layers and the proposed > format > >> enables the sniffer/tap device to provide additional information > from both > >> layers. > > 1) You are welcome to send pull request! > 2) I see that Guy has engaged your ticket. I could have sworn we already > had >802.15.4 DLT that could take a variety of extra data. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works|IoT > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on > rails[ > > > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Public Release of Z-Wave G.9959 TAP Specification
--- Begin Message --- Just two comments inline. On Mon, Dec 5, 2022 at 3:45 PM Denis Ovsienko via tcpdump-workers < tcpdump-workers@lists.tcpdump.org> wrote: > > > > -- Forwarded message -- > From: Denis Ovsienko > To: tcpdump-workers@lists.tcpdump.org > Cc: > Bcc: > Date: Mon, 5 Dec 2022 23:44:46 + > Subject: Re: [tcpdump-workers] Public Release of Z-Wave G.9959 TAP > Specification > On Mon, 5 Dec 2022 11:53:11 -0800 > Chris Brandson via tcpdump-workers > wrote: > > > Hello everyone, > > > > We are pleased to publish the draft Z-Wave G.9959 TAP Specification > [...] > > Hello Chris. > > Thank you for preparing the document. I am not familiar with the > standard to make more substantial comments, but a few things seem to > require some attention: > > * Page 7: "Length is a minimum of 4 octets and must be a multiple of 4. > The addition of new TLVs does not and must not require incrementing > the version number." -- this definition automatically creates a > problem space on the receiving/reading end of this encoding because > slightly more than 75% of all possible length values are invalid by > definition. The classic solution would be not to include the first 4 > octets into the length, and to count in multiples of 4, this way any > length value would be valid, free of underflows and better consumable > by simple parsers such as BPF bytecode. > > Note that the TAP header length field differs from the TLV header length field. I'm not opposed to omitting the header bytes from the TAP header length but just wanted to make sure we all understood the difference in this part of the document. For a little background: I know this specification was based on IEEE802.15.4-TAP ( https://github.com/jkcko/ieee802.15.4-tap) and that was based on IEEE802.11-RADIOTAP (https://www.radiotap.org/). This was also likely because IP header length and total length fields also includes the header bytes. * Page 8: "Z-Wave PHY Payload" -- is this the PPDU from Figure A.7 of > G.9959 2015/01, starting from "preamble sequence"? > > * Page 9: "length - number of octets for type in value field (not > including padding)" -- this definition looks better, but in the next > three TLV diagrams the length does include the T and the L. > > 4.1 FCS length should be 1 rather than 4 here. Padding not included. Regards, James --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
