re: analyze CAP-014 (Group W repeat) — snaplen fixed, handle-mapping still open

Confirms the CAP-017 snaplen truncation is resolved (0/4663 frames truncated),
but the 0x0c0X/0x0f2X handle-to-UUID mapping remains unresolved for a newly
identified reason: this session reused an already-bonded phone with a cached
GATT client, so Android served the cluster from its cache instead of
re-declaring it on the wire, rather than the snaplen truncation CAP-017 hit.
Confirms ADR-008 was respected (Accessory Non-Owner Service was never
read/written, only listed) and corrects the stale instruction to drill into
it at its source in CAPTURE_BLUETOOTH_HCI_SNOOP.md/CAP-017-FINDINGS.md so it
doesn't resurface in a future session template. Cross-capture reproduction:
0x0f2a="Revision 6" (3rd session), 0x0f32=0x64/0x0f33 (2nd session), CTKD
bonding (2nd session). All PROTOCOL.md/CAPTURE_BLUETOOTH_HCI_SNOOP.md/
TESTPLAN_BLUETOOTH_HCI_SNOOP.md updates are marked PROPOSAL — pending
maintainer approval, per AGENTS.md §6.

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

Author: tedsluis

CAPTURE_BLUETOOTH_HCI_SNOOP.md

@@ -1046,10 +1046,10 @@ is how the 2026-08-18 `CAP-005`/`CAP-007`/`CAP-010` ID-reuse incident (see
 | `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` | 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). **PROPOSAL — pending maintainer approval:** 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-014` | 2026-08-27 | Pixel 7a | 17 (⚪ assumed, not re-confirmed on screen this session) | release_5.203 (confirmed on-screen 20:59:07) | nRF Connect for Mobile (Nordic Semiconductor); official Pixel Buds app also surfaced twice, 20:54:39 and 20:58:52–53, unintentionally | W (repeat — **PROPOSAL, pending maintainer approval:** neither of Group W's own candidate methods was actually used this session either, see deviation note below) | `GATT-001`, incidental `PAIR-001` | Intended: repeat the `CAP-017` nRF-Connect procedure with (1) a fixed/longer HCI snoop snaplen and (2) an on-screen drill-down into "Accessory Non-Owner Service"/"Unknown Service" — **(2)'s Accessory-Non-Owner half was correctly not executed, that instruction conflicted with `DECISIONS.md` ADR-008** (`CAP-014-FINDINGS.md` §2) | `captures/CAP-014-2026-08-27_20-53-37_20-59-17-Group_W/CAP-014-btsnoop_hci.log` | same file | analyzed — see `CAP-014-FINDINGS.md` in that folder; **PROPOSAL, pending maintainer approval:** (1) succeeded — snaplen confirmed fixed, 0 truncated frames out of 4,663 (§0); **but `GATT-001`'s handle↔UUID mapping is still 🔴 OPEN** — root cause now identified precisely (§4): this session reused the same, already-bonded Pixel 7a with a cached GATT client, so Android served the `0x0c0X`/`0x0f2X` cluster from its cached database instead of re-declaring it on the wire (only the GATT service itself, handles `0x0001`–`0x0009`, was genuinely re-discovered live). Neither Group W Option (a) `pm clear com.android.bluetooth` nor Option (b) (Pixel 9a) was actually tried — both remain the clearly-identified next step, now combined with a confirmed-working snaplen for the first time. Reproduces `0x0f2a`="Revision 6" (3rd session, byte-identical to `CAP-002`) and `0x0f32`=`0x64`/`0x0f33` CCCD (2nd session, byte-identical to `CAP-017`, narrowing that open question); bonding used Cross-Transport Key Derivation (2nd confirmed instance after `CAP-004`, consistent with `CAP-012`'s "BLE-tool-first" explanation) |
 | `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 |
