Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-01T17:08:19ZOpen Source Mobile Communications
Redmine Linux Kernel GTP-U - Bug #6382 (Feedback): "TC_pdp6_act_deact_gtpu_access" fails with kernel gtp-uhttps://osmocom.org/issues/63822024-03-01T17:08:19Zosmith
<p>Pau and I debugged why TC_pdp6_act_deact_gtpu_access does not work with osmo-ggsn with kernel gtp-u. It passes without kernel gtp-u.</p>
<blockquote>
<p>pespin: so I'd say that use case cannot really be performed right now as with current setup, but it's quite a specific one and not sure what would be the best desired behavior</p>
</blockquote>
<blockquote>
<p>pespin: so in summary: a GTP-U/IPv6(src-addr-link-local) arrives to the gtp kernel module (socket fd1u), and it decides the GGSN (userspace) needs to handle the packet, so the packet is pushed/read by osmo-ggsn, which in our current logic decides to forward the packet out of the tun. In order to do that, when we have a non-gtp generic tun, we use the tun FD to inject the decapsulted packet (IPv6(src-addr-link-local) into the network stack.</p>
</blockquote>
<blockquote>
<p>pespin: but when using the gtp tundev kind, we apparently do have the "tun fd" we need to inject decapsulated packets from the userspace program (osmo-ggsn), that only happens through the network stack internally.</p>
</blockquote>
<blockquote>
<p>pespin: So the question would be: 1- Can we somehow obtain an fd for the tun so we can inject decapsulated packets to it like we do in the userspace-gtp scenario? If yes, we should replace fd = -1 with that. If no, then we simply assume we don't want to inject those packets and discard them</p>
</blockquote>
<blockquote>
<p>pespin: feel free to create the ticket or point me to the existing one and I can fill in more info</p>
</blockquote>
<p><a href="#" onclick="$('#collapse-45975d80-show, #collapse-45975d80-hide').toggle(); $('#collapse-45975d80').fadeToggle(150);; return false;" id="collapse-45975d80-show" class="icon icon-collapsed collapsible">osmo-ggsn log + dmesg</a><a href="#" onclick="$('#collapse-45975d80-show, #collapse-45975d80-hide').toggle(); $('#collapse-45975d80').fadeToggle(150);; return false;" id="collapse-45975d80-hide" class="icon icon-expended collapsible" style="display:none;">osmo-ggsn log + dmesg</a><div id="collapse-45975d80" class="collapsed-text" style="display:none;"><pre>
+ osmo-ggsn -c /data/osmo-ggsn.cfg
20240301163326408 DLSTATS INFO Stats timer started with interval 5 sec (stats.c:206)
20240301163326410 DGGSN INFO APN(internet): Starting (ggsn.c:186)
20240301163326411 DGGSN INFO APN(internet): Opening Kernel GTP device tun46 (ggsn.c:204)
20240301163326412 DGGSN NOTICE APN(internet): Skipping APN start (ggsn.c:210)
20240301163326413 DGGSN INFO GGSN(ggsn0): Starting GGSN (ggsn.c:816)
20240301163326414 DLGTP NOTICE GTP: gtp_newgsn() started at 172.18.70.201 (gsn.c:465)
20240301163326416 DLGTP NOTICE State information file (/tmp/gsn_restart) not found. Creating new file. (gsn.c:386)
20240301163326417 DLGLOBAL DEBUG validating counter group 0x7fd8d2ca7b00(gsn) with 18 counters (rate_ctr.c:86)
20240301163326419 DGGSN NOTICE GGSN(ggsn0): Successfully started (ggsn.c:852)
20240301163326420 DGGSN INFO APN(internet): Starting (ggsn.c:186)
20240301163326421 DGGSN INFO APN(internet): Opening Kernel GTP device tun46 (ggsn.c:204)
20240301163326422 DGGSN NOTICE Initialized GTP kernel mode (genl ID is 32) (gtp-kernel.c:79)
[ 0.772102] gtp: enable gtp on 7, 4
[ 0.772475] gtp: enable gtp on 9, 5
[ 0.773067] tun46: registered new GTP interface
20240301163326425 DTUN NOTICE GTP kernel configured (tun.c:217)
[ 0.774548] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0002, skip
20240301163326426 DGGSN INFO APN(internet): Setting tun IP address 176.16.16.0/20 (ggsn.c:230)
20240301163326428 DGGSN INFO APN(internet): Setting tun IPv6 address 2001:780:44:2100::/56 (ggsn.c:242)
20240301163326429 DGGSN INFO APN(internet): Creating IPv4 pool 176.16.16.0/20 (ggsn.c:288)
20240301163326430 DGGSN INFO APN(internet): Blacklist tun IP 176.16.16.0/20 (ggsn.c:167)
20240301163326432 DGGSN INFO APN(internet): Creating IPv6 pool 2001:780:44:2100::/56 (ggsn.c:305)[ 0.781506] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
20240301163326434 DGGSN INFO APN(internet): Blacklist tun IP 2001:780:44:2100::/56 (ggsn.c:167)
20240301163326435 DGGSN NOTICE APN(internet): Successfully started (ggsn.c:320)
20240301163326436 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4260 (telnet_interface.c:88)
20240301163326437 DLCTRL NOTICE CTRL at 127.0.0.1 4257 (control_if.c:1014)
[ 1.166137] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[ 1.603649] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
[ 1.604747] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0002, skip
[ 1.606563] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
[ 1.739641] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
[ 2.243889] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
20240301163328636 DLGLOBAL INFO Accept()ed new telnet connection r=172.18.70.202:37064<->l=172.18.70.201:4260 (telnet_interface.c:192)
20240301163328660 DLGLOBAL NOTICE TTCN3 f_logp(): TC_pdp6_act_deact_gtpu_access() start (logging_vty.c:1165)
20240301163328670 DLGTP DEBUG Begin pdp_tidget tid = e505007495524262 (pdp.c:322)
20240301163328674 DLGTP DEBUG Begin pdp_tidget. Not found (pdp.c:330)
20240301163328678 DLGTP DEBUG Begin pdp_tidset tid = e505007495524262 (pdp.c:277)
20240301163328682 DLGTP DEBUG End pdp_tidset (pdp.c:286)
20240301163328686 DGGSN DEBUG PDP(262425594700505:14): Processing create PDP context request for APN 'inet6' (ggsn.c:441)
20240301163328690 DGGSN DEBUG PDP(262425594700505:14): gtp_kernel_tunnel_add tun46 v1 TEID c88d0b86 EUA=(,2001:780:44:2101::) SGSN=172.18.70.202 (gtp-kernel.c:50)
[ 3.043499] tun46: GTPv1-U: new PDP ctx id=1/c88d0b86 ssgn=172.18.70.202 ms=32.1.7.128 (pdp=(____ptrval____))
20240301163328698 DGGSN INFO SGSN(172.18.70.202): Discovered (sgsn.c:83)
20240301163328700 DGGSN DEBUG PDP(262425594700505:14): PCO Protocol 0x0003 (pco.c:206)
20240301163328704 DGGSN INFO PDP(262425594700505:14): Successful PDP Context Creation: APN=inet6(internet), TEIC=1, IPv4=none, IPv6=2001:780:44:2101:: (ggsn.c:563)
20240301163328710 DLGTP DEBUG Registering seq=62633 in restransmit resp queue (gtp.c:503)
[ 3.065090] tun46: encap_recv sk=(____ptrval____)
[ 3.066495] tun46: received GTP1U packet
[ 3.067603] tun46: No PDP ctx for this MS
[ 3.068730] tun46: pass up to the process
20240301163328721 DGGSN DEBUG PDP(262425594700505:14): Packet received on APN(internet): forwarding to tun tun46 (ggsn.c:675)
[ 3.078465] tun46: encap_recv sk=(____ptrval____)
[ 3.079954] tun46: received GTP1U packet
[ 3.081068] tun46: No PDP ctx for this MS
[ 3.082226] tun46: pass up to the process
[ 3.083371] tun46: encap_recv sk=(____ptrval____)
[ 3.084696] tun46: received GTP1U packet
[ 3.085825] tun46: No PDP ctx for this MS
[ 3.086953] tun46: pass up to the process
20240301163328739 DGGSN DEBUG PDP(262425594700505:14): Packet received on APN(internet): forwarding to tun tun46 (ggsn.c:675)
20240301163328744 DTUN ERROR errno=9/Bad file descriptor TUN(tun46): write() failed (tun.c:324)
20240301163328747 DGGSN DEBUG PDP(262425594700505:14): Packet received on APN(internet): forwarding to tun tun46 (ggsn.c:675)
20240301163328752 DTUN ERROR errno=9/Bad file descriptor TUN(tun46): write() failed (tun.c:324)
[ 5.251918] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0002, skip
20240301163331735 DLGLOBAL INFO Closing telnet connection r=172.18.70.202:37064<->l=172.18.70.201:4260 (telnet_interface.c:138)
</pre></div></p>
<p>The error happens in <code>lib/tun.c</code>:</p>
<pre><code class="c syntaxhl"><span class="kt">int</span> <span class="nf">tun_encaps</span><span class="p">(</span><span class="k">struct</span> <span class="n">tun_t</span> <span class="o">*</span><span class="n">tun</span><span class="p">,</span> <span class="kt">void</span> <span class="o">*</span><span class="n">pack</span><span class="p">,</span> <span class="kt">unsigned</span> <span class="n">len</span><span class="p">)</span>
<span class="p">{</span>
<span class="kt">int</span> <span class="n">rc</span><span class="p">;</span>
<span class="n">rc</span> <span class="o">=</span> <span class="n">write</span><span class="p">(</span><span class="n">tun</span><span class="o">-></span><span class="n">fd</span><span class="p">,</span> <span class="n">pack</span><span class="p">,</span> <span class="n">len</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">rc</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="n">SYS_ERR</span><span class="p">(</span><span class="n">DTUN</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">errno</span><span class="p">,</span> <span class="s">"TUN(%s): write() failed"</span><span class="p">,</span> <span class="n">tun</span><span class="o">-></span><span class="n">devname</span><span class="p">);</span>
<span class="p">...</span>
</code></pre>
<code>tun->fd</code> is -1 for kernel gtp-u, it gets set in <code>lib/tun.c:tun_new()</code>:
<pre><code class="c syntaxhl"> <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">use_kernel</span><span class="p">)</span> <span class="p">{</span>
<span class="cm">/* Open the actual tun device */</span>
<span class="k">if</span> <span class="p">(((</span><span class="o">*</span><span class="n">tun</span><span class="p">)</span><span class="o">-></span><span class="n">fd</span> <span class="o">=</span> <span class="n">open</span><span class="p">(</span><span class="s">"/dev/net/tun"</span><span class="p">,</span> <span class="n">O_RDWR</span><span class="p">))</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="p">...</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="n">strncpy</span><span class="p">((</span><span class="o">*</span><span class="n">tun</span><span class="p">)</span><span class="o">-></span><span class="n">devname</span><span class="p">,</span> <span class="n">dev_name</span><span class="p">,</span> <span class="n">IFNAMSIZ</span><span class="p">);</span>
<span class="p">(</span><span class="o">*</span><span class="n">tun</span><span class="p">)</span><span class="o">-></span><span class="n">devname</span><span class="p">[</span><span class="n">IFNAMSIZ</span> <span class="o">-</span> <span class="mi">1</span><span class="p">]</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
<span class="p">(</span><span class="o">*</span><span class="n">tun</span><span class="p">)</span><span class="o">-></span><span class="n">fd</span> <span class="o">=</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="n">gtp_kernel_create</span><span class="p">(</span><span class="o">-</span><span class="mi">1</span><span class="p">,</span> <span class="n">dev_name</span><span class="p">,</span> <span class="n">fd0</span><span class="p">,</span> <span class="n">fd1u</span><span class="p">)</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
</code></pre> Core testing infrastructure - Bug #5858 (Feedback): osmo-python-tests: Ignore, at least clean up ...https://osmocom.org/issues/58582023-01-15T19:57:10Zarehbein
<p>I've had <code>osmo-bsc/tests/ctrl_test_runner.py</code> fail on me (make distclean didn't help either) seemingly inexplicably.</p>
<p>What seems to be happening is the script <code>osmo-python-tests/scripts/osmotestconfig.py</code> tries to copy the config directory to <code>osmo-bsc/writtenconfig</code>, and along the way - if <code>osmo-bsc/tests/ctrl_test_runner.py</code> exited before teardown of the testcase occurred, e.g. due to cancellation - it encounters an error due to trying to copy a socket file (<code>tmp_dummy_sock</code>), resulting in a very unspecific/misleading error (see <a class="external" href="https://github.com/python/cpython/issues/81881">https://github.com/python/cpython/issues/81881</a>) <strong>and exits</strong>:</p>
<p>(osmo-python-tests/scripts/osmopythontestconfig.py: 42)<br /><pre>
# If there's a socket error, skip the rest of the tests for this config
except IOError:
return 1
</pre></p>
I would suggest the following, unless there is a good reason why none of this has been done before (I suppose there isn't...):
<ul>
<li>ignore all files <code>tmp_dummy_sock</code> in shutil in <code>osmo-python-tests/scripts/osmotestconfigpython.py</code></li>
<li>register a signal handler to clean up such files in <code>osmo-bsc/tests/ctrl_test_runner.py</code></li>
<li>fix <code>make clean</code>, <code>make distclean</code> to cleanup such files</li>
</ul>
<p>Possibly related: OS#5665</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> libosmo-netif - Bug #5368 (Feedback): consider using SCTP_EVENT instead of SCTP_EVENTShttps://osmocom.org/issues/53682021-12-22T15:45:22Zlaforge
<p>The infamous SCTP_EVENTS and its ABI breakage (<a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: [centos] ttcn3-msc-test: 177 failures! (Resolved)" href="https://osmocom.org/issues/4573">#4573</a>) have been deprecated by IETF in 2011 already, and a new SCTP_EVENT option has been introduced. See <a class="external" href="https://datatracker.ietf.org/doc/html/rfc6458">https://datatracker.ietf.org/doc/html/rfc6458</a> Section 6.2.2.</p>
<p>We could switch libosmo-netif over to the new socket option.</p>
<p>However, Linux only introduced support for SCTP_EVENT in 2018 in<br /><pre>
commit 480ba9c18a27ff77b02a2012e50dfd3e20ee9f7a
Author: Xin Long <lucien.xin@gmail.com>
Date: Sun Nov 18 16:08:54 2018 +0800
sctp: add sockopt SCTP_EVENT
This patch adds sockopt SCTP_EVENT described in rfc6525#section-6.2.
With this sockopt users can subscribe to an event from a specified
asoc.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
</pre></p>
<p>The related code is hence only present in kernels >= 5.0</p>
<p>So it seems like a better choice to stay with SCTP_EVENTS for now as we need it to support older kernels anyway.</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> 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 - Bug #4008 (Feedback): Channel Activation starts SACCH too early in Asynchronous Handoverhttps://osmocom.org/issues/40082019-05-19T20:48:41Zlaforge
<p>In case of an asynchronous hand-over related channel activation, 3GPP TS 48.058 Section 4.1.3 is very specific:</p>
<pre>
BTS starts transmission immediately on the main channel in the indicated mode and with encryption if so indicated. If
the MS Power element is present the BTS may start transmission also on the SACCH.
When receiving a correct access burst with the correct handover reference, BTS starts the normal reception process on
the main channel in the indicated mode and starts receiving (and sending if not started earlier) on SACCH. Deciphering
is started if so indicated. The handover detection procedure towards BSC is also started.
</pre>
<p>However, as uncovered by an upcoming <code>BTS_Tests.TC_sacch_chan_act_ho_async</code> test case, we appear to be activating the SACCH unconditionally from the first moment.</p>
<p>The problem here is quite obvious: Until we have received the access burst from the MS, we don't yet know the timing offset, and hence the timing advance that we should advertise in the downlink SACCH. If we start SACCH transmission too early, it means that a wrong TA is advertised, which may be picked up by the MS, which will then apply a wrong TA value -> boom.</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> 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 - 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> OsmoNITB - Bug #2691 (Feedback): Old TMSI paged after LUhttps://osmocom.org/issues/26912017-11-29T09:37:38Zzecke
<p>While working on the scripting of "mobile" I noticed a funny paging issue.</p>
<ul>
<li>Do UL from mobile</li>
<li>Send SMS from NITB and start paging to mobile</li>
<li>"shutdown" mobile</li>
<li>"no shutdown" mobile
<ul>
<li>UL happens</li>
<li>TMSI reallocation</li>
</ul>
</li>
<li>NITB will continue paging the old TMSI</li>
</ul>
<p>The issue got introduced in 6d804b1a7e375213cb4b3e437c2b9b8c68872164 when separating the subscribers...</p> OsmoSGSN - Bug #1942 (Feedback): Gb: implement paging in case of MM state == STANDBY && rx DL PDUhttps://osmocom.org/issues/19422017-02-04T08:07:03Zlynxis
<p>In case of a DL PDU received from GGSN and the MS MM state is STANDBY, the MS must be paged within the RA.</p>
<p>- implement the paging<br />- find out what should happen with the DL PDU (there is no queuing in SGSN atm.)</p> OsmoBTS - Bug #1898 (Feedback): Wrong handover detection with l1sap on wrong ss=0/ts=0https://osmocom.org/issues/18982016-12-27T12:24:04Zzecke
<p>So handover being detected on TS=0, SS=0... which is unlikely to be the right channel.. Need input validation and checking if the channel is allocated? But verify it.. not sure why it detects it like that.. Happens frequently at the 33C3</p>
<pre>
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<000a> handover.c:111 (bts=0,trx=0,ts=0,ss=0) RACH on dedicated channel received with TA=0
<0007> l1sap.c:1205 modifying channel chan_nr=0x20 trx=0
<000a> oml.c:1852 (bts=0,trx=0,ts=0,ss=0) modifying channel for handover
<0006> oml.c:1077 (bts=0,trx=0,ts=0,ss=0) MPH-ACTIVATE.req (hL2=0x000000bb, SDCCH TxDL)
<0007> l1_if.c:166 Tx L1 prim MPH-ACTIVATE.req
<0000> rsl.c:578 Sending HANDOver DETect
Program received signal SIGSEGV, Segmentation fault.
rslms_rx_rll_udata_req (msg=msg@entry=0xc0748, dl=dl@entry=0xb6fc14b0) at lapdm.c:855
855 lapdm.c: No such file or directory.
(gdb) bt
#0 rslms_rx_rll_udata_req (msg=msg@entry=0xc0748, dl=dl@entry=0xb6fc14b0) at lapdm.c:855
#1 0x4fcacb00 in rslms_rx_rll (lc=0xb6fc133c, msg=0xc0748) at lapdm.c:1154
#2 lapdm_rslms_recvmsg (msg=msg@entry=0xc0748, lc=lc@entry=0xb6fc1294) at lapdm.c:1223
#3 0x000279d4 in ho_tx_phys_info (lchan=lchan@entry=0xb6fc11ec) at handover.c:61
#4 0x00027cbc in handover_rach (lchan=0xb6fc11ec, ra=<optimized out>, acc_delay=acc_delay@entry=0 '\000') at handover.c:131
#5 0x0002a680 in l1sap_handover_rach (l1sap=<optimized out>, rach_ind=<optimized out>, rach_ind=<optimized out>,
rach_ind=<optimized out>, trx=0xb6fbd038) at l1sap.c:659
#6 l1sap_ph_rach_ind (rach_ind=0xbf4fc, l1sap=0xbf4ec, trx=0xb6fbd038) at l1sap.c:974
#7 l1sap_up (trx=trx@entry=0xb6fbd038, l1sap=l1sap@entry=0xbf4ec) at l1sap.c:1022
#8 0x0000d690 in handle_ph_ra_ind (l1p_msg=0xbf428, ra_ind=<optimized out>, fl1=0xbf428) at l1_if.c:1064
#9 l1if_handle_ind (fl1=<optimized out>, msg=msg@entry=0xbf428) at l1_if.c:1090
#10 0x0000dfc8 in l1if_handle_l1prim (wq=<optimized out>, fl1h=<optimized out>, msg=msg@entry=0xbf428) at l1_if.c:1144
#11 0x00017e48 in read_dispatch_one (queue=<optimized out>, msg=0xbf428, fl1h=<optimized out>) at l1_transp_hw.c:190
#12 l1if_fd_cb (ofd=0xb86d0, what=<optimized out>) at l1_transp_hw.c:224
#13 0x4fcd6330 in osmo_fd_disp_fds (_eset=0xbefffb48, _wset=0xbefffac8, _rset=0xbefffa48) at select.c:149
#14 osmo_select_main (polling=polling@entry=0) at select.c:189
#15 0x0002bf84 in bts_main (argc=<optimized out>, argv=<optimized out>) at main.c:349
#16 0x4fa61684 in __libc_start_main (main=0xbefffd84, argc=1337463808, argv=0x4fa61684 <__libc_start_main+276>,
init=<optimized out>, fini=0x2ec70 <__libc_csu_fini>, rtld_fini=0x4fa27dc4 <_dl_fini>, stack_end=0xbefffd84) at libc-start.c:269
#17 0x0000b8a4 in _start () at ../ports/sysdeps/arm/start.S:124
(gdb) frame 5
#5 0x0002a680 in l1sap_handover_rach (l1sap=<optimized out>, rach_ind=<optimized out>, rach_ind=<optimized out>,
rach_ind=<optimized out>, trx=0xb6fbd038) at l1sap.c:659
659 l1sap.c: No such file or directory.
#17 0x0000b8a4 in _start () at ../ports/sysdeps/arm/start.S:124
(gdb) frame 5
#5 0x0002a680 in l1sap_handover_rach (l1sap=<optimized out>, rach_ind=<optimized out>, rach_ind=<optimized out>,
rach_ind=<optimized out>, trx=0xb6fbd038) at l1sap.c:659
659 l1sap.c: No such file or directory.
(gdb) p lc
No symbol "lc" in current context.
(gdb) p lc^CQuit
(gdb) p *lchan
value has been optimized out
(gdb) p *rach_ind
value has been optimized out
(gdb) p rach_ind->chan_nr
value has been optimized out
(gdb) frame 6
#6 l1sap_ph_rach_ind (rach_ind=0xbf4fc, l1sap=0xbf4ec, trx=0xb6fbd038) at l1sap.c:974
974 in l1sap.c
(gdb) p *rach_ind
$1 = {chan_nr = 64 '@', ra = 0, acc_delay = 0 '\000', fn = 2107, is_11bit = 0 '\000', burst_type = GSM_L1_BURST_TYPE_ACCESS_0}
(gdb) frame 3
#3 0x000279d4 in ho_tx_phys_info (lchan=lchan@entry=0xb6fc11ec) at handover.c:61
61 handover.c: No such file or directory.
(gdb) p *lchan
$2 = {ts = 0xb6fc08f8, nr = 0 '\000', type = GSM_LCHAN_SDCCH, rsl_cmode = 0, tch_mode = GSM48_CMODE_SIGN, csd_mode = LCHAN_CSD_M_NT,
state = LCHAN_S_NONE, broken_reason = 0x0, bs_power = 0 '\000', ms_power = 0 '\000', encr = {alg_id = 0 '\000',
key_len = 0 '\000', key = '\000' <repeats 15 times>}, mr_ms_lv = "\000\000\000\000\000\000",
mr_bts_lv = "\000\000\000\000\000\000", sapis = "\000\000\000\000\000\000\000", sacch_deact = 0, abis_ip = {bound_ip = 0,
connect_ip = 0, bound_port = 0, connect_port = 0, conn_id = 0, rtp_payload = 0 '\000', rtp_payload2 = 0 '\000',
speech_mode = 0 '\000', rtp_socket = 0x0}, rqd_ta = 0 '\000', name = 0x6b778 "(bts=0,trx=0,ts=0,ss=0)", sapi_cmds = {
next = 0xc0150, prev = 0xc0240}, sapis_dl = '\000' <repeats 22 times>, sapis_ul = '\000' <repeats 22 times>, lapdm_ch = {list = {
next = 0x0, prev = 0x0}, name = 0x0, lapdm_acch = {datalink = {{dl = {send_dlsap = 0x0, send_ph_data_req = 0x0,
update_pending_frames = 0x0, cr = {loc2rem = {cmd = 0 '\000', resp = 0 '\000'}, rem2loc = {cmd = 0 '\000',
resp = 0 '\000'}}, mode = LAPD_MODE_USER, use_sabme = 0, reestablish = 0, n200 = 0, n200_est_rel = 0, lctx = {
dl = 0x0, n201 = 0, cr = 0 '\000', sapi = 0 '\000', tei = 0 '\000', lpd = 0 '\000', format = 0 '\000', p_f = 0 '\000',
n_send = 0 '\000', n_recv = 0 '\000', s_u = 0 '\000', length = 0, more = 0 '\000'}, maxf = 0, k = 0 '\000',
v_range = 0 '\000', v_send = 0 '\000', v_ack = 0 '\000', v_recv = 0 '\000', state = 0, seq_err_cond = 0,
own_busy = 0 '\000', peer_busy = 0 '\000', t200_sec = 0, t200_usec = 0, t203_sec = 0, t203_usec = 0, t200 = {node = {
rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0,
tv_usec = 0}, active = 0, cb = 0x0, data = 0x0}, t203 = {node = {rb_parent_color = 0, rb_right = 0x0,
rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, retrans_ctr = 0 '\000', tx_queue = {next = 0x0, prev = 0x0}, send_queue = {next = 0x0, prev = 0x0},
send_buffer = 0x0, send_out = 0, tx_hist = 0x0, range_hist = 0 '\000', rcv_buffer = 0x0, cont_res = 0x0}, mctx = {
dl = 0x0, lapdm_fmt = 0, chan_nr = 0 '\000', link_id = 0 '\000', ta_ind = 0 '\000', tx_power_ind = 0 '\000'},
entity = 0x0}, {dl = {send_dlsap = 0x0, send_ph_data_req = 0x0, update_pending_frames = 0x0, cr = {loc2rem = {
cmd = 0 '\000', resp = 0 '\000'}, rem2loc = {cmd = 0 '\000', resp = 0 '\000'}}, mode = LAPD_MODE_USER,
use_sabme = 0, reestablish = 0, n200 = 0, n200_est_rel = 0, lctx = {dl = 0x0, n201 = 0, cr = 0 '\000', sapi = 0 '\000',
tei = 0 '\000', lpd = 0 '\000', format = 0 '\000', p_f = 0 '\000', n_send = 0 '\000', n_recv = 0 '\000',
s_u = 0 '\000', length = 0, more = 0 '\000'}, maxf = 0, k = 0 '\000', v_range = 0 '\000', v_send = 0 '\000',
v_ack = 0 '\000', v_recv = 0 '\000', state = 0, seq_err_cond = 0, own_busy = 0 '\000', peer_busy = 0 '\000',
t200_sec = 0, t200_usec = 0, t203_sec = 0, t203_usec = 0, t200 = {node = {rb_parent_color = 0, rb_right = 0x0,
rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, t203 = {node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0},
timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0, data = 0x0}, retrans_ctr = 0 '\000', tx_queue = {
next = 0x0, prev = 0x0}, send_queue = {next = 0x0, prev = 0x0}, send_buffer = 0x0, send_out = 0, tx_hist = 0x0,
range_hist = 0 '\000', rcv_buffer = 0x0, cont_res = 0x0}, mctx = {dl = 0x0, lapdm_fmt = 0, chan_nr = 0 '\000',
link_id = 0 '\000', ta_ind = 0 '\000', tx_power_ind = 0 '\000'}, entity = 0x0}}, last_tx_dequeue = 0, tx_pending = 0,
mode = LAPDM_MODE_MS, flags = 0, l1_ctx = 0x0, l3_ctx = 0x0, l1_prim_cb = 0x0, l3_cb = 0x0, lapdm_ch = 0x0, ta = 0 '\000',
tx_power = 0 '\000'}, lapdm_dcch = {datalink = {{dl = {send_dlsap = 0x0, send_ph_data_req = 0x0, update_pending_frames = 0x0,
cr = {loc2rem = {cmd = 0 '\000', resp = 0 '\000'}, rem2loc = {cmd = 0 '\000', resp = 0 '\000'}}, mode = LAPD_MODE_USER,
use_sabme = 0, reestablish = 0, n200 = 0, n200_est_rel = 0, lctx = {dl = 0x0, n201 = 0, cr = 0 '\000', sapi = 0 '\000',
tei = 0 '\000', lpd = 0 '\000', format = 0 '\000', p_f = 0 '\000', n_send = 0 '\000', n_recv = 0 '\000',
s_u = 0 '\000', length = 0, more = 0 '\000'}, maxf = 0, k = 0 '\000', v_range = 0 '\000', v_send = 0 '\000',
v_ack = 0 '\000', v_recv = 0 '\000', state = 0, seq_err_cond = 0, own_busy = 0 '\000', peer_busy = 0 '\000',
t200_sec = 0, t200_usec = 0, t203_sec = 0, t203_usec = 0, t200 = {node = {rb_parent_color = 0, rb_right = 0x0,
rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, t203 = {node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0},
timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0, data = 0x0}, retrans_ctr = 0 '\000', tx_queue = {
next = 0x0, prev = 0x0}, send_queue = {next = 0x0, prev = 0x0}, send_buffer = 0x0, send_out = 0, tx_hist = 0x0,
range_hist = 0 '\000', rcv_buffer = 0x0, cont_res = 0x0}, mctx = {dl = 0x0, lapdm_fmt = 0, chan_nr = 0 '\000',
link_id = 0 '\000', ta_ind = 0 '\000', tx_power_ind = 0 '\000'}, entity = 0x0}, {dl = {send_dlsap = 0x0,
send_ph_data_req = 0x0, update_pending_frames = 0x0, cr = {loc2rem = {cmd = 0 '\000', resp = 0 '\000'}, rem2loc = {
cmd = 0 '\000', resp = 0 '\000'}}, mode = LAPD_MODE_USER, use_sabme = 0, reestablish = 0, n200 = 0,
n200_est_rel = 0, lctx = {dl = 0x0, n201 = 0, cr = 0 '\000', sapi = 0 '\000', tei = 0 '\000', lpd = 0 '\000',
format = 0 '\000', p_f = 0 '\000', n_send = 0 '\000', n_recv = 0 '\000', s_u = 0 '\000', length = 0, more = 0 '\000'},
maxf = 0, k = 0 '\000', v_range = 0 '\000', v_send = 0 '\000', v_ack = 0 '\000', v_recv = 0 '\000', state = 0,
seq_err_cond = 0, own_busy = 0 '\000', peer_busy = 0 '\000', t200_sec = 0, t200_usec = 0, t203_sec = 0, t203_usec = 0,
t200 = {node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {
tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0, data = 0x0}, t203 = {node = {rb_parent_color = 0, rb_right = 0x0,
rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, retrans_ctr = 0 '\000', tx_queue = {next = 0x0, prev = 0x0}, send_queue = {next = 0x0, prev = 0x0},
send_buffer = 0x0, send_out = 0, tx_hist = 0x0, range_hist = 0 '\000', rcv_buffer = 0x0, cont_res = 0x0}, mctx = {
dl = 0x0, lapdm_fmt = 0, chan_nr = 0 '\000', link_id = 0 '\000', ta_ind = 0 '\000', tx_power_ind = 0 '\000'},
entity = 0x0}}, last_tx_dequeue = 0, tx_pending = 0, mode = LAPDM_MODE_MS, flags = 0, l1_ctx = 0x0, l3_ctx = 0x0,
l1_prim_cb = 0x0, l3_cb = 0x0, lapdm_ch = 0x0, ta = 0 '\000', tx_power = 0 '\000'}}, dl_tch_queue = {next = 0xb6fc16c0,
prev = 0xb6fc16c0}, si = {valid = 0, last = 0, buf = {'\000' <repeats 22 times> <repeats 24 times>}}, meas = {flags = 0 '\000',
res_nr = 0 '\000', bts_tx_pwr = 0 '\000', num_ul_meas = 0 '\000', uplink = {{ber10k = 0, ta_offs_qbits = 0, c_i = 0,
is_sub = 0 '\000', inv_rssi = 0 '\000'} <repeats 104 times>}, l1_info = "\000", ul_res = {full = {rx_lev = 0 '\000',
rx_qual = 0 '\000'}, sub = {rx_lev = 0 '\000', rx_qual = 0 '\000'}}}, tch = {amr_mr = {gsm48_ie = "\000", ms_mode = {{
mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'}, {mode = 0 '\000', threshold = 0 '\000',
hysteresis = 0 '\000'}, {mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'}, {mode = 0 '\000',
threshold = 0 '\000', hysteresis = 0 '\000'}}, bts_mode = {{mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'},
{mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'}, {mode = 0 '\000', threshold = 0 '\000',
hysteresis = 0 '\000'}, {mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'}}, num_modes = 0 '\000'}, dtx = {
dl_amr_fsm = 0x0, cache = '\000' <repeats 19 times>, facch = '\000' <repeats 22 times>, len = 0 '\000', fn = 0,
is_update = false, ul_sid = false, dl_active = false}, last_cmr = 0 '\000', last_fn = 0}, ciph_state = 0 '\000',
ciph_ns = 0 '\000', loopback = 0 '\000', ho = {active = 2 '\002', ref = 0 '\000', t3105 = {node = {rb_parent_color = 0,
rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, phys_info_count = 1}, s = 0, rel_act_kind = 0, rtp_tx_marker = false, ms_power_ctrl = {current = 0 '\000',
fixed = 0 '\000'}}
(gdb) frame 4
#4 0x00027cbc in handover_rach (lchan=0xb6fc11ec, ra=<optimized out>, acc_delay=acc_delay@entry=0 '\000') at handover.c:131
131 in handover.c
(gdb) p ra
$3 = <optimized out>
(gdb)
$4 = <optimized out>
(gdb) c
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
</pre> 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> OsmoPCU - Bug #1640 (Feedback): Missing release field/length in MS RA capability containerhttps://osmocom.org/issues/16402016-03-10T11:29:11Zprasadkg
<p>Description<br />In case of MS RA Capability container "Content_t", there is no dedicated field to denote the existence of 3GPP release in the message. The encoder goes out of max length allowed for release supported and encodes incorrectly. <br />Example vector with failure:<br />vector1 = 40165e000000268ca2a050740440000000300b2b2b2b2b<br />vector2 = 40165e00000026d0a2a0507400000220000000180b2b2b<br />vector1 == vector2 : FALSE</p>
<p>Proposal:<br />For this, we shall have precomputed value of length to terminate the container encoding before calling Content_Dissector in csn1.cpp file. The pre computing length logic routine shall consider the presence of different 3GPP releases.</p>
<p>For example in case of release 5 RA capability message , encoder should be able to code only till release 5 fields . In case of release 6 RA capability, encoder must be able to code till release 6. This release information must be available to the encoder to calculate length. Decoder will set the release field based on the fields present in the message.</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>