Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-19T19:33:49ZOpen Source Mobile Communications
Redmine libosmocore - Bug #6410 (New): osmo_io poll backend doesn't work on file descriptors that are not...https://projects.osmocom.org/issues/64102024-03-19T19:33:49Zlaforge
<p>I just wanted to use osmo_io on a file descriptor pointing to an actual file, not a socket.</p>
<p>The poll backend fails as it unconditionally tries to use sendmsg, even if the mode is READ_WRITE.</p> libosmocore - Feature #6402 (New): consider using IORING_RECVSEND_POLL_FIRST for our socket-readshttps://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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://projects.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> libosmocore - Feature #6388 (New): stats_reporter via osmo_io / io_uring?https://projects.osmocom.org/issues/63882024-03-02T16:54:39Zlaforge
<p>I briefly looked at migrating the osmo_stats_reporter over to osmo_io, and I'm not entirely sure if it's that great an idea. Right now each stats_reporter has one msgb that's allocated at socket-open time. Whenever there's something to write, that buffer is used and then immediately sent off using sendto(). There's no integration into the osmocom select loop. We always assume the [udp] socket is writable. The buffers are hence never free'd or re-allocated at runtime.</p>
<p>If we switch over to osmo_io, then it would mean every stats report allocates a new msgb, and once that's handed over to the io_uring backend there are even more allocations. So yes, we'd save the sendto system call, but at the cost of more load on the heap allocator. The syscall is likely more expensive, sure. But is it worth it? I'm not so sure.</p> pySim - Feature #6367 (New): PC/SC <-> Android OMAPI bridge for pySim and othershttps://projects.osmocom.org/issues/63672024-02-17T13:34:01Zlaforge
It's a frequent usage pattern that somebody
<ul>
<li>inserts a (sysmocom) USIM/ISIM or even EUICC in their PC/SC card reader, performs some actions with it from the PC (such as changing a file via pySim) and then</li>
<li>inserts it into a phone to test it with the modification, then</li>
<li>restarts the cycle again by removing the card and placing it in the PC/SC reader</li>
</ul>
<p>While working with <a href="https://gitea.angry.im/PeterCxy/OpenEUICC" class="external">EasyEUICC</a> it occurred to me that it has raw APDU-level access via Androids FEATURE_SE_OMAPI_UICC. So it should be possible to write an Android app that acts as a proxy/brige for passing APDUs transparently to between an UICC/eUICC present in the phone and a remote PC running pySim (or any other software that expects a local PC/SC card reader)</p>
<p>In fact, given that the vpcd project alreay has a "APDU over TCP" protocol and has an <a href="https://github.com/frankmorgner/vsmartcard/blob/master/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c" class="external">ifd_handler exposing virtual card readers to pcscd</a>, only the android side would have to be developed.</p>
<p>So in the end, using the approach above, it shoul be possible to have pySim-shell or other tools talk to the UICC/eUICC while it remains inserted into the phone. After changes were made, we have to see if we can somehow trigger the REFRESH proactive command to tell the baseband to discard its cache and re-read the card contents. Likely a manual "Airplane mode on / off" toggle will also do the trick. But no more inserting/removing the card in between iterations.</p>
<p>Of course the same should in theory be possible also via 03.48 OTA / SCP80 without any Android app. However, OTA works with "APDU scripts" and that's not 1:1 the same as a live connection to the card, where the card doesn't loose state like which file was SELECTed between different OTA commands.</p>
Any ideas/comments on this? I'm not an Android developer, but the task looks reasonably simple to me:
<ul>
<li>access the UICC/eUICC the same way as EasyEUICC</li>
<li>create a TCP connection to a user-configured IP/Port (the ifd-vpcd)</li>
<li>implement the super simple VPCD protocol over TCP to transceive APDUs</li>
</ul> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6354 (New): investigate UE behavior in ...https://projects.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://projects.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> pySim - Feature #6316 (New): include test data in user manualhttps://projects.osmocom.org/issues/63162023-12-23T09:36:16Zlaforge
<p>If you're looking at a SIM that doesn't have meaningful contents in all files,<br />It's sometimes difficult to figure out the JSON syntax that you can use in edit_binary_decoded and the like.</p>
<p>However, we already do have valid per-file JSON as part of the tests (like the <code>_test_de_encode</code> list). So in order to improve the situation, let's try to auto-generate a section of the user manual which contains those examples.</p> pySim - Feature #6315 (New): have test data for all supported fileshttps://projects.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://projects.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> OCTOI - Osmocom Community TDM over IP - Bug #6281 (New): divf yate: calls to wave playback or loo...https://projects.osmocom.org/issues/62812023-12-03T16:03:18Zlaforge
<p>I think we've had this problem before, but I don't recall how we worked around it. For sure after my yate upgrade (or the diaplan changes yesterday) we get the following behaviour:</p>
<ul>
<li>loopback doesn't ever answer</li>
<li>wave playback happens at early audio before the call ever connects</li>
</ul>
<p>any ideas?</p> libosmo-sccp + libosmo-sigtran - Feature #6241 (New): M3UA "Network Appearance" supporthttps://projects.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> libosmo-sccp + libosmo-sigtran - Feature #6239 (New): finally deprecate libosmo-sccp (headers, st...https://projects.osmocom.org/issues/62392023-10-31T14:43:09Zlaforge
<p>This is about deprecating the actual libosmo-sccp library (not the libosmo-sccp.git repo). That libosmo-sccp.a is an old static library that was originally used in the old openbsc in the openbsc.git repo (initial sccplite support) as well as the bsc_mgcp and other ancient stuff.</p>
<p>No currently maintained software should be linking libosmo-sccp.a but only use libosmo-sigtran.so.</p>
<p>To the best of my knowedge, there are some header files / enum values that are used by some applications. Those definitions should be copied to a [new?] header file of libosmo-sigtran, so that applications can stop doing <code>PKG_CHECK_MODULES(LIBOSMOSCCP, libosmo-sccp)</code></p> Retronetworking - Feature #6224 (Feedback): how to document the rescued EWSDhttps://projects.osmocom.org/issues/62242023-10-18T16:50:10Zlaforge
<p>To me, the <em>EWSD rescue</em> project is not just about getting the equipment safely disassembled and reassembled at <a class="user active" href="https://projects.osmocom.org/users/42">jolly</a>, but also to document this <em>for posterity</em></p>
This, in my opinion, would include:
<ul>
<li>some general description of the project (why, ...)</li>
<li>some high-level introduction on what an EWSD is/was, and what role it played</li>
<li>media from disassembly/transport/reassembly
<ul>
<li>various photos from August and October</li>
<li>timelapse videos from October
<ul>
<li>wait for everyone to agre on whether they want to be shown</li>
<li>edit out the lunch break parts</li>
<li>mask out sections of the pictures unrelated to the EWSD, if requested by telecom operator</li>
</ul>
</li>
</ul>
</li>
<li>wiki pages on the individual components (circuit boards)
<ul>
<li>high-res photographs of both sides of the PCBA</li>
<li>EPROM images (if any)</li>
<li>some textual description based on our knowledge and related documentation</li>
</ul></li>
</ul>
<p>I'm happy to contribute in terms of writing documentation/wiki pages, putting together general EWSD information, editing the timelapse videos, etc.</p>
<p>However, I can obviously not take PCBA photographs or dump EPROMs.</p>
<p>One of the main topics is to decide how and where to publish the information. We could create a separate redmine project here, even though it is not the most easy interface for people to navigate and find information. At least we could edit wiki pages, etc. - we don't really have a nice gallery with captions for pictures, though. Maybe there is some useable redmine extension for that?</p>
<p>We could use some other system for collecting the information, but then that system would have to be maintained/preserved for decades to come.... and staying within redmine increases the likelihood as that's what we will preserve for Osmocom anyway.</p>
<p>Any thoughts?</p>
<p>Any comments welcome</p> OsmoSGSN - Bug #6176 (New): build failure (dependency / concurrency issue)https://projects.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> libosmo-abis - Bug #5756 (New): io_uring support in libosmo-abishttps://projects.osmocom.org/issues/57562022-11-09T12:57:42Zlaforge
<p>Once libosmocore provides the new API for the upcoming io_uring backend (<a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: io_uring support in libosmocore (Resolved)" href="https://projects.osmocom.org/issues/5751">#5751</a>) we will need to port libosmo-abis over to this new API.</p>
<p>Currently we're using the following code-paths for I/O</p>
<table>
<tr>
<th>libosmo-abis function</th>
<th>I/O function</th>
<th>provided by</th>
</tr>
<tr>
<td>ipa_client_write_default_cb</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>ipa_server_conn_write</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>ipa_client_read</td>
<td>ipa_msg_recv_buffered</td>
<td>libosmocore</td>
</tr>
<tr>
<td>ipa_server_conn_read</td>
<td>ipa_msg_recv_buffered</td>
<td>libosmocore</td>
</tr>
</table>
<p>We need to analyze each of those and migrate, if possible.</p>
<p>There are also the mISDN and DAHDI input drivers, which are currently not seen as performance critical.</p>
<p>Likewise there is RTP support in libosmo-trau which is doing I/O via libortp, which we also consider out of scope for now.</p> OCTOI - Osmocom Community TDM over IP - Bug #5693 (Stalled): no progress tones in yatehttps://projects.osmocom.org/issues/56932022-09-30T13:04:16Zlaforge
<p>We've never had call progress tones from yate in our network and had ignored that until now.</p>
This is the case in
<ul>
<li>any outbound call setup from a phone, where there are no dial tones, alerting tones, etc.</li>
<li>calls routed to tone/*</li>
</ul>
<p>The respective ToneSource() class instances are created and provide the respective quantity of samples. It works for SIP, but not for ISDN.</p>
<p>I think it's related to the Q.931 signaling side. It states:</p>
<blockquote>
<p><strong>5.4 In-band tones and announcements</strong></p>
<p>When in-band tones/announcements not associated with a call state change are to be provided by the network before reaching the Active state, a PROGRESS message is returned simultaneously with the application of the in-band tone/announcement. The PROGRESS message contains the progress indicator No. 8, in-band information or appropriate pattern is now available.</p>
<p>When tones/announcements have to be provided together with a call state change, then the appropriate message [e.g. for ALERTING, DISCONNECT, etc., (see clause 3)] with progress indicator No. 8, in-band information or appropriate pattern is now available, is sent simultaneously with the application of the in-band tone/announcement.</p>
</blockquote> OCTOI - Osmocom Community TDM over IP - Feature #5526 (New): ability to generate GSMTAP traces fr...https://projects.osmocom.org/issues/55262022-04-12T12:08:36Zlaforge
<p>In a typical setup, where icE1usb + osmo-e1d are used to connect some PBX or other PRI capable equipment, it would be nice if osmo-e1d could be used to generate signaling protocol traces.</p>
This would work as follows:
<ul>
<li>some VTY command to create a GSMTAP source</li>
<li>some VTY command to create software HLDC decoder instances (always in pairs for Rx+Tx) on specific timeslots of specific lines</li>
</ul>
<p>GSMTAP source and software HDLC are available in libosmocore, they just need to be hooked up accordingly</p> osmo-e1d - Feature #5520 (New): exponential back-off on octoi client reconnect attemptshttps://projects.osmocom.org/issues/55202022-04-10T10:38:29Zlaforge
<p>right now the octoi-client is re-trying at a fixed 3s interval. We should back-off if for some reason we cannot establish the connection, up to e.g. 30s.</p> OCTOI - Osmocom Community TDM over IP - Feature #5519 (New): reimplement overlapped.php based on ...https://projects.osmocom.org/issues/55192022-04-09T17:36:33Zlaforge
<p>I really don't like PHP and would like to replace the overlap dialling php script with something I can read, understand and maintain.</p>
<p>There are several python libraries implementing the yate messaging protocol for external modules around.</p> OCTOI - Osmocom Community TDM over IP - Feature #5434 (Stalled): more statistics / countershttps://projects.osmocom.org/issues/54342022-01-30T11:09:45Zlaforge
<p>For some more long-term testing or later operation, we need good statistics, such as</p>
<ul>
<li>re-ordered or missing IP packets</li>
<li>Rx/Tx byte/packet count</li>
<li>RTT</li>
<li>frame underflows in IP -> E1 direction</li>
</ul>
<p>Those stats could be interrogated via VTY, but ideally also exposed via our libosmocore statsd exporter.</p> osmo-e1d - Feature #4915 (New): consider a one-thread-per-line architecturehttps://projects.osmocom.org/issues/49152020-12-18T10:22:48Zlaforge
<p>If we want to auto-discover hot-plugged USB devices at runtime, we need to consider situations where we hve to do that <em>while</em> other E1 interfaces/lines are in operation. We hence have to do everything asynchronous/non-blocking to those existing interfaces/lines.</p>
This is particularly cumbersome in terms of anything that performs USB transactions to the new device:
<ul>
<li>obtaining the serial number string of the USB device</li>
<li>SET_CONFIGURATION</li>
<li>SET_INTERFACE (needed for altif=1)</li>
</ul>
<p>One approach would be to have one thread per e1_line. This thread would be created before opening the respective USB device (each in its own libusb_context). It would furthermore server all the per-timeslot file-descriptors of the line it serves, and due to its own libusb_context also serve [only] those libusb file-descriptors related to its USB interface.</p>
<p>We'd need some rwlock around the global list of interfaces / devices (vty introspection from main thread), and some kind of fd-based communication between main thread (ctl socket from/to applications) and the per-line threads for handling TS_OPEN / LINE_CONFIG.</p>
<p>This architecture would give us the least possible impact from opening a new USB interface (== e1_line) and provide significant isolation.</p> OsmoBTS - Bug #3056 (Rejected): OsmoBTS doesn't implement SACCH Repetition Order (SRO)https://projects.osmocom.org/issues/30562018-03-11T18:41:01Zlaforge
<p>3GPP TS 44.004 + 44.006 are referring to a SACCH Repetition Order mechanism which uses a bit in the SACCH L1 header. I don't think we handle this at all - yet it's not stated anywhere that handling would be optional.</p> libosmo-sccp + libosmo-sigtran - Feature #2006 (New): Implement M2PA supporthttps://projects.osmocom.org/issues/20062017-04-10T12:04:13Zlaforge
<p>M2PA is what is used e.g. by Cisco ITP, and I believe also by yate. So we could test SS7 routing/interop with those implementations if we had M2PA support.</p> Linux Kernel GTP-U - Bug #1953 (Resolved): IPv6 support for outer (transport) IP layer missinghttps://projects.osmocom.org/issues/19532017-02-18T12:29:47Zlaforge
<p>The 3GPP specs permit for both IPv4 and IPv6, but we only implement IPv4. This is embarrassing and should be changed. Contribution welcome!</p> OsmoBTS - Bug #1618 (Rejected): AMR adaption loop doesn't use C/I thresholds, only BERhttps://projects.osmocom.org/issues/16182016-02-23T16:27:47ZlaforgeOsmoSGSN - Feature #1585 (New): Gn interface for inter-SGSN MM Context transferhttps://projects.osmocom.org/issues/15852016-02-23T15:44:50Zlaforge
<p>Currently, we support mobility between multiple PCUs attached to one SGSN, but we don't support transfer of the MM context from one SGSN to another SGSN. The latter would require an implementation of the GTP-C based Gn interface.</p>