["Hal Lander" <hal_lander@xxxxxxxxxxx>]

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