[tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- Hello all, DLT_BLUETOOTH_LE_LL_WITH_PHDR was created close to a decade ago mainly to support Bluetooth LE sniffers. It includes parameters describing sniffer RF capture settings in addition to the BLE link layer packet. It was created in the days of Bluetooth 4.0, when BLE was simpler, without multiple PHY modes, extended advertising, isochronous PDU types etc. This link type is used mainly by Bluetooth LE sniffers and software processing sniffer output, most notably: - Ubertooth: https://github.com/greatscottgadgets/ubertooth - libbtbb (mainly used by Ubertooth): https://github.com/greatscottgadgets/libbtbb - Crackle: https://github.com/mikeryan/crackle - BtleJack (to support Crackle): https://github.com/virtualabs/btlejack - Sniffle (created by me): https://github.com/nccgroup/Sniffle Sniffle is a Bluetooth LE sniffer that supports many of the new features in Bluetooth 5.x, such as multiple PHY modes and extended advertising. Unfortunately, the existing link type definition lacks support for indicating PHY modes and distinguishing types of extended advertising packets. Also, the existing link type lacks means to indicate the direction of a packet when the direction is known; this reduces the effectiveness of advanced packet dissectors, and makes it harder to interpret PCAPs. There does exist another DLT for BLE sniffers (DLT_NORDIC_BLE), and its dissector implementation in Wireshark does support Bluetooth LE features up to v5.1. However the Nordic packet format is rather specific to the design of the Nordic BLE sniffer's firmware, so I'd need to mimic the firmware state machine of the Nordic sniffer if I were to use it. Also, the Nordic DLT is not compatible with existing tooling using DLT_BLUETOOTH_LE_LL_WITH_PHDR such as Crackle. Thus, there is a need to modernize DLT_BLUETOOTH_LE_LL_WITH_PHDR to support Bluetooth 5.x while maintaining backwards and forwards compatibility with existing software. Through discussions with Joakim Anderson (of Nordic) and Mike Ryan (Ubertooth developer), and going through several iterations of proposed protocol updates, I/we came up with this: https://gistcdn.githack.com/sultanqasim/8b6561309f5934f084a0d938ae733b7a/raw/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html I implemented support for it in the Wireshark dissector with this change: https://code.wireshark.org/review/#/c/37142/ The design goals for this change were: 1. Support new features added to the Bluetooth LE specification between versions 4.0 (when this DLT was first defined) and 5.2 (current). 2. Maintain backward compatibility so that old PCAPs, and PCAPs generated using software following the old version of the specification, retain their meanings unchanged under the new version of the specification. 3. Maintain forward compatibility so that PCAPs generated using the new version of the specification can be handled sensibly by software compliant with the old version of the spec (such as current/older Wireshark and Crackle versions). By repurposing unused flag bits, the proposed changes add the following features in a manner compatible with existing software: - Indication of the PHY mode used by the packet - Disambiguation of auxiliary advertisement packet types under BLE5 extended advertising - Indication of data packet direction when it is known (while maintaining support for unknown direction for backwards compatibility) - Disambiguation of broadcast and connected isochronous PDU types from advertising and data PDU types A couple other notes regarding the changes: - Repurposing MIC flag bits 0x3000 for auxiliary advertising is safe because advertising is never encrypted or authenticated. - I'm encoding the PHY in the flag bits rather than the two most significant bits of the RF channel field because some software (eg. existing Wireshark versions) don't mask out the currently unused upper bits of the channel. - I avoided creating an "extended header" flag because it would break forward compatibility (old Wireshark and Crackle versions would misinterpret new PCAPs with an extended header, which would annoy users). - In case future changes to the Bluetooth specification require more fields through an "extended header", the "Reserved for Future Use" PDU type 7 could indicate the presence of an extended header, but we'll cross that bridge when we get there. For now, we can maintain forward compatibility while fully supporting Bluetooth 5.2, and this makes life easier for everyone. Any comments on the proposed changes? What would it take to formalize these changes and have the definition on tcpdump.org updated? https://www.tcpdump.org/linktypes/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html Thanks, Sultan --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpd
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- 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: * 0x: 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
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- Thanks for the feedback, your suggestions do make the specification clearer. I edited the specification based on your suggestions, and I also clarified the usage of integer bit fields within the Flags field. Link to the updated version of the spec with the latest changes: https://gistcdn.githack.com/sultanqasim/8b6561309f5934f084a0d938ae733b7a/raw/199fb1867642c927f768fe7d67dae2a639acb48e/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html Best regards, Sultan On Fri, Jul 10, 2020 at 3:58 PM Guy Harris wrote: > 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: > > * 0x: 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
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- For an advertising physical channel PDU, it appears that the PDU type is in the least-significant 4 bits of the PDU header. Is that not present in an auxiliary advertising packet?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- The reason the extra auxiliary PDU type field is needed is that the four-bit auxiliary PDU type is ambiguous and context-dependent for auxiliary PDUs. See Volume 6, Part B, Section 2.3, Table 2.3. The four least significant bits of the advertising PDU header will be 0b0111 for AUX_ADV_IND, AUX_CHAIN_IND, AUX_SYNC_IND, and AUX_SCAN_RSP, so you need extra information to distinguish those. The ADV_EXT_IND PDU can be distinguished from those despite also being 0b0111 because it's not on a secondary advertising channel (ie. not an auxiliary advertisement). Sultan On Fri, Jul 10, 2020 at 6:30 PM Guy Harris wrote: > For an advertising physical channel PDU, it appears that the PDU type is > in the least-significant 4 bits of the PDU header. > > Is that not present in an auxiliary advertising packet? --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
