The (BLE) Mouse-trap

I received a Logitech MX Master 3S mouse (it’s quite cool) as a gift, and I was having a very hard time pairing it with my Ubuntu 22.04 laptop. It would just never show up in any Bluetooth discovery tools. After a lot of effort (mostly by Claude), I finally figured out the issue and a fix.

What follows is a write-up of the most-probable actual issue, including summaries of the steps that were taken in this (long) process. I’m posting this in the hopes that it helps someone else who might be having a similar issue. If I miss anything, do let me know!

Full disclosure: I did not write most of the following write-up myself.

TL;DR

Problem: Logitech MX Master 3S (Bluetooth LE only, no USB receiver) is completely invisible to bluetoothctl, blueman, and btmgmt find on Ubuntu 22.04 with an Intel AX201 adapter — despite the kernel’s HCI layer provably receiving the mouse’s advertisements.

Root cause: The kernel’s Bluetooth management layer buffers ADV_IND reports waiting for a SCAN_RSP that the Intel AX201 never successfully solicits from this mouse. Combined with controller-level duplicate filtering, the buffered report is never flushed to userspace. The mouse is silently dropped inside process_adv_report() in net/bluetooth/hci_event.c.

Fix (one command):

sudo btmgmt pair -t 2 <MAC Address>

Replace the MAC with your mouse’s address (find it with sudo btmon while the mouse is in pairing mode. You’ll find an HCI event with the name of your mouse mentioned there, so take the corresponding MAC address. I guess an easier way to do this if you don’t want to sift through btmon’s output is just redirect it to a temp file and wait for ~5 seconds then just search for “Logitech” or whatever in the file).

You can follow this up with trusting the device using bluetoothctl trust <MAC Address>.

Environment

  • OS: Ubuntu 22.04, kernel 6.8.0-124-generic (HWE)
  • Bluetooth chipset: Intel AX201 (8087:0026)
  • BlueZ: 5.64-0ubuntu1.4
  • Mouse: Logitech MX Master 3S, BLE only, Static Random address

Symptoms

  • Mouse in pairing mode (fast-blinking LED)
  • bluetoothctl devices — empty
  • bluetoothctl pair <MAC Address> — fails immediately (device unknown)
  • sudo btmgmt find — finds other nearby devices but never the mouse
  • GNOME Bluetooth settings and blueman — nothing

The Investigation

Step 1: Is the hardware receiving the mouse at all?

sudo btmon
# (put mouse in pairing mode)

Result: YES. btmon captured a complete, well-formed LE Extended Advertising Report from the mouse:

LE Extended Advertising Report (0x0d)
  Legacy PDU Type: ADV_IND (0x0013)
  Address type: Random (0x01)
  Address: <MAC Address> (Static)
  RSSI: -41 dBm
  Data length: 0x1f
  Flags: 0x05 (LE Limited Discoverable, BR/EDR Not Supported)
  Appearance: Mouse (0x03c2)
  Service UUIDs: HID (0x1812), Logitech (0xfd72)
  Name (short): MX Master
  Company: Microsoft (6)  ← Swift Pair data
    Data: 030080

The radio works. The controller sees the mouse. Something above HCI is eating it.

Step 2: Is it bluetoothd or the kernel mgmt layer?

btmgmt talks directly to the kernel’s Bluetooth management socket, bypassing bluetoothd and D-Bus entirely.

sudo btmgmt find

Result: Found other devices (including another LE Random device), but never the mouse. This rules out bluetoothd — the fault is in the kernel’s mgmt layer, between HCI event reception and the mgmt_device_found event.

Step 3: What kind of scan is being used?

Captured btmon during btmgmt find to see the scan parameters:

LE Set Extended Scan Parameters (0x08|0x0041)
  Entry 0: LE 1M
    Type: Active (0x01)          ← Active scan, good
    Interval: 22.500 msec
    Window: 11.250 msec

LE Set Extended Scan Enable (0x08|0x0042)
  Extended scan: Enabled (0x01)
  Filter duplicates: Enabled (0x01)  ← Important!

Active scan with duplicate filtering enabled. Active scanning means the controller should send SCAN_REQ to the mouse after receiving its ADV_IND, and the mouse should reply with SCAN_RSP.

Step 4: The smoking gun — no SCAN_RSP

Grepping the full btmon capture during discovery:

grep "SCAN_RSP" /tmp/btmon_full.txt
# (empty — zero results)

The mouse never sends a SCAN_RSP. Either the AX201 isn’t sending SCAN_REQ, or the RF exchange is failing.

And critically:

grep "Device Found" /tmp/btmon_full.txt
# Only shows an Apple device — never the mouse

The MGMT Device Found event is never emitted for the mouse.

Root Cause: Kernel Source Analysis

Traced through process_adv_report() in net/bluetooth/hci_event.c (kernel 6.8). The following is inferred from the source code, btmon evidence, and the fact that bypassing discovery fixed it — not confirmed via kernel tracing (ftrace/kprobe on process_adv_report). If you want to nail it down further, instrumenting that function is the next step.

Mouse ADV_IND received by controller
         ↓
hci_le_ext_adv_report_evt()           ← parses HCI event
         ↓
