Re: DLTs for Z-Wave

[Guy Harris <guy () alum mit edu>]

On Sep 6, 2014, at 3:35 AM, Joshua Wright <jwright () hasborg com> wrote:

> I request two DLTs for Z-Wave packet captures based on the ITU-T
> Recommendation G.9959 (http://www.itu.int/rec/T-REC-G.9959).
>
> My packet capture tool has support for three Z-Wave RF profiles
> (sometimes called "channel configurations"):
>
> R1 - 9.6 Kbps (908.42 North America, 868.42 Europe)
> R2 - 40 Kbps (908.4, 868.4)
> R3 - 100 Kbps (916, 869.85)
>
> The MAC format for R1 and R2 Z-Wave networks is identical, but the R3
> MAC is different with additional fields and different bit mask
> definitions.

So there are differences other than the FCS length?

> Unfortunately, there is no version or other indicator in
> the MAC frame to indicate if the packet is R1, R2, or R3. A decoding
> tool (e.g. Wireshark) needs an indicator as to the RF profile in use
> to properly decode the packet capture.
>
> I believe this MAC behavior warrants two DLT's for Z-Wave: one DLT for
> R1/R2 packets, and a second DLT for R3 packets.

Will all packets in a capture use the same profile?

If so, then, yes, two DLT_/LINKTYPE_ values will suffice.

Will the packet data be in the form specified by the "MAC Layer" part of Figure A.3 "General frame structure", with 
nothing added, removed, or transformed?  Or, for example, will it have radio metadata, along the lines of what radiotap:

        http://www.radiotap.org/

provides?  Will it include the FCS?

(And what does the "* R1 only" in that figure indicate?  Figure 7-4 "PPDU packet format" says the End of Frame 
Delimiter has the same note, with the * attached to the end-of-frame delimiter, so maybe they forgot to put the "*" 
into Figure A.3 after MFR?)

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers