- OpenBSC - lists.osmocom.org

libosmocore / rate_ctr / osmo_fsm / invalid identifiers
by Harald Welte 25 Oct '17

25 Oct '17

Dear Osmocom comunity, after my patches being in gerrit since October 3 without getting any significant review comments, I decided to rebase+merge the code to enforce correct "identifiers" for entnties like rate_ctr or osmo_fsm which get registered to libosmocore and which are subsequently automatically exported via CTRL. A valid identifier is from now on known as any 7-bit ASCII string excluding characters from the following set: :., {}[]()<>|~\\^`'\"?=;/+*&%$#! This has caused some (not entirely unexpected) breakage in osmo-bts.git and osmo-bsc.git and is the cause of a couple of "red" Jenkins builds for those projects. I've quickly followed-up with patches for those two repositories to make sure other people/patches don't suffer from fall-out. What's important to note from now on and in the future: * don't use any string identifiers that violate osmo_identifier_valid() * check the return value of calls like osmo_fsm_register() as they may fail if your identifiers are incorrect * use ':' as separator in rate_ctr_group or rate_ctr names. Any existing '.' will be transparently converted to ':' for compatibility reasons. * if you find other sub-systems in the libosmo* universe that use string identifiers for certain objects, let's try to introduce calls to osmo_identifier_valid() in all of their registration paths to ensure that we could later on add automatic export of such objects to CTRL or other interfaces without having to change the name at that point. Things that come to my mind are e.g. * SCCP global titles and AS/ASP names in libosmo-sigtran * SMPP ESME names in osmo-{msc,nitb} Patches welcome! Regards, Harald -- - Harald Welte <hwelte(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

2 2

Problem running osmoBTS with BladeRF
by Anindya Sankar Roy 24 Oct '17

24 Oct '17

Hello all, I am getting the following error and osmocom-bts-virtual just closes giving following error. bts.c:208 Shutting down BTS 0, Reason Abis close <0006> bts_model.c:161 Unimplemented bts_model_trx_deact_rf <0006> bts_model.c:55 Unimplemented bts_model_trx_close Please help Thanks Anindya

1 0

Re: layer23/mobile: VTY is broken
by Harald Welte 23 Oct '17

23 Oct '17

Hi Neels, On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote: > Ah, damn. I checked all of the repositories I know to use the VTY, I didn't > imagine that OsmocomBB also has a VTY. That's really my fault then. I think in general we should not fall into that trap. We have *no clue* at all who might be using libosmo* for whatever purpose. If we provide a libary with a given API/ABI, then it's our responsibility to keep that ABI/API as stable as possible. I understand that it was hardly possible without fall-out in that particular case, and for sure there are exceptions. However, completely unrelated to this particular topic (and hence the Cc to openbsc@) I'm not happy in general with the way how "carlessly" we sometimes introduce breakage. We have to be more disciplined in general on this. All of us. BTW: The fact that this change has gone into master without being noticed also means that possibly we're not modelling osmocom-bb as a downstream user of libosmocore that needs to be rebuilt (and at least checked if it starts up correctly?) whenever testing a libosmocore change. That's also something to investigate. Maybe there's some way we can test this without too much effort. Regards, Harald -- - 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)

3 2

Re: [MERGED] libosmocore[master]: Cleanup jenkins build scripts
by Neels Hofmeyr 23 Oct '17

23 Oct '17

This patch was merged, but I frankly don't like what it does. Building in a separate dir is fine, but it does so with a bunch of changes along that introduce indenting errors and potentially destroy the scripts' certainty of building cleanly every time. Please still reply to my comments at https://gerrit.osmocom.org/#/c/3132/ ...maybe actually here on the ML instead of on gerrit? Thanks! ~N

2 1

Re: Build failure of network:osmocom:nightly/libosmocore in xUbuntu_16.04/i586
by Neels Hofmeyr 23 Oct '17

23 Oct '17

On Sat, Oct 21, 2017 at 07:55:00PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… > > Package network:osmocom:nightly/libosmocore failed to build in xUbuntu_16.04/i586 The failure is [ 235s] +/usr/src/packages/BUILD/tests/testsuite.dir/at-groups/9/test-source: line 25: 32555 Illegal instruction $abs_top_builddir/tests/conv/conv_gsm0503_test Seems our cpu feature selection isn't working on that particular build host. Should we investigate or just hope to hit another build host next time? ~N

2 1

some current patches blocking others
by Neels Hofmeyr 23 Oct '17

23 Oct '17

Would like to mention, since it's hard to see the sequence of patches in gerrit. I have a series of osmo-hlr patches ready for commit, but others preceding them still need review: https://gerrit.osmocom.org/#/c/4305/ https://gerrit.osmocom.org/#/c/4273/ https://gerrit.osmocom.org/#/c/4275/ ...whenever you get a chance is fine, thx! ~N

1 0

libversion update question
by Max 21 Oct '17

21 Oct '17

Hi. When we're making new library release we got to make sure that the API/ABI versions are properly updated by correctly setting *_LIBVERSION which has 3 components: current[:revision[:age]]. That's documented in https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info… The rules are as follows: 1. If the library source code has changed at all since the last update, r++; 2. If any interfaces have been added, removed, or changed since the last update, c++, r=0; 3. If any interfaces have been added since the last public release, a++; 4. If any interfaces have been removed or changed since the last public release, a=0. What's not clear to me is how those rules should be used. Do we apply them sequentially? For example, I've added function lol_what() to public API of my library with previous LIBVERSION=3:2:1 and would like to compute new LIBVERSION properly. According to rule #1 I've got to update revision: 3:3:1 According to rule #2 I've got to update current and reset revision: 4:0:1 The rules are conflicting so let's assume latest rule wins and apply further rules: According to rule #3 I've got to increase age: 4:0:2 So far so good but do correct me if I'm misunderstanding it. Now LIBVERSION=4:0:2 is released, I've removed lol_what() and added foobar() functions. Let's bump the LIBVERSION: #1: 4:1:2 #2: 5:0:2 #3: 5:0:3 #4: 5:0:0 Am I interpreting this right? We only increase revision if no interfaces have been added, removed, or changed since the last update? This means that "current" and "revision" increments are mutually exclusive. -- Max Suraev <msuraev(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

2 1

osmo-bsc and msc connection
by gsm sim 20 Oct '17

20 Oct '17

Hello everyone, we are struggling to set up an 2G network using single bsc and msc components rather than osmo-nitb. We successfully managed to run an 2G-Network with osmo-nitb using an usrp-n210 as trx. Now how is the BSC supposed to connect to the MSC? In an older build of the osmo-bsc and like described in the osmo-msc user manual I was able to setup an cs7 instance using the m3ua via osmo-stp to the msc. But as I'm using the nighlty-packages now there is no longer a way to configure cs7 instances in the BSC and since we are completely new to this project we aren't up to date with all the recent changes. Apologizes for that. We're also struggling to build the osmo-bsc sources. It quits with "bsc_vty.c:313:5: error: implicit declaration of function ‘OSMO_SEC2DAY’". So I guess there is a package missing but I couldn't find out which one it is. TIA Best regards, Ralf

4 5

RE: Location Update Error
by Sudhanthiradasan R 20 Oct '17

20 Oct '17

Hi, I have even tried authorizing imsi via sql. I could able to authorize by following https://osmocom.org/projects/osmonitb/wiki/OsmoNITB and it lists the extension number, exactly what I have assigned. But the error still persists. Issues listed below is similar to what I'm facing but is there any solution for this? http://lists.osmocom.org/pipermail/openbsc/2012-February/004695.html https://osmocom.org/issues/1648#note-19 Thanks, Sudhanthiradasan R From: Sudhanthiradasan R Sent: Monday, October 16, 2017 6:28 PM To: openbsc(a)lists.osmocom.org Subject: Location Update Error Hello, I'm getting below error, when I ran "/usr/local/osmo_built/bin/osmo-nitb -c ./../osmo_cfg/osmo-nitb_2trx.cfg -l ./../osmo_cfg/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM" <0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0000> gsm_04_08.c:3960 Dispatching 04.08 message, pdisc=5 <0002> gsm_04_08.c:1389 LOCATION UPDATING REQUEST: MI(IMSI)=901550000001016 type=NORMAL <0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x18 to MS. <0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ERROR INDICATION <0000> abis_rsl.c:1954 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION cause=SABM frame with information not allowed in this state in state=ACTIVE <0002> gsm_04_08.c:596 Location Updating Request procedure timedout. <0002> gsm_04_08.c:474 Subscriber 901550000001016: <0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x04 to MS. Anyone had the same issue earlier? Is there any solution for this error? Thanks, Sudhanthiradasan R ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------

1 0

OSMO UMTS
by robert 18 Oct '17

18 Oct '17

Hi, Can a UMTS network be implemented using what is already available from OSMO projects ?

2 5