OpenBSC February 2019

openbsc@lists.osmocom.org

15 participants
25 discussions

Osmocom-Debian-install-test fails for 10 consecutive days!
by Harald Welte 03 Mar '19

03 Mar '19

Dear Osmocom community, for the last 10 days our "Debian installation test" job is consistently failing, see https://jenkins.osmocom.org/jenkins/job/Osmocom-Debian-install-latest/ It somehow seems to be related to soapySDR mismatching versions where we use a 0.5 package from the debian feed: > Get:358 http://deb.debian.org/debian stretch/main amd64 libsoapysdr0.5-2 amd64 0.5.4-1 [64.4 kB] and mix that with a 0.7 lms7 module from our feed: > Get:425 http://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_9… ./ soapysdr0.7-module-lms7 19.01.0-1 [49.9 kB] > Unpacking soapysdr0.7-module-lms7:amd64 (19.01.0-1) ... > dpkg: error processing archive /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so', which is also in package ... > Errors were encountered while processing: /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) > Build step 'Execute shell' marked build as failure > Finished: FAILURE Does anyone know of any change that would have triggered this? I've created https://osmocom.org/issues/3809 to track this. Regards, Harald -- - Harald Welte <hwelte(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

4 4

fsm: Delaying dispatch of events while we're already inside a dispatch callback.
by Sylvain Munaut 21 Feb '19

21 Feb '19

Hi, Currently if you call osmo_fsm_dispatch from a function that happens to have been triggered by another call to dispatch, things can get a little bit messy (depending on where that callback is in the chain of even that may/may not change the state of the FSM). So what I would propose is that any event dispatched to an FSM will be processed only after the processing of any previous event is fully completed (in the order they were generated). I have a prototype implementation for review on gerrit : https://gerrit.osmocom.org/c/libosmocore/+/12983 Now, this does break some tests, but looking at the breakage, it looks just like message re-ordering at first glance. I guess running the whole full range of test on this would be useful. There are also another consequence is that it's now impossible to return an error code if that event can't be handled in the current state (previously dispatch would return -1). But since the actual dispatch can be deferred ... well, can't do much. Looking at the codebase, that error code is ignored most of the time. When it's returned, it seems to always end up being ignored at the end of the chain (because well ... realistically there isn't much you can do about it anyway, it's a programming bug if it happens). Thoughts / Comments ? Useful ? Crazy idea ? ... Cheers, Sylvain

3 3

less osmo-msc patches
by Neels Hofmeyr 20 Feb '19

20 Feb '19

Hi everyone, let me remind you that I am refactoring the RAN connection in osmo-msc to allow for inter-MSC handover. Patches merged to osmo-msc now are almost guaranteed to produce merge conflicts. Cosmetic changes to RAN code are likely to be obsolete. I would prefer if you guys wouldn't bother for another few weeks. Thanks, ~N

1 0

Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #395
by jenkins＠lists.osmocom.org 20 Feb '19

20 Feb '19

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/395/display/redire…> ------------------------------------------ Started by timer Building remotely on build2-deb9build-ansible (ttcn3 osmo-gsm-tester-build osmocom-gerrit-debian9 osmocom-master-debian9 coverity) in workspace <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/> Wiping out workspace first. Cloning the remote Git repository Cloning repository git://git.osmocom.org/osmo-ci > git init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/> # timeout=10 ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/> at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:772) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:564) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to build2-deb9build-ansible at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at hudson.remoting.Channel.call(Channel.java:955) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146) at sun.reflect.GeneratedMethodAccessor338.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132) at com.sun.proxy.$Proxy87.execute(Unknown Source) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1146) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186) at hudson.scm.SCM.checkout(SCM.java:504) at hudson.model.AbstractProject.checkout(AbstractProject.java:1208) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1810) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Caused by: hudson.plugins.git.GitException: Command "git init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/"> returned status code 1: stdout: stderr: <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/.git>: No space left on device at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:770) ... 11 more ERROR: Error cloning remote repo 'origin'

1 0

OML bringup bugs and compatibility
by Harald Welte 19 Feb '19

19 Feb '19

