Project

General

Profile

Bug #4180

Regression in osmo-ttcn3-hacks broke f_bssgp_wait_ul_ud()

Added by osmith about 2 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
08/29/2019
Due date:
% Done:

100%

Spec Reference:

Description

Currently we have four ttcn3 tests in PCU_Tests.ttcn3, but we are not running them in jenkins yet. This patch broke these tests ("BSSGP_Emulation: Abandon "BssgpDecoded" intermediate structure"):

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/13865

With this patch, the following function in PCU_Tests.ttcn does not match the expected message anymore and runs into the timeout:

function f_bssgp_wait_ul_ud(template PDU_BSSGP exp) runs on dummy_CT {
    timer T := 5.0;
    T.start;
    alt {
    [] BSSGP[0].receive(exp) {
        log("found matching BSSGP UL-UNITDATA PDU");
        }
    [] T.timeout {
        setverdict(fail, "Timeout waiting for ", exp);
        mtc.stop;
        }
    }
}

It gets called like this:

    for (var integer i := 0; i < sizeof(us.tbf.llc_pdus_enc); i := i+1) {
        f_bssgp_wait_ul_ud(tr_BSSGP_UL_UD(g_mmctx.tlli, ?, us.tbf.llc_pdus_enc[i]));
    }

Log message as it fails to match:

16:19:03.049284 mtc PCU_Tests.ttcn:331 Matching on port BSSGP[0] failed: Type of the first message in the queue is not @BSSGP_Types.PDU_BSSGP.

The actual message is of type @MobileL3_Types.PDU_L3_MS_SGSN and looks like this:

16:23:31.232353 mtc PCU_Tests.ttcn:334 Receive operation on port BSSGP[0] succeeded, message from 4: @MobileL3_Types.PDU_L3_MS_SGSN: {
    discriminator := '0000'B,
    tiOrSkip := {
        skipIndicator := '0000'B
    },
    msgs := {
        gcc := '0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFE'O
    }
} id 4

Without the regression, the message looks like this:

16:07:08.144611 mtc PCU_Tests.ttcn:331 Receive operation on port BSSGP[0] succeeded, message from 4: @BSSGP_Emulation.BssgpDecoded : {
    bssgp := {
        pDU_BSSGP_UL_UNITDATA := {
            bssgpPduType := '01'O,
            tLLI := '59B5D42D'O,
            qoS_Profile := {
                peak_Bit_Rate := '0000'O,
                precedence := '100'B,
                a_bit := '0'B,
                t_bit := '0'B,
                c_r_bit := '0'B,
                peakBitRateGranularity := '00'B
            },
            cell_Identifier := {
                iEI := '08'O ("\b"),
                ext := '1'B,
...

So... the patch looks good, but I'm wondering what is missing to make it properly decode the message again, and return the right type.

lynxis, laforge: any idea?


Related issues

Related to OsmoPCU - Bug #3925: Missing PCU_Tests.ttcn UL TBF testsNew04/15/2019

History

#1 Updated by osmith about 2 months ago

  • Related to Bug #3925: Missing PCU_Tests.ttcn UL TBF tests added

#2 Updated by osmith about 2 months ago

#3 Updated by osmith about 2 months ago

The problem is in the f_send_bssgp_dec function:

private function f_send_bssgp_dec(BssgpDecoded dec, BSSGP_Client_CT vc_conn, BSSGP_SP_PT pt := BSSGP_SP) runs on BSSGP_CT {
    if (ispresent(dec.l3_mt)) {
        pt.send(dec.l3_mt) to vc_conn;
    } else if (ispresent(dec.l3_mo)) {
        pt.send(dec.l3_mo) to vc_conn;
    } else if (ispresent(dec.sndcp)) {
        pt.send(dec.sndcp) to vc_conn;
    } else if (ispresent(dec.llc)) {
        pt.send(dec.llc) to vc_conn;
    } else {
        pt.send(dec.bssgp) to vc_conn;
    }
}

When I change it to always send dec.bssgp, the test passes again:

private function f_send_bssgp_dec(BssgpDecoded dec, BSSGP_Client_CT vc_conn, BSSGP_SP_PT pt := BSSGP_SP) runs on BSSGP_CT {
    pt.send(dec.bssgp) to vc_conn;
}

I've tested that this change does not cause any breakage in the PCU and PCU-SNS testsuites, and now I'm testing whether it works with the SGSN testsuite too. If it does, I'll submit this as patch.

#4 Updated by osmith about 2 months ago

My proposed patch above breaks the SGSN tests, so that won't work. I'll try to find a better solution.

Meanwhile I found an unrelated bug in the "Abandon BssgpDecoded" patch and submitted a fix: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15348/1

#5 Updated by osmith about 2 months ago

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

laforge recommended to add a configurable encoding depth, and set it to the BSSGP layer for the existing PCU tests. This works and resolves this issue:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15377

#6 Updated by osmith about 2 months ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)