OpenBSC July 2017

openbsc@lists.osmocom.org

24 participants
39 discussions

Pysim error: SW match failed
by Martin Nagy 16 Aug '25

16 Aug '25

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

3 3

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 5

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

ip.access nano 3G S8 Configuration
by John Thewlis - Meath Broadband 07 Aug '17

07 Aug '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

3 3

Need nano3G (S8 - Model 237A)
by Akib Sayyed 01 Aug '17

01 Aug '17

Dear List I am extremely sorry for off the topic question. I am willing to buy nano3G Nodeb. Is anyone in list have spare which can be sold. Please let me know. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 2

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2017