Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-02-24T07:00:58ZOpen Source Mobile Communications
Redmine libosmo-abis - Bug #6375 (In Progress): default TCP user timeout is way too lowhttps://projects.osmocom.org/issues/63752024-02-24T07:00:58Zlaforge
<p>The default USERT_IMEOUT for TCP keep-alive (which is active by default) should have been:</p>
<pre><code>val = 1000 * line->keepalive_num_probes * line->keepalive_probe_interval + line->keepalive_idle_timeout;</code></pre>
<p>Which should have been 1000 * 10 * 3 + 30 which expands to roughly 30 seconds.</p>
<p>However, I guess there's two bugs in the code, looking at it:</p>
<ol>
<li>there should have been parenthesis around the + operator (line->keepalive_probe_interval + line->keepalive_idle_timeout) as the keepalive_idle_timeout is in seconds, not milli-seconds.</li>
<li>in the default case, all those values are configured to -1 (E1INP_USE_DEFAULT). This means we're using <code>1000 * -1 * -1 + -1 = 999</code>, i.e. just below aq second which clearly is not enough for a lossy satellite back-haul.</li>
</ol>
<p>This is actaully rather critical, a proposed untested fix is in <a class="external" href="https://gerrit.osmocom.org/c/libosmo-abis/+/36079">https://gerrit.osmocom.org/c/libosmo-abis/+/36079</a></p> Cellular Network Infrastructure - Bug #6349 (Feedback): example configs missing in release tarballshttps://projects.osmocom.org/issues/63492024-01-28T15:42:07Zfixeria
<p>Today I created a release <code>osmo-bts v1.7.2</code> package for Arch Linux:</p>
<p><a class="external" href="https://aur.archlinux.org/packages/osmo-bts">https://aur.archlinux.org/packages/osmo-bts</a><br /><a class="external" href="https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=osmo-bts">https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=osmo-bts</a></p>
<p>which downloads, unpacks, and builds the latest release tarball:</p>
<p><a class="external" href="https://downloads.osmocom.org/releases/osmo-bts/osmo-bts-1.7.2.tar.bz2">https://downloads.osmocom.org/releases/osmo-bts/osmo-bts-1.7.2.tar.bz2</a></p>
<p>Unfortunately, I am hitting a build error when running <code>makepkg</code>:</p>
<pre>
Making all in doc
make[2]: Entering directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc'
Making all in examples
make[3]: Entering directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc/examples'
make[3]: *** No rule to make target 'trx/osmo-bts-trx.cfg', needed by 'all-am'. Stop.
make[3]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc/examples'
make[2]: *** [Makefile:387: all-recursive] Error 1
make[2]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc'
make[1]: *** [Makefile:446: all-recursive] Error 1
make[1]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2'
make: *** [Makefile:378: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
</pre>
<p>The problem can be reproduced by downloading and building the tarball manually (make sure to build with <code>--enable-trx</code>).</p>
<p>Surprisingly, <code>trx/osmo-bts-trx.cfg</code> is not present in the release tarball:</p>
<pre>
$ tar -tvf osmo-bts-1.7.2.tar.bz2 | grep doc/examples
drwxr-xr-x 1000/1000 0 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/
-rw-r--r-- 1000/1000 23617 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/Makefile.in
drwxr-xr-x 1000/1000 0 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/virtual/
-rw-r--r-- 1000/1000 1271 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/virtual/osmo-bts-virtual.cfg
-rw-r--r-- 1000/1000 1501 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/Makefile.am
</pre>
<p>I believe the problem is that in <code>doc/examples/Makefile.am</code> we add config files to <code>EXTRA_DIST</code> conditionally:</p>
<pre><code class="shell syntaxhl"><span class="k">if </span>ENABLE_TRX
doc_trxdir <span class="o">=</span> <span class="si">$(</span>docdir<span class="si">)</span>/examples/osmo-bts-trx
doc_trx_DATA <span class="o">=</span> <span class="se">\</span>
trx/osmo-bts-trx.cfg <span class="se">\</span>
trx/osmo-bts-trx-calypso.cfg
EXTRA_DIST +<span class="o">=</span> <span class="si">$(</span>doc_trx_DATA<span class="si">)</span>
OSMOCONF_FILES +<span class="o">=</span> trx/osmo-bts-trx.cfg
endif
</code></pre>
<p>So if the project is configured without <code>--enable-foo</code>, then <code>make dist-bzip2</code> will produce a tarball without those files added conditionally.</p> OsmoSGSN - Bug #6197 (Feedback): "Cannot handle SM for unknown MM CTX"https://projects.osmocom.org/issues/61972023-09-28T14:32:29Zfixeria
<p>I am observing relatively long PDP Context activation with Sony Ericsson K800i and recent osmo-sgsn:</p>
<p>osmo-sgsn 1.11.0<br />osmo-pcu 1.3.1.1-c1b0</p>
<p>I don't remember if this was the case before, most likely not.</p>
<p>As can be seen from the attached PCAP, the MS orders a PDP Context activation right after completing the Attach (frame 259):</p>
<pre>
130 16.160906108 127.0.0.1 → 127.0.0.1 GPRS-LLC 107 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Attach Request
156 16.161190149 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Identity Request
157 16.797408334 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Response
173 16.797533278 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Request
181 17.200282825 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Identity Response
226 17.225222456 127.0.0.1 → 127.0.0.1 GPRS-LLC 113 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Attach Accept
239 17.697504097 127.0.0.1 → 127.0.0.1 GPRS-LLC 77 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 3(DTAP) (GMM) Attach Complete
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request <-- (!)
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request <-- (!)
</pre>
<p>The SGSN is responding with GMM Detach Request (frame 275), here is the related logging:</p>
<pre>
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request
260 17.739109847 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
261 17.739128332 127.0.0.1 → 127.0.5.1 GSMTAP 263 GPRS-NS2-VC(UDP-NSE00101-NSVC00101-0_0_0_0:23000-127_0_0_1:23023)[0x55e69ba253d0]{UNBLOCKED}: Received Event RX-UNITDATA
262 17.739139873 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
263 17.739148439 127.0.0.1 → 127.0.5.1 GSMTAP 183 BSSGP TLLI=0x85c79efb Rx UPLINK-UNITDATA
264 17.739181411 127.0.0.1 → 127.0.5.1 GSMTAP 236 LLME(ffffffff/85c79efb){UNASSIGNED} LLC RX: unknown TLLI 0x85c79efb, creating LLME on the fly
265 17.739188394 127.0.0.1 → 127.0.5.1 GSMTAP 193 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x3ef88c
266 17.739193033 127.0.0.1 → 127.0.5.1 GSMTAP 149 CMD=UI
267 17.739196720 127.0.0.1 → 127.0.5.1 GSMTAP 147 DATA
268 17.739200627 127.0.0.1 → 127.0.5.1 GSMTAP 143
269 17.739212048 127.0.0.1 → 127.0.5.1 GSMTAP 214 LLME(ffffffff/85c79efb){UNASSIGNED} Cannot handle SM for unknown MM CTX
270 17.739224792 127.0.0.1 → 127.0.5.1 GSMTAP 198 LLME(ffffffff/85c79efb){UNASSIGNED} LLGM Reset (SAPI=1)
271 17.739243207 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
272 17.739252294 127.0.0.1 → 127.0.5.1 GSMTAP 215 <- GMM DETACH REQ (type: re-attach required, cause: Implicitly detached)
273 17.739257293 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request
</pre>
<p>The MS repeats the request again (frame 517) 30 seconds after the first attempt, and finally gets a PDP Context activated.<br />The key difference between frames 259 (first attempt) and 517 (second attempt) is TLLI indicated in the BSSGP header.</p> OsmocomBB - Feature #6132 (New): Add MS_GPRS_Tests to osmo-ttcn3-hackshttps://projects.osmocom.org/issues/61322023-08-02T18:18:57Zpespin
<p>It would be really great to have something similar to existing TTCN3 PCU_Tests, testing RLC/MAC, but for the MS side, using the "modem" app.</p> OsmoBSC - Bug #6019 (New): "PCU version PCU socket has LOST connection connected"https://projects.osmocom.org/issues/60192023-04-28T12:17:03Zfixeria
<p>This is what I see in the output of <code>show bts</code> command:</p>
<pre>
OsmoBSC> show bts 0
BTS 0 is of osmo-bts type in band GSM900, has CI 0 LAC 1, BSIC 63 (NCC=7, BCC=7) and 1 TRX
Description: (null)
ARFCNs: 85
PCU version PCU socket has LOST connection connected
...
</pre>
<p>what means that somehow <code>bts->pcu_version[]</code> contains <code>PCU socket has LOST connection</code>. I am also seeing this in logging:</p>
<pre>
апр 28 19:14:07 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version 1.2.0.31-33a1bf3
...
апр 28 19:14:10 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version PCU socket has LOST connection
</pre>
<p>This looks a bit confusing, maybe we should just say "PCU state"?</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://projects.osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://projects.osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> Cellular Network Infrastructure - Bug #5749 (New): configure.ac: default CFLAGS, LT_INIT adds "-g...https://projects.osmocom.org/issues/57492022-11-08T18:04:34Zfixeria
<p>Today I spent quite some time trying to figure out why am I seeing <code>-g -O2</code> present in <code>CFLAGS</code> by default when building some projects. As it turned out, it's the <code>LT_INIT</code> (called in <code>configure.ac</code>) adding <code>-g -O2</code> to <code>CFLAGS</code> if they're empty. I could not find anything in documentation describing this behavior. The problem is that this behavior is inconsistent across the Osmocom projects: for some you get empty CFLAGS by default, for some you get <code>CFLAGS=-g -O2</code>. Most likely this inconsistency was introduced when we started to specify the <code>-std=gnu11</code> explicitly: in some projects (e.g. libosmocore.git, libosmo-abis.git, osmo-bsc) we set <code>CFLAGS</code> before calling the <code>LT_INIT</code>, in some (osmo-hlr, osmo-iuh, osmo-sgsn) after.</p>
<p>We need to decide on whether we want to have empty <code>CFLAGS</code> or <code>CFLAGS=-g -O2</code> set by default. Personally I prefer the former approach, because explicit is better then implicit. <a class="user active" href="https://projects.osmocom.org/users/52">Hoernchen</a> also prefers the former and does not want "magical flags out of nowhere". Either way, the default behavior should be consistent across all Osmocom projects. <a class="user active" href="https://projects.osmocom.org/users/7">laforge</a> what do you think?</p> Core testing infrastructure - Bug #5665 (Stalled): ERROR: files left in build directory after dis...https://projects.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> libosmocore - Bug #5570 (New): coding: decode in-band data in AMR's special DTX frames (SID_FIRST...https://projects.osmocom.org/issues/55702022-05-21T14:21:38Zfixeria
<p>Whenever gsm0503_tch_a[fh]s_decode_dtx() detects a special AMR's DTX frame (e.g SID_FIRST, SID_UPDATE, SID_ONSET) it immediately jumps out and ignores the coded in-band data (CMI, CMC/CMR). A hard-coded default value=0 is assigned instead of the actual value(s) indicated by the MS. This basically breaks rate adaptation when DTXu is employed.</p> OsmoTRX - Feature #5283 (New): Implement TRXDv2 supporthttps://projects.osmocom.org/issues/52832021-10-27T22:35:37Zfixeria
<p>At the moment, only TRXDv0 and TRXDv1 are supported. Given that osmo-bts-trx does support TRXDv2, it would be nice to have it in osmo-trx too.</p> OsmoBTS - Bug #5242 (Stalled): A-bis/RSL: CRCX ACK indicates '0.0.0.0' as the local/bind addresshttps://projects.osmocom.org/issues/52422021-09-30T09:25:47Zfixeria
<p>Currently both TC_speech_rtp_tchf and TC_speech_rtp_tchh fail, because CRCX ACK from osmo-bts indicates '0.0.0.0' as the local/bind address. The local/bind address of osmo-bts is needed in order to know where to send RTP packets for the RTP_Emulation component, and of course '0.0.0.0' cannot be used as the remote address for send(). See the attached PCAP file.</p> libosmocore - Bug #4993 (New): gsm_septets2octets: warning: use of NULL ‘rdata’ where non-null ex...https://projects.osmocom.org/issues/49932021-01-29T20:49:14Zlaforge
<p>When using gcc-10 with "-fanalyzer", we get the following report:</p>
<pre>
gsm_utils.c: In function ‘gsm_septets2octets’:
gsm_utils.c:340:3: warning: use of NULL ‘rdata’ where non-null expected [CWE-690] [-Wanalyzer-null-argument]
340 | memcpy(data, rdata, septet_len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
‘gsm_7bit_encode_n’: events 1-3
|
| 378 | int gsm_7bit_encode_n(uint8_t *result, size_t n, const char *data, int *octets)
| | ^~~~~~~~~~~~~~~~~
| | |
| | (1) entry to ‘gsm_7bit_encode_n’
|......
| 385 | uint8_t *rdata = calloc(strlen(data) * 2, sizeof(uint8_t));
| | ~~~~~~~~~~~~
| | |
| | (2) allocated here
| 386 | y = gsm_septet_encode(rdata, data);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (3) calling ‘gsm_septet_encode’ from ‘gsm_7bit_encode_n’
|
+--> ‘gsm_septet_encode’: events 4-8
|
| 292 | int gsm_septet_encode(uint8_t *result, const char *data)
| | ^~~~~~~~~~~~~~~~~
| | |
| | (4) entry to ‘gsm_septet_encode’
|......
| 296 | for (i = 0; i < strlen(data); i++) {
| | ~~~ ~~~~~~~~~~~~
| | | |
| | | (5) following ‘false’ branch (when ‘data’ is non-NULL)...
| | | (6) ...to here
| | (7) following ‘false’ branch...
|......
| 318 | return y;
| | ~
| | |
| | (8) ...to here
|
<------+
|
‘gsm_7bit_encode_n’: events 9-10
|
| 386 | y = gsm_septet_encode(rdata, data);
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (9) returning to ‘gsm_7bit_encode_n’ from ‘gsm_septet_encode’
|......
| 396 | o = gsm_septets2octets(result, rdata, y, 0);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (10) calling ‘gsm_septets2octets’ from ‘gsm_7bit_encode_n’
|
+--> ‘gsm_septets2octets’: events 11-19
|
| 327 | int gsm_septets2octets(uint8_t *result, const uint8_t *rdata, uint8_t septet_len, uint8_t padding)
| | ^~~~~~~~~~~~~~~~~~
| | |
| | (11) entry to ‘gsm_septets2octets’
|......
| 334 | if (padding) {
| | ~
| | |
| | (12) following ‘false’ branch (when ‘padding == 0’)...
|......
| 340 | memcpy(data, rdata, septet_len);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (13) ...to here
| | (14) following ‘false’ branch (when ‘data’ is non-NULL)...
| | (15) ...to here
| | (16) assuming ‘rdata’ is NULL
| | (17) following ‘true’ branch (when ‘rdata’ is NULL)...
| | (18) ...to here
| | (19) argument 2 (‘rdata’) NULL where non-null expected
|
In file included from ../../include/osmocom/core/utils.h:6,
from gsm_utils.c:82:
/usr/include/string.h:43:14: note: argument 2 of ‘memcpy’ must be non-null
</pre>
<p>There's also a couple of others in that file:<br /><pre>
gsm_utils.c:340:3: warning: use of NULL ‘data’ where non-null expected [CWE-690] [-Wanalyzer-null-argument]
gsm_utils.c: In function ‘gsm_7bit_encode_n’:
gsm_utils.c:401:2: warning: double-‘free’ of ‘rdata’ [CWE-415] [-Wanalyzer-double-free]
gsm_utils.c:369:9: warning: leak of ‘rdata’ [CWE-401] [-Wanalyzer-malloc-leak]
</pre></p> OsmoPCU - Bug #4879 (Stalled): endless pdch.cpp:809 Got CS-N RLC block: R=0, SI=0, TFI=0, CPS=0, ...https://projects.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://projects.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> OsmocomBB - Bug #4798 (Feedback): fake_trx send TRXC responses from wrong source addresshttps://projects.osmocom.org/issues/47982020-10-11T15:59:10Zlaforge
<p>I'm starting fake_trx.py like this:<br /><pre>
./fake_trx.py -R 127.0.0.21 -r 127.0.0.21 --trx TRX1@127.0.0.21:5700/1 --trx TRX2@127.0.0.21:5700/2 --trx TRX3@127.0.0.21:5700/3
</pre></p>
<p>And then osmo-bts-trx is sending TRXC commands from 127.0.0.20 to 127.0.0.21, and fake_trx.py responds. However, the response originates from 127.0.0.1 instead of the 127.0.0.21 that was configured.</p>
<p>Subsequently, osmo-bts-trx rejects those UDP responses as (presumably) the socket is fully connected and hence only accepts packets with correct source ip+port.</p>
<p><img src="https://projects.osmocom.org/attachments/download/4309/fake_trx_wrong_source.png" alt="" /></p>
<p>pcap file attached.</p> OsmoBTS - Bug #4771 (Stalled): Don't log NOTICE messages on missing uplink burstshttps://projects.osmocom.org/issues/47712020-10-01T12:05:51Zlaforgelibosmocore - Bug #4731 (Stalled): LAPDm does not implement SAPI priorities between data link layershttps://projects.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> Cellular Network Infrastructure - Feature #3628 (New): document nanoBTS calibration procedure usi...https://projects.osmocom.org/issues/36282018-10-04T11:13:31Zlaforge
<p>The nanoBTS has the capability to OCXO calibration against another (macro) BTS. We had implemented this in ipaccess-config, but we apparently never documented how it works.</p>
<p>Let's add it somewhere to the nanoBTS related wiki pages.</p>
<p>Without trying, I remember that it was part of the "Tests" that can be triggered via OML.</p>
<pre>
static const struct value_string test_names[] = {
»·······{ NM_IPACC_TESTNO_CHAN_USAGE, "Channel Usage" },
»·······{ NM_IPACC_TESTNO_BCCH_CHAN_USAGE, "BCCH Channel Usage" },
»·······{ NM_IPACC_TESTNO_FREQ_SYNC, "Frequency Synchronization" },
»·······{ NM_IPACC_TESTNO_BCCH_INFO, "BCCH Info" },
»·······{ NM_IPACC_TESTNO_TX_BEACON, "Transmit Beacon" },
»·······{ NM_IPACC_TESTNO_SYSINFO_MONITOR, "System Info Monitor" },
»·······{ NM_IPACC_TESTNO_BCCCH_MONITOR, "BCCH Monitor" },
</pre>
<p>I think you start with a CHAN_USAGE to see the receive level per ARFCN. You then proceed to a FREQ_SYNC to see which of those have a FCCH (and hence are BCCH/CCCH carrying).</p> libosmocore - Feature #3522 (New): libosmocoding: move TCH ordering functions to libosmocodec and...https://projects.osmocom.org/issues/35222018-09-04T20:49:08Zfixeria
<p>The GSM 05.03 implementation present in libosmocoding is using the RTP speech frame format for TCH coding functions. It is implemented in a way of performing 'canonical -> RTP' bit reordering in decoding functions, and 'RTP -> canonical' bit reordering in encoding functions. At the moment, the RTP format bit reordering implementation is not exposed.</p>
<p>This API could be used by some other projects (at least by osmo-gapk), moreover libosmocoding is already being linked against libosmocodec.</p> libosmocore - Feature #3521 (New): core/utils: engineering notation helpershttps://projects.osmocom.org/issues/35212018-09-04T20:32:52Zfixeria
<p>It would be great to have some auxiliary API to parse numbers written in the engineering notation (e.g. 945.6M, -33k) to the regular numbers (float?), and, vice versa, the regular numbers to engineering notation. This is useful in the cases where a user should provide some input, such as frequency (e.g. in osmo-arfcn) or sample rate.</p>
<p>Inspired by GNU Radio: <a class="external" href="https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py">https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py</a></p>
<p>If this feature also looks useful for others, I would implement it.</p> GSM Audio Pocket Knife - Bug #3398 (New): build: configure fails if (optional) libalsa wasn't foundhttps://projects.osmocom.org/issues/33982018-07-16T20:45:23Zfixeria
<p>ALSA is optional dependency, which is only required for audio capture and playback.<br />We should not enforce this optional dependency as a mandatory one.</p> Cellular Network Infrastructure - Feature #3142 (New): Further simplification of "NITB like" setupshttps://projects.osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</p> GSM Audio Pocket Knife - Bug #2514 (Stalled): GSM HR encoding result does not match the referencehttps://projects.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> OsmocomBB - Feature #2409 (Stalled): Add GPRS support to virt_phy and L1CTLhttps://projects.osmocom.org/issues/24092017-07-29T12:31:13Zlaforge
<p>It should be rather simple to add GPRS support to virt_phy. The more interesting question is how to strucutre the L1CTL interface.</p>
It could simply
<ul>
<li>get configuration as to which timeslots are relevant to UL/DL TBFs via L1CTL</li>
<li>forward all downlink blocks on any of the related timeslots via L1CTL</li>
<li>transmit uplink blocks as instructed by L1CTL</li>
</ul>
<p>However, the uplink transmission can be either static, dynamic or extended dynamic allocation. In the dynamic cases, uplink is transmitted whenever the USF of the current downlink block matches the USF of the TBF. This has rather tight timing, as there's only the "3 timeslot" shift between DL and UL.</p>
<p>If this is critical, the L1 (virt_phy in this case) would have to be tightly integrated with the MAC layer in order to decode the USF of the MAC header. Given the USF is the three LSB of every first octet of each downlink block, it should be rather simple to match on that.</p>
<p>Let's investigate what the 3GPP specs have in mind in terms of a L1-SAP between L1 and the MAC layer in GPRS.</p> OsmoMSC - Feature #1597 (Stalled): External interface for USSDhttps://projects.osmocom.org/issues/15972016-02-23T15:52:03Zlaforge
<p>we already have SMPP for SMS, but don't have similar functionality for USSD, i.e. a way in which external applications can exchange USSD with MSs.</p>
<p>There are some provisions for USSD in SMPP, but I think they don't really appreciate the session-oriented nature of USSD.</p>
<p>In either case, I'm not aware of any standard to hand USSD to external applications. Of course there's MAP, but nobody wants to implement that in an external application...</p> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://projects.osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p> OsmoPCU - Feature #1545 (Stalled): continuous timing advance loop using PTCCHhttps://projects.osmocom.org/issues/15452016-02-23T15:02:54Zlaforge
<p>We currently only implement the "initial TA" where the TA of a MS is determined at time the TBF is established. If the MS moves more than 1 TA during a TBF being active, this leads to problems.</p>
GPRS has the PTCCH for this, a special channel in the PDCH channel combination multiplex, using which we can instruct a sub-set of 16 MS (whether TBFs are active or not) to adjust their timing advance continuously. What needs to be done is
<ul>
<li>code to generate the PTCCH/D messages</li>
<li>code to parse the PTCCH/U messages</li>
<li>code to determine which 16 MS will be part of the current PTCCH subset</li>
<li>unit tests for the above</li>
</ul>
<p>We also need to see how we can test this with actual hardware, in a way that TA exists (and changes) over time. Unfortuantely we don't have a MS-side GPRS implementation for OsmocomBB, because then we could simply artificially delay the transmit burst timing to make the network determine a higher TA.</p> OsmoPCU - Feature #1526 (Stalled): Acquire/update timing advance (TA)https://projects.osmocom.org/issues/15262016-02-22T20:59:31Zzecke
<p>Currently the TA is derived from the initial RACH request and never updated during the lifetime of a TBF.</p>
<p>Is this handled correctly for network initiated DL TBF establishment?</p>
<p>TS 44.018, 3.5.3.1.2 asks for TA determination on DL TBF establshment if the MS is idle and the TA is not known (see "If the network does not have a valid timing advance ...").</p>
<p>Other related issues:</p>
<ul>
<li>The burst timing info (qta) should be applied (see <a class="issue tracker-1 status-7 priority-3 priority-high3" title="Bug: re-integrate tracing + card reader modes into SIMtrace2 firmware (SAM3S) (Stalled)" href="https://projects.osmocom.org/issues/1705">#1705</a>)</li>
<li>Support access bursts on PDCH which can be requested by the PCU if the current TA is unknown (44.060)</li>
</ul> OsmocomBB - Feature #1461 (Stalled): include some version information / negotiation in the L1CTL ...https://projects.osmocom.org/issues/14612016-02-19T22:48:42Zlaforge
<p>The host software should have a way to determine the firmware build/version, as well as the enabled features (TX support or not, burst_ind, ...).</p>