[TonybynMp4]

Summary

On a Pixel with AirDrop compatibility, the Quick Share send sheet drops the phone's WiFi when it's on 5 GHz, so the BLE receiver advertisement is the only way it can find us. On Linux with Experimental = true, BlueZ's LE Audio client mcp then asks the phone to pair, and the phone never lists us:

phone connects to read our advertisement (slot 0)
  mcp reads the phone's Media Player Name (0x2b93)
    phone: Insufficient Authentication
    BlueZ: SMP Security Request (Bonding, No MITM, SC)
  phone declines, drops the link before reading slot 0
  phone retries from a new address while the sheet is open

The advertisement monitor only registers when Experimental is on, so the app now uses that to show one dismissible note:

 BleListener::monitor (core_lib/src/hdl/ble.rs)
+  BLUEZ_EXPERIMENTAL.send_replace(registered)   # watch, read by bluez_experimental()
 spawn_receiver_tasks (src-tauri/src/main.rs)
+  emit("bluez_experimental", on) on each change
 <SideMenu>
+  <note "Phones may ask to pair">   # Learn more -> KNOWN_ISSUES.md D, Got it -> settings store

• get_bluez_experimental covers a window that opens after the event. Its invoke is in a try/catch, so a failure can't skip the rest of the mount.
• "Got it" is saved as bluez_experimental_note_dismissed in the settings store, so it holds across closing to the tray and restarts.
• KNOWN_ISSUES.md gains C (the WiFi drop, linking ble-receiver-discovery.md) and D (this, with -P mcp first, then pairing once, then Client = false).
• ble-nearby-alert.md no longer calls declining the request harmless, names the characteristic, corrects the Security Request to "no MITM", and lists pairing once as an option.

Limits: the note can't show with nearby alerts off, since the monitor only runs then. It also keeps showing after -P mcp is applied, because nothing on D-Bus says the plugin is off, so "Got it" is the way out.

Evidence

btmon on BlueZ 5.85 with a Pixel 11 Pro, unpaired, WiFi off:

• Before (mcp loaded): read of 0x2b93, Insufficient Authentication, Security Request on every retry. The phone showed a pairing prompt and never listed us.
  After (bluetoothd -P mcp): 0x2b93 shows up in discovery but nothing reads it. No prompt, and the phone listed us.

The app built from this branch, against the real bluetoothd:

Case	Result
Experimental on	note shows, "Learn more" opens KNOWN_ISSUES.md
"Got it", close to tray and reopen, full restart	stays hidden
Experimental off (RegisterMonitor ... doesn't exist, continuous scan)	no note
Experimental turned on while the app runs	no note until the next start

The last row comes from an existing bug: after a bluetoothd restart, the BLE listener logs waiting for Bluetooth to turn on and never resumes. That happens on master too and isn't changed here.

cargo fmt --check, cargo clippy --workspace --all-features --all-targets -D warnings, cargo test --workspace --all-features, pnpm lint, pnpm ts-check and pnpm vitest run pass on Linux.

Merge danger

Door: two-way. One new settings key, nothing migrated.

Blast radius: small. A note in the Linux side menu and docs. Windows only compiles the command, which returns false.

🤖 Generated with Claude Code

[asulwer]

Thanks for tracking this down. The WiFi drop itself is why the BLE receiver exists (docs/ble-receiver-discovery.md), so please link that doc from section C rather than describing it as new. The part I didn't have is that it's a same-band check and a phone on 2.4 or 6 GHz keeps its WiFi, which is worth keeping in C.

Before going further with the code: was Experimental = true set in /etc/bluetooth/main.conf (or bluetoothd started with -E) when you tested? docs/ble-nearby-alert.md already covers this prompt. With Experimental on, BlueZ's mcp LE Audio client reads the phone's media control service, gets Insufficient Authentication and asks to pair, and starting bluetoothd with -P mcp stopped it when we tested. If you can, a sudo btmon capture of one attempt would show which read triggers the Security Request.

If it is mcp, section D should point to that doc and suggest -P mcp before Client = false, which costs every BLE mouse and keyboard. In that case I'd also rather have a much smaller check than the detector: the app already knows Experimental is on, because the advertisement monitor only registers with it, so it can show one dismissible note instead of tracking peers. If Experimental was off, then that doc is incomplete and the detector makes more sense. Either way, its line "Declining the request is harmless" is wrong given what you found, so please correct it.

If the detector stays: please drop the tray notification and keep just the side menu hint and the log warning, and wrap the get_ble_pairing_needed invoke in HomePage.vue in a try/catch so a failure there can't skip the rest of the mount.

For a change this size, please open an issue first next time so we can agree on the approach before you write it.

[TonybynMp4]

Experimental was on, and i verified, it is mcp.

So I've replaced the detector with the smaller check you described. The core publishes whether the advertisement monitor registered, and the side menu shows one dismissible note when it did. Since the monitor only runs with nearby alerts on, the note can't show when alerts are off. I think that's fine, but say if you'd rather check another way. The invoke is in a try/catch and the tray notification is gone.

Updated the note:

Docs:

• C now links ble-receiver-discovery.md and keeps the same-band detail.
• D points to ble-nearby-alert.md and lists -P mcp first, then pairing once, then Client = false.
• In ble-nearby-alert.md I replaced "Declining the request is harmless" with what actually happens, added pairing once to the options table, and corrected the Security Request to "no MITM", which is what the capture shows.

Noted on opening an issue first for big fixes next time!

[asulwer]

Thanks, this is what I was after. Checking only when the nearby alert runs is fine, since alerts are on by default. Merging.