openbsc build broken due to new GSM_PCHAN value

Neels Hofmeyr nhofmeyr at
Sun Jul 24 11:11:33 UTC 2016

Just to let you know, the addition of GSM_PCHAN_TCH_F_TCH_H_PDCH in libosmocore
implicitly broke the ctrl interface tests in openbsc.

FAIL: testBtsChannelLoad (__main__.TestCtrlBSC)
Traceback (most recent call last):
  File "./", line 237, in testBtsChannelLoad
    self.assertEquals(r['value'], 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0')
AssertionError: 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0 unknown 0xb,0,0' != 'CCCH+SDCCH4,0,0 TCH/F,0,0 TCH/H,0,0 SDCCH8,0,0 TCH/F_PDCH,0,0 CCCH+SDCCH4+CBCH,0,0 SDCCH8+CBCH,0,0'

because this is unexpected output: "unknown 0xb,0,0"

So *any* commit submitted to openbsc will currenty fail.
I'll probably fix it shortly with a commit to openbsc...

This also directed my attention towards the pchan_load mechanics. It always
shows a TCH/F_PDCH entry, but in PDCH mode those would not have any load. I
guess it makes sense in the current scheme of things, though it could make even
more sense to record channel load not as separate TCH/F_PDCH but in the TCH/F
slot, depending on current pchan mode?  Similarly for upcoming
TCH/F_TCH/H_PDCH: record in the TCH/F or TCH/H slot according to current pchan
mode...  (For now I'm focusing on completion of TCH/F_TCH/H_PDCH usability, if
at all pchan_load tweaks would come later)


- Neels Hofmeyr <nhofmeyr at>
* 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: <>

More information about the OpenBSC mailing list