Bug #4475
closedTC_paging_imsi_80percent + TC_paging_tmsi_80percent fail since 842 (March 28)
100%
Description
These two tests started failing from March 28 onwards:
The IMSI test case:
"BTS_Tests.ttcn:3051 : Expected 271 pagings but have 284" BTS_Tests.ttcn:6414 BTS_Tests control part BTS_Tests.ttcn:3051 TC_paging_imsi_80percent testcase
The TMSI test case:
"BTS_Tests.ttcn:3075 : Expected 543 pagings but have 553" BTS_Tests.ttcn:6415 BTS_Tests control part BTS_Tests.ttcn:3075 TC_paging_tmsi_80percent testcase
How can the number of expected pagings in a given time period have changed? It's not that we suddenly have more PCH capacity in downlink?
Updated by laforge almost 4 years ago
maybe this is related to:
commit d665c232371e0495a6d97f67101d825ddcc356a0 Author: Vadim Yanitskiy <axilirator@gmail.com> Date: Mon Mar 30 14:40:41 2020 +0700 BTS: fix as_l1_count_paging(): use ispresent() instead of isvalue() We actually need to check if a MI is present, i.e. not omit. ispresent(omit) => false isvalue(omit) => true Change-Id: I0e24e2aaa1f0da7ffdbc93ea4a19491e5dfb39b4
?
Updated by fixeria almost 4 years ago
maybe this is related to: [...]
I don't think so, because this change has been merged today, on Mar 30. It may be related to other recent changes though, I'll investigate.
Would you mind if I steal this ticket and assign to myself?
Updated by fixeria almost 4 years ago
Hmm, the last 'good' commit on which both test cases pass is:
commit 7b2242157b8245553eefb94a407057125947c182 (HEAD) Author: Vadim Yanitskiy <axilirator@gmail.com> Date: Thu Mar 26 02:43:55 2020 +0700 PCU: also test GSGN originated PS/CS Paging containing TMSI This additional couple of test cases reveals several bugs: 1) the IUT encodes a erroneous RR Paging Request message containing P-TMSI, so TITAN fails to decode it; 2) the IUT prints an invalid P-TMSI in its log output due to load of misaligned address (found by UBSan). [1] I97fd5ffc15a4a58112d7c37c69b7ac42b0741a0e [2] Icf8836f216793e342b239c8e6645aac1e82bf324 Change-Id: I7fbec5b2c5c3943a7413417b623f55c135c152d7
while the culprit is the next commit:
commit 35d3a159e256b584e962e98e86f04f4d4b54eccc (HEAD) Author: Vadim Yanitskiy <axilirator@gmail.com> Date: Sat Mar 28 00:45:56 2020 +0700 deps/Makefile: bump titan.ProtocolModules.MobileL3_v13.4.0_commit This revision has an important fix concerning the length limitations of Mobile Identity IE (see 3GPP TS 24.008, section 10.5.1.4) when no identity is present (see 'No_Identity' record). Change-Id: If5339c7a91b4e0188194f1cd935798f153974e01
Funny enough the new commit hash promised bad luck ;)
badbad680df216b3211260d56b14734eeb2c9028
Updated by fixeria almost 4 years ago
- Status changed from New to In Progress
- Assignee changed from dexter to fixeria
- % Done changed from 0 to 80
Ok, the problem is that since If5339c7a91b4e0188194f1cd935798f153974e01, TITAN also decodes RR Paging Request messages with no identity (PCH filling). In as_l1_count_paging() we should not count such messages because they're generated by osmo-bts-trx itself. I have a working patch, will send it for review soon.
Updated by fixeria almost 4 years ago
- Status changed from In Progress to Feedback
- % Done changed from 80 to 100
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/17683 BTS: fix as_l1_count_paging(): do not count PCH filling messages
Updated by fixeria almost 4 years ago
- Status changed from Feedback to Resolved
Fixed since build #847.