On Thu, Jun 26, 2003 at 02:41:31PM +0530, Naveen Kumar Kaushik wrote:
> If I understood correctly
> One need to know them what DLT values are used in NetVCR
Yes.
> and whether these values are assigned by tcpdump.org .
...*and* whether they're used anywhere else or *might* be used anywhere
else.
> Ok
> I would like to know whether ethereal can capture ATM/Frame Relay/PPP/Cisco
> Serial/Serial WellFleet over T1 traffic,
It can do so only if libpcap can do so; the standard libpcap only
supports capturing on network interfaces that are connected to the OS's
networking stack (or BPF mechanism), which means that it can't support
third-party passive capture on interfaces.
It does have DLT_ values for:
SunATM on Solaris, which has a link-layer header that is *not*
the same as the one in the ATM capture you sent;
classical IP over ATM on Linux, which has *no* link-layer
headers - the packet begins with the IP header;
RFC 1483 ATM on BSD, which has an 802.2 LLC header at the
beginning of the packet;
Frame Relay, with the link-layer header beginning with the DLCI
(not with the flag - it assumes that bit-stuffing and framing
has already been removed);
PPP;
Cisco HDLC.
It doesn't care about the physical link layer in that case; for example,
PPP could be over a T1 line, or an asynchronous serial line - it assumes
that all the framing and bit-stuffing/octet-stuffing has already been
removed by the time libpcap sees the packet.
> if yes what DLT values will it use
> (I have used ethereal just to see the packets).
The standard libpcap values are what Ethereal will use; those are:
123 for SunATM;
106 for Linux classical IP;
100 for BSD RFC 1483 ATM;
107 for Frame Relay;
9 for PPP;
104 for Cisco HDLC.
> 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.
Note that those dissectors might not expect the same packet data that is
in a NetVCR capture. If so, they should *not* be changed to expect
that; they expect what will show up if you capture using libpcap, and
should continue to do so. If NetVCR supplies different packet data,
you'd need a *new* DLT_ value for that.
> I would also like to know whether ethereal will consider NetVCR capture as
> types which might be included in list of discetors.
If
1) it doesn't take much work to add dissectors (for example, if
ATM captures have cells rather than reassembled AAL5 PDUs,
then displaying them as anything other than un-reassembled
cells would take a lot of work) or somebody's willing to do
that work (I don't have the time to write ATM SAR code);
2) the NetVCR captures either
use standard tcpdump.org DLT_ values rather than
values already assigned for other purposes
or
use a new file format, rather than libpcap format, and
we get a *complete* description of that file format;
it'd be considered, although it's more likely to be considered if
somebody sends us all the changes necessary to support it.