OpenBSC

openbsc@lists.osmocom.org

1 participants
4317 discussions

Fwd: Support for new SDR devices
by Xaver Zu 11 Sep '20

11 Sep '20

That library does a lot of work. Configures HW, sends samples to FPGA via DMA, does calibration, normalization, format conversions ... Highly optimized for Intel CPU. If everything were to be done in an equivalently closed version, it would take several years of work for me. I would like to start with a simple proof-of concept. Implementing only the functions used in osmo-trx-pciesdr. In the first phase, these can be only dummy functions writing or reading zeros. I assume that the GPL violation problem will be solved from the moment I will be able to build the library and link it with osmo-trx and run it. The next step is just a matter of effort from anyone in the community. Xaver

1 0

Re: Support for new SDR devices
by Harald Welte 11 Sep '20

11 Sep '20

Hi Xaver, On Fri, Sep 11, 2020 at 07:51:50AM +0200, Xaver Zu wrote: > I created a short Wiki page. Please see if it's enough as a link to a > commit message. > https://osmocom.org/projects/sdr/wiki/PCIeSDR Thanks. For sure it is sufficient in terms of content. I did some minor reformatting while reading. However, I found a major problem. You state: > The higher-level driver (in userspace) includes a DSP, a calibration stage, and the gateware update. It is in the form of a closed source dynamic library named libsdr.so. The C API for Linux / x86 is in the form of a header file libsdr.h which also serves as brief documentation. This is incompatible with the strong copyleft licensing (AGPLv3) of osmo-trx! You cannot directly link with a proprietary library. The only way I can see a PCIeSDR backend for osmo-trx would be via osmo-trx-ipc, which provides a general-purpose sharde memory interface to another process. The other process can then use the non-free library, if you want that. -- - 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)

1 0

OsmoDevCon / COVID-19
by Harald Welte 07 Sep '20

07 Sep '20

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. 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)

3 2

Re: New Defects reported by Coverity Scan for Osmocom
by nhofmeyr＠sysmocom.de 26 Aug '20

26 Aug '20

