> >From my reading of the README.developer, I expected tethereal to decode
> packets the same way that the ethereal GUI does. I made some
> modifications to packet-ethertype.c to make it decode some "special"
> ethertypes correctly,
"Decode" in what sense?
"Decode" in the sense of showing the packet type in the "Info" column if
there's no higher-level dissector in Ethereal, or "decode" in the sense
of providing a higher-level dissector in Ethereal?
> and added a column to the GUI display to show an interpretation of those
> types.
"Interpretation" in what sense?
If you actually want to dissect the contents of packets with those
ethertypes, the right way to handle that is to add a new dissector
module and have it register itself, with the specified ethertype, to the
"ethertype" dissector table, with a call such as
dissector_add("ethertype", ETHERTYPE_XXX, dissect_xxx);
in a "proto_reg_handoff_xxx()" routine (see, for example,
"proto_reg_handoff_ip()" in "packet-ip.c"). The interpretation of those
types would then go in the Info column; there would be no need to add a
new column.
If, however, you're not dissecting the contents of packets with those
ethertypes, but just interpreting the ethertype *itself* differently,
why can this not be done by adding new entries to the "etype_vals" array
at the beginning of "ethertype.c"?
If the ethertypes are "special" in that there is, say, a large range of
them, with all of those packets being the same type, and with some of
the bits of the type field being interpreted in some other fashion - for
example, to pick a hypothetical example, ethertypes in the range 0x8000
through 0x80ff (yes, I know, that probably isn't the range, and probably
overlaps real ethertypes), with the lower-order 8 bits of the ethertype
being a packet priority level, the right way to do that would probably
be to:
not add those types to "etype_vals";
have the code at the bottom of "ethertype()" do, if
"match_strval()" returns a null pointer (which would be the case
if the types weren't in "etype_vals()", as would be the case
here), check whether the types are in the specified range and,
if so, add to the Info column the name of the ethertype *and*
the packet priority level;
with, again, no need to add a new column - "Info" is the appropriate
place for that information.
(Adjust the example above as appropriate for the ethertypes in question.)
> But when I try tethereal -V, it looks as if it never passes through the
> ethertype function.
That seems *extremely* unlikely; if dissection done with "tethereal -V"
didn't cause "ethertype()" ever to be called, dissection done with
"tethereal -V" would *never* show any packets, in an Ethernet (or other
Ethertype-based link layer) capture, as being, for example, IP packets,
and it *does* show them.
Could you please
1) give us a detailed explanation of what's "special" about the
ethertypes in question, and of the changes you made to
"packet-ethertype.c";
2) give us a detailed example of what happens when dissecting a
capture with those packets, both with Ethereal and with
Tethereal with the "-V" flag?
