On Thursday, June 26, 2003, at 8:03AM, Ian Schorr wrote:
Niksun distributes a modified version of Ethereal as part of their
"NetXperts" package. Can this version read these types of files? If
so, I suspect that their released source code for modified Ethereal
(http://www.niksun.com/index.php?id=314) would already contain code to
interpret/dissect the data.
It does, but they did several things that they might not have known
were bogus, but that are, in fact, bogus:
1) they reused the standard existing DLT_ types for Cisco HDLC and
Frame Relay to be used for Cisco HDLC and Frame Relay captures with
their extra headers - this means that, without sticking in some
heuristics (which might not be implementable, and which would probably
be ugly in any case), one cannot have a version of Ethereal that can
read those captures *and* can read normal Cisco HDLC or Frame Relay
libpcap captures;
2) they reused DLT_ type 18, used in SuSE 6.3 libpcap for Linux
Classical IP over ATM (with *no* link-layer header; the packet starts
with an IP header) for their ATM link-layer type, and DLT_ type 19,
used in the libpcap/tcpdump patches in at least some versions of the
Linux ATM distribution for Linux Classical IP over ATM, for their
Ethernet link-layer type - this means that, without heuristics,
Ethereal wouldn't be able to read those Linux ATM captures and Niksun
captures as well;
3) they reused the already-too-overloaded DLT_ type 16 for PPP and the
already-overloaded DLT_ type 17 for Cisco HDLC.
So they need to:
1) stop using 19 for Ethernet, and just use 1, which is the standard
DLT_ value for Ethernet (it's called DLT_EN10MB, but the "10MB" is to
distinguish it from the old 3MB experimental Ethernet, which I think
had 8-bit rather than 48-bit addresses and really *did* need separate
dissectors; it's intended for use with *all* 802.3 Ethernet, regardless
of speed - and regardless of whether there's a type or length field in
the header of the packet);
2) ask tcpdump-workers@xxxxxxxxxxx for new DLT_ values for their Frame
Relay, PPP, Cisco HDLC, ATM, and Wellfleet HDLC headers, and use those
instead of the values they were using.
Once that's done, I'd be willing to add support for the new link-layer
types. Captures from the existing versions of their software would
have to be handed to a "fix-up" program that would patch the link-layer
type in the header (I'd be willing to write such a program - it's not
hard) in order for Ethereal to be able to read them.
