Wireshark-dev: Re: [Wireshark-dev] Should I create virtual fields for use in display filters
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.
