["Talbert, Britt USA" <bctalber@xxxxxxx>]

 

 

-----Original Message-----
From: Guy Harris [mailto:gharris@xxxxxxxxx]
Sent: Tuesday, August 03, 2004 5:16 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.

 

No, I didn't see a /dev entry.

 

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.

 

Writing it in libpcap is where I am stuck…see comments at the end.

 

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.

 

My program seems to successfully strip the frame delimiters and “destuff” the bits, however I tried to put it in libpcap format with editcap and it choked on the file.  Right now, I am only interested in piping the captured file into Tethereal so that I can write out the HDLC capture.  The next step would be to do it directly from the device.  Is editcap the correct method?

 

Thanks again…

 

> 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.