Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] tektronix k12xx rf5 support

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

Date: Sat, 11 Jun 2005 14:57:06 +0200
So far I've been able to identify and extract  most of the useful data
in .rf5 files.

Yesterday, I checked in the first stable read-only implementation.

There are few issues I like to discuss before procceding:

  - The k12 format allows for several sources each with its own
protocol stack. That means that there can be files using more than one
encapsulation.

   - It supports a very wide range of stacks for most of which may not
be an encapsulation already there.  Even if we add many of those we
may leave many outside.

  - it contains information regarding each the source (the name,
Timeslot, VC, may be more).

I been thinking on two ways to handle this, either compeletely by the
wiretap module or with the help of a specific dissector.

A dissector would provide the user with information like the name of
the source, it's configuration, and the name of the stackfile used.

A dissector would allow the user to choose the right protocol for a
source with the file already open.

Altogether a dissector would be a more versatile hanlder. *But*, when
opening a k12 file, one would only be able to save to another k12
file.

On the other hand If all of it is done by wiretap:

   - one day one users could use editcap to covert between k12 file
format and other formats, porvided that at least libpcap's
implementation supports per-packet  encapsulation. As wiretap's
libpcap format does not implement per-packet encapsulation yet.
Neither for reading nor for writing. that's not very useful today
(Anyway I would prefer to work on this instead of k12 write support,
as I believe it is useful to a broader user-base)

  - The only way (I'm aware of) the user can talk with wiretap is via
environment variables. That makes very cumbersome to configure the
import mechanism. Other than that users should know exactly what's in
the files before opening the file.  I thought in using an environment
variable to point to a config file.

Luis