Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-07-10T20:22:57ZOpen Source Mobile Communications
Redmine 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> 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> 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> 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 #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> 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> 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> 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> libosmocore - Bug #2613 (Closed): vty crashes on tab-completionhttps://osmocom.org/issues/26132017-11-02T16:11:14Zdexter
<p>The problem is located in libosmocore, so it exists in all our products. It<br />looks like it is somehow liked to the tab-completion. The problem can be<br />triggered for example by logging into a vty and try to tab-complete some<br />items of the help menu, it seems to bail at the second level of tab completion.</p>
<pre>
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Welcome to the osmo-stp control interface
Copyright (C) 2015-2017 by Harald Welte <laforge@gnumonks.org>
Contributions by Holger Freyther, Neels Hofmeyr
License GPLv2+: GNU GPL Version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free ot change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Free Software lives by contribution. If you use this, please contribute!
osmo-stp>
show Show running system information
list Print command list
exit Exit current mode and down to previous mode
help Description of the interactive help system
enable Turn on privileged mode command
terminal Set terminal line parameters
who Display who is on vty
logging Configure log message to this terminal
osmo-stp> h
osmo-stp> help
</pre>
<p>Attached the logtext including backtrace.</p> libosmocore - Feature #2587 (Closed): helper function to finde the right interface for a remote I...https://osmocom.org/issues/25872017-10-20T14:48:40Zdexter
<p>In some cases (mgcp-gw) it is important to know the IP-Address of the interface through which a remote IP-Address is reachable. This can be done using the syscalls connect() and getsockname(). Implement a helper function in socket.c that takes a remote ip-address as input and outputs the coresponding local interface</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> OpenBSC - Bug #2424 (Closed): use osmo_sccp_addr_set_ssn() in osmo-bschttps://osmocom.org/issues/24242017-08-07T15:14:20Zdexter
<p><a class="external" href="https://gerrit.osmocom.org/#/c/3359/">https://gerrit.osmocom.org/#/c/3359/</a> is still in review, use the provided function osmo_sccp_addr_set_ssn() as soon as it is merged.</p> libosmo-sccp + libosmo-sigtran - Feature #2417 (Closed): function to check sccp-addresseshttps://osmocom.org/issues/24172017-08-01T10:37:29Zdexter
<p>sccp-addresses consist of a number of components. A presence bitmask denotes if a component has a valid value or not. Add a function that checks the presence field against a given value. Also check if the values fall into the correct range, so that a malformed sccp-address is detected early.</p> libosmo-sccp + libosmo-sigtran - Bug #2381 (Closed): function to automatically generate a local S...https://osmocom.org/issues/23812017-07-20T08:27:17Zdexter
<p>In some cases it would be very helpful if the user could just ask the sccp API for a local address. Such an address can be derived from the configuration data we have set for the CS7 instance via VTY.</p> libosmo-sccp + libosmo-sigtran - Bug #2376 (Closed): search for an sscp-address and return ss7 in...https://osmocom.org/issues/23762017-07-19T08:09:09Zdexter
<p>By the current API definition, the user can limit the search range to a specific ss7 instance (if that instance is known). When the given ss7 instance pointer is NULL, the global list is searched. This scheme will be changed to:</p>
<p>When searching, always the global list is searched. If found, the address will be copied to the pointer which the caller has issued. We will also return the pointer to the ss7 instance. A returned NULL pointer indicates that the entry was not found. By creating a copy of the addressbook entry we also prevent that the caller might change the address data in the addressbook. The only legal way to change addressbook entries is the VTY.</p>
<p>The API should look like this:</p>
<p>struct osmo_ss7_instance *osmo_sccp_addr_by_name(const char *name, struct osmo_sccp_addr *dest);</p>
<p>const char *osmo_sccp_name_by_addr(const struct osmo_sccp_addr *addr);</p> libosmo-sccp + libosmo-sigtran - Bug #2375 (Closed): enforce unique names in sccp-addressbookhttps://osmocom.org/issues/23752017-07-19T07:56:56Zdexter
<p>Each sccp-addressbook entry is referenced by a name. Make sure that a name can not be used twice.</p>
<p>Inside a single ss7 instace, reusing a name twice is not possible, but a user could use the same name twice in different ss7 instance. This situation mus be prevented.</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 #2351 (Closed): unify sccp instance configurationhttps://osmocom.org/issues/23512017-07-06T09:41:55Zdexter
<p>The configuration of the sccp instance can be unified. The parameters of osmo_sccp_simple_client() which is used to create the sccp instance could be configured using the built in VTY of libosmo-sccp. This would unify the configuration of SCCP and offload the application specific VTY. It also would help to simplify the configuration from the users perspective. The user will not have to learn a new way to configur SS7 applications all the time.</p>
<pre>
struct osmo_sccp_instance *
osmo_sccp_simple_client(void *ctx, const char *name, uint32_t pc,
enum osmo_ss7_asp_protocol prot, int local_port,
const char *local_ip, int remote_port, const char *remote_ip);
</pre> libosmo-sccp + libosmo-sigtran - Bug #2345 (Closed): VTY: Check returncode of osmo_ss7_pointcode_...https://osmocom.org/issues/23452017-06-30T13:50:30Zdexter
<p>The function osmo_ss7_pointcode_parse() may yield -EINVAL as result. Make sure that if this is the case, the result will not be used and a CMD_WARNING is returned.</p> libosmo-sccp + libosmo-sigtran - Bug #2328 (Closed): sccp-address nodeshttps://osmocom.org/issues/23282017-06-15T10:04:54Zdexter
<p>the SCCP level addresses. Unfortunately a SCC (called|calling) party<br />address is rather complex and hence it cannot easily be supplied by a<br />single VTY command. My idea is thus to add 'sccp-address' nodes,<br />where one can specify a SCCP address like this:</p>
<pre><code>sccp-address my-bsc-addr<br /> routing-indicator 1<br /> point-code 2.3.1<br /> subsystem-number 253<br /> global-title<br /> gti 4<br /> digits 2342<br /> ...</code></pre>
<p>The above vty code would become part of libosmo-sigtran, and the<br />BSC/MSC then can simply have a single vty line like<br />"bsc sccp-address my-bsc-addr" <br />and then call a function that resolves this address by it's<br />string-name "my-bsc-addr"</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>