On Tue, Aug 25, 2020 at 02:49:39AM +0000, scan-admin(a)coverity.com wrote: > *** CID 212862: Error handling issues (CHECKED_RETURN) > /source-Osmocom/osmo-pcu/src/pdch.cpp: 211 in gprs_rlcmac_pdch::packet_paging_request()() > 205 > 206 /* loop until message is full */ > 207 while (pag) { > 208 if (log_check_level(DRLCMAC, LOGL_DEBUG)) { > 209 struct osmo_mobile_identity omi = {}; > 210 char str[64]; > >>> CID 212862: Error handling issues (CHECKED_RETURN) > >>> Calling "osmo_mobile_identity_decode" without checking return value (as is done elsewhere 20 out of 22 times). > 211 osmo_mobile_identity_decode(&omi, pag->identity_lv + 1, pag->identity_lv[0], true); > 212 osmo_mobile_identity_to_str_buf(str, sizeof(str), &omi); > 213 LOGP(DRLCMAC, LOGL_DEBUG, "Paging MI - %s\n", str); > 214 } I'd like to let you guys know that I intentionally don't check the return value here. This is only for logging the mobile identity, and if decoding fails, the logging should just show "NONE". ~N

2 1

Patches and Packaging for Erlang Components
by Matthew Johnson 25 Aug '20

25 Aug '20

Hello! I was able to use the experimental osmo_dia2gsup converter to successfully enable circuit switched fallback in a test network, but have a couple fixes for it and osmo_ss7 needed to work with the latest 2G CN components. I would open a change request in gerrit, but I see that the rebar.conf of osmo_dia2gsup already depends on a WIP branch from osmo_ss7. How best should I provide patches for review? Is there ongoing work in http://git.osmocom.org/erlang/osmo_ss7/log/?h=laforge/wip that needs to be merged first, and is there a reason it has not been merged already? Otherwise should I open a change request towards the WIP branch? Also, do folks have any opinions on how best to package erlang components? I was going to generate a Debian package for a stand-alone erlang “release” of osmo_dia2gsup, and am happy to contribute the debian metadata and build files upstream, but I am not an erlang expert and want to make sure it’s structured in the correct way if there is a convention I should follow. >From a random sample it looks like none of the other erlang components are packaged, so I don’t have a good example to go from. If there is no opinion I will make an attempt, but I wanted to ask first! Thanks for your help and patience! -Matt J.

2 2

openBSC with commercial BTS
by Ivan Babanov 24 Aug '20

24 Aug '20

Hello, I see that currently openBSC/osmoBSC works with a number of old commercial BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis. My question is, did somebody try something newer than Nokia UltraSite? I have an ability to try with FlexiBTS rel.3 with Abis over IP. I'm trying to find out if maybe it was already tried and had some unresolveable problems? Please let me know if any. Thank you Ivan

4 5

Support for new SDR devices
by Xaver Zu 17 Aug '20

17 Aug '20

Hi all, What are the plans to expand support for new SDR devices? When I check the contents of osmo-trx/Transceiver52M/device/ on the git master I see the supported lms, uhd and usrp1 devices. For example the XTRX SDR was presented at OsmoDevCon 2018. I expected it to be included in the master soon. At this point I see its addition in the fairwaves / libxtrx-wip branch from 2018. That doesn't give me much encouragement for my next question. Would it be possible to add support for PCIe SDR from Amarisoft? Some information about SDR is here https://discourse.myriadrf.org/t/amarisoft-sdr-integration-with-oai/2288 Based on the https://media.ccc.de/v/osmocon2018-82-osmotrx-status-support-for-more-drive… I tried to create support by myself. I've gotten into a state that some MS with weak requirements for signal quality and timing can connect. My branch is here https://github.com/XK1ZU/osmo-trx/tree/PCIeSDR-LMSstyle gr-osmosdr support is here https://github.com/XK1ZU/gr-osmosdr/commits/PCIeSDR This osmo-trx is able to run for a few tens of seconds then it quits and I have to restart it, so I would need a deeper understanding of the timing and scheduling of processes within osmo-trx. Who should be a clock master SW stack or SDR device? I see a lot of log error messages as 0000> Transceiver.cpp:422 [tid=140137319651072][chan=0] dumping STALE burst in TRX->SDR interface (1:1408722 vs 7:1408723), retrans=0 <0000> Transceiver.cpp:1122 [tid=140137311258368] ClockInterface: sending IND CLOCK 1408899 or 0000> Transceiver.cpp:280 [tid=140137328043776] Starting the transceiver <0000> radioInterface.cpp:181 [tid=140137328043776] Starting radio device <0000> PCIESDRDevice.cpp:199 [tid=140137328043776] PCIESDRDevice::start <0000> PCIESDRDevice.cpp:205 [tid=140137328043776] starting PCIeSDR..., sample rate:1.08333e+06 <0000> PCIESDRDevice.cpp:234 [tid=140137328043776] PCIESDRDevice::flush <0000> PCIESDRDevice.cpp:219 [tid=140137328043776] msdr_start ok: <0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment <0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment <0000> radioInterface.cpp:202 [tid=140137328043776] Radio started <0000> Threads.cpp:119 [tid=140137294472960] Thread 140137294472960 (task 18522) set name: TxLower <0000> Threads.cpp:119 [tid=140137311258368] Thread 140137311258368 (task 18524) set name: RxUpper0 <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP POWERON 0' <0000> Threads.cpp:119 [tid=140137302865664] Thread 140137302865664 (task 18523) set name: RxLower <0002> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0 <0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested timestamp is not valid <0000> Threads.cpp:119 [tid=140137319651072] Thread 140137319651072 (task 18525) set name: TxUpper0 <0002> PCIESDRDevice.cpp:365 [tid=140137302865664] timestamp = 10960, length = 262144, time_start = 6765960, time_end = 6766960, data_start = 223320, data_end = 224320 <0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:3 rx_overflow_count:0 <0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun ts_tmp:10976 ts:10960 hwts:6762040 <0000> radioInterface.cpp:334 [tid=140137302865664] Receive error 0 <0000> Transceiver.cpp:1162 [tid=140137302865664] Something went wrong in thread RxLower, requesting stop <0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:4 rx_overflow_count:0 <0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun ts_tmp:13476 ts:13460 hwts:6762278 <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETRXGAIN 40' <0000> PCIESDRDevice.cpp:318 [tid=140137328043776] Setting RX gain to 40 dB. <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETRXGAIN 0 40' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETPOWER 0' <0000> PCIESDRDevice.cpp:297 [tid=140137328043776] Setting TX gain to 60 dB. device:0x1f6e0e0 chan:0 <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETPOWER 0 0' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 0 5' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 0 5' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 1 7' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 1 7' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 2 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 2 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 3 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 3 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 4 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 4 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 5 8' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 5 8' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 6 8' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 6 8' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 5 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 5 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 7 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 7 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 6 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 6 13' <0000> osmo-trx.cpp:485 [tid=140137400406720] Shutting down transceiver... <0000> Transceiver.cpp:338 [tid=140137400406720] Stopping the transceiver <0000> Transceiver.cpp:351 [tid=140137400406720] Stopping the device <0000> PCIESDRDevice.cpp:254 [tid=140137400406720] PCIESDRDevice::stop <0000> PCIESDRDevice.cpp:261 [tid=140137400406720] PCIESDR stopped <0000> Transceiver.cpp:364 [tid=140137400406720] Transceiver stopped <0000> PCIESDRDevice.cpp:78 [tid=140137400406720] Closing PCIESDR Device Yours XK1Zu

5 7

Re: osmo-mslookup-client.c
by Neels Hofmeyr 13 Aug '20

13 Aug '20

Hi Edgard, thanks for your interest in the Osmocom project. On Sat, Aug 08, 2020 at 08:56:08PM +0100, Edgard Ndassimba wrote: > I have difficulte to implemente osmo-mslookup-client.c I'm sorry, I don't understand the question... I looked, and I notice that osmo-mslookup-client is missing from the binary packages. I opened a bug tracker for it: https://osmocom.org/issues/4706 If you want to use osmo-mslookup-client, you need to build osmo-hlr manually. For that, please look at https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source MSLookup and DGSM are explained in http://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf chapter "12 Distributed GSM / Multicast MS Lookup" If you have more questions about this, please write an email to openbsc(a)lists.osmocom.org or ask on IRC: FreeNode #osmocom Please write to the mailing list, and not to me personally. That way you have more people that can help you, and more people can learn from your progress. Thanks! ~N > > I use ubuntu 16.04 LTS amd64 > > Could you help me please? > > Best Regards > > -- > Edgard NDASSIMBA

1 0

ttcn3-bsc-test-latest status
by Neels Hofmeyr 13 Aug '20

13 Aug '20

I recently broke ttcn3-bsc-test-latest for a couple of builds, which is fixed now. Still it appears like some 'latest' tests remain damaged, but that is actually not the case. Here a summary of those that look like failures but are expected: TC_chan_rel_rr_cause: the test is new and tests a feature not implemented in 'latest' yet. TC_chan_rqd_emerg_deny: the test is new and I'm not sure of its 'latest' status. TC_si2quater_2_earfcns, TC_si2quater_3_earfcns: osmo-ttcn3-hacks just now merged a patch that also tests EARFCN presence in a Channel Release message. Since 'latest' still has a bug that causes only the first EARFCN to appear in that message, these two tests now fail in 'latest'. TC_cbsp_emerg_write_bts_cgi_cchan: This used to fail, then during the massive failures it suddenly passed for a bit, and now fails again. The passes must have been flukes. ~N

1 0

build trigger thunder cloud
by Neels Hofmeyr 12 Aug '20

12 Aug '20

Today I noticed that osmo-msc-master was being built several times in a row and I found there are multiple redundant ricocheting downstream builds of the same original upstream build timer. All of: https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18894/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18895/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18896/ show: Started by upstream project master-libosmocore build number 1624 And then there are: https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18897/ https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18898/ showing: Started by upstream project master-libosmo-abis build number 2611 So there are two timers launching master-libosmocore and launching master-libosmo-abis, and each of these cause multiple downstream build triggers of osmo-msc. Then there is also the osmo-msc timer, independently launching more nightly master-osmo-msc builds. It is not necessary to depend these builds on each other, because none of them depends on artifacts built in another job, each of them in turn builds the entire chain of libosmocore up to that build's target project. Upon a libosmocore *code change*, it makes sense to trigger downstream builds, but not when caused by a timer or for other jenkins trigger or user reasons. I vaguely remember discussing this before, but now I realize we could solve this and have less redundant builds: Do not configure libosmocore to trigger downstream builds of master-libosmo-abis (and so on), but instead trigger master-libosmo-abis upon each libosmocore patch merge. That can be done by adding a "Gerrit trigger" on the master-libosmo-abis build job config, making a patch-merge to the gerrit libosmocore.git cause a master-libosmo-abis build. At that point, jenkins timers no longer cause downstream builds, but merges to master on upstream git repositories do still cause builds. (maybe there is also a normal git SCM way that doesn't require gerrit.osmocom.org?) For projects like osmo-msc, we would add multiple projects as upstream git repositories, like libosmocore, libosmo-abis, libosmo-netif, ... , osmo-iuh, osmo-mgw, ... Basically all of the projects with more than one dependency get retriggered redundantly every night, some doing their entire build matrix over several times for no good reason. I'm not sure that it's really worth the effort, but I thought I'd mention it since seeing so many redundant builds on various osmo source trees at night seems avoidable stupidity. Should someone spend cycles to implement this? ~N

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC