range error in RSL_CHAN_SDCCH4_ACCH + lchan_nr?

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Tue Jul 19 12:03:51 UTC 2016


Yesterday I came across gsm_ts2chan_nr() in openbsc gsm_data_shared.c
(which is used both in openbsc and osmo-bts).

IIUC this case would expect lchan_nr to be in the range 0..3:

        case GSM_PCHAN_CCCH_SDCCH4:
        case GSM_PCHAN_CCCH_SDCCH4_CBCH:
                cbits = 0x04;
                cbits += lchan_nr;
                break;

Because if we'd add 4 or more, we would be walking into this cbits space:

        case GSM_PCHAN_SDCCH8_SACCH8C:
        case GSM_PCHAN_SDCCH8_SACCH8C_CBCH:
                cbits = 0x08;
                cbits += lchan_nr;
                break; 

The thing is, I added an assert for lchan_nr < 4, and it hits. We're
actually passing lchan_nr == 4 and thus use cbits = 0x08 for a
GSM_PCHAN_CCCH_SDCCH4: wrong.

This code in osmo-bts-*/oml.c:opstart_compl() activates lchan[4] of a
CCCH+SDCCH4 ts:

        /* ugly hack to auto-activate all SAPIs for the BCCH/CCCH on TS0 */
        if (mo->obj_class == NM_OC_CHANNEL && mo->obj_inst.trx_nr == 0 &&
            mo->obj_inst.ts_nr == 0) {
                struct gsm_lchan *cbch = gsm_bts_get_cbch(mo->bts);
                DEBUGP(DL1C, "====> trying to activate lchans of BCCH\n");
                mo->bts->c0->ts[0].lchan[4].rel_act_kind = LCHAN_REL_ACT_OML;
                lchan_activate(&mo->bts->c0->ts[0].lchan[4]);
                if (cbch) {
                        cbch->rel_act_kind = LCHAN_REL_ACT_OML;
                        lchan_activate(cbch);
                }
        }

This [4] the first SDCCH4, because this has CCCH in the first [0..3], right?
But then we should use lchan->nr - 4 to add to the cbits, right?

It seems pretty much everyone, our code and various BTS models, are ignoring
the erratic cbits, but would be good to fix.

My SysmoBTS GSM cell still works if I pass cbits = 0x04 instead of 0x08, like
this:

        case GSM_PCHAN_CCCH_SDCCH4:
        case GSM_PCHAN_CCCH_SDCCH4_CBCH:
                /* SDCCH4 is in lchan_nr 4..7, so subtract 4 before adding to
                 * the cbits. */
                if (lchan_nr >= 4)
                        lchan_nr -= 4;
                OSMO_ASSERT(lchan_nr < 4);
                cbits = 0x04;
                cbits += lchan_nr;

However, I guess passing 0x04 cbits for a CCCH lchan is wrong as well (0x04 is
RSL_CHAN_SDCCH4_ACCH). Instead, we should pass RSL_CHAN_RACH (Uplink CCCH) or
RSL_CHAN_PCH_AGCH (Downlink CCCH), right? How to decide which of the two?

Thanks for any hints,
~Neels


[[[
[...]
<0001> oml.c:830 OC=CHANNEL(03) INST=(00,00,00) Rx OPSTART
<0006> oml.c:500 (bts=0,trx=0,ts=0,ss=0) pchan=CCCH+SDCCH4 ts_connect_as(CCCH+SDCCH4) logChComb=4

  ^ SDCCH4

<0007> l1_if.c:164 Tx L1 prim MPH-CONNECT.req
<0001> oml.c:249 OC=CHANNEL INST=(00,00,00) AVAIL STATE Dependency -> OK
<0001> oml.c:256 OC=CHANNEL INST=(00,00,00) OPER STATE Disabled -> Enabled
<0001> oml.c:217 OC=CHANNEL INST=(00,00,00) Tx STATE CHG REP
<0006> oml.c:285 ====> trying to activate lchans of BCCH
<0006> lchan.c:31 (bts=0,trx=0,ts=0,ss=4) state NONE -> ACTIVATION REQUESTED

  ^ ss=4 means lchan->nr=4

<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, FCCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (FCCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI FCCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, SCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (SCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI SCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, BCCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (BCCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI BCCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, AGCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (AGCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI AGCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, PCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (PCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI PCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, RACH RxUL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (RACH RxUL)
<0006> oml.c:783 Successful activation of L1 SAPI RACH on TS 0
<0006> lchan.c:31 (bts=0,trx=0,ts=0,ss=4) state ACTIVATION REQUESTED -> ACTIVE
Assert failed lchan_nr < 4 gsm_data_shared.c:518

  ^ from mph_info_chan_confirm(), lchan_nr == 4

(gdb) bt
#0  0x47d47208 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x47d4ad8c in __GI_abort () at abort.c:89
#2  0x000186e4 in gsm_ts2chan_nr (ts=<optimized out>, lchan_nr=<optimized out>) at ../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:518
#3  0x00018710 in gsm_lchan2chan_nr (lchan=lchan at entry=0xb6d5b000) at ../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:540
#4  0x0000eb0c in mph_info_chan_confirm (lchan=0xb6d5b000, lchan at entry=0xb6d283c8, type=type at entry=PRIM_INFO_ACTIVATE, cause=cause at entry=0 '\000') at oml.c:56
#5  0x00010730 in sapi_activate_cb (lchan=0xb6d283c8, status=0) at oml.c:1080
#6  0x000108d4 in sapi_queue_dispatch (lchan=0x1, lchan at entry=0xb6d283c8, status=<optimized out>) at oml.c:729
#7  0x00010c2c in lchan_act_compl_cb (trx=<optimized out>, l1_msg=l1_msg at entry=0x4f850, data=<optimized out>) at oml.c:814
#8  0x0000da2c in l1if_handle_l1prim (wq=<optimized out>, fl1h=0xafdc0, msg=msg at entry=0x4f850) at l1_if.c:1037
]]]

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160719/8e88a4ac/attachment.bin>


More information about the OpenBSC mailing list