Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-20T14:24:47ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #6411 (New): ttcn3: execute testsuites with a more realisti...https://osmocom.org/issues/64112024-03-20T14:24:47Zfixeria
<p>This idea by <a class="user active" href="https://osmocom.org/users/7">laforge</a> originates from <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://osmocom.org/issues/6375">#6375</a>: we should try running at least some of our BTS / BSC tests over an Abis link with simulated latency and non-zero packet loss. I did some experiments using tc-netem, running the whole ttcn3-bts-test with a simulated delay: <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://osmocom.org/issues/6375#note-14">#6375#note-14</a>. Let's continue discussing this here.</p> Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> OsmoBTS - Bug #5953 (Feedback): ttcn3-bts-test: TC_ms_pwr_ctrl_{constant,pf_ewma} are failinghttps://osmocom.org/issues/59532023-03-21T12:57:05Zfixeria
<p>These two testcases were added by me back in 2020 and have been passing until recently:</p>
<pre>
commit c7ef03057fe6644372b8bf08c165afef29fc600f
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:24:18 2020 +0700
BTS_Tests: introduce TC_ms_pwr_ctrl_constant()
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9052 BTS_Tests control part
BTS_Tests.ttcn:8111 TC_ms_pwr_ctrl_constant testcase
</pre>
<pre>
commit 652e60eb83f928036a649fa45f7a4a4eb8207eac
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:43:27 2020 +0700
BTS_Tests: add TC_ms_pwr_ctrl_pf_ewma: test EWMA based power filtering
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9053 BTS_Tests control part
BTS_Tests.ttcn:8178 TC_ms_pwr_ctrl_pf_ewma testcase
</pre>
<p>The "red age" of both TCs is 102 days ago for both -master and -latest.<br />I guess this might be related to the recent changes in osmocom-bb.git/trxcon.</p> OsmoBTS - Bug #5952 (New): ttcn3-bts-test: TC_ho_physical_info failshttps://osmocom.org/issues/59522023-03-21T12:35:13Zfixeria
<p>The testcase was added by me and is failing since the very beginning:</p>
<pre>
commit 1ab332ff86117e7aa22ca973993ea16bedbf63b7
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sat Mar 12 15:31:23 2022 +0300
BTS_Tests: add new test case TC_ho_physical_info
</pre>
<p>The problem is explained in the commit message:</p>
<pre>
Currently the new test case fails for several reasons:
* osmo-bts-trx starts transmitting on DCCH before the handover
Access Burst is received, this is wong;
* trxcon immediately starts sending dummy frames on Uplink
DCCH, causing osmo-bts to stop sendig RR Physical Info.
</pre> OsmoBTS - Feature #5025 (New): Missing TTCN-3 coverage for the Timing Advance loophttps://osmocom.org/issues/50252021-02-15T16:36:08Zfixeria
<p>As we figured out in <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Timing Advance loop is broken for SDCCH channels (Resolved)" href="https://osmocom.org/issues/5024">#5024</a>, there seems to be no TTCN-3 test case(s) for continuous Timing Advance control:</p>
<p>Harald Welte wrote:</p>
<blockquote>
<p>Regarding TTCN3 tests: We also only test the correct TA usage on initial channel establishment (BTS_Tests.TC_rsl_chan_initial_ta) and no tests yet for the TA loop during an active channel.</p>
</blockquote> osmo-gbproxy - Bug #4968 (Feedback): Multiple TTCN3 tests only expect one SGSNhttps://osmocom.org/issues/49682021-01-21T17:26:17Zdaniel
<p>There are various tests in TTCN3 that are not yet aware of SGSN-pooling. As such they usually just test that a message is forwarded to the first SGSN where we would expect it to be broadcast.</p>
<p>f_reset_ptp_bvc_from_sgsn() is a bit special and I'm not sure what to do here. Right now we expect the reset from one SGSN to be forwarded to the BSS. In that case we also need to reset the connection on the other SGSNs. Or we block the BVC to the other SGSNs and reset those connection as soon as the RESET-ACK from the BSS arrives at the gbproxy.</p>
<p>Couldn't we also locally answer the BVC-RESET?</p> OsmoBTS - Bug #4801 (Stalled): BTS_Tests.TC_tch_sign_l2_fill_frame_dtxd failshttps://osmocom.org/issues/48012020-10-11T19:52:01Zlaforge
<p>The tests fails with the sttement</p>
<pre>
TC_tch_sign_l2_fill_frame_dtxd(6)@nataraja: received only 2+0 (SACCH+other) out of 3 expected fill frames
MTC@nataraja: Test case TC_tch_sign_l2_fill_frame_dtxd finished. Verdict: fail reason: "BTS_Tests.ttcn:6675 : Not enough fill frames received"
</pre>
<p>So it seems like the SACCH in downlink is received, but the fill frames that should be sent by the related code in osmo-bts (<a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/10415">https://gerrit.osmocom.org/c/osmo-bts/+/10415</a>) are either not sent, or somehow lost, or not detected by the test case.</p> OsmoBTS - Bug #4023 (Stalled): Missing coverage of PCU interface in osmo-btshttps://osmocom.org/issues/40232019-05-24T20:19:52Zlaforge
<p>let's use this as a separate ticket from <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Extension of BTS_Tests.ttcn test coverage (Resolved)" href="https://osmocom.org/issues/3750">#3750</a> to provide a more verbose list of the tests related to the PCU interface</p> OsmoSGSN - Bug #3940 (New): TTCN-3: Iu: test UMTS Authhttps://osmocom.org/issues/39402019-04-18T14:21:20Zlynxis
<p>Test UMTS Auth on the Iu Interface via TTCN-3</p> OsmoSGSN - Bug #3939 (New): TTCN: do a GMM Attach Request when in GMM Connected and have a PDP Re...https://osmocom.org/issues/39392019-04-18T14:19:49Zlynxis
<p>When a GMM Attach Request is received for a <b>already</b> attached MS, the complete State of the MS should be reseted</p>
<pre>
Spec: 3GPP TS 24.008 version 13.7.0 Release 13
4.7.3.1.6 Abnormal cases on the network side
e) ATTACH REQUEST received in state GMM-REGISTERED
</pre> OsmoSGSN - Bug #3937 (In Progress): Iu: verify handling of GMM Service Request (data)when no PDP ...https://osmocom.org/issues/39372019-04-16T18:24:31Zlynxis
<p>What should the SGSN answer to GMM Service Request (type=data) when no PDP Context are active?<br />If there would be PDP Context, it should activate RAB Assignment Request to the RNC.</p>
<p>Should it ask the UE for the PDP Context Status and invalidate unknown PDP Contexts?<br />Should it sent GMM Service Reject?</p> OsmoPCU - Bug #3929 (New): Missing PCU_Tests.ttcn link adaptation testshttps://osmocom.org/issues/39292019-04-15T07:58:29Zlaforge
<p>We should have automatically executed tests that cover the link/rate adaptation, i.e. changes of CS/MCS based on [simulated] radio link performance.</p> OsmoPCU - Bug #3928 (Stalled): Missing PCU_Tests.ttcn for various timers / time-outshttps://osmocom.org/issues/39282019-04-15T07:57:37Zlaforge
<p>We should have automatically-executed tests that test the various RLC/MAC related timers and timeouts</p> OsmoPCU - Bug #3926 (Stalled): Missing PCU_Tests.ttcn DL TBF testshttps://osmocom.org/issues/39262019-04-15T07:55:21Zlaforge
<p>We should have a bunch of automatically executed tests in PCU_Tests.ttcn that cover DL TBF establishment</p> OsmoMGW - Bug #3731 (New): TTCN3 TC_rtpem_selftest randomly failshttps://osmocom.org/issues/37312018-12-13T12:37:31Zdaniel
<p>Every once in a while the osmo-mgw TTCN3 test TC_rtpem_selftest fails with "Received unexpected type from RTP"</p>
<p>Here are the relevant lines from the log:<br /><pre>
06:33:37.398872 75 RTP_Emulation.ttcn:341 entering f__IPL4__PROVIDER__listen: 127.0.0.1:10000 / UDP
06:33:37.399121 75 RTP_Emulation.ttcn:349 entering f__IPL4__PROVIDER__listen: 127.0.0.1:10001 / UDP
06:33:37.399174 75 RTP_Emulation.ttcn:357 Replied on CTRL to mtc @RTP_Emulation.RTPEM_bind : { local_port := 10000 }
[...]
06:33:37.399487 76 RTP_Emulation.ttcn:341 entering f__IPL4__PROVIDER__listen: 127.0.0.2:20000 / UDP
06:33:37.399810 76 RTP_Emulation.ttcn:349 entering f__IPL4__PROVIDER__listen: 127.0.0.2:20001 / UDP
06:33:37.399866 76 RTP_Emulation.ttcn:357 Replied on CTRL to mtc @RTP_Emulation.RTPEM_bind : { local_port := 20000 }
[...]
06:33:37.400095 75 RTP_Emulation.ttcn:365 entering f__IPL4__PROVIDER__connect: 127.0.0.1:10000 -> 127.0.0.2:20000 / UDP
06:33:37.400123 75 RTP_Emulation.ttcn:373 entering f__IPL4__PROVIDER__connect: 127.0.0.1:10001 -> 127.0.0.2:20001 / UDP
06:33:37.400139 75 RTP_Emulation.ttcn:381 Replied on CTRL to mtc @RTP_Emulation.RTPEM_connect : { }
[...]
06:33:37.400343 76 RTP_Emulation.ttcn:365 entering f__IPL4__PROVIDER__connect: 127.0.0.2:20000 -> 127.0.0.1:10000 / UDP
06:33:37.400368 76 RTP_Emulation.ttcn:373 entering f__IPL4__PROVIDER__connect: 127.0.0.2:20001 -> 127.0.0.1:10001 / UDP
06:33:37.400384 76 RTP_Emulation.ttcn:381 Replied on CTRL to mtc @RTP_Emulation.RTPEM_connect : { }
[...]
06:33:37.421230 75 RTP_Emulation.ttcn:303 Sent on RTP to system @RTP_CodecPort.RTP_Send : { connId := 1, msg := { rtp := { version := 2, padding_ind := '0'B, extension_ind := '0'B, CSRC_count := 0, marker_bit := '0'B, payload_type := 0, sequence_number := 0, time_stamp := '00000000000000000000000000000000'B, SSRC_id := '11011110101011011011111011101111'B, CSRCs := omit, ext_header := omit, data := '01020304'O } } }
06:33:37.421328 76 RTP_Emulation.ttcn:303 Sent on RTP to system @RTP_CodecPort.RTP_Send : { connId := 1, msg := { rtp := { version := 2, padding_ind := '0'B, extension_ind := '0'B, CSRC_count := 0, marker_bit := '0'B, payload_type := 0, sequence_number := 0, time_stamp := '00000000000000000000000000000000'B, SSRC_id := '11011110101011011011111011101111'B, CSRCs := omit, ext_header := omit, data := '01020304'O } } }
06:33:37.421404 75 RTP_Emulation.ttcn:303 Outgoing message was mapped to @IPL4asp_Types.ASP_Send : { connId := 1, proto := { udp := { } }, msg := '8000000000000000DEADBEEF01020304'O }
06:33:37.421443 76 RTP_Emulation.ttcn:303 Outgoing message was mapped to @IPL4asp_Types.ASP_Send : { connId := 1, proto := { udp := { } }, msg := '8000000000000000DEADBEEF01020304'O }
06:33:37.421561 76 RTP_Emulation.ttcn:462 Start timer T_transmit: 0.02 s
06:33:37.421578 75 RTP_Emulation.ttcn:303 Message enqueued on RTP from system @Socket_API_Definitions.PortEvent : { result := { errorCode := ERROR_SOCKET (4), connId := 1, os_error_code := 1, os_error_text := "Operation not permitted" } } id 1
06:33:37.421631 75 RTP_Emulation.ttcn:462 Start timer T_transmit: 0.02 s
06:33:37.421660 75 RTP_Emulation.ttcn:439 Matching on port RTP failed: Type of the first message in the queue is not @RTP_CodecPort.RTP_RecvFrom.
06:33:37.421674 75 RTP_Emulation.ttcn:470 Matching on port RTP succeeded.
06:33:37.421689 75 RTP_Emulation.ttcn:470 Receive operation on port RTP succeeded, message from system(): @Socket_API_Definitions.PortEvent: { result := { errorCode := ERROR_SOCKET (4), connId := 1, os_error_code := 1, os_error_text := "Operation not permitted" } } id 1
06:33:37.421705 75 RTP_Emulation.ttcn:470 Message with id 1 was extracted from the queue of RTP.
06:33:37.421723 75 RTP_Emulation.ttcn:471 setverdict(fail): none -> fail reason: "Received unexpected type from RTP", new component reason: "Received unexpected type from RTP"
</pre></p>
<p>Both sockets get bound and connected to each other, but the send on one of them then fails with -EPERM.</p>
<p>Not sure why this is going on here. It seems that trying to send a packet that is dropped through firewalling rules will result in -EPERM, but since this only happens once in a while I don't think that's it.</p>
<p>Maybe the fact that both sockets are on the same machine and trying to send to each other at the same time has something to do with it?</p> Cellular Modem Information - Feature #3658 (New): Create a "osmocom-bb-host-latest" docker containerhttps://osmocom.org/issues/36582018-10-16T14:11:32Zosmith
<p>The ttcn3-bts-test-latest jenkins job should use the "latest" version of everything that is used for the test.<br />But since there is no "latest" tag in the osmocom-bb.git repository, we can't build a osmocom-bb-host-latest docker image.</p>
<p>The current workaround is using osmocom-bb-host-master for ttcn3-bts-test-latest.</p> OsmoMSC - Feature #3620 (Stalled): Implement TTCN-3 testsuite for Inter-MSC HOhttps://osmocom.org/issues/36202018-10-02T18:23:34Zlaforge
<p>Implementation of TTCN-3 test cases as part of MSC_Tests.ttcn in osmo-ttcn3-hacks.git which emulate one external BSC and MSC to test basic and subsequent Inter-MSC hand-over of OsmoMSC.</p> OsmoBTS - Feature #3155 (Stalled): execute BTS_Tests.ttcn with real (C123) phone hardware in LTHW...https://osmocom.org/issues/31552018-04-10T16:28:12Zlaforge
<p>We want to execute the BTS_Tests.ttcn against all real hardware BTS models of our LTHW setup.</p>
<a name="Hardware-Setup"></a>
<h2 >Hardware Setup<a href="#Hardware-Setup" class="wiki-anchor">¶</a></h2>
On the hardware side, his means, we need to
<ul>
<li>add a C123 with RF cabling to the "modem ports" of the setup</li>
<li>be able to power cycle this C123 from software</li>
<li>attach the C123 UART via CP2103 USB-UART to the main unit</li>
</ul>
<a name="Software-Setup"></a>
<h2 >Software Setup<a href="#Software-Setup" class="wiki-anchor">¶</a></h2>
<p>We will need to be able to execute the BTS_Tests.ttcn on the gsm tester main unit. This could be done either natively or via the existing docker containers. In any case, we don't want to <strong>build</strong> the ttcn source on the low-power APU, but we want that the compiled test suite is copied/transferred to the APU and then executed there.</p>
<p>We also want to make sure that we have proper locking/exclusivity with the osmo-gsm-tester stack, so that we either run osmo-gsm-tester or BTS_Tests.ttcn.</p>
<p>Finally, this should all be started from jenkins.osmocom.org.</p>
<p>It probably makes sense (as usual) to start with the R&D setup and then replicate the setup in production.</p> OsmoBSC - Bug #3020 (New): OsmoBSC PCU socket interface not yet tested by BSC_Tests.ttcnhttps://osmocom.org/issues/30202018-03-01T16:34:00Zlaforge
<p>While the PCU socket of OsmoBTS alreasy has extensive test coverage in BTS_Tests.ttcn, we don't do any testing of the PCU socket in OsmoBSC from BSC_Tests.ttcn so far. This should change.</p> OsmoSGSN - Bug #2962 (New): Missing TTCN-3 test caseshttps://osmocom.org/issues/29622018-02-18T21:59:54Zlaforge
<p>let's collect the missing test cases here. IuPS has a separate ticket, so let's focus on [E]GPRS here.</p> OsmoSGSN - Bug #2958 (Stalled): OsmoSGSN doesn't authenticate on second/further ATTACH REQUESThttps://osmocom.org/issues/29582018-02-17T17:29:12Zlaforge
<p>When a new/unknown MS performs an ATTACH REQUEST for the first time, it is authenticated.</p>
<p>However, if that same MS later performs a second ATTACH REQUEST, even with new P-TMSI/TLLI, it is not authenticated and we simply send an ATTACH ACCEPT. This is a security problem, as it means anyone can impersonate other known-existing IMSIs.</p> OsmoGGSN (former OpenGGSN) - Feature #2946 (New): Add test suite for sgsnemuhttps://osmocom.org/issues/29462018-02-14T16:14:38Zpespin
<p>We should add some testing framework to check we don't break sgsnemu.</p>
<p>Some ideas:<br />- Run sgsnemu in one docker and osmo-ggsn in another one and see if we can create the pdp ctx and use ping (createif mode requires osmo-ggsn to be in separate net namespace for correct routing of packets).<br />- Create TTCN3 testsuite for sgsnemu.</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>