Dear Osmocom community, It has recently been uncovered that there are some problems in the OML bringup sequence between OsmoBSC and OsmoBTS. Basically, the core of the issue circulates around the RADIO CARRIER managed object. * OsmoBTS is accepting OPSTART even though no attributes (such as ARFCN) are set * OsmoBSC is sending OPSTART twice for this MO, while it's only sending it once for all other MOs The problem now is: If we "fix" the BTS side to reject the OPSTART without prior SET RADIO CARRIER ATTRIBUTES, then older OsmoBSC will stop to work with newer OsmoBTS. The underlying issue is that if we OPSTART the transceiver before setting the ARFCN, then the later setting of attributes is no longer going to do anything, as the radio has already started with "ARFCN 0". TS 12.21 is not very clear on *when* attributes are permitted to be set. The MO can be either locked or unlocked, or it can be enabled or not... My idea so far was that if you want to change attributes of a MO (such as the ARFCN), you need to first bring it down somehow (e.g. set it to "locked"), then make the change and finally bring it online again. A bit of playing with a nanoBTS revealed that it actually permits the OPSTART not only before the attributes are set, but also before the software has even been activated for that MO. This makes no sense whatsoever, though. More details in: https://osmocom.org/issues/3789 and https://osmocom.org/issues/3782, particularly the last few updates to those tickets. Any ideas? -- - 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)

3 4

iPhone X and openbsc
by Akib Sayyed 15 Feb '19

15 Feb '19

Hi list Did any1 tested iPhone X and openbsc I am struggling to get it work. iPhone don't show network. Other phone is working fine.

2 1

BTS logging RTP clock out of synch...
by Gullik Webjorn 14 Feb '19

14 Feb '19

<000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160 (1619189->1619249) <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82592960 vs 160 (1619505->1619436) <000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160 (1619471->1619531) <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82591360 vs 160 (1619587->1619475) <000e> l1sap.c:144 RTP clock out of sync with lower layer: 2080 vs 160 (1619557->1619613) <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82594400 vs 160 (1620892->1620862) <000e> l1sap.c:144 RTP clock out of sync with lower layer: 1440 vs 160 (1620862->1620900) Very large value, is this a typecast / intsize problem ?? Gullik

3 2

LimeSDR rx level and quality
by Gullik Webjorn 13 Feb '19

13 Feb '19

The values reported by the "show connections" command seem suspect to me. I frequently have a uplink value of around -60 dBm, but RXQ values showing 1-4 or so. While I move about a lot, I anticipate fading, but there seems to be a too big BER when compared with the "healthy" signal level. When testing ul / dl on the Mini, I found values that reasonably well corresponded between spectrum analyzer and "show connections". The downlink is, I assume, reported by the MS. The question comes up how to verify the relatively "new" LimeSDR Mini / and the osmo-trx-lms with regards to this issue. I have made some improvements to the TX, and now have a nice +10 - +17 dBm signal which is indicated by the phones. I have more than 100 m range with regards to the phones ( crappy ? ) bargraph indicator, at least 2 bars in the periphery, and always 5 bars inside the house / lab. Antennas are inside, and the house made of timber. However, reception seems to be the limiting factor right now. Q: I have deduced that RXQ is referenced in abis_rsl.c in the bsc, is it just propagated from the sdr up through Transceiver, where is the actual evaluation done? Other thoughts on this.... Regards, Gullik

2 1

osmo-bsc show connections
by Gullik Webjorn 12 Feb '19

12 Feb '19

Hi, I cannot find a description of this command in the manual. This is very useful to debug ms, antennas and radio. OsmoBSC> show conn Active subscriber connections: conn ID=232, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1@mgw BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F Connection: 1, State: ESTABLISHED BS Power: 0 dBm, MS Power: 10 dBm Channel Mode / Codec: SPEECH_V1 No Subscriber Bound IP: 192.168.1.75 Port 16404 RTP_TYPE2=0 CONN_ID=0 Conn. IP: 192.168.1.70 Port 4084 RTP_TYPE=3 SPEECH_MODE=0x00 Measurement Report: Flags: MS Timing Offset: 0 L1 MS Power: 10 dBm, Timing Advance: 4 RXL-FULL-dl: -73 dBm, RXL-SUB-dl: -73 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -57 dBm, RXL-SUB-ul: -58 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 I guess "dl" means downlink, from BTS to MS, and "ul" means uplink, MS to BTS. But, what is the difference between FULL and SUB ? What does the two rightmost items mean, those which are 0 in the above? What does the "No Subscriber" mean, should that be IMSI ? Still on the subject of LimeSDR Mini, now debugging radio and antenna arrangements. Regards, Gullik

