Skip to content

Phase D.6.2 H1c — pair trigger falsified, trigger-type is not the variable

Status: verified — completed 2026-04-23

Tested devicectl manage pair (and fallback unpair+pair) against the UUID-patched Go backend. Four sessions captured, every one hit the same 40-line handshake baseline with zero post-handshake frames. devicectl error surface identical to iter-6 / D.6.0-B: com.apple.Mercury.error 1000 "connection was interrupted". H1c is falsified — the command we invoke on the client side is not the missing variable. CDS's post- handshake silence is structural. Full writeup: findings.md.

New top-ranked hypotheses for D.6.3: H1b (passive port instrumentation, widened pcap filter) and H2-reply (we're missing a server-side follow-up frame beyond the iter-01 replay corpus).

What D.6.2 ruled out

Three trigger classes now produce identical silent-hold behaviour:

trigger result
devicectl device info details (iter-7 / D.6.1-B) no post-handshake, 130 s silent hold
devicectl manage pair (this iter) no post-handshake, 9/16/119/3 s EOF cycle
devicectl manage unpair + pair (this iter, fallback) no post-handshake, 3 s EOF

Since the trigger surface is exhausted without finding the variable, the missing piece must be on our side (backend) — either we're not listening where CDS tries to connect, or we're not emitting a frame CDS expects after #8.

Files

  • findings.md — full per-session timeline, triple-iteration comparison table, implications for D.6.3.
  • verbose-session.log — 158 lines, 4 sessions, patched UUIDs visible per session.
  • iosmux-d8.pcap — 75 KB loopback capture (filter tcp port 34719). No UDID hits — safe to commit. Note: this filter missed any back-connect CDS may have tried to other ports — D.6.3 uses a wider filter.

Secondary observation worth remembering

devicectl operates on its own internal device UUID (list devices returns it), not on tunneld's advertised UDID. Passing the raw UDID to devicectl manage pair --device ... returns "specified device was not found". Use the devicectl- internal UUID for all manage/info/etc commands.

Next step

D.6.3 widens the pcap filter to reveal whether CDS back-connects to any of our advertised Services ports. That single pcap run separates H1b (CDS tries to connect, we're not listening) from H2-reply (CDS is waiting silently for us to emit another frame).