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> 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> 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> OsmoGGSN (former OpenGGSN) - Feature #6096 (In Progress): add support for kernel-GTP IPv6https://projects.osmocom.org/issues/60962023-07-12T20:37:17Zlaforge
<p><a class="user active" href="https://projects.osmocom.org/users/21027">pablo</a> has implemented [inner] IPv6 support in the kernel GTP driver and libgtpnl, see <a class="issue tracker-1 status-2 priority-3 priority-high3" title="Bug: IPv6 support for inner (user) IP layer missing (In Progress)" href="https://projects.osmocom.org/issues/1952">#1952</a></p>
<p>In order to end-to-end test it in our TTCN3 test suite (which already tests ipv6 when used with userspace GTP), we would need to add supprot for it to osmo-ggsn</p>
<p>I think <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> is currently too busy to look at this, hence assigned to <a class="user active" href="https://projects.osmocom.org/users/301771">osmith</a>, but that's not mandatory. Feel free to pass around as needed.</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> Cellular Network Infrastructure - Bug #5685 (Feedback): Dropping debian 10 (buster)https://projects.osmocom.org/issues/56852022-09-19T13:09:00Zosmith
<p>Debian 10 was EOL in 2022-08. It still has LTS support (<a class="external" href="https://wiki.debian.org/DebianReleases">https://wiki.debian.org/DebianReleases</a>).</p>
<a class="user active" href="https://projects.osmocom.org/users/7">laforge</a>:
<ul>
<li>Do we want to remove it form OBS now? (after migrating all docker containers to debian 11)</li>
<li>In general, when do we want to stop supporting old Debian releases?</li>
</ul>
<p>Currently it is still in use by various docker containers:<br /><pre>
$ git grep debian-buster
debian-buster-build/Makefile:DISTRO=debian-buster
debian-buster-jenkins/Makefile:DISTRO=debian-buster
debian-buster-simtrace2/Dockerfile:FROM $USER/debian-buster-build
fpga-build/Dockerfile:FROM $USER/debian-buster-build
jenkins-common.sh: debian-buster-*) echo "debian-buster" ;;
jenkins-common.sh: debian-buster-*) echo "debian:buster" ;;
nplab-m3ua-test/jenkins.sh: "debian-buster-build" \
nplab-sua-test/jenkins.sh: "debian-buster-build" \
osmo-gsm-tester/Dockerfile:FROM $USER/debian-buster-jenkins
osmo-gsm-tester/jenkins.sh: "debian-buster-jenkins" \
sigtran-tests/Dockerfile:FROM $USER/debian-buster-build
</pre></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> OsmoMGW - Bug #4447 (New): DSCP value should be a 6 bit fieldhttps://projects.osmocom.org/issues/44472020-03-09T09:11:24Zosmith
<p>TOS was 8bits, but only the upper 6 bits became DSCP. The VTY command for DSCP in OsmoMGW accepts an 8 bit value. We are setting the setsockopt for TOS with that value without bit-shifting.</p>
<p>This came up while writing a <a href="https://gerrit.osmocom.org/c/osmo-bts/+/17401" class="external">similar patch</a> for setting DSCP for OsmoBTS.</p>
<p>Should we</p>
<p>a) shift it two bits up and adjust the command syntax (and config template) to restrict to 0..63 (backwards incompatible)</p>
<p>or</p>
<p>b) change the description of the VTY command, so it is obvious that we are actually setting the TOS? (probably confusing)</p>
<p>CC: <a class="user active" href="https://projects.osmocom.org/users/7">laforge</a></p> OsmoMSC - Bug #4167 (Feedback): Event VLR_ULA_E_ID_IMEISV not permittedhttps://projects.osmocom.org/issues/41672019-08-22T13:11:47Zfixeria
<p>We're running Osmocom based network at the CCCamp 2019. I noticed the following errors happening quite often:</p>
<pre>
Thu Aug 22 14:03:29 2019 DVLR ERROR libvlr/vlr.c:1180 vlr_lu_fsm(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0x7F53E4C2:GERAN-A-70445:LU)[0x5563947582c0]{VLR_ULA_S_WAIT_HLR_UPD}: Event VLR_ULA_E_ID_IMEISV not permitted
Thu Aug 22 14:20:59 2019 DVLR ERROR libvlr/vlr.c:1180 vlr_lu_fsm(IMSI-262423403003705:MSISDN-7968:TMSI-0x0FB923BC:GERAN-A-71816:LU)[0x55639482b3a0]{VLR_ULA_S_WAIT_HLR_UPD}: Event VLR_ULA_E_ID_IMEISV not permitted
Thu Aug 22 14:21:51 2019 DVLR ERROR libvlr/vlr.c:1180 vlr_lu_fsm(IMSI-262423103001767:MSISDN-2404:TMSI-0x916773EF:GERAN-A-71882:LU)[0x5563947752d0]{VLR_ULA_S_WAIT_HLR_UPD}: Event VLR_ULA_E_ID_IMEISV not permitted
</pre>
<p><a class="user active" href="https://projects.osmocom.org/users/301771">osmith</a> any ideas?</p> Cellular Network Infrastructure - Feature #4109 (New): debian-repo-install-test: start a virtual ...https://projects.osmocom.org/issues/41092019-07-16T12:36:01Zosmith
<p>We could extend <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: no automatic testing of Debian/Ubuntu packages (Resolved)" href="https://projects.osmocom.org/issues/3369">#3369</a> (which made debian-repo-install-test start up all systemd services of Osmocom programs) to also start a virtual mobile subscriber (phone) and do a location update.</p> OsmoBSC - Bug #4070 (Stalled): Implement IPA PING/PONG mechanism on RSL and OMLhttps://projects.osmocom.org/issues/40702019-06-21T14:46:51Zlaforge
<p>Let's make sure the RSL and OML links use the IPA PING/PONG mechanism to the BTSs and disconnect if no PONG is received. the interval and timeout should ideally be user(vty)-configurable. It might be that the actual code has to reside in libosmo-abis, not in OsmoBSC itself. Keep in mind that classic E1 BTSs don't have IPA or TCP.</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> OsmoMSC - Feature #3636 (New): detailed call statistics (with rate counters)https://projects.osmocom.org/issues/36362018-10-08T11:14:43Zosmith
<p>Follow up to <a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: osmo-sip-connector: Add stats for call handling (Resolved)" href="https://projects.osmocom.org/issues/1679">#1679</a>: rate counter statistics in OsmoMSC would be useful for:</p>
<blockquote>
How many calls were;
<ul>
<li>busy</li>
<li>rang out (unanswered)</li>
<li>unreachable,<br />etc, etc...</li>
</ul>
</blockquote>
<p>There are already call rate counters present, but they don't specify an exact reason why a call was terminated.</p>
<pre>
call:mo_setup: 0 (0/s 0/m 0/h 0/d) Received setup requests from a MS to init a MO call.
call:mo_connect_ack: 0 (0/s 0/m 0/h 0/d) Received a connect ack from MS of a MO call. Call is now succesful connected up.
call:mt_setup: 0 (0/s 0/m 0/h 0/d) Sent setup requests to the MS (MT).
call:mt_connect: 0 (0/s 0/m 0/h 0/d) Sent a connect to the MS (MT).
call:active: 0 (0/s 0/m 0/h 0/d) Count total amount of calls that ever reached active state.
call:complete: 0 (0/s 0/m 0/h 0/d) Count total amount of calls which got terminated by disconnect req or ind after reaching active state.
call:incomplete: 0 (0/s 0/m 0/h 0/d) Count total amount of call which got terminated by any other reason after reaching active state.
</pre> Cellular Network Infrastructure - Feature #3477 (New): add a wiki page explaining interconnection...https://projects.osmocom.org/issues/34772018-08-20T09:21:37Zneelsnhofmeyr@sysmocom.de
<p>The <a class="wiki-page" href="https://projects.osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box">Osmocom Network In The Box</a> wiki page explains running components on the same machine.<br />As soon as this is split up between several boxes, numerous config items become necessary to set bind-addresses and remote addresses.<br />Each user manual should explain this, but it would also be nice to have a common wiki page guiding through this process.</p> Cellular Network Infrastructure - Feature #3386 (New): Generate man pages at build time from adoc...https://projects.osmocom.org/issues/33862018-07-06T10:24:03Zpespin
<p>Once we have documentation being build in each project repository separately (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Move project specific manuals from osmo-gsm-manuals to each respective git repository (Resolved)" href="https://projects.osmocom.org/issues/3385">#3385</a>), we want to generate man pages for each repository.</p>
<p>The idea here is to have an .adoc file with all the required content to be used in the man pag, and which is already included in the user manual. Then we need to scripts/makefile to transform this .adoc file into man source format and make it be build and installed when --enable-man is passed. Then, install it in the debian packages (which means we in turn need to modify dh_configure or similar to pass the --enable-man flag, and somehow include the common osmo-gsm-manuals.git in there when sending to OBS).</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 - Feature #3229 (New): build-system: jenkins.sh: Improve debian ...https://projects.osmocom.org/issues/32292018-05-03T12:40:28Zpespin
<p>The idea is to add extra tests/checks to avoid breaking debian package building during nightly builds in OBS. Instead, let's catch it during gerrit patch submission time and don't allow merging it until it's fixed.</p>
<p>We should investigate several tools, like pbuilder, dpkg-build, etc. I recall lynxis also told me something about some kind of lint tool available for this purposes.</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 #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> 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 #2846 (New): MSC doesn't close SCCP/BSSAP connection on CM SERV REQ tht cannot be p...https://projects.osmocom.org/issues/28462018-01-20T20:40:36Zlaforge
<p>If sending a CM SERV REQ that's invalid, I get</p>
<pre>
<000a> a_iface_bssap.c:699 Rx BSC DT: 00 15 57 05 01 03 17 0f 05 24 01 01 50 09 21 26 24 10 32 54 76 98 0f
<000a> a_iface_bssap.c:629 Rx MSC DT1 BSSMAP COMPLETE LAYER 3
<000a> a_iface_bssap.c:291 BSC has completed layer 3 connection (conn_id=1)
<000a> a_iface_bssap.c:311 Unable to parse element CELL IDENTIFIER (wrong field length) -- discarding message!
</pre>
<p>but the MSC doesn't close the SCCP connection. It also doesn't send AUTH REQ or any other L3 message, basically keeping the radio channel open for no reason at all.</p> libosmo-abis - Bug #2571 (New): libosmo-abis API documentation missing (doxygen)https://projects.osmocom.org/issues/25712017-10-11T08:07:35ZlaforgeOsmoHLR - Feature #2542 (Stalled): have subscriber create-on-demandhttps://projects.osmocom.org/issues/25422017-10-06T02:52:42Zneelsnhofmeyr@sysmocom.de
<p>Especially communal networks that allow 3rd party SIM cards to camp on the network would<br />greatly benefit from a subscriber create-on-demand feature in the osmo-hlr. A new subscriber<br />could be rejected from the network at first, but has then left its IMSI and IMEI in the db.</p>
<p>This implies the ability to disable subscribers even though they are present in the HLR,<br />otherwise anyone showing up would be authorized immediately, which is usually not desirable.</p>
<p>Clarify whether nam_ps/nam_cs or purge_ps/purge_cs are suitable for this purpose,<br />otherwise we'd need another flag per subscriber saying 'authorized', which could be false<br />by default for subscriber create-on-demand.</p> Cellular Network Infrastructure - Feature #2451 (New): Add static builds to jenkins jobshttps://projects.osmocom.org/issues/24512017-08-18T10:51:23Zmsuraev
<p>Right now most (all?) Osmocom projects support static builds which is sometimes useful for testing and deployment in particular environments.</p>
<p>However, in the absence of per-commit tests it can be easily broken as an unintended side-effect of some patches.</p>
<p>We should add "--enable-static" test builds to the corresponding jenkins jobs to avoid breaking it.</p> OsmoBTS - Feature #2356 (New): have per-SAPI logging in OsmoBTS DL1P / DL1Chttps://projects.osmocom.org/issues/23562017-07-10T18:31:22Zlaforge
<p>the L1 logging is inherently verbose, particularly for L1P.</p>
<p>It would be nice if one could enable logging only for specific L1 SAPIs, such as SACCH, TCH, FACCH, or the like.</p>
<p>Having different log subsystems is overkill, but maybe the 'log filter' framework can be used for this?</p> OsmoBSC - Feature #1946 (New): Add checks to the BSC VTY to prevent configurations known to not workhttps://projects.osmocom.org/issues/19462017-02-08T23:41:53Zneelsnhofmeyr@sysmocom.de
<p>e.g. running TCH/F_TCH/H_PDCH timeslots on a nanobts doesn't work,<br />similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR),<br />and so on.</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> OsmoBSC - Feature #1605 (In Progress): logging / ring buffer for ALERT messages from A-bis OML fr...https://projects.osmocom.org/issues/16052016-02-23T15:59:17Zlaforge
<p>OML ALERT messages are currently not really used much. They should be used more from the BTS side, and the BSC component in the NITB should not only log them somewhere but possibly even keep an in-memory ring buffer for each BTS/TRX so one can inspect the most recent errors for those objects via the VTY.</p> OsmoPCU - Feature #1558 (New): Generate BSSGP LLC Discarded messages on TBF/MS freehttps://projects.osmocom.org/issues/15582016-02-23T15:15:01Zlaforge
<p>If a TBF is freed (e.g. caused by timeout or replacement), the dropped (unsent/unacknowledged) RLC frames are silently dropped. If an MS object is freed (TBF creation failed during the timeout interval), the dropped LLC frames are also not reported. At least counters should be implemented for these cases.</p>
<p>It's a violation of the spec. OsmoSGSN doesn't care, but if you interface with other SGSNs, they might expect to receive such messages in order to optimize their flow control and/or QoS.</p>