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> pySim - Bug #6278 (Resolved): fix sending of raw APDUshttps://osmocom.org/issues/62782023-11-29T12:12:50Zdexter
<p>There is a problem when sending raw APDUs to cards that are not provisioned yet. The scc (SimCardCommands) object seems to be missing for some reason.</p>
<pre>
$ ./pySim-shell.py -p 0
Using PC/SC reader number 0
Waiting for card...
Warning: Could not detect card type - assuming a generic card type...
Unsupported card type!
pySim-shell not equipped!
Welcome to pySim-shell!
(C) 2021-2023 by Harald Welte, sysmocom - s.f.m.c. GmbH and contributors
Online manual available at https://downloads.osmocom.org/docs/pysim/master/html/shell.html
pySIM-shell (no card profile)> apdu 0000000000
EXCEPTION of type 'AttributeError' occurred with message: ''SimCardBase' object has no attribute 'scc''
To enable full traceback, run the following command: 'set debug true'
pySIM-shell (no card profile)>
</pre> pySim - Bug #6271 (Resolved): do not execute a startup script on initialization errorshttps://osmocom.org/issues/62712023-11-23T10:42:26Zdexter
<p>When there is an error at initialization (e.g. card is not present) and a startup script is passed with the command line option, then the script will execute anyway. This cause a lot of unnecessary error messages and confusion. pySim-shell should not continue executing a starup script when there were initialization errors!</p> OsmoBSC - Bug #6159 (New): use paging queue for PAGING messages that come from the BSC co-located...https://osmocom.org/issues/61592023-08-30T12:38:17Zdexter
<p>When a BSC co-located PCU sends a PAGING message to the BSC via PCUIF, then this message is forwarded immediately via RSL as RSL PAGING COMMAND. This illegally circumvents the paging queue of OsmoBSC. The PAGING messages from the PCU should take the route through the paging queue like any other paging does.</p> OsmoBTS - Bug #6142 (Resolved): channels are opened, but nothing happens, sometimes strange DTAP ...https://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> 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> OsmoMSC - Bug #4214 (Resolved): Also accept messages with unknown TLV Information elementshttps://osmocom.org/issues/42142019-09-24T09:22:37Zdexter
<p>3GPP TS 29.118, chapter 7.5 states: "The receiving entity shall ignore all information elements unknown or unforeseen in a message." Unfortunately we currently send a STATUS message back and ignore the message. This is not as the standard specifies.</p> OsmoMSC - Bug #3959 (Resolved): Extranous SGsAP-PAGING-REQUEST after MT CSFB call (TC_sgsap_lu_an...https://osmocom.org/issues/39592019-04-25T11:47:59Zdexter
<p>There is an SGsAP-PAGING-REQUEST visible just after the CSFB call is complete. This behaviour seems not to be catched by the testsuite, but it looks problematic. Attached one finds a trace from TC_sgsap_lu_and_mt_call</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> 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> 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 #3803 (Resolved): fix frame number calculation in scheduler_trxhttps://osmocom.org/issues/38032019-02-15T16:46:32Zdexter
<p>In rx_tchh_fn() and rx_tchh_fn() there is a formula used to calculate the frame number of the block that is passed up to the higher layers. The two functions collect a set of bursts and when complete, it is passed up. At the moment there are two indications generated when a block is completed. A measurement indication and a tch indication. Both should use the same fn. But the current implementation uses the stored *first_fn for the measurement indication and a formular that gets the fn of the last received block for the tch indication. Both seems to be incorrect because we need to take into account that TCH blocks are interleaved over 8 bursts. We need to tag each block with its starting frame number. To get this correct we need to check the formulas and make sure that the measurement indication and the tch indication use the same fn.</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> 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> OsmoGGSN (former OpenGGSN) - Bug #3319 (Resolved): also handle PCOs that contain primary and seco...https://osmocom.org/issues/33192018-06-04T20:25:53Zdexter
<p>On GTP level in the CREATE PDP CONTEXT message, one finds a field Protocol Configuration Options. This field contains among other info the primary and secondary DNS server address inside an IPCP container. Usually primary and secondary DNS are packed into on IPCP container. However it seems also to be legal to have primary and secondary DNS server in two separate IPCP container. At the moment the parser can only handle one IPCP container so we will loose the secondary DNS in the two-container case. We now have to extend the parser so that it handles IPCP containers flexible.</p>
<p>Attached one finds an example packet where primary and secondary DNS are in two separate IPCP containers.</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> OsmoMSC - Bug #3035 (Resolved): fix BSSMAP reset + add TTCN3 testcasehttps://osmocom.org/issues/30352018-03-06T09:08:22Zdexter
<p>There is a problem with the BSSMAP reset in osmo-msc. When osmo-msc receives BSSMAP data before reset it reaches a deadlock situation and the BSSMAP reset stops working properly. The problem has already been solved (see <a class="external" href="https://gerrit.osmocom.org/6840">https://gerrit.osmocom.org/6840</a>) but there is no TTCN3 test yet.</p> OsmoMSC - Bug #2777 (Resolved): Document that DTMF signalling does not work (with internal MNCC)https://osmocom.org/issues/27772017-12-21T19:11:17Zdexter
<p>The correct transmission of DTMF tones is currently not working. I have done a series of tests, here are the results:</p>
<ul>
<li>unsuccessful_ms_to_ms_dtmf_tone_(NG40).pcapng: Mobile to mobile DTMF tone signalling Start and stop of the DTMF tone is acknowledged. This looks good to my perspective, probably the DTMF forwarding is not properly configured inside the NG40 tester, otherwise I would expect to see the MSC at least trying to deliver the DTMF tones to the other mobile.</li>
</ul>
<ul>
<li>unsuccessful_ms_to_ms_dtmf_tone_with_external_mncc.pcapng: Here I can see the start command, which gets translated into a SIP message on the osmo-sip-connector. The tone also gets acknowledged and is stopped again. But again we see no response to the other MS whatsoever. This could also still be a problem with my PBX setup, since we would expect to see another SIP-Message that triggers the DTMF tone for the other MS.</li>
</ul>
<ul>
<li>unsuccessful_ms_to_ms_dtmf_tone_with_internal_mncc.pcapng: This trace was recorded with the internal MNCC active and really looks not ok. The DTMF tone gets actively rejected.</li>
</ul>
<ul>
<li>successful_ms_to_sip_dtmf_tone.pcapng: Here I see almost the same as in unsuccessful_ms_to_ms_dtmf_tone_with_external_mncc.pcapng, but the tone gets actually played on the other side. So I think sending DTMF tones should be fine, but receiving definetly has a problem.</li>
</ul>
<ul>
<li>When I press buttons on the sip phone actually nothing, not even a sip-message is transmitted. That also confirms that there may be problems with the PBX.</li>
</ul>
<p>However. I still wonder why the DTMF tones get rejected when osmo-msc is running on its internal MNCC. Something is definetly problematic there. The DTMF tone should travel back to the other end and not get rejected. I also attached the configuration files of osmo-bsc and osmo-msc. Maybe I am just lacking the right configuration options.</p> OsmoSGSN - Bug #2577 (Resolved): Ensure meaningful default loglevels.https://osmocom.org/issues/25772017-10-17T09:52:24Zdexter
<p>There are some loglevels configured to LOGL_DEBUG by default in osmo-sgsn. Find meaningful defaults and also check the other products.</p>
<p>(We should also add a test that checks if some application registers odd log levels by default.)</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>