Project

General

Profile

Bug #2936

Fix TTCN3 Test BSC_Tests.TC_assignment_sign

Added by dexter 8 months ago. Updated 5 months ago.

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

100%

Spec Reference:
Tags:

Description

The Testcase BSC_Tests.TC_assignment_sign seems to behave incorrectly. It sends an Assignment Request where it requests a signaling only channel SDCCH. Osmo-bsc then decides that is already active is compatible and sends a Channel Mode Modify via RSL, which is never answered. The T10 timeout expires and the assignment fails.

From what I can see, the decision osmo-bsc makes is correct. Also the TTCN3 function f_channel_compatible(ass_cmd.pdu.bssmap.assignmentRequest.channelType, g_chan_nr) that is called from f_establish_fully() comes to the conclusion that the channel is compatible. I am currently lost in the altstep in at the end. I would expect it to continue with as_modify(st) but there I can see none of the steps processed.

From my understanding the behavior of osmo-bsc is correct and the TTCN3 testcase has some malfunction. Attached one finds a trace of the current behavior. See also branch: pmaier/fsm

trace.pcapng trace.pcapng 3.44 KB dexter, 02/12/2018 08:23 PM
20180510-sdcch_mode_modify.pcapng 20180510-sdcch_mode_modify.pcapng 4.13 KB pcap file showing OsmoBSC wants to modify signaling->signaling laforge, 05/10/2018 08:12 PM

History

#1 Updated by dexter 6 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 100

I think I managed to fix the problem. TC_assignment_sign now passes nicely on my side.

Unfortunately the testcase also had some problems. The first issue was that there was no g_pars assigned. There was only a local variable pars which was not used. This is fixed with:

https://gerrit.osmocom.org/7836 BSC_Tests: Assign g_pars in TC_assignment_sign

Also there was a problem with the guard statements in the altstep as_modify(). I am not entirely sure if my fix is correct but it looks plausible for me. Please have a look at:

https://gerrit.osmocom.org/7837 BSC_Tests: handle mode modify also for signalling

The problem on the osmo-bsc side was that the assignment complete message could not be generated because the function send_ass_compl() had no way to distinguish between an ASSIGNMENT COMPLETE for a voice channel and an ASSIGNMENT COMPLETE for a signalling channel. This is now fixed. I also removed some dead code (which is debatable)

https://gerrit.osmocom.org/7838 gscon: fix assignment of signalling channels
https://gerrit.osmocom.org/7839 gscon: remove dead code

The TTCN3 tests are not tested with docker since the modifications are minor and no changes to config files were made. However, I still need to upgrade the XML that models the expected results but I do not know how exactly to mask out the the runtime. Probably we have a commandline switch for that, or a script?

#2 Updated by dexter 6 months ago

  • % Done changed from 100 to 60

All the important patches got merged. However, there was some misunderstanding about the effect that the ASSIGNMENT COMMAND should have on the BSC side. Since we are already have a signalling channel assigned when we send the ASSIGNMENT COMMAND, we do not expect any MODE MODIFY activity on RSL level. The next we need to investigate is why osmo-bsc is performs the mode modify request despite we are already on a signaling channel.

#3 Updated by dexter 6 months ago

  • % Done changed from 60 to 80

osmo-bsc now checks if the channel mode modify is really necessary. If the mode matches already the desired mode, the modification of the channel is skipped and the ASSIGNMENT COMPLETE is sent back to the MSC right away:

https://gerrit.osmocom.org/8019 bsc_api/GSCON: prevent unnecessary channel mode modifys

The TTCN3 test does not pass yet, this is due to problems in f_establish_fully_ret(). the FSM that is modeled into the altstep expects st.modify_done set to true in order to accept the ASSIGNMENT COMPLETE. Normally this flag is set in as_modify(), but as_modify() is designed to only work with voice calls. We must add an exception here for this particular case, but I am afraid to mess up other testcases with that.

#4 Updated by dexter 6 months ago

The patch got merged, but the TTCN3 test still needs to get fixed.

When we set st.modify_done to true before entering the altstep we are able to accept an assignment complete without requiring to go through as_modify first. We may also think about altering the guard statement that guards the assignment complete.

The code checks if an assignment (RSL) is necessary or not. If the channel type is compatible with the requested service we may go through as_modify if the mode is different from the current channel mode. If the current channel mode is the same as the desired channel mode we expect an ASSIGNMENT COMPLETE on the A interface directly. as_modify is then omitted. I still wonder why as_modify only works on voice calls (?)

I think we need a check that can decide if a mode modify is necessary or not. I wonder if g_chan_nr or st can be used to determine the current channel mode.

#5 Updated by laforge 5 months ago

dexter wrote:

The patch got merged, but the TTCN3 test still needs to get fixed.

it makes sense to always address both at the same time, while the problem is still fully in one's head.

When we set st.modify_done to true before entering the altstep we are able to accept an assignment complete without requiring to go through as_modify first. We may also think about altering the guard statement that guards the assignment complete.

I'm not sure i fully understand, but any patches against the ttcn3 bsc test are welcome.

