Capture accepted: from packet upload to a Preliminary Report and Final Report
- 01CaptureAccepted
- 02RCA engineInvestigating
- 03Preliminary ReportReady
- 04Final ReportReady
RCA engine · evidence pass
Comparing the success path with the resets
InvestigatingSuccessful baselineFRAME 29 · SUCCESSFUL CLIENT HELLOFRAME 31 · SERVER HELLO
Affected attemptFRAME 56 · SNI CLIENT HELLOFRAME 57 · IMMEDIATE RST/ACK
Candidate emergingReset occurs immediately after ClientHello12 matching attempts grouped for verification
Preliminary ReportVerification continues →
Root-cause direction readyImmediate reset after ClientHello
Immediate TCP resets after ClientHello are the strongest supported cause—not packet loss.
- Affected sequence
- Frames 56–57 · representative ClientHello → RST/ACK
- Repeated pattern
- Frames 56–92, 174–190 · 12 affected attempts
- Successful baseline
- Frames 29, 31, 97, 115 · successful TLS baselines
Frames 56–57 support the lead Packet loss rejected
Verification completeFinal Report
Verified conclusionClientHello-to-reset sequence verified across 12 attempts
The preliminary finding is verified across the capture. The reset origin remains open because the packets cannot identify the responsible device or policy.
- Verified
- ClientHello → immediate reset
- Ruled out
- Packet loss as primary cause
- Open question
- RST/ACK hop + matched rule
Actionable next stepCheck the service path to 198.51.100.80:443
Target flow192.0.2.24 → 198.51.100.80:443
Compare each matched rule and log event with successful baseline frames 29–31; attach the hop name, rule ID, and log event that aligns with the RST/ACK.
The capture is accepted, the root-cause engine compares successful and failed TLS sessions, a clearly labelled Preliminary Report identifies immediate resets after ClientHello, and a Final Report verifies that sequence across 12 attempts while recording the reset source as an explicit open question and recommending the evidence-linked next action: inspect firewall, load-balancer, TLS-inspection, and service logs for the sanitized endpoint aliases and exact frame windows, identify the reset-generating device and rule, and attach that log event to the report.