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.
