A sanitized, persisted PacketSafari Agent run showing useful preliminary direction, the background verification work, and the updated packet-grounded finding.
Some TLS sessions reach the application service while others fail immediately after ClientHello. Find the strongest supported cause and distinguish it from incidental alerts.
01 / How the report evolves · Fast + verification
The Agent delivers bounded direction first while PacketSafari Triage and the Core Engine continue wider evidence discovery and an independent verifier challenges the first answer.
Times are measured upload-to-milestone values from this controlled run, not a general runtime guarantee.
Active TCP resets immediately after TLS begins are the strongest supported cause—not packet loss.
Direction is supported by frames 26–62, but its scope and competing explanations have not yet been independently challenged.
The verifier tests the reset hypothesis, looks for counterexamples, expands the affected scope, and separates incidental alerts from discriminating evidence.
02 / Current result
Twelve TLS attempts are terminated by an immediate RST/ACK after ClientHello. The capture does not prove which device or policy generated the resets.
Twelve affected attempts show the same ClientHello-to-RST sequence, while four successful baselines proceed normally.
The packets do not identify the reset-generating component or the policy selecting the failed ClientHello profile.
03 / Packet sequence
The comparison rejects a capture-wide outage and keeps the failure mechanism separate from the still-unknown policy trigger.
The TLS session proceeds into application exchange. Frames 97 and 115 provide additional successful baselines.
The same sequence repeats across frames 56–92 and 174–190 in streams 2–9 and 13–16.
04 / Evidence ledger
The strongest failure and baseline anchors stay visible. Every additional claim remains one step away.
Frame 56 carries the SNI-bearing ClientHello; frame 57 is the immediate reverse-direction RST/ACK.
frame.number == 56 || frame.number == 57Successful attempts receive ServerHello and proceed, rejecting a capture-wide service or path outage.
frame.number == 29 || frame.number == 31 || frame.number == 97 || frame.number == 115Twelve attempts in streams 2–9 and 13–16 follow the same ClientHello-to-reset pattern.
tcp.stream in { 2 3 4 5 6 7 8 9 13 14 15 16 } && tls.handshake.type == 1Reset traffic uses TTL 64 and window 1024; normal server-direction traffic uses TTL 125 with sequential IP IDs. This supports—but does not prove—a different generating stack.
frame.number == 54 || frame.number == 5705 / Verification changes
The verifier must account for the first answer, not merely restate it.
The summary stays short. Open the decision ledger only when you need the claim-by-claim comparison.
The first report identified active TCP resets after TLS begins as the strongest supported cause.
Independent review confirmed the same ClientHello-to-RST/ACK sequence across all 12 affected attempts.
The preliminary report used streams 2 and 3 as representative failures.
Wider capture evidence established exactly 12 affected streams and four successful baselines.
Retransmission and SACK alerts appeared incidental rather than causal.
Recovery events also occur on successful sessions and before the failure cluster, rejecting packet loss as the primary explanation.
One successful TLS stream showed the service could complete a session.
Four successful baselines coexist with the failures, rebutting a capture-wide outage.
The first bounded report did not establish a distinct reset-stack fingerprint.
TTL 64, TCP window 1024, and non-sequential IP IDs support—but do not prove—a different stack or intermediary.
The packets did not identify the component or policy selecting the failed ClientHello profile.
Wider evidence still cannot attribute the reset to the endpoint, load balancer, firewall, or TLS-inspection component.
06 / Evidence boundary
07 / Operator handoff
The report ends with a testable next move—not a generic recommendation.
tcp.stream in { 2 3 4 5 6 7 8 9 13 14 15 16 } &&
tls.handshake.type == 1