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

[Chris Waters <chris.waters@xxxxxxxxxxxxxxxxxxxx>]

Hi,

I appreciate your feedback on protocol design and I have addressed your
questions below. However, my intention in contributing this patch is not to
propose a standard for 802.11 packet capture, it is simply so that users of
Ethereal can dissect captures containing TZSP frames. Currently I have to
provide a patched version and it is a lot of work to keep it synced with the
latest Ethereal version.

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

TZSP is not a link-layer protocol on the network, however from the
perspective of Ethereal it can be the first protocol in a decode. We use a
modified version of winpcap which receives packets from a remote sensor,
strips off the protocol headers up to the TZSP header and then passes the
packet to Ethereal as if TZSP was the link-layer protocol. This gives the
illusion to a user that the packet was captured locally, even though it
actually came across the network. The screenshot below shows how it looks to
the user.

http://www.networkchemistry.com/products/wsp100/images/ss_wlan_capture.gif

In reality TZSP is encapsulated in UDP so if you captured packets using an
Ethernet adapter you would see:

http://www.networkchemistry.com/products/wsp100/images/ss_wlan_capture_ether
eal.gif

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

Since captures contain TZSP packets can be saved to disk in libpcap format a
DLT value is necessary to differentiate the resulting files.

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

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.

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

TZSP *is* designed to be used for arbitrary link-layer types. We already use
it for Ethernet as well as 802.11. I am not sure I agree that a new DLT
should be added for each protocol that could be encapsulated. Consider the
scenario where a capture program runs on a PC and sends captured packets
across the network to another workstation running Ethereal. With the current
design, supporting different devices on the capture PC (PPP, Bluetooth,
802.11, Ethernet, etc) only requires that an appropriate driver be available
and that the capture program populates the TZSP header correctly. There is
no need to modify Ethereal to support a new encapsulation when a new driver,
e.g. token ring, becomes available.

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

IMHO TLVs are the best way to achieve our goals, and to avoid endless
revisions of the protocol.

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

This is a good point and one that I hadn't considered. In practice the BPF
filters are run before the packets are encapsulated, i.e. on the remote
sensor, so this isn't a big drawback, but I guess it would be better if TZSP
could support BPF. Perhaps version 2 of the protocol needs a length field
too.

You have identified at least two places where a future version of the
protocol could be improved, however there are a lot of TZSP version 1
devices already in the field so I would still like to see this patch
committed.

Regards,

Chris.