ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Add computed bytes of different length

From: Evan Huus <eapache@xxxxxxxxx>
Date: Wed, 4 Jun 2014 12:18:52 -0400
On Wed, Jun 4, 2014 at 12:12 PM, Kevin Cox <kevincox@xxxxxxxxxxx> wrote:
On 04/06/14 10:24, Anders Broman wrote:
> One option is to read the bytes from the tvb to a buffer manipulate the bytes and make a new tvb with the manipulated bytes in the buffer and then dissect that new tvb.
> Like uncompressing something and  then dissect the content of the uncompressed result.If it's just a few bytes that may not be feasible I suppose.

I tried this using tvb_new_child_real_data_ but the highlighted area in
wireshark seemed to be the first n bytes of the parent tvb.  I don't
know how to link it back where the data actually came from.

> If the encoded stuff really is a string "string coming from the wrong place in the packet" you might want to add a new string encoding type and add it as a string
> With ENC_MY_STRING_ENCODING.

This is possible but I'm not sure it would be ideal.  I will explain my
use case a bit more.

I have a "blob" type in my protocol that has some metadata such as
length and type and I want to create a generic parser function that can
be used from multiple locations in my protocol.

I'm thinking that the ideal output would contain an parent item of a
type passed into my function.  This would have the value of the blob
content so it can be filtered on.  However I want it to highlight the
whole source of the blob in the "packet view".

Then this item would have expert children such as length, type and data
which would point to the actual pieces inside the structure.

I can get most of this using a FT_NONE or text item with custom
formatting however that will leave me unable to filter the field.
 
If you're going to have a data subfield that is filterable, why do you need the parent item to be filterable as well? Wouldn't they have the exact same thing? Most Wireshark dissectors do not make the intermediate tree items filterable, only the "bottom"-level elements.

Is this the best approach?  Or would a different method be better.  I
did a similar dissection of a string and am very pleased with the
output, however because the source and value lengths are tied together
for bytes objects I don't know how to implement it.

Thanks,
Kevin


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe