SSP, Secure Connections, and the Murata firmware swap

The chip from essay 9 talks HCI. The wakeup plumbing from essay 10 keeps it talking under load. Neither buys us pairing. To pair with a 2026-vintage Bluetooth speaker — anything that requires Secure Simple Pairing (BT 2.1+) and Secure Connections (BT 4.1+) — three things have to happen together:

1. The kernel HCI stack handles SSP events. FreeBSD’s ng_hci only knew about the legacy pre-2.1 events. SSP introduces opcodes 0x32–0x35 (IO_Capability_Request, IO_Capability_Response, User_Confirmation_Request, User_Passkey_Request, Remote_OOB_Data_Request) plus 0x36 (Simple_Pairing_Complete) that have to be dispatched up to userland.
2. Userland answers those events. hcsecd — the BSD security daemon — knew how to handle PIN code requests but had no concept of SSP. We added a Just Works mode.
3. The chip negotiates Secure Connections cleanly. Encryption mode 0x02 (AES-CCM) versus 0x01 (legacy E0) is the gate that modern profiles refuse to cross. The chip’s firmware build determines whether SC is even available.

The first two were patches. The third was the surprise: the bug was inside the binary blob, not our code.

ng_hci: making SSP events visible

ng_hci_evnt.c had a switch in its event-dispatch path that listed events the stack would forward to upper hooks (hcsecd listens via the raw HCI socket). The list included IO_CAPABILITY_REQUEST and SIMPLE_PAIRING_COMPLETE but nothing in between. The result: pairing peers would send IO_Capability_Response, User_Confirmation_Request, etc., the chip would hand the events to ng_hci, and ng_hci would just NG_FREE_M(event) without notifying anyone. Pairing stalled at the user-confirmation step forever.

The fix was small but had to land in the right order:

That second hunk — adding NG_HCI_CON_NOTIFY_ACL / NG_HCI_CON_NOTIFY_SCO flags to raw-HCI-initiated connection completions — is the seam that lets userland-driven create_connection (via hccontrol or our bt_attach) get its connection handle propagated to L2CAP. Without it, the kernel knows the ACL exists but never tells L2CAP, and any bt_a2dp.sh script that uses hccontrol create_connection gets a dead handle. 242c4ef ng_hci: handle SSP events 0x32/0x33/0x34/0x35 is the SSP event dispatch; the connection-notify flag came in the same batch.

hcsecd: Just Works pairing in userland

hcsecd is the BSD bluetooth security daemon. It listens for HCI events on a raw socket, makes pairing decisions per the policy in /etc/bluetooth/hcsecd.conf, and writes HCI commands back to answer link-key and PIN requests. It had no SSP code. We added it ( 91261a8 hcsecd: add SSP (Just Works) pairing support , patches/usr.sbin/bluetooth/hcsecd/hcsecd.c.patch):

• Subscribe to the new events (bit_set(filter.event_mask, ...) for IO_CAPABILITY_REQUEST, USER_CONFIRMATION_REQUEST, SIMPLE_PAIRING_COMPLETE).
• On IO_Capability_Request, reply with IO_Capability_Request_Reply claiming NoInputNoOutput and general bonding — the “Just Works” association model.
• On User_Confirmation_Request, reply with User_Confirmation_Request_Reply (auto-accept). In Just Works mode there’s no numeric to actually confirm; both ends are claiming no I/O.
• On Simple_Pairing_Complete, log the status.

The IO capability bytes are from BT Vol 2 Part E §7.7.40. The relevant constants are commented in the patch:

#define HCSECD_IO_CAP_NO_IO        0x03    /* "Just Works" */
#define HCSECD_AUTH_GENERAL_BONDING 0x04   /* preferred */

This is the minimum viable pairing path — no UI, no numeric comparison, no MITM protection. Sufficient for a speaker on a phone you control. Insufficient for production, by design; an essay later in the arc covers what a real pairing UI would need.

ng_hci: stop alerting on spurious Command_Complete

The first time we got partway through a pair flow with the kernel-side SSP fix, the next failure was new. ng_hci_cmds.c would log ALERT and refuse to drain the command queue when the chip sent a Command_Complete for an opcode that wasn’t currently pending. That happens — Linux’s HCI core silently drops these — most often when the BCM firmware emits an unsolicited Reset Command_Complete during its internal SSP state-machine resets. Worse: the upstream ng_hci_cmds.c would also clear NG_HCI_UNIT_INITED when processing a Reset completion. After an unsolicited Reset in the middle of an SSP flow, the unit was no longer “INITED,” and the next Connection_Request from the peer hit lp_con_rsp: unit is not ready and the pair flow fell apart.

