OpenBSC February 2021

openbsc@lists.osmocom.org

16 participants
14 discussions

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.

4 weeks

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

1 month

Problem while running NIB on Open Cellular Base sation

by Brackley Casinga

Hi, My name is Brackley Cassinga Form DRC, we run a community network called pamoja net where we offer gsm services using osmocom open source software and OC Base station. Recently I have tried to install another base station as the same installed but I could not find any resource guiding through all the steps to take to run NIB on a base station. I'm currently running Ubuntu and I will appreciate if you could guide me on the installation of BSC,hlr,MSC , in order to run a basic gsm network. Thank you. Regards -- *Ir Brackley heshima Casinga **Pacifique* *CEO and Founder of kwanzatechnologie* KwanzaTechnologies ,GlobalElectronics +243977265291 | +243977265291 | Pcassinga(a)gmail.com/ brackley(a)ensemblepourladifference.org www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> | Skype: Brackley cassinga <https://webapp.wisestamp.com/#> Av Semliki N 43

1 year, 4 months

WIP / RFC for pysim 'next generation;' aka pysim-shell

by Harald Welte

Dear Osmocom community, pySim-prog was nice when there were only 5 parameters on a SIM that we could program, and where the use case was pretty limited. Today, we have SIM/USIM/ISIM cards with hundreds of files and even more parameters to program. We cannot add a command line argument for each file to pySim-prog. Instead, this introduces an interactive command-line shell / REPL, in which one can navigate the file system of the card, read and update files both in raw format and in decoded/parsed format. The idea is primarily inspired by Henryk Ploetz' venerable cyberflex-shell, but implemented on a more modern basis using the cmd2 python module. You can see the very first prototype in the laforge/shell branch of pysim.git You can do things with it like this: ===> Start-up and authenticate with adm pin ---------------------------------------------------------------------- $ ./pysim-shell.py -p 0 Using PC/SC reader interface Autodetected card type: sysmoISIM-SJA2 AIDs on card: ['a0000000871002ffffffff8907090000', 'a0000000871004ffffffff8907090000'] Welcome to pySim-shell! pySIM-shell (3f00)> verify_adm 92990895 ---------------------------------------------------------------------- ===> interactive help ---------------------------------------------------------------------- pySIM-shell (3f00)> help Documented commands (use 'help -v' for verbose/'help <topic>' for details): ISO7816 Commands ================ read_binary select_adf select_file update_binary update_record verify_chv pySim Commands ============== intro verify_adm USIM Commands ============= read_ehplmn ust_service_activate ust_service_deactivate pySim-shell built-in commands ============================= alias help macro quit run_script shell edit history py run_pyscript set shortcuts ---------------------------------------------------------------------- ===> more interactive help ---------------------------------------------------------------------- pySIM-shell (3f00)> help read_binary usage: read_binary [-h] [--file-id FILE_ID] [--offset OFFSET] [--length LENGTH] [--record-nr RECORD_NR] Read binary data from a transparent EF optional arguments: -h, --help show this help message and exit --file-id FILE_ID File ID --offset OFFSET Byte offset for start of read --length LENGTH Number of bytes to read --record-nr RECORD_NR Number of record to read ---------------------------------------------------------------------- ===> navigating the FS and reading files ---------------------------------------------------------------------- pySIM-shell (3f00)> select_file 7f20 ['622c8202782183027f20a509800171830400018d088a01058b032f0601c60f90017083010183018183010a83010b'] pySIM-shell (3f00/7f20)> read_binary --file-id 6f07 089910070000400310 ---------------------------------------------------------------------- ===> interaction with local filesystem, i.e. I/O redirect + shell commands ---------------------------------------------------------------------- pySIM-shell (3f00)> select_adf a0000000871002 pySIM-shell (a0000000871002)> select_file 5f3b pySIM-shell (a0000000871002/5f3b)> read_binary --file-id 4f20 > /tmp/f pySIM-shell (a0000000871002/5f3b)> !cat /tmp/f ffffffffffffffff07 ---------------------------------------------------------------------- ===> piping output through shell tools like grep ---------------------------------------------------------------------- pySIM-shell (3f00)> read_ust | grep 86 Service 86 - Allowed CSG Lists and corresponding indications ---------------------------------------------------------------------- ===> enabling/disabling services ---------------------------------------------------------------------- pySIM-shell (3f00/7f20)> ust_service_activate 123 pySIM-shell (3f00/7f20)> ust_service_deactivate 123 ---------------------------------------------------------------------- It's a very first prototype, but it is really promising. The major tasks I see to make this go anywhere is: * have "File" class with encoder/decoder methods, which are registered automatically with a 'file system' layer that knows about the DF/ADF hierarchy ** this allows us to have a "read-decoded" command, which will call the decode method of the file, automatically resolved by the selected FID/path * automatic mapping of file-name -> FID and FID -> file name ** when printing (like in the path), use the human-readable names ** allow users to use human-readable names in SELECT * decode + display the TLVs / FCPs after a SELECT (like cyberflex-shell * ability to enable/disable APDU trace * dynamically register/deregster commands based on the path, i.e. offer USIM commands only when in ADF_USIM We have quite a bit of that infrastructure in the c-language libosmosim, (part of libosmocore.git), but unfortunately not in python :/ Let me know if anyone is interested in joining this 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)

