Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-03-29T20:00:42ZOpen Source Mobile Communications
Redmine OsmoMGW - Bug #5984 (Closed): fix regression in TC_two_crcx_and_one_mdcx_rtp_hohttps://osmocom.org/issues/59842023-03-29T20:00:42Zdexter
<p>TC_two_crcx_and_one_mdcx_rtp_ho fails with reason: "RTP packets received while RX was disabled"</p> OsmoBTS - Bug #5645 (Resolved): osmo-bts-trx crashes when using gsmtap option -ihttps://osmocom.org/issues/56452022-08-15T12:48:31Zdexter
<p>When osmo-bts-trx is started with option -i (osmo-bts-trx -c ./osmo-bts.cfg -i 127.0.0.1), then it fails with SIGABRT (or Segmentation Fault without GDB). The problem is most likely related to an msgb that is too small.</p>
<pre>
Mon Aug 15 14:43:21 2022 <0001> nm_channel_fsm.c:152 NM_CHAN_OP(bts0-trx0-ts5)[0x55555576f660]{DISABLED_OFFLINE}: state_chg to ENABLED
Mon Aug 15 14:43:21 2022 <0001> oml.c:354 OC=CHANNEL INST=(00,00,05) AVAIL STATE Off line -> OK
Mon Aug 15 14:43:21 2022 <0001> oml.c:362 OC=CHANNEL INST=(00,00,05) OPER STATE Disabled -> Enabled
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:242 Sending info
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:257 BTS is up
Mon Aug 15 14:43:21 2022 <0001> oml.c:144 OC=CHANNEL(03) INST=(00,00,05): Tx State Changed Event Report
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:139 127.0.0.1:3002 connected write
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:139 127.0.0.1:3002 connected write
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:135 127.0.0.1:3002 connected read
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:56 127.0.0.1:3002 message received
Mon Aug 15 14:43:21 2022 <0001> oml.c:1017 OC=CHANNEL(03) INST=(00,00,06): Rx OPSTART
Mon Aug 15 14:43:21 2022 <0001> l1_if.c:588 NM_CHAN_OP(bts0-trx0-ts6)[0x55555576fcb0]{DISABLED_OFFLINE}: Received Event OPSTART_ACK
Mon Aug 15 14:43:21 2022 <0001> oml.c:144 OC=CHANNEL(03) INST=(00,00,06): Tx Opstart Ack
Mon Aug 15 14:43:21 2022 <0001> nm_channel_fsm.c:152 NM_CHAN_OP(bts0-trx0-ts6)[0x55555576fcb0]{DISABLED_OFFLINE}: state_chg to ENABLED
Mon Aug 15 14:43:21 2022 <0001> oml.c:354 OC=CHANNEL INST=(00,00,06) AVAIL STATE Off line -> OK
Mon Aug 15 14:43:21 2022 <0001> oml.c:362 OC=CHANNEL INST=(00,00,06) OPER STATE Disabled -> Enabled
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:242 Sending info
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:257 BTS is up
Mon Aug 15 14:43:21 2022 <0001> oml.c:144 OC=CHANNEL(03) INST=(00,00,06): Tx State Changed Event Report
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:139 127.0.0.1:3002 connected write
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:139 127.0.0.1:3002 connected write
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:139 127.0.0.1:3002 connected write
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:135 127.0.0.1:3002 connected read
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:56 127.0.0.1:3002 message received
Mon Aug 15 14:43:21 2022 <0001> oml.c:1017 OC=CHANNEL(03) INST=(00,00,07): Rx OPSTART
Mon Aug 15 14:43:21 2022 <0001> l1_if.c:588 NM_CHAN_OP(bts0-trx0-ts7)[0x555555770300]{DISABLED_OFFLINE}: Received Event OPSTART_ACK
Mon Aug 15 14:43:21 2022 <0001> oml.c:144 OC=CHANNEL(03) INST=(00,00,07): Tx Opstart Ack
Mon Aug 15 14:43:21 2022 <0001> nm_channel_fsm.c:152 NM_CHAN_OP(bts0-trx0-ts7)[0x555555770300]{DISABLED_OFFLINE}: state_chg to ENABLED
Mon Aug 15 14:43:21 2022 <0001> oml.c:354 OC=CHANNEL INST=(00,00,07) AVAIL STATE Off line -> OK
Mon Aug 15 14:43:21 2022 <0001> oml.c:362 OC=CHANNEL INST=(00,00,07) OPER STATE Disabled -> Enabled
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:242 Sending info
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:257 BTS is up
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:221 (bts=0,trx=0) PDCH on ts=7 is available (tsc=6 hopping=no arfcn=868)
Mon Aug 15 14:43:21 2022 <0001> oml.c:144 OC=CHANNEL(03) INST=(00,00,07): Tx State Changed Event Report
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:139 127.0.0.1:3002 connected write
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:863 Activate request received: TRX=0 TS=7
Mon Aug 15 14:43:21 2022 <0006> l1sap.c:1942 (bts=0,trx=0,ts=7,ss=0) Activating channel PDCH on TS7
Mon Aug 15 14:43:21 2022 <0006> scheduler.c:1099 (bts=0,trx=0,ts=7,ss=0) Activating PDTCH
Mon Aug 15 14:43:21 2022 <0006> scheduler.c:1099 (bts=0,trx=0,ts=7,ss=0) Activating PTCCH
Mon Aug 15 14:43:21 2022 <0006> lchan.c:271 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVE
Mon Aug 15 14:43:21 2022 <0006> l1sap.c:837 (bts=0,trx=0,ts=7,ss=0) activate confirm chan_nr=PDCH on TS7 trx=0
Mon Aug 15 14:43:21 2022 <0000> rsl.c:1389 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK
Mon Aug 15 14:43:21 2022 <0011> input/ipa.c:139 127.0.0.1:3002 connected write
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:448 Sending rts request: is_ptcch=0 arfcn=868 block=11
Mon Aug 15 14:43:21 2022 <0009> pcu_sock.c:680 Data request received: sapi=PDTCH arfcn=868 block=11 data=
msgb(0x5555558a3a30): Not enough tailroom msgb_put (allocated 52904, head at 0, len 16, tailroom 53024 < want tailroom 1432604448)
backtrace() returned 22 addresses
/usr/local/lib/libosmocore.so.19(osmo_generate_backtrace+0x18) [0x7ffff7e15e23]
/usr/local/lib/libosmocore.so.19(+0x29b01) [0x7ffff7e15b01]
/usr/local/lib/libosmocore.so.19(osmo_panic+0xca) [0x7ffff7e15bd0]
/usr/local/lib/libosmocore.so.19(+0x28fd0) [0x7ffff7e14fd0]
/usr/local/lib/libosmocore.so.19(gsmtap_makemsg_ex+0x110) [0x7ffff7e1533f]
/usr/local/lib/libosmocore.so.19(gsmtap_send_ex+0x88) [0x7ffff7e1563e]
/usr/local/lib/libosmocore.so.19(gsmtap_send+0x79) [0x7ffff7e156fa]
/usr/local/bin/osmo-bts-trx(+0x51806) [0x5555555a5806]
/usr/local/bin/osmo-bts-trx(+0x56493) [0x5555555aa493]
/usr/local/bin/osmo-bts-trx(+0x566c4) [0x5555555aa6c4]
/usr/local/bin/osmo-bts-trx(+0x4998e) [0x55555559d98e]
/usr/local/bin/osmo-bts-trx(+0x4a740) [0x55555559e740]
/usr/local/bin/osmo-bts-trx(+0x4b174) [0x55555559f174]
/usr/local/bin/osmo-bts-trx(+0x4b3b9) [0x55555559f3b9]
/usr/local/lib/libosmocore.so.19(+0x1082c) [0x7ffff7dfc82c]
/usr/local/lib/libosmocore.so.19(+0x10939) [0x7ffff7dfc939]
/usr/local/lib/libosmocore.so.19(osmo_select_main+0x15) [0x7ffff7dfc955]
/usr/local/bin/osmo-bts-trx(+0x5a5f1) [0x5555555ae5f1]
/usr/local/bin/osmo-bts-trx(+0xd5ed) [0x5555555615ed]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7ffff7c1309b]
/usr/local/bin/osmo-bts-trx(+0xd14a) [0x55555556114a]
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)
</pre> Cellular Network Infrastructure - Bug #5030 (Resolved): jenkins ttcn3-bsc-test and ttcn3-bts-test...https://osmocom.org/issues/50302021-02-17T13:31:41Zdexter
<p>The following two TTCN3 testsuites fail in jenkins.</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1285/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1285/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/1190/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/1190/</a></p>
<p>building osmo-bts fails with the following errror message:<br />../../include/osmo-bts/gsm_data.h:326:29: error: field 'l1_info' has incomplete type</p>
<p>This is due to the following patch:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/22938">https://gerrit.osmocom.org/c/osmo-bts/+/22938</a></p>
<p>which depends on</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/22932">https://gerrit.osmocom.org/c/libosmocore/+/22932</a></p>
<p>both are merged and were built without problems in gerrit. It might be that the libosmocore change is not propagated into the libosmocore package yet.</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> OsmoBSC - Bug #3833 (Resolved): Fix storage location of AMR S15-S0 bitshttps://osmocom.org/issues/38332019-03-11T17:44:34Zdexter
<p>The current storage location of s15_s0 (lchan->activate.info.s15_s0) is incorrect by the current memory model. This should be fixed by finding a proper storage location that fits into the current memory model.</p>
<p>See also:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/13200/">https://gerrit.osmocom.org/#/c/osmo-bsc/+/13200/</a><br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039/">https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039/</a></p> OpenBSC - Bug #3657 (Resolved): fix support for non voice configurationhttps://osmocom.org/issues/36572018-10-16T13:32:46Zdexter
<p>At the moment osmo-bsc does not permit non voice configurations. A valid voice codec configuration must be in place, otherwise the COMPLETE LAYER 3 INFORMATION message generation will fail because the SPEECH CODEC LIST (BSS supported) IE can not be generated. The speech codec list is a mandatory IE, but only if the network supports an IP based user plane interface. In networks that intentionally do not support voice, it could be garmented that those networks do not have such an interface and therefore the inclusion of the speech codec list is not needed. Also a speech codec list with 0 elements is indeed permitted by the spec. We could also include a speech codec list with 0 elements for the non-voice configurations.</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> 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> OsmoBSC - Bug #2936 (Resolved): Fix TTCN3 Test BSC_Tests.TC_assignment_signhttps://osmocom.org/issues/29362018-02-12T20:23:55Zdexter
<p>The Testcase BSC_Tests.TC_assignment_sign seems to behave incorrectly. It sends an Assignment Request where it requests a signaling only channel SDCCH. Osmo-bsc then decides that is already active is compatible and sends a Channel Mode Modify via RSL, which is never answered. The T10 timeout expires and the assignment fails.</p>
<p>From what I can see, the decision osmo-bsc makes is correct. Also the TTCN3 function f_channel_compatible(ass_cmd.pdu.bssmap.assignmentRequest.channelType, g_chan_nr) that is called from f_establish_fully() comes to the conclusion that the channel is compatible. I am currently lost in the altstep in at the end. I would expect it to continue with as_modify(st) but there I can see none of the steps processed.</p>
<p>From my understanding the behavior of osmo-bsc is correct and the TTCN3 testcase has some malfunction. Attached one finds a trace of the current behavior. See also branch: pmaier/fsm</p> OsmoMGW - Bug #2863 (Resolved): osmo-mgw segfaults on DLCX (use-after-free in mgcp_network.c)https://osmocom.org/issues/28632018-01-23T19:23:47Zdexter
<p>In mgcp_network.c in mgcp_dispatch_rtp_bridge_cb() we use conn->priv to store the pointer to the opposite connection so we do not need to iterate through the connection list once more. When someone frees the opposite connection using a DLCX, then the pointer points to already freed memory. We need some mechanism to invalidate that information on DLCX, so that the callback function can know and prevent the use-after-free.</p> 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> 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 #2516 (Resolved): automatic testing of osmo-mgw / jenkins integrationhttps://osmocom.org/issues/25162017-09-18T21:45:01Zdexter
<p>Currently we test osmo-mgw with unit tests. It might make sense to run some more realistic tests. The idea is to start osmo-mgw in a testrig that then makes test connections and sends test data. The testrig could be a python program or even a TTCN3 test.</p>
Some ideas:
<ul>
<li>Send command (e.g. CRCX) and inspect resulting internal states via VTY also check response for plausibility</li>
<li>Send odd command sequences, check if the expected error codes are generated.</li>
<li>Send malformed messages or incomplete messages, check if the expected error codes are generated</li>
<li>Create a full connection, send RTP packets through, check if the RTP packets take the right path</li>
<li>Create a loopback connection, send RTP packets, check if the packets are reflected correctly</li>
</ul> OpenBSC - Feature #2515 (Closed): integrate osmo-mgw in osmo-bschttps://osmocom.org/issues/25152017-09-18T15:48:17Zdexter
<p>osmo-mgw has reached a development state, where it makes sens to try out how it performs in a real life situation. Osmo-bsc seems like a good test target for that and requires mgcp features anyway to support handover. The complexity can be limited by leaving osmo-msc on the legacy mgcp, while performing changes only to osmo-bsc. When done, osmo-bsc should not behave any different on the A-Interface.</p> libosmo-sccp + libosmo-sigtran - Bug #2441 (Closed): chopped-off pointcodeshttps://osmocom.org/issues/24412017-08-15T11:16:54Zdexter
<p>It seems that that the pointcode data is chopped off when receiving unittdata.</p>
<p>When looking at the attached trace.pcapng file, one can see that the RESET<br />command is correctly transmitted, but the response, the RESET ACK is always<br />sent to the wrong destination address. (187 instead of 2235). When converting<br />those to numbers one can see that the addresses seem to be chopped off,<br />presumably at the 8th bit:</p>
<pre>
2235 = 100010111011
187 = 10111011
</pre>
<p>When investigating further it turns out that the pointcode is already chopped<br />off when the RESET is received:</p>
<pre>
Tue Aug 15 11:35:20 2017 <000a> a_iface.c:531 N-UNITDATA.ind(00 04 30 04 01 20 )
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:184 Rx BSC UDT: 00 04 30 04 01 20
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:157 Rx BSC UDT BSSMAP RESET
Tue Aug 15 11:35:20 2017 <000a> a_iface_bssap.c:110 Rx RESET from BSC RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT, sending RESET ACK
Tue Aug 15 11:35:20 2017 <000a> fsm.c:176 FSM RESET(FSM RESET INST)[0x55555589b7a0]{DISC}: Timeout of T0
Tue Aug 15 11:35:20 2017 <000a> a_reset.c:102 (RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT) reset-ack timeout (T0) in state ST_DISC (disconnected), resending...
Tue Aug 15 11:35:20 2017 <000a> a_iface.c:443 Sending RESET to BSC RI=SSN_PC,PC=0.23.3,SSN=unknown 0xfe,GTI=NO_GT
</pre>
<p>Presumably the upcoming primitive already contains the chopped pointcode.</p> 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> OpenBSC - Bug #2342 (Closed): fix MSC co located MGCPhttps://osmocom.org/issues/23422017-06-28T12:47:28Zdexter
<p>There is a problem with the handling of the MGCP on the MSC side. A crash/restart of the MSC might leave open MGCP endpoints. The endpoints will stay open and will be not available for new connections.</p>
<p>To get around problems after restarting the MSC we currently send a DLCX before we seize a new enpoint. This ensures that the endpoint is closed before we try to seize it. This works fine but is a spec violation. Normally a DLCX requires a connection identifier ("C"). Since our MGCP gateway ignores the connection identifier in a DLCX the current method work. However, it might fail when using an MGCP gateway from another vendor.</p>
<p>So sending a DLCX is not a good option becaus on restart we lost all information about the connection identifiers. Holger suggested to use an already existing "reset all endpoints" vendor extension in our MGCP. This would be a possible solution. However, it would reset everything at once. It would work, but this would certainly disturb possible other users of the MGCPGW. I do not know if this is even planned or required.</p> libosmo-sccp + libosmo-sigtran - Bug #2328 (Closed): sccp-address nodeshttps://osmocom.org/issues/23282017-06-15T10:04:54Zdexter
<p>the SCCP level addresses. Unfortunately a SCC (called|calling) party<br />address is rather complex and hence it cannot easily be supplied by a<br />single VTY command. My idea is thus to add 'sccp-address' nodes,<br />where one can specify a SCCP address like this:</p>
<pre><code>sccp-address my-bsc-addr<br /> routing-indicator 1<br /> point-code 2.3.1<br /> subsystem-number 253<br /> global-title<br /> gti 4<br /> digits 2342<br /> ...</code></pre>
<p>The above vty code would become part of libosmo-sigtran, and the<br />BSC/MSC then can simply have a single vty line like<br />"bsc sccp-address my-bsc-addr" <br />and then call a function that resolves this address by it's<br />string-name "my-bsc-addr"</p> OsmoMSC - Bug #2322 (Resolved): Make osmo-msc work with external mncchttps://osmocom.org/issues/23222017-06-12T17:06:27Zdexter
<p>In its current state, osmo-msc does not work with the external mncc. This needs to be fixed.</p> libosmo-sccp + libosmo-sigtran - Bug #2259 (New): problem with local referencehttps://osmocom.org/issues/22592017-05-16T13:05:55Zdexter
<p>When a connection attemt (local reference = 2) is made, libosmo-sccp complains with "<000d> sccp_scoc.c:1528 Cannot find connection for local reference 2". Current master is at 872c6b2a8e309ca6739ef295f1fc468c189e4ec9. The problem seems to be introduced with commit 5527df78adc08b76df07c4b682263b5bdd6181d4 (libosmo-sccp.git). When the commit is reverted, the correct functionality of libosmo-sccp seems to be restored.</p>
<p>The problem can be demonstrated by using the client/server example that is shipped with libosmo-sccp. The following VTY-Commands were used to trigger the problem:</p>
<pre>
enable
sccp-user
called-addr-ssn 202
connect-req 2 hello
</pre>
<p>Note: In the good case I can see the normal CR with payload attached and the CC that with the payload that is echoed by the the echo subsystem. The bad case results in an CREF message, which contains an refusal cause code 0x0F (unqalified)</p> libosmo-sccp + libosmo-sigtran - Bug #2004 (Closed): Problem sending CR without datahttps://osmocom.org/issues/20042017-04-10T12:03:00Zdexter
<p>When attempting to send a connection response (CR) without any data using:</p>
<pre>
osmo_sccp_tx_conn_resp(scu, scu_prim->u.connect.conn_id,
&scu_prim->u.connect.called_addr,
NULL, 0);
</pre>
<p>Wireshark displays a malformed packet. To me it looks like if there is an optional parameter (the data part) announced, but the data is (of course) not there. However. CR seems to work fine when no data is attached.</p> libosmo-sccp + libosmo-sigtran - Bug #1995 (Closed): Segfault when callin osmo_sccp_tx_unitdata()...https://osmocom.org/issues/19952017-04-07T08:44:51Zdexter
<p>The problem occurs when a peer (server role) tries to send unitdata to a remote peer (client) that is not connected.</p>
<p>The attached code contains the source code snippets I used for experimentation.</p>
<p>Good case:<br />fist start dummy_msc (client), then dummy_bsc (server). The client will connect and when the timer at the server expires unitdata is sent from the server to the client.</p>
<p>Bad case:<br />start dummy_bsc, when the timer expires, the segfault occurs.</p>
<p>Note: The scheme is a bit odd and not covered by the examples, since there, the server never actively sends data without being stimulated through an existing connection. It is questionable if a server should send unsolicited data at all. In this test, the server role has been chosen for one side because of the lack of an STP.</p> pySim - Bug #1989 (Closed): SMSC not set for sysmo-usim-sjs1https://osmocom.org/issues/19892017-03-27T07:55:36Zdexter
<p>When setting the SMSC using pysim, it stays at its original value. Possibly setting of the SMSC value is not implemented for sysmo-usim-sjs1.</p> pySim - Bug #1988 (Closed): problem changing the ICCID on sysmo-usim-sjs1https://osmocom.org/issues/19882017-03-20T17:10:57Zdexter
<p>When programming an sysmo-usim-sjs1, all parameters are written fine, except for the ICCID. There are no error messages printend. When checking the ICCID with the phone, the original ICCID is shown, regardless what is previously programmed.</p>
<pre>
$ ./mksim.sh
Insert card now (or CTRL-C to cancel)
Generated card parameters :
> Name : Magic
> SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
> ICCID : 1234567890123456789
> MCC/MNC : 1/1
> IMSI : 001010000000006
> Ki : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
> OPC : 79316551103BD050B7C8CDB0030C49F0
> ACC : None
Programming ...
Done !
</pre>
<p>Script used for programming:</p>
<pre>
#!/bin/bash
PYSIM=~/bin/pysim/pySim-prog.py
ADM1=14546485
OPC=79316551103BD050B7C8CDB0030C49F0
MCC=001
MNC=01
IMSI=001010000000006
KI=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ICCID=1234567890123456789
python $PYSIM -p 0 -t sysmoUSIM-SJS1 -o $OPC -k $KI -x $MCC -y $MNC -i $IMSI -s $ICCID -a $ADM1</pre> OsmoSGSN - Bug #1972 (Closed): show online-help outputs generates multiple commandshttps://osmocom.org/issues/19722017-03-08T12:43:20Zdexter
<p>The attached file was generated using the "show online-help" vty command in osmo-sgsn. Some of the commands show up 3 times on different nodes.</p>
For example:
<ul>
<li>"<command id='logging level (all| ..." shows up in node 1, 3 and 7</li>
<li>"<command id='show mm-context all [pdp]'>" shows up in node 1 and 3</li>
<li>"<command id='write file'>" shows up in node 3, 4, 7, 8, 9, 12, 13, 26</li>
<li>"<command id='no compression v42bis'> shows up once at node 26 (as expected)</li>
</ul> OsmoPCU - Bug #1957 (Closed): Fix calculation of absolute frame number from relative frame number...https://osmocom.org/issues/19572017-02-22T12:42:21Zdexter
<p>A RACH request that is forwarded to the PCU (usually) contains only a relative frame number. When a RACH request is processed by the BTS class, the absolute frame number is calculated from the relative framenumber. The current implementation lacks the handling of cornercases and race conditions.</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> OsmoPCU - Bug #1931 (Rejected): Downlink TBF allocation problem during PDP-Context Deact REQ on O...https://osmocom.org/issues/19312017-01-30T12:04:26Zdexter
<p>In some cases, primarily when a the MS requests to deactivate the PDP context a problem allocating a downlink TBF occurs:</p>
<p>The observation of the diag interface of the MS shows that that the MS is sending a PDP context deactivation request. The request reaches SGSN and the SGSN responds correctly with a PDP context deactivation ACK. The diag interface on the modem shows that the PDP context deactivation ACK is never received. The MS repeats the request 4 times until it finally gives up.</p>
<pre>
Thu Jan 19 11:27:19 2017 <0011> gprs_bssgp.c:379 BSSGP TLLI=0xd4d4ca34 Rx UPLINK-UNITDATA
Thu Jan 19 11:27:19 2017 <0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x20b16a CMD=UI DATA
Thu Jan 19 11:27:19 2017 <0002> gprs_gmm.c:2444 MM(001010000000001/d4d4ca34) -> DEACTIVATE PDP CONTEXT REQ (cause: Regular deactivation)
Thu Jan 19 11:27:19 2017 <000f> sgsn_libgtp.c:286 PDP(001010000000001/0) Delete PDP Context
Thu Jan 19 11:27:19 2017 <000f> sgsn_libgtp.c:613 PDP Context was deleted
Thu Jan 19 11:27:19 2017 <000f> sgsn_libgtp.c:590 libgtp cb_conf(type=20, cause=128, pdp=(nil), cbp=0x1a2e010)
Thu Jan 19 11:27:19 2017 <000f> sgsn_libgtp.c:513 PDP(001010000000001/0) Received DELETE PDP CTX CONF, cause=128(Request accepted)
Thu Jan 19 11:27:19 2017 <0013> gprs_sndcp.c:509 SNSM-DEACTIVATE.ind (lle=0x1a2be20, TLLI=d4d4ca34, SAPI=3, NSAPI=5)
Thu Jan 19 11:27:19 2017 <0002> gprs_gmm.c:2127 MM(001010000000001/d4d4ca34) <- DEACTIVATE PDP CONTEXT ACK
Thu Jan 19 11:27:24 2017 <0011> gprs_bssgp.c:797 BSSGP BVCI=23 Rx Flow Control BVC
Thu Jan 19 11:27:27 2017 <0011> gprs_bssgp.c:379 BSSGP TLLI=0xd4d4ca34 Rx UPLINK-UNITDATA
Thu Jan 19 11:27:27 2017 <0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xac2522 CMD=UI DATA
Thu Jan 19 11:27:27 2017 <0002> gprs_gmm.c:2444 MM(001010000000001/d4d4ca34) -> DEACTIVATE PDP CONTEXT REQ (cause: Regular deactivation)
Thu Jan 19 11:27:27 2017 <0002> gprs_gmm.c:2451 MM(001010000000001/d4d4ca34) Deactivate PDP Context Request for non-existing PDP Context (IMSI=001010000000001, TI=0)
Thu Jan 19 11:27:27 2017 <0002> gprs_gmm.c:2127 MM(001010000000001/d4d4ca34) <- DEACTIVATE PDP CONTEXT ACK
Thu Jan 19 11:27:30 2017 <000f> gprs_sgsn.c:870 Checking for inactive LLMEs, time = 126147
Thu Jan 19 11:27:34 2017 <0010> gprs_ns.c:528 NSEI=23 Tx NS ALIVE_ACK (NSVCI=23)
Thu Jan 19 11:27:34 2017 <0011> gprs_bssgp.c:797 BSSGP BVCI=23 Rx Flow Control BVC
Thu Jan 19 11:27:34 2017 <0010> gprs_ns.c:582 NSEI=23 Timer expired in mode tns-test (30 seconds)
Thu Jan 19 11:27:34 2017 <0010> gprs_ns.c:515 NSEI=23 Tx NS ALIVE (NSVCI=23)
Thu Jan 19 11:27:34 2017 <0010> gprs_ns.c:554 NSEI=23 Starting timer in mode tns-alive (3 seconds)
Thu Jan 19 11:27:34 2017 <0010> gprs_ns.c:554 NSEI=23 Starting timer in mode tns-test (30 seconds)
Thu Jan 19 11:27:35 2017 <0011> gprs_bssgp.c:379 BSSGP TLLI=0xd4d4ca34 Rx UPLINK-UNITDATA
Thu Jan 19 11:27:35 2017 <0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xb55300 CMD=UI DATA
Thu Jan 19 11:27:35 2017 <0002> gprs_gmm.c:2444 MM(001010000000001/d4d4ca34) -> DEACTIVATE PDP CONTEXT REQ (cause: Regular deactivation)
Thu Jan 19 11:27:35 2017 <0002> gprs_gmm.c:2451 MM(001010000000001/d4d4ca34) Deactivate PDP Context Request for non-existing PDP Context (IMSI=001010000000001, TI=0)
Thu Jan 19 11:27:35 2017 <0002> gprs_gmm.c:2127 MM(001010000000001/d4d4ca34) <- DEACTIVATE PDP CONTEXT ACK
Thu Jan 19 11:27:43 2017 <0011> gprs_bssgp.c:379 BSSGP TLLI=0xd4d4ca34 Rx UPLINK-UNITDATA
Thu Jan 19 11:27:43 2017 <0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x39c748 CMD=UI DATA
Thu Jan 19 11:27:43 2017 <0002> gprs_gmm.c:2444 MM(001010000000001/d4d4ca34) -> DEACTIVATE PDP CONTEXT REQ (cause: Regular deactivation)
Thu Jan 19 11:27:43 2017 <0002> gprs_gmm.c:2451 MM(001010000000001/d4d4ca34) Deactivate PDP Context Request for non-existing PDP Context (IMSI=001010000000001, TI=0)
Thu Jan 19 11:27:43 2017 <0002> gprs_gmm.c:2127 MM(001010000000001/d4d4ca34) <- DEACTIVATE PDP CONTEXT ACK
Thu Jan 19 11:27:44 2017 <0011> gprs_bssgp.c:797 BSSGP BVCI=23 Rx Flow Control BVC
Thu Jan 19 11:27:51 2017 <0011> gprs_bssgp.c:379 BSSGP TLLI=0xd4d4ca34 Rx UPLINK-UNITDATA
Thu Jan 19 11:27:51 2017 <0012> gprs_llc_parse.c:82 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xf7702b CMD=UI DATA
Thu Jan 19 11:27:51 2017 <0002> gprs_gmm.c:2444 MM(001010000000001/d4d4ca34) -> DEACTIVATE PDP CONTEXT REQ (cause: Regular deactivation)
Thu Jan 19 11:27:51 2017 <0002> gprs_gmm.c:2451 MM(001010000000001/d4d4ca34) Deactivate PDP Context Request for non-existing PDP Context (IMSI=001010000000001, TI=0)
Thu Jan 19 11:27:51 2017 <0002> gprs_gmm.c:2127 MM(001010000000001/d4d4ca34) <- DEACTIVATE PDP CONTEXT ACK
Thu Jan 19 11:27:54 2017 <0011> gprs_bssgp.c:797 BSSGP BVCI=23 Rx Flow Control BVC
Thu Jan 19 11:28:00 2017 <000f> gprs_sgsn.c:870 Checking for inactive LLMEs, time = 126177
Thu Jan 19 11:28:04 2017 <0010> gprs_ns.c:528 NSEI=23 Tx NS ALIVE_ACK (NSVCI=23)
Thu Jan 19 11:28:04 2017 <0011> gprs_bssgp.c:797 BSSGP BVCI=23 Rx Flow Control BVC
Thu Jan 19 11:28:04 2017 <0010> gprs_ns.c:582 NSEI=23 Timer expired in mode tns-test (30 seconds)
</pre>
<p>By the diag log we see that the downlink assignment message, the PCU is sending is missing, while the log of the PCU confirms that the downlink assignment message is sent:</p>
<pre>
Thu Jan 19 11:27:51 2017 <0001> pcu_l1_if.cpp:350 RACH request received: sapi=1 qta=0, ra=123, fn=82125
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:562 MS requests UL TBF on RACH, so we provide one
ra=0x7b Fn=82125 qta=0 is_11bit=0:
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:708 pcu has not received burst type from bts
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:694 ********** TBF starts here **********
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:696 Allocating UL TBF: MS_CLASS=0/0
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:115 Creating MS object, TLLI = 0x00000000
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:454 Searching for first unallocated TFI: TRX=0
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:464 Found TFI=0.
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:525 Slot Allocation (Algorithm B) for unknown class (assuming 12)
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:560 - Rx=4 Tx=4 Sum Rx+Tx=5 Tta=2 Ttb=1 Tra=2 Trb=1 Type=1
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 0, because not enabled
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 1, because not enabled
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 2, because not enabled
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 3, because not enabled
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 4, because not enabled
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 5, because not enabled
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 6, because not enabled
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:579 - Possible DL/UL slots: (TS=0)".......C"(TS=7)
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:940 - Selected UL slots: (TS=0)".......U"(TS=7), single
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single slot at TS 7 for UL
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:990 - Reserved DL/UL slots: (TS=0)".......C"(TS=7)
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:1017 - Assigning UL TS 7
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:1681 PDCH(TS 7, TRX 0): Attaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001.
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:399 - Setting Control TS 7
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:268 Attaching TBF to MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL)
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:647 Allocated TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL): trx = 0, ul_slots = 80, dl_slots = 00
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:471 Modifying MS object, TLLI = 0x00000000, TA 220 -> 0
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:294 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) changes state from NULL to FLOW
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:422 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) starting timer 3169.
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:611 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) [UPLINK] START
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:617 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) RX: [PCU <- BTS] RACH qbit-ta=0 ra=0x7b, Fn=82125 (29,15,17)
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:620 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) TX: START Immediate Assignment Uplink (AGCH)
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:640 - TRX=0 (866) TS=7 TA=0 TSC=7 TFI=0 USF=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82134 block_nr=6 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82138 block_nr=7 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82142 block_nr=8 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82147 block_nr=9 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82151 block_nr=10 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82155 block_nr=11 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82160 block_nr=0 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82164 block_nr=1 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82168 block_nr=2 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82173 block_nr=3 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82177 block_nr=4 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82181 block_nr=5 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:109 Received RTS for PDCH: TRX=0 TS=7 FN=82186 block_nr=6 scheduling USF=0 for required uplink resource of UL TFI=0
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:426 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) restarting timer 3169 while old timer 3169 pending
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:457 Modifying MS object, TLLI = 0x00000000, IMSI '' -> '001010000000001'
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:361 Clearing MS object, TLLI: 0xd4d4ca34, IMSI: '001010000000001'
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:396 Modifying MS object, UL TLLI: 0x00000000 -> 0xd4d4ca34, not yet confirmed
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:141 Destroying MS object, TLLI = 0x00000000
Thu Jan 19 11:27:51 2017 <0009> tbf_ul.cpp:373 LLC [PCU -> SGSN] TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FLOW) len=10
Thu Jan 19 11:27:51 2017 <0002> tbf_ul.cpp:294 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FLOW) changes state from FLOW to FINISHED
Thu Jan 19 11:27:51 2017 <0009> gprs_bssgp_pcu.cpp:180 LLC [SGSN -> PCU] = TLLI: 0xd4d4ca34 IMSI: 001010000000001 len: 8
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:775 ********** TBF starts here **********
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:777 Allocating DL TBF: MS_CLASS=0/0
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:454 Searching for first unallocated TFI: TRX=0
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:464 Found TFI=0.
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:902 - Selected DL slots: (TS=0)".......D"(TS=7), single
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single slot at TS 7 for DL
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac_ts_alloc.cpp:1004 - Assigning DL TS 7
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:1681 PDCH(TS 7, TRX 0): Attaching TBF(TFI=0 TLLI=0x00000000 DIR=DL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001.
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:399 - Setting Control TS 7
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:287 Attaching TBF to MS object, TLLI = 0xd4d4ca34, TBF = TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=NULL)
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:647 Allocated TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=NULL): trx = 0, ul_slots = 80, dl_slots = 80
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:430 Modifying MS object, TLLI: 0xd4d4ca34 confirmed
Thu Jan 19 11:27:51 2017 <0002> tbf_dl.cpp:161 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=NULL) [DOWNLINK] START
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:749 Send dowlink assignment for TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=NULL) on PCH, no TBF exist (IMSI=001010000000001)
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:294 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=NULL) changes state from NULL to ASSIGN
Thu Jan 19 11:27:51 2017 <0002> gprs_rlcmac.cpp:35 TX: [PCU -> BTS] Paging Request (CCCH)
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:770 TX: START TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) Immediate Assignment Downlink (PCH)
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:777 - TRX=0 (866) TS=7 TA=0 pollFN=-1
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:422 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) starting timer 0.
Thu Jan 19 11:27:51 2017 <0002> tbf_dl.cpp:90 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) append
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:487 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED): Scheduling polling at FN 82203 TS 7
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:181 Scheduling control message at RTS for TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED) (TRX=0, TS=7)
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:426 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED) restarting timer 3169 while old timer 3169 pending
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:426 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED) restarting timer 3169 while old timer 3169 pending
Thu Jan 19 11:27:51 2017 <0006> gprs_rlcmac_sched.cpp:329 Received RTS for PDCH: TRX=0 TS=7 FN=82199 block_nr=9 scheduling free USF for polling at FN=82203 of TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED)
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:1448 +++++++++++++++++++++++++ RX : Uplink Control Block +++++++++++++++++++++++++
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:1451 ------------------------- RX : Uplink Control Block -------------------------
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:955 RX: [PCU <- BTS] TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED) Packet Control Ack
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:960 TBF: [UPLINK] END TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED)
Thu Jan 19 11:27:51 2017 <0007> gprs_rlcmac_meas.cpp:104 UL RSSI of TLLI=0xd4d4ca34: -103 dBm
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:342 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED) free
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:447 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED) stopping timer 3169.
Thu Jan 19 11:27:51 2017 <0002> bts.cpp:1701 PDCH(TS 7, TRX 0): Detaching TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED), 0 TBFs, USFs = 00, TFIs = 00000000.
Thu Jan 19 11:27:51 2017 <0002> gprs_ms.cpp:324 Detaching TBF from MS object, TLLI = 0xd4d4ca34, TBF = TBF(TFI=0 TLLI=0xd4d4ca34 DIR=UL STATE=FINISHED)
Thu Jan 19 11:27:51 2017 <0002> tbf.cpp:363 ********** TBF ends here **********
Thu Jan 19 11:27:53 2017 <0002> tbf.cpp:829 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) timer 0 expired.
Thu Jan 19 11:27:53 2017 <0002> tbf.cpp:372 ********** TBF update **********
Thu Jan 19 11:27:53 2017 <0002> bts.cpp:1701 PDCH(TS 7, TRX 0): Detaching TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN), 0 TBFs, USFs = 00, TFIs = 00000000.
Thu Jan 19 11:27:53 2017 <0002> bts.cpp:454 Searching for first unallocated TFI: TRX=0
Thu Jan 19 11:27:53 2017 <0002> bts.cpp:464 Found TFI=0.
Thu Jan 19 11:27:53 2017 <0002> gprs_rlcmac_ts_alloc.cpp:902 - Selected DL slots: (TS=0)".......D"(TS=7)
Thu Jan 19 11:27:53 2017 <0002> gprs_rlcmac_ts_alloc.cpp:970 Using 1 slots for DL
Thu Jan 19 11:27:53 2017 <0002> gprs_rlcmac_ts_alloc.cpp:1004 - Assigning DL TS 7
Thu Jan 19 11:27:53 2017 <0002> bts.cpp:1681 PDCH(TS 7, TRX 0): Attaching TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN), 1 TBFs, USFs = 00, TFIs = 00000001.
Thu Jan 19 11:27:53 2017 <0002> bts.cpp:736 Send dowlink assignment on PACCH, because TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) exists
Thu Jan 19 11:27:53 2017 <0002> bts.cpp:294 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) changes state from ASSIGN to ASSIGN
Thu Jan 19 11:27:53 2017 <0002> tbf.cpp:422 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) starting timer 0.
Thu Jan 19 11:27:53 2017 <0002> tbf.cpp:985 New and old TBF are the same TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:53 2017 <0002> tbf.cpp:1007 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) start Packet Downlink Assignment (PACCH)
Thu Jan 19 11:27:53 2017 <0002> tbf.cpp:1014 +++++++++++++++++++++++++ TX : Packet Downlink Assignment +++++++++++++++++++++++++
Thu Jan 19 11:27:53 2017 <0002> tbf.cpp:1017 ------------------------- TX : Packet Downlink Assignment -------------------------
Thu Jan 19 11:27:53 2017 <0002> tbf.cpp:487 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN): Scheduling polling at FN 82636 TS 7
Thu Jan 19 11:27:53 2017 <0006> gprs_rlcmac_sched.cpp:181 Scheduling control message at RTS for TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) (TRX=0, TS=7)
Thu Jan 19 11:27:53 2017 <0006> gprs_rlcmac_sched.cpp:329 Received RTS for PDCH: TRX=0 TS=7 FN=82632 block_nr=1 scheduling free USF for polling at FN=82636 of TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:498 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) poll timeout for FN=82636, TS=7 (curr FN 82697)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:553 - Timeout for polling PACKET CONTROL ACK for PACKET DOWNLINK ASSIGNMENT.
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:914 - Assignment was on PACCH
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:922 - No downlink ACK received yet
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:985 New and old TBF are the same TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1007 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) start Packet Downlink Assignment (PACCH)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1014 +++++++++++++++++++++++++ TX : Packet Downlink Assignment +++++++++++++++++++++++++
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1017 ------------------------- TX : Packet Downlink Assignment -------------------------
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:487 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN): Scheduling polling at FN 82710 TS 7
Thu Jan 19 11:27:54 2017 <0006> gprs_rlcmac_sched.cpp:181 Scheduling control message at RTS for TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) (TRX=0, TS=7)
Thu Jan 19 11:27:54 2017 <0006> gprs_rlcmac_sched.cpp:329 Received RTS for PDCH: TRX=0 TS=7 FN=82706 block_nr=6 scheduling free USF for polling at FN=82710 of TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:498 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) poll timeout for FN=82710, TS=7 (curr FN 82771)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:985 New and old TBF are the same TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1007 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) start Packet Downlink Assignment (PACCH)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1014 +++++++++++++++++++++++++ TX : Packet Downlink Assignment +++++++++++++++++++++++++
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1017 ------------------------- TX : Packet Downlink Assignment -------------------------
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:487 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN): Scheduling polling at FN 82784 TS 7
Thu Jan 19 11:27:54 2017 <0006> gprs_rlcmac_sched.cpp:181 Scheduling control message at RTS for TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) (TRX=0, TS=7)
Thu Jan 19 11:27:54 2017 <0006> gprs_rlcmac_sched.cpp:329 Received RTS for PDCH: TRX=0 TS=7 FN=82779 block_nr=11 scheduling free USF for polling at FN=82784 of TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:498 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) poll timeout for FN=82784, TS=7 (curr FN 82849)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:985 New and old TBF are the same TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1007 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) start Packet Downlink Assignment (PACCH)
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1014 +++++++++++++++++++++++++ TX : Packet Downlink Assignment +++++++++++++++++++++++++
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:1017 ------------------------- TX : Packet Downlink Assignment -------------------------
Thu Jan 19 11:27:54 2017 <0002> tbf.cpp:487 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN): Scheduling polling at FN 82862 TS 7
Thu Jan 19 11:27:54 2017 <0006> gprs_rlcmac_sched.cpp:181 Scheduling control message at RTS for TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) (TRX=0, TS=7)
Thu Jan 19 11:27:54 2017 <0006> gprs_rlcmac_sched.cpp:329 Received RTS for PDCH: TRX=0 TS=7 FN=82857 block_nr=5 scheduling free USF for polling at FN=82862 of TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:498 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) poll timeout for FN=82862, TS=7 (curr FN 82927)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:985 New and old TBF are the same TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:1007 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) start Packet Downlink Assignment (PACCH)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:1014 +++++++++++++++++++++++++ TX : Packet Downlink Assignment +++++++++++++++++++++++++
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:1017 ------------------------- TX : Packet Downlink Assignment -------------------------
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:487 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN): Scheduling polling at FN 82940 TS 7
Thu Jan 19 11:27:55 2017 <0006> gprs_rlcmac_sched.cpp:181 Scheduling control message at RTS for TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) (TRX=0, TS=7)
Thu Jan 19 11:27:55 2017 <0006> gprs_rlcmac_sched.cpp:329 Received RTS for PDCH: TRX=0 TS=7 FN=82935 block_nr=11 scheduling free USF for polling at FN=82940 of TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:498 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) poll timeout for FN=82940, TS=7 (curr FN 83005)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:985 New and old TBF are the same TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:1007 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) start Packet Downlink Assignment (PACCH)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:1014 +++++++++++++++++++++++++ TX : Packet Downlink Assignment +++++++++++++++++++++++++
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:1017 ------------------------- TX : Packet Downlink Assignment -------------------------
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:487 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN): Scheduling polling at FN 83018 TS 7
Thu Jan 19 11:27:55 2017 <0006> gprs_rlcmac_sched.cpp:181 Scheduling control message at RTS for TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) (TRX=0, TS=7)
Thu Jan 19 11:27:55 2017 <0006> gprs_rlcmac_sched.cpp:329 Received RTS for PDCH: TRX=0 TS=7 FN=83013 block_nr=5 scheduling free USF for polling at FN=83018 of TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:829 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) timer 0 expired.
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:838 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) releasing due to PACCH assignment timeout.
Thu Jan 19 11:27:55 2017 <0002> tbf_dl.cpp:294 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=ASSIGN) changes state from ASSIGN to RELEASING
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:342 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=RELEASING) free
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:354 TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=RELEASING) Software error: Pending downlink assignment. This may not happen, because the assignment message never gets transmitted. Please be sure not to free in this state. PLEASE FIX!
Thu Jan 19 11:27:55 2017 <0002> bts.cpp:1701 PDCH(TS 7, TRX 0): Detaching TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=RELEASING), 0 TBFs, USFs = 00, TFIs = 00000000.
Thu Jan 19 11:27:55 2017 <0002> gprs_ms.cpp:324 Detaching TBF from MS object, TLLI = 0xd4d4ca34, TBF = TBF(TFI=0 TLLI=0xd4d4ca34 DIR=DL STATE=RELEASING)
Thu Jan 19 11:27:55 2017 <0002> tbf.cpp:363 ********** TBF ends here **********
</pre>
<p>With some experimentation we found out that after changing "gprs mode gprs" to "gprs mode egprs" in nitb.cfg the problem seems to dissappear, this leads to the assumption that it is a timing problem between osmo-bts and osmo-pcu.</p>
<p>The problem has been observerd with an OCTBTS/Octphy, see also traces, logs and configuration files in the attachment.</p> OsmoBTS - Bug #1895 (Closed): Multiple bts and gsm core network instances on the same machinehttps://osmocom.org/issues/18952016-12-21T12:14:38Zdexter
<p>In most of our software modules we offer flexibility to rename sockets and to bind services on different ip addresses, while some of the modules still have hardcoded socket names or similar limitations. In this task we want to setup two independed core networks on a single machine for test to rule out remaining limitations.</p>
<p>Things that should not be a problem:<br />GGSN: would simply bind on a different lo address (GGSN <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> on 127.0.0.1, GGSN <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a> 127.0.0.3)<br />SGSN: Connection from SGSN <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> to GGSN <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a>: gtp local-ip 127.0.0.2; ggsn 0 remote-ip 127.0.0.1<br />SGSN: Connection from SGSN <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a> to GGSN <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a>: gtp local-ip 127.0.0.4; ggsn 0 remote-ip 127.0.0.3<br />SGSN: Connection from PCU <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> to SGSN <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a>: encapsulation udp local-port 23000<br />SGSN: Connection from PCU <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a> to SGSN <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a>: encapsulation udp local-port 23001<br />PCU: Connection from PCU <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> to SGSN <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a>: gprs nsvc 0 local udp port 23100; gprs nsvc 0 remote udp port 23000<br />PCU: Connection from PCU <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a> to SGSN <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a>: gprs nsvc 0 local udp port 23101; gprs nsvc 0 remote udp port 23001<br />BSC: MNCC socket paths of the BSC can be renamed via command line option but this should be migrated to a VTY option if possible.<br />BTS: Socket path can be changed via VTY<br />VTY/Control interfaces of all components can be bind to a different address</p>
<p>Things that are a problem:<br />BTS: Connection from BTS <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> to BSC <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a>: oml remote-ip 127.0.0.1<br />BTS: Connection from BTS <a class="issue tracker-2 status-5 priority-5 priority-highest closed" title="Feature: port Dieter's windows code to mISDN (Closed)" href="https://osmocom.org/issues/1">#1</a> to BSC <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Fix / finish the paging code (Closed)" href="https://osmocom.org/issues/2">#2</a>: oml remote-ip 127.0.0.1 > Clash!<br />Check if there is an option to change the abis over ip port for both, BTS and BSC</p>
<p>PCU: Connection to BTS: hardcoded socket path > Clash!<br />Make a VTY option to change the socket path!</p>
<p>(When done we probably should look out for more of such limitations. For new features we should always ensure that there are VTY commands to change socket names, ports and ip addresses, devices etc...)</p> OpenBSC - Bug #1779 (Closed): Problems with automatic subscriber creation.https://osmocom.org/issues/17792016-07-21T22:50:12Zdexter
<p>Maybe this is a problem with my configuration, but after long time I tried the automatic subscriber creation mode again. It constantly rejects the location update with the cause that no subscriber could be found. I traced the problem down to gsm_04_08.c:static bool subscr_regexp_check(). There the regexec() seems to fail.</p>
<p>The VTY show s the following:</p>
<p>OpenBSC> show network <br />BSC is on Country Code 1, Network Code 1 and has 1 BTS<br /> Long network name: 'Vaderfone'<br /> Short network name: 'Vaderfone'<br /> Authentication policy: accept-all, authorized regexp: *<br /> Auto create subscriber: yes<br /> Auto assign extension: yes<br /> Location updating reject cause: 13<br /> Encryption: A5/0<br /> NECI (TCH/H): 1<br /> Use TCH for Paging any: 0<br /> RRLP Mode: none<br /> MM Info: On<br /> Handover: Off<br /> Current Channel Load:<br /> Last RF Command: <br /> Last RF Lock Command:</p>
<p>If i get things right, "authorized regexp: *" should be ok with any IMSI. When I hardcode the returnvalue of subscr_regexp_check() to true it accepts any IMSI again and happyly creates the subscriber.</p>