Fix “No default controller available” on Kali (BlueZ): btusb, rfkill, systemd, and USB dongle checks

---

Start here: is the controller missing, blocked, or ignored?

Before you “fix Bluetooth,” do one thing: classify the failure. This error is a signpost, not a diagnosis. Your goal is to answer a single question: Does the kernel see a Bluetooth HCI device right now?

I learned this the hard way on a travel day: airport Wi-Fi, a USB hub, a cheap dongle, and 20 minutes of “service restarting” that did absolutely nothing. The moment I checked for an HCI device, the truth was immediate: there was nothing there to manage.

The 3 states: Blocked vs Not detected vs Detected but unmanaged

• Blocked: rfkill shows Bluetooth blocked (soft or hard). HCI may or may not appear.
• Not detected: btmgmt info and hciconfig show nothing; logs show USB attach/detach or nothing at all.
• Detected but unmanaged: an HCI exists, but bluetoothctl show can’t select a default controller (or shows “not powered”).

Proof command trio: rfkill + HCI tools + bluetoothctl

Copy/paste these in order:

rfkill list
btmgmt info || true
bluetoothctl show

Quick truth: if there’s no HCI, BlueZ can’t “restart” its way into one

This is the moment where people burn an hour. If the kernel can’t see an HCI device, BlueZ is basically a manager showing up to an empty office.

---

rfkill first: the invisible “no controller” mask

The Linux kernel includes rfkill, a subsystem designed to disable radio transmitters (Wi-Fi, Bluetooth, WWAN). That’s good. But it’s also why this error can look like a driver failure when it’s really a radio block.

My most embarrassing version of this was on a Dell laptop: I “fixed” Bluetooth three times—then realized I’d bumped a hardware toggle while moving the machine. The logs were fine. BlueZ was fine. The radio was simply not allowed to transmit.

Soft vs hard block (and why hard blocks waste hours)

• Soft blocked: the OS can toggle it. Usually solvable from the terminal.
• Hard blocked: a physical switch, BIOS setting, or firmware airplane mode. Terminal commands won’t override reality.

The unblock sequence that you verify, not just run

rfkill list
sudo rfkill unblock bluetooth
rfkill list

Don’t “trust” the unblock—verify it. The second rfkill list is your proof.

Laptop toggles/BIOS/airplane-mode gotchas (common US hardware patterns)

• Airplane mode toggles can hard-block radios on some laptops.
• BIOS/UEFI wireless settings sometimes let you disable Bluetooth separately from Wi-Fi—especially on systems where you’ve already wrestled with boot settings during a Kali dual-boot GRUB fix.
• Fn keys can flip states without you noticing (especially when you’re tired and chasing “just one more fix”).

---

HCI reality check: prove the kernel sees Bluetooth hardware

This is the section that separates “Bluetooth troubleshooting” from hardware reality. You’re looking for a Bluetooth controller interface—typically hci0. If you don’t have one, your next steps are about enumeration, not pairing.

In my own notes, I call this the “don’t negotiate with the void” check. Because that’s what it feels like: trying to convince BlueZ to manage a controller that doesn’t exist.

What “good” looks like in btmgmt / hciconfig

Try:

btmgmt info
hciconfig -a

Good typically means you see an index (like hci0) and some basic capabilities. Even if it’s “powered: no,” the controller is at least present.

What “bad” looks like: empty indexes, invalid index, nothing enumerated

• btmgmt info shows no controllers.
• hciconfig outputs nothing.
• bluetoothctl can’t show a default controller because there isn’t one.

Open loop: why you can see some Bluetooth logs even when there’s no controller

Because the software stack still starts. bluetoothd can run, systemd can report “active,” and D-Bus can happily offer an API—while the kernel has no HCI device to expose. That mismatch is exactly what this error is telling you.

Show me the nerdy details

BlueZ is the user-space Bluetooth protocol stack, and it interacts with the kernel’s Bluetooth subsystem. If no controller is enumerated at the kernel level, user-space can’t create a “default controller.” That’s why controller presence checks are so high-signal: they tell you whether you’re fixing user-space behavior or hardware detection.

---

systemd + bluetoothd: when “active (running)” lies

If you’re on Kali, you’re almost certainly on a systemd-based setup. That means the Bluetooth daemon can be “running” while still being effectively useless. Not because systemd is bad—because it reports service state, not adapter availability.

