OpenBSC

openbsc@lists.osmocom.org

10 participants
4188 discussions

Osmocom Mailing List re-organization
by Harald Welte 09 Mar '21

09 Mar '21

Dear Osmocom community, This topic has been past due for way too many years by now: A re-organization of our major mailing lists. I would like to propose the following changes. Pleas let me know if you have any comments or feedback. I'm aware that renaming will mean people have to update their mail filter rules, but I think we're long past the point where the names of some of our lists started to confuse users. == openbsc(a)lists.osmocom.org == * openbsc doesn't exist anymore since OsmoNITB, which is also obsolete * does already cover anything "Osmocom CNI" related * Proposed new name: osmocom-cni(a)lists.osmocom.org == osmocom-net-gprs(a)lists.osmocom.org == This date back to when GPRS was a highly experimental add-on to our GSM code base. This list should simply be merged with openbsc@ as osmocom-cni(a)lists.osmocom.org == simtrace(a)lists.osmocom.org == Historically was created to cover only the simtrace project. We should rename this to osmocom-simcard(a)lists.osmocom.org or something along those lines. I would like to suggest it covers * SIMtrace / SIMtrace2 hardware + firmware * pySim and related tools for working with SIM/USIM/UICC cards * any other information / discussion related to SIM/USIM/UICC cards, like OTA, ARA-M, ... == osmodevcon(a)lists.osmocom.org == This has been a private list for people attending OsmoDevCon I would like to open up list membership to the general public, and ensure it also covers the new OsmoDevCall. We could then have discussions regarding feedback, topics, scheduling, etc. on that list. Maybe rename it to osmocom-events(a)lists.osmocom.org instead? To differentiate: osmocom-event-orga(a)lists.osmocom.org should remain a private list related to organizational / administrative topics of those involved with organizing future events. == nextepc(a)lists.osmocom.org == Should have been renamed to open5gs(a)lists.osmocom.org quite some time ago, I simply forgot about it. My apologies. -- - 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 5

Bringing back GrcardSIM2
by Mychaela Falconia 08 Mar '21

08 Mar '21

Hello esteemed masters of Osmocom, (asking here because Harald's proposed osmocom-simcard list hasn't been created yet) I have some questions and experience-based corrections related to the gold nuggets contained in this wiki page: https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2 First let me establish relevance: even though Sysmocom stopped selling these GR2 cards ages ago and it looks like the wider Osmocom community also stopped playing with them once sysmoUSIM-SJS1 came out, these same GrcardSIM2 cards are still available from Grcard in the present day. A week and a half ago I received 5 sample cards (plain white, no printing, unprogrammed) from Grcard that return the same ATR as is listed for sysmoSIM-GR2, and all of the card-model-specific proprietary commands described on the above wiki page work exactly the same on these cards as they once worked on sysmoSIM-GR2. I am now in the process of ordering a batch of 200 of these cards from Grcard, with my own custom printing applied (so they will look pretty, not plain white and not black like sysmoISIM-SJA2) - essentially I am bringing back an exact equivalent of the discontinued sysmoSIM-GR2. With relevance thus established, let's move on technical questions: * The wiki page describes a file named EF.WEKI, file ID 0001 under DF.GSM. Whoever wrote this wiki page, how did you get this fancy name EF.WEKI? Was there some kind of document from Grcard that described this card-model-specific proprietary file? Does that document still exist somewhere? Can there be some way for mere mortals like me to see that document? * The wiki page describes byte 3 of EF.WEKI as selecting COMP128 algorithm version. It lists 0 as selecting COMP128v1 and 1 as selecting COMP128v2, and these two codes are correct - confirmed by programming these codes, doing a RUN GSM ALGO command, and comparing returned SRES and Kc against osmo-auc-gen. However, the page lists 3 as selecting COMP128v3, and this part is not correct - writing 3 in there results in COMP128v2 being selected, just like code 1. Instead I need to write 2 into the lower nibble of this byte in order to get COMP128v3 SRES and Kc in response to RUN GSM ALGO. * The COMP128 selection code is just the lower nibble of byte 3 of EF.WEKI - the upper nibble is something else that currently eludes my understanding. The wiki page instructs users to write 0 into the upper nibble, and so does pySim-prog - yet in the initial "unprogrammed" state of the cards I received from Grcard, this upper nibble is set to 2, not 0. I could not see any observable difference in card behaviour whether the upper nibble is set to 0 or 2 - either way the lower nibble selects COMP128 version for RUN GSM ALGO operations. * The wiki page gives the impression that EF.WEKI is 19 bytes long in total. However, the actual size of this transparent EF on the card is 35 bytes, i.e., there is another 16-byte field (some other key?) after Ki. Of the people who were once privileged with proper official documentation for these cards, might anyone be able to tell what this other key is for? Could it perhaps be some kind of key for OTA? Before someone tells me that I should direct these questions to Grcard, given that I am buying cards from them, let me assure everyone that yes, of course I am doing everything I can to pry this information out of them. However, they seem to have the same attitude as most Chinese companies where they just want you to buy their product and not ask any technical questions, and whatever answers they do give are so terse that they feel like non-answers. But there is also the undeniable fact that once upon a time these cards were resold by Sysmocom, once upon a time this Osmocom community right here worked with these cards, and someone in this community (or on Sysmocom staff) must have gotten enough documentation to write the wiki page and pySim-prog support for them. Thus I feel at least somewhat justified in asking this community for help with bringing back this lost knowledge. On a happier note, my fc-pcsc-tools suite (fc-simtool and its limited- function companion fc-uicc-tool) is advancing quite a bit in functionality. I don't know how it compares to pysim-shell since I gave up trying to get the latter to run under Slackware (just too many difficult dependencies), but from what I read in mailing list posts, pysim-shell seems to be rather UICC-centric - I couldn't tell if it is supposed to work on non-UICC GSM 11.11 protocol cards or not. In contrast, my fc-simtool (written in C, zero dependencies beyond libpcsclite) speaks the classic GSM 11.11 SIM protocol and does everything that is possible within this protocol, including innovative hacks like brute force search of the file ID space. This tool should be ideal for cards like GrcardSIM2 which are non-UICC and for which the classic GSM 11.11 SIM protocol is native. The companion utility fc-uicc-tool for the UICC protocol is quite minimal in functionality, just enough to satisfy the few areas of curiosity I had in relation to that protocol and the cards I have around that speak it. These new C-language SIM tools live here: https://www.freecalypso.org/hg/fc-pcsc-tools/ The code is 100% my own original work and there is a LICENSE file at the top of the repository declaring it as public domain, so there should be no problem with Free Software status of the work. In hacking fellowship, Mother Mychaela

