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 <[email protected]> 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 <[email protected]> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)
>
>
