OpenBSC

openbsc@lists.osmocom.org

13 participants
4278 discussions

New subscriber not created automatically with accept-all/subscriber-create-on-demand configuration
by Shaddi Hasan 27 Jul '16

27 Jul '16

Hi folks, I'm seeing some unexpected behavior from OsmoNITB. I am running from the Debian 8 nightly builds from July 25 for everything. My OpenBSC configuration is set as follows: network [...] auth policy accept-all [...] nitb subscriber-create-on-demand assign-tmsi [...] When a new phone tries to camp to the network, it's rejected as follows: https://gist.github.com/shaddi/7674680c329f14c0042fbeca5227962e ("Failed to find subscriber"). My full openbsc.cfg is in that gist as well. If I create the subscriber by IMSI via the VTY though, it camps fine and everything else works as expected. When I tested this this configuration a few weeks ago with an earlier build (sorry, can't recall which one), adding the subscriber manually wasn't necessary, and with the configuration above seems like it also shouldn't be necessary. Couple questions: - Is this the expected behavior for this configuration? - If so, is there currently a way to achieve the prior behavior (subscriber created automatically when a new phone tries to camp, rather than being rejected)? Thanks, Shaddi

2 2

HEADS UP: openbsc.git: force push on master
by Neels Hofmeyr 26 Jul '16

26 Jul '16

Today, gerrit has merged four of my changesets twice for some reason (even though they had the very same Change-Id), meaning that openbsc.git master got four empty commits. It could end up being a stupid thing to do, but I thought if at all then right now and no later: I forced master HEAD back so that we don't have empty commits in it, back to d1c0e3755f2832270a16bdb2d350463409cad887. I apologize in advance for any inconvenience caused. If you need help to recover from a diverged master branch, don't hesitate to ask! ~Neels -- - Neels Hofmeyr <nhofmeyr(a)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

1 1

NITB hangs if many subscribes and/or subsr. exists with empty extension in hlr
by Keith 26 Jul '16

26 Jul '16

Hi All, On one of our sites osmo-nitb was hanging a few seconds after startup. It took me a while to track it down, and I'm sorry I do not have log output as it has gone to scroll buffer heaven, and I do not want to break the system again right now to get another output, but I can say more or less what happens. If I see it again, I'll be sure to capture full debug log. I also have a backup of the state of the offending hlr, so I can bring it up locally and see if I can replicate and send the log. In fact, there was nothing out of the ordinary in the log anyway before nitb simply stops responding. (CTRL-C still shuts down cleanly if would seem) This 'bad' hlr has some 30,815 subscriber entries, one of them has empty string for extension. (We normally never get to anything near 30,000 as we purge inactive subscribers regularly, but the blank extension had broken our purge job) On this blank extension issue, i'm not sure it coincides with the hang, but I noted this error followed by DBI traceback from here: http://git.osmocom.org/openbsc/tree/openbsc/src/libmsc/db.c#n54 Error was non unique value for column extension, which makes sense of course, as we don't give it a value. Also seems we don't recover from this, as |db_subscriber_alloc_exten() will never be called? | I deleted some 28,000 subscriber entries that were not commissioned users, and the nitb then functions, so I'm at a loss to know where it might have been actually stuck, or if it might be related to the blank extension, or to the large amount of subscriber entries, or something else. Maybe it's obvious to somebody. I have of course deleted the blank extension entry now from the hlr. Thanks! Keith.

2 1

openbsc build broken due to new GSM_PCHAN value
by Neels Hofmeyr 25 Jul '16

25 Jul '16

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 "./ctrl_test_runner.py", 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 -- - Neels Hofmeyr <nhofmeyr(a)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

2 3

gerrit: permission to submit
by Neels Hofmeyr 25 Jul '16

25 Jul '16

I've added permission to submit a reviewed patch to the known users group, re: On Sun, Jul 24, 2016 at 04:08:35PM +0000, lynxis lazus wrote: > @Holger: I'm not allowed to do so on gerrit. On Mon, Jul 25, 2016 at 08:08:00AM +0000, Tom Tsou wrote: > Holger, Gerrit does not allow me to submit. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)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

1 0

Looking for trace with GPRS XID / SNDCP-CID messages
by Philipp Maier 25 Jul '16

25 Jul '16

