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).
