[tcpdump-workers] Request for new DLT for RFTAP
Hi! I am posting to request a value for DLT_RFTAP and LINKTYPE_RFTAP. RFtap is a simple protocol designed to provide Radio Frequency (RF) metadata about packets, such as: * Accurate signal and noise power * Accurate timing and phase information * Accurate Carrier and Doppler frequency of every packet, and more. https://rftap.github.io/specifications/ RFtap protocol support is already integrated into Wireshark. Thanks, Jonathan Brucker. RFtap Packet Structure +---+ | Magic | | (4 Octets)| +---+ | Length32 | | (2 Octets)| +---+ | Flags | | (2 Octets)| +---+ | RFtap optional fields | . . . . . . +---+ | Payload | . . . . . . Short Description: All values are little-endian. The magic field is a fixed signature used to identify the packet. The signature is: 52 46 74 61 (hex), i.e. the ASCII sequence "RFta". The length32 field indicates how many 32-bit words are used by the entire RFtap header including the optional fields. The flags field is a bitfield indicating the presence of following RFtap fields (similar to radiotap "present" flags), or in few cases directly the value of boolean fields. The bitfield ordering starts from LSB. Payload: The encapsulated payload follows after the RFtap header. Interpretation of the payload is dependent on RFtap fields, specifically the RFtap Data Link Type (DLT) field. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new DLT for RFTAP
On Aug 31, 2016, at 9:18 AM, Jonathan Brucker wrote: > I am posting to request a value for DLT_RFTAP and LINKTYPE_RFTAP. > > RFtap is a simple protocol designed to provide Radio Frequency (RF) > metadata about packets, What types of packets? 802.11 packets? If so, this is probably better done in radiotap. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new DLT for RFTAP
The RFtap protocol is designed to encapsulate any type of packet: Wi-Fi, Bluetooth, or packets from any proprietary protocol. RFtap is designed to carry RF metadata which is not handled by current metadata protocols such as gsmtap, radiotap, and PPI. You can read more about the typical use case in: https://rftap.github.io/ and https://rftap.github.io/blog/2016/08/27/decoding-rds-with-rftap.html On Wed, Aug 31, 2016 at 4:38 PM, Guy Harris wrote: > On Aug 31, 2016, at 9:18 AM, Jonathan Brucker > wrote: > >> I am posting to request a value for DLT_RFTAP and LINKTYPE_RFTAP. >> >> RFtap is a simple protocol designed to provide Radio Frequency (RF) >> metadata about packets, > > What types of packets? 802.11 packets? If so, this is probably better done > in radiotap. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for new DLT for RFTAP
On Aug 31, 2016, at 11:49 AM, Jonathan Brucker wrote: > On Wed, Aug 31, 2016 at 6:27 PM, Guy Harris wrote: >> On Aug 31, 2016, at 11:03 AM, Jonathan Brucker >> wrote: >> >>> RFtap is here to bridge this gap, for all protocols. >> >> That's exactly why I don't like its current design! >> >> Can we please kill off the idea of meta-data headers that contain link-layer >> header types, so that you have a LINKTYPE_/DLT_ value where the packet >> payload could have extremely different protocol link-layer header types, now >> and forever? >> >> Now, if you want to provide the *measured* information in a >> protocol-independent fashion, a better way, that doesn't have the "LINKTYPE_ >> value says nothing whatsoever about the actual link-layer protocol" problem, >> we could have *multiple* LINKTYPE_ values, for "RFtap followed by Radiotap >> followed by 802.11" and "RFtap followed by GSMTAP followed by GSMTAP >> payload" and so on. > > We could split the 32-bit value of LINKTYPE It's a 16-bit value in pcapng: http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/pcapng/pcapng/master/draft-tuexen-opsawg-pcapng.xml&modeAsFormat=html/ascii&type=ascii#rfc.section.4.2 so you don't have 32 bits to use. >>> The cross section of BPF users and RFtap users may be empty. >>> RFtap is more oriented towards higher-level tools such as Wireshark >>> and Scapy. >> >> You are aware that Wireshark, at least, uses libpcap/WinPcap to capture, and >> therefore uses BPF when capturing? I'm not sure about Scapy, but it might >> support libpcap filters as well. > > Sure, I meant users that actually use the *filters* in BPF. For higher > level tools, BPF is mostly used just a conduit, with a filter to > accept all packets. > The RFtap the filtering is expected to be done mostly using Wireshark > dissectors or Scapy dissectors. Actually, the Wireshark developers expect people to do libpcap-layer filtering when using Wireshark, and often recommend doing it. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
