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(a)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(a)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