[tcpdump-workers] Request for DLT value

Guy Harris guy at alum.mit.edu
Wed Apr 5 03:28:29 EDT 2017

On Apr 4, 2017, at 10:53 PM, Selvig, Bjorn <b.selvig at 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:


	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.

More information about the tcpdump-workers mailing list