| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: I6d4efa6ddef41607aecd5ceee78e400db821292f
|
|
Change-Id: I9b11fbe3bf85b7096a3bd5f9b67168350e66a90a
|
|
Change-Id: I322e8857990f77246bcf4dbc0510f4b42527dc82
|
|
This reflects what happens in libosmo-abis during 'show e1'
and makes sure we don't attempt to write for more TS than exist
(e.g. in the T1 case).
Change-Id: Iaeac2d080ae3ddc27901cbc4be5220100e9820a8
|
|
We have to check if g_pcap_fd is >= 0,as we initialize it to -1.
Change-Id: I458c02b4619b6fb2c7d30b1ce3bbac86243a6977
|
|
Change-Id: I79d9e12ef723841db186cd122da4dadb3f7d3969
|
|
Change-Id: Id9adf8d444013272a461bd5f4dbe64a5d0b373b4
|
|
Change-Id: I705b5356309507c39eaf517ca5b9ce0e1aa89852
|
|
Change-Id: I65a862132563f578eff11b8d085960b820f5d4b7
|
|
storage.c:90:7: error: implicit declaration of function ‘writev’; did you mean ‘write’? [-Werror=implicit-function-declaration]
90 | rc = writev(g_out_fd, iov, ARRAY_SIZE(iov));
| ^~~~~~
| write
Change-Id: If98737199f5a6e8fb37a4fd6403ee973dcf70612
|
|
We can now write a PCAP file from the HDLC-decoded super channel.
|
|
... and some more comments/documentation
|
|
Finally the bit ordering and bit format of the SuperChannel has been
figured out.
* the data as read from DAHDI must be flipped (0->1 / 1->0). why?
* the data must be read lsb-first when converting into a bit-buffer
We are now getting the following output e.g. for a OM2000 "TX
Configuration Request" message:
fa 03 8a 8a 80 80 00 13 00 b0 0b 00 ff 01 20 00 2e 2b 1c 00 06 01 95 81 76 00 e9 bf
^ lapd hdr ^ OML ^l ^OM2000 TX Config Req for 43 dBm
|
|
* remove the notion of states, as there is really only one state
* implement zero removal / bit stuffing for synchronous links
|
|
|
|
|
|
|
|
In the super channel mode, it seems the BTS transmits one byte in each
timeslot, accross the entire link.
This basically means that if you have a 10 byte long signalling message
to be sent, its first byte will be in TS1 up until the tenth byte in
TS10.
As we are reading in 160 byte chunks from the E1 timeslots, we build a
matrix with 160 columns (for each byte) and 24/30 rows (timeslots). So
we write 24 times 160 bytes into the matrix.
Once we have completed all timeslots, we start to read the matrix by
reading byte 0 of each timeslot (in incrementing TS order), next byte 1
of each timeslot, ... until we end up having read 160 times 24 bytes
from the matrix.
The resulting bitstream needs to be HDLC-synchronized and the resulting
messages passed up for further decoding.
|
|
|
|
open file
|
|
|
|
The SIGN mode implies that LAPD instances are bound to the timeslots, which is
of course not what we want in a pure capturing/recording scenario.
Instead, use the new E1INP_TS_TYPE_HDLC mode, which allows us to capture
any HDLC framed messages on E1/T1 timeslots, whether LAPD or e.g. MTP.
|
|
We can now filter a given 16k sub-slot out of the capture data and
export it to stdout.
|
|
output
|
|
|
|
|
|
|
|
This was a stupid mistake when writing the header initially, let's try
to fix it while staying binary compatible.
|
|
|
|
|
|
|
|
|
|
|
