re: analyze CAP-013 (Group A repeat) — clearing-action window still not captured, PAIR-004 secondary question resolved

CAP-013 was meant to capture HCI snoop logging before any prior association with
the Buds existed at all, to resolve CAP-001-FINDINGS.md §6's open question (did a
BLE link/link key already exist before the on-screen clearing action?). Verified
against both the video and the log rather than taken on the maintainer's advance
note: the actual gap is larger than described — the clearing action was a
phone-wide "Reset Bluetooth & Wi-Fi", not a single-device "Forget", and the log's
first frame starts 2m21s after it, also missing the case-open/pair-button/device-
selection sequence. The primary question stays 🔴 OPEN QUESTION, not narrowed.

What the captured window does answer: TESTPLAN's PAIR-004 secondary question — the
subsequent re-pairing shows a complete fresh classic SSP handshake (Delete Stored
Link Key → Negative Link Key Reply → IO Capability/User Confirmation/Simple
Pairing Complete → new Link Key Notification), not a reused key. Also confirmed
this session's log is severely ACL-truncated like CAP-012 (~15-byte capture
length), and found two new single-sample observations flagged for follow-up: DLCI
0x02 opening ~61s after the other RFCOMM channels, and a second unattributed BLE
link to a random address.

Proposes (awaiting maintainer sign-off, not committed as settled): Capture Index/
TESTPLAN/PROTOCOL.md open-questions updates reflecting the above, and a follow-up
capture CAP-031 to actually start logging before the clearing action.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjo12itgeoZW8rPFPXUZvz

Author: tedsluis

CAPTURE_BLUETOOTH_HCI_SNOOP.md

@@ -600,12 +600,24 @@ same window.
 > point** (`CAP-012-FINDINGS.md` §1/§4). A further repeat with a working, non-truncated snoop log
 > would still be worthwhile for that reason alone.
 
-> **Note on Group A's repeatability, optional (added 2026-08-14):** `CAP-001-FINDINGS.md` §6 found
+> **Note on Group A's repeatability, optional (added 2026-08-14).** `CAP-001-FINDINGS.md` §6 found
 > a BLE link and a still-valid link key both existing *before* the on-screen "Forget" tap and
 > before the case was reopened — unresolved whether "Forget" fully clears prior association state.
 > A repeat of Group A that starts HCI snoop logging **before** any association with the device
 > exists at all (e.g. immediately after a phone restart, before ever opening the case or any Buds
-> app) would isolate this — optional, lower priority than Groups T/U/V/W/X above.
+> app) would isolate this.
+>
+> **Update (2026-08-26): `CAP-013` attempted this repeat — did not achieve it, primary question
+> still open.** Logging did not actually start before the clearing action (which itself was a
+> phone-wide "Reset Bluetooth & Wi-Fi," not a single-device "Forget") — the log's first frame lands
+> 2m21s after that action, and after the case-open/pair-button/device-list-tap sequence too
+> (`CAP-013-FINDINGS.md` §0). The primary question above remains 🔴 OPEN. `CAP-013` did resolve the
+> secondary `PAIR-004` question (fresh SSP, no key reuse, for whatever bonding state was active when
+> its own logging window began) — see `TESTPLAN_BLUETOOTH_HCI_SNOOP.md`'s `PAIR-004` row. **VOORSTEL
+> — wacht op goedkeuring maintainer:** a further repeat is still needed, this time with logging
+> verifiably started before the clearing action itself (e.g. enable HCI snoop logging immediately
+> after a phone restart, before touching Bluetooth settings at all) — proposed as `CAP-031` (next
+> free ID per `id_registry.csv`, not yet assigned/registered).
 
 #### Group Y — BLE-only connection isolation for the `0x0044` notification burst (occasional, added 2026-08-20)
 **Purpose:** `CAP-016-FINDINGS.md` §11 found a 73-frame `Handle Value Notification` burst on BLE