3 5

Jenkins: 2 new raspberry pi nodes / running on raspbian10
by Oliver Smith 08 Mar '21

08 Mar '21

Hey all, short FYI regarding jenkins.osmocom.org: two new raspberry pi nodes are available, in order to reduce wait times for free build slots during heavy osmo-trx development. All three pis execute the jenkins jobs on top of raspbian10 now, unlike the old setup where it was on top of debian 9 in a LXC running in raspbian10. In other words, the LXC layer is gone now, and there might be slight differences related to debian9 vs. debian 10 packages. For all the jobs running in docker instead of directly on the host, there should be no difference at all. Details are in OS#5055. Best, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://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

1 0

Osmocom CNI release 202102
by Pau Espin Pedrol 26 Feb '21

26 Feb '21

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

1 0

Looking for historical sysmoSIM-GR2 card
by Mychaela Falconia 24 Feb '21

24 Feb '21

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

3 3

OTA RFM on sysmoISIM-SJA2 cards
by Mychaela Falconia 22 Feb '21

22 Feb '21

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

2 3

Introducing ntt. Modern tools for TTCN-3
by Simon, Matthias (Nokia - DE/Ulm) 22 Feb '21

22 Feb '21

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/

3 4

RFC: generic CTRL interface for VTY config settings
by Harald Welte 18 Feb '21

18 Feb '21

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)

5 7

testing TTCN3 test stability
by Harald Welte 14 Feb '21

14 Feb '21

I think this might be of interest to some of the other developers. Soemtimes we have a problem that the test suite itself is not 100% stable, and it's not easy to reproduce a test that fails sporadically every Nth time. As the "execute" statement in the "control" section actually returns a verdict type, you can use the following construct in a control section: control { for (var integer i := 0; i < 10000; i := i+1) { var verdicttype v; v := execute( TC_paging_ps_ptp_lac() ); if (v != pass) { break; } } } This way you keep running the test suite until the given test fails for the first time. Then go do something else for some hour(s) and by the time you get back, hopefully you will have reproduced the problem. 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)

2 2

Inexpensive Huawei GSM Picocells
by Saturn Rocket 13 Feb '21

13 Feb '21

4 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC