Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] LAPD decode problem

From: "Harvey, James B." <Jim.Harvey@xxxxxxxxxxx>
Date: Wed, 22 Jul 2009 08:00:26 -0500
From: wireshark-users-bounces@xxxxxxxxxxxxx [wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris [guy@xxxxxxxxxxxx]
Sent: Tuesday, July 21, 2009 6:58 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] LAPD decode problem

On Jul 20, 2009, at 12:32 PM, Harvey, James B. wrote:

> AFIK, Agilent did not document their file formats.  I attached a Zip
> file with a capture, a print of the capture and a picture of the
> stack, it's the one in the middle. This capture was saved with only
> data.

I'll see what I can figure out from that.
Do you have any other Agilent captures, especially from other types of
network?  That would make reverse engineering easier.

**   I have some PPP captures.  I will send to you directly.  These packets use TCP/IP over PPP over HDLC and the J2300 doesn't handle that very well either.

> This is not ISDN, it is a SONET DCC channel.

But it's still using LAPD on that channel, as per, for example:
        http://www.opencon.com/dcc/details.htm
(so what does the Troubled Assets Relief Program have to do with
that? :-))?

**   Yes it is. That's a good diagram.  Our machines implement most of it, except for X.25.  We use Marben http://www.marben-products.com/osiam/stack_foundation.html.  The TARP part is the one thing I DON"T have a problem with. You'd think the government would send a check.

> I didn't use any -l option in the text2pcap.

To quote the text2pcap man page, and to emphasize the relevant point:
        −l  Specify the link‐layer type of this packet. Default is
Ethernet
^^^^^^^^^^^^^^^^^^^

If you don't use any -l option, the file will be an Ethernet pcap
file, so Wireshark will interpret the packet data as an Ethernet packet.

> Do you have a suggestion?

There isn't any "raw LAPD" link-layer value, so there's no standard
DLT value to use.

You might, however, try one of the "user DLT" values (147 through
162), and tell Wireshark to dissect that value with the "lapd"
dissector.

** I will experiment with that.  Is there a way to tell Wireshark to start decoding at a fixed byte offset so I could just skip the LAPD header?  We had a real Network General Sniffer in here and it wouldn't do the decode any better than the Advisor.  Their support people came up with a skip 4 bytes hack as a work around.  I tried to do this indirectly in the TCL script I use to hexify the Agilent print file but did not have much luck.

> The only LAPD I see in bpf.h is type 177

That's DLT_LINUX_LAPD; to quote the comment
so it won't work for normal raw LAPD.

> and Wireshark won't even load a file converted with that.

You must have an old version of Wireshark - current versions should be
able to read that.

** Using 1.2 and it didn't. I would guess the Linux DLT has more or fewer bytes so the conversion resulted in a garbage header.
___________________________________________________________________________

Jim Harvey

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================