4 years, 2 months

Idea for 2021: Regular "OsmoDevCall"

by Harald Welte

Dear Osmocom community, as the pandemic continues and physical meetings are out of the question for the forseeable future, it would be a good idea to have a periodic virtual online meeting of the interested Osmocom community. I was thinking of a format where we would serve two major purposes: 1) technical talks about osmocom relevant topics - ideally current/recent developments * can be pre-recorded to avoid any problems with technical setup, streaming, ... * should ideally have a Q+A session at their initial "airing" during one OsmoDevCall 2) unstructured solicited social event (USSE) * random chat in audio (optionally video) * not recorded, obviously The recording of the technical presentation should then be permanently made available (like the presentations of our prior OsmoCon / OsmoDevCon). Not every OsmoDevCall would neccessarily need the two parts, but I think it would be great if we can make that happen. We could also have e.g. a two-weekly schedule for the USSE and a monthly schedule for the technical presentation. We'd need somebody to volunteer to "manage" the "broadcast" side of this, preferably somebody with at least some prior exposure to online events (like the c3voc). I'm using https://osmocom.org/issues/4928 to collect a tentative list of topics. Feel free to add your ideas there, as well as any comment/ feedback you may have. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 years, 2 months

Osmocom CNI release 202102

by Pau Espin Pedrol

Dear all, I am pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. Find more information about the release here [1]. Osmocom "Latest" repositories in OBS [2] should already contain packages for the new versions. OpenEmbedded related meta-layers such as meta-telephony usual stable/testing branch "201705" [3] have also been updated to build recipes for new versions. Regards, Pau [1] https://osmocom.org/news/132 [2] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds [3] https://git.osmocom.org/meta-telephony/log/?h=201705 -- - Pau Espin Pedrol <pespin(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

4 years, 3 months

Looking for historical sysmoSIM-GR2 card

by Mychaela Falconia

