On Apr 4, 2017, at 10:53 PM, Selvig, Bjorn <b.sel...@ti.com> wrote: > This header is for support of TI boards as sniffer adapter (LAUNCHXL boards) > for low power wireless protocols like BLE, 802.15.4 or TI proprietary > protocols.
So there are two ways of handling this: 1) a single LINKTYPE_/DLT_ value where the header includes a field specifying the actual link-layer header following the radio metadata header; 2) separate LINKTYPE_/DLT_ values for each actual link-layer type, each of which means "XXX with a radio meta-data header". I *very very very very very very very very very very very very very very very* strongly prefer the second way, as it means that filter code generated by pcap_compile() for each of the LINKTYPE_/DLT_ values in question can just skip the radio meta-data header and test the fields of the actual link-layer header. So, this would mean a LINKTYPE_/DLT_ value for: Bluetooth Low Energy, which would be similar to LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR: http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html but perhaps with more fields; 802.15.4, which would be similar to one of the LINKTYPE_IEEE802_15_4 values, but with a radio pseudo-header; one or more for the TI proprietary protocols. > The packet info header will contain the following information: > - Interface type and Interface ID (For example COM 142). Is that necessary? If the file is a pcapng file, that would presumably be part of the interface name in the Interface Description Block. > - Frequency > - Channel > - Protocol and PHY If by "Protocol" you mean "the actual link layer", then that doesn't belong in the header; see above. (Yes, I think PPI was a mistake, whose only reason for existence is that pcapng wasn't ready yet.) The PHY is presumably link-layer dependent, so its values would be different for different LINKTYPE_/DLT_ values. > - RSSI value "RSSI" in the 802.11 sense of "a number whose only significance is that, for any given interface, a bigger value means a stronger signal", or "RSSI" in the sense of "dB from some standard point, e.g. dBm"? > - Frame check status (CRC Status) "Status" as in "CRC error" or "no CRC error"? That, ideally, belongs in the flags field of a pcapng Enhanced Packet Block. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers