OpenBSC

openbsc@lists.osmocom.org

1 participants
4317 discussions

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

libosmovty version is UNKNOWN
by Josip Stjepanović 20 Oct '19

20 Oct '19

Hello, Unfortunately I have come up to the problem that I can't google myself and my friends can't help with either. Maybe it has something to do with readme saying that libsomocore in the git I pulled isn't for system wide installation but when I make the osmocombb src then it spits out this: configure: error: Package requirements (libosmovty >= 0.10.0) were not met: Requested 'libosmovty >= 0.10.0' but version of Osmocom VTY Interface Library is UNKNOWN Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBOSMOVTY_CFLAGS and LIBOSMOVTY_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Makefile:94: recipe for target 'host/layer23/Makefile' failed make: *** [host/layer23/Makefile] Error 1 If I need to get a different libosmocore could you provide it to me? Thank you

2 1

optional steps in ttcn3 interleave
by Neels Hofmeyr 18 Oct '19

18 Oct '19

Hi, I've got the problem that optional steps seem to not be possible in 'interleave' statements. What I want: accept either BSSMAP Assignment Request or Iu Rab Assignment: interleave { [g_pars.ran_is_geran] BSSAP.receive(tr_BSSMAP_AssignmentReq) { ... }; [not g_pars.ran_is_geran] BSSAP.receive(tr_RANAP_RabAssReq(rab_sml)) { ... }; [] other {...}; [] complex {...}; [] steps {...}; } But that's illegal syntax; works for altsteps, but not for interleave. Even in the language spec, there is no token between the interleave braces. How unfortunate. Options I am considering: 1) moving the optionals into a separate altstep var default assignment; if (g_pars.ran_is_geran) { assignment := activate(as_BSSMAP_assignment()); } else { assignment := activate(as_RANAP_assignment()); } interleave { [] other {...}; [] complex {...}; [] steps {...}; } deactivate(assignment); or 2) blatant code dup if (g_pars.ran_is_geran) { interleave { [] BSSAP.receive(tr_BSSMAP_AssignmentReq) { ... }; [] other {...}; [] complex {...}; [] steps {...}; } } else { interleave { [] BSSAP.receive(tr_RANAP_RabAssReq) { ... }; [] other {...}; [] complex {...}; [] steps {...}; } } 3) boolean dance and break var boolean done1 := false; var boolean done2 := false; var boolean done3 := false; var boolean done4 := false; interleave { [] BSSAP.receive(tr_BSSMAP_AssignmentReq) { if (not g_pars.ran_is_geran) { setverdict(fail); } done1 := true; if (done1 and done2 and done3 and done4) { break; } }; [] BSSAP.receive(tr_RANAP_RabAssReq(rab_sml)) { if (g_pars.ran_is_geran) { setverdict(fail); } done1 := true; if (done1 and done2 and done3 and done4) { break; } }; [] other { done2 := true; if (done1 and done2 and done3 and done4) { break; } }; [] complex { done3 := true; if (done1 and done2 and done3 and done4) { break; } }; [] steps { done4 := true; if (done1 and done2 and done3 and done4) { break; } }; } 1) is bad because the interleave may exit without having seen an actual assignment at all. Also interacting with local variables isn't allowed in this kind of altstep. Also if there are more optional parts, the side-altsteps become hard to understand. Also the altstep needs to "repeat;" so that it doesn't break the outer interlave, which makes us accept more than one of the optional message. 2) is bad because it is code dup. 3) is bad because of code clutter that is likely to cause weird failure when the interleave is modified. I am already using this method somewhere... but. Are there other options?? Why is this coming up? I am preparing for a change in osmo-msc during call setup, and I am making the ttcn3 call testing more flexible and cleaning things up. As a result, some more tests are moved to using f_mo_call_establish() instead of copy-pasting it. That makes some Iu tests go from passed to FAIL, because the f_mo_call_establish() is unable to do the above distinguishing between BSSMAP and IU. We can also choose to ignore those Iu tests that start to fail. But I am curious whether there is a way for optional interleave steps in ttcn3. Thanks, ~N

2 2

gerrit update / reply by e-mail
by Harald Welte 11 Oct '19

11 Oct '19

Dear Osmocom community, I just upgraded gerrit to 2.16.12, the latest version of the 2.16 branch, still featuring the option to use the old UI. While reading through change logs, I just discovered that one can actually send responses to gerrit e-mail notifications, and those changes will end up creating new comments int he gerrit database/UO: http://gerrit-documentation.storage.googleapis.com/Documentation/2.14/intro… Maybe that's useful for some of you here... 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)

1 0

DW-TV report on Rhizomatica, TIC and Osmocom/sysmocom
by Harald Welte 01 Oct '19

01 Oct '19