-| `CAP-017` | 2026-08-16 | Pixel 7a | 17 | release_5.203 (⚪ assumed — not re-confirmed on-the-wire this session, DLCI 0x08 never opened) | nRF Connect for Mobile (Nordic Semiconductor), not the official app | W | `GATT-001` | Second same-day Group W attempt (distinct session from `CAP-010`'s 11:42 attempt), this time driving a brand-new third-party GATT client (nRF Connect) instead of the official app, to force a real cache-miss discovery walk | `captures/CAP-017-2026-08-16_18-30-12_18-37-12-Group_W/CAP-017-btsnoop_hci.log` | same file | analyzed — see `CAP-017-FINDINGS.md` in that folder; **`GATT-001`'s discovery goal achieved for the first time in this project (🟢 FACT)** via a third path not previously identified (fresh GATT client UID has no cache to hit) — 137 live `Read By Type`/`Read By Group Type`/`Find Information` frames on the wire (vs. zero in every prior attempt); full 15-service GATT profile recovered from video (incl. Google Fast Pair Service `0xFE2C` and two previously-undocumented 128-bit UUIDs); **but the wire log itself is severely ACL-truncated (~15B snaplen), so UUID bytes aren't recoverable from the log, and no characteristic-level drill-down happened on screen — confirmed by a dedicated full-video verification pass (§4b) that the handle↔UUID mapping cannot be closed from this capture's artifacts**; recapture needed with (1) fixed snaplen and (2) on-screen characteristic drill-down into "Accessory Non-Owner Service"/"Unknown Service" |
+| `CAP-017` | 2026-08-16 | Pixel 7a | 17 | release_5.203 (⚪ assumed — not re-confirmed on-the-wire this session, DLCI 0x08 never opened) | nRF Connect for Mobile (Nordic Semiconductor), not the official app | W | `GATT-001` | Second same-day Group W attempt (distinct session from `CAP-010`'s 11:42 attempt), this time driving a brand-new third-party GATT client (nRF Connect) instead of the official app, to force a real cache-miss discovery walk | `captures/CAP-017-2026-08-16_18-30-12_18-37-12-Group_W/CAP-017-btsnoop_hci.log` | same file | analyzed — see `CAP-017-FINDINGS.md` in that folder; **`GATT-001`'s discovery goal achieved for the first time in this project (🟢 FACT)** via a third path not previously identified (fresh GATT client UID has no cache to hit) — 137 live `Read By Type`/`Read By Group Type`/`Find Information` frames on the wire (vs. zero in every prior attempt); full 15-service GATT profile recovered from video (incl. Google Fast Pair Service `0xFE2C` and two previously-undocumented 128-bit UUIDs); **but the wire log itself is severely ACL-truncated (~15B snaplen), so UUID bytes aren't recoverable from the log, and no characteristic-level drill-down happened on screen — confirmed by a dedicated full-video verification pass (§4b) that the handle↔UUID mapping cannot be closed from this capture's artifacts**; recapture needed with (1) fixed snaplen and (2) on-screen characteristic drill-down into "Unknown Service" (`109b862f-…`) — **"Accessory Non-Owner Service" is out of scope for any drill-down/read, per `DECISIONS.md` ADR-008; do not include it in a future session's plan** (correction added post-`CAP-014`, which caught this exact instruction still standing here and had to decline it — see `CAP-014-FINDINGS.md` §2). `CAP-014`'s repeat (below) fixed the snaplen but did not achieve a genuine cache-miss discovery, so the mapping is still open — see that row |
 | `CAP-018` | *planned* | either phone | TBD | TBD | TBD | Y | `GATT-002` | BLE-only connection isolation for the `0x0044` notification burst (`CAP-016-FINDINGS.md` §11) — enable Bluetooth and let the BLE link to the already-paired Buds form without touching the buds/case at all, to isolate whether the burst is triggered by BLE link establishment alone, independent of any bud/case action | — | — | planned |
 | `CAP-019` | 2026-08-21 | Pixel 7a | 17 (⚪ assumed) | release_5.203 (⚪ assumed) | 1.0.955078536 (assumed same as prior sessions) | C | `CONV-001`, `MULTI-001` | Conversation Detection and Multipoint on/off toggles | `captures/CAP-019-2026-08-21_07-35-50_07-39-30-Group_C/CAP-019-btsnoop_hci.log` | same file | analyzed — see `CAP-019-FINDINGS.md` in that folder; both toggles isolate to a single DLCI 0x02 `Sent` frame each (🟡 HYPOTHESIS, `field5{field4{field22=1}}`/`field5{field4{field11=1}}`); Multipoint additionally triggers a DLCI 0x04 Group `0x07` (SASS) burst including an ASCII `"in-use"` string — first content-level correlation of SASS traffic to a specific action |
 | `CAP-020` | 2026-08-21 | Pixel 7a | 17 (⚪ assumed) | release_5.203 (⚪ assumed) | 1.0.955078536 (assumed) | F | `TOUCH-001`, `HEAD-001` | Touch controls and Head gestures top-level on/off toggles; leaves Head gestures ON for `CAP-028` (Group O) | `captures/CAP-020-2026-08-21_07-46-14_07-47-49-Group_F/CAP-020-btsnoop_hci.log` | same file | analyzed — see `CAP-020-FINDINGS.md` in that folder; both toggles isolate to a single DLCI 0x02 `Sent` frame each (🟡 HYPOTHESIS, `field5{field4{field4=1}}`/`field5{field4{field29=2}}`) — first identification of the general-purpose `field5{field4{...}}` settings-write envelope, reused by every other capture in this batch |