Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.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://projects.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://projects.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://projects.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> OsmoMGW - Feature #6171 (In Progress): mgcp-client API: there should be a separate mgcp_codec_par...https://projects.osmocom.org/issues/61712023-09-08T15:21:26Zdexter
<p>This was previously discussed in ticket #5723, which got deleted due to an error.</p>
<p>There is a problem we face with the mgcp_client API. mgcp_client_fsm in particular.</p>
<p>The problem is that we are not able to assign different payload type numbers for the same codec. So it is not possible to have the following configuration:</p>
<p>codec: AMR, payload-type: 112<br />codec: AMR, payload-type: 113</p>
<p>However, this would be necessary in case we want to define AMR once in octet-aligned and once in bandwith-efficient configuration, which brings us to the second problem. Since there is only one mgcp_codec_param struct member "param", which only lets us to define exactly one set of codec parameters we cannot even define two different configurations.</p>
<p>Also in some cases it would be also convenient to circumvent the SDP parsing/generation of osmo-mgcp-client and use a user defined SDP string directly.</p> OsmoBSC - Bug #6159 (New): use paging queue for PAGING messages that come from the BSC co-located...https://projects.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 - Feature #6150 (New): PCUIF: Use unique identifiers instead of the TLLI as msg_id.https://projects.osmocom.org/issues/61502023-08-25T14:05:40Zdexter
<p>When the PCUIF sends a MAC block for PCH (or AGCH) it may request a conformation when the MAC block is sent. For the conformation an uint32_t message id (msg_id) is used. At the moment we use the TLLI as message identifier. However, on the one hand side the TLLI may not be unique, and on the other hand the TBF may not have a TLLI assigned yet. This is in particular the case when the MS is just attaching to the network and has not completed the GMM attach phase yet.</p>
<p>A solution would be to somehow generate a truly unique identifier inside the PCU and use it when sending MAC blocks through the PCUIF. When the receiving end responds with the confirmation we will have to match the identifier back to the TBF to which it belongs.</p> OsmoBTS - Bug #6147 (Resolved): TC_pcu_data_req_pdtch/ptcch/pdtch/ptcch and TC_pcu_ptcch failhttps://projects.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://projects.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> OsmoSGSN - Feature #6139 (New): test mobility between GERAN (OsmoPCU) and EUTRAN (Open5GS) end to...https://projects.osmocom.org/issues/61392023-08-22T09:55:50Zdexter
<p>The mobility features that we recently added to Open5GS and OsmoPCU were developed and tested against TTCN3 testsuites, but we didn't confirm the functionality on real hardware yet.</p>
<p>To do this we need to create a setup with an OsmoBTS/OsmoPCU based GERAN cell and an appropriate EUTRAN ENB that is controlled by Open5GS. In order to be able to trigger the cell change it may be required to equip the transmittig antennas of both radios with variable attenuators.</p> OsmoPCU - Bug #6100 (Resolved): nacc_fsm: uninitialized neigh_key variable https://projects.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://projects.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://projects.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://projects.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://projects.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> OsmoSGSN - Feature #6050 (Closed): Add missing testcase to test GERAN originated RIM RAN informat...https://projects.osmocom.org/issues/60502023-06-02T15:08:09Zdexter
<p>At the moment we only have a testcase for an EUTRAN originated RAN information request that targets a GERAN cell (TC_rim_eutran_to_geran). We have no testcase that tests the reverse direction, which is equally important. (We also have no testcase for requests that go from EUTRAN to EUTRAN.)</p>
<p>We should add those two missing testcases to the testsuite in order to be sure that RIM message forwarding is working correctly.</p> OsmoPCU - Feature #6044 (Resolved): Extend osmo-pcu and related TTCN3 tests so that PacketCellCha...https://projects.osmocom.org/issues/60442023-05-25T10:18:53Zdexter
<p>At the moment we only test PacketCellChangeNotification (which triggers the RAN information request cascade) with 2G cells. Also osmo-pcu is currently only able to understand PacketCellChangeNotification requests that contain 2G cells as well.</p>
<p>In order to improve NACC/CCO support towards 3G and most importantly 4G we must extend the TTCN3 tests and osmo-pcu. On the TTCN3 testsuite this essentially means to complete the missing bits in the message records of RLCMAC_CSN1_Types.ttcn. Once that is done we can complete the testcases and use those to complete osmo-pcu. There we mainly have to take care that the 3G/4G target cell information is properly encapsulated in RIM messages. There may also be missing bits in the reverse path when the cell information is encapsulated in PacketNeighbourCellData messages and passed back to the MS/UE.</p> SIMtrace 2 - Bug #6026 (Resolved): simtrace2 cardem firmware stops card communication earlyhttps://projects.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://projects.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://projects.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://projects.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> pySim - Feature #5976 (New): pySim-prog: do not program linked files multiple timeshttps://projects.osmocom.org/issues/59762023-03-27T16:05:01Zdexter
<p>In the card file system there are files that exist in DF.GSM and in ADF.USIM. In case the files share the same content there may be one physical file and one that is a link to that physical file. At the momen pySim-prog does not care about this. It just programs all files or it programs the file intentionally only in one of the two locations, the latter one is a problem in case the specification of one of the files evolves so that the link has to be removed for newer card revisions and two individual files have to be created. Then one of the two is no longer programmed.</p>
<p>This can be handled smarter. The FCP should tell if the file is a linked file or not. So we should check if the file in question is a linked file and if so, we would skip programming it. In case the file is a physical file we would program it. This would mean we would have to visit all files in all locations but we would be on the safe side in case we have to break up links in future card revisions.</p>
<p>(The topic came up while fixing <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: pySim-prog.py --mnclen=3 buggy / broken (Resolved)" href="https://projects.osmocom.org/issues/5830">#5830</a>)</p> OsmoPCU - Feature #5930 (New): handle multiple BTSs with one PCUhttps://projects.osmocom.org/issues/59302023-03-02T09:07:50Zdexter
<p>OsmoPCU has been used so far in BTS co-located scenario only. This scenario always consists of exactly one BTS instance and exactly one PCU instance. When the PCU is used on a BSC colocated scenario one PCU may serve multiple BTSs. OsmoPCU already manages a list with BTSs and the PCU socket protocol already supports multiple BTSs as well but it is unclear how mature this is. At least the code/API that is used to handle the direct PHY access is not able to distinguish between different BTSs.</p> OsmoBTS - Feature #5927 (Resolved): use "Direct TLLI" method to confirm IMMEDIATE ASSIGNMENT mess...https://projects.osmocom.org/issues/59272023-02-28T10:42:39Zdexter
<p>To assign downlink TBFs, the PCU sends an IMMEDIATE ASSIGNMENT MAC block through the PCU SOCK interface to the BTS. The BTS confirms the sending of this IMMEDIATE ASSIGNMENT to the PCU by sending the MAC block back to the PCU. The MAC block essentially serves as a reference for the confirmation message. This method has some disadvantages so we decided to replace it.</p>
<p>The new method attaches a TLLI (and a paging group field) to the MAC block when it send to the BTS. The BTS then uses the TLLI instead of the MAC block as an identifier to confirm the sending of the IMMEDIATE ASSIGNMENT. The OsmoPCU already supports the method but OsmoBTS still have to be upgraded.</p>
<p>The related PCU/BTS TTCN3 tests also require an update.</p> OsmoBTS - Bug #5688 (Resolved): osmo-bts-sysmo and osmo-bts-trx use different GSM-HR RTP packet f...https://projects.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://projects.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://projects.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://projects.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://projects.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> OsmoMGW - Feature #4841 (Stalled): TC_e1_crcx_and_dlcx_ep does not pass - move the IPA code out o...https://projects.osmocom.org/issues/48412020-11-02T23:27:39Zdexter
<p>The testcase TC_e1_crcx_and_dlcx_ep can not be executed correctly because it requires a running osmo-e1d but in order to have this available in jenkins this would mean that we need to build the related debian packages with osmo-e1d support, which then creates an impractical dependency to osmo-e1d.</p>
<pre>
The proper solution is to move the IPA code out of libosmo-abis. Historically that made sense,
as the IPA multiplex was first encountered in Abis. But then it was also present in SCCPlite,
we started using it for GSUP, and most recently for RSPRO in osmo-remsim.
This now means that virtually all osmocom projects depend on libosmo-abis, while all they want
is the IPA abstraction.
Adding osmo-e1d support to libosmo-abis creates another dependency, and I rally do not want
to have to exlpain to an osmo-remsim user why he needs to install an E1 interface driver
if he wants to have remote sim functionality.
So my plan was to see if we can untangle this somehow without spending two weeks of time on it,
and then re-enable the dependency of libosmo-abis to osmo-e1d once nobody (except osmo-mgw
and osmo-bsc) depend on libosmo-abis anymore.
</pre>
<p>See also <a class="issue tracker-2 status-3 priority-3 priority-high3 closed behind-schedule" title="Feature: Add E1/T1 endpoint type to osmo-mgw (Resolved)" href="https://projects.osmocom.org/issues/2547">#2547</a></p> OsmoBSC - Bug #4752 (Resolved): TC_ho_int does not passhttps://projects.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://projects.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>