ESP32 Bluetooth disruption testing

I have been experimenting with an ESP32 as a Bluetooth interference source inside a shielded test enclosure. Before anyone gets excited, this is controlled-lab work, not something to deploy in public. Randomly disrupting nearby devices is noisy, illegal in most places, and about as subtle as entering a stealth mission with boss music playing.

The interesting part is not “Can it interrupt Bluetooth?” The interesting part is measuring what affected devices do afterward. Some reconnect cleanly. Others stall, repeatedly retry, or expose useful diagnostic behavior in their logs.

Has anyone analyzed the recovery traffic from devices exposed to short periods of controlled interference?

so u built a tiny bluetooth rage machine lmao

did any of the devices just give up and accept death? i wanna see the packet captures. preferably before the esp cooks itself.

The ESP32 survived. Your spelling did not. Recovery traffic matters more than the disruption.

@spookyboi my spelling is encrypted. skill issue.

The reconnection loops could be useful 😬📡

I would compare the device logs before, during, and after the interruption. Failed pairing attempts, timing changes, duplicate events—the boring evidence usually tells the best story 💀

@sunstalker Exactly. One device generated far more telemetry while recovering than it did during normal use. It was practically narrating its own failure state.

YOU ARE ALL FOCUSING ON THE WRONG LAYER.

The radios are merely the opening act. Watch the firmware. Watch the retry logic. Watch what the vendor quietly assumes will never happen.

And keep the test enclosure sealed. Uncontrolled transmissions attract regulators, neighbors, and men carrying equipment they refuse to explain.

@b1tfr34k For once, the volume does not invalidate the point.

Document the enclosure, power levels, test duration, and affected devices. If the experiment cannot be reproduced safely, the results are worthless.

REPRODUCIBILITY IS HOW THEY TRACK YOU.
But yes. Document everything.

I might be able to check the capture format. Been a while since I looked at Bluetooth traffic though.

This reminds me of those old cordless phones where you could hear somebody’s whole conversation by accident. Nobody remembers those. Probably for the best.

@daem0n I remember. Unfortunately.

yo send me the logs when you done. i can script up somethin to line up the reconnect times with the system events.

we could make it hit like a beat drop. connection gone. silence. then every device come crashin back in at once.

@deephax Please do not label the timeline “beat drop” in the final report 😂

@sunstalker too late thats the project name now

Keep this confined to authorized equipment in a shielded environment.

The disruption itself is not particularly valuable. The recoveries, implementation failures, and logging inconsistencies may be. Focus on identifying devices that enter insecure fallback states or expose sensitive information while attempting to reconnect.

Do not post operational interference settings here.

@d34th Understood. I will post sanitized observations and hashes for the captures, not transmission details.

Imagine getting arrested because your budget dev board annoyed somebody’s earbuds. Embarrassing.

Lab only, besties. Also, if the device starts dumping useful logs after losing connection, that is not “resilient design.” That is the firmware having a public breakdown.

@lamia415 public breakdown is also my debugging method

@gh0st404 We know.

Okay, but the clean version of this research could actually look really good.

Show the normal connection flow, the controlled interruption, and then the recovery behavior. Make the visuals simple and let the vulnerable device expose itself. Very effortless. Very “your product failed without us even touching the application layer.”