Hello fellow GSM hackers, Would anyone here happen to have a sysmoSIM-GR2 card (once sold by Sysmocom aeons ago, but long since discontinued) which they would be willing to sell? I have a friend who has sysmoSIM-GR1 and sysmoUSIM-GR1 (other long-discontinued historical cards from aeons ago), but no sysmoSIM-GR2. I am looking for just one card (doesn't matter if it is fully intact, broken out 2FF, or even cut down to 3FF), and I am willing to pay premium price for it, plus I will pay for private courier shipping to bypass USPS which can't be trusted with anything valuable these days. So if anyone has one of these cards which they would be willing to part with, and could use a little money, please give me a holler. Oh, and if the card's SUPER ADM PIN has been changed to something other than the default 88888888, I will need to be given that key. Background info: I am trying to get some new cards from Grcard, and I ordered samples. These samples were originally scheduled to arrive in USA next week, but then some snafu happened, and the shipment got returned to the sender. I was given a non-answer as to what the problem issue is, and I basically have to wait an indefinitely long time (at least past LNY 2-week holiday, plus however much longer after that) to get a resent package - and it looks like they are going to resend via a slower method too. Meanwhile I have implemented Grcard2 custom commands in fc-simtool based on this wiki page: https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2 I am now looking for a way to test my Grcard2 command implementation against some card that is *known* to speak Grcard2 protocol and not some other (hence sysmoSIM-GR2 would be ideal), and when I receive the new sample cards from Grcard at some future time (probably many weeks or even months out), I will be able to compare, and determine if they are also Grcard2 or something else. (If the new cards turn out to be different from both Grcard1 and Grcard2, I will call them Grcard3. :) Hopeful, Mother Mychaela of FreeCalypso

4 years, 3 months

OTA RFM on sysmoISIM-SJA2 cards

by Mychaela Falconia

Hello Osmocom community, Has anyone here ever played with the RFM (Remote File Management) feature on sysmoUSIM-SJS1 and sysmoISIM-SJA2 cards? I know that a lot of people play with RAM (Remote Application Management) for installing Java applets, but I am more interested in RFM for doing a different kind of OTA programming - I am seeking to recreate the workflow of traditional GSM network operators where "blank" (not yet activated, but ready to activate) SIM cards sit on store shelves with their IMSI and secret keys (Ki/K/OPc etc) already programmed at the factory, but blank EF_MSISDN because the future user's phone number is not known yet. Customers activate these SIMs by reading the ICCID from the card to customer service over the phone, or salespeople in stores scan the ICCID barcode - and then the operator's customer management system matches that ICCID with its knowledge of the IMSI and secret keys, and the service gets activated on the new SIM. And then the operator's network uses SMS-PP SIM data download to program the EF_MSISDN record in the newly activated SIM - I know full well that a phone does not need to know its own MSISDN to make and receive calls, but every classic GSM dumbphone has a menu command for "Show my number" or whatever it's called, this command displays the MSISDN record from the SIM, and traditional operators program this record OTA so that this menu command will work. I am seeking to recreate this OTA programming step. I just got the needed KI[CD][23] OTA keys for my sysmoUSIM-SJS1 cards (thanks Sysmocom support!), and I am able to exercise RFM successfully on these cards by uncommenting these lines in the shadysim.py script: # for RFM testing ac.test_rfm() exit(0) It appears that the "tribal" knowledge (not written in any formal document, AFAICT) of how to use the RFM feature on sysmoUSIM-SJS1 cards exists only in the following code stanzas in shadysim.py, code that never executes unless you uncomment that ac.test_rfm() call: def send_wrapped_apdu_rfm_sim(self, data): # TAR RFM SIM: B00010, sysmoSIM SJS1: MSL = 6, second keyset return self.send_wrapped_apdu_internal(data, 'B00010', 6, 2, 2) def send_wrapped_apdu_rfm_usim(self, data): # TAR RFM USIM: B00011, sysmoSIM SJS1: MSL = 6, third keyset return self.send_wrapped_apdu_internal(data, 'B00011', 6, 3, 3) It was only thanks to the above code lines and comments that I learned that I need to use keyset 2 for SIM RFM, and how else would we know the needed magic TAR if not for the above code and comments? In any case, the RFM test function of shadysim.py works like a charm on my sysmoUSIM-SJS1 cards with the right keys (successfully displays the IMSI read out via RFM), and I am now going to work on my own C code that will replace Python and do what I need. However, I also tried the exact same shadysim.py RFM test function on the newer sysmoISIM-SJA2 cards, and it does NOT work. I run the exact same shadysim.py (modified only to uncomment the RFM test) that works against sysmoUSIM-SJS1, but when I run it against sysmoISIM-SJA2 and specify the respective card's KIC2 and KID2 from the webshop key data email, I get this output: ICCID: 8988211000000471501f ('', '') Here is the output with a good sysmoUSIM-SJS1: ICCID: 8988211000000386808f ('089910070000306808', '9000') Given that the code stays exactly the same and I am merely specifying different keys as needed for each card, there must be something different about the new sysmoISIM-SJA2 cards with respect to RFM. Perhaps the TAR is different? Perhaps the association of which keyset goes for what is different? Some other differences like different crypto algorithms being used? Perhaps a migration from 3DES to AES? I am fine with just using sysmoUSIM-SJS1 for development of my C tools (tools which will hopefully be extended later to work with other vendors' SIMs beyond just Sysmocom), but it would be nice to fill in the knowledge gap regarding sysmoISIM-SJA2 and get these cards to work as well. In hacking fellowship, Mother Mychaela

4 years, 3 months

Introducing ntt. Modern tools for TTCN-3

by Simon, Matthias (Nokia - DE/Ulm)

Hi, I am Matthias, a TTCN-3 tool developer from Nokia. Thank you for opening your work. Your repository osmo-ttcn3-hacks helped me to understand how other developers use TTCN-3 for testing. This gave me valuable insights for tool development. I hope I can give something back by opening up our internal TTCN-3 tools as well. Harald suggested to introduce them on this list. I'd appreciate your feedback. Our project is called ntt and it provides various tools for working with TTCN-3 [1]. For example, you can create a tags file: $ ntt tags ./osmo-ttcn3-hacks/bts >TAGS Or you can list things. To filter cyclic imports, for example: $ ntt list imports ./osmo-ttcn3-hacks/bts | tsort 1>/dev/null But the most interesting piece is probably the TTCN-3 language server: ntt implements the language server protocol. This makes ntt a universal TTCN-3 language plugin for virtually any editor or IDE [2]. It's still very much beta, but we are finishing the Go to Definition feature (as replacement for ctags files). The next feature would be adding various diagnostics. It would be great if you could give ntt a try and share your experience or editor configuration with me. This is my first open source project and we still have to figure some stuff out. So please excuse if there are still some rough edges. Cheers, Matthias [1] https://nokia.github.io/ntt/ [2] https://nokia.github.io/ntt/editors/

4 years, 3 months

RFC: generic CTRL interface for VTY config settings

by Harald Welte

Dear all, we always had said the VTY is a human CLI, while the CTRL interface is for interfacing with other software. This was primarily related to asking users to not parse the VTY output of "show" commands or the like. For configuration via VTY, we have to provide a stable interface anyway, as otherwise loading config files would not be possible across [non-major] software upgrades. While that is right in principle, the fact that we don't have a generic configuration store / API / MIB means that one would explicitly have to add CTRL command for all relevant settings, which may have been realistic in 2010, but is unrealistic with the hundreds of VTY configuration parameters today. I was thinking wither it might make sense to add a generic CTRL interface GET/SET for "configuration" mode VTY settings. This would mean we write code once, and immediately expose all our VTY nodes to CTRL. Thinking of the following example done via VTY: ----------------------------------- OsmoBSC> enable OsmoBSC# configure terminal OsmoBSC(config)# network OsmoBSC(config-net)# bts 0 OsmoBSC(config-net-bts)# trx 1 OsmoBSC(config-net-bts-trx)# timeslot 0 OsmoBSC(config-net-bts-trx-ts)# training_sequence_code 3 ----------------------------------- We could have something like the following CTRL command: SET network.bts.0.trx.1.timeslot.0.training_sequence_code 3 The devil is a bit in the details of the syntax * the normal '.' as separator looks generally OK, I think we have [almost?] no VTY commands that include a ',' * we somehow need some kind of separator to tell where individual VTY commands are separated, like SET network."bts 0"."trx 1"."timeslot 0".training_sequence_code 3 or SET network|bts.0|trx.1|timeslot.0|training_sequence_code 3 or SET network#bts.0#trx.1#timeslot.0#training_sequence_code 3 or SET network.bts#0.trx#1.timeslot#0.training_sequence_code 3 SET network.bts@0.trx@1.timeslot@0.training_sequence_code 3 I think the last examples would be more "natural" for existing CTRL interface code, as the dot separat separates tokens, and we simply expand the '#' or '@' to spaces in the context of VTY commands The generic vty-cfg-via-CTRL code then would basically emulate a user entering the sequence of commands - including the "exclusion" of not allowing multiple concurrent VTY or vty-cfg-via-CTRL users at the same time What do you guys think? Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 years, 4 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2021