Open Source Mobile Communications: Issueshttps://www.osmocom.org/https://www.osmocom.org/favicon.ico?16647414092024-03-26T13:03:08ZOpen Source Mobile Communications
Redmine OsmoBSC - Bug #6422 (Feedback): latest: BSC_Tests.TC_ctrl_location started fo fail on March 15thhttps://www.osmocom.org/issues/64222024-03-26T13:03:08Zlaforge
<ul>
<li><a class="external" href="https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bsc-test-sccplite/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bsc-test-sccplite/test_results_analyzer/</a></li>
</ul>
<p>This test used to pass and started failing since March 15. It fails consistently ever since. Interestingly, master is not affected.</p>
<p>I don't see any commits to osmo-ttcn3-hacks.git touching the BSC code which were merged on March 14th.</p>
<p>Does anyone have any ideas?</p> OsmoMSC - Bug #6414 (Feedback): ttcn3-msc-test: TC_ho_inter_bsc_a5_[134] are failing with io_uringhttps://www.osmocom.org/issues/64142024-03-22T07:59:15Zfixeria
<p>Since recently, we started executing ttcn3-msc-test (among with some other testsuites) with <code>LIBOSMO_IO_BACKEND=IO_URING</code> in a separate job. Compared to the "normal" job, the IO_URING one exhibits a regression since <a href="https://jenkins.osmocom.org/jenkins/view/TTCN3-io_uring/job/ttcn3-msc-test-io_uring/5/" class="external">build 5</a> (Mar 15, 2024):</p>
<ul>
<li>TC_ho_inter_bsc_a5_3 is failing "reliably",</li>
<li>TC_ho_inter_bsc_a5_<sup><a href="#fn14">14</a></sup> are alternating between pass and fail.</li>
</ul>
<p>I was unable to reproduce the problem, neither locally on my machine nor on the dedicated build server in Docker env.</p> Cellular Network Infrastructure - Bug #6349 (Feedback): example configs missing in release tarballshttps://www.osmocom.org/issues/63492024-01-28T15:42:07Zfixeria
<p>Today I created a release <code>osmo-bts v1.7.2</code> package for Arch Linux:</p>
<p><a class="external" href="https://aur.archlinux.org/packages/osmo-bts">https://aur.archlinux.org/packages/osmo-bts</a><br /><a class="external" href="https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=osmo-bts">https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=osmo-bts</a></p>
<p>which downloads, unpacks, and builds the latest release tarball:</p>
<p><a class="external" href="https://downloads.osmocom.org/releases/osmo-bts/osmo-bts-1.7.2.tar.bz2">https://downloads.osmocom.org/releases/osmo-bts/osmo-bts-1.7.2.tar.bz2</a></p>
<p>Unfortunately, I am hitting a build error when running <code>makepkg</code>:</p>
<pre>
Making all in doc
make[2]: Entering directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc'
Making all in examples
make[3]: Entering directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc/examples'
make[3]: *** No rule to make target 'trx/osmo-bts-trx.cfg', needed by 'all-am'. Stop.
make[3]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc/examples'
make[2]: *** [Makefile:387: all-recursive] Error 1
make[2]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc'
make[1]: *** [Makefile:446: all-recursive] Error 1
make[1]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2'
make: *** [Makefile:378: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
</pre>
<p>The problem can be reproduced by downloading and building the tarball manually (make sure to build with <code>--enable-trx</code>).</p>
<p>Surprisingly, <code>trx/osmo-bts-trx.cfg</code> is not present in the release tarball:</p>
<pre>
$ tar -tvf osmo-bts-1.7.2.tar.bz2 | grep doc/examples
drwxr-xr-x 1000/1000 0 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/
-rw-r--r-- 1000/1000 23617 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/Makefile.in
drwxr-xr-x 1000/1000 0 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/virtual/
-rw-r--r-- 1000/1000 1271 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/virtual/osmo-bts-virtual.cfg
-rw-r--r-- 1000/1000 1501 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/Makefile.am
</pre>
<p>I believe the problem is that in <code>doc/examples/Makefile.am</code> we add config files to <code>EXTRA_DIST</code> conditionally:</p>
<pre><code class="shell syntaxhl"><span class="k">if </span>ENABLE_TRX
doc_trxdir <span class="o">=</span> <span class="si">$(</span>docdir<span class="si">)</span>/examples/osmo-bts-trx
doc_trx_DATA <span class="o">=</span> <span class="se">\</span>
trx/osmo-bts-trx.cfg <span class="se">\</span>
trx/osmo-bts-trx-calypso.cfg
EXTRA_DIST +<span class="o">=</span> <span class="si">$(</span>doc_trx_DATA<span class="si">)</span>
OSMOCONF_FILES +<span class="o">=</span> trx/osmo-bts-trx.cfg
endif
</code></pre>
<p>So if the project is configured without <code>--enable-foo</code>, then <code>make dist-bzip2</code> will produce a tarball without those files added conditionally.</p> OsmoSGSN - Bug #6197 (Feedback): "Cannot handle SM for unknown MM CTX"https://www.osmocom.org/issues/61972023-09-28T14:32:29Zfixeria
<p>I am observing relatively long PDP Context activation with Sony Ericsson K800i and recent osmo-sgsn:</p>
<p>osmo-sgsn 1.11.0<br />osmo-pcu 1.3.1.1-c1b0</p>
<p>I don't remember if this was the case before, most likely not.</p>
<p>As can be seen from the attached PCAP, the MS orders a PDP Context activation right after completing the Attach (frame 259):</p>
<pre>
130 16.160906108 127.0.0.1 → 127.0.0.1 GPRS-LLC 107 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Attach Request
156 16.161190149 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Identity Request
157 16.797408334 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Response
173 16.797533278 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Request
181 17.200282825 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Identity Response
226 17.225222456 127.0.0.1 → 127.0.0.1 GPRS-LLC 113 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Attach Accept
239 17.697504097 127.0.0.1 → 127.0.0.1 GPRS-LLC 77 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 3(DTAP) (GMM) Attach Complete
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request <-- (!)
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request <-- (!)
</pre>
<p>The SGSN is responding with GMM Detach Request (frame 275), here is the related logging:</p>
<pre>
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request
260 17.739109847 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
261 17.739128332 127.0.0.1 → 127.0.5.1 GSMTAP 263 GPRS-NS2-VC(UDP-NSE00101-NSVC00101-0_0_0_0:23000-127_0_0_1:23023)[0x55e69ba253d0]{UNBLOCKED}: Received Event RX-UNITDATA
262 17.739139873 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
263 17.739148439 127.0.0.1 → 127.0.5.1 GSMTAP 183 BSSGP TLLI=0x85c79efb Rx UPLINK-UNITDATA
264 17.739181411 127.0.0.1 → 127.0.5.1 GSMTAP 236 LLME(ffffffff/85c79efb){UNASSIGNED} LLC RX: unknown TLLI 0x85c79efb, creating LLME on the fly
265 17.739188394 127.0.0.1 → 127.0.5.1 GSMTAP 193 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x3ef88c
266 17.739193033 127.0.0.1 → 127.0.5.1 GSMTAP 149 CMD=UI
267 17.739196720 127.0.0.1 → 127.0.5.1 GSMTAP 147 DATA
268 17.739200627 127.0.0.1 → 127.0.5.1 GSMTAP 143
269 17.739212048 127.0.0.1 → 127.0.5.1 GSMTAP 214 LLME(ffffffff/85c79efb){UNASSIGNED} Cannot handle SM for unknown MM CTX
270 17.739224792 127.0.0.1 → 127.0.5.1 GSMTAP 198 LLME(ffffffff/85c79efb){UNASSIGNED} LLGM Reset (SAPI=1)
271 17.739243207 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
272 17.739252294 127.0.0.1 → 127.0.5.1 GSMTAP 215 <- GMM DETACH REQ (type: re-attach required, cause: Implicitly detached)
273 17.739257293 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request
</pre>
<p>The MS repeats the request again (frame 517) 30 seconds after the first attempt, and finally gets a PDP Context activated.<br />The key difference between frames 259 (first attempt) and 517 (second attempt) is TLLI indicated in the BSSGP header.</p> OsmocomBB - Feature #6132 (New): Add MS_GPRS_Tests to osmo-ttcn3-hackshttps://www.osmocom.org/issues/61322023-08-02T18:18:57Zpespin
<p>It would be really great to have something similar to existing TTCN3 PCU_Tests, testing RLC/MAC, but for the MS side, using the "modem" app.</p> OsmoBSC - Bug #6019 (New): "PCU version PCU socket has LOST connection connected"https://www.osmocom.org/issues/60192023-04-28T12:17:03Zfixeria
<p>This is what I see in the output of <code>show bts</code> command:</p>
<pre>
OsmoBSC> show bts 0
BTS 0 is of osmo-bts type in band GSM900, has CI 0 LAC 1, BSIC 63 (NCC=7, BCC=7) and 1 TRX
Description: (null)
ARFCNs: 85
PCU version PCU socket has LOST connection connected
...
</pre>
<p>what means that somehow <code>bts->pcu_version[]</code> contains <code>PCU socket has LOST connection</code>. I am also seeing this in logging:</p>
<pre>
апр 28 19:14:07 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version 1.2.0.31-33a1bf3
...
апр 28 19:14:10 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version PCU socket has LOST connection
</pre>
<p>This looks a bit confusing, maybe we should just say "PCU state"?</p> OsmoBTS - Bug #5953 (Feedback): ttcn3-bts-test: TC_ms_pwr_ctrl_{constant,pf_ewma} are failinghttps://www.osmocom.org/issues/59532023-03-21T12:57:05Zfixeria
<p>These two testcases were added by me back in 2020 and have been passing until recently:</p>
<pre>
commit c7ef03057fe6644372b8bf08c165afef29fc600f
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:24:18 2020 +0700
BTS_Tests: introduce TC_ms_pwr_ctrl_constant()
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9052 BTS_Tests control part
BTS_Tests.ttcn:8111 TC_ms_pwr_ctrl_constant testcase
</pre>
<pre>
commit 652e60eb83f928036a649fa45f7a4a4eb8207eac
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:43:27 2020 +0700
BTS_Tests: add TC_ms_pwr_ctrl_pf_ewma: test EWMA based power filtering
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9053 BTS_Tests control part
BTS_Tests.ttcn:8178 TC_ms_pwr_ctrl_pf_ewma testcase
</pre>
<p>The "red age" of both TCs is 102 days ago for both -master and -latest.<br />I guess this might be related to the recent changes in osmocom-bb.git/trxcon.</p> OsmoBTS - Bug #5952 (New): ttcn3-bts-test: TC_ho_physical_info failshttps://www.osmocom.org/issues/59522023-03-21T12:35:13Zfixeria
<p>The testcase was added by me and is failing since the very beginning:</p>
<pre>
commit 1ab332ff86117e7aa22ca973993ea16bedbf63b7
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sat Mar 12 15:31:23 2022 +0300
BTS_Tests: add new test case TC_ho_physical_info
</pre>
<p>The problem is explained in the commit message:</p>
<pre>
Currently the new test case fails for several reasons:
* osmo-bts-trx starts transmitting on DCCH before the handover
Access Burst is received, this is wong;
* trxcon immediately starts sending dummy frames on Uplink
DCCH, causing osmo-bts to stop sendig RR Physical Info.
</pre> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://www.osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> pySim - Bug #5878 (New): pySim shell: version fails with DistributionNotFoundhttps://www.osmocom.org/issues/58782023-01-26T17:55:43Zlynxis
<p>I'm running into a DistributionNotFound error when running pysim.</p>
<ul>
<li>debian bullseye</li>
<li>pcsclite</li>
<li>pipenv</li>
<li>swig</li>
<li>simcard congster prepaid sim</li>
</ul>
<p>I would guess the dependencies aren't right or the pySim scripts needs to be installed by the setup.py.</p>
<pre>
git clone https://gitea.osmocom.org/sim-card/pysim.git
cd pysim
pipenv install -r requirements.txt
pipenv shell
./pySim-shell.py
version
</pre>
<pre>
(pysim-wiDMH_1-) lynxis@pysim:~/pysim$ ./pySim-shell.py -p 0
Using PC/SC reader interface
Waiting for card...
Autodetection failed
Warning: Could not detect card type - assuming a generic card type...
Info: Card is of type: UICC-SIM
AIDs on card:
USIM: a0000000871002ff4994208903100000 (EF.DIR)
Welcome to pySim-shell!
pySIM-shell (MF)> help
Documented commands (use 'help -v' for verbose/'help <topic>' for details):
ISO7816 Commands
================
activate_file deactivate_file open_channel suspend_uicc
change_chv disable_chv select unblock_chv
close_channel enable_chv status verify_chv
pySim Commands
==============
bulk_script dir equip intro tree version
desc echo export reset verify_adm
TS 102 222 Administrative Commands
==================================
create_df delete_file terminate_df
create_ef terminate_card_usage terminate_ef
pySim-shell built-in commands
=============================
alias edit history py run_pyscript set shortcuts
apdu help macro quit run_script shell
pySIM-shell (MF)> version
EXCEPTION of type 'DistributionNotFound' occurred with message: 'The 'pySim' distribution was not found and is required by the application'
To enable full traceback, run the following command: 'set debug true'
pySIM-shell (MF)> set debug true
debug - was: False
now: True
pySIM-shell (MF)> version
Traceback (most recent call last):
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/cmd2/cmd2.py", line 2129, in onecmd_plus_hooks
stop = self.onecmd(statement, add_to_history=add_to_history)
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/cmd2/cmd2.py", line 2559, in onecmd
stop = func(statement)
File "/home/lynxis/pysim/./pySim-shell.py", line 457, in do_version
self.poutput(pkg_resources.get_distribution('pySim'))
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/pkg_resources/__init__.py", line 481, in get_distribution
dist = get_provider(dist)
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/pkg_resources/__init__.py", line 357, in get_provider
return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/pkg_resources/__init__.py", line 900, in require
needed = self.resolve(parse_requirements(requirements))
File "/home/lynxis/.local/share/virtualenvs/pysim-wiDMH_1-/lib/python3.9/site-packages/pkg_resources/__init__.py", line 786, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pySim' distribution was not found and is required by the application
EXCEPTION of type 'DistributionNotFound' occurred with message: 'The 'pySim' distribution was not found and is required by the application'
</pre> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://www.osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> Cellular Network Infrastructure - Bug #5749 (New): configure.ac: default CFLAGS, LT_INIT adds "-g...https://www.osmocom.org/issues/57492022-11-08T18:04:34Zfixeria
<p>Today I spent quite some time trying to figure out why am I seeing <code>-g -O2</code> present in <code>CFLAGS</code> by default when building some projects. As it turned out, it's the <code>LT_INIT</code> (called in <code>configure.ac</code>) adding <code>-g -O2</code> to <code>CFLAGS</code> if they're empty. I could not find anything in documentation describing this behavior. The problem is that this behavior is inconsistent across the Osmocom projects: for some you get empty CFLAGS by default, for some you get <code>CFLAGS=-g -O2</code>. Most likely this inconsistency was introduced when we started to specify the <code>-std=gnu11</code> explicitly: in some projects (e.g. libosmocore.git, libosmo-abis.git, osmo-bsc) we set <code>CFLAGS</code> before calling the <code>LT_INIT</code>, in some (osmo-hlr, osmo-iuh, osmo-sgsn) after.</p>
<p>We need to decide on whether we want to have empty <code>CFLAGS</code> or <code>CFLAGS=-g -O2</code> set by default. Personally I prefer the former approach, because explicit is better then implicit. <a class="user active" href="https://www.osmocom.org/users/52">Hoernchen</a> also prefers the former and does not want "magical flags out of nowhere". Either way, the default behavior should be consistent across all Osmocom projects. <a class="user active" href="https://www.osmocom.org/users/7">laforge</a> what do you think?</p> OsmoPCU - Bug #5696 (Stalled): RLC/MAC: poll timeout when assigning a multi-slot DL TBFhttps://www.osmocom.org/issues/56962022-10-05T07:58:36Zfixeria
<p>One of my phones, Sony Ericsson K800i, fails to complete <code>PDP Context Activation</code> procedure. Thanks to TEMS, I found out that the phone never receives <code>Activate PDP Context Accept</code> message. Further analysis revealed that <code>Activate PDP Context Request</code> message from the phone triggers allocation of a multi-slot Downlink TBF, which includes TS6 and TS7. For some reason, <strong>the phone ACKnowledges allocation of Downlink TBF on TS7 instead of TS6</strong>, what confuses osmo-pcu and causes retransmissions of the <code>PACKET_DOWNLINK_ASSIGNMENT</code> message.</p> Core testing infrastructure - Bug #5665 (Stalled): ERROR: files left in build directory after dis...https://www.osmocom.org/issues/56652022-08-28T09:21:41Zfixeria
<p>Since recently we're observing sporadic master-* job failures on Jenkins. There is always a coredump file, which makes 'distcleancheck' target fail:</p>
<pre>
ERROR: files left in build directory after distclean:
./tests/core
make[1]: Leaving directory '/build/libosmocore-1.7.0.26-862dd/_build/sub'
make[1]: *** [Makefile:1010: distcleancheck] Error 1
make: *** [Makefile:941: distcheck] Error 1
</pre>
<p>This is not specific to libosmocore, I saw master-osmo-{bsc,msc} failing with the same verdict too.</p> libosmocore - Bug #5570 (New): coding: decode in-band data in AMR's special DTX frames (SID_FIRST...https://www.osmocom.org/issues/55702022-05-21T14:21:38Zfixeria
<p>Whenever gsm0503_tch_a[fh]s_decode_dtx() detects a special AMR's DTX frame (e.g SID_FIRST, SID_UPDATE, SID_ONSET) it immediately jumps out and ignores the coded in-band data (CMI, CMC/CMR). A hard-coded default value=0 is assigned instead of the actual value(s) indicated by the MS. This basically breaks rate adaptation when DTXu is employed.</p> OsmoBTS - Bug #5517 (New): ttcn3-bts-test: new sporadic test case failureshttps://www.osmocom.org/issues/55172022-04-07T21:37:29Zfixeria
<p>Since recently, the following testcases sporadically fail:</p>
<ul>
<li>BTS_Tests.TC_tx_power_ramp_adm_state_change,</li>
<li>BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown,</li>
<li>BTS_Tests.TC_rsl_ms_pwr_dyn_up.</li>
</ul>
<p>We should investigate why and try to fix them.</p> libosmocore - Bug #4993 (New): gsm_septets2octets: warning: use of NULL ‘rdata’ where non-null ex...https://www.osmocom.org/issues/49932021-01-29T20:49:14Zlaforge
<p>When using gcc-10 with "-fanalyzer", we get the following report:</p>
<pre>
gsm_utils.c: In function ‘gsm_septets2octets’:
gsm_utils.c:340:3: warning: use of NULL ‘rdata’ where non-null expected [CWE-690] [-Wanalyzer-null-argument]
340 | memcpy(data, rdata, septet_len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
‘gsm_7bit_encode_n’: events 1-3
|
| 378 | int gsm_7bit_encode_n(uint8_t *result, size_t n, const char *data, int *octets)
| | ^~~~~~~~~~~~~~~~~
| | |
| | (1) entry to ‘gsm_7bit_encode_n’
|......
| 385 | uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t));
| | ~~~~~~~~~~~~
| | |
| | (2) allocated here
| 386 | y = gsm_septet_encode(rdata, data);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (3) calling ‘gsm_septet_encode’ from ‘gsm_7bit_encode_n’
|
+--> ‘gsm_septet_encode’: events 4-8
|
| 292 | int gsm_septet_encode(uint8_t *result, const char *data)
| | ^~~~~~~~~~~~~~~~~
| | |
| | (4) entry to ‘gsm_septet_encode’
|......
| 296 | for (i = 0; i < strlen(data); i++) {
| | ~~~ ~~~~~~~~~~~~
| | | |
| | | (5) following ‘false’ branch (when ‘data’ is non-NULL)...
| | | (6) ...to here
| | (7) following ‘false’ branch...
|......
| 318 | return y;
| | ~
| | |
| | (8) ...to here
|
<------+
|
‘gsm_7bit_encode_n’: events 9-10
|
| 386 | y = gsm_septet_encode(rdata, data);
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (9) returning to ‘gsm_7bit_encode_n’ from ‘gsm_septet_encode’
|......
| 396 | o = gsm_septets2octets(result, rdata, y, 0);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (10) calling ‘gsm_septets2octets’ from ‘gsm_7bit_encode_n’
|
+--> ‘gsm_septets2octets’: events 11-19
|
| 327 | int gsm_septets2octets(uint8_t *result, const uint8_t *rdata, uint8_t septet_len, uint8_t padding)
| | ^~~~~~~~~~~~~~~~~~
| | |
| | (11) entry to ‘gsm_septets2octets’
|......
| 334 | if (padding) {
| | ~
| | |
| | (12) following ‘false’ branch (when ‘padding == 0’)...
|......
| 340 | memcpy(data, rdata, septet_len);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (13) ...to here
| | (14) following ‘false’ branch (when ‘data’ is non-NULL)...
| | (15) ...to here
| | (16) assuming ‘rdata’ is NULL
| | (17) following ‘true’ branch (when ‘rdata’ is NULL)...
| | (18) ...to here
| | (19) argument 2 (‘rdata’) NULL where non-null expected
|
In file included from ../../include/osmocom/core/utils.h:6,
from gsm_utils.c:82:
/usr/include/string.h:43:14: note: argument 2 of ‘memcpy’ must be non-null
</pre>
<p>There's also a couple of others in that file:<br /><pre>
gsm_utils.c:340:3: warning: use of NULL ‘data’ where non-null expected [CWE-690] [-Wanalyzer-null-argument]
gsm_utils.c: In function ‘gsm_7bit_encode_n’:
gsm_utils.c:401:2: warning: double-‘free’ of ‘rdata’ [CWE-415] [-Wanalyzer-double-free]
gsm_utils.c:369:9: warning: leak of ‘rdata’ [CWE-401] [-Wanalyzer-malloc-leak]
</pre></p> OsmoBTS - Bug #4801 (Stalled): BTS_Tests.TC_tch_sign_l2_fill_frame_dtxd failshttps://www.osmocom.org/issues/48012020-10-11T19:52:01Zlaforge
<p>The tests fails with the sttement</p>
<pre>
TC_tch_sign_l2_fill_frame_dtxd(6)@nataraja: received only 2+0 (SACCH+other) out of 3 expected fill frames
MTC@nataraja: Test case TC_tch_sign_l2_fill_frame_dtxd finished. Verdict: fail reason: "BTS_Tests.ttcn:6675 : Not enough fill frames received"
</pre>
<p>So it seems like the SACCH in downlink is received, but the fill frames that should be sent by the related code in osmo-bts (<a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/10415">https://gerrit.osmocom.org/c/osmo-bts/+/10415</a>) are either not sent, or somehow lost, or not detected by the test case.</p> OsmocomBB - Bug #4798 (Feedback): fake_trx send TRXC responses from wrong source addresshttps://www.osmocom.org/issues/47982020-10-11T15:59:10Zlaforge
<p>I'm starting fake_trx.py like this:<br /><pre>
./fake_trx.py -R 127.0.0.21 -r 127.0.0.21 --trx TRX1@127.0.0.21:5700/1 --trx TRX2@127.0.0.21:5700/2 --trx TRX3@127.0.0.21:5700/3
</pre></p>
<p>And then osmo-bts-trx is sending TRXC commands from 127.0.0.20 to 127.0.0.21, and fake_trx.py responds. However, the response originates from 127.0.0.1 instead of the 127.0.0.21 that was configured.</p>
<p>Subsequently, osmo-bts-trx rejects those UDP responses as (presumably) the socket is fully connected and hence only accepts packets with correct source ip+port.</p>
<p><img src="https://www.osmocom.org/attachments/download/4309/fake_trx_wrong_source.png" alt="" /></p>
<p>pcap file attached.</p> OsmoBTS - Bug #4592 (Stalled): osmo-bts-trx: make sure that handover detection workshttps://www.osmocom.org/issues/45922020-06-07T08:18:06Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: osmo-bts-trx leaks memory (Resolved)" href="https://www.osmocom.org/issues/4586">#4586</a>, I noticed that <strong>osmo-bts-trx never sends <em>TRXC HANDOVER</em> command</strong>. It looks like <em>TRXC NOHANDOVER</em> is being sent twice.</p>
<pre>
1401 3.835299624 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
1404 3.835525858 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
1673 3.947655470 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
1674 3.947925293 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2028 4.071425165 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2031 4.071810374 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2334 4.186607520 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2337 4.187177856 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
2648 4.295164236 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
2649 4.295823750 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
10759 7.367793910 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
10762 7.368688082 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
11205 7.532400900 127.0.0.1 → 127.0.0.1 OsmoTRXC 61 CMD NOHANDOVER 1 0
11206 7.532637365 127.0.0.1 → 127.0.0.1 OsmoTRXC 63 RSP NOHANDOVER 0 1 0
</pre>
<p>The purpose of these TRXC commands is to control handover detection in transceiver. By default, handover detection is enabled on all inactive channels. As soon as the BSC activates a logical channel, osmo-bts-trx needs to send <em>TRXC NOHANDOVER</em> to the transceiver, so handover detection is disabled for that channel. As soon as a logical channel is deactivated, osmo-bts-trx needs to send <em>TRXC HANDOVER</em> to the transceiver, so handover detection is on again.</p>
<p>I quickly checked the source code, and indeed there is a bug:</p>
<pre><code class="c syntaxhl"><span class="cm">/* setting all logical channels given attributes to active/inactive */</span>
<span class="kt">int</span> <span class="nf">trx_sched_set_lchan</span><span class="p">(</span><span class="k">struct</span> <span class="n">l1sched_trx</span> <span class="o">*</span><span class="n">l1t</span><span class="p">,</span> <span class="kt">uint8_t</span> <span class="n">chan_nr</span><span class="p">,</span> <span class="kt">uint8_t</span> <span class="n">link_id</span><span class="p">,</span> <span class="n">bool</span> <span class="n">active</span><span class="p">)</span>
<span class="p">{</span>
<span class="cm">/* Skipped code here... */</span>
<span class="cm">/* disable handover detection (on deactivation) */</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">active</span><span class="p">)</span>
<span class="n">_sched_act_rach_det</span><span class="p">(</span><span class="n">l1t</span><span class="p">,</span> <span class="n">tn</span><span class="p">,</span> <span class="n">ss</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
<span class="k">return</span> <span class="n">rc</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>Even the comment near the 'if' statement is wrong.</p> Cellular Network Infrastructure - Feature #3628 (New): document nanoBTS calibration procedure usi...https://www.osmocom.org/issues/36282018-10-04T11:13:31Zlaforge
<p>The nanoBTS has the capability to OCXO calibration against another (macro) BTS. We had implemented this in ipaccess-config, but we apparently never documented how it works.</p>
<p>Let's add it somewhere to the nanoBTS related wiki pages.</p>
<p>Without trying, I remember that it was part of the "Tests" that can be triggered via OML.</p>
<pre>
static const struct value_string test_names[] = {
»·······{ NM_IPACC_TESTNO_CHAN_USAGE, "Channel Usage" },
»·······{ NM_IPACC_TESTNO_BCCH_CHAN_USAGE, "BCCH Channel Usage" },
»·······{ NM_IPACC_TESTNO_FREQ_SYNC, "Frequency Synchronization" },
»·······{ NM_IPACC_TESTNO_BCCH_INFO, "BCCH Info" },
»·······{ NM_IPACC_TESTNO_TX_BEACON, "Transmit Beacon" },
»·······{ NM_IPACC_TESTNO_SYSINFO_MONITOR, "System Info Monitor" },
»·······{ NM_IPACC_TESTNO_BCCCH_MONITOR, "BCCH Monitor" },
</pre>
<p>I think you start with a CHAN_USAGE to see the receive level per ARFCN. You then proceed to a FREQ_SYNC to see which of those have a FCCH (and hence are BCCH/CCCH carrying).</p> libosmocore - Feature #3522 (New): libosmocoding: move TCH ordering functions to libosmocodec and...https://www.osmocom.org/issues/35222018-09-04T20:49:08Zfixeria
<p>The GSM 05.03 implementation present in libosmocoding is using the RTP speech frame format for TCH coding functions. It is implemented in a way of performing 'canonical -> RTP' bit reordering in decoding functions, and 'RTP -> canonical' bit reordering in encoding functions. At the moment, the RTP format bit reordering implementation is not exposed.</p>
<p>This API could be used by some other projects (at least by osmo-gapk), moreover libosmocoding is already being linked against libosmocodec.</p> GSM Audio Pocket Knife - Bug #3398 (New): build: configure fails if (optional) libalsa wasn't foundhttps://www.osmocom.org/issues/33982018-07-16T20:45:23Zfixeria
<p>ALSA is optional dependency, which is only required for audio capture and playback.<br />We should not enforce this optional dependency as a mandatory one.</p> Cellular Network Infrastructure - Feature #3142 (New): Further simplification of "NITB like" setupshttps://www.osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</p> OsmoMSC - Feature #1974 (New): VLR: high water mark on subscriber storagehttps://www.osmocom.org/issues/19742017-03-08T14:54:50Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.</p>
<p>Implement a configurable way of limiting the number of subscribers kept in RAM, e.g. a fixed max size.<br />If this is reached, discard those subscribers that have been inactive for the longest time first.</p> OsmoMSC - Feature #1973 (New): VLR: efficient subscriber lookuphttps://www.osmocom.org/issues/19732017-03-08T14:52:10Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.<br />Storing numerous subscribers in a linear list is inefficient, implement a hash table for faster access times.</p> OsmoBTS - Feature #1755 (New): osmo-bts-sysmo L1: unify hLayer3 handlinghttps://www.osmocom.org/issues/17552016-06-16T11:27:40Zneelsnhofmeyr@sysmocom.de
<p>In <a class="external" href="https://gerrit.osmocom.org/264">https://gerrit.osmocom.org/264</a> , some hLayer3 use was added.<br />However, some of the messages were already using hLayer3.</p>
<p>After the patch, the prim_init() sets a hLayer3 which is overwritten<br />shortly after that, so the other functionality is not affected by this patch.</p>
<p>Some functions to generate hLayer3 for a timeslot and similar already existed,<br />and also to retrieve a timeslot and similar back from a hLayer3 handle.</p>
<p>And also, the other hLayer3 functions use a "magic" byte<br />(like the most significant byte always set to 0xbb).</p>
<p>So in fact, we should have rejected this patch, and we should follow up with<br />a merger of my hLayer3 to the existing hLayer3 infrastructure.<br />The priority is low though, since no harm is done.</p>
<p>See:</p>
<ul>
<li>osmo-bts/src/osmo-bts-sysmo/oml.c
<ul>
<li>mph_send_activate_req()</li>
<li>mph_send_config_logchpar()</li>
<li>mph_send_config_ciphering()</li>
<li>mph_send_deactivate_req()</li>
</ul></li>
</ul> OsmoMSC - Feature #1597 (Stalled): External interface for USSDhttps://www.osmocom.org/issues/15972016-02-23T15:52:03Zlaforge
<p>we already have SMPP for SMS, but don't have similar functionality for USSD, i.e. a way in which external applications can exchange USSD with MSs.</p>
<p>There are some provisions for USSD in SMPP, but I think they don't really appreciate the session-oriented nature of USSD.</p>
<p>In either case, I'm not aware of any standard to hand USSD to external applications. Of course there's MAP, but nobody wants to implement that in an external application...</p> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://www.osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p> OsmoBTS - Feature #1568 (New): Move various code bits to libosmocorehttps://www.osmocom.org/issues/15682016-02-23T15:28:32Zlaforge
<p>There are plenty of FIXMEs in src/common.c about code that should be moved to libosmocore as a clean-up</p>