Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-01-24T14:24:33ZOpen Source Mobile Communications
Redmine OsmocomBB - Bug #6342 (Feedback): ms-sdr gprs performancehttps://osmocom.org/issues/63422024-01-24T14:24:33ZHoernchen
<p>A simple ping test using using one 74b ping packet per second<br /><pre><code class="shell syntaxhl">ping <span class="nt">-I</span> modem4 google.de
</code></pre><br />Is reliable, but in a very unreliable way:<br /><pre><code class="shell syntaxhl"> ✘ pi5@rp5 ~/bernd/osmo-trx ➦ 669ee04 ± ping <span class="nt">-I</span> modem4 google.de
PING <span class="o">(</span>142.251.36.163<span class="o">)</span> from 176.16.222.14 modem4: 56<span class="o">(</span>84<span class="o">)</span> bytes of data.
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>1 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>1540 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>2 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>587 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>3 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>5486 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>4 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>4530 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>5 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>3584 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>6 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>2620 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>7 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>1656 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>8 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>692 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>9 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>532 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>10 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>654 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>11 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>5593 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>12 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>4621 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>13 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>3675 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>14 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>2711 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>15 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>1747 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>16 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>783 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>17 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>623 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>18 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>745 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>19 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>5703 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>20 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>4732 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>21 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>3791 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>22 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>2827 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>23 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>1863 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>24 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>899 ms
64 bytes from muc12s11-in-f3.1e100.net <span class="o">(</span>142.251.36.163<span class="o">)</span>: <span class="nv">icmp_seq</span><span class="o">=</span>25 <span class="nv">ttl</span><span class="o">=</span>117 <span class="nb">time</span><span class="o">=</span>740 ms
^C
<span class="nt">---</span> ping statistics <span class="nt">---</span>
26 packets transmitted, 25 received, 3.84615% packet loss, <span class="nb">time </span>25381ms
rtt min/avg/max/mdev <span class="o">=</span> 532.376/2517.521/5703.264/1774.915 ms, pipe 6
</code></pre></p>
<p>The transfer is chunky and stalls all the time, it always repeats the same block of messages:<br /><pre><code class="shell syntaxhl">snibedi snab 8< 8< 8<
20240124150628408 DL1C INFO l1ctl.c:754 Tx Reset Req <span class="o">(</span>1<span class="o">)</span>
20240124150628408 DL1C INFO l1ctl.c:404 Sync Req
20240124150628410 DL1C INFO l1ctl.c:764 Layer1 Reset indication
20240124150628410 DCS NOTICE app_modem.c:219 S_L1CTL_RESET
20240124150628441 DL1C INFO l1ctl.c:138 <span class="nv">snr</span><span class="o">=</span>0000, <span class="nv">arfcn</span><span class="o">=</span>871 <span class="nv">result</span><span class="o">=</span>0
20240124150628441 DCS NOTICE app_modem.c:243 S_L1CTL_FBSB_RESP
20240124150628510 DRR NOTICE grr.c:583 GPRS-RR<span class="o">(</span>1<span class="o">)[</span>0x55678c25b0]<span class="o">{</span>PACKET_NOT_READY<span class="o">}</span>: Cell is usable, GRR becomes ready
20240124150628551 DRR NOTICE grr.c:683 GPRS-RR<span class="o">(</span>1<span class="o">)[</span>0x55678c25b0]<span class="o">{</span>PACKET_ACCESS<span class="o">}</span>: Rx RACH.conf <span class="o">(</span><span class="nv">RA</span><span class="o">=</span>0x79, <span class="nv">T1</span><span class="o">=</span>6, <span class="nv">T3</span><span class="o">=</span>14, <span class="nv">T2</span><span class="o">=</span>23, <span class="nv">FN</span><span class="o">=</span>8837<span class="o">)</span>
20240124150628734 DTUN DEBUG app_modem.c:122 APN<span class="o">(</span>internet<span class="o">)</span>: system wants to transmit IPv4 pkt to 142.251.36.163 <span class="o">(</span>84 bytes<span class="o">)</span>
20240124150628734 DSNDCP INFO sndcp_prim.c:426 Rx from upper layers: SN-UNITDATA.request
20240124150628764 DL1C INFO l1ctl.c:553 Tx Dedic.Mode Est Req <span class="o">(</span><span class="nv">arfcn</span><span class="o">=</span>979, <span class="nv">chan_nr</span><span class="o">=</span>0xc3<span class="o">)</span>
20240124150628822 DGMM INFO gmm_prim.c:677 Rx from lower layers: GMRR-LLC_TRANSMITTED.indication
20240124150628822 DGMM INFO gmm.c:311 GMME<span class="o">(</span>IMSI-001010000000000:PTMSI-d041daef:TLLI-d041daef<span class="o">)</span> READY timer started <span class="o">(</span>expires <span class="k">in </span>44 seconds<span class="o">)</span>
20240124150628882 DGMM INFO gmm_prim.c:677 Rx from lower layers: GMRR-LLC_TRANSMITTED.indication
20240124150628882 DGMM INFO gmm.c:311 GMME<span class="o">(</span>IMSI-001010000000000:PTMSI-d041daef:TLLI-d041daef<span class="o">)</span> READY timer started <span class="o">(</span>expires <span class="k">in </span>44 seconds<span class="o">)</span>
20240124150628942 DGMM INFO gmm_prim.c:677 Rx from lower layers: GMRR-LLC_TRANSMITTED.indication
20240124150628942 DGMM INFO gmm.c:311 GMME<span class="o">(</span>IMSI-001010000000000:PTMSI-d041daef:TLLI-d041daef<span class="o">)</span> READY timer started <span class="o">(</span>expires <span class="k">in </span>44 seconds<span class="o">)</span>
20240124150629021 DGMM INFO gmm_prim.c:677 Rx from lower layers: GMRR-LLC_TRANSMITTED.indication
20240124150629021 DGMM INFO gmm.c:311 GMME<span class="o">(</span>IMSI-001010000000000:PTMSI-d041daef:TLLI-d041daef<span class="o">)</span> READY timer started <span class="o">(</span>expires <span class="k">in </span>44 seconds<span class="o">)</span>
20240124150629098 DGMM INFO gmm_prim.c:677 Rx from lower layers: GMRR-LLC_TRANSMITTED.indication
20240124150629098 DGMM INFO gmm.c:311 GMME<span class="o">(</span>IMSI-001010000000000:PTMSI-d041daef:TLLI-d041daef<span class="o">)</span> READY timer started <span class="o">(</span>expires <span class="k">in </span>44 seconds<span class="o">)</span>
20240124150629159 DGMM INFO gmm_prim.c:677 Rx from lower layers: GMRR-LLC_TRANSMITTED.indication
20240124150629159 DGMM INFO gmm.c:311 GMME<span class="o">(</span>IMSI-001010000000000:PTMSI-d041daef:TLLI-d041daef<span class="o">)</span> READY timer started <span class="o">(</span>expires <span class="k">in </span>44 seconds<span class="o">)</span>
20240124150629200 DSNDCP INFO sndcp_prim.c:594 Rx from lower layers: LL-UNITDATA.indication
20240124150629260 DSNDCP INFO sndcp_prim.c:594 Rx from lower layers: LL-UNITDATA.indication
20240124150629338 DSNDCP INFO sndcp_prim.c:594 Rx from lower layers: LL-UNITDATA.indication
20240124150629398 DSNDCP INFO sndcp_prim.c:594 Rx from lower layers: LL-UNITDATA.indication
20240124150629458 DSNDCP INFO sndcp_prim.c:594 Rx from lower layers: LL-UNITDATA.indication
20240124150629518 DSNDCP INFO sndcp_prim.c:594 Rx from lower layers: LL-UNITDATA.indication
20240124150629735 DTUN DEBUG app_modem.c:122 APN<span class="o">(</span>internet<span class="o">)</span>: system wants to transmit IPv4 pkt to 142.251.36.163 <span class="o">(</span>84 bytes<span class="o">)</span>
20240124150629735 DSNDCP INFO sndcp_prim.c:426 Rx from upper layers: SN-UNITDATA.request
20240124150630119 DGMM INFO gmm_prim.c:677 Rx from lower layers: GMRR-LLC_TRANSMITTED.indication
20240124150630119 DGMM INFO gmm.c:311 GMME<span class="o">(</span>IMSI-001010000000000:PTMSI-d041daef:TLLI-d041daef<span class="o">)</span> READY timer started <span class="o">(</span>expires <span class="k">in </span>44 seconds<span class="o">)</span>
20240124150630358 DSNDCP INFO sndcp_prim.c:594 Rx from lower layers: LL-UNITDATA.indication
20240124150630735 DTUN DEBUG app_modem.c:122 APN<span class="o">(</span>internet<span class="o">)</span>: system wants to transmit IPv4 pkt to 142.251.36.163 <span class="o">(</span>84 bytes<span class="o">)</span>
20240124150630735 DSNDCP INFO sndcp_prim.c:426 Rx from upper layers: SN-UNITDATA.request
20240124150631240 DGMM INFO gmm_prim.c:677 Rx from lower layers: GMRR-LLC_TRANSMITTED.indication
20240124150631240 DGMM INFO gmm.c:311 GMME<span class="o">(</span>IMSI-001010000000000:PTMSI-d041daef:TLLI-d041daef<span class="o">)</span> READY timer started <span class="o">(</span>expires <span class="k">in </span>44 seconds<span class="o">)</span>
20240124150631480 DSNDCP INFO sndcp_prim.c:594 Rx from lower layers: LL-UNITDATA.indication
20240124150631736 DTUN DEBUG app_modem.c:122 APN<span class="o">(</span>internet<span class="o">)</span>: system wants to transmit IPv4 pkt to 142.251.36.163 <span class="o">(</span>84 bytes<span class="o">)</span>
20240124150631736 DSNDCP INFO sndcp_prim.c:426 Rx from upper layers: SN-UNITDATA.request
20240124150632766 DTUN DEBUG app_modem.c:122 APN<span class="o">(</span>internet<span class="o">)</span>: system wants to transmit IPv4 pkt to 142.251.36.163 <span class="o">(</span>84 bytes<span class="o">)</span>
20240124150632766 DSNDCP INFO sndcp_prim.c:426 Rx from upper layers: SN-UNITDATA.request
20240124150633790 DTUN DEBUG app_modem.c:122 APN<span class="o">(</span>internet<span class="o">)</span>: system wants to transmit IPv4 pkt to 142.251.36.163 <span class="o">(</span>84 bytes<span class="o">)</span>
20240124150633790 DSNDCP INFO sndcp_prim.c:426 Rx from upper layers: SN-UNITDATA.request
20240124150634814 DTUN DEBUG app_modem.c:122 APN<span class="o">(</span>internet<span class="o">)</span>: system wants to transmit IPv4 pkt to 142.251.36.163 <span class="o">(</span>84 bytes<span class="o">)</span>
20240124150634814 DSNDCP INFO sndcp_prim.c:426 Rx from upper layers: SN-UNITDATA.request
20240124150635838 DTUN DEBUG app_modem.c:122 APN<span class="o">(</span>internet<span class="o">)</span>: system wants to transmit IPv4 pkt to 142.251.36.163 <span class="o">(</span>84 bytes<span class="o">)</span>
20240124150635838 DSNDCP INFO sndcp_prim.c:426 Rx from upper layers: SN-UNITDATA.request
20240124150636600 DRLCMAC NOTICE tbf_dl.c:103 TBF<span class="o">(</span>DL:NR-5:TLLI-d041daef<span class="o">)</span> Timeout of T3190
snibedi snab 8< 8< 8<
loops here
</code></pre></p>
<pre><code class="shell syntaxhl">curl <span class="nt">--interface</span> modem4 http://fsn.icmp.hetzner.com/1GB.bin <span class="nt">-o</span> /dev/null
</code></pre><br />Fails completely, probably for the same reason.
<p>pcap contains debug log level messages.</p>
<p>all of this is with multislot-class default 1 pcu config.</p> OsmocomBB - Bug #6338 (Feedback): ms-sdr gprs startup issueshttps://osmocom.org/issues/63382024-01-23T12:27:41ZHoernchen
<p>Most of the time the startup fails at the assignment stage, see attached log & pcap (mssdr.log continues like this indefinitely)</p> libosmocore - Bug #6233 (Feedback): --enable-embedded build fails if pkg-config can't find some o...https://osmocom.org/issues/62332023-10-22T16:25:58ZHoernchen
<pre><code class="bash syntaxhl">./configure <span class="nt">--disable-doxygen</span> <span class="nt">--disable-detect-tls-gcc-arm-bug</span> <span class="nt">--enable-embedded</span>
<span class="o">[</span>snibedi snab]
checking <span class="k">for </span>liburing <span class="o">>=</span> 0.7... no
configure: error: Package requirements <span class="o">(</span>liburing <span class="o">>=</span> 0.7<span class="o">)</span> were not met:
Package <span class="s1">'liburing'</span>, required by <span class="s1">'virtual:world'</span>, not found
Consider adjusting the PKG_CONFIG_PATH environment variable <span class="k">if </span>you
installed software <span class="k">in </span>a non-standard prefix.
Alternatively, you may <span class="nb">set </span>the environment variables URING_CFLAGS
</code></pre> OsmocomBB - Bug #6200 (New): osmo-trx-ms: lots of @Received bad frame (rc=-1, ber=444/444)@https://osmocom.org/issues/62002023-10-03T16:46:40Zfixeria
<p>Hi <a class="user active" href="https://osmocom.org/users/52">Hoernchen</a>,</p>
<p>we had a debugging session with <a class="user active" href="https://osmocom.org/users/30187">pespin</a> today and we got the mssdr-ms side to work more or less reliably. But we noticed a weird problem:</p>
<pre>
20231003152951965 DL1C NOTICE trxcon(0)[0x5579a42900]{BCCH_CCCH}: L1CTL_DM_EST_REQ indicates single ARFCN GSM900 979 (l1ctl.c:572)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Reset scheduler (sched_trx.c:190)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Delete TDMA timeslot #0 (sched_trx.c:226)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Add a new TDMA timeslot #4 (sched_trx.c:207)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: (Re)configure TDMA timeslot #4 as PDCH (sched_trx.c:276)
20231003152951966 DSCH NOTICE trxcon(0)[0x5579a42900]: TS4-PDTCH activating (sched_trx.c:476)
20231003152951966 DSCH NOTICE trxcon(0)[0x5579a42900]: TS4-PTCCH activating (sched_trx.c:476)
20231003152953364 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=86/456) at fn=513573 (sched_lchan_pdtch.c:94)
20231003152954366 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=87/456) at fn=513790 (sched_lchan_pdtch.c:94)
20231003152954804 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513885 (sched_lchan_pdtch.c:94)
20231003152954827 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513890 (sched_lchan_pdtch.c:94)
20231003152954846 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513894 (sched_lchan_pdtch.c:94)
20231003152954864 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513898 (sched_lchan_pdtch.c:94)
20231003152954887 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513903 (sched_lchan_pdtch.c:94)
20231003152954906 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513907 (sched_lchan_pdtch.c:94)
20231003152954924 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513911 (sched_lchan_pdtch.c:94)
20231003152954947 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513916 (sched_lchan_pdtch.c:94)
20231003152954966 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513920 (sched_lchan_pdtch.c:94)
20231003152954984 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513924 (sched_lchan_pdtch.c:94)
20231003152955007 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513929 (sched_lchan_pdtch.c:94)
20231003152955025 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513933 (sched_lchan_pdtch.c:94)
20231003152955044 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513937 (sched_lchan_pdtch.c:94)
20231003152955067 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513942 (sched_lchan_pdtch.c:94)
20231003152955085 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513946 (sched_lchan_pdtch.c:94)
20231003152955104 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513950 (sched_lchan_pdtch.c:94)
20231003152955127 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513955 (sched_lchan_pdtch.c:94)
20231003152955145 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513959 (sched_lchan_pdtch.c:94)
20231003152955164 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513963 (sched_lchan_pdtch.c:94)
20231003152955188 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513968 (sched_lchan_pdtch.c:94)
20231003152955205 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513972 (sched_lchan_pdtch.c:94)
20231003152955224 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513976 (sched_lchan_pdtch.c:94)
20231003152955248 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513981 (sched_lchan_pdtch.c:94)
20231003152955265 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513985 (sched_lchan_pdtch.c:94)
20231003152955284 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513989 (sched_lchan_pdtch.c:94)
20231003152955308 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513994 (sched_lchan_pdtch.c:94)
20231003152955325 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513998 (sched_lchan_pdtch.c:94)
20231003152955344 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514002 (sched_lchan_pdtch.c:94)
20231003152955368 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514007 (sched_lchan_pdtch.c:94)
20231003152955385 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514011 (sched_lchan_pdtch.c:94)
20231003152955404 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514015 (sched_lchan_pdtch.c:94)
</pre>
<p>It's not seen during the GMM ATTACH and SM PDP CTX ACT procedures, but only when we tried sending some data (ICMP ping) over the tun interface.<br />As can be seen, quite a lot of Downlink PDCH blocks not being decoded. The <code>BER=444/444</code> makes me think that received bursts were all 0 (neither -127 nor 127).<br />This is enlarging the ping delays significantly (from ~600ms to ~5000ms ==> ~10 times):</p>
<pre>
PING 176.16.222.1 (176.16.222.1) 56(84) bytes of data.
64 bytes from 176.16.222.1: icmp_seq=1 ttl=64 time=681 ms
64 bytes from 176.16.222.1: icmp_seq=2 ttl=64 time=803 ms
64 bytes from 176.16.222.1: icmp_seq=3 ttl=64 time=625 ms
64 bytes from 176.16.222.1: icmp_seq=4 ttl=64 time=525 ms
64 bytes from 176.16.222.1: icmp_seq=5 ttl=64 time=5646 ms
64 bytes from 176.16.222.1: icmp_seq=6 ttl=64 time=4678 ms
64 bytes from 176.16.222.1: icmp_seq=7 ttl=64 time=3911 ms
64 bytes from 176.16.222.1: icmp_seq=8 ttl=64 time=2948 ms
64 bytes from 176.16.222.1: icmp_seq=9 ttl=64 time=1984 ms
64 bytes from 176.16.222.1: icmp_seq=10 ttl=64 time=1020 ms
64 bytes from 176.16.222.1: icmp_seq=11 ttl=64 time=602 ms
64 bytes from 176.16.222.1: icmp_seq=12 ttl=64 time=742 ms
64 bytes from 176.16.222.1: icmp_seq=13 ttl=64 time=5741 ms
64 bytes from 176.16.222.1: icmp_seq=14 ttl=64 time=4769 ms
64 bytes from 176.16.222.1: icmp_seq=15 ttl=64 time=3824 ms
64 bytes from 176.16.222.1: icmp_seq=16 ttl=64 time=2860 ms
64 bytes from 176.16.222.1: icmp_seq=17 ttl=64 time=1896 ms
64 bytes from 176.16.222.1: icmp_seq=18 ttl=64 time=932 ms
64 bytes from 176.16.222.1: icmp_seq=19 ttl=64 time=813 ms
64 bytes from 176.16.222.1: icmp_seq=20 ttl=64 time=653 ms
64 bytes from 176.16.222.1: icmp_seq=21 ttl=64 time=5630 ms
64 bytes from 176.16.222.1: icmp_seq=22 ttl=64 time=4658 ms
64 bytes from 176.16.222.1: icmp_seq=23 ttl=64 time=3893 ms
64 bytes from 176.16.222.1: icmp_seq=24 ttl=64 time=2929 ms
64 bytes from 176.16.222.1: icmp_seq=25 ttl=64 time=1969 ms
64 bytes from 176.16.222.1: icmp_seq=26 ttl=64 time=1005 ms
64 bytes from 176.16.222.1: icmp_seq=27 ttl=64 time=546 ms
64 bytes from 176.16.222.1: icmp_seq=28 ttl=64 time=686 ms
</pre>
<p>This looks like a PHY problem to me, so assigning to you.</p> libosmocore - Bug #6162 (Feedback): master build failure with clang-16https://osmocom.org/issues/61622023-08-31T12:34:52ZHoernchen
<pre><code class="shell syntaxhl"> CC osmo_io_uring.lo
osmo_io_uring.c:324:29: error: incompatible pointer to integer conversion passing <span class="s1">'void *'</span> to parameter of <span class="nb">type</span> <span class="s1">'__u64'</span> <span class="o">(</span>aka <span class="s1">'unsigned long long'</span><span class="o">)</span> <span class="o">[</span><span class="nt">-Wint-conversion</span><span class="o">]</span>
324 | io_uring_prep_cancel<span class="o">(</span>sqe, iofd->u.uring.read_msghdr, 0<span class="o">)</span><span class="p">;</span>
| ^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/liburing.h:542:12: note: passing argument to parameter <span class="s1">'user_data'</span> here
542 | __u64 user_data, int flags<span class="o">)</span>
| ^
osmo_io_uring.c:332:29: error: incompatible pointer to integer conversion passing <span class="s1">'void *'</span> to parameter of <span class="nb">type</span> <span class="s1">'__u64'</span> <span class="o">(</span>aka <span class="s1">'unsigned long long'</span><span class="o">)</span> <span class="o">[</span><span class="nt">-Wint-conversion</span><span class="o">]</span>
332 | io_uring_prep_cancel<span class="o">(</span>sqe, iofd->u.uring.write_msghdr, 0<span class="o">)</span><span class="p">;</span>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/liburing.h:542:12: note: passing argument to parameter <span class="s1">'user_data'</span> here
542 | __u64 user_data, int flags<span class="o">)</span>
| ^
2 errors generated.
make[4]: <span class="k">***</span> <span class="o">[</span>Makefile:714: osmo_io
</code></pre> libosmocore - Bug #6021 (New): map file breaks recent lld buildshttps://osmocom.org/issues/60212023-05-02T08:49:54ZHoernchen
<p>lld defaults to --no-undefined-version since <a class="external" href="https://reviews.llvm.org/D135402">https://reviews.llvm.org/D135402</a> which breaks building if not all symbols mentioned in the map file exist, i.e. by building libosmocore without systemd. Fix: add -Wl,--undefined-version to the LDFLAGS.</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> OsmoBSCNAT - Bug #5574 (New): OsmoBSCNAT testsuite running in jenkinshttps://osmocom.org/issues/55742022-06-01T10:38:54Zosmith
<p>As discussed earlier, OsmoBSCNAT ttcn3 tests should be running in jenkins, like for other Osmocom projects.</p> OsmoTRX - Bug #5178 (New): LimeNET Micro clock errorhttps://osmocom.org/issues/51782021-06-12T19:25:29ZAnelito
<p>Running the example setup listed below fails on a LimeNET Micro v2.1 because of internal clock error.<br />Reference guide: [[<a class="external" href="https://lucasteske.medium.com/creating-your-own-gsm-network-with-limesdr-1935bac257f4">https://lucasteske.medium.com/creating-your-own-gsm-network-with-limesdr-1935bac257f4</a>]]</p>
<pre><code>$ sudo osmo-trx-lms<br /> % 'rt-prio 18' is deprecated, use 'policy rr 18' under 'sched' node instead<br /> Sat Jun 12 10:00:30 2021 DLGLOBAL &lt;0008&gt; telnet_interface.c:104 Available via telnet 127.0.0.1 4237<br /> Sat Jun 12 10:00:30 2021 DLCTRL &lt;000f&gt; control_if.c:887 CTRL at 127.0.0.1 4236<br /> Sat Jun 12 10:00:30 2021 DMAIN &lt;0000&gt; osmo-trx.cpp:563 Config Settings<br /> Log Level............... 0<br /> Device args............. <br /> TRX Base Port........... 5700<br /> TRX Address............. 127.0.0.1<br /> GSM BTS Address......... 127.0.0.1<br /> Channels................ 1<br /> Tx Samples-per-Symbol... 4<br /> Rx Samples-per-Symbol... 4<br /> EDGE support............ 0<br /> Extended RACH support... 0<br /> Reference............... 0<br /> Filler Burst Type....... Empty bursts<br /> Filler Burst TSC........ 0<br /> Filler Burst RACH Delay. 0<br /> Multi-Carrier........... 0<br /> LO freq. offset......... 0<br /> RSSI to dBm offset...... 0 (relative)<br /> Swap channels........... 0<br /> Tx Antennas............. 'BAND1'<br /> Rx Antennas............. 'LNAW'</code></pre>
<pre><code>Sat Jun 12 10:00:30 2021 DMAIN &lt;0000&gt; osmo-trx.cpp:481 Setting SCHED_RR priority 18. This setting is DEPRECATED, please use 'policy rr 18' under the 'sched' VTY node instead.<br /> Sat Jun 12 10:00:30 2021 DDEV &lt;0005&gt; LMSDevice.cpp:140 creating LMS device...<br /> Sat Jun 12 10:00:30 2021 DDEV &lt;0005&gt; LMSDevice.cpp:272 Opening LMS device..<br /> Sat Jun 12 10:00:30 2021 DDEV &lt;0005&gt; LMSDevice.cpp:278 Devices found: 1<br /> Sat Jun 12 10:00:30 2021 DDEV &lt;0005&gt; LMSDevice.cpp:288 Device [0]: LimeNET-Micro, media=USB 2.0, module=FT601, addr=24607:1027, serial=005839EC8507E7<br /> Sat Jun 12 10:00:30 2021 DDEV &lt;0005&gt; LMSDevice.cpp:297 Using device[0]<br /> Sat Jun 12 10:00:30 2021 DDEVDRV &lt;0006&gt; LMSDevice.cpp:187 Reference clock 30.72 MHz<br /> Sat Jun 12 10:00:30 2021 DDEV &lt;0005&gt; LMSDevice.cpp:126 Device identified as LimeNET-Micro<br /> Sat Jun 12 10:00:30 2021 DDEV &lt;0005&gt; LMSDevice.cpp:324 Init LMS device<br /> Sat Jun 12 10:00:31 2021 DDEV &lt;0005&gt; LMSDevice.cpp:332 Setting Internal clock reference<br /> Sat Jun 12 10:00:31 2021 DDEV &lt;0005&gt; LMSDevice.cpp:482 Device type LimeNET-Micro doesn't support internal reference clock<br /> Sat Jun 12 10:00:31 2021 DDEV &lt;0005&gt; LMSDevice.cpp:377 Error in LMS open, closing: <br /> Sat Jun 12 10:00:31 2021 DMAIN &lt;0000&gt; osmo-trx.cpp:597 Failed to create radio device<br /> Sat Jun 12 10:00:31 2021 DMAIN &lt;0000&gt; osmo-trx.cpp:568 Shutting down transceiver...<br /> Sat Jun 12 10:00:31 2021 DDEV &lt;0005&gt; LMSDevice.cpp:158 Closing LMS device</code></pre> OsmoMSC - Bug #5057 (New): Can only send a maximum of 15 SMPP messages?https://osmocom.org/issues/50572021-03-03T02:53:02Zoxenff
<p>I am currently using SMPP to send SMS messages to a device connected to my GSM Core Network ( via LTE ).</p>
<p>For some strange reason however, once the MSC sends 15 messages, they stop and I can't send anymore.</p>
<p>I've had a pretty extensive search around the code as to why this might be happening but can't for the life of me work out why.</p>
<p>This was not an issue when using the previous OpenBSC SMPP ( 0.15.0 ).</p>
<p>Any help would be greatly appreciated !</p> osmo-qcdiag - Bug #4781 (New): get hoernchen/gsmtap branch mergedhttps://osmocom.org/issues/47812020-10-06T15:09:14Zlaforge
<p>I had no idea that this work from May had not undergone some patch submission to gerrit so far.</p>
<p>It should go without saying that we always want to make sure that our work ends up in the master branch, as far as possible.</p>
Please split up in per-feature patches and push them to gerrit. Looking at the code, that could fore xample be:
<ul>
<li>support for LTE RRC</li>
<li>getopt parsing</li>
<li>SIGINT/SIGTERM handling to close gracefully</li>
<li>UMTS RRM gsmtap support (possibly including cell_id tracking)</li>
<li>UMTS NAS gsmtap support</li>
<li>introduction of diag_instance as first parameter to handle_* functions</li>
<li>GSM RR gsmtap support</li>
<li>GSM GMM gsmtap support</li>
<li>GPRS MAC gsmtap support</li>
<li>DIAG I/O fies</li>
</ul>
<p>In the end, the customer/usage/application specific patch could consist of mainly adding some #ifdefs to disable/enable handling of specific features. That patch can stay in a branch, but all of the general improvements should be merged master.</p>
<p>Thanks!</p> osmo-ccid-firmware - Bug #4777 (New): Reader does not answer to GET DATA RATES commandhttps://osmocom.org/issues/47772020-10-03T16:11:03Zrousseau
<p>If I use the parse tool from my CCID driver to get the supported clock list I get:<br /><a class="external" href="https://ccid.apdu.fr/#CCID_compliant">https://ccid.apdu.fr/#CCID_compliant</a></p>
<pre>
bNumDataRatesSupported: 0 (will use whatever is returned)
IFD does not support GET_DATA_RATES request: LIBUSB_ERROR_TIMEOUT
</pre>
<p>Since the value of bNumDataRatesSupported is 0 an empty list as answer would be perfect instead of a timeout.</p>
<p>The CCID spec says: "A CCID with bNumDataRatesSupported equal to 00h does not have to support this request." so the reader is stil compliant to the CICD specification. But an answer would be fine.</p> osmo-ccid-firmware - Bug #4776 (New): Reader does not answer to GET CLOCK FREQUENCIES commandhttps://osmocom.org/issues/47762020-10-03T16:05:18Zrousseau
<p>If I use the parse tool from my CCID driver to get the supported clock list I get:</p>
<pre>
bNumClockSupported: 4
IFD does not support GET CLOCK FREQUENCIES request: LIBUSB_ERROR_TIMEOUT
</pre>
<p>I expected a list of 4 values.</p>
<p>This command is described in CCID v1.1 chapter '5.3.2 GET_CLOCK_FREQUENCIES' page 24.</p> OsmoTRX - Bug #4622 (New): Lots of "dumping STALE burst in TRX->SDR interface" messages in osmo-t...https://osmocom.org/issues/46222020-06-18T17:01:52Zpespin
<p>Running osmo-bts-trx with osmo-trx-uhd using a B200 with multi-arfcn enabled and 2 TRX.<br />Then osmo-bts-trx enters a "graceful exit" due to Abis signal lost (eg: kill BSC process). As part of "graceful exit", BTS will ramp down power, and finally send CMD POWEROFF and wait for RSP POWEROFF before exiting the process.<br />At this point in time, osmo-trx is still running waiting for next osmo-bts-trx to connect to it and do a "POWERON".<br />When osmo-bts-trx is restarted and connects to it after a few seconds, and does the "POWERON", then LOTS of messages like this show up in the log during a few seconds/minutes</p>
<p>Remark: I'm using my WIP branch to have all those graceful shutdown features I'm mentioning, but they will be merged soon and they are not the "cause" of the issue.</p>
<p>So clearly there's something wrong during 2nd POWERON (POWERON->POWEROFF->wait some time->POWERON). Probably some state is kept regarding reading timestamps and then upon 2nd POWERON osmo-trx somehow tries to catch up.<br /><pre>
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967881 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967881 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967881 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967881 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967883 vs 5:967952), retrans=0
20200618185527592 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967881 vs 6:967952), retrans=0
20200618185527596 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967882 vs 4:967953), retrans=0
20200618185527596 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967882 vs 4:967953), retrans=0
20200618185527596 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967884 vs 4:967953), retrans=0
20200618185527596 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967882 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967882 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967882 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967882 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967884 vs 5:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967882 vs 6:967953), retrans=0
20200618185527597 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967882 vs 6:967953), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967883 vs 4:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967885 vs 4:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967883 vs 5:967954), retrans=0
20200618185527601 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967885 vs 5:967954), retrans=0
20200618185527602 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967883 vs 6:967954), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967884 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967886 vs 5:967955), retrans=0
20200618185527606 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967886 vs 5:967955), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967885 vs 5:967956), retrans=0
20200618185527610 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967885 vs 5:967956), retrans=0
20200618185527611 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967885 vs 5:967956), retrans=0
20200618185527611 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967885 vs 5:967956), retrans=0
20200618185527611 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967887 vs 5:967956), retrans=0
20200618185527611 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967887 vs 5:967956), retrans=0
20200618185527614 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967886 vs 4:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (6:967888 vs 4:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (5:967886 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=1] dumping STALE burst in TRX->SDR interface (7:967888 vs 5:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (6:967886 vs 6:967957), retrans=0
20200618185527615 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (7:967886 vs 6:967957), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (0:967887 vs 5:967958), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (1:967887 vs 5:967958), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (2:967887 vs 5:967958), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (3:967887 vs 5:967958), retrans=0
20200618185527620 DTRXDDL <0003> Transceiver.cpp:428 [tid=139983326238464][chan=0] dumping STALE burst in TRX->SDR interface (4:967887 vs 5:967958), retrans=0
</pre></p> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://osmocom.org/issues/45992020-06-08T18:05:33Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:</p>
<pre>
<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.
</pre>
<p>I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.</p>
<p>The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.</p>
<p><a class="user active" href="https://osmocom.org/users/1741">lynxis</a> any ideas?</p> OsmoTRX - Bug #4468 (Feedback): "RSSI offset" default of 0 is not usefulhttps://osmocom.org/issues/44682020-03-21T20:18:54Zlaforge
<p>The "rssi offset" value that can be configured via the VTY and command line arguments is initialized to a default of 0.</p>
<p>This does not work out at all, at the very least it's proven to be bogus on the popular USRP B2xx hardware in DCS 1800 (See <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: bad voice quality in current osmo-bts-trx master (Closed)" href="https://osmocom.org/issues/4467">#4467</a>). I would acually be surprised if it's correct on any hardware at all.</p>
<p>In an ideal world, every GPSDR vendor would ship every unit together with a proper calibration table over frequency, so that a power level as seen in the I/Q samples can be translated into an absolute value in dBm.</p>
<p>However, the world is far from ideal, and the best we can do is try to measure this offset for the few commonly used devices we have available (B200, B210, N200, LimeSDR-mini, LimeSDR USB) and then use that value instead of '0'.</p>
<p>We may need a value per band (particularly on LMS where different bands go thorugh different RF paths), and it will of course also change depending on how the hardware receive gains/LNAs are configured. Also, it will drift over frequency within the band, and it will of course have a spread across different units of a given device type.</p>
<p>However, I guess anything is better than "0" at this point.</p> osmo-remsim - Bug #4409 (Stalled): osmo-remsim-client-st2 (or firmware?) gets stuck on PTShttps://osmocom.org/issues/44092020-02-20T21:02:21Zlaforge
<p>In the test setup at my home office, I can occasionally see osmo-remsim-client-st2 get stuck when the Modem (in this case a Quectel EC20) is performing PTS with the card.</p>
<p>In the log of osmo-remsim-client-st2 I can see:<br /><pre>
SIMtrace => PTS req: ff 10 94 7b 00 00 ^M
SIMtrace -> 01 07 00 00 00 00 15 00 04 ff 10 94 7b 00 00 ff 10 94 7b ^M
SIMtrace => PTS req: ff 10 94 7b 00 00 ^M
SIMtrace IRQ 01 04 00 00 00 00 15 00 13 00 00 00 00 00 09 04 0a 80 25 00 00 ^M
</pre></p>
<p>after which the communication doens't proceed. After a long time, the modem seems to retry without PTS and then proceeds with normal SIM card communication.</p>
<p>The SIM Card ATR in this case is 3b7d9400005555530a7486930b247c4d5468.</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> libosmo-sccp + libosmo-sigtran - Bug #4072 (New): Implement IPA PING/PONG mechanism in libosmo-si...https://osmocom.org/issues/40722019-06-21T14:51:56Zlaforge
<p>When using an IPA based transport (SCCPlite), we should use the IPA PING/PONG mechanism to check the peer is still alive. This applies both to the server (SGW) and client (AS/ASP) roles.</p> SIMtrace 2 - Bug #3815 (New): simtrace2 fails USB-IF CH9 testhttps://osmocom.org/issues/38152019-02-23T15:10:02Zlaforge
<p>When running the Chapter9 tests of the USB IF against a simtrace2 device, they fail. The test claims SET_CONFIGURATION is failing, which is quite odd.</p> OsmoTRX - Bug #3342 (Stalled): osmo-trx-lms: low tx output power levelhttps://osmocom.org/issues/33422018-06-13T16:56:06Zlaforge
<p>According to <a class="external" href="https://discourse.myriadrf.org/t/limesdr-s-maximum-transmitting-power-at-different-frequencies/1649">https://discourse.myriadrf.org/t/limesdr-s-maximum-transmitting-power-at-different-frequencies/1649</a> I would expect something like 3-5dBm maximum output power at 1.8 GHz.</p>
<p>Hoewever, when running at ARFCN 871, and even when manually patching <code>LMS_SetNormalizedGain(m_lms_dev, LMS_CH_TX, chan, 1.0);</code> into the osmo-trx-lms source code, I'm not seeing more than -3.8 dB coming out of the TX1_1 port of the device. Where does that 6..8 dB difference come from?</p> Cellular Network Infrastructure - Feature #3229 (New): build-system: jenkins.sh: Improve debian ...https://osmocom.org/issues/32292018-05-03T12:40:28Zpespin
<p>The idea is to add extra tests/checks to avoid breaking debian package building during nightly builds in OBS. Instead, let's catch it during gerrit patch submission time and don't allow merging it until it's fixed.</p>
<p>We should investigate several tools, like pbuilder, dpkg-build, etc. I recall lynxis also told me something about some kind of lint tool available for this purposes.</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 #2933 (New): change of trans->bearer_cap (e.g. via MNCC) will not trigger BSSMAP AS...https://osmocom.org/issues/29332018-02-12T11:36:39Zlaforge
<p>Whenever the trans->bearer_cap change (e.g.due to a CC MODIFY or MNCC MODIFY), the MSC must chck if the new bearer capabilities are different from the old bearer capabilities, and subsequently trigger a BSSMAP ASSIGNMENT towards the BSS.</p>
<p>Currently, the handling of bearer_cap will in only work if the related CC/MNCC message with <br />besrer_cap IE happens before the pint in time at which the MSC performs the BSSMAP ASSIGNMENT<br />procedure. Our logic still needs to change in a way that the CC/MNCC <br />code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and<br />in that case triggers a new follow-up BSSMAP ASSIGNMENT.</p> OsmoMSC - Bug #2928 (New): OsmoMSC doesn't do BSSMAP ASSIGNMENT if no MNCC_RTP_CREATE is receivedhttps://osmocom.org/issues/29282018-02-11T10:35:23Zlaforge
When operating OsmoMSC with external MNCC handler, it seems that it "forgets" to
<ul>
<li>perform BSSMAP ASSIGNMENT procedure</li>
<li>perform CRCX/MDCX on MGW endpoint for RAN side<br />if the eternal MNCC handler is not sending the MNCC_RTP_CREATE.</li>
</ul>
<p>This is wrong and indicates the state machines have some trouble.</p>
<p>The voice call should be established towards MS/RAN/MGW as usual, no matter if and when an external MNCC handler decides to actually connect to the MSC-located MGW. The MNCC_RTP_{CREATE,MODIFY} should only be translated to CRCX/MDCX of the mncc-side connection to OsmoMGW, and not anything on the RAN side.</p> OsmoBSC - Feature #1946 (New): Add checks to the BSC VTY to prevent configurations known to not workhttps://osmocom.org/issues/19462017-02-08T23:41:53Zneelsnhofmeyr@sysmocom.de
<p>e.g. running TCH/F_TCH/H_PDCH timeslots on a nanobts doesn't work,<br />similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR),<br />and so on.</p> osmo-qcdiag - Bug #1906 (Feedback): wireshark: fix decoding of (E)GPRS RLC/MAC frameshttps://osmocom.org/issues/19062017-01-11T12:20:09Zlaforge
<p>The RLC/MAC frames contained in DIAG are currently not correctly displayed, I assume it is some kind of bit alignment/padding issue.</p>
<p>dissect_qcdiag_log_gmac() in <a class="external" href="http://git.osmocom.org/wireshark/tree/epan/dissectors/packet-qcdiag_log.c?h=laforge/qcdiag">http://git.osmocom.org/wireshark/tree/epan/dissectors/packet-qcdiag_log.c?h=laforge/qcdiag</a> maybe needs the same kind of bit-fucking like implemented in <a class="external" href="http://git.osmocom.org/wireshark/commit/?h=laforge/qcdiag&id=270c4e66fee78aa1a79f6b3ff4dc445a2521e6dd">http://git.osmocom.org/wireshark/commit/?h=laforge/qcdiag&id=270c4e66fee78aa1a79f6b3ff4dc445a2521e6dd</a> and the related code should thus be added to the rlc/mac dissector (registering a new dissector for differently aligned frames?) rather than to packet-gsmtap.c, packet-qcdiag_log.c and packet-gsm_abis_pgsl.c</p> Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p>