Project

General

Profile

Actions

Bug #3286

closed

TC_cr_before_reset fails since build #148 (May 16)

Added by laforge almost 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
05/23/2018
Due date:
% Done:

60%

Resolution:
fixed
Spec Reference:
Tags:

Description

MSC_Tests.TC_cr_before_reset appears to be failing since May 16:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/148/

This was just around the time when I8e489eb494d358d130e51cb2167929edeaa12e92 ("a_reset: cleanup + remove dead code") was merged, so that may have had some impact on it?


Files

archive.zip archive.zip 1.17 MB dexter, 05/25/2018 01:10 PM
with_f_sleep.pcapng with_f_sleep.pcapng 1.07 KB dexter, 05/25/2018 01:34 PM
without_f_sleep.pcapng without_f_sleep.pcapng 480 Bytes dexter, 05/25/2018 01:34 PM

Related issues

Related to OsmoMSC - Feature #3103: use a_reset.c in osmo-mscResolveddexter03/23/2018

Actions
Actions #1

Updated by laforge almost 6 years ago

Actions #2

Updated by dexter almost 6 years ago

I have tried to pinpoint the problem. Unfortunately I can not exactly say what it is. The problem is reproducible with docker, but not with my normal setup on my workstation. When I add an f_sleep(10) at the beginning of TC_cr_before_reset() the testcase passes.

In the build artifacts (MSC_Tests.TC_cr_before_reset.pcap) I see only the messages from TTCN3, but not from the MSC, but in osmo-msc.log I can see that the MSC receives the messages from TTCN3 correctly. I can see the connection attempt and the BSSMAP RESET. Also the log says that the BSSMAP RESET ACK is sent out.

Tue May 22 04:33:08 2018 DBSSAP <0010> a_iface.c:138 The calling BSC (RI=SSN_PC,PC=0.24.1,SSN=BSSAP) is unknown to this MSC ...
Tue May 22 04:33:08 2018 DBSSAP <0010> a_iface.c:457 Adding new BSC connection for BSC RI=SSN_PC,PC=0.24.1,SSN=BSSAP...
Tue May 22 04:33:08 2018 DBSSAP <0010> a_iface_bssap.c:110 Rx BSSMAP RESET from BSC RI=SSN_PC,PC=0.24.1,SSN=BSSAP, sending RESET ACK

To me this looks like a race condition that causes a communication problem between MSC and TTCN3. However, I am really confused to see messages arriving at the MSC because when I check the trace (without_f_sleep.pcapng) I see only the messages from TTCN3 to the STP, but do not see any egress messages going from the STP to the MSC. With the f_sleep(10) the trace looks normal (with_f_sleep.pcapng).

Note: We do not expect the MSC to respond to the CR with an BSSMAP RESET since the BSSMAP RESET from TTCN3 arrives so quickly at the RESET FSM inside the MSC does not get to the point where it sends its BSSMAP RESET. This is fine so far.

Actions #3

Updated by dexter almost 6 years ago

  • Status changed from New to Feedback
  • Assignee changed from dexter to laforge
Actions #4

Updated by laforge almost 6 years ago

  • Tags set to TTCN3
Actions #5

Updated by laforge over 5 years ago

  • Status changed from Feedback to Stalled
  • Assignee changed from laforge to dexter

I'm not really able to produce any feedback here. I suggest you dig deeper and possibly ask daniel for some help, he's been doing great work in finding TTCN3 related race conditions recently.

Actions #6

Updated by daniel over 5 years ago

  • Status changed from Stalled to In Progress
  • Assignee changed from dexter to daniel
  • % Done changed from 0 to 60

It seems the f_init_bssap_direct call needs an f_bssap_start in order for the BSSAP messages to reach the MSC.

Actions #8

Updated by daniel over 5 years ago

  • Status changed from In Progress to Resolved
  • Resolution set to fixed

Merged now

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)