Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-02-05T09:25:36ZOpen Source Mobile Communications
Redmine 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> 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> 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> OCTOI - Osmocom Community TDM over IP - Bug #5694 (Stalled): BERT testinghttps://osmocom.org/issues/56942022-10-01T06:59:48Zlaforge
<p>Soem initial tests with a PrTel93i doing BERT testing on a single B-channel indicates we have some problems to investigate.</p>
<p>This ticket serves as log of the various tests/attempts so far</p>
<ul>
<li>PrTel93i against same PrTel93i doing internal call through Auerswald COMmander2 PBX
<ul>
<li>0 errors in several 1min and 15min calls. So the PrTel and the wiring are good.</li>
</ul></li>
</ul>
<ul>
<li>PrTel93i against same PrTel93i doing external call through same PBX but going out via icE1usb to OCTOI hub and calling back through the same path:
<ul>
<li>first 1min call was with 0 errors</li>
<li>first 15min call was with 6.62 E-2 BER</li>
<li>second 15min call was with 5.92 E-2 BER</li>
<li>no lost / reordered OCTOI frames observed during that time</li>
</ul></li>
</ul>
<ul>
<li>PrTel93i against bchan_loop from capi-hacks (hfc-usb, mISDN, CAPI20) doing internal call through Auerswald COMmander2 PBX
<ul>
<li>1min call with 4.25 E-1 BER</li>
<li>so clearly there are some problems in the misdn/capi integration</li>
</ul></li>
</ul> 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> libosmo-abis - Feature #5691 (Stalled): Expose DAHDI statistics to prometheushttps://osmocom.org/issues/56912022-09-27T15:32:46Zlaforge
<p>The DAHDI_SPANSTAT ioctl can be used to obtain a number of statistics for a given span (E1/T1 line).</p>
<p>It would be a good idea to implement some library code which would start a timer to periodically poll the DAHDI_SPANSTAT on each of the relevant spans. This could be used by osmo-bsc, osmo-gbproxy or even a stand-alone application to pull all those counters into osmocom rate_ctr infrastructure.</p>
<p>That in turn would allow the counters to be exported alongside all our other counters/stats via the statsd exporter.</p> 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> 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> libosmocore - Feature #5034 (Stalled): logging: Enable category name instead of hex val by defaulthttps://osmocom.org/issues/50342021-02-18T18:06:59Zpespin
<p>Discussion started in this patch:<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/12095">https://gerrit.osmocom.org/c/libosmocore/+/12095</a></p>
<p>Summary/outcome:<br /><pre>
As a reference, I think it makes more sense to change it for all log targets this way:diff --git a/src/logging.c b/src/logging.c
index a40008e9..f878be5a 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -918,7 +918,8 @@ struct log_target *log_target_create(void)
target->use_color = 1;
target->print_timestamp = 0;
target->print_filename2 = LOG_FILENAME_PATH;
- target->print_category_hex = true;
+ target->print_category_hex = false;
+ target->print_category = true;
So here actually by default we disable the hex output and we enable the string representation. Once this is applied, some tests will need to be adapted since they may not set those fields explicitly and use default ones.
</pre></p>
Steps:
<ul>
<li>Apply change in libosmocore locally</li>
<li>Build other projects and see if a test in any projects fails. For each test failing, make sure to set explicit values for log_set_print_category{_hex} to match current expectancies.</li>
<li>Once those patches are merged, submit + merge libosmocore patch changing the default.</li>
</ul> libosmocore - Bug #4731 (Stalled): LAPDm does not implement SAPI priorities between data link layershttps://osmocom.org/issues/47312020-08-26T19:34:40Zlaforge
<p>AFAIR, The 3GPP specifications contain some very strict rules regarding priorities among different concurrent LAPDm data links for the same subscriber. For example, SAIP0 always has higher priority than SAPI3.</p>
<p>We've just encountered a situation where in MT-SMS, the SAPI3 SABM from BTS to MS was sent <strong>before</strong> the BTS replied with the UA for SAPI0 (contetion resolution procedure, where we echo the PAGING RESPONSE back to the MS).</p>
<p>A quick look at the LAPDm code in libosmocore reveals that it is doing a round-robin rather than implementing the rules.</p>
<p>TS 44.005 Section 4.2.2 states the priorities for SDCCH and SACCH. I guess we can think of FACCH == SDCCH in this context.</p> Core testing infrastructure - Feature #4692 (Stalled): finally implement testing of the actual vo...https://osmocom.org/issues/46922020-08-05T08:27:45Zlaforge
<p>For many years we've set up tons of testing, but it's all on the control plane, and the user plane for PS services. We don't yet have any testing of the acutal voice path, so we wouldn't detect codec problems drop-outs or whatever other voice quality issues in any of our testing.</p> Core testing infrastructure - Bug #4576 (Stalled): ttcn3-hlr-tests need to route multicast traffi...https://osmocom.org/issues/45762020-06-02T22:29:38Zneelsnhofmeyr@sysmocom.de
<p>The MSLookup tests in the ttcn3-hlr-test send out multicast-DNS queries,<br />and these should be answered by osmo-hlr running in the osmo-hlr-master container.</p>
<p>Running wireshark on the docker-hosting machine on 'any', the DNS queries are visible:</p>
<pre>
No. Time Arrival Time Source Source Port Destination Destination Port Info
102721 4919.259341 Jun 3, 2020 00:16:05.287612000 CEST 172.18.10.103 4266 239.192.23.42 4266 Standard query 0x5ca3 ANY sip.voice.491618327224.msisdn.mdns.osmocom.org
102722 4919.259341 Jun 3, 2020 00:16:05.287612000 CEST 172.18.10.103 4266 239.192.23.42 4266 Standard query 0x5ca3 ANY sip.voice.491618327224.msisdn.mdns.osmocom.org
</pre>
<p>Running tcpdump in the osmo-hlr-master container shows no such activity.</p>
<p>When running the osmo-mslookup-client commandline tool with the same query, osmo-hlr does receive it and responds in the way that the test expects it:</p>
<pre>
# osmo-mslookup-client sip.voice.262422543586245.imsi
query result last age v4_ip v4_port v6_ip v6_port
sip.voice.262422543586245.imsi result last 257 66.66.66.66 5060
</pre>
<p>But also, the tester does not receive that response<br />(as I found out by "infinitely" looping the MSLookup send and receive in HLR_Tests.ttcn).</p>
<p>I am not sure how <a class="user active" href="https://osmocom.org/users/301771">osmith</a> managed to test the MSLookup tests successfully,<br />there must be some way to get the multicast traffic to pass through the containers.</p> Ericsson RBS 6xxx - Support #4534 (Stalled): Take pictures of RBS6k gear for documentationhttps://osmocom.org/issues/45342020-05-05T18:27:31Zlaforge
In order to improve the wiki with pictures and to later on create documentation describing the various inter-connections etc., it would be great to have some<br />useful quality picturs of the RBS6k equipment, that is (primarily) at this point:
<ul>
<li>RRUS</li>
<li>RUS</li>
<li>DUG20</li>
<li>DUL20</li>
<li>RBS6601 (2U rack)</li>
</ul>
Focus should be on
<ul>
<li>any kind of connectors (RF, E1, Ethernet, etc.)</li>
<li>any kind of LEDs / buttons</li>
<li>anything else that might be relevant to the user.</li>
</ul>
<p>Please add the (basic cropped) pictures to the related wiki pages of the respective equipment here.</p> IMSI Pseudonymization - Feature #4476 (Stalled): OsmoHLR: support IMSI pseudo in location updatehttps://osmocom.org/issues/44762020-04-01T08:05:08Zosmith
Columns for subscriber_imsi_pseudo table (<a href="https://gerrit.osmocom.org/plugins/gitiles/imsi-pseudo#in-detail" class="external">reference</a>):
<ul>
<li>id</li>
<li>imsi</li>
<li>imsi_pseudo</li>
<li>imsi_pseudo_i</li>
</ul> IMSI Pseudonymization - Feature #4404 (Stalled): Research: Make sure that we can silently detach ...https://osmocom.org/issues/44042020-02-19T10:34:18Zosmith
<p>laforge wrote:</p>
<blockquote>
<p>neels wrote:</p>
<blockquote>
<p>The usefulness of the project seems to pivot on the visibility of the IMSI Detach.<br />If we can't omit the IMSI Detach message, then we either introduce an interruption in network service,<br />or we make it easy to correlate old and new IMSIs by time correlation of Detach and Attach.</p>
</blockquote>
<p>I doublt IMSI DETACH is used much in real-world networks these days as it is unauthenticated<br />and hence subject to spoofing.</p>
</blockquote>
<p>Here's a checklist to prove whether this works or not.</p> Distributed GSM - Feature #4306 (Stalled): GSUP proxy cache: store data persistentlyhttps://osmocom.org/issues/43062019-12-04T13:58:28Zneelsnhofmeyr@sysmocom.de
<p>when we store auth tuples (<a class="issue tracker-2 status-7 priority-1 priority-lowest" title="Feature: GSUP proxy: cache auth tuples to re-use / fall back to simpler auth methods (Stalled)" href="https://osmocom.org/issues/4305">#4305</a>), even a local power outage should retain those tuples in the proxy.</p>
<p>options:<br />- store in the HLR DB<br />- just dump to a local .csv file to recover on startup</p> Distributed GSM - Feature #4305 (Stalled): GSUP proxy: cache auth tuples to re-use / fall back to...https://osmocom.org/issues/43052019-12-04T13:56:41Zneelsnhofmeyr@sysmocom.de
<p>if a link goes away, we'd like to still allow continued operation for some time.</p>
<p>Goals:</p>
<p>- we don't want to replicate the auth keys themselves; just ask for tuples from the home HLR.<br />- for a later attach, assume the link to home hlr is broken.<br />- we have cached the previous auth tuples and attempt to re-use them.<br />- Maybe we have asked for N more tuples on auth tuple request.<br />- milenage sqn: use a separate SQN IND bucket for each site, so going back to a previous site will be fine with SQN number jumps.<br />- if that doesn't work, fall back to 2G auth if possible.<br />- if that doesn't work, fall back to no auth (for some time/during link failure, for continued service)</p> Cellular Network Infrastructure - Bug #4131 (Stalled): osmo-gsm-manuals: Use leveloffset attribut...https://osmocom.org/issues/41312019-07-26T13:04:49Zpespin
<p>Right now, all documents under osmo-gsm-manuals.git/commons/ start with title level 1 (==). However, if one wishes to add a document with level 2 (===) so it can also be included in other repository document, it will make osmo-gsm-manuals.git "make check" fail due to osmo-gsm-manuals/tests/Makefile.am:22:<br /><pre>
echo "include::$${chapter}[]" >> $@; \
</pre></p>
<p>Which includes stuff under a test document with level 0 (=). If a document with level different than 1 (==) is added, then it will fail on some versions (like jenkins):<br /><pre>
"asciidoc: WARNING: mgcp_extension_osmux.adoc: line 2: section title out of sequence: expected level 1, got level 2"
</pre></p>
<p>See for instance commit osmo-gsm-manuals.git 061cca4d7345bc4f496324d0b4d30bc51e1f8d23, which had to be fixed up later.</p>
<p>The solution here is to use "leveloffset" attribute. To make our life easier in the future, we need to move all documents under common/ to start with level 0 (=), and then use "leveloffset" on all includes in all other repositories using them. This way same document can easily be added on different levels on different documents.</p>
<p>Important! It seems this syntax doesn't work for me:<br /><pre>
include::chapter2.adoc[leveloffset=+1]
</pre></p>
<p>However, this does and it's basically the same:<br /><pre>
:leveloffset: 1
include::chapter1.adoc[]
:leveloffset: 0
</pre></p>
<p>Related information:<br /><a class="external" href="https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc">https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc</a><br /><a class="external" href="https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html">https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html</a><br /><a class="external" href="http://asciidoc.org/userguide.txt">http://asciidoc.org/userguide.txt</a></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> Cellular Network Infrastructure - Feature #4073 (Stalled): try to get counter and vty reference i...https://osmocom.org/issues/40732019-06-21T14:55:46Zlaforge
<p>The existing approach of extracting counter and vty information at runtime has various disadvantages. We'd like to explore options to generate this information from the source code. Whether that's using static code analysis, an existing C parser of some form, clang, ... doesn't really matter.</p>
<p>The goal is to generate the same textual (asciidoc for counters, xml for VTY) format as the existing 'runtime' approach.</p> Cellular Network Infrastructure - Feature #4006 (Stalled): TRX protocol: wind of changehttps://osmocom.org/issues/40062019-05-16T19:54:33Zfixeria
<p>We are using TRX protocol in <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki">OsmoBTS</a> in order to "speak" with transceiver (e.g. <a class="wiki-page" href="https://osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>, FakeTRX). Basically it defines three interfaces: clock for TDMA frame clock indications, control (we agreed to call it TRXC) for transceiver management, and data (TRXD) for exchanging Rx/Tx bursts. It was first introduced in <a href="http://openbts.org/" class="external">OpenBTS</a> project, from which we forked <a class="wiki-page" href="https://osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>. For more information, please see: <a class="external" href="https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager">https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager</a>.</p>
<p>The protocol is being used for years, and it still serves us for good. However, it is extremely inflexible. For example, there is no way to send more information about received bursts on TRXD interface, than the fixed-size header already has (TDMA frame number, timeslot number, RSSI, ToA256). On TRXC interface, which is working over UDP as the other ones, there is no way to distinguish command retransmission, which may happen due to timeout, from a regular command. There is no way to notify the L1 (i.e. <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki">OsmoBTS</a>) about some events (e.g. device has been disconnected), no way to indicate transceiver version, and so on...</p>
<p>During <a class="wiki-page" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019">OsmoDevCon2019</a> (and before too) we have been discussing the idea of introducing the new version of TRX protocol, which would allow us to solve the mentioned problems. In order to keep backwards compatibility, both L1 and transceiver would initially use the old TRX protocol, while the new version can be optionally enabled by sending a command on TRXC interface. If the transceiver does support the new protocol, it would acknowledge the command. Otherwise, the command is rejected, so L1 would continue to work in "backwards compatibility" mode.</p>
<p>Finally, we need to write a proper protocol description like we already have for GSUP in <a class="external" href="https://git.osmocom.org/osmo-gsm-manuals/">https://git.osmocom.org/osmo-gsm-manuals/</a>. But before starting to work on this, let's create some kind of a wish list - what would you like to see in the new version of TRX protocol?</p> libosmo-netif - Bug #3812 (Stalled): stream_test fails depending on where it is runhttps://osmocom.org/issues/38122019-02-21T15:18:52Zneelsnhofmeyr@sysmocom.de
<p><a class="user active" href="https://osmocom.org/users/119">msuraev</a>, your new stream_test fails for me.<br />On my home laptop sporadically, on my office box reliably.</p>
<pre>
1: stream_test FAILED (testsuite.at:8)
▶ cat tests/testsuite.dir/1/testsuite.log
# -*- compilation -*-
1. testsuite.at:4: testing stream_test ...
../../../src/libosmo-netif/tests/testsuite.at:8: $abs_top_builddir/tests/stream/stream_test
--- experr 2019-02-21 16:12:24.956776809 +0100
+++ /n/s/dev/make/libosmo-netif/tests/testsuite.dir/at-groups/1/stderr 2019-02-21 16:12:33.984665754 +0100
@@ -12,8 +12,7 @@
autoreconnecting test step 6 [client OK, server OK], FD reg 1
autoreconnecting test step 5 [client OK, server OK], FD reg 1
-[ CONNECTED] osmo_stream_cli_recv(): connection closed with srv
-[ NONE] osmo_stream_cli_reconnect(): retrying in 9 seconds...
+connection closed with srv
autoreconnecting test step 4 [client OK, server OK], FD reg 0
@@ -37,7 +36,6 @@
non-reconnecting test step 2 [client OK, server OK], FD reg 1
non-reconnecting test step 1 [client OK, server OK], FD reg 1
-[ CONNECTED] osmo_stream_cli_recv(): connection closed with srv
-[ NONE] osmo_stream_cli_reconnect(): not reconnecting, disabled.
+connection closed with srv
-non-reconnecting test step 0 [client OK, server OK], FD reg 0
+non-reconnecting test step 0 [client OK, server OK], FD reg 1
1. testsuite.at:4: 1. stream_test (testsuite.at:4): FAILED (testsuite.at:8)
</pre> Cellular Network Infrastructure - Feature #3699 (Stalled): merge Debian patcheshttps://osmocom.org/issues/36992018-11-19T13:41:54Zmsuraev
<p>There're numerous patches from Debian developers available via:<br /><a class="external" href="https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org">https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org</a><br />individual package links example:<br /><a class="external" href="https://sources.debian.org/patches/libosmo-sccp/0.10.0-2/">https://sources.debian.org/patches/libosmo-sccp/0.10.0-2/</a><br />Relevant package version could be obtained from the first link.</p>
<p>Some of those patches are Debian-specific while others are generally relevant fixes. We should go over all packaged projects and submit all relevant patches to gerrit for review.</p>
<p>Note: Debian seems to have the most recent versions packaged compared to other repositories according to repology - see for example<br /><a class="external" href="https://repology.org/metapackage/libosmocore/versions">https://repology.org/metapackage/libosmocore/versions</a></p> Misc Hardware Projects - Feature #3566 (Stalled): power supply / battery / charge for our GSM-R O...https://osmocom.org/issues/35662018-09-18T13:54:06Zroh
figure out a pinout/spec for these 2 kinds of devices:
<ul>
<li>sagem NNG OPS 940
<ul>
<li>pogopins from device to battery</li>
<li>ericcson style flat connector row on bottom end</li>
<li>3.6V 2.3Ah li-ion battery</li>
</ul></li>
</ul>
<ul>
<li>timba tec pocket pc
<ul>
<li>5V DC 2.4A label</li>
<li>3.7V 4Ah li-ion battery</li>
</ul></li>
</ul> libosmo-ranap - Bug #3420 (Stalled): ranap_transp_assoc_decode() decodes X.213 NSAP address heade...https://osmocom.org/issues/34202018-07-26T13:51:46Zneelsnhofmeyr@sysmocom.de
<p>The SysmoCell5000 series sends RAB-AssignmentResponse with X.213 NSAP addresses, which get parsed by ranap_transp_assoc_decode().<br />These contain a three byte header followed by the IP address, typically it is 0x350001 followed by the Ipv4 address in hex.</p>
<p>ranap_transp_assoc_decode() however starts at the header and decodes as 53.0.1.N where N is the first octet of the actual IPv4 address, e.g. 192.<br />Hence switching RTP streams to the cell fails, since obviously 53.0.1.192 is not the correct IP address.</p>
<p>a) fix the check for the address length, should be len == 7, not len > 7.</p>
<p>b) generally be stricter about the lengths.</p> Cellular Network Infrastructure - Feature #2604 (Stalled): GSUP-to-DIAMETER converter / IWFhttps://osmocom.org/issues/26042017-10-29T23:01:06Zlaforge
<p>In order to support a single subscriber database for 2G/3G and LTE, operators normally use a single HSS. HSS is the EPC successor of the LTE.</p>
<p>Instead of MAP over SS7, HSS's speak DIAMETER over SCTP or TCP (with optional TLS). The types of procedures / transactions are pretty much the same as before, but the encoding and the protocol changed completely.</p>
<p>There are a couple of (at least minimal) HSS implementations out there, from freeDiameter to nextepc, to name some examples.</p>
<p>If we were to implement a converter between GSUP and DIAMETER, then the OsmoMSC and OsmoSGSN could access an external HSS - and that same HSS could be accessed from nextepc or even openair-cn for LTE access.</p>
<p>3GPP TS 29.305 specifies the MAP-to-DIAMETeR InterWorkingFunction (IWF), which is pretty much the same device, with the exception that we'd use GSUP instead of MAP.</p> Cellular Network Infrastructure - Feature #2558 (Stalled): Scripts to manage thousands of "mobile...https://osmocom.org/issues/25582017-10-06T14:53:38Zlaforge
<p>The goal here is to be able to run a network with hundreds of BTSs, several hundreds of TRXs and thousands of MSs from a single command, in order to perform load testing against OsmoBSC.</p>
<p>The scripts should make sure all related processes are started reliably, their termination is recorded, and somehow their result / error / logging is aggregated and reported.</p> GSM Audio Pocket Knife - Bug #2514 (Stalled): GSM HR encoding result does not match the referencehttps://osmocom.org/issues/25142017-09-15T14:39:13Zfixeria
<p>Implementing the automake transcoding tests, I found that GSM HR related<br />encoding tests are always fail, while decoding from the reference files<br />is ok.</p>
<p>Regression tests summary:</p>
<pre><code>1: procqueue ok<br /> 2: io/pq_file ok<br /> 3: io/pq_rtp ok<br /> 4: conv/enc/amr_efr ok<br /> 5: conv/enc/gsm ok<br /> 6: conv/enc/racal_hr FAILED (testsuite.at:49)<br /> 7: conv/enc/racal_fr ok<br /> 8: conv/enc/racal_efr ok<br /> 9: conv/enc/ti_hr FAILED (testsuite.at:79)<br /> 10: conv/enc/ti_fr ok<br /> 11: conv/enc/ti_efr ok<br /> 12: conv/enc/rtp_efr ok<br /> 13: conv/enc/rtp_hr_etsi FAILED (testsuite.at:119)<br /> 14: conv/enc/rtp_hr_ietf FAILED (testsuite.at:129)<br /> 15: conv/dec/amr_efr ok<br /> 16: conv/dec/gsm ok<br /> 17: conv/dec/racal_hr ok<br /> 18: conv/dec/racal_fr ok<br /> 19: conv/dec/racal_efr ok<br /> 20: conv/dec/ti_hr ok<br /> 21: conv/dec/ti_fr ok<br /> 22: conv/dec/ti_efr ok<br /> 23: conv/dec/rtp_efr ok<br /> 24: conv/dec/rtp_hr_etsi ok<br /> 25: conv/dec/rtp_hr_ietf ok</code></pre>
<p>The same problem can be discovered using the built-in shell<br />script named 'test_all_formats.sh'.</p>
<p>I have also attempted to compare the encoding results with<br />the reference files and found, that the mismatching bytes are<br />starting from 128th until 352 bytes.</p>