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.
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? :-))?
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
^^^^^^^^^^^^^^^^^^^
(1). See net/bpf.h for the complete list of possible
encapsulations. Note that this option should be used if
your dump
is a complete hex dump of an encapsulated packet and you
wish to
specify the exact type of encapsulation. Example: −l 7
for ARCNet
packets.
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.
The only LAPD I see in bpf.h is type 177
That's DLT_LINUX_LAPD; to quote the comment
/*
* Requested by Daniele Orlandi <daniele@xxxxxxxxxxx> for raw LAPD
* for vISDN (http://www.orlandi.com/visdn/). Its link-layer header
* includes additional information before the LAPD header, so it's
* not necessarily a generic LAPD header.
*/
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.
