OpenBSC July 2017

openbsc@lists.osmocom.org

24 participants
44 discussions

osmo-bts-trx fails frequently on osmo-gsm-tester
by Neels Hofmeyr 10 Oct '17

10 Oct '17

We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. I have run a tcpdump on the ntp port for the past days, and nothing is doing ntp besides the actual ntp service. Today I started ntp while an osmo-bts-trx run was active and what do you know, the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx shouldn't use wall clock time for precise timing needs. Besides that, I have no idea what could cause the clock skews, except maybe that the CPU or the USB are not fast enough?? I'm wondering, is there still such a thing as a separate linux realtime kernel? We will soon take to productive use another main unit which will be a cleanly installed OS. If we see the same problems on that system and can't find a software fix, we may need to reconsider the tester for osmo-bts-trx... ~N

8 26

catch-22 VTY error
by Neels Hofmeyr 07 Sep '17

07 Sep '17

I'd like to share a VTY config error analysis that has a tricky solution: I started osmo-bsc -c osmo-bsc.cfg with, according to openbsc/doc/examples/osmo-bsc: net [...] bts 0 [...] periodic location update 30 trx 0 [...] and get this error: There is no such command. Error occurred during reading below line: trx 0 what? 'net / bts / trx' is no command?? Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on this branch, I've actually moved the 'periodic location update N' command a level up, from net / bts / periodic to net / periodic (background: assuming that OsmoMSC does not have individual BTS info, we moved some settings up to network level; whether this makes sense for osmo-bsc is a different question, it's just what happens to be on the vlr_3G branch now). So there is no net / bts / periodic command. Why do I get an error for net / bts / trx instead? two reasons: 1. 'trx 0' was the line following the 'periodic' command, 2. since 'periodic' exists one level above, the vty code goes to the parent node automatically. About 2: we tend to indent our VTY config files, but in fact the indentation has no effect whatsoever, it is just eye candy (very useful eye candy). The code in question: If a command does not exist, try 'vty_go_parent()' and see if the command exists there. That's what allows us to omit 'exit' in our config files to go to the parent node explicitly: libosmocore/src/vty/command.c: int config_from_file(struct vty *vty, FILE * fp) { int ret; vector vline; while (fgets(vty->buf, VTY_BUFSIZ, fp)) { vline = cmd_make_strvec(vty->buf); /* In case of comment line */ if (vline == NULL) continue; /* Execute configuration command : this is strict match */ ret = cmd_execute_command_strict(vline, vty, NULL); /* Try again with setting node to CONFIG_NODE */ while (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO && is_config_child(vty)) { HERE -----> vty_go_parent(vty); ret = cmd_execute_command_strict(vline, vty, NULL); } cmd_free_strvec(vline); if (ret != CMD_SUCCESS && ret != CMD_WARNING && ret != CMD_ERR_NOTHING_TODO) return ret; } return CMD_SUCCESS; } In this case the 'periodic...' command does in fact now exist one level above, so the vty_go_parent() is successful and running that command works. But, the vty config parsing then sits above on the 'network' level, is no longer in 'bts 0' and hence refuses to accept the following bts-level command, in this case 'trx 0'. Confusing! So it's not a bug, it's a feature. But it's a feature we might see quite often if we move the 'periodic' command up to network level and users attempt to use their old config files. Same goes for the 'timezone' command, BTW, so we might want to rename commands, or re-consider moving commands one level up in the first place. Maybe we should leave backward compat catchers in place that print a warning. ~N -- - 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 4

BSC+BTS SI + LAPD validation, TTCN-3 Testsuite
by Harald Welte 29 Aug '17

29 Aug '17

Dear all, I've started to implement some test cases that validate the accuracy of OsmoBTS and OsmoBSC SYSTEM INFORMATION generation. Those test cases are written in TTCN-3, which is a special programming language specifically designed for testing and validation of protocol stacks. For those present at OsmoDevCon, I've briefly presented about it there. In terms of general core infrastructure, I've written: * Definition of GSM RR and some other commonly used GSM types using the TTCN-3 type description language and the TITAN RAW (binary) encoder/decoder. The beauty of this is that one can simply describe the message structure without having to generate any code for encoding/decoding the message. See http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_Types.ttcn and http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_SystemInformation.… * A GSMTAP Test Port, whcih is basically how a TTCN-3 testcase/testsuite interacts with a given IUT (implementation under test). It is implemented as dual-faced port on top of the TITAN IPL4asp (ip layer 4) port and implements GSMTAP header encoding/decoding from/to TTCN-3 structured data types: http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_PortType.ttcn which uses http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_Types.ttcn describing the GSMTAP header format. * Helper functions to emulate interactive use of the VTY based on the existing TITAN TELNETasp Test Port: http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/Osmocom_VTY_Functions.… * L1CTL type definition (again using auto-generated encoder/decoders!) http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_Types.ttcn as well as an L1CTL Test Port at http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_PortType.ttcn Using the above one can easily interface from TTCN3 with L1CTL of virtphy in order to e.g. sync to a BTS on a given ARFCN and establish a dedicated radio channel. Here is where the beautoy of the TTCN3 type language, templates and matching can be seen. It's very easy to perform something like "does this IMMEDIATE ASSIGNMENT match the RA + FN of the RACH request that I sent? Based on all of the above, there's two test suites: == Test Suites 1) SYSTEM INFORMATION contents and scheduling validation I've written some SI validation code which can be found at http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo SI scheduling is quite complex, particularly when you have many of the 2ter/2bis/2quater/13/2n/... enabled. At some point actually you will overflow what's possible to comply with the rules in a BCCH Norm. and you have to go to a BCCH Extd. (OsmoBTS doesn't implement the latter yet, btw). See e.g. function f_validate_si_scheduling() for validation of scheduling constraints: http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn#n229 Later in the file you can find test cases TC_cellid() and below for the individual test cases that validate that individual VTY configured values such as BSIC, CellId, LAC, ... are actually broadcast in the SI message. IT will update its internal matching template and then perform a sequence of VTY commands to e.g. change the LAC followed by verifying that the LAC of the decoded SI has actually changed. The above tools have helped to discover (and fix) the following bugs: * http://osmocom.org/issues/2368 * http://osmocom.org/issues/2367 * http://osmocom.org/issues/2365 (very critical, I believe) and also the not-yet-fixed but low-importance * http://osmocom.org/issues/2364 2) LAPDm testing I've written some (early) LAPDm testing code at http://git.osmocom.org/osmo-ttcn3-hacks/tree/lapdm The idea here is to test for valid and invalid transactions on the Um interface and see how OsmoBTS and the libosmcore lapdm code perform. With very few lines, this has already uncovered the following issues: * http://osmocom.org/issues/2370 * http://osmocom.org/issues/2380 Unfortunately my progress was severely affected over the weekend as I spent about one working day wrapping my head around something that turned out to be a bug in the Eclipse TITAN RAW coder, see https://www.eclipse.org/forums/index.php/t/1087557/ - fortuantely the Titan team has provided both a work-around and a fix today, which I count as excellent service. If you're curious about TTCN-3, I strongly recommend http://www.ttcn-3.org/files/TTCN3_P.pdf as an introductory slide deck. == Outlook I want to add more test cases to the sysinfo and lapdm test suites and get hands-on experience with the Junit XML output plugin. At that point, a Debian 9 build slave of our jenkins should be able to automatically build + run the latest test cases from osmo-ttcn3-hacks.git and present the individual test case results inside jenkins. I also want to add test suites for validation of: * proper generation + scheduling of of PAGING REQUEST in the BTS, considering paging groups particularly in the context of different BS_AG_BLKS_RES values * CBCH validation * proper generation of CCCH load indications by the BTS, i.e. generate a certian load e.g. on uplink RACH and check the reports * TA loop verification (add timing information to GSMTAP and then dynamically change timing from MS side to see that BTS is compensating as expected * power control loop verification: GSMTAP already has a field for transmitting RSSI in dBm. We can adjust this from the MS side to validate the BTS will adjus the instructed transmit power level of the virtual MS accordingly * actually exhaust all channels of a multi-TRX virtual BTS in different channel combinations, verify we can establish all existing logical channels in each configuration * combine the last topic with configurations that have dynamic PDCH/TCH channels to verify we properly switch forward and backward * various link failure conditions, i.e. does the BTS close the logical channel in the expected timing after uplink loss? Despite my current excitement about all of this, I'm not sure how much time I will be able to spend on this, given that the sysmocom customer priority is typically not the development of automatic test suites. But I'll try my best. If anyone wants to join: TITAN is just one "apt-get install eclipse-titan" away! == What's not good to test with TTCN-3 / TITAN: While the existing infrastructure I've built is very suitable to test low-level protocol topics, I think it's not particularly useful/applicable in other areas: * SI REST OCTETS and GPRS RLC/MAC, as they're defined in CSN.1 and TITAN has no CSN.1 encoder/decoder. For easy mathing/generation of those messages, we'd have to find something like an external CSN.1-to-ASN.1-BER or CSN.1-to-XML converter which we could use. I'd be happy to consider paying a reasonable amount for a proprietary product, just as long as we are sure that it will provde the kind of productivity that's useful here. * full end-to-end tests with actual mobile phones, RF and BTSs in the picture. We already have osmo-gsm-tester for this, and Titan with its powerful type language, templates and matching capabilities doesn't provide all that much benefit here over other languages/approaches * higher-layer protocol testing. We do have OsmocomBB as a L2 + L3 MS-side implementation, and I don't think it makes sense to replicate this. Even while the message encoding/decoding is super easy with TITAN, we still have all the related state machines. So I'd rather extend OsmocomBB where needed for automatic test cases than reinvent the wheel here. 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

Ring Back Tone Missing during Call Setup
by Ron 11 Aug '17

11 Aug '17

Hi All, I’m not sure if this is a valid question but still I’m going to try. I just updated from my old version of OSMOCOM to the latest one. Upon trying to test the updated version, it seems that the ring back tone, the one that rings in the Caller (Anum/Mobile Originating) side if the call started to ring on the Callee (BNUM/Mobile Terminating) side, is missing. Can anyone direct me to the right path where to check it? Below are the configuration files used for each OSMOCOM elements. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 5

libosmo-sccp vty point-code
by Neels Hofmeyr 27 Jul '17

27 Jul '17

In the libosmo-sigtran cs7-instance vty scope, we have the same point-code command on adjacent scopes: cs7 instance 1 point-code 1.2.3 ! sets primary_pc sccp-address msc point-code 0.0.1 sccp-address sgsn point-code 0.0.2 So if we reverse the order, we're in trouble: cs7 instance 1 sccp-address msc point-code 0.0.1 sccp-address sgsn point-code 0.0.2 point-code 1.2.3 ! sets primary_pc The parser interprets the last point-code to belong to the sgsn address scope, not the outer cs7 scope. We could rename the sccp-address one to 'pc', but... This reinforces the idea to do strict parsing of leading spaces in all our vty config files to interpret as explicit scope exit. That would break some running configs with odd spacing, but would also fix all of these issues forever. Given we're moving to a kind of Osmocom 2.0, now would be a good time to make such a change. If we from now on disallow tabs and enforce single-space indenting of child scopes, the code for that should be rather simple: count leading spaces and done. And we'd need to turn this off for interactive VTY shells. ~N

1 0

ip.access nano 3G S8 Configuration
by Meath Broadband 26 Jul '17

26 Jul '17

We are trying to setup this AP as part of the 3.5G Osmocom project. We have the software stack operational and are now preparing the nano for testing. When we try to login via telnet at port 8090 we are getting a constant refusal to connect:- root@osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090 Trying 192.168.192.30... telnet: Unable to connect to remote host: Connection refused The device seems to be locked as indicated by the leds on the front panel. We have tried resetting the nano to see if this would help but to no avail. Any ideas as to how to access the device for initial configuration?. Thanks John

1 0

code being sacrificed in the course of the OmsoNITB split-up
by Neels Hofmeyr 24 Jul '17

24 Jul '17

Some code that is disabled to be able to compile libmsc without libbsc is related to communication to the BTS, that is replaced by the new A-interface. However, the following bits are not; Any opinions about what to do with it: - Report on which ARFCN and timeslot a silent call has occured. I would simply drop the ARFCN and timeslot information, saying "silent call successful". (same in two log messages) static int scall_cbfn(unsigned int subsys, unsigned int signal, void *handler_data, void *signal_data) { struct scall_signal_data *sigdata = signal_data; struct vty *vty = sigdata->data; switch (signal) { case S_SCALL_SUCCESS: vty_out(vty, "%% silent call on ARFCN %u timeslot %u%s", sigdata->conn->lchan->ts->trx->arfcn, sigdata->conn->lchan->ts->nr, VTY_NEWLINE); break; case S_SCALL_EXPIRED: vty_out(vty, "%% silent call expired paging%s", VTY_NEWLINE); break; } return 0; } - Add Osmocom specific TLVs to SMPP /* Append the Osmocom vendor-specific additional TLVs to a SMPP msg */ static void append_osmo_tlvs(tlv_t **req_tlv, const struct gsm_lchan *lchan) { int idx = calc_initial_idx(ARRAY_SIZE(lchan->meas_rep), lchan->meas_rep_idx, 1); const struct gsm_meas_rep *mr = &lchan->meas_rep[idx]; const struct gsm_meas_rep_unidir *ul_meas = &mr->ul; const struct gsm_meas_rep_unidir *dl_meas = &mr->dl; /* Osmocom vendor-specific SMPP34 extensions */ append_tlv_u16(req_tlv, TLVID_osmo_arfcn, lchan->ts->trx->arfcn); if (mr->flags & MEAS_REP_F_MS_L1) { uint8_t ms_dbm; append_tlv_u8(req_tlv, TLVID_osmo_ta, mr->ms_l1.ta); ms_dbm = ms_pwr_dbm(lchan->ts->trx->bts->band, mr->ms_l1.pwr); append_tlv_u8(req_tlv, TLVID_osmo_ms_l1_txpwr, ms_dbm); } else if (mr->flags & MEAS_REP_F_MS_TO) /* Save Timing Offset field = MS Timing Offset + 63 */ append_tlv_u8(req_tlv, TLVID_osmo_ta, mr->ms_timing_offset + 63); append_tlv_u16(req_tlv, TLVID_osmo_rxlev_ul, rxlev2dbm(ul_meas->full.rx_lev)); append_tlv_u8(req_tlv, TLVID_osmo_rxqual_ul, ul_meas->full.rx_qual); if (mr->flags & MEAS_REP_F_DL_VALID) { append_tlv_u16(req_tlv, TLVID_osmo_rxlev_dl, rxlev2dbm(dl_meas->full.rx_lev)); append_tlv_u8(req_tlv, TLVID_osmo_rxqual_dl, dl_meas->full.rx_qual); } if (lchan->conn && lchan->conn->vsub) { struct vlr_subscr *vsub = lchan->conn->vsub; size_t imei_len = strlen(vsub->imei); if (imei_len) append_tlv(req_tlv, TLVID_osmo_imei, (uint8_t *)vsub->imei, imei_len+1); } } deliver_to_esme() { [...] if (esme->acl && esme->acl->osmocom_ext && conn->lchan) append_osmo_tlvs(&deliver.tlv, conn->lchan); [...] } - Siemens BS11 MRPCI /* see mail on openbsc@ 9 Feb 2016 22:30:15 +0100 * We need to hook sending of MRPCI to Siemens BS11 somewhere else */ if (is_siemens_bts(conn->bts)) send_siemens_mrpci(msg->lchan, classmark2-1); - Debug log: report bts - trx - ts - ti in mncc_rcvmsg() (No BTS information available in OsmoMSC anymore) - In gsm48_cc_rx_setup(), populate struct gsm_mncc setup with lchan type. (lchan information is no longer available in OsmoMSC) - In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be dropped from libmsc. /* * This will be run by the linker when loading the DSO. We use it to * do system initialization, e.g. registration of signal handlers. */ static __attribute__((constructor)) void on_dso_load_0408(void) { osmo_signal_register_handler(SS_ABISIP, handle_abisip_signal, NULL); } ~N

2 4

Re: osmo-nitb error during execution (Error occured... timer t3103 0)
by Vadim Yanitskiy 24 Jul '17

24 Jul '17

Hi, > Error occurred during reading below line: > timer t3103 0 I may be wrong, but it's probably related to recent change: http://git.osmocom.org/openbsc/commit/?id=ab2454e776f1a4bc4977ef48ec2844600… In short, it doesn't make sense to set '0' value to any timer. So, updating the software, please also keep your configuration updated ;) With best regards, Vadim Yanitskiy.

