Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-08T13:33:39ZOpen Source Mobile Communications
Redmine OsmoUPF - Feature #6394 (Stalled): Basic URR (Usage Reporting Rule) support for tunnel mappinghttps://osmocom.org/issues/63942024-03-08T13:33:39Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p><a class="user active" href="https://osmocom.org/users/30187">pespin</a> had implemented something like this for open5gs-upf in<br /><pre>commit fb8ebcdbeae0648e30d04fd016a956642131dddd
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Apr 8 16:10:42 2022 +0200
[UPF] Add initial support for URR Usage Report (#1476)
</pre><br />and following commits.</p>
<p>Now sadly, open5gs-upf is more like a lab-grade upf and nothing that scales at all, and we hence have users of osmo-upf that use it for its fast kernel path.</p>
<p>The primary goal for this feature is the <em>tunnel mapping</em> case in a osmo-hnbgw co-located osmo-upf. The packet and byte counters hence will have to be added to the nftables rules.</p> 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> 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> 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> OsmoPCU - Bug #4452 (Stalled): manual testing of osmo-pcuhttps://osmocom.org/issues/44522020-03-10T15:46:02Zroh
<p>these are manual testruns with osmo-pcu and osmo-bts-sysmo from -nightly and the cni running on debian on an apu.</p>
<p>attached are the configs for the sysmobts (osmo-pcu and osmo-bts-sysmo) as well as the remaining cni (on debian9 from -nightly)</p>
<p>the pcap files are generated by dumping the complete interface on the bsc. in addition to that the gsmtap for -bts and -pcu sends its debug there.<br />the pcap file(s) are single runs: getting the phone from airplane mode - register - do a network request - airplane mode.</p> 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> 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> OsmocomBB SDR PHY - Bug #3459 (Stalled): apps/grgsm_trx: AssertionError: packe t_info.packet_coun...https://osmocom.org/issues/34592018-08-09T19:10:03Zfixeria
<p>Despite actual burst transmission works, I see the following messages repeated multiple times:</p>
<pre>
[i] Recv POWEROFF cmd
[i] Stopping transceiver...
[i] Setting TA value 0
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: drop all
[i] Recv MEASURE cmd
[i] Recv POWEROFF cmd
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: TS 0
[i] Recv POWERON CMD
[i] Starting transceiver...
thread[thread-per-block[15]: <block gr uhd usrp sink (8)>]: EnvironmentError: IOError: Radio ctrl (0) packet parse error - AssertionError: packe
t_info.packet_count == (seq_to_ack & 0xfff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /build/libuhd/src/uhd-3.11.1.0/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:254
</pre>
<p>Observed within a Docker image wit the recent software:</p>
<ul>
<li>UHD_3.11.1.0-0-unknown</li>
<li>GNU Radio 3.7.11-6</li>
<li>GR-GSM TRX from fixeria/trx</li>
</ul>
<p>Could you please have a look?<br />Do you see this too?</p> OsmocomBB SDR PHY - Bug #3458 (Stalled): apps/grgsm_trx: [ERROR] [STREAMER] recv packet demuxer u...https://osmocom.org/issues/34582018-08-09T18:29:31Zfixeria
<p>Sometimes, while running the following output appears:</p>
<pre>
[i] Recv ECHO cmd
[i] Recv POWEROFF cmd
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: TS 0
[i] Recv RXTUNE cmd
[i] Recv TXTUNE cmd
[i] Recv POWERON CMD
[i] Starting transceiver...
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4a000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xe0024
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x37ffe7
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1b0005
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff530020
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xcff6d
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x7ffc8
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffbeff95
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x65000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb20072
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x16ffc9
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff5fff1
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffc400bb
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xcffdd
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffdcffcb
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb2fff5
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd5ffc4
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x38fff2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcf0000
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xbb0069
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x12ffcc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb6001f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd7001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x14004c
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffa6ffe8
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xa002a
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff76003f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff96ffd3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x130013
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd5ffe3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff8c0075
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff0000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xdffee
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff40011
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1afff9
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff9aff5d
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff9afffa
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x7ffce
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcb0008
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff7ffdd
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x5a005e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x38ffca
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x6ffa2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4ffcc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffba00ab
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff420029
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1effe2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x70067
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1a001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1a0016
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xb00a5
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffbe0008
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffe6001a
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcfffc3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x130003
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffceff44
</pre> 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> OsmocomBB SDR PHY - Bug #3425 (Stalled): Receiver: missing AGC (Automatic Gain Control)https://osmocom.org/issues/34252018-07-26T20:25:52Zfixeria
<p>When the signal becomes too strong, we need to decrease the gain to avoid saturation.<br />When the signal becomes less powerful, we need to increase the gain...</p> OsmocomBB SDR PHY - Feature #3424 (Stalled): Transceiver: implement automatic TX delay measurementhttps://osmocom.org/issues/34242018-07-26T20:22:05Zfixeria
<p>As we all know, the world is not perfect, and there is some delay on the TX path of SDR devices.<br />At the moment, we know that for USRP B2X0 this delay is constant, so we take it into account.</p>
<p>But since we are going to extend the hardware compatibility, it makes sense to implement<br />some automatic measurement of delay for a particular device.</p> OsmocomBB SDR PHY - Bug #3422 (Stalled): Receiver: sample / burst buffering problemhttps://osmocom.org/issues/34222018-07-26T20:08:47Zfixeria
<p>The problem appears when one stops the flow-graph, changes some parameters (e.g. freq.) and starts it again.<br />As soon as the flow-graph is started, Receiver block will still output some bursts from the past for some time.</p>
<p>Please note that <strong>I just assume</strong> that this is a problem of Receiver block.<br />It might be also a problem of any other block(s), such as 'TRX Interface'.</p> 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> 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> 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> 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> 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>