agent: fix NoInputNoOutput agents rejecting all pairing requests

[abezukor]

Problem

It is currently impossible to register a working NoInputNoOutput agent, because the capability string passed to RegisterAgent is derived automatically from which handler fields are set:

• All handlers None → capability is NoInputNoOutput, but BlueZ still calls RequestAuthorization for incoming just-works pairing (and AuthorizeService for service connections). Since the handler is None, bluer replies with org.bluez.Error.Rejected — so every pairing attempt fails.
• Setting request_authorization to accept → the derivation flips the capability to DisplayYesNo, so MITM-capable centrals (iOS in particular sets the MITM flag) negotiate numeric comparison instead of just-works. The phone then shows a "confirm this code" dialog for a code that a headless device cannot display anywhere.

This also contradicts the existing Agent documentation, which states:

Setting all handlers to [None] (the default) will result in a NoInputNoOutput handler that accepts all requests.

The all-None agent rejected all requests instead, so the documented behavior never worked.

Use case

A headless device (no display, no input) exposing a GATT service with encrypt-read/encrypt-write characteristics. Phones must be able to pair via just-works with a single consent tap and no passkey dialog. This requires advertising NoInputNoOutput and accepting RequestAuthorization/AuthorizeService.

Fix

1. Exclude request_authorization and authorize_service from the capability derivation. Per the BlueZ agent API, RequestAuthorization is called "to request the user to authorize an incoming pairing attempt which would in other circumstances trigger the just-works model" — it is a local authorization policy decision, invoked regardless of the published capability, not an input/output capability. The same applies to AuthorizeService. Only request_confirmation now implies yes/no capability. With this change, an agent with only authorization handlers correctly advertises NoInputNoOutput.

2. Make the all-None default match the documented behavior. When no handlers are set, default RequestAuthorization and AuthorizeService handlers that accept all requests are installed at registration, so the default Agent is the documented "NoInputNoOutput handler that accepts all requests". Code-input requests (RequestPinCode, RequestPasskey, etc.) still reject — BlueZ does not send them to a NoInputNoOutput agent.

Behavior changes

• An agent with only request_authorization/authorize_service set now publishes NoInputNoOutput instead of DisplayYesNo. Such configurations were effectively broken before, since they had no request_confirmation to satisfy numeric comparison.
• An all-None agent now accepts incoming just-works pairing instead of rejecting it, matching the existing documentation.

cargo build and cargo clippy --all-features pass with no new warnings.

🤖 Generated with Claude Code - I (a Human) did manually verify the issue and audit the code.

[frankier]

I just encountered this too. As far as I understand the fix looks reasonable. Anything I can do to help get this merged?

Below is a summary from Opus:

I hit this without knowing the PR existed and arrived at the same two conclusions, so here is the wire-level evidence in case it is useful.

Setup. bluer 0.17.4, BlueZ 5.87 on both ends, Fedora 44 (kernels 7.1.3 / 7.1.5). The peripheral registered exactly the agent the docs describe:

Agent { request_default: true, ..Default::default() }

The intent was the documented one: NoInputNoOutput, just-works, nothing to answer on a headless box. Every LE pairing attempt failed, with the host reporting only org.bluez.Error.AuthenticationFailed.

btmon on the peripheral:

SMP: Pairing Request (0x01) len 6
IO capability: KeyboardDisplay (0x04)
Authentication requirement: Bonding, MITM, SC, No Keypresses, CT2 (0x2d)
< SMP: Pairing Response (0x02) len 6
IO capability: NoInputNoOutput (0x03)
... Pairing Public Key / Pairing Confirm / Pairing Random ...
@ MGMT Event: User Confirmation Request (0x000f) plen 12
Confirm hint: 0x01
@ MGMT Command: User Confirmation Negative Reply (0x001d) plen 7
< SMP: Pairing Failed (0x05) len 1
Reason: Numeric comparison failed (0x0c)

The capability negotiation is correct — NoInputNoOutput selects just-works, and the kernel says so with Confirm hint: 0x01. What goes wrong is downstream: bluetoothd turns that into RequestAuthorization, Agent::call finds the handler unset and answers ReqError::Rejected, and that becomes a User Confirmation Negative Reply.

So the peripheral rejects its own pairing, and the failure surfaces as Numeric comparison failed (0x0c) on a link where no numeric comparison was ever meant to happen. That reason code sends you looking at association models, the host, or the controller — the one place it does not point is a missing callback in your own agent.

Worth stressing as a footgun rather than only a doc bug: an all-None agent is the natural thing to write for a headless just-works device, it is what the docs recommend, and it is the one configuration that cannot pair at all.