Ethereal-users: RE: [Ethereal-users] RE: Analyzing Cisco HDLC

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

From: "Talbert, Britt USA" <bctalber@xxxxxxx>
Date: Tue, 14 Sep 2004 10:47:28 -0700
Excellent! That worked...I went in and poked around with the link type
(changed it to PPP) and ethereal displayed everything.

Thanks for the tip, I appreciate it.

Britt

>-----Original Message-----
>From: ethereal-users-bounces@xxxxxxxxxxxx [mailto:ethereal-users-
>bounces@xxxxxxxxxxxx] On Behalf Of Nisbet, Tom
>Sent: Monday, September 13, 2004 4:25 PM
>To: 'Ethereal user support'
>Subject: RE: [Ethereal-users] RE: Analyzing Cisco HDLC
>
>It sounds like your trace may be PPP rather than Cisco HDLC.  If you
send
>me
>a few frames I can take a look.  The fix may be as simple as changing
the
>link type of your capture file.
>
>Tom
>
>> -----Original Message-----
>> From: Talbert, Britt USA [mailto:bctalber@xxxxxxx]
>> Sent: Friday, September 10, 2004 12:37 AM
>> To: Guy Harris
>> Cc: ethereal-users@xxxxxxxxxxxx
>> Subject: RE: [Ethereal-users] RE: Analyzing Cisco HDLC
>>
>>
>> Thanks for the help, I appreciate it, but I have one
>> (hopefully?) more question.  I start with the raw Cisco HDLC
>> capture and a program that does the following:
>>
>>     -- discard the leading ones
>>     -- strips and discards the frame delimiters
>>     -- removes the "stuffed" bits
>>     -- reassembles the frame once the ending frame delimiter is found
>>     -- configures it into libpcap format
>>     -- discards all the 1s until the next frame delimiter is
>> encountered.
>>     -- Starts the process over until the eof.
>>
>> The result is a packet capture in libpcap format that I can
>> pipe to Ethereal, which works.  The problem is when Ethereal
>> displays the packet capture.  It seems like some of the admin
>> information regarding the network is displayed in the lower
>> display next to the hex dump, however I only get N/A for
>> source and destination and the protocol column only has the
>> hex value (0x0021, in this case).  I poked around with the
>> options and preferences, but it doesn't seem to work.
>>
>> Any suggestions?  I can provide more info if needed.
>>
>> Thanks again,
>>
>> Britt
>>
>> -----Original Message-----
>> From: Guy Harris [mailto:gharris@xxxxxxxxx]
>> Sent: Tue 8/3/2004 5:15 PM
>> To: Talbert, Britt USA
>> Cc: ethereal-users@xxxxxxxxxxxx
>> Subject: Re: [Ethereal-users] RE: Analyzing Cisco HDLC
>>
>>
>>
>> 	Talbert, Britt USA said:
>> 	> On Wed, Jul 28, 2004 at 04:02:42PM -0700, Talbert,
>> Britt USA wrote:
>> 	>>> 1)      How do I put the file into a format
>> (capture format) so that
>> 	>>> tethereal will understand?
>> 	>
>> 	>>Get a sufficiently recent version of libpcap/WinPcap,
>> and using it,
>> 	>>write a program that:
>> 	>
>> 	> I am using Tethereal on Debian 3.0-i386-woody with
>> libpcap 0.6.2 - is
>> 	> that recent enough?  I looked in the source code and
>> found the functions
>> 	> you were referring to below.
>>
>> 	That should be recent enough to have that function...
>>
>> 	>>        calls "pcap_open_dead()" (you need a
>> sufficiently recent version
>> 	so it *has*
>> 	>>        that function) with a "linktype" of
>> DLT_C_HDLC and a "snaplen"
>> 	of 65535;
>>
>> 	...and to have DLT_C_HDLC.
>>
>> 	> I am using Tethereal on Debian and the current
>> version of libpcap is
>> 	> 0.6.2. I looked at 0.8.3 and
>> 	> saw the "pcap-dag.c" and "pcap-linux.c".  Would I
>> alter the code so that
>> 	> instead of checking to
>> 	> see if "dag" was in the name, I would check for a name that is
>> 	> distinctive from a network interface?
>>
>> 	Does the device on which you're capturing have a "/dev"
>> entry?  If so, you
>> 	might just look for names that correspond to its "/dev"
>> entry, and use the
>> 	name.
>>
>> 	You wouldn't do that instead of checking for "dag",
>> unless your devices
>> 	have "dag" in the name; you'd leave the DAG code in
>> there (although it
>> 	probably wouldn't be compiled in), and do the check for
>> your device
>> 	before, or after, the check for the DAG device.
>>
>> 	> I suppose I could do that with libpcap 0.8.3 and then
>> once that's done
>> 	> feed it to Tethereal, which is using 0.6.2, but I
>> guess that would not
>> 	matter
>> 	> since the data would already be in a form Tethereal
>> could understand.
>> 	Is that correct?
>>
>> 	If you wrote it in libpcap format, Tethereal would
>> understand it.
>>
>> 	However, if you're willing to rebuild Tethereal from
>> source, you could
>> 	rebuild it with your modified 0.8.3, in which case it
>> (and Ethereal) would
>> 	be able to capture on that device directly.
>>
>> 	> Is it a matter of  "#ifdef MY_DEVICE_NAME" instead of
>> the "#ifdef
>> 	HAVE_DAG_API" followed by
>> 	> the call to "MY_DEVICE_NAME_open_live"
>>
>> 	The only reason the "#ifdef HAVE_DAG_API" is there is
>> that the API used to
>> 	access DAG devices is present only if it's been
>> installed; you have to get
>> 	the software for that from Endace.
>>
>> 	Unless your code would also require a library that's
>> not present on all of
>> 	the OSes on which you'd want to build libpcap 0.8.3
>> from source, you
>> 	wouldn't need the #ifdef.
>>
>> 	> That clarifies it - I thought that Tethereal took care of the
>> 	> bit-stuffing and frame delimiters, 01111110, for me.
>>
>> 	Nope - all the capture file formats it reads with Cisco
>> HDLC have the
>> 	bit-stuffing and framing removed, with each frame being
>> in a separate
>> 	record in the file.
>>
>> 	> So basically, what I need to do once I have the data
>> off the wire is the
>> 	> following:
>> 	>
>> 	> 1)   Take care of the bit-stuffing and strip the
>> delimiters from the
>> 	> frames.
>> 	>
>> 	> 2)   Put the data into file capture format (by
>> modifying libpcap) that
>> 	> will be understood by Tethereal.
>>
>> 	You only need to modify libpcap if you want to have
>> Tethereal (or other
>> 	libpcap-based programs, such as tcpdump or Ethereal)
>> *directly* capture
>> 	from your device.
>>
>> 	If all you'll be using libpcap for is to write out a
>> Cisco HDLC capture,
>> 	and you won't be using libpcap to read the packets from
>> the device, you
>> 	don't have to modify libpcap.
>>
>> 	> I have #1 working (pretty much).  Is there anything
>> available for #2?
>>
>> 	Nothing that I know of, but there's not a lot of code
>> to be written for that.
>>
>>
>>
>>
>>
>
>_______________________________________________
>Ethereal-users mailing list
>Ethereal-users@xxxxxxxxxxxx
>http://www.ethereal.com/mailman/listinfo/ethereal-users