OpenBSC October 2019

openbsc@lists.osmocom.org

8 participants
14 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

Problem while running NIB on Open Cellular Base sation
by Brackley Casinga 31 Jan '24

31 Jan '24

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

2 1

massive VTY related master-osmo-{msc,sgsn} build failures
by Harald Welte 29 Oct '19

29 Oct '19

Dear Osmocom developers, please see the attached messages. I'm getting dozens of these since yesterday, it appears likely some regression was merged? Any help is appreciated. 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

build2.osmocom.org hardware replacement
by Harald Welte 28 Oct '19

28 Oct '19

Hi all, during the past couple of days, there have been a high number of build failures due to 'illegal instruction'. I checked about a handful of them, and they all happened on build2.osmocom.org. On the machine nothing strange could be observed, i.e. no oopses or the like. Also, debsums didn't report any broken compiler binaries. I've taken the builds slaves offline and asked for the machine to be replaced (disks will be moved so no data loss expected). Let's hope that fixes it. If not, I guess a full re-install of OS + lxc's (via ansible) is up next. -- - 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)

1 1

Re: unable to install osmo-bts
by Neels Hofmeyr 23 Oct '19

23 Oct '19

On Mon, Oct 21, 2019 at 05:37:51PM +0100, ah med wrote: > well,for the osmo-all.sh script,it can be found here under Running > examples : > > https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I… Ha, completely forgot about that. I tweaked that wiki page a bit to be less of a pitfall to newcomers (hopefully). BTW, off-list, ah med wrote to us that he figured out to use osmo-trx and osmo-bts-trx but still struggles with the BladeRF. We asked him to come back on-list or visit IRC for further questions. ~N

1 0

Bladerf X40 failure with osmo-trx-uhd
by ah med 22 Oct '19

22 Oct '19

