Attention is currently required from: dexter.
dexter has posted comments on this change. (
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34498?usp=email )
Change subject: PCUIF_Components: ensure clean IMSI string
......................................................................
Patch Set 1:
(2 comments)
Patchset:
PS1:
> Now I get: "262420000000423" & char(0, 0, 0, 0) & char(0, 0, 0, 241), which
> causes even more odd beh […]
I don't really understand where the char(0, 0, 0, 241) comes from. The data in
the buffer is as expected. (Two 0x00 at the end). I also checked the code. The
message is pre-initialized, so there is no garbage, which is good in the first
place.
I tried once more and I did the type definition exactly like it is done with
PCUIF_Text. The result is the same:
09:40:29.053840 4 PCUIF_Components.ttcn:558 Warning: dec_PCUIF_pch(): Data
remained at the end of the stream after successful decoding: '2B00'O
09:40:29.054549 4 PCUIF_Components.ttcn:576 Sent on TC to mtc
@PCUIF_Components.BTS_CCCH_Block : {
bts_nr := 0,
raw := {
sapi := PCU_IF_SAPI_PCH_2 (8),
len := 45,
data :=
'FFFFFFFF323632343230303030303030343233000031062100082926240000004032272B2B2B2B2B2B2B2B2B00'O,
fn := 0,
arfcn := 0,
trx_nr := 0,
ts_nr := 0,
block_nr := 0,
rssi := 0,
ber10k := 0,
ta_offs_qbits := 0,
lqual_cb := 0
},
msg_id := 'FFFFFFFF'O,
imsi := "262420000000423" & char(0, 0, 0, 0) & char(0, 0, 0, 241),
rr_msg := {
header := {
l2_plen := {
l2_plen := 0,
zero_one := '00'B
},
skip_indicator := 3,
rr_protocol_discriminator := 1,
message_type := SYSTEM_INFORMATION_TYPE_5ter (6)
},
payload := {
other := '2100082926240000004032272B2B2B2B2B2B2B2B'O
}
},
confirm := true
}
But this time I noticed that the payload and confirm field does not look good
as well. There is one 2B missing at the end of the payload and the confirm flag
should be false in this case. I have the feeling that the null_terminated
messes up the decoder?
I think the PCUIF_text definition works because it is the last field in the
record definition, so there no consecutive fields that could be messed up.
But to be honest, I still do not understand this. If null_terminated would mean
"stop here, everything that follows belongs to the next field". We wouldnt get
the garbage in that IMSI field. I also don't get where the first two MAC block
bytes (3106) went.
File pcu/PCUIF_Components.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34498/comment/f24ceca3_ef658695
PS1, Line 545: var charstring imsi_filter_regexp := "(\d*)" /* numbers
only */
> missing `;` at the end of line, btw
Done
--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34498?usp=email
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I7bfea59a306e75211856e4e80985ebf000c42224
Gerrit-Change-Number: 34498
Gerrit-PatchSet: 1
Gerrit-Owner: dexter <[email protected]>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <[email protected]>
Gerrit-Reviewer: pespin <[email protected]>
Gerrit-Attention: dexter <[email protected]>
Gerrit-Comment-Date: Fri, 22 Sep 2023 07:57:58 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria <[email protected]>
Comment-In-Reply-To: dexter <[email protected]>
Gerrit-MessageType: comment
