Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-11-23T10:42:26ZOpen Source Mobile Communications
Redmine 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> 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> OsmoSGSN - Feature #6050 (Closed): Add missing testcase to test GERAN originated RIM RAN informat...https://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 #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> 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> OsmoBSC - Bug #3864 (Resolved): Do not execute S15-S0 related tests in ttcn3-bsc-test-sccplitehttps://osmocom.org/issues/38642019-03-26T16:48:58Zdexter
<p>The information element that contains S15-S0 is not present in sccplite, therefore it does not make sense to execute the related tests in ttcn3-bsc-test-sccplite. Those tests should be disabled here</p> OsmoBTS - Support #3863 (Stalled): setup testing of osmo-bts-oc2g on real hardware with ttcn3 and...https://osmocom.org/issues/38632019-03-26T16:21:06Zdexter
<p>In order to be able to debug problems with automatic interop testing a local instance of an osmocom-bb phone and BTS is required. TRXCONT/FAKETRX are exchanged with a real BTS/PHONE.</p> 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 #3843 (Resolved): clean up sending of OML failure event reportshttps://osmocom.org/issues/38432019-03-15T12:41:11Zdexter
<p>When osmo-bts sends a failure event report to the BSC either a signal to SS_FAIL is dispatched or the function oml_fail_rep() is called. There should be only one way to send failure event reports. Dispatching a signal seems to complicated for the task.</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> OsmoBSC - Bug #3548 (Resolved): COMPLETE LAYER 3 INFORMATION does not contain Codec List (BSS Sup...https://osmocom.org/issues/35482018-09-12T09:13:01Zdexter
<p>3GPP TS 48.008 3.2.1.32, COMPLETE LAYER 3 INFORMATION clearly states that the information element Codec List (BSS Supported) must be included when AoIP is used. "Codec List (BSS Supported) shall be included, if the radio access network supports an IP based user plane interface."</p>
<p>The lack of the mentioned information element may cause interop problems with thrid party MSCs.</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> pySim - Bug #3376 (Resolved): create test scripts to verify pysim-prog ans sysmo-usim-tool with j...https://osmocom.org/issues/33762018-07-04T09:01:19Zdexter
<p>At the moment pysim, nor sysmo-usim-tool does have integration tests on jenkins. Especially for pysim-prog.py this is a problem. pysim-prog.py supports various types of simcards now and its becoming hard to check every single one of them during development. We need a script that can automatically verify various card types.</p>
<p>The setup should consist of multiple physical cards and readers. The script then should execute a test write/read operation on each of the cards.</p>
<p>For sysmo-usim-tool the task is similar but with the exception that only one card type is checked and the script can be much simpler</p> OsmoMSC - Bug #3266 (Resolved): CM Service reject with wrong cause-codehttps://osmocom.org/issues/32662018-05-15T13:23:26Zdexter
<p>When the msc reboots all MS get implicitly detached. On the next CM SERVICE REQUEST the MS will get a CM SERVICE REJECT and by the cause code it knows that it has to perform a LOCATION UPDATE in order to get detached again. Unfortunately the cause code that the MSC returns with the CM SERVICE REJECT (GSM48_REJECT_MS_IDENTITY_NOT_DERVIVABLE = 9) is incorrect because this is a cause code from the GMM domain and is interpreted GSM48_REJECT_SRV_OPT_TMP_OUT_OF_ORDER by the MS, which also will not do any location update then.</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> 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> 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> OsmoMGW - Bug #2598 (Closed): Choose correct interface/ip automaticallyhttps://osmocom.org/issues/25982017-10-27T11:11:27Zdexter
<p>If we run osmo-mgw in a setup where RTP streams are switched through more than a single interface will run into a problem. On startup osmo-mgw gets a statically configured IP-Address via VTY config. This IP-Address is returned with every MDCX/CRCX response. This works fine as long as all RTP traffic is passing through the configured interface.</p>
<p>In cases where a client tries to switch an RTP stream through an interface different from the configured one osmo-mgw still (binds to and) returns the IP-Address that has been configured. The problem is that the other side will then try to send the RTP traffic to that IP-Address, which will fail.</p>
<p>(e.g. osmo-mgw is bound to 1.1.1.1, 1.1.1.1 will be returned with any CRCX or MDCX, even when the remote host is connected through the interface with IP 2.2.2.2)</p>
<p>A solution could be to determine the correct interface/ip automatically. Then we could (bind to and) return the IP oft the interface that actually points to the remote side. All information we would need to do this is the IP-Address of the remote side. Then we can use osmo_sock_local_ip() from libosmocore to determine the IP we have to use.</p>
<p>However, this only works well if we can get the IP-Address of the remote side early with a CRCX message. Luckily this is the case with osmo-bsc, there we do a single phased connection assignment (one CRCX with remote IP, one response with local ip). For the other cases where we do not get the remote end IP with the CRCX we must fall back to the configured IP address.</p> OsmoSGSN - Bug #2585 (Closed): build osmo-sgsn without libosmo-sigtranhttps://osmocom.org/issues/25852017-10-20T09:25:33Zdexter
<p>In its current state osmo-sgen depends on libosmo-sigtran even if it is not build for IU (3G-Support).</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> OsmoMGW - Feature #2516 (Resolved): automatic testing of osmo-mgw / jenkins integrationhttps://osmocom.org/issues/25162017-09-18T21:45:01Zdexter
<p>Currently we test osmo-mgw with unit tests. It might make sense to run some more realistic tests. The idea is to start osmo-mgw in a testrig that then makes test connections and sends test data. The testrig could be a python program or even a TTCN3 test.</p>
Some ideas:
<ul>
<li>Send command (e.g. CRCX) and inspect resulting internal states via VTY also check response for plausibility</li>
<li>Send odd command sequences, check if the expected error codes are generated.</li>
<li>Send malformed messages or incomplete messages, check if the expected error codes are generated</li>
<li>Create a full connection, send RTP packets through, check if the RTP packets take the right path</li>
<li>Create a loopback connection, send RTP packets, check if the packets are reflected correctly</li>
</ul> OpenBSC - Feature #2396 (Closed): Comfortable CS7/SS7 VTY configuration for osmo-bsc and osmo-mschttps://osmocom.org/issues/23962017-07-24T19:54:54Zdexter
<p>osmo-msc and osmo-bsc currently lack important SS7 related VTY configuration features. Add proper VTY configuration commands to both applications</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> OsmoMSC - Bug #2348 (Closed): AoIP: garbled RTP in call following a call to an unreachable subscr...https://osmocom.org/issues/23482017-07-03T20:14:14Zdexter
<p>There is a problem somewhere in the call control, probably also connected to MGCP. The problem succours very rarely, but it can be provoked by doing the following:</p>
<p>1) Make a call to an unreachable subscriber</p>
<p>2) Make a call to a reachable subscriber</p>
<p>The other phone will ring. When picked up on the calling phone playing a metallic noise sound (garbeled RTP traffic).</p>
<p>The problem needs to be investigated further. It might be a race condition between the connection that is still open from the failed call and the new established connection.</p>
<hr />
<p>In a_iface.c, see a_iface_tx_dtap(), the link_id is permanently set to 0x00. Looks like a candidate for the cause of the problem.</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>