Bug #4475
closed
TC_paging_imsi_80percent + TC_paging_tmsi_80percent fail since 842 (March 28)
Added by laforge about 4 years ago.
Updated about 4 years ago.
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?
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
?
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?
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
- 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.
- Status changed from In Progress to Feedback
- % Done changed from 80 to 100
- Status changed from Feedback to Resolved
Also available in: Atom
PDF
