tcpdump mailing list archives
Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
From: Sultan Khan via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Thu, 9 Jul 2020 17:15:04 -0400
--- Begin Message --- From: Sultan Khan <sultanqasim () gmail com>
Date: Thu, 9 Jul 2020 17:15:04 -0400
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/tcpdump-workers
Current thread:
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Guy Harris via tcpdump-workers (Jul 09)
- Message not available
- Fwd: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 09)
- Re: Fwd: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 09)
- Message not available
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Guy Harris via tcpdump-workers (Jul 10)
- Message not available
- Message not available
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 10)
- Fwd: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 09)
- Message not available
- Message not available
- Message not available
- Message not available
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Guy Harris via tcpdump-workers (Jul 10)
- Message not available
- Message not available
- Message not available
- Message not available
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 10)
- Message not available
- Message not available
- Message not available
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Guy Harris via tcpdump-workers (Jul 13)
- <Possible follow-ups>
- Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 10)
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 13)
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 13)
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Guy Harris via tcpdump-workers (Jul 13)
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 13)
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 13)
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Guy Harris via tcpdump-workers (Jul 13)
- Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR Sultan Khan via tcpdump-workers (Jul 13)