Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-02-05T09:25:36ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://projects.osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> Cellular Network Infrastructure - Feature #6327 (New): Osmocom-build-tags-against-master job buil...https://projects.osmocom.org/issues/63272024-01-11T20:17:59Zfixeria
<p>The idea behind this job is to check if [a limited set of] old tagged versions of various Osmocom projects can still compile with the most recent versions of Osmocom libraries.</p>
<p>I checked the build logs and found out that it's building the default configurations for Osmocom projects (no <code>--with-foo</code> flags passed to configure scripts).<br />For instance, the default build configuration for osmo-bts does not include any models except the <code>-virtual</code>, so <code>osmo-bts-{trx,sysmo,...}</code> are not covered.<br />Same applies to osmo-trx: we build only the common code, but not the <code>-uhd/-lms</code> variants.</p>
<p>The more complete configurations we build, the more chances we have to catch various backwards compatibility problems.<br />A good example is <a class="external" href="https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh">https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh</a>, where we do enable much more features / variants.<br />Maybe this code can be generalized and re-used somehow?</p> OsmoHNBGW - Bug #6302 (Resolved): ttcn3-hnbgw-test-latest regression (IUT segmentation fault)https://projects.osmocom.org/issues/63022023-12-12T12:31:45Zfixeria
<p>Starting from December 5th, we're seeing regressions in ttcn3-hnbgw-test <strong>latest</strong>:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/535/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/535/</a> (+28 failures)</p>
<p>All affected testcases fail due to a DTE:</p>
<pre>
MTC@6005ed7d57b8: setverdict(fail): none -> fail reason: ""VTY Timeout for prompt: enable"", new component reason: ""VTY Timeout for prompt: enable""
</pre>
<p>We can also see a coredump file in the artifacts:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/535/artifact/logs/hnbgw/core">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/535/artifact/logs/hnbgw/core</a></p>
<p>I managed to reproduce the problem locally and examined the coredump in gdb:</p>
<pre>
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f75debf1489 in on_success (data=<optimized out>, ci=0x562ca9a8f690) at ./src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:539
539 ./src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c: No such file or directory.
(gdb) bt
#0 0x00007f75debf1489 in on_success (data=<optimized out>, ci=0x562ca9a8f690) at ./src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:539
#1 osmo_mgcpc_ep_fsm_handle_ci_events (fi=<optimized out>, event=<optimized out>, data=<optimized out>) at ./src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:957
#2 0x00007f75deaf2ef0 in _osmo_fsm_inst_dispatch (fi=0x562ca9a8be50, event=0, data=0x562ca9a9603c, file=0x7f75debf5ba3 "mgcp_client_fsm.c", line=446) at ./src/core/fsm.c:875
#3 0x00007f75deaf2ef0 in _osmo_fsm_inst_dispatch (fi=0x562ca9a95c10, event=3, data=0x562ca9a95d40, file=0x7f75debf5ba3 "mgcp_client_fsm.c", line=429) at ./src/core/fsm.c:875
#4 0x00007f75debe2817 in mgcp_client_handle_response (mgcp=0x562ca9a7d970, pending=0x562ca9a8b840, response=<optimized out>) at ./src/libosmo-mgcp-client/mgcp_client.c:246
#5 0x00007f75debe2dc4 in mgcp_client_rx (mgcp=mgcp@entry=0x562ca9a7d970, msg=msg@entry=0x562ca9a96380) at ./src/libosmo-mgcp-client/mgcp_client.c:741
#6 0x00007f75debe3da7 in mgcp_do_read (fd=0x562ca9a7ddb0) at ./src/libosmo-mgcp-client/mgcp_client.c:771
#7 0x00007f75deb0f241 in osmo_wqueue_bfd_cb (fd=0x562ca9a7ddb0, what=1) at ./src/core/write_queue.c:47
#8 0x00007f75deb00a94 in poll_disp_fds (n_fd=<optimized out>) at ./src/core/select.c:419
#9 _osmo_select_main (polling=polling@entry=0) at ./src/core/select.c:457
#10 0x00007f75deb00ba6 in osmo_select_main_ctx (polling=polling@entry=0) at ./src/core/select.c:513
#11 0x0000562ca98dc6e2 in main (argc=3, argv=0x7ffc2bf14318) at ./src/osmo-hnbgw/osmo_hnbgw_main.c:317
</pre>
<p>Looks like the problem is actually in libosmo-mgcp-client rather than in osmo-hnbgw?</p>
<pre>
ii libosmo-mgcp-client12:amd64 1.12.1 amd64 libosmo-mgcp-client: Osmocom's Media Gateway Control Protocol client utilities
ii libosmocore 1.9.2 amd64 Open Source MObile COMmunications CORE library (metapackage)
ii osmo-hnbgw 1.5.0 amd64 OsmoHNBGW: Osmocom Home Node B Gateway
</pre> OsmocomBB - Bug #6209 (Resolved): modem: no response to ICMP Echo Req (ping to MS) with mssdr-mshttps://projects.osmocom.org/issues/62092023-10-05T18:21:39Zfixeria
<p>I am trying to ping the MS from the BTS side, but seeing lots of errors and almost no Echo Rsp.</p>
<p>trxcon logs errors about GPRS UL BLOCK.req without prior TBF CFG.req:</p>
<pre>
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: Reset scheduler (sched_trx.c:190)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #0 (sched_trx.c:226)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: Add a new TDMA timeslot #3 (sched_trx.c:207)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: (Re)configure TDMA timeslot #3 as PDCH (sched_trx.c:276)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: TS3-PDTCH activating (sched_trx.c:476)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: TS3-PTCCH activating (sched_trx.c:476)
20231005180900843 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #3 (sched_trx.c:226)
20231005180900843 DGPRS ERROR trxcon(0)[0x5572f10900]: (PDCH-3) Rx UL BLOCK.req (fn=2003126, len=34), but this PDCH has no configured TBFs (l1gprs.c:643)
20231005180900871 DL1C NOTICE trxcon(0)[0x5572f10900]{PACKET_DATA}: Received reset request (FULL) (l1ctl.c:439)
20231005180900871 DSCH NOTICE trxcon(0)[0x5572f10900]: Reset scheduler and clock counter (sched_trx.c:190)
20231005180900872 DL1C NOTICE trxcon(0)[0x5572f10900]{RESET}: Received FBSB request (GSM900 979, timeout 100 TDMA FNs) (l1ctl.c:380)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: Add a new TDMA timeslot #0 (sched_trx.c:207)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 (sched_trx.c:276)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-SCH activating (sched_trx.c:476)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-BCCH activating (sched_trx.c:476)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-RACH activating (sched_trx.c:476)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-CCCH activating (sched_trx.c:476)
20231005180900890 DAPP ERROR trxcon(0)[0x5572f10900]{FBSB_SEARCH}: Event TRXCON_EV_RX_DATA_IND not permitted (trxcon_shim.c:93)
20231005180901644 DL1C NOTICE trxcon(0)[0x5572f10900]{BCCH_CCCH}: Received 8-bit RACH request (offset=0, ra=0x78) (l1ctl.c:542)
20231005180901646 DSCHD NOTICE trxcon(0)[0x5572f10900]: TS0-RACH Scheduled 8-bit RACH (TS0: GSM, GMSK) at fn=2003300 (sched_lchan_rach.c:130)
20231005180901834 DL1C NOTICE trxcon(0)[0x5572f10900]{BCCH_CCCH}: Received L1CTL_DM_EST_REQ (tn=4, chan_nr=0xc4, tsc=7, tch_mode=SIGNALLING) (l1ctl.c:630)
20231005180901834 DL1C NOTICE trxcon(0)[0x5572f10900]{BCCH_CCCH}: L1CTL_DM_EST_REQ indicates single ARFCN GSM900 979 (l1ctl.c:572)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: Reset scheduler (sched_trx.c:190)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #0 (sched_trx.c:226)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: Add a new TDMA timeslot #4 (sched_trx.c:207)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: (Re)configure TDMA timeslot #4 as PDCH (sched_trx.c:276)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: TS4-PDTCH activating (sched_trx.c:476)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: TS4-PTCCH activating (sched_trx.c:476)
20231005180902026 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #4 (sched_trx.c:226)
20231005180902026 DGPRS ERROR trxcon(0)[0x5572f10900]: (PDCH-4) Rx UL BLOCK.req (fn=2003382, len=34), but this PDCH has no configured TBFs (l1gprs.c:643)
20231005180902054 DL1C NOTICE trxcon(0)[0x5572f10900]{PACKET_DATA}: Received reset request (FULL) (l1ctl.c:439)
20231005180902054 DSCH NOTICE trxcon(0)[0x5572f10900]: Reset scheduler and clock counter (sched_trx.c:190)
20231005180902055 DL1C NOTICE trxcon(0)[0x5572f10900]{RESET}: Received FBSB request (GSM900 979, timeout 100 TDMA FNs) (l1ctl.c:380)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: Add a new TDMA timeslot #0 (sched_trx.c:207)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 (sched_trx.c:276)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-SCH activating (sched_trx.c:476)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-BCCH activating (sched_trx.c:476)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-RACH activating (sched_trx.c:476)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-CCCH activating (sched_trx.c:476)
20231005180902511 DL1D NOTICE trxcon(0)[0x5572f10900]: L1CTL connection error: read() failed (rc=0): Resource temporarily unavailable (l1ctl_server.c:55)
20231005180902511 DL1C NOTICE trxcon(0)[0x5572f10900]: Closing L1CTL connection (l1ctl_server.c:203)
20231005180902511 DSCH NOTICE trxcon(0)[0x5572f10900]: Shutdown scheduler (sched_trx.c:173)
20231005180902511 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #0 (sched_trx.c:226)
<pre>
Please find the PCAPs (MS side + BTS side) attached.</pre> 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> OsmocomBB - Bug #5907 (Resolved): layer23/{misc,modem}: command line option -a/--arfcn is ignoredhttps://projects.osmocom.org/issues/59072023-02-15T15:43:04Zfixeria
<p>Since recently I noticed that the modem app ignores the ARFCN value passed via as a command line argument (-a/--arfcn).</p>
<pre>
fixeria@DELL:~/projects/osmocom/bb/src/host/layer23$ ./src/modem/modem -a 1 -d DL1C
Copyright (C) 2022 by sysmocom - s.m.f.c. GmbH <info@sysmocom.de>
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
DL1C INFO l1ctl.c:776 Tx Reset Req (1)
DL1C DEBUG l1l2_interface.c:139 Sending: '0d 00 00 00 01 00 00 00 '
DL1C INFO l1ctl.c:786 Layer1 Reset indication
DL1C INFO l1ctl.c:427 Sync Req
DL1C DEBUG l1l2_interface.c:139 Sending: '01 00 00 00 03 67 00 64 27 10 03 20 03 07 00 00 19 '
DL1C INFO l1ctl.c:161 snr=0000, arfcn=871 result=255
DL1C ERROR l1ctl.c:165 FBSB RESP: result=255
</pre>
<p>This is unfortunately also the case for misc apps like <code>ccch_scan</code> and <code>cbch_sniff</code>.</p>
<pre>
fixeria@DELL:~/projects/osmocom/bb/src/host/layer23$ ./src/misc/ccch_scan -a 1 -d DL1C
Copyright (C) 2010 Harald Welte <laforge@gnumonks.org>
Contributions by Holger Hans Peter Freyther
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
DL1C INFO l1ctl.c:776 Tx Reset Req (1)
DL1C DEBUG l1l2_interface.c:139 Sending: '0d 00 00 00 01 00 00 00 '
DL1C INFO l1ctl.c:786 Layer1 Reset indication
DL1C INFO l1ctl.c:427 Sync Req
DL1C DEBUG l1l2_interface.c:139 Sending: '01 00 00 00 03 67 00 64 27 10 03 20 03 07 00 00 19 '
DL1C INFO l1ctl.c:161 snr=0000, arfcn=871 result=255
DL1C ERROR l1ctl.c:165 FBSB RESP: result=255
</pre>
<p>As can be seen, the apps are using hard-coded <code>arfcn=871</code> regardless of the requested ARFCN.</p> 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> OsmocomBB - Bug #5831 (New): SE K2x0i: built-in SIM reader is not workinghttps://projects.osmocom.org/issues/58312022-12-15T23:46:08Zfixeria
<p>Currently the mobile app fails to use built-in SIM reader of my Sony Ericsson K200i:</p>
<pre>
DMM INFO subscriber.c:596 Requesting SIM file 0x2fe2
DSIM INFO sim.c:223 got new job: SIM_JOB_READ_BINARY (handle=00000004)
DSIM INFO sim.c:712 go MF
DSIM INFO sim.c:256 SELECT (file=0x3f00)
DSIM INFO sim.c:181 sending APDU (class 0xa0, ins 0xa4)
DSIM INFO sim.c:200 Using built-in SIM reader
DSIM INFO sim.c:901 received APDU (len=0 sw1=0x00 sw2=0x00)
DSIM INFO sim.c:979 command failed
DSIM INFO sim.c:147 sending result to callback function (type=1)
</pre>
<p>This is what the firmware log looks like:</p>
<pre>
OsmocomBB Layer 1 (revision osmocon_v0.0.0-2885-g86f46edd-modified)
======================================================================
Device ID code: 0xb496
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: e515201ce51557b9
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff7
CNTL_ARM_DIV=0xfff9
======================================================================
Power up simcard:
key=20 pressed
key=20 released
Checking TIFFS for the RF calibration records
...
L1CTL_RESET_REQ: FULL!
SIM Request (7): a0 a4 00 00 02 3f 00
SIM: ACK read failed
SIM Response (2): 00 00
</pre>
<p>Note the <code>key=20 pressed/released</code>, I wasn't actually pressing anything.</p> Cellular Network Infrastructure - Bug #5729 (Resolved): ttcn3-bsc-test-sccplite: +47 failues sinc...https://projects.osmocom.org/issues/57292022-10-25T18:12:52Zfixeria
<p>Starting from <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1644/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1644/</a>, we see a massive fallout. Most of them fail due to timeout waiting for response to CRCX.</p>
<pre>
Timeout waiting for response to {
line := {
verb := "CRCX",
trans_id := "0",
ep := "1@mgw",
ver := "1.0"
},
params := {
{
code := "M",
val := "sendrecv"
},
{
code := "C",
val := "51234"
},
{
code := "L",
val := "p:20, a:AMR"
}
},
sdp := {
protocol_version := 0,
origin := {
user_name := "-",
session_id := "23",
session_version := "42",
net_type := "IN",
addr_type := "IP4",
addr := "127.0.0.4"
},
session_name := "-",
information := omit,
uri := omit,
emails := omit,
phone_numbers := omit,
connection := {
net_type := "IN",
addr_type := "IP4",
conn_addr := {
addr := "127.0.0.5",
ttl := omit,
num_of_addr := omit
}
},
bandwidth := omit,
times := {
{
time_field := {
start_time := "0",
stop_time := "0"
},
time_repeat := omit
}
},
timezone_adjustments := omit,
key := omit,
attributes := omit,
media_list := {
{
media_field := {
media := "audio",
ports := {
port_number := 14000,
num_of_ports := omit
},
transport := "RTP/AVP",
fmts := {
"3"
}
},
information := omit,
connections := omit,
bandwidth := omit,
key := omit,
attributes := {
{
ptime := {
attr_value := "20"
}
}
}
}
}
}
}
BSC_Tests.ttcn:12030 BSC_Tests control part
BSC_Tests.ttcn:4047 TC_assignment_fr_a5_0 testcase
</pre>
<p>Even more tests started to fail today: <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1648/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1648/</a>.</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 #5385 (Resolved): Segmentation fault in chan_counts_for_bts()https://projects.osmocom.org/issues/53852022-01-05T10:32:13Zfixeria
<p>Recent ttcn3-bsc-test-latest run 1192 shows +111 failures:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-latest/1192/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-latest/1192/</a></p>
<p>and indeed there is a core dump file in the artifacts:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-latest/lastCompletedBuild/artifact/logs/bsc/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-latest/lastCompletedBuild/artifact/logs/bsc/</a></p>
<p>Here is a backtrace:</p>
<pre>
Core was generated by `/usr/bin/osmo-bsc -c /data/osmo-bsc.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055cb2eae7111 in chan_counts_for_bts (bts_counts=bts_counts@entry=0x7ffea2f4cf50, bts=0x0) at chan_counts.c:137
137 chan_counts.c: No such file or directory.
(gdb) bt
#0 0x000055cb2eae7111 in chan_counts_for_bts (bts_counts=bts_counts@entry=0x7ffea2f4cf50, bts=0x0) at chan_counts.c:137
#1 0x000055cb2eaf11aa in candidate_set_free_tch (c=c@entry=0x7ffea2f4d730) at handover_decision_2.c:1030
#2 0x000055cb2eaf2c57 in collect_handover_candidate (lchan=lchan@entry=0x7f06d9cdad48, nmp=0x7ffea2f4d730, nmp@entry=0x7f06d9cdaec4, clist=clist@entry=0x7ffea2f4dec0,
candidates=candidates@entry=0x7ffea2f4deac, include_weaker_rxlev=include_weaker_rxlev@entry=true, rxlev_current=rxlev_current@entry=8,
neighbors_count=0x7ffea2f4de14) at handover_decision_2.c:1146
#3 0x000055cb2eaf3843 in collect_candidates_for_lchan (lchan=lchan@entry=0x7f06d9cdad48, clist=clist@entry=0x7ffea2f4dec0, candidates=candidates@entry=0x7ffea2f4deac,
_rxlev_current=_rxlev_current@entry=0x7ffea2f4dea8, include_weaker_rxlev=include_weaker_rxlev@entry=true) at handover_decision_2.c:1224
#4 0x000055cb2eaf4b89 in find_alternative_lchan (lchan=0x7f06d9cdad48, include_weaker_rxlev=<optimized out>, request_upgrade_to_tch_f=true)
at handover_decision_2.c:1303
#5 0x000055cb2eb00480 in ho_meas_rep (mr=0x7f06d9cdafb8) at handover_logic.c:95
#6 ho_logic_sig_cb (subsys=<optimized out>, signal=<optimized out>, handler_data=<optimized out>, signal_data=<optimized out>) at handover_logic.c:316
#7 0x00007f06da98c50c in osmo_signal_dispatch () from /usr/lib/x86_64-linux-gnu/libosmocore.so.18
#8 0x000055cb2eab0e37 in send_lchan_signal (resp=0x7f06d9cdafb8, lchan=<optimized out>, sig_no=8) at abis_rsl.c:67
#9 rsl_rx_meas_res (msg=msg@entry=0x55cb2f695c70) at abis_rsl.c:1455
#10 0x000055cb2eab5b34 in abis_rsl_rx_dchan (msg=0x55cb2f695c70) at abis_rsl.c:1544
#11 abis_rsl_rcvmsg (msg=0x55cb2f695c70) at abis_rsl.c:3056
#12 0x00007f06da950ee1 in ipaccess_fd_cb () from /usr/lib/x86_64-linux-gnu/libosmoabis.so.10
#13 0x00007f06da98bfd8 in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.18
#14 0x00007f06da98c0c7 in osmo_select_main_ctx () from /usr/lib/x86_64-linux-gnu/libosmocore.so.18
#15 0x000055cb2eaa35d7 in main (argc=3, argv=<optimized out>) at osmo_bsc_main.c:1087
</pre> OsmoBTS - Bug #5273 (Resolved): ttcn3-bts-test-latest: TC_sms_cb_cmd_sdcch8_{1,2}block failing si...https://projects.osmocom.org/issues/52732021-10-20T00:24:02Zfixeria
<p>BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch8_1block (from Titan):</p>
<pre>
Received unexpected CBCH block: { block_type := { spare := '0'B, lpd := '01'B, last_block := false, seq_nr := 0 },
payload := '001000320F1141660C344DD3CBA09A0C000000000000'O }
BTS_Tests_SMSCB.ttcn:1104 BTS_Tests_SMSCB control part
BTS_Tests_SMSCB.ttcn:545 TC_sms_cb_cmd_sdcch8_1block testcase
</pre>
<p>BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch8_2block (from Titan):</p>
<pre>
Received unexpected CBCH block: { block_type := { spare := '0'B, lpd := '01'B, last_block := false, seq_nr := 1 },
payload := '000102030405060708090A0B0C0D0E0F101213141516'O }
BTS_Tests_SMSCB.ttcn:1105 BTS_Tests_SMSCB control part
BTS_Tests_SMSCB.ttcn:563 TC_sms_cb_cmd_sdcch8_2block testcase
</pre>
<p>Note that SDCCH/4+CBCH is not affected, only the SDCCH/8 variants fail.</p> OsmoBTS - Bug #5251 (Resolved): VAMOS: CHANnel ACTIVation on shadow timeslots is brokenhttps://projects.osmocom.org/issues/52512021-10-08T20:05:15Zfixeria
<p>Starting from <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/1432/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/1432/</a>, we see new regressions affecting all VAMOS related test cases. The problem is that osmo-bts started to NACK CHANnel ACTIVaction messages for lchans on the shadow timeslots:</p>
<pre>
(bts=0,trx=0,ts=1,shadow,pchan=TCH/F) rx chan activ but TS not in nm_state oper=ENABLED avail=OK, nack!
</pre>
<p>because they do not reflect the OML states of primary timeslots:</p>
<pre><code class="c syntaxhl"><span class="k">if</span> <span class="p">(</span><span class="n">ts</span><span class="o">-></span><span class="n">mo</span><span class="p">.</span><span class="n">nm_state</span><span class="p">.</span><span class="n">operational</span> <span class="o">!=</span> <span class="n">NM_OPSTATE_ENABLED</span> <span class="o">||</span>
<span class="n">ts</span><span class="o">-></span><span class="n">mo</span><span class="p">.</span><span class="n">nm_state</span><span class="p">.</span><span class="n">availability</span> <span class="o">!=</span> <span class="n">NM_AVSTATE_OK</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DRSL</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="s">"%s rx chan activ but TS not in nm_state oper=ENABLED avail=OK, nack!</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span>
<span class="n">gsm_ts_and_pchan_name</span><span class="p">(</span><span class="n">ts</span><span class="p">));</span>
<span class="k">return</span> <span class="n">rsl_tx_chan_act_nack</span><span class="p">(</span><span class="n">lchan</span><span class="p">,</span> <span class="n">RSL_ERR_RR_UNAVAIL</span><span class="p">);</span>
<span class="p">}</span>
<span class="n">and</span> <span class="n">all</span> <span class="n">members</span> <span class="n">of</span> <span class="n">ts</span><span class="o">-></span><span class="n">mo</span><span class="p">.</span><span class="n">nm_state</span> <span class="n">are</span> <span class="n">zero</span><span class="o">-</span><span class="n">initialized</span><span class="p">.</span>
</code></pre> OsmoBTS - Bug #5248 (Resolved): Memory leaks across A-bis/RSL connectionhttps://projects.osmocom.org/issues/52482021-10-06T08:29:15Zfixeria
<p>While working on ttcn3-bts-test, I left osmo-bts running for a while and ran out of memory. Below are the biggest talloc chunks:</p>
<pre>
OsmoBTS# show talloc-context application full tree 0x608000000380
full talloc report on 'OsmoBTS context' (total 25932818 bytes in 2379 blocks)
abis contains 197460 bytes in 1481 blocks (ref 0) 0x608000000380
unixsocket contains 1 bytes in 1 blocks (ref 0) 0x60b00014f060
ipa contains 1213 bytes in 13 blocks (ref 0) 0x60b00014efb0
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x6120000501a0
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b000190350
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x6120000405a0
127.0.2.1 contains 10 bytes in 1 blocks (ref 0) 0x60b00018b0d0
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x61200003bda0
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b00018a1b0
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x61200000e920
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b000184170
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x612000029620
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b00017d6e0
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x612000018220
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b000176620
...
OsmoBTS# show talloc-context application 2 tree 0x627000000160
talloc report on 'OsmoBTS context' (total 598284656 bytes in 48753 blocks)
struct gsm_bts contains 598181420 bytes in 48417 blocks (ref 0) 0x627000000160
struct tlv_parsed contains 4131 bytes in 16 blocks (ref 0) 0x6210016a4560
struct tlv_parsed contains 4106 bytes in 3 blocks (ref 0) 0x6210016a3160
struct tlv_parsed contains 4117 bytes in 7 blocks (ref 0) 0x6210016a1d60
struct tlv_parsed contains 4116 bytes in 4 blocks (ref 0) 0x6210016a0960
struct tlv_parsed contains 4098 bytes in 3 blocks (ref 0) 0x62100169f560
...
struct gsm_bts_trx contains 111271976 bytes in 8983 blocks (ref 0) 0x7fcd7df16860
struct gsm_bts_trx contains 111271976 bytes in 8983 blocks (ref 0) 0x7fcd7e116860
struct gsm_bts_trx contains 111271976 bytes in 8983 blocks (ref 0) 0x7fcd7e316860
struct gsm_bts_trx contains 111271976 bytes in 8983 blocks (ref 0) 0x7fcd7e816860
</pre>
<a name="How-to-reproduce"></a>
<h2 >How to reproduce?<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h2>
<p>In ttcn3-bts-test environment start everything except the testsuite, so that osmo-bts can establish A-bis/OML connections, but not the A-bis/RSL.</p>
<a name="Software-versions"></a>
<h2 >Software versions<a href="#Software-versions" class="wiki-anchor">¶</a></h2>
<pre>
libosmocore ca5ce0d84966c998e353b606a7054f8bc8366cae
libosmo-abis d2d28d83a437f7478a4dfff0c6cae5305801b881
osmo-bts 93fbcdfb39674eb3b5b7768919e14fbc8c455fc4
</pre> 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> Cellular Network Infrastructure - Bug #4957 (Closed): ttcn3-sip-test is broken since 15 Dec 2020https://projects.osmocom.org/issues/49572021-01-19T14:35:56Zfixeria
<p>All test cases fail under both Debian and CentOS:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/1051/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/1051/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-sip-test/238/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-sip-test/238/</a></p>
<p>Although, the 'latest' is relatively stable:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test-latest/828/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test-latest/828/</a></p>
<p>I spent a few hours trying to investigate what's going on. Here are some intermediate results:</p>
<ul>
<li>Q: Did sofia-sip change?
<ul>
<li>A: No. All test cases on my machine also fail with v1.12.11 that I installed back in 2019.</li>
</ul>
</li>
<li>Q: Did the test suite change?
<ul>
<li>A: I could not find any changes that would affect the test suite behavior directly:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ib4399aa488afd917e3eda5e79d56ea3797ef7c78">https://gerrit.osmocom.org/q/Ib4399aa488afd917e3eda5e79d56ea3797ef7c78</a> - only expected-results.xml was changed,</li>
<li><a class="external" href="https://gerrit.osmocom.org/q/I37db9962f51baf2c63bd58ec47ec89f773d7a255">https://gerrit.osmocom.org/q/I37db9962f51baf2c63bd58ec47ec89f773d7a255</a> - changing code that is commended out.</li>
</ul>
</li>
</ul>
</li>
<li>Q: Did osmo-sip-connector's code change?
<ul>
<li>A: Yes, some new commits have been merged recently:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ia156010194c1f4334a4966d01aadfd02fa7097a8">https://gerrit.osmocom.org/q/Ia156010194c1f4334a4966d01aadfd02fa7097a8</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ic926d192c238ef84fb3ad2be27e507e010b0e93f">https://gerrit.osmocom.org/q/Ic926d192c238ef84fb3ad2be27e507e010b0e93f</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ia84602955b913a3bb13de7a6a92048799f2e1955">https://gerrit.osmocom.org/q/Ia84602955b913a3bb13de7a6a92048799f2e1955</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/I870c16d7ee5e5424304f3c1c9fb78af418ae2577">https://gerrit.osmocom.org/q/I870c16d7ee5e5424304f3c1c9fb78af418ae2577</a></li>
</ul>
</li>
<li>... downgrading before them does not change anything though :/
<ul>
<li>tried I17e1adac40ac01daee0dd83da0a6aaebd78ea0dc and I3b1bebbcc9e36be43d8d055c8d28cbb38ff21b37</li>
</ul>
</li>
</ul>
</li>
<li>Q: Did libosmocore's code change?
<ul>
<li>A: Needs to be investigated.
<ul>
<li>I tried downgrading to I781ab838bd02ac1b13d384ce3f4259e26cedb61e => nothing changed.</li>
</ul></li>
</ul></li>
</ul>
<p>The test cases fail due to DTEs listed below:</p>
<ul>
<li>"MNCC_CodecPort.ttcn:19 Dynamic test case error: Initializing a variable of enumerated type @MNCC_Types.MNCC_MsgType with invalid numeric value 346140544. (No such file or directory)" </li>
<li>"Dynamic test case error: SIP Test Port: syntax error "v" -> unexpected character at character position 1." </li>
<li>"MNCC_Emulation.ttcn:348 Dynamic test case error: Write error (Broken pipe)"</li>
</ul>
<p>Sometimes it's one reason, sometimes another. Sometimes there is no DTE but "timeout of Tguard". Weird.</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> OsmoBSC - Bug #4755 (Resolved): Premature OML Radio Carrier(00,00,ff) Opstarthttps://projects.osmocom.org/issues/47552020-09-16T13:44:33Zfixeria
<p>During the A-bis/OML bootstrapping, osmo-bsc sends <em>Opstart</em> to the <em>Radio Carrier</em> MO twice:</p>
<pre>
$ tshark -r /tmp/oml.pcap -Y "gsm_abis_oml.fom.obj_class == 0x02"
14 0.009785 127.0.0.1 → 127.0.0.1 OML 88 OML Radio Carrier(00,00,ff) State Changed Event Report NULL Power off Locked
37 0.019692 127.0.0.1 → 127.0.0.1 OML 88 OML Radio Carrier(00,00,ff) State Changed Event Report Disabled OK Locked
39 0.021458 127.0.0.1 → 127.0.0.1 OML 80 OML Radio Carrier(00,00,ff) Software Activated Report
89 0.039537 127.0.0.1 → 127.0.0.1 OML 80 OML Radio Carrier(00,00,ff) Opstart (!)
90 0.039675 127.0.0.1 → 127.0.0.1 OML 80 OML Radio Carrier(00,00,ff) Opstart ACK
91 0.039967 127.0.0.1 → 127.0.0.1 OML 87 OML Radio Carrier(00,00,ff) Set Radio Carrier Attributes
92 0.041042 127.0.0.1 → 127.0.0.1 OML 87 OML Radio Carrier(00,00,ff) Set Radio Carrier Attributes ACK
101 0.045359 127.0.0.1 → 127.0.0.1 OML 82 OML Radio Carrier(00,00,ff) Change Administrative State Unlocked
102 0.046372 127.0.0.1 → 127.0.0.1 OML 82 OML Radio Carrier(00,00,ff) Change Administrative State ACK Unlocked
103 0.046480 127.0.0.1 → 127.0.0.1 OML 88 OML Radio Carrier(00,00,ff) State Changed Event Report Disabled OK Unlocked
105 0.047801 127.0.0.1 → 127.0.0.1 OML 80 OML Radio Carrier(00,00,ff) Opstart (!)
106 0.048047 127.0.0.1 → 127.0.0.1 OML 82 OML Radio Carrier(00,00,ff) Opstart NACK
</pre>
<p>According to 3GPP TS 12.21, figure 2, we shall send it once, after the "Attribute setting" step. Therefore, the first <em>Opstart</em> (packet 89) is premature, and shall not be sent. The code in osmo-bsc looks correct: we send the <em>Opstart</em> in sw_activ_rep() after sending of both <em>Set Radio Carrier Attributes</em> and <em>Change Administrative State</em>.</p>
<pre><code class="c syntaxhl"><span class="k">case</span> <span class="n">NM_OC_RADIO_CARRIER</span><span class="p">:</span> <span class="p">{</span>
<span class="cm">/*
* Locking the radio carrier will make it go
* offline again and we would come here. The
* framework should determine that there was
* no change and avoid recursion.
*
* This code is here to make sure that on start
* a TRX remains locked.
*/</span>
<span class="kt">int</span> <span class="n">rc_state</span> <span class="o">=</span> <span class="n">trx</span><span class="o">-></span><span class="n">mo</span><span class="p">.</span><span class="n">nm_state</span><span class="p">.</span><span class="n">administrative</span><span class="p">;</span>
<span class="cm">/* Patch ARFCN into radio attribute */</span>
<span class="k">struct</span> <span class="n">msgb</span> <span class="o">*</span><span class="n">msgb</span> <span class="o">=</span> <span class="n">nanobts_attr_radio_get</span><span class="p">(</span><span class="n">trx</span><span class="o">-></span><span class="n">bts</span><span class="p">,</span> <span class="n">trx</span><span class="p">);</span>
<span class="n">abis_nm_set_radio_attr</span><span class="p">(</span><span class="n">trx</span><span class="p">,</span> <span class="n">msgb</span><span class="o">-></span><span class="n">data</span><span class="p">,</span> <span class="n">msgb</span><span class="o">-></span><span class="n">len</span><span class="p">);</span>
<span class="n">msgb_free</span><span class="p">(</span><span class="n">msgb</span><span class="p">);</span>
<span class="n">abis_nm_chg_adm_state</span><span class="p">(</span><span class="n">trx</span><span class="o">-></span><span class="n">bts</span><span class="p">,</span> <span class="n">foh</span><span class="o">-></span><span class="n">obj_class</span><span class="p">,</span>
<span class="n">trx</span><span class="o">-></span><span class="n">bts</span><span class="o">-></span><span class="n">bts_nr</span><span class="p">,</span> <span class="n">trx</span><span class="o">-></span><span class="n">nr</span><span class="p">,</span> <span class="mh">0xff</span><span class="p">,</span>
<span class="n">rc_state</span><span class="p">);</span>
<span class="n">abis_nm_opstart</span><span class="p">(</span><span class="n">trx</span><span class="o">-></span><span class="n">bts</span><span class="p">,</span> <span class="n">foh</span><span class="o">-></span><span class="n">obj_class</span><span class="p">,</span> <span class="n">trx</span><span class="o">-></span><span class="n">bts</span><span class="o">-></span><span class="n">bts_nr</span><span class="p">,</span>
<span class="n">trx</span><span class="o">-></span><span class="n">nr</span><span class="p">,</span> <span class="mh">0xff</span><span class="p">);</span>
<span class="k">break</span><span class="p">;</span>
<span class="p">}</span>
</code></pre> OsmoBSC - Bug #4624 (Resolved): osmo-bsc leaks memoryhttps://projects.osmocom.org/issues/46242020-06-19T19:23:32Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: ttcn3-bsc-test: all LCLS test cases broken since build #987 (Resolved)" href="https://projects.osmocom.org/issues/4619">#4619</a>, I noticed that osmo-bsc (or libosmo-abis?) leaks memory.</p>
<p>Before running LCLS test cases:</p>
<pre>
OsmoBSC# show talloc-context application brief
talloc report on 'osmo-bsc' (total 914581 bytes in 584 blocks)
telnet_connection contains 89 bytes in 2 blocks (ref 0) 0x561a66e7a910
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x561a66e9a420
struct osmo_ss7_instance contains 3452 bytes in 28 blocks (ref 0) 0x561a66e7b6a0
struct cmd_element contains 122 bytes in 2 blocks (ref 0) 0x561a66e3c3a0
struct cmd_element contains 123 bytes in 2 blocks (ref 0) 0x561a66e3b410
struct cmd_element contains 121 bytes in 2 blocks (ref 0) 0x561a66e38860
../../../../src/libosmocore/src/vty/utils.c:353 contains 168 bytes in 1 blocks (ref 0) 0x561a66c6fd10
../../../../src/libosmocore/src/vty/utils.c:353 contains 56 bytes in 1 blocks (ref 0) 0x561a66c6fc70
../../../../src/libosmocore/src/vty/utils.c:353 contains 495 bytes in 1 blocks (ref 0) 0x561a66c6fa10
../../../../src/libosmocore/src/vty/utils.c:353 contains 130 bytes in 1 blocks (ref 0) 0x561a66c5a120
abis contains 193781 bytes in 24 blocks (ref 0) 0x561a66c54630 // <--- check
struct gsm_network contains 709584 bytes in 488 blocks (ref 0) 0x561a66c53080
logging contains 5971 bytes in 11 blocks (ref 0) 0x561a66c52880
counter contains 0 bytes in 1 blocks (ref 0) 0x561a66c52810
subch_txq_entry contains 0 bytes in 1 blocks (ref 0) 0x561a66c527a0
bs11_file_list_entry contains 0 bytes in 1 blocks (ref 0) 0x561a66c52730
paging_request contains 0 bytes in 1 blocks (ref 0) 0x561a66c526c0
xua_msg contains 0 bytes in 1 blocks (ref 0) 0x561a66c52650
osmo_signal contains 480 bytes in 13 blocks (ref 0) 0x561a66c525e0
msgb contains 0 bytes in 1 blocks (ref 0) 0x561a66c52570
</pre>
<p>After running LCLS test cases:</p>
<pre>
OsmoBSC# show talloc-context application brief
talloc report on 'osmo-bsc' (total 1659989 bytes in 723 blocks)
telnet_connection contains 89 bytes in 2 blocks (ref 0) 0x560e7f96c910
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x560e7f98dcc0
struct osmo_ss7_instance contains 5326 bytes in 36 blocks (ref 0) 0x560e7f97af50
struct cmd_element contains 122 bytes in 2 blocks (ref 0) 0x560e7f92e3a0
struct cmd_element contains 123 bytes in 2 blocks (ref 0) 0x560e7f92d410
struct cmd_element contains 121 bytes in 2 blocks (ref 0) 0x560e7f92a860
../../../../src/libosmocore/src/vty/utils.c:353 contains 168 bytes in 1 blocks (ref 0) 0x560e7f761d10
../../../../src/libosmocore/src/vty/utils.c:353 contains 56 bytes in 1 blocks (ref 0) 0x560e7f761c70
../../../../src/libosmocore/src/vty/utils.c:353 contains 495 bytes in 1 blocks (ref 0) 0x560e7f761a10
../../../../src/libosmocore/src/vty/utils.c:353 contains 130 bytes in 1 blocks (ref 0) 0x560e7f74c120
abis contains 869141 bytes in 66 blocks (ref 0) 0x560e7f746630 // <--- check
struct gsm_network contains 777226 bytes in 570 blocks (ref 0) 0x560e7f745080
logging contains 6503 bytes in 18 blocks (ref 0) 0x560e7f744880
counter contains 0 bytes in 1 blocks (ref 0) 0x560e7f744810
subch_txq_entry contains 0 bytes in 1 blocks (ref 0) 0x560e7f7447a0
bs11_file_list_entry contains 0 bytes in 1 blocks (ref 0) 0x560e7f744730
paging_request contains 0 bytes in 1 blocks (ref 0) 0x560e7f7446c0
xua_msg contains 0 bytes in 1 blocks (ref 0) 0x560e7f744650
osmo_signal contains 480 bytes in 13 blocks (ref 0) 0x560e7f7445e0
msgb contains 0 bytes in 1 blocks (ref 0) 0x560e7f744570
</pre>
<p>Here is a full report on the 'abis' chink:</p>
<pre>
OsmoBSC# show talloc-context application full tree 0x560e7f746630
full talloc report on 'osmo-bsc' (total 1659989 bytes in 723 blocks)
abis contains 869141 bytes in 66 blocks (ref 0) 0x560e7f746630
unixsocket contains 1 bytes in 1 blocks (ref 0) 0x560e7f746880
ipa contains 820273 bytes in 56 blocks (ref 0) 0x560e7f746810
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa80dc0
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa73d20
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa68040
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa5c360
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa50680
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa449a0
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa38cc0
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa2bc20
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa1ff40
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa14260
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa08580
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9f6500
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9ea820
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9deb40
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9c9550
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9b26b0
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9a3380
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct ipa_server_link contains 96 bytes in 2 blocks (ref 0) 0x560e7f97bb30
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x560e7f99fb90
struct ipa_server_link contains 96 bytes in 2 blocks (ref 0) 0x560e7f97ba70
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x560e7f985340
e1inp contains 48867 bytes in 8 blocks (ref 0) 0x560e7f7466a0
struct e1inp_line contains 48673 bytes in 3 blocks (ref 0) 0x560e7f96f050
struct ipaccess_line contains 1 bytes in 1 blocks (ref 17) 0x560e7f96d020
../../../src/libosmocore/src/rate_ctr.c:234 contains 432 bytes in 1 blocks (ref 17) 0x560e7f97ad30
e1inp_sign_link contains 193 bytes in 4 blocks (ref 0) 0x560e7f746710
struct e1inp_sign_link contains 64 bytes in 1 blocks (ref 0) 0x560e7f9c8520
struct e1inp_sign_link contains 64 bytes in 1 blocks (ref 0) 0x560e7f97b6a0
struct e1inp_sign_link contains 64 bytes in 1 blocks (ref 0) 0x560e7f97b7d0
</pre>
<p>Assigning to <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> (as discussed) since he was been working on reference counting recently.<br />Please see a capture file (containing GSMTAP logs, all debug) attached.</p> Cellular Network Infrastructure - Bug #4618 (Resolved): osmo-gsm-tester_virtual is completely bro...https://projects.osmocom.org/issues/46182020-06-17T08:59:41Zfixeria
<p>Check out <a class="external" href="https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/test_results_analyzer/</a>.</p>
<pre>
Traceback (most recent call last):
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/core/test.py", line 76, in run
self.path)
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/core/util.py", line 367, in run_python_file
spec.loader.exec_module( importlib.util.module_from_spec(spec) )
File "<frozen importlib._bootstrap_external>", line 673, in exec_module
File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
File "/build/osmo-gsm-tester/sysmocom/suites/nitb_netreg_mass/register_default_mass.py", line 14, in <module>
modems = tenv.all_resources(tenv.modem)
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/testenv.py", line 279, in all_resources
l.append(resource_func())
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/testenv.py", line 264, in modem
ms_obj = MS.get_instance_by_type(self, conf)
File "/build/osmo-gsm-tester/src/osmo_gsm_tester/obj/ms.py", line 78, in get_instance_by_type
return ms_class(testenv, conf)
TypeError: Can't instantiate abstract class MSOsmoMobile with abstract methods get_assigned_addr, is_registered
</pre> OsmoHLR - Bug #4385 (Resolved): mslookup_client_mdns_test fails on my machinehttps://projects.osmocom.org/issues/43852020-01-29T10:26:07Zfixeria
<p>Since the mslookup-related code was merged to OsmoHLR, I noticed that mslookup_client_mdns_test fails on my machine, while daily build jobs in Jenkins do pass just fine. I am using the recent versions, in particular:</p>
<ul>
<li>libosmocore 89c04288252f1a50bbba5680c2f884a95f0eba2d</li>
<li>libosmo-abis ef1f327c967d5ee974e039d0da62c79e9ab9184b</li>
<li>osmo-hlr 5e5ce4aef29a9cb6dcc5f811899c92b61a9995d6</li>
</ul>
<p>Here is the test output:</p>
<pre>
Total time passed: 0.000000 s
-- test_server_client --
server_init
client_init
client_query
sending mDNS query: gsup.hlr.123456789012345.imsi
Assert failed osmo_select_main_ctx(1) == 1 mslookup_client_mdns_test.c:180
backtrace() returned 7 addresses
/usr/local/lib/libosmocore.so.12(+0x1a13f) [0x7f726537f13f]
/usr/local/lib/libosmocore.so.12(osmo_panic+0xce) [0x7f726537f0de]
tests/mslookup/mslookup_client_mdns_test(+0x5c2c) [0x557731de1c2c]
tests/mslookup/mslookup_client_mdns_test(+0x688a) [0x557731de288a]
/usr/lib/libc.so.6(__libc_start_main+0xf3) [0x7f726481c153]
tests/mslookup/mslookup_client_mdns_test(+0x44be) [0x557731de04be]
Aborted (core dumped)
</pre>
<p>Adding an additional fprintf() before doing OSMO_ASSERT() gives me:</p>
<pre>
sending mDNS query: gsup.hlr.123456789012345.imsi
Wait, rc=0?!?
Assert failed rc == 1 mslookup_client_mdns_test.c:182
</pre> libosmo-sccp + libosmo-sigtran - Bug #4378 (Resolved): Having 'sctp-role client' in configuration...https://projects.osmocom.org/issues/43782020-01-28T10:00:14Zfixeria
<a name="How-to-reproduce"></a>
<h2 >How to reproduce?<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h2>
<p>Just add 'sctp-role client' to your configuration file, e.g. to osmo-msc.cfg:</p>
<pre>
cs7 instance 0
point-code 0.23.1
asp asp-clnt-OsmoMSC-A 2905 0 m3ua
remote-ip 127.0.0.1
sctp-role client ! <-- this line causes OsmoMSC to use 100% CPU
as as-clnt-OsmoMSC-A m3ua
asp asp-clnt-OsmoMSC-A
routing-key 1 0.23.1
</pre>
<a name="What-happens"></a>
<h2 >What happens?<a href="#What-happens" class="wiki-anchor">¶</a></h2>
<p>Looking at the output of strace, it seems like some file descriptor makes the select() loop non-blocking:</p>
<pre>
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=519755}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=519751})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=519456}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=519450})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=519371}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=519367})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=519280}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=519277})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=519191}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=519187})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=519112}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=519109})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=519038}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=519035})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518958}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518955})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518877}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518872})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518813}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518810})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518747}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518744})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518686}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518683})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518632}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518619})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518553}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518550})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518501}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518498})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518423}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518420})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518353}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518350})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518282}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518278})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518132}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518128})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=518048}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=518045})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517967}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517963})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517888}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517885})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517809}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517806})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517730}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517727})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517651}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517647})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517576}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517573})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517519}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517517})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517465}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517461})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517395}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517392})
select(11, [3 4 5 6 9 10], [4 10], [], {tv_sec=0, tv_usec=517317}) = 2 (in [4], out [4], left {tv_sec=0, tv_usec=517314})
</pre>
<p>lsof tells that fd=4 is an SCTP connection:</p>
<pre>
$ lsof -p 387341 -ad 4
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
osmo-msc 387341 fixeria 4u sock 0,9 0t0 459782671 protocol: SCTP
</pre>
<p>OsmoBSC fails to establish connection to the MSC:</p>
<pre>
Jan 28 16:45:50 DELL osmo-bsc[389147]: DMSC NOTICE a_reset.c:106 A-RESET(msc-0)[0x55b321ad6a70]{DISC}: (re)sending BSSMAP RESET message...
Jan 28 16:45:50 DELL osmo-bsc[389147]: DMSC NOTICE osmo_bsc_sigtran.c:102 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
Jan 28 16:45:50 DELL osmo-stp[389002]: DLSS7 ERROR osmo_ss7_hmrt.c:257 MTP-TRANSFER.req for DPC 185: no route!
Jan 28 16:45:52 DELL osmo-bsc[389147]: DMSC NOTICE a_reset.c:106 A-RESET(msc-0)[0x55b321ad6a70]{DISC}: (re)sending BSSMAP RESET message...
Jan 28 16:45:52 DELL osmo-bsc[389147]: DMSC NOTICE osmo_bsc_sigtran.c:102 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
Jan 28 16:45:52 DELL osmo-stp[389002]: DLSS7 ERROR osmo_ss7_hmrt.c:257 MTP-TRANSFER.req for DPC 185: no route!
Jan 28 16:45:54 DELL osmo-bsc[389147]: DMSC NOTICE a_reset.c:106 A-RESET(msc-0)[0x55b321ad6a70]{DISC}: (re)sending BSSMAP RESET message...
Jan 28 16:45:54 DELL osmo-bsc[389147]: DMSC NOTICE osmo_bsc_sigtran.c:102 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
Jan 28 16:45:54 DELL osmo-stp[389002]: DLSS7 ERROR osmo_ss7_hmrt.c:257 MTP-TRANSFER.req for DPC 185: no route!
Jan 28 16:45:56 DELL osmo-bsc[389147]: DMSC NOTICE a_reset.c:106 A-RESET(msc-0)[0x55b321ad6a70]{DISC}: (re)sending BSSMAP RESET message...
Jan 28 16:45:56 DELL osmo-bsc[389147]: DMSC NOTICE osmo_bsc_sigtran.c:102 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP
Jan 28 16:45:56 DELL osmo-stp[389002]: DLSS7 ERROR osmo_ss7_hmrt.c:257 MTP-TRANSFER.req for DPC 185: no route!
</pre>
<p>OsmoSTP has the following routing table:</p>
<pre>
OsmoSTP# show cs7 instance 0 route
Routing table = system
C=Cong Q=QoS P=Prio
Destination C Q P Linkset Name Linkset Non-adj Route
---------------------- - - - ------------------- ------- ------- -------
0.23.3/14 0 as-rkm-2 ? ? ?
</pre>
<a name="Some-more-observations"></a>
<h2 >Some more observations<a href="#Some-more-observations" class="wiki-anchor">¶</a></h2>
<p>I don't know the exact role OsmoMSC is supposed to play. Adding this line to osmo-bsc.cfg replicates the same behaviour. Changing sctp-role from 'client' to 'server' or omitting this line makes both OsmoMSC and OsmoBSC talk to each other just fine again.</p>
<p>I had this line in my osmo-msc.cfg since the last breakage of libosmo-sccp, and so far everything was working good (until the recent upgrade). Even if this is an incorrect configuration, we should not keep OsmoMSC running and eating CPU. Aborting the process makes more sense in this case. Otherwise it's not easy to notice this problem.</p>
<p><a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> any ideas?</p> libosmocore - Bug #3626 (Resolved): LAPDm code pulls both 'l1h' and 'l2h' of msgbhttps://projects.osmocom.org/issues/36262018-10-04T00:26:25Zfixeria
<p>In some cases, it's required to keep some data before the actual MAC-block, e.g. in order to indicate<br />the FDMA/TDMA info (frame number, ARFCN, etc.) to the upper layers, but the current implementation<br />doesn't allow this, because it calls msgb_pull_to_l3() stripping all headers. In other words,<br />when a message buffer is being passed through the current LAPDm code, everything before the<br />data frame is getting lost.</p> OsmoBTS - Bug #3510 (Resolved): Make sure the ECU (Error Concealment Unit) is working correctlyhttps://projects.osmocom.org/issues/35102018-08-29T07:50:27Zfixeria
<p>In 69d0d506775c82eb2bde66fe748100a94a3173a0 "osmo-bts-trx: perform error concealment for FR frames",<br />the ECU (Error Concealment Unit) was introduced. In short, if one (or more) speech frame is lost,<br />one may experience some unpleasant audio effects. The ECU is used to avoid such effects.</p>
<p>While working on audio support in OsmocomBB, I have discovered that the libosmocoding API<br />actually produces decoded <strong>speech frames in RTP format</strong>, and I guess the ECU implementation<br />may expect <strong>speech frames in canonical format</strong>.</p>
<p>I think it makes sense to:</p>
<ul>
<li>clarify, which frame format is expected by the libosmocodec's ECU FR implementation?
<ul>
<li>add some comments there (I couldn't find any);</li>
</ul>
</li>
<li>manually test with a regular phone (by dripping TCH bursts somehow);</li>
<li>add some TTCN-3 testing coverage;</li>
</ul> OsmocomBB - Bug #3467 (Resolved): trxcon/sched_clck.c: use CLOCK_MONOTONIC for TDMA frame timerhttps://projects.osmocom.org/issues/34672018-08-16T16:51:10Zfixeria
<p>Hi Stefan,</p>
<p>I was AFK and missed your messages, but now you're offline, so I will answer here.</p>
<blockquote>
<p>I've been reading trxcon code today to learn more about how gsm frames are laid out<br />and how they are processed; the code is a surprisingly great resource for this!</p>
</blockquote>
<p>Thanks. I am glad to hear that this code is helpful for other people :)<br />But it was not written from scratch, some parts are based on the OsmoBTS code,<br />and this is another great source for learning new things about GSM L1.</p>
<blockquote>
<p>I also found what looks like bugs in the clock code: <a class="external" href="https://paste.apache.org/XgAV">https://paste.apache.org/XgAV</a></p>
</blockquote>
<p>This part of the code is also heavily based on the corresponding part of OsmoBTS,<br />but in OsmoBTS it was updated: <a class="external" href="https://gerrit.osmocom.org/3037/">https://gerrit.osmocom.org/3037/</a>, unlike trxcon.</p>
<blockquote>
<p>I plan to write patches for this soon, just checking if you agree</p>
</blockquote>
<p>Sure, thanks!</p>
<p>I have this task in my personal TODO list, but still have no enough time for that.<br />So, feel free, I will be happy to review ;)</p> OsmoGGSN (former OpenGGSN) - Bug #3230 (Resolved): configure: linux/if.h: present but cannot be c...https://projects.osmocom.org/issues/32302018-05-03T15:56:10Zfixeria
<pre>
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking linux/if.h usability... no
checking linux/if.h presence... yes
configure: WARNING: linux/if.h: present but cannot be compiled
configure: WARNING: linux/if.h: check for missing prerequisite headers?
configure: WARNING: linux/if.h: see the Autoconf documentation
configure: WARNING: linux/if.h: section "Present But Cannot Be Compiled"
configure: WARNING: linux/if.h: proceeding with the compiler's result
configure: WARNING: ## ------------------------------------------------- ##
configure: WARNING: ## Report this to osmocom-net-gprs@lists.osmocom.org ##
configure: WARNING: ## ------------------------------------------------- ##
checking for linux/if.h... no
checking net/if.h usability... yes
checking net/if.h presence... yes
checking for net/if.h... yes
checking linux/if_tun.h usability... yes
checking linux/if_tun.h presence... yes
checking for linux/if_tun.h... yes
checking net/if_tun.h usability... no
checking net/if_tun.h presence... no
checking for net/if_tun.h... no
checking linux/netlink.h usability... yes
checking linux/netlink.h presence... yes
checking for linux/netlink.h... yes
checking linux/rtnetlink.h usability... yes
checking linux/rtnetlink.h presence... yes
checking for linux/rtnetlink.h... yes
checking for an ANSI C-conforming const... yes
checking for mode_t... yes
checking for size_t... yes
...
</pre>
<p>Anyone else can confirm this? If no, I'll share some more details about my OS.<br />Asking because I don't see such messages during compilation of other osmo-*.</p> OsmoBTS - Bug #3055 (Closed): osmo-bts-trx: slow TA loop feedbackhttps://projects.osmocom.org/issues/30552018-03-10T10:59:59Zfixeria
<p>There is probably an issue of TA loop in osmo-bts-trx: if a delay between<br />MS and BTS is changed with a big step, e.g. from 0 to 2048 symbol periods,<br />then a new Timing Advance value would be changed too slow, i.e. step by<br />step after each measurement period => changing ToA from 0 to 2048 will take<br />2048 / 256 = 8 measurement periods to compensate the loop...</p>
<p>How to reproduce?</p>
<p>Use both <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki/FakeTRX">FakeTRX</a> and <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki/TRX_Interface#The-trxcon-application">trxcon</a> from <a class="wiki-page" href="https://projects.osmocom.org/projects/baseband/wiki">OsmocomBB</a>. There is an auxiliary<br />command 'FAKE_TOA', which is intended to simulate a delay between MS and BTS:</p>
<p><a class="external" href="https://osmocom.org/projects/baseband/wiki/FakeTRX">https://osmocom.org/projects/baseband/wiki/FakeTRX</a><br /><a class="external" href="https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/trx&id=5ab622d2b72ac6df9d71d42736a6a65ac76cfab5">https://git.osmocom.org/osmocom-bb/commit/?h=fixeria/trx&id=5ab622d2b72ac6df9d71d42736a6a65ac76cfab5</a></p> OsmoTRX - Bug #3029 (Resolved): make distclean is brokenhttps://projects.osmocom.org/issues/30292018-03-02T11:36:43Zfixeria
<p>How to reproduce:</p>
<pre>
1) compile as usual
2) make distclean
</pre>
<p>Result:</p>
<pre>
make[2]: Leaving directory `/opt/osmocom/osmo-trx/Transceiver52M/arm'
Making distclean in x86
make[2]: Entering directory `/opt/osmocom/osmo-trx/Transceiver52M/x86'
Makefile:445: ../common/.deps/convert_base.Plo: No such file or directory
Makefile:446: ../common/.deps/convolve_base.Plo: No such file or directory
make[2]: *** No rule to make target `../common/.deps/convolve_base.Plo'. Stop.
make[2]: Leaving directory `/opt/osmocom/osmo-trx/Transceiver52M/x86'
make[1]: *** [distclean-recursive] Error 1
make[1]: Leaving directory `/opt/osmocom/osmo-trx/Transceiver52M'
make: *** [distclean-recursive] Error 1
</pre> libosmocore - Bug #3021 (Resolved): src/gsm/gsm0808.c/gsm0808_create_paging(): Expression 'cil' i...https://projects.osmocom.org/issues/30212018-03-01T17:58:22Zfixeria
<p>Have a look at the following parts of the gsm0808_create_paging():</p>
<blockquote>
<p>/* Mandatory emelents! */<br />OSMO_ASSERT(imsi);<br />OSMO_ASSERT(cil);</p>
</blockquote>
<p>and</p>
<blockquote>
<p>/* Cell Identifier List 3.2.2.27 */<br />if (cil)<br />gsm0808_enc_cell_id_list(msg, cil);</p>
</blockquote>
<p>The 'cil' cannot be NULL, because we assert this.</p> OsmocomBB - Bug #2925 (Resolved): Unfreed 'Mobile Primitive' chunkshttps://projects.osmocom.org/issues/29252018-02-10T12:59:38Zfixeria
<p>The recent LUA integration code introduced the following<br />memory chunks unfreed at exit of mobile:</p>
<pre>
full talloc report on 'layer2 context' (total 8121 bytes in 9 blocks)
msgb contains 8120 bytes in 8 blocks (ref 0) 0x259e4d0
Mobile Primitive contains 1160 bytes in 1 blocks (ref 0) 0x2651510
Mobile Primitive contains 1160 bytes in 1 blocks (ref 0) 0x2652400
Mobile Primitive contains 1160 bytes in 1 blocks (ref 0) 0x2650720
Mobile Primitive contains 1160 bytes in 1 blocks (ref 0) 0x264fc10
Mobile Primitive contains 1160 bytes in 1 blocks (ref 0) 0x2651f10
Mobile Primitive contains 1160 bytes in 1 blocks (ref 0) 0x2651a20
Mobile Primitive contains 1160 bytes in 1 blocks (ref 0) 0x264f690
</pre>
<p>Isn't this feature optional?<br />Do we really need to keep that chunks all time?</p>