Hi all, DW-TV has just released a video report on the community owned and operated cellular networks within TIC, the Mexican partner of Rhizomatica. You can find the (Spanish only) video at https://www.dw.com/es/telefon%C3%ADa-ind%C3%ADgena-en-defensa-del-derecho-a… I recommend to watch the full video to catch some glimpses into the life of people in one of the communities operating their own Osmocom based cellular network. If you don't have the time to follow the full video, some pointers below: * from 4:35 you can see how the taxi service (the only form of public transport!) can pick up people anywhere in the region after they make a mobile phone call * from 12:50 onwards, the BTS is introduced, and its role (and that of the BSC) are explained in a nice animation. * from 18:49 you can see the part covering the role Osmocom and sysmocom are playing in the development of the underlying technology. You can also catch a glimpse of the sysmocom office Especially for somebody who's never been there in person, it is very enlightening to see more about how people use it. And the technology geek in me of course enjoys the work related to power supply, including the home-made inverter for solar charging (from 16:12) Let me conclude with the statement that I'm extremely happy about (and proud of) the amazing work that Rhizomatica, TIC and friends are doing. It's great to see Osmocom code being put to use in such a meaningful way, and for what it was crated: To enable people (literally anyone) to operate their own cellular networks in whatever way, independent of large multi-national corporations. There are just very few places where people have actually managed to do this, given all the legal, political, economic constraints, including spectrum licensing. Thanks to Peter, Keith and his colleagues for dedicating many years to this cause. Thanks to DW-TV and Eva Usi (the reporter behind this piece). Further links (in case you weren't aware of those projects/entities): https://www.rhizomatica.org/ https://www.tic-ac.org/ 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 4

Fwd: Build failure of network:osmocom:nightly/libosmo-netif in Debian_8.0/x86_64
by Harald Welte 30 Sep '19

30 Sep '19

In case this wasn't noticed yet, libosmo-netif doesn't build (pass "make check") on debian 8 anymore. This clearly looks like a regression. It happens both on x86_64 and on armv7l. Thanks in advance for anyone finding time to investigate. Cheers (from holidays), Harald -------- Original Message -------- From: OBS Notification <admin(a)opensuse.org> Sent: September 19, 2019 3:44:40 AM GMT+02:00 To: Alexander Couzens <lynxis(a)fe80.eu>, Harald Welte <laforge(a)gnumonks.org>, OpenBSC gerrit-log Mailing List <gerrit-log(a)lists.osmocom.org> Subject: Build failure of network:osmocom:nightly/libosmo-netif in Debian_8.0/x86_64 Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… Package network:osmocom:nightly/libosmo-netif failed to build in Debian_8.0/x86_64 Check out the package for editing: osc checkout network:osmocom:nightly libosmo-netif Last lines of build log: [ 124s] autoreconnecting test step 3 [client OK, server OK], FD reg 1 [ 124s] [ 124s] autoreconnecting test step 2 [client OK, server OK], FD reg 0 [ 124s] + [ 124s] +autoreconnecting test step 1 [client OK, server OK], FD reg 0 [ 124s] connection closed with srv [ 124s] [ 124s] -autoreconnecting test step 1 [client OK, server NA], FD reg 0 [ 124s] +autoreconnecting test step 0 [client OK, server NA], FD reg 0 [ 124s] [ 124s] non-reconnecting test step 7 [client NA, server OK], FD reg 1 [ 124s] [ 124s] 1. testsuite.at:4: 1. stream_test (testsuite.at:4): FAILED (testsuite.at:8) [ 124s] debian/rules:27: recipe for target 'override_dh_auto_test' failed [ 124s] make[1]: *** [override_dh_auto_test] Error 1 [ 124s] make[1]: Leaving directory '/usr/src/packages/BUILD' [ 124s] debian/rules:13: recipe for target 'build' failed [ 124s] make: *** [build] Error 2 [ 124s] dpkg-buildpackage: error: debian/rules build gave error exit status 2 [ 124s] [ 124s] build30 failed "build libosmo-netif_0.6.0.2.a1e9.dsc" at Thu Sep 19 01:44:36 UTC 2019. [ 124s] [ 124s] ### VM INTERACTION START ### [ 125s] Powering off. [ 125s] [ 106.236806] reboot: Power down [ 125s] ### VM INTERACTION END ### [ 125s] [ 125s] build30 failed "build libosmo-netif_0.6.0.2.a1e9.dsc" at Thu Sep 19 01:44:38 UTC 2019. [ 125s] -- Configure notifications at https://build.opensuse.org/user/notifications openSUSE Build Service (https://build.opensuse.org/) -- Sent from a mobile device. Please excuse my brevity.

3 2

C/C++ dialect defaults
by Oliver Smith 18 Sep '19

18 Sep '19

Hello Osmocom community, how about we set the C and C++ dialect defaults in for each Osmocom program? Then we would not run into the kind of errors, where code compiled without errors in the gerrit verification jenkins job, but failed to compile elsewhere because a different GCC uses different default dialects. We ran into this already with differences in gerrit verification and master builds [1], and it can easily happen when building the binary packages for the various Debian versions and derivatives in OBS. In [2] is an example patch for OsmoPCU, hardcoding the following dialects (gnu89 is the same as the linux kernel uses [3]). CXXFLAGS="$CXXFLAGS -std=gnu++03" CFLAGS="$CFLAGS -std=gnu89" (Note that we can't use the non-gnu dialects, libosmocore won't build with those.) Is anybody against doing this, or has other recommendations for dialects we should use? Regards, Oliver [1] https://osmocom.org/issues/3598 [2] https://gerrit.osmocom.org/c/osmo-pcu/+/15565 [3] https://github.com/torvalds/linux/commit/51b97e354ba9fce1890cf38ecc754aa496… -- - 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC