Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-01-24T09:43:35ZOpen Source Mobile Communications
Redmine pySim - Bug #6340 (New): exception when using osmo-smdpp with python 3.9https://osmocom.org/issues/63402024-01-24T09:43:35Zdexter
<p>There is an exception when starting osmo-smdpp with python 3.9. This exception does not occur with python 3.10.</p>
<pre>
owner@osmotest:~/git_master/pysim$ python3.9 ./osmo-smdpp.py
Traceback (most recent call last):
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 100, in <module>
class SmDppHttpServer:
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 196, in SmDppHttpServer
def initiateAutentication(self, request: IRequest, content: dict) -> dict:
TypeError: 'staticmethod' object is not callable
</pre>
<p>Commit hash: af87cd544f784e51a41cea303cb57001d9954d9c</p> pySim - Bug #6278 (Resolved): fix sending of raw APDUshttps://osmocom.org/issues/62782023-11-29T12:12:50Zdexter
<p>There is a problem when sending raw APDUs to cards that are not provisioned yet. The scc (SimCardCommands) object seems to be missing for some reason.</p>
<pre>
$ ./pySim-shell.py -p 0
Using PC/SC reader number 0
Waiting for card...
Warning: Could not detect card type - assuming a generic card type...
Unsupported card type!
pySim-shell not equipped!
Welcome to pySim-shell!
(C) 2021-2023 by Harald Welte, sysmocom - s.f.m.c. GmbH and contributors
Online manual available at https://downloads.osmocom.org/docs/pysim/master/html/shell.html
pySIM-shell (no card profile)> apdu 0000000000
EXCEPTION of type 'AttributeError' occurred with message: ''SimCardBase' object has no attribute 'scc''
To enable full traceback, run the following command: 'set debug true'
pySIM-shell (no card profile)>
</pre> pySim - Bug #6271 (Resolved): do not execute a startup script on initialization errorshttps://osmocom.org/issues/62712023-11-23T10:42:26Zdexter
<p>When there is an error at initialization (e.g. card is not present) and a startup script is passed with the command line option, then the script will execute anyway. This cause a lot of unnecessary error messages and confusion. pySim-shell should not continue executing a starup script when there were initialization errors!</p> 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> OsmoBTS - Bug #6142 (Resolved): channels are opened, but nothing happens, sometimes strange DTAP ...https://osmocom.org/issues/61422023-08-23T14:41:41Zdexter
<p>This behavior was observed with osmo-bts-trx. A channel gets assigned, we see measurement reports and rarely some strange DTAP messages. The channel stays open for a while and then closes. (see attached trace)</p>
<p>When libosmocore change Id62c18f49f270449067b25b7104eb8b47f1955ec is reverted, then everything appears to be normal again.</p> OsmoPCU - Bug #6100 (Resolved): nacc_fsm: uninitialized neigh_key variable https://osmocom.org/issues/61002023-07-19T10:58:21Zdexter
<p>The neigh_key variable in handle_retrans_pkt_cell_chg_notif() is used uninitialized.</p>
<p>There is never data written to it, but it should contain the neighbor key information from the previous message (we are detecting a resend/dup here).<br />The neigh_key variable is used with neigh_cache_entry_key_eq() at the bottom on the function, but all neigh_cache_entry_key_eq() does is a comparison, it does not put valid values into neigh_key.<br />Then when neigh_key is detected as different from the neigh_key information in ctx.<br />The neigh_key information in ctx is overwritten with the (invalid) contents of the uninitialized neigh_key variable. This cannot work and needs fixing.</p>
<p>(change I96280f0ec5955ed3cb17641bf4118496c929bdac did not introduce the problem)</p>
<pre>
** CID 322150: (UNINIT)
/source-Osmocom/osmo-pcu/src/nacc_fsm.c: 409 in handle_retrans_pkt_cell_chg_notif()
/source-Osmocom/osmo-pcu/src/nacc_fsm.c: 409 in handle_retrans_pkt_cell_chg_notif()
________________________________________________________________________________________________________
*** CID 322150: (UNINIT)
/source-Osmocom/osmo-pcu/src/nacc_fsm.c: 408 in handle_retrans_pkt_cell_chg_notif()
402 * section 8c.6.1. */
403 nacc_fsm_state_chg(ctx->fi, NACC_ST_TX_CELL_CHG_CONTINUE);
404 return;
405 }
406
407 /* If tgt cell changed, restart resolving it */
>>> CID 322150: (UNINIT)
>>> Using uninitialized value "neigh_key.tgt_arfcn" when calling "neigh_cache_entry_key_eq".
408 if (!neigh_cache_entry_key_eq(&ctx->neigh_key, &neigh_key)) {
409 ctx->neigh_key = neigh_key;
410 nacc_fsm_state_chg(ctx->fi, NACC_ST_WAIT_RESOLVE_RAC_CI);
411 }
412 /* else: ignore it, it's a dup, carry on what we were doing */
413 }
/source-Osmocom/osmo-pcu/src/nacc_fsm.c: 409 in handle_retrans_pkt_cell_chg_notif()
403 nacc_fsm_state_chg(ctx->fi, NACC_ST_TX_CELL_CHG_CONTINUE);
404 return;
405 }
406
407 /* If tgt cell changed, restart resolving it */
408 if (!neigh_cache_entry_key_eq(&ctx->neigh_key, &neigh_key)) {
>>> CID 322150: (UNINIT)
>>> Using uninitialized value "neigh_key". Field "neigh_key.tgt_bsic" is uninitialized.
409 ctx->neigh_key = neigh_key;
410 nacc_fsm_state_chg(ctx->fi, NACC_ST_WAIT_RESOLVE_RAC_CI);
411 }
412 /* else: ignore it, it's a dup, carry on what we were doing */
413 }
414
/source-Osmocom/osmo-pcu/src/nacc_fsm.c: 409 in handle_retrans_pkt_cell_chg_notif()
403 nacc_fsm_state_chg(ctx->fi, NACC_ST_TX_CELL_CHG_CONTINUE);
404 return;
405 }
406
407 /* If tgt cell changed, restart resolving it */
408 if (!neigh_cache_entry_key_eq(&ctx->neigh_key, &neigh_key)) {
>>> CID 322150: (UNINIT)
>>> Using uninitialized value "neigh_key". Field "neigh_key.tgt_arfcn" is uninitialized.
409 ctx->neigh_key = neigh_key;
410 nacc_fsm_state_chg(ctx->fi, NACC_ST_WAIT_RESOLVE_RAC_CI);
411 }
412 /* else: ignore it, it's a dup, carry on what we were doing */
413 }
414
/source-Osmocom/osmo-pcu/src/nacc_fsm.c: 408 in handle_retrans_pkt_cell_chg_notif()
402 * section 8c.6.1. */
403 nacc_fsm_state_chg(ctx->fi, NACC_ST_TX_CELL_CHG_CONTINUE);
404 return;
405 }
406
407 /* If tgt cell changed, restart resolving it */
>>> CID 322150: (UNINIT)
>>> Using uninitialized value "neigh_key.local_lac" when calling "neigh_cache_entry_key_eq".
408 if (!neigh_cache_entry_key_eq(&ctx->neigh_key, &neigh_key)) {
409 ctx->neigh_key = neigh_key;
410 nacc_fsm_state_chg(ctx->fi, NACC_ST_WAIT_RESOLVE_RAC_CI);
411 }
412 /* else: ignore it, it's a dup, carry on what we were doing */
413 }
/source-Osmocom/osmo-pcu/src/nacc_fsm.c: 408 in handle_retrans_pkt_cell_chg_notif()
402 * section 8c.6.1. */
403 nacc_fsm_state_chg(ctx->fi, NACC_ST_TX_CELL_CHG_CONTINUE);
404 return;
405 }
406
407 /* If tgt cell changed, restart resolving it */
>>> CID 322150: (UNINIT)
>>> Using uninitialized value "neigh_key.tgt_bsic" when calling "neigh_cache_entry_key_eq".
408 if (!neigh_cache_entry_key_eq(&ctx->neigh_key, &neigh_key)) {
409 ctx->neigh_key = neigh_key;
410 nacc_fsm_state_chg(ctx->fi, NACC_ST_WAIT_RESOLVE_RAC_CI);
411 }
412 /* else: ignore it, it's a dup, carry on what we were doing */
413 }
</pre> OsmoBTS - Bug #6099 (Resolved): Immediate Assignment on PCH without IMSI (check back behaviour)https://osmocom.org/issues/60992023-07-17T08:25:51Zdexter
<p>It may happen that the PCU tries to perform an ImmediateAssignment even though it does not know the IMSI yet. At the moment osmo-bts rejects those ImmediateAssignment (PCUIF) requests since without an IMSI we can not properly calculate the paging group. However, since we discovered ImmediateAssignments without an IMSI in the wild we need to check back if we changed the behavior when moving from PCUIF v.10 to PCUIF v.11. And if necessary we should make sure that the behavior we had before the change is restored.</p>
<p>The specs seem not to be entirely clear about this, here are some references:<br />3gpp TS 44.018 3.5.3.1.2<br />3gpp TS 44.060 5.5.1.5</p> OsmoHNBGW - Bug #6093 (Resolved): Some TTCN3 tests, including TC_rab_assignment faile due to prob...https://osmocom.org/issues/60932023-07-10T20:22:57Zdexter
<p>There is a problem with MGCP that prevents TC_rab_assignment from passing: Osmo-mgcp-client now checks if the payload type / codec name we get back from the MGW actually makes sense. Since we use 23 as payload type and "FOO" as codec name in the MGW emulation of the TTCN3 testsuite, this gets rejected. We must use a more realistic payload type / codec name.</p> OsmoBSC - Bug #6059 (New): negotiate GSM-HR RTP packet format explicitlyhttps://osmocom.org/issues/60592023-06-13T10:38:00Zdexter
<p>In <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: osmo-bts-sysmo and osmo-bts-trx use different GSM-HR RTP packet format (Resolved)" href="https://osmocom.org/issues/5688">#5688</a> we have solved the problem that, depending on the BTS model, the BTS may use a different HR-GSM format (RFC5993 vs. TS 101.318. Now the user can chose via a VTY option which format the BTS should emit. This improves the situation a lot.</p>
<p>However if conversion is still needed for some reason, OsmoMGW will still blindly convert TS 101.318 to RFC5993 and vice versa. This means that there is a problem in case there is one BTS That speaks TS 101.318 and another one that speaks RFC5993 on the same MGW. OsmoMGW can already be explicitly instructed via SDP (similar to AMR BWE/OE) which format to use. We should add a VTY option to osmo-bsc so that we can specify the format we want to use on the link pointing to the core network side. Doing so, the MGW would accept any format on the leg pointing to the BTS and emit the specified format on the leg pointing towards the core network.</p>
<p>Unfortunately osmo-mgcp-client does not yet have the API to specify the format. #5723 already deals with the problem but this also means that this ticket is blocked by #5723</p> SIMtrace 2 - Bug #6026 (Resolved): simtrace2 cardem firmware stops card communication earlyhttps://osmocom.org/issues/60262023-05-09T07:54:28Zdexter
<p>The latest (08052023) version of the simtrace cardem firmware seems to be broken. The card communication seems normal at first but then suddenly stops early.</p>
<p>Attached one finds two firmware images:<br />Latest firmware from 08.05.2023: simtrace-cardem-dfu-latest.bin (does not work)<br />Firmware image from last year: simtrace-cardem-dfu-0.8.1.33-9088.bin (works, even with current master host utils)</p>
<pre>
$ simtrace2-cardem-pcsc -V 1d50 -P 60e3 -C 1 -I 0 -H "2-1" -n 2
simtrace2-cardem-pcsc - Using PC/SC reader as SIM
(C) 2010-2022, Harald Welte <laforge@gnumonks.org>
(C) 2018, sysmocom -s.f.m.c. GmbH, Author: Kevin Redon <kredon@sysmocom.de>
DLINP NOTICE [0] <= osmo_st2_cardem_request_config(features=00000001)
DLINP NOTICE [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
DLINP NOTICE [0] <= _modem_sim_select(remote_sim=1)
DLINP NOTICE [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f c7 80 31 a0 73 be 21 13 67 43 20 07 18 00 00 01 a5 )
DLINP NOTICE [0] <= _modem_reset(asserted=2, pulse_ms=300)
Entering main loop
DLGLOBAL NOTICE => IRQ STATUS: flags=0x13, fi=1, di=1, wi=10 wtime=9600 (RESET VCC CLK )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x3, fi=1, di=1, wi=10 wtime=9600 (VCC CLK )
DLGLOBAL NOTICE Warm Resetting card in reader...
DLGLOBAL NOTICE => PTS req: ff 10 96 79
DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 a4 00 04 02
DLINP DEBUG [0] <= osmo_st2_cardem_request_pb_and_rx(pb=a4, le=2)
DLGLOBAL INFO => DATA: flags=0x02 (FINAL ), 3f 00
DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=6156)
DLGLOBAL INFO => DATA: flags=0x01 (HDR ), 00 c0 00 00 56
DLINP DEBUG [0] <= osmo_st2_cardem_request_pb_and_tx(pb=c0, tx=62 54 82 02 78 21 83 02 3f 00 a5 19 80 01 71 83 02 7f ff cb 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 ca 01 82 8a 01 05 ab 1b 84 01 2e 90 00 84 01 88 a4 06 83 01 01 95 01 08 84 01 fc a4 06 83 01 0a 95 01 08 c6 0f 90 01 70 83 01 01 83 01 0a 83 01 0b 83 01 81 , len=86)
DLINP DEBUG [0] <= osmo_st2_cardem_request_sw_tx(sw=9000)
DLGLOBAL NOTICE => IRQ STATUS: flags=0x13, fi=9, di=6, wi=10 wtime=9600 (RESET VCC CLK )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x12, fi=9, di=6, wi=10 wtime=9600 (RESET CLK )
DLGLOBAL NOTICE => IRQ STATUS: flags=0x10, fi=9, di=6, wi=10 wtime=9600 (RESET )
</pre> OsmoPCU - Bug #6022 (Resolved): osmo-pcu, fix support for multiple PDCH on ericsson RBShttps://osmocom.org/issues/60222023-05-02T15:27:15Zdexter
<p>The API function (l1if_open_pdch) which opens a TRX (direct PHY) suggests that a PDCH (timeslot) rather then a TRX (8 timeslots) are returned. Same is true for l1if_open_pdch. This may lead to confusion when implementing the Ercisson RBS CCU support. The problem should be fixed and the functions should be renamed to l1if_open_trx and l1if_close_trx.</p> OsmoPCU - Bug #6015 (New): osmo-pcu (with ericsson RBS) is unable to keep TRAU frames in sync https://osmocom.org/issues/60152023-04-25T08:59:55Zdexter
<p>The problem is observed with an RBS installation that uses a DUG20 but a different (presumably older, RRUS 01?) transceiver. The symptom is that the PCU is unable to get a reliable sync on the TRAU frames coming from the CCU (transceiver unit). The CCU eventually closes the channel.</p>
<p>we see the following messages:</p>
<pre>
Mon Apr 24 09:34:08 2023 <0010> trau/trau_sync.c:519 trau_sync(trau-sync){FRAME_ALIGNED}: state_chg to FRAME_ALIGNMENT_LOST
</pre>
The reasons for this could be:
<ul>
<li>Unreliable E1 connection (the setup uses icE1usb+osmo-e1d)</li>
<li>The transceiver module has a slightly different TRAU frame format (unlikely)</li>
<li>Bug in the TRAU synchronizer of libosmo-abis</li>
</ul> 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 #5688 (Resolved): osmo-bts-sysmo and osmo-bts-trx use different GSM-HR RTP packet f...https://osmocom.org/issues/56882022-09-20T16:28:55Zdexter
<p>When comparing the RTP packet format that is used by osmo-bts-sysmo and osmo-bts-trx it becomes obvious that osmo-bts-trx uses RFC5993 (35 byte payload), while osmo-bts-sysmo uses TS 101.318 (34 byte payload). The reason for this is that osmo-bts-trx is using the encoding function in libosmocore gsm0503_coding.c, while osmo-bts-sysmo uses the encoder and decoder functions of its DSP.</p>
<p>We should make sure that all osmo-bts versions always use the same format. For osmo-bts-sysmo that would mean that we need to convert to RFC5993. The conversion is simple, we just need to prepend one byte ToC at the beginning of each RTP packet we emit.</p>
<p>In the receiving path we should make sure that both formats are accepted. Since the BTS knows when GSM-HR is in use we could just check the length of the packets to distinguish which of the two formats we receive</p>
<p>Optionally it might also make the format configurable. Preferably using a proprietary RSL IE so that the config value can be in the osmo-bsc.cfg.</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> OsmoBSC - Bug #5634 (Resolved): Paging broken (at least) for E1 BTSshttps://osmocom.org/issues/56342022-07-26T16:33:01Zdexter
<p>The change with the ID I1b5b1a98115b4e9d821eb3330fc5b970a0e78a44 introduces a new way to handle nm signgals in paging.c. This seems to break the paging for E1 based BTSs.</p>
<p>For some reason the right signal / nsd->obj_class combination never occurs and so the line "bts->paging.available_slots = paging_estimate_available_slots(bts, load_ind_timeout);" is never executed. This results into 0 free paging slots, which means paging requests will never find a free slot to get executed. Also the VTY shows 0 free paging slots. When one commit below the change above is checked out and osmo-bsc is compiled in that state, then the paging is fine again.</p>
<p>A solution might be to find out what signal and object class combinations occur in the E1 world and to see how that is different from the ipacces world. At least the signal S_NM_RUNNING_CHG never occurrs, when the line that filters on this signal is commented out it drops out in the default section of the case below because the expected object class never occurs.</p> OsmoBSCNAT - Bug #5597 (Resolved): fix uninitialized address CID 273006https://osmocom.org/issues/55972022-06-29T15:21:34Zdexter
<pre>
*** CID 273006: (UNINIT)
/source-Osmocom/osmo-bsc-nat/src/osmo-bsc-nat/bsc_nat_fsm.c: 136 in sccp_sap_up_cn()
130 break;
131
132 case OSMO_PRIM(OSMO_SCU_PRIM_N_DISCONNECT, PRIM_OP_INDICATION):
133 /* indication of disconnect */
134 subscr_conn = subscr_conn_get_by_id(prim->u.disconnect.conn_id, BSC_NAT_NET_CN);
135 if (!subscr_conn) {
>>> CID 273006: (UNINIT)
>>> Using uninitialized value "addr" when calling "bsc_nat_print_addr".
136 LOGP(DMAIN, LOGL_ERROR, "Unknown conn_id=%" PRIu32 " from %s\n", prim->u.disconnect.conn_id,
137 bsc_nat_print_addr_cn(addr));
138 goto error;
139 }
140
141 LOGP(DMAIN, LOGL_DEBUG, "Fwd via %s\n", talloc_get_name(subscr_conn));
/source-Osmocom/osmo-bsc-nat/src/osmo-bsc-nat/bsc_nat_fsm.c: 124 in sccp_sap_up_cn()
118 break;
119
120 case OSMO_PRIM(OSMO_SCU_PRIM_N_DATA, PRIM_OP_INDICATION):
121 /* connection-oriented data received */
122 subscr_conn = subscr_conn_get_by_id(prim->u.data.conn_id, BSC_NAT_NET_CN);
123 if (!subscr_conn) {
>>> CID 273006: (UNINIT)
>>> Using uninitialized value "addr" when calling "bsc_nat_print_addr".
124 LOGP(DMAIN, LOGL_ERROR, "Unknown conn_id=%" PRIu32 " from %s\n", prim->u.data.conn_id,
125 bsc_nat_print_addr_cn(addr));
126 goto error;
127 }
128
129 rc = bssap_handle_dt(BSC_NAT_NET_CN, subscr_conn, oph->msg, msgb_l2len(oph->msg));
** CID 273005: (UNINIT)
</pre>
<p>The address variable is uninitialized in case OSMO_PRIM(OSMO_SCU_PRIM_N_DATA, PRIM_OP_INDICATION) and OSMO_PRIM(OSMO_SCU_PRIM_N_DISCONNECT, PRIM_OP_INDICATION. Its only used to print it in the log, which means removing bsc_nat_print_addr_cn(addr) from the log statement would fix the problem. Unfortunately this also would make debugging more difficult, however there seems also to be no way to ask libosmo-sccp for the address of a particular conn_id.</p> 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> OsmoBSC - Bug #4752 (Resolved): TC_ho_int does not passhttps://osmocom.org/issues/47522020-09-14T15:55:30Zdexter
<p>Since build 1113 TC_ho_int does not pass.</p> OsmoBTS - Bug #4281 (Resolved): MS power control loop is interrupted when bad frames are receivedhttps://osmocom.org/issues/42812019-11-26T13:25:54Zdexter
<p>See <a class="external" href="http://git.osmocom.org/osmo-bts/tree/src/common/l1sap.c#n1236">http://git.osmocom.org/osmo-bts/tree/src/common/l1sap.c#n1236</a><br />When a bad frame is received the on l1sap.c, then it is checked if it was a SACCH frame and if it was only radio_link_timeout() is called. The function then exits with -EINVAL. However, later in the code one can find that there is a call to lchan_ms_pwr_ctrl(). We should not skip this step. Instead we should supply the power control loop so that it knows that the reception is not enough and the MS power must be increased.</p>
<p>See also @pespin's comment at <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16170/1/src/common/l1sap.c">https://gerrit.osmocom.org/c/osmo-bts/+/16170/1/src/common/l1sap.c</a>:<br />That means in this case lchan_ms_pwr_ctrl() is not called and the MS power loop is missing information. For instance it could mean the strength being used by the MS is not enough and precisely lchan_ms_pwr_ctrl() should be notified so that BTS can instruct the MS to increase the signal strength.</p>
<p>If in this case we don't have block data (data<sup><a href="#fn0">0</a></sup>) then MS Power Level value is not available for lchan_ms_pwr_ctrl(). In that case I'd probably makes sense to pass a special value to it, for instance <del>1, so that it knows the value is not available. Internally it can then for instance use lchan</del>>ms_power_ctrl.current as input for calculations, or simply raise the current MS Power level if rssi is detected to be bad.</p> OsmoMSC - Bug #4214 (Resolved): Also accept messages with unknown TLV Information elementshttps://osmocom.org/issues/42142019-09-24T09:22:37Zdexter
<p>3GPP TS 29.118, chapter 7.5 states: "The receiving entity shall ignore all information elements unknown or unforeseen in a message." Unfortunately we currently send a STATUS message back and ignore the message. This is not as the standard specifies.</p> OsmoMSC - Bug #4160 (Rejected): osmo-msc segfaultshttps://osmocom.org/issues/41602019-08-20T11:40:11Zdexter
<pre>
Tue Aug 20 13:24:18 2019 DPAG <0005> paging.c:97 Paging: IMSI-001010000000102:MSISDN-23102 for MNCC: establish call: Starting paging
Tue Aug 20 13:24:18 2019 DMSC <0006> sgs_iface.c:470 XXXXXXXXXX state == 1 conf_by_radio_contact_ind == 1
Tue Aug 20 13:24:18 2019 DREF <000a> vlr_sgs.c:351 VLR subscr IMSI-001010000000102:MSISDN-23102 + SGs-paging-req: now used by 6 (2*SGs,attached,mncc_tx_to_gsm_cc,CC,SGs-paging-req)
Tue Aug 20 13:24:18 2019 DREF <000a> paging.c:107 VLR subscr IMSI-001010000000102:MSISDN-23102 + Paging: now used by 7 (2*SGs,attached,mncc_tx_to_gsm_cc,CC,SGs-paging-req,Paging)
Tue Aug 20 13:24:18 2019 DREF <000a> gsm_04_08_cc.c:1925 VLR subscr IMSI-001010000000102:MSISDN-23102 - mncc_tx_to_gsm_cc: now used by 6 (2*SGs,attached,CC,SGs-paging-req,Paging)
Tue Aug 20 13:24:19 2019 DREF <000a> sgs_iface.c:274 VLR subscr IMSI-001010000000102:MSISDN-23102 + check_sgs_association: now used by 7 (2*SGs,attached,CC,SGs-paging-req,Paging,check_sgs_association)
Tue Aug 20 13:24:19 2019 DREF <000a> sgs_iface.c:293 VLR subscr IMSI-001010000000102:MSISDN-23102 - check_sgs_association: now used by 6 (2*SGs,attached,CC,SGs-paging-req,Paging)
Tue Aug 20 13:24:19 2019 DREF <000a> sgs_iface.c:786 VLR subscr IMSI-001010000000102:MSISDN-23102 + sgs_rx_service_req: now used by 7 (2*SGs,attached,CC,SGs-paging-req,Paging,sgs_rx_service_req)
Tue Aug 20 13:24:19 2019 DREF <000a> vlr_sgs.c:263 VLR subscr IMSI-001010000000102:MSISDN-23102 + vlr_sgs_pag_ack: now used by 8 (2*SGs,attached,CC,SGs-paging-req,Paging,sgs_rx_service_req,vlr_sgs_pag_ack)
Tue Aug 20 13:24:19 2019 DREF <000a> vlr_sgs.c:270 VLR subscr IMSI-001010000000102:MSISDN-23102 - SGs-paging-req: now used by 7 (2*SGs,attached,CC,Paging,sgs_rx_service_req,vlr_sgs_pag_ack)
Tue Aug 20 13:24:19 2019 DREF <000a> vlr_sgs.c:272 VLR subscr IMSI-001010000000102:MSISDN-23102 - vlr_sgs_pag_ack: now used by 6 (2*SGs,attached,CC,Paging,sgs_rx_service_req)
Tue Aug 20 13:24:19 2019 DREF <000a> sgs_iface.c:823 VLR subscr IMSI-001010000000102:MSISDN-23102 - sgs_rx_service_req: now used by 5 (2*SGs,attached,CC,Paging)
Tue Aug 20 13:24:21 2019 DBSSAP <0010> sccp_ran.c:84 (GERAN-A-1 from RI=SSN_PC,PC=0.23.3,SSN=BSSAP) sccp_ran_sap_up(N-CONNECT.indication)
Tue Aug 20 13:24:21 2019 DRR <0003> ran_peer.c:596 ran_peer(GERAN-A:RI-SSN_PC:PC-0-23-3:SSN-BSSAP)[0x55d7abeed440]{READY}: Received Event RAN_PEER_EV_MSG_UP_CO_INITIAL
Tue Aug 20 13:24:21 2019 DMSC <0006> fsm.c:423 msub_fsm[0x55d7abeed2a0]{active}: Allocated
Tue Aug 20 13:24:21 2019 DMSC <0006> fsm.c:423 msc_i[0x55d7abeee460]{READY}: Allocated
Tue Aug 20 13:24:21 2019 DMSC <0006> fsm.c:453 msc_i[0x55d7abeee460]{READY}: is child of msub_fsm[0x55d7abeed2a0]
Tue Aug 20 13:24:21 2019 DMSC <0006> fsm.c:423 msc_a[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: Allocated
Tue Aug 20 13:24:21 2019 DMSC <0006> fsm.c:453 msc_a[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: is child of msub_fsm[0x55d7abeed2a0]
Tue Aug 20 13:24:21 2019 DMSC <0006> msc_a.c:1039 msc_a(unknown:GERAN-A-1:NONE)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: State change to MSC_A_ST_VALIDATE_L3 (X1, 5s)
Tue Aug 20 13:24:21 2019 DMSC <0006> ran_peer.c:392 msc_i(unknown:GERAN-A-1:NONE)[0x55d7abeee460]{READY}: Received Event MSC_EV_FROM_RAN_COMPLETE_LAYER_3
Tue Aug 20 13:24:21 2019 DMSC <0006> msc_i.c:103 msc_a(unknown:GERAN-A-1:NONE)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: Received Event MSC_A_EV_FROM_I_COMPLETE_LAYER_3
Tue Aug 20 13:24:21 2019 DREF <000a> msc_a.c:176 msc_a(unknown:GERAN-A-1:NONE)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: + msc_a_ran_dec: now used by 1 (msc_a_ran_dec)
Tue Aug 20 13:24:21 2019 DBSSAP <0010> ran_msg_a.c:783 msc_a(unknown:GERAN-A-1:NONE)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: RAN decode: BSSMAP: Rx BSSMAP DT1 COMPLETE LAYER 3
Tue Aug 20 13:24:21 2019 DBSSAP <0010> msc_a.c:1513 msc_a(unknown:GERAN-A-1:NONE)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: RAN decode: BSSMAP Complete Layer 3
Tue Aug 20 13:24:21 2019 DRLL <0000> msc_a.c:1160 msc_a(unknown:GERAN-A-1:NONE)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: Dispatching 04.08 message: RR GSM48_MT_RR_PAG_RESP
Tue Aug 20 13:24:21 2019 DRR <0003> gsm_04_08.c:1145 msc_a(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: Rx PAGING RESPONSE
Tue Aug 20 13:24:21 2019 DREF <000a> gsm_04_08.c:1147 msc_a(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: + paging-response: now used by 2 (msc_a_ran_dec,paging-response)
Tue Aug 20 13:24:21 2019 DVLR <000e> fsm.c:423 Process_Access_Request_VLR(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeeebb0]{PR_ARQ_S_INIT}: Allocated
Tue Aug 20 13:24:21 2019 DVLR <000e> fsm.c:453 Process_Access_Request_VLR(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeeebb0]{PR_ARQ_S_INIT}: is child of msc_a(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeee920]
Tue Aug 20 13:24:21 2019 DVLR <000e> vlr_access_req_fsm.c:675 Process_Access_Request_VLR(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeeebb0]{PR_ARQ_S_INIT}: rev=R99 net=GERAN (no Auth)
Tue Aug 20 13:24:21 2019 DVLR <000e> vlr_access_req_fsm.c:699 Process_Access_Request_VLR(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeeebb0]{PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
Tue Aug 20 13:24:21 2019 DVLR <000e> vlr_access_req_fsm.c:402 Process_Access_Request_VLR(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeeebb0]{PR_ARQ_S_INIT}: proc_arq_fsm_done(IMSI_UNKNOWN_IN_VLR)
Tue Aug 20 13:24:21 2019 DVLR <000e> vlr_access_req_fsm.c:103 Process_Access_Request_VLR(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeeebb0]{PR_ARQ_S_INIT}: State change to PR_ARQ_S_DONE (no timeout)
Tue Aug 20 13:24:21 2019 DVLR <000e> vlr_access_req_fsm.c:112 Process_Access_Request_VLR(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeeebb0]{PR_ARQ_S_DONE}: Process Access Request result: IMSI_UNKNOWN_IN_VLR
Tue Aug 20 13:24:21 2019 DMSC <0006> vlr_access_req_fsm.c:153 msc_a(TMSI-0x2009A35F:GERAN-A-1:PAGING_RESP)[0x55d7abeee920]{MSC_A_ST_VALIDATE_L3}: Received Event MSC_A_EV_CN_CLOSE
./start-msc_ext_mncc.sh: line 5: 8168 Segmentation fault sudo osmo-msc -c ./osmo-msc.cfg -M /tmp/bsc_mncc
</pre> osmo-sip-connector - Bug #4159 (Resolved): osmo-sip-connector segfaultshttps://osmocom.org/issues/41592019-08-20T11:38:29Zdexter
<pre>
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:956 MNCC rcvd message type: MNCC_DISC_IND
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:575 Rcvd MNCC_DISC_IND, Cause: NORM_CALL_CLEAR
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:577 leg(2147483649) was disconnected. Releasing
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:68 Starting Timer for MNCC_REL_CNF
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:142 MNCC sent message type: MNCC_REL_REQ
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:457 sip_release_call(): Release with MNCC cause(NORM_CALL_CLEAR)
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:429 cause2status(): Mapping cause(NORM_CALL_CLEAR) to status(200)
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:481 Ending leg(0x55d0078bb090) in connected state.
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:327 SIP event[nua_r_bye] status(200) phrase(OK) 0x55d0078bb090
Tue Aug 20 13:16:12 2019 DSIP <0000> sip.c:376 leg(0x55d0078bb090) got resp to bye
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:956 MNCC rcvd message type: MNCC_REL_CNF
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:82 Got response(MNCC_REL_CNF), stopping timer on leg(2147483649)
Tue Aug 20 13:16:12 2019 DMNCC <0001> mncc.c:624 leg(2147483649) was cnf released.
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:327 SIP event[nua_i_invite] status(100) phrase(Trying) (nil)
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:392 Processing INVITE Call-ID: 6deb60a42abf482b0f4555df2a0e06fb@10.9.1.122:5060
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:115 Incoming call(6deb60a42abf482b0f4555df2a0e06fb@10.9.1.122:5060) handle(0x55d0078bfaf0)
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:167 SDP Extracted: IP=(10.9.1.122) PORT=(14472) PAYLOAD=(3).
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:327 SIP event[nua_i_state] status(100) phrase(Trying) 0x55d0078c2170
Tue Aug 20 13:24:18 2019 DSIP <0000> sip.c:415 Did not handle event[nua_i_state] status(100)
Tue Aug 20 13:24:21 2019 DMNCC <0001> mncc.c:946 Failed to read 0/Function not implemented. Re-connecting.
Tue Aug 20 13:24:21 2019 DAPP <0002> app.c:50 Going to release call(5020) due MNCC.
Tue Aug 20 13:24:21 2019 DSIP <0000> sip.c:457 sip_release_call(): Release with MNCC cause(unknown 0x0)
Tue Aug 20 13:24:21 2019 DSIP <0000> sip.c:433 cause2status(): Cause(unknown 0x0) not found in map.
Tue Aug 20 13:24:21 2019 DSIP <0000> sip.c:468 Cancelling leg(0x55d0078c2170) in confirmed state
Tue Aug 20 13:24:21 2019 DMNCC <0001> mncc.c:290 MNCC not connected releasing leg(5020)
Tue Aug 20 13:24:26 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:31 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:36 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:41 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:46 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:51 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:24:56 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:25:01 2019 DMNCC <0001> mncc.c:925 Failed to connect(/tmp/bsc_mncc). Retrying
Tue Aug 20 13:25:04 2019 DSIP <0000> sip.c:327 SIP event[nua_i_invite] status(100) phrase(Trying) (nil)
Tue Aug 20 13:25:04 2019 DSIP <0000> sip.c:392 Processing INVITE Call-ID: 2465a4853348db406e3bd1d618d95ce8@10.9.1.122:5060
Tue Aug 20 13:25:04 2019 DSIP <0000> sip.c:115 Incoming call(2465a4853348db406e3bd1d618d95ce8@10.9.1.122:5060) handle(0x55d0078bd160)
Tue Aug 20 13:25:04 2019 DSIP <0000> sip.c:167 SDP Extracted: IP=(10.9.1.122) PORT=(15736) PAYLOAD=(3).
Tue Aug 20 13:25:04 2019 DMNCC <0001> mncc.c:906 Failed to send message leg(5021)
./start-osmo-sip-connector.sh: line 5: 20158 Segmentation fault sudo osmo-sip-connector -c ./osmo-sip-connector.cfg
</pre> OsmoBTS - Bug #3960 (Resolved): fix TC_rsl_ms_pwr_ctrl and TC_si_sched_13_2bis_2ter_2quaterhttps://osmocom.org/issues/39602019-04-26T10:08:56Zdexter
<p>The tests fix TC_rsl_ms_pwr_ctrl and TC_si_sched_13_2bis_2ter_2quater fail since a delay after RSL initalization was introduced. Since the failure also appears with with latest, the problem must have been triggered by the change in the testsuite.</p> OsmoMSC - Bug #3959 (Resolved): Extranous SGsAP-PAGING-REQUEST after MT CSFB call (TC_sgsap_lu_an...https://osmocom.org/issues/39592019-04-25T11:47:59Zdexter
<p>There is an SGsAP-PAGING-REQUEST visible just after the CSFB call is complete. This behaviour seems not to be catched by the testsuite, but it looks problematic. Attached one finds a trace from TC_sgsap_lu_and_mt_call</p> OsmoMSC - Bug #3941 (Resolved): investigate why TC_lu_and_mt_sms_paging_and_nothing suddelnly fai...https://osmocom.org/issues/39412019-04-18T14:22:15Zdexter
<p>In ttcn3-msc-test-latest TC_lu_and_mt_sms_paging_and_nothing now failes, but in ttcn3-msc-test it does pass. This meas that something in the testsuite has changed. We need to check why this effect occurs in order to make sure the problem is not related to some regression.</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>