Ethereal-dev: Re: [Ethereal-dev] WTAP_ENCAP_FRELAY

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

From: Guy Harris <[email protected]>
Date: Fri, 2 Jul 2004 00:36:26 -0700
On Tue, Jun 22, 2004 at 12:38:42PM +0200, Marc Carbones wrote:
> I'm trying to open Sniffer Pro cap files captured with a Wan Book, the
> only thing I can see are the Frame Relay headers of the packets that the
> Wan Book captures.

Are you certain that the packets are, in fact, Frame Relay packets?

The Snifferbook (and probably the WanBook) allow you (at least according
to the manual) select an encapsulation option for the line on which
you're capturing - the list of options offered on the Snifferbook are

	Frame Relay
	Cisco HDLC
	Other Router/Bridge

and the capture you sent looks as if the packets in it are Cisco HDLC,
not Frame Relay.

"editcap" has an option to read a capture file and write it out with a
different file type and encapsulation.

I'm not sure we've seen any Windows Sniffer captures with Cisco HDLC
traffic in it - we haven't found anything in the file header of a
Windows Sniffer capture that appears to indicate whether it's a Cisco
HDLC capture, so we don't support writing Cisco HDLC captures, and thus
can't transform your capture into a Windows Sniffer Cisco HDLC capture.

We can, however, transform it into a libpcap Cisco HDLC capture.  I did,
with the command

	editcap -F libpcap -T chdlc {input file} {output file}

and, if I read the output file, the packets decode correctly - the
frames start with 0x0f 0x00 0x08 0x00, where:

	0x0f indicates, in Cisco HDLC, that the packet is a unicast

	0x00 is a padding packet in Cisco HDLC;

	0x08 0x00 is an Ethernet packet type - those are used for most
	    protocols in Cisco HDLC - and, is in fact, the packet type
	    for IP;

so, if the capture is turned into a Cisco HDLC capture, most of the
packets are decoded as UDP packets from, ports 2336 and
2334, to, ports 2326 and 2328.  There are also some TCP
packets, including some Telnet traffic, and some SNMP traps.

So I suspect the capture was, in fact, done on a line that was using
Cisco HDLC, not a Frame Relay line, and that the WanBook was incorrectly
set with an encapsulation type of Frame Relay rather than Cisco HDLC.