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@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@entry=0xb6d5b000) at ../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:540 #4 0x0000eb0c in mph_info_chan_confirm (lchan=0xb6d5b000, lchan@entry=0xb6d283c8, type=type@entry=PRIM_INFO_ACTIVATE, cause=cause@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@entry=0xb6d283c8, status=<optimized out>) at oml.c:729 #7 0x00010c2c in lchan_act_compl_cb (trx=<optimized out>, l1_msg=l1_msg@entry=0x4f850, data=<optimized out>) at oml.c:814 #8 0x0000da2c in l1if_handle_l1prim (wq=<optimized out>, fl1h=0xafdc0, msg=msg@entry=0x4f850) at l1_if.c:1037 ]]]
Hi Neels,
On Tue, Jul 19, 2016 at 02:03:51PM +0200, Neels Hofmeyr wrote:
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 */
As the comment says, it is our BTS-internal "hack" to actiwate the L1 SAPIs for the BCCH/CCCH.
The problem is bascially that 08.58 RSL specifies explicit activation for all the dedicated channels (SDCCH, TCH, ..) but doesn't specify any protocol-level activation for the common channels like CCCH.
In the BTS code, we have this data structure where we basically define a list of L1 SAPIs (and associated directions) to activate for a given lchan (type).
So the "logical" hack was to basically use the Combined BCCH lchan[4] (0...3 ar SDCCH, numbers 4 or higher are not used) to enable the common channel (PCH,AGCH,RACH, possibly CBCH, ...) at BTS start-up. Doing it this way means we only have one way of activating logical channels in the data model and in the code, rather than some special case code for the common channels, differing from the dedicated channels.
This should be safe within our bts/trx/ts/lchan data model, and purely internal to the BTS, and is nothing that ever is exposed to RSL.
<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
I see no issue here
<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
I see no issue here either.
<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
this is where it breaks. The introduction of the L1SAP interface uses RSL-style channel numbers in the primitive, and hence the assert.
However, no RSL message is ever to be generated out of this chan-act.confirm. If we do, it is a bug
Hope the above helps...
-
Harald Welte -
Neels Hofmeyr