Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-08-30T12:38:17ZOpen Source Mobile Communications
Redmine OsmoBSC - Bug #6159 (New): use paging queue for PAGING messages that come from the BSC co-located...https://osmocom.org/issues/61592023-08-30T12:38:17Zdexter
<p>When a BSC co-located PCU sends a PAGING message to the BSC via PCUIF, then this message is forwarded immediately via RSL as RSL PAGING COMMAND. This illegally circumvents the paging queue of OsmoBSC. The PAGING messages from the PCU should take the route through the paging queue like any other paging does.</p> OsmoBTS - Bug #6147 (Resolved): TC_pcu_data_req_pdtch/ptcch/pdtch/ptcch and TC_pcu_ptcch failhttps://osmocom.org/issues/61472023-08-24T14:29:37Zdexter
<p>Since 20.08.2023 the following testcases fail:</p>
<p>TC_pcu_data_req_pdtch<br />TC_pcu_data_req_ptcch<br />TC_pcu_data_req_pdtch<br />TC_pcu_data_req_ptcch<br />TC_pcu_ptcch</p> OsmoSGSN - Feature #6139 (New): test mobility between GERAN (OsmoPCU) and EUTRAN (Open5GS) end to...https://osmocom.org/issues/61392023-08-22T09:55:50Zdexter
<p>The mobility features that we recently added to Open5GS and OsmoPCU were developed and tested against TTCN3 testsuites, but we didn't confirm the functionality on real hardware yet.</p>
<p>To do this we need to create a setup with an OsmoBTS/OsmoPCU based GERAN cell and an appropriate EUTRAN ENB that is controlled by Open5GS. In order to be able to trigger the cell change it may be required to equip the transmittig antennas of both radios with variable attenuators.</p> OsmoBTS - Feature #5927 (Resolved): use "Direct TLLI" method to confirm IMMEDIATE ASSIGNMENT mess...https://osmocom.org/issues/59272023-02-28T10:42:39Zdexter
<p>To assign downlink TBFs, the PCU sends an IMMEDIATE ASSIGNMENT MAC block through the PCU SOCK interface to the BTS. The BTS confirms the sending of this IMMEDIATE ASSIGNMENT to the PCU by sending the MAC block back to the PCU. The MAC block essentially serves as a reference for the confirmation message. This method has some disadvantages so we decided to replace it.</p>
<p>The new method attaches a TLLI (and a paging group field) to the MAC block when it send to the BTS. The BTS then uses the TLLI instead of the MAC block as an identifier to confirm the sending of the IMMEDIATE ASSIGNMENT. The OsmoPCU already supports the method but OsmoBTS still have to be upgraded.</p>
<p>The related PCU/BTS TTCN3 tests also require an update.</p> OsmoMSC - Bug #3934 (Resolved): TC_sgsap_expl_imsi_det_noneps crashes osmo-mschttps://osmocom.org/issues/39342019-04-16T07:59:23Zdexter
<p>This is presumably similar to <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: TC_smpp_mt_sms crashes osmo-msc (Resolved)" href="https://osmocom.org/issues/3930">#3930</a>.</p>
<pre>
Tue Apr 16 09:56:08 2019 DMNCC <0004> mncc_sock.c:320 MNCC socket at /home/owner/mncc_sock
Tue Apr 16 09:56:08 2019 DLGLOBAL <0012> telnet_interface.c:104 Available via telnet 127.0.0.1 4254
Tue Apr 16 09:56:08 2019 DSMPP <000c> smpp_smsc.c:1017 SMPP at 0.0.0.0 2775
Tue Apr 16 09:56:08 2019 DLCTRL <0019> control_if.c:911 CTRL at 127.0.0.1 4255
Tue Apr 16 09:56:08 2019 DLGSUP <001c> gsup_client.c:73 GSUP connecting to 127.0.0.1:4222
Tue Apr 16 09:56:08 2019 DLMGCP <0022> mgcp_client.c:716 MGCP client: using endpoint domain '@mgw'
Tue Apr 16 09:56:08 2019 DLMGCP <0022> mgcp_client.c:791 MGCP GW connection: r=127.0.0.1:2427<->l=127.0.0.1:2727
Tue Apr 16 09:56:08 2019 DLSCCP <001f> sccp_user.c:397 OsmoMSC-A: Using SS7 instance 0, pc:0.23.1
Tue Apr 16 09:56:08 2019 DLSCCP <001f> sccp_user.c:415 OsmoMSC-A: Using AS instance as-clnt-OsmoMSC-A
Tue Apr 16 09:56:08 2019 DLSCCP <001f> sccp_user.c:420 OsmoMSC-A: Creating default route
Tue Apr 16 09:56:08 2019 DLSCCP <001f> sccp_user.c:476 OsmoMSC-A: Using ASP instance asp-clnt-OsmoMSC-A
Tue Apr 16 09:56:08 2019 DLSS7 <001e> osmo_ss7.c:471 0: Creating SCCP instance
Tue Apr 16 09:56:08 2019 DSGS <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:29118
Tue Apr 16 09:56:08 2019 DBSSAP <0010> a_iface.c:674 Initalizing SCCP connection to stp...
Tue Apr 16 09:56:09 2019 DLGSUP <001c> gsup_client.c:73 GSUP connecting to 127.0.0.1:4222
Tue Apr 16 09:56:10 2019 DLGSUP <001c> gsup_client.c:73 GSUP connecting to 127.0.0.1:4222
Tue Apr 16 09:56:10 2019 DLM3UA <0021> m3ua.c:634 asp-asp-clnt-OsmoMSC-A: Received NOTIFY Type State Change:AS Inactive ()
Tue Apr 16 09:56:10 2019 DLSS7 <001e> xua_default_lm_fsm.c:353 xua_default_lm(asp-clnt-OsmoMSC-A)[0x5607406a6fe0]{ACTIVE}: Ignoring primitive M-ASP_ACTIVE.confirm
Tue Apr 16 09:56:10 2019 DLM3UA <0021> m3ua.c:634 asp-asp-clnt-OsmoMSC-A: Received NOTIFY Type State Change:AS Active ()
Tue Apr 16 09:56:11 2019 DLGSUP <001c> gsup_client.c:73 GSUP connecting to 127.0.0.1:4222
Tue Apr 16 09:56:12 2019 DLGSUP <001c> gsup_client.c:73 GSUP connecting to 127.0.0.1:4222
Tue Apr 16 09:56:13 2019 DLGSUP <001c> gsup_client.c:73 GSUP connecting to 127.0.0.1:4222
Tue Apr 16 09:56:13 2019 DLCTRL <0019> control_if.c:554 accept()ed new CTRL connection from (r=127.0.0.1:38313<->l=127.0.0.1:4255)
Tue Apr 16 09:56:13 2019 DMNCC <0004> mncc_sock.c:275 MNCC Socket has connection with external call control application
Tue Apr 16 09:56:14 2019 DLGSUP <001c> gsup_client.c:73 GSUP connecting to 127.0.0.1:4222
Tue Apr 16 09:56:14 2019 DLINP <0014> input/ipa.c:128 127.0.0.1:4222 connection done
Tue Apr 16 09:56:14 2019 DLINP <0014> input/ipaccess.c:705 received ID get from 0/0/0
Tue Apr 16 09:56:14 2019 DBSSAP <0010> a_iface.c:140 The calling BSC (RI=SSN_PC,PC=0.24.1,SSN=BSSAP) is unknown to this MSC ...
Tue Apr 16 09:56:14 2019 DBSSAP <0010> a_iface.c:490 Adding new BSC connection for BSC RI=SSN_PC,PC=0.24.1,SSN=BSSAP...
Tue Apr 16 09:56:14 2019 DBSSAP <0010> a_iface_bssap.c:112 Rx BSSMAP RESET from BSC RI=SSN_PC,PC=0.24.1,SSN=BSSAP, sending RESET ACK
Tue Apr 16 09:56:14 2019 DSMPP <000c> smpp_smsc.c:753 [] smpp_pdu_rx(00 00 00 32 00 00 00 09 00 00 00 00 00 00 00 01 6d 73 63 5f 74 65 73 74 65 72 00 6f 73 6d 6f 63 6f 6d 31 00 4d 53 43 5f 54 65 73 74 73 00 34 00 00 00 )
Tue Apr 16 09:56:14 2019 DSMPP <000c> smpp_smsc.c:546 [msc_tester] Rx BIND Trx (Version 34)
Tue Apr 16 09:56:14 2019 DSGS <0011> sgs_server.c:123 r=127.0.0.1:9999<->l=127.0.0.1:29118: Accepted new SGs connection
Tue Apr 16 09:56:14 2019 DLCTRL <0019> control_if.c:554 accept()ed new CTRL connection from (r=127.0.0.1:45709<->l=127.0.0.1:4255)
Tue Apr 16 09:56:14 2019 DSGS <0011> fsm.c:423 SGs-VLR-RESET(901-70-0001-01)[0x5607406ac120]{unknown 0}: Allocated
Tue Apr 16 09:56:14 2019 DSGS <0011> fsm.c:423 SGs-UE(num:0)[0x5607406aca20]{SGs-NULL}: Allocated
Tue Apr 16 09:56:14 2019 DSGS <0011> vlr_sgs_fsm.c:359 SGs-UE(num:0)[0x5607406aca20]{SGs-NULL}: state_chg to SGs-NULL
Tue Apr 16 09:56:14 2019 DREF <000a> vlr_sgs.c:83 VLR subscr unknown + SGs: now used by 1 (SGs)
Tue Apr 16 09:56:14 2019 DVLR <000e> vlr.c:446 set IMSI on subscriber; IMSI=262420000011815 id=262420000011815
Tue Apr 16 09:56:14 2019 DVLR <000e> vlr.c:397 New subscr, IMSI: 262420000011815
Tue Apr 16 09:56:14 2019 DVLR <000e> vlr.c:446 set IMSI on subscriber; IMSI=262420000011815 id=262420000011815
Tue Apr 16 09:56:14 2019 DSGS <0011> vlr_sgs.c:96 SGs-UE(num:0)[0x5607406aca20]{SGs-NULL}: Received Event RX_LU_FROM_MME
Tue Apr 16 09:56:14 2019 DSGS <0011> vlr_sgs_fsm.c:55 SGs-UE(num:0)[0x5607406aca20]{SGs-NULL}: state_chg to SGs-LA-UPDATE-PRESENT
Tue Apr 16 09:56:14 2019 DVLR <000e> gsm_04_08.c:1772 SUBSCR(IMSI-262420000011815:TMSInew-0x25E218F7) VLR: update for IMSI=262420000011815 (MSISDN=)
Tue Apr 16 09:56:14 2019 DVLR <000e> vlr.c:197 GSUP tx: 04010862420200001118f5280102
Tue Apr 16 09:56:14 2019 DVLR <000e> vlr.c:1092 GSUP rx 20: 10010862420200001118f5080706942103108151
Tue Apr 16 09:56:14 2019 DREF <000a> vlr.c:1113 VLR subscr IMSI-262420000011815:TMSInew-0x25E218F7 + vlr_gsupc_read_cb: now used by 2 (SGs,vlr_gsupc_read_cb)
Tue Apr 16 09:56:14 2019 DVLR <000e> vlr.c:800 IMSI:262420000011815 has MSISDN:491230011815
Tue Apr 16 09:56:14 2019 DVLR <000e> gsm_04_08.c:1772 SUBSCR(IMSI-262420000011815:MSISDN-491230011815:TMSInew-0x25E218F7) VLR: update for IMSI=262420000011815 (MSISDN=491230011815)
Tue Apr 16 09:56:14 2019 DVLR <000e> vlr.c:197 GSUP tx: 12010862420200001118f5
Tue Apr 16 09:56:14 2019 DREF <000a> vlr.c:1161 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSInew-0x25E218F7 - vlr_gsupc_read_cb: now used by 1 (SGs)
Tue Apr 16 09:56:14 2019 DVLR <000e> vlr.c:1092 GSUP rx 11: 06010862420200001118f5
Tue Apr 16 09:56:14 2019 DREF <000a> vlr.c:1113 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSInew-0x25E218F7 + vlr_gsupc_read_cb: now used by 2 (SGs,vlr_gsupc_read_cb)
Tue Apr 16 09:56:14 2019 DSGS <0011> vlr_sgs.c:116 SGs-UE(num:0)[0x5607406aca20]{SGs-LA-UPDATE-PRESENT}: Received Event TX_LU_ACCEPT
Tue Apr 16 09:56:14 2019 DSGS <0011> vlr_sgs_fsm.c:141 SGs-UE(imsi:262420000011815)[0x5607406aca20]{SGs-LA-UPDATE-PRESENT}: state_chg to SGs-ASSOCIATED
Tue Apr 16 09:56:14 2019 DREF <000a> vlr.c:1161 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSInew-0x25E218F7 - vlr_gsupc_read_cb: now used by 1 (SGs)
Tue Apr 16 09:56:14 2019 DREF <000a> vlr_sgs.c:223 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSInew-0x25E218F7 + vlr_sgs_tmsi_reall_compl: now used by 2 (SGs,vlr_sgs_tmsi_reall_compl)
Tue Apr 16 09:56:14 2019 DSGS <0011> vlr_sgs.c:227 SGs-UE(imsi:262420000011815)[0x5607406aca20]{SGs-ASSOCIATED}: Received Event RX_TMSI_REALLOC
Tue Apr 16 09:56:14 2019 DSGS <0011> vlr_sgs_fsm.c:206 SGs-UE(imsi:262420000011815)[0x5607406aca20]{SGs-ASSOCIATED}: state_chg to SGs-ASSOCIATED
Tue Apr 16 09:56:14 2019 DREF <000a> vlr_sgs.c:228 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSI-0x25E218F7 - vlr_sgs_tmsi_reall_compl: now used by 1 (SGs)
Tue Apr 16 09:56:17 2019 DREF <000a> vlr_sgs.c:140 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSI-0x25E218F7 + vlr_sgs_imsi_detach: now used by 2 (SGs,vlr_sgs_imsi_detach)
Tue Apr 16 09:56:17 2019 DSGS <0011> vlr_sgs.c:166 SGs-UE(imsi:262420000011815)[0x5607406aca20]{SGs-ASSOCIATED}: Received Event RX_DETACH_IND_FROM_MME
Tue Apr 16 09:56:17 2019 DSGS <0011> vlr_sgs_fsm.c:72 SGs-UE(imsi:262420000011815)[0x5607406aca20]{SGs-ASSOCIATED}: state_chg to SGs-NULL
Tue Apr 16 09:56:17 2019 DREF <000a> vlr.c:1254 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSI-0x25E218F7 - attached: now used by 1 (SGs,vlr_sgs_imsi_detach,-1*attached)
Assert failed _osmo_use_count_get_put(&(vsub)->use_count, "attached", -1, "vlr.c", 1254) == 0 vlr.c:1254
backtrace() returned 11 addresses
/usr/local/lib/libosmocore.so.12(osmo_panic+0xbb) [0x7f0dbf83a8db]
osmo-msc(+0x3dfc1) [0x56073f346fc1]
osmo-msc(+0x446ee) [0x56073f34d6ee]
osmo-msc(+0x3637b) [0x56073f33f37b]
osmo-msc(+0x36ccb) [0x56073f33fccb]
/usr/local/lib/libosmonetif.so.6(+0xa7e3) [0x7f0dbf4037e3]
/usr/local/lib/libosmocore.so.12(osmo_select_main+0x1f1) [0x7f0dbf82fbc1]
osmo-msc(+0xd44f) [0x56073f31644f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f0dbe3c52b1]
osmo-msc(+0xd5ea) [0x56073f3165ea]
signal 6 received
backtrace() returned 15 addresses
osmo-msc(+0xd81d) [0x56073f31681d]
/lib/x86_64-linux-gnu/libc.so.6(+0x33030) [0x7f0dbe3d8030]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf) [0x7f0dbe3d7fcf]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a) [0x7f0dbe3d93fa]
/usr/local/lib/libosmocore.so.12(osmo_set_panic_handler+0) [0x7f0dbf83a8e0]
osmo-msc(+0x3dfc1) [0x56073f346fc1]
osmo-msc(+0x446ee) [0x56073f34d6ee]
osmo-msc(+0x3637b) [0x56073f33f37b]
osmo-msc(+0x36ccb) [0x56073f33fccb]
/usr/local/lib/libosmonetif.so.6(+0xa7e3) [0x7f0dbf4037e3]
/usr/local/lib/libosmocore.so.12(osmo_select_main+0x1f1) [0x7f0dbf82fbc1]
osmo-msc(+0xd44f) [0x56073f31644f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f0dbe3c52b1]
osmo-msc(+0xd5ea) [0x56073f3165ea]
talloc report on 'vty' (total 174968 bytes in 9344 blocks)
struct vty contains 863 bytes in 4 blocks (ref 0) 0x5607406ab440
struct vty contains 1004 bytes in 16 blocks (ref 0) 0x5607406a7450
Configure SCCP timer values, see ITU-T Q.714
Waiting for connection confirm message, 1 to 2 minutes (default: 60)
Send keep-alive: on an idle connection, delay before sending an Idle Timer message, 5 to 10 minutes (default: 420)
Receive keep-alive: on an idle connection, delay until considering a connection as stale, 11 to 21 minutes (default: 900)
Waiting for release complete message, 10 to 20 seconds (default: 10)
Waiting for release complete message; or to repeat sending released message after the initial expiry, 10 to 20 seconds (default: 10)
Waiting for release complete message; or to release connection resources, freeze the LRN and alert a maintenance function after the initial expiry, extending to 1 minute (default: 60)
Waiting to resume normal procedure for temporary connection sections during the restart procedure, 23 to 25 minutes (default: 1380)
Waiting to release temporary connection section or alert maintenance function after reset request message is sent, 10 to 20 seconds (default: 10)
Waiting to receive all the segments of the remaining segments, single segmented message after receiving the first segment, 10 to 20 seconds (default: 10)
Timer value, in seconds
contains 1194 bytes in 1 blocks (ref 0) 0x5607405c5830
sccp-timer (conn_est|ias|iar|rel|repeat_rel|int|guard|reset|reassembly) <1-999999> contains 83 bytes in 1 blocks (ref 0) 0x5607405c56c0
save_cwd contains 37 bytes in 1 blocks (ref 0) 0x560740587960
vty_command contains 105253 bytes in 5615 blocks (ref 0) 0x560740574c20
vty_vector contains 66534 bytes in 3705 blocks (ref 0) 0x560740574bb0
full talloc report on 'osmo_msc' (total 18143 bytes in 98 blocks)
telnet_connection contains 177 bytes in 3 blocks (ref 0) 0x56074069e0f0
struct telnet_connection contains 88 bytes in 1 blocks (ref 0) 0x5607406ab380
struct telnet_connection contains 88 bytes in 1 blocks (ref 0) 0x5607406aa590
struct osmo_ss7_instance contains 2478 bytes in 29 blocks (ref 0) 0x56074069e650
struct osmo_sccp_instance contains 266 bytes in 3 blocks (ref 0) 0x5607406a6570
struct osmo_sccp_user contains 90 bytes in 2 blocks (ref 0) 0x5607406a7110
OsmoMSC-A contains 10 bytes in 1 blocks (ref 0) 0x56074069ebd0
struct osmo_ss7_as contains 624 bytes in 7 blocks (ref 0) 0x56074069ee70
as-clnt-OsmoMSC-A contains 18 bytes in 1 blocks (ref 0) 0x56074069f360
struct osmo_fsm_inst contains 364 bytes in 4 blocks (ref 0) 0x56074069f040
struct xua_as_fsm_priv contains 104 bytes in 1 blocks (ref 0) 0x56074069f290
XUA_AS(as-clnt-OsmoMSC-A)[0x56074069f040] contains 42 bytes in 1 blocks (ref 0) 0x56074069f1f0
as-clnt-OsmoMSC-A contains 18 bytes in 1 blocks (ref 0) 0x56074069f170
as-clnt-OsmoMSC-A contains 18 bytes in 1 blocks (ref 0) 0x56074069efc0
struct osmo_ss7_asp contains 1147 bytes in 14 blocks (ref 0) 0x56074069eaa0
(r=127.0.0.1:2905<->l=127.0.0.1:41915) contains 39 bytes in 1 blocks (ref 0) 0x56074069ed70
struct osmo_fsm_inst contains 367 bytes in 4 blocks (ref 0) 0x5607406a5de0
struct xua_asp_fsm_priv contains 104 bytes in 1 blocks (ref 0) 0x5607406a64a0
XUA_ASP(asp-clnt-OsmoMSC-A)[0x5607406a5de0] contains 44 bytes in 1 blocks (ref 0) 0x5607406a5f10
asp-clnt-OsmoMSC-A contains 19 bytes in 1 blocks (ref 0) 0x56074069e1d0
struct osmo_stream_cli contains 242 bytes in 2 blocks (ref 0) 0x5607406a4a00
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x5607406a4b50
struct osmo_fsm_inst contains 278 bytes in 4 blocks (ref 0) 0x5607406a6fe0
struct lm_fsm_priv contains 8 bytes in 1 blocks (ref 0) 0x5607406a7b00
xua_default_lm(asp-clnt-OsmoMSC-A)[0x5607406a6fe0] contains 51 bytes in 1 blocks (ref 0) 0x5607406a57b0
asp-clnt-OsmoMSC-A contains 19 bytes in 1 blocks (ref 0) 0x5607406a5860
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x56074069e2c0
asp-clnt-OsmoMSC-A contains 19 bytes in 1 blocks (ref 0) 0x56074069e540
struct osmo_ss7_route_table contains 145 bytes in 4 blocks (ref 0) 0x56074069e7e0
struct osmo_ss7_route contains 82 bytes in 2 blocks (ref 0) 0x5607406a59f0
as-clnt-OsmoMSC-A contains 18 bytes in 1 blocks (ref 0) 0x5607406a7a80
system contains 7 bytes in 1 blocks (ref 0) 0x56074069e4d0
struct osmo_stream_srv_link contains 352 bytes in 4 blocks (ref 0) 0x56074069c870
struct sgs_connection contains 256 bytes in 2 blocks (ref 0) 0x5607406a6c90
struct osmo_stream_srv contains 104 bytes in 1 blocks (ref 0) 0x5607406a9d20
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x56074069c930
struct sgs_state contains 741 bytes in 5 blocks (ref 0) 0x56074069c690
struct sgs_mme_ctx contains 365 bytes in 4 blocks (ref 0) 0x5607406ac050
struct osmo_fsm_inst contains 261 bytes in 3 blocks (ref 0) 0x5607406ac120
SGs-VLR-RESET(901-70-0001-01)[0x5607406ac120] contains 46 bytes in 1 blocks (ref 0) 0x5607406ac250
901-70-0001-01 contains 15 bytes in 1 blocks (ref 0) 0x5607406ab760
struct smsc contains 600 bytes in 3 blocks (ref 0) 0x560740689f20
struct osmo_esme contains 336 bytes in 1 blocks (ref 0) 0x5607406a6ad0
struct osmo_smpp_acl contains 112 bytes in 1 blocks (ref 0) 0x56074069f460
struct gsm_network contains 7961 bytes in 31 blocks (ref 0) 0x5607405c7580
struct bsc_context contains 441 bytes in 5 blocks (ref 0) 0x5607406aa3f0
struct osmo_fsm_inst contains 241 bytes in 3 blocks (ref 0) 0x5607406a7290
A-RESET(bsc-193)[0x5607406a7290] contains 33 bytes in 1 blocks (ref 0) 0x5607406a73c0
bsc-193 contains 8 bytes in 1 blocks (ref 0) 0x5607406a6d90
struct reset_ctx contains 16 bytes in 1 blocks (ref 0) 0x5607406aa510
struct mgcp_client contains 688 bytes in 1 blocks (ref 0) 0x5607406a4ff0
struct gsm_sms_queue contains 216 bytes in 1 blocks (ref 0) 0x5607406a4830
struct ctrl_handle contains 478 bytes in 5 blocks (ref 0) 0x56074069cfa0
struct ctrl_connection contains 199 bytes in 2 blocks (ref 0) 0x5607406ab1e0
(r=127.0.0.1:45709<->l=127.0.0.1:4255) contains 39 bytes in 1 blocks (ref 0) 0x5607406ab2f0
struct ctrl_connection contains 199 bytes in 2 blocks (ref 0) 0x5607406a9b80
(r=127.0.0.1:38313<->l=127.0.0.1:4255) contains 39 bytes in 1 blocks (ref 0) 0x5607406a9c90
struct mncc_sock_state contains 104 bytes in 1 blocks (ref 0) 0x56074069e880
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x5607405c8440
/home/owner/mncc_sock contains 22 bytes in 1 blocks (ref 0) 0x56074069e450
112 contains 4 bytes in 1 blocks (ref 0) 0x56074069e160
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x56074069e3d0
OsmoMSC contains 8 bytes in 1 blocks (ref 0) 0x5607405c8360
OsmoMSC contains 8 bytes in 1 blocks (ref 0) 0x5607405c83d0
struct vlr_instance contains 2804 bytes in 10 blocks (ref 0) 0x5607405c84c0
struct vlr_subscr contains 1994 bytes in 4 blocks (ref 0) 0x5607406ac2f0
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x5607406aca20
SGs-UE(imsi:262420000011815)[0x5607406aca20] contains 45 bytes in 1 blocks (ref 0) 0x5607406ad210
imsi:262420000011815 contains 21 bytes in 1 blocks (ref 0) 0x5607406ad190
struct osmo_gsup_client contains 490 bytes in 4 blocks (ref 0) 0x5607406a4340
struct osmo_fd contains 48 bytes in 1 blocks (ref 0) 0x5607406a45d0
struct ipa_client_conn contains 186 bytes in 2 blocks (ref 0) 0x5607406a44b0
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x5607406a4670
struct ipaccess_unit contains 64 bytes in 1 blocks (ref 0) 0x5607406a4290
rate_ctr.c:234 contains 2352 bytes in 1 blocks (ref 0) 0x5607405c7920
logging contains 4393 bytes in 9 blocks (ref 0) 0x560740574360
Configure logging
Set the log level for a specified category
A-bis Radio Link Layer (RLL)
Layer3 Call Control (CC)
Layer3 Mobility Management (MM)
Layer3 Radio Resource (RR)
MNCC API for Call Control application
Paging Subsystem
Mobile Switching Center
Media Gateway Control Protocol
Hand-Over
Database Layer
Reference Counting
Control interface
SMPP interface for external SMS apps
Radio Access Network Application Part Protocol
Visitor Location Register
Iu-CS Protocol
BSSAP Protocol (A Interface)
SGs Interface (SGsAP)
Library-internal global log family
LAPD in libosmogsm
A-bis Intput Subsystem
A-bis B-Subchannel TRAU Frame Multiplex
A-bis Input Driver for Signalling
A-bis Input Driver for B-Channels (voice)
Layer3 Short Message Service (SMS)
Control Interface
GPRS GTP library
Statistics messages and logging
Generic Subscriber Update Protocol
Osmocom Authentication Protocol
libosmo-sigtran Signalling System 7
libosmo-sigtran SCCP Implementation
libosmo-sigtran SCCP User Adaptation
libosmo-sigtran MTP3 User Adaptation
libosmo-mgcp Media Gateway Control Protocol
libosmo-netif Jitter Buffer
Remote SIM protocol
Deprecated alias for 'no logging level force-all'
contains 1173 bytes in 1 blocks (ref 0) 0x5607405dcf70
logging level (rll|cc|mm|rr|mncc|pag|msc|mgcp|ho|db|ref|ctrl|smpp|ranap|vlr|iucs|bssap|sgs|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf|lrspro) everything contains 212 bytes in 1 blocks (ref 0) 0x5607405dcd80
Configure logging
Set the log level for a specified category
A-bis Radio Link Layer (RLL)
Layer3 Call Control (CC)
Layer3 Mobility Management (MM)
Layer3 Radio Resource (RR)
MNCC API for Call Control application
Paging Subsystem
Mobile Switching Center
Media Gateway Control Protocol
Hand-Over
Database Layer
Reference Counting
Control interface
SMPP interface for external SMS apps
Radio Access Network Application Part Protocol
Visitor Location Register
Iu-CS Protocol
BSSAP Protocol (A Interface)
SGs Interface (SGsAP)
Library-internal global log family
LAPD in libosmogsm
A-bis Intput Subsystem
A-bis B-Subchannel TRAU Frame Multiplex
A-bis Input Driver for Signalling
A-bis Input Driver for B-Channels (voice)
Layer3 Short Message Service (SMS)
Control Interface
GPRS GTP library
Statistics messages and logging
Generic Subscriber Update Protocol
Osmocom Authentication Protocol
libosmo-sigtran Signalling System 7
libosmo-sigtran SCCP Implementation
libosmo-sigtran SCCP User Adaptation
libosmo-sigtran MTP3 User Adaptation
libosmo-mgcp Media Gateway Control Protocol
libosmo-netif Jitter Buffer
Remote SIM protocol
Log debug messages and higher levels
Log informational messages and higher levels
Log noticeable messages and higher levels
Log error messages and higher levels
Log only fatal messages
contains 1308 bytes in 1 blocks (ref 0) 0x5607405dc7f0
logging level (rll|cc|mm|rr|mncc|pag|msc|mgcp|ho|db|ref|ctrl|smpp|ranap|vlr|iucs|bssap|sgs|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf|lrspro) (debug|info|notice|error|fatal) contains 233 bytes in 1 blocks (ref 0) 0x5607405dc600
struct log_target contains 242 bytes in 2 blocks (ref 0) 0x560740574970
struct log_category contains 74 bytes in 1 blocks (ref 0) 0x560740574a80
struct log_info contains 1224 bytes in 2 blocks (ref 0) 0x5607405743d0
struct log_info_cat contains 1184 bytes in 1 blocks (ref 0) 0x560740574460
transaction contains 0 bytes in 1 blocks (ref 0) 0x5607405742f0
gsm_call contains 0 bytes in 1 blocks (ref 0) 0x560740574280
sms contains 0 bytes in 1 blocks (ref 0) 0x560740574210
osmo_signal contains 280 bytes in 8 blocks (ref 0) 0x5607405741a0
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x56074069ece0
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x56074069ec50
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x5607406aa840
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x5607406a9690
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x56074069e5c0
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x56074069e340
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x560740652e60
msgb contains 1160 bytes in 2 blocks (ref 0) 0x560740574130
SGsAP contains 1160 bytes in 1 blocks (ref 0) 0x5607406abb60
./start_msc.sh: line 6: 25552 Aborted osmo-msc -c ./osmo-msc.cfg
$
</pre>
<p>This time it was possible to reproduce the issue with gdb:</p>
<pre>
Tue Apr 16 09:58:30 2019 DSGS <0011> vlr_sgs_fsm.c:206 SGs-UE(imsi:262420000011815)[0x55555591b320]{SGs-ASSOCIATED}: state_chg to SGs-ASSOCIATED
Tue Apr 16 09:58:30 2019 DREF <000a> vlr_sgs.c:228 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSI-0x3A4902EF - vlr_sgs_tmsi_reall_compl: now used by 1 (SGs)
Tue Apr 16 09:58:33 2019 DREF <000a> vlr_sgs.c:140 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSI-0x3A4902EF + vlr_sgs_imsi_detach: now used by 2 (SGs,vlr_sgs_imsi_detach)
Tue Apr 16 09:58:33 2019 DSGS <0011> vlr_sgs.c:166 SGs-UE(imsi:262420000011815)[0x55555591b320]{SGs-ASSOCIATED}: Received Event RX_DETACH_IND_FROM_MME
Tue Apr 16 09:58:33 2019 DSGS <0011> vlr_sgs_fsm.c:72 SGs-UE(imsi:262420000011815)[0x55555591b320]{SGs-ASSOCIATED}: state_chg to SGs-NULL
Tue Apr 16 09:58:33 2019 DREF <000a> vlr.c:1254 VLR subscr IMSI-262420000011815:MSISDN-491230011815:TMSI-0x3A4902EF - attached: now used by 1 (SGs,vlr_sgs_imsi_detach,-1*attached)
Assert failed _osmo_use_count_get_put(&(vsub)->use_count, "attached", -1, "vlr.c", 1254) == 0 vlr.c:1254
backtrace() returned 11 addresses
/usr/local/lib/libosmocore.so.12(osmo_panic+0xbb) [0x7ffff731e8db]
/usr/local/bin/osmo-msc(+0x3dfc1) [0x555555591fc1]
/usr/local/bin/osmo-msc(+0x446ee) [0x5555555986ee]
/usr/local/bin/osmo-msc(+0x3637b) [0x55555558a37b]
/usr/local/bin/osmo-msc(+0x36ccb) [0x55555558accb]
/usr/local/lib/libosmonetif.so.6(+0xa7e3) [0x7ffff6ee77e3]
/usr/local/lib/libosmocore.so.12(osmo_select_main+0x1f1) [0x7ffff7313bc1]
/usr/local/bin/osmo-msc(+0xd44f) [0x55555556144f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7ffff5ea92b1]
/usr/local/bin/osmo-msc(+0xd5ea) [0x5555555615ea]
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff5ebd3fa in __GI_abort () at abort.c:89
#2 0x00007ffff731e8e0 in osmo_panic_default (args=0x7fffffffcb68, fmt=0x55555559a28c "Assert failed %s %s:%d\n") at panic.c:49
#3 osmo_panic (fmt=fmt@entry=0x55555559a28c "Assert failed %s %s:%d\n") at panic.c:84
#4 0x0000555555591fc1 in vlr_subscr_expire (vsub=vsub@entry=0x55555591abf0) at vlr.c:1254
#5 0x00005555555986ee in vlr_sgs_imsi_detach (vlr=<optimized out>, imsi=imsi@entry=0x7fffffffcca0 "262420000011815", type=SGSAP_ID_NONEPS_T_COMBINED_UE_EPS_NONEPS) at vlr_sgs.c:171
#6 0x000055555558a37b in sgs_rx_imsi_det_ind (tp=0x7fffffffce40, tp=0x7fffffffce40, imsi=0x7fffffffcca0 "262420000011815", msg=0x55555591a530, sgc=0x555555918650) at sgs_iface.c:634
#7 sgs_iface_rx (sgc=sgc@entry=0x555555918650, msg=msg@entry=0x55555591a530) at sgs_iface.c:985
#8 0x000055555558accb in sgs_conn_readable_cb (conn=0x555555913810) at sgs_server.c:87
#9 0x00007ffff6ee77e3 in osmo_stream_srv_read (conn=0x555555913810) at stream.c:894
#10 osmo_stream_srv_cb (ofd=<optimized out>, what=1) at stream.c:949
#11 0x00007ffff7313bc1 in osmo_fd_disp_fds (_eset=0x7fffffffe050, _wset=0x7fffffffdfd0, _rset=0x7fffffffdf50) at select.c:223
#12 osmo_select_main (polling=<optimized out>) at select.c:263
#13 0x000055555556144f in main (argc=3, argv=0x7fffffffe218) at msc_main.c:724
(gdb)
</pre> OsmoMSC - Bug #3930 (Resolved): TC_smpp_mt_sms crashes osmo-msc https://osmocom.org/issues/39302019-04-15T09:37:33Zdexter
<p>It seems that there were problems introduced with <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-msc/+/13136/">https://gerrit.osmocom.org/#/c/osmo-msc/+/13136/</a>, which now cause osmo-msc to crash.</p>
<pre>
Mon Apr 15 11:32:52 2019 DVLR <000e> fsm.c:535 lu_compl_vlr_fsm(IMSI-262420000000045:MSISDN-491230000045:GERAN-A-0:LU)[0x561d3f9224f0]{LU_COMPL_VLR_S_DONE}: Deallocated
Mon Apr 15 11:32:52 2019 DVLR <000e> vlr_lu_fsm.c:749 vlr_lu_fsm(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f9255d0]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
Mon Apr 15 11:32:52 2019 DMM <0002> vlr_lu_fsm.c:741 RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]{RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
Mon Apr 15 11:32:52 2019 DSMPP <000c> smpp_smsc.c:656 [msc_tester] Tx ALERT_NOTIFICATION (491230000045/3/1): Available
Mon Apr 15 11:32:52 2019 DMM <0002> ran_conn.c:146 RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]{RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
Mon Apr 15 11:32:52 2019 DMM <0002> ran_conn.c:276 RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]{RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
Mon Apr 15 11:32:52 2019 DMM <0002> ran_conn.c:297 RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]{RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
Mon Apr 15 11:32:52 2019 DMM <0002> ran_conn.c:906 RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
Mon Apr 15 11:32:52 2019 DMM <0002> ran_conn.c:408 RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
Mon Apr 15 11:32:52 2019 DMM <0002> ran_conn.c:415 RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
Mon Apr 15 11:32:52 2019 DVLR <000e> ran_conn.c:415 vlr_lu_fsm(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f9255d0]{VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090])
Mon Apr 15 11:32:52 2019 DVLR <000e> ran_conn.c:415 vlr_lu_fsm(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f9255d0]{VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]
Mon Apr 15 11:32:52 2019 DVLR <000e> vlr_lu_fsm.c:1415 vlr_lu_fsm(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f9255d0]{VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
Mon Apr 15 11:32:52 2019 DVLR <000e> fsm.c:514 vlr_lu_fsm(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f9255d0]{VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]
Mon Apr 15 11:32:52 2019 DMM <0002> fsm.c:530 RAN_conn(IMSI-262420000000045:MSISDN-491230000045:TMSI-0x14A42776:GERAN-A-0:LU)[0x561d3f926090]{RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
Mon Apr 15 11:32:52 2019 DSMPP <000c> smpp_smsc.c:753 [msc_tester] smpp_pdu_rx(00 00 00 36 00 00 00 04 00 00 00 00 00 00 00 02 43 4d 54 00 00 00 31 32 33 34 35 00 01 01 34 39 31 32 33 30 30 30 30 30 34 35 00 01 00 00 00 00 00 00 01 00 01 00 )
Mon Apr 15 11:32:52 2019 DSMPP <000c> smpp_smsc.c:735 [msc_tester] Rx SUBMIT-SM (491230000045/1/1)
Assert failed _osmo_use_count_get_put(&(sms->receiver)->use_count, "SMS-receiver", -1, "gsm_04_11.c", 74) == 0 gsm_04_11.c:74
backtrace() returned 11 addresses
/usr/local/lib/libosmocore.so.12(osmo_panic+0xbb) [0x7f2a78ab58db]
osmo-msc(+0x231f5) [0x561d3f3391f5]
osmo-msc(+0x3a192) [0x561d3f350192]
osmo-msc(+0x37d52) [0x561d3f34dd52]
osmo-msc(+0x382a4) [0x561d3f34e2a4]
/usr/local/lib/libosmocore.so.12(osmo_wqueue_bfd_cb+0x73) [0x7f2a78aaff53]
/usr/local/lib/libosmocore.so.12(osmo_select_main+0x1f1) [0x7f2a78aaabc1]
osmo-msc(+0xd44f) [0x561d3f32344f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f2a776402b1]
osmo-msc(+0xd5ea) [0x561d3f3235ea]
signal 6 received
backtrace() returned 15 addresses
osmo-msc(+0xd81d) [0x561d3f32381d]
/lib/x86_64-linux-gnu/libc.so.6(+0x33030) [0x7f2a77653030]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf) [0x7f2a77652fcf]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a) [0x7f2a776543fa]
/usr/local/lib/libosmocore.so.12(osmo_set_panic_handler+0) [0x7f2a78ab58e0]
osmo-msc(+0x231f5) [0x561d3f3391f5]
osmo-msc(+0x3a192) [0x561d3f350192]
osmo-msc(+0x37d52) [0x561d3f34dd52]
osmo-msc(+0x382a4) [0x561d3f34e2a4]
/usr/local/lib/libosmocore.so.12(osmo_wqueue_bfd_cb+0x73) [0x7f2a78aaff53]
/usr/local/lib/libosmocore.so.12(osmo_select_main+0x1f1) [0x7f2a78aaabc1]
osmo-msc(+0xd44f) [0x561d3f32344f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f2a776402b1]
osmo-msc(+0xd5ea) [0x561d3f3235ea]
talloc report on 'vty' (total 174968 bytes in 9344 blocks)
struct vty contains 863 bytes in 4 blocks (ref 0) 0x561d3f921d80
struct vty contains 1004 bytes in 16 blocks (ref 0) 0x561d3f91dad0
Configure SCCP timer values, see ITU-T Q.714
Waiting for connection confirm message, 1 to 2 minutes (default: 60)
Send keep-alive: on an idle connection, delay before sending an Idle Timer message, 5 to 10 minutes (default: 420)
Receive keep-alive: on an idle connection, delay until considering a connection as stale, 11 to 21 minutes (default: 900)
Waiting for release complete message, 10 to 20 seconds (default: 10)
Waiting for release complete message; or to repeat sending released message after the initial expiry, 10 to 20 seconds (default: 10)
Waiting for release complete message; or to release connection resources, freeze the LRN and alert a maintenance function after the initial expiry, extending to 1 minute (default: 60)
Waiting to resume normal procedure for temporary connection sections during the restart procedure, 23 to 25 minutes (default: 1380)
Waiting to release temporary connection section or alert maintenance function after reset request message is sent, 10 to 20 seconds (default: 10)
Waiting to receive all the segments of the remaining segments, single segmented message after receiving the first segment, 10 to 20 seconds (default: 10)
Timer value, in seconds
contains 1194 bytes in 1 blocks (ref 0) 0x561d3f83c830
sccp-timer (conn_est|ias|iar|rel|repeat_rel|int|guard|reset|reassembly) <1-999999> contains 83 bytes in 1 blocks (ref 0) 0x561d3f83c6c0
save_cwd contains 37 bytes in 1 blocks (ref 0) 0x561d3f7fe960
vty_command contains 105253 bytes in 5615 blocks (ref 0) 0x561d3f7ebc20
vty_vector contains 66534 bytes in 3705 blocks (ref 0) 0x561d3f7ebbb0
full talloc report on 'osmo_msc' (total 17200 bytes in 93 blocks)
telnet_connection contains 177 bytes in 3 blocks (ref 0) 0x561d3f9150f0
struct telnet_connection contains 88 bytes in 1 blocks (ref 0) 0x561d3f921cc0
struct telnet_connection contains 88 bytes in 1 blocks (ref 0) 0x561d3f920d20
struct osmo_ss7_instance contains 2478 bytes in 29 blocks (ref 0) 0x561d3f915650
struct osmo_sccp_instance contains 266 bytes in 3 blocks (ref 0) 0x561d3f91d570
struct osmo_sccp_user contains 90 bytes in 2 blocks (ref 0) 0x561d3f91e110
OsmoMSC-A contains 10 bytes in 1 blocks (ref 0) 0x561d3f915bd0
struct osmo_ss7_as contains 624 bytes in 7 blocks (ref 0) 0x561d3f915e70
as-clnt-OsmoMSC-A contains 18 bytes in 1 blocks (ref 0) 0x561d3f916360
struct osmo_fsm_inst contains 364 bytes in 4 blocks (ref 0) 0x561d3f916040
struct xua_as_fsm_priv contains 104 bytes in 1 blocks (ref 0) 0x561d3f916290
XUA_AS(as-clnt-OsmoMSC-A)[0x561d3f916040] contains 42 bytes in 1 blocks (ref 0) 0x561d3f9161f0
as-clnt-OsmoMSC-A contains 18 bytes in 1 blocks (ref 0) 0x561d3f916170
as-clnt-OsmoMSC-A contains 18 bytes in 1 blocks (ref 0) 0x561d3f915fc0
struct osmo_ss7_asp contains 1147 bytes in 14 blocks (ref 0) 0x561d3f915aa0
(r=127.0.0.1:2905<->l=127.0.0.1:52054) contains 39 bytes in 1 blocks (ref 0) 0x561d3f915d70
struct osmo_fsm_inst contains 367 bytes in 4 blocks (ref 0) 0x561d3f91cde0
struct xua_asp_fsm_priv contains 104 bytes in 1 blocks (ref 0) 0x561d3f91d4a0
XUA_ASP(asp-clnt-OsmoMSC-A)[0x561d3f91cde0] contains 44 bytes in 1 blocks (ref 0) 0x561d3f91cf10
asp-clnt-OsmoMSC-A contains 19 bytes in 1 blocks (ref 0) 0x561d3f9151d0
struct osmo_stream_cli contains 242 bytes in 2 blocks (ref 0) 0x561d3f91ba00
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x561d3f91bb50
struct osmo_fsm_inst contains 278 bytes in 4 blocks (ref 0) 0x561d3f91dfe0
struct lm_fsm_priv contains 8 bytes in 1 blocks (ref 0) 0x561d3f91eb00
xua_default_lm(asp-clnt-OsmoMSC-A)[0x561d3f91dfe0] contains 51 bytes in 1 blocks (ref 0) 0x561d3f91c7b0
asp-clnt-OsmoMSC-A contains 19 bytes in 1 blocks (ref 0) 0x561d3f91c860
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x561d3f9152c0
asp-clnt-OsmoMSC-A contains 19 bytes in 1 blocks (ref 0) 0x561d3f915540
struct osmo_ss7_route_table contains 145 bytes in 4 blocks (ref 0) 0x561d3f9157e0
struct osmo_ss7_route contains 82 bytes in 2 blocks (ref 0) 0x561d3f91c9f0
as-clnt-OsmoMSC-A contains 18 bytes in 1 blocks (ref 0) 0x561d3f91ea80
system contains 7 bytes in 1 blocks (ref 0) 0x561d3f9154d0
struct osmo_stream_srv_link contains 96 bytes in 2 blocks (ref 0) 0x561d3f913870
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x561d3f913930
struct sgs_state contains 376 bytes in 1 blocks (ref 0) 0x561d3f913690
struct smsc contains 600 bytes in 3 blocks (ref 0) 0x561d3f900f20
struct osmo_esme contains 336 bytes in 1 blocks (ref 0) 0x561d3f91dd00
struct osmo_smpp_acl contains 112 bytes in 1 blocks (ref 0) 0x561d3f916460
struct gsm_network contains 7961 bytes in 31 blocks (ref 0) 0x561d3f83e580
struct bsc_context contains 441 bytes in 5 blocks (ref 0) 0x561d3f924bc0
struct osmo_fsm_inst contains 241 bytes in 3 blocks (ref 0) 0x561d3f924d60
A-RESET(bsc-193)[0x561d3f924d60] contains 33 bytes in 1 blocks (ref 0) 0x561d3f924e90
bsc-193 contains 8 bytes in 1 blocks (ref 0) 0x561d3f923fd0
struct reset_ctx contains 16 bytes in 1 blocks (ref 0) 0x561d3f924ce0
struct mgcp_client contains 688 bytes in 1 blocks (ref 0) 0x561d3f91bff0
struct gsm_sms_queue contains 216 bytes in 1 blocks (ref 0) 0x561d3f91b830
struct ctrl_handle contains 478 bytes in 5 blocks (ref 0) 0x561d3f913fa0
struct ctrl_connection contains 199 bytes in 2 blocks (ref 0) 0x561d3f921bb0
(r=127.0.0.1:32793<->l=127.0.0.1:4255) contains 39 bytes in 1 blocks (ref 0) 0x561d3f91e650
struct ctrl_connection contains 199 bytes in 2 blocks (ref 0) 0x561d3f920b80
(r=127.0.0.1:39451<->l=127.0.0.1:4255) contains 39 bytes in 1 blocks (ref 0) 0x561d3f920c90
struct mncc_sock_state contains 104 bytes in 1 blocks (ref 0) 0x561d3f915880
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x561d3f83f440
/home/owner/mncc_sock contains 22 bytes in 1 blocks (ref 0) 0x561d3f915450
112 contains 4 bytes in 1 blocks (ref 0) 0x561d3f915160
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x561d3f9153d0
OsmoMSC contains 8 bytes in 1 blocks (ref 0) 0x561d3f83f360
OsmoMSC contains 8 bytes in 1 blocks (ref 0) 0x561d3f83f3d0
struct vlr_instance contains 2804 bytes in 10 blocks (ref 0) 0x561d3f83f4c0
struct vlr_subscr contains 1994 bytes in 4 blocks (ref 0) 0x561d3f925890
struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x561d3f923bd0
SGs-UE(imsi:262420000000045)[0x561d3f923bd0] contains 45 bytes in 1 blocks (ref 0) 0x561d3f925700
imsi:262420000000045 contains 21 bytes in 1 blocks (ref 0) 0x561d3f925230
struct osmo_gsup_client contains 490 bytes in 4 blocks (ref 0) 0x561d3f91b340
struct osmo_fd contains 48 bytes in 1 blocks (ref 0) 0x561d3f91b5d0
struct ipa_client_conn contains 186 bytes in 2 blocks (ref 0) 0x561d3f91b4b0
127.0.0.1 contains 10 bytes in 1 blocks (ref 0) 0x561d3f91b670
struct ipaccess_unit contains 64 bytes in 1 blocks (ref 0) 0x561d3f91b290
rate_ctr.c:234 contains 2352 bytes in 1 blocks (ref 0) 0x561d3f83e920
logging contains 4393 bytes in 9 blocks (ref 0) 0x561d3f7eb360
Configure logging
Set the log level for a specified category
A-bis Radio Link Layer (RLL)
Layer3 Call Control (CC)
Layer3 Mobility Management (MM)
Layer3 Radio Resource (RR)
MNCC API for Call Control application
Paging Subsystem
Mobile Switching Center
Media Gateway Control Protocol
Hand-Over
Database Layer
Reference Counting
Control interface
SMPP interface for external SMS apps
Radio Access Network Application Part Protocol
Visitor Location Register
Iu-CS Protocol
BSSAP Protocol (A Interface)
SGs Interface (SGsAP)
Library-internal global log family
LAPD in libosmogsm
A-bis Intput Subsystem
A-bis B-Subchannel TRAU Frame Multiplex
A-bis Input Driver for Signalling
A-bis Input Driver for B-Channels (voice)
Layer3 Short Message Service (SMS)
Control Interface
GPRS GTP library
Statistics messages and logging
Generic Subscriber Update Protocol
Osmocom Authentication Protocol
libosmo-sigtran Signalling System 7
libosmo-sigtran SCCP Implementation
libosmo-sigtran SCCP User Adaptation
libosmo-sigtran MTP3 User Adaptation
libosmo-mgcp Media Gateway Control Protocol
libosmo-netif Jitter Buffer
Remote SIM protocol
Deprecated alias for 'no logging level force-all'
contains 1173 bytes in 1 blocks (ref 0) 0x561d3f853f70
logging level (rll|cc|mm|rr|mncc|pag|msc|mgcp|ho|db|ref|ctrl|smpp|ranap|vlr|iucs|bssap|sgs|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf|lrspro) everything contains 212 bytes in 1 blocks (ref 0) 0x561d3f853d80
Configure logging
Set the log level for a specified category
A-bis Radio Link Layer (RLL)
Layer3 Call Control (CC)
Layer3 Mobility Management (MM)
Layer3 Radio Resource (RR)
MNCC API for Call Control application
Paging Subsystem
Mobile Switching Center
Media Gateway Control Protocol
Hand-Over
Database Layer
Reference Counting
Control interface
SMPP interface for external SMS apps
Radio Access Network Application Part Protocol
Visitor Location Register
Iu-CS Protocol
BSSAP Protocol (A Interface)
SGs Interface (SGsAP)
Library-internal global log family
LAPD in libosmogsm
A-bis Intput Subsystem
A-bis B-Subchannel TRAU Frame Multiplex
A-bis Input Driver for Signalling
A-bis Input Driver for B-Channels (voice)
Layer3 Short Message Service (SMS)
Control Interface
GPRS GTP library
Statistics messages and logging
Generic Subscriber Update Protocol
Osmocom Authentication Protocol
libosmo-sigtran Signalling System 7
libosmo-sigtran SCCP Implementation
libosmo-sigtran SCCP User Adaptation
libosmo-sigtran MTP3 User Adaptation
libosmo-mgcp Media Gateway Control Protocol
libosmo-netif Jitter Buffer
Remote SIM protocol
Log debug messages and higher levels
Log informational messages and higher levels
Log noticeable messages and higher levels
Log error messages and higher levels
Log only fatal messages
contains 1308 bytes in 1 blocks (ref 0) 0x561d3f8537f0
logging level (rll|cc|mm|rr|mncc|pag|msc|mgcp|ho|db|ref|ctrl|smpp|ranap|vlr|iucs|bssap|sgs|lglobal|llapd|linp|lmux|lmi|lmib|lsms|lctrl|lgtp|lstats|lgsup|loap|lss7|lsccp|lsua|lm3ua|lmgcp|ljibuf|lrspro) (debug|info|notice|error|fatal) contains 233 bytes in 1 blocks (ref 0) 0x561d3f853600
struct log_target contains 242 bytes in 2 blocks (ref 0) 0x561d3f7eb970
struct log_category contains 74 bytes in 1 blocks (ref 0) 0x561d3f7eba80
struct log_info contains 1224 bytes in 2 blocks (ref 0) 0x561d3f7eb3d0
struct log_info_cat contains 1184 bytes in 1 blocks (ref 0) 0x561d3f7eb460
transaction contains 0 bytes in 1 blocks (ref 0) 0x561d3f7eb2f0
gsm_call contains 0 bytes in 1 blocks (ref 0) 0x561d3f7eb280
sms contains 648 bytes in 2 blocks (ref 0) 0x561d3f7eb210
struct gsm_sms contains 648 bytes in 1 blocks (ref 0) 0x561d3f924f20
osmo_signal contains 280 bytes in 8 blocks (ref 0) 0x561d3f7eb1a0
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x561d3f915ce0
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x561d3f915c50
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x561d3f921840
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x561d3f920690
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x561d3f9155c0
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x561d3f915340
struct signal_handler contains 40 bytes in 1 blocks (ref 0) 0x561d3f8c9e60
msgb contains 190 bytes in 2 blocks (ref 0) 0x561d3f7eb130
SMPP Rx contains 190 bytes in 1 blocks (ref 0) 0x561d3f923d00
./start_msc.sh: line 6: 21718 Aborted osmo-msc -c ./osmo-msc.cfg
</pre> OsmoMSC - Bug #3915 (Resolved): TC_lu_and_mt_call does not passhttps://osmocom.org/issues/39152019-04-11T07:05:33Zdexter
<p>The TTCN3 test TC_lu_and_mt_call does not pass for the last three consecutive test runs.</p> OsmoMSC - Bug #3853 (Resolved): TC_sgsap_mt_sms_and_nothing does not passhttps://osmocom.org/issues/38532019-03-21T14:45:54Zdexter
<p>For the last consecutive test builds TC_sgsap_mt_sms_and_nothing is failing.</p> OsmoMSC - Bug #3704 (Resolved): When Paging request for SMS is unanswered, osmo-msc sends infinit...https://osmocom.org/issues/37042018-11-22T18:01:02Zdexter
<p>The problem occurs when the MSC is attempting to page for an MT SM but the BSC is not responding in any way. The paging requests repeat over and over, even when the SCCP connection is shut down one can still see by the logs that the BSC still trying to page.</p>
<p>The reason for this problem seems not to be located in the code that controls the paging, but rather in the code that runs the SM Queue. The problem is that when the paging fails the SM Queue is trying to deliver the SM again and again. However, there is indeed a mechanism implemented that shall prevent undeliverable SM cycling through the queue again and again. When there are errors during the delivery, the function db_sms_inc_deliver_attempts() is called and once the counters reach a certain maximum the SM is removed from the queue. For some reason this is only done when some error during the delivery happens, but not when the delivery could not be started because the paging did not succeed.</p> OsmoMSC - Bug #3599 (Resolved): TTCN3 test TC_mo_setup_and_nothing does not passhttps://osmocom.org/issues/35992018-09-27T08:47:09Zdexter
<p>The TTCN3 test TC_mo_setup_and_nothing establishes a call until SETUP and then remains silent. A clear from the MSC comand is expected but there seem to be no clear command. This must be investigated because the failure of the test could mean that a call establishment could forever.</p> OsmoBSC - Bug #3527 (Resolved): When EFR is used Speech Version and Speech Codec seem to mismatch...https://osmocom.org/issues/35272018-09-06T07:28:28Zdexter
<p>The specification demands that Speech Codec (choosen) and Speech Version (choosen) are consistent. With osmo-bsc this seems not to be the case when EFR is used. It still shows "GSM speech full rate version 1" in the Speech Version field. This looks odd and needs to be checked back. There should be something like "GSM speech full rate version 2" or so but not 1.</p>
<p>Attached one finds a sample packet.</p> OsmoBTS - Bug #3497 (Resolved): udp/gsmtap multicast is broken osmo-bts-virtual and virtphyhttps://osmocom.org/issues/34972018-08-23T18:08:37Zdexter
<p>Unfortunately libosmocore change I4a8ffb8d598aca88801a4a0322944d7cdd8d4047 introduced than SO_REUSEADDR should be disabled when IPPROTO_UDP is used. Under normal conditions this makes sense and is also necessary to detect when two processes try to use the same port but for multicast situations like we have them with osmo-bts-virtual, virtphy and gsmtap in general this becomes a problem.</p> OsmoBTS - Bug #3465 (Resolved): TTCN3 tests for osmo-bts failhttps://osmocom.org/issues/34652018-08-14T13:20:27Zdexter
<p>At the moment, all osmo-bts tests fail.</p> libosmocore - Bug #3441 (Resolved): two processes can open the same UDP port without errorhttps://osmocom.org/issues/34412018-08-01T11:00:32Zdexter
<p>When two processes open a socket with the same UDP port there will be no error since we set SO_REUSEADDR also for UDP ports. This is dangerous and might lead into situations that are very difficult to debug. There is no point in setting SO_REUSEADDR for UDP ports since UDP is connection less and there can not be any lingering connections like with TCP.</p> OsmoBSC - Bug #3413 (Resolved): TC_lcls_connect_clear does not pass anymore.https://osmocom.org/issues/34132018-07-23T19:39:02Zdexter
<p>After we increased the test coverage in <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: BSC_Tests.ttcn is too tolerant in MGCP validation (Resolved)" href="https://osmocom.org/issues/3292">#3292</a> we observed problems with the LCLS tests. (TC_ho_int is a real regression) Those were then fixed, but now TC_lcls_connect_clear indicates problems again. It is not clear yet what causes the failure, but it the location of the problems seems to be in the second interleave after the clear command is sent. The testcase seems to have problems with receiving/matching the tr_RSL_RF_CHAN_REL() template. The test case passes when CONN_A.receive(tr_RSL_RF_CHAN_REL(?)) is removed from the interleave.</p>
<p>When the interactions are traced using wirshark, the RSL CHANNEL RELEASE message can be seen, so it must be somewhere in the template/interleave processing.</p> Cellular Network Infrastructure - Bug #3384 (Resolved): Translate PT before sending RTP packets (...https://osmocom.org/issues/33842018-07-05T15:06:40Zdexter
<p>When dynamic payload types are used and the call-agent configures two connections with the same codec, but different payload type numbers then osmo-mgw must ensure that the RTP packets are sent with the correct payload type number. This means on the ingress connection the MGW must lookup the codec by the payload type number. On the egress connection the MGW must use the previously looked up codec to determine the matching payload type number that is configured for that codec on the egress connection.</p>
<p>We need: Payload-type number re-writing in osmo-mgw and a TTCN3 testcase that verifies this behavior.</p> OsmoBSC - Bug #3361 (Resolved): VTY option codec-support is not usedhttps://osmocom.org/issues/33612018-06-28T16:12:27Zdexter
<p>osmo-bts has per-bts codec support flags, which are stored in struct bts_codec_conf *codec</p>
<p>The vty option codec-support sets those flags:<br />codec->hr<br />codec->efr<br />codec->amr</p>
<p>But the flags seem not to be used anywhere. In osmo_bsc_bssap.c osmo-bts decides for a codec depending on what the MS and the MSC offer. We should include those flags here as well.</p> OsmoMGW - Feature #3334 (Resolved): use proper sdp in libosmo-mgcp-clienthttps://osmocom.org/issues/33342018-06-11T19:30:18Zdexter
<p>libosmo-mgcp-client currently uses hardcoded SDP with fixed values. It also uses a payload type 255, which is illegal.</p>
<p>- Add new struct members to allow setting of ptime, payload type and rtpmap if needed.<br />- Generate proper SDP and use it when communicating to the MGW<br />- Decode the SDP responses from osmo-mgw.<br />- Update both, the normal mgcp_client and mgcp_client_fsm</p> OsmoBSC - Bug #2939 (Resolved): TTCN3: Fix broken paging testshttps://osmocom.org/issues/29392018-02-13T11:11:23Zdexter
<p>Many of the paging tests still fail. The result is the same for pmaier/fsm and for current master. Also the jenkins shows a very similar picture.</p>
<pre>
#BSC_Tests.TC_paging_imsi_nochan # Pass
#BSC_Tests.TC_paging_tmsi_nochan # Fail
#BSC_Tests.TC_paging_tmsi_any # Fail
#BSC_Tests.TC_paging_tmsi_sdcch # Fail
#BSC_Tests.TC_paging_tmsi_tch_f # Fail
#BSC_Tests.TC_paging_tmsi_tch_hf # Fail
#BSC_Tests.TC_paging_imsi_nochan_cgi # Pass
#BSC_Tests.TC_paging_imsi_nochan_lac_ci # Pass
#BSC_Tests.TC_paging_imsi_nochan_ci # Pass
#BSC_Tests.TC_paging_imsi_nochan_lai # Fail
#BSC_Tests.TC_paging_imsi_nochan_lac # Fail
#BSC_Tests.TC_paging_imsi_nochan_all # Pass
#BSC_Tests.TC_paging_imsi_a_reset # Fail
#BSC_Tests.TC_paging_imsi_load # Fail
#BSC_Tests.TC_paging_counter # Fail
#BSC_Tests.TC_rsl_drop_counter # Pass
</pre> OsmoBSC - Bug #2823 (Resolved): Use bsc_subscr_conn_fsm in BSChttps://osmocom.org/issues/28232018-01-08T22:28:12Zdexter
<p>On laforge/fsm a draft FSM implementation can be found to make the handling of the subscriber connection safer and stateful.</p> OsmoMSC - Feature #2822 (Closed): work out MSC test scenarioshttps://osmocom.org/issues/28222018-01-08T20:43:22Zdexter
<p>We plan to test osmo-msc with TTCN3 as well. In Preparation of this we have to collect Ideas for test-cases.</p> OsmoMSC - Bug #2745 (Resolved): UMTS ciphering on GSM does not work when both 2G and 3G keys are ...https://osmocom.org/issues/27452017-12-13T16:20:57Zdexter
<p>When populating the hlr database with 3G keys (auc_3g), then 2G authentication stops working, while 3G authentication on nano3G still works fine. When the 3G keys are removed, then 2G authentication works again. At the moment we suspect that osmo-msc trys to perform 3G authentication on 2G (specified) and fails because it does not work.</p>
<p>In the attached archive one finds a trace from the connection between MSC and BSC and the complete network configuration, hlr database logs and start scripts.</p> libosmocore - Bug #2613 (Closed): vty crashes on tab-completionhttps://osmocom.org/issues/26132017-11-02T16:11:14Zdexter
<p>The problem is located in libosmocore, so it exists in all our products. It<br />looks like it is somehow liked to the tab-completion. The problem can be<br />triggered for example by logging into a vty and try to tab-complete some<br />items of the help menu, it seems to bail at the second level of tab completion.</p>
<pre>
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Welcome to the osmo-stp control interface
Copyright (C) 2015-2017 by Harald Welte <laforge@gnumonks.org>
Contributions by Holger Freyther, Neels Hofmeyr
License GPLv2+: GNU GPL Version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free ot change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Free Software lives by contribution. If you use this, please contribute!
osmo-stp>
show Show running system information
list Print command list
exit Exit current mode and down to previous mode
help Description of the interactive help system
enable Turn on privileged mode command
terminal Set terminal line parameters
who Display who is on vty
logging Configure log message to this terminal
osmo-stp> h
osmo-stp> help
</pre>
<p>Attached the logtext including backtrace.</p> OsmoMGW - Feature #2517 (Resolved): use libosmocore counters for packet/byte counting (statistics)https://osmocom.org/issues/25172017-09-22T07:37:31Zdexter
<p>use any of the libosmocore counters, rather than having hand-coded counters. A rate counter would have the benefit that it would come with free CTRL interface access to the counters.</p>
<p>(see also the SGSN/PDP-Context per direction packet and byte counting)</p> OpenBSC - Bug #2424 (Closed): use osmo_sccp_addr_set_ssn() in osmo-bschttps://osmocom.org/issues/24242017-08-07T15:14:20Zdexter
<p><a class="external" href="https://gerrit.osmocom.org/#/c/3359/">https://gerrit.osmocom.org/#/c/3359/</a> is still in review, use the provided function osmo_sccp_addr_set_ssn() as soon as it is merged.</p> libosmo-sccp + libosmo-sigtran - Bug #2351 (Closed): unify sccp instance configurationhttps://osmocom.org/issues/23512017-07-06T09:41:55Zdexter
<p>The configuration of the sccp instance can be unified. The parameters of osmo_sccp_simple_client() which is used to create the sccp instance could be configured using the built in VTY of libosmo-sccp. This would unify the configuration of SCCP and offload the application specific VTY. It also would help to simplify the configuration from the users perspective. The user will not have to learn a new way to configur SS7 applications all the time.</p>
<pre>
struct osmo_sccp_instance *
osmo_sccp_simple_client(void *ctx, const char *name, uint32_t pc,
enum osmo_ss7_asp_protocol prot, int local_port,
const char *local_ip, int remote_port, const char *remote_ip);
</pre> libosmo-sccp + libosmo-sigtran - Bug #2345 (Closed): VTY: Check returncode of osmo_ss7_pointcode_...https://osmocom.org/issues/23452017-06-30T13:50:30Zdexter
<p>The function osmo_ss7_pointcode_parse() may yield -EINVAL as result. Make sure that if this is the case, the result will not be used and a CMD_WARNING is returned.</p> OsmoPCU - Bug #1932 (Closed): vty command write corrupts config file for osmo-bts-octphyhttps://osmocom.org/issues/19322017-01-30T14:19:12Zdexter
<p>After issuing the write command from the VTY console, osmo-bts-octphy will refuse to start due to unparsable config file:</p>
<pre>
((*))
|
/ \ OsmoBTS
<0006> l1_if.c:765 model_init()
There is no such command.
Error occurred during reading below line:
netdev eth4
Failed to parse the config file: 'osmo-bts.cfg'
</pre> OsmoSGSN - Bug #1882 (Closed): xid is not re-transmitted on pdp-ctx-ack retransmissionhttps://osmocom.org/issues/18822016-12-19T12:20:18Zdexter
<p>When a pdp-context is established, usually a xid is sent. This works the first time, but when the pdp-ctx-ack is retransmitted from do_act_pdp_req() in gprs_gmm.c the xid negotiation should also be repeated.</p> OsmoSGSN - Bug #1768 (Stalled): VTY show llc displays State TLLI Unassigned permanentlyhttps://osmocom.org/issues/17682016-07-07T11:48:18Zdexter
<p>Expecting at least some assigned TLLI states in in SAPI list on globally Assigned TLLI state.</p>
<pre>
TLLI e625e4fb (Old TLLI ffffffff) BVCI=2 NSEI=101 Age=0: State TLLI Assigned
SAPI 1 State TLLI Unassigned (1) VUsend=4, VUrecv=5 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=400, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 2 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 3 State TLLI Unassigned (1) VUsend=91, VUrecv=64 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=500, N201-I=1503, mD=1520, mU=1520, kD=16, kU=16
SAPI 5 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=10, N200=3, N201-U=500, N201-I=1503, mD=760, mU=760, kD=8, kU=8
SAPI 7 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 8 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 9 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=500, N201-I=1503, mD=380, mU=380, kD=4, kU=4
SAPI 11 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=40, N200=3, N201-U=500, N201-I=1503, mD=190, mU=190, kD=2, kU=2
</pre>
<p>Already checked if the get_value_string(gprs_llc_state_strs, lle->state) returns the right string. Seems to work, numerical state is always 1 as well.</p>