Ethereal-dev: Re: [Ethereal-dev] TZSP Patch

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Tue, 7 Jan 2003 21:08:04 -0800
On Fri, Dec 27, 2002 at 05:00:59PM -0800, Guy Harris wrote:
> On Fri, Dec 27, 2002 at 04:50:37PM -0800, Chris Waters wrote:
> > This is a good point. I agree with you that the choice of Ethereal
> > WTAP_ENCAP values to specify the encapsulated protocol is flawed. Hmm,
> > perhaps version 2 of the protocol can switch to DLT values instead.
> 
> ...and perhaps version 1 of the protocol should be defined to use
> specific values for encapsulated protocols, and Ethereal should map
> those to WTAP_ENCAP values *even though most of them happen to be the
> same, at this moment, as WTAP_ENCAP values*.
> 
> I.e.:
> 
> 	TZSP_ENCAP_ETHERNET	1
> 	TZSP_ENCAP_TOKEN_RING	2
> 
> and so on; that way, the TZSP protocol is defined without any reference
> to Ethereal, so that
> 
> 	1) tcpdump could map TZSP_ENCAP values to DLT_ values and handle
> 	   TZSP captures
> 
> and
> 
> 	2) if Ethereal changed the WTAP_ENCAP values it'd still work
> 	   with TZSP captures.
> 
> (Note that not all WTAP_ENCAP values should necessarily have
> corresponding TZSP_ENCAP values; values that include a pseudo-header
> won't work unless you explicitly define how the information used to
> construct that WTAP_ENCAP's pseudo-header information will be stored in
> the raw packet data.)

I've checked in "packet-tzsp.c" (with some whitespace cleanups and some
other fixes for problems reported by compiler warnings), with that
change to use a mapping table to go from TZSP_ENCAP values to WTAP_ENCAP
values (which is necessary because WTAP_ENCAP_IEEE_802_11 no longer has
the value 18 in Wiretap), and also checked in your most recent patch
(with a change to map 128, not 126, to WTAP_ENCAP_TZSP, as 128 is the
value assigned to DLT_TZSP - 126 and 127 were already taken).

The WTAP_ENCAP values I've given TZSP_ENCAP values are the ones where
there either is no pseudo-header or the pseudo-header includes only a
direction - I plan to move the direction out of the pseudo-header and
allow it to have a "direction not known" value, as, for point-to-point
links, libpcap captures don't always supply it.