Thank you for your kind suggestions.
I made a simple test with code snippet (lines):
1. var S1AP_PDU ber_pdu_to_log :=
valueof(ts_S1AP_SetupReq(g_enb_pars[idx].global_enb_id,g_enb_pars[idx].supported_tas,
v32));
2. log(ber_pdu_to_log);
3. var charstring pdu_to_send_to_ip_layer := enc_S1AP_PDU(ber_pdu_to_log);
4. log(pdu_to_send_to_ip_layer);
RESULT from line 2.
{ initiatingMessage := { procedureCode := 17, criticality := reject
(0), value_ := { s1SetupRequest := { protocolIEs := { { id := 59,
criticality := ignore (1), value_ := { global_ENB_ID := { pLMNidentity
:= '62F224'O, eNB_ID := { macroENB_ID := '00000001010110110011'B },
iE_Extensions := omit } } }, { id := 60, criticality := ignore (1),
value_ := { eNBname := "Ksenija" } }, { id := 64, criticality :=
reject (0), value_ := { supportedTAs := { { tAC := '3039'O ("09"),
broadcastPLMNs := { '62F224'O }, iE_Extensions := omit } } } } } } } }
}
#################################
RESULT from line 3. ASN.1 (A)PER S1AP
'00110020000003003B40080062F22400015B30003C4002030000400007000C0E4062F224'O
#################################
I checked encoded ASN.1 message with publicly available decoders.
Error is thrown whenever decoder tries to decode ENBname.
I can conclude that libfftranscode API is the source of the problem.
On Mon, Oct 25, 2021 at 5:50 PM Harald Welte <laforge@osmocom.org> wrote:
>
> On Fri, Oct 22, 2021 at 02:12:03PM +0200, Mirko Kovacevic wrote:
> > Protocol-IEs, MMEname and ENBname, cant be decoded\encoded properly,
> > definitely.
>
> one would have to check if the encoding problem already exists in the BER version
> (as generated by TITAN natively) or if it happens at the BER <-> PER transcoding
> inside the [unfortunately] non-public libfftranscode, generated by ffasn1c.
>
> I you can build a small, self contained test case that shows a problem in
> BER <-> PER transcoding using the libfftranscode API directly (removing all of TITAN, etc.)
> then we may have a chance of either solving it at sysmocom or by asking
> the ffasn1c author to have a look
>
> > Amazing progress with S1AP emulation, congrats.
>
> thanks. Please keep us posted about any progress. We're happy to merge any
> related patches you may have for adding more test cases, fixing bugs, etc.
>
> I never found the time for it, but the general idea always was to automatically
> run this testsuite in jenkins.osmocom.org against the open5gs-mme, like we do
> for or own osmocom software.
>
> Regards,
> Harald
> --
> - Harald Welte <laforge@osmocom.org> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)
--
Puno pozdrava,
Mirko Kovacevic