[S] Change in osmo-ttcn3-hacks[master]: PCUIF_Components: ensure clean IMSI string - gerrit-log

22 Sep 2023

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_ef65… 
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 &lt;pmaier(a)sysmocom.de&gt;
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria &lt;vyanitskiy(a)sysmocom.de&gt;
Gerrit-Reviewer: pespin &lt;pespin(a)sysmocom.de&gt;
Gerrit-Attention: dexter &lt;pmaier(a)sysmocom.de&gt;
Gerrit-Comment-Date: Fri, 22 Sep 2023 07:57:58 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: fixeria &lt;vyanitskiy(a)sysmocom.de&gt;
Comment-In-Reply-To: dexter &lt;pmaier(a)sysmocom.de&gt;
Gerrit-MessageType: comment