Ethereal-users: [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, 3 Aug 2004 15:44:01 -0700

Guy,

 

Thank you…that helps tremendously.  I have a couple clarifying questions – see below…..

 

 

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.
 
>        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;
 
>        uses the "pcap_t" you get back from that call in a call to
>        "pcap_dump_open()";
 
>        for each frame it reads from the PCI card:
 
>            assembles the contents of the frame in memory, *with all the
>            bit-stuffing and 01111110 framing stuff stripped out* (as
>            Tethereal expects that to have been done);
>            fills in a "struct pcap_pkthdr" with the current time as the
>            time stamp and the number of bytes in the frame (with the
>            bit-stuffing and framing stuff removed) as the len and
>            caplen;
 
>            calls "pcap_dump()" with the "pcap_dumper_t" returned by
>            "pcap_dump_open()" as the first argument, a pointer to the
>            "struct pcap_pkthdr" as the second argument, and a pointer
>            to the packet data as the third argument;
 
>        calls "pcap_dump_close()" on the "pcap_dumper_t" when the last
>        packet has been seen.
 
>> a.       The problem with that is that I will be handing tethereal
>> 1-byte size files on a continual basis.
 
>Tethereal can't handle that.
 
May not be a problem anymore – I got ahead of myself.
 
>> 2)      How can I pipe the data to tethereal before putting it in a
>> file?
 
>What do you mean by "before"?
 
>You could pipe it to Tethereal and have *it* write it to a file:
 
>         yourprogram | tethereal -i - -w filename
 
Yes, that’s what I meant.
 
>Another alternative would be to, instead of writing a program, modify
>libpcap to be able to read from your device.  It'd still strip out the
>bit-stuffing and framing, and construct a "struct pcap_pkthdr", but it'd
>hand them to the application using libpcap.
 
>See "pcap-bpf.c" or "pcap-linux.c" in libpcap 0.8 or WinPcap 3.1 beta
>for an example of how to hook into the open routine on whatever platform
>you're doing this - see the code in "pcap_open_live()" inside "#ifdef
>HAVE_DAG_API"/"#endif".  That code checks whether the name of the device
>being opened has "dag" in it and, if so, calls the routine for opening
>Endace DAG devices.  You'd have to pick some other string that your
>device would have in its name but no network interface would have, or
>figure out some other way to distinguish your device from a network
>interface.
 
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?
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?  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 actual code for your device would work somewhat similarly to the DAG
>code in "pcap-dag.c" in libpcap 0.8 or WinPcap 3.1 beta.  (You'd have to
>modify one of those versions or a later version.)
 
>With something such as that, tcpdump/WinDump or Ethereal or Tethereal or
>Snort or...  could itself capture on your device.
 
>> The documentation says that tethereal supports Cisco HDLC.
 
>It does, but note that "supports Cisco HDLC" means "supports dissecting
>Cisco HDLC frames, if they're being read from a capture file, in one of
>the formats Ethereal/Tethereal supports, with a link-layer type in the
>file that Ethereal can recognize as Cisco HDLC, and if the frames have
>been stripped of all their bit-stuffing and framing stuff".
 

That clarifies it – I thought that Tethereal took care of the bit-stuffing and frame delimiters, 01111110, for me.

I have a program that will cycle through the data and remove the “extra bits” due to bit stuffing and will also

remove the frame delimiters. 

 

 

 

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.

3)       Pipe it to Tethereal (and then into a file via the –w option)

 

I have #1 working (pretty much).  Is there anything available for #2?  I will certainly do what you were talking about

above, but figured I would ask so that I don’t re-invent the wheel and can move on to the next item in the project.

 

 

Again, thank you for answering my questions, I appreciate it.

 

Britt