Two Adapters, One Lab
Building a Complete Bluetooth Research Setup

The sniffer was working. But listening isn't enough. To really understand Bluetooth you need to control both sides of the conversation — and that meant adding a second device. Getting it working was harder than expected.

BLE Security Kali Linux Bluetooth Home Lab

After Part 2 I had the nRF52840 sniffer working and I understood why spotting my own phone in a Bluetooth crowd was harder than expected. BLE Privacy meant my phone was cycling through random MAC addresses — one phone, multiple identities, all by design.

That got me thinking about the next step. The sniffer is great at listening passively, but it can't create connections or advertise its own services. To really understand Bluetooth I needed to control both sides — a sniffer to watch, and a controller to participate. That meant adding a second Bluetooth device to the Kali box.

A New Adapter

I added a USB Bluetooth adapter to the machine. Running lsusb confirmed Linux saw it immediately:

Bus 003 Device 007: ID 0bda:a760 Realtek Semiconductor Corp. Bluetooth Radio

At first glance everything looked perfect. Hardware detected, driver loaded. Unfortunately that was only the beginning.

The First Problem

Although Linux detected the adapter, it wasn't actually usable. Checking the Bluetooth controller showed:

hci0
DOWN

Trying to bring it up produced a sequence of errors — first Connection timed out (110), then later Authentication Failed. It wasn't clear yet what was wrong. The list of suspects was long: missing firmware, driver issues, kernel compatibility, or just faulty hardware.

Investigating Properly

Rather than randomly trying fixes, I started collecting evidence. The first useful clue came from the kernel logs — the Realtek firmware was actually loading successfully. The controller was reporting itself as RTK_BT_5.0 and Linux confirmed the firmware had been uploaded correctly.

That immediately ruled out one of the biggest suspects. The adapter wasn't missing firmware. Using Bluetooth management tools confirmed the controller was responding — it reported itself as a Bluetooth 5.1 device with LE support, advertising support, and Secure Connections. So the controller was very much alive. It simply refused to enter the powered state.

Troubleshooting pattern: Confirm hardware detection → verify firmware loading → check controller state → read kernel logs → test management tools → reset → verify. Every step rules out one more possibility until the real problem becomes obvious.

The Fix

Instead of continuing to fight the Bluetooth stack, I reset it completely. The solution turned out to be surprisingly simple:

sudo systemctl stop bluetooth

sudo modprobe -r btusb btrtl

sudo modprobe btusb

sudo systemctl start bluetooth

Reloading the Bluetooth kernel modules changed everything. Running hciconfig -a now showed:

UP RUNNING

Why Two Bluetooth Devices?

This was the biggest realisation of the session — and it took getting both devices working to see it clearly.

Originally I thought I just needed "a Bluetooth adapter." Now I understand I actually need two completely different things doing two completely different jobs:

The nRF52840 acts like Wireshark. It listens passively. It never participates in Bluetooth communication — it just watches every packet fly past and hands them to Wireshark for analysis. It's the observer.

The Realtek adapter actually participates. It connects, pairs, advertises, and exchanges data. It's the actor.

With both working together I can create Bluetooth traffic while simultaneously capturing every packet independently. That's a very different capability from just having a sniffer.

The Lab — Current State

Looking back over the past few sessions, the Kali machine has become a surprisingly capable wireless research platform without me really planning it that way.

Wi-Fi
Realtek RTL8812AU
Monitor mode · Packet capture · Wireless security research
Software Defined Radio
RTL2838
SDR · Radio analysis · RF experiments · Entropy source (RTL-TRNG)
Bluetooth Sniffer
Nordic nRF52840 Dongle
Passive BLE packet capture · Wireshark integration · Advertising analysis
Bluetooth Controller
Realtek BT 5.1 USB Adapter
Active connections · Pairing · Advertising · Testing · Development

What This Makes Possible

Now that both Bluetooth devices are working, the next phase is building a controlled test environment rather than relying on whatever random devices happen to be nearby. Instead of passively watching other people's traffic, I can generate my own — then capture and study exactly what happens.

That shift from observer to experimenter is what Part 4 is about.