add dlt (Data Link Type) and qual (quality) fields in PDU metadata

[bastibl]

Can you explain why this fields are needed? If RFtap requires the link type, couldn't it just add them with an additional block?

[jonathanbrucker]

dlt (Data Link Type) field is used to derive how the packet should be encapsulated, ie to tell Wireshark how to decode the data. It could be used also in foo-wireshark block and is generally a good thing to have attached directly to the PDU, signifying the "PDU type".

[bastibl]

and Wireshark allows to set the DLT per Frame? Isn't this an option at the very start of the PCAP file? AFAIS, that's something that should be set per PCAP file and not be annotated to every frame.

Do you have a special use case in mind that really requires this field?

[jonathanbrucker]

Regarding "qual" field - it's a generic field indicating the quality of the packet, from 0.0 to 1.0. It is generic to all protocols (rftap field 8), as opposed to LQI which is Zigbee-centric and not defined for other protocols. It could be added externally, by reading "LQI" and setting "qual", however I'm not sure exactly how to do it (in GNU Radio there is "PDU Set" but there is no "PDU Get")

RFtap Field 8: Signal Quality Field name: qual Signal quality, in arbitrary units from 0.0 (worst) to 1.0 (best). This is sometimes used as a substitute for SNR, when accurate power and/or noise level estimation is difficult to implement.

[bastibl]

I don't think that the ZigBee transceiver should calculate a derived value for the RFtap protocol. If RFtap want's to map things to a generic 0.0 to 1.0 value, then RFtap should do the mapping.

[jonathanbrucker]

Regarding DLT per frame - yes, Wireshark RFtap dissector allows it. This is designed for the field of cognitive radio, such as Google summer of code gr-sigint and similar efforts. The general idea is to allow a SDR receiver to tune a specific band, say 2.4G, and detect and decode all the packets found within the band.

Just as when tapping an Ethernet link, you would like to get all packet types like ARP, BOOTP and Bridge annoucements, and not just IP packets (TCP/UDP).

So the same goes for packets in the "Air", i.e. RF: RFtap is designed to encapsulate any packet that may be detected in the air, including packets which don't have a Data Link Type (just power, duration, frequency etc).

[jonathanbrucker]

The idea encapsulating all the packets in a medium is an old one.

For Ethernet communication medium, there is https://en.wikipedia.org/wiki/EtherType For Pcap files, there is DLT Data Link Type, http://www.tcpdump.org/linktypes.html For capturing from dissimilar interfaces, there is Linux cooked-mode capture (SLL) https://wiki.wireshark.org/SLL

and now, for RF, there is RFtap, which can encapsulate any packet received over the RF medium.

[bastibl]

Thank you for explaining the concept, but encapsulating different payloads inside an Ethernet frame is a bit different from having a different link type per frame. Actually, RFtap is introducing a custom variable that has absolutely nothing to do with the DLT of Wireshark (albeit I understand that it is useful).

My main point is that this RFtap support is not required and can be added easily with another block. I don't think that its a good idea that the PHY has to add metadata of all custom monitoring tools that are available. Especially since it absolutely not required.

[jonathanbrucker]

All right, I'll use an adapter PDU block instead of modifying the PHY. We can close this for now.