OpenBSC January 2021

openbsc@lists.osmocom.org

7 participants
10 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, 1 week

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, 2 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

4 months, 1 week

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, 7 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, 5 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, 6 months

OsmoHNBGW M3UA IPSP mode

by Mirko Kovacevic

Hello, not many discussions found on OsmoHNBGW topic. 1. Can we connect O' HNBGW directly to SGSN without STP (IPSP mode)? 2. If not, I am wondering do OSMOCOM have development support for IPSP M3UA mode in SIGTRAN development files or elsewhere? Thank you in advance, and keep shaking mobile development world. Mirko K.

4 years, 7 months

SMPP Alert Notifications

by Keith

Hi Osmocom Community. I'd like to extend the SMPP protocol alert notifications to be able to differentiate between IMSI_ATTACH, NORMAL and PERIODIC LURs The reason is to be able to react to an initial attach by sending a "Welcome" SMS. SMPP specifies only three status possibilities: 0 = Available 1 = Disabled 2 = Not Available (Detaching) I've added 3 for IMSI_ATTACH - Actually I ended up using != PERIODIC because not all phones send an ATTACH after a DETACH, some send NORMAL LUR. With this the ESME can respond to an alert notification that has status 3 by looking up the IMSI to see if it's known/autorised etc (this is outside of osmo-hlr in my use case, although I guess it could also be done by checking what the HLR says inside the MSC) Anyway.. I'm wondering if anybody else ever did this, and do we want/accept this functionality in master osmo-msc? Or.. any better ideas on how to do it? Thanks k/

4 years, 8 months

OsmoBSC - SCCP Connection to Nokia MSC

by Sonny Lafuente

Hi Community, Happy New Year! Would like to ask if anyone here have experience integrating OsmoBSC to Nokia MSC? Currently we are doing the integration in Nokia MSC and we encountered issue. Basically, in the SCCP part, the BSC is trying to send UDT (BSSAP) Reset but no response from the MSC. After the default timer of the RESET, we observed a SACK SST and SACK UDTS. In the SACK SST, we saw the trace that there is no Calling indicator which is my BSC point code. When checking the trace we saw this Affected Subsystem Number: 254. I’ve red some documentations in OSMO but I don’t find any SCCP management configuration in OSMO so I think this one is on MSC side. Below is the Trace we captured. BSC Point code - 2262 Nokia Point code - 7039 Regards, Sonny

4 years, 8 months

set a c/c++ standard for all osmocom core network projects

by Alexander 'lynxis' Couzens

Hi, I would like to start a discussion to set for all osmocom core network projects a language standard (could be also set for other osmocom projects). The current state is the code is compiled with the compilers choice of c/c++. This produce unexpected build failures on newer or older system. I would like to start setting it to c11/c++11 + gnu extensions. This is a more random choice of standard. I would argue to have at least c99 for c. Any feedback? Best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

4 years, 8 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2021