Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-02T15:54:57ZOpen Source Mobile Communications
Redmine Core testing infrastructure - Bug #6386 (In Progress): eclipse-titan 9.0.0 not building in debian...https://projects.osmocom.org/issues/63862024-03-02T15:54:57Zlaforge
<p>I just ran into bugs caused by running a too old version of eclipse-titan (8.2.0 provided by debian), since our 9.0.0 is not building on unstable: <a class="external" href="https://obs.osmocom.org/package/show/osmocom:latest/eclipse-titan">https://obs.osmocom.org/package/show/osmocom:latest/eclipse-titan</a></p>
<p>Please have a look, thanks!</p> Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://projects.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> OsmoBSC - Bug #6324 (New): Making a data call results in B0RKEN lchanshttps://projects.osmocom.org/issues/63242024-01-05T20:31:49Zkeith
<p>I made a data call from a GSM modem and ended up with a CHAN NACK from osmo-bts (as is to be expected, I suppose)</p>
<p>Should we enhance osmo-bsc's NACK handling to do something a little more helpful than just B0RK the channel?</p> OsmoSGSN - Bug #6295 (New): TMSI realloc complete leads to SecurityModeRejecthttps://projects.osmocom.org/issues/62952023-12-07T15:15:38Zosmith
<p>With osmo-sgsn 1.11.1 and nano3g, I'm observing the following sccp traffic (pcap in SYS#6582):</p>
<ul>
<li>SecurityModeCommand</li>
<li>SecurityModeComplete</li>
<li>TMSI realloc complete</li>
<li>SecurityModeCommand</li>
<li>SecurityModeReject with error code conflict-with-already-existing-integrity-protection-and-or-ciphering-information (13)</li>
</ul>
<p>I guess we should tell the hnb to forget the ciphering information when doing a tmsi realloc? or there might be a way to not have SecurityModeCommand after TMSI realloc?</p>
<p>Creating the issue for future reference, currently looking into another problem.</p> libosmocore - Bug #6232 (New): jenkins should give all libosmocore config options a tryhttps://projects.osmocom.org/issues/62322023-10-22T16:16:56ZHoernchen
<p>Neither --enable-embedded nor the --disable-* flags currently work as expected, so all of those options should be built once per week to ensure that they still work.</p>
<p>(embedded currently still requires uring headers, socket/io implodes due to sctp defines, ...)</p>
<p>The tricky part is that testing the flags requires not installing (or masking) the libs/header packages, to ensure they are not silently used anyway, which is currently the case.</p> rtl-sdr - Bug #6225 (New): rtl-sdr reelase tarballs missing from https://ftp.osmocom.org/releases/https://projects.osmocom.org/issues/62252023-10-18T17:05:38ZlaforgeCellular Network Infrastructure - Bug #6188 (New): Osmocom manuals have "draft" in debian package...https://projects.osmocom.org/issues/61882023-09-21T16:37:08Zosmith
<p>The "draft" watermark on the first page is currently only getting removed when uploading the manuals here, for the released versions (not master):<br /><a class="external" href="https://ftp.osmocom.org/docs/">https://ftp.osmocom.org/docs/</a></p>
<p>However the debian packages still have the "draft" watermark in osmocom:latest.</p> OsmoGSMTester - Bug #6149 (New): osmo-gsm-tester gerrit verifications currently broken, not runni...https://projects.osmocom.org/issues/61492023-08-25T09:13:18Zosmith
<p>The gerrit verifications for osmo-gsm-tester.git are currently failing, because the job tries to build the osmo-gsm-tester manuals (outside of the usual/any docker container) and doesn't have rsvg-convert installed (<a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/34158">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/34158</a>).</p>
<pre>
Image 'dblatex' not found
rsvg-convert -a -f pdf -o fig0.pdf /home/jenkins/workspace/osmo-gsm-tester_gerrit/osmo-gsm-tester/_manuals_temp/osmo-gsm-tester-manual__1.svg
A possible reason for transformation failure is invalid DocBook
(as reported by xmllint)
Error: [Errno 2] No such file or directory
</pre>
<p>This job should run in docker, like pretty much all other gerrit verification jobs we have now. This will fix the problem that we don't have the dependencies available.</p> Cellular Network Infrastructure - Bug #6122 (New): remove big endian supporthttps://projects.osmocom.org/issues/61222023-07-31T09:46:32Zosmith
<p>Follow-up to <a class="external" href="https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/ORBO2FWVVPCHTAXSPZTQLSSM4YB76ITB/">https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/ORBO2FWVVPCHTAXSPZTQLSSM4YB76ITB/</a></p> Core testing infrastructure - Bug #5919 (New): osmo-python-tests: Update/fix README or setup processhttps://projects.osmocom.org/issues/59192023-02-22T18:25:53Zarehbein
<p><code>osmo-python-tests/README</code> states three ways of installation. Two of these failed for me:</p>
<pre>
$ pip3 install --verbose --user -e .
...
Installing collected packages: osmopython
Running setup.py develop for osmopython
Running command /usr/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/home/somedir/osmo-python-tests/setup.py'"'"'; __file__='"'"'/home/somedir/osmo-python-tests/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps --user --prefix=
running develop
running egg_info
error: [Errno 13] Permission denied
ERROR: Command errored out with exit status 1: /usr/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/home/somedir/osmo-python-tests/setup.py'"'"'; __file__='"'"'/home/somedir/osmo-python-tests/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps --user --prefix= Check the logs for full command output.
Exception information:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 223, in _main
status = self.run(options, args)
File "/usr/lib/python3/dist-packages/pip/_internal/cli/req_command.py", line 180, in wrapper
return func(self, options, args)
File "/usr/lib/python3/dist-packages/pip/_internal/commands/install.py", line 421, in run
installed = install_given_reqs(
File "/usr/lib/python3/dist-packages/pip/_internal/req/__init__.py", line 82, in install_given_reqs
requirement.install(
File "/usr/lib/python3/dist-packages/pip/_internal/req/req_install.py", line 800, in install
install_editable_legacy(
File "/usr/lib/python3/dist-packages/pip/_internal/operations/install/editable_legacy.py", line 49, in install_editable
call_subprocess(
File "/usr/lib/python3/dist-packages/pip/_internal/utils/subprocess.py", line 261, in call_subprocess
raise InstallationSubprocessError(proc.returncode, command_desc)
</pre>
<p>Seems like the command is throwing an error, because the prefix option is passed with an empty argument, but I don't know.</p>
<p>For checkinstall, the Debian package isn't built if one leaves the default value for version (<code>test</code>), since it hast to begin with a digit:</p>
<pre>
dpkg-deb: error: parsing file '/var/tmp/tmp.6EyaipPJOV/package/DEBIAN/control' near line 7 package 'osmo-python':
'Version' field value 'tests-1': version number does not start with digit
</pre>
<p>Outputs for each command are attached.</p> libosmo-sccp + libosmo-sigtran - Bug #5899 (New): ttcn3-sccp-test-latest is actually running code...https://projects.osmocom.org/issues/58992023-02-09T16:40:05Zosmith
<p>In jenkins.sh:</p>
<pre>
# Always require osmo-stp-master since is the only with sccp_demo_user installed
docker_images_require \
"osmo-stp-master" \
"ttcn3-sccp-test"
</pre>
<p>A way to resolve this would be packaging the demo programs sccp_demo_user (and _server?) in a -demos subpackage.</p>
<p>We only have one test in the testsuite, so this doesn't have much of an impact, just noting for future reference.</p> Cellular Network Infrastructure - Bug #5887 (New): coverity: build everything in docker container...https://projects.osmocom.org/issues/58872023-02-01T10:25:23Zosmith
<p>Currently the coverity scripts are not automatically tested before merging, and when they fail it is quite some effort to reproduce the errors as one has to manually install all dependencies (and missing ones only show up half-way through the build when something fails). Also libusrp requires sdcc 3, while e.g. on this system I have sdcc 4 installed.</p> Cellular Network Infrastructure - Bug #5809 (Feedback): applications disrespect potentially VTY-c...https://projects.osmocom.org/issues/58092022-12-05T18:25:49Zlaforge
<p>Originally we had the <code>telnet_init()</code> function, which later on was replaced by <code>telnet_init_dynif()</code> - both requiring the application to know the TCP port (and possibly local address)</p>
<p>Later we added VTY commands for this, and there is <code>telnet_init_default()</code> which uses <code>vty_get_bind{port,addr}()</code> to make sur the VTY-configured IP/port are used.</p>
<p>The problem is that most if not all applications still use <code>telnet_init_dynif()</code> to which they pass the "normal" port like <code>OSMO_VTY_PORT_HNODEB</code>.</p>
<p>This means the user may configure a different port in the VTY, but that port won't actually be used.</p>
<p>All the osmo-* projects need to be converted to <code>telnet_init_default()</code>.</p>
<p>We should also [marc ase] deprecate the old <code>telnet_init()</code> and <code>telnet_init_dynif()</code> functions for exactly that reason.</p> OsmoMSC - Bug #5568 (Stalled): SMPP socket doesn't use TCP_NODELAYhttps://projects.osmocom.org/issues/55682022-05-17T18:33:30Zlaforge
<p>The SMPP socket uses sockets directly (without relying on libosmo-netif/stream) and fails to setsockopt(TCP_NODELAY). This is not critical (SMS is sloooow), but it does add unintended latency to all SMPP messages sent.</p>
<p>The quick fix is to add the setsockopt for every socket we accept(). The clean-up would be to use libosmo-netif/stream...</p> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://projects.osmocom.org/issues/45992020-06-08T18:05:33Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:</p>
<pre>
<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.
</pre>
<p>I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.</p>
<p>The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.</p>
<p><a class="user active" href="https://projects.osmocom.org/users/1741">lynxis</a> any ideas?</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://projects.osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> Cellular Network Infrastructure - Bug #4131 (Stalled): osmo-gsm-manuals: Use leveloffset attribut...https://projects.osmocom.org/issues/41312019-07-26T13:04:49Zpespin
<p>Right now, all documents under osmo-gsm-manuals.git/commons/ start with title level 1 (==). However, if one wishes to add a document with level 2 (===) so it can also be included in other repository document, it will make osmo-gsm-manuals.git "make check" fail due to osmo-gsm-manuals/tests/Makefile.am:22:<br /><pre>
echo "include::$${chapter}[]" >> $@; \
</pre></p>
<p>Which includes stuff under a test document with level 0 (=). If a document with level different than 1 (==) is added, then it will fail on some versions (like jenkins):<br /><pre>
"asciidoc: WARNING: mgcp_extension_osmux.adoc: line 2: section title out of sequence: expected level 1, got level 2"
</pre></p>
<p>See for instance commit osmo-gsm-manuals.git 061cca4d7345bc4f496324d0b4d30bc51e1f8d23, which had to be fixed up later.</p>
<p>The solution here is to use "leveloffset" attribute. To make our life easier in the future, we need to move all documents under common/ to start with level 0 (=), and then use "leveloffset" on all includes in all other repositories using them. This way same document can easily be added on different levels on different documents.</p>
<p>Important! It seems this syntax doesn't work for me:<br /><pre>
include::chapter2.adoc[leveloffset=+1]
</pre></p>
<p>However, this does and it's basically the same:<br /><pre>
:leveloffset: 1
include::chapter1.adoc[]
:leveloffset: 0
</pre></p>
<p>Related information:<br /><a class="external" href="https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc">https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc</a><br /><a class="external" href="https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html">https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html</a><br /><a class="external" href="http://asciidoc.org/userguide.txt">http://asciidoc.org/userguide.txt</a></p> Cellular Network Infrastructure - Bug #4069 (New): Implement IPA PING/PONG mechanism everywherehttps://projects.osmocom.org/issues/40692019-06-21T14:44:02Zlaforge
<p>As was seen in <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Prolonged remaining in state with RSL link gone, OML link open (Closed)" href="https://projects.osmocom.org/issues/4061">#4061</a>, we're not doing a good job in closing connections if they're dead. Let's improve this situation by implementing an IPA PING sender / PONG receiver which closes+reconnects (client) or simply closes (server) the respective connection.</p>
<p>I recently added ipa_keepalive_fsm_start to libosmo-abis. It's used only in osmo-remsim,<br />but should probably be used by virtually any of our programs that implement IPA<br />multiplex, starting from BTS (Abis), BSC (Abis), MSC (SCCPlite, GSUP), HLR (GSUP),<br />all our CTRL interfaces, ... - but anything beyond RSL+OML in BTS+BSC is out of scope for this<br />ticket. I'll add separate tickets about this.</p>
<p>Whether or not that specific FSM is used: The IPA PING/PONG logic should exist everywhere.</p> Cellular Network Infrastructure - Bug #3382 (New): Investigate and fix lintian issues listed by D...https://projects.osmocom.org/issues/33822018-07-05T11:37:34Zpespin
<p>This web page lists a list of warnings which we may want to fix: <a class="external" href="https://lintian.debian.org/maintainer/Debian-mobcom-maintainers@lists.alioth.debian.org.html">https://lintian.debian.org/maintainer/Debian-mobcom-maintainers@lists.alioth.debian.org.html</a></p> Cellular Network Infrastructure - Bug #3167 (New): Build osmo-*-master docker containers with add...https://projects.osmocom.org/issues/31672018-04-14T12:47:52Zlaforge
<p>In order to catch use-after-free and similar bugs during TTCN-3 test execution, it would be great if we'd modify the <code>docker-playground/osmo-*-master</code> containers to build with asan enabled. We'd of course have to capture the stderr output of the related processes somehow into jenkins (e.g. as artefacts) to reap the benefits from this.</p> OsmoMSC - Bug #3163 (New): RANAP: reject Level 3 Complete from cells with invalid LAIhttps://projects.osmocom.org/issues/31632018-04-12T15:00:38Zneelsnhofmeyr@sysmocom.de
<p>Level 3 Complete messages contain a cell identity of the calling BSC/RNC.</p>
<ul>
<li>Verify that we do not allow RNCs with invalid PLMN (and LAC) to send Level 3 Complete requests.</li>
<li>Write a ttcn3 test that sends a LU from an RNC (Iu-interface, RANAP) that has a LAI mismatching the MSC's global PLMN.</li>
</ul>
<p>(This issue is created as a split of <a class="issue tracker-1 status-6 priority-2 priority-default closed" title="Bug: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual value (Rejected)" href="https://projects.osmocom.org/issues/2980">#2980</a>, to clarify the confusion we created there.)</p> OsmoSGSN - Bug #2959 (New): OsmoSGSN puts bogus LAC/RAC in GTP Create PDP CTX ACT REQhttps://projects.osmocom.org/issues/29592018-02-17T19:45:22Zlaforge
<p>The RAC/LAC values of the GTP Create PDP Context Request are not those of the Subscriber / MM Context. I protocol traces, I've repeatedly seen 0xFFFE as LAC and 0xFF as RAC.</p> OsmoSGSN - Bug #2958 (Stalled): OsmoSGSN doesn't authenticate on second/further ATTACH REQUESThttps://projects.osmocom.org/issues/29582018-02-17T17:29:12Zlaforge
<p>When a new/unknown MS performs an ATTACH REQUEST for the first time, it is authenticated.</p>
<p>However, if that same MS later performs a second ATTACH REQUEST, even with new P-TMSI/TLLI, it is not authenticated and we simply send an ATTACH ACCEPT. This is a security problem, as it means anyone can impersonate other known-existing IMSIs.</p> OsmoMSC - Bug #2933 (New): change of trans->bearer_cap (e.g. via MNCC) will not trigger BSSMAP AS...https://projects.osmocom.org/issues/29332018-02-12T11:36:39Zlaforge
<p>Whenever the trans->bearer_cap change (e.g.due to a CC MODIFY or MNCC MODIFY), the MSC must chck if the new bearer capabilities are different from the old bearer capabilities, and subsequently trigger a BSSMAP ASSIGNMENT towards the BSS.</p>
<p>Currently, the handling of bearer_cap will in only work if the related CC/MNCC message with <br />besrer_cap IE happens before the pint in time at which the MSC performs the BSSMAP ASSIGNMENT<br />procedure. Our logic still needs to change in a way that the CC/MNCC <br />code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and<br />in that case triggers a new follow-up BSSMAP ASSIGNMENT.</p> OsmoMSC - Bug #2928 (New): OsmoMSC doesn't do BSSMAP ASSIGNMENT if no MNCC_RTP_CREATE is receivedhttps://projects.osmocom.org/issues/29282018-02-11T10:35:23Zlaforge
When operating OsmoMSC with external MNCC handler, it seems that it "forgets" to
<ul>
<li>perform BSSMAP ASSIGNMENT procedure</li>
<li>perform CRCX/MDCX on MGW endpoint for RAN side<br />if the eternal MNCC handler is not sending the MNCC_RTP_CREATE.</li>
</ul>
<p>This is wrong and indicates the state machines have some trouble.</p>
<p>The voice call should be established towards MS/RAN/MGW as usual, no matter if and when an external MNCC handler decides to actually connect to the MSC-located MGW. The MNCC_RTP_{CREATE,MODIFY} should only be translated to CRCX/MDCX of the mncc-side connection to OsmoMGW, and not anything on the RAN side.</p> OsmoBSC - Bug #2899 (New): channel attributes are sent to BTS even for NONE channelshttps://projects.osmocom.org/issues/28992018-01-30T16:19:34Zstsp
<p>While trying to set up a network with very few channels, I disabled most channels for bts 0 in the OsmoBSC configuration file by setting them to NONE.</p>
<p>In this configuration, an osmo-bts-virtual BTS refuses channel attributes sent by OsmoBSC, resulting in a failure of the connection between BTS and BSC.</p>
<p>A pcap file showing the protocol exchange is attached (filter for gsm_abis_oml).</p>
<p>The BSC side log says this:<br /><pre>
<0024> input/ipa.c:263 accept()ed new link from 127.0.0.1 to port 3002
<0024> bts_ipaccess_nanobts.c:420 Identified BTS 6969/0/0
<0005> abis_nm.c:1644 Get Attr (bts=0)
<0005> abis_nm.c:1644 Get Attr (bts=0)
<0005> abis_nm.c:382 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:1981 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART
<0005> abis_nm.c:382 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:1662 Set BTS Attr (bts=0)
<0005> abis_nm.c:1981 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART
<0005> abis_nm.c:382 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:382 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:382 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:382 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03)
<0005> abis_nm.c:382 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:552 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0
<0005> abis_nm.c:464 BTS0 Get Attributes Response Info: 65 bytes total with 0 unreported attributes
<0005> abis_nm.c:508 BTS0 feature 'GPRS' reported via OML does not match statically set feature: 0 != 1. Please fix.
<0005> abis_nm.c:508 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix.
<0005> abis_nm.c:575 BTS0: ARI reported sw[0/2]: sysmobts is 0.7.0.54-e5b6
<0005> abis_nm.c:447 BTS0 reported variant: unknown
<0005> abis_nm.c:552 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0
<0005> abis_nm.c:464 BTS0 Get Attributes Response Info: 32 bytes total with 1 unreported attributes
<0005> abis_nm.c:469 BTS0 Attribute Manufacturer Dependent State is unreported
<0005> abis_nm.c:575 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown
<0005> abis_nm.c:814 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Opstart ACK
<0005> abis_nm.c:382 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff)
<0005> abis_nm.c:1981 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:382 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff)
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=0)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=1)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=2)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=3)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=4)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=5)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=6)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05)
<0005> abis_nm.c:1874 Set Chan Attr (bts=0,trx=0,ts=7)
<0005> abis_nm.c:1981 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART
<0005> abis_nm.c:382 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:1679 Set TRX Attr (bts=0,trx=0)
<0005> abis_nm.c:1981 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:382 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report
<0005> abis_nm.c:1981 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART
<0005> abis_nm.c:2800 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00
<0005> abis_nm.c:382 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:814 OC=BTS(01) INST=(00,ff,ff) Opstart ACK
<0005> abis_nm.c:382 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:814 OC=RADIO-CARRIER(02) INST=(00,00,ff) Opstart ACK
<0005> abis_nm.c:818 OC=CHANNEL(03) INST=(00,00,00) Set Channel Attributes ACK
<0005> abis_nm.c:382 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff)
<0005> abis_nm.c:814 OC=CHANNEL(03) INST=(00,00,00) Opstart ACK
<0005> abis_nm.c:768 OC=CHANNEL(03) INST=(00,00,01) SET CHANNEL ATTRIBUTE NACK CAUSE=Parameter value outside permitted range
<0005> bsc_init.c:62 Got SET CHANNEL ATTRIBUTE NACK going to drop the OML links.
</pre></p> OsmoMSC - Bug #2669 (New): osm-msc doesn't clean up BSC statehttps://projects.osmocom.org/issues/26692017-11-20T19:13:59Zlaforge
<p>If a BSC has ever sent a BSSMAP RESET to OsmoMSC we acknowledge this with a RESET-ACK. But then it appears we keep its state indefinitely and want to perform a MSC-originated RESET procedure in return. If the BSC never gets back, this process appears to continue indefinitely.</p>
<p>This is bad, as it means that anyone ever sending/spoofing a single "BSSMAP RESET" to OsmoMSC will be able to turn it into an "amplification attack" with OsmoMSC sending BSSMAP RESET in return.</p>
<p>In order to avoid this, we should probably do both of:</p>
<ul>
<li>stop re-transmitting the BSSMAP RESET after some point and simply forget about the BSCs</li>
<li>introduce a "locked down" mode in which we don't accept BSSMAP from any random source out there, but only explicitly configured BSCs (in the VTY)</li>
</ul> libosmo-abis - Bug #2571 (New): libosmo-abis API documentation missing (doxygen)https://projects.osmocom.org/issues/25712017-10-11T08:07:35ZlaforgeOsmoPCU - Bug #2404 (Feedback): PAGING-PS doesn't use QoS parameters from BSSGPhttps://projects.osmocom.org/issues/24042017-07-29T08:59:48Zlaforge
<p>The BSSGP PAGING PS message contains mandatory QoS parameters. However, we don't actually encode those when generating the PCH paging message in Encoding::write_paging_request()</p> Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://projects.osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p>