--- Begin Message ---A couple more editorial comments: In the description of the bits in the Flags field, I'd describe the 0x3000 bits as "PDU type dependent", and, after they're listed indicate that:For PDU types other than type 1 (auxiliary advertising), the PDU type dependent field indicates the checked status of the MIC portion of the decrypted packet: * 0x1000 indicates the MIC portion of the decrypted LE Packet was checked * 0x2000 indicates the MIC portion of the decrypted LE Packet passed its check For PDU type 1 (auxiliary advertising, the PDU type dependent field indicates the auxiliary advertisement type: * 0x0000: AUX_ADV_IND * 0x1000: AUX_CHAIN_IND * 0x2000: AUX_SYNC_IND * 0x3000: AUX_SCAN_RSP I'd redo the last two paragraphs as: The LE Packet field follows the previous fields. All multi-octet values in the LE Packet are always expressed in little-endian format, as is the normal Bluetooth practice. For packets using the LE Uncoded PHYs (LE 1M PHY and LE 2M PHY) as defined in the Bluetooth Core Specification v5.2, Volume 6, Part B, Section 2.1, it is represented as the four-octet access address, immediately followed by the PDU and CRC; it does not include the preamble. For packets using the LE Coded PHY as defined in the Bluetooth Core Specification v5.2, Volume 6, Part B, Section 2.2, the LE Packet is represented as the four-octet access address, followed by the Coding Indicator (CI), stored in a one-octet field with the lower 2 bits containing the CI value, immediately followed by the PDU and the CRC; it does not include the preamble. Packets using the LE Coded PHY are represented in an uncoded form, so the TERM1 and TERM2 coding terminators are not included in the LE packet field.
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
