Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092023-10-10T13:13:58ZOpen Source Mobile Communications
Redmine OsmoMSC - Bug #6217 (Feedback): Bearer Capability mismatch in MT SETUPhttps://projects.osmocom.org/issues/62172023-10-10T13:13:58Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: mobile: MT calls not working anymore (Resolved)" href="https://projects.osmocom.org/issues/6216">#6216</a>, I noticed that the Bearer Capability in MT SETUP looks weird and does not match such in the MO SETUP.</p>
<p>[frame 9] MO Setup (from SE K800):</p>
<pre>
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 6
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0010 = Speech version indication: GSM full rate speech version 2(GSM EFR) (0x2)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0001 = Speech version indication: GSM half rate speech version 1(GSM HR) (0x1)
</pre>
<p>[frame 22] MT Setup (from osmo-msc):</p>
<pre>
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 5
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 1011 = Speech version indication: GSM half rate speech version 6(OHR AMR) (0xb)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
</pre>
<p>osmo-msc.git 1792ba92c1f939fb232e25ae1124eda7bb11983f (1.11.1)<br />libosmocore.git 435856be518c9d3531ae5b8cbadac1474d521f3a</p> OsmoSGSN - Bug #6197 (Feedback): "Cannot handle SM for unknown MM CTX"https://projects.osmocom.org/issues/61972023-09-28T14:32:29Zfixeria
<p>I am observing relatively long PDP Context activation with Sony Ericsson K800i and recent osmo-sgsn:</p>
<p>osmo-sgsn 1.11.0<br />osmo-pcu 1.3.1.1-c1b0</p>
<p>I don't remember if this was the case before, most likely not.</p>
<p>As can be seen from the attached PCAP, the MS orders a PDP Context activation right after completing the Attach (frame 259):</p>
<pre>
130 16.160906108 127.0.0.1 → 127.0.0.1 GPRS-LLC 107 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Attach Request
156 16.161190149 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Identity Request
157 16.797408334 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Response
173 16.797533278 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Request
181 17.200282825 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Identity Response
226 17.225222456 127.0.0.1 → 127.0.0.1 GPRS-LLC 113 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Attach Accept
239 17.697504097 127.0.0.1 → 127.0.0.1 GPRS-LLC 77 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 3(DTAP) (GMM) Attach Complete
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request <-- (!)
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request <-- (!)
</pre>
<p>The SGSN is responding with GMM Detach Request (frame 275), here is the related logging:</p>
<pre>
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request
260 17.739109847 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
261 17.739128332 127.0.0.1 → 127.0.5.1 GSMTAP 263 GPRS-NS2-VC(UDP-NSE00101-NSVC00101-0_0_0_0:23000-127_0_0_1:23023)[0x55e69ba253d0]{UNBLOCKED}: Received Event RX-UNITDATA
262 17.739139873 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
263 17.739148439 127.0.0.1 → 127.0.5.1 GSMTAP 183 BSSGP TLLI=0x85c79efb Rx UPLINK-UNITDATA
264 17.739181411 127.0.0.1 → 127.0.5.1 GSMTAP 236 LLME(ffffffff/85c79efb){UNASSIGNED} LLC RX: unknown TLLI 0x85c79efb, creating LLME on the fly
265 17.739188394 127.0.0.1 → 127.0.5.1 GSMTAP 193 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x3ef88c
266 17.739193033 127.0.0.1 → 127.0.5.1 GSMTAP 149 CMD=UI
267 17.739196720 127.0.0.1 → 127.0.5.1 GSMTAP 147 DATA
268 17.739200627 127.0.0.1 → 127.0.5.1 GSMTAP 143
269 17.739212048 127.0.0.1 → 127.0.5.1 GSMTAP 214 LLME(ffffffff/85c79efb){UNASSIGNED} Cannot handle SM for unknown MM CTX
270 17.739224792 127.0.0.1 → 127.0.5.1 GSMTAP 198 LLME(ffffffff/85c79efb){UNASSIGNED} LLGM Reset (SAPI=1)
271 17.739243207 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
272 17.739252294 127.0.0.1 → 127.0.5.1 GSMTAP 215 <- GMM DETACH REQ (type: re-attach required, cause: Implicitly detached)
273 17.739257293 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request
</pre>
<p>The MS repeats the request again (frame 517) 30 seconds after the first attempt, and finally gets a PDP Context activated.<br />The key difference between frames 259 (first attempt) and 517 (second attempt) is TLLI indicated in the BSSGP header.</p> OsmoMSC - Bug #6152 (In Progress): built-in MNCC: forward the @Low layer compatibility I@ IE to t...https://projects.osmocom.org/issues/61522023-08-27T18:28:35Zfixeria
<p>The <code>Low layer compatibility I</code> IE is usually present in mobile-originated (CC) Setup messages related to date calls (CSD). According to 3GPP TS 24.008, section 9.3.23.1.7, this IE shall be included in the mobile-terminated (CC) Setup message if the calling user specified it. Currently this IE is simply ignored by the built-in osmo-msc's MNCC and not forwarded to the called party.</p> OsmoPCU - Bug #6084 (Resolved): Assert failed !ms_dl_tbf(ms) src/osmo-pcu/src/gprs_ms.c:1099https://projects.osmocom.org/issues/60842023-07-04T17:39:55Zfixeria
<p>I am running osmo-pcu master (c46b6f29f9c534ec07c3e9bed81561cd479c90b7) and saw this segfault today:</p>
<pre>
Started Osmocom OsmoPCU.
DLGLOBAL NOTICE pcu_main.cpp:298 Setting up GSMTAP Um forwarding to '127.0.1.1:4729'
DLGLOBAL NOTICE telnet_interface.c:88 Available via telnet 127.0.0.1 4240
DL1IF NOTICE osmobts_sock.c:237 osmo-bts PCU socket /tmp/pcu_bts has been connected
DL1IF NOTICE pcu_l1_if.cpp:1244 Received message for new BTS0
DL1IF NOTICE pcu_l1_if.cpp:778 PCUIF version 10 is deprecated. OS#5927
DLNS NOTICE gprs_ns2.c:575 NSE(00101) NS-STATUS.ind(bvci=00000): cause=NSE recovery, transfer=100, first=1, mtu=65523
DPCU NOTICE gprs_bssgp_pcu.c:681 NS-NSE 101 became available
DLBSSGP NOTICE gprs_bssgp.c:124 BSSGP (BVCI=0) Tx BVC-RESET CAUSE=O&M intervention
DLNS NOTICE gprs_ns2.c:571 NSE(00101)-NSVC(00101) NS-STATUS.ind(bvci=00000): cause=NSVC recovery, transfer=100, first=0, mtu=65523
DLBSSGP NOTICE gprs_bssgp_pcu.c:421 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK
DLBSSGP NOTICE gprs_bssgp.c:124 BSSGP (BVCI=2) Tx BVC-RESET CAUSE=O&M intervention
DLBSSGP NOTICE gprs_bssgp_pcu.c:421 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK
DLBSSGP NOTICE gprs_bssgp_bss.c:281 BSSGP (BVCI=2) Tx BVC-UNBLOCK
DLBSSGP NOTICE gprs_bssgp_pcu.c:435 Rx BSSGP BVCI=0 (SIGN) BVC_UNBLOCK_ACK
DRLCMAC NOTICE pdch_ul_controller.c:327 PDCH(bts=0,trx=0,ts=7) Timeout for registered POLL (FN=5213, reason=UL_ASS): TBF(DL:TFI-0-0-0:G:IMSI-001010000000000:TLLI-0x80000000){FLOW}
DTBF NOTICE tbf.cpp:487 TBF(DL:TFI-0-0-0:G:IMSI-001010000000000:TLLI-0x80000000){FLOW} poll timeout for FN=5213, TS=7 (curr FN 5213)
DTBF NOTICE tbf_ul_ass_fsm.c:270 TBF(DL:TFI-0-0-0:G:IMSI-001010000000000:TLLI-0x80000000){FLOW} Timeout for polling PACKET CONTROL ACK for PACKET UPLINK ASSIGNMENT: |Assignment was on PACCH|Downlink ACK was received|
DRLCMAC NOTICE pdch_ul_controller.c:327 PDCH(bts=0,trx=0,ts=7) Timeout for registered POLL (FN=6045, reason=UL_ASS): TBF(DL:TFI-0-0-0:G:IMSI-001010000000000:TLLI-0x80000000){WAIT_RELEASE}
DTBF NOTICE tbf.cpp:487 TBF(DL:TFI-0-0-0:G:IMSI-001010000000000:TLLI-0x80000000){WAIT_RELEASE} poll timeout for FN=6045, TS=7 (curr FN 6045)
DTBF NOTICE tbf_ul_ass_fsm.c:270 TBF(DL:TFI-0-0-0:G:IMSI-001010000000000:TLLI-0x80000000){WAIT_RELEASE} Timeout for polling PACKET CONTROL ACK for PACKET UPLINK ASSIGNMENT: |Assignment was on PACCH|Downlink ACK was received|
Assert failed !ms_dl_tbf(ms) ../../../src/osmo-pcu/src/gprs_ms.c:1099
Signal 6 received.
...
Process 536300 (osmo-pcu) of user 1000 dumped core.
Stack trace of thread 536300:
#0 0x00007fc3739b226c n/a (libc.so.6 + 0x8926c)
#1 0x00007fc373962a08 raise (libc.so.6 + 0x39a08)
#2 0x00007fc37394b538 abort (libc.so.6 + 0x22538)
#3 0x00007fc374074b63 osmo_panic_default (libosmocore.so.20 + 0x24b63)
#4 0x000055b305c51f81 ms_is_reachable_for_dl_ass (osmo-pcu + 0x29f81)
#5 0x000055b305c67826 dl_tbf_handle (osmo-pcu + 0x3f826)
#6 0x000055b305c4a9bd gprs_bssgp_pcu_rx_dl_ud (osmo-pcu + 0x229bd)
#7 0x000055b305c4bb2a gprs_ns_prim_cb (osmo-pcu + 0x23b2a)
#8 0x00007fc3743a2081 ns2_recv_unitdata (libosmogb.so.14 + 0x2c081)
#9 0x00007fc374068e4e _osmo_fsm_inst_dispatch (libosmocore.so.20 + 0x18e4e)
#10 0x00007fc3743a2e68 ns2_vc_rx (libosmogb.so.14 + 0x2ce68)
#11 0x00007fc37439ac2a ns2_recv_vc (libosmogb.so.14 + 0x24c2a)
#12 0x00007fc37439d5c7 handle_nsip_recvfrom (libosmogb.so.14 + 0x275c7)
#13 0x00007fc3740748c7 iofd_poll_ofd_cb_recvmsg_sendmsg (libosmocore.so.20 + 0x248c7)
#14 0x00007fc374076c2f poll_disp_fds (libosmocore.so.20 + 0x26c2f)
#15 0x00007fc374076d0e osmo_select_main (libosmocore.so.20 + 0x26d0e)
#16 0x000055b305c4535d main (osmo-pcu + 0x1d35d)
#17 0x00007fc37394c850 n/a (libc.so.6 + 0x23850)
#18 0x00007fc37394c90a __libc_start_main (libc.so.6 + 0x2390a)
#19 0x000055b305c45865 _start (osmo-pcu + 0x1d865)
ELF object binary architecture: AMD x86-64
</pre>
<p>This happened just once when I started the modem app as usual, obviously it failed to complete the ATTACH procedure.</p>
<p>Here is a backtrace:</p>
<pre>
(gdb) bt
#0 0x00007fc3739b226c in ?? () from /usr/lib/libc.so.6
#1 0x00007fc373962a08 in raise () from /usr/lib/libc.so.6
#2 0x00007fc37394b538 in abort () from /usr/lib/libc.so.6
#3 0x00007fc374074b63 in osmo_panic_default (args=0x7ffda9ff2c60, fmt=0x55b305c921fb "Assert failed %s %s:%d\n") at ../../../../src/libosmocore/src/core/panic.c:45
#4 osmo_panic (fmt=fmt@entry=0x55b305c921fb "Assert failed %s %s:%d\n") at ../../../../src/libosmocore/src/core/panic.c:80
#5 0x000055b305c51f81 in ms_is_reachable_for_dl_ass (ms=0x55b306e50b50) at ../../../src/osmo-pcu/src/gprs_ms.c:1099
#6 ms_append_llc_dl_data (ms=0x55b306e50b50, pdu_delay_csec=1000, data=0x55b306e959e8 "\001\300\r\b\002\001*D\t\361\a", len=26)
at ../../../src/osmo-pcu/src/gprs_ms.c:1400
#7 0x000055b305c67826 in dl_tbf_handle (bts=0x55b306e442b0, tlli=tlli@entry=2147483648, tlli_old=tlli_old@entry=4294967295,
imsi=imsi@entry=0x7ffda9ff2e64 "001010000000000", ms_class=ms_class@entry=0 '\000', egprs_ms_class=egprs_ms_class@entry=0 '\000', delay_csec=1000,
data=0x55b306e959e8 "\001\300\r\b\002\001*D\t\361\a", len=26) at ../../../src/osmo-pcu/src/tbf_dl.cpp:230
#8 0x000055b305c4a9bd in gprs_bssgp_pcu_rx_dl_ud (tp=0x7ffda9ff3180, msg=<optimized out>) at ../../../src/osmo-pcu/src/gprs_bssgp_pcu.c:180
#9 gprs_bssgp_pcu_rx_ptp (bctx=<optimized out>, tp=0x7ffda9ff3180, msg=<optimized out>) at ../../../src/osmo-pcu/src/gprs_bssgp_pcu.c:354
#10 gprs_bssgp_pcu_rcvmsg (msg=<optimized out>) at ../../../src/osmo-pcu/src/gprs_bssgp_pcu.c:573
#11 0x000055b305c4bb2a in gprs_ns_prim_cb (oph=0x7ffda9ff4200, ctx=<optimized out>) at ../../../src/osmo-pcu/src/gprs_bssgp_pcu.c:735
#12 0x00007fc3743a2081 in ns2_recv_unitdata (msg=<optimized out>, fi=<optimized out>) at ../../../../src/libosmocore/src/gb/gprs_ns2_vc_fsm.c:627
#13 0x00007fc374068e4e in _osmo_fsm_inst_dispatch (fi=fi@entry=0x55b306d67f10, event=event@entry=10, data=data@entry=0x55b306e958c0,
file=file@entry=0x7fc3743c29e0 "../../../../src/libosmocore/src/gb/gprs_ns2_vc_fsm.c", line=line@entry=964) at ../../../../src/libosmocore/src/core/fsm.c:863
#14 0x00007fc3743a2e68 in ns2_vc_rx (nsvc=nsvc@entry=0x55b306e23280, msg=msg@entry=0x55b306e958c0, tp=tp@entry=0x7ffda9ff4340)
at ../../../../src/libosmocore/src/gb/gprs_ns2_vc_fsm.c:964
#15 0x00007fc37439ac2a in ns2_recv_vc (nsvc=0x55b306e23280, msg=msg@entry=0x55b306e958c0) at ../../../../src/libosmocore/src/gb/gprs_ns2.c:1362
#16 0x00007fc37439d5c7 in handle_nsip_recvfrom (iofd=<optimized out>, error=<optimized out>, msg=0x55b306e958c0, saddr=0x7ffda9ff5430)
at ../../../../src/libosmocore/src/gb/gprs_ns2_udp.c:218
#17 0x00007fc3740748c7 in iofd_poll_ofd_cb_recvmsg_sendmsg (what=<optimized out>, ofd=0x55b306d88ad0) at ../../../../src/libosmocore/src/core/osmo_io_poll.c:75
#18 iofd_poll_ofd_cb_dispatch (ofd=0x55b306d88ad0, what=1) at ../../../../src/libosmocore/src/core/osmo_io_poll.c:130
#19 0x00007fc374076c2f in poll_disp_fds (n_fd=<optimized out>) at ../../../../src/libosmocore/src/core/select.c:419
#20 _osmo_select_main (polling=<optimized out>) at ../../../../src/libosmocore/src/core/select.c:457
#21 0x00007fc374076d0e in osmo_select_main (polling=<optimized out>) at ../../../../src/libosmocore/src/core/select.c:496
#22 0x000055b305c4535d in main (argc=3, argv=<optimized out>) at ../../../src/osmo-pcu/src/pcu_main.cpp:353
</pre>
<p>Ping me if you need more info from the coredump file.</p> OsmoBTS - Bug #6020 (Resolved): "Discarding duplicated RSP from old CMD ..."https://projects.osmocom.org/issues/60202023-04-28T17:04:44Zfixeria
<p>I am seeing these messages quite often when running osmo-bts-trx with <code>fake_trx.py</code>:</p>
<pre>
...
DTRX NOTICE trx_if.c:694 phy0.0: Discarding duplicated RSP from old CMD 'RSP SETFORMAT 1 1'
...
DTRX NOTICE trx_if.c:708 phy0.0: Discarding duplicated RSP from old CMD 'RSP POWERON -1'
...
DTRX NOTICE trx_if.c:708 phy0.0: Discarding duplicated RSP from old CMD 'RSP SETSLOT 0 0 4'
...
</pre>
<p>First I thought it's a bug in <code>fake_trx.py</code>, but then I found out that it's actually osmo-bts-trx sending some messages twice:</p>
<pre>
...
DTRX FATAL trx_if.c:268 phy0.0: Enqueue TRXC 'CMD SETFORMAT 1'
DTRX FATAL trx_if.c:177 phy0.0: Sending control 'CMD SETFORMAT 1' <---- sending 1st time
DTRX FATAL trx_if.c:177 phy0.0: Sending control 'CMD SETFORMAT 1' <---- sending 2nd time?!?
DTRX FATAL trx_if.c:685 phy0.0: Response message: 'RSP SETFORMAT 1 1'
DTRX FATAL trx_if.c:727 phy0.0: Dequeue TRXC 'CMD SETFORMAT 1'
DTRX FATAL trx_if.c:685 phy0.0: Response message: 'RSP SETFORMAT 1 1'
DTRX NOTICE trx_if.c:694 phy0.0: Discarding duplicated RSP from old CMD 'RSP SETFORMAT 1 1'
...
</pre> OsmoBSC - Bug #6019 (New): "PCU version PCU socket has LOST connection connected"https://projects.osmocom.org/issues/60192023-04-28T12:17:03Zfixeria
<p>This is what I see in the output of <code>show bts</code> command:</p>
<pre>
OsmoBSC> show bts 0
BTS 0 is of osmo-bts type in band GSM900, has CI 0 LAC 1, BSIC 63 (NCC=7, BCC=7) and 1 TRX
Description: (null)
ARFCNs: 85
PCU version PCU socket has LOST connection connected
...
</pre>
<p>what means that somehow <code>bts->pcu_version[]</code> contains <code>PCU socket has LOST connection</code>. I am also seeing this in logging:</p>
<pre>
апр 28 19:14:07 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version 1.2.0.31-33a1bf3
...
апр 28 19:14:10 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version PCU socket has LOST connection
</pre>
<p>This looks a bit confusing, maybe we should just say "PCU state"?</p> OsmoHNodeB - Bug #5989 (Resolved): python-tests: fix documentation errorshttps://projects.osmocom.org/issues/59892023-03-29T20:25:31Zfixeria
<p>I submitted a patch enabling commented out python-tests target, and the build verification failed:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnodeb/+/32146">https://gerrit.osmocom.org/c/osmo-hnodeb/+/32146</a></p>
<pre>
Documentation error (missing docs):
<command id='asn-debug (1|0)'>
<param name='1' doc='(null)' />
<param name='0' doc='(null)' />
Documentation error (missing docs):
<command id='asn-debug (1|0)'>
<param name='1' doc='(null)' />
<param name='0' doc='(null)' />
</pre> OsmoBSC - Bug #5894 (Resolved): Backport https://gerrit.osmocom.org/c/osmo-bsc/+/31189 to 1.9.xhttps://projects.osmocom.org/issues/58942023-02-06T17:57:48Zfixeria
<p>As was suggested during the review:</p>
<pre>
I guess this would also need to be backported to 2023qX?
Also, it seems the offending commit 8d22e6870637ed6d392a8a77aeaebc51b23a8a50
was alrady present in 1.89.0, 1.8.1 and 1.9.0. I think at least it should
be back-ported to 1.9.x creating a 1.9.1 release?
</pre>
<p>I already submitted a backport for 2023q1: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/31197">https://gerrit.osmocom.org/c/osmo-bsc/+/31197</a>.<br />Would be nice if somebody with more experience could tag 1.9.1. Maybe <a class="user active" href="https://projects.osmocom.org/users/301771">osmith</a>? Thanks!</p> OsmoTRX - Bug #5847 (Closed): -Wmaybe-uninitialized when building --with-mstrxhttps://projects.osmocom.org/issues/58472022-12-27T22:48:53Zfixeria
<p>I am seeing these warnings when building osmo-trx-ms with gcc v12.2.0:</p>
<pre>
In file included from ms/ms.h:42,
from ms/ms_upper.cpp:23:
In member function ‘bool spsc_detail::spsc<SZ, ELEM, block_read, block_write, T>::spsc_push(const ELEM*) [with unsigned int SZ = 8; ELEM = trxcon::internal_q_tx_buf; boo
l block_read = true; bool block_write = false; T = spsc_detail::spsc_cond_detail]’,
inlined from ‘void sighandler(int)’ at ms/ms_upper.cpp:454:24,
inlined from ‘void sighandler(int)’ at ms/ms_upper.cpp:444:6:
ms/itrq.h:154:17: warning: ‘b’ may be used uninitialized [-Wmaybe-uninitialized]
154 | buf[cur_wp] = *elem;
| ^~~
ms/ms_upper.cpp: In function ‘void sighandler(int)’:
ms/ms_upper.cpp:453:43: note: ‘b’ declared here
453 | trxcon::internal_q_tx_buf b;
| ^
In member function ‘bool spsc_detail::spsc<SZ, ELEM, block_read, block_write, T>::spsc_push(const ELEM*) [with unsigned int SZ = 8; ELEM = trxcon::trxcon_phyif_cmd; bool
block_read = true; bool block_write = false; T = spsc_detail::spsc_cond_detail]’,
inlined from ‘void sighandler(int)’ at ms/ms_upper.cpp:455:32,
inlined from ‘void sighandler(int)’ at ms/ms_upper.cpp:444:6:
ms/itrq.h:154:17: warning: ‘cmd’ may be used uninitialized [-Wmaybe-uninitialized]
154 | buf[cur_wp] = *elem;
| ^~~
ms/ms_upper.cpp: In function ‘void sighandler(int)’:
ms/ms_upper.cpp:452:42: note: ‘cmd’ declared here
452 | trxcon::trxcon_phyif_cmd cmd;
|
</pre> libosmocore - Bug #5570 (New): coding: decode in-band data in AMR's special DTX frames (SID_FIRST...https://projects.osmocom.org/issues/55702022-05-21T14:21:38Zfixeria
<p>Whenever gsm0503_tch_a[fh]s_decode_dtx() detects a special AMR's DTX frame (e.g SID_FIRST, SID_UPDATE, SID_ONSET) it immediately jumps out and ignores the coded in-band data (CMI, CMC/CMR). A hard-coded default value=0 is assigned instead of the actual value(s) indicated by the MS. This basically breaks rate adaptation when DTXu is employed.</p> OsmoPCU - Bug #5555 (Resolved): AddressSanitizer: heap-use-after-free found by an RPi slave on Je...https://projects.osmocom.org/issues/55552022-05-06T12:46:07Zfixeria
<p>On May 5 2022 job 'master-osmo-pcu' failed:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-pcu/4825/">https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-pcu/4825/</a></p>
<p>in particular, the 'rpi4-raspbian11' configuration:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-pcu/4825/FIRMWARE_VERSION=master,WITH_MANUALS=0,label=rpi4-raspbian11,with_dsp=none,with_vty=False/">https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-pcu/4825/FIRMWARE_VERSION=master,WITH_MANUALS=0,label=rpi4-raspbian11,with_dsp=none,with_vty=False/</a></p>
<p>as can be seen from the Console, an RPi4 slave hits a heap-use-after-free while running the 'tbf' test:</p>
<pre>
--- experr 2022-05-06 00:12:16.383377168 +0000
+++ /build/osmo-pcu-1.0.0.13-0bda/_build/sub/tests/testsuite.dir/at-groups/4/stderr 2022-05-06 00:12:24.423181086 +0000
@@ -9154,4 +9154,56 @@
TBF(UL-TFI_-1){ASSIGN}: Deallocated
UL_ASS_TBF(UL-TFI_-1){NONE}: Deallocated
DL_ASS_TBF(UL-TFI_-1){NONE}: Deallocated
-=== end test_packet_access_rej_prr_no_other_tbfs ===
+TBF(TFI=1 TLLI=0xf1223344 DIR=DL STATE=FINISHED) T3191 timeout expired, freeing TBF: |Assignment was on PACCH|No downlink ACK received yet|
+=================================================================
+==19647==ERROR: AddressSanitizer: heap-use-after-free on address 0xb3e53e0c at pc 0x005d9129 bp 0xbe8fd518 sp 0xbe8fd51c
+READ of size 4 at 0xb3e53e0c thread T0
+ #0 0x5d9127 in bts_do_rate_ctr_inc (/build/osmo-pcu-1.0.0.13-0bda/_build/sub/tests/tbf/TbfTest+0x169127)
+ #1 0x5e14d7 in tbf_free (/build/osmo-pcu-1.0.0.13-0bda/_build/sub/tests/tbf/TbfTest+0x1714d7)
+ #2 0x5e68d3 in tbf_timeout_free(gprs_rlcmac_tbf*, tbf_timers, bool) (/build/osmo-pcu-1.0.0.13-0bda/_build/sub/tests/tbf/TbfTest+0x1768d3)
+ #3 0x5e693f in cb_T3191(void*) (/build/osmo-pcu-1.0.0.13-0bda/_build/sub/tests/tbf/TbfTest+0x17693f)
+
+0xb3e53e0c is located 23564 bytes inside of 23720-byte region [0xb3e4e200,0xb3e53ea8)
+freed by thread T0 here:
+ #0 0xb6a5d47d in free (/usr/lib/arm-linux-gnueabihf/libasan.so.3+0x9247d)
+
+previously allocated by thread T0 here:
+ #0 0xb6a5d69b in __interceptor_malloc (/usr/lib/arm-linux-gnueabihf/libasan.so.3+0x9269b)
+ #1 0x1d (<unknown module>)
+ #2 0x1 (<unknown module>)
+
+SUMMARY: AddressSanitizer: heap-use-after-free (/build/osmo-pcu-1.0.0.13-0bda/_build/sub/tests/tbf/TbfTest+0x169127) in bts_do_rate_ctr_inc
+Shadow bytes around the buggy address:
+ 0x367ca770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+ 0x367ca780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+ 0x367ca790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+ 0x367ca7a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+ 0x367ca7b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+=>0x367ca7c0: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd
+ 0x367ca7d0: fd fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa
+ 0x367ca7e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+ 0x367ca7f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+ 0x367ca800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+ 0x367ca810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
+Shadow byte legend (one shadow byte represents 8 application bytes):
+ Addressable: 00
+ Partially addressable: 01 02 03 04 05 06 07
+ Heap left redzone: fa
+ Heap right redzone: fb
+ Freed heap region: fd
+ Stack left redzone: f1
+ Stack mid redzone: f2
+ Stack right redzone: f3
+ Stack partial redzone: f4
+ Stack after return: f5
+ Stack use after scope: f8
+ Global redzone: f9
+ Global init order: f6
+ Poisoned by user: f7
+ Container overflow: fc
+ Array cookie: ac
+ Intra object redzone: bb
+ ASan internal: fe
+ Left alloca redzone: ca
+ Right alloca redzone: cb
+==19647==ABORTING
stdout:
../../../tests/testsuite.at:28: exit code was 1, expected 0
4. testsuite.at:25: 4. tbf (testsuite.at:25): FAILED (testsuite.at:28)
</pre>
<p>This looks like a race condition to me. Next build 4826 is back to normal.</p> OsmoBSC - Bug #5444 (Resolved): ttcn3-bsc-test-vamos: leaked 'struct bsc_subscr'https://projects.osmocom.org/issues/54442022-02-07T08:47:41Zfixeria
<p>This ticket was split up from <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: ttcn3-bsc-test: leaked struct bsc_subscr in BSC_Tests.TC_no_msc (Resolved)" href="https://projects.osmocom.org/issues/5337">#5337</a>.</p>
<ul>
<li>We started check to the IUT's talloc report in <code>f_shutdown_helper()</code> (see <code>f_verify_talloc_count()</code>)
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/26619">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/26619</a> bsc: detect subscr and conn leaks during f_shutdown_helper()</li>
</ul>
</li>
<li>Module BSC_Tests.ttcn was updated by Neels, so all test cases clean up the IUT's state properly.</li>
<li>Module BSC_Tests_VAMOS.ttcn <strong>was not updated</strong>, so we see regressions in ttcn3-bsc-test-vamos:
<ul>
<li><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-vamos/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-vamos/</a> (+4 since build 245)</li>
</ul></li>
</ul> OsmoBTS - Bug #5243 (Resolved): Both BTS_Tests.TC_meas_res_sign_sdcch4 and BTS_Tests.TC_meas_res_...https://projects.osmocom.org/issues/52432021-09-30T10:50:55Zfixeria
<p>TITAN shows this verdict:</p>
<pre>
Stacktrace
"BTS_Tests.ttcn:2153 : Received unexpected MEAS RES { msg_disc := { msg_group := RSL_MDISC_DCHAN (4), transparent := false }, msg_type := RSL_MT_MEAS_RES (40), ies := { { iei := RSL_IE_CHAN_NR (1), body := { chan_nr := { u := { sdcch4 := { tag := '001'B, sub_chan := 0 } }, tn := 0 } } }, { iei := RSL_IE_MEAS_RES_NR (27), body := { meas_res_nr := 1 } }, { iei := RSL_IE_UPLINK_MEAS (25), body := { uplink_meas := { len := 3, rfu := '0'B, dtx_d := false, rxlev_f_u := 5, reserved1 := '00'B, rxlev_s_u := 5, reserved2 := '00'B, rxq_f_u := 7, rxq_s_u := 7, supp_meas_info := omit } } }, { iei := RSL_IE_BS_POWER (4), body := { bs_power := { reserved := 0, epc := false, fpc := false, power_level := 0 } } }, { iei := RSL_IE_L1_INFO (10), body := { l1_info := { ms_power_lvl := 7, fpc := false, reserved := 0, actual_ta := 0 } } }, { iei := RSL_IE_L3_INFO (11), body := { l3_info := { len := 6, payload := '06150A0A0000'O } } }, { iei := RSL_IE_MS_TIMING_OFFSET (37), body := { ms_timing_offset := 65 } } } }"
BTS_Tests.ttcn:7821 BTS_Tests control part
BTS_Tests.ttcn:3278 TC_meas_res_sign_sdcch4 testcase
</pre>
<p>which is not really informative.</p>
<p>I manually compared PCAP files of a successful and failed runs, and found out that for some reason the first RSL Measurement Report comes with Measurement result number IE equal 1. The test suite expects it to be 0, and thus fails. We need to investigate why osmo-bts counts from 1.</p> OsmoBTS - Bug #5242 (Stalled): A-bis/RSL: CRCX ACK indicates '0.0.0.0' as the local/bind addresshttps://projects.osmocom.org/issues/52422021-09-30T09:25:47Zfixeria
<p>Currently both TC_speech_rtp_tchf and TC_speech_rtp_tchh fail, because CRCX ACK from osmo-bts indicates '0.0.0.0' as the local/bind address. The local/bind address of osmo-bts is needed in order to know where to send RTP packets for the RTP_Emulation component, and of course '0.0.0.0' cannot be used as the remote address for send(). See the attached PCAP file.</p> OsmoBSC - Bug #4873 (Resolved): BSC trying to activate TS while still in avail=dependencyhttps://projects.osmocom.org/issues/48732020-11-28T10:20:38Zfixeria
<p>I am getting these warnings when starting osmo-bts-trx:</p>
<pre>
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx0-ts0)[0x6120000036a0]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx0-ts1)[0x612000003820]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx0-ts2)[0x6120000039a0]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx0-ts3)[0x612000003b20]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx0-ts4)[0x612000003ca0]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx0-ts5)[0x612000003e20]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx0-ts6)[0x612000003fa0]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx0-ts7)[0x612000004120]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx1-ts0)[0x6120000048a0]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx1-ts1)[0x612000004a20]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx1-ts2)[0x612000004ba0]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx1-ts3)[0x612000004d20]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx1-ts4)[0x612000004ea0]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx1-ts5)[0x612000005020]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx1-ts6)[0x6120000051a0]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
DOML NOTICE nm_channel_fsm.c:84 NM_CHAN_OP(bts0-trx1-ts7)[0x612000005320]{DISABLED_DEPENDENCY}:
BSC trying to activate TS while still in avail=dependency. Allowing it to stay backward-compatible with older osmo-bts versions, but BSC is wrong.
</pre>
<p>Given that I am using up to date osmo-bsc and osmo-bts-trx, why is this happening? Another race condition?</p> OsmoTRX - Bug #4828 (Resolved): Building osmo-trx-lms fails due to linker errorshttps://projects.osmocom.org/issues/48282020-10-24T00:31:48Zfixeria
<p>I have no idea why this is happening:</p>
<pre>
$ autoreconf -fi
$ ./configure --with-lms --with-uhd
$ make
...
CXXLD osmo-trx-uhd
CXXLD osmo-trx-lms
/usr/bin/ld: ./device/lms/.libs/libdevice.a(LMSDevice.o): in function `LMSDevice::do_clock_src_freq(ReferenceType, double)':
/home/wmn/wmn/osmocom/osmo-trx/Transceiver52M/device/lms/LMSDevice.cpp:493: undefined reference to `get_value_string(value_string const*, unsigned int)'
/usr/bin/ld: ./device/lms/.libs/libdevice.a(LMSDevice.o): in function `LMSDevice::assign_band_desc(gsm_band)':
/home/wmn/wmn/osmocom/osmo-trx/Transceiver52M/device/lms/LMSDevice.cpp:237: undefined reference to `osmo_panic(char const*, ...)'
collect2: error: ld returned 1 exit status
</pre>
<p>while both osmo-trx-{ipc,uhd} seem to compile just fine. Here is more detailed output:</p>
<pre>
$ make V=s
/bin/sh ../libtool --tag=CXX --mode=link g++ -lpthread -I/usr/local/include/ -pthread -I/usr/local/include/ -I/usr/local/include/ -g -O2 -o osmo-trx-lms osmo_trx_lms-osmo-trx.o ./device/lms/libdevice.la libtransceiver_common.la ../Transceiver52M/arch/x86/libarch.la ../GSM/libGSM.la ../CommonLibs/libcommon.la -lfftw3f -L/usr/local/lib -Wl,-rpath,/usr/lib -ltalloc -losmocore -L/usr/local/lib -Wl,-rpath,/usr/lib -ltalloc -losmoctrl -losmogsm -losmocore -L/usr/local/lib -Wl,-rpath,/usr/lib -ltalloc -losmovty -losmocore -lLimeSuite
libtool: link: g++ -I/usr/local/include/ -pthread -I/usr/local/include/ -I/usr/local/include/ -g -O2 -o osmo-trx-lms osmo_trx_lms-osmo-trx.o -Wl,-rpath -Wl,/usr/lib -Wl,-rpath -Wl,/usr/lib -Wl,-rpath -Wl,/usr/lib ./device/lms/.libs/libdevice.a ./.libs/libtransceiver_common.a ../Transceiver52M/arch/x86/.libs/libarch.a ../GSM/.libs/libGSM.a ../CommonLibs/.libs/libcommon.a -lpthread -L/usr/local/lib -lfftw3f /usr/local/lib/libosmoctrl.so /usr/local/lib/libosmogsm.so -lgnutls /usr/local/lib/libosmovty.so /usr/local/lib/libosmocore.so -ltalloc -lsctp -ldl -lsystemd -lLimeSuite -pthread
/usr/bin/ld: ./device/lms/.libs/libdevice.a(LMSDevice.o): in function `LMSDevice::do_clock_src_freq(ReferenceType, double)':
/home/wmn/wmn/osmocom/osmo-trx/Transceiver52M/device/lms/LMSDevice.cpp:493: undefined reference to `get_value_string(value_string const*, unsigned int)'
/usr/bin/ld: ./device/lms/.libs/libdevice.a(LMSDevice.o): in function `LMSDevice::assign_band_desc(gsm_band)':
/home/wmn/wmn/osmocom/osmo-trx/Transceiver52M/device/lms/LMSDevice.cpp:237: undefined reference to `osmo_panic(char const*, ...)'
collect2: error: ld returned 1 exit status
</pre>
<p>See also: <a class="external" href="https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-trx/1007/">https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-trx/1007/</a>.</p> Cellular Network Infrastructure - Bug #4573 (Resolved): [centos] ttcn3-msc-test: 177 failures!https://projects.osmocom.org/issues/45732020-05-31T18:37:18Zfixeria
<p>See <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-msc-test/2/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-msc-test/2/</a>.</p>
<p>Here I what I noticed in the logs of osmo-stp (build artifacts):</p>
<pre>
20200531003124852 DLGLOBAL <0000> telnet_interface.c:104 Available via telnet 127.0.0.1 4239
20200531003126073 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003126073 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003128331 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003131074 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003131075 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003136075 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003136076 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003138405 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003141077 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003141077 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
20200531003146078 DLINP <0002> stream.c:113 couldn't activate SCTP events on FD 8
</pre>
<p>and osmo-msc:</p>
<pre>
20200531003126073 DSGS <0011> sgs_server.c:186 SGs socket bound to r=NULL<->l=0.0.0.0:29118
20200531003126073 DMSC <0006> msc_main.c:697 A-interface: SCCP user OsmoMSC-A:RI=SSN_PC,PC=(no PC),SSN=BSSAP, cs7-instance 0 ((null))
20200531003126073 DMSC <0006> msc_main.c:716 Iu-interface: SCCP user OsmoMSC-IuCS:RI=SSN_PC,PC=(no PC),SSN=RANAP, cs7-instance 0 ((null))
20200531003126073 DLINP <0015> stream.c:113 couldn't activate SCTP events on FD 12
20200531003126073 DLSS7 <001f> xua_default_lm_fsm.c:354 xua_default_lm(asp-clnt-OsmoMSC-A)[0x831380]{WAIT_ASP_UP}: Ignoring primitive M-ASP_DOWN.indication
20200531003126073 DLINP <0015> stream.c:269 [WAIT_RECONNECT] osmo_stream_cli_write(): not connected, dropping data!
</pre>
<p>The origin of this error message is libosmo-netif's sctp_sock_activate_events():</p>
<pre><code class="c syntaxhl"><span class="cm">/* IMPORTANT: Do NOT enable sender_dry_event here, see
* https://bugzilla.redhat.com/show_bug.cgi?id=1442784 */</span>
<span class="n">rc</span> <span class="o">=</span> <span class="n">setsockopt</span><span class="p">(</span><span class="n">fd</span><span class="p">,</span> <span class="n">IPPROTO_SCTP</span><span class="p">,</span> <span class="n">SCTP_EVENTS</span><span class="p">,</span>
<span class="o">&</span><span class="n">event</span><span class="p">,</span> <span class="k">sizeof</span><span class="p">(</span><span class="n">event</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="n">LOGP</span><span class="p">(</span><span class="n">DLINP</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="s">"couldn't activate SCTP events "</span>
<span class="s">"on FD %u</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">fd</span><span class="p">);</span>
</code></pre> pySim - Bug #4419 (Resolved): CardConnectionException: Failed to transmit with protocol T0. Trans...https://projects.osmocom.org/issues/44192020-02-26T17:33:53Zfixeria
<p>For some reason, pySim-prog.py fails to program a SIM card when using Python 3.</p>
<pre>
Using PC/SC reader (dev=0) interface
Ready for Programming: Insert card now (or CTRL-C to cancel)
Autodetected card type: sysmoUSIM-SJS1
Generated card parameters :
> Name : Osmocom
> SMSP : e1ffffffffffffffffffffffff068100095155f5ffffffffff000000
> ICCID : [REMOVED]
> MCC/MNC : 901/70
> IMSI : 901700000025647
> Ki : [REMOVED]
> OPC : [REMOVED]
> ACC : None
> ADM1(hex): [REMOVED]
Programming ...
Card programming failed with an execption:
---------------------8<---------------------
Traceback (most recent call last):
File "./pySim-prog.py", line 751, in <module>
rc = process_card(opts, first, card_handler)
File "./pySim-prog.py", line 689, in process_card
card.program(cp)
File "/home/fixeria/osmocom/pysim/pySim/cards.py", line 602, in program
data, sw = self._scc.update_binary('2fe2', enc_iccid(p['iccid']))
File "/home/fixeria/osmocom/pysim/pySim/commands.py", line 128, in update_binary
self.select_file(ef)
File "/home/fixeria/osmocom/pysim/pySim/commands.py", line 106, in select_file
data, sw = self._tp.send_apdu_checksw(self.cla_byte + "a4" + self.sel_ctrl + "02" + i)
File "/home/fixeria/osmocom/pysim/pySim/transport/__init__.py", line 93, in send_apdu_checksw
rv = self.send_apdu(pdu)
File "/home/fixeria/osmocom/pysim/pySim/transport/__init__.py", line 68, in send_apdu
data, sw = self.send_apdu_raw(pdu)
File "/home/fixeria/osmocom/pysim/pySim/transport/pcsc.py", line 76, in send_apdu_raw
data, sw1, sw2 = self._con.transmit(apdu, CardConnection.T0_protocol)
File "/usr/lib/python3.8/site-packages/smartcard/CardConnectionDecorator.py", line 82, in transmit
return self.component.transmit(bytes, protocol)
File "/usr/lib/python3.8/site-packages/smartcard/CardConnection.py", line 146, in transmit
data, sw1, sw2 = self.doTransmit(bytes, protocol)
File "/usr/lib/python3.8/site-packages/smartcard/pcsc/PCSCCardConnection.py", line 200, in doTransmit
raise CardConnectionException(
smartcard.Exceptions.CardConnectionException: Failed to transmit with protocol T0. Transaction failed.
---------------------8<---------------------
</pre>
<p>At the same time, reading a SIM card works just fine. Switching back to Python 2 makes pySim-prog.py work again.</p>
<p>I grabbed debug output of pcscd using the following command:</p>
<pre>
$ sudo LIBCCID_ifdLogLevel=0x0007 pcscd -fd | tee /tmp/pcscd.log
</pre>
<p>Please seee attached files and the difference between them.</p> libosmocore - Bug #4388 (Resolved): bitvec: bitvec_read_field() can never return negative value o...https://projects.osmocom.org/issues/43882020-02-04T20:53:58Zfixeria
<p>The doxygen documentation of bitvec_read_field() tells us that it can return a negative on error:</p>
<pre><code class="c syntaxhl"><span class="cm">/*! read part of the vector
* \param[in] bv The boolean vector to work on
* \param[in,out] read_index Where reading supposed to start in the vector
* \param[in] len How many bits to read from vector
* \returns read bits or *negative value on error*
*/</span>
<span class="kt">uint64_t</span> <span class="nf">bitvec_read_field</span><span class="p">(</span><span class="k">struct</span> <span class="n">bitvec</span> <span class="o">*</span><span class="n">bv</span><span class="p">,</span> <span class="kt">unsigned</span> <span class="kt">int</span> <span class="o">*</span><span class="n">read_index</span><span class="p">,</span> <span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">len</span><span class="p">)</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
</code></pre>
<p>However, as can be seen its return value is unsigned - uint64_t. So actually it returns a huge number on error.</p>
<p>This can be seen in the logs of OsmoPCU:</p>
<pre>| Padding = 22|86|86|86|86|18446744073709551594|</pre>
<p>where 18446744073709551594 is basically a negative number casted to uint64_t.</p> OsmoPCU - Bug #4111 (Resolved): BSSGP SUSPEND ACK with unknown BVCI=0https://projects.osmocom.org/issues/41112019-07-17T13:03:29Zfixeria
<p>When a GPRS-attached MS initiates a circuit-switched service (e.g. SS/USSD or SMS), OsmoSGSN logs the following:</p>
<pre>
DBSSGP NOTICE gprs_bssgp.c:556 BSSGP BVCI=0 Rx BVC STATUS, cause=Unknown BVCI
DBSSGP ERROR gprs_bssgp.c:563 BSSGP BVCI=0 Rx STATUS cause=Unknown BVCI missing conditional BVCI IE
</pre>
<p>As far as I understand, OsmoPCU sends BSSGP SUSPEND (BVCI=0) to OsmoSGSN, and gets BSSGP SUSPEND ACK (BVCI=0) from it. So then OsmoPCU realizes that BVCI=0 is now known for some reason, and sends BSSGP STATUS (BVCI=0) with cause "BVCI unknown (5)".</p>
<p>Please see an attached capture. OsmoSGSN is bound to 127.0.0.10:23000, OsmoPCU is at 127.0.0.1:23000.</p> OsmoBTS - Feature #3906 (Resolved): Automatically adjust LAPDm timer values with 'fn-advance' par...https://projects.osmocom.org/issues/39062019-04-06T18:19:30Zfixeria
<p>Currently we use fn-advance=20 by default, so the burst scheduler is working 20 TDMA frames in advance. This advance gives the transceiver some time to receive a burst, process it (i.e. modulate), and send to the Tx buffer of SDR. As a side effect, this increases the delay between UL and DL: 20 TDMA frames => 92.3ms of delay.</p>
<p>Higher fn-advance values cause a longer delay, resulting in LAPDm frame retransmissions.<br />OsmoBTS should automatically adjust LAPDm timer values with the configured 'fn-advance' value.</p> OsmoMSC - Bug #3684 (Resolved): Always true/false conditions (reported by clang-4.0 with -Wall)https://projects.osmocom.org/issues/36842018-11-09T01:45:16Zfixeria
<p>Sorry for so brief and lazy report, no time.</p>
<pre>
db.c:278:25: warning: comparison of constant 256 with expression of type 'uint8_t' (aka 'unsigned char') is always false
[-Wtautological-constant-out-of-range-compare]
if (sms->user_data_len > sizeof(sms->user_data))
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~
db.c:424:25: warning: comparison of constant 256 with expression of type 'uint8_t' (aka 'unsigned char') is always false
[-Wtautological-constant-out-of-range-compare]
if (sms->user_data_len > sizeof(sms->user_data))
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~
db.c:780:25: warning: comparison of constant 256 with expression of type 'uint8_t' (aka 'unsigned char') is always false
[-Wtautological-constant-out-of-range-compare]
if (sms->user_data_len > sizeof(sms->user_data))
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~
5 warnings generated.
</pre>
<pre>
osmo_msc.c:243:23: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if (conn->use_tokens < 0)
~~~~~~~~~~~~~~~~ ^ ~
</pre>
<pre>
osmo_msc.c:277:29: warning: comparison of constant 32 with expression of type 'enum msc_subscr_conn_use' is always true
[-Wtautological-constant-out-of-range-compare]
OSMO_ASSERT(balance_token < 32);
~~~~~~~~~~~~~ ^ ~~
/usr/local/include/osmocom/core/utils.h:89:8: note: expanded from macro 'OSMO_ASSERT'
if (!(exp)) { \
^~~
</pre>
<pre>
osmo_msc.c:304:29: warning: comparison of constant 32 with expression of type 'enum msc_subscr_conn_use' is always true
[-Wtautological-constant-out-of-range-compare]
OSMO_ASSERT(balance_token < 32);
~~~~~~~~~~~~~ ^ ~~
/usr/local/include/osmocom/core/utils.h:89:8: note: expanded from macro 'OSMO_ASSERT'
if (!(exp)) { \
^~~
</pre>
<pre>
smpp_openbsc.c:211:5: warning: comparison of constant 256 with expression of type 'uint8_t' (aka 'unsigned char') is always false
[-Wtautological-constant-out-of-range-compare]
OSMO_MIN(ud_len, sizeof(sms->user_data)));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/osmocom/core/utils.h:21:29: note: expanded from macro 'OSMO_MIN'
#define OSMO_MIN(a, b) ((a) >= (b) ? (b) : (a))
~~~ ^ ~~~
</pre> gr-gsm - Feature #3520 (Resolved): apps/grgsm_trx: implement a possibility to shift both RX and T...https://projects.osmocom.org/issues/35202018-09-04T18:12:32Zfixeria
<p>This feature would allow <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki">OsmocomBB</a> working on <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki/SDR_PHY">SDR PHY</a> to interact with a BTS running in some shifted frequency band (e.g. 2.4 GHz).<br />Please see <a class="external" href="https://osmocom.org/versions/136">https://osmocom.org/versions/136</a> for a bit more detailed description.</p> OsmocomBB SDR PHY - Bug #3459 (Stalled): apps/grgsm_trx: AssertionError: packe t_info.packet_coun...https://projects.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://projects.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> GSM Audio Pocket Knife - Bug #3398 (New): build: configure fails if (optional) libalsa wasn't foundhttps://projects.osmocom.org/issues/33982018-07-16T20:45:23Zfixeria
<p>ALSA is optional dependency, which is only required for audio capture and playback.<br />We should not enforce this optional dependency as a mandatory one.</p> OsmoBTS - Bug #3032 (Resolved): (Wrong?) measurement of both RSSI and ToA on TCH channelshttps://projects.osmocom.org/issues/30322018-03-05T08:01:32Zfixeria
<p>Unlike xCCH and PDTCH, where we measure both RSSI and ToA values <strong>for each</strong> burst:</p>
<pre>
// ...
/* update mask + RSSI */
*mask |= (1 << bid);
*rssi_sum += rssi;
(*rssi_num)++;
*toa256_sum += toa256;
(*toa_num)++;
// ...
/* Send uplink measurement information to L2 */
l1if_process_meas_res(l1t->trx, tn, *first_fn,
trx_chan_desc[chan].chan_nr | tn, n_errors, n_bits_total,
*rssi_sum / *rssi_num, *toa256_sum / *toa_num);
ber10k = compute_ber10k(n_bits_total, n_errors);
return _sched_compose_ph_data_ind(l1t, tn, *first_fn, chan,
l2, l2_len,
*rssi_sum / *rssi_num,
4 * (*toa256_sum) / *toa_num, 0, ber10k,
PRES_INFO_UNKNOWN);
// ...
</pre>
<p>both TCH/F and TCH/H are currently sending the measurements <strong>for the last</strong> burst:</p>
<pre>
// ...
/* Send uplink measurement information to L2 */
l1if_process_meas_res(l1t->trx, tn, *first_fn,
trx_chan_desc[chan].chan_nr|tn, n_errors, n_bits_total,
rssi, toa256);
// ...
/* FACCH */
_sched_compose_ph_data_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
tch_data + amr, GSM_MACBLOCK_LEN,
rssi, 4 * toa256,
0, ber10k, PRES_INFO_UNKNOWN);
// ...
return _sched_compose_tch_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME,
chan, tch_data, rc);
</pre>
<p>Moreover, in case of FACCH carried on a TCH/H channel the ToA256 is<br />for some reason devided by 64, while in case of TCH/F it's passed as is:</p>
<pre>
/* TCH/F FACCH */
_sched_compose_ph_data_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
tch_data + amr, GSM_MACBLOCK_LEN,
rssi, 4 * toa256,
0, ber10k, PRES_INFO_UNKNOWN);
/* TCH/H FACCH */
_sched_compose_ph_data_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 10 - ((fn % 26) >= 19)) % GSM_HYPERFRAME,
chan, tch_data + amr, GSM_MACBLOCK_LEN,
rssi, toa256/64,
0, ber10k, PRES_INFO_UNKNOWN);
</pre>
<p>And finally, on TCH channels we only attach the measurements to<br />FACCH indications, while speech frames don't have such info:</p>
<pre>
/* TCH/F FACCH */
_sched_compose_ph_data_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
tch_data + amr, GSM_MACBLOCK_LEN,
rssi, 4 * toa256,
0, ber10k, PRES_INFO_UNKNOWN);
// ...
/* TCH/F speech frame */
return _sched_compose_tch_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME,
chan, tch_data, rc);
</pre>
<p>I wish I could resolve this issue myself, but I didn't find anything<br />in GSM specifications about the BTS side measurement process...</p>
<p>According to the GSM TS 05.03, a single TCH/F frame is mapped over<br />8 bursts, while a TCH/H frame is mapped over 6 bursts. This should<br />be taken into account.</p>
<p>Any ideas are welcome.</p> GSM Audio Pocket Knife - Bug #2483 (Closed): ALSA buffer overrun causes program exithttps://projects.osmocom.org/issues/24832017-09-02T12:17:41Zfixeria
<p>When a sound device is active, data is transferred continuously between the hardware and application buffers. In the case of data capture (recording), if the application does not read the data in the buffer rapidly enough, the circular buffer is overwritten with new data. The resulting data loss is known as overrun. During playback, if the application does not pass data into the buffer quickly enough, it becomes starved for data, resulting in an error called underrun. The ALSA documentation sometimes refers to both of these conditions using the term XRUN. Properly designed applications can minimize XRUN and recover if it occurs.</p>
<p>When the buffer underrun happens, GAPK stops processing with the following message:</p>
<p>[+] PQ: Adding ALSA output (dev='default', blk_len=320)<br />[!] pq_execute(): abort, item returned -1<br />[+] Processed X frames</p>
<p>The snd_pcm_prepare() should be called to recover pcm_handle from buffer underrun state.</p> OsmoBTS - Bug #2223 (Closed): common/power_control.c: strange conditionshttps://projects.osmocom.org/issues/22232017-05-04T10:11:31Zfixeria
<p>Look at the lchan_ms_pwr_ctrl():</p>
<pre>
int lchan_ms_pwr_ctrl(struct gsm_lchan *lchan,
const uint8_t ms_power, const int rxLevel)
{
int rx;
int cur_dBm, new_dBm, new_pwr;
struct gsm_bts *bts = lchan->ts->trx->bts;
struct gsm_bts_role_bts *btsb = bts_role_bts(bts);
const enum gsm_band band = bts->band;
// ...
/*
* What is the difference between what we want and received?
* Ignore a margin that is within the range of measurement
* and MS output issues.
*/
rx = btsb->ul_power_target - rxLevel;
if (rx >= 0 && rx < 1)
return 0;
if (rx < 0 && rx > -1) // Unreachable
return 0;
// ...
}
</pre>
<blockquote>
<p>if (rx < 0 && rx > -1)</p>
</blockquote>
<p>As rx has type int, it cannot be in range (-1; 0)...</p>
<blockquote>
<p>if (rx >= 0 && rx < 1)</p>
</blockquote>
<p>Again, the only possible value here is 0.</p> OsmocomBB - Support #1639 (Closed): BCCH at TS1-7 supporthttps://projects.osmocom.org/issues/16392016-03-09T15:02:23Zfixeria
<p>The specs says it's possible to have paging channels on other time slots than 0.<br />But support for it is not implemented in Osmocom-bb...</p>