Re: Capturing stream protocols

[Guy Harris <guy () alum mit edu>]

On Jan 15, 2010, at 12:30 AM, Justas Poderys wrote:

> //Sorry if this is a duplicate

It's not a duplicate, the *other* one is. :-)  (So it sounds as if your messages were delivered out-of-order.)

> What I am doing is a device for capturing data from Common Channel
> Signaling link in E1/T1 systems. I can extract each byte from a CCS
> channel in each frame.
> <...>
> Then I can use Wireshark for decoding actual data. I am lost in between
> extraction of CCS data and forming libpcap format packets for Wireshark
> to decode.

The impression I have is that Common Channel Signaling is a general term that can refer to several different types of 
signaling, such as Signaling System 7 and...

> Is there a library or something, that can do it for me, so I won't have
> to reinvent the wheel? I am using traces in pcap format from a
> commercial E1 board as an example, and I can clearly see where raw data
> is put in the packet. What troubles me, is how to know how many bytes of
> raw data is to be put in each packet?
>
> Another solution I can think of is to wait for first RR byte and dump it
> into a packet with single byte. Then to dump everything traveling same
> direction into another pcap packet, until I see another RR. Maybe
> someone with an experience in LAPD can comment this approach?

...ISDN.  (Well, that's what the Wikipedia article says, at least.)

In the case of ISDN, the impression I have is that LAPD uses HDLC-style framing, so that what goes over the particular 
bit stream on the particular T1/E1/BRI/whatever channel is broken up into packets by frame sequences; to quote Q.921:

        2.2     Flag sequence

        All frames shall start and end with the flag sequence consisting of one 0 bit followed by six contiguous 1 bits 
and one 0 bit. The flag preceding the address field is defined as the opening flag. The flag following the Frame Check 
Sequence (FCS) field is defined as the closing flag. The closing flag may also serve as the opening flag of the next 
frame, in some applications. However, all receivers must be able to accommodate receipt of one or more consecutive 
flags. See ISDN User-Network Interfaces: Layer 1 Recommendations I.430 [5] and I.431 [6] for applicability.

and any time you would get 5 1 bits in sequence in a packet *other* than in a flag byte, a 0 bit is inserted into the 
bit stream: 

        2.6     Transparency

        A transmitting data link layer entity shall examine the frame content between the opening and closing flag 
sequences, (address, control, information and FCS fields) and shall insert a 0 bit after all sequences of five 
contiguous 1 bits (including the last five bits of the FCS) to ensure that a flag or an abort sequence is not simulated 
within the frame. A receiving data link layer entity shall examine the frame contents between the opening and closing 
flag sequences and shall discard any 0 bit which directly follows five contiguous 1 bits.

So your device, or the software driving it, should break the bit sequence on the CCS link into frames, by looking for 
flag sequences, and should put each frame's contents, *without* the flag sequences, into a single packet.  While it's 
extracting bits from the bit sequence into a packet, it should, if it sees 5 1 bits in sequence followed by a 0 bit, 
ignore the 0 bit.

I don't know how much of that work the hardware in your device can do; there might be software available (free or 
commercial) to do the remaining part.

For SS7, MTP3, according to Q.703, uses the same HDLC-style framing.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.