OpenBSC January 2019

openbsc@lists.osmocom.org

25 participants
48 discussions

Problems installing libosmocore / gr-gsm on my Mac
by Andrea Pellegrin 22 Jan '19

22 Jan '19

Hi, I really hope you can help me, I’m trying this for 10h. I’m following your instruction: https://osmocom.org/projects/gr-gsm/wiki/Installation https://osmocom.org/projects/libosmocore/wiki/Libosmocore Installing gr-gsm I stay still at cmake .., for libosmocore (No package 'libosmocoding' found) So I try to install libosmocore, everything work up to make command. Infact give a lot of error, here: Air-di-Andrea:libosmocore andreapellegrin$ make /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in include /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am make[3]: Nothing to be done for `all-am'. Making all in src /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am CC timer_clockgettime.lo timer_clockgettime.c:78:7: error: use of undeclared identifier 'CLOCK_REALTIME_COARSE' case CLOCK_REALTIME_COARSE: ^ timer_clockgettime.c:82:7: error: use of undeclared identifier 'CLOCK_MONOTONIC_COARSE'; did you mean '_CLOCK_MONOTONIC_RAW'? case CLOCK_MONOTONIC_COARSE: ^~~~~~~~~~~~~~~~~~~~~~ _CLOCK_MONOTONIC_RAW /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h:158:1: note: '_CLOCK_MONOTONIC_RAW' declared here _CLOCK_MONOTONIC_RAW __CLOCK_AVAILABILITY = 4, ^ timer_clockgettime.c:86:7: error: use of undeclared identifier 'CLOCK_BOOTTIME'; did you mean '_CLOCK_REALTIME'? case CLOCK_BOOTTIME: ^~~~~~~~~~~~~~ _CLOCK_REALTIME /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h:153:1: note: '_CLOCK_REALTIME' declared here _CLOCK_REALTIME __CLOCK_AVAILABILITY = 0, ^ timer_clockgettime.c:86:7: error: duplicate case value '_CLOCK_REALTIME' case CLOCK_BOOTTIME: ^ timer_clockgettime.c:76:7: note: previous case defined here case CLOCK_REALTIME: ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h:154:24: note: expanded from macro 'CLOCK_REALTIME' #define CLOCK_REALTIME _CLOCK_REALTIME ^ timer_clockgettime.c:84:7: error: duplicate case value '_CLOCK_MONOTONIC_RAW' case CLOCK_MONOTONIC_RAW: ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/time.h:159:29: note: expanded from macro 'CLOCK_MONOTONIC_RAW' #define CLOCK_MONOTONIC_RAW _CLOCK_MONOTONIC_RAW ^ timer_clockgettime.c:82:7: note: previous case defined here case CLOCK_MONOTONIC_COARSE: ^ 5 errors generated. make[3]: *** [timer_clockgettime.lo] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Air-di-Andrea:libosmocore andreapellegrin$ I’m really desperate, hoping you can help me! Really thanks. Andrew

3 2

Scaling up virtual bts tests for the BTS test - how I hold it wrong?
by Holger Freyther 22 Jan '19

22 Jan '19

After a lot of work[1] the gsm tester can finally: * Start a virtual bts * Mobile/virtphy processes * Complete LUs for 10 MS. The next step (besides having a proper test verdict) is scaling this beyond what a simple physical set-up can provide. Let's go to 100+ BTS and 10k subscribers but somehow I am still holding it wrongly and would like to have feedback to see how to evolve the gsm tester. What do I need to change to scale this up and how to externally parameterize it? * suite.conf: Add one line per virtual bts to reserve (I would prefer to specify type+num) * resources.prod.conf: Add more Virtual BTS. I started to pick IPs from 127.0.1.0/24 as it avoids having to configure special IPs. * register_default_mass.py: I need to somehow know how many BTS (and NITBs) were reserved. Or in the long run the topology of how to connect M BTS to N BSCs? Currently I can run until I get an exception but that is not desirable. What's missing: * High-level API of the SuiteRun to get me the toplogy of the network. It seems undesirable in the specific suite to discover how many BTSs were reserved in suite.conf or what the topology is. * ARFCN usage. Besides the redundancy all my BTS currently have the same ARFCN. There should be an easy way to configure an band+arfcn pool. * IMSI/MSISDN pooling. I would like to specify pools of IMSI/MSISDN pairs (and size) and then draw from it. I needs these to program into the mobile, NITB/HLR/AuC and for client to client SMS transfers. * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change). Any idea or comment on how to achieve this? cheers holger [1] Hindsight is 20/20 and the difficulty was not adding scripting to mobile but getting the GSM tester to spawn the network and we are unfortunately not done yet.

2 5

tagging new versions / problems
by Harald Welte 21 Jan '19

21 Jan '19

