On Thu, Jun 26, 2003 at 12:13:34PM +0530, Naveen Kumar Kaushik wrote:
> This file was captured by a Commercial software NetVCR (www.niksun.com) It
> runs on modified FreeBSD kernel.. They use their own engine to capture this
> file. As i know this engine makes use of pcap library only.
> To my surprise the software gives good info about the captured packet and
> you can save them in pcap format.
Unfortunately, it's a pcap format that, at least for ATM-over-T1, uses
the same link-layer-type value as some Linux systems use for ATM
Classical IP when the link-layer header is completely absent (the packet
begins with an IP header) - no ATM header information (e.g., VPI/VCI)
whatsoever is present.
Therefore, Ethereal cannot read it, as it assumes that link-layer type
value means Linux ATM Classical IP, not, for example, ATM-over-T1 with
some sort of link-layer header, as appears to be what's in the capture
file you sent.
In order to get Ethereal to read those captures, a different DLT_ value
- or values - would have to be chosen, and a tool would have to be used
to change the DLT_ value in the capture file header. Fortunately, once
support is added in Ethereal, the "editcap" tool that comes with
Ethereal could do that.
The first question is whether the ATM-over-T1 captures have had
reassembly done or if there's one ATM cell per packet. The capture you
sent has, in most packets, what appears to be a 5-byte header followed
by 45 00, which *could* be a 5-byte header of some sort (e.g., VPI/VCI
plus some other information) followed by an IPv4 header, although the
first packet has only 4 bytes. If they do ATM SAR, that's good, because
if they *don't* do that, somebody'd have to write SAR code for Ethereal,
and I suspect there aren't many people who'd volunteer to do that (I
wouldn't - I don't have time to do so or much interest in doing so).
Then the Niksun people should send to "ethereal-dev@xxxxxxxxxxxx" a
description of the link-layer headers in the packet data for all the
capture formats NetVCR can handle; that description must give enough
detail to allow somebody to write a dissector for the header (or to
determine that the existing ATM/PPP/Cisco HDLC/Frame Relay/Wellfleet
HDLC dissectors can handle them, or can handle them with some changes).
They should also tell us whether the NetVCR knows, at the time it writes
the capture file, which of those link-layer types is being used; if so,
that would be Very Good, as it'd mean that the file could specify, in
its header, what type of file it is, rather than requiring Ethereal to
try to use some heuristics to figure it out.
Once that's one, we'll know how many link-layer type values they'll
need, and we can tell them. It might be that, for some of the
link-layer types, there already exists a standard libpcap link-layer
type value for that type; if so, they should use that value rather than
whatever value they're currently using. If there are any link-layer
types for which there isn't already a link-layer type value (as I
suspect is the case for their ATM-over-T1, for example), they will have
to get those assigned by tcpdump.org, and they should then use the value
tcpdump.org gives them rather than whatever value they're currently
using.
Note that their software should continue to support the old link-layer
type values when reading captures; however, they should change their
software to write captures using the new link-layer type values -
unfortunately, this means that the old software won't read the new
captures. If that's not acceptable to them, then Ethereal will *never*
be able to read their captures without first having "editcap" process
the capture file to use the new standard link-layer type value.