Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Should I create virtual fields for use in display filters

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sat, 02 Dec 2006 11:29:49 -0800
Hal Lander wrote:

How does tvb_reported_length() know the actual length of the packet if the full packet was not captured?

Because the full packet was received; it was just cut short in the process of supplying it to the capture mechanism (i.e., all the packet data was available, but only part of it was supplied to libpcap by the capture mechanism). The capture mechanism supplies both the full length and the captured length.

If, in the middle pane, you put the cursor on a field then the raw data that generated the field is "highlighted" in the lower pane. When you use PROTO_ITEM_SET_GENERATED() it displays the field in the middle pane in square brackets, it still highlights the raw data in the lower pane though, so it probably makes sense to highlight the data from which the calculated value was derived.

Possibly, possibly not. I wouldn't necessarily expect to see the message type field highlighted when I select the expected message length generated field.

However, if you want that to happen, then you should, when you create the entry for the expected message length, specify the offset and length corresponding to the data from which it was generated.

I have tried corrupting packets and Wireshark does nicely flag up the offending subtree as "[Malformed Packet]". How do I filter to find those packets that are malformed?

As per my previous mail, use the display filter "malformed".

If I try and dissect beyond the end of the bufferWireshark is automatically going to flag packets that are too short as being malformed . Is there any way to also get Wireshark to flag packets that are too long as malformed, that way all packets of the wrong length can be caught with one filter?

If any of the extra data is present in the tvbuff, I'd use "proto_tree_add_protocol_format()", with "proto_malformed", and have the text be "[Malformed packet: extra data at the end]" or something such as that. If the data *isn't* present in the tvbuff - for example, because the captured data was cut short by a snapshot length - do the same, but use 0 as the offset and length.