Wireshark-dev: Re: [Wireshark-dev] Hardware Platform to capture SS7 traffic on TDM lines to Dec
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.
