Eclipse Community Forums: Eclipse Titan » Translation ports vs dual-faced ports part2

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 02:44

Eclipse User

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

icmpPort.cc
icmpPort.hh

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

Attachment: ICMP_TranslPort.tgz
(Size: 304.40KB, Downloaded 252 times)

[Updated on: Thu, 18 October 2018 05:56] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796370 is a reply to message #1763623]

Thu, 11 October 2018 14:41

Eclipse User

Did you encounter a ipv4 payload problem and get this error:

Size of captured packet is not correct (expected: 14-1514 byte, received: <value>)

Re: Translation ports vs dual-faced ports part2 [message #1796481 is a reply to message #1796370]

Mon, 15 October 2018 02:29

Eclipse User

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 #1796531 is a reply to message #1796481]

Mon, 15 October 2018 15:40

Eclipse User

Here are the logs and wireshark trace.
BTW, this packet error is not there when 'repeat' is removed in ICMP2ETH.ttcn at line 224:
[]Icmp_PCO.receive { repeat;}

Attachment: icmp.pcap
(Size: 9.11MB, Downloaded 183 times)
Attachment: l2.ttcn-david-mtc.log
(Size: 12.05MB, Downloaded 177 times)

[Updated on: Mon, 15 October 2018 16:20] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796571 is a reply to message #1796531]

Tue, 16 October 2018 05:44

Eclipse User

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 #1796576 is a reply to message #1796571]

Tue, 16 October 2018 06:04

Eclipse User

also , can you send me the log in case repeat is removed?

Thanks

Re: Translation ports vs dual-faced ports part2 [message #1796579 is a reply to message #1796576]

Tue, 16 October 2018 06:32

Eclipse User

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 09:02

Eclipse User

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 11:30] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796622 is a reply to message #1796571]

Tue, 16 October 2018 10:38

Eclipse User

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 162 times)
Attachment: icmp_dest.pcap
(Size: 0.94KB, Downloaded 110 times)

[Updated on: Tue, 16 October 2018 13:03] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796644 is a reply to message #1796622]

Tue, 16 October 2018 16:12

Eclipse User

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 16:57] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796659 is a reply to message #1796644]

Tue, 16 October 2018 22:52

Eclipse User

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]

Tue, 16 October 2018 22:59

Eclipse User

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 02:47

Eclipse User

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:

index.php/fa/34093/0/

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 1395 times)

Re: Translation ports vs dual-faced ports part2 [message #1796670 is a reply to message #1796665]

Wed, 17 October 2018 05:52

Eclipse User

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 #1796678 is a reply to message #1796670]

Wed, 17 October 2018 09:22

Eclipse User

Hi Elemer,

We put back the localhost ip address and original config.
In both case scenario (translation and dual), the wireshark is missing the Echo Reply.

Based on your feedback, we now understand that it's a general template and we are reviewing everything.

One more thing, how can I put the libcap filter in *.cfg under one of the paramater category ?

Is this bug resolved ? https://bugs.eclipse.org/bugs/show_bug.cgi?id=534266

Regards - David

[Updated on: Wed, 17 October 2018 14:25] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796680 is a reply to message #1796678]

Wed, 17 October 2018 10:06

Eclipse User

Hi David,

are the interface name and src mac address set properly?

Should match your ifconfig reading.

dest mac address can remain FFFFFFFF.

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1796703 is a reply to message #1796680]

Wed, 17 October 2018 15:33

Eclipse User

Hi Elemer,

Here is the config and test case.

1. As you suggested earlier, we introduce the libcap in the config:
/*Packet filter expression for LibPCAP*/
system.LANL2_PCO.packet_filter := "dst port 68"

2. The missing part is to open an interface before the timeout as described in:
https://www.eclipse.org/forums/index.php/m/1716660/?srch=dst.eth#msg_1716660

type record ETH_FRAME_openInterface {
charstring interface_name,
OCT6 default_src_addr optional,
boolean promisc_mode optional,
charstring packet_filter optional
}

And described in section 2.4 of LANL2asp_CNL113519_1551.doc.

Could you give us a hint on how to open the interface in the test case ?

Regards - David

Attachment: ICMP2ETH.ttcn
(Size: 6.70KB, Downloaded 158 times)
Attachment: ICMP2ETH.cfg
(Size: 1.58KB, Downloaded 124 times)

[Updated on: Wed, 17 October 2018 16:09] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796736 is a reply to message #1796703]

Thu, 18 October 2018 05:28

Eclipse User

Hi David,

I apologize, I found the time to look in the code and you're right , it's completely wrong.

I'll fix it and upload it soonest.

Best regards
Elemer

[Updated on: Thu, 18 October 2018 05:29] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796738 is a reply to message #1796736]

Thu, 18 October 2018 05:48

Eclipse User

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;
}

