["Nisbet, Tom" <Tnisbet@xxxxxxxxxxxxxxxxxx>]

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