Hi! I've been looking at tagging new versions of our libraries. I know Pau in the past already used the abi-{dumper,tracer,...} toolkit, but I couldn't find any instructions about it, nor has it been automatized it seems. I've now started with this and have a setup that we can run nightly to generate ABI/API compatibility reports. There are unfortunately some issues in libosmogsm: http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12… related to LCLS changes that (I believe) were mostly introduced by Max. gsm0808_cause_name() changes the size of the argumetn from uint8_t to an 'int' that may be 32/64bit in size :( That breaks ABI, so we need to bump soversion, or revert that change. As the gsup changes require a version bump anyway, we should be fine. gsm0808_create_lcls_conn_ctrl() has changed its argument type. Are we sure there were no users of the function? The old signature was part of the previous release! In libosmocore we have some problem related to 'struct log_target': http://people.osmocom.org/laforge/abi-report/compat_report/libosmocore/0.12… I suppose this is "only" ABI breakage but not API breakage and hence a new libversion can rescue us? In libgtp we also have changes requiring a libveersion change: http://people.osmocom.org/laforge/abi-report/compat_report/osmo-ggsn/1.2.2/… Apart from that, it looks quite fine. libosmo-sigtran has two new symbols, but remains fully backwwards compatible: http://people.osmocom.org/laforge/abi-report/compat_report/libosmo-sccp/0.1… Feel free to comment. The most important part is to get the libosmocore/LCLS questions resolved. 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 4

two general code review questions
by Neels Hofmeyr 18 Jan '19

18 Jan '19

Should we now put copyright comments in header files as well? re https://gerrit.osmocom.org/c/osmo-msc/+/11642/3/include/osmocom/msc/sgs_ifa… When I see structs containing talloc'd char*, should I generally give code review to use fixed char arrays instead? I think it ends up being simpler semantically as well as better in terms of mem allocation. Right? e.g. https://gerrit.osmocom.org/c/osmo-msc/+/11642/30/include/osmocom/msc/sgs_se… and #21 Thanks for your opinions... ~N

2 2

SMS sm_rp_mr set only when conn already established
by Neels Hofmeyr 18 Jan '19

18 Jan '19

Hi folks, just now while resolving some unrelated merge conflict, I notice this bit of code we have in osmo-msc master. (It has recently been tweaked, but the code in question has been like this for a long time.) https://git.osmocom.org/osmo-msc/tree/src/libmsc/gsm_04_11.c#n1057 static struct gsm_trans *gsm411_alloc_mt_trans(struct gsm_network *net, struct vlr_subscr *vsub) { struct ran_conn *conn; struct gsm_trans *trans; int tid; LOGP(DLSMS, LOGL_INFO, "Going to send a MT SMS\n"); /* Generate a new transaction ID */ tid = trans_assign_trans_id(net, vsub, GSM48_PDISC_SMS, 0); if (tid == -1) { LOGP(DLSMS, LOGL_ERROR, "No available transaction IDs\n"); return NULL; } /* Attempt to find an existing connection */ conn = connection_for_subscr(vsub); /* Allocate a new transaction */ trans = gsm411_trans_init(net, vsub, conn, tid); if (!trans) return NULL; if (conn) { <===== if no active communication, this is NULL /* Generate unique RP Message Reference */ trans->sms.sm_rp_mr = conn->next_rp_ref++; <===== here } /* Use SAPI 3 (see GSM 04.11, section 2.3) */ trans->dlci = UM_SAPI_SMS; return trans; } We often create an MT SMS transaction when no connection to the subscriber is currently available, which is the case if we create the SMS transaction and only page later. (To prove that, the call flow is gsm411_send_sms(vsub) trans = gsm411_alloc_mt_trans(vsub) gsm411_rp_sendmsg(trans) gsm411_smr_send() srdownstatelist[0] = gsm411_rl_data_req() gsm411_mn_send() gsm411_mm_send() gsm411_mmsms_est_req() trans->paging_request = subscr_request_conn(...) ) But we only assign an sm_rp_mr reference number when the conn is already present. That means when we send an SMS, the sm_rp_mr reference is unset when we still need to page first?? Does anyone know this code well? I'm almost certain we should always set an RP reference? (i.e. drop the 'if (conn)' condition) What errors could arise from this? It seems that we would always send an RP reference of zero for all SMS that require paging. Could that be a reason Rhizomatica sometimes saw SMS delivered to the wrong recipient? So, does anyone already know that I'm on the wrong track here -- otherwise I'll create an issue for this, probably also needing tests. ~N

2 2

Checking out LimeSDR Mini with osmocom. It seems good!!
by Gullik Webjorn 18 Jan '19

18 Jan '19

