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