4 5

coding style: fixed indenting vs align-with-brace
by Neels Hofmeyr 08 Feb '19

08 Feb '19

Recently, fixeria brought up that it would be better to not align wrapped lines with an opening brace, but rather have a constant indent for wrapped lines. I'd like to ask for the general opinion / kernel style compliance. What indenting is acceptable? For a long time my opinion was that opening brace alignment is better for readability, but my opinion has shifted. I now find it more desirable to keep a constant indent. Consider: unsigned int my_function_signature(int a_very_long_parameter, int wrapped_line, int another_line); If a patch modifies the return value or the name, the patch either touches three lines or leaves inconsistent indenting behind: int my_func(int a_very_long_parameter, int wrapped_line, int another_line); Also, a very long function name wastes a lot of usable linewidth for indent for all arguments. I've submitted a lot of patches over the years that touch more lines than necessary, and left quite a few inconsistent indents behind, because an automatic find-replace doesn't fix subsequent indenting. I'm currently editing a lot of the osmo-msc sources and changing my mind about API, so this line indenting due to renames issue comes up. I thought I could pick a constant indent now while I'm at it. If we had a single tab as indent, the function signatures' indenting would be independent from the length of the name, and a find-replace leaves behind consistent indenting / no whitespace changes needed for renames: unsigned int my_function_signature(int a_very_long_parameter, int wrapped_line, int another_line); int my_func(int a_very_long_parameter, int wrapped_line, int another_line); I finally understood the vim cindent options to achieve this: :se cino=(1s,u1s (Forgive me if this is a bit too vim specific for your taste; I definitely want vim to automatically give me the desired indenting.) My problem with that is that it also affects if- and for- statements: 'if' and 'for' will never change their name, so aligning with opening-brace is unlikely to ever cause unnecessary whitespace change. What was: // vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(0,u0,/0,:0 int my_func(int a_very_long_parameter, int wrapped_line, int another_line) { if (a_very_long_parameter == 3 || a_very_long_parameter < 0 || wrapped_line == 7 || (one_level_deeper && (one_level_deeper || foo))) return 5; } Now becomes: // vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(1s,u1s,/0,:0 int my_func(int a_very_long_parameter, int wrapped_line, int another_line) { if (a_very_long_parameter == 3 || a_very_long_parameter < 0 || wrapped_line == 7 || (one_level_deeper && (one_level_deeper || foo))) return 5; } (The cino=k0 parameter does control 'if', 'for' and 'while' separately, but there is no way to tell it to brace-align while the '(' option is set to '(1s', stupid quirk in cinoptions.) IMHO aligning with opening brace improves readability of the nested conditions and uses more of the line width. But I could get used to that, I guess. I think I've seen this used a lot in Osmocom, too. Another thing to consider: if (a_very_long_parameter == 3 || a_very_long_parameter < 0 || wrapped_line == 7) return has_same_indent_as_condition(" :/ "); I could use two tabs for in-brace indenting, but I haven't seen that anywhere before, and it makes wrapped conditions waste a lot of line width: // vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(2s,u1s,/0,:0 int my_function_signature(int a_very_long_parameter, int wrapped_line, int another_line) { if (a_very_long_parameter == 3 || a_very_long_parameter < 0 || wrapped_line == 7 || (one_level_deeper && (one_level_deeper || foo))) return 5; if (a_very_long_parameter == 3 || a_very_long_parameter < 0 || wrapped_line == 7) return 5; } I think I'll adopt fixed single-tab indenting in my patches from now on: :se cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(1s,u1s,k0,/0,:0 Any (strong) opinions on / best practices for this? Which one is more consistent with linux kernel style? Thanks! ~N

7 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2019