Tue 15-jan-2019 LimeSDR transmit check. Fired up old HP 8614A signal generator at 1880 Mhz, and let it stabilize for 1 hour. Level measurement after adjusting ALC, 0dBm = -0.4 dBm as checked with spectrum analyzer Checked level with HP L423A probe. Check of LimeSDR mini output. Output as seen on spectrum analyzer -1.0 dBm. This correlates with LMS7002 datasheet with a possible 1 dB loss between chip and analyzer, including SMA-BNC coax adapter, 2 m foam insulated RG58 size cable, BNC - N connector. So, for practical purposes the LimeSDR mini provides 0 dBm ( +/- 1.4 dBm ) LimeSDR receive check. Receive antenna rigged with a 1/10 dB splitter, -10 dB port connected to spectrum analyzer, -1 dB port to LimeSDR. Connect single Nokia Handset, and make a call from osmobsc to fixed phone, so that only one mobile is using TCH. Move phone to get different uplink levels and correlate these to spectrum analyzer. Since carrier is TDMA, use peak hold on analyzer. Active subscriber connections: conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 10 dBm, MS Power: 10 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 10 dBm, Timing Advance: 4 RXL-FULL-dl: -51 dBm, RXL-SUB-dl: -51 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -54 dBm, RXL-SUB-ul: -54 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Level on uplink -54 dBm, indicated on spectrum analyzer -53 (-63) dBm. OsmoBSC# show conn Active subscriber connections: conn ID=31, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 10 dBm, MS Power: 10 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 192.168.1.75 Port 16384 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4110 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 10 dBm, Timing Advance: 4 RXL-FULL-dl: -69 dBm, RXL-SUB-dl: -69 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -59 dBm, RXL-SUB-ul: -59 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Mobile moved to another location within the lab. Level on uplink -59 dBm, indicated on spectrum analyzer -60 (-70) dBm. Conclusion: For such a simple low cost SDR, the accuracy seems within a couple of dB. Instruments used were are not "professional grade", at least not w.r. 2019, but I estimate I can measure within +/- 2 dB or so with this crude config. Power output is 10 times lower than I expected, I was probably mislead by some review on the web, and had to go down to the actual scematic and datasheet to understand that the expected level should be around 0 dBm. (thanks for pointing this out, Harald) For practical use outside a lab output is far too low. My plan is to add a small simple booster to bring level up to +15 which would allow me to cover my 2 acre lot without breaking any rules. Else, I am impressed, good value for a low price tag. I had expected far worse than indicated accuracy. Best Regards, Gullik

2 2

Re: Re: Re: OsmoTRX - osmo-trx-usrp-1 Aborted :: Assertion 'px != 0' failed
by Sergey Mayzus 17 Jan '19

17 Jan '19

1 0

osmo-hlr db upgrade behavior poll
by Neels Hofmeyr 17 Jan '19

17 Jan '19

Hi all, when reviewing osmo-hlr db schema upgrades, I came up with the idea that we shouldn't upgrade automatically. That's why, for schema updates, osmo-hlr now refuses to start and requires one start with the --db-upgrade option. Our systemd service file does not include that option. The result is that after an upgraded osmo-hlr binary, admins may have to take extra action to upgrade the DB. The rationale is that if someone by accident launches a newer osmo-hlr only once, with automatic upgrade the user is then stuck with the newer version DB, since we don't make a backup and we don't provide a downgrade path. I'm now wondering whether that is really necessary. In the daily churn, it creates noise. How to make this less noisy? - Users could add the --db-upgrade option to the service file to always upgrade. (But it is cumbersome to have a .service file that differs from the installed version) - We could also add a cfg file option to allow-db-upgrades. - We could drop the behavior and always upgrade. In the lack of strong opinions, this will probably stay as it is. I'd just like to hear what you guys think about it. Is it annoying or a good idea? Thanks! ~N

4 4

default TA vty config for OSMO-PCU?
by Keith 16 Jan '19

16 Jan '19

Hey list.. so i want to do some experiments setting the default TA in the PCU to the distance from the tower to the main population centre, rather than have it set to 220 (invalid) So, this email is not about the details of that issue, rather just a quick question. In the interim while this gets finally done right, would we accept adding a default-timing-advance param to the vty config? Otherwise I can patch and compile version for each BTS, but the vty config would be WAY more handy! thnx k/

2 2

SMS Sender Name Using Alphanumeric Characters
by Ron 15 Jan '19

15 Jan '19

Hi Community, Is it possible to send SMS using alphanumeric characters as a sender address? We tried it using an Open-Source SMS GW and it can send alphanumeric information in the sender address. Unfortunately, the SMS sent through API was not received to the test phone and the logs below are seen in OSMO-MSC. <000c> smpp_smsc.c:729 [entropy] Rx SUBMIT-SM (09170000023/1/1) <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 259 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. <0017> sms_queue.c:155 Sending SMS 260 failed 0 times. We also tried sending SMS with only Numeric information in the sender address and the SMS was received successfully by the test phone. We can share the traces taken and the configurations used if needed. TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

3 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2019