Wireshark-dev: Re: [Wireshark-dev] Should I create virtual fields for use in display filters
From: Guy Harris <[email protected]>
Date: Sun, 26 Nov 2006 11:14:48 -0800
Hal Lander wrote:
I would like to give users of my dissector a quick and easy way to find any packets that have been sent which are not of the expected size. To me, as a newbie, the obvious way to do this would be to allow them to filter packets based on expected and actual packet sizes.
To do that I think I need fields for the "actual" and "expected" packet 
size.
The packets in my protocol do not contain a field for the "expected" 
size, though it can be deduced from the message type.
The "actual" size could be obtained from tvb_length(tvb).
That's not guaranteed to be the actual size of the packet.  tvb_length() 
returns the amount of data in the tvbuff; because a capture can be made 
with a "snapshot length" less than the maximum packet size on a network, 
the amount of data for a packet in the capture file might be less than 
the actual size of the packet on the network, and that reduction of the 
amount of data would be reflected in the result of tvb_length().
Use tvb_reported_length() instead.

Should I create fields for the "actual" and "expected" sizes even though these fields don't actually exist in the data?
That would be one way to do it; there are other dissectors that include 
"calculated" fields or other fields that don't exist in the data.  You 
should use PROTO_ITEM_SET_GENERATED() on the item after putting it into 
the protocol tree, so it can be marked as not directly corresponding to 
data in the packet.
If I do what should I get Wireshark to highlight e.g. for the "expected" size should Wireshark highlight the data in the header showing the message type?
"Highlight" in what sense?

Is there a more correct/better way of achieving what I want. for example is there already some way to filter on "actual" packet size without the need for me to create a field.
There's no way to filter on the actual size of a packet at an arbitrary 
protocol layer.
However:

if the packet is too short, and the dissector is dissecting all the fields of a packet, it will probably get an error when it tries to fetch a field that would be past the end of the packet, and the packet will be flagged as "malformed", so you can use the filter "malformed";
	if a packet is too long, your dissector could define a field for extra 
data at the end of the packet, and dissect the extra data at the end of 
the packet as with that field, and you could filter for that field.