Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-08T13:33:39ZOpen Source Mobile Communications
Redmine 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> Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> pySim - Bug #6317 (Stalled): data driven tests for TLV decodershttps://osmocom.org/issues/63172023-12-23T15:12:32Zlaforge
<p>While we do have the <code>_test_de_encode</code> data driven tests for file definitions, we don't yet have something similar for derived classes of BER_TLV_IE. This means that TLVs used outside of the filesystem context (for example, decoding the SELECT/STATUS response, but also eUICC and other stuff) do not yet have test coverage.</p> OsmoMGW - Feature #6136 (Stalled): libosmo-mgcp-client should ignore unknown codecs in SDPhttps://osmocom.org/issues/61362023-08-08T16:46:58Zneelsnhofmeyr@sysmocom.de
<p>When mgcp_client receives an MGCP response that has an unknown codec in the SDP part, it aborts with an error.<br />Instead, it should simply ignore entries that are unknown, and carry on with other, known, codecs.<br />An error should occur only when none of the SDP codec entries is valid.</p> OsmoHLR - Feature #6135 (Stalled): Implement routing of SMS-over-GSUP messages between connected ...https://osmocom.org/issues/61352023-08-07T09:14:59Zfalconia
<p>As of <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Possibility to route SMS messages over GSUP (Resolved)" href="https://osmocom.org/issues/3587">#3587</a>, OsmoMSC can suppress its built-in SMSC and instead pass SMS-PP to and from external SMSCs via MAP-mimicking GSUP, following classic GSM architecture. However, current OsmoHLR is unable to route these SMS-over-GSUP messages: if I implement my own GSUP-speaking SMSC and connect it to OsmoHLR, the latter won't know how to forward MO-forwardSM.req from OsmoMSC to the SMSC based on the SC-address in SM-RP-DA, or how to forward MT-forwardSM.req in the opposite direction based on the IMSI.</p>
<p>Themyscira Wireless is currently in need of a custom SMSC, I am starting to implement one, and I am looking to do it in the most GSM-architecture-classic manner. The mechanism of SMS-over-GSUP looks like the right way to do what I seek, or at least from OsmoMSC side the protocol does exactly what it should, pass SM-RP to an external SMSC with minimal transformation. My SMSC would connect to OsmoHLR via GSUP much like EUSEs do for USSD - copy the same model, so far so good. But the routing piece in OsmoHLR is missing.</p>
<p>I propose the following design:</p>
<ul>
<li>Similarly to how EUSEs connect with IPA names of the form EUSE-foobar, require SMSCs to connect with IPA names of the form SMSC-12345, where 12345 is the SC-address of this SMSC, i.e., the number to be programmed as the Service-Centre-Address in the EF_SMSP record on SIM cards.</li>
</ul>
<ul>
<li>When MO-forwardSM.req comes from MSC/VLR, route it based on SM-RP-DA: require the address type to be SMSC, and look for a connected GSUP peer with name SMSC-12345 or whatever digit string is in the SC address field coming from the MS.</li>
</ul>
<ul>
<li>To route MO-forwardSM.{resp,err} correctly, the SMSC will be responsible for setting destination_name in the response to a copy of source_name from the request, ideally using osmo_gsup_req_respond().</li>
</ul>
<ul>
<li>When MT-forwardSM.req comes from an SMSC, route it to the serving VLR based on the IMSI just like MT USSD coming from an EUSE.</li>
</ul>
<ul>
<li>For MT-forwardSM.{resp,err} routing, OsmoMSC will need to be patched to fill response destination_name with a copy of request source_name, which it currently fails to do.</li>
</ul>
<p>The only part for which I don't have any solution currently is READY-FOR-SM.req: it's a request coming from MSC/VLR, but there is no SMSC address to route to. In the official architecture the HLR is expected to keep a list of SMSC that attempted and failed MT SMS delivery, and notify all of them upon a single "ready" notification from MSC/VLR - but implementing all that complexity would be a bit too much for me at the present moment. I am thinking of having OsmoHLR simply reply with "success" to READY-FOR-SM.req as a FIXME placeholder in the initial implementation, just so that the MS gets an RP-ACK rather than RP-ERROR (the MS did nothing wrong!), and leave it as a problem to be solved later.</p>
<p>Any better ideas?</p> Core testing infrastructure - Feature #6023 (Stalled): test rack/lab power management software wi...https://osmocom.org/issues/60232023-05-04T06:38:46Zlaforge
<a name="Problem-Statement"></a>
<h2 >Problem Statement<a href="#Problem-Statement" class="wiki-anchor">¶</a></h2>
<p>In our test/lab setups, we do have a number of systems that run 24/7 but which are really used only very few hours per day. This has become very visible after we started (a few months ago) to deploy tasmota/influxdb/grafana for plotting many different power rails.</p>
<p>Direct on/off switching from within a given test job only works if that test job is the only user of the given resource (such as e.g. a BTS in osmo-gsm-tester).</p>
<p>For jenkins builders, OBS workers and similar machines, there could be any number of concurrent users. So there's no single job that can power on the resourec before using it, and power it off after it terminates.</p>
<p>What we need is a system that maintains a usage count, similar to how we do usage/reference counting in data structures in software development.</p>
<p>I've started to prototype a modular python daemon which offers a REST API over which users can obtain <em>usage tokens</em> for named resources. The daemon then keeps track of the current use count and switches resources on/off as needed.</p>
<p>Jenkins jobs would then (e.g. in a pipeline) first obtain a usage token (which would implicitly power up the resource if it is not aleady powwered), and release the usage token after they're gone. This way we can power up build machines only when needed, saving significant electrical power, reducing noise and minimizing heat dissipation.</p>
<a name="Architecture-Class-model"></a>
<h2 >Architecture / Class model<a href="#Architecture-Class-model" class="wiki-anchor">¶</a></h2>
<a name="Resource"></a>
<h3 >Resource<a href="#Resource" class="wiki-anchor">¶</a></h3>
<p>A <em>Resource</em> is typically some kind of physical equipment (server, build host, network equipment, ...) which one or multiple users may be using concurrently.</p>
<p>The Resource has a state, such as</p>
<table>
<tr>
<th>State</th>
<th>Description</th>
</tr>
<tr>
<td>off</td>
<td>Powered down</td>
</tr>
<tr>
<td>powered</td>
<td>Powered up, but not reachable yet</td>
</tr>
<tr>
<td>available</td>
<td>Powered up and reachable (typically via network)</td>
</tr>
</table>
<p>A Resource refers to a <em>Switcher</em> and an <em>AvailabilityChecker</em></p>
<p>A Resource keeps a list of <em>UsageToken</em>; one for each concurrent user.</p>
<a name="Switcher"></a>
<h3 >Switcher<a href="#Switcher" class="wiki-anchor">¶</a></h3>
A <em>Switcher</em> is something that can switch power. Possible implementations include
<ul>
<li>sispm compatible USB-switchable power sockets</li>
<li>Intellinet rackmount PDUs with IP/HTTP interface</li>
<li>Tasmota switchable power sockets</li>
<li>ethernet wake-on-lan (on) + ssh-based shutdown (off)</li>
</ul>
A <em>Switcher</em> implementation (inheriting from the abstract Switcher base class) provides methods for
<ul>
<li>changing the power state (on/off)</li>
<li>determining the current actual power state (if supported by hardware). This is important to get the state right at start-up time.</li>
</ul>
<a name="SwitcherGroup"></a>
<h3 >SwitcherGroup<a href="#SwitcherGroup" class="wiki-anchor">¶</a></h3>
<p>A <em>SwitcherGroup</em> is a logical group of multiple <em>Switcher</em>, for example the set of four switchable sispm sockets in one power strip, or the set of 8 switchable power ports in an Intellinet PDU.</p>
<a name="AvailabilityChecker"></a>
<h3 >AvailabilityChecker<a href="#AvailabilityChecker" class="wiki-anchor">¶</a></h3>
<p>An <em>AvailabilityChecker</em> is something that can check the logical availability of a (powered-up) resource. One common example for an IP-attached resources is an ICMP echo request/response based check.</p>
<a name="UsageToken"></a>
<h3 >UsageToken<a href="#UsageToken" class="wiki-anchor">¶</a></h3>
<p>An <em>UsageToken</em> for a <em>Resource</em> must be obtained by any user intending to use the Resource. The UsageToken has a validity time (in seconds), after which it automatically expires.</p>
<p>Release of the UsageToken can hence be either explicit (via REST API after the user is done) or implicit (timeout of the validity period).</p> SDR (Software Defined Radio) - Feature #5892 (Stalled): design/build ext clock input board for Pl...https://osmocom.org/issues/58922023-02-06T10:04:22Zlaforge
<p>We have a number of plutosdr devices at sysmocom, unfortunately all of them still RevB which unlike current RevD has no external clock input. Most of our use cases require a proper reference clock input, so I thought it might be a good idea to build a small board which contains the LTC6957HMS-3#PBF based input circuitry that was added in RevD. This circuit ensures that any square or sine clock can be used, at proper 50 Ohm impedance, over a wide range of levels.</p>
<p>The ext in / ext out ports should be SMA connectors, so that the resulting PCB can be panel-mounted by bulkhead-mounting those two SMA connectors to a face plate of whatever enclosure we're putting the plutosdr into.</p>
<p>The interconnect between the clock board and plutosdr can be made via u.fl as shown in <a class="external" href="https://coherent-receiver.com/wp-content/uploads/2018/01/umc-pluto-site.jpg">https://coherent-receiver.com/wp-content/uploads/2018/01/umc-pluto-site.jpg</a></p>
<p><a class="external" href="https://wiki.analog.com/university/tools/pluto/hacking/hardware">https://wiki.analog.com/university/tools/pluto/hacking/hardware</a></p> Core testing infrastructure - Feature #5760 (Stalled): Develop TTCN-3 test suite for MMEhttps://osmocom.org/issues/57602022-11-09T21:46:56Zlaforge
<p>Implement functional test suites in the TTCN-3 domain specific language for the MME, and create jenkins/docker/... integration for executing it nightly against open5gs mme.</p> OsmoSGSN - Feature #5759 (Stalled): Support for Mobility between SGSN (2G/3G) and S-GW (4G)https://osmocom.org/issues/57592022-11-09T21:45:34Zlaforge
<p>Develop the interface for mobility between 2G/3G and 4G on the S-GW/SGSN level, allowing subscribers to switch seamlessly between 2G/3G and 4G coverage areas with minimal interruption.</p> pySim - Bug #5714 (Stalled): update_record_decoded does not use real record length when writing E...https://osmocom.org/issues/57142022-10-16T08:44:29ZCHV
<p>I'm using old regular cards for testing.</p>
<p>Class EF_MSISDN, method _encode_record_hex always assumes a rec_len of 15 which results in misaligned/invalid data if the real record length is different.<br />The encoded msisdn must always use the <ins>last 14 bytes</ins> in the record. This can only be achieved when the real record length is used.</p>
<p>Example:<br /><pre>
select MF/ADF.USIM/EF.MSISDN
update_record_decoded 1 {"msisdn":"+491234567890"}
read_record_decoded 1
read_record 1
</pre></p>
<p>This may also concern updating EF.ADN records.</p> OCTOI - Osmocom Community TDM over IP - Bug #5693 (Stalled): no progress tones in yatehttps://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> Core testing infrastructure - Bug #5665 (Stalled): ERROR: files left in build directory after dis...https://osmocom.org/issues/56652022-08-28T09:21:41Zfixeria
<p>Since recently we're observing sporadic master-* job failures on Jenkins. There is always a coredump file, which makes 'distcleancheck' target fail:</p>
<pre>
ERROR: files left in build directory after distclean:
./tests/core
make[1]: Leaving directory '/build/libosmocore-1.7.0.26-862dd/_build/sub'
make[1]: *** [Makefile:1010: distcleancheck] Error 1
make: *** [Makefile:941: distcheck] Error 1
</pre>
<p>This is not specific to libosmocore, I saw master-osmo-{bsc,msc} failing with the same verdict too.</p> OsmoMSC - Bug #5568 (Stalled): SMPP socket doesn't use TCP_NODELAYhttps://osmocom.org/issues/55682022-05-17T18:33:30Zlaforge
<p>The SMPP socket uses sockets directly (without relying on libosmo-netif/stream) and fails to setsockopt(TCP_NODELAY). This is not critical (SMS is sloooow), but it does add unintended latency to all SMPP messages sent.</p>
<p>The quick fix is to add the setsockopt for every socket we accept(). The clean-up would be to use libosmo-netif/stream...</p> OsmocomBB - Feature #5502 (Stalled): MS-side LLC implementationhttps://osmocom.org/issues/55022022-03-29T12:35:40Zlaforge
<p>The LLC + SNDCP protocols are rather symmetrical, so the existing code from the network side (in <a class="wiki-page" href="https://osmocom.org/projects/osmosgsn/wiki">osmo-sgsn</a> should be possible to generalize rather easily</p> OsmocomBB - Feature #5501 (Stalled): MS-side GPRS Mobility Management (GMM) + Session Management ...https://osmocom.org/issues/55012022-03-29T12:32:56Zlaforge
<p>In order to support GPRS from the MS side, we will need a GMM + SM implementation on the mobile side.</p>
<p>The network side is already implemented as part of <a class="wiki-page" href="https://osmocom.org/projects/osmosgsn/wiki">osmo-sgsn</a></p> OCTOI - Osmocom Community TDM over IP - Feature #5434 (Stalled): more statistics / countershttps://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> OCTOI - Osmocom Community TDM over IP - Feature #5417 (Stalled): S/T (S0) ISDN BRI adapter with V...https://osmocom.org/issues/54172022-01-24T19:52:37Zlaforge
<p>So.. As part of the <a class="wiki-page" href="https://osmocom.org/projects/octoi/wiki/Community_TDMSS7_Network">Community_TDMSS7_Network</a>, offering PRI is nice but most people will have BRI equipment (modems, ISDN-TA, small home PBX, ...) that they'd be interested in attaching.</p>
<p>Doing this with COTS ISDN adapters is not an option, as we cannot control their clock to match the master clock of the TDMoIP network.</p>
<p>I've been brainstorming a potential design and validated component availability. Currently I'm thinking of something like this</p>
<ul>
<li>CologneChip XHFC-2SU (2-port S0) controller IC, operated in NT mode
<ul>
<li>available from stock at MOQ-160 from CologneChip</li>
</ul>
</li>
<li>Matching dual magnetics.
<ul>
<li>digikey + mouser have a few pulse parts still in stock (low qty): T5007</li>
<li>Sumida has stopped all production</li>
<li>Talema has 30 weeks lead time</li>
<li>UMEC still has some stock of UT20795-5MTS, I'm putting a 250 unit reel on sysmocom stock right now</li>
</ul>
</li>
<li>clocking
<ul>
<li>10 MHz VCXO (optional external 10 MHz input in case somebody already has GPS-DO around)</li>
<li>some clock divider to bring this down to 8kHz. If we have no other programmable logic or timer/counter blocks that can be used, an ATTiny clocked off 10MHz (no prescaler, counter generating interrupt every 250 cycles, divide-by-5 in software/irq-handler) approach can be used - doen in a lot of DYI 10MHz -> 1PPS designs.</li>
<li>some PWM or DAC to drive the VXCO</li>
</ul></li>
</ul>
<p>The more interesting question is the interface on the "Compute" side.</p>
Possible high-level approaches:
<ol>
<li>USB-attached to some Linux PC
<ul>
<li>more analoguous to icE1usb, but requires an additonal computer</li>
</ul>
</li>
<li>Raspi hat (or beagle or the like)
<ul>
<li>I'm not a big raspi fan, but they are very popular</li>
</ul>
</li>
<li>built-in Ethernet for direct TDMoIP
<ul>
<li>most easy to deploy, would allow people without Linux knowledge to simply plug+play</li>
</ul></li>
</ol>
<p>Right now I'm leaning mostly towards something self-contained with built-in Ethernet.</p>
The major problem right now is availability of uC or FPGA.
<ul>
<li>STM32 are basically vanished off the planet</li>
<li>iCE40 equally not available (yes, <a class="user active" href="https://osmocom.org/users/12">tnt</a> might get 100, but ...)</li>
</ul>
<p>One thought might be to use an SAME5x (sysmocom uses that part in the sysmoOCTSIM and has some stock. It is a bit on the high-end side compared to the requirements).</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> osmo-e1d - Bug #4916 (Stalled): USB unplug / replug renders e1d unusablehttps://osmocom.org/issues/49162020-12-18T10:28:45Zlaforge
right now the behavior on USB unplug (or - god forbid - a firmware crash) is not very user friendly:
<ul>
<li>e1d keeps running</li>
<li>e1d does not re-open the device when it comes back</li>
</ul>
IMHO, we have the following options
<ol>
<li>fail fast - simply exit when the device is lost, assume systemd or some other management instance will keep respawning us until the device is back
<ul>
<li>but what about client programs like osmo-bsc / osmo-mgw ?</li>
</ul>
</li>
<li>implement re-opening of a single icE1usb device, knowing our blocking control transfers would corrupt any other ongoing communication
<ul>
<li>is it worth the effort, assuming this is only an interim solution</li>
</ul>
</li>
<li>go for a full-blown hot-plug capable architecture lined out in <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: consider a one-thread-per-line architecture (New)" href="https://osmocom.org/issues/4915">#4915</a>
<ul>
<li>will probably take significant effort</li>
</ul></li>
</ol>
<p>I think right now we mostly have to worry about situations with a single icE1usb, so I'm tempted to go for the fail-fast approach, assuming osmo-bsc/osmo-mgw recover in some way.</p> OsmoPCU - Bug #4879 (Stalled): endless pdch.cpp:809 Got CS-N RLC block: R=0, SI=0, TFI=0, CPS=0, ...https://osmocom.org/issues/48792020-11-29T23:17:31Zfixeria
<p>I just upgraded all osmo-{ran,cni} components to the recent master, and now quite often run into a situation when the MS (at least Sony Ericsson K800i, TEMS) keeps sending the same Uplink block again and again. I am not sure what exactly causes it, but I can reproduce it more or less reliably by starting Opera Mini (<a class="external" href="http://people.osmocom.org/fixeria/j2me/opera_mini.jar">http://people.osmocom.org/fixeria/j2me/opera_mini.jar</a>). When started for the first time, Opera initiates the installation process, and this is where the problem usually shows up.</p>
<pre>
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACUL INFO pdch.cpp:809 Got CS-2 RLC block: R=0, SI=0, TFI=0, CPS=0, RSB=0, rc=264
DRLCMACMEAS INFO gprs_rlcmac_meas.cpp:108 MS(TLLI=0xc5849e78, IMSI=901990000000021, TA=0, 10/0, UL DL) UL RSSI: -29 dBm
</pre>
<p>Please see the attached capture file. Some highlights:</p>
<pre>
43585 RACH!
43591 IMM ASS (single block)
43731 UL Packet Resource Request
43799 DL Packet Uplink Assignment (TS=6 USF=0)
...
43910 UL DATA (BSN=0 CV=15)
...
43915 UL DATA | TCP FIN,ACK (Opera Mini closes connection to the server)
...
43918 UL DATA (BSN=3 CV=15)
43955 UL DATA (BSN=5 CV=14) <-- 14 RLC blocks left
...
44070 UL DATA (BSN=14 CV=5)
...
44146 UL DATA (BSN=19 CV=0) <-- 0 RLC blocks left
...
44149 UL DATA (BSN=19 CV=0) <-- re-transmission
44152 UL DATA (BSN=19 CV=0) <-- re-transmission
</pre>
<p>starting from frame 44149, the MS keeps transmitting the same RLC/MAC block ('35bdc794cd2b631285b2d43513'O). Interestingly enough, after each re-transmission the PCU logs "GPRS DL CTRL: PACKET_UPLINK_ACK_NACK", but <strong>does not actually send it</strong> (dummy RLC/MAC frames are not recorded). And this goes like that unless I turn off the phone. At the same time, Downlink blocks are received and accepted by the MS on the same timeslot.</p>
<p>OsmoPCU 58cd1d2f8a0474de45112e8d6e460051494eba79<br />OsmoBTS def24f0d9af2463a5ef557d35f23abd5b4d07120</p> OsmoBTS - Bug #4801 (Stalled): BTS_Tests.TC_tch_sign_l2_fill_frame_dtxd failshttps://osmocom.org/issues/48012020-10-11T19:52:01Zlaforge
<p>The tests fails with the sttement</p>
<pre>
TC_tch_sign_l2_fill_frame_dtxd(6)@nataraja: received only 2+0 (SACCH+other) out of 3 expected fill frames
MTC@nataraja: Test case TC_tch_sign_l2_fill_frame_dtxd finished. Verdict: fail reason: "BTS_Tests.ttcn:6675 : Not enough fill frames received"
</pre>
<p>So it seems like the SACCH in downlink is received, but the fill frames that should be sent by the related code in osmo-bts (<a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/10415">https://gerrit.osmocom.org/c/osmo-bts/+/10415</a>) are either not sent, or somehow lost, or not detected by the test case.</p> OsmoPCU - Bug #4452 (Stalled): manual testing of osmo-pcuhttps://osmocom.org/issues/44522020-03-10T15:46:02Zroh
<p>these are manual testruns with osmo-pcu and osmo-bts-sysmo from -nightly and the cni running on debian on an apu.</p>
<p>attached are the configs for the sysmobts (osmo-pcu and osmo-bts-sysmo) as well as the remaining cni (on debian9 from -nightly)</p>
<p>the pcap files are generated by dumping the complete interface on the bsc. in addition to that the gsmtap for -bts and -pcu sends its debug there.<br />the pcap file(s) are single runs: getting the phone from airplane mode - register - do a network request - airplane mode.</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 - Feature #3659 (Stalled): handover during LCLS directly between BTSshttps://osmocom.org/issues/36592018-10-17T09:22:23Zlaforge
<p>So far, we have implemented LCLS on the BSC level, i.e. in case of a local switch, the RTP stream still goes from BTS A to the BSC-colocated MGW and from there to BTS B. This removes the RTP/voice from A, but not from the Abis side.</p>
<p>In deployments where there are e.g. 3 BTS (A,B,C) at one site, back-hauled via Abis to a BSC in a remote data center, we want the voice to go directly between BTS A and BTS B, without going to the MGW at the BSC.</p>
<p>This basically means that we close the loop not inside our osmo-mgw via MGCP, but that we close it between the two involved BTSs.</p>
<p>Even in a single-remote-BTS use case, this helps in cases where both calling and called subscribers are attached to that same BTS.</p> OsmocomBB SDR PHY - Bug #3459 (Stalled): apps/grgsm_trx: AssertionError: packe t_info.packet_coun...https://osmocom.org/issues/34592018-08-09T19:10:03Zfixeria
<p>Despite actual burst transmission works, I see the following messages repeated multiple times:</p>
<pre>
[i] Recv POWEROFF cmd
[i] Stopping transceiver...
[i] Setting TA value 0
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: drop all
[i] Recv MEASURE cmd
[i] Recv POWEROFF cmd
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: TS 0
[i] Recv POWERON CMD
[i] Starting transceiver...
thread[thread-per-block[15]: <block gr uhd usrp sink (8)>]: EnvironmentError: IOError: Radio ctrl (0) packet parse error - AssertionError: packe
t_info.packet_count == (seq_to_ack & 0xfff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /build/libuhd/src/uhd-3.11.1.0/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:254
</pre>
<p>Observed within a Docker image wit the recent software:</p>
<ul>
<li>UHD_3.11.1.0-0-unknown</li>
<li>GNU Radio 3.7.11-6</li>
<li>GR-GSM TRX from fixeria/trx</li>
</ul>
<p>Could you please have a look?<br />Do you see this too?</p> OsmocomBB SDR PHY - Bug #3458 (Stalled): apps/grgsm_trx: [ERROR] [STREAMER] recv packet demuxer u...https://osmocom.org/issues/34582018-08-09T18:29:31Zfixeria
<p>Sometimes, while running the following output appears:</p>
<pre>
[i] Recv ECHO cmd
[i] Recv POWEROFF cmd
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: TS 0
[i] Recv RXTUNE cmd
[i] Recv TXTUNE cmd
[i] Recv POWERON CMD
[i] Starting transceiver...
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4a000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xe0024
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x37ffe7
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1b0005
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff530020
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xcff6d
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x7ffc8
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffbeff95
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x65000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb20072
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x16ffc9
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff5fff1
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffc400bb
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xcffdd
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffdcffcb
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb2fff5
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd5ffc4
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x38fff2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcf0000
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xbb0069
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x12ffcc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb6001f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd7001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x14004c
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffa6ffe8
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xa002a
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff76003f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff96ffd3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x130013
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd5ffe3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff8c0075
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff0000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xdffee
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff40011
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1afff9
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff9aff5d
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff9afffa
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x7ffce
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcb0008
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff7ffdd
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x5a005e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x38ffca
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x6ffa2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4ffcc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffba00ab
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff420029
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1effe2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x70067
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1a001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1a0016
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xb00a5
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffbe0008
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffe6001a
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcfffc3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x130003
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffceff44
</pre> OsmocomBB SDR PHY - Bug #3425 (Stalled): Receiver: missing AGC (Automatic Gain Control)https://osmocom.org/issues/34252018-07-26T20:25:52Zfixeria
<p>When the signal becomes too strong, we need to decrease the gain to avoid saturation.<br />When the signal becomes less powerful, we need to increase the gain...</p> OsmocomBB SDR PHY - Feature #3424 (Stalled): Transceiver: implement automatic TX delay measurementhttps://osmocom.org/issues/34242018-07-26T20:22:05Zfixeria
<p>As we all know, the world is not perfect, and there is some delay on the TX path of SDR devices.<br />At the moment, we know that for USRP B2X0 this delay is constant, so we take it into account.</p>
<p>But since we are going to extend the hardware compatibility, it makes sense to implement<br />some automatic measurement of delay for a particular device.</p> OsmocomBB SDR PHY - Feature #3423 (Stalled): Receiver: hard-coded GSM 05.02 channel configurationhttps://osmocom.org/issues/34232018-07-26T20:15:46Zfixeria
<p>Unlike <a class="wiki-page" href="https://osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>, it's impossible to configure the desired channel configuration.<br />Please see GSM 05.02, section 6.4 "Permitted channel combinations".</p>
<p>In order to reduce the recourse consumption, it makes sense to implement some API,<br />which would allow both initial and dynamic timeslot configuration...</p> OsmocomBB SDR PHY - Bug #3422 (Stalled): Receiver: sample / burst buffering problemhttps://osmocom.org/issues/34222018-07-26T20:08:47Zfixeria
<p>The problem appears when one stops the flow-graph, changes some parameters (e.g. freq.) and starts it again.<br />As soon as the flow-graph is started, Receiver block will still output some bursts from the past for some time.</p>
<p>Please note that <strong>I just assume</strong> that this is a problem of Receiver block.<br />It might be also a problem of any other block(s), such as 'TRX Interface'.</p>