I’ve watched this play out on a VMware lab: the service was green, the commands worked, and yet the controller never appeared. The issue was USB passthrough. The “active” status was basically a polite shrug—very similar to the kind of “everything looks fine” confusion you get after certain updates in a Kali VirtualBox setup that breaks after an update.

Confirm bluetooth.service status (then immediately pivot to evidence)

systemctl status bluetooth --no-pager

Look for obvious failures, but don’t stop here. A healthy service doesn’t guarantee a controller.

Read the right logs: journalctl -u bluetooth -b

journalctl -u bluetooth -b --no-pager

You’re scanning for lines that mention firmware load failures, adapter bring-up failures, timeouts, or repeated USB resets.

Here’s what no one tells you… “Running” can still mean “nothing to manage”

If your HCI check shows nothing, logs become your truth serum. The service can be stable and still “manage” zero adapters.

D-Bus and stale state: why restarting helps once (then the error returns)

If a restart temporarily makes the controller appear, you’re likely dealing with state or power issues: autosuspend, hub instability, or a driver that gets wedged after sleep. That’s a clue—not a victory lap.

---

btusb + module reload: the safest “reset button”

Most USB Bluetooth adapters use the btusb kernel module (with helpers like btintel, btrtl, or vendor-specific modules). If your system is in the “ignored” state—HCI kind of exists, but behavior is weird—then a module reload is often a clean, reversible move.

Personal rule: I reload modules before I reinstall packages. It’s like resetting a stuck door latch instead of rebuilding the whole house—and it fits the same “do the boring proof first” mindset behind building a dependable toolkit of essential Kali tools.

Confirm modules: what you’re looking for

lsmod | grep -E 'btusb|bluetooth|btintel|btrtl|btbcm'

You don’t need every vendor module—just enough to confirm the stack is present and your adapter’s driver is loaded.

The unload/reload sequence (safe, reversible)

sudo systemctl stop bluetooth
sudo modprobe -r btusb
sudo modprobe btusb
sudo systemctl start bluetooth
bluetoothctl show

Success criteria: after this, bluetoothctl show should display controller details rather than the “no default controller” error.

When reload works: what it implies about suspend/resume or driver state

• If it works after reload but breaks later: suspect autosuspend, hubs, or VM USB glitches.
• If it never works: suspect missing firmware, blocked radios, or hardware enumeration issues.

---

Firmware signatures: decode “-2”, “-110”, and opcode failures

This is where the logs stop being “noise” and start being instructions. When Bluetooth fails to initialize, the kernel often tells you exactly what went wrong—just not in a friendly way.

I once spent 45 minutes blaming BlueZ for what turned out to be a missing firmware blob after a clean reinstall. The log line was there the whole time. I just wasn’t reading it like a clue—especially common when you rebuilt your system from a stick and had to think about things like Kali persistent USB + Secure Boot before you even got to “Bluetooth.”

“Failed to load firmware file (-2)”: missing blob / wrong path

In Linux error codes, -2 often corresponds to “file not found.” If the kernel is trying to load firmware and can’t, you’ll see this kind of message in dmesg or the journal. The fix is usually: install the right firmware package for your chipset, then reboot (or replug/reload).

Timeout / transport failures (often seen as -110): power, suspend, or USB instability

Timeout-style failures often point to transport problems: flaky hubs, poor power, aggressive autosuspend, or a controller that’s crashing during init. If you’re using a tiny dongle on a front USB port through a hub, this is where the story gets suspicious.

Open loop: the log pattern that suggests a clone/counterfeit dongle

Some ultra-cheap dongles identify as something common, but behave inconsistently under Linux. You’ll see repeated attach/detach cycles, odd vendor IDs, or initialization sequences that fail in the same spot every time. The “fix” can be replacing the dongle with one that has predictable Linux support—because you can’t patch honesty into a counterfeit chipset.

---

USB dongle checks: prove it’s real hardware, not marketing

USB dongles are supposed to be the easy fix. Sometimes they are. Sometimes they’re the reason you’re here.

I keep two dongles in my kit: one “known good” and one “mystery.” The mystery one is for learning. The known good one is for getting work done when I’m on a deadline. If you’re time-poor, you want to become the kind of person who owns one “boring and reliable” dongle—the same way a well-built Kali lab infrastructure saves you from chasing phantom issues.

