User manual CACE TECHNOLOGIES PPI HEADER SPECIFICATION V1.0.7

[. . . ] Often such data of interest pertains to the PHY layer, but this need not always be the case. Whatever the carried information may be, the intent is that the information contained is only added to data captured in real-time, not stored packets. It is not intended to add arbitrary data to packets, such as annotations. That task is better suited to NTAR. 1. 2 Scope This document defines the general format of the PPI header, along with the formats of several fields. [. . . ] It MUST be between 8 and 65, 532 inclusive. pph_dlt This MUST contain a valid data link type as defined in pcap-bpf. h from the libpcap distribution. If an official DLT registry is ever created by the libpcap development team, then it will supersede this list. A capture facility can implement per-packet DLTs by setting pph_version to 0, pph_flags to 0, pph_len to 8, and pph_dlt to the DLT of the encapsulated packet. 3. 1. 4 3. 2 PPI Field Structure Each PPI field includes a type and length: typedef struct ppi_fieldheader { u_int16_t pfh_type; /* Type */ u_int16_t pfh_datalen; /* Length of data */ } ppi_fieldheader_t; 3. 2. 1 pfh_type The type of data following the field header MUST be a valid type value as defined below: Range 0-29, 999 30, 000-65, 535 Possible Values General-purpose field. Defined in section 5. If an unknown field value is encountered, it MUST be skipped according to the length rule in section 3. 3. Implementations MAY mark it as "unknown" as appropriate. © CACE Technologies, 2007 - 2008 Page 6 PPI Header Specification Version: 1. 0. 7 Date: 9/11/2008 3. 2. 2 pfh_datalen The length of the data, in bytes, that follows MUST be between 0 and 65, 520 inclusive. The end of the data MUST NOT exceed the total header length. Field Processing The first field header immediately follows the packet header (that is, if the packet header starts at byte 0, the first field header starts at byte 8). The starting point of each subsequent field header is defined by the "alignment" bit in pph_flags: · If the "alignment" bit in pph_flags is set to 1 AND pfh_datalen in field n is not a multiple of 4, then field n+1 will start at the next multiple of 4. For example, if pph_datalen in field 3 is 9, then the next three bytes MUST be considered padding, and field 4 will begin at byte 12. If the "alignment" bit in pph_flags is 0, then field n+1 will start at the next byte offset following the data in field n. 3. 3 · The "alignment" bit in pph_flags also applies to field data. That is, if the "alignment" bit is set and the field type is 7 bytes long, then there will be one byte of padding between the field header and field data. All padding bytes MUST be set to 0 in order to keep from exposing kernel memory to user space. 4. General-Purpose Field Types The following general-purpose fields are currently defined. Further general-purpose fields will be defined in later revisions of this document. Vendor-specific fields may be defined externally. Type 0-1 2 3 4 5 6 7 8 9 10 ­ 29, 999 20 12 48 22-65, 520 19-65, 520 ???4 8 Length (Bytes) Description RESERVED 802. 11-Common. Common (pre-n and . 11n) radio information. Interface information for packets coming from aggregating interfaces. Information regarding 802. 3 (Ethernet) packets. RESERVED 4. 1 4. 1. 2 Field Descriptions 802. 11-Common Zero or one 802. 11-Common fields may be present in a single header. [. . . ] A valid delimiter sequence consists of Idle start-of-frame(SOF) data, pad(optional) end-of-frame(EOF) fill(optional) idle Bit 2 = The frame has a symbol error. Value Type Unsigned integer Length 4 bytes Errors Unsigned integer 4 bytes 5. Vendor-Specific Field Types Type values 30, 000 to 65, 535 are reserved for vendor-specific applications. Vendor numbers are assigned by the WinPcap development team, and assignment may be handed over to a formal standards body in the future. To request a vendor number, send and mail to winpcap-users@winpcap. org. [. . . ]