What does a [Malformed Packet] entry in Wireshark's packet list mean, and how do you work out what caused it?
answer
- a dissector gave up mid-parse
- the label names the protocol
- wrong dissector, no reassembly, real damage, bug
- truncation has a different label
- check the bytes against the spec
basics
~20 sA dissector tried to read past the data it was given and threw, so Wireshark stopped decoding that protocol. The cause can be the wrong dissector, an unreassembled message, genuinely broken bytes, or a dissector bug.
solid answer
~50 s`[Malformed Packet: X]` means the dissector for protocol X hit an exception, usually by reading beyond the end of the data it was handed, so the tree stops at that layer and Expert Info records an Error entry, *Malformed Packet (Exception occurred)*. The Wireshark user guide lists four causes: the **wrong dissector** was chosen (a protocol on a port it does not own), the message spans several segments and was **not reassembled**, the packet really **is malformed**, or the **dissector is buggy**. To tell them apart, check that the named protocol is what that port carries and fix it with Decode As if not, make sure reassembly is on, then read the bytes against the protocol specification. It is not the same as `[Packet size limited during capture]`, which means the capture's snapshot length cut the frame short.
go deeper
Recall that Malformed Packet means a dissector gave up on that protocol, and that the label names which protocol. Know the four causes the user guide lists.
Explain how the label differs from Packet size limited during capture and from unreassembled fragments, and walk through Decode As and reassembly checks before reading the bytes.
Separate analyser-side causes from real wire damage before reporting anything, and say which conclusions a malformed label can and cannot support in an incident write-up.
Set the evidential bar for the team: a malformed label is a lead, not a finding, and reports should record the dissector, version and settings that produced it.
## What the label means Every dissector reads its protocol's fields from a buffer of bytes. If it asks for bytes beyond the end of what the packet says it contains, Wireshark raises an exception, stops that dissector, and marks the packet. The packet list shows `[Malformed Packet]` in the Info column, the details pane shows `[Malformed Packet: X]` where X is the protocol whose dissector stopped, and Expert Info gets an **Error**-severity entry in the *Malformed* group reading *Malformed Packet (Exception occurred)*. The pseudo-protocol has the filter name `_ws.malformed`, so these packets can be found in bulk. Everything decoded before the failure is still valid; everything after it in that packet is missing. ## The four causes | Cause | What is wrong | Which side | First check | |---|---|---|---| | **Wrong dissector** | A protocol on a port registered to another one, or a heuristic guessed wrong | Analyser | Is X what this port really carries? Decode As the port, or `(none)` | | **Not reassembled** | One message spans several TCP segments and the dissector sees only part of it | Analyser settings | Are TCP reassembly and the protocol's own reassembly preference on? | | **Packet is malformed** | The bytes on the wire really break the specification | Sender or network | Compare the bytes with the specification | | **Dissector is buggy** | The dissector mishandles valid input | Analyser code | Try a newer Wireshark release; report it with a sample | The reassembly case is the easiest to recognise once you have seen it. A 6,000-byte application message sent over a path with a 1,460-byte maximum segment size arrives in five TCP segments. With reassembly off, the dissector reads a length field in the first segment that promises 6,000 bytes, follows it, and runs off the end of the 1,460 it was given. Every large message is then marked malformed while every small one decodes cleanly, a pattern no real sender fault produces. Only the third row says anything about the traffic. The other three are about how Wireshark decoded it, which is why a malformed label on its own is not evidence that a peer sent bad data. ## Labels that look similar but mean something else | Label | Meaning | Expert Info | |---|---|---| | `[Malformed Packet: X]` | Dissector X read past the packet's real length | Error, *Malformed* group | | `[Malformed Packet: X: length of contained item exceeds length of containing item]` | An inner length field claims more than the outer item holds | Error, *Malformed* group | | `[Packet size limited during capture: X truncated]` | The frame was cut by the capture's snapshot length; the bytes exist on the wire but were never recorded | None | | `[BoundError Unreassembled Packet: X]` | A fragment was dissected with reassembly off | Note: *Unreassembled fragment (change preferences to enable reassembly)* | | `[Dissector bug, protocol X: ...]` | The dissector hit an internal consistency check | Error, *Dissector bug* | The snapshot-length case is **capture-side**: the network delivered the whole frame, but the capture kept only the first part. The only remedy is to capture again with a larger or unlimited snapshot length. ## A triage order 1. Read which protocol the label names, and whether it fires on every packet of a conversation or only some. 2. **Every packet on one port**: suspect the wrong dissector. Look at the port and the Decode As dialog's *Default* column; map the port to the right protocol, or to `(none)` to see raw `Data`. 3. **Only large messages**: suspect reassembly. Check the TCP and protocol reassembly preferences before blaming the sender. 4. **Isolated packets on a correctly decoded stream**: open the bytes pane and compare the field the dissector failed on with the specification. A length field that disagrees with the data that follows is real damage or a non-conforming implementation. 5. **Still unexplained**: disable the protocol under Analyze > Enabled Protocols to see what the layer below shows, then test with a newer release. A dissector bug is worth reporting with a minimal sample capture. ## Why it matters in a security review Malformed traffic that really is malformed is interesting: fuzzing, a broken client, or deliberate attempts to make different parsers disagree. That is exactly why the cause must be established before anyone writes it up. A Decode As mistake or a reassembly setting can fill Expert Info with Error entries that say nothing about the sender, and a report built on them will be wrong in a way the evidence makes easy to expose.
- Why does a truncated frame not produce a Malformed Packet entry?Wireshark knows each frame's captured length and its original length. When a dissector runs past the captured bytes but stays inside the original length, the data existed on the wire and the snapshot length cut it, so Wireshark shows `[Packet size limited during capture]` and records no Expert Info event. Malformed is reserved for reading past the packet's real length.
- Every packet to one TCP port is marked malformed for the same protocol; what do you do first?Assume the wrong dissector before assuming broken traffic. Check what is registered for that port in the Decode As dialog's *Default* column, then map the port to the protocol the service actually speaks, or to `(none)` to see the raw bytes. If the labels disappear, the sender was never at fault.
saying these in an interview costs you the question
- Malformed Packet proves the sender put invalid bytes on the wire.
- A short snapshot length shows up as Malformed Packet entries.
- Malformed means the frame failed its Ethernet checksum.
- Nothing after the malformed layer can be trusted anywhere in the capture.
- Turning off the dissector is the fix, not a diagnostic step.