Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-10-20T19:48:41ZOpen Source Mobile Communications
Redmine osmo-ccid-firmware - Bug #4822 (Stalled): sysmoOCTSIM with osmo-ccid-firmware sometimes fails to ...https://osmocom.org/issues/48222020-10-20T19:48:41Zlaforge
<p>I've never had this before, for many months. However, with recent firmware (0.2.48) I've observed this:<br /><pre>
[179007.559048] usb 1-4.4.3: new full-speed USB device number 32 using xhci_hcd
[179007.639242] usb 1-4.4.3: device descriptor read/64, error -32
[179007.827237] usb 1-4.4.3: device descriptor read/64, error -32
[179008.015187] usb 1-4.4.3: new full-speed USB device number 33 using xhci_hcd
[179008.095235] usb 1-4.4.3: device descriptor read/64, error -32
[179008.283233] usb 1-4.4.3: device descriptor read/64, error -32
[179008.391179] usb 1-4.4-port3: attempt power cycle
[179008.995200] usb 1-4.4.3: new full-speed USB device number 34 using xhci_hcd
[179008.995416] usb 1-4.4.3: Device not responding to setup address.
[179009.203351] usb 1-4.4.3: Device not responding to setup address.
[179009.411047] usb 1-4.4.3: device not accepting address 34, error -71
[179009.491114] usb 1-4.4.3: new full-speed USB device number 35 using xhci_hcd
[179009.491311] usb 1-4.4.3: Device not responding to setup address.
[179009.699411] usb 1-4.4.3: Device not responding to setup address.
[179009.907037] usb 1-4.4.3: device not accepting address 35, error -71
[179009.907219] usb 1-4.4-port3: unable to enumerate USB device
[179039.515037] usb 1-4.4.3: new full-speed USB device number 36 using xhci_hcd
[179039.595097] usb 1-4.4.3: device descriptor read/64, error -32
[179039.782880] usb 1-4.4.3: device descriptor read/64, error -32
[179039.971039] usb 1-4.4.3: new full-speed USB device number 37 using xhci_hcd
[179040.051067] usb 1-4.4.3: device descriptor read/64, error -32
[179040.239072] usb 1-4.4.3: device descriptor read/64, error -32
[179040.347191] usb 1-4.4-port3: attempt power cycle
[179040.954828] usb 1-4.4.3: new full-speed USB device number 38 using xhci_hcd
[179040.954974] usb 1-4.4.3: Device not responding to setup address.
[179041.167074] usb 1-4.4.3: Device not responding to setup address.
[179041.374849] usb 1-4.4.3: device not accepting address 38, error -71
[179041.454915] usb 1-4.4.3: new full-speed USB device number 39 using xhci_hcd
[179041.455125] usb 1-4.4.3: Device not responding to setup address.
[179041.667065] usb 1-4.4.3: Device not responding to setup address.
[179041.879032] usb 1-4.4.3: device not accepting address 39, error -71
[179041.879256] usb 1-4.4-port3: unable to enumerate USB device
</pre></p>
<p>twice in a row while attaching the same sysmoOCTSIM using the same cable attached to the same USB hub, ... that has litrally worked hundreds of times before.</p>
<p>As sysmocom also received a similar report on raspi a few days ago, there may be something wrong.</p>
<p>I removed one SIM card and re-plugged it, and it worked. Unforunately it currently also works with that SIM card re-inserted. Weird.</p> 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> OsmoTRX - Feature #4362 (Stalled): osmo-trx-lms: Support multi-arfcn featurehttps://osmocom.org/issues/43622020-01-13T17:04:18Zpespin
<p>According to [1], we cannot use the two channels of LimeSDR devices on different frequencies. However, we may still be able to serve several TRX using multi-arfcn feature in osmo-trx, by muxing them into the same physical channel.</p>
<p>[1] <a class="external" href="https://github.com/myriadrf/LimeSuite/issues/276">https://github.com/myriadrf/LimeSuite/issues/276</a></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> OsmoGSMTester - Bug #4151 (Stalled): osmo-gsm-tester: osmo-trx-lms process sometimes kept forever...https://osmocom.org/issues/41512019-08-14T09:56:49Zpespin
<p>It was spotted several times that all osmo-trx-lms tests in osmo-gsm-tester fail with message:<br /><pre>
socket.c:367 unable to bind socket:10.42.42.117:4237: Address already in use
</pre></p>
<p>Close lookup shows osmo-trx-lms stil running but idle (not consuming CPU):<br /><pre>
# ps -ef | grep osmo-trx-lms
root 14643 14604 0 11:47 pts/1 00:00:00 grep osmo-trx-lms
jenkins 55210 1 0 Aug06 ? 00:00:53 /osmo-gsm-tester-trx/last_run/osmo-trx/bin/osmo-trx-lms -C /osmo-gsm-tester-trx/last_run/osmo-trx.cfg
</pre></p>
<p>In order to get process creation time (too see which test caused the issue and if logs around it provide more information):<br /><pre>
# ls -ld --time-style=full-iso /proc/$(pidof osmo-trx-lms)
dr-xr-xr-x 9 jenkins jenkins 0 2019-08-06 10:37:14.274166715 +0200 /proc/55210
</pre></p>
<p>At that time, following run was in place:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod/1926/">https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod/1926/</a></p>
<p>And the test: <code>trial-1926 gprs:trx-lms+mod-bts0-numtrx2+mod-bts0-chanallocdescend cs_paging_gprs_active.py</code></p>
<p>The test runs and at some fails (expected since multi-trx is not yet supported in osmo-trx-lms) and then osmo-gsm-tester goes over regular procedure to kill all processes (in the case of osmo-trx-lms, it kills the ssh client, which should end up killing its child through the script handler):<br /><pre>
10:38:00.558825 --- ParallelTerminationStrategy: DBG: Scheduled to terminate 22 processes. [process.py:108]
10:38:00.560001 --- ParallelTerminationStrategy: DBG: Starting to kill with SIGTERM [process.py:116]
...
10:38:00.669914 run osmo-trx-lms(pid=1883): Terminating (SIGTERM) [trial-1926↪gprs:trx-lms+mod-bts0-numtrx2+mod-bts0-chanallocdescend↪osmo-bts-trx↪osmo-trx-lms↪osmo-trx-lms(pid=1883)] [process.py:236]
...
10:38:00.773158 --- ParallelTerminationStrategy: PID 1883 died... [process.py:75]
10:38:00.773706 run osmo-trx-lms(pid=1883): DBG: Cleanup [trial-1926↪gprs:trx-lms+mod-bts0-numtrx2+mod-bts0-chanallocdescend↪osmo-bts-trx↪osmo-trx-lms↪osmo-trx-lms(pid=1883)] [process.py:265]
10:38:00.776101 run osmo-trx-lms(pid=1883): Terminated {rc=36608} [trial-1926↪gprs:trx-lms+mod-bts0-numtrx2+mod-bts0-chanallocdescend↪osmo-bts-trx↪osmo-trx-lms↪osmo-trx-lms(pid=1883)] [process.py:270]
</pre></p>
<p>So my guess is not that ssh killing its child process is not working, but rather than when running with multi-trx we may end up in some race condition which somehow blocks osmo-trx-lms and prevents it from exiting.</p> OsmoBTS - Bug #4023 (Stalled): Missing coverage of PCU interface in osmo-btshttps://osmocom.org/issues/40232019-05-24T20:19:52Zlaforge
<p>let's use this as a separate ticket from <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Extension of BTS_Tests.ttcn test coverage (Resolved)" href="https://osmocom.org/issues/3750">#3750</a> to provide a more verbose list of the tests related to the PCU interface</p> OsmoBTS - Support #3863 (Stalled): setup testing of osmo-bts-oc2g on real hardware with ttcn3 and...https://osmocom.org/issues/38632019-03-26T16:21:06Zdexter
<p>In order to be able to debug problems with automatic interop testing a local instance of an osmocom-bb phone and BTS is required. TRXCONT/FAKETRX are exchanged with a real BTS/PHONE.</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> OsmoBSC - Bug #3806 (Stalled): OsmoBSC accepts BSSAP with wrong length fieldhttps://osmocom.org/issues/38062019-02-18T13:17:55Zlaforge
<p>As seen in <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoMSC sends invalid BSSMAP length field on CSFB CLEAR COMMAND (Resolved)" href="https://osmocom.org/issues/3805">#3805</a>, OsmoBSC would happily accept BSSMAP CLEAR COMMAND messages with IEs that extend beyond the length field of the BSSAP header.</p>
<p>This is definitely wrong. We should</p>
<ul>
<li>parse the length field</li>
<li>ensure we have a minimum of that number of bytes of payload as specified by the length field</li>
<li>truncate the msgb to a payload length as specified</li>
</ul>
<p>This way any additional garbage at the end of a message would simply be ignored, with us only parsing the specified "length" number of bytes.</p>
<p>Let's also make sure to add TTCN-3 tests for this, intentionally sending length field values too large and too short.</p>
<p>Once implemented in OsmoBSC, we should also implement it on the MSC side.</p> OsmoTRX - Bug #3775 (Stalled): properly debug limesdr usb and limesdr mini clocking requirements ...https://osmocom.org/issues/37752019-01-31T16:45:21Zroh
<p>limesdr usb and limesdr mini need a external reference clock to be used for gsm applications properly since the internal oscillator is sadly not of the required performance class.</p>
<p>limesdr usb has an extra internal pll (ADF4002 and Si5351C as well as LMK00105) and can handle different external clocks quite flexible<br />limesdr mini has no pll chip, but only a clock buffer (LMK00105) and needed some help from the fpga to make clocks possible which are not 40MHz</p> OsmoMSC - Feature #3445 (Stalled): SS/USSD: clean up the local GSM 04.80 APIhttps://osmocom.org/issues/34452018-08-03T09:43:56Zfixeria
<p>Since the SS/USSD related changes have been merged, OsmoMSC doen't process the<br />SS/USSD requests internally. This is why some part of the local GSM 04.80 API<br />has become useless. Would be great to clean it up, and keep only the most<br />important functions there...</p> OsmoTRX - Bug #3341 (Stalled): osmo-trx-lms RF Envelope FAIL on LimeSDR, but not on LimeSDR-minihttps://osmocom.org/issues/33412018-06-13T13:46:18Zlaforge
<p>I'm observing a strange behavior when comparing the RF envelope of osmo-trx-lms on a LimeSDR and a LimeSDR-mini.</p>
<p>The LimeSDR-mini envelope is within spec. Specifically, the transmit power level is at full strength before the start of the next burst.</p>
<p><img src="https://osmocom.org/attachments/download/3215/SCREEN1.BMP" title="RF envelope on LimeSDR-mini" alt="RF envelope on LimeSDR-mini" /> <img src="https://osmocom.org/attachments/download/3216/SCREEN2.BMP" title="RF envelope on LimeSDR-mini (zoom)" alt="RF envelope on LimeSDR-mini (zoom)" /></p>
<p>On the LimeSDR however, the next burst/timeslot starts too late, (or the slew rate is too low?):</p>
<p><img src="https://osmocom.org/attachments/download/3217/SCREEN3.BMP" title="RF envelope on LimeSDR" alt="RF envelope on LimeSDR" /> <img src="https://osmocom.org/attachments/download/3218/SCREEN4.BMP" title="RF envelope on LimeSDR (zoom)" alt="RF envelope on LimeSDR (zoom)" /></p>
<p>This is using the exact same versions of LimeSuite (f1e5444496923890ad7d030abef9c224c37c46cf) and osmo-trx (70621b74844a6ea08d6da5f5b1e1835b9af91771). All I'm doing is swapping the hardware and re-starting osmo-trx-lms and osmo-bts.</p>
<p>It's very odd, and I currently have no clue of what might be going on here.</p> OsmoSGSN - Bug #2958 (Stalled): OsmoSGSN doesn't authenticate on second/further ATTACH REQUESThttps://osmocom.org/issues/29582018-02-17T17:29:12Zlaforge
<p>When a new/unknown MS performs an ATTACH REQUEST for the first time, it is authenticated.</p>
<p>However, if that same MS later performs a second ATTACH REQUEST, even with new P-TMSI/TLLI, it is not authenticated and we simply send an ATTACH ACCEPT. This is a security problem, as it means anyone can impersonate other known-existing IMSIs.</p> OsmoBSC - Feature #2893 (Stalled): automatic simulator for large LU load https://osmocom.org/issues/28932018-01-27T16:43:22Zlaforge
<p>Every so often we see systems suffering a lot from large LU load.</p>
<p>There are many tunables like each tx delay/integer, access control class ramping, ms-acces-lv-min ramping, doewnlink poweer ramping, im ass reejct timer, etc</p>
<p>In order to be able to test different configurations and possible patches, we need a reproducible test scenario for benchmarking our performance.</p>
Ideally this shoiuld be possible with osmocombb and virtphy. For just performing a LU, we don't even need scripting. However, we need
<ul>
<li>starting large number of "mobile" </li>
<li>realistic timing for network scan / cell search (virtphy is too fast)</li>
<li>implementation of downlink attenuation</li>
<li>detection of RACH collisions in bts-virtual</li>
</ul> OsmoMSC - Bug #2851 (Stalled): a_iface.c:534 Unhandled SIGTRAN primitive: 3:2https://osmocom.org/issues/28512018-01-21T19:52:32Zlaforge
<p>Every so often I'm seeing the following error message:<br /><pre>
<000a> a_iface.c:534 Unhandled SIGTRAN primitive: 3:2
</pre></p>
We should
<ul>
<li>investigate and resolve this</li>
<li>make sure we print string values rather than numeric ones.</li>
</ul> OsmoBSC - Support #2622 (Stalled): Prepare automatic interop testing of OmsoBSC against NG40 core...https://osmocom.org/issues/26222017-11-07T21:46:30Zlaforge
<p>Please create a setup where the signaling tests (LU, MO-SMS, MT-SMS, USSD) can be done with osmocombb-mobile + virt_phy + osmo-bts-virtual + osmo-bsc against NG40.</p>
<p>This is in preparation of automatizing this task as soon as we have a scripting interface towards OsmocomBB "mobile"</p>
<p>Building all components should be automatic / scripted. It might be an idea to do this via Dockerfiles. Execution of the tests + checking results is not automatic yet, as this is pending the OsmocomBB "mobile" script interface.</p>
The goal is basically to have a single command/script to
<ul>
<li>build/install osmo-bsc, osmo-bts-virtual, virt-phy + mobile</li>
<li>might make sense to have
<ul>
<li>one docker image for osmo-bsc</li>
<li>one docker image for osmo-bts-virtual + virt_phy</li>
</ul></li>
</ul>
and then have another scripted way to
<ul>
<li>start N instances of each of them (except "mobile"), where the number of BSCs is different from the number of BTSs and again different from the number of virt-phy instances</li>
</ul> 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> OsmoGSMTester - Feature #2197 (Stalled): osmo-gsm-tester: use MNCC interfacehttps://osmocom.org/issues/21972017-04-26T15:29:52Zneelsnhofmeyr@sysmocom.de
<p>the MNCC interface present in the old osmo-gsm-tester code is not yet present in the new osmo-gsm-tester.<br />Add test API to interact with the NITB (future OsmoMSC) using MNCC.</p> OsmoPCU - Bug #1838 (Stalled): Nokia E52 doest reply to PUAN message properlyhttps://osmocom.org/issues/18382016-11-09T12:27:17Zarvind.sirsikar
<p>When we indicate MS that we have Nack in receiving window(in PUAN). Nokia E52 MS doesn’t honor that and keeps sending the new RLC blocks even when it crosses its transmit window in UL. causing the reception of RLC blocks outside RLC window.</p>
<p>below is PCU log snippet for one such example:</p>
<p>encoding.cpp:676 - EGPRS URBB, len = 11, SSN = 671, ESN_CRBB = 670, SNS = 2048, WS = 64, V(Q) = 670, V(R) = 682, BOW, EOW</p>
<p>message = 40 24 01 1f 3e 90 00 92 f0 8d 35 3e ff c3 2b 2b 2b 2b 2b 2b 2b 2b 2b</p>
<p>Below is the decoded message.</p>
<pre><code>EGPRS_AckNack<br /> 1... .... = ACKNACK: (Union)<br /> Desc<br /> .000 1101 0... .... = ACKNACK Dissector length: 26<br /> Desc<br /> .0.. .... = FINAL_ACK_INDICATION: False<br /> ..1. .... = BEGINNING_OF_WINDOW: 1<br /> ...1 .... = END_OF_WINDOW: 1<br /> .... 0101 0011 111. = STARTING_SEQUENCE_NUMBER: 671<br /> .... ...0 = CRBB Exist: 0<br /> 1111 1111 110. .... = URBB_BITMAP: 2046</code></pre>
<p>Other MS like LG F70 and Lenovo K4 note behaves properly for this kind of PUAN with nacked bits present in it.<br />further investigation needs to be done</p> OsmoPCU - Feature #1823 (Stalled): Ericsson PCU TRAU frame encoding/decodinghttps://osmocom.org/issues/18232016-10-15T15:42:23Zlaforge
<p>It is not yet clear if this code will be part of OsmoPCU internally, or if it is better kept in an external process.</p>
The general idea is as follows:
<ul>
<li>open the E1 time-slots used for PCU TRAU frames
<ul>
<li>try to use only full 64k slots. If 16k sub-slots required, the subchan_mux code of libosmo-abis should be reused.</li>
</ul>
</li>
<li>synchonize on the PCU-TRAU frames (frame_sync.c which I already wrote but never tested)</li>
<li>receive + decode the TRAU frames. We need at least
<ul>
<li>PCU_TRAU_ER_FT_CCU_SYNC_IND</li>
<li>PCU_TRAU_ER_FT_DATA_IND for CS1, CS2, CS3, CS4</li>
</ul>
</li>
<li>encode + transmit the TRAU frames. We need at least
<ul>
<li>PCU_TRAU_ER_FT_PCU_SYNC_IND</li>
<li>PCU_TRAU_ER_FT_DATA_IND for CS1, CS2, CS3, CS4</li>
</ul></li>
</ul>
<p>The SYNC procedure is the starting point. The *-SYNC-IND messages are always sent in case the link is idle and nothing else is to be sent.</p>
<p>See <a class="wiki-page" href="https://osmocom.org/projects/openbsc/wiki/Ericsson_RBS2000_GPRS">Ericsson_RBS2000_GPRS</a> for more information.</p> OsmoSGSN - Bug #1794 (Stalled): support random IV for GEA (via XID)https://osmocom.org/issues/17942016-08-09T14:21:57Zmsuraev
<p>Current implementation of GPRS encryption uses hardcoded IV = 0 while according to spec it should be random. This random value is communicated to client as part of XID negotiation.</p> OsmoSGSN - Bug #1768 (Stalled): VTY show llc displays State TLLI Unassigned permanentlyhttps://osmocom.org/issues/17682016-07-07T11:48:18Zdexter
<p>Expecting at least some assigned TLLI states in in SAPI list on globally Assigned TLLI state.</p>
<pre>
TLLI e625e4fb (Old TLLI ffffffff) BVCI=2 NSEI=101 Age=0: State TLLI Assigned
SAPI 1 State TLLI Unassigned (1) VUsend=4, VUrecv=5 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=400, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 2 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 3 State TLLI Unassigned (1) VUsend=91, VUrecv=64 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=500, N201-I=1503, mD=1520, mU=1520, kD=16, kU=16
SAPI 5 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=10, N200=3, N201-U=500, N201-I=1503, mD=760, mU=760, kD=8, kU=8
SAPI 7 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 8 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 9 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=500, N201-I=1503, mD=380, mU=380, kD=4, kU=4
SAPI 11 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=40, N200=3, N201-U=500, N201-I=1503, mD=190, mU=190, kD=2, kU=2
</pre>
<p>Already checked if the get_value_string(gprs_llc_state_strs, lle->state) returns the right string. Seems to work, numerical state is always 1 as well.</p> OsmoPCU - Bug #1759 (Stalled): Wrong calculation of DL window size for DL assignmenthttps://osmocom.org/issues/17592016-06-28T10:27:21Zarvind.sirsikar
<p>Hi,</p>
<p>When we create DOWNLINK TBF without existing UPLINK TBF i.e DL assignment on PCH case, The calculation of window size is found to be incorrect.</p>
<p>Description:<br /> 4 time slots is configured for DL and osmo-pcu.cfg is configured as window-size 64 104.</p>
<pre><code>When we try to do IPERF in DL direction, PCU allocates window-size as 160 but configures 4 time slots<br /> as seen by PCU VTY. Below is the result of VTY output.</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=160 V(A)=12 V(S)=12 nBSN=138</code></pre>
<pre><code>But we see proper calculation of window-size when DL assignement is done on PACCH. as seen by VTY interface below</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=480 V(A)=138 V(S)=139 nBSN=138</code></pre>
<p>Thanks,<br />Aravind Sirsikar</p> OsmoNITB - Bug #1725 (Stalled): iPhone6 network selection issue with GSM1900https://osmocom.org/issues/17252016-05-17T20:07:23Zzecke
<p>We have some form of issue with the iPhone 6S (we can use messenger to move it around). Now the iPhone is a really bad phone (manual network selection not re-scanning, selecting it not trying to access the network in a reasonable amount of time). But what I can re-produce:</p>
<ul>
<li>Put customer IMSI in the phone</li>
<li>Wait for the network to be selected</li>
<li>Enter airplane mode</li>
<li>Leave airplane mode</li>
</ul>
<p>Theory:</p>
<p>The LU should lead to the <abbr title="+band?">ARFCN</abbr> be written to the SIM card. This ARFCN should be tried <em>after</em> the airplane mode (or reboot) is used. But the phone ends up in "No Service". I make my tests with with a RevA hardware and maybe slightly incorrect calibration but other phones behave a lot better.</p>
<p>Reality:</p>
<p>What happens is that after the airplane mode.. the phone does <em>not</em> select a network (It goes to Searching and then prints No Network). Toggling "Automatic" to "Manual" network seaearch it sometimes starts to connect it (after many many minutes).</p>
<p>Stats:<br /><pre>
iPhone 6s
Version 9.3.2 (14F69)
Carrier 24.0
Model MKQK2ZD/A
Modem Firmware 1.60.00
</pre></p>
<p>For reference the SIs of another small network at 1900</p>
<pre>
SI1 5506198f0e0000000000000000000000000000bb00006b
SI2 59061a00000000000000000000000000000000ffbb0000
SI3 49061b9c4072f480101949030f07c346bb00008000832b
SI4 41061c72f4801019c346bb00006430021c80008b2b2b2b
SI13 <empty>
SI5 49061d10000000000000000000000000000000
SI6 2d061e9c4072f480101997ff3b2b2b2b2b2b2b
</pre> OsmoNITB - Bug #1671 (Stalled): Combined 850/1800 NITB not seen by Option Icon2 stickhttps://osmocom.org/issues/16712016-03-24T06:53:41Zzecke
<p>When having a NITB with one GSM1800 BTS on ARFCN 877 and one on GSM850 on ARFCN 130 (that is not broadcasting), the Icon2 stick failed to join the network. When removing this cell (and hence the neighborcell information) it works immediately. The test was done with a nanoBTS.</p>
<p>Tests:</p>
<ul>
<li>Make this stable, I had issued another AT+CFUN=0/CFUN=1 today morning and while I did this yesterday it is not a clear call</li>
<li>Test with sysmoBTS and the nanoBTS (e.g. maybe some SIs are not scheduled)</li>
<li>Look if all generated SIs are being sent</li>
<li>Look at the spec if such config is legal..</li>
<li>Look at the generated SIs</li>
</ul>
<p>BTS 1 config<br /><pre>
bts 1
type sysmobts
band GSM850
cell_identity 0
location_area_code 1
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
periodic location update 30
radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
ip.access unit_id 1802 0
oml ip.access stream_id 255 line 0
neighbor-list mode automatic
codec-support fr
gprs mode none
no force-combined-si
trx 0
rf_locked 0
arfcn 130
nominal power 23
max_power_red 22
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
</pre></p> OsmoSGSN - Feature #1655 (Stalled): KPIs for OsmoSGSNhttps://osmocom.org/issues/16552016-03-11T09:53:30Zlaforge
<ul>
<li>overall GPRS DL and UL IP payload throughput (mbps) : waits for compression</li>
<li>overall GPRS DL and UL IP compression gain (%) : waits for compression</li>
<li>overall GPRS DL and UL LLC througput (mbps) : via global rate counters</li>
<li>GPRS Attach attempts (number) : gprs.attempts_request</li>
<li>GPRS Attach success rate (%) : gprs.attempts_accepted / gprs.attempts_request</li>
<li>PDP context attempts (number) : pdp.activate_requests</li>
<li>PDP context establish success rate (%) : pdp.activate_requests / pdp.activate_accept</li>
<li>PDP context cut-off (%) : ?</li>
</ul> OsmocomBB - Support #1627 (Stalled): DCS_8BIT and DCS_UCS2 encoding supprothttps://osmocom.org/issues/16272016-02-29T03:46:52Zfixeria
<p>Currently it is impossible to send/receive SMS messages and USSD encoded in 8-bit or 16-bit alphabet.</p> OsmoBSC - Bug #1614 (Stalled): better identification of BTS model / capabilities to BSChttps://osmocom.org/issues/16142016-02-23T16:24:51Zlaforge
Right now, there is a lot of implied knowledge at the BSC level about the BTS, i.e.
<ul>
<li>the BSC needs to be told which BTS model it is</li>
<li>the BSC needs to be told the nominal transmit power of each TRX</li>
<li>the BSC needs to be told about the codec capabilities, etc.</li>
</ul>
<p>In order to reduce the currently seemingly endless possbilities how somebody can end up with a non-working<br />configuration, it would be good if the BTS would express its capabilities towards the BSC. As there is<br />no standard in the Abis specs for this, we have to come up with a mechanism of our own.</p>
<p>It might be a vendor-specific OML request from BSC to BTS, which we could use to determine from BSC side if the BTS supports this request at all (if not, proceed as usual). This would also ensure backwards compatibility with nanoBTS or older OsmoBTS versions.</p> OsmoSGSN - Feature #1587 (Stalled): SMS over GPRS supporthttps://osmocom.org/issues/15872016-02-23T15:46:03Zlaforge
<p>Currently, the SGSN doesn't support the transmission of SMS via the packet-switched plane. However, this is much more efficient in terms of air interface resource usage than to do this over circuit-switched GSM/SDCCH.</p>