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

Wireshark-dev: Re: [Wireshark-dev] Hardware Platform to capture SS7 traffic on TDM lines to Dec

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 03 Sep 2007 02:14:03 -0700
Varuna De Silva wrote:

Dear friends I am new to the Wireshark community as a developer. As our final year project we will be developing a SS7 protocol Analyzer. Here we will be developing the Hardware Circuitry to tap a physical E1 line. We have used Dallas Maxim E1/DS1 ICs are being used to capture the raw data and those data will be ported in to a machine using a USB IC from FTDI.

We hope to analyze the raw data we capture through WireShark. The data we capture is in the memory and we can access them via a custom API. We hope to insert these data in to pseudo
UDP or TCP packets and analyze through WireShark.

You don't need to do that. Wireshark can analyze "raw" SS7 packets, for a suitable definition of "raw".

To capture SS7 traffic, modify libpcap to handle your hardware. See, for example, pcap-linux.c's pcap_open_live() routine, where the code at the beginning of the routine checks whether the name of the capture device being opened contains the string "dag" and, if so, calls the open routine for an Endace DAG card, or contains the string "septel" and, if so, calls the open routine for a Septel card, and check pcap-dag.c and pcap-septel.c, which contain code to open DAG or Septel cards and capture various forms of traffic from the DAG card, including MTP2 traffic, or capture MTP2 traffic from the Septel card.

Also we want to know what is the starting point of dissecting the SS7 stack in the WireShark source. We went through the dissectors included in epan especially mtp2.c and there onwards up the stack but our impression is that for our purpose we cant start at mtp2.c since we dont see the Frame Alignment Word of SS7 ' 01111110 ' being handled there, subsequent decoding.

Wireshark dissects frames, not bit streams. It assumes that the capture file it's reading contains records corresponding to frames.

Therefore, it assumes that the frame delimiters, and any bit/byte stuffing, have already been removed from any protocol that uses HDLC framing.

In particular, the MTP2 dissector expects an MTP2 frame *without* the frame delimiters, just as it expects, for example, PPP frames without the frame delimiters.