lsusb + topology: hubs, front ports, and power dips

lsusb
lsusb -t

• If the dongle doesn’t appear at all: switch ports, remove hubs, try another machine.
• If it appears and disappears: suspect power, hub instability, or a failing adapter.

USB 2.0 vs 3.x quirks (yes, this can matter)

USB 3.x environments can introduce interference and stability issues for some tiny radio devices. If you’re troubleshooting, it’s worth testing a plain USB 2.0 port—or at least removing the dongle from a noisy hub chain.

“CSR / Bluetooth 5.x” listings: what they do not guarantee on Linux

Marketing labels aren’t driver support. Two products can claim the same Bluetooth version and behave very differently. What matters is chipset support in the Linux kernel plus stable firmware behavior.

Open loop: why two “identical” dongles behave differently

Because “identical” on a product page isn’t identical in silicon. Revision changes happen. Counterfeits happen. If you want reliability, you test and you keep a known-good spare.

---

VM branch: when the controller is trapped on the host

If you’re running Kali inside VirtualBox, VMware, or UTM, you have a special kind of trap: your Bluetooth controller may be perfectly healthy… on the host. The guest never truly owns it, so BlueZ never sees it. If you’re still deciding your platform, start with a clean comparison of VirtualBox vs VMware vs Proxmox for VM-based pentesting so you know what trade-offs you’re inheriting.

I’ve watched people debug inside the guest for days while the dongle was quietly claimed by macOS or Windows. The fix was not “reinstall BlueZ.” The fix was “pass the USB device through correctly.”

USB passthrough sanity: does the guest own the device?

• Confirm the device is attached to the VM, not the host.
• Unplug/replug after the VM is running (some hypervisors bind devices at boot only).
• If you can’t pass through Bluetooth reliably: consider using a dedicated USB dongle for the VM.

Host Bluetooth conflicts: when the host grabs the controller first

Your host OS may automatically connect to the dongle or internal controller. That means the guest sees nothing. If you want Bluetooth in the guest, you need a controller the host isn’t actively using.

Snapshot/suspend weirdness: the “replug is the fix” reality

VM suspend/resume can wedge USB devices. If your controller disappears after sleep, treat “replug and reattach” as a real diagnostic step, not a superstition.

Short Story: A few months ago, I was building a small lab demo on a tight schedule—one of those “it has to work in 30 minutes” situations. My Kali VM kept throwing “No default controller available,” and I did what everyone does: restarted the service, rebooted the guest, reinstalled packages. Nothing. Then I noticed the host OS had quietly adopted the dongle like a stray cat—pairing requests, background scans, the whole vibe.

I detached the device from the host, passed it cleanly to the VM, and the controller appeared instantly. The lesson was painfully simple: sometimes you’re not fixing Bluetooth. You’re negotiating device ownership.

If you’re on VMware specifically, it helps to understand the practical differences between VMware Player vs Workstation vs Fusion, because device handling quirks often track with “which VMware” you’re actually using. And if you’re mixing environments, a WSL2 + Kali + VMware hybrid setup can add another layer of “who owns the device?” confusion that’s worth recognizing early.

If you’re building a more permanent lab and want fewer surprises, consider moving heavy workflows to a dedicated host like a Proxmox pentest lab where hardware ownership is simpler and more consistent.

---

Common mistakes that make this error permanent

This is where I save you the most time. Most “Bluetooth fix” guides fail because they encourage maximum activity with minimum evidence. Here are the mistakes that turn a 10-minute diagnosis into an all-day saga.

Mistake #1: restart-looping services while the kernel sees no HCI

If btmgmt and hciconfig show nothing, restarting BlueZ is theater. Stop and fix enumeration or passthrough.

Mistake #2: installing random Bluetooth GUIs before reading logs

GUIs don’t create controllers. They only add layers. Use them after you’ve proven the adapter exists.

Mistake #3: debugging pairing before you have a controller

Pairing issues happen later. Your current job is to get one working controller showing up in the system.

Mistake #4: assuming “works on Windows” means “supported on Linux”

Windows can hide a lot with vendor drivers. Linux is honest. That’s a feature—especially in a lab environment.