ext_evt_type_to_legacy(0x0013)        ← converts to LE_ADV_IND ✓
         ↓
process_adv_report(type=LE_ADV_IND, ext_adv=false)
         ↓
[line 6416] !ext_adv && !has_pending_adv_report(hdev)  → true
         ↓
[line 6420] type == LE_ADV_IND → true
         ↓
[line 6421] store_pending_adv_report()  ← BUFFERED, waiting for SCAN_RSP
         ↓
return;                                ← mgmt_device_found() NEVER CALLED

The pending buffer is designed to merge ADV_IND + SCAN_RSP into a single Device Found event. It gets flushed when:

  1. A SCAN_RSP from the same device arrives → never happens (AX201/mouse RF failure)
  2. An ADV from a different device arrives → didn’t happen during the active scan window (only one other device found, and it was discovered before the btmgmt scan started)
  3. Discovery ends → buffer is NOT flushed (no cleanup path)

Meanwhile, Filter duplicates: Enabled tells the controller to suppress subsequent ADV_IND from the same address. So the mouse gets exactly one shot, it gets buffered, and it’s lost forever.

After discovery ends, the kernel reverts to passive background scanning. The mouse’s ADV_IND arrives again (duplicate filter reset on scan restart), but now it hits line 6385:

if (hdev->le_scan_type == LE_SCAN_PASSIVE) {
    if (!hci_pend_le_action_lookup(&hdev->pend_le_reports, bdaddr, bdaddr_type) &&
        idr_is_empty(&hdev->adv_monitors_idr))
        return;  // ← SILENTLY DROPPED
}

Mouse isn’t in pend_le_reports (never been paired) → dropped again.

The Fix

Since the mouse IS advertising connectable ADV_IND and the radio CAN talk to it, we just need to bypass the broken discovery pipeline and go straight to pairing:

# Pair directly via the mgmt socket, specifying LE Random address type
sudo btmgmt pair -t 2 <MAC Address>

This initiates a direct LE connection to the mouse’s address without requiring it to appear in discovery results. The connection, key exchange, and bonding all succeed normally — the only thing broken was the discovery path.

Making it persist across reboots

# Add to auto-connect list:
#   -t 2        = address type: LE Random
#   <MAC>       = device address
#   2 (trailing) = action code: auto-connect (reconnect when advertisement seen)
sudo btmgmt add-device -t 2 <MAC Address> 2

After reboot, bluetoothd should load the pairing keys from /var/lib/bluetooth/<adapter>/<device>/info and the mouse should reconnect automatically. (I haven’t explicitly verified the reboot-and-reconnect cycle — if it doesn’t come back, re-run the btmgmt pair command and check that the info file exists with a valid LTK.)

What’s Actually Broken

This is a compound failure:

  1. Intel AX201 firmware: Not successfully completing the SCAN_REQ → SCAN_RSP exchange with the MX Master 3S during active scanning. Could be a timing issue, RF sensitivity, or a firmware bug with this specific device’s advertisement structure (which includes Microsoft Swift Pair manufacturer-specific data alongside standard HID/GAP fields in a full 31-byte legacy PDU).

  2. Kernel design fragility: process_adv_report() assumes SCAN_RSP will arrive for scannable devices during active scanning. When it doesn’t, the pending buffer becomes a black hole. There’s no timeout or fallback to flush buffered reports. Combined with controller-level duplicate filtering, a single missed SCAN_RSP makes a device permanently invisible for the duration of that discovery session.

Things That Didn’t Help

  • ClassicBondedOnly=false in /etc/bluetooth/input.conf
  • Clearing bluetoothctl discovery filters
  • Restarting bluetooth service
  • ControllerMode = dual in main.conf

Likely Affected Configurations

  • Intel AX200/AX201/AX210 Bluetooth adapters (extended advertising via legacy PDU path)
  • BLE-only HID devices (mice, keyboards) that pack full 31-byte AD payloads
  • Any device that includes Microsoft Swift Pair data alongside standard BLE AD structures
  • Kernel versions using the store_pending_adv_report buffering mechanism (present in 5.x through 6.8+)

Reporting Upstream

If this affects you, this is likely worth reporting to the kernel Bluetooth maintainers. The issue probably isn’t MX-Master-3S-specific — it’d affect any BLE HID device on Intel AX2xx that packs a full ~31-byte AD payload and doesn’t reliably answer SCAN_REQ. That’s a plausible pattern across Logitech mice/keyboards, and potentially other BLE peripherals with Microsoft Swift Pair data.

The kernel-side fix would be a timeout or fallback in process_adv_report() to flush the pending buffer when no SCAN_RSP arrives within a reasonable window, rather than holding it indefinitely.

What’s Next: Button/Gesture Configuration

Pairing and HID configuration are separate problems. Once the mouse is paired, if you want to configure gestures, button mappings, or DPI settings, see logiops — a userspace daemon for Logitech HID++ devices on Linux.

Debugged on Ubuntu 22.04, kernel 6.8.0-124-generic, BlueZ 5.64, July 2026.


Raghav Doshi

he/him

I was drawn into a rabbit hole of weird Bluetooth issues trying to connect a mouse to my laptop

Last updated:
2026-07-23