Open Source Mobile Communications: Issueshttps://osmocom.org/https://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://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://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://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://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://osmocom.org/issues/62252023-10-18T17:05:38ZlaforgeOsmoGGSN (former OpenGGSN) - Feature #6223 (In Progress): TTCN3 unit test[s] for GTPv1U with exte...https://osmocom.org/issues/62232023-10-18T15:03:43Zlaforge
<p>Let's generate GTPv1U trffic with one or even multiple extension headers and see if osmo-ggsn (in both kernel and userspace case) pass the user data as normally expected.</p> Cellular Network Infrastructure - Bug #6188 (New): Osmocom manuals have "draft" in debian package...https://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://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> OsmoGGSN (former OpenGGSN) - Feature #6096 (In Progress): add support for kernel-GTP IPv6https://osmocom.org/issues/60962023-07-12T20:37:17Zlaforge
<p><a class="user active" href="https://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://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://osmocom.org/users/30187">pespin</a> is currently too busy to look at this, hence assigned to <a class="user active" href="https://osmocom.org/users/301771">osmith</a>, but that's not mandatory. Feel free to pass around as needed.</p> Cellular Network Infrastructure - Bug #5809 (Feedback): applications disrespect potentially VTY-c...https://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 - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> Cellular Network Infrastructure - Bug #5685 (Feedback): Dropping debian 10 (buster)https://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://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> OsmoBSCNAT - Bug #5492 (New): Support MSC poolinghttps://osmocom.org/issues/54922022-03-21T10:41:34Zosmith
<p>Harald wrote in <a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc-nat/+/27473">https://gerrit.osmocom.org/c/osmo-bsc-nat/+/27473</a>:</p>
<blockquote>
<p>Please note that we cannot assume just one MSC, but have to consider the situation of MSC pooling, too. Most if not all real netwokrs use MSC pooling, and we support it in the BSC as well just as we support SGSN pooling in the PCU and gbproxy.</p>
</blockquote>
<blockquote>
<p>any vty configuration regarding pooling should look as much as possible identical to how it is done in other places (gbproxy, for example)</p>
</blockquote>
<p>Related: <a class="external" href="https://osmocom.org/projects/osmo-bscnat/wiki/AoIP_OsmoBSCNAT#MSC-pooling">https://osmocom.org/projects/osmo-bscnat/wiki/AoIP_OsmoBSCNAT#MSC-pooling</a></p> Core testing infrastructure - Bug #5301 (Stalled): Run TTCN3 docker tests with sanitizer enabledhttps://osmocom.org/issues/53012021-11-10T10:49:12Zdaniel
<p>After updating libosmocore I noticed that the TTCN3 GbProxy tests start to fail with an ASan issue when run locally.</p>
<p>I think at least for the TTCN3 tests on master we should enable <code>*San</code> to catch hidden bugs early. Unfortunately this has a large impact on how the <code>osmo-*-master</code> docker images are built if we want to enable it for the libraries as well - currently we install the nightly packages and build the target from master.</p>
<p>Instead we could build an image that builds all the libraries from master (with sanitizer enabled) and installs those and then use that as base for osmo-*-master.</p>
<p>Not sure what the downsides are, any ideas?</p> OsmoMGW - Feature #5279 (New): systemd service / unit for multiple osmo-mgw on one machinehttps://osmocom.org/issues/52792021-10-25T11:41:42Zlaforge
<p>Now that some deployments run multiple instances of osmo-mgw in parallel on one machine (to scale out over multiple processors), the question is how to properly handle this from a systemd unit/service point of view.</p>
<p><a class="user active" href="https://osmocom.org/users/732038">iedemam</a> might have some ideas and has already done some work in that direction.</p> OsmocomBB - Bug #4834 (New): package cp210x-program as part of network:osmocom:{nightly,latest}https://osmocom.org/issues/48342020-10-26T18:01:48Zlaforge
<p>The cp210x-program utility is used to program the CP210x cables with custom baud rates.</p>
<a class="wiki-page" href="https://osmocom.org/projects/baseband/wiki/HardwareCP210xTutorial">HardwareCP210xTutorial</a> is slightly outdated and still points to a sourceforge version of the tool, which
<ul>
<li>is python2 only</li>
<li>tries to do ELF parsing of libusb.so, which at least on my Debian unstable x86_64 doesn't seem to work anymore</li>
</ul>
<p>Let's instead use the maintained fork at <a class="external" href="https://github.com/VCTLabs/cp210x-program">https://github.com/VCTLabs/cp210x-program</a> and package it in our feeds.</p>
<p>Assigning to <a class="user active" href="https://osmocom.org/users/301771">osmith</a>, knowing that he only starts to work on Osmocom topics again from January 1st, 2021 onwards. If somebody else wants to pick this up, feel free to do so.</p>
<p>The wiki page should then subsequently be updated, too.</p> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://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://osmocom.org/users/1741">lynxis</a> any ideas?</p> OsmoMGW - Bug #4447 (New): DSCP value should be a 6 bit fieldhttps://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://osmocom.org/users/7">laforge</a></p> OsmoMSC - Bug #4167 (Feedback): Event VLR_ULA_E_ID_IMEISV not permittedhttps://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://osmocom.org/users/301771">osmith</a> any ideas?</p> OsmoHLR - Bug #4163 (New): Subscriber on demand: "Error while deleting subscriber data for IMSI" ...https://osmocom.org/issues/41632019-08-21T07:54:44Zosmith
<p>Reported by Rafael:<br /><a class="external" href="https://lists.osmocom.org/pipermail/openbsc/2019-August/012997.html">https://lists.osmocom.org/pipermail/openbsc/2019-August/012997.html</a></p>
<blockquote>
<p>And after giving "cs+ps" permission, when trying to set to "none" again,<br />I get:</p>
</blockquote>
<pre>
<0000> hlr.c:651 Error while deleting subscriber data for IMSI724056816211859
<0007> input/ipa.c:370 127.0.0.1:60216 sending data
<0007> input/ipa.c:390 connected read/write
<0007> input/ipa.c:346 127.0.0.1:60210 message received
<0000> hlr.c:651 Error while deleting subscriber data for IMSI724056816211859
<0007> input/ipa.c:390 connected read/write
<0007> input/ipa.c:346 127.0.0.1:60216 message received
<0000> hlr.c:651 Error while deleting subscriber data for IMSI724056816211859
<0007> input/ipa.c:390 connected read/write
<0007> input/ipa.c:346 127.0.0.1:60210 message received
<0000> hlr.c:651 Error while deleting subscriber data for IMSI724056816211859
</pre> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://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 - Feature #4107 (Stalled): Start systemd services as non-root userhttps://osmocom.org/issues/41072019-07-15T06:56:35Zosmith
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> wrote in <a href="https://osmocom.org/issues/3369#note-12" class="external">OS#3369</a>:</p>
<blockquote>
<p>Ideally, as far as possible, we should start them as non-root user<br />(which may require changes to our systemd service files, etc. in the<br />individual git repos - but that is fine!). Starting them as non-root<br />will also means that any writes to unintended directories like '/'will<br />be discovered as they then would make the program start fail.</p>
</blockquote> OsmoBSC - Bug #4070 (Stalled): Implement IPA PING/PONG mechanism on RSL and OMLhttps://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> OsmoBTS - Bug #3792 (New): OsmoBTS doesn't include the "Starting Time" attribute in "Set BTS Attr...https://osmocom.org/issues/37922019-02-07T20:13:33Zlaforge
<p>This is used by the BTS to inform the BSC about the GSM frame number at the time of starting the BTS. It's not clearly required by the spec, but nanoBTSs send it.</p> libosmo-ranap - Bug #3420 (Stalled): ranap_transp_assoc_decode() decodes X.213 NSAP address heade...https://osmocom.org/issues/34202018-07-26T13:51:46Zneelsnhofmeyr@sysmocom.de
<p>The SysmoCell5000 series sends RAB-AssignmentResponse with X.213 NSAP addresses, which get parsed by ranap_transp_assoc_decode().<br />These contain a three byte header followed by the IP address, typically it is 0x350001 followed by the Ipv4 address in hex.</p>
<p>ranap_transp_assoc_decode() however starts at the header and decodes as 53.0.1.N where N is the first octet of the actual IPv4 address, e.g. 192.<br />Hence switching RTP streams to the cell fails, since obviously 53.0.1.192 is not the correct IP address.</p>
<p>a) fix the check for the address length, should be len == 7, not len > 7.</p>
<p>b) generally be stricter about the lengths.</p> Cellular Network Infrastructure - Bug #3417 (New): show asciidoc counters does not show all the c...https://osmocom.org/issues/34172018-07-25T07:01:29Zdaniel
<p>Since show asciidoc counters only iterates through the allocated rate_ctr/stat_item groups it does not necessarily show all the counters that can be available.</p>
<p>For example the sgsn only creates (and reports) bssgp:bss_ctx counters if there is actually a bssgp configured in the sgsn. While you could argue that this is just a misconfiguration the issue remains with counters allocated for each mm or pdp context. As long as no phones are GMM attached the command show asciidoc counters does not know about any statistics for mm or pdp context.</p>
<p>We could add commands to add the rate_ctr_group_desc ans osmo_stat_item_group_desc to another list which keeps track of available counters and traverse that for show asciidoc stats as we don't need the actual allocations for counter values that the *_group_alloc() functions do. Group and counter description needed for documentation are all available from the *_group_desc structs.</p>
<p>This would mean that we need to register every counter group independently from the *_group_alloc() calls happening right now, so the documentation knows about them - but as a side effect we could also have a function to allocate a rate_ctr/stat_item group by name (instead of struct pointer). Not sure how useful that would be.</p> OsmoSGSN - Bug #2958 (Stalled): OsmoSGSN doesn't authenticate on second/further ATTACH REQUESThttps://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> OsmoSGSN - Bug #2951 (Feedback): OsmoSGSN Accepts two MO L3 Messages with N(U) set to zerohttps://osmocom.org/issues/29512018-02-16T16:17:36Zlaforge
when
<ul>
<li>the MS sends its first GMM message "ATTACH REQUEST" in LLC with N(U) set to 0 (expected)</li>
<li>the SGSN then inquires abou the IMEI using GMM "IDENTITY REQUEST" </li>
<li>the MS subsequently sends its GMM "IDENTITY RESPONSE" in LLC with N(U) set to 0 again (broken behavior!)</li>
</ul>
<p>Then OsmoSGSN still accepts that IDENTITY RESPONSE. This is odd. Later on, OsmoSGSN detects duplicate N(U) sequence numbers. But at the initial stage (or maybe when it's 0?) it doesn't detect the duplicate sequence number [which should be dropped].</p> OsmoSGSN - Bug #2501 (In Progress): suspected problem with unanswered neighbor solicitationhttps://osmocom.org/issues/25012017-09-07T12:20:44Zdexter
<p>getting and using an IPV6 pdp context has been tested successfully using a<br />samsung galaxy S2, but tests with a Getnord ONYX fail.</p>
<p>In the failure case, the PDP-Context is opened successfully, also the following<br />interactions look good. Except that the pdp context is closed by the phone a<br />shortly after it had been established. The dactivation cause is a regular<br />deactivation.</p>
<p>When comparing the two traces it is distinctive, that the trace from the<br />getnord does contain a neighbor solicitation request. This request seems to be<br />ignored by the GGSN. It is likely that the getnord mobile interprets this as<br />a failure and then closes the pdp context.</p>
<p>The traces of the two cases are attached to this ticket.</p> osmo-sip-connector - Feature #1685 (In Progress): osmo-sip-connector: Review and define log state...https://osmocom.org/issues/16852016-03-31T18:41:03Zzecke
<p>Define how to handle logging and which fields to include. It should be call + leg. Right now it is only leg.</p>