19 Oct
2021
19 Oct
'21
3:59 p.m.
Hi, Osmonians,
I don't know where to write for MME TTCN-3, so I chose to write to it
closet relative - SGSN.
I was trying to do slight modification to TTCN-3 code, modifing
S1AP_Templates.ttcn.
I embedded enodeb name for all tests with new protoc-IE = id-eNBname :
##################################
template (value) S1AP_PDU
ts_S1AP_SetupReq(template (value) Global_ENB_ID p_global_ENB_ID,
template (value) SupportedTAs p_supportedTAs,
template (value) PagingDRX p_pagingDRXs) := {
initiatingMessage := {
procedureCode := id_S1Setup,
criticality := reject,
value_ := {
S1SetupRequest := {
protocolIEs := {
{
id := S1AP_Constants.id_Global_ENB_ID,
criticality := ignore,
value_ := { Global_ENB_ID := p_global_ENB_ID }
},
{
id := S1AP_Constants.id_SupportedTAs,
criticality := reject,
value_ := {SupportedTAs := p_supportedTAs}
},
{
id := S1AP_Constants.id_eNBname,//id-eNBname
criticality := ignore,
value_ := {ENBname := "OsmoEnodeb"}
} /* HACK: work around nextepc bug
, {
id := S1AP_Constants.id_pagingDRX,
criticality := ignore,
value_ := {PagingDRX := p_pagingDRXs}
} */
}
}
}
}
}
########################
Code compiles, but PDU is not encoded well.
I attached Wireshark preview.
Can you help me with this issue ?
--
Puno pozdrava,
Mirko Kovacevic
22 Oct
22 Oct
2:12 p.m.
Hi,
Protocol-IEs, MMEname and ENBname, cant be decoded\encoded properly,
definitely.
I am using open5g-mme. When IE=MMEname is turned off, test can pass or used
till the end.
Amazing progress with S1AP emulation, congrats.
If I misuse this group with the topic, be free to tell me.
On Tue, Oct 19, 2021 at 3:59 PM Mirko Kovacevic <northmirko(a)gmail.com>
wrote:
Hi, Osmonians,
I don't know where to write for MME TTCN-3, so I chose to write to it
closet relative - SGSN.
I was trying to do slight modification to TTCN-3 code, modifing
S1AP_Templates.ttcn.
I embedded enodeb name for all tests with new protoc-IE = id-eNBname :
##################################
template (value) S1AP_PDU
ts_S1AP_SetupReq(template (value) Global_ENB_ID p_global_ENB_ID,
template (value) SupportedTAs p_supportedTAs,
template (value) PagingDRX p_pagingDRXs) := {
initiatingMessage := {
procedureCode := id_S1Setup,
criticality := reject,
value_ := {
S1SetupRequest := {
protocolIEs := {
{
id := S1AP_Constants.id_Global_ENB_ID,
criticality := ignore,
value_ := { Global_ENB_ID := p_global_ENB_ID }
},
{
id := S1AP_Constants.id_SupportedTAs,
criticality := reject,
value_ := {SupportedTAs := p_supportedTAs}
},
{
id := S1AP_Constants.id_eNBname,//id-eNBname
criticality := ignore,
value_ := {ENBname := "OsmoEnodeb"}
} /* HACK: work around nextepc bug
, {
id := S1AP_Constants.id_pagingDRX,
criticality := ignore,
value_ := {PagingDRX := p_pagingDRXs}
} */
}
}
}
}
}
########################
Code compiles, but PDU is not encoded well.
I attached Wireshark preview.
Can you help me with this issue ?
--
Puno pozdrava,
Mirko Kovacevic
--
*Puno pozdrava,Mirko Kovacevic*
25 Oct
25 Oct
5:46 p.m.
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)
27 Oct
27 Oct
10:43 p.m.
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:
--
Puno pozdrava,
Mirko Kovacevic
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)
29 Oct
29 Oct
9:13 a.m.
But don't bother with this small defect, we can live without MMEname,
ENBname, they are optional in many production systems, too.
S1 handover would be a very good case to write.
On Wed, Oct 27, 2021 at 10:43 PM Mirko Kovacevic <northmirko(a)gmail.com>
wrote:
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:
============================================================================
--
*Puno pozdrava,Mirko Kovacevic*
On Fri, Oct 22, 2021 at 02:12:03PM +0200, Mirko Kovacevic wrote:
BER version
Protocol-IEs, MMEname and ENBname, cant be
decoded\encoded properly,
definitely.
one would have to check if the encoding problem already exists in the (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
any
Amazing progress with S1AP emulation, congrats.
thanks. Please keep us posted about any progress. We're happy to merge 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
1 p.m.
Hi Mirko,
On Fri, Oct 29, 2021 at 09:13:25AM +0200, Mirko Kovacevic wrote:
But don't bother with this small defect, we can
live without MMEname,
ENBname, they are optional in many production systems, too.
Thanks.
Given the current workload and the fact that there is no customer paying
for this, I think it will be a low priority item and unlikely to be
investigated any time soon.
S1 handover would be a very good case to write.
Well, osmocom is a collaborative open source project. Anyone can add whatever
test cases they want, we're happy to merge any related patches.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
25 Oct
25 Oct
5:42 p.m.
Hi Mirko,
sorry for the late response..
On Tue, Oct 19, 2021 at 03:59:07PM +0200, Mirko Kovacevic wrote:
I don't know where to write for MME TTCN-3, so I
chose to write to it
closet relative - SGSN.
That's ok, we don't really have any mailing lists specific for the test suites.
Code compiles, but PDU is not encoded well.
I attached Wireshark preview.
Can you help me with this issue ?
I don't have the time to dive into this at the moment, sorry. It's been
years since I last touched that code, and There are tons of other projects
and issues requiring urgent attention :/
I did have some problems when first implementing it, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=549252
--
- 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)
915
days inactive
925
days old
osmocom-net-gprs@lists.osmocom.org
6 comments
3 participants
participants (3)
-
Harald Welte -
Harald Welte -
Mirko Kovacevic