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.
