PANalyzr Troubleshooting

PANalyzr gets stuck / No packets in the Wireshark window
If there are no Bluetooth packets in the Wireshark window, attempt to generate the traffic again.

If packets are still not displayed in the Wireshark window, this could be an indication the detection threshold is too high or low.

If any PANalyzr USB errors are displayed in the terminal window, close the terminal window, detach, re-attach the PANalyzr hardware to the computer, and restart the PANalyzr software.

Brackle Troubleshooting

BR/EDR (E0) "SRES Assert" Error

When running brackle for E0 decryption, the user must input a valid master Bluetooth address, slave Bluetooth address, and 128-bit link key. If incorrect values are provided, the brackle utility will generate an error indicating an issue with the calculated Signed Response (SRES) value.

To resolve this, try the following solution options, then re-run the brackle utility:
• Check the slave Bluetooth address value for typos
• Check that the link key value provided is valid for the encrypted connection in the pcap file used
• Use the master Bluetooth address value in both the slave and master address parameter fields

Missing Packets
When running brackle, the utility will search the provided pcap file for the necessary packets needed for decryption to work. If all of the required packets are not seen in the capture file, the missing packet types will be listed in the output, and the brackle utility will quit.

To resolve this, it is necessary to generate a new capture file and re-run the brackle utility on that file.

Encryption Key Size (E0)
Brackle currently only decrypts BR/EDR E0 packets encrypted using a 16-byte encryption key size. If the key size is less than 16-bytes, then the message “Warning: Encryption Key Size less than 16 bytes. Redo capture with an encryption key size of 16 bytes” will be displayed the brackle utility will quit.

Failed E0 Decryption
Once brackle is done running on a BR/EDR capture file, and the new pcap file has been generated, the file should be checked for valid decrypted packets. These packets will be displayed after any LMP_start_encryption_req packet and before any LMP_stop_encryption_req or (possibly) an LMP_detach packet. If these previously encrypted packets do not appear to have been properly decrypted and dissected in the new capture file, creating a new capture file with the same devices, then rerunning brackle often resolves the issue.

If the packets still don’t properly decrypt, it is possible the wrong BDADDR was used in the master Bluetooth address parameter when brackle was run. Re-run the brackle command utilizing the slave Bluetooth address value in the master and slave parameter fields to resolve this.