Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-11-29T12:12:50ZOpen Source Mobile Communications
Redmine 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> 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> 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> OsmoMGW - Bug #3849 (New): race condition problem in rtp flow tests of the ttcn3 testsuitehttps://osmocom.org/issues/38492019-03-18T16:53:06Zdexter
<p>The TTCN3 tests that test actual RTP flow behavior through the MGW are prone to fail due to a race condition. The problem occurs when the RTP receiver in the test suite is switched off while at least one packet is still in the loop. When the packet eventually arrives the follwing error is generated:</p>
<pre>
RTP packets received while RX was disabled
MGCP_Test.ttcn:1424 MGCP_Test control part
MGCP_Test.ttcn:1364 TC_ts101318_rfc5993_rtp_conversion testcase
</pre>
<p>The problem is presumably more likely to occur when the test slave is under high load. Since all RTP tests are using the same API and work by the same principle all of those tests are prone to fail from time to time:</p>
<p>TC_one_crcx_loopback_rtp<br />TC_one_crcx_receive_only_rtp<br />TC_rtpem_selftest<br />TC_ts101318_rfc5993_rtp_conversion<br />TC_two_crcx_and_one_mdcx_rtp_ho<br />TC_two_crcx_and_rtp<br />TC_two_crcx_and_rtp_bidir<br />TC_two_crcx_and_unsolicited_rtp<br />TC_two_crcx_diff_pt_and_rtp<br />TC_two_crcx_diff_pt_and_rtp_bidir<br />TC_two_crcx_mdcx_and_rtp</p> OsmoBTS - Bug #3782 (New): OML bringup fails for osmo-bts-oc2g on high latency linkshttps://osmocom.org/issues/37822019-02-06T08:11:44Zdexter
<p>When osmo-bts-oc2g is used in lab setups with low latency links the OML bringup works without any problems. However, when there is a high latency link between BTS and BSC, then the OML bringup fails. The symptoms are not obvious, on the first look the bringup seems to work fine, but the BTS does not start transmitting and closer inspection of the OML related LOG output reveals that there are problems.</p> OsmoMGW - Bug #3673 (Resolved): chopped LCOhttps://osmocom.org/issues/36732018-10-26T12:20:47Zdexter
<p>(see trace) The codec name that that is transmitted in the LCO of the first CRCX is expected to re-appear in the SDP of the following 200 OK message. When inspecting the SDP of the following/second message, one can see that the last character of the codec name is missing. Since such a behavior can not observed when the codec was transmitted via SDP, the problem presumably is in the LCO parser.</p> OsmoMGW - Bug #3443 (New): Check audio-payload options in osmo-mgw VTYhttps://osmocom.org/issues/34432018-08-02T14:14:54Zdexter
<p>The VTY in osmo-mgw has some strange audio-payload settings, which can set payload number, name, ptime. Normally those are parameters that are set via LCO and SDP by the call agent. Why do we need to set those information in the VTY? We need to check back if those options are still used in a meaningful way and what they are for. Maybe this is a leftover from the refactoring which requires fixing/removal.</p>
<p>Here are some examples:</p>
<p>sdp audio-payload number<br />sdp audio-payload name NAME<br />sdp audio-payload send-ptime",</p> OsmoMGW - Bug #3442 (New): fix int mgcp_codec_decide() in mgcp_codec.chttps://osmocom.org/issues/34422018-08-02T14:08:40Zdexter
<p>The function mgcp_codec_decide() selects the codec that is later returned with the MGCP response in MGCP. The response is generated from rtp->codec, which is set by mgcp_codec_decide().</p>
<p>Unfortunately, the current implementation of mgcp_codec_decide() makes no sense at all. It only causes no trouble at the moment because endp->tcfg->no_audio_transcoding is set to 0, which means that transcoding is turned on at the moment even though we do not support trans coding.</p>
<p>mgcp_codec_decide() should be revised in the following way: <br />We remove rtp->codec, because Technically an MGW does not have one selected codec, it knows about several codecs and may make choices based on its transcoding capabilities and policies. In practice this would mean that mgcp_codec_decide() removes all the unsupported codecs from rtp->codecs[]. The functions that generate the SDP will then find only the selected codecs and return them. At the moment we can only return one codec from inside the SDP because we use rtp->codec as data source.</p>
<p>Since we do not support transcoding at the moment there will not be much in mgcp_codec_decide(), endp->tcfg->no_audio_transcoding is set to 0 we can display a warning that tells the user that transcoding is not supported yet.</p> OsmoBTS - Bug #3015 (Rejected): octphy: Mode Modify is currently not supported for Octasic PHYhttps://osmocom.org/issues/30152018-02-28T12:00:59Zdexter
<p>osmo-bts-octphy seems not to support MODE MODIFY.</p>
<p>See osmo-bts-octphy:l1_if.c:mph_info_req(). The call to l1if_rsl_mode_modify(lchan) is commented out.</p> OsmoBTS - Bug #2355 (New): optimize log output of phy specific codehttps://osmocom.org/issues/23552017-07-10T08:44:24Zdexter
<p>In osmo-bts, there is plenty of log output in the phy specific code. Some of this log output could be moved to the common code. This would unify the log output.</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> 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> OsmoSGSN - Bug #1768 (Stalled): VTY show llc displays State TLLI Unassigned permanentlyhttps://osmocom.org/issues/17682016-07-07T11:48:18Zdexter
<p>Expecting at least some assigned TLLI states in in SAPI list on globally Assigned TLLI state.</p>
<pre>
TLLI e625e4fb (Old TLLI ffffffff) BVCI=2 NSEI=101 Age=0: State TLLI Assigned
SAPI 1 State TLLI Unassigned (1) VUsend=4, VUrecv=5 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=400, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 2 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 3 State TLLI Unassigned (1) VUsend=91, VUrecv=64 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=500, N201-I=1503, mD=1520, mU=1520, kD=16, kU=16
SAPI 5 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=10, N200=3, N201-U=500, N201-I=1503, mD=760, mU=760, kD=8, kU=8
SAPI 7 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 8 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 9 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=500, N201-I=1503, mD=380, mU=380, kD=4, kU=4
SAPI 11 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=40, N200=3, N201-U=500, N201-I=1503, mD=190, mU=190, kD=2, kU=2
</pre>
<p>Already checked if the get_value_string(gprs_llc_state_strs, lle->state) returns the right string. Seems to work, numerical state is always 1 as well.</p>