With the Bluetooth sniffer working reliably, I wanted to move beyond simply capturing packets. The next challenge was more interesting: could I identify my own phone from all the Bluetooth traffic around me?
At first that sounded simple. It turned out to be a fantastic lesson in how modern Bluetooth devices actually work.
Watching the Airwaves
My first idea was to build a simple live view showing which Bluetooth devices were advertising most frequently. Using tshark, I extracted every advertising address from the capture and counted how many times each appeared.
3953 35:a2:27:33:e0:3b 3672 35:6b:be:53:c9:de 3221 1f:af:f2:e8:ac:d4 2805 ee:91:61:80:ae:06
It was immediately obvious that some devices were advertising far more frequently than others. The problem was I had absolutely no idea which physical device each address belonged to.
My First Mistake
My initial thought: "I'll simply turn Bluetooth off on my phone and see which address disappears."
That sounded perfectly reasonable. Unfortunately, the counters kept increasing and it became impossible to tell which addresses actually belonged to my phone.
Designing a Better Experiment
Instead of watching one continuously growing capture, I created two completely separate packet captures.
Capture One — Phone Bluetooth OFF
Twenty seconds. Saved as phone-off.pcap. A clean baseline of everything advertising in the environment without my phone in the mix.
Capture Two — Phone Bluetooth ON
Twenty seconds. Same location, same duration — the only variable was my phone's Bluetooth state. Saved as phone-on.pcap.
Two clean datasets to compare. This approach removed the noise from cumulative packet counts and gave me something I could actually reason about.
Comparing the Results
The "Bluetooth OFF" capture showed a number of regular advertisers that clearly weren't dependent on my phone — they continued regardless of my handset's state:
1f:af:f2:e8:ac:d4 ee:91:61:80:ae:06 35:a2:27:33:e0:3b 35:6b:be:53:c9:de
These were just environmental — other devices nearby doing their own thing.
Something New Appeared
When I looked at the "Bluetooth ON" capture, several completely new addresses had appeared that simply hadn't existed in the first capture:
60:a8:2d:26:5b:cf 7c:98:b5:f2:f5:ca 6e:a2:81:31:98:a7 7f:8c:ee:39:4b:71
These addresses only appeared when Bluetooth was enabled on my phone. That was the evidence I needed — they were strongly associated with my phone's Bluetooth being active. But there was something unexpected about the result.
One Phone. Multiple Addresses.
I had expected one phone to use one Bluetooth address. Instead, my phone appeared to advertise using multiple random addresses simultaneously.
At first I thought something was wrong with the capture. After digging deeper I discovered this behaviour is completely normal. Modern Bluetooth devices use Bluetooth Low Energy Privacy.
The thing I was trying to do — identify a specific device by its Bluetooth address — is exactly what BLE Privacy is designed to prevent. The difficulty wasn't a flaw in my experiment. It was a feature of the protocol.
Bluetooth Isn't As Simple As It Looks
Another lesson came from analysing manufacturer information in the packets. Some clearly identified themselves as Apple advertisements. Others carried Microsoft's company identifier. At first I assumed I'd found lots of different manufacturers nearby.
Looking more carefully, I realised protocol analysis isn't always that straightforward. Some values were genuine Bluetooth SIG company identifiers. Others turned out to be artefacts of how tshark was parsing certain packet types rather than real manufacturer IDs. Packet analysis is as much about understanding your tools as it is about understanding the data.
Thinking Like an Engineer
Looking back, today's session wasn't really about Bluetooth. It was about problem solving. The workflow that emerged:
- Observe something interesting
- Form a hypothesis
- Design a controlled experiment
- Collect clean evidence
- Compare the results
- Draw conclusions from data, not assumptions
That's the same process used in networking, cybersecurity, embedded development, and debugging. The Bluetooth packets were simply today's dataset.
What I Learned
The biggest lesson wasn't a command or a piece of software. It was understanding that modern Bluetooth devices actively protect user privacy — and that privacy protection is the reason identifying devices from captures is genuinely hard.
Rather than immediately revealing every nearby device, Bluetooth Low Energy presents a puzzle that has to be solved using careful observation and controlled experiments. That makes it far more interesting than I originally expected.
What's Next
The hardware setup is complete. The next phase moves away from packet capture and towards making sense of the data. Rather than long tshark one-liners, I'm planning to build a Python application that can analyse captures, track devices across address changes, and eventually run as a live Bluetooth dashboard for the homelab.
The setup phase is done. The real investigation begins.