# F5 Ethernet trailer decoder

> Paste the F5 Ethernet trailer that a BIG-IP appends to packets captured with the tcpdump noise flags, and get each field explained: direction, slot and TMM, the virtual server, flow and peer identifiers, and the device's own RST cause. It detects a TLS provider section and deliberately decodes none of it, because from v15 that section carries session secrets. Local and offline.

- Tool: https://ronutz.com/en/tools/f5-eth-trailer-decoder
- Family: Networking

---

## 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.

## Standards and references

- [F5 - Configure Wireshark to read F5 Ethernet Trailers (K14812111)](https://my.f5.com/manage/s/article/K14812111)
- [F5 DevCentral - Getting started with the F5 Wireshark plugin](https://community.f5.com/kb/technicalarticles/getting-started-with-the-f5-wireshark-plugin-on-windows/285686)
- [Wireshark - packet-f5ethtrailer dissector source](https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-f5ethtrailer.c)

## Related reading

- [What the BIG-IP writes into your capture](https://ronutz.com/en/learn/f5-ethernet-trailer.md): The F5 Ethernet trailer carries what TMM knew about each packet — slot, TMM, virtual server, flow IDs and the reset cause. From v15 it can also carry TLS session secrets, which changes what a pcap is.