after setting the osmo-bts-trx and osmo-trx-uhd and with a BLADERF X40 ,i just got this when running my network ! every other services like HLR,MSC...work perfectly and just the osmo-trx-uhd have some problems with the bladerf ! osmo-trx-uhd.service - Osmocom SDR BTS L1 Transceiver (UHD Backend) Loaded: loaded (/lib/systemd/system/osmo-trx-uhd.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2019-10-21 20:04:25 CET; 5min ago Process: 20384 ExecStart=/usr/bin/osmo-trx-uhd -C /etc/osmocom/osmo-trx-uhd.cfg (code=exited, status=1/FAILURE) Main PID: 20384 (code=exited, status=1/FAILURE) Oct 21 20:04:24 osmo-trx-uhd[20384]: -- setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz Oct 21 20:04:24 osmo-trx-uhd[20384]: -- setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DDEV <0002> UHDDevice.cpp:355 [tid=140004723987136] Unsupported device bladeRF Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DMAIN <0000> osmo-trx.cpp:514 [tid=140004723987136] Failed to create radio device Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DMAIN <0000> osmo-trx.cpp:485 [tid=140004723987136] Shutting down transceiver... Oct 21 20:04:24 osmo-trx-uhd[20384]: -- bladerf_close() Oct 21 20:04:25 systemd[1]: Stopping Osmocom SDR BTS L1 Transceiver (UHD Backend)... Oct 21 20:04:25 systemd[1]: osmo-trx-uhd.service: Main process exited, code=exited, status=1/FAILURE Oct 21 20:04:25 systemd[1]: osmo-trx-uhd.service: Failed with result 'exit-code'. Oct 21 20:04:25 systemd[1]: Stopped Osmocom SDR BTS L1 Transceiver (UHD Backend). I am using the systemd service file .all parts are installed using apt-get install via the latest builds!. by the way,the uhd_find_devices give the correct output! uhd_find_devices linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.14.1.1-release -------------------------------------------------- -- UHD Device 0 -------------------------------------------------- Device Address: serial: 9e52d2c864bc9b191e8a3327a4b2a216 backend: libusb device: 0x01:0x0E driver: bladerf instance: 0 label: BladeRF #0 [9e52d2c8..a4b2a216] type: soapy bladeRF-cli -p Description: Nuand bladeRF Backend: libusb Serial: 9e52d2c864bc9b191e8a3327a4b2a216 USB Bus: 1 USB Address: 17 bladeRF> version bladeRF-cli version: 1.7.1-2018.12-rc3-2-ppabionic libbladeRF version: 2.2.0-2018.12-rc3-2-ppabionic Firmware version: 1.9.1 FPGA version: 0.10.2 SoapySDRUtil --probe="driver=bladerf" ###################################################### ## Soapy SDR -- the SDR abstraction library ## ###################################################### Probe device driver=bladerf [INFO] bladerf_open_with_devinfo() [WARNING @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1705] RX DC calibration table not found. Manual gain control will be used instead. [INFO @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1706] To enable AGC, see "Generating a DC offset table" at https://github.com/Nuand/bladeRF/wiki/DC-offset-and-IQ-Imbalance-Correction [INFO] bladerf_get_serial() = 9e52d2c864bc9b191e8a3327a4b2a216 [INFO] setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz [INFO] setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz [WARNING @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1705] RX DC calibration table not found. Manual gain control will be used instead. [INFO @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1706] To enable AGC, see "Generating a DC offset table" at https://github.com/Nuand/bladeRF/wiki/DC-offset-and-IQ-Imbalance-Correction ---------------------------------------------------- -- Device identification ---------------------------------------------------- driver=bladeRF hardware=bladerf1 fpga_size=40 fpga_version=0.10.2 fw_version=1.9.1 serial=9e52d2c864bc9b191e8a3327a4b2a216 ---------------------------------------------------- -- Peripheral summary ---------------------------------------------------- Channels: 1 Rx, 1 Tx Timestamps: YES Registers: LMS Other Settings: * XB200 Transverter - bladeRF XB200 Transverter Board [key=xb200, default=disabled, type=string, options=(disabled, 50M, 144M, 222M, auto1db, auto3db, auto, custom)] * Sampling Mode - Internal = Via RX/TX connectors, External = Direct sampling from J60/J61 connectors [key=sampling_mode, default=internal, type=string, options=(internal, external)] * Loopback Mode - Enable/disable internal loopback [key=loopback, default=none, type=string, options=(none, firmware, bb_txlpf_rxvga2, bb_txlpf_rxlpf, bb_txvga1_rxvga2, bb_txvga1_rxlpf, rf_lna1, rf_lna2, rf_lna3)] * Reset Device - Reset the device, causing it to reload its firmware from flash. [key=reset, default=false, type=bool, options=(true, false)] * Erase the FPGA region of flash - Erase the FPGA region of SPI flash, effectively disabling FPGA autoloading. [key=erase_stored_fpga, default=false, type=bool, options=(true, false)] * Write FX3 firmware to flash - Write FX3 firmware to the bladeRF's SPI flash from the provided file path. This will require a power cycle to take effect. [key=flash_firmware, type=string] * Write to the FPGA region of flash - Write FPGA image to the bladeRF's SPI flash from the provided file path and enable FPGA loading from SPI flash at power on. [key=flash_fpga, type=string] * Clear out a firmware signature word in flash and jump to FX3 bootloader - The device will continue to boot into the FX3 bootloader across power cycles until new firmware is written to the device. [key=jump_to_bootloader, default=false, type=bool, options=(true, false)] * Load device's FPGA - Load device's FPGA from the provided file path. Note that this FPGA configuration will be reset at the next power cycle. [key=load_fpga, type=string] GPIOs: CONFIG, EXPANSION ---------------------------------------------------- -- RX Channel 0 ---------------------------------------------------- Full-duplex: YES Supports AGC: NO Stream formats: CS16, CF32 Native format: CS16 [full-scale=2048] Stream args: * Buffer Count - Number of async USB buffers. [key=buffers, units=buffers, default=32, type=int] * Buffer Length - Number of bytes per USB buffer, the number must be a multiple of 1024. [key=buflen, units=bytes, default=4096, type=int] * Num Transfers - Number of async USB transfers. Use 0 for automatic [key=transfers, units=bytes, default=0, type=int, range=[0, 32]] Antennas: RX Corrections: DC offset, IQ balance Full gain range: [-1, 60, 1] dB lna gain range: [0, 6, 3] dB rxvga1 gain range: [5, 30, 1] dB rxvga2 gain range: [0, 30, 3] dB Full freq range: [237.5, 3800] MHz RF freq range: [237.5, 3800] MHz Sample rates: [0.08, 10], [10, 20], [20, 40] MSps Filter bandwidths: [1.5, 28] MHz ---------------------------------------------------- -- TX Channel 0 ---------------------------------------------------- Full-duplex: YES Supports AGC: NO Stream formats: CS16, CF32 Native format: CS16 [full-scale=2048] Stream args: * Buffer Count - Number of async USB buffers. [key=buffers, units=buffers, default=32, type=int] * Buffer Length - Number of bytes per USB buffer, the number must be a multiple of 1024. [key=buflen, units=bytes, default=4096, type=int] * Num Transfers - Number of async USB transfers. Use 0 for automatic [key=transfers, units=bytes, default=0, type=int, range=[0, 32]] Antennas: TX Corrections: DC offset, IQ balance Full gain range: [17, 73, 1] dB txvga1 gain range: [-35, -4, 1] dB txvga2 gain range: [0, 25, 1] dB Full freq range: [237.5, 3800] MHz RF freq range: [237.5, 3800] MHz Sample rates: [0.08, 10], [10, 20], [20, 40] MSps Filter bandwidths: [1.5, 28] MHz [INFO] bladerf_close()

3 2

unable to install osmo-bts
by ah med 21 Oct '19

21 Oct '19

HI Hope that you are doing well! system : Ubuntu 18.04.3 LTS when trying to start the osmocom CNI using the osmo-all script i will get : ./osmo-all.sh restart > + systemctl restart osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn > osmo-stp osmo-bsc osmo-hnbgw osmo-bts-sysmo osmo-pcu > Failed to restart osmo-bts-sysmo.service: Unit osmo-bts-sysmo.service not > found. > so seems that osmo-bts it's not installed,wjen i try to install it will get : sudo apt-get install osmo-bts > > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > osmo-bts : Depends: libosmoabis5 (>= 0.3.2+20151106git86fc3c8) but it is > not going to be installed > E: Unable to correct problems, you have held broken packages. and when trying to install libosmoabis5 i will get : sudo apt-get install libosmoabis5 > The following packages will be REMOVED: > libosmo-gsup-client0 libosmoabis6 osmo-bsc osmo-bts-trx osmo-bts-virtual > osmo-hlr osmo-msc osmo-sgsn > The following NEW packages will be installed: > libosmoabis5 > 0 upgraded, 1 newly installed, 8 to remove and 0 not upgraded. > thanks in advnace!

3 2

Re: libosmovty version is UNKNOWN
by Vadim Yanitskiy 21 Oct '19

21 Oct '19

Hi, > libosmocore.so.4 -> libosmocore.so.4.0.0 > libosmovty.so.0 -> libosmovty.so.0.0.0 it looks like you have installed a very old libosmocore. You need to remove it (make uninstall) and install the recent one from the upstream (not from OsmocomBB). With best regards, Vadim Yanitskiy.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2019