v0.2.1-alpha

Two fixes, both from real captures sent in by outside testers. Neither
condition was reachable with the synthetic fixtures the tool was built
against, which is the argument for sending in more of them.

Captures that declare no snap length now open

A classic pcap stores the snap length as a plain number, so "no truncation
limit" has to be written as zero. libpcap and Wireshark have always read that
as unlimited; pcaptriage read it as a zero-byte ceiling, decided every packet
was too big, and refused the file with capture length exceeds snap length.
Both captures sent in were written that way, by a NETSCOUT InfiniStream
appliance, and neither would open at all.

The file on disk is never touched. Where a file declares no limit, the report
now says so rather than repeating a substituted figure.

Captures with rewritten headers are now reported as such

The second capture opened, built 406 flows, and produced ranked findings —
several near-identical connection-timeout findings and a reset — from a file
in which a third of the frames carried a TCP header length below the legal
minimum, and the frames that did decode carried flag bytes distributed like
noise. Nothing in the report indicated this.

R15 (capture quality) now detects header length fields that cannot be
correct and states that the header bytes are not what left the sending host.
Findings are still shown, qualified: the frame numbers are real and can be
opened in Wireshark, but the conditions reported may be artifacts of the
corruption rather than events on the network. They are not withheld — an
empty list would tell a reader less than qualified findings under a caveat.

Only impossible values count. A clipped or header-only capture is short, not
wrong, and is not reported as damaged.

For what this is worth in practice: the test fixture for it is the clean
capture with one frame in three corrupted, so there is no packet loss in it
at all. tshark, reading sequence numbers out of those frames, reports 18
retransmissions and 2 reorderings that never happened.

Also

R15 now detects snaplen truncation — frames arriving shorter than they were
on the wire. This was specified and described in the in-app guide but had
never been built. The first capture tested turned out to be clipped on
223,600 of its 223,646 frames while declaring no snap length at all.

Install

Download pcaptriage-gui.exe below. There is no installer — it is a single
file. Windows only.

Windows will warn you the first time. The binary is not code-signed, so
SmartScreen shows "Windows protected your PC" with an unknown publisher.
That is expected: code-signing certificates cost money annually and this is a
free tool. Click More info, then Run anyway.

Alpha. The thresholds deciding what counts as unusual are still starting
points. Feedback on whether the ranking puts the right thing first remains
the most useful thing to send back — as does any capture it mishandles.