Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] plug in dissector for Wireshark 0.99.3

From: Bill Fassler <bill.fassler@xxxxxxxxx>
Date: Fri, 15 Sep 2006 13:13:04 -0700 (PDT)
Thanks Guy!  I really appreciate your prompt and informative response.  I never used or seen Ethereal or Wireshark before last week nor have I ever worked with VoIP, so if it sounds like I don't know what I'm talking about its because I really don't know what I'm talking about.  This application is fairly easy to work with and I made good progress in the last few days for not having any idea how to do it before Monday.  With help from pros like you I should have this plugin spit and polished in no time.

Thanks again,
Bill

Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Sep 15, 2006, at 12:14 PM, Bill Fassler wrote:

> The traffic is initially captured and classified as "Ethernet
> II" (apparently the default selection when Wireshark can't determine
> what kind of Ethernet traffic).

What do you mean by "classified as 'Ethernet II'"? If you mean it
displays

Ethernet II, Src: IeeeRegi_33:7f:00 (00:50:c2:33:7f:00), Dst:
IeeeRegi_33:7f:fc (00:50:c2:33:7f:fc)
Destination: IeeeRegi_33:7f:fc (00:50:c2:33:7f:fc)
Source: IeeeRegi_33:7f:00 (00:50:c2:33:7f:00)

that's not a "default selection", it's done for all traffic with a
type field (rather than a length field) *regardless* of whether it can
determine what kind of traffic it is, because *all* that traffic is
"Ethernet II" traffic (or whatever you want to call it - the current
802.3 standards include both "Ethernet II" traffic with a type field
and "802.3" traffic with a length field).

If you mean that, when your dissector isn't present, the traffic is
just classified as "Ethernet II" traffic, yes, that's the default for
traffic that it can't further identify.

> Although it looks like I can get my dissector to start on the packet
> after the byte that identifies ethernet type (byte 14)

Well, yes, that's where dissectors for Ethernet traffic are supposed
to start, and that's where the Ethernet dissector will start them.

> I don't know how to "backtrack" and over rule what the core
> Wireshark application has already dissected.

You can't know how to do that, because it's not possible, by design.

> As you can see from this snipped, my protocol (566F) is still
> considered "Type : Unkown" even though it just used that information
> to pass the packet to my plugin.

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.

> Also there is information in the source and destination MAC
> addresses that I would like to dissect.

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


All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.