Home » Eclipse Projects » Eclipse Titan » Translation ports vs dual-faced ports part2 (ICMP/IP/Ethernet )
| Translation ports vs dual-faced ports part2 [message #1763623] |
Thu, 18 May 2017 06:44  |
|
Dear all,
this time we will resuscitate the example of dual-face port usage published earlier in:
Example of ping (ICMP) over a layer 2 test port with Titan
(Example of ICMP/IP over a LANL2 test port in dual-faced mode with Titan)
https://www.eclipse.org/forums/index.php/t/1068359/
in the form of a translation port use case.
The code presents interest in itself as it describes a modality to directly access the Ethernet layer using the LANL2asp tets port.
The northern part of the translation port (IcmpPort) receives ICMP messages like this:
template PDU_ICMP t_PDU_ICMP_ECho(OCT2 par_seq):=
{
echo:={
type_field:=8,
code:=0,
checksum:='0000'O,
identifier:='0002'O,
sequence_number:=par_seq,
data:='6162636465666768696a6b6c6d6e6f7071727374757677616263646566676869'O
}
}
and translates them to Ethernet frames for the southern end (LANL2asp port).
The test case sends a cycle of ICMP messages (pings) and receives the ICMP echo sent by the kernel IP stack.
Here's the translation port:
//Translation port
type port IcmpPort message map to LANL2asp_PT{
in PDU_ICMP from ASP_v2_LANL2 with dec_ASP_v2_LANL2_Icmp();
out PDU_ICMP to ASP_LANL2 with enc_PDU_ICMP();
in Bool3, Bool4;
in ASP_LANL2_Error, ASP_LANL2_open_result, ASP_v2_LANL2_Error, ASP_LANL2;
}
versus the dual-faced port, somewhat more complicated and difficult to read:
//Dual faced port
type port IcmpPort message {
inout PDU_ICMP;
in Bool3, Bool4;
}
with
{
extension "user LANL2asp_PT
out(
PDU_ICMP -> ASP_LANL2: function(enc_PDU_ICMP)
)
in(
ASP_LANL2 -> PDU_ICMP : function(dec_ASP_LANL2_Icmp),
- : discard;
ASP_LANL2_Error -> - : discard;
ASP_v2_LANL2 -> PDU_ICMP : function(dec_ASP_v2_LANL2_Icmp),
- : discard;
ASP_LANL2_open_result -> - : discard;
ASP_v2_LANL2_Error -> - : discard
)"
}
and one of the functions after :
//------------------------------------------------------------------------------
function dec_ASP_LANL2_Icmp (in ASP_LANL2 par_msg, out PDU_ICMP result ) //return integer
//------------------------------------------------------------------------------
{
var PDU_ICMP v_PDU_ICMP;
var IPv4_packet v_IPv4_packet:= f_IPv4_dec(par_msg.payload);
if (v_IPv4_packet.header.proto ==1)//ICMP
{
v_PDU_ICMP:= f_dec_PDU_ICMP(v_IPv4_packet.payload)
result:=v_PDU_ICMP;
log("ICMP received!!")
port.setstate(0);
return;
}
port.setstate(1);
}
with { extension "prototype(fast)" }
and before (not much difference here):
//------------------------------------------------------------------------------
function dec_ASP_LANL2_Icmp (in ASP_LANL2 par_msg, out PDU_ICMP result ) return integer
//------------------------------------------------------------------------------
{
var PDU_ICMP v_PDU_ICMP;
var IPv4_packet v_IPv4_packet:= f_IPv4_dec(par_msg.payload);
if (v_IPv4_packet.header.proto ==1)//ICMP
{
v_PDU_ICMP:= f_dec_PDU_ICMP(v_IPv4_packet.payload)
result:=v_PDU_ICMP;
log("ICMP received!!")
return 0;
}
return -1;
}
with { extension "prototype(backtrack)" }
Here's a snippet from the log where the message flow can be followed:
2017/May/09 03:05:56.183850 PORTEVENT ICMP2ETH.ttcn:250 Sent on Icmp_PCO to system @ICMP_Types.PDU_ICMP : { echo := { type_field := 8, code := 0, checksum := '0000'O, identifier := '0002'O, sequence_number := '00C9'O, data := '6162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O ("abcdefghijklmnopqrstuvwabcdefghi") } }
2017/May/09 03:05:56.183884 PORTEVENT ICMP2ETH.ttcn:250 The state of the Icmp_PCO port was changed by a setstate operation to unset. Information: by test environment.
2017/May/09 03:05:56.183902 DEBUG ICMP2ETH.ttcn:156 Encoding PDU_ICMP: { echo := { type_field := 8, code := 0, checksum := '0000'O, identifier := '0002'O, sequence_number := '00C9'O, data := '6162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O ("abcdefghijklmnopqrstuvwabcdefghi") } }
2017/May/09 03:05:56.184042 DEBUG ICMP2ETH.ttcn:156 PDU_ICMP after encoding: '08004C91000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O
2017/May/09 03:05:56.184128 DEBUG ICMP2ETH.ttcn:165 Entering f__IPv4__enc__eth
2017/May/09 03:05:56.184193 DEBUG ICMP2ETH.ttcn:165 Encoding IPv4_packet: { header := { ver := 4, hlen := 5, tos := 0, tlen := 10, id := 50000, res := '0'B, dfrag := '0'B, mfrag := '0'B, foffset := 0, ttl := 128, proto := 1, cksum := 0, srcaddr := '7F000001'O, dstaddr := '7F000001'O }, ext_headers := omit, payload := '08004C91000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O }
2017/May/09 03:05:56.184285 DEBUG ICMP2ETH.ttcn:165 Entering Encode_IPv4_extension_headers
2017/May/09 03:05:56.184358 DEBUG ICMP2ETH.ttcn:165 Entering Encode_IPv4_ESP_tails
2017/May/09 03:05:56.184424 DEBUG ICMP2ETH.ttcn:167 Entering f__IPv4__checksum
2017/May/09 03:05:56.184487 DEBUG ICMP2ETH.ttcn:167 Entering Calculate_cksum
2017/May/09 03:05:56.184552 PORTEVENT ICMP2ETH.ttcn:177 The state of the Icmp_PCO port was changed by a setstate operation to translated.
2017/May/09 03:05:56.184575 PORTEVENT ICMP2ETH.ttcn:250 Outgoing message was mapped to @LANL2asp_Types.ASP_LANL2 : { eth_dst_addr := 'FFFFFFFFFFFF'O, eth_src_addr := '000C29FBE6D1'O, type_field := '0800'O, payload := '4500003CC35000008001796E7F0000017F00000108004C91000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O }
2017/May/09 03:05:56.184695 TIMEROP ICMP2ETH.ttcn:251 Start timer t_time: 4 s
2017/May/09 03:05:56.194215 PORTEVENT ICMP2ETH.ttcn:252 Message enqueued on Icmp_PCO from system @LANL2asp_Types.ASP_LANL2 : { eth_dst_addr := 'FFFFFFFFFFFF'O, eth_src_addr := '005056E0346F'O, type_field := '0806'O, payload := '0001080006040001005056E0346FC0A88B020000000000007F000001000000000000000000000000000000000000'O } id 1
2017/May/09 03:05:56.194285 MATCHING ICMP2ETH.ttcn:254 Matching on port Icmp_PCO succeeded.
2017/May/09 03:05:56.194301 PORTEVENT ICMP2ETH.ttcn:254 Receive operation on port Icmp_PCO succeeded, message from system(): @LANL2asp_Types.ASP_LANL2: { eth_dst_addr := 'FFFFFFFFFFFF'O, eth_src_addr := '005056E0346F'O, type_field := '0806'O, payload := '0001080006040001005056E0346FC0A88B020000000000007F000001000000000000000000000000000000000000'O } id 1
2017/May/09 03:05:56.194316 PORTEVENT ICMP2ETH.ttcn:254 Message with id 1 was extracted from the queue of Icmp_PCO.
2017/May/09 03:05:57.194147 PORTEVENT ICMP2ETH.ttcn:252 Message enqueued on Icmp_PCO from system @LANL2asp_Types.ASP_LANL2 : { eth_dst_addr := 'FFFFFFFFFFFF'O, eth_src_addr := '005056E0346F'O, type_field := '0806'O, payload := '0001080006040001005056E0346FC0A88B020000000000007F000001000000000000000000000000000000000000'O } id 2
2017/May/09 03:05:57.194231 MATCHING ICMP2ETH.ttcn:254 Matching on port Icmp_PCO succeeded.
2017/May/09 03:05:57.194249 PORTEVENT ICMP2ETH.ttcn:254 Receive operation on port Icmp_PCO succeeded, message from system(): @LANL2asp_Types.ASP_LANL2: { eth_dst_addr := 'FFFFFFFFFFFF'O, eth_src_addr := '005056E0346F'O, type_field := '0806'O, payload := '0001080006040001005056E0346FC0A88B020000000000007F000001000000000000000000000000000000000000'O } id 2
2017/May/09 03:05:57.194266 PORTEVENT ICMP2ETH.ttcn:254 Message with id 2 was extracted from the queue of Icmp_PCO.
The files
are parts of the port skeleton generated and added to the build for the reasons explained in the previous part.
Code archive and log attached.
Best regards
Elemer
[Updated on: Thu, 18 October 2018 09:56] Report message to a moderator |
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796481 is a reply to message #1796370] |
Mon, 15 October 2018 06:29  |
|
Hi David,
according to the documentation of the LANL2 test port , this means:
"The size of the received packet is not a correct Ethernet II frame size. The
packet is not sent to TITAN."
If you upload the complete log in debug mode and an associated Wireshark , trace , maybe we can figure out more.
BR
Elemer
|
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796571 is a reply to message #1796531] |
Tue, 16 October 2018 09:44 |
|
Hi David,
the packets that are received
e.g.:
Receive operation on port Icmp_PCO succeeded, message from system(): @LANL2asp_Types.ASP_LANL2: { eth_dst_addr := 'FA163ED742B7'O, eth_src_addr := 'FA163EB4684D'O, type_field := '0800'O, payload := '45000048B4FE40004006680D0A141E10C0A834D8CC0B270F09BA016BEF7D338F801800DD1DDF00000101080A0680B4760680B46E131201074C616E5F50434F0849636D705F50434F'O } id 2
are not ICMP but TCP packets exchanged between 10.20.30.16 and 192.168.36.156
and I'm not sure how they got there.
Can you upload the config file you use?
BR
Elemer
|
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796579 is a reply to message #1796576] |
Tue, 16 October 2018 10:32 |
|
Hi David,
here's what I think happens:
I tried this on an interface with no traffic ; there's traffic on yours, so you need to set
a packet filter ( see documentation)
packet_filter
This parameter is optional but should be set according to the specific usage.
The user can specify here a Libpcap filter expression. The receiving of the
packets will be filtered according to the expression. The format is exactly the
same as the filter used by tcpdump[6]. If not set, every packet will be
transmitted.
that will tell the port to discard unwanted traffic.
Best regards
Elemer
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796604 is a reply to message #1796579] |
Tue, 16 October 2018 13:02 |
 David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
1. Translation port
We suspect that the payload in ICMP2ETH.ttcn has by default proto = 6 defined for TCP while we are clearly sending ICMP in template IPv4_header t_IPv4_header (proto = 1), but both template PDU_ICMP t_PDU_ICMP_ECho (data) and IPv4_packet t_IPv4_packet (ext_headers:=omit) may have the incorrect setting for ICMP in ICMP2ETH.ttcn.
We are using the loaded ICMP2ETH.ttcn and cfg and libraries used previously in ICMP_TranslPort.tgz for port translation.
We are finding that the ICMP received are proto = 6 which is as you stated TCP and we are looking into it....Thx for the info on Libpcap
2. Dual port:
And this may also impact the ICMP2ETH.ttcn for dual port (ICMP.tgz):
https://www.eclipse.org/forums/index.php/t/1068359/
We made changes and added a system port in original ICMP2ETH.ttcn to pass the mapping:
type component MTC
{
port IcmpPort Icmp_PCO; // self port
port LANL2asp_PT Lan_PCO; // added system port
}
But it's failing further down the path at 'function dec_ASP_LANL2_Icmp' as the received packet is in TCP (proto=6) while we expect ICMP (proto=1):
if (v_IPv4_packet.header.proto ==1)
Regards - David
Note:
- We are relying for proto definition in IP_Types.ttcn
// ICMP and ICMPv6 definitions (CR_TR00017206)
const LIN1 c_ip_proto_tcp := 6;
const LIN1 c_ip_proto_icmp := 1;
const LIN1 c_ip_proto_icmpv6 := 58;
[Updated on: Tue, 16 October 2018 15:30] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796622 is a reply to message #1796571] |
Tue, 16 October 2018 14:38 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
1. Translation Port
- On the wireshark, I'm sending ICMP from 10.20.30.16 to 10.201.8.41.
- We can see that ICMP is sent in frame 1716, 2738 of the wireshark attachment (see picture)
- On the destination 10.201.8.41, ICMP payload sent is received as TCP (see attached wireshark icmp_dest.pcap) and we are also investigating
Would you know where I can fetch the external function f_IPv4_dec ?
BTW, we are able to ping from 10.20.30.16 to 10.201.8.41 and the ICMP is fine.
Note: (192.168.36.156 is my PC)
2. Dual Port
Same result, why f_IPv4_dec does not decode (see wireshark below) ?
MTC@ttcn-l2: the received ASP_LANL2 msg is'450000344A0B40004006D3140A141E0FC0A834D9270FC47D939A282B7D158A4480100D7E1DCB00000101080A002581B9002581B9'O
MTC@ttcn-l2: f_dec_PDU_ICMP(): Stream before decoding
'270FC47D939A282B7D158A4480100D7E1DCB00000101080A002581B9002581B9'O
MTC@ttcn-l2: f_dec_PDU_ICMP(): Decoded @ICMP_Types.PDU_ICMP: { unknown := '270FC47D939A282B7D158A4480100D7E1DCB00000101080A002581B9002581B9'O }
MTC@ttcn-l2: result is{ unknown := '270FC47D939A282B7D158A4480100D7E1DCB00000101080A002581B9002581B9'O }
MTC@ttcn-l2: ICMP1 received!!
MTC@ttcn-l2: Entering f__IPv4__dec
MTC@ttcn-l2: Entering Decode_IPv4_extension_headers
MTC@ttcn-l2: { header := { ver := 4, hlen := 5, tos := 0, tlen := 86, id := 62438, res := '0'B, dfrag := '1'B, mfrag := '0'B, foffset := 0, ttl := 63, proto := 6, cksum := 10775, srcaddr := 'C0A834D9'O, dstaddr := '0A141E0F'O }, ext_headers := omit, payload := 'C47D270F7D158A44939A282B801800DD64B500000101080A002581B9002581B9210185DE98AD248CDE572D166D6F68616E2049434D50312072656365697665642121'O }
Regards - David
Attachment: ICMP.PNG
(Size: 79.50KB, Downloaded 80 times)
Attachment: icmp_dest.pcap
(Size: 0.94KB, Downloaded 46 times)
[Updated on: Tue, 16 October 2018 17:03] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796644 is a reply to message #1796622] |
Tue, 16 October 2018 20:12 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
- We suspect the following for both translation and dual port case. ICMP2ETH.ttcn is incomplete as the response is not checked due to line 234: []Icmp_PCO.receive { repeat;}
- For both cases in the wireshark trace, TTCN sends ICMP request on port 9999 defined in *.cfg but the destination server never receives the ICMP request, as opposed to ping command which is received in the destination server. Could this problem be port related ?
Should ICMP2ETH.ttcn contain a received payload validation as: []Icmp_PCO.receive (???) { repeat;} ?
Regards - David
[Updated on: Tue, 16 October 2018 20:57] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796659 is a reply to message #1796644] |
Wed, 17 October 2018 02:52 |
Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
Hi Elemer,
On similar subject, i am using a dual port for ICMP ping but yet to succeed in recieving an ICMP_EchoReply.
2018/Oct/17 02:28:51.612087 TESTCASE ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:223 Test case tc_ICMP_echo started.
2018/Oct/17 02:28:51.612135 PARALLEL ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:223 Initializing variables, timers and ports of component type ICMP2ETH.MTC inside testcase tc_ICMP_echo.
2018/Oct/17 02:28:51.612176 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:223 Port Icmp_PCO was started.
2018/Oct/17 02:28:51.612247 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:223 Port ASPLan_PCO was started.
2018/Oct/17 02:28:51.612254 PARALLEL ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:223 Component type ICMP2ETH.MTC was initialized.
2018/Oct/17 02:28:51.612264 PARALLEL ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:228 Mapping port mtc:Icmp_PCO to system:ASPLan_PCO.
2018/Oct/17 02:28:51.612600 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:228 LANL2asp__PT_PROVIDER::get_iface_mtu(ens3): MTU is 1450
2018/Oct/17 02:28:51.642026 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:228 Port Icmp_PCO was mapped to system:ASPLan_PCO.
2018/Oct/17 02:28:51.642469 PARALLEL ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:228 Map operation of mtc:Icmp_PCO to system:ASPLan_PCO finished.
2018/Oct/17 02:28:51.642669 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:234 Sent on Icmp_PCO to system @ICMP_Types.PDU_ICMP : { echo := { type_field := 8, code := 0, checksum := '0000'O, identifier := '0002'O, sequence_number := '00C9'O, data := '6162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O ("abcdefghijklmnopqrstuvwabcdefghi") } }
2018/Oct/17 02:28:51.642717 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:135 Encoding PDU_ICMP: { echo := { type_field := 8, code := 0, checksum := '0000'O, identifier := '0002'O, sequence_number := '00C9'O, data := '6162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O ("abcdefghijklmnopqrstuvwabcdefghi") } }
2018/Oct/17 02:28:51.642783 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:135 PDU_ICMP after encoding: '08004C91000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O
2018/Oct/17 02:28:51.642829 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:144 Entering f__IPv4__enc__eth
2018/Oct/17 02:28:51.642849 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:144 Encoding IPv4_packet: { header := { ver := 4, hlen := 5, tos := 0, tlen := 10, id := 50000, res := '0'B, dfrag := '0'B, mfrag := '0'B, foffset := 0, ttl := 128, proto := 1, cksum := 0, srcaddr := 'C0A834D9'O, dstaddr := '0AC90829'O }, ext_headers := omit, payload := '08004C91000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O }
2018/Oct/17 02:28:51.643156 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:144 Entering Encode_IPv4_extension_headers
2018/Oct/17 02:28:51.643245 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:144 Entering Encode_IPv4_ESP_tails
2018/Oct/17 02:28:51.643315 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:146 Entering f__IPv4__checksum
GETTING THE ERROR "Incoming message of type @LANL2asp_Types.ASP_LANL2 could not be handled by the type mapping rules on port Icmp_PCO. The message was discarded." as shown in the log below. How to avoid this error?
2018/Oct/17 02:28:51.644030 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:234 Outgoing message was mapped to @LANL2asp_Types.ASP_LANL2 : { eth_dst_addr := '0090FB60E1EC'O, eth_src_addr := 'FA163EFADCED'O, type_field := '0800'O, eth_src_ip_addr := 'C0A834D9'O, eth_dst_ip_addr := '0AC90829'O, payload := '4500003CC350000080016EFDC0A834D90AC9082908004C91000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O }
2018/Oct/17 02:28:51.644137 USER ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:235 mohan I have sent ECHO Request
2018/Oct/17 02:28:51.644165 TIMEROP ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:236 Start timer t_time: 4 s
2018/Oct/17 02:28:51.653162 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:237 Message enqueued on Icmp_PCO from system @LANL2asp_Types.ASP_LANL2 : { eth_dst_addr := 'FA163ED742B7'O, eth_src_addr := 'FA163EFADCED'O, type_field := '0800'O, eth_src_ip_addr := <unbound>, eth_dst_ip_addr := <unbound>, payload := '4500004B521840004006CAF00A141E0FC0A834D99824270F820A424E170B7130801800DD1DE200000101080A00AA12AC00AA12A41612000849636D705F50434F0A4153504C616E5F50434F'O } id 1
2018/Oct/17 02:28:51.653214 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:183 Entering f__IPv4__dec
2018/Oct/17 02:28:51.653280 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:183 Entering Decode_IPv4_extension_headers
2018/Oct/17 02:28:51.653314 DEBUG ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:183 { header := { ver := 4, hlen := 5, tos := 0, tlen := 75, id := 21016, res := '0'B, dfrag := '1'B, mfrag := '0'B, foffset := 0, ttl := 64, proto := 6, cksum := 51952, srcaddr := '0A141E0F'O, dstaddr := 'C0A834D9'O }, ext_headers := omit, payload := '9824270F820A424E170B7130801800DD1DE200000101080A00AA12AC00AA12A41612000849636D705F50434F0A4153504C616E5F50434F'O }
2018/Oct/17 02:28:51.653353 USER ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:184 the received ASP_LANL2 msg is'4500004B521840004006CAF00A141E0FC0A834D99824270F820A424E170B7130801800DD1DE200000101080A00AA12AC00AA12A41612000849636D705F50434F0A4153504C616E5F50434F'O
2018/Oct/17 02:28:51.653419 USER ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:194 failed test-case
2018/Oct/17 02:28:51.653438 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:237 Incoming message of type @LANL2asp_Types.ASP_LANL2 could not be handled by the type mapping rules on port Icmp_PCO. The message was discarded.
2018/Oct/17 02:28:51.653461 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:237[b] Message enqueued on Icmp_PCO from system @LANL2asp_Types.ASP_LANL2 : { eth_dst_addr := 'FA163EFADCED'O, eth_src_addr := 'FA163ED742B7'O, type_field := '0800'O, eth_src_ip_addr := <unbound>, eth_dst_ip_addr := <unbound>, payload := [/b]'4500004B521840003F06CBF0C0A834D90A141E0F9824270F820A424E170B7130801800DDFE8D00000101080A00AA12AC00AA12A41612000849636D705F50434F0A4153504C616E5F50434F'O } id 1
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796660 is a reply to message #1796644] |
Wed, 17 October 2018 02:59 |
Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
Hi Elemer,
While using dual ports for testing ICMP echo and echo reply, the mapping is successful between the component port and the system port and also i can view the ICMP Echo request being sent to the Systme Port. But when receiving the Echo Request the followign error messages is seen. I tried various combinations of port types and ASP LANL2, but nothing worked. Can you help me in understanding the meaning of this sentence? Also, i see that the initial message that goes from the component port to the system port is having Proto as 1 but on the reply, from SystemPort, the proto is always 6. What i also understand is for ASP_LANL2 we need not use the config files for adjusting the values and therefore, assume that if we send Proto as 1 we should receive back the proto as 1. Do we need to use any delays, before we shut the ports after the execution of the testcase? May be it takes sometime for the reply to reach, before which probably the ports are shutdown? Could that be a solution? Need your help in understanding the literal meaning of this sentence below.
Incoming message of type @LANL2asp_Types.ASP_LANL2 could not be handled by the type mapping rules on port Icmp_PCO. The message was discarded.
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796665 is a reply to message #1796644] |
Wed, 17 October 2018 06:47 |
|
Hi David,
the intention was never to present a complete industrial-robustness code but a simple example for the usage of the translation port.
Yes, it is a good idea to validate the received message, even with a template tailored to the expected answer.
Now there seems to be a confusion around ICMP and ports: ICMP does not have ports the same way TCP or UDP has,
The TCP port you see in the config file:
[MAIN_CONTROLLER]
TCPPort := 9999
is for Titan internal communication.
According to the wireshark trace the Echo requests are sent apparently correct:
Why they don't reach the destination I can't 'tell. I suggest you compare a wireshark trace of ping command and a trace of what Titan sends and configure it accordingly.
Best regards
Elemer
-
Attachment: ping.png
(Size: 66.29KB, Downloaded 1125 times)
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796670 is a reply to message #1796665] |
Wed, 17 October 2018 09:52 |
|
Hi David,
one more thing:
why don't you ry it locally, on teh loop interface, with src and dest IP set to 127.0.0.1 ?
This is how it was intended to be run in the first place.
This will eliminate most of the non-related influences and will help you to understand better how the code works.
After that you van move the target to a different machine.
Just a thought
BR
Elemer
|
|
| | | | |
| Re: Translation ports vs dual-faced ports part2 [message #1796738 is a reply to message #1796736] |
Thu, 18 October 2018 09:48 |
|
Hi David,
here's the quick fix:
change the translation port declaration from :
//Translation port
type port IcmpPort message map to LANL2asp_PT{
in PDU_ICMP from ASP_v2_LANL2 with dec_ASP_v2_LANL2_Icmp();
out PDU_ICMP to ASP_LANL2 with enc_PDU_ICMP();
in Bool3, Bool4;
in ASP_LANL2_Error, ASP_LANL2_open_result, ASP_v2_LANL2_Error, ASP_LANL2;
}
to
//Translation port
type port IcmpPort message map to LANL2asp_PT{
// in PDU_ICMP from ASP_v2_LANL2 with dec_ASP_v2_LANL2_Icmp();
in PDU_ICMP from ASP_LANL2 with dec_ASP_LANL2_Icmp();
out PDU_ICMP to ASP_LANL2 with enc_PDU_ICMP();
in Bool3, Bool4;
in ASP_LANL2_Error, ASP_LANL2_open_result, ASP_v2_LANL2_Error, ASP_v2_LANL2;
}
Here's the reason:
the port is prepared to receive two categories of L2 messages, version 1 and version 2 ; the translation port was assuming with V2 (ASP_V2_LANL2), while you receive v1. (ASP_LANL2)
also , if you add to
function dec_ASP_LANL2_Icmp (in ASP_LANL2 par_msg, out PDU_ICMP result )
if (v_IPv4_packet.header.proto ==1)//ICMP
{
:
:
}
else {
log("Non-ICMP message received!!")
port.setstate(4); //discard
}
this will get rid of unwanted non_ICMP messages
Please test it and tell me the results.
BR
Elemer
|
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796742 is a reply to message #1796741] |
Thu, 18 October 2018 10:43 |
|
The usage of ASP_LANL2 and ASP_v2_LANL2 depends on the number of network interfaces
in the host:
if there's only one, port_mode has to be set to single_interface and ASP_LANL2 will be used
if there're several , port_mode has to be set to multiple_interface and ASP_v2_LANL2 will be used
ASP_v2_LANL2 has an interface id field not present on ASP_LANL2, which field permits addressing different network interfaces
I hope this makes it clearer
BR
Elemer
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796754 is a reply to message #1796742] |
Thu, 18 October 2018 13:45 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
Thx for your prompt response.
1. We had a compiling error on line 204 and made the following change:
../TestObjects/Features/L2Net/ICMP2ETH.ttcn:204.20: error: The value of the first parameter must be 0, 1, 2 or 3.
- from
port.setstate(4); //discard
- to
port.setstate(3); //discard
2. Translation and dual port issue for us:
The component itself is the L2 (TTCN-3 executable) component ICMP, that we are currently working with and the SUT Adapter is the port from where the communication from TTCN gets out to the SUT. We have to trigger the run time interfaces by sending the right message from the executable to the SUT Adapter to open the interface of the Adapter towards the SUT.
We are triggering the ICMP Echo Request now with ICMP protocol, which is getting queued so it times out and fails because we assume the connection does not happen to the external SUT and there is no response for the request we send.
Could you help us on this issue ?
(We are looking at this blog which is quiet similar)
https://www.eclipse.org/forums/index.php/m/1784043/?srch=interface#msg_1784043
Regards - David
[Updated on: Thu, 18 October 2018 14:21] Report message to a moderator |
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796765 is a reply to message #1796762] |
Thu, 18 October 2018 15:33 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
1. Our compiler version is: /home/ubuntu/ttcn3-6.3.pl0-linux64-gcc5.4-ubuntu16.04.tgz
2. Using your ICMP2ETH.ttcn and with 127.0.0.1 ip_address for both, we still do not get the echo_reply as displayed in your logs:
2018/Oct/18 03:12:52.337827 USER ICMP2ETH.ttcn:179 ICMP received!!
2018/Oct/18 03:12:52.337864 PORTEVENT ICMP2ETH.ttcn:180 The state of the Icmp_PCO port was changed by a setstate operation to translated.
2018/Oct/18 03:12:52.337876 PORTEVENT ICMP2ETH.ttcn:248 Incoming message was mapped to @ICMP_Types.PDU_ICMP : { echo_reply := { type_field := 0, code := 0, checksum := '5491'O, identifier := '0002'O, sequence_number := '00C9'O, data := '6162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O ("abcdefghijklmnopqrstuvwabcdefghi") } } id 1
Would you mind uploading your *.cfg ?
Regards - David
[Updated on: Thu, 18 October 2018 16:55] Report message to a moderator |
|
| | | | | | |
| Re: Translation ports vs dual-faced ports part2 [message #1796776 is a reply to message #1796772] |
Thu, 18 October 2018 18:24 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
Same result for 3 setup condition: real and localhost and based on ping.
Regards - David
2018/Oct/18 18:03:31.562189 DEBUG_UNQUALIFIED ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:139(function:enc_PDU_ICMP) Entering f__IPv4__enc__eth
2018/Oct/18 18:03:31.562197 DEBUG_UNQUALIFIED ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:139(function:enc_PDU_ICMP) Encoding IPv4_packet: {
header := {
ver := 4,
hlen := 5,
tos := 0,
tlen := 10,
id := 50000,
res := '0'B,
dfrag := '0'B,
mfrag := '0'B,
foffset := 0,
ttl := 128,
proto := 1,
cksum := 0,
srcaddr := 'C0A834D8'O,
dstaddr := '0AC90829'O
},
ext_headers := omit,
payload := '08004C83000200D76162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O
}
2018/Oct/18 18:03:31.562223 DEBUG_UNQUALIFIED ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:139(function:enc_PDU_ICMP) Entering Encode_IPv4_extension_headers
2018/Oct/18 18:03:31.562231 DEBUG_UNQUALIFIED ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:139(function:enc_PDU_ICMP) Entering Encode_IPv4_ESP_tails
2018/Oct/18 18:03:31.562239 DEBUG_UNQUALIFIED ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:141(function:enc_PDU_ICMP) Entering f__IPv4__checksum
2018/Oct/18 18:03:31.562246 DEBUG_UNQUALIFIED ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:141(function:enc_PDU_ICMP) Entering Calculate_cksum
2018/Oct/18 18:03:31.562254 PORTEVENT_SETSTATE ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:151(function:enc_PDU_ICMP) The state of the Icmp_PCO port was changed by a setstate operation to translated.
2018/Oct/18 18:03:31.562279 PORTEVENT_DUALSEND ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:239(testcase:tc_ICMP_echo) Outgoing message was mapped to @LANL2asp_Types.ASP_LANL2 : {
eth_dst_addr := '0090FB60E1EC'O,
eth_src_addr := '307C5E1288C0'O,
type_field := '0800'O,
payload := '4500003CC350000080016EFEC0A834D80AC9082908004C83000200D76162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O
}
2018/Oct/18 18:03:31.562317 TIMEROP_START ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:240(testcase:tc_ICMP_echo) Start timer t_time: 4 s
2018/Oct/18 18:03:35.562340 TIMEROP_TIMEOUT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:245(testcase:tc_ICMP_echo) Timeout t_time: 4 s
2018/Oct/18 18:03:35.562512 PARALLEL_UNQUALIFIED ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:252(testcase:tc_ICMP_echo) Unmapping port mtc:Icmp_PCO from system:Lan_PCO.
[Updated on: Thu, 18 October 2018 18:25] Report message to a moderator |
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796782 is a reply to message #1796778] |
Thu, 18 October 2018 19:59 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
With your ICMP2ETH.ttcn and our config file, we get the following result.
Based on your logs, we are missing this part below and can it be resolved in 6.4 due to missing libraries ?...it's regarding the second part:
The component itself is the L2 (TTCN-3 executable) component ICMP, that we are currently working with and the SUT Adapter is the port from where the communication from TTCN gets out to the SUT. We have to trigger the run time interfaces by sending the right message from the executable to the SUT Adapter to open the interface of the Adapter towards the SUT.
We are triggering the ICMP Echo Request now with ICMP protocol, which is getting queued so it times out and fails because we assume the connection does not happen to the external SUT and there is no response for the request we send.
Regards - David
2018/Oct/18 03:12:52.337537 PORTEVENT ICMP2ETH.ttcn:248 Message enqueued on Icmp_PCO from system @LANL2asp_Types.ASP_LANL2 : { eth_dst_addr := '000C29FC5671'O, eth_src_addr := '005056C00008'O, type_field := '0800'O, payload := '4500003C30130000800120DBC0A83401C0A8348100005491000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O } id 1
2018/Oct/18 03:12:52.337568 PORTEVENT ICMP2ETH.ttcn:248 The state of the Icmp_PCO port was changed by a setstate operation to unset. Information: by test environment.
2018/Oct/18 03:12:52.337577 DEBUG ICMP2ETH.ttcn:173 Entering f__IPv4__dec
2018/Oct/18 03:12:52.337640 DEBUG ICMP2ETH.ttcn:173 Entering Decode_IPv4_extension_headers
2018/Oct/18 03:12:52.337681 DEBUG ICMP2ETH.ttcn:173 { header := { ver := 4, hlen := 5, tos := 0, tlen := 60, id := 12307, res := '0'B, dfrag := '0'B, mfrag := '0'B, foffset := 0, ttl := 128, proto := 1, cksum := 8411, srcaddr := 'C0A83401'O, dstaddr := 'C0A83481'O }, ext_headers := omit, payload := '00005491000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O }
2018/Oct/18 03:12:52.337734 DEBUG ICMP2ETH.ttcn:177 f_dec_PDU_ICMP(): Stream before decoding: '00005491000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O
2018/Oct/18 03:12:52.337778 DEBUG ICMP2ETH.ttcn:177 f_dec_PDU_ICMP(): Decoded @ICMP_Types.PDU_ICMP: { echo_reply := { type_field := 0, code := 0, checksum := '5491'O, identifier := '0002'O, sequence_number := '00C9'O, data := '6162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O ("abcdefghijklmnopqrstuvwabcdefghi") } }
2018/Oct/18 03:12:52.337827 USER ICMP2ETH.ttcn:179 ICMP received!!
[Updated on: Thu, 18 October 2018 21:04] Report message to a moderator |
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796801 is a reply to message #1796791] |
Fri, 19 October 2018 05:55 |
|
Hi Mohan,
I'm a bit surprised it turned out to be so difficult, usually it's more straightforward; sorry for this, I added myself to the confusion.
The TTCN-3 code is quite simple so all I can suggest you add log statements at different points in the code and see how the message progresses ;
again the code was not meant to be a demo for ICMP , but rather a demo for dual/translation port features.
My initial log was from a VM as well, that's the simplest from networking point of view.
Don't lose your faith, once it will start to work it will be rock solid.
BR
Elemer
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796825 is a reply to message #1796801] |
Fri, 19 October 2018 12:42 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
1. For both translation and dual port, the wireshark now shows the echo_reply after we switch the floating ip address to internal one, however TTCN does not decode the received message.....this is what we are investigating...Thx for your support.
2. On a different subject, is it possible to fetch the data from an external file instead of an actual value in the ICMP2ETH.cfg ?
For instance in [Define] subsection of ICMP2ETH.cfg , would it be possible to define the mac address from a list of source mac address listed in an external file MacAddress.txt:
[Define]
eth_mac_address_source = "MacAddress.txt"
Regards - David
[Updated on: Fri, 19 October 2018 13:09] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796832 is a reply to message #1796825] |
Fri, 19 October 2018 14:32 |
Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
Hi Elmer,
Thanks for your suggestion. The discarding of the reply is it because of the below statement? because i do not see anything happening with the incoming reply. I am not able to use "log" message here as it is not allowing. Any hints would help.
with
{
extension "user LANL2asp_PT
out(
PDU_ICMP -> ASP_LANL2: function(enc_PDU_ICMP)
)
in(
ASP_LANL2 -> PDU_ICMP : function(dec_ASP_LANL2_Icmp),
- : discard;
ASP_LANL2_Error -> - : discard;
ASP_v2_LANL2 -> PDU_ICMP : function(dec_ASP_v2_LANL2_Icmp),
- : discard;
ASP_LANL2_open_result -> - : discard;
ASP_v2_LANL2_Error -> - : discard
)"
}
Thanks
Mohan Raj
[Updated on: Fri, 19 October 2018 14:35] Report message to a moderator |
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796854 is a reply to message #1796846] |
Fri, 19 October 2018 18:44 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
type port IcmpPort (PT2) is already defined as the internal interface in ICMP2ETH.ttcn:
type port IcmpPort message map to LANL2asp_PT
We believe that translation and dual port are missing the external LANL2asp_PT type port interface (PT1) as you described in the programmer guide in section 4.22.10 and in LANL2asp_PortType.ttcn:
type port LANL2asp_PT message
to bypass this line as it's not reading from the queue in PT2
in PDU_ICMP from ASP_LANL2 with dec_ASP_LANL2_Icmp();
The LANL2 test port uses Libpcap for filtering the received packets.
Would you know how it can be declared in ICMP2ETH.ttcn ?
Regards - David
[Updated on: Fri, 19 October 2018 20:27] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796870 is a reply to message #1796854] |
Sat, 20 October 2018 09:16 |
|
Hi David,
"We believe that translation and dual port are missing the external LANL2asp_PT type port interface (PT1) as you described in the programmer guide in section 4.22.10 and in LANL2asp_PortType.ttcn:
type port LANL2asp_PT message "
this declaration is in LANL2asp_PortType.ttcn and it is imported
I suggest we focus on the translation port and let go of the dual port as that is an obsolete non-standard solution.
The translation port will give you more flexibility.
Reading config files from an external text file is not supported and I don't see any advantage of that.
Can you please send me the latest logs ?
So you are saying that you see ping reply in wireshark, but there's no "ICMP received!!" in the Titan log?
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1796927 is a reply to message #1796870] |
Mon, 22 October 2018 13:30 |
Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
Hi Elmer,
For the dual port implementation we have the ping and reply working now towards the test system. The problem was with the destination mac. We had to give the GW mac in the destination mac since the test system was in a different subnet from the TTCN itself. Once we changed the destination mac to the GW and the source mac as the ttcn, we were able to ping the test system IP (from the GW) and get a reply back to TTCN . This was the reason why we missed to see the request on the test system side and we assumed, that the interface is not open. This works fine now. This is the same case with the both the translation as well as the dual port.
We need the following clarification:
1. Yes, as you said the reply, seems to be not processed or decoded in both cases(dual-port and translation port). That is, though we see the echo reply in the wireshark, we are not able to decode the message and see the ICMP recevied in the TTCN logs.
2. Since, the dual port implementation is the only one described in the documentation, we just followed it. Do you still suggest to drop it, since the basic L2 test case seems to be fine with the dual port except for the reading the recieved message.
Thanks
Mohan Raj
[Updated on: Mon, 22 October 2018 14:01] Report message to a moderator |
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1796959 is a reply to message #1796936] |
Tue, 23 October 2018 07:58 |
|
Hi David, Mohan,
I'm sorry , it's quite difficult to debug it based on your feedback. If the dual port implementation works halfway, just keep it, but try to understand the translation port as that will take you further.
I will attach the code I'm using on a Ubuntu 18.04 with the log it generated this morning. All you are supposed to do with it is to change IP and MAC addresses in the config file appropriately.
You can see that the ICMP messages are nicely decoded.
Try to build and run this project form scratch.
The translation port is well described in the standard, see ETSI ES 202 781 V1.6.1 (2018-05) , that's why we did not add it to the documentation, while the dual port is a non standard feature.
the compiler version I'm using is
TTCN-3 and ASN.1 Compiler for the TTCN-3 Test Executor
Product number: CRL 113 200/6 R3B
Build date: Mar 21 2018 07:43:09
Compiled with: GCC 7.3.0
Using OpenSSL 1.1.0d 26 Jan 2017
you may have 6.4.0 which should be perfectly fine
BR
Elemer
-
Attachment: ICMP_20181023.tgz
(Size: 305.43KB, Downloaded 66 times) -
Attachment: ICMP.log
(Size: 938.98KB, Downloaded 54 times)
|
|
| | | | | | | | | | | |
| Re: Translation ports vs dual-faced ports part2 [message #1797077 is a reply to message #1797055] |
Wed, 24 October 2018 20:50 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
We have migrated to a multiple interface ASP_v2_LANL2 for ICMP flooding but we have an issue on the interface_id.
In multiple interface what we understand is before sending the ASP_v2_LANL2, the interface needs to be open using open_interface and receive open_result. We basically should pack the interface_name in open_interface and get an interface_id in open_Result., which can be further handled in ASP_v2_LANL2. Is our understanding correct?
If we try directly sending the ASP_v2_LANL2, we end up in this error of interface id in both dual port and translation port. In addition, in dual ports we see a clear error reported in ASP_LANL2_Error "INVALID_INTERFACE_ID".
The above multiple interface scenario is to have multiple source mac's push ping traffic to a single destination. This is the idea behind the above scenario.
Could you help us based on the attached logs and config ?
Regards - David
2018/Oct/24 20:29:19.527422 PORTEVENT ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:278(testcase:tc_ICMP_echo) Outgoing message was mapped to @LANL2asp_Types.ASP_v2_LANL2 : { interface_id := 1, eth_dst_addr := 'FA163E11AA68'O, eth_src_addr := 'FA163EB4D20F'O, type_field := '0800'O, payload := '4500003CC35000008001272B0A141E100A141E0E08004C91000200C96162636465666768696A6B6C6D6E6F7071727374757677616263646566676869'O }
2018/Oct/24 20:29:19.527563 ERROR ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:278(testcase:tc_ICMP_echo) Dynamic test case error: LANL2asp_PT('Lan_PCO'): Invalid inteface id was specified '1'.
2018/Oct/24 20:29:19.527641 VERDICTOP ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:278(testcase:tc_ICMP_echo) setverdict(error): none -> error
2018/Oct/24 20:29:19.527692 EXECUTOR ../TestObjects/Features/L2Net/ICMP2ETH.ttcn:278(testcase:tc_ICMP_echo) Performing error recovery.
[Updated on: Wed, 24 October 2018 20:50] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1797099 is a reply to message #1797077] |
Thu, 25 October 2018 08:42 |
|
Hi David,
you are absolutely right,
with port_mode := "multiple_interface"
you need to send first a message of type ASP_LANL2_open_interface, containing the interface name as parameter,
to which the port responds with ASP_LANL2_open_result , containing the interface_id to be used from now on.
This can be followed by ASP_v2_LANL2 messages containing the payload.
This assumes appropriate mapping between an upper port say ICMP_PCO able to receive/send ICMP messages ( in fact a composite structure containing ICMP messages and an interface_id , see below)
and the lower LANL2 port.
Problem is , if you want to keep the upper port ICMP only, then you have to resolve the following within the mapping:
-at the reception of the first PDU_ICMP, the above described handshake has to take place
this can be done with the translation port only, with an extension described in the forum as stateful translation port.
So I suggest the following:
-Let the upper port accept both a record consisting of ICMP messages and interface_id and ASP_v2_LANL2 messages
the latter will be mapped directly to the lower port, with no modification
-at start , send from the TTCN-3 code an "open interface" and receive "open_result"
as many times as you think it's needed
save the interface_ids in a table which contains interface_name and interface_id pairs
now you can send a record with PDU_ICMP and an interface_id you want to associate it with
{
PDU_ICMP pdu_icmp,
integer interface_id,
}
based on these two pieces of info you can assemble the IPv4 packet, and then the L2 packet
of course port declarations and translation will have to be modified accordingly
If you browse through my examples of translation ports in this forum you will see similar solutions
Please let me know if this helps
BR
Elemer
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1797107 is a reply to message #1797099] |
Thu, 25 October 2018 11:18 |
Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
Hi,
Do you think we are on the right path to have mutiple mac's ping to the destination? I introduced yesterday icmp type fiels for open_interface and open result and added two fucnctions to send and receive these messges. I can see in logs that i am able to send the open_interface message but still not successful in receive the open_Result. THis is in dual_ports, as i am dealing with that.
1. Is there a way to pass parameters between funcitons without using module parameters? I am tring to pass the interface id received in open_result to the lanl2 echo. Since, without this, i am receiveing INVALID_INTERFACE_ID, since i am hard coding it now.
2. Iam attaching the code part currently for your review. Kindly review the same.
As of now, i am not receiving the Open_Result. Instead i am receiving LAN_L2_Error. I am not sure how after sending the open_interface control goes to the ASP_LANL2 message sending part, since according to the code, it should wait for receiving the open_result. Or is it because, it is receiving LAN_L2_Error message, which it discards and goes to send LANL2_echo_message? If we are able to receive the open_result and pass the paramter to the LANL2 message, we should be able to ping using the changed SOURCE mac addr which we are not able to succeed currently with single interface implementation.
Need your views on this.
Best Regards, Mohan Raj
[Updated on: Thu, 25 October 2018 11:45] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1797133 is a reply to message #1797107] |
Thu, 25 October 2018 22:41 |
Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
PLEASE IGNORE MY PREVIOUS MESSAGE. I have some updates on the status.
The multi interface dual-port mode seems to be working. Although, i want some clarification.
I am attaching the code part and the successful and unsuccessful logs.
The following are the clarifications i need:
1. I dont send close interface. Hope that is fine.
2. In the code i always have interface id as 0 sent in ASP_v2_LANL2 messages as interface id. I want to change them for each interface id. I am missing something here. Any indications would help.
3. Pointers to documentation on multiple interface as the documentation i have seen so far, has very minimal documentation
For the unsuccessful scenario, i am not sure, why the echo doesn't get any response! Still pondering.
map(self:Icmp_PCO, system:ASPLan_PCO);
for (var integer j := 1; j <= nbr_macAddress; j := j + 1)
{
v_cycle:=int2oct(j+200,2);
Icmp_PCO.send(t_asp_open_interface(v_cycle));
t_time.start;
alt {
[]Icmp_PCO.receive{log ("Recevied open_result ------------",j)};
[]t_time.timeout{setverdict(fail)}
}
t_time.stop;
Icmp_PCO.send(t_PDU_ICMP_ECho(v_cycle));
t_time.start;
alt {
[]Icmp_PCO.receive(t_PDU_ICMP_EchoReply(v_cycle)){setverdict(pass)};
[]t_time.timeout {setverdict(fail)}
}
t_time.stop;
[Updated on: Thu, 25 October 2018 22:45] Report message to a moderator |
|
| | |
| Re: Translation ports vs dual-faced ports part2 [message #1797182 is a reply to message #1797167] |
Sat, 27 October 2018 06:30 |
|
Hi David,
you can put any source address in the TTCN-3 code or config file, there's no restriction here.
But if you put in something that does not match the network , that is the HW of the network interface , it will not work.
So if you thought that somehow Titan will create virtual interfaces, that will not happen.
If you want to work with multiple interfaces, you will have to add as many physical interfaces as needed or
somehow create virtual interfaces , but that's beyond my expertise.
Mohan:
1. I dont send close interface. Hope that is fine.
Depends. As I suggested , you should open an interface in the beginning, than send an unlimited number of ICMP messages. If the execution terminates here,
the interface will be closed; however it's more elegant to close it manually.
2. In the code i always have interface id as 0 sent in ASP_v2_LANL2 messages as interface id. I want to change them for each interface id. I am missing something here. Any indications would help.
That's definitely not the way to go. Let's assume you have 4 interfaces say ens1, ens2, ens3, ens4
Than you should send 4 open messages and you should receive 4 interface id's say 0,1,2,3
You need to build a table that associates if name with id
e.g.
ens1 3
ens2 1
ens3 0
ens4 2
and should use these id's when sending ICMP; you should also be aware all the time to which interface you send the ICMP as the reply should be returned on that interface
3. Pointers to documentation on multiple interface as the documentation i have seen so far, has very minimal documentation
you should look into the linux documentation specific to you environment plus standard networking info.
That is not TTCN specific.
BR
Elemer
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1797228 is a reply to message #1797182] |
Sun, 28 October 2018 19:18 |
Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
Hi Elemer,
Thanks for all your reply. It gives us a better view now on why it fails if we give a different source from the ifconfig. And it also gives us a clear view about multiple interfaces. Infact, our intention for using multiple interfaces is with the understanding that TTCN will have mutiple virtual interfaces (in one physical inteface with the same ip). If it is not the case, we need not go for multiple interface at all.
Just one more query, will it consider if we change the mac address by using "ifconfig" by executing a script each time we change the source mac.?
I mean, we will generate using rnd() , random mac address and using "ifconfig ens3 HW ether "generated random mac" change it in the ifconfig and use it. Hope this will work.
Thanks
Mohan Raj
[Updated on: Sun, 28 October 2018 19:24] Report message to a moderator |
|
| | | |
| Re: Translation ports vs dual-faced ports part2 [message #1797310 is a reply to message #1797270] |
Mon, 29 October 2018 19:40 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
For port translation, the frame size (data) is defined as 64 bytes in t_PDU_ICMP_ECho ().
If we were to add multiple frame sizes up to 1518 bytes, does TTCN have a predefined function to validate the max frame allowed per second sent and received for the latency ? or can we predefine the max frame size allowed and latency in the *.cfg ?
Regards - David
[Updated on: Mon, 29 October 2018 20:14] Report message to a moderator |
|
| | | | | | | | |
| Re: Translation ports vs dual-faced ports part2 [message #1797823 is a reply to message #1797567] |
Wed, 07 November 2018 03:24 |
Mohan Raj Janardhan
Messages: 32
Registered: October 2018 |
Member |
|
|
Thanks Elemer, for your clarification. But i doubt, whether the implementation supports it as i did the changes you suggested and it looks like the whole thing reboots each time and it looses the virtual interface. So no use, in this.
Getting into the issue of MAC flooding further, what i clearly see is, we do not have ARP messages for the amount of PINGs, even if we change the MAC address (via RND MAC function). This could mean that, we might have to construct ARP Request and ARP reply for the change of Source MAC and send/ recieve the same to keep the result in ARP cache.
Do you think, the above would work if the port is still kept PDU_ICMP and if we additional type fileds, for ARP_Request and Reply each time, we change the source???? Or do you suggest anyother ways to do this?
May be this what is missing. Because, i do not see the ARP request and reply at all if the MAC changes.
Anyway, i will try this tomorrow and check if this triggers anything which we require for MAC flooding.'
Thanks
Mohan Raj
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1797829 is a reply to message #1797823] |
Wed, 07 November 2018 07:47 |
|
Hi Mohan,
it's not clear what are you doing ; did you create a protocol module for ARP messages with the appropriate encoding and injected the ARP into the L2 ?
I'm sorry I can't figure out if what you are doing is consistent from a) network b) TTCN-3 point of view.
All I could recommend is to keep experimenting as understanding will get you closer to what you wan to achieve.
BR
Elemer
|
|
| |
| Re: Translation ports vs dual-faced ports part2 [message #1797852 is a reply to message #1797850] |
Wed, 07 November 2018 13:11 |
|
Hi Mohan,
that's right, you need to create an ARP protocol module, which has not been yet written.
TitanSim is only partly open sourced, that is the core load library and a number of IoT application libraries.
I don't think it will be of any use for you here, you should go for a simple TTCN-3 solution.
BR
Elemer
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1797865 is a reply to message #1797852] |
Wed, 07 November 2018 16:10 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
1) When we add a oversize payload > 1450, TTCN throws a dynamic error as followed:
Dynamic test case error: LANL2asp_PT('Lan_PCO'): Length of 'payload' is not of correct size (expected: 46-1450, given: 1468 byte). (Resource temporarily unavailable)
setverdict(error): none -> error
I have coded this to pass the intended fault in TTCN, but is there a cleaner catch ?
var charstring error_message := " ...dynamic string error...";
@try {
Icmp_PCO.send(t_PDU_ICMP_ECho(v_cycle));
}
@catch (msg) {
if (not match(msg, error_message)) {
setverdict(fail, "Expected error is: ", dte_message, ", got: ", msg);
}
}
2) One more thing for undersize payload < 46 byte
it seems that v_ASP_LANL2.payload always keep it to 46 bytes even you lower the data under 46 byte.
Regards - David
[Updated on: Wed, 07 November 2018 21:54] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1797889 is a reply to message #1797865] |
Thu, 08 November 2018 08:13 |
|
Hi David,
this is what the port documentation -which BTW I strongly recommend you read it- says about this:
Length of 'payload' is not of correct size (expected: 46-<MTU>, given: <value> byte).
According to [4], the payload size of an Ethernet II frame has to be 46-<MTU> bytes. The standard MTU size is 1500, but if the Jumbograms are supported it can be higher.
This is a network restriction, and it has nothing to do with TTCN-3 or Titan.
BR
Elemer
|
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1797927 is a reply to message #1797889] |
Thu, 08 November 2018 15:56 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
Thx for your response but we had a misunderstanding due to my last incomplete question.
We are now able to spot the CRC error by adding this config value:
system.Lan_PCO.dump_erroneous_frame := "1"
The logs shows the undersize payload (incorrect Ethernet II frame size) on Echo Reply:
LANL2asp_PT('Lan_PCO'): Erroneous packet (size of captured packet is not correct: 43 bytes)
Regards - David
[Updated on: Thu, 08 November 2018 16:05] Report message to a moderator |
|
| | | |
| Re: Translation ports vs dual-faced ports part2 [message #1798134 is a reply to message #1798113] |
Tue, 13 November 2018 07:30 |
|
HI David,
no, this is not supported;
according to the documentation the faulty short packet is discarded :
dump_erroneous_frame
This parameter is optional. If set to "1", when receiving an Ethernet packet smaller than 60 bytes (without CRC) but bigger than 14 bytes the event is logged as warning with the packet size given, and the packet dumped.
However you have the source code so you can modify it it according to what you wan to achieve.
BR
Elemer
|
|
| | | | | | | | | | | |
| Re: Translation ports vs dual-faced ports part2 [message #1799025 is a reply to message #1799000] |
Wed, 28 November 2018 21:36 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
We created 3 distinct template template IPv4_header t_IPv4_header [1..3] for each pertaining destination ip address.
but we came across a problem on port type function type port IcmpPort message map to LANL2asp_PT.
it mainly complained about duplicated receiver port when we added 2 extra:
out PDU_ICMP to ASP_LANL2 with enc_PDU_ICMP1()
out PDU_ICMP to ASP_LANL2 with enc_PDU_ICMP2()
out PDU_ICMP to ASP_LANL2 with enc_PDU_ICMP3()
Should we create a distinct type port IcmpPort message map to LANL2asp_PT for 3 distinct encoding function enc_PDU_ICMPx or did we take the long and convoluted implementation ?
Regards - David
[Updated on: Wed, 28 November 2018 21:46] Report message to a moderator |
|
| | | | |
| Re: Translation ports vs dual-faced ports part2 [message #1803375 is a reply to message #1803370] |
Wed, 27 February 2019 13:58 |
David Laurent
Messages: 68
Registered: September 2018 |
Member |
|
|
Hi Elemer,
- Unlike for dual port, we noticed that we were unable to run multiple test case in ICMP2ETH.cfg with translation port as shown below....would you know why ?
- Furthermore, we were unable to run both test case together as dual port was complaining of IcmpPort.cc and IcmpPort.hh
- Essentially, it looks to us that translation port is a stand alone test case ?
[EXECUTE]
ICMP2ETH.control
ICMP1ETH.control
ICMP3ETH.control
Regards - David
[Updated on: Wed, 27 February 2019 14:04] Report message to a moderator |
|
|
| Re: Translation ports vs dual-faced ports part2 [message #1803411 is a reply to message #1803375] |
Thu, 28 February 2019 09:14 |
|
Hi David,
sorry, I'm not following;
could you please add more details, exemplified with code:
-what is the expected behaviour
-what is the actual behaviour ( examples with logs)
"we were unable to run multiple test cases" does not carry any meaning we can use to solve the problem
BR
Elemer
|
|
| | |
Goto Forum:
Current Time: Wed Jun 23 00:58:27 GMT 2021
Powered by FUDForum. Page generated in 0.07126 seconds |
Search
Help
Register
Login
Home
