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 <guy@xxxxxxxxxxxx> 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
> Wireshark-dev@xxxxxxxxxxxxx
> 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.
