>> 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?
Yes, notably R3 uses an 8-bit sequence number, where R1 and R2 use a 4-bit sequence number in the Frame Control field. The R3 header is one byte larger than the R1/R2 header to accommodate the larger sequence number field. Also, the frame control bit mask is different in R3 and R1/R2. >> 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. Yes, all packets in a capture will be of the same profile. > 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? It would be reasonable to anticipate additional characteristics that could make their way into a capture file for received traffic, such as RSSI and noise levels, antenna selection, etc. For the requested link types, the packet will start with the MAC Layer data (the 4-byte HomeID comes first), including an FCS, with no additional data. For captures that require RSSI or additional metadata to be associated with the packet, RadioTap or PPI could be used similar to what is already done for Bluetooth Low Energy and other wireless protocols. > (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?) I believe that to be an error in the specification. Both R1 and R2 have an EHR indicator that is not present in R3 frames (at least in the dozen or so devices I have been testing with). For these DLT’s, the packet will contains the MPDU/PSDU data and will not contain the EHR or SFD data — just the “MAC Layer” shown in Figure A.14 and A.15. Thank you, -Josh _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
