OpenBSC March 2017

openbsc@lists.osmocom.org

22 participants
49 discussions

by Martin Nagy

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

1 month

Re: Help with sccp library

by mosbah abdelkader

> 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.

2 months, 1 week

dynamic traffic channels

by Neels Hofmeyr

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

4 months

Thoughts on a next generation MIB/VTY replacement

by Harald Welte

Hi All, Using zebra/quagga VTY code was a great idea back then and has served us nicely in all those years. I like the general style of the command-line based interface with its various nodes, the strict syntax checking, the tab completion and the interactive context-sensivive help. However, it feels a bit 20ieth-century-ish to have to manually write code to parse and to save the respective values. This is not a productive way to spend our development resources, and it is error prone. The "save" can be forgotten, resulting in non-saveable config parameters. The save can store values that the "parse" function will not be able to read again, etc. Furthermore, the VTY is inherently a human user interface, not intended for programmatic consumption. For programmatic access, we have developed the control interface. In reality though, only 1% of the parameters available in the VTY are exported via the control interface. And rather than adding all the missing bits and pieces with hand-crafted code to the control interface, we should have a generic way to define a new configuration value, and that value should then be automatically parse- and storable via VTY as well as a programmatic interface. The next "problem' is that the current telnet connections live within the process of the application. This means that a user can effectively "stall" the main application by performing I/O intensive operation on the VTY, or even on as many VTY/telnet sessions as he wants. There shouldn't be any need for this, at least not for something as mundane as performing configuration changes. Of course the VTY has different use cases such as runtime introspection of system state as well as logging. But still. Yet another concern is "VTY and telnet port proliferation". Particularly with the conversion from NITB to BSC+MSC+HLR, we are yet again getting more network elements with their own telnet ports. Remembering the port numbers is clumsy. It would be more convenient if a single command line interface could provide access to the configuration and the state of multiple different processes / network elements. Last, but not least, the current implementation is fixed to telnet, without any form of authentication, and without a path to migrate e.g. to something like SSL or SSH. I don't think it is a major concern (you can always SSH to the system and then telnet locally). So what I had in mind for quite some time (actually since netconf 1.2 about one year ago), is to have some kind of an external "VTY/MIB daemon" (or even separate daemons for each) which maintains a hierarchical database of configuration values. The MIB deamon simply offers an API (via client library) to GET or SET the individual values, or to NOTIFY an application about a changed value. This API is both used by the actual Osmocom programs to obtain their configuration (and obtain updates to it during runtime), as well as by the "VTY daemon" providing interactive shell access to it. Finally, other external applications could use the same interface/client library to do the same. A proxy to SNMP or REST interfaces can be imagined, for even more interfacing with the outside world. What I don't like about many existing MIBs I've used (as a sysadmin/user, not a developer) is their simple type system. You can often specify any random value to such a MIB, even one that is completely useless. A simple INT or STRING type is not sufficient, we really want the ability to have ENUM types, to have integers with ranges, etc. - just like we have in the VTY. Also, the MIBs I've used typically are nothing more than a hierarchical key-value store. They do not contain the information required for interactive, context-sensitive help needed for the "VTY" feel :( This is btw also the problem I have with OpenWRT's uci: It just has keys and values, with no way to constrain those values to something that's reasonable to the given program/context that is being configured, and there's no help or other information associated with those keys and values. So what I would like to see in this context, is some way to have a machine-parseable description of a "MIB/config item", together with syntax, ranges, enum values, help texts, etc (ideally in the C source code, possibly in comments?) which is used by some kind of MIB compiler to build up the hierarchical structure of the MIB and all of its keys as well as their permitted values and syntax reference. This information is then available to the VTY/telnet connections, irrespective of whether a given application [using those values] is running at all. Once an application starts, it can query for the configuration values it is interested in and populate its internal data structures from it. Ideally, one would even be able to generate a 'struct' from the MIB compiler, so that there is no need to explicitly call a "get" function on each single configuration value, but one simply gets a C-language 'struct' with all the values filled in by the client library. As stated above, there should be some way how he MIB can notify applications about changes to certain nodes in the MIB tree, so the application[s] can react to that. I don't have a clear picture yet how transaction logic (like changing multiple values and then committing them at once) would work, or whether applications should even be able to reject/revert a modification? In either case, I just wanted to share my thoughts on this. I know it sounds rather complex, but I think the investment in some kind of unified configuration database system would save us of a lot of boilerplate code and subtle bugs and inconsistencies. I've created https://osmocom.org/issues/1975 with above text to keep track of it, but I think at this point it's more of a mailing list discussion rather than something we can put into an issue. I guess the progress would rather be * first discuss it here and/or at OsmoDevCon * create something like a specification in the wiki * then follow-up with actual tickets on the work items All of this is brainstorming and vaporware, but I can't help to think of better ways of doing this. If somebody has experience with any existing systems and wants to share if and how they might fit, or what other ideas are useful to borrow: Please share! 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)

8 years, 4 months

RFC: speed up gerrit verifications by using dependency artifacts

by André Boddenberg

