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