Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.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://projects.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://projects.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://projects.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> OsmocomBB - Feature #6132 (New): Add MS_GPRS_Tests to osmo-ttcn3-hackshttps://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.osmocom.org/users/7">laforge</a> what do you think?</p> libosmocore - Bug #5570 (New): coding: decode in-band data in AMR's special DTX frames (SID_FIRST...https://projects.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://projects.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> OsmoMSC - Bug #5340 (New): ttcn3-msc-test: more memory leakshttps://projects.osmocom.org/issues/53402021-12-07T14:17:36Zfixeria
<p>We have talloc reports in the build artifacts starting from today:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/*.talloc">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/*.talloc</a></p>
<p>And here one can clearly see leaked memory (MSC_Tests_Iu.TC_mo_cc_iu_release executed last):</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/MSC_Tests_Iu.TC_mo_cc_iu_release.talloc/*view*/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/MSC_Tests_Iu.TC_mo_cc_iu_release.talloc/*view*/</a></p>
<a name="Chunk-bssmap-clear-command"></a>
<h3 >Chunk 'bssmap: clear command'<a href="#Chunk-bssmap-clear-command" class="wiki-anchor">¶</a></h3>
<pre>
msgb contains 17400 bytes in 16 blocks (ref 0) 0x563205605390
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a0290
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057f30c0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057e39e0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057eca30
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057d7740
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a4e50
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a5e80
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057c9fe0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057d2120
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057ed520
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057ce880
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632058004a0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057c8940
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x563205800aa0
bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057bb620
</pre>
<p>I can reproduce this leak by running MSC_Tests.TC_ho_inter_bsc manually.</p>
<a name="Chunk-struct-sgs_connection"></a>
<h3 >Chunk 'struct sgs_connection'<a href="#Chunk-struct-sgs_connection" class="wiki-anchor">¶</a></h3>
<pre>
struct osmo_stream_srv_link contains 3688 bytes in 24 blocks (ref 0) 0x563205791920
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc010
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc2d0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b0760
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cd200
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e16c0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057f76e0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057fa3b0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc630
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b5a00
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d1e20
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057ddd50
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d6b30
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057dc280
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e3030
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057f80d0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e2e80
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b4410
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057c7ad0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cdf10
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b0a50
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d95e0
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x563205794760
</pre>
<p>This is weird, I would expect all SGs connections to be terminated at some point?</p>
<a name="Chunk-struct-vlr_subscr"></a>
<h3 >Chunk 'struct vlr_subscr'<a href="#Chunk-struct-vlr_subscr" class="wiki-anchor">¶</a></h3>
<pre>
struct vlr_instance contains 315472 bytes in 658 blocks (ref 0) 0x56320577c0d0
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205837060
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205836b10
SGs-UE(imsi:262420000001131)[0x563205836b10] contains 45 bytes in 1 blocks (ref 0) 0x563205814560
imsi:262420000001131 contains 21 bytes in 1 blocks (ref 0) 0x56320581c120
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205838a50
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205839130
SGs-UE(imsi:262420000001130)[0x563205839130] contains 45 bytes in 1 blocks (ref 0) 0x563205836f10
imsi:262420000001130 contains 21 bytes in 1 blocks (ref 0) 0x563205803440
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x5632058360e0
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205830410
SGs-UE(imsi:262420000001129)[0x563205830410] contains 45 bytes in 1 blocks (ref 0) 0x563205829750
imsi:262420000001129 contains 21 bytes in 1 blocks (ref 0) 0x56320581be90
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205832900
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205832fe0
SGs-UE(imsi:262420000001128)[0x563205832fe0] contains 45 bytes in 1 blocks (ref 0) 0x563205810490
imsi:262420000001128 contains 21 bytes in 1 blocks (ref 0) 0x5632058318e0
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x56320582a920
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x56320581d030
SGs-UE(imsi:262420000001127)[0x56320581d030] contains 45 bytes in 1 blocks (ref 0) 0x56320581f700
imsi:262420000001127 contains 21 bytes in 1 blocks (ref 0) 0x5632058156e0
...
</pre>
<p>This is probably not a problem, the lifetime of a VLR subscriber is controlled by T3212, which is set to 60m by default.</p> OsmoTRX - Feature #5283 (New): Implement TRXDv2 supporthttps://projects.osmocom.org/issues/52832021-10-27T22:35:37Zfixeria
<p>At the moment, only TRXDv0 and TRXDv1 are supported. Given that osmo-bts-trx does support TRXDv2, it would be nice to have it in osmo-trx too.</p> OsmoBTS - Feature #5025 (New): Missing TTCN-3 coverage for the Timing Advance loophttps://projects.osmocom.org/issues/50252021-02-15T16:36:08Zfixeria
<p>As we figured out in <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Timing Advance loop is broken for SDCCH channels (Resolved)" href="https://projects.osmocom.org/issues/5024">#5024</a>, there seems to be no TTCN-3 test case(s) for continuous Timing Advance control:</p>
<p>Harald Welte wrote:</p>
<blockquote>
<p>Regarding TTCN3 tests: We also only test the correct TA usage on initial channel establishment (BTS_Tests.TC_rsl_chan_initial_ta) and no tests yet for the TA loop during an active channel.</p>
</blockquote> libosmocore - Bug #4993 (New): gsm_septets2octets: warning: use of NULL ‘rdata’ where non-null ex...https://projects.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> OsmoHLR - Bug #4565 (New): TTCN-3 testsuite: mDNS_UDP: maximum number of open file descriptors is...https://projects.osmocom.org/issues/45652020-05-26T07:12:54Zosmith
<p>I'm analyzing why the TTCN-3 tests for DGSM are failing now, although they have been working before the dgsm code was merged into OsmoHLR. I think we've upgraded the ttcn-3 version inbetween, maybe that is why it worked before and does not work anymore now.</p>
<p>The tests run into a timeout at mDNS.receive calls, such as:<br /><pre>
/* [mDNS] TS-HLR <= HLR proxy: query for GSUP server who knows the IMSI */
mDNS.receive(tr_MSLookup_mDNS_query(domain)) -> value mdns_msg;
</pre></p>
<p>While executing the tests (and even while running non-dgsm tests), the testsuite prints a new message (this was not printed when I wrote and tested the tests initially):<br /><pre>
07:14:22.466652 5 MSLookup_mDNS_Emulation.ttcn:23 Warning: The maximum number of open file descriptors (1048576) is greater than FD_SETSIZE (1024). Ensure that Test Ports using Install_Handler do not try to wait for events of file descriptors with values greater than FD_SETSIZE (1024). (Current caller of Install_Handler is "mDNS_UDP")
</pre></p>
<p>So for some reason, a huge number of file descriptors is allocated. This happens even if just one test is enabled.</p> OsmocomBB - Feature #3666 (New): trxcon: Introduce VTY interfacehttps://projects.osmocom.org/issues/36662018-10-24T12:16:08Zfixeria
<p>Having the VTY interface would allow one to configure various logging<br />parameters, observe some statistics, and moreover to configure<br />multiple L23 <-> TRX connections.</p>
<pre>
log stderr
logging filter all 1
logging print category 1
...
! One transceiver connection
trxcon foo
! TRX interface configuration
trx ip local 127.0.0.1
trx base-port local 5800
trx ip remote 127.0.0.1
trx base-port remote 5700
trx fn-advance 20
...
! L23 interface configuration
layer2-socket /tmp/osmocom_l2.foo
...
! Another transceiver connection
trxcon bar
...
! Another transceiver connection
trxcon zoo
...
</pre> Cellular Network Infrastructure - Feature #3628 (New): document nanoBTS calibration procedure usi...https://projects.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> OsmocomBB - Bug #3557 (New): trxcon: decoding errors after applying a new TCH modehttps://projects.osmocom.org/issues/35572018-09-16T09:52:18Zfixeria
<p>There are also some decoding errors after applying a new TCH mode from Channel Mode Modify:</p>
<pre>
<0005> sched_trx.c:263 (Re)configure TDMA timeslot #2 as TCH/H+SACCH
<0005> sched_trx.c:420 Activating lchan=TCH/H(0) on ts=2
<0005> sched_trx.c:420 Activating lchan=SACCH/TH(0) on ts=2
<0006> sched_lchan_xcch.c:96 Received incomplete data frame at fn=0 (0/104) for SACCH/TH(0)
<0006> sched_lchan_xcch.c:106 Received bad data frame at fn=0 (0/104) for SACCH/TH(0)
<0005> sched_clck.c:138 Clock indication: fn=22389
<0005> sched_clck.c:138 Clock indication: fn=22440
<0001> l1ctl.c:695 Received L1CTL_TCH_MODE_REQ (tch_mode=1, audio_mode=10)
<0005> sched_clck.c:138 Clock indication: fn=22491
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22513 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22518 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22522 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22526 on TCH/H(0) (rc=-1)
<0005> sched_clck.c:138 Clock indication: fn=22542
<0005> sched_clck.c:138 Clock indication: fn=22593
<0005> sched_clck.c:138 Clock indication: fn=22644
<0005> sched_clck.c:138 Clock indication: fn=22695
<0005> sched_clck.c:138 Clock indication: fn=22746
<0005> sched_clck.c:138 Clock indication: fn=22797
</pre> libosmocore - Feature #3522 (New): libosmocoding: move TCH ordering functions to libosmocodec and...https://projects.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> libosmocore - Feature #3521 (New): core/utils: engineering notation helpershttps://projects.osmocom.org/issues/35212018-09-04T20:32:52Zfixeria
<p>It would be great to have some auxiliary API to parse numbers written in the engineering notation (e.g. 945.6M, -33k) to the regular numbers (float?), and, vice versa, the regular numbers to engineering notation. This is useful in the cases where a user should provide some input, such as frequency (e.g. in osmo-arfcn) or sample rate.</p>
<p>Inspired by GNU Radio: <a class="external" href="https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py">https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py</a></p>
<p>If this feature also looks useful for others, I would implement it.</p> GSM Audio Pocket Knife - Bug #3398 (New): build: configure fails if (optional) libalsa wasn't foundhttps://projects.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://projects.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://projects.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://projects.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://projects.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> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://projects.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://projects.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>