What it does
Paste the F5 Ethernet Trailer section as Wireshark displays it, or the raw trailer bytes as hex, and the tool explains each field: direction, slot and TMM, the virtual server, the flow and peer identifiers, and the device's own RST cause. Local and offline; it parses the text you paste and contacts nothing.
Why the trailer is worth reading
Run tcpdump on a BIG-IP with the noise flags — :n low, :nn medium, :nnn high, with -s0 — and each frame carries the device's own account of that packet. The RST cause is the field that earns the exercise: a capture without it shows a connection died; with it, the device tells you it killed the connection and why.
What it warns you about
Flow IDs are unique only within a slot and TMM combination, and they are reused. The same ID can appear on unrelated packets earlier or later in one capture. The tool says so on every decode, because a flow ID trusted as globally unique produces a confident wrong conclusion.
It also points at f5ethtrailer.anyflowid, which matches the ID as either flow or peer and so returns both sides of the connection — filtering on flowid alone returns half of what you wanted.
*** The section it refuses to decode ***
From BIG-IP v15 the trailer can carry a TLS provider section containing session secrets. Wireshark will turn them into keylog entries and decrypt the capture.
This tool detects that section, tells you it is there, and decodes none of it. A golden vector asserts that no secret ever appears anywhere in the output.
The reason is the thing worth knowing: a capture taken at high noise on a v15+ device can contain the keys to its own TLS sessions. F5 documents that the trailer never leaves the device on the wire — true, and about the wire. The file is a different question, and sending it to a ticket or a colleague sends the keys with it.
What it will not do
It does not read pcap files, and it cannot see your capture. Where an RST cause is not in its table it says so rather than inventing an explanation for it.