Hi, some weeks a go the topic about using dependency-artifacts to speed up gerrit verifications was mentioned by Neels in the "RFC: jenkins pipeline" thread [1]. I was curious and wrote a bash script (osmo-artifacts.sh) [2], which enables build jobs to archive and fetch dependencies. Instead of Docker it simply uses archives to store them. An artifact's name has the following form: ( n(${project}.${branch}.${shortRev}_) ).tar.gz Openbsc builds are 50 % faster when using artifacts. [3] The jenkins.sh [2] script had to be slightly modified i.e. basically split into two functions: 1) buildProjectDeps() 2) buildProject() A third function to generate the artifact name has been added. The template.sh [2] script illustrates this description. What do you think about the result/artifactStore/approach in general? A cleanUpArtifactStore.sh script running as a cron job is already on my mind, but imo it's a good point to discuss the intermediate result. blobb [1] http://lists.osmocom.org/pipermail/openbsc/2017-March/010400.html [2] git clone https://github.com/blobbsen/diy-artifacts.git [3] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_test…

8 years, 5 months

weekly test report (w13 2017)

by Joachim Steiger

Hi, this is the BTS test report for week13 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G All test cases have passed. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests following are some git hashes/version strings of tested components: libosmo-abis: 5e87fdfcabc9cabe0025d7350b7ab31cdc4b6fa3 libosmocore: d78c973cd89fc7c119573357cfbebb891dbc697a libosmo-netif: 5fe77a4656f3590c343861ea96bcec18e370e437 libosmo-sccp: 8e708d1f2da1b187f631bf08172a5194a85b1a23 libsmpp34: cc0bcd6bc051d5ccaf32cdbbc28f073369900857 openbsc: b1e6b3749389ec5b3f33d5ac0fcc7f43df3f4641 openggsn: 19e19e3609508d121ba46c165e5ed1502a3cf9da osmo-bts: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-bts-octphy: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-pcu: e6d26ec09c2bcd2126416a58cb23af27318ec67e osmo-trx: e0c12189d455eb0d17299e4504749ce36629e18b sysmobts: OsmoBTS version 0.4.0.414-e16b5 sysmobts: Osmo-PCU version 0.2.900-e6d2 octbts: (name='octsdr_gsm', desc='Software Define Radio', ver='02.07.00-B1039', ver_hdr='02.07.00-B1039') octbts: (platform='Opus2', version='OCTSYS_VERSION=01.02.19.B1;OCTODK_VERSION=01.15.01-B1;OCTADF_VERSION=04.05.01-B2637;') nanobts: Equipment_Version='165g029_79' nanobts: Software_Version='168d462_v200b202d0' if you are interested in the details, drop me a mail and i'll forward the whole report. kind regards -- - Joachim Steiger <jsteiger(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 Directors: Harald Welte

8 years, 5 months

commit python script to openbsc/contrib

by Keith Whyte

Hi all. I have a python script I'd like to commit to openbsc/contrib. It reads the SMS table, gives stats and retrieves individual messages. - should maybe go in openbsc/contrib/sms ? Anyway, should I submit this via gerrit + code review or is there another way? There's really no point in having jenkins look at it, right? Thanks! k.

8 years, 5 months

pysim has moved to gerrit

by Neels Hofmeyr

pysim patches are managed by gerrit from now on. ~N

8 years, 5 months

[PATCH 0/2] fixes for pysim

by Philipp Maier

Hello, I would like to propose the two changes for pysim, the first is for fixing the sysmo-usim-sjs1 support and the second fixes the missing support for writing the ICCID to a sysmo-usim-sjs1. If there are no major concerns with that I would like to merge the two patches to master. Repo: https://git.osmocom.org/pysim Branch: pmaier/fixfci regards, Philipp Maier Philipp Maier (2): Fix select control parameter fix writing of ICCID for sysmo-usim-sjs1 pySim/cards.py | 15 ++++++++------- pySim/commands.py | 11 +++++++++-- 2 files changed, 17 insertions(+), 9 deletions(-) -- 1.9.1

8 years, 5 months

Updates on Osmocom Conference 2017

by Harald Welte

OsmoCon 2017 updates There are some updates related to OsmoCon2017, the first Osmocom Conference, held on April 21st, 2017 in Berlin, Germany. See http://osmocom.org/news/68 for the web version of this announcement. == Summary == Summary (for those too busy to read the full post): * Schedule of talks has been released http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule * Travel Grants available for participants who are otherwise unable to travel to Berlin: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants * Social Event details available, including menu: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent * April 21st is approaching fast, make sure you get your Ticket in time. Limited number of seats available http://shop.sysmocom.de/products/ticket-for-osmocon-2017 == Details == === Schedule has been released === The list of talks with their abstracts has been on the website for quite some time, but now we actually have put together a schedule based on those talks. Please see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule for the schedule. As you can see, the day is fully packed with talks about Osmocom cellular infrastructure projects. We had to cut some talk slots short (30min instead of 45min), but I'm confident that it is good to cover a wider range of topics, while at the same time avoiding fragmenting the audience with multiple tracks. === Travel Grants === We are happy to announce that we have received donations to permit for providing travel grants! This means that any attendee who is otherwise not able to cover their travel to OsmoCon 2017 (e.g. because their interest in Osmocom is not related to their work, or because their employer doesn't pay the travel expenses) can now apply for such a travel grant. For more details see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants and/or constact osmocon2017(a)sysmocom.de. === Social Event === Tech Talks are nice and fine, but what many people enjoy even more at conferences is the informal networking combined with good food. For this, we have the social event at night, which is open to all attendees. See more details about it at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent -- - 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)

8 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2017