Hi Folks, I am busy with implementing XID / SNDCP-XID parameter negotiation to use data and header compression with GPRS. It would be very helpful to have an example at hand that shows me how an SNDCP-XID is performed in real life. If someone of you has a GB-Interface trace at hand it would be very helpful for me. regards. Philipp

1 0

Re:Need Help In installing openBSC for establishing GSM network with EDGE support
by ayush gupta 23 Jul '16

23 Jul '16

Hello everyone, i am noob to this field and currently trying to establishing a GSM network with EDGE support using this page as guide http://openbsc.osmocom.org/trac/wiki/Ettus_USRP_B2xx_family#no1 i am stuck at this command sudo osmo-nitb -C -c openbsc.conf -T -P -m its giving me following error There is no such command. Error occurred during reading below line: extension-prefix 0 % 'dtx-used' is now deprecated: use dtx * configuration options of BTS instead Fri Jul 15 05:35:26 2016 <0005> bsc_init.c:492 Failed to parse the config file: '/home/ryker/openbsc.conf' any help would be highly appreciated thanks

5 4

TCH_H and TCH_F
by Neels Hofmeyr 22 Jul '16

22 Jul '16

I have this problem: DCC <0001> gsm_04_08.c:1649 Cannot patch through call with different channel types: local = TCH_F, remote = TCH_H (At first I thought it was a bug in dynamic TCH_F/TCH_H/PDCH, but it's actually about any situation where both TCH/H and TCH/F are available. Tested with master:) If I configure the BSC to have both TCH_H and TCH_F slots, my two test phones try to call each other with mismatching TCH types. The CHANNEL REQUIRED messages send TCH/H and TCH/F, respectively. phones: Samsung S4 vs. Sony Ericsson SE K800i. If the CN is configured with only TCH/H or only TCH/F, the two phones talk to each other fine. So is this a missing feature in openbsc? In this sense: If one side started off in TCH/H, the other side should be urged towards TCH/H as well. This breaks the dynamic TS feature #1776: with fully dynamic TS, we're implicitly allowing both TCH/H and TCH/F, so if an MS asks for a TCH/F, it will get one before even considering a TCH/H, even if that mismatches the MS peer. So we should fix openbsc to "clamp" the callee to the caller's pchan type. We could also offer a limited TCH/H_PDCH type (or some other config to disable TCH/F on dyn TS, for example). ~Neels -- - Neels Hofmeyr <nhofmeyr(a)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

1 1

Re: PDTCH and PTCCH activation
by Harald Welte 22 Jul '16

22 Jul '16

Hi Neels, [posting to the openbsc mailing list, as this discussion is not GPRS related] On Thu, Jul 21, 2016 at 12:25:25PM +0200, Neels Hofmeyr wrote: > On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote: > > It's called from lchan_act_compl_cb() via sapi_queue_send() which is > > also in mph_send_activate_req() - I have hard time understanding how > > this works at all. Do we have this documented somewhere? > > Both the TCH/F_TCH/H_PDCH timeslot feature and the TCH/F_PDCH on osmo-trx > are stuck on some post-lchan_act_compl SAPI stuff. can you be more specific about what "stuff"? It's hard to be of assistance without details. Also, SAPIs exist completely separately on every SAP, such as the (M)PH-SAP of the physical layer and the (M)DL-SAP of LAPDm, wich is implemented via RSL. So it is useful to explicitly state which SAP we are talking about when mentioning "SAPI stuff". > So, I would also benefit from better understanding the actions after > lchan_act. I actually think the L1 SAPI activation/deactivation is rather simple. You have the tables that list the SAPI+Direction combinations needed for every lchan type (what I just quoted for PDCH in my recent mail), and then the code iterates over the list of SAPI+Direction at time of lchan activation or deactivation. > Apparently related: libosmocore/gsm/lapd*.c How are the SAPIs of the data link layer should be related to SAPIs of the physical layer? LAPDm is establishing reliable channels over the already established physical layer, and LAPDm is not by iself activating/deactivating any channels, i.e. not talking to the MPH-SAP. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 5

range error in RSL_CHAN_SDCCH4_ACCH + lchan_nr?
by Neels Hofmeyr 20 Jul '16

20 Jul '16

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 ]]] -- - Neels Hofmeyr <nhofmeyr(a)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

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC