Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-20T14:24:47ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #6411 (New): ttcn3: execute testsuites with a more realisti...https://osmocom.org/issues/64112024-03-20T14:24:47Zfixeria
<p>This idea by <a class="user active" href="https://osmocom.org/users/7">laforge</a> originates from <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://osmocom.org/issues/6375">#6375</a>: we should try running at least some of our BTS / BSC tests over an Abis link with simulated latency and non-zero packet loss. I did some experiments using tc-netem, running the whole ttcn3-bts-test with a simulated delay: <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://osmocom.org/issues/6375#note-14">#6375#note-14</a>. Let's continue discussing this here.</p> Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> Cellular Network Infrastructure - Bug #6349 (Feedback): example configs missing in release tarballshttps://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> Cellular Network Infrastructure - Feature #6327 (New): Osmocom-build-tags-against-master job buil...https://osmocom.org/issues/63272024-01-11T20:17:59Zfixeria
<p>The idea behind this job is to check if [a limited set of] old tagged versions of various Osmocom projects can still compile with the most recent versions of Osmocom libraries.</p>
<p>I checked the build logs and found out that it's building the default configurations for Osmocom projects (no <code>--with-foo</code> flags passed to configure scripts).<br />For instance, the default build configuration for osmo-bts does not include any models except the <code>-virtual</code>, so <code>osmo-bts-{trx,sysmo,...}</code> are not covered.<br />Same applies to osmo-trx: we build only the common code, but not the <code>-uhd/-lms</code> variants.</p>
<p>The more complete configurations we build, the more chances we have to catch various backwards compatibility problems.<br />A good example is <a class="external" href="https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh">https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh</a>, where we do enable much more features / variants.<br />Maybe this code can be generalized and re-used somehow?</p> Cellular Network Infrastructure - Bug #6325 (Resolved): ttcn3-msc-test: MSC_Tests_ASCI.TC_complet...https://osmocom.org/issues/63252024-01-09T14:24:27Zfixeria
<p>First of all, I found out that testcases from <code>MSC_Tests_ASCI</code> are not being executed on Jenkins:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/35521">https://gerrit.osmocom.org/c/docker-playground/+/35521</a> ttcn3-msc-test: also execute ASCI (VBS/VGCS) testcases</p>
<p>thanks to the config file duplication between osmo-ttcn3-hacks.git and docker-playground.git :(</p>
<p>I noticed this while running ttcn3-msc-test locally and seeing that the following testcases fail:</p>
<ul>
<li>NEW: FAIL MSC_Tests_ASCI.TC_complete_vgcs</li>
<li>NEW: FAIL MSC_Tests_ASCI.TC_complete_vbs</li>
</ul>
<p>The failure verdicts vary between consecutive test runs, here is what I saw last time:</p>
<pre>
TC_complete_vgcs0(13)@LEGION: setverdict(fail): none -> fail reason: "Got unexpected message on control connection.", new component reason: "Got unexpected message on control connection."
TC_complete_vgcs0(13)@LEGION: Final verdict of PTC: fail reason: "Got unexpected message on control connection."
MTC@LEGION: setverdict(fail): none -> fail reason: "Timeout waiting for Test result", new component reason: "Timeout waiting for Test result"
MTC@LEGION: Dynamic test case error: Port COORD_control has neither connections nor mappings. Message cannot be sent on it.
MTC@LEGION: setverdict(error): fail -> error
MTC@LEGION: Test case TC_complete_vbs finished. Verdict: fail reason: Couldn't find Expect for incoming connection { calledAddress := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000011000001'B, subsystemNumber := 254, globalTitle := omit }, callingAddress := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000010111001'B, subsystemNumber := 254, globalTitle := omit }, qualityOfService := omit, userData := { discriminator := '0'B, spare := '0000000'B, dlci := omit, lengthIndicator := 36, pdu := { bssmap := { vGCS_VBSAssignmentRequest := { messageType := '07'O ("\a"), channelType := { elementIdentifier := '0B'O ("\v"), lengthIndicator := 3, speechOrDataIndicator := '0001'B, spare1_4 := '0000'B, channelRateAndType := '08'O ("\b"), speechId_DataIndicator := '01'O }, assignmentRequirement := { elementIdentifier := '33'O ("3"), assignmentRequirement := '01'O }, cellIdentifier := { elementIdentifier := '05'O, lengthIndicator := 3, cellIdentifierDiscriminator := '0010'B, spare1_4 := '0000'B, cellIdentification := { cI_CI := '002A'O } }, groupCallReference := { elementIdentifier := '37'O ("7"), lengthIndicator := 5, descrGroupbroadcastCallRef := '00001A0000'O }, priority := omit, circuitIdentityCode := omit, downLinkDTX_Flag := omit, encryptionInformation := omit, vSTK_RAND := omit, vSTK := omit, cellIdentifierListSegment := omit, aoIPTransportLayer := { elementIdentifier := '7C'O ("|"), lengthIndicator := 6, ipAddress := { ipv4 := '01010101'O }, uDPPortValue := 10000 }, callIdentifier := { elementIdentifier := '7F'O, callIdentifierInfo := '01000000'O }, codecList := { elementIdentifier := '7D'O ("}"), lengthIndicator := 1, codecElements := { { codecType := GSM_FR (0), tF := '0'B, pT := '0'B, pI := '0'B, fI := '1'B, extendedCodecType := omit, s0_7 := omit, s8_15 := omit } } } } } } }, connectionId := 16002295, importance := omit }
</pre>
<p>Please find the respective PCAP files attached.</p>
<p>libosmocore.git 85554db38d45c3f2e72b5b9c37a5c1c7b9ecc009<br />osmo-msc.git 4fa6c2f636261927a70677963109c569920e473f</p> Cellular Network Infrastructure - Bug #5990 (Closed): osmo-bsc fails to start after osmo-sgsn: "R...https://osmocom.org/issues/59902023-03-31T12:28:23Zfixeria
<p>If I start osmo-stp, osmo-msc, osmo-bsc, and then osmo-sgsn everything works fine. However, if I start osmo-sgsn before starting osmo-bsc, the later is having problems:</p>
<pre>
DRESET INFO osmo_bsc_sigtran.c:64 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
DLSS7 ERROR m3ua.c:508 XUA_AS(as-clnt-OsmoBSC-A)[0x561c69637920]{AS_INACTIVE}: Event AS-TRANSFER.req not permitted
DLSS7 INFO xua_rkm.c:439 0: asp-asp-clnt-OsmoBSC-A: Received RKM REG RES rctx=0 status=Invalid Routing Key
DLSS7 NOTICE xua_default_lm_fsm.c:246 xua_default_lm(asp-clnt-OsmoBSC-A)[0x561c69652ad0]{RKM_REG}: Received RKM_REG_RSP with negative result
DLSS7 INFO osmo_ss7.c:1608 0: asp-asp-clnt-OsmoBSC-A: Restarting ASP asp-clnt-OsmoBSC-A, r=127.0.0.1:2905<->l=0.0.0.0:0
DLSS7 INFO osmo_ss7.c:1841 0: asp-asp-clnt-OsmoBSC-A: Client connected (r=127.0.0.1:2905<->l=127.0.0.1:38305)
DLSS7 INFO xua_rkm.c:439 0: asp-asp-clnt-OsmoBSC-A: Received RKM REG RES rctx=0 status=Invalid Routing Key
DLSS7 NOTICE xua_default_lm_fsm.c:246 xua_default_lm(asp-clnt-OsmoBSC-A)[0x561c696548f0]{RKM_REG}: Received RKM_REG_RSP with negative result
DLSS7 INFO osmo_ss7.c:1608 0: asp-asp-clnt-OsmoBSC-A: Restarting ASP asp-clnt-OsmoBSC-A, r=127.0.0.1:2905<->l=0.0.0.0:0
DLSS7 INFO osmo_ss7.c:1841 0: asp-asp-clnt-OsmoBSC-A: Client connected (r=127.0.0.1:2905<->l=127.0.0.1:56621)
</pre>
<p>Interestingly enough, the routing context is 0 in the logging messages, while I have it set to 2 in the config file.</p>
<p>Below is the configuration snippets for osmo-stp, osmo-msc, osmo-bsc and osmo-sgsn:</p>
<table>
<tr>
<th>Component</th>
<th>point-code</th>
<th>routing-key</th>
</tr>
<tr>
<td> osmo-msc </td>
<td> 0.23.1 </td>
<td> 1 0.23.1 </td>
</tr>
<tr>
<td> osmo-bsc </td>
<td> 0.23.3 </td>
<td> 2 0.23.3 </td>
</tr>
<tr>
<td> osmo-sgsn </td>
<td> 0.23.4 </td>
<td> 0 0.23.4 </td>
</tr>
</table>
<a name="etcosmocomosmo-stpcfg"></a>
<h3 >/etc/osmocom/osmo-stp.cfg<a href="#etcosmocomosmo-stpcfg" class="wiki-anchor">¶</a></h3>
<pre>
cs7 instance 0
xua rkm routing-key-allocation dynamic-permitted
listen m3ua 2905
accept-asp-connections dynamic-permitted
local-ip 127.0.0.1
local-ip ::1
</pre>
<a name="etcosmocomosmo-msccfg"></a>
<h3 >/etc/osmocom/osmo-msc.cfg<a href="#etcosmocomosmo-msccfg" class="wiki-anchor">¶</a></h3>
<pre>
cs7 instance 0
point-code 0.23.1
asp asp-clnt-OsmoMSC-A 2905 0 m3ua
remote-ip 127.0.0.1
as as-clnt-OsmoMSC-A m3ua
asp asp-clnt-OsmoMSC-A
routing-key 1 0.23.1
</pre>
<a name="etcosmocomosmo-bsccfg"></a>
<h3 >/etc/osmocom/osmo-bsc.cfg<a href="#etcosmocomosmo-bsccfg" class="wiki-anchor">¶</a></h3>
<pre>
cs7 instance 0
point-code 0.23.3
asp asp-clnt-OsmoBSC-A 2905 0 m3ua
remote-ip 127.0.0.1
as as-clnt-OsmoBSC-A m3ua
asp asp-clnt-OsmoBSC-A
routing-key 2 0.23.3
</pre>
<a name="etcosmocomosmo-sgsncfg"></a>
<h3 >/etc/osmocom/osmo-sgsn.cfg<a href="#etcosmocomosmo-sgsncfg" class="wiki-anchor">¶</a></h3>
<pre>
cs7 instance 0
point-code 0.23.4
asp asp-clnt-OsmoSGSN 2905 0 m3ua
local-ip 127.0.0.1
remote-ip 127.0.0.1
sctp-role client
as as-clnt-OsmoSGSN m3ua
asp asp-clnt-OsmoSGSN
routing-key 0 0.23.4
</pre>
<a name="Software-versions"></a>
<h3 >Software versions<a href="#Software-versions" class="wiki-anchor">¶</a></h3>
<table>
<tr>
<th>Component</th>
<th>Version</th>
</tr>
<tr>
<td>libosmocore.git</td>
<td>37dc995234c50cc5f3caf325598e7fddd52cb878</td>
</tr>
<tr>
<td>libosmo-sccp.git</td>
<td>79c64ab5556ca0d709a56f0d4f61e2f9044c4550</td>
</tr>
<tr>
<td>osmo-bsc.git</td>
<td>6d369665dda4160068e4f66851c3c30dcbd6133b</td>
</tr>
<tr>
<td>osmo-sgsn.git</td>
<td>d5dca3a67f6c028b870315bc5139f39d938d1610</td>
</tr>
</table> Cellular Network Infrastructure - Bug #5985 (New): tests: not all Osmocom projects have @osmoappd...https://osmocom.org/issues/59852023-03-29T20:09:42Zfixeria
<p>This is a manifest file, which is used by both <code>osmotestvty.py</code> and <code>osmotestconfig.py</code> for running VTY and config tests.</p>
<p>AFAICS, only the following files have this manifest (my local repos, might be incomplete):</p>
<pre>
fixeria@DELL:~/osmo-dev/src$ find . -name osmoappdesc.py
./libosmocore/tests/gb/osmoappdesc.py
./osmo-sgsn/osmoappdesc.py
./libosmo-sccp/osmoappdesc.py
./osmo-bsc/osmoappdesc.py
./osmo-pcu/osmoappdesc.py
./osmo-smlc/osmoappdesc.py
./osmo-mgw/osmoappdesc.py
./osmo-msc/osmoappdesc.py
./osmo-pcap/osmoappdesc.py
./osmo-sip-connector/osmoappdesc.py
</pre>
<p>I am adding checkboxes for projects missing this file. Maybe something for @arehbein to work on?</p> Cellular Network Infrastructure - Bug #5913 (Resolved): ttcn3-pgw-test is broken (open5gs compone...https://osmocom.org/issues/59132023-02-20T09:59:02Zfixeria
<p>Since recently, all testcases are failing in ttcn3-pgw-test:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pgw-test/326/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pgw-test/326/</a></p>
<p>The problem is that some open5gs components fail to start:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pgw-test/326/artifact/logs/pgw/open5gs-smfd.out/*view*/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pgw-test/326/artifact/logs/pgw/open5gs-smfd.out/*view*/</a></p>
<pre>
Open5GS daemon v2.6.0-35-g0df402b
02/18 14:00:24.733: [app] INFO: Configuration: '/data/open5gs-smf.yaml' (../lib/app/ogs-init.c:126)
02/18 14:00:24.746: [sbi] ERROR: TLS enabled but no server key (../lib/sbi/context.c:186)
02/18 14:00:24.746: [app] ERROR: Failed to intialize SMF (../src/smf/app.c:28)
02/18 14:00:24.746: [app] FATAL: Open5GS initialization failed. Aborted (../src/main.c:219)
</pre>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pgw-test/326/artifact/logs/pgw/open5gs-nrf.out/*view*/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pgw-test/326/artifact/logs/pgw/open5gs-nrf.out/*view*/</a></p>
<pre>
Open5GS daemon v2.6.0-35-g0df402b
02/18 14:00:23.789: [app] INFO: Configuration: '/data/open5gs-nrf.yaml' (../lib/app/ogs-init.c:126)
02/18 14:00:23.791: [sbi] ERROR: TLS enabled but no server key (../lib/sbi/context.c:186)
02/18 14:00:23.791: [app] ERROR: Failed to intialize NRF (../src/nrf/app.c:28)
02/18 14:00:23.791: [app] FATAL: Open5GS initialization failed. Aborted (../src/main.c:219)
</pre>
<p>Interestingly enough, nowhere in our config files TLS is enabled explicitly.</p> Cellular Network Infrastructure - Bug #5823 (Resolved): ttcn3-bsc-test: BSC_Tests.TC_chan_rel_con...https://osmocom.org/issues/58232022-12-11T11:08:17Zfixeria
<p>Starting from build <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1951/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1951/</a>, I see sporadic failures of <code>BSC_Tests.TC_chan_rel_conn_fail</code>.</p>
<pre>
Timeout of T_guard
BSC_Tests.ttcn:12102 BSC_Tests control part
BSC_Tests.ttcn:1984 TC_chan_rel_conn_fail testcase
</pre>
<p>As can be seen from the attached PCAP file, osmo-bsc fails to deliver <code>BSSMAP Clear Request/Complete</code> messages:</p>
<pre>
614 3.071251 172.18.2.20 → 172.18.2.203 GSMTAP 178 Tx MSC: BSSMAP: CLEAR REQUEST
615 3.071265 172.18.2.20 → 172.18.2.203 GSMTAP 248 Sending connection (id=15) oriented data to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP (00 04 22 04 01 01 )
616 3.071276 172.18.2.20 → 172.18.2.203 GSMTAP 194 Received SCCP User Primitive (N-DATA.request)
617 3.071285 172.18.2.20 → 172.18.2.203 GSMTAP 220 SCCP-SCOC(15)[0x55725960a7b0]{CONN_PEND_OUT}: Received Event N-DATA.req
618 3.071317 172.18.2.20 → 172.18.2.203 GSMTAP 225 SCCP-SCOC(15)[0x55725960a7b0]{CONN_PEND_OUT}: Event N-DATA.req not permitted
619 3.071346 172.18.2.20 → 172.18.2.203 GSMTAP 253 SUBSCR_CONN(msc0-conn15)[0x55725960a2b0]{WAIT_CLEAR_CMD}: Unable to deliver BSSMAP Clear Request message
620 3.071356 172.18.2.20 → 172.18.2.203 GSMTAP 247 SUBSCR_CONN(msc0-conn15)[0x55725960a2b0]{WAIT_CLEAR_CMD}: State change to WAIT_SCCP_RLSD (X4, 60s)
621 3.071368 172.18.2.20 → 172.18.2.203 GSMTAP 179 Tx MSC: BSSMAP: CLEAR COMPLETE
622 3.071380 172.18.2.20 → 172.18.2.203 GSMTAP 239 Sending connection (id=15) oriented data to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP (00 01 21 )
623 3.071390 172.18.2.20 → 172.18.2.203 GSMTAP 194 Received SCCP User Primitive (N-DATA.request)
624 3.071399 172.18.2.20 → 172.18.2.203 GSMTAP 220 SCCP-SCOC(15)[0x55725960a7b0]{CONN_PEND_OUT}: Received Event N-DATA.req
625 3.071413 172.18.2.20 → 172.18.2.203 GSMTAP 225 SCCP-SCOC(15)[0x55725960a7b0]{CONN_PEND_OUT}: Event N-DATA.req not permitted
626 3.071427 172.18.2.20 → 172.18.2.203 GSMTAP 237 SUBSCR_CONN(msc0-conn15)[0x55725960a2b0]{WAIT_SCCP_RLSD}: Unable to deliver SCCP message
</pre> Cellular Network Infrastructure - Bug #5764 (New): GCC does not check format strings in LOGPFSM m...https://osmocom.org/issues/57642022-11-11T06:30:22Zfixeria
<p>Recently I submitted a patch with an error in one of the LOGPFSM statements ('%s' instead of '%d' for printing an uint16_t):</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1">https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1</a><br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1/src/host/trxcon/src/trxcon_fsm.c#229">https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1/src/host/trxcon/src/trxcon_fsm.c#229</a></p>
<p>Surprisingly, gcc does not emit any warnings and compiles obviously wrong code just fine. This is not specific to <code>osmocom-bb.git</code>, I was able to reproduce this problem in other Osmocom repositories, except <code>libosmocore.git</code> where it magically does emit <code>-Wformat</code> warnings as expected. This is most likely a bug in gcc, because clang behaves as expected.</p>
<p>I also tried to narrow down the problem to a specific macro:</p>
<pre><code class="c syntaxhl"><span class="cp">#define FMT "Test %s\n"
#define ARG 1337, "extra", -1
</span>
<span class="cm">/* GCC does emit -Wformat / -Wformat-extra-args warnings as expected */</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DAPP</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="cm">/* GCC does *not* emit any warnings, clang does */</span>
<span class="n">LOGPFSML</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="n">LOGPFSMLSRC</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="n">LOGPFSMSLSRC</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span> <span class="o">?</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="o">-></span><span class="n">log_subsys</span> <span class="o">:</span> <span class="n">DLGLOBAL</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span>
<span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="cm">/* GCC does emit -Wformat / -Wformat-extra-args warnings as expected */</span>
<span class="n">LOGPSRC</span><span class="p">((</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="o">-></span><span class="n">log_subsys</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span>
<span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span>
<span class="s">"%s{%s}: "</span> <span class="n">FMT</span><span class="p">,</span>
<span class="n">osmo_fsm_inst_name</span><span class="p">(</span><span class="n">fi</span><span class="p">),</span>
<span class="p">(</span><span class="n">fi</span><span class="p">)</span> <span class="o">?</span> <span class="n">osmo_fsm_state_name</span><span class="p">((</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="p">,</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">state</span><span class="p">)</span> <span class="o">:</span> <span class="s">"fi=NULL"</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
</code></pre>
<p>Running gcc with <code>-E -P</code> confirms that the preprocessor expands all <code>LOGPFSM</code> statements identical to the last <code>LOGPSRC</code>.</p> Cellular Network Infrastructure - Bug #5750 (New): contrib/jenkins.sh: build with -Wunused-macros...https://osmocom.org/issues/57502022-11-08T20:07:03Zfixeria
<p>According to <code>man cpp</code>:</p>
<pre>
-Wundef
Warn if an undefined identifier is evaluated in an "#if" directive.
Such identifiers are replaced with zero.
-Wunused-macros
Warn about macros defined in the main file that are unused. A macro
is used if it is expanded or tested for existence at least once. The
preprocessor also warns if the macro has not been used at the time it
is redefined or undefined.
Built-in macros, macros defined on the command line, and macros
defined in include files are not warned about.
Note: If a macro is actually used, but only used in skipped
conditional blocks, then the preprocessor reports it as unused. To
avoid the warning in such a case, you might improve the scope of the
macro's definition by, for example, moving it into the first skipped
block. Alternatively, you could provide a dummy use with something
like:
#if defined the_macro_causing_the_warning
#endif
</pre>
<p>I think it would be good to have these options enabled during the build verification.</p>
<p>With this option enabled, I quickly found a copy-paste bug in osmo-bsc:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/30058">https://gerrit.osmocom.org/c/osmo-bsc/+/30058</a></p> Cellular Network Infrastructure - Bug #5749 (New): configure.ac: default CFLAGS, LT_INIT adds "-g...https://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://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://osmocom.org/users/7">laforge</a> what do you think?</p> Cellular Network Infrastructure - Bug #5729 (Resolved): ttcn3-bsc-test-sccplite: +47 failues sinc...https://osmocom.org/issues/57292022-10-25T18:12:52Zfixeria
<p>Starting from <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1644/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1644/</a>, we see a massive fallout. Most of them fail due to timeout waiting for response to CRCX.</p>
<pre>
Timeout waiting for response to {
line := {
verb := "CRCX",
trans_id := "0",
ep := "1@mgw",
ver := "1.0"
},
params := {
{
code := "M",
val := "sendrecv"
},
{
code := "C",
val := "51234"
},
{
code := "L",
val := "p:20, a:AMR"
}
},
sdp := {
protocol_version := 0,
origin := {
user_name := "-",
session_id := "23",
session_version := "42",
net_type := "IN",
addr_type := "IP4",
addr := "127.0.0.4"
},
session_name := "-",
information := omit,
uri := omit,
emails := omit,
phone_numbers := omit,
connection := {
net_type := "IN",
addr_type := "IP4",
conn_addr := {
addr := "127.0.0.5",
ttl := omit,
num_of_addr := omit
}
},
bandwidth := omit,
times := {
{
time_field := {
start_time := "0",
stop_time := "0"
},
time_repeat := omit
}
},
timezone_adjustments := omit,
key := omit,
attributes := omit,
media_list := {
{
media_field := {
media := "audio",
ports := {
port_number := 14000,
num_of_ports := omit
},
transport := "RTP/AVP",
fmts := {
"3"
}
},
information := omit,
connections := omit,
bandwidth := omit,
key := omit,
attributes := {
{
ptime := {
attr_value := "20"
}
}
}
}
}
}
}
BSC_Tests.ttcn:12030 BSC_Tests control part
BSC_Tests.ttcn:4047 TC_assignment_fr_a5_0 testcase
</pre>
<p>Even more tests started to fail today: <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1648/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1648/</a>.</p> Cellular Network Infrastructure - Bug #5727 (Resolved): ttcn3-bsc-test: all LCLS test cases are f...https://osmocom.org/issues/57272022-10-25T09:44:55Zfixeria
<p>All failing with the following verdict:</p>
<pre>
"MSC_ConnectionHandler.ttcn:1484 : Received unexpected ASSIGNMENT FAIL"
BSC_Tests_LCLS.ttcn:743 BSC_Tests_LCLS control part
BSC_Tests_LCLS.ttcn:264 TC_lcls_gcr_only testcase
</pre>
<p>Looks like osmo-bsc is not happy about the <code>BSSAP Assignment Request</code> sent by the testsuite?</p> Cellular Network Infrastructure - Bug #5689 (Resolved): libosmo-gprs: cgit mirror is out of synchttps://osmocom.org/issues/56892022-09-22T16:33:34Zfixeria
<p>The cgit mirror is out of sync with Gerrit:</p>
<pre>
$ git ls-remote https://gerrit.osmocom.org/libosmo-gprs HEAD
0b5a816356a9f74d5ac05b6d2171f571b869f2b8 HEAD
commit 0b5a816356a9f74d5ac05b6d2171f571b869f2b8 (gerrit/master)
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Thu Sep 22 01:50:43 2022 +0700
</pre>
<p>vs</p>
<pre>
$ git ls-remote https://git.osmocom.org/libosmo-gprs HEAD
11cbba9d9dd3423959adc6cd9200fe1ce9afd227 HEAD
commit 11cbba9d9dd3423959adc6cd9200fe1ce9afd227 (origin/master)
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Wed Aug 10 03:47:09 2022 +0700
</pre>
<p>The sync worked until Aug 10th and suddenly got broken since then.</p> Cellular Network Infrastructure - Bug #5670 (Resolved): git.osmocom.org: cloning via https:// is ...https://osmocom.org/issues/56702022-08-30T19:50:57Zfixeria
<p>I just noticed that cloning from <code>git.osmocom.org</code> via <code>https://</code> is <strong>significantly</strong> slower than cloning from Gitea or Gerrit.</p>
<pre>
$ time git clone https://gerrit.osmocom.org/libosmo-sccp
Cloning into 'libosmo-sccp'...
remote: Counting objects: 127, done
remote: Total 5302 (delta 0), reused 5302 (delta 0)
Receiving objects: 100% (5302/5302), 1.94 MiB | 37.49 MiB/s, done.
Resolving deltas: 100% (3049/3049), done.
real 0m0.204s
user 0m0.211s
sys 0m0.056s
$ time git clone https://gitea.osmocom.org/osmocom/libosmo-sccp
Cloning into 'libosmo-sccp'...
remote: Enumerating objects: 5302, done.
remote: Counting objects: 100% (5302/5302), done.
remote: Compressing objects: 100% (2149/2149), done.
remote: Total 5302 (delta 3134), reused 5102 (delta 2984), pack-reused 0
Receiving objects: 100% (5302/5302), 1.74 MiB | 36.38 MiB/s, done.
Resolving deltas: 100% (3134/3134), done.
real 0m0.244s
user 0m0.242s
sys 0m0.034s
$ time git clone https://git.osmocom.org/libosmo-sccp
Cloning into 'libosmo-sccp'...
Fetching objects: 5302, done.
real 0m14.780s
user 0m1.147s
sys 0m1.166s
</pre>
<p>Note that even the output looks different when cloning from <code>git.osmocom.org</code>.</p> Cellular Network Infrastructure - Bug #5658 (Rejected): sporadic failures when cloning from https...https://osmocom.org/issues/56582022-08-23T08:25:00Zfixeria
<p>Recently we migrated our osmo-ci infrastructure from git:// to https://</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ci/+/28349">https://gerrit.osmocom.org/c/osmo-ci/+/28349</a> [MERGED]</p>
<p>and immediately after that we started to observe sporadic git-clone failures in master Jenkins jobs like:</p>
<pre>
+ git clone https://git.osmocom.org/libosmo-abis libosmo-abis
Cloning into 'libosmo-abis'...
error: (curl_result = 56, http_code = 200, sha1 = 6498826eae07a02be1afc8e4f161bd1caa626e7d)
error: Unable to find 6498826eae07a02be1afc8e4f161bd1caa626e7d under https://git.osmocom.org/libosmo-abis
Cannot obtain needed tree 6498826eae07a02be1afc8e4f161bd1caa626e7d
while processing commit e58d33153dd2bed3629b9a09fd6add58f296bd6a.
error: fetch failed.
+ git clone https://git.osmocom.org/libosmo-sccp libosmo-sccp
Cloning into 'libosmo-sccp'...
error: HTTP/2 stream 0 was closed cleanly, but before getting all response header fields, treated as error (curl_result = 92, http_code = 0, sha1 = 80f1e4bfb9c161c76f04443bd03b8a2c3ce7dbd5)
error: HTTP/2 stream 0 was closed cleanly, but before getting all response header fields, treated as error (curl_result = 92, http_code = 0, sha1 = 7be9bdd1632efe63b9af2d42dd355eda7883747c)
error: Unable to find 7be9bdd1632efe63b9af2d42dd355eda7883747c under https://git.osmocom.org/libosmo-sccp
Cannot obtain needed blob 7be9bdd1632efe63b9af2d42dd355eda7883747c
while processing commit e7c8067df026fd294af2c95fbd2ceb16eeab7d74.
error: fetch failed.
</pre>
<p>In the last few days only master-openbsc is affected (failing to clone libosmo-sccp):</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-openbsc/12429/">https://jenkins.osmocom.org/jenkins/view/master/job/master-openbsc/12429/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-openbsc/12418/">https://jenkins.osmocom.org/jenkins/view/master/job/master-openbsc/12418/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-openbsc/12414/">https://jenkins.osmocom.org/jenkins/view/master/job/master-openbsc/12414/</a></p> Cellular Network Infrastructure - Bug #5635 (Resolved): ttcn3-bts-test: TC_rsl_ms_pwr_dyn_{ass_up...https://osmocom.org/issues/56352022-07-27T00:24:18Zfixeria
<p>After the recent changes in osmocom-bb.git/trxcon, we started to see some new regressions. Some of them caused by the problem explained in <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Separate TDMA scheduler into a library (libtdmasched) (Resolved)" href="https://osmocom.org/issues/3761">#3761</a>:</p>
<blockquote>
<ul>
<li>Sending L1 SACCH header = { 0x00, 0x00 } in cached SACCH PDUs.
<ul>
<li>You'll see "FIXME: no direct access to trx->{tx_power,ta}" during compilation.</li>
<li>Makes <code>TC_rsl_ms_pwr_dyn_{ass_updown,max}</code> and <code>TC_ms_pwr_ctrl_{constant,pf_ewma}</code> fail.</li>
</ul></li>
</ul>
</blockquote>
<p>The problem is likely in the testsuite itself, because generally we should not rely on cached measurements.</p> Cellular Network Infrastructure - Bug #5366 (Resolved): ttcn3-{bsc,msc,sgsn,smlc,sccp}-test regre...https://osmocom.org/issues/53662021-12-21T14:20:00Zfixeria
<p>Since Dec 17 2021 we started to see massive regressions in the recent test results on Jenkins:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1594/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1594/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1500/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1500/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sccp-test/707/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sccp-test/707/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sgsn-test/1457/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sgsn-test/1457/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-smlc-test/431/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-smlc-test/431/</a></p>
<p>Interestingly enough, -latest is generally not affected, except ttcn3-msc-test:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1167/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1167/</a> (+151 failures)<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1168/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1168/</a> (-152 failures, back to normal)<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1169/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1169/</a> (+152 failures)</p> Cellular Network Infrastructure - Bug #5282 (Resolved): ttcn3-sip-test is broken since build #1342https://osmocom.org/issues/52822021-10-27T10:54:13Zfixeria
<p>Basically all test cases started to fail a few days ago:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/1342/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/1342/</a></p>
<pre>
/osmo-ttcn3-hacks/sip/SIP_Tests: Segmentation fault occurred
/usr/lib/titan/libttcn3-parallel-dynamic.so(_Z14signal_handleri+0xa3)[0x7f076b36a363]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060)[0x7f07697bd060]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x14)[0x7f0769805524]
/usr/lib/titan/libttcn3-parallel-dynamic.so(Free+0xe)[0x7f076b359e8e]
/osmo-ttcn3-hacks/sip/UD_PT.so(_ZN12UD__PortType15UD__PT_PROVIDER24Handle_Fd_Event_ReadableEi+0x1de)[0x7f076b7db66e]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN19Fd_And_Timeout_User13call_handlersEi+0x56d)[0x7f076b32e3bd]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN13TTCN_Snapshot8take_newEb+0x387)[0x7f076b32eaf7]
/osmo-ttcn3-hacks/sip/MNCC_Emulation.so(_ZN15MNCC__Emulation5main_ERKNS_7MnccOpsERK10CHARSTRINGS5_RK7BOOLEAN+0x140a)[0x7f07829570d0]
/osmo-ttcn3-hacks/sip/MNCC_Emulation.so(_ZN15MNCC__Emulation18start_ptc_functionEPKcR8Text_Buf+0x911)[0x7f0782959c18]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN11Module_List14start_functionEPKcS1_R8Text_Buf+0x2b)[0x7f076b314c0b]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN12TTCN_Runtime14start_functionEPKcS1_R8Text_Buf+0x25)[0x7f076b326dd5]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN18TTCN_Communication13process_startEv+0x42)[0x7f076b2eac22]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN18TTCN_Communication23process_all_messages_tcEv+0x2f5)[0x7f076b2eb475]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN12TTCN_Runtime8ptc_mainEv+0xdf)[0x7f076b32a9ef]
/usr/lib/titan/libttcn3-parallel-dynamic.so(main+0x365)[0x7f076b022345]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f07697aa2e1]
/osmo-ttcn3-hacks/sip/SIP_Tests(+0x178a)[0x564418a0178a]
</pre>
<p>This change is most likely the culprit:</p>
<p><a class="external" href="https://git.osmocom.org/osmo-sip-connector/commit/?id=364f237b42d34b14de283d6cb0db2d8c246645d6">https://git.osmocom.org/osmo-sip-connector/commit/?id=364f237b42d34b14de283d6cb0db2d8c246645d6</a></p>
<pre>
commit 364f237b42d34b14de283d6cb0db2d8c246645d6 (origin/master, origin/HEAD)
Author: Keith <keith@rhizomatica.org>
Date: Sun Jan 31 05:24:29 2021 +0100
MNCC v8: Implement Basic Support for Global Call Reference.
</pre>
<p>MNCCv8 should have been implemented in ttcn3-sip-test before merging this patch.</p> Cellular Network Infrastructure - Bug #5112 (Resolved): osmo-gsm-manuals: build verification is b...https://osmocom.org/issues/51122021-04-10T01:57:24Zfixeria
<p>Today I submitted a set of patches for osmo-gsm-manuals:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23687">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23687</a> TRXD: generalze description of the 'RFU' ('PAD') field<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23688">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23688</a> TRXD: clarify modulation specific length of Soft-/Hard-bits<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/22867">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/22867</a> TRXD: add documentation for TRXDv2 protocol</p>
<p>and all of them did not pass the build verification. <a class="user active" href="https://osmocom.org/users/1741">lynxis</a> also faced this problem with his:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23393">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23393</a> common/chapters: extend gb/ns2 chapters</p>
<p>The build logs contain a very cryptic failure reason:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-gsm-manuals/559/a1=default,a2=default,a3=default,a4=default,label=osmocom-gerrit-debian9/console">https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-gsm-manuals/559/a1=default,a2=default,a3=default,a4=default,label=osmocom-gerrit-debian9/console</a></p>
<pre>
# Do print the WARNING output but return error if any was found
# (grep -v would omit the WARNING output from the log).
asciidoc: WARNING: mgcp_extension_osmux.adoc: line 2: section title out of sequence: expected level 1, got level 2
../build/Makefile.asciidoc.inc:90: recipe for target 'test-usermanual.check' failed
make[3]: Leaving directory '/build/tests'
make[3]: *** [test-usermanual.check] Error 1
../build/Makefile.asciidoc.inc:80: recipe for target 'check' failed
</pre> Cellular Network Infrastructure - Bug #4957 (Closed): ttcn3-sip-test is broken since 15 Dec 2020https://osmocom.org/issues/49572021-01-19T14:35:56Zfixeria
<p>All test cases fail under both Debian and CentOS:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/1051/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/1051/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-sip-test/238/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-sip-test/238/</a></p>
<p>Although, the 'latest' is relatively stable:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test-latest/828/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test-latest/828/</a></p>
<p>I spent a few hours trying to investigate what's going on. Here are some intermediate results:</p>
<ul>
<li>Q: Did sofia-sip change?
<ul>
<li>A: No. All test cases on my machine also fail with v1.12.11 that I installed back in 2019.</li>
</ul>
</li>
<li>Q: Did the test suite change?
<ul>
<li>A: I could not find any changes that would affect the test suite behavior directly:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ib4399aa488afd917e3eda5e79d56ea3797ef7c78">https://gerrit.osmocom.org/q/Ib4399aa488afd917e3eda5e79d56ea3797ef7c78</a> - only expected-results.xml was changed,</li>
<li><a class="external" href="https://gerrit.osmocom.org/q/I37db9962f51baf2c63bd58ec47ec89f773d7a255">https://gerrit.osmocom.org/q/I37db9962f51baf2c63bd58ec47ec89f773d7a255</a> - changing code that is commended out.</li>
</ul>
</li>
</ul>
</li>
<li>Q: Did osmo-sip-connector's code change?
<ul>
<li>A: Yes, some new commits have been merged recently:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ia156010194c1f4334a4966d01aadfd02fa7097a8">https://gerrit.osmocom.org/q/Ia156010194c1f4334a4966d01aadfd02fa7097a8</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ic926d192c238ef84fb3ad2be27e507e010b0e93f">https://gerrit.osmocom.org/q/Ic926d192c238ef84fb3ad2be27e507e010b0e93f</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ia84602955b913a3bb13de7a6a92048799f2e1955">https://gerrit.osmocom.org/q/Ia84602955b913a3bb13de7a6a92048799f2e1955</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/I870c16d7ee5e5424304f3c1c9fb78af418ae2577">https://gerrit.osmocom.org/q/I870c16d7ee5e5424304f3c1c9fb78af418ae2577</a></li>
</ul>
</li>
<li>... downgrading before them does not change anything though :/
<ul>
<li>tried I17e1adac40ac01daee0dd83da0a6aaebd78ea0dc and I3b1bebbcc9e36be43d8d055c8d28cbb38ff21b37</li>
</ul>
</li>
</ul>
</li>
<li>Q: Did libosmocore's code change?
<ul>
<li>A: Needs to be investigated.
<ul>
<li>I tried downgrading to I781ab838bd02ac1b13d384ce3f4259e26cedb61e => nothing changed.</li>
</ul></li>
</ul></li>
</ul>
<p>The test cases fail due to DTEs listed below:</p>
<ul>
<li>"MNCC_CodecPort.ttcn:19 Dynamic test case error: Initializing a variable of enumerated type @MNCC_Types.MNCC_MsgType with invalid numeric value 346140544. (No such file or directory)" </li>
<li>"Dynamic test case error: SIP Test Port: syntax error "v" -> unexpected character at character position 1." </li>
<li>"MNCC_Emulation.ttcn:348 Dynamic test case error: Write error (Broken pipe)"</li>
</ul>
<p>Sometimes it's one reason, sometimes another. Sometimes there is no DTE but "timeout of Tguard". Weird.</p> Cellular Network Infrastructure - Bug #4662 (Resolved): ttcn3-bts-test: both TC_si_sched_13_2bis_...https://osmocom.org/issues/46622020-07-10T17:58:38Zfixeria
<p>Both test cases are broken since build#949 [1][2]:</p>
<pre>
Dynamic test case error: While RAW-decoding type '@GSM_SystemInformation.SystemInformation':
There is not enough bits in the buffer to decode type @GSM_RestOctets.UTRAN_GPRSMeasParamsDescOpt.presence.
</pre>
<p>I think this regression is caused by [3]. The problem is that in ttcn3-bts-test, SI2quater contains a list of UTRAN neighbor cells, that is currently not implemented in <em>SI2quaterRestOctets</em>. The coding of this list is quite complex (more complex than the E-ARFCN list), and would probably require us to implement some parts in C++. As a quick work around, we could avoid calling <em>dec_SystemInformation()</em> on SI2quater in f_l1_sample_si().</p>
<p>[1] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/</a><br />[2] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_si_sched_13_2bis_2ter_2quater.merged">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_si_sched_13_2bis_2ter_2quater.merged</a><br />[3] <a class="external" href="https://gerrit.osmocom.org/q/I879c37eb51ece55d79346c6bf1a4951c3f11c77e">https://gerrit.osmocom.org/q/I879c37eb51ece55d79346c6bf1a4951c3f11c77e</a></p> Cellular Network Infrastructure - Bug #4659 (Rejected): ttcn3-bts-test: sporadic test case failur...https://osmocom.org/issues/46592020-07-09T09:49:29Zfixeria
<p>It was first noticed by <a class="user active" href="https://osmocom.org/users/91">neels</a> that in build#945 [1] we got more failed test cases than usually. Now I see similar failures in build#949 [2]. The build aftifacts in both cases look really suspicious: it seems like <strong>osmo-bts-trx did not even try to establish any OML/RSL connections</strong> [3]. The packet captures [4] contain no A-bis traffic at all. What's even more strange is that osmo-bts-trx was scheduling Downlink bursts even without being connected to the BSC. This needs to be investigated.</p>
<p>[1] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/945/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/945/</a><br />[2] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/</a><br />[3] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_pcu_act_req.merged">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_pcu_act_req.merged</a><br />[4] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_pcu_act_req.pcap">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_pcu_act_req.pcap</a></p> Cellular Network Infrastructure - Bug #4619 (Resolved): ttcn3-bsc-test: all LCLS test cases broke...https://osmocom.org/issues/46192020-06-17T09:14:40Zfixeria
<p>Check out <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/</a>.</p>
<p>This is probably related to my recent IPA/RSL emulation refactoring changes:</p>
<blockquote>
<p>Changes<br />1. centos-repo-install-test: new image (detail)<br />2. debian-repo-install-test: move scripts to osmo-ci (detail)<br />3. ttcn3-bts-test: enable 3 additional transceivers for BTS#0 (detail)</p>
</blockquote>
<p>Here is an extract from the build artifacts of build#987:</p>
<pre>
06:26:01.572279 921 RSL_Emulation.ttcn:556 Matching on port IPA_PT succeeded: matched
06:26:01.572304 921 RSL_Emulation.ttcn:556 Receive operation on port IPA_PT succeeded, message from IPA0-RSL-IPA(920): @IPA_Emulation.ASP_RSL_Unitdata : { conn_id := 1,
streamId := IPAC_PROTO_RSL_TRX0 (0), rsl := { msg_disc := { msg_group := RSL_MDISC_IPACCESS (63), transparent := false }, msg_type := RSL_MT_IPAC_CRCX (112), ies := { {
iei := RSL_IE_CHAN_NR (1), body := { chan_nr := { u := { ch0 := RSL_CHAN_NR_Bm_ACCH (1) }, tn := 2 } } }, { iei := RSL_IE_IPAC_SPEECH_MODE (244), body := { ipa_speech_mo
de := { reserved := '00'B, mode := RSL_IPA_SPM_RECVONLY (1), codec := RSL_IPA_CODEC_FR (0) } } }, { iei := RSL_IE_IPAC_RTP_PAYLOAD (242), body := { ipa_rtp_pt := 3 } } }
} } id 27
06:26:01.572325 921 RSL_Emulation.ttcn:556 Message with id 27 was extracted from the queue of IPA_PT.
06:26:01.572351 921 RSL_Emulation.ttcn:199 No Dchan handler for 0{ u := { ch0 := RSL_CHAN_NR_Bm_ACCH (1) }, tn := 2 }
06:26:01.572469 923 MSC_ConnectionHandler.ttcn:784 dec_PDU_ML3_NW_MS(): Decoded @MobileL3_Types.PDU_ML3_NW_MS: { discriminator := '0110'B, tiOrSkip := { skipIndicator :=
'0000'B }, msgs := { rrm := { assignmentCommand := { messageType := '00101110'B, descrOf1stChAfterTime := { timeslotNumber := '010'B, channelTypeandTDMAOffset := '00001
'B, octet3 := '43'O ("C"), octet4 := '67'O ("g") }, PowerCommand := { powerlevel := '00111'B, fPC_EP := '0'B, ePC_Mode := '0'B, spare_1 := '0'B }, frequencyList_at := om
it, cellChannelDescr := omit, descrMultislotAllocation := omit, modeOf1stChannel := { elementIdentifier := '63'O ("c"), mode := '01'O }, channelSet2 := omit, channelSet3
:= omit, channelSet4 := omit, channelSet5 := omit, channelSet6 := omit, channelSet7 := omit, channelSet8 := omit, descrOf2ndChAfterTime := omit, modeOf2ndChannel := omi
t, mobileAllocation_at := omit, startingTime := omit, frequencyList_bt := omit, descrOf1stCh_bt := omit, descrOf2ndCh_bt := omit, frequencyChannelSequence := omit, mobil
eAllocation_bt := omit, cipherModeSetting := omit, vGCS_TargetModeIndication := omit, multiRateConfiguration := omit, vGCS_Ciphering_Parameters := omit, extendedTSCSet_a
fterTime := omit, extendedTSCSet_beforeTime := omit } } } }
06:26:01.572471 921 RSL_Emulation.ttcn:563 setverdict(fail): none -> fail reason: "RSL for unknown Dchan", new component reason: "RSL for unknown Dchan"
06:26:01.572505 921 RSL_Emulation.ttcn:564 Stopping MTC. The current test case will be terminated.
06:26:01.572526 921 RSL_Emulation.ttcn:564 Stopping test component execution.
</pre>
<p>Note that ttcn3-bsc-test-latest is not affected.</p> Cellular Network Infrastructure - Bug #4618 (Resolved): osmo-gsm-tester_virtual is completely bro...https://osmocom.org/issues/46182020-06-17T08:59:41Zfixeria
<p>Check out <a class="external" href="https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/test_results_analyzer/</a>.</p>
<pre>
Traceback (most recent call last):
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/core/test.py", line 76, in run
self.path)
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/core/util.py", line 367, in run_python_file
spec.loader.exec_module( importlib.util.module_from_spec(spec) )
File "<frozen importlib._bootstrap_external>", line 673, in exec_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
File "/build/osmo-gsm-tester/sysmocom/suites/nitb_netreg_mass/register_default_mass.py", line 14, in <module>
modems = tenv.all_resources(tenv.modem)
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/testenv.py", line 279, in all_resources
l.append(resource_func())
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/testenv.py", line 264, in modem
ms_obj = MS.get_instance_by_type(self, conf)
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/obj/ms.py", line 78, in get_instance_by_type
return ms_class(testenv, conf)
TypeError: Can't instantiate abstract class MSOsmoMobile with abstract methods get_assigned_addr, is_registered
</pre> Cellular Network Infrastructure - Bug #4617 (Resolved): ttcn3-bsc-test: sporadic TC_ho_neighbor_c...https://osmocom.org/issues/46172020-06-17T08:22:45Zfixeria
<p>Check out <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/</a>.</p>
<ul>
<li>TC_ho_neighbor_config_2 (see build 1000 and 1002)</li>
<li>TC_ho_neighbor_config_6 (see build 995)</li>
<li>TC_ho_neighbor_config_7 (see build 999)</li>
</ul>
<p>Here is an extract from build artifacts:</p>
<pre>
06:18:28.242981 785 RSL_Emulation.ttcn:581 Message with id 19 was extracted from the queue of IPA_PT.
06:18:28.243004 785 RSL_Emulation.ttcn:205 No Dchan handler for trx_nr=0 and chan_nr={ u := { ch0 := RSL_CHAN_NR_Bm_ACCH (1) }, tn := 1 }
06:18:28.243112 790 RSL_Emulation.ttcn:674 Called on RSL_PROC to IPA0-RSL-RSL(785) @RSL_Emulation.RSLEM_register : { trx_nr := 0, chan_nr := { u := { ch0 := RSL_CHAN_NR_Bm_ACCH (1) }, tn := 1 }, hdlr := TC_ho_neighbor_config_2(790) }
06:18:28.243156 785 RSL_Emulation.ttcn:588 setverdict(fail): none -> fail reason: "RSL for unknown Dchan", new component reason: "RSL for unknown Dchan"
06:18:28.243186 785 RSL_Emulation.ttcn:589 Stopping MTC. The current test case will be terminated.
06:18:28.243204 785 RSL_Emulation.ttcn:589 Stopping test component execution.
</pre>
<p>Note that ttcn3-bsc-test-latest is not affected. Any ideas?</p> Cellular Network Infrastructure - Bug #4573 (Resolved): [centos] ttcn3-msc-test: 177 failures!https://osmocom.org/issues/45732020-05-31T18:37:18Zfixeria
<p>See <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-msc-test/2/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-msc-test/2/</a>.</p>
<p>Here I what I noticed in the logs of osmo-stp (build artifacts):</p>
<pre>
20200531003124852 DLGLOBAL <0000> telnet_interface.c:104 Available via telnet 127.0.0.1 4239
20200531003126073 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003126073 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003128331 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003131074 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003131075 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003136075 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003136076 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003138405 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003141077 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003141077 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003146078 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
</pre>
<p>and osmo-msc:</p>
<pre>
20200531003126073 DSGS <0011> sgs_server.c:186 SGs socket bound to r=NULL<->l=0.0.0.0:29118
20200531003126073 DMSC <0006> msc_main.c:697 A-interface: SCCP user OsmoMSC-A:RI=SSN_PC,PC=(no PC),SSN=BSSAP, cs7-instance 0 ((null))
20200531003126073 DMSC <0006> msc_main.c:716 Iu-interface: SCCP user OsmoMSC-IuCS:RI=SSN_PC,PC=(no PC),SSN=RANAP, cs7-instance 0 ((null))
20200531003126073 DLINP <0015> stream.c:113 couldn't activate SCTP events on FD 12
20200531003126073 DLSS7 <001f> xua_default_lm_fsm.c:354 xua_default_lm(asp-clnt-OsmoMSC-A)[0x831380]{WAIT_ASP_UP}: Ignoring primitive M-ASP_DOWN.indication
20200531003126073 DLINP <0015> stream.c:269 [WAIT_RECONNECT] osmo_stream_cli_write(): not connected, dropping data!
</pre>
<p>The origin of this error message is libosmo-netif's sctp_sock_activate_events():</p>
<pre><code class="c syntaxhl"><span class="cm">/* IMPORTANT: Do NOT enable sender_dry_event here, see
* https://bugzilla.redhat.com/show_bug.cgi?id=1442784 */</span>
<span class="n">rc</span> <span class="o">=</span> <span class="n">setsockopt</span><span class="p">(</span><span class="n">fd</span><span class="p">,</span> <span class="n">IPPROTO_SCTP</span><span class="p">,</span> <span class="n">SCTP_EVENTS</span><span class="p">,</span>
<span class="o">&</span><span class="n">event</span><span class="p">,</span> <span class="k">sizeof</span><span class="p">(</span><span class="n">event</span><span class="p">));</span>
<span class="k">if</span> <span class="p">(</span><span class="n">rc</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DLINP</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="s">"couldn't activate SCTP events "</span>
<span class="s">"on FD %u</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">fd</span><span class="p">);</span>
</code></pre> Cellular Network Infrastructure - Bug #4279 (Resolved): osmo-gsm-manuals: Jenkins build broken: "...https://osmocom.org/issues/42792019-11-23T05:51:33Zfixeria
<p>Some of our Jenkins master builds are failing from yesterday (Nov 22):</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-trx/1503/">https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-trx/1503/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-bts/2966/">https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-bts/2966/</a></p> Cellular Network Infrastructure - Feature #4006 (Stalled): TRX protocol: wind of changehttps://osmocom.org/issues/40062019-05-16T19:54:33Zfixeria
<p>We are using TRX protocol in <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki">OsmoBTS</a> in order to "speak" with transceiver (e.g. <a class="wiki-page" href="https://osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>, FakeTRX). Basically it defines three interfaces: clock for TDMA frame clock indications, control (we agreed to call it TRXC) for transceiver management, and data (TRXD) for exchanging Rx/Tx bursts. It was first introduced in <a href="http://openbts.org/" class="external">OpenBTS</a> project, from which we forked <a class="wiki-page" href="https://osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>. For more information, please see: <a class="external" href="https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager">https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager</a>.</p>
<p>The protocol is being used for years, and it still serves us for good. However, it is extremely inflexible. For example, there is no way to send more information about received bursts on TRXD interface, than the fixed-size header already has (TDMA frame number, timeslot number, RSSI, ToA256). On TRXC interface, which is working over UDP as the other ones, there is no way to distinguish command retransmission, which may happen due to timeout, from a regular command. There is no way to notify the L1 (i.e. <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki">OsmoBTS</a>) about some events (e.g. device has been disconnected), no way to indicate transceiver version, and so on...</p>
<p>During <a class="wiki-page" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019">OsmoDevCon2019</a> (and before too) we have been discussing the idea of introducing the new version of TRX protocol, which would allow us to solve the mentioned problems. In order to keep backwards compatibility, both L1 and transceiver would initially use the old TRX protocol, while the new version can be optionally enabled by sending a command on TRXC interface. If the transceiver does support the new protocol, it would acknowledge the command. Otherwise, the command is rejected, so L1 would continue to work in "backwards compatibility" mode.</p>
<p>Finally, we need to write a proper protocol description like we already have for GSUP in <a class="external" href="https://git.osmocom.org/osmo-gsm-manuals/">https://git.osmocom.org/osmo-gsm-manuals/</a>. But before starting to work on this, let's create some kind of a wish list - what would you like to see in the new version of TRX protocol?</p>