[Guy Harris <gharris@xxxxxxxxx>]

On Thu, Dec 26, 2002 at 10:02:40PM -0800, Chris Waters wrote:
> This patch is for the TZSP protocol. I have submitted it before, however
> this time it is with a proper libpcap DLT value.

Only link-layer protocols, such as Ethernet, get a DLT_ value. 
Presumably you don't have your own physical network type for TZSP, so
you don't need a DLT_ value for it - you'd just write a dissector to run
atop raw Ethernet, or UDP, or whatever protocol TZSP runs atop.

If, however, you want to dissect the captures sent *over* TZSP, rather
than dissecting the TZSP protocol *itself*, that would require a DLT_
value if the captures are written to a tcpdump-format file.

However, if this is intended to be a protocol for sending *arbitrary*
link-layer types, rather than just 802.11, using Ethereal WTAP_ENCAP
values for the encapsulation is the wrong answer as:

	WTAP_ENCAP values are not guaranteed to remain the same over
	time;

	WTAP_ENCAP values don't just specify the encapsulation of the
	raw frame data - they also specify, in some cases,
	"pseudo-headers" that are constructed from both per-packet
	headers in the file format that are not part of the raw frame
	data and from raw frame data if the particular capture file
	format happens to put that sort of information in raw frame
	data;

	DLT_ formats for libpcap should not contain anything tied to
	Ethereal, because it should be possible for applications not
	based on Ethereal code to read captures in libpcap format.

For example, WTAP_ENCAP_IEEE_802_11_WITH_RADIO specifies a pseudo-header
for the radio information - in Sniffer Wireless captures, the radio
information is stored in per-packet headers that aren't part of the raw
frame data, and in AiroPeek captures, the radio information is stored in
the beginning of the raw frame data.  Wiretap hides those details from
the 802.11 dissector, supplying to Ethereal a pseudo-header containing
the radio information and raw frame data containing only the 802.11
frame, *not* any radio information.

If the TZSP protocol is intended to be used for arbitrary link-layer
types, the encapsulation type should be a DLT_ type.  DLT_TZSP should
instead be a DLT_ value for "802.11 plus the WSP100's TLV information",
and new DLT_ values should be added as additional link-layer types are
supported by it.

(If the TZSP protocol is *not* intended to be used for arbitrary
link-layer types, it needn't contain an encapsulation value at all.)

Note, however, the recent tcpdump-workers discussion of the "to TLV or
not to TLV" issue:

	http://www.tcpdump.org/lists/workers/2002/12/msg00108.html

	http://www.tcpdump.org/lists/workers/2002/12/msg00113.html

	http://www.tcpdump.org/lists/workers/2002/12/msg00116.html

	http://www.tcpdump.org/lists/workers/2002/12/msg00122.html

in which Solomon Peachy gives the reasons why *his* "802.11 plus extra
information" capture file format - supported by current-CVS libpcap
(which just skips the extra information), current-CVS tcpdump (which
just skips the extra information, although it could be made to print
it), and current-CVS Ethereal (I forget whether it was checked in before
0.9.8 or not) - doesn't use TLVs.

His format is documented in

	http://www.shaftnet.org/~pizza/software/capturefrm.txt

Counter-arguments should be directed to Solomon, not to me; I'm CCing
him in case either

	1) he's not on ethereal-dev

or

	2) he didn't notice this thread.

Note that a header containing TLVs, and no indication before the TLVs of
the total length of all the TLVs, *cannot* be skipped by libpcap BPF
filters when testing packet headers (thus making it impossible to use
capture filters), as BPF does not support backwards branches (so that
one cannot shove an infinite loop into the kernel; there *are* platforms
on which non-privileged users can set BPF filters:

	% ls -l /dev/bpf*
	crw-------  1 guy  wheel   23,   0 Jun  9  2002 /dev/bpf0
	crw-------  1 guy  wheel   23,   1 Jun  9  2002 /dev/bpf1

), and thus BPF programs cannot loop.  Solomon's header does have a
length at the beginning, so libpcap could skip it (it currently skips it
based on a hardwired length, but I may try to fix that for the release
of libpcap after 0.8).