//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 #1796741 is a reply to message #1796738]

Thu, 18 October 2018 06:22

Eclipse User

Hi David,

pls find the repaired ICMP2ETH.ttcn and the associated log:

This should answer most of your problems.

Please make sure mac addresses etc. are OK and you run it with root privileges.

Sorry for the blunder.

BR

Elemer

Attachment: ICMP2ETH.ttcn
(Size: 4.83KB, Downloaded 184 times)
Attachment: ICMP.log
(Size: 104.65KB, Downloaded 121 times)

Re: Translation ports vs dual-faced ports part2 [message #1796742 is a reply to message #1796741]

Thu, 18 October 2018 06:43

Eclipse User

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 09:45

Eclipse User

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 10:21] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796762 is a reply to message #1796754]

Thu, 18 October 2018 10:46

Eclipse User

Hi David,

for the first issue, please refresh your compiler ;
the latest released 6.4.0 should already support setstate(4) (discard)

I'll come back for the second part.

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1796765 is a reply to message #1796762]

Thu, 18 October 2018 11:33

Eclipse User

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 12:55] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796766 is a reply to message #1796765]

Thu, 18 October 2018 11:57

Eclipse User

Hi David,

there seems to be a misunderstanding,
according to this snippet you do get the echo reply.

I'm not sure what am I missing here.

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1796768 is a reply to message #1796766]

Thu, 18 October 2018 12:02

Eclipse User

Ah sorry , this is from my log;

you need to set src mac address as per ifconfig, dest mac address can be set to "FFFFFFFF",
interface name as per ifconfig
if 127.0.0.1 does not work try to use the real ip address as per ifconfig
theres not much else

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1796769 is a reply to message #1796768]

Thu, 18 October 2018 12:23

Eclipse User

OK
I see there-s a problem ; I'll look into it.

could you try between machines now? with real IP and mac

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1796770 is a reply to message #1796769]

Thu, 18 October 2018 12:26

Eclipse User

Hi Elemer,

We already tried with real ip and mac address without much success
Would the compiler version stop us from receiving the echo_reply ?

This is our version:
ttcn3-6.3.pl0-linux64-gcc5.4-ubuntu16.04.tgz

Should we get this version to align with you ?
ttcn3-6.4.pl0-linux64-gcc7.3-ubuntu18.04.tgz

Regards - David

[Updated on: Thu, 18 October 2018 13:01] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796771 is a reply to message #1796770]

Thu, 18 October 2018 12:32

Eclipse User

Hi David, no,

it's some networking issue ; I'll figure it out.

Re: Translation ports vs dual-faced ports part2 [message #1796772 is a reply to message #1796771]

Thu, 18 October 2018 12:41

Eclipse User

Hi David,

here's what you should do:

ping some external IP through the interface and take a wireshark trace

use the same src, dest mac and src dest IP as in the trace in the config file

that should work

it apears that FFFFFFFF is noot OK for dest mac

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1796776 is a reply to message #1796772]

Thu, 18 October 2018 14:24

Eclipse User

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 14:25] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796778 is a reply to message #1796776]

Thu, 18 October 2018 14:28

Eclipse User

Hi David,

OK, can you send me the wireshark trace for the ping and your config file ?

