Set CRC and payload decrypted flags PCAP packet header #66
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After attempting to sniff some Bluetooth BR/EDR traffic, I saw that the correct plaintext data was present in the packet bytes in Wireshark, but Wireshark was not decoding the packet any more than the "BT BR/EDR RF" packet type, even though I should have seen LMP and L2CAP packets decoded as well. Digging into the code for the Wireshark BT BR/EDR packet dissector shows that the LLID of the packets is only decoded if there is a non-zero data length, the CRC is checked, and the CRC is valid: https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-btbredr_rf.c#L1558-L1559
These bits should be set in the BT BR/EDR packet "Flags" field whenever
libbtbb
adds a new packet to the PCAP, but currently they're not being set.This PR sets the
BREDR_CRC_CHECKED
,BREDR_CRC_VALID
, andBREDR_PAYLOAD_DECRYPTED
flags here so that the PCAP is properly decoded in Wireshark.This solution probably can't be merged in its current state, as we're setting these flags without actually ensuring the data is encrypted or the CRC is valid. But hardcoding them was helpful for my use case, so I'm putting this PR up as an FYI of this issue and so others can use.
For a full solution, maybe
ubertooth-rx
andubertooth-follow
could have a command line flag that would set these flags when enabled?