The patch does two things. First, it converts NG_HCI_ALERT to NG_HCI_INFO and returns EPROTO (instead of EINVAL) when a spurious or out-of-order Command_Complete arrives — so the kernel logs are quiet and the queue continues to drain. Second, it removes the unit->state &= ~NG_HCI_UNIT_INITED clear on Reset completions, with a comment explaining why. 22d91e3 bcm firmware + ng_hci: fix post-patchram init + preserve INITED .

ng_hci_ulpi.c got one related tweak: when paging a peer with no cached info, default page_scan_rep_mode to R1 instead of R0. Most BT 2.1+ peers run R1 page-scan windows; using R0 caused Page Timeout 0x04 because the page train and scan window never overlapped.

The firmware swap

With the kernel and userland both handling SSP, pairing got further. IO_Capability_Request arrived. hcsecd answered. User_Confirmation_Request arrived. hcsecd answered. Simple_Pairing_Complete arrived with status 0x00. Auth_Complete arrived with status 0x00. Then we asked for encryption — Set_Connection_Encryption with enable=1 — and Encryption_Change came back with enabled=0x01. Which is legacy E0, not AES-CCM. And bluez on the speaker side refused to bring up A2DP over a non-SC link.

We chased this for two days on the wrong ladder.

BCM4345C0 Murata Type-1MW UART 37.4 MHz BT 5.0-0187

The trace that proved it

After the firmware swap, with all four patches in place:

      1776832627.488071
       EVT
       len=10  04 36 07 00 eb 70 c5 64 d4 e0
    

      1776832627.488149
       EVT
       len=26  04 18 17 eb 70 c5 64 d4 e0 26 b8 d0 54 da 0d ab fb 14 15 f0 51 9e 81 98 70 07
    

      1776832627.488192
       EVT
       len=6   04 06 03 00 0c 00
    

      1776832628.412288
       CMD
       len=7   01 13 04 03 0c 00 01
    

      1776832628.745240
       EVT
       len=7   04 08 04 00 0c 00 02
    

Decoded:

• 04 36 07 00 eb 70 c5 64 d4 e0: Simple_Pairing_Complete (event 0x36), status 0x00, peer BD address e0:d4:64:c5:70:eb.
• 04 18 17 eb 70 c5 64 d4 e0 26 b8 d0 54 da 0d ab fb 14 15 f0 51 9e 81 98 70 07: Link_Key_Notification (event 0x18), 23-byte payload, peer BD addr, 16-byte link key, type 0x07 — and the 0x07 is the magic byte. Type 0x07 is Authenticated_Combination_Key_P256, the SC-derived link key. Anything 0x00–0x06 would be a legacy key.
• 04 06 03 00 0c 00: Auth_Complete, status 0x00, handle 0x000c.
• 01 13 04 03 0c 00 01: outbound Set_Connection_Encryption, handle 0x000c, enable=1.
• 04 08 04 00 0c 00 02: Encryption_Change, status 0x00, handle 0x000c, enabled=0x02 (AES-CCM).

That enabled=0x02 is the gate. First time we ever saw it. Everything downstream — ACL data, L2CAP signaling, AVDTP profile negotiation, A2DP — assumes the link is encrypted under a modern cipher, and bluez 5.86 on the receiving side specifically refuses to bring up A2DP if the link reports enabled=0x01. Two-byte field, one bit difference, weeks of work to flip it.

What also had to land

Three smaller fixes shipped in the same window and are part of why the trace above is reproducible:

• EIR (Extended Inquiry Response). Without EIR, bluez on a peer flags the device as LegacyPairing: yes and falls back to PIN pairing — which hcsecd rejects. The bringup script writes a 240-byte EIR with Flags + Local Name fields via HCI_Write_Extended_Inquiry_Response (0x0c52) before scan-enable.
• Write_Simple_Pairing_Mode=1. The chip defaults SSP-disabled after HCI_Reset. bcm_firmware_load.pl step 10 issues 0x0c56 with 01 to enable it. Skipping this caused peers to negotiate down to legacy PIN. 7366036 bcm_firmware_load.pl: keep Write_Simple_Pairing_Mode=1 made this the load-time default.
• An autoagent on the host you’re pairing TO. This isn’t FreeBSD-side — it’s solomon (the GNOME laptop in our test setup). gnome-shell registers a default DisplayYesNo agent that shadows any in-session agent NoInputNoOutput from bluetoothctl. Mid-pair, bluez asks RequestConfirmation via DBus, nobody answers, 30 seconds later Auth Failure 0x05. Fix: a stand-alone root DBus agent (overlay/solomon/bt-autoagent.py) registered with NoInputNoOutput that auto-accepts every method. 67f80aa A2DP debug: bluez auto-confirmation agent + loader env tweak . Strictly speaking this is the pairing partner’s bug, not ours, but documenting it because every bringup hits it.

The link is encrypted under AES-CCM, the peer trusts us, the kernel routes ACL data into L2CAP, and userland believes a pair happened. Now we need audio to actually traverse that link. That’s essay 12 — and the breakthrough commit, and the soundbite.