Releases: Proxy-IT/pcaptriage
Release list
v0.2.2-alpha
If you downloaded v0.2.1-alpha, this is the one you wanted. That tag was
cut before the branding work landed, so its binary is the unbranded build.
The product has a name
It is called PCAP Triage. The binary, the repository and the module path
stay pcaptriage — only the strings a person reads changed: the window title,
the Help menu, the home screen, the About page, and the Windows file
properties.
The exported report's tool.name field deliberately still says pcaptriage.
It identifies which binary produced the file rather than naming the product,
so anything you have built against the JSON output is unaffected.
The placeholder icon is gone
The app shipped with the stock Wails logo. That glyph is what Windows showed
in Task Manager, on the taskbar, and on the SmartScreen prompt — the moment a
first-time user decides whether to trust an unsigned download from a stranger.
It is now the product mark, drawn separately at each size rather than
resampled: line art above 48px, a solid silhouette between 25 and 47, and
hand-placed pixels at 16 and 20. A scaled-down line drawing at 16px is an
unreadable grey smudge, which is the problem this replaced.
The mark also appears in the app bar and at the head of every exported report.
The report is the artifact that gets attached to tickets and emailed to
vendors, so it is the one that most needed to look like it came from
somewhere.
The report no longer says two things that were false
Its masthead carried a hardcoded "Partial build." directly above a sentence
announcing a complete rule set, and its capture-completeness note said the
capture-quality assessment "is R15, which is not implemented in this build"
while listing conditions that check already detects. Both stopped being true
when the fifteenth rule landed and stayed in place for two releases.
The report now states only what is derived from the rule registry, so neither
claim can contradict the build again. For a tool whose whole argument is that
it does not overclaim, false copy in the artifact that leaves the building was
the worst place for it.
Also
The repository now runs its test suite in CI on every push. It had never run
anywhere but a working tree that already had the files, which is how the
golden files sat committed with the wrong line endings through two releases —
every one of those tests would have failed on a fresh clone, and nothing ever
tried one.
No rule, threshold, detection logic or output schema changed in this
release. The JSON output is byte-identical to v0.2.1-alpha's for the same
capture.
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.
Still an alpha. The thresholds deciding what counts as unusual are 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.
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.
v0.2.0-alpha — the complete v1 rule set
All fifteen v1 rules are implemented. This is the first build where the rule
set is complete.
What's new since v0.1.0-alpha
Four checks, completing the set:
- R10 rtt-outlier — one host far slower to reach than every other host in
the capture. Reports whether the latency was steady or variable, since that
separates distance from congestion. - R11 dns-failure — name lookups that went unanswered, came back as errors,
or ran slow. A lookup happens before the connection it enables, so a slow one
delays everything behind it and is very often blamed on the application. - R12 tls-handshake-failure — encrypted connections that failed to
negotiate, took an unusually long time, or presented a certificate close to
expiry. - R13 pmtu-blackhole — large packets repeatedly failing while small ones on
the same connection succeed. The signature of a size limit on the path that
nothing is reporting back to the sender.
R11 and R12 are the first checks that read above TCP. Two consequences:
- Encrypted traffic is reported as unreadable, not as clean. DNS over TLS
and TLS 1.3 both hide what these checks would otherwise read, and both produce
an explicit "not assessed" note. An absence of certificate findings is not a
statement that the certificates are valid. - Neither check reads names. R11 reports how many lookups failed, never
which ones. R12 reads a certificate expiry date and no subject, issuer or
server name.
Also in this release:
- The report no longer says "Partial build". It names the fifteen checks and
states that anything outside them was not examined. - A capture containing nothing to examine is no longer presented as well
covered. - Findings can be filtered by clicking the hosts and ports they name, or by
typing one. Informational findings fold into a single row so a long report
stays readable. - Guide pages for every check, in plain language, reachable from any finding.
What's not in it
- Windows only. It should build for macOS and Linux; neither has been
produced or tested. - No export action in the app. The development CLI writes HTML and JSON
reports; the app does not yet. - ICMP is not decoded. R13 detects path-MTU blackholes from the TCP
signature alone and says it could not check for the ICMP half. - Thresholds are uncalibrated. They are starting points measured against
synthetic captures, not real ones.
Installing
Download pcaptriage-gui.exe below. There is no installer — it is a single
file. Put it wherever you like and run it.
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. Click More info, then Run anyway.
SHA256 6AAEF2CB797B46D2481784F63E7B946214A9A9DF50297981275DC68D7EC32E3B
Feedback
This is an alpha. The most useful thing you can report is whether the ranking
puts the right thing first on a capture of your own — that is the one question
synthetic fixtures cannot answer.
v0.1.0-alpha
First test build. Private, unsigned, not for distribution outside this repo's collaborators.
Built (11 of 15 rules)
- R01
zero-window-stall - R02
syn-unanswered - R03
syn-rejected - R04
server-response-outlier - R05
rto-retransmission - R06
fast-retransmission - R07
out-of-order-not-loss - R08
asymmetric-loss - R09
reset-mid-transfer - R14
connection-churn - R15
capture-quality(meta-rule: gates degradation flags for R04/R08/R10/R13/R14, reports capture-host drops)
Also in this build: the in-app guide (per-rule explanations, reached from a finding or from the top nav), dark mode (light/dark/system, set on the About screen), and self-contained HTML report export.
Not yet built (4 rules)
- R10
rtt-outlier - R11
dns-failure - R12
tls-handshake-failure - R13
pmtu-blackhole
An empty findings list does not mean a clean capture — it means these 11 checks found nothing. The app states this on the home screen and in every report.
Known issue
The binary is unsigned. Windows SmartScreen will show an "unrecognized app" warning on first run.