@@ -985,7 +997,7 @@ is how the 2026-08-18 `CAP-005`/`CAP-007`/`CAP-010` ID-reuse incident (see
 | `CAP-010` | 2026-08-16 | Pixel 7a | 17 | release_5.203 | official Pixel Buds Companion App (version not visible on screen) | W (attempted) | `PAIR-001` | Intended as Group W's stronger GATT cache-busting attempt; **actual on-screen procedure was a standard system-Settings forget-and-re-pair on the same Pixel 7a used throughout this project — neither `pm clear com.android.bluetooth` nor the Pixel 9a was used, so Group W's own method was not actually exercised (`CAP-010-FINDINGS.md` §1)** | `captures/CAP-010-2026-08-16_11-42-31_11-45-01-Group_W/CAP-010-btsnoop_hci.log` | same file | analyzed — see `CAP-010-FINDINGS.md` in that folder; **`GATT-001` still unresolved, 4th consecutive negative result** (`CAP-002`, `CAP-003`, `CAP-004`, `CAP-010`): zero `Read By Group Type`/`Find Information` traffic despite a genuinely fresh classic bond this time — explained by the procedure gap above, not new evidence against Group W's untried methods; independently reproduces the `0x0f2a`/`0x0c0X` handle cluster's stable numbering and FORM (now a 3rd–4th confirming session), the DLCI 0x08 private handshake incl. `release_5.203` (5th confirming session), and the classic fresh-pairing state machine (4th confirming session); new byte-level detail for `0x0c0c` (40B notify) and `0x0c13`/`0x0c14` (9/10/32B, doesn't fit the `0x0c04`/`0x0c05` AES-block pattern — 🟡 possibly a structurally distinct characteristic) |
 | `CAP-011` | 2026-08-21 | Pixel 7a | 17 (⚪ assumed) | release_5.203 (⚪ assumed) | official Pixel Buds Companion App (open for most of session) | Q (#18) | `BATT-002`, `BATT-003` | Passive BLE scan intended for case-closed/idle, to capture the Fast Pair Battery Notification advertisement independently of RFCOMM (`PROTOCOL.md` §4.3 Option A) | `captures/CAP-011-2026-08-21_09-45-17_09-55-16-Group_Q/CAP-011-btsnoop_hci.log` | same file | analyzed — see `CAP-011-FINDINGS.md` in that folder; **procedure deviation**: an active classic RFCOMM+GATT connection was present throughout (app left open on "Device details"), not the intended connection-free scan; `0xFE2C` Fast Pair Service BLE advertisements confirmed present (🟢 FACT, 634 frames, 5 rotating addresses) but the sampled payloads do **not** structurally match `PROTOCOL.md` §4.3 Option A's documented Battery Notification byte layout — recorded as inconclusive, not force-fit; a clean connection-free repeat is still needed. **Re-analyzed 2026-08-23** (maintainer spotted a 1% battery drop in the recording): pinpointed the exact change to 09:52:25.8 and found a DLCI 0x08 message (`Group 0x0e Code 0x01`, cross-confirmed by `Group 0x04 Code 0x03`) tracking the Left/Right values across 4 occurrences in the log — proposed as `PROTOCOL.md` §4.3 Option E, 🟡 HYPOTHESIS pending sign-off; see `CAP-011-FINDINGS.md` §7 |
 | `CAP-012` | 2026-08-26 | Pixel 7a | 17 (⚪ assumed, not visible on screen this capture) | release_5.203 (⚪ assumed — not re-confirmed on the wire this session, log severely ACL-truncated) | uninstalled (GMS disabled) | S (repeat) | `GFPS-001`, `PAIR-001`, `CASE-003`, bonus `PAIR-003` (first Pixel 7a occurrence) | Repeat of Group S following its original system-settings-only procedure exactly (no nRF Connect at any point, independently confirmed both on screen and on the wire — zero BLE connection to the Buds anywhere in the log), to isolate whether `CAP-004`'s Cross-Transport-Key-Derivation bonding result was an artifact of nRF Connect's early BLE connection (`CAP-004-FINDINGS.md` §8 item 4) | `captures/CAP-012-2026-08-26_15-30-19_15-32-28-Group_S/CAP-012-btsnooz_hci.log` (**severely ACL-truncated, ~15-byte captured length per data packet — `btsnooz`-fallback extraction rather than a raw untruncated log; see `CAP-012-FINDINGS.md` §1**) | same file | analyzed — see `CAP-012-FINDINGS.md` in that folder; **hypothesis confirmed (🟢 FACT): this session uses classic Secure Simple Pairing, not CTKD** — `CAP-004`'s CTKD result is isolated to nRF Connect's early BLE connection, not to the GMS-disabled/no-app condition itself (§2/§10 there); `GFPS-001`'s channel-topology result reproduces `CAP-004`'s (DLCI 0x04 never opens) but the payload-content sub-question is **inconclusive**, not resolved, due to this log's truncation (§1/§4); bonus finding: a manual disconnect/reconnect (`PAIR-003`) retriggers the full HFP AT-command handshake (§6), narrowing a `PROTOCOL.md` §6 open question |
-| `CAP-013` | *planned, optional* | Pixel 7a | TBD | TBD | TBD | A (repeat) | `PAIR-004` | HCI snoop logging started before any prior association with the device exists (e.g. immediately after a phone restart) — resolves whether "Forget" fully clears prior bonding/BLE-association state (`CAP-001-FINDINGS.md` §6) | — | — | planned |
+| `CAP-013` | 2026-08-26 | Pixel 7a | 17 (⚪ assumed, not screen-confirmed) | release_5.203 | official Pixel Buds Companion App (version not visible on screen) | A (repeat) | `PAIR-001`, `PAIR-004`, incidental `BATT-004`, `APP-001`, `APP-002` | Intended: HCI snoop logging started before any prior association with the device exists — resolves whether a clearing action fully clears prior bonding/BLE-association state (`CAP-001-FINDINGS.md` §6). **VOORSTEL — wacht op goedkeuring maintainer:** status/row text below proposed, not yet maintainer-approved. | `captures/CAP-013-2026-08-26_17-09-01_17-14-04-Group_A/CAP-013-btsnooz_hci.log` (**severely ACL-truncated, ~15-byte captured length per data packet — `btsnooz`-fallback extraction, same issue as `CAP-012`; see `CAP-013-FINDINGS.md` §1**) | same file | analyzed — **partial: pre-clearing-action window not captured** — see `CAP-013-FINDINGS.md`/`CAP-013-EVENT-NOTES.md` in that folder. Verified (not assumed) that the intended method wasn't actually followed: the on-screen clearing action was "Reset Bluetooth & Wi-Fi" (not a single-device "Forget"), and the log's first frame (17:11:45.8) starts **2m21s after** that action — also after Bluetooth re-enable, case-open, pair-button-press, and device-list-tap, none of which are logged. **Primary question (`CAP-001-FINDINGS.md` §6) remains 🔴 OPEN, not answered.** **Secondary question (`PAIR-004`) is answered: 🟢 CONFIRMED fresh classic SSP handshake** (full IO-Capability/User-Confirmation/new-Link-Key-Notification sequence, frames 117–270) for the bonding state active when this capture's window began — no key-reuse path observed. Bonus: DLCI 0x02 (`libmaestro` candidate) opens ~61s after the other 4 channels this session, coinciding with an app-permission "Allow" tap — 🟡 single-sample, not promoted; a second BLE link to an unrelated random address appears mid-session, unattributed (🔴 OPEN). A genuine repeat (logging before the clearing action itself) is still needed — see proposed follow-up capture ID below. |
 | `CAP-014` | *planned* | Pixel 7a or Pixel 9a | TBD | TBD | TBD | W (repeat, done properly / handle-mapping follow-up) | `GATT-001` | `GATT-001`'s core discovery goal is now met (see `CAP-017`, 18:30) via a fresh-GATT-client-app path not originally in this row's scope — `pm clear com.android.bluetooth`/Pixel-9a remain untried alternates, now lower priority. **Primary remaining need:** repeat the nRF-Connect procedure with (1) a fixed/longer HCI snoop snaplen (the 18:30 log's ~15B-per-frame truncation made discovery-response UUIDs unrecoverable from the wire) and (2) an on-screen tap into "Accessory Non-Owner Service" and "Unknown Service" (`109b862f-…`) to read their characteristics/handles — this is the one step that would resolve the `0x0c0X`/`0x0f2X` handle↔UUID mapping this project has wanted since `CAP-002` (`CAP-017-FINDINGS.md` §4b/§5) | — | — | planned |
 | `CAP-015` | 2026-08-18 | Pixel 7a | 17 | release_5.203 | 1.0.955078536 | T | `EQP-002`, `EQS-004` | Completes/supersedes `CAP-005`'s Group T goal: five distinct EQ presets tapped in sequence, then all five EQ sliders each dragged to both extremes and back near-zero (3 passes), to resolve `CAP-005`'s open field-to-band mapping question | `captures/CAP-015-2026-08-18_06-11-06_06-17-40-Group_T/CAP-015-btsnoop_hci.log` | same file | analyzed — see `CAP-015-FINDINGS.md` in that folder; **field-to-band mapping promoted to 🟢 FACT** (field 1↔Low bass, 2↔Bass, 3↔Mid, 4↔Treble, 5↔Upper treble, wire order reversed from on-screen order) — matches `CAP-005`'s single-band inference exactly; also established the ±6.0 band-gain clamp (🟢 FACT, units unconfirmed) and a confirmed preset-quintet reference table |
 | `CAP-016` | 2026-08-18 | Pixel 7a | 17 (build `CP2A.260705.006`, confirmed on-screen) | release_5.203 | n/a (Android system Bluetooth "Device details" page, not the companion app) | U | `CASE-004`, `CASE-005`, `CASE-006`, `OBS-003` | Re-run of Group U (distinct session from `CAP-007`): Bluetooth-on, both buds removed from case one at a time, empty-case lid close/reopen, both buds re-docked, disconnect, lid close — general case/bud-removal correlation rather than Group U's own narrower liveness-bracket procedure (see `CAP-016-FINDINGS.md` scope note) | `captures/CAP-016-2026-08-18_06-31-31_06-33-58-Group_U/CAP-016-btsnoop_hci.log` | same file | analyzed — see `CAP-016-FINDINGS.md` in that folder; **clean single-attempt, Buds-initiated reconnect on first bud removal (🟢 FACT, contrast `CAP-001`'s 3-attempt phone-initiated connect)**; **ACL disconnects the instant both buds are re-docked, Buds-initiated (reason `0x13`), 🟢 FACT**; **case-lid open/close while buds are elsewhere produces zero wire signal, 🟢 FACT — 2nd independent capture confirming this (`CAP-007` §3.4)**; a full RFCOMM channel bounce (all 4 DLCIs) recurs with **no camera-visible trigger this time**, ruling out "bud removal is the sole cause" for that class of event (`CAP-007` §3.3's hypothesis); ANC-state Notify's "settable-toggles" byte (`0x00` vs `0xe8`) newly observed to change value, tracking the app's own "no ANC mode selectable" UI state — proposed refinement to `PROTOCOL.md`'s ANC Notify field table, not yet promoted; **`INEAR-002`/`INEAR-003`/`INEAR-004` still not exercised** — no earbud is shown inserted into or removed from an ear on camera in this session either |

PROTOCOL.md

@@ -1059,6 +1059,11 @@ Delete stored link key (if any) → Create Connection → Connect Complete
   part of the protocol's own timing. `CAP-003` also shows the BLE (LE) link
   established ~0.4s *before* the classic connection attempt, consistent with
   Fast Pair's BLE-first design (classic pairing triggered from the BLE side).
+- **`CAP-013`** (2026-08-26, official app, following a phone-wide "Reset Bluetooth & Wi-Fi"):
+  frames 117–270, 17:11:46.737–48.843. Same shape again, a ~1.2s IO-Capability-to-Complete gap. A
+  fifth independent confirming instance of this path — see `CAP-013-FINDINGS.md` §2/§7 for the
+  full frame table (this capture's own purpose was `PAIR-004`, not this path itself, which was
+  already 🟢 FACT before this session).
 
 **Reconnect (stored key exists) — `CAP-001`:**
 
@@ -1119,13 +1124,13 @@ and exactly when the first battery notification/app command arrives relative
 to the classic link completing (steps 3–6 in the diagram above). Only the
 classic BR/EDR link-establishment mechanics (steps 1–2) are promoted here.
 
-**Status**: 🟢 FACT for classic BR/EDR link establishment (§5.1, four
+**Status**: 🟢 FACT for classic BR/EDR link establishment (§5.1, five
 independent captures); ⚪ ASSUMPTION for the RFCOMM/Message-Stream/battery/
 command portions (steps 3–6); 🟢 FACT for step 5's specific behavioral outcome
 (battery notification on reconnect), per `TESTPLAN_BLUETOOTH_HCI_SNOOP.md` §3.
 **Evidence**: §5.1 above for the classic-link portion (`CAP-001` frames
 732–917, `CAP-002` frames 653–734, `CAP-003` frames 1621/1687–1756, `CAP-016`
-frames 1213–1217); steps 3–6
+frames 1213–1217, `CAP-013` frames 117–270); steps 3–6
 still need a full connection sequence captured end-to-end (see
 `CAPTURE_BLUETOOTH_HCI_SNOOP.md`).
 
@@ -1464,6 +1469,27 @@ leaving them buried in prose elsewhere.
       (`4f:25:00:85:9a:b1`, connected 06:31:40.983) actually belong to the same physical Buds unit
       as classic peer `04:00:6e:cf:6e:07`? Time-coincident only — not content-verified in that
       pass; a GATT-level read of that handle's advertised service data would settle it.
+      **Second occurrence, 2026-08-26 (`CAP-013-FINDINGS.md` §6):** a further second BLE link,
+      to yet another random/resolvable address (`43:8a:82:03:4b:f2`), forms shortly after classic
+      pairing/RFCOMM-channel-open in that session — same open question (not content-verified as the
+      Buds' own address), not yet the same address as `CAP-016`'s either, so this doesn't confirm a
+      stable secondary identity, only that the pattern (an unattributed second BLE link appearing
+      around connection time) recurs.
+- [ ] **Re-raised 2026-08-26, still unresolved from `CAP-001-FINDINGS.md` §6 (primary question
+      `CAP-013` was meant to answer, `TESTPLAN_BLUETOOTH_HCI_SNOOP.md`'s `PAIR-004`):** did a BLE
+      link and/or a still-valid classic link key already exist for this peer *before* the on-screen
+      clearing action (`CAP-001`'s "Forget" tap at 08:51:02–03, pre-dated by a BLE link at
+      08:50:36)? `CAP-013` (2026-08-26) attempted the planned repeat — start HCI snoop logging
+      before any association exists at all — but logging in that session did not actually begin
+      until 2m21s *after* its own clearing action ("Reset Bluetooth & Wi-Fi", not a single-device
+      "Forget") and after the entire subsequent case-open/pair-button/device-selection sequence
+      (`CAP-013-FINDINGS.md` §0). **Still 🔴 OPEN QUESTION, not narrowed by `CAP-013`** — a genuine
+      repeat, with logging verified to start before the clearing action itself, is still needed
+      (proposed as a new capture, next free ID `CAP-031` per `id_registry.csv`, not yet assigned).
+      What `CAP-013` *did* confirm: the classic-link re-pairing that followed its own clearing
+      action used a fresh SSP handshake, not a reused key (`CAP-013-FINDINGS.md` §2/§7) — another
+      instance of `PROTOCOL.md` §5.1's already-FACT "fresh pairing" path, not a new finding in
+      itself.
 
 ### Resolved