One thing I noticed in your sample program is the size of the frame
you're sending to DAHDI. Try adding 2 to the size parameter when you
write() on the device (assuming you're still using dahdi HDLC).
Also, you must append 2 empty bytes to the frame you write down to the
DAHDI dchan as a placeholder for the CRC.
So change:
-const uint8_t sabme_frame_nonraw[] = { 0xFA, 0x7D, 0x7F };
to:
+const uint8_t sabme_frame_nonraw[] = { 0xFA, 0x7D, 0x7F, 0x00, 0x00 };
And that should take care of both things I mentioned above.
Be warned though, a DAHDI channel set to be a "dchan" will send HDLC
idle bit patterns when no data is sent (0x7e) on it. This means that
if you need to send 0xff or 0xaa or some pattern like you posted
above, you will need to use custom HDLC code, or modify the DAHDI hdlc
code to send your required idle pattern.
Matthew Fredrickson
On Tue, Feb 8, 2011 at 5:19 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi all,
I've connected my 6113 to a DAHDI card in raw mode and sampled the
data, it can be found (together with some tools) in osmo-rbs.git
on
git.osmocom.org
To me, it seems as if it simply sending a continuous sequence of SABM
commands for TEI=62/SAPI=62 on timeslot 1, interspaced with idle pattern
of FLAG bytes.
However, if I attempt to send this sequence (using dslot=1, i.e. the HDLC
support within DAHDI) and the rbs_sabm.c program on /dev/dahdi/1), there is no
response from the RBS.
On all other timeslots, the 6113 will just produce a default pattern of
alternating 0 and 1 bits (0xAAAAAAA).
We still must be doing something wrong here...
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)