Skip to content

Phase D.6.3 — wide-filter pcap: H1b FALSIFIED, H2-reply survives

Status: verified — completed 2026-04-24

Single decisive capture with tcpdump -i lo0 "tcp and not port 49151" (wider than iter-8's tcp port 34719-only filter). Result: CDS makes exactly one TCP connection, to our backend on [::1]:34719. Zero SYNs to any of our 62 advertised Services ports. H1b (CDS back-connects to service port and gets ECONNREFUSED) is decisively falsified. H2-reply (we're missing a server-initiated follow-up frame beyond iter-01's #8/#9 replay corpus) is the surviving hypothesis. Full writeup: findings.md.

Next: D.6.4a — temporary SPIKE→stock tunneld swap + utun4 pcap on real iPhone flow, using Q2 methodology extended with longer capture window, to get authoritative bytes for the missing follow-up frame(s).

What D.6.3 proved

Exactly one SYN observed across the entire 120-second window:

src dst count
[::1]:49492 (CDS) [::1]:34719 (our backend) 1

All 42 captured packets belong to that one flow. CDS never attempted to reach any port in our Services dict.

What this rules out

  • Service-port binding requirement on our backend — no
  • "Silent ECONNREFUSED" path where CDS tries to reach a service, fails, and abandons — no, because CDS never tries
  • Identity-field cross-validation triggering a back-connect probe — no

What this leaves open

CDS expects more frames from us on the SAME HTTP/2 stream, not a separate service connection. The iter-01 replay corpus (10 frames, ending at #9 RST_STREAM(s1)) was captured from a one-shot pymobiledevice3 remote rsd-info round-trip. Real CDS pair-flow is different — iPhone emits more than that corpus covers.

Files

  • findings.md — full writeup, SYN-destination table, D.6.4 plan with three ranked options (a = passive utun4 reference, b = pair reference, c = code-only heartbeat sandbox).
  • verbose-session.log — 41 lines, one session, identical 40-line handshake baseline as iter-7 and iter-8.
  • iosmux-d9-wide.pcap — 18 KB. Pre-commit scan for UDID / devicectl UUID / hostname: 0 matches across all patterns. Safe to commit.

Next step requires user approval

D.6.4a needs a tunneld mode swap: SPIKE → stock → capture → SPIKE again. The iosmux-restore.sh flow already supports both modes; only the SPIKE reactivation after capture is a manual pkill + nohup env IOSMUX_SPIKE=1 ... step (same command used throughout the D.6.x arc). But since it touches the live tunneld that CDS is currently consulting, explicit go-ahead before execution.