Wireshark-dev: Re: [Wireshark-dev] Should I create virtual fields for use in display filters
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: "Hal Lander" <hal_lander@xxxxxxxxxxx>
Date: Sat, 02 Dec 2006 09:18:42 -0900
Very helpful feedback, but I have three questions;


> 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.
How does tvb_reported_length() know the actual length of the packet if the full packet was not captured? 


                                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?
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. 


	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.
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?
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? 

TIA
Hal




From: Guy Harris <guy@xxxxxxxxxxxx>
Reply-To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx> 
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] Should I create virtual fields for use in display filters 
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.
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev


_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered by Pandora http://radio.msn.com/?icid=T002MSN03A07001