how to import raw binary file into wireshark

Sounds like an ISDN S/T interface trace of the LAPD protocol.

Or PPP in HDLC-like Framing?

See also, High-Level Data Link Control.

I was handling a similar scenario, extraction of LAPD from an E1 timeslot, and ended up extracting the PDUs and writing them in pcap or pcapng format. As I am a "non-dev", i.e. I don't speack C fluently and haven't rolled out the development environment necessary to write binary Wireshark plugins, I've used perl to code the whole thing, from reading from the E1 to generating the pcap(ng) stream.

As by then (and maybe until now?) Wireshark couldn't read pcapng from a pipe, I had to choose between the ability to run live capture and the ability to provide packet metadata (direction and L1 errors), so I've chosen the second.

Important points:

• HDLC normally doesn't have any field to indicate the application protocol it carries (Cisco HDLC is an exception), so you have to identify it yourself, and choose the right encapsulation type in order to properly plant the dissection tree. Look here for existing link types (encapsulations). If what you've caught is really PPP over HDLC, then LINKTYPE_PPP_WITH_DIR, LINKTYPE_C_HDLC_WITH_DIR may be your best candidates for pcap format, and their predecessors lacking the direction information for pcapng format where the direction is part of the metadata. If it is some proprietary packet encapsulation, you'll have to either write your own dissector to bridge the gap between the HDLC and the standards-macthing part of the frame data and use one of the USER link types to tell Wireshark that it should use that dissector, or extract only the standards-matching part of the frame and use the corresponding link type identifier.

• although HDLC allows not to use the bit-escaping of 11111 with 111110 if the carrier is byte-structured, some HDLC over structured E1 implementations don't make use of this option (namely, LAPD doesn't). It should be easy to tell: if you can see not only long series of 7E but also long series of FC and 3F in your byte stream, there is a good chance that the implementation uses the byte-structured carrier as a raw bit stream and you'll have to work with it the same way to be able to properly identify PDU borders.

thanks. it is LAPD and i see the long strings of 7E FC, and EF. i'll give it a try