Hi,
Better use:
proto_tree_add uint(vppn_tree, hf_dest_id, tvb, 0, 0, packet_info.dl_dst);
Thanx,
Jaap
On Mon, 18 Sep 2006, Bill Fassler wrote:
> I could use a little more help. The propietary protocol I am working with has
> a one byte ID at the ends of both the source and destination MAC addresses.
> This Source (SID) or Destination (DID) ID helps me identify whether the
> packet was generated by a Master board or a slave board and also helps me
> identify the packet type. I can use a negative offset which causes WireShark
> to properly highlight the SID or DID within the packet, but will not display
> or relay the value (it always displays 0x00 regardless). Here is the line I
> tried to use:
>
> proto_tree_add_item(vppn_tree, hf_dest_id, tvb, -9, 1, FALSE);
> corresponding field array declaration:
> static hf_register_info hf[] = {
> { &hf_dest_id,
> { "Destination ID",
> "vppn.did",
> FT_UINT8, BASE_HEX, NULL, 0x0,
> "Destination ID", HFILL }},
>
> Then based on Guy Harris's reply (relevant portion included) to my last post
> I tried this:
>
> proto_tree_add_item(vppn_tree, packet_info.dl_dst, tvb, 0, 0, FALSE);
>
> Of course this won't compile so I obviously don't know what I'm doing?
>
> Can any of you Gurus straighten me out?
>
> Bill Fassler
> Guy Harris <[EMAIL PROTECTED]> wrote:
>
> The problem there isn't that your dissector can't go back and
> "rewrite" what the Ethernet dissector has done, the problem is that we
> don't have a mechanism by which the value_string table for a field can
> be set up at run time. We arguably should have that, so that, for
> example, the table of Ethernet types can be updated by dissectors of
> Ethernet protocols - or, alternatively, so that the table can be read
> from a file.
>
> Again, by design, you won't be able to update the way those fields are
> dissected. Dissecting them is the job of the Ethernet dissector, as
> their contents are defined by the Ethernet spec.
>
> However, if you just need to *read* those in your dissector, you can
> do that by looking at the dl_src and dl_dst fields in the structure
> pointed to by the "packet_info" pointer argument to your dissector.
>
> You could also put into *your* dissector's protocol tree a dissection
> of the relevant parts of those fields; the offset and length values
> would both be 0, as you wouldn't be able to make them refer to the
> data in the Ethernet header portion of the packet (again, by design).
>
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
>
> ---------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> countries) for 2?/min or less.
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
