Attention is currently required from: dexter.

View Change

2 comments:

• Patchset:

  • Patch Set #1:

    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:

  • Patch Set #1, Line 545: var charstring imsi_filter_regexp := "(\d*)" /* numbers only */

    missing `;` at the end of line, btw

    Done

To view, visit change 34498. To unsubscribe, or for help writing mail filters, visit settings.