verify Linux BLE discovery and peripheral mode end-to-end on actual hardware

[Dancode-188]

Background

The Linux BLE implementation uses bluer for peripheral mode (GATT server + LE advertising) and btleplug for central mode (scanning). Two bugs in the discovery path were identified and fixed on this branch:

Bug 1: BlueZ scan filter was silently dropping the advertisement.
BlueZ's SetDiscoveryFilter checks device UUIDs against AD type 0x07 (the service UUID list). The previous code only populated AD type 0x21 (service data). BlueZ does not reliably extract service UUIDs from service data for filter matching, so the advertisement was dropped before any event fired. Fixed by adding service_uuids to the bluer::adv::Advertisement struct.

Bug 2: Initial discovery event was ignored.
btleplug on Linux fires CentralEvent::DeviceDiscovered when a device is first seen. CentralEvent::ServiceDataAdvertisement only arrives on subsequent property-change events. The previous discover() loop only handled ServiceDataAdvertisement, so the initial discovery was dropped silently. Fixed by querying peripheral.properties() on DeviceDiscovered and emitting the announcement immediately.

Both fixes are based on reading the btleplug and bluer source directly. The logic is correct. What we do not have is confirmation they work on actual hardware.

Acceptance criteria

• BLE peripheral advertising started appears in /tmp/pathweave.log on the Linux machine
• BLE scan started appears in /tmp/pathweave.log on the Linux machine
• BLE central event: DeviceDiscovered(...) appears in the log when the peer is nearby
• The peer is visible in nRF Connect advertising UUID 82dfc0ba-e2b5-4e65-ad11-c7238ca545c9
• The pw-chat TUI on both machines shows the peer connected with BLE as the active transport
• A message sent from one side is received on the other over BLE

How to test

Two machines: one running Linux (Ubuntu 22.04+ or Raspberry Pi OS Bookworm) and one running Windows or another Linux machine. Both running pw-chat.

On the Linux machine:

sudo env RUST_LOG=pathweave_transport_ble=debug ./target/release/pw-chat

Logs write to /tmp/pathweave.log when RUST_LOG is set, to avoid the TUI alternate screen issue.

What to check if it fails

• BLE peripheral advertising started missing: bluer failed to advertise. Check BlueZ is running (systemctl status bluetooth) and the adapter is powered (bluetoothctl show).
• BLE scan started missing: btleplug failed to start scanning. Same checks.
• DeviceDiscovered never appears: the advertisement is not reaching the scanner. Verify with nRF Connect that UUID 82dfc0ba-e2b5-4e65-ad11-c7238ca545c9 is visible.
• DeviceDiscovered fires but no peer in pw-chat: the properties query is failing or the service data is malformed. Share the full log here.

Out of scope

• Windows BLE (separate implementation, separate issue)
• macOS BLE (verify macOS BLE peripheral mode and discovery end-to-end on actual hardware #73)
• BLE relay or multi-hop scenarios