Bluetooth RPA Rotation Debugging with Bluetooth Explorer
Randomized Bluetooth addresses are good privacy and bad debugging when the team treats every new address as a new device. The bug report says duplicate devices; the protocol evidence often says address rotation was working and the app forgot how to group the clues.
TL;DR: Use Bluetooth Explorer to record the old address, new address, rotation timing, advertised data, bond state, and identity-resolution result before changing discovery logic or blaming the peripheral.
Why does RPA confuse discovery?
A resolvable private address is supposed to change. The problem starts when product logic expects a stable address and ignores the identity clues that should connect several sightings to the same device.
What should Bluetooth Explorer capture?
Capture address type, timestamp, advertised name, service UUIDs, manufacturer data, RSSI pattern, and whether the client is bonded. The useful evidence is the sequence, not a single scan row.
How should teams retest?
Run one controlled scan for a full rotation window, then repeat after toggling bond state or app permissions. Keep the location fixed so movement does not masquerade as a privacy behavior change.
When is grouping risky?
Do not group devices only because the names match. In a crowded room, matching names and similar RSSI are weak. Group only when identity resolution, payload continuity, or a controlled test path supports the decision.
| Observation | Likely meaning | Next move |
|---|---|---|
| Address changes but payload stays consistent | Privacy rotation may be normal | Check identity resolution before creating a duplicate device record |
| Name matches across several nearby devices | The app may be grouping too aggressively | Require stronger payload or bond evidence |
| Rotation timing changes after reconnect | Bond state or controller policy may be involved | Compare bonded and unbonded scans under the same setup |
How do you keep the scan useful?
- Log timestamps for every address change instead of saving one screenshot.
- Separate address type from advertised name in the notes.
- Record whether the phone is bonded to the peripheral.
- Keep the scanner still for the first pass to reduce RSSI confusion.
- Retest with one variable changed: bond state, permission, firmware, or distance.
What should users ask?
Does a new Bluetooth address always mean a new device?
No. A device using a resolvable private address can change addresses while still representing the same physical peripheral.
What is the safest grouping clue?
Identity resolution from a bonded relationship is stronger than name matching, RSSI closeness, or a single repeated service UUID.
When should Bluetooth Explorer users stop grouping sightings?
Stop when the evidence is only a shared name or a vague signal pattern in a busy area.
Useful references
Bottom line: Bluetooth Explorer helps teams debug RPA rotation by turning duplicate-looking scan rows into timing, address type, bond state, and identity-resolution evidence.
