[Kevin Fowler <kfowler@xxxxxxxxxx>]

Guy,
 by special I meant as you described below, a range of ethertypes.
Beyond these special values, there is nothing different from a normal IP
ethertype, and so I just passed it to dissect_ip, i.e., see added code
below.
------------------------------------
void
ethertype(guint16 etype, tvbuff_t *tvb, int offset_after_etype,
packet_info *pinfo,
                proto_tree *tree, proto_tree *fh_tree, int item_id)
{
        dissector_t     sub_dissector;
        char            *description;
        tvbuff_t        *next_tvb;
        const guint8    *next_pd;
        int             next_offset;

        /* Add to proto_tree */
        if (tree) {
                proto_tree_add_uint(fh_tree, item_id, tvb,
offset_after_etype - 2, 2, etype);
        }

        next_tvb = tvb_new_subset(tvb, offset_after_etype, -1, -1);
        tvb_compat(next_tvb, &next_pd, &next_offset);

/* trying a  dynamic approach here */
   if (oneofmine(etype)) {
     if (check_col(pinfo->fd, COL_IBN_VR)) {
         col_add_fstr(pinfo->fd, COL_IBN_VR, "ET%d", etype);
     }
     dissector_add("ethertype", etype, dissect_ip);
     dissect_ip(next_pd, next_offset, pinfo->fd, tree);
     return;
  }

---------------------------------------------------------------
I put it here to avoid having to put 64 distinct dissector_add
statements in packet-ip.c, but I'll do that if I have to - just trying
to avoid the brute force method.
This is also where I added the value to the new column. The purpose of
this is to allow me to quickly identify and sort on this value. I want
the Info column to continue to be used by higher layer protocols that
decode the rest of the packet. I realize this is not for general use -
I'm trying to adpat it for monitoring a private net internal to a
distributed system.


Guy Harris wrote:
> 
> > >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"?

I also do this so that the correct interpretation appears inside the
"Ethernet II" decode.

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

the reason I don't do this is that I want the rest of the packet decoded
according to normal IP, etc. as follows in the dissect_ip function.

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


I even put some printf statements in packet-eth.c, right before it calls
ethertype(). When I decode with ethereal, I see it, when I decode with
tethereal -V, I don't. 

> 
> 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";

I want ethertype range 0900-093f to be decoded as an IP packet. I want
the ethertype to be interpreted correctly in the "Ethernet II" decode,
and the value to appear in its own column to the left of the source
address in both the GUI and the tethereal summary output.

> 
>         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?

With ethereal, I see the column I added, with the ethertype values
listed when they fall in the special range. I see the type interpreted
according to the entries I added to etype_vals (yes all 64 of them :-(,.
And I see the rest of the packet decoded correctly.

With tethereal -V, I do not see the ethertype interpreted correctly in
the "Ethernet II" decode (just says "Unknown"), and the packet is not
decoded as an IP packet - its just Data after the Ethernet header and
the MAC addresses are shown for the source and dest addresses.


I also want to modify the summary output of tethereal (no -V) to have
the same column as I now have in the GUI summary pane. I tried to add it
in tethereal.c, but I was just shooting in the dark.

Thanks for your guidance!
Kevin