If I understood correctly
One need to know them what DLT values are used in NetVCR and whether these
values are assigned by tcpdump.org .
Ok
I would like to know whether ethereal can capture ATM/Frame Relay/PPP/Cisco
Serial/Serial WellFleet over T1 traffic, if yes what DLT values will it use
(I have used ethereal just to see the packets).
Once i know these DLT values ,by seeing wiretap/libpcap.c in ethereal source
i might be able to find out which discetors are called when file containing
these traffic are opened.
I would also like to know whether ethereal will consider NetVCR capture as
types which might be included in list of discetors .
Naveen
----- Original Message -----
From: "Guy Harris" <guy@xxxxxxxxxxxx>
To: "Naveen Kumar Kaushik" <naveenk@xxxxxxxxxxxxx>
Cc: <Ethereal-users@xxxxxxxxxxxx>
Sent: Thursday, June 26, 2003 1:43 PM
Subject: Re: [Ethereal-users] Capturing ATM over T1
> 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.
>