Re: Translation ports vs dual-faced ports part2 [message #1796782 is a reply to message #1796778]

Thu, 18 October 2018 15:59

Eclipse User

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!!

Attachment: ICMP2ETH.cfg
(Size: 1.69KB, Downloaded 125 times)
Attachment: icmp.pcap
(Size: 5.43MB, Downloaded 509 times)
Attachment: l2.ttcn-david-mtc.log
(Size: 55.49KB, Downloaded 154 times)

[Updated on: Thu, 18 October 2018 17:04] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796791 is a reply to message #1796782]

Thu, 18 October 2018 22:55

Eclipse User

Hi Elemer,

Myself and David are working together on the subject and would like to inform you that, while David is trying for the Translation port scenario, i have been working on the Daul Port for the same scenario. Today, we had a breakthrough in that, when an ICMP ping is done from my VM to David's TTCN we are able to see a reply. Although, after receiving the reply, the TTCN on my end does not decode the message. I just wanted to let you know that the Dual port seem to be working but again, the implementation seems to be not fully done for this.

Just wanted to keep you informed.

Re: Translation ports vs dual-faced ports part2 [message #1796801 is a reply to message #1796791]

Fri, 19 October 2018 01:55

Eclipse User

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 08:42

Eclipse User

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 09:09] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796832 is a reply to message #1796825]

Fri, 19 October 2018 10:32

Eclipse User

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 10:35] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796846 is a reply to message #1796832]

Fri, 19 October 2018 12:48

Eclipse User

Hi Elemer,

Also what we think is, there is message handling for port IcmpPort a snippet of which is attached above, but we do not find the handling for LANL2asp_PT which is on the receiving side. Will this block the processing or the decoding of the received message?

Re: Translation ports vs dual-faced ports part2 [message #1796854 is a reply to message #1796846]

Fri, 19 October 2018 14:44

Eclipse User

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 16:27] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796870 is a reply to message #1796854]

Sat, 20 October 2018 05:16

Eclipse User

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 09:30

Eclipse User

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

Attachment: dual_port_logs.log
(Size: 4.25KB, Downloaded 124 times)
Attachment: test_system_wireshark.pcap
(Size: 3.07KB, Downloaded 119 times)

[Updated on: Mon, 22 October 2018 10:01] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796936 is a reply to message #1796927]

Mon, 22 October 2018 10:48

Eclipse User

Hi Elemer,

A) Same result for translation port and here are the logs as requested.
It timeout as "icmp received" are not generated,
eventhough the Echo reply is there in the wireshark

B} BTW, I'm able to compile, however I have the following red warning in ICMP2ETH.ttcn, (is it related to the compiler version ?):

1. type port IcmpPort message map to LANL2asp_PT at line 116 out PDU_ICMP:
Outgoing message type `@ICMP_Types.PDU_ICMP' of test component port type `@ICMP2ETH.IcmpPort' is not present on the outgoing list of system port type `@LANL2asp_PortType.LANL2asp_PT'

2. function enc_PDU_ICMP at line 152 port.setstate(0);
There is no visible definition with name `setstate' in module `ICMP2ETH'

Regards - David

Attachment: translation.log
(Size: 8.88KB, Downloaded 148 times)
Attachment: icmp.pcap
(Size: 2.29MB, Downloaded 140 times)

[Updated on: Mon, 22 October 2018 15:07] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1796959 is a reply to message #1796936]

Tue, 23 October 2018 03:58

Eclipse User

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 165 times)
Attachment: ICMP.log
(Size: 938.98KB, Downloaded 123 times)

