In Wireshark, what does the Expert Information dialog show, how are its severity levels ranked, and how far should you trust it?
answer
- where the analyser points first
- entries raised by individual dissectors
- four rising levels plus comments
- severity is not the same as group
- starting point, not stopping point
basics
~20 sExpert Information lists anomalies that dissectors flagged, ranked Chat, Note, Warn, Error from lowest to highest (packet comments sit below Chat) and grouped by kind, such as Sequence or Malformed. It shows where to look; it never diagnoses.
solid answer
~40 sYou open it with **Analyze > Expert Info** or by clicking the expert level indicator in the status bar. Every entry has a severity, a group (`Sequence`, `Malformed`, `Protocol`, `Checksum`, ...), a summary and the protocol whose dissector raised it. Severities run **Chat** (normal workflow, such as a SYN), **Note** (notable: the TCP dissector files a retransmission or a duplicate ACK here), **Warn** (a zero window, an out-of-order segment, a segment the capture never saw) and **Error** (malformed packets); **Comment** carries packet comments. The same colours mark fields in the packet details, and an optional Expert Info Severity column shows each packet's worst level. I treat it as a starting point: coverage depends on the dissector, a Warn can be normal for one application, and an empty dialog proves nothing about health.
go deeper
Recall where the dialog lives (Analyze > Expert Info or the status-bar indicator) and the order Chat, Note, Warn, Error, and say plainly that it is a hint, not a diagnosis.
Explain severity versus group, why a retransmission is a Note while a zero window is a Warn, and how Limit to display filter and Show... let you read one conversation's Warn items quickly.
Show the judgement: which Warn items are normal for this application, why an empty dialog can coexist with a slow server, and how you confirm an item in the packets before reporting it.
Talk about what a team should standardise: a shared profile with the analysis preferences known, and a reporting habit that cites packets and counts rather than screenshots of coloured rows.
## What the dialog is Wireshark decodes every packet with **dissectors**, one per protocol. While a dissector decodes a field, it can attach an **expert information item** when it sees something unusual or worth noticing: a TCP segment that repeats data already seen, an HTTP 404, a malformed DNS record. The **Expert Information** dialog collects every such item in the capture in one place, so you do not have to scroll through a 400,000-packet list to find the interesting few. You open it from **Analyze > Expert Info**, or by clicking the expert level indicator in the main status bar. ## The four severities, plus comments Every item has exactly one **severity**. From lowest to highest: | Severity | Colour | Meaning | TCP examples (as the TCP dissector files them) | |---|---|---|---| | Chat | blue | usual workflow | a window update | | Note | cyan | notable, often normal | retransmission, fast retransmission, duplicate ACK, keep-alive | | Warn | yellow | unusual, probably worth a look | zero window, window full, out-of-order, previous segment not captured | | Error | red | serious, e.g. a malformed packet | (none in that list; any dissector that aborts on bad data raises a Malformed Error) | Below Chat there is also **Comment**, used for packet comments a person added to a pcapng file. It is the lowest level the code knows, and tshark's expert statistics accept it as a level too. Two things surprise newcomers here: - A **TCP retransmission is a Note**, not a Warn. One retransmission on a healthy path is ordinary; what matters is how many, on which conversation, and when. - Severity is chosen by whoever wrote that dissector. It reflects their judgement of how often the condition indicates a real problem, not a measurement of your network. ## Severity versus group Separately from severity, each item belongs to a **group** that says what kind of finding it is: `Sequence` (a suspicious sequence number, such as a retransmission), `Malformed` (the dissector gave up), `Protocol` (a field violates the specification), `Checksum`, `Reassemble`, `Response Code`, `Request Code`, `Security`, `Undecoded`, `Decryption`, `Deprecated`, `Assumption`, `Comment` and `Debug`. Group answers *what kind*, severity answers *how loud*. A `Sequence` item can be a Note (retransmission) or a Warn (out-of-order); a `Response Code` item can be a Note (HTTP 404) or a Warn. ## Working the dialog The dialog groups items by severity and lists them under their group. The controls that matter: 1. **Limit to display filter** shows only items in packets that match the current display filter, for example after you have narrowed the view to one conversation. 2. **Group by summary** groups by the summary text instead of by group. 3. **Search** narrows to items matching a string or regular expression, such as `dns`. 4. **Show...** hides whole severities: deselecting Chat and Note leaves the Warn and Error items that usually deserve attention first. 5. Right-clicking an item lets you apply or prepare a filter from it, which jumps the packet list to exactly those packets. Outside the dialog, the packet details pane paints the offending field in its severity colour and propagates that colour up to the protocol's top-level line, and you can add an optional **Expert Info Severity** column to the packet list from the Columns preferences to see each packet's worst level at a glance. ## How far to trust it The user guide is blunt: expert information is the **starting point for investigation, not the stopping point**. Three limits follow: - **Coverage is uneven.** TCP and IP dissectors raise detailed items; many other dissectors raise few or none. Silence about a protocol may only mean nobody wrote checks for it, or that the traffic was never decoded as that protocol at all. - **Presence is not a fault.** A zero window from a printer pausing a job is normal; a handful of retransmissions over hours is normal; a 404 on a health check may be expected. - **Absence is not health.** A slow application can produce an almost empty dialog when the delay is the server thinking before it answers, which no dissector flags. The TCP sequence-analysis items (retransmissions, duplicate ACKs, zero windows, gaps) also exist only while the TCP preference **Analyze TCP sequence numbers** is on. It is on by default; a profile or command line that turns it off removes every one of those entries from the dialog without making the connection any healthier. ## How to use it in practice Open Expert Info early, hide Chat and Note, and read the Warn and Error groups by count. Then ask of each: is this condition normal for this application, does its count or timing line up with the user's complaint, and which conversation does it belong to? Confirm the answer in the packets themselves before you put it in a report.
- Why does Wireshark file a TCP retransmission as a Note rather than a Warn?The TCP dissector registers retransmission, fast retransmission, spurious retransmission and duplicate ACK at Note, because a few of them occur on healthy paths. It files zero window, window full, out-of-order and the two not-captured conditions at Warn. The colour is the dissector author's judgement; the count, the conversation and the timing are what tell you whether the retransmissions matter.
- The Expert Information dialog shows nothing for a protocol you care about. What do you check before trusting that silence?First, that the traffic was decoded as that protocol at all: on a non-standard port it may show as bare TCP or `Data`, and then no checks run. Second, whether that dissector raises expert items in the first place; many raise few or none. Silence is only evidence once both are confirmed.
Expert Info is like a car dashboard's warning lights: a lit lamp tells you where to look first, an amber one is louder than a blue one, and a dark dashboard does not prove the engine is healthy.
saying these in an interview costs you the question
- An empty Expert Information dialog proves the network is healthy.
- Every Warn or Error entry is a real fault that must be fixed.
- A TCP retransmission always shows at Warn or Error severity.
- Severity and group are the same thing, so Sequence always means Warn.
- Every protocol dissector raises expert items with the same depth as TCP.