Bug #4180
closedRegression in osmo-ttcn3-hacks broke f_bssgp_wait_ul_ud()
100%
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.
Related issues
Updated by osmith over 4 years ago
- Related to Bug #3925: Missing PCU_Tests.ttcn UL TBF tests added
Updated by osmith over 4 years 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.
Updated by osmith over 4 years 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
Updated by osmith over 4 years 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:
Updated by osmith over 4 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100