Re: Translation ports vs dual-faced ports part2 [message #1796973 is a reply to message #1796959]

Tue, 23 October 2018 07:55

Eclipse User

Hi Elmer,

What i observe from the log you attached is that the proto is 6 and not 1. If we keep the self port and the system port as Icmp_PCO we also got something similar, though i am not sure if it is exactly the same. If i keep the self port as Icmp_Port and SystemPort as ASPLan_PCO, the proto remains as ICMP(1), but the received message is not processed. Anyway, this is just for your information. We will wait for hte code part so that we can try from our side.

Thanks
Mohan Raj

Re: Translation ports vs dual-faced ports part2 [message #1796975 is a reply to message #1796973]

Tue, 23 October 2018 08:34

Eclipse User

Hi Mohan,

I'm not sure what you mean by "the proto is 6 and not 1",
ICMP was always 1.

https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1796980 is a reply to message #1796975]

Tue, 23 October 2018 09:14

Eclipse User

Hi Elemer,

Thanks for your clarification. I got confused with other messages in the log. Looks like if other messages are received you print out "Non-Icmp messages recieved" and when ICMP message arrives you decode it!

Just one clarification, is there an explanation to the usage of Self and System ports anywhere?

I will try to check the code and provide a feedback.

Thanks
Mohan Raj

Re: Translation ports vs dual-faced ports part2 [message #1797000 is a reply to message #1796980]

Tue, 23 October 2018 14:22

Eclipse User

Hi Elemer,

After removing the "packet_filter", we were able to process the received message. This was actually blocking the message from being received. Both dual port and translation sends and receives echo request and reply.

Thanks for your support!

Thanks
Mohan Raj

Re: Translation ports vs dual-faced ports part2 [message #1797010 is a reply to message #1797000]

Wed, 24 October 2018 01:53

Eclipse User

Hi Mohan,

great,

now the log file is full of garbage from non-icmp messages, so you can insert a filter in the port to discard every such non-icmp message.

Best regards
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797040 is a reply to message #1797010]

Wed, 24 October 2018 07:31

Eclipse User

Hi Elemer,
How do we add this? Is it packet_filter.proto in test port parameters of the configuration file? Any hints would help.

Re: Translation ports vs dual-faced ports part2 [message #1797043 is a reply to message #1797010]

Wed, 24 October 2018 07:51

Eclipse User

Hi Elemer,
Our scenario is to do a Mac flooding by changing the source Mac of the interface and do a ping. In the process of doing this we wanted to see if we can send an arp message. I checked the forum and did not see anything related. Can you send us any indication if you of aware if anyone had tried sending an sto message.

Thanks
Mohan raj

Re: Translation ports vs dual-faced ports part2 [message #1797047 is a reply to message #1797043]

Wed, 24 October 2018 08:11

Eclipse User

Hi Mohan,

packet_filter:="ip proto icmp"

should work

ARP should be OK as well; as we don't have a protocol module available, either you write one with RAW encoding
or assemble the octets with your own functions.

This should go into the payload (PDU_LANL2 )

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797050 is a reply to message #1797047]

Wed, 24 October 2018 08:26

Eclipse User

Hi Mohan,

sorry , the correct expression is

system.Lan_PCO.packet_filter := "proto 1"

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797053 is a reply to message #1797050]

Wed, 24 October 2018 09:49

Eclipse User

Thanks Elemer, it works perfectly fine. One question about having multiple MACs, is it possible we use the multiple interface mode for this? What are the mandatory parameters on this? And is there any limit on the interface number itself. We are needing atleast 9000 mac's for which if we move to multiple interfaces, we will end up creating 9000 interfaces. Is it supported at all?

Thanks
Mohan Raj

Re: Translation ports vs dual-faced ports part2 [message #1797055 is a reply to message #1797053]

Wed, 24 October 2018 10:02

Eclipse User

Hi Mohan,

multiple interface mode should work
for the parameters see documentation at
https://github.com/eclipse/titan.TestPorts.LANL2asp

I'm not sure about the limitations though
no one tried with that many interfaces before
so the only way to find out is to try

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797077 is a reply to message #1797055]

Wed, 24 October 2018 16:50

Eclipse User

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.

Attachment: icmp_multiple.log
(Size: 8.56KB, Downloaded 139 times)
Attachment: ICMP2ETH.cfg
(Size: 1.82KB, Downloaded 118 times)
Attachment: ICMP2ETH.ttcn
(Size: 6.95KB, Downloaded 118 times)

[Updated on: Wed, 24 October 2018 16:50] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1797099 is a reply to message #1797077]

Thu, 25 October 2018 04:42

Eclipse User

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 07:18

Eclipse User

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

Attachment: ICMP2ETH.ttcn
(Size: 8.25KB, Downloaded 174 times)
Attachment: l2.ttcn-mr2-mtc.log
(Size: 6.25KB, Downloaded 119 times)

[Updated on: Thu, 25 October 2018 07:45] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1797133 is a reply to message #1797107]

Thu, 25 October 2018 18:41

Eclipse User

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;

Attachment: l2.ttcn-mr2-mtc-unsuccessful-ech_reply_timeout.log
(Size: 67.34KB, Downloaded 132 times)
Attachment: l2.ttcn-mr2-mtc_succes_echo_reply.log
(Size: 107.95KB, Downloaded 154 times)
Attachment: ICMP2ETH.ttcn
(Size: 8.47KB, Downloaded 133 times)

[Updated on: Thu, 25 October 2018 18:45] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1797166 is a reply to message #1797133]

Fri, 26 October 2018 11:11

Eclipse User

Re: Translation ports vs dual-faced ports part2 [message #1797167 is a reply to message #1797133]

Fri, 26 October 2018 11:11

Eclipse User

Hi Elemer,

We have a fundamental question regarding TTCN.

When we define a mac source address (eth_mac_address_source) in *.cfg config file, should the source mac address be the server mac source address ? (ifconfig see attached picture of previous conversation)
Can we insert any random mac address in *.cfg or is it hardcoded in TTCN to take the server source mac address ?

- Apart from the *.cfg config file, does TTCN validate elsewhere the source mac address of the server ?
- Is there a specific restriction on TTCN associated to the source mac address of the H/W ?

Regards - David

Attachment: E1.PNG
(Size: 36.98KB, Downloaded 157 times)

[Updated on: Fri, 26 October 2018 13:54] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1797182 is a reply to message #1797167]

Sat, 27 October 2018 02:30

Eclipse User

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 15:18

Eclipse User

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 15:24] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1797254 is a reply to message #1797228]

Mon, 29 October 2018 05:41

Eclipse User

Hi Mohan,

sure, there should be no problem with first changing the interface mac and then using that random mac in TTCN-3

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797263 is a reply to message #1797254]

Mon, 29 October 2018 07:16

Eclipse User

Hi Elemer,

Thanks for confirming i will check by changing it. But is it only via the EXTERNAL COMMANDS we should run this script? Or can it be programmed in .ttcn? Because it need to be called after each time the rnd() mac is generated.

Thanks
Mohan raj

Re: Translation ports vs dual-faced ports part2 [message #1797270 is a reply to message #1797263]

Mon, 29 October 2018 08:03

Eclipse User

Hi Mohan,

you can use the PIPE test port

https://github.com/eclipse/titan.TestPorts.PIPEasp

to run commands on the system

Also look into the utilities in
https://github.com/eclipse/titan.Libraries.TCCUsefulFunctions

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797310 is a reply to message #1797270]

Mon, 29 October 2018 15:40

Eclipse User

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 16:14] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1797361 is a reply to message #1797310]

Tue, 30 October 2018 06:22

Eclipse User

Hi David,

as far as I remember there's no such function but you can write your own and have it parameterized from the config file.

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797382 is a reply to message #1797361]

Tue, 30 October 2018 09:13

Eclipse User

Hi Elemer,

If you have some good references for writing external function can you let us know the link. I am writing a function to run a script, ia m not sure on how it should be defined on the TTCN side. The use of external keyword gives some compile issues.

Thanks
Mohan Raj

Re: Translation ports vs dual-faced ports part2 [message #1797383 is a reply to message #1797361]

Tue, 30 October 2018 09:16

Eclipse User

Re: Translation ports vs dual-faced ports part2 [message #1797415 is a reply to message #1797383]

Tue, 30 October 2018 12:29

Eclipse User

Hi Mohan,
it does not necessarily have to be an external function , you can conveniently write it in TTCN-3.

As for external functions, a good reference is the collection of useful functions I have mentioned.

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797482 is a reply to message #1797415]

Wed, 31 October 2018 10:06

Eclipse User

Thanks for your suggestions will try the same. By the way, i saw in TCCInterface functions, a function called f_setIP and f_setIP_ip. I do not understand the differnece between the two. Also, in f_setIP it is said we can mention the number of virtual interfaces we need to create, but in the funciton the number is equated to 1. Is this a limitation?

external function f_setIP(in charstring interface, in charstring ipaddress,
in charstring subnetmask, in charstring broadcast,
in integer number := 1)

Re: Translation ports vs dual-faced ports part2 [message #1797519 is a reply to message #1797482]

Thu, 01 November 2018 02:26

Eclipse User

Hi Mohan,
please read the documentation in /doc

number is set to 1 by default so if you omit it when calling the function, it will stay 1
if you set it to a value, the function will be called with that value

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797538 is a reply to message #1797519]

Thu, 01 November 2018 09:27

Eclipse User

Thanks Elemer, i checked the functionality and it works. But is it possible to have different MAC's for the virtual interfaces created. Because now i see the virtual interfaces created are having the same MAC as the original interface MAC. I dont see a way to change the MAC of the virtual interfaces that are getting created.

Meaing if we create ens3:0, ens3:1 interfaces they have the same MAC like ens3 (physical interface).

Thanks
Mohan Raj

Re: Translation ports vs dual-faced ports part2 [message #1797567 is a reply to message #1797538]

Thu, 01 November 2018 15:48

Eclipse User

Hi Mohan.

there are several ways to change the mac address from "ifconfig...". to "ip link..." and macchanger etc.

Please do a google search and chose the one suitable for your environment.

BR
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1797823 is a reply to message #1797567]

Tue, 06 November 2018 22:24

Eclipse User

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 02:47

Eclipse User

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 #1797850 is a reply to message #1797829]

Wed, 07 November 2018 07:58

Eclipse User

Hi Elemer,

We want to do MAC flooding which is a bunch of ARP_Request and ARP_Replies. Currently i dont think we have this protocol module implemented. I wanted to use the already existing ICMP modules. But i dont think it is possible until we write a separate module for ARP. I wanted your views on whether the ARP modules already exist in TTCN. From your reply, i understand, it doesn't exist and we have to create one.

I searched in the forum, and nobody have used ARP messages as far as i know. Also, we want to know if MAC flooding traffic can be generated using TTCN or do we need TitanSIM and is TitanSIM open source as well? I hear mixed feedback on TitanSim

Thanks
Mohan Raj

Re: Translation ports vs dual-faced ports part2 [message #1797852 is a reply to message #1797850]

Wed, 07 November 2018 08:11

Eclipse User

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 11:10

Eclipse User

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 16:54] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1797889 is a reply to message #1797865]

Thu, 08 November 2018 03:13

Eclipse User

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 10:56

Eclipse User

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 11:05] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1797932 is a reply to message #1797927]

Thu, 08 November 2018 12:30

Eclipse User

Hi Elemer,

1. For overized frame, I was able to catch/pass the dynamic error based on this doc
in the "Catching Dynamic Test Case Errors" section (https://github.com/eclipse/titan.core/blob/5d4b0ac7882f52054b78d9645c6f95d04a6b5591/usrguide/referenceguide/4-ttcn3_language_extensions.adoc)

2. For undersize frame, should I catch the following log event TTCN_WARNING as value or template "LANL2asp_PT('Lan_PCO'): Erroneous packet (size of captured packet is not correct: 43 bytes)" ?

Regards - David

[Updated on: Thu, 08 November 2018 13:06] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1798059 is a reply to message #1797932]

Mon, 12 November 2018 02:11

Eclipse User

Hi David,

if I understand correctly, one of the parties sends undersized frames. This is invalid and should be investigated and fixed.

Best regards

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1798113 is a reply to message #1798059]

Mon, 12 November 2018 11:17

Eclipse User

Hi Elemer,

For undersize frame, we purposely sent a small frame to receive the expected error LANL2asp_PT('Lan_PCO'): Erroneous packet (size of captured packet is not correct: 43 bytes).
Could we catch in the alt section of the function tc_ICMP_echo() after []Icmp_PCO.receive as: []Icmp_PCO.catch or by other means ?

Regards - David

[Updated on: Mon, 12 November 2018 11:25] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1798134 is a reply to message #1798113]

Tue, 13 November 2018 02:30

Eclipse User

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 #1798173 is a reply to message #1798134]

Tue, 13 November 2018 10:27

Eclipse User

Hi Elemer,

Thx for your concise response. Would you know how to activate Dribble bit in the config file or other means ?

Regards - David

[Updated on: Tue, 13 November 2018 10:28] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1798201 is a reply to message #1798173]

Wed, 14 November 2018 02:30

Eclipse User

Hi David,

the documentation and the code itself should answer all your questions.

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1798259 is a reply to message #1798201]

Wed, 14 November 2018 12:05

Eclipse User

Hi Elmer,

I was trying with a pre-compiled executable so far in a virtual machine, which ahd the needed environment. But when try to bring up ttcn on a server, i open the eclipse, but dont find the titan editing or other titan perspectives available. Is there anything i am missing? This is a fresh environment

Thanks
Mohan Raj

Re: Translation ports vs dual-faced ports part2 [message #1798273 is a reply to message #1798259]

Wed, 14 November 2018 14:28

Eclipse User

Hi Elmer,

IGNORE MY PREVIOUS COMMENT. Found the way to do it.

Thanks
Mohan Raj

[Updated on: Wed, 14 November 2018 17:54] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1798862 is a reply to message #1798273]

Mon, 26 November 2018 13:08

Eclipse User

Hi Elemer,

Does TTCN-3 support multiple destination ?
For instance, if we want to send an icmp request to 3 different server at the same time, meaning 3 different:
- ethernet interface
- destination mac address
- destination ip address

Regards - David

Re: Translation ports vs dual-faced ports part2 [message #1798898 is a reply to message #1798862]

Tue, 27 November 2018 02:54

Eclipse User

Hi David,

yes,

that's the whole point of multi-interface support in LANL2.

Not to split hairs, but that has nothing to do with TTCN-3 as a language per se, it's a feature of teh above-mentioned test port.

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1798909 is a reply to message #1798898]

Tue, 27 November 2018 05:49

Eclipse User

Hi David,

a small addition:

if you don't need different source mac address/network interface, than of course you can send icmp messages to different servers from teh same network interface as well.

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1798952 is a reply to message #1798909]

Tue, 27 November 2018 16:40

Eclipse User

Hi Elemer,

We are taking your advise and we are sending to 3 different destination ip address. However, we are unable to overwrite the dstaddr:=f_IPv4_addr_enc(dst_IP1) in the template IPv4_header t_IPv4_header.

Any hints would be greatly appreciated (see attached files)

Regards - David

Attachment: ICMP.txt
(Size: 8.70KB, Downloaded 115 times)
Attachment: icmp.log
(Size: 6.32KB, Downloaded 138 times)

Re: Translation ports vs dual-faced ports part2 [message #1798985 is a reply to message #1798952]

Wed, 28 November 2018 05:37

Eclipse User

Well,

in this case try with fixed templates with precalculated IPV4 addresses.

I'm sure you are running into a very simple mistake, and you should be able to fix it on your own.

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1798997 is a reply to message #1798985]

Wed, 28 November 2018 08:30

Eclipse User

Thx....would you have a sample link ?
Or do you mean that I would need multiple templates with fixed IPs ?

Regards - David

[Updated on: Wed, 28 November 2018 09:10] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1799000 is a reply to message #1798997]

Wed, 28 November 2018 08:54

Eclipse User

Hi David,

multiple templates with fixed mac/ip

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1799025 is a reply to message #1799000]

Wed, 28 November 2018 16:36

Eclipse User

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 16:46] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1799037 is a reply to message #1799025]

Thu, 29 November 2018 04:07

Eclipse User

Hui David,

you should not modify the translation port definition.

I'll let you workout the details yourselves.

BR

Elemer

Re: Translation ports vs dual-faced ports part2 [message #1799150 is a reply to message #1799037]

Fri, 30 November 2018 09:20

Eclipse User

Hi Elemer,

Thx....Would it be possible to return integer in function enc_PDU_ICMP while still keeping the extension prototype(fast) ?

Or our only option is to change it to prototype(backtrack) in order to return an integer ? and then change the type port IcmpPort

Regards - David

[Updated on: Fri, 30 November 2018 09:44] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1799184 is a reply to message #1799150]

Sat, 01 December 2018 02:57

Eclipse User

Hi David,

only prototype(backtrack) will return result in an integer
(see referenceguide 4.22.3 Encoder/decoder Function Prototypes)

Best regards
Elemer

Re: Translation ports vs dual-faced ports part2 [message #1803370 is a reply to message #1799184]

Wed, 27 February 2019 08:22

Eclipse User

No Message Body

Re: Translation ports vs dual-faced ports part2 [message #1803375 is a reply to message #1803370]

Wed, 27 February 2019 08:58

Eclipse User

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 09:04] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1803411 is a reply to message #1803375]

Thu, 28 February 2019 04:14

Eclipse User

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

Re: Translation ports vs dual-faced ports part2 [message #1803443 is a reply to message #1803411]

Thu, 28 February 2019 12:51

Eclipse User

Hi Elemer,

For instance, translation port test case would give us compiling error when we integrate with the port translation setup test case due to the IcmpPort.cc and IcmpPort.hh.

Are they incompatible ?

Regards - David

[Updated on: Thu, 28 February 2019 12:53] by Moderator

Re: Translation ports vs dual-faced ports part2 [message #1803466 is a reply to message #1803443]

Fri, 01 March 2019 02:50

Eclipse User

Hi David,

I would refer you to my previous answer.

BR

Elemer

Previous Topic:	Data operation
Next Topic:	Function parameter

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 13 01:29:15 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter