--- 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/tcpdump-workers
