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> OsmoMGW - Feature #6171 (In Progress): mgcp-client API: there should be a separate mgcp_codec_par...https://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://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://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> OsmoSGSN - Feature #6139 (New): test mobility between GERAN (OsmoPCU) and EUTRAN (Open5GS) end to...https://osmocom.org/issues/61392023-08-22T09:55:50Zdexter
<p>The mobility features that we recently added to Open5GS and OsmoPCU were developed and tested against TTCN3 testsuites, but we didn't confirm the functionality on real hardware yet.</p>
<p>To do this we need to create a setup with an OsmoBTS/OsmoPCU based GERAN cell and an appropriate EUTRAN ENB that is controlled by Open5GS. In order to be able to trigger the cell change it may be required to equip the transmittig antennas of both radios with variable attenuators.</p> 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> 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> pySim - Feature #5976 (New): pySim-prog: do not program linked files multiple timeshttps://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://osmocom.org/issues/5830">#5830</a>)</p> OsmoPCU - Feature #5930 (New): handle multiple BTSs with one PCUhttps://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> 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> 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> OsmoBSC - Bug #3833 (Resolved): Fix storage location of AMR S15-S0 bitshttps://osmocom.org/issues/38332019-03-11T17:44:34Zdexter
<p>The current storage location of s15_s0 (lchan->activate.info.s15_s0) is incorrect by the current memory model. This should be fixed by finding a proper storage location that fits into the current memory model.</p>
<p>See also:<br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/13200/">https://gerrit.osmocom.org/#/c/osmo-bsc/+/13200/</a><br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039/">https://gerrit.osmocom.org/#/c/osmo-bsc/+/13039/</a></p> 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> OpenBSC - Bug #3657 (Resolved): fix support for non voice configurationhttps://osmocom.org/issues/36572018-10-16T13:32:46Zdexter
<p>At the moment osmo-bsc does not permit non voice configurations. A valid voice codec configuration must be in place, otherwise the COMPLETE LAYER 3 INFORMATION message generation will fail because the SPEECH CODEC LIST (BSS supported) IE can not be generated. The speech codec list is a mandatory IE, but only if the network supports an IP based user plane interface. In networks that intentionally do not support voice, it could be garmented that those networks do not have such an interface and therefore the inclusion of the speech codec list is not needed. Also a speech codec list with 0 elements is indeed permitted by the spec. We could also include a speech codec list with 0 elements for the non-voice configurations.</p> 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> libosmocore - Bug #3441 (Resolved): two processes can open the same UDP port without errorhttps://osmocom.org/issues/34412018-08-01T11:00:32Zdexter
<p>When two processes open a socket with the same UDP port there will be no error since we set SO_REUSEADDR also for UDP ports. This is dangerous and might lead into situations that are very difficult to debug. There is no point in setting SO_REUSEADDR for UDP ports since UDP is connection less and there can not be any lingering connections like with TCP.</p> Cellular Network Infrastructure - Bug #3384 (Resolved): Translate PT before sending RTP packets (...https://osmocom.org/issues/33842018-07-05T15:06:40Zdexter
<p>When dynamic payload types are used and the call-agent configures two connections with the same codec, but different payload type numbers then osmo-mgw must ensure that the RTP packets are sent with the correct payload type number. This means on the ingress connection the MGW must lookup the codec by the payload type number. On the egress connection the MGW must use the previously looked up codec to determine the matching payload type number that is configured for that codec on the egress connection.</p>
<p>We need: Payload-type number re-writing in osmo-mgw and a TTCN3 testcase that verifies this behavior.</p> OsmoBSC - Bug #3112 (Resolved): Clean up / fix osmo_bsc_filter.chttps://osmocom.org/issues/31122018-03-26T13:25:58Zdexter
<p>There are some leftovers from the time where osmo-bsc had an SCCPLITE/IPA based A interface. There is still an msc_con->is_connected and an msc_con->is_authenticated flag which is hard coded to 1. These flags are used by osmo_bsc_filter. Presumably the functionality in osmo_bsc_filter is presumably broken. We need to look into this and either fix it or remove it.</p>
<p>See also osmo_bsc_msc.c<br />data->msc_con->is_connected = 1;<br />data->msc_con->is_authenticated = 1;</p> osmo-sip-connector - Feature #2950 (Resolved): create OE-Package for osmo-sip-connectorhttps://osmocom.org/issues/29502018-02-16T15:20:42Zdexter
<p>It appears to be that osmo-sip-connector is not built as OE package, so it is not available for easy install on sysmoBTS or sysmoNITB. However, having osmo-sip-connector available on those platform would make sense.</p>
<p>Dependencies:<br />SOFIASIP, sofia-sip-ua-glib >= 1.12.0</p> OsmoBSC - Feature #2918 (New): Implement a function to properly test connection clearing in MSC_C...https://osmocom.org/issues/29182018-02-09T17:11:45Zdexter
<p>BSC_ConnectionHandler.ttcn implements a function to test proper connection clearing: f_expect_clear()</p>
<p>We should have an inverse pendant in MSC_ConnectionHandler.ttcn for the BSC tests as well. Here we will probably have two scenarios, the first is when the BSC asks the MSC to clear the connection and the second will be when the MSC instructs the BSC to clear the connection (regular case)</p> libosmocore - Bug #2915 (Resolved): FSM: Do not terminate child FSMs earlyhttps://osmocom.org/issues/29152018-02-09T11:35:35Zdexter
<p>When an FSM is terminated _osmo_fsm_inst_term() first terminates the child FSMs and then executes the cleanup callback of the respective FSM. This prevents the FSM to perform actions on its children while it is terminated. Eventually this behavior prevents a graceful exit of the child FSMs. The parent FSM should always be able to signal last actions to its child FSMs before the final termination happens.</p>
<p>The patch that got merged recently caused unexpected fallout on the unit-tests of osmo-msc and had to be reverted:</p>
<p><a class="external" href="https://gerrit.osmocom.org/6318">https://gerrit.osmocom.org/6318</a></p>
<p>Manual tests on the test-network (includes osmo-bsc, osmo-msc, osmo-hlr, osmo-stp and osmo-mgw) did not reveal any behavioral difference. Also the TTCN3 testsuit for the BSC did not show any sign of problems caused by the patch. However, the fallout needs to be investigated and we need to check if it actually changes behavior or or if it just changes the position of some log-lines (expected, cleanup_cb now runs before the child termination).</p>
<p>Attached one finds a patch that shows the difference of the changed log-output of the test (.err).</p> OsmoMGW - Feature #2580 (New): implement timeout/resend mechanism for mgcp_clienthttps://osmocom.org/issues/25802017-10-17T16:28:03Zdexter
<p>At the moment mgcp_client sends the the message out and waits for the response, when the response is received, then a the result is returned through a callback. If no response is received (e.g. packet loss), then simply nothing happens. It would be very helpful if the message gets resend after some time.</p>
<p>Each mgcp_message has a unique ID-Number and osmo-mgw is able to handle resend messages. So if the message was received osmo-mgw, but the response got lost on its way to the client, a resend would not hurt. We only need to upgrade the mgcp_client to resend messages after some timeout in case no response is received.</p> OsmoSGSN - Bug #2501 (In Progress): suspected problem with unanswered neighbor solicitationhttps://osmocom.org/issues/25012017-09-07T12:20:44Zdexter
<p>getting and using an IPV6 pdp context has been tested successfully using a<br />samsung galaxy S2, but tests with a Getnord ONYX fail.</p>
<p>In the failure case, the PDP-Context is opened successfully, also the following<br />interactions look good. Except that the pdp context is closed by the phone a<br />shortly after it had been established. The dactivation cause is a regular<br />deactivation.</p>
<p>When comparing the two traces it is distinctive, that the trace from the<br />getnord does contain a neighbor solicitation request. This request seems to be<br />ignored by the GGSN. It is likely that the getnord mobile interprets this as<br />a failure and then closes the pdp context.</p>
<p>The traces of the two cases are attached to this ticket.</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> libosmo-sccp + libosmo-sigtran - Bug #2259 (New): problem with local referencehttps://osmocom.org/issues/22592017-05-16T13:05:55Zdexter
<p>When a connection attemt (local reference = 2) is made, libosmo-sccp complains with "<000d> sccp_scoc.c:1528 Cannot find connection for local reference 2". Current master is at 872c6b2a8e309ca6739ef295f1fc468c189e4ec9. The problem seems to be introduced with commit 5527df78adc08b76df07c4b682263b5bdd6181d4 (libosmo-sccp.git). When the commit is reverted, the correct functionality of libosmo-sccp seems to be restored.</p>
<p>The problem can be demonstrated by using the client/server example that is shipped with libosmo-sccp. The following VTY-Commands were used to trigger the problem:</p>
<pre>
enable
sccp-user
called-addr-ssn 202
connect-req 2 hello
</pre>
<p>Note: In the good case I can see the normal CR with payload attached and the CC that with the payload that is echoed by the the echo subsystem. The bad case results in an CREF message, which contains an refusal cause code 0x0F (unqalified)</p> libosmocore - Bug #1938 (Resolved): lapd_core human readable connection IDs in debug loghttps://osmocom.org/issues/19382017-02-03T11:31:12Zdexter
<p>At the moment we print the pointer address to identify the log lines belonging to a specific connection. Since pointer addresses are difficult to work with, a human readable ID should be printed instead.</p>
<p>e.g. "This is LAPD instance for SAPI3 on bts0/trx1/ts5/lchan3"</p>
<p>This can be implemented by adding a string member to the lapd_datalink struct. The user would set the string to a human readable identifier when the link is created. (See also osmo_fsm).</p>
<p>See also: <a class="external" href="https://gerrit.osmocom.org/#/c/1724/">https://gerrit.osmocom.org/#/c/1724/</a></p>