5 6

osmo-nitb error during execution (Error occured... timer t3103 0)
by Ron 23 Jul '17

23 Jul '17

Hi All, Requesting your help on this kind of issue. Upon running the osmo-nitb, we had received and error regarding the timer configuration. osmo-nitb -C -c /root/osmocom_files/openbsc_1trx.conf -T -P -m Sat Jul 22 18:28:18 2017 <0006> mncc_sock.c:316 MNCC socket at /tmp/bsc_mncc There is no such command. Error occurred during reading below line: timer t3103 0 % Ignoring deprecated logging level everything % Ignoring deprecated logging level everything Sat Jul 22 18:28:18 2017 <0005> bsc_init.c:536 Failed to parse the config file: '/root/osmocom_files/openbsc_1trx.conf' Reading config failed. Exiting. But upon removing all the timer configured in the configuration file, osmo-nitb run as usual. Not sure if you guys removed it in purpose. Kindly advice please. osmo-nitb version used: 0.15.1.20170721 Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 2

sysmoUSIM variants and alternatives
by Mychaela Falconia 22 Jul '17

22 Jul '17

(Posting to the OpenBSC list because I figured that the set of people who issue their own SIMs probably has a good overlap with the set of people who operate their own physical GSM networks.) I am shopping for some non-carrier-branded, non-carrier-issued SIM cards for use in testing my FreeCalypso GSM MS devices (specifically, testing of the SIM interface in isolation without bringing up radio, as well as radio and full MS functionality testing with a base station simulator like CMU200 instead of live networks), and the only product I found so far is sysmoUSIM - if anyone else makes a similar product ("generic" SIM cards for tinkerers), I would like to know about it. In the case of sysmo(U)SIM cards, it looks like 2FF-only cards are no longer available, and the current choices are 2FF+3FF or 2FF+4FF. My question is: if I only want 2FF and have no interest in 3FF or 4FF, which variant should I buy? In other words, which variant is mechanically stronger and less likely to break in 2FF-only usage in various kinds in 2FF sockets? TIA, Mychaela

3 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2017