The code checks if an assignment (RSL) is necessary or not. If the channel type is compatible with the requested service we may go through as_modify if the mode is different from the current channel mode. If the current channel mode is the same as the desired channel mode we expect an ASSIGNMENT COMPLETE on the A interface directly. as_modify is then omitted.

I still wonder why as_modify only works on voice calls (?)

why would you modify any signaling channel? The assumption here is that every channel from the beginning on is first in signalling mode. If the channel is in signalling, and the new mode is also signalling, then there's no MODE MODIFY.

In fact, the current code (after your patch) still gets it wrong, as far as I can tell. If I'm on a SDCCH, and the MSC sends an ASSIGNMENT CMD (signaling), then OsmoBSC is still sending a MODE MODIFY command which wants to "modify" a channel that's already in signalling to signalling. The test case gets it right by not expecting a modify here.

I think we need a check that can decide if a mode modify is necessary or not. I wonder if g_chan_nr or st can be used to determine the current channel mode.

I think we need a check in OsmoBSC to make sure a MODE MODIFY is only sent when needed (old mode != new mode).

I'm working on a new set of testcases (BSC_Tests.TC_ciph_mode_a5_{0,1,3}) and they all fail for the unrelated reason that OsmoBSC is sending a MODE MODIFY where none is needed. See attached PCAP file.

#6 Updated by dexter 5 months ago

  • Priority changed from Normal to High

#7 Updated by dexter 5 months ago

  • Status changed from In Progress to Feedback
  • Assignee changed from dexter to laforge

I have a quick question about the BSC_Tests.TC_ciph_mode_a5_{0,1,3} testcases:

/* Establish signalling channel (non-assignment case) followed by cipher mode */
private function f_tc_ciph_mode_a5(charstring id) runs on MSC_ConnHdlr {
    var template PDU_BSSAP exp_compl := tr_BSSMAP_AssignmentComplete(omit, ?);
    var BSSMAP_IE_AoIP_TransportLayerAddress tla := valueof(ts_BSSMAP_IE_AoIP_TLA4('01020304'O, 2342));
    var template PDU_BSSAP ass_cmd := valueof(ts_BSSMAP_AssignmentReq(omit, tla));
    ass_cmd.pdu.bssmap.assignmentRequest.channelType := valueof(ts_BSSMAP_IE_ChannelTypeSIGNAL);

    // Disable generation of ASSIGNMENT CMD, as OsmoBSC currently performs MODE MODFIY sign->sign (OS#2936)
    //f_establish_fully(ass_cmd, exp_compl);
    f_establish_fully(omit, exp_compl);
}

I am a bit confused about the two f_establish_fully() at the end. Do we really call f_establish_fully() two times or is f_establish_fully(omit, exp_compl) replaced with f_establish_fully(ass_cmd, exp_compl) when the problem is fixed. I guess so since "omit" indeed disables f_establish_fully() almost completely.

#8 Updated by laforge 5 months ago

On Thu, May 17, 2018 at 04:41:13PM +0000, dexter [REDMINE] wrote:

I am a bit confused about the two f_establish_fully() at the end.

there was one that sent an assignment command, but it was commented out due to an OsmoBSC
but, and replaced with the 'omit' case that doesn't send an assignment command.

Do we really call f_establish_fully() two times or is f_establish_fully(omit, exp_compl) replaced with f_establish_fully(ass_cmd, exp_compl) when the problem is fixed.

We simply replace the currently not commented "f_establish_fully(omit, exp_compl);" with the
"f_establish_fully(ass_cmd, exp_compl);" after the bug is fixed in OsmoBSC.

#9 Updated by laforge 5 months ago

  • Status changed from Feedback to In Progress
  • Assignee changed from laforge to dexter

#10 Updated by dexter 5 months ago

I have now integrated a check into f_establish_fully() that checks if the mode modify is expected or not. For this I check the channel number to see if we are on a signalling channel or not. BSC_Tests.TC_assignment_sign now passes nicely without any modification.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9231 MSC_ConnectionHandler: check channel mode in f_establish_fully

Also I have now re-enabled the generation of the BSSMAP ASSIGNMENT. However, for some reason the ASSIGNMENT COMPLETE is expected to include an AoIP transport address, which I think is not correct for a signalling channel. Also the ASSIGNMENT COMMAND should not contain one. I have corrected this now and the test passes fine. No MODE MODIFY is generated or expected by the test.

See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9232 BSC_Tests: fix TC_ciph_mode_a5_{0,1,3}

(Correct me if I am wrong, but from what I can see osmo-bsc decides correct since change: I86a2d52836c54d2dbd77441b182f757327ec7262)

#11 Updated by dexter 5 months ago

  • % Done changed from 80 to 90

I have rebased the two patches to current master. The fix for TC_ciph_mode_a5_{0,1,3} had a merge conflict, this is now fixed again. The function f_channel_needs_modify() is not perfect yet. I have added the fixme note as discussed on gerrit.

See also:

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9231
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9232

#12 Updated by laforge 5 months ago

  • Tags set to TTCN3

#13 Updated by dexter 5 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

The patches are merged and the tests

TC_assignment_sign
TC_ciph_mode_a5_0
TC_ciph_mode_a5_1
TC_ciph_mode_a5_3

are passing. I think this can be closed.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)