Mistake #5: ignoring firmware errors in dmesg

Firmware errors are not “warnings.” They’re often the entire cause. Read them like a detective, not like background music.

---

Recovery playbook: smallest-change path to “Controller shows up”

This is the part you can follow like a recipe. The goal is to change one variable at a time, with clear stop points. That’s how you avoid breaking things while “fixing” them.

My own ritual: I keep a terminal tab called “proof” and I rerun the same three commands after every change. It’s boring. It’s also the reason I finish faster—especially if your shell is tuned for speed (for example, with a Zsh setup for pentesters that makes repeatable checks feel frictionless).

Stop Point A: controller appears in bluetoothctl show

bluetoothctl show

If you see controller details, you’re out of the “no controller” wilderness. Now you can move to power state, scanning, pairing.

Stop Point B: controller powers on in btmgmt

btmgmt info

If it’s present but not powered, you may need to power it on (or resolve blocks) before it becomes usable.

Stop Point C: scanning works and stays stable

Stability matters. A controller that appears for 30 seconds and then vanishes is telling you about power, autosuspend, or VM USB handling.

---

FAQ

What does “No default controller available” mean in bluetoothctl?

It means BlueZ can’t find a usable Bluetooth controller (an HCI device) to manage. Either the controller is blocked, missing, or present but not being managed correctly.

Why is bluetooth.service running but there’s still no controller?

bluetooth.service being “active” only means the daemon is running. It doesn’t guarantee your system has an enumerated controller. Verify HCI presence with btmgmt info or hciconfig -a.

What’s the fastest order of operations to fix this?

Do it in this order: rfkill (block state) → HCI proof (controller exists) → logs (firmware/USB clues) → module reload (btusb reset) → re-test in bluetoothctl.

My USB dongle shows up in lsusb. Why is there still no controller?

Enumeration in lsusb only proves the USB device is detected—not that the Bluetooth controller successfully initialized. Check logs for firmware failures or timeouts, and confirm an HCI appears in btmgmt / hciconfig.

Do I need a USB Bluetooth dongle for Kali in a VM?

Often, yes. Many VM setups can’t reliably pass through an internal Bluetooth controller. A dedicated USB dongle passed directly to the VM is usually the cleanest path.

What logs should I collect before asking for help?

Collect: rfkill list, btmgmt info (or hciconfig -a), and journalctl -u bluetooth -b --no-pager. Those three outputs typically reveal whether the issue is block state, enumeration, firmware, or service behavior.

---

Next step: run the controller-first checklist (copy/paste)

This is your “15-minute, no-drama” next step. Run it once, top to bottom, and stop when you hit the branch that matches your output.

I keep this exact block in a notes file because it saves me from myself—especially when I’m tired and tempted to do the loud, complicated thing instead of the correct, boring thing. (If you like this kind of repeatable “one routine, many fixes” approach, it pairs well with a fast enumeration routine for any VM—same philosophy, different subsystem.)

# 1) Block state
rfkill list

# 2) HCI proof
btmgmt info || true
hciconfig -a || true

# 3) Service + logs
systemctl status bluetooth --no-pager
journalctl -u bluetooth -b --no-pager | tail -n 120

# 4) Optional: safe reset
sudo systemctl stop bluetooth
sudo modprobe -r btusb
sudo modprobe btusb
sudo systemctl start bluetooth

# 5) Re-test
bluetoothctl show

If you want a clean “ask for help” post, include exactly those outputs plus one sentence: “Internal adapter or USB dongle?” That single detail changes the entire diagnosis path.

---

Conclusion: make the controller real first, then make it work

Let’s close the loop from the beginning: this error isn’t a mystery message. It’s BlueZ telling you, plainly, that it can’t see a controller to manage. When you treat it as a controller-detection problem—blocked vs missing vs ignored—you stop wasting time on fixes that can’t possibly help.

Give yourself 15 minutes today: run the controller-first checklist, pick the correct branch, and commit to a stop point. If the hardware isn’t real or stable, replacing a $10–$20 dongle can be the most “professional” move you make all week. Boring, reliable, done. And once your box is stable again, it’s a good moment to tighten the basics—especially if this is a machine you use outside the lab—like Kali SSH hardening so your “working system” doesn’t become a soft target.

Last reviewed: 2025-12-26