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> OsmoSGSN - Bug #6197 (Feedback): "Cannot handle SM for unknown MM CTX"https://projects.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://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> OsmoPCU - Bug #5696 (Stalled): RLC/MAC: poll timeout when assigning a multi-slot DL TBFhttps://projects.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://projects.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://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 - Bug #5242 (Stalled): A-bis/RSL: CRCX ACK indicates '0.0.0.0' as the local/bind addresshttps://projects.osmocom.org/issues/52422021-09-30T09:25:47Zfixeria
<p>Currently both TC_speech_rtp_tchf and TC_speech_rtp_tchh fail, because CRCX ACK from osmo-bts indicates '0.0.0.0' as the local/bind address. The local/bind address of osmo-bts is needed in order to know where to send RTP packets for the RTP_Emulation component, and of course '0.0.0.0' cannot be used as the remote address for send(). See the attached PCAP file.</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> OsmoBTS - Feature #4941 (Stalled): VAMOS support in OsmoBTShttps://projects.osmocom.org/issues/49412021-01-12T14:05:15Zlaforge
<p>This ticket should document what needs to be done in terms of supporting <a class="wiki-page" href="https://projects.osmocom.org/projects/cellular-infrastructure/wiki/VAMOS">VAMOS</a> from <a class="wiki-page" href="https://projects.osmocom.org/projects/osmobts/wiki/OsmoBTS">OsmoBTS</a>, and to track its status via check-lists and possibly sub-issues.</p>
<p>Our implementation will be focusing <code>on osmo-bts-trx</code> as none of the "proprietary PHY" we support implement any VAMOS support.</p>
This likely includes (at least)
<ol>
<li>Indication of [which level of] VAMOS support the BTS has via OML attributes to BSC</li>
<li>Implementation of "shadow TRX" concept in data structures</li>
<li>Implementation of VAMOS related RSL extensions on Abis</li>
<li>Implementation of a new TRXDv2 protocol from/to the TRX</li>
<li>VAMOS-aware uplink + downlink power control</li>
<li>generation of one set of downlink symbols from the real + shadow timeslot/lchan</li>
</ol>
<p>The corresponding BSC related work is tracked in <a class="issue tracker-2 status-7 priority-3 priority-high3" title="Feature: VAMOS support in OsmoBSC (Stalled)" href="https://projects.osmocom.org/issues/4940">#4940</a></p> OsmoPCU - Bug #4879 (Stalled): endless pdch.cpp:809 Got CS-N RLC block: R=0, SI=0, TFI=0, CPS=0, ...https://projects.osmocom.org/issues/48792020-11-29T23:17:31Zfixeria
<p>I just upgraded all osmo-{ran,cni} components to the recent master, and now quite often run into a situation when the MS (at least Sony Ericsson K800i, TEMS) keeps sending the same Uplink block again and again. I am not sure what exactly causes it, but I can reproduce it more or less reliably by starting Opera Mini (<a class="external" href="http://people.osmocom.org/fixeria/j2me/opera_mini.jar">http://people.osmocom.org/fixeria/j2me/opera_mini.jar</a>). When started for the first time, Opera initiates the installation process, and this is where the problem usually shows up.</p>
<pre>
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACMEAS INFO gprs_rlcmac_meas.cpp:108 MS(TLLI=0xc5849e78, IMSI=901990000000021, TA=0, 10/0, UL DL) UL RSSI: -29 dBm
</pre>
<p>Please see the attached capture file. Some highlights:</p>
<pre>
43585 RACH!
43591 IMM ASS (single block)
43731 UL Packet Resource Request
43799 DL Packet Uplink Assignment (TS=6 USF=0)
...
43910 UL DATA (BSN=0 CV=15)
...
43915 UL DATA | TCP FIN,ACK (Opera Mini closes connection to the server)
...
43918 UL DATA (BSN=3 CV=15)
43955 UL DATA (BSN=5 CV=14) <-- 14 RLC blocks left
...
44070 UL DATA (BSN=14 CV=5)
...
44146 UL DATA (BSN=19 CV=0) <-- 0 RLC blocks left
...
44149 UL DATA (BSN=19 CV=0) <-- re-transmission
44152 UL DATA (BSN=19 CV=0) <-- re-transmission
</pre>
<p>starting from frame 44149, the MS keeps transmitting the same RLC/MAC block ('35bdc794cd2b631285b2d43513'O). Interestingly enough, after each re-transmission the PCU logs "GPRS DL CTRL: PACKET_UPLINK_ACK_NACK", but <strong>does not actually send it</strong> (dummy RLC/MAC frames are not recorded). And this goes like that unless I turn off the phone. At the same time, Downlink blocks are received and accepted by the MS on the same timeslot.</p>
<p>OsmoPCU 58cd1d2f8a0474de45112e8d6e460051494eba79<br />OsmoBTS def24f0d9af2463a5ef557d35f23abd5b4d07120</p> OsmoBSC - Bug #4848 (Feedback): osmo-bsc user manual shows tables with per-bts counters three (!)...https://projects.osmocom.org/issues/48482020-11-04T16:14:28Zlaforge
<p>The current PDF file (attached for reference) contains the "implemented counters" three times. Tables 8 + 9 appear to be identical copies of Table 7.</p> OsmoBTS - Bug #4801 (Stalled): BTS_Tests.TC_tch_sign_l2_fill_frame_dtxd failshttps://projects.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://projects.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://projects.osmocom.org/attachments/download/4309/fake_trx_wrong_source.png" alt="" /></p>
<p>pcap file attached.</p> libosmocore - Bug #4797 (Feedback): vty: the output of 'show ns' command is confusinghttps://projects.osmocom.org/issues/47972020-10-09T23:38:34Zfixeria
<p>This looks cryptic, at least to me:</p>
<pre>
OsmoPCU# show ns
UDP bind: 0.0.0.0:22000 dcsp: 0
1 NS-VC:
udp)[0.0.0.0]:22000<1234>[127.0.0.1]:23000
NSEI 1234
:0 <> 127.0.0.1:23000Remote: udp)[0.0.0.0]:22000<1234>[127.0.0.1]:23000 UDP
</pre>
<p>Let's print something more readable.</p> OsmoBTS - Bug #4771 (Stalled): Don't log NOTICE messages on missing uplink burstshttps://projects.osmocom.org/issues/47712020-10-01T12:05:51Zlaforgelibosmocore - Bug #4731 (Stalled): LAPDm does not implement SAPI priorities between data link layershttps://projects.osmocom.org/issues/47312020-08-26T19:34:40Zlaforge
<p>AFAIR, The 3GPP specifications contain some very strict rules regarding priorities among different concurrent LAPDm data links for the same subscriber. For example, SAIP0 always has higher priority than SAPI3.</p>
<p>We've just encountered a situation where in MT-SMS, the SAPI3 SABM from BTS to MS was sent <strong>before</strong> the BTS replied with the UA for SAPI0 (contetion resolution procedure, where we echo the PAGING RESPONSE back to the MS).</p>
<p>A quick look at the LAPDm code in libosmocore reveals that it is doing a round-robin rather than implementing the rules.</p>
<p>TS 44.005 Section 4.2.2 states the priorities for SDCCH and SACCH. I guess we can think of FACCH == SDCCH in this context.</p> OsmocomBB - Bug #4658 (Stalled): Wrong burst order in a multi-trx setuphttps://projects.osmocom.org/issues/46582020-07-08T11:45:30Zfixeria
<p>While running the existing test cases from ttcn3-bts-test on hopping channels (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: baseband frequency hopping support for osmo-bts-trx (Resolved)" href="https://projects.osmocom.org/issues/4546">#4546</a>), I noticed that sometimes trxcon starts to consume a lot of CPU power. As it turned out, this happens because the burst loss detection logic in trxcon somehow detects that the whole TDMA hyper-frame is lost, so it tries to substitute ~2715647 allegedly lost TDMA frames with a dummy burst. Of course it's a bug, because we're not supposed to compensate more than one TDMA multi-frame period. So the problem was a missing 'return' statement:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/19183">https://gerrit.osmocom.org/c/osmocom-bb/+/19183</a> trxcon/scheduler: subst_frame_loss(): print current TDMA fn<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/19184">https://gerrit.osmocom.org/c/osmocom-bb/+/19184</a> trxcon/scheduler: fix subst_frame_loss(): do not compensate too much</p>
<p>However, I was interested to know what exactly tricks the burst detection logic to think that so many frames are lost.</p>
<pre><code class="c syntaxhl"><span class="cm">/*! Return the difference of two specified TDMA frame numbers (subtraction) */</span>
<span class="cp">#define GSM_TDMA_FN_SUB(a, b) \
((a + GSM_TDMA_HYPERFRAME - b) % GSM_TDMA_HYPERFRAME)
</span>
<span class="cm">/* How many frames elapsed since the last one? */</span>
<span class="n">elapsed</span> <span class="o">=</span> <span class="n">GSM_TDMA_FN_SUB</span><span class="p">(</span><span class="n">fn</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">elapsed</span> <span class="o">></span> <span class="n">mf</span><span class="o">-></span><span class="n">period</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DSCHD</span><span class="p">,</span> <span class="n">LOGL_NOTICE</span><span class="p">,</span> <span class="s">"Too many (>%u) contiguous TDMA frames elapsed (%u) "</span>
<span class="s">"since the last processed fn=%u (current %u)</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span>
<span class="n">mf</span><span class="o">-></span><span class="n">period</span><span class="p">,</span> <span class="n">elapsed</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">,</span> <span class="n">fn</span><span class="p">);</span>
<span class="k">return</span> <span class="o">-</span><span class="n">EIO</span><span class="p">;</span>
<span class="p">}</span> <span class="k">else</span> <span class="nf">if</span> <span class="p">(</span><span class="n">elapsed</span> <span class="o">==</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DSCHD</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="s">"No TDMA frames elapsed since the last processed "</span>
<span class="s">"fn=%u, must be a bug?</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">);</span>
<span class="k">return</span> <span class="o">-</span><span class="n">EIO</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>And slightly more informative logging message gives us a hint:</p>
<pre>
sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647) since the last processed fn=633 (current fn=632)
</pre>
<p>so, a burst with TDMA fn=632 is for some reason received <strong>late</strong>, since we already received a burst with TDMA fn=633.</p>
<p>This is definitely unexpected, and of course subtraction would result in a huge number: ((632 + 2715648) - 633) % 2715648 == 2715647.</p>