Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
-----Original Message-----
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.
|
- Follow-Ups:
- Re: [Ethereal-users] RE: Analyzing Cisco HDLC
- From: Guy Harris
- Re: [Ethereal-users] RE: Analyzing Cisco HDLC
- Prev by Date: Re: [Ethereal-users] t.38/ udptl decode discrepancy
- Next by Date: Re: [Ethereal-users] New Ethereal user
- Previous by thread: Re: [Ethereal-users] RE: Analyzing Cisco HDLC
- Next by thread: Re: [Ethereal-users] RE: Analyzing Cisco HDLC
- Index(es):