Home » Eclipse Projects » Eclipse Titan » Trouble getting SCTP to work with IPL4
| Trouble getting SCTP to work with IPL4 [message #1821669] |
Tue, 18 February 2020 12:06  |
 Andre Puschmann
Messages: 6
Registered: February 2020 |
Junior Member |
|
|
Hi guys,
I am currently in the process of refactoring some binary protocol between the DUT and the tester. I've used TCP over the IPL4 test port previously but would like to use SCTP instead.
In theory this should be straight forward, shouldn't it? But I can't seem to get it to work. The autoconnect wouldn't succeed. Below are the testport parameters.
[TESTPORT_PARAMETERS]
system.E_SRB.debug := "yes" //or "no"
system.E_SRB.defaultListeningPort := "0"
system.E_SRB.map_behavior := "connect"
system.E_SRB.RemotePort := "2226" // SUT port for E_SRB
system.E_SRB.RemoteHost := "127.0.0.1" // SUT - IP
system.E_SRB.lazy_conn_id_handling := "yes"
system.E_SRB.map_protocol := "sctp"
system.E_SRB.sctp_stack := "kernel"
I am running a ncat listener like this but I am not seeing any connection whatsoever.
The Titan logs look like this:
13:03:53.523609 PARALLEL NasEmu.ttcn:689(function:f_NASEMU_MainLoop) Mapping port 4:SYS_SRB to system:E_SRB.
13:03:53.523693 PORTEVENT NasEmu.ttcn:689(function:f_NASEMU_MainLoop) Port SYS_SRB was mapped to system:E_SRB.
13:03:53.523757 PORTEVENT NasEmu.ttcn:689(function:f_NASEMU_MainLoop) Port E_SRB was started.
13:03:53.523799 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: debug, value: yes)
13:03:53.523836 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: defaultListeningPort, value: 0)
13:03:53.523855 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_behavior, value: connect)
13:03:53.523867 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: RemotePort, value: 2226)
13:03:53.523878 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: RemoteHost, value: 127.0.0.1)
13:03:53.523903 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: lazy_conn_id_handling, value: yes)
13:03:53.523917 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_protocol, value: sctp)
13:03:53.523928 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: sctp_stack, value: kernel)
13:03:53.523941 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::user_map(SYS_SRB): enter
13:03:53.524232 PORTEVENT NasEmu.ttcn:689(function:f_NASEMU_MainLoop) entering f__IPL4__PROVIDER__connect: :0 -> 127.0.0.1:2226 / SCTP
13:03:53.524262 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: f__IPL4__PROVIDER__connect: enter
13:03:53.524327 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: f__IPL4__PROVIDER__connect: create new socket: :0 -> 127.0.0.1:2226
13:03:53.524493 ERROR NasEmu.ttcn:689(function:f_NASEMU_MainLoop) Dynamic test case error: IPL4asp__PT_PROVIDER::user_map(SYS_SRB): Autoconnect: Can not connect: -1
13:03:53.524575 VERDICTOP NasEmu.ttcn:689(function:f_NASEMU_MainLoop) setverdict(error): none -> error
I am using R25A of the IPL4asp.
Any idea whats going on here?
Thanks
Andre
|
|
|
| Re: Trouble getting SCTP to work with IPL4 [message #1821700 is a reply to message #1821669] |
Tue, 18 February 2020 20:09  |
Andre Puschmann
Messages: 6
Registered: February 2020 |
Junior Member |
|
|
Here is an update regarding the above-desribed issue. I've updated to the most recent version of the IPL4asp on Github. After passing the `USE_SCTP` to the compiler I am not getting a bit further. But I am still not able to replicate the TCP behaviour of the port. I've been using the test port in connect mode and on my SS I am listening on the SCTP socket. When I start the binary it the autoconnect feature connects to the port but it would immediately close it again.
I've also tried to turn it around, so that Titan listens and my client connects. I can also see the connection happening but no data is ever received. See the logs below:
18:46:18.017595 PORTEVENT IP_PTC_CtrlMsgs.ttcn:164(function:f_ICMPv6_Start) Message with id 2 was extracted from the queue of IP.
18:46:18.019106 MATCHING EUTRA_Component.ttcn:192(altstep:a_EUTRA_StandardDefault) Operation `any timer.timeout' failed: The test component does not have active timers.
18:46:18.136740 DEBUG NasEmu.ttcn:698(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::Handle_Fd_Event_Readable: enter, fd: 8
18:46:18.137022 DEBUG NasEmu.ttcn:698(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::Handle_Fd_Event_Readable: connId: 1 READABLE sock: 8, type: 3, sslState: 0
18:46:18.137224 DEBUG NasEmu.ttcn:698(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::Handle_Fd_Event_Readable: incoming connection requested
18:46:18.137308 DEBUG NasEmu.ttcn:698(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER: ConnAdd enter: type: 4, ssl_tls_type: 0, sock: 9, parentIx: 1
18:46:18.137342 DEBUG NasEmu.ttcn:698(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::ConnAdd: connId: 2
18:46:18.137482 DEBUG NasEmu.ttcn:698(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::ConnAdd: leave: sockListCnt: 2
18:46:18.138060 PORTEVENT NasEmu.ttcn:698(function:f_NASEMU_MainLoop) Message enqueued on SYS_SRB from system @Socket_API_Definitions.PortEvent : {
connOpened := {
connId := 2,
remName := "127.0.0.1",
remPort := 47031,
locName := "127.0.0.1",
locPort := 2226,
proto := {
sctp := {
sinfo_stream := omit,
sinfo_ppid := omit,
remSocks := omit,
assocId := omit
}
},
userData := 0
}
} id 1
18:46:18.138554 DEBUG NasEmu.ttcn:698(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::Handle_Fd_Event_Readable: leave
18:46:18.138773 MATCHING NasEmu.ttcn:616(altstep:a_AspFromSystemAdaptorHandler) Matching on port SYS_SRB failed: Type of the first message in the queue is not @NasEmu_AspTypes.RRC_PDU_IND.
18:46:18.138830 MATCHING NasEmu.ttcn:703(function:f_NASEMU_MainLoop) Matching on port SYS_SRB succeeded.
18:46:18.138894 PORTEVENT NasEmu.ttcn:703(function:f_NASEMU_MainLoop) Receive operation on port SYS_SRB succeeded, message from system(): @Socket_API_Definitions.PortEvent: {
connOpened := {
connId := 2,
remName := "127.0.0.1",
remPort := 47031,
locName := "127.0.0.1",
locPort := 2226,
proto := {
sctp := {
sinfo_stream := omit,
sinfo_ppid := omit,
remSocks := omit,
assocId := omit
}
},
userData := 0
}
} id 1
18:46:18.139060 PORTEVENT NasEmu.ttcn:703(function:f_NASEMU_MainLoop) Message with id 1 was extracted from the queue of SYS_SRB.
18:46:18.139342 VERDICTOP CommonDefs.ttcn:145(function:f_SetVerdict) setverdict(inconc): none -> inconc reason: ""/home/anpu/src/srslte_ttcn3_rlc_titan/bin2/NasEmu.ttcn:704: unexpected message (skipped)"", new component reason: ""/home/anpu/src/srslte_ttcn3_rlc_titan/bin2/NasEmu.ttcn:704: unexpected message (skipped)""
Here is the setup log of for this socket:
18:46:17.866224 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: debug, value: yes)
18:46:17.866277 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: defaultListeningHost, value: 0.0.0.0)
18:46:17.866307 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: defaultListeningPort, value: 2226)
18:46:17.866330 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_behavior, value: listen)
18:46:17.866345 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: RemotePort, value: 2226)
18:46:17.866363 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: RemoteHost, value: 127.0.0.1)
18:46:17.866377 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: map_protocol, value: sctp)
18:46:17.866390 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::set_parameter: enter (name: sctp_stack, value: kernel)
18:46:17.866404 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::user_map(SYS_SRB): enter
18:46:17.866747 PORTEVENT NasEmu.ttcn:689(function:f_NASEMU_MainLoop) entering f__IPL4__PROVIDER__listen: 0.0.0.0:2226 / SCTP
18:46:17.866778 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: f__IPL4__PROVIDER__listen: enter 0.0.0.0 2226
18:46:17.866814 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: SetLocalSockAddr: locName: 0.0.0.0 loc_port 2226 def_loc_host 0.0.0.0, add_family AF_INET
18:46:17.866882 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::setOptions: enter, number of options: 0
18:46:17.866898 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::setOptions: sock: 8
18:46:17.866919 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::setOptions: Socket option REUSEADDR on socket 8 is set to: 1
18:46:17.866934 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::setOptions: Setting sctp options sinit_num_ostreams:64,sinit_max_instreams:64, sinit_max_attempts:0, sinit_max_init_timeo:0
18:46:17.866957 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::setOptions: leave
18:46:17.867014 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER: ConnAdd enter: type: 3, ssl_tls_type: 0, sock: 8, parentIx: -1
18:46:17.867044 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::ConnAdd: new sockListSize: 16
18:46:17.867061 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::ConnAdd: connId: 1
18:46:17.867099 DEBUG NasEmu.ttcn:689(function:f_NASEMU_MainLoop) E_SRB: IPL4asp__PT_PROVIDER::ConnAdd: connId: set ssl options for connId : 1
Does anybody have experience using the IPL4asp in SCTP mode? Is it working in both client and server mode?
Thanks
Andre
P.S.: Somehow my forum account got erased, I could login with my credentials but the user history is empty. Was there a DB loss or anything like that?
|
|
|
| Re: Trouble getting SCTP to work with IPL4 [message #1821736 is a reply to message #1821700] |
Wed, 19 February 2020 10:05 |
Andre Puschmann
Messages: 6
Registered: February 2020 |
Junior Member |
|
|
Hi again,
I've found the issue now with the SCTP translation ports. Basically the default handling of the SCTP events is causing a shutdown because there are no handles for the, e.g. SCTP association event. If I turn those events of, the port works as expected. See config below:
system.E_SRB.sctp_association_event := "no"
system.E_SRB.sctp_address_event := "no"
system.E_SRB.sctp_shutdown_event := "no"
Here is the log:
11:02:29.686023 PORTEVENT NasEmu.ttcn:703(function:f_NASEMU_MainLoop) Receive operation on port SYS_SRB succeeded, message from system(): @Socket_API_Definitions.PortEvent: {
sctpEvent := {
sctpAssocChange := {
clientId := 1,
proto := {
sctp := {
sinfo_stream := omit,
sinfo_ppid := omit,
remSocks := omit,
assocId := omit
}
},
sac_state := SCTP_COMM_UP (0)
}
}
} id 1
11:02:29.686101 PORTEVENT NasEmu.ttcn:703(function:f_NASEMU_MainLoop) Message with id 1 was extracted from the queue of SYS_SRB.
11:02:29.686506 VERDICTOP CommonDefs.ttcn:145(function:f_SetVerdict) setverdict(inconc): none -> inconc reason: ""/home/anpu/src/srslte_ttcn3_rlc_titan/bin2/NasEmu.ttcn:704: unexpected message (skipped)"", new component reason: ""/home/anpu/src/srslte_ttcn3_rlc_titan/bin2/NasEmu.ttcn:704: unexpected message (skipped)""
1
So the event seems to be simply passed to the main loop which doesn't expect it and therefore stops.
Question is now how shall a translation port handle those events correctly? Are there any public examples out there?
Thanks
Andre
|
|
|
| Re: Trouble getting SCTP to work with IPL4 [message #1821828 is a reply to message #1821736] |
Thu, 20 February 2020 18:34 |
|
Hi Andre,
I guess the simplest you can do is to write an altstep to catch all events that appear in your log;
mind that transmission of sctp events to the upper layer can be configured, see port documentation.
so you need something like
altstep as_SCTP_EVENTS() runs on SCTP_CT {
//Will be used as default behaviour!!!!
//******************************************************
[]SCTP_PCO.receive(ASP_SCTP_ASSOC_CHANGE:?) {repeat};
[]SCTP_PCO.receive(ASP_SCTP_PEER_ADDR_CHANGE:?) {repeat};
:
:
}
(the example is based on the declarations of the SCTPasp port, but IPL4 declarations are very much the same)
now this altstep will have to be declared as default behaviour in your testcase:
//******************************************************
testcase tc_sctp() runs on SCTP_CT {
//******************************************************
:
var default v_def := activate(as_SCTP_EVENTS());
:
}
This default will take care of handling all SCTP events sent by the port to the application layer.In this form it won't do much with them but it will extract them from the incoming queue so they won't block other messages you are more interested in.
I will try to prepare more detailed examples, using the IPL4 port as well.
I hope this helps somewhat.
Best regards
Elemer
|
|
|
Goto Forum:
Current Time: Tue Apr 16 10:10:26 GMT 2024
Powered by FUDForum. Page generated in 0.06029 seconds |
] 
Search
Help
Register
Login
Home
