Re: [RFC PATCH BlueZ 0/4] Bearer.LE1: Add ReadRSSI

[Kevin Dewald <kevin@simpleble.org>]

Hi Luiz,

On Thu, Nov 12, 2026 at 8:07 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> That still a poll in my book, not bluetoothd directly but I bet
> application will start to just poll it on their own.

They will, and Get Connection Information was designed for that: the
kernel caches the values for a random 1 to 3 seconds "to avoid client
trying to guess when to poll again". Applications that need the value
poll today anyway, as root through mgmt [1] or with raw HCI sockets
that bypass bluetoothd and the cache. Blueman still reads it through
libbluetooth for its signal bars, which only works on BR/EDR [2].

> Well the reported values are vendor dependent, so I'm not sure how
> much it would help since you can't use a measurement of link
> degradation in a generic manner, it needs hardware details to go
> along. We need a clear motivation for why this would be useful apart
> from just covering what other OSes might have since they may use a
> vendor command, or in Apple's case, probably deal with an exclusive
> vendor which makes things a lot more simpler.

For LE the spec fixes the value: Read RSSI returns the absolute
received signal strength in dBm to +/-6 dB accuracy (Vol 4, Part E,
7.5.4), the same unit as the advertising RSSI in Device1.RSSI. BR/EDR
is the one relative to the golden range, which is why the method is
only on Bearer.LE1. Android's readRemoteRssi sends the standard Read
RSSI command, and BlueZ's own Android port implemented it with Get
Connection Information.

What the value gives that a threshold event can't:

- Choosing between links. A device in range of several gateways should
  stay connected to the one with the best link, and a hub with
  redundant sensors should read from the strongest. That needs numbers
  that can be compared, not a crossing per link.
- Diagnostics. Logging the RSSI next to throughput and packet loss is
  how support tells a weak link from a firmware bug, after the fact.
- Production test. Test stations connect to every unit and check its
  RSSI against a reference unit, to catch a bad antenna or enclosure.
- Trends. An application streaming data can see the RSSI falling and
  lower its rate before the link drops, instead of finding out from a
  threshold picked in advance.

> Which means every btmon trace will now grow just with RSSI reports, I
> mean I could live with an event generated if RSSI drops below a
> certain threshold, not a command and event, every 2 seconds.

Only while an application reads it. A threshold event needs the same
Read RSSI every 2 seconds underneath, as the RSSI Monitor RFC did in
2011, unless the controller monitors it itself: LE Path Loss
Monitoring, which also needs LE Power Control on the peripheral, or
the MSFT extension's LE connection RSSI monitor, which the kernel does
not use yet.

BlueZ already has both for advertising: Device1.RSSI for the value and
AdvertisementMonitor1 for thresholds. ReadRSSI is the value half for
connections, and I'm happy to add thresholds on top where the
controller can monitor the link itself.

[1] https://lore.kernel.org/linux-bluetooth/aa77c035-d2aa-f227-bfcd-358b5f063b21@labapart.com/
[2] https://github.com/blueman-project/blueman/pull/1642

--
Kevin