Project

General

Profile

Bug #3639

TC_assignment_sign, TC_ciph_mode_a5_0, TC_ciph_mode_a5_1, TC_ciph_mode_a5_3 do not pass in the sccp-lite testsuite

Added by dexter 10 days ago. Updated 10 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
10/09/2018
Due date:
% Done:

90%

Spec Reference:

Description

There is a regression with the following tests:

TC_assignment_sign
TC_ciph_mode_a5_0
TC_ciph_mode_a5_1
TC_ciph_mode_a5_3

This needs to be fixed.

History

#1 Updated by dexter 10 days ago

  • Status changed from New to In Progress

#2 Updated by laforge 10 days ago

Please note it appears to only be a regression in the SCCPlite case?

#3 Updated by dexter 10 days ago

  • Subject changed from TC_assignment_sign, TC_ciph_mode_a5_0, TC_ciph_mode_a5_1, TC_ciph_mode_a5_3 do not pass to TC_assignment_sign, TC_ciph_mode_a5_0, TC_ciph_mode_a5_1, TC_ciph_mode_a5_3 do not pass in the sccp-lite testsuite

The problem is now fixed, however one of the main problem was that MSC_ConnectionHandler does not really know if AoIP or sccplite style messages should be used. During f_establish_fully() this is decided by looking at the CIC parameter in the assignment command. If it present sccplite is assumed. However, this is not a very good pivot point to check since for signalling channels no CIC is present anyway. I think we need an explicit setting that determines if AoIP style messages or sccpplite messages are expected.

The following patch adds an aoip flag and makes sure that it is set properly. I made sure to test this with the testsuite for Aoip and sccplite.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11289 MSC_ConnectionHandler: Use explicit AoIP flag

#4 Updated by dexter 10 days ago

  • % Done changed from 0 to 90

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)