Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T11:40:28ZOpen Source Mobile Communications
Redmine OsmoGGSN (former OpenGGSN) - Bug #6420 (New): osmo-ggsn + pre-configured tun device seems to be b...https://osmocom.org/issues/64202024-03-26T11:40:28Zosmith
<p>When using a pre-configured tun device with OsmoGGSN as described in the user manual, in combination with <code>gtpu-mode kernel-gtp</code>, osmo-ggsn fails to configure the kernel GTP device:</p>
<pre>
<0002> ggsn.c:210 APN(internet): Skipping APN start
<000d> gsn.c:465 GTP: gtp_newgsn() started at 10.23.24.2
<000d> gsn.c:386 State information file (/tmp/gsn_restart) not found. Creating new file.
<0002> ggsn.c:854 GGSN(ggsn0): Successfully started
<0002> gtp-kernel.c:79 Initialized GTP kernel mode (genl ID is 34)
<0001> tun.c:213 cannot create GTP tunnel device: File exists
<0002> ggsn.c:215 APN(internet): Failed to configure Kernel GTP device
</pre> OsmoGGSN (former OpenGGSN) - Bug #6419 (New): osmo-ggsn removes tun devices it did not createhttps://osmocom.org/issues/64192024-03-26T11:26:04Zosmith
<p>From the <a href="https://ftp.osmocom.org/docs/osmo-ggsn/master/osmoggsn-usermanual.pdf" class="external">user manual</a>:</p>
<blockquote>
<p>It’s possible to run OsmoGGSN without root privileges if the tun devices are already configured.<br />The interface creation + configuration must then happen before osmo-ggsn starting up.<br />[...]<br />With the tun device pre-configured in one of the ways outlined above, the main changes in your osmo-ggsn.cfg file are:<br />• remove ip ifconfig directive,<br />• make sure that no shutdown is present in the apn section as well as no shutdown ggsn in the ggsn section.</p>
</blockquote>
<p>With this configuration, a tun device created by <code>/etc/network/interfaces</code> will be removed when osmo-ggsn shuts down and <code>ifup -f apn0</code> must be used to recreate it, before starting osmo-ggsn again.</p> libosmocore - Feature #6402 (New): consider using IORING_RECVSEND_POLL_FIRST for our socket-readshttps://osmocom.org/issues/64022024-03-14T08:21:57Zlaforge
<p>io_uring has an IORING_RECVSEND_POLL_FIRST which will increase the performance of read/recv/recvmsg/recvfrom calls if no data is present in the socket at the time we submit a read.</p>
<p>This works by going directly into poll, bypassing the initial attempt to recv/recvmsg.</p>
<p>Given that our sockets are often very low traffic and work in a request/response fashion, this might be worth a shot.</p> libosmocore - Feature #6401 (New): benchmark batching io_uring operationshttps://osmocom.org/issues/64012024-03-14T08:10:59Zlaforge
<p>right now we <code>io_uring_submit()</code> reads/writes right when they are added. This triggers the kernel processing on those without the benefit of batching multiple operations.</p>
<p>We might want to try to benefit from batching by waiting until we enter osmo_select_main().</p> OsmoHNBGW - Feature #6395 (New): PFCP URR support in osmo-hnbgwhttps://osmocom.org/issues/63952024-03-08T13:38:17Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to use PFCP URR to instruct the UPF to:
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p>The osmo-hnbgw side then will have to report those packet/byte counters [at the very least] as per-hnb aggregate figures.</p>
<p>Until osmo-upf has the related features (<a class="issue tracker-2 status-7 priority-1 priority-lowest" title="Feature: Basic URR (Usage Reporting Rule) support for tunnel mapping (Stalled)" href="https://osmocom.org/issues/6394">#6394</a>), testing of the osmo-hnbgw side can be done against open5gs-upf, which should already suport it since <a class="user active" href="https://osmocom.org/users/30187">pespin</a> taught it URR support in April 2022.</p> OsmoUPF - Feature #6394 (Stalled): Basic URR (Usage Reporting Rule) support for tunnel mappinghttps://osmocom.org/issues/63942024-03-08T13:33:39Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p><a class="user active" href="https://osmocom.org/users/30187">pespin</a> had implemented something like this for open5gs-upf in<br /><pre>commit fb8ebcdbeae0648e30d04fd016a956642131dddd
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Apr 8 16:10:42 2022 +0200
[UPF] Add initial support for URR Usage Report (#1476)
</pre><br />and following commits.</p>
<p>Now sadly, open5gs-upf is more like a lab-grade upf and nothing that scales at all, and we hence have users of osmo-upf that use it for its fast kernel path.</p>
<p>The primary goal for this feature is the <em>tunnel mapping</em> case in a osmo-hnbgw co-located osmo-upf. The packet and byte counters hence will have to be added to the nftables rules.</p> libosmocore - Feature #6390 (New): port CTRL over to osmo_io / io_uringhttps://osmocom.org/issues/63902024-03-02T18:45:00Zlaforge
<p>In theory this should be fairly trivial to mogirate over. It uses a tx_queue anyway for writes today, so handing those msgb's over to osmo_io should be easy.</p>
<p>However, the user API of ctrl is a nightmare and it exposes a lot of internal details - among them are the use of ctrl_connection by a ctrl <strong>CLIENT</strong> from sysmobts_mgr.</p>
<p>Let's not do this now, the performance of CTRL is not that significant.</p> libosmocore - Feature #6389 (New): port VTY over to osmo_io / io_uringhttps://osmocom.org/issues/63892024-03-02T16:55:56Zlaforge
<p>The VTY uses its 'buffer' layer between writes by the software and writing to the acutal socket file descriptor. buffer_flush_all is currently used whenever the socket is write-able. So it's a pull model.</p>
<p>We'd probably have to change that logic to work the other way around: Once a buffer has a certain fill-level (or age?), proactively push it via osmo_io.</p>
<p>Unless somebody uses a lot of scripts acccessing the VTY, it's also unlikely that the syscall load of a human VTY user would place significant I/O load on an osmocom program. So it's not super criticial.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6354 (New): investigate UE behavior in ...https://osmocom.org/issues/63542024-02-07T16:10:55Zlaforge
<p>As we've seen in <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: connect a real phone to the epdg to test strongswan ipsec configuration (Closed)" href="https://osmocom.org/issues/6114">#6114</a> it might be interesting to control the eDPG hostname so we can generate a certificate for it (signed by letsencrypt which presumably is trusted by default in unmodified android). It's not critical as EAP-only authentication appeared to be working in the test case there.</p>
<p>It would be good to find some time to test with a couple of different UE whether they actually respect the ePDG related files / configs that can be stored in the USIM/ISIM.</p>
<p>A quick look in TS 31.102 revaled:</p>
<ul>
<li><code>EF.ePDGId</code>
<ul>
<li>contains a TLV-wrapped IPv4, IPv6 or hostname of the ePDG</li>
</ul>
</li>
<li><code>EF.ePDGSelection</code>
<ul>
<li>control the <em>Selection of the ePDG</em> proceduer in the UE (3GPP TS 24.302)</li>
<li>contais a number of (plmn, epdg_priority, epdg_fqdn_indicator)
<ul>
<li>the epdg_fqdn_indicator state whether the <em>Operator Identifier FQDN</em>, or a <em>location based FQDN</em> format shall be used</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li><code>EF.ePDGIdEm</code>
<ul>
<li>same as above, but for emergency calls</li>
</ul>
</li>
<li><code>EF.ePDGSelectionEm</code>
<ul>
<li>same as above, but for emergency calls.</li>
</ul></li>
</ul>
<p>So <code>EF.ePDGId</code> is really the most interesting one.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6345 (New): osmo-epdg: Implement SWm in...https://osmocom.org/issues/63452024-01-25T16:32:08Zpespin
<p>In current architecture of osmo-epdg, the process contains both the ePDG and the AAA Server nodes.</p>
<p>These 2 nodes speak Diameter SWm interface between them.</p>
<p>We may want to split the 2 nodes into 2 processes and properly implement SWm at some point, or use another AAA server implementation.</p>
<p>Anyway, creating the ticket as a reference point to look up/comment on related communication between ePDG and AAA nodes.</p>
Spec references:
<ul>
<li>TS 29.273 section 7</li>
<li>TS 23.402 (grep for "SWm")</li>
</ul> pySim - Bug #6322 (New): ATR type annotationhttps://osmocom.org/issues/63222024-01-03T21:55:30Zmerlinchlosta
<p>There's a small mixup in the ATR type annotations (<code>Hexstr</code> vs. <code>List[int]</code>) in <code>PcscSimLink</code>:</p>
<pre>
def get_atr(self) -> Hexstr:
return self._con.getATR()
</pre>
<p><code>pyscard</code> actually returns <code>List[int]</code> for an ATR. Depending code seems to convert using <code>i2h</code>.<br /><code>SerialSimLink</code> mimics the behavior (writing <code>self._atr</code> as <code>List[int]</code> in <code>_reset_card</code>).</p> OsmoMSC - Bug #6321 (New): SMS not delivered from corrupted SMS databasehttps://osmocom.org/issues/63212024-01-02T13:07:31Zjolly
<p>When osmo-msc is started with corrupted "sms.db", no SMS is delivered.</p>
<p>Only the earliest SMS is delivered on a location update. All other SMS are not delivered until the next location update triggers the next earliest SMS delivery.</p>
<p>The problem was solved by removing the "sms.db" file and restarting osmo-msc. All queued SMS were delivered instantly. A newly queued SMS was delivered instantly.</p>
<p>To reproduce and debug the problem, I keept the corrupt database file. It is not included with this issue, because it may contain private information. Ask me for it. (/files/auftraege/sysmocom-MSC_SMS_BUG/sms.db_buggy)</p> pySim - Feature #6315 (New): have test data for all supported fileshttps://osmocom.org/issues/63152023-12-23T09:33:25Zlaforge
<p>We long have the support for <code>_test_de_encode</code> and related class attributes specifiying per-file test data. This is still lacking for a number of files.</p>
<p>For some files it is easy to get real-world data, but for other files (specifically ADF.ISIM related, or mdoern DF.5GS) there simply are no real-world SIMs of production operators that would provide us with test data.</p>
<p>It might be worth looking at the UE/SIM conformance test specs, maybe those can help</p> pySim - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://osmocom.org/issues/63142023-12-23T09:31:02Zlaforge
<p>during execution of our pySim-shell test, even with the included pcap we're getting:</p>
<pre>
WARNING pySim.apdu.ts_102_221: SELECT UNKNOWN AID a00000015141434c00
</pre>
<p>the AID is that of the ARA-M applet. We do support ARA-M in pySim-shell. However, we do not appear to use that code from pySim-shell, probably related to the AID auto-detection missing.</p> OsmoPCU - Feature #6303 (New): Convert pcuif to TLV to make backwards compatibility more feasiblehttps://osmocom.org/issues/63032023-12-12T16:07:01Zosmith
<p>In a meeting today with <a class="user active" href="https://osmocom.org/users/30187">pespin</a> and <a class="user active" href="https://osmocom.org/users/67">fixeria</a>, we figured it would be useful to have a TLV based PCUIF protocol so we could extend it in the future without always breaking backwards compatibility. If it was backwards compatible, we would not need to have osmo-pcu, osmo-bts and osmo-bsc all speak the exact same PCUIF version as it is currently the case.</p> OsmoHNBGW - Feature #6285 (New): IUFP needs not CRCX in loopback modehttps://osmocom.org/issues/62852023-12-04T03:58:47Zneelsnhofmeyr@sysmocom.de
<p>doing CRCX in loopback mode was necessary for early 3G support in osmo-mgw.<br />We faked an IuUP Initialization ACK message using loopback and some header patching -- ugly.</p>
<p>osmo-mgw supports IuUP Initialization to work in any mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b.</p>
<p>osmo-msc has removed the loopback hack from its CRCX for IUFP in march 2023, and creates the initial IUFP conn in recvonly.<br />osmo-hnbgw should do the same.</p>
<p>Using loopback or not should be completely orthogonal to using IUFP or not.<br />So techincally, osmo-hnbgw is free to use loopback if it wants to.<br />But currently the only reason to use loopback was the IuUP hack -- with that gone, let's not keep a confusing RTP mode.</p> Cellular Network Infrastructure - Feature #6243 (New): vty cfg: make changing startup defaults of...https://osmocom.org/issues/62432023-11-01T00:56:38Zneelsnhofmeyr@sysmocom.de
<p>Sometimes our recommendation of what the usual/good setting should be for a given vty config item changes.<br />Then we have the problem that we cannot change it without endangering running installations,<br />and/or creating hassle for admins.</p>
<p>So how about a general mechanism in all of our config files in form of a vty command, maybe like this:</p>
<p>osmo-foo.cfg:<br /><pre>
defaults (v0|v1.5|v1.6)
</pre></p>
<p>so a user can decide when to make the cfg upgrade, independently from binary upgrades.</p>
<p>When 'defaults' is not specified, we would have to assume like 'defaults v0'.<br />(A bit more convenient for new users would be to add the newest available 'defaults' setting automatically somehow,<br />but I guess that also breaks the entire feature then, unless someone can think of an elegant way.)</p> libosmo-sccp + libosmo-sigtran - Feature #6241 (New): M3UA "Network Appearance" supporthttps://osmocom.org/issues/62412023-10-31T15:00:11Zlaforge
<p>M3UA has the notion of an (entirely optional) "Network Appearance" IE. We don't support it at all</p>
<p>The spec says:</p>
<blockquote>
<p><strong>Network Appearance</strong> - The Network Appearance is a M3UA local reference shared by SG and AS (typically an integer) that, together with an Signaling Point Code, uniquely identifies an SS7 node by indicating the specific SS7 network to which it belongs. It can be used to distinguish between signalling traffic associated with different networks being sent between the SG and the ASP over a common SCTP association. An example scenario is where an SG appears as an element in multiple separate national SS7 networks and the same Signaling Point Code value may be reused in different networks.</p>
</blockquote>
<p>Supporting this properly in libosmo-sigtran is likely non-trivial, as it means that everywhere where right now only the point code is considered, we need to consider point code + network appearance. This affects not only routing decisions, but it also affects things like peer addresses of SCCP connections.</p> OsmoSGSN - Bug #6176 (New): build failure (dependency / concurrency issue)https://osmocom.org/issues/61762023-09-13T15:02:17Zlaforge
<p>when trying <code>make -j8 check</code> in current master (which is also 1.11.0):</p>
<pre>
...
Making check in src
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[5]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
Making check in gprs
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
Making install in src
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC crc24.lo
CC gprs_llc_parse.lo
CC gprs_utils.lo
Making install in gprs
CC sgsn_ares.lo
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC gprs_llc_parse.lo
CC crc24.lo
CC gprs_utils.lo
CC sgsn_ares.lo
mv: cannot stat '.deps/crc24.Tpo': No such file or directory
make[3]: *** [Makefile:454: crc24.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
mv: cannot stat 'gprs_utils.loT': No such file or directory
mv: cannot stat '.deps/gprs_utils.Tpo': No such file or directory
make[3]: *** [Makefile:454: gprs_utils.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: install-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: install-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:765: install] Error 2
make: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: check-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: check-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:760: check] Error 2
</pre>
<p>doing that with <code>-j1</code> works, though.</p> OsmoBTS - Feature #6167 (New): csd_v110: implement rate adaptation for TCH/F14.4https://osmocom.org/issues/61672023-09-01T11:58:07Zfixeria
<p>We do implement scheduling of TCH/F14.4 in osmo-bts-trx, however the rare adaptation is missing. This is why current osmo-bts-trx would NACK CHANnel ACTIVation attempts for this data rate. The rate adaptation functions for TCH/F14.4 are different from the ones employed for TCH/F9.6, TCH/F4.8, and TCH/F2.4. According to 3GPP TS 48.020, chapter 10, we would need to implement RA1'/RAA' and RA1'/RAA". Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> pySim - Feature #6104 (New): reduce number of python dependencieshttps://osmocom.org/issues/61042023-07-20T15:52:39Zlaforge
<p>In terms of overall dependency reduction, I think by refactoring we can get rid of pytlv (we have much more powerful TLV code in pySim internally now). We should also be able to get rid of bidict. For pyyaml I don't even know why we depend on it... ah, the card_handler. Should also be possible to do in a simpler way without introducing that dependency.</p> OsmoBTS - Bug #5995 (New): osmo-bts printing log line 'OC=GPRS-NSE(f0) INST=(00,ff,ff): Tx unkno...https://osmocom.org/issues/59952023-04-04T18:16:58Zpespin
<p>osmo-bts fails to log properly name string of NM_MT_IPACC_SET_ATTR_ACK in oml_mo_send_msg():</p>
<pre>
DEBUGPFOH(DOML, foh, "Tx %s\n", get_value_string(abis_nm_msgtype_names, foh->msg_type));
</pre>
<p>This is because IPACCESS specific messages (enum abis_nm_msgtype_ipacc) are not included in "abis_nm_msgtype_names".</p>
<p>We need to discuss whether we want them added to "abis_nm_msgtype_names" or have some way to also translate those.<br />The problem is that there can be other vendors providing other extensions which may reuse same enum values, such as enum abis_nm_msgtype_bs11.<br />So ideally we should add a function to first check abis_nm_msgtype_names() and if it fails (or within expected range for vendor-implementation) then translte from "enum abis_nm_msgtype_ipacc".</p> OsmoPCU - Feature #5930 (New): handle multiple BTSs with one PCUhttps://osmocom.org/issues/59302023-03-02T09:07:50Zdexter
<p>OsmoPCU has been used so far in BTS co-located scenario only. This scenario always consists of exactly one BTS instance and exactly one PCU instance. When the PCU is used on a BSC colocated scenario one PCU may serve multiple BTSs. OsmoPCU already manages a list with BTSs and the PCU socket protocol already supports multiple BTSs as well but it is unclear how mature this is. At least the code/API that is used to handle the direct PHY access is not able to distinguish between different BTSs.</p> Cellular Network Infrastructure - Feature #5908 (New): Cleanup license information throughout the...https://osmocom.org/issues/59082023-02-16T10:48:43Zmsuraev
<p>Right now licensing information is rather fragmented: some files use SPDX, others don't, different license headers in the same project etc.</p>
<p>There's handy tool <a class="external" href="https://reuse.software/">https://reuse.software/</a> which could help remediate this.</p>
<p>Running 'reuse lint' in the repository (installable via 'sudo apt install reuse') will give comprehensive report regarding project licensing information.</p>
<p>Once outstanding issues are fixed, it can be added to commit linter to make sure the compliance is checked automatically.</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> libosmocore - Feature #5829 (New): log fallback for log_check_level(), log_parse_category()https://osmocom.org/issues/58292022-12-13T22:44:12Zneelsnhofmeyr@sysmocom.de
<p>in LOGPSRCC and LOGPC macros, we call log_stub() as callback when logging is not enabled.</p>
<p>Every so often, callers use log_check_level() to skip running expensive logging code if no target will print it.<br />For log_check_level() and log_parse_category(), we still call assert_loginfo(<i>func</i>) unconditionally.</p>
<p>For example osmo_pfcp_msg_err_cb() in libosmo-pfcp/src/libosmo-pfcp/pfcp_msg.c uses log_check_level(),<br />hence libosmo-pfcp regression tests need to initialize logging or get a program abort without much information.</p>
<p>To make the fallback logging more universally applicable,<br />log_check_level() could always return true when logging is not initialized;<br />log_parse_category() could always return DLGLOBAL.</p> Cellular Network Infrastructure - Bug #5819 (New): Gerrit/gitiles: Parent links don't workhttps://osmocom.org/issues/58192022-12-08T13:28:35Zarehbein
<p>When clicking the parent link in a Gitiles commit view, I get an error message</p>
<pre><code>Secure Connection Failed<br />An error occurred during a connection to gerrit.osmocom.org:80. SSL received a record that exceeded the maximum permissible length.<br />Error code: SSL_ERROR_RX_RECORD_TOO_LONG</code></pre>
<p>I have encountered this before and now again, for example here<br /><a class="external" href="https://gerrit.osmocom.org/plugins/gitiles/osmo-upf/+/2430533206004a8d9c29dc837cd08efe0d264dfb">https://gerrit.osmocom.org/plugins/gitiles/osmo-upf/+/2430533206004a8d9c29dc837cd08efe0d264dfb</a></p> OsmoHNBGW - Feature #5816 (New): Picocells availiable in R.Uhttps://osmocom.org/issues/58162022-12-07T03:42:28Zcopslock
<p>This topic is describing the info of femtocells in russia,as the local operaters seem started to retire these devices<br />For example,the MTS ePico3801<br /><img src="https://osmocom.org/attachments/download/5719/2650013279-1.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5720/2650013279-2.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5721/2650013279-3.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5722/2650013279-4.png" alt="" /></p> OsmocomBB - Feature #5815 (New): mobile: compose Bearer Capability IE depending on PHY capabiliti...https://osmocom.org/issues/58152022-12-06T19:38:37Zfixeria
<p>This was originally proposed as a checklist item in <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: mobile: implement GAPK based audio capture / playback (via ALSA) (Resolved)" href="https://osmocom.org/issues/3400">#3400</a>. The idea is to compose the <code>Bearer Capability IE</code> in Uplink <code>(CC) Setup</code> messages not only based on the VTY configuration (see below), but also based on the PHY capabilities (see <a class="issue tracker-2 status-7 priority-3 priority-high3" title="Feature: include some version information / negotiation in the L1CTL protocol (Stalled)" href="https://osmocom.org/issues/1461">#1461</a>) and GAPK codec support (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: mobile: implement GAPK based audio capture / playback (via ALSA) (Resolved)" href="https://osmocom.org/issues/3400">#3400</a>). The respective function <code>mncc_set_bearer()</code> can be found in <a class="external" href="https://cgit.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/mnccms.c">https